FC2ブログ

名張市つつじが丘おもちゃ病院

三重県名張市つつじが丘でおもちゃの病院を開院しています。年中無休で修理は無料、部品代のみ実費です。おもちゃの修理依頼は tutuji@cb4.so-net.ne.jp へメールにてご連絡下さい。なお、宅配便での受け付けは行っておりません。このブログにはおもちゃ等の修理事例やツール製作などを載せていきます。故障診断や修理方法の改善等、ご意見をお寄せ下さい。

2.4GHz8chリモコンモジュール「JDY-40」の評価

【前振り】
ラジコンカーの修理でCOB故障の場合に、 SE8R01+16F1503で換装するためのファームウェア を公開している。

最近、JDY-40と言う8chリモコンモジュールが出回っていて、価格は約83円(2019年AliExpress)で、SE8R01(約35円、2019年AliExpress)+16F1503(85円、2019年秋月)よりも安いのでコストメリットがある。

それで、JDY-40だけでラジコンカーの換装が可能なのか評価してみた。

なお、JDY-40はキーオン/キーオフの制御しかできないので、フルアクション方式での応用に絞って評価する。


【評価観点】
JDY-40はラジコンカーの制御を意図した製品では無いので、ラジコンカーに特有の以下の機能が実現できるかどうか、を評価する。

(1)ノーコン状態の検知と自動停止

電波伝搬の阻害やコントローラ側の電源ダウンなどでノーコン状態になったとき、速やかに車体を停止させる機能がラジコンカーでは必要不可欠だ。今まで数多くのラジコンカーを診てきたが、このフェールセーフ機能が無いものは見たことが無い。

(2)正逆転の排他制御機能

前後進駆動とステアリング制御で、正転と逆転の信号が同時に出ないように排他制御の機能が必要だ。トイラジでは専用のモータードライバICを使わないで、MOSFETやTrを組み合わせただけのベアなHブリッジを使っている場合が多い。最新の2.4GHzラジコンの「CCP社Wドライブ/Gドライブシリーズもそうである。その場合に正転と逆転の信号が同時に出るとHブリッジに貫通電流が流れて素子が破壊する。

JDY-40では、8chのキーオン/キーオフの制御はそれぞれ独立しているので、前進に割当てたchと後進に割当てたchが同時にオンすることを防ぐことはできない。従って、前進と後進の操作がタクトSWで同時に押せる構造のコントローラでは、同時に押すとその時点でHブリッジの素子が破壊する。ステアリング操作についても同じことが言える。そのため、そのような操作構造のコントローラに対しては、元々JDY-40を適用する考えが成り立たない。

そうすると、評価する意味が無くなってしまうので、ここでは、シーソータイプの操作構造のコントローラを想定して、機械的に前後進、或いは右左折の操作が同時には起きないことを前提として評価を行うこととする。


【評価回路】
JDY-40の簡易マニュアルに掲載されている回路で行った。
2.4GHz8点リモコンモジュール「JDY-40」の評価回路図
簡易マニュアルでの説明書きには「7 IO」と記載されているが、「8 IO」の誤りである。ここ以外にも、簡易マニュアルには誤記が多い。

送信側は CLSS=C1、受信側は CLSS=C4 を設定している。


【評価結果】
先ずは実験動画をご覧いただきたい。


(1)ノーコン状態の検知と自動停止

結果はNG。

・送信側はキーオンまたはキーオフされた瞬間に一度だけ指令を送信し、それ以外はSleepしている。受信側は新たな指令を受信するまで前回の指令を保持している。

・電波伝搬の阻害やコントローラ側の電源ダウンなどでキーオフの指令が届かなかった場合は、車体は走り続けてしまう。

(2)正逆転の排他制御機能

結果はNG。

・上記(1)と同じ理屈で、正転信号のchがオフされないまま、逆転信号のchがオン状態になってしまう。JDY-40がラジコンカーの制御を意図した製品ではないので、当然の結果ではある。

・トイラジではベアなHブリッジを採用しているものが殆どなので、このような状況になることは極めて危険である。

(3)総合評価

ラジコンカーで必須な機能がJDY-40だけでは実現できないことが明らかになった。そのため、外付けの制御回路で機能を補う必要がある。

・ノーコン状態を検知させるには、一定時間間隔で指令を送受信させる仕組みにする必要があり、送信側と受信側の両方にロジック回路の追加、若しくは、マイコンでの制御が必要になる。

・正逆転の排他制御機能は受信側にロジック回路の追加が必要になる。ベアなHブリッジをブレーキング機能が付いたモータードライバICに交換するにしてもデッドバンド制御は必要になる。

・不足する機能を外付け回路で補うとJDY-40の廉価性と実装の容易性が失われてしまうので、現状では、ラジコンカーの修理にJDY-40を採用するメリットは無い。

・外付けロジック回路を装備せずにJDY-40だけで、ベアなHブリッジを実装したラジコンカーを換装することは極めて危険であり、やってはならない。
スポンサーサイト



  1. 2019/08/25(日) 12:21:53|
  2. 2.4GHzラジコン
  3. | コメント:0

PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦

【前振り】
PIC電子オルゴールVer6_1の改善(ブリッジ出力) は以前にやってみたのだが、性能面の理由から失敗 していた。

しかし、ブリッジ出力にするメリットは大きいので、再挑戦することにした。

ブリッジ出力のメリット

・低電圧でも大きな音で鳴る。シングル出力に比べて4倍の出力になる。
・音の内容やブリッジ回路以降の特性などによるが、消費電流は1/2以下になる。
・上記の2つを合わせて、電力効率は8倍以上になる。


【設計】
内部のPCMデータの取り扱いをWAV形式にすることは前回と同じで、そのため、演算処理を全般的に変更する。これは前回の試行で実施済みだ。

今回は性能改善が取り組みの課題になる。

PIC電子オルゴールの内部の処理は以下の3つの部分から成る。

・曲演奏/音声再生処理(それぞれのサンプリング周期で実行)

・出力合算処理(PWM周期で実行)

・メイン制御(メインループ)

ミュート処理は、従来は出力合算時に演算していたが、これを実行頻度が少ない曲演奏/音声再生処理に持ってくることで全体のDSを削減する。

聴感上問題にならない程度に、エンベロープ処理における乗算処理のビット数を少なくする。従来は7ビット演算していたが、5ビットに縮小する。約3%の分解能になる。

前の記事 で、「PIC電子オルゴールでサポートしてきたデバイスで、ブリッジ出力ができるかどうか調べた」のだが、その結果に間違いがあったので、今回の開発での結果を掲示しておく。

16F1503 CWGにはフルブリッジモードが無く、PWMをマスター/スレーブ構成にすることもできないのでブリッジ出力は不可能
12F1572 CWGにはフルブリッジモードが無いが、PWMをマスター/スレーブ構成にしてブリッジ出力が可能
16F1579 CWGにはフルブリッジモードが無いが、PWMをマスター/スレーブ構成にしてブリッジ出力が可能
12F1612 CWGにはフルブリッジモードが無いが、同期ステアリングモードでブリッジ出力が可能
16F1705 COGのフルブリッジモードで、ブリッジ出力が可能
12F1822 CCPのシングル出力同期ステアリングモードで、ブリッジ出力が可能
12F1840 CCPのシングル出力同期ステアリングモードで、ブリッジ出力が可能
16F15325 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18313 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18325 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18326 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18857 CWGのフルブリッジモードで、ブリッジ出力が可能

なお、12F1501は1kワードしかなく、orgel6_1の最少構成でも載らないのでサポート対象から落とした。


【評価】
性能改善については、曲演奏と音声再生をコンカレントに走行しても正常な音で鳴っていて、アンダーランは発生していない。

音量と電力効率の評価には 16F1705 を使った。正相出力ピンと逆相出力ピン(シングル出力時はGNDピン)に290Ωスピーカを繋いで、スピーカの両端子間の電圧を観測した。PICの電源電圧は4.5Vで、全体の消費電流も測定した。

シングル出力時
PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦シングル出力波形
出力電圧はほぼ電源電圧、消費電流は7.6mA

コンプリ出力時
PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦コンプリ出力波形
出力電圧は電源電圧のほぼ2倍、消費電流は9.1mA


ブリッジ出力時
PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦ブリッジ出力波形
出力電圧は電源電圧のほぼ2倍、消費電流は3.5mA

PIC自体の消費電流が2mA強あることから、ブリッジ出力での電力効率は非常に高いことが判る。音の大きさはコンプリ出力時と全く変わらない。但し、信号レベルや出力段(実際に繋ぐHブリッジ以降)の特性によるが、かなりの改善が期待できる。


【ダウンロード】

orgel6_1の最新版は ここから ダウンロードできる。

当面旧版のVer5_7も残しておくが、バグがあってもメンテしない。
  1. 2019/08/21(水) 13:54:34|
  2. 電子オルゴール+音声再生
  3. | コメント:1

PIC電子オルゴールVer6_1の改善(フルブリッジ出力)は失敗

ホントに参りました。

PIC電子オルゴールVer6_1の改善(ブリッジ出力)」 は、タッチセンスのモデルで不具合が出て改善の見通しが立たないため、WAV形式PCM値で処理するという目論見は失敗と判断した。

今後も悪あがきはすると思うが、解決できるかどうかは判らない。
  1. 2019/08/02(金) 14:11:50|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer6_1の改善(ブリッジ出力)

【前振り】
PIC電子オルゴールVer5_7では、PWMの出力タイプが、シングル出力と相補出力しかなかった。相補出力ではスピーカーをBTL駆動できるが、音声レベルが0のときにも50%デューティのPWMが出てしまう。これを、音声レベルが0のときは、ブリッジの正相と逆相ともにデューティが0となるように改善を施した。今回の改善は、内部のPCMデータの扱いをunsignedからWAV形式に変える大きな変更であるため、バージョン番号を 6_1 に革めた。


【設計の経緯】
PIC電子オルゴール開発の当初はシングル出力のみを想定していて、演奏出力が無いときはPWMデューティを0としていた。オルゴールの音源データをunsignedの0から始まるように作っておくことで、演奏の始まりではPCM値が自然に0となり、PCM値をそのままデューティに設定するだけでポップノイズ対策は不要だった。演奏の終わりではエンベロープレベルが小さくなっていくので、これまた自然に0となる。つまり、内部の演算処理をunsignedでやることが都合がよく、簡単であった。WAV形式での扱いは考えに無かった。

その後、音声再生をサポートしたときに、音声データはWAV形式(音声レベル0のPCM値は0x80)であり、いきなり音声データのPCM値をデューティに設定すると大きなポップノイズが発生する問題が生じた。この対策として、音声再生開始前にデューティが最初の音声データ値になるまでランプ出力し、音声再生終了後は逆にデューティが0になるまでランプ出力するようにした。

効率的なブリッジ駆動のためには、音声レベルが0のときは正相と逆相ともデューティ0にするのが良いのだが、従前のunsignedのPCM値をPWM出力時点で正相分と逆相に分けるのが難しい。その点、WAV形式のPCM値はレベル0を中心に正負に振れているので、ブリッジ出力にマッチしている。

音声再生をサポート後も内部の演算処理はunsignedのままにして、ポップノイズの抑止だけを刹那的に対応してきた訳で、スマートな設計ではないのが気になっていた。そこで、今回は音源データからWAV形式に統一して、まともなブリッジ出力を行うように改変した。


【設計】
・今までPIC電子オルゴールでサポートしてきたデバイスで、ブリッジ出力ができるかどうか調べた。

1501 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1503 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1572 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1579 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1612 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1705 COGのフルブリッジモードで、ブリッジ出力が可能
1822 CCPが1個で、フルブリッジモードも無いため、ブリッジ出力は不可能
1840 CCPのステアリングモード(同期)で、ブリッジ出力が可能
15325 CWGのフルブリッジモードで、ブリッジ出力が可能
18313 CWGのフルブリッジモードで、ブリッジ出力が可能
18325 CWGのフルブリッジモードで、ブリッジ出力が可能
18326 CWGのフルブリッジモードで、ブリッジ出力が可能
18857 CWGのフルブリッジモードで、ブリッジ出力が可能

 1822 はブリッジ出力は不可能で、これは諦める。

 1840 は特殊なやり方になるが、個別対応でできそうだ。

 15xx はソフトの工夫でブリッジ出力ができそうだ。

・15xx で、PWMモジュールの出力ピンを切り替えることで1個のPWMモジュールを正相と逆相に共用させようとすると、デューティレジスタがバッファリングされているのに対してピン切り替えはリアルタイムで効いてしまうので、同期することができず上手く行かない。今回は、正相出力用と逆相出力用に別のPWMモジュールを対応付けて、それぞれにデューティ設定するやり方のフィージビリティスタディとしてやってみる。

・従来から BTL=x で指定している出力タイプは シングル出力・コンプリ出力・ブリッジ出力 の3種類に替える。

 シングル出力(BTL=0)は、正相のみを正論理で出力し、出力が無いときはデューティ0とする。旧版(Ver5_7)の BTL=0 と同じ動作をする。

 コンプリ出力(BTL=1)は、正相の正論理出力に加えて、逆相に正相のコンプリ波形を出力する。出力が無いときはデューティ0とする。旧版(Ver5_7)の BTL=1 と同じ動作をする。

 ブリッジ出力(BTL=2)は、正相と逆相とも正論理で出力し、出力レベルが0のときは正相と逆相ともデューティ0とする。出力レベルが正のときは正相のみに出力レベルに応じたデューティで出力する。出力レベルが負のときは逆相のみに出力レベルに応じたデューティで出力する。旧版(Ver5_7)の BTL=2 とは異なる動作をする。

 旧版(Ver5_7)の BTL=2(BTL出力でSleep時は同相出力する) は廃止する。

BTL=2 のときの出力波形
PIC電子オルゴールVer6_1BTL=2出力波形

・音源データをWAV形式に作り替える。

 オルゴールの音源でExcelの計算で作ったものはレベル0から始まるように作り替える。エンベロープ波形データとピッチベンド波形データはunsignedのままで処理するので変更不要。

 ピアノなどのサンプリング音源波形はレベル0の部分が先頭に来るようにデータを移動する。

 音声データはWAVファイルから変換したときにWAV形式PCM値になっているので対応不要。

・内部の演算処理をWAV形式対応に替える。

 PIC16は乗算命令がないのでソフト実装している。従来は unsigned×unsigned の処理しか用意していなかったが、WAV形式×unsigned の処理も用意する。

 加減算もWAV形式で行うように替える。

・正相と逆相間で出力が切り替わるときはデッドバンドを確保する。

 デューティが100%、およびそれに近い状態で正相と逆相が切り替わるときは貫通電量が発生する可能性がある。そのため、最低限確保するデッドバンド(正相と逆相がともにオフになる時間)を設定可能とする。具体的には、オフとなるPWMステップ数が指定されたステップ数よりも小さい場合は、切り替わった最初のデューティを0とする。極めて乱暴な処置だが、100%デューティに近い状態から正逆が反転することは音声データの場合には殆ど無いと考える。


【ダウンロード】
PIC電子オルゴールVer6_1の設計資料と開発プロジェクトは ここから ダウンロードできる。

現在は16F1705のプロジェクトのみ旧版(Ver5_7)から移行している。その他のデバイスについては今後拡充していく。


(重要)後日談】
16F1705のタッチセンスのプロジェクトの動作がおかしいので、原因を調べたところ、演奏/音声再生のデータ準備でアンダーランが発生していることが判った。WAV形式PCM値の演算が各所にあり、それぞれは若干のダイナミックステップ増なのだが、チリツモで全体ではCPU消費が増大している。それと、タッチセンスの処理は固有処理と割り込み処理でCPUを喰うので、問題が顕在化した。

数日間改善を試みたが、アンダーランの解消には至らず。

PIC電子オルゴールVer6_1は残念ながら、開発を中断したことをここに告知する。
  1. 2019/07/31(水) 15:27:43|
  2. 電子オルゴール+音声再生
  3. | コメント:0

2.4GHzラジコン用ファームウェアの改善(電源瞬低への対応)の続編

【前振り】
先般、 「2.4GHzラジコン用ファームウェアの改善(電源瞬低への対応)」 のファームウェアを公開したばかりだが、スッキリしないところがあった。

コントローラからの指令が一定時間(標準値200ms)途切れたら、車体を停止させる。このフェールセーフ機能は以前から実装していた。通信阻害が続く場合は電源電圧の瞬低によるトランシーバのダウンが想定されるので、フェールセーフ機能が働いたときはトランシーバの初期設定を再度行うようにしたのが先般の改善だ。

車体を停止させるには、フルアクション制御とESC制御ではモータードライバへの出力をオフすればよいのだが、サーボ制御の場合は予め設定されたサーボパルス巾(ニュートラル位置)で出力を継続する必要がある。

サーボパルスの標準仕様は周期20ms、パルス巾は1~2msである。16F1503や16F18325等の10ビットPWMではPWM周期を20msにすると1ステップは20usになり、サーボパルスの可変巾1msに対して2%の分解能しか得られない。もう少し分解能を稼ぎたいので、少し工夫している。

PWM周期をサーボパルスの最大巾の2msに近付けて、PWMのn周期がサーボパルス周期の20msになるようにする。つまり、PWMのn周期中のうち1周期のみにサーボパルスを出力することで、PWMのステップ巾を小さくする考えだ。

TMR2のクロックソースとプリスケーラの選択条件の中では、Fosc=16MHz、プリスケ=1/64、PR=249 の設定でPWM周期は4msになり、n=5でサーボパルス周期を20msにできる。1ステップは4usでサーボパルスの可変巾1msに対して0.4%の分解能に改善できる。なお、PWM周期を2msにしないのは、サーボパルス巾の最大巾を2.5msまで拡張可能とするためだ。

2.4GHzラジコン用ファームウェアの改善(電源瞬低への対応)の続編

PWM出力を1/nに間引く操作はソフト実装していて、メインループの中で行っている。この処理はPWM周期の4ms以内に動作する必要がある。そこに、トランシーバの初期設定のような時間が掛かる処理が入ると、サーボパルスが規定通りに出せなくなってしまうのである。これが、「スッキリしないところ」なのだ。

改善策は、PWM出力を1/nに間引く操作を割り込み処理で行うことだ。そうすれば、メインループでの処理状況に影響を受けずに正しくサーボパルスを出力できる。

16ビットPWMを持ったデバイス、例えば16F157x系を使えば解決できる問題だが、デバイスが割高なので今はソフトの工夫で対処する。


【設計】
上記のとおり、PWMデューティの設定をPWM周期(TMR2)割り込み処理で実行するように変更した。


【ダウンロード】
ファームウェアの設計資料と開発プロジェクトは下記からダウンロードできる。

制御タイプが動的に変更可能な「デモ」仕様は ここから ダウンロードできる。

ホルダ名とプロジェクト名に、トランシーバのデバイス名・送信側/受信側の別・PICのデバイス名を織り込んでいる。「MON」が付いたプロジェクトは、開発時に使う受信モニタで、おもちゃには実装しない。


制御タイプを駆動とステアリングともにデジタル入力フルアクションに固定したものは ここから ダウンロードできる。トランシーバはSE8R01とnRF24L01+のみサポートしている。

制御タイプをCCP社G-DRIVE/W-DRIVEのデジプロ対応に固定したものは ここから ダウンロードできる。トランシーバはSE8R01とnRF24L01+のみサポートしている。
  1. 2019/07/15(月) 21:50:21|
  2. 2.4GHzラジコン
  3. | コメント:0

2.4GHzラジコン用ファームウェアの改善(電源瞬低への対応)

【前振り】
つつじが丘おもちゃ病院では2.4GHzラジコンのエンコーダ/デコーダ、トランシーバが故障した場合にそれらを換装するためのファームウェアを開発して、当ブログで公開してきた。例えば、

2.4GHzラジコン用ファームウェア(フルアクションタイプ対応版)

2.4GHzラジコン用ファームウェア(CCP社G-DRIVE/W-DRIVEのデジプロ対応版)

2.4GHzラジコン用ファームウェアのデモボード

上記以外にも関連記事が多くあり、「2.4GHzラジコン」でブログ内検索すると出てくる。

これらのファームウェアの利用者は徐々に増えてきていて、実装の結果や改善意見をいただいている。僕はファームウェアと技術情報を提供しているが、実際のおもちゃへの換装は数が少ない。そのためフィールドからいただくご意見はファームウェアを改善していくのに大変有難い。その中で 「電源瞬低への対応」 が要望され、今回対応した。


【要件】
ラジコンが動いているときには電池電流が大きく変動する。特に走り始めるときや急加速時には大きなモーター電流が流れて、電池電圧が瞬低する。制御に使っているPICは電源電圧の瞬低により停止しても、復電するとPORして動作を再開する。しかし、トランシーバモジュールは一度ダウンすると、PORしてもキャリブレーションを含む初期設定を再度実行しないと通信は再開できない。

トランシーバがダウンした事を検知して、初期設定を再実行することが今回の改善要件である。

安定な電源電圧を担保するには昇圧電源を装備することが本来のやり方であろうが、できるだけ廉価にファームウェア側での対応だけで済ませられないか、というのがテーマだ。


【設計】
・トランシーバがダウンしたことの検知

トランシーバのデータシートにPORの要件が示されていて、電源電圧が緩やかに変動する場合は正常にPORされず、デバイスの状態は不定になることがある。例えばCC2500では
2.4GHzラジコン用ファームウェアの改善(電源瞬低への対応)CC2500のPOR条件

トランシーバがダウンしている最中はSPIの応答が無いので検知できるが、復電し再稼働後はSPIの応答はあり、ステータス等を読み出すと正常な値を返してくる。そのため、SPIの応答ではトランシーバがダウンしたことは検知できない。次善の策として、正常な受信が一定時間以上無かった場合にトランシーバがダウンしたと見做して初期設定を再実行することにする。

コントローラ側ではトランシーバのダウンを検知する方法が無いため、コントローラ側のファームウェアでは対応しない。電源電圧の瞬低は負荷電流が急激に増加する車体側で発生するものであり、コントローラ側での対応は不要と考える。

・初期設定の再実行

以前から、通信阻害による暴走を防止するために、一定時間コントローラからの電波を受信しなかった場合は車体を停止させる仕様になっている。今回は、その時限を超えて更に受信できない状態が継続したらトランシーバの初期設定を実行する。

トランシーバが正常にPORしていない場合があるので、初期設定を再実行する前にトランシーバをリセットしておく。

具体的なやり方としては、トランシーバのダウンを検知したらPICをソフトリセットして再起動する。


【対応デバイス】
・PIC
16F1503
16F1705
16F18325

・トランシーバ
SE8R01
nRF24L01+(パワー強化版と非強化版)
A7105
CC2500

上記のPICとトランシーバの組み合わせが可能


【動作検証】
改善前後の動作検証を 飯塚こわれたおもちゃの相談所さん がやってくれた。多謝


【ダウンロード】
ファームウェアの設計資料と開発プロジェクトは ここから ダウンロードできる。

制御タイプが動的に変更可能な「デモ」仕様になっているので、実際のおもちゃの換装に応用する場合はおもちゃの構造に合わせて制御タイプを固定すること。具体的には、ソースコードの1行で制御タイプを宣言するだけだ。

ホルダ名とプロジェクト名に、トランシーバのデバイス名・送信側/受信側の別・PICのデバイス名を織り込んでいる。「MON」が付いたプロジェクトは、開発時に使う受信モニタで、おもちゃには実装しない。


制御タイプを駆動とステアリングともにデジタル入力フルアクションに固定したものは ここから ダウンロードできる。トランシーバはSE8R01とnRF24L01+のみサポートしている。

制御タイプをCCP社G-DRIVE/W-DRIVEのデジプロ対応に固定したものは ここから ダウンロードできる。トランシーバはSE8R01とnRF24L01+のみサポートしている。
  1. 2019/07/14(日) 08:49:30|
  2. 2.4GHzラジコン
  3. | コメント:0

PIC電子オルゴールで12F1572と16F1579のサンプルプロジェクトを追加

【前振り】
昨年から公開ファイルには追加されていたのだが、公式のアナウンスはこれが初めてだ(と思う)。

157xはPWM機能が強化されたデバイスで、分解能はなんと16ビットだ。

でも 「そんなの関係ねぇ!」。 PIC電子オルゴールは音源が8ビットしかない。だから、16ピットPWMのメリットは無く、8ビット分解能でいいから半額にして欲しい。

それでも、PIC電子オルゴールでサポートしたのは、それなりに廉価だから。PIC電子オルゴールでは動作スピードとメモリ容量が重要だ。8ピン2kワードでは12F1572が最安(2019年秋月価格@80円)、8kワード20ピンでは16F1579が最安(2019年秋月価格@140円)。AliExpressには12F1572(SOP)が@30円台で出ている。

PIC電子オルゴールの開発当初は、当時最廉価だった12F1822(秋月@80円)を使っていたが、現在は(PIC電子オルゴールとしては)12F1572が代替品となる。


【設計】
PIC電子オルゴールのエンジン部は記述が汎用化されていて、デバイスの差異の影響を受けない(ように設計している)ので、PIC電子オルゴールでのサポートとは、固有処理部にデバイス固有の定義と初期化、それと必要なら割り込み処理のオンコーディング部を書くことだ。

今回のデバイスはPWM機能が強化されていて、PWM関連のレジスタの種類と設定内容が従来のデバイスと全く異なる。そのため、PWMモジュールの初期設定とPWM周期割り込み処理でのデューティ設定トリガの設定を新規に書いた。詳細はソースコードの該当部分を従来のデバイスと比較すれば理解し易い。


【ダウンロード】
PIC電子オルゴールのファームウェアは ここから ダウンロードできる。

追加したプロジェクトは
 demo_PIC1572.X onsei_PIC1572.X onsei_PIC1572_I2C.X onsei_PIC1572_SD.X onsei_PIC1572_SPI.X
 demo_PIC1579.X onsei_PIC1579.X onsei_PIC1579_I2C.X onsei_PIC1579_SD.X onsei_PIC1579_SPI.X
  1. 2019/06/24(月) 18:50:35|
  2. 電子オルゴール+音声再生
  3. | コメント:0

ミミクリーペット系おもちゃの基板換装用の完成基板の頒布(飯塚こわれたおもちゃの相談所)

ミミクリーペット系おもちゃの基板換装用の完成基板の頒布を始めた。
ミミクリーペット系おもちゃの基板換装用の完成基板の頒布(飯塚こわれたおもちゃの相談所)基板外観

と言っても、それは「つつじが丘おもちゃ病院」(当院)ではない。当院ではファームウェアを無償で提供しているだけで、ファームウェア書き込み済みマイコンや換装用の基板の頒布は行っていない。頒布を始めたのは 飯塚こわれたおもちゃの相談所 さんだ。上記の画像は飯塚こわれたおもちゃの相談所さんのブログ記事から転載したもの。

換装用基板の仕様や頒布の条件については、飯塚こわれたおもちゃの相談所さんのブログ記事 「オウム返し おもちゃ」修理用マイコン基板の頒布 を参照。
  1. 2019/06/17(月) 09:10:31|
  2. 音声再生・録音再生
  3. | コメント:0

「DFPlayerMiniの制御」のレジューム対応版の改善

DFPlayerMiniの制御車載外観2

【前振り】
「DFPlayerMiniの制御」の記事はしつこいくらいに出てくる。申し訳ないが、今回も。

おもちゃの修理も含めて人からの頼まれ物は納期があり、それなりに完成するのだが、自分の製作物はいつまでも工事中であり、完成することが無い。

【改善点】
「DFPlayerMiniの制御用ファームウェア」も少しずつ改善されてきていて、今回の改善点は、「ソフトUART送信のビットのタイミングをタイマーで計時するようにした」ことだ。

以前は、ビット巾をスピンループで待っていたため、割り込み処理が走行するとビット巾が延びて、通信エラーになる恐れがあった。そのため、アプリ処理の流れで、送信と割り込み処理が同時に起きないようにしていた。本末転倒の対処だった。

【設計】
正確に言うと改善後もスピンループであるのだが、ループの中でタイマーを見ることで、割り込み処理が走っても正確に計時する。

計時にはTMR0を使う。TMR0は赤外線受信にも使っているが、赤外線受信とDFプレーヤーへの送信は同時並行処理をしないので、TMR0を共用することができる。TMR2はDFプレーヤーからの割り込み受信に使用していて、これは非同期処理なのでTMR2の共用はできない。TMR1は、それを内蔵していないデバイスもあって、ファームウェアのポータビリティを確保するため敬遠した。

経時の方法はオーソドックスに、TMR0に (-経時時間) を設定し、TMR0のオーバフローを待つ。実際には、TMR0の更新時のインクリ抑止期間と関数呼び出しを含めたオーバヘッド分を加味してTMR0を設定する。

この処理は、DFプレーヤーへの送信処理とデバグ情報出力のソフトUARTに適用した。対象のターゲットデバイスは 12F1501 と 16F18313。10F322 はメモリが満杯で手入れができない状況である。

【改善結果】
ホルダ内トラック数のクエリと再生開始コマンド間を130ms空けていたが、30msの待ちに短縮できた。使用感としては変化には気付かない程度だが。

デバグ情報の採取の制約が少なくなったので、デバグはやり易くなった。こちらの方が僕としてはメリットがある。他の開発プロジェクトにも展開して行きたい。

【ダウンロード】
設計資料とファームウェアの開発プロジェクトは ここから ダウンロードできる。

プロジェクトは DFPlayer_1501.X と DFPlayer_18313.X
  1. 2019/06/16(日) 21:48:24|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」のレジューム対応版で12F1501をサポート

DFPlayerMiniの制御車載外観2

【前振り】
電源オフ/オンで動作状態を引き継ぐ「レジューム機能」をサポート したのだが、16F18313のEEPROMに引継情報を退避するのに43msも掛かるので、その間のVddを保持するのに1000uFもの大きな電解コンが必要だった。EEPROMの書き換えがバイト単位であることが書き換えに時間が掛かる原因になっている。それに対して、HEFはROW単位での書き換えなので、書き換え時間が短くて済む。それで、ターゲットデバイスを12F1501に替えて、引継情報の退避先をHEFにしてみた。

【設計】
12F1501のHEFの書き換え(消去+書き込み)に必要な時間はデータシートでは約4ms、実測では3.3msであった。16F18313のEEPROMの書き換え時間の1/10以下だ。書き換え時間にVddを保持するためのパスコンを小さくできる。実測による評価を行った結果、22uFとした。

Vddのパスコンを22uFとしたときの引継情報書き替えタイミングの実測結果
DFPlayerMiniの制御1501(HEF書替えタイミング検証)

引継情報の1バイトはHEF上では1ワードに対応する。また、HEFの書き換えはROW単位なので、12F1501のROWサイズの16ワードになるよう引継情報の構造体にはダミーエリアを設けておく。

//----------------------------------------------
//作業領域
//----------------------------------------------
static struct DF_CNT //DFプレーヤーの引継情報
{
unsigned char val1; //有効性検証バイト1
unsigned char df_mode; //DFプレーヤーの動作モード
// (0=SD内リピート、1=ホルダ内リピート、2=1トラックリピート)
unsigned char df_volume; //DFプレーヤーの音量設定値
unsigned char df_eq; //DFプレーヤーのイコライザ設定値
unsigned char df_pause; //DFプレーヤーのpause設定値(0=停止中、1=再生中)
unsigned char df_hld_no; //DFプレーヤーのホルダ番号
unsigned char df_trk_no; //DFプレーヤーのホルダ内トラック番号
unsigned char dummy[8]; //ROWを埋めるためのダミー
unsigned char val2; //有効性検証バイト2
} df_cnt;

#define HEF_ADR 0x3f0 //HEFのワードアドレス

//----------------------------------------------
//HEF領域
//----------------------------------------------
const struct DF_CNT HEF@HEF_ADR={0xff,0xff}; //DFプレーヤーの引継情報の初期値

上記のようにHEF領域を確保しておけば、該当するHEFの領域にプログラムコードが配置されることを防止できる。リンカーコマンドやスクリプトで領域を確保するより、簡便でプログラムの見通しが良い。

12F1501はUARTモジュールを内蔵していないので、DFプレーヤーからの受信は、ソフトUARTの割込み処理で実装する。

【回路図と配線図】

DFPlayerMiniの制御1501(回路図)

DFPlayerMiniの制御1501(配線図1)
DFPlayerMiniの制御1501(配線図2)


【ダウンロード】
設計資料とファームウェアの開発プロジェクトは ここから ダウンロードできる。

プロジェクトは DFPlayer_1501.X

【感想】
これからは、EEPROMよりも書き換え時間が短かいHEFを利用するのがよさそうだ。
  1. 2019/06/08(土) 21:18:23|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」で操作性を改善(レジューム機能の改善)

DFPlayerMiniの制御車載外観2

【前振り】
一昨日行った 「DFPlayerMiniの制御」で操作性を改善(レジューム機能)」 は、EEPROMへの引継情報の退避が頻繁に発生して宜しくない。書き込み許容回数が1日27回じゃ少な過ぎる。そう思いながら作ったのだが、やはり宜しくない。そこで、電源オフのときにだけ退避するように、今になって真面目に取り組むことにした。

【設計】
電源がオフされても、引継情報を退避する時間はVddが保持されるように、電源からショットキーを介してVddを供給し、Vddには大きな電解コンを設置しておく。

Vddを抵抗分圧してコンパレータに入れて、FVRの1.024Vと比較することで、Vddが低下したことを検知する。

EEPROMへの書込み時間は5ms掛かるので8バイトの書き込みには40ms掛かる。実測による評価を行った結果、330uFとした。

Vddのパスコンを330uFとしたときの引継情報書き替えタイミングの実測結果
DFPlayerMiniの制御18313(EEP書替えタイミング検証)

【回路図と配線図】

DFPlayerMiniの制御18313(回路図)

DFPlayerMiniの制御18313(配線図1)
DFPlayerMiniの制御18313(配線図2)
Vddのパスコン330uFは基板には載せていない。


【ダウンロード】
設計資料とファームウェアの開発プロジェクトは ここから ダウンロードできる。

プロジェクトは DFPlayer_18313.X

【課題】
EEPROMへの書込みはバイト単位なので、引継情報のバイト数だけ時間が掛かる。そのため、Vddを保持する電解コンに大きなものが必要になる。そこで、退避先をHEFにすれば、ROW単位の消去書込みになるので、退避時間を短くできると思う。
  1. 2019/06/07(金) 19:16:21|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」で操作性を改善(レジューム機能)

DFPlayerMiniの制御車載外観2

【前振り】
以前に作ったDFプレーヤー は車載で使っているのだが、車のキーONをするたびに再生開始の操作をするのが煩わしくなってきた。それで、キーON時には、キーOFFしたときの曲を自動的に再生開始するようにした。

【設計】
動作状態が変わる都度、管理情報をEEPROMに退避する。
POR時にEEPROMから管理情報を回復して、DFプレーヤを前回動作時の状態に設定する。
PAUSE状態だったときは、再生開始しない。
電源断を挟んで引き継ぐ情報は以下の通り。
・リピートモード(SD内リピート/ホルダ内リピート/1曲リピート)
・音量設定
・イコライザ設定
・PAUSE状態
・ホルダ番号
・トラック番号
ターゲットデバイスはEEPROMを持つものなら何でもよいので、廉価な16F18313を採用した。

EEPROMの書き替え耐力は100k回なので、10年間毎日使うとすると1日当たりの書き替え許容回数は 100k/10年/365日=27回 しかない。そのため、できるだけ永く使えるように、引継情報の書き換えは再生終了時とPAUSE操作時のみとした。ホルダとトラックの選択、音量、イコライザの変更は再生が終了するかPAUSEが操作されるまで引継情報に反映されないことになるが、許容することにする。

【回路図・配線図】
DFPlayerMiniの制御Cタイプ(回路図)
DFPlayerMiniの制御Cタイプ(配線図1)
DFPlayerMiniの制御Cタイプ(配線図2)


【ダウンロード】
設計資料とファームウェアの開発プロジェクトは ここから ダウンロードできる。

プロジェクトは DFPlayer_18313.X
  1. 2019/06/05(水) 21:04:18|
  2. 電子オルゴール+音声再生
  3. | コメント:0

ミミクリーペット基板換装用ファームウェア(12F1501+24C256)

ミミクリ基板換装12F1501外観
ミミクリ基板換装12F1501基板

【前振り】
ミミクリの基板を換装するのにはtiny13Aが現時点では最廉価なのだが、AVRの開発環境を持たないおもちゃドクターには利用して貰えない。そのため、12F1501用のファームウェアを公開することにした。ずっと前にもPICを使ったミミクリ換装基板を紹介しているのだが、それ以降に機能改善をしてきているので、今回改めて公開する。

【改善点】
今回は以下の改善を施している。

・ゼロクロスポイントで再生を繰り返すことで、音質を改善
・オートパワーオフ機能をサポート
・3V電源(電池2本)動作での安定性確保

【設計】
ゼロクロスポイントについては ここを 参照。

オートパワーオフを実現するためには、マイクアンプの電源を制御する必要があるが、ポート数が足りなくて、独立してポートを割り当てられない。ピン数が多いデバイスに替えればよいのだが、そうすると基板が大きくなり、修理対象のおもちゃに収納することができなくなる恐れがある。

対策として、PWM出力をモーター制御にも兼用する。音声再生中は少なくとも1ステップのPWMが出ていると見做して、モーター制御用のゲート電圧を生成する。

3V電源(電池2本)動作での安定性確保については ここを 参照。

【回路図と配線図】
ミミクリ基板換装12F1501回路図

ショットキーと放電回路は3V(乾電池2本)での運用を考慮して電源電圧の瞬低に対応したものだが、4.5Vでの運用の場合は不要だ。放電用ダイオードはVfが0.6V以下のものを選ぶ。
3V電源の場合を想定して低VgsのFETを使っているが、4.5V電源ではフツウの、より廉価なもので構わない。

ミミクリ基板換装12F1501配線図

【実装結果】
Sleep時の消費電流は13uAだった。

【ダウンロード】
設計資料と開発プロジェクトは ここから ダウロードできる。
プロジェクト名にターゲットデバイスの型番を織り込んでいる。
  1. 2019/05/17(金) 17:55:49|
  2. 音声再生・録音再生
  3. | コメント:0

ミミクリーペット基板換装用ファームウェア(tiny13A+24C256)

ミミクリ基板換装tiny13A外観
ミミクリ基板換装tiny13A基板

【前振り】
ミミクリーペットの基板を換装するためのファームウェアは、デバイスの価格変動への対応や機能改善を幾度も行ってきている。直近では 「ミミクリーペットのマイコン換装の改善(tiny13A+24C256+ECM使用)」 を公開した。しかし、その版ではオートパワーオフのインプリメントを忘れていたので、また、改版を公開することになった。

【要件】
・音声入力待ちが一定時間継続するとオートパワーオフする。
・オートパワーオフの時限は数分から数10分程度とする。

【設計】
前回の改善で、tiny13Aのプログラムメモリが残り8ワードになっていて、このままでは機能追加は難しい。今はCで書いていて、アセンブラにすると小さくなると思うが、やり直す気力がない。そのため、音声レベルの評価を一部手抜きしたり、I2CのタイミングマージンのためのNOPを取ったりして、10数ワードを空けた。

tiny13Aのタイマーは8ビットのタイマー0しか無く、それはPWMで既に使っている。WDTを使う方法もあるが、WDTを汎用タイマーとして利用するにはプログラムステップが嵩むので、メモリに余裕のない状況では避けたい。

そのため、PWM周期(正確にはADC実行周期)をベースタイマーとして、ソフトでポストスケーラを実装することにする。ポストスケーラの分周比は10進で8桁程度が必要になるので、long変数でカウントする。

・音声入力待ちに入る前に監視時限を設定しておき、音声無しの評価の都度デクリしていく。
・0になったら、省電力設定してSleepする。
・Wakeupトリガは用意しない。起動は電源の再投入とする。

【回路図と配線図】

ミミクリ基板換装tiny13A回路図
ショットキーと放電回路は3V(乾電池2本)での運用を考慮して電源電圧の瞬低に対応したものだが、4.5Vでの運用の場合は不要だ。放電用ダイオードはVfが0.6V以下のものを選ぶ。
3V電源の場合を想定して低VgsのFETを使っているが、4.5V電源ではフツウの、より廉価なもので構わない。

ミミクリ基板換装tiny13A配線図

【実装結果】
Sleep時の消費電流は0.2uAだった。

【ダウンロード】
設計資料と開発プロジェクトは ここから ダウロードできる。
プロジェクト名にターゲットデバイスの型番を織り込んでいる。
tiny85のプロジェクトはデバグ用である。tiny13Aはメモリが少なくて、デバグ行を入れるとパンクしてしまう。そのため、兄貴分のtiny85を使って実機デバグを行っている。
  1. 2019/05/17(金) 17:26:07|
  2. 音声再生・録音再生
  3. | コメント:0

PIC電子オルゴールVer5_7でCPSモジュールを使ったタッチセンスで音声再生

【前振り】
CPSを内蔵していないPICで実現したタッチセンスは当ブログで既に公開していて、おもちゃ修理に応用していただいている。簡易版(ローコスト版)なので、それなりの感度と安定性でときには誤動作することもあり、おもちゃとしては愛嬌があるかなと。それで今回は、CPSモジュールを使ってキチンとしたタッチセンスをやってみた。

【結果】
下記の動画のとおり、すこぶる快調に動作する。数10円のコスト差以上の価値がある。

長押しを検知する前には短押しを検知するが、それは自然の道理だ。
デモには含んでいないがマルチタッチも可能で、マトリクスSWとして使うこともできる。

【設計】
・使用部品
ターゲットデバイスはCPSモジュール内蔵では最廉価なPICの16F1823。
音声データを格納するSPIフラッシュはW25Q16。
CR類は電源パスコンの10uFが1個だけ。

・SPIは内蔵のMSSPモジュールを使う。16F1823は内蔵モジュールのピン割り当てがほぼ決められているので不自由だが、逆に悩みは無く、SPIピンを割り当てて残ったピンをタッチセンスに使う。

・「設計」と言って何かウンチクめいたことを書きたいのだけれど、CPSモジュールの使い方はデータシートの通りで工夫も何も無く、書くことが無い。オプションは幾つかあり、例えば「参照電圧」とか「電源モード」とかが選択できるのだが、変えてみての比較評価はしていない。

・タイマーリソースにはTMR1を使った。PIC電子オルゴールではPWM出力にTMR2を使っていて、TMR0とTMR1は空いている。ビット数が多いのと、カウントの開始と停止の制御がやり易いTMR1にした。

・固定タイムベースはPIC電子オルゴールの固有処理のコールバック周期を10msに設定して、それを使った。今回はCPSモジュールの入力チャネル数を5個としたので、特定のチャネルを評価するのは50ms周期となる。電子オルゴールの操作を行うには丁度良い時間だ。

・カウント値は時系列平均をとって、動作環境の揺らぎに追随するようにした。時系列平均値へのサンプル値の反映は1/16ずつにして、800msで半分程度が新陳代謝する。

・実機動作確認で判ったことは、入力チャネルによってカウント値が大きくバラつくことだ。そのため、カウント値の変化、つまりタッチ感度が違う。そこで、タッチ有り無しの判定の閾値は入力チャネル毎にチューニングができるようにした。おもちゃへの実装では入力チャネル毎に配線ルートやパッド形状が異なると思われるので、実装状態でチューニングを行う必要がありそうだ。

・回路図
PICとメモリを繋ぐだけなので、回路図は書いていない。ソースコードにコメント書きしているピン割り当てを参照のこと。

【ダウンロード】
PIC電子オルゴールのファームウェアは ここから ダウンロードできる。

プロジェクトは onsei_PIC1823_SPI_touch.X
親のソースコードは onsei_PIC1823_SPI_touch..asm
音声データは voice_TOUCH
  1. 2019/05/14(火) 20:45:13|
  2. 電子オルゴール+音声再生
  3. | コメント:0

2.4GHzラジコン用ファームウェア(フルアクションタイプ対応版)

2.4GHzラジコン用ファームウェア は以下の制御タイプで使用可能なものを公開している。

・フルアクション制御
TX2/RX2に代表される前後進と右左折、及びターボの操作が可能なもの。動作はオンかオフの制御であり、プロポーショナルな制御はできない。

・サーボ制御
操作量によって制御量をプロポーショナルに制御するもの。標準のサーボパルスを出力して、サーボを制御する。

・ESC制御
前後進のモーターをESC制御するもの。

・アナログ入力のフルアクション制御
動作はフルアクションだが、操作信号をアナログ電圧で入力するもの。

上記の制御タイプを自由に組み合わせて使うことができるように、汎用性を持たせたファームウェアを公開している。実際におもちゃを換装するときには、制御タイプを決めるためのカスタマイズを行うことを前提としている。

しかし、このカスタマイズ作業の依頼が増えてきていて、需要が多そうな制御タイプにカスタマイズを施したものを用意しておこうと思っている。先日公開した「2.4GHzラジコン用ファームウェア(CCP社G-DRIVE/W-DRIVEのデジプロ対応版)」もその一つだ。

今回は、前後進と右左折ともにオン/オフ動作のフルアクション制御に固定したものを公開する。この制御タイプは昔からあるベーシックなものだ。操作信号のインタフェースはTX2/RX2と同様に、負論理のデジタル信号をPICのポートに入力する。信号レベルはPICの規定に従う。

【ハード構成】
コントローラ側と車体側ともに、トランシーバモジュールはSE8R01(またはnRF24L01+)、マイコンは16F1503を使用する。

コントローラ側の操作SWは既存のものを使って、エンコードとRF部を上記の構成で換装する。

車体側のモータードライバーは既存のものを使って、RFとデコード部を上記の構成で換装する。

【周辺回路の設計情報】
コントローラ側16F1503のポート割り当ては以下の通り。
//RA0:後進SW入力(負論理、内部プルアッフ
//RA1:前進SW入力(負論理、内部プルアッフ)
//RA2:ターボSW入力(負論理、内部プルアッフ)
//RA3:無接続
//RA4:左折SW入力(負論理、内部プルアッフ)
//RA5:右折SW入力(負論理、内部プルアッフ)
//RC0:SE8R01(またはnRF24L01+)のSCK
//RC1:SE8R01(またはnRF24L01+)のMISO
//RC2:SE8R01(またはnRF24L01+)のMOSI
//RC3:SE8R01(またはnRF24L01+)のCSN
//RC4:SE8R01(またはnRF24L01+)のCE
//RC5:無接続

車体側16F1503のポート割り当ては以下の通り。
//RA0:無接続
//RA1:ターボ出力(正論理)
//RA2:左折出力(正論理)
//RA3:無接続
//RA4:SE8R01(またはnRF24L01+)のMISO
//RA5:SE8R01(またはnRF24L01+)のMOSI
//RC0:SE8R01(またはnRF24L01+)のSCK
//RC1:右折出力(正論理)
//RC2:SE8R01(またはnRF24L01+)のCSN
//RC3:後進出力(正論理)
//RC4:SE8R01(またはnRF24L01+)のCE
//RC5:前進出力(正論理)

【ダウンロード】
ファームウェアの設計情報とプロジェクト一式は ここから ダウンロードできる。

プロジェクトは以下の通り。

コントローラ側
RC24_SE8R01_TX_1503.X
RC24_nRF24L01_TX_1503.X

車体側
RC24_SE8R01_RX_1503.X
RC24_nRF24L01_RX_1503.X
  1. 2019/04/16(火) 11:16:36|
  2. 2.4GHzラジコン
  3. | コメント:0

アンパンマンはじめてのおしゃべり48(音源のバックアップ)

PINOCCHIOの「アンパンマンはじめてのおしゃべり48」というぬいぐるみの知育おもちゃ。
アンパンマンはじめてのおしゃべり48外観

基板に電源は来ているが、うんともすんとも言わない。COB不良で音声再生の換装事案かと診察するのを楽しみにしていたのだが、不動作の原因は基板のランド剥がれで、バイパス配線で復旧してしまった。

でも、このような音声再生ものは音源が命だから、元気なうちにバックアップを録っておくことが重要だ。音源さえあればCOB換装はなんとかなる。

アンパンマンはじめてのおしゃべり48(音源ダイジェスト)

仕掛けはタッチセンスだった。両手両足腹鼻頭の7か所にタッチパッドが設置されていて、体中にタッチパッドの配線が走っている。そのため、抱いたまま遊ぶと誤動作が起き易いようだ。基板には傾斜センサーも設置されていた。

しゃべる文言はランダムであったり、「数を数えるよ」では10まで数えないと終らなかったり、動作シナリオがよく判らない。だから、すべての文言と効果音をバックアップできたかどうかは判らない。それと、実際に換装するときはシナリオを創作する必要がありそうだが、今はやらない。
  1. 2019/04/12(金) 20:21:53|
  2. 電子オルゴール+音声再生
  3. | コメント:0

2.4GHzラジコン用ファームウェア(CCP社G-DRIVE/W-DRIVEのデジプロ対応版)

CCP社のG-DRIVE、及びW-DRIVEの基板換装用のファームウェアの需要が多いようなので、つつじが丘おもちゃ病院が公開している 「2.4GHzラジコン用ファームウェア」 をG-DRIVE/W-DRIVE用にカスタマイズしたものを公開する。

2.4GHzラジコン用ファームウェア(CCP社G-DRIVE/W-DRIVEのデジプロ対応版)G-DRIVE
2.4GHzラジコン用ファームウェア(CCP社G-DRIVE/W-DRIVEのデジプロ対応版)W-DRIVE


【適用条件】
一口にG-DRIVE/W-DRIVEと言ってもいろんなバリエーションがあり、今回対応しているのは「スピードコントロール(デジプロ)」が謳われているのものだ。特徴は、コントローラのステアリング操作はSWのオン/オフで、前後進はボリュームでプロポーショナルに操作できるようになっている。

換装後もステアリングの操作はSWのオン/オフで、前後進はボリュームでプロポーショナルに操作できる。車体側では前後進はPWMによるESCとなる。

前後進の操作では、PICに入力される操作信号の電圧は以下を前提としている。そうなるようにボリューム回路を構成すること。

・操作量0%~100%で操作信号の電圧はGND~Vddまで変化する。

コントローラに使われているボリュームは、抵抗値の可変範囲の角度が非常に小さいタイプで、操作スティックの操作で抵抗値が0%~100%のフルに変化する。

前後進の操作量と制御量の対応は既製品のG-DRIVEの操作フィーリングに合わせて、以下のように設定している。
(このG-DRIVEの操作フィーイングは「おもちゃの病院さがみはら」の一色様から要件をいただき、カスタマイズの結果についても評価していただいた。感謝)

・操作量0%~30%はフル後進
・操作量30%~70%はフル後進~フル前進の比例制御
・操作量70%~100%はフル前進
・操作量50%で停止

このファームウェアは、CCP社の制御プロトコルとは互換性が無いので、コントローラ側と車体側の双方とも換装する必要がある。

CCP社とのペアリングはできない。また、当該ファームウェアに置いてもペアリング機能は実装していないので、換装後のコントローラと車体は1対1に括り付けとなる。ペアリングの仕様をまだ決めていないが、需要があれば検討したい。

コントローラ側は、ニッカド充電池2本での運用を可能とするため、BORをOFFに設定している。LFタイプを使用するのがスジだが、廉価なFタイプで動かすための策だ。実験結果ではVddが2.2Vまで動作した。CPUがダウン後にVddを回復すると正常にPORするため、BORをOFFで運用しても支障は無いと考える。

【ハード構成】
コントローラ側と車体側ともに、トランシーバモジュールはSE8R01(またはnRF24L01+)、マイコンは16F1503を使用する。

コントローラ側の操作SW、ボリュームは既存のものを使って、エンコードとRF部を上記の構成で換装する。

車体側のモータードライバーは既存のものを使って、RFとデコード部を上記の構成で換装する。

【周辺回路の設計情報】
コントローラ側16F1503のポート割り当ては以下の通り。
//RA0:無接続
//RA1:前後進ボリューム入力
//RA2:無接続
//RA3:無接続
//RA4:左折SW入力(負論理、内部プルアッフ)
//RA5:右折SW入力(負論理、内部プルアッフ)
//RC0:SE8R01(またはnRF24L01+)のSCK
//RC1:SE8R01(またはnRF24L01+)のMISO
//RC2:SE8R01(またはnRF24L01+)のMOSI
//RC3:SE8R01(またはnRF24L01+)のCSN
//RC4:SE8R01(またはnRF24L01+)のCE
//RC5:無接続

車体側16F1503のポート割り当ては以下の通り。
//RA0:無接続
//RA1:無接続
//RA2:左折出力(正論理)
//RA3:無接続
//RA4:SE8R01(またはnRF24L01+)のMISO
//RA5:SE8R01(またはnRF24L01+)のMOSI
//RC0:SE8R01(またはnRF24L01+)のSCK
//RC1:右折出力(正論理)
//RC2:SE8R01(またはnRF24L01+)のCSN
//RC3:後進出力(PWM、正論理)
//RC4:SE8R01(またはnRF24L01+)のCE
//RC5:前進出力(PWM、正論理)

【ダウンロード】
ファームウェアの設計情報とプロジェクト一式は ここから ダウンロードできる。

プロジェクトは以下の通り。

コントローラ側
RC24_SE8R01_TX_1503.X
RC24_nRF24L01_TX_1503.X

車体側
RC24_SE8R01_RX_1503.X
RC24_nRF24L01_RX_1503.X
  1. 2019/04/11(木) 23:00:04|
  2. 2.4GHzラジコン
  3. | コメント:0

ミミクリーペットのマイコン換装の改善(tiny13A+24C256+ECM使用)

【今回の改善ポイント】
前回の改善 ではスピーカーとマイクを兼用してコストを抑えたが、考えてみるとおもちゃの換装時は既存のマイクを使えばよいので、スピーカーとマイクを兼用するメリットはない。逆にスピーカーをマイク代用すると音があまりクリアではないデメリットがある。それで、今回はフツウにECMを使ったものにした。初めからそうしておけば良かった。

もう一点の改善点はファームウェアの設計条件をオプション化したこと。

・PWM出力とモーター制御出力のポートをPB0とPB1で交換可能とした。
・PWM出力の極性を正論理か負論理か変更可能とした。
・モーター制御出力の極性を正論理か負論理か変更可能とした。

設定方法
//#define PWM_PB1 //PWMをPB1へ、モーター制御をPB0へ出力するときに宣言する
//#define PWM_INV //PWMを負論理で出力するときに宣言する
//#define MTR_INV //モーター制御を負論理で出力するときに宣言する

当方が公開しているファームウェアは複製・改変・再配布はフリーで、応用ケースごとにカスタマイズして使って貰う前提で、設計資料とソースコードの全てを公開している。しかし、正論理を負論理に変えるだけのカスタマイズでも当方へ依頼が多くあり、オプション化しておくと僕も対応が楽なので、カスタマイズの依頼が多そうなものは予めオプション化している。

【全体像】
ミミクリーペット5ECM全体

【回路図と配線図】
ミミクリーペット5ECM回路図


ミミクリーペット5ECM配線図

【実装】
ミミクリーペット5ECM基板表
ミミクリーペット5ECM基板裏

【再生音】
tiny13A+24C256+ECM使用版再生音

【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。
  1. 2019/04/08(月) 20:14:01|
  2. 音声再生・録音再生
  3. | コメント:0

「DFPlayerMiniの制御」で操作性を改善(SDカードの抜き挿し対応)

DFPlayerMiniの制御で操作性を改善(任意のトラックからのリピート再生) をやったばかりだが、今度は SDカードの抜き挿し に対応した。あってしかるべき機能だが、今までは無かった。当初はおもちゃの音声再生機能の換装を目的としたフィージビリティスタディだったので、コマンド1発で操作できる機能しか実現しなかった。その後、フツウのMP3プレーヤーとしての機能改善で、任意のトラックからのリピート再生を行ったのだが、SDカードの抜き差しもフツウに必要と感じてきた。

【要件】
SDカードの抜き挿し対応が無いとどうなるかと言うと、デバイス内のホルダ数の情報が更新されないため、実在しないホルダへ飛んだり、逆に実在するホルダへ進めなかったりする。機能追加と言うよりバグ対応に近いかも。

今回追加した機能は以下の2つのみだ。

・SDカードが抜かれたら、デバイスの管理情報をクリアする。
・SDカードが挿入されたら、デバイスの管理情報を取り込む。

【設計】
今回はファームウェアのみの改善であり、回路図と配線図は DFプレーヤーを制御するファームウェア を参照。 

DFPlayerMiniからの非同期通知で、該当イベントを受信したら、要件の処理を行う。

【ダウンロード】
設計資料とファームウェアの開発プロジェクトは ここから ダウンロードできる。

プロジェクトは DFPlayerB_322.X
  1. 2019/04/01(月) 07:46:33|
  2. 電子オルゴール+音声再生
  3. | コメント:0
次のページ

プロフィール

大泉茂幸

Author:大泉茂幸
名張市つつじが丘おもちゃ病院
名張市つつじが丘南3番町129
tutuji@cb4.so-net.ne.jp
090-5534-6494
連絡は上記のメール、またはSMSでお願いします。

子どもの頃から趣味は電子工作一筋でやってきました。理科離れが進む中で科学技術に興味を持つ子どもが少しでも増えて行くことを願って、子ども達に電子工作の活動の場を提供しています。

1981年からおもちゃ病院の活動を始め、2014年に三重県名張市への移住を機に「つつじが丘おもちゃ病院」を開院しました。自分でおもちゃを設計し製作する【おもちゃ工房】と、マイコンを応用した電子工作を楽しむ【マイコンクラブ】も併設しています。新規参加メンバーを募集しています。

当ブログで公開している技術情報や成果物の複製、改変および再配布はフリーです。読者様のおもちゃ病院活動のお役に立てば幸いです。ご利用いただいた結果や感想等を記事へのコメントやメールでフィードバックしていただけると有難いです。なお、公開ファイルは最新版を載せているので、古い記事の内容から変わっている場合があります。

カテゴリ

おもちゃ修理技術 (124)
¦ ・電子オルゴール+音声再生 (52)
¦ ・音声再生・録音再生 (13)
¦ ・2.4GHzラジコン (35)
¦ ・レガシーラジコン (13)
¦ ・赤外線リモコン (4)
¦ ・RFID (3)
¦ ・タッチセンス (4)
ツール製作 (35)
¦ ・プログラマー (27)
¦ ・USB-シリアル変換 (3)
¦ ・その他のツール (5)
修理事例 (157)
¦ ・マイコン換装 (75)
¦ ・電子・電気修理 (59)
¦ ・メカ修理 (23)
製作記事 (5)
PIC開発 (4)
おもちゃ病院 (9)
ドクター研修会 (2)
未分類 (0)

最新記事

最新コメント

月別アーカイブ

訪問者数

検索フォーム

RSSリンクの表示

リンク

このブログをリンクに追加する

QRコード

QR