Darkside(リンクエラー修正しました)

2018年07月の記事

<< 前のページ

2018年7月17日(火) 22:41

ドップラーセンサー

 ハイスピードカメラ注文中だが、受け入れ準備が必要だ。
 ハイスピードカメラは、撮影可能時間が短い。だから、撮影対象が来たことを検知し、カメラにトリガー信号を送る。すなわち、動体検出装置を別途用意せねばならない。動体検知は監視カメラでも必須であり、潰しが効く。しかし、適切な手法が難しいのも、既に分かっている。

 ハイスピードカメラだけであれば、動体が横切ったときに検出できれば実用になる。それならば、赤外線パッシブの人感センサーが効果的である。だが、人感センサーは体温と背景の温度差が4度ぐらい無いといけない。今の季節は、検出感度が落ちる可能性がある。
 また、監視カメラは縦方向の動きを検出したい状況が多いため、人感センサーは不適切であることも判明している。すなわち、潰しが効かない。

 そこで、秋月に買い出しするとき目に付いた、ドップラーセンサーを試してみた。

 ドップラーセンサーはレーダー電波を発し、反射波の周波数ズレから接近あるいは遠ざかる動きを検出する。
 超音波で似たようなことをする動体センサーは以前試して、実用にならなかった。だが、超音波動体センサーは反射音の遅延から距離を検出しているだけであり、速度を検出していたのではない。そのため、近傍に反射体があるとその反射音が支配的となり、それより遠い場所の物体が検出困難になる。
 すなわち、狭い通路などでは実用にならない。

 しかしドップラーセンサーだと、近傍の壁で反射したものは周波数が変わらないため、引っ掛からない。ごちゃごちゃした室内でも、素晴らしい検出能力が確認できた。
 これは、監視カメラ用トリガーとして極めて優秀だ。

 ただし、秋月のキットは10.5ギガヘルツ帯なので、室内専用である。電波法上、屋外での使用は認められていない。室内監視カメラにしか使えない。

 24ギガヘルツ帯なら屋外でも使えるのに、なぜ秋月は制約が多い10.5ギガヘルツ帯をキット化したのか?
 恐らくは、コストだろう。室内しか使えないことから人気がなく、24ギガヘルツ帯よりレーダーがかなり安い。

 しかし、10.5ギガヘルツ帯でも、ドップラーセンサーの桁外れな動体検出能力が確認できた。ならば、24ギガヘルツ帯のレーダーを買って、自作すれば良い。

 実際には、センサーと周辺回路が一体になった24ギガヘルツ帯のレーダーも、秋月は扱っている。しかしそれは、明らかに監視カメラ用である。内部で信号処理し、虫が横切ったり葉が風で揺れるという類の誤検出が発生しにくいようメーカーが調整してくれている。
 監視カメラでその手の誤検出は、猛烈に多い。だから、そのうち買って監視カメラとの組み合わせを研究するのも良いだろう。

 しかし、直近の用途はソレではない。ハイスピードカメラのトリガーだ。
 用途が異なると、誤検出を減らす信号処理は「おせっかい」になりかねない。素のデーターを出力してくれるレーダーの方が扱い易い。もちろん、秋月で扱っている。そっちをキット化すれば良いのに、と思うがデーターシートを見ると、キットのレーダーより出力が強そうだ。dsPIC あたりに読み込んで自分で信号処理すれば良い。

・・・とまあ結局こんな感じで、キットは10.5ギガヘルツ帯なのだろう。

written by higashino [カメラ] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年7月16日(月) 21:21

割り込み

 ゲートドライバーは、1つでローサイドとハイサイドのペアを駆動できる。つまり、モーター1つに3個で足りる。左右なら合計6個だ。

 そこで、まとめて製作しようと更に3個を変換基板に載せたが、ハンダブリッジが解消できずに悪戦苦闘。遂に断念。
 ところが、別の変換基板を使ったら嘘のように簡単にハンダ付けできてしまった。

 この変換基板は、配線が太いことが気に入って買い足した。だが、作業性でも非常にすぐれている。太いだけに熱も伝わり易く、ハンダが配線部分だけに高速で綺麗に流れる。

 本筋の作業としては、今日はこれだけである。裏でいろいろやっているが・・・

 その代わり、近年にないほど大量の買い出しを行った。特に、無線モジュールの試験は優先順位が高い。別件で無線を使う必要が出て来たので、この際無線部分の作業を割り込みさせる。
 ドリル戦車だって、無線は必要になる。後でやるか、今やるかの差でしかない。

written by higashino [ドリル戦車] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年7月15日(日) 20:43

吸い取り線

 いよいよ本丸たるブラシレスモーター制御を試験すべく、ドライバーを製作する。
 dsPIC は制御信号を出力することができるが、実際にモーターを動かすにはFETやゲートドライバーが必須だ。

 ゲートドライバーは、例の本を参考に LM5101A を採用。
 ドライブ電流最大3Aで、制御信号がTTLレベルすなわち3.3V系マイコン直結可能。
 ただし、最近の有用素子の例に漏れず、DIPパッケージが存在しない。表面実装品しかない。ピッチ1.27ミリはマシな方だが、いちおう変換基板にハンダ付けする。

 ピッチ0.65ミリの更に小さなタイプは、腹に放熱部が存在しそこに放熱体をハンダ付けすることが推奨されている。しかし、1.27ミリのパッケージは、特別な放熱部は無い。

 表面実装品をハンダ付けする場合、ハンダブリッジお構い無しにハンダ付けを済ませて、ハンダ吸い取り線でブリッジ部分を除去するという手法が定番だ。
 しかし、在庫のハンダ吸い取り線(右)だと、どうやっても無理。そう、在庫が存在するのは理由があって、使い物にならないから減らないのだ。

 止むを得ず、いつもの吸い取り線(左)を買いに行く。幅1.5ミリという最も細い吸い取り線を使い、先端を押し当てるとほぐれて広がる。広がっただけ薄くなり、熱が伝わり易くなる。これで、ようやく吸い取り可能になる。

 LM5101A 自体はハイサイド電位100Vまでしか対応していないが、それだけあれば十分過ぎる。
 それより、チャージポンプ用のコンデンサーを適正に選ぶのが大変だ。いっそハイサイドには絶縁型DC-DCを接続すれば、と以前考えたが、良く考えると3相すべてに独立したDC-DCコンバーターが必要になる。更に、ローサイドも12Vは欲しいのでDC-DCが必要。つまり、モーター1つにDC-DCコンバーターが4つも必要になる。戦車だから左右あって、合計8つ。さすがにそれは、二の足を踏む。

 FETに関しては秋月だけ見ていると適切なものが無いが、もっと世の中広く探せば耐圧40Vの超強力なものが存在した。
 IRL7472L1TRPBF という奴で、正真正銘の化け物である。ゲート操作10Vで、オン抵抗が最大0.45ミリオーム。耐電流375A、パルス耐電流1500A。これなら、並列接続せずに十分な性能。つまり、モーター1個あたり6個使用すれば済む。左右で12個。価格は1個400円なので、FET費用が想定より遥かに安く済む。

 現在までの経験から、FETはどんどん高性能化が進んでいるのを感じる。つまり、これは凄い!と買い溜めするのは下策。必要になるたびに、その時点での最新鋭のFETを選定し購入するのが正しい。
 だから、予備2個を確保し最小限の14個しか注文しなかった。

written by higashino [ドリル戦車] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年7月14日(土) 21:20

あくまで手段

 I2Cでは、常時Lという問題は解消された。だが、途中で止まってしまう。
 LCDに対して送るコマンドは、3バイト1組である。

1)スレイブアドレスを送信
2)0を送信
3)コマンドを送信

 ここで、2)までは終了するが、3)が終了しない。送信の内部にLチカを仕込んで調べると、送信できているがスレイブがACKを返して来ない。1)と2)ではACKが返って来ているのに、3)だけ返って来ないのは意味不明。
 そこで、オシロの出番。

 なぜか、1)が捉えられない。2)と3)だけ捉えられている。そして、2)だけでなく3)も、ACKは返って来ているように見える。となると、問題はソフト側だ。ソフトのちょっとした命令入れ替えで動作したりしなくなったりするのがI2Cである。動作例はネットにいろいろ転がっているが、コピペしてもどこかに障害が出てなぜか動かない、というのがI2Cあるあるだ。

 ACK受信までの手順を試行錯誤していると、遂に液晶表示に成功!
・・・なのだが、異様に薄い。かろうじて文字が読めるぐらいで、コントラストを最大限に調整しても写真を撮れないぐらい薄い表示にしかならない。
 オシロでは、

 一部の波形が妙にクリッピングされている。しかも、ソフトを元に戻してもクリッピングは直らない。それでも極薄表示なりに液晶が使えるのだから、とオシロを外したら表示されなくなった。
 オシロのプローブを付けると、液晶に極薄表示される。プローブを外すと、何も表示されない。プローブを外したときのI2C波形は、当たり前だが不明である。どこの量子力学だよ!

 今日も繰り返すが、液晶表示とかI2C使用とか、あくまでも手段である。目的ではない。だからもう開き直って、液晶表示させたい時はオシロを付けることにした。ハード周りに何か実装上の問題があるのだろうが、究明している暇など無い。
 必要ならオシロを付けて表示させデバッグする。

 1系統だけになったので12ビットに戻したADCが、ちゃんと読めていることを液晶表示して確認。
 しかし別の問題として、sprintf が猛烈にメモリーを消費する。この命令1つ増えただけで、プログラムエリアの37%ぐらいを食ってしまうのだ。確かにコード量が多い関数だというのは想像が付くが、逆に言うと dsPIC33 のプログラムエリアが小さ過ぎる。
 やはり、dsPIC33 にはブラシレスモーター制御のみを任せ、ドリル戦車のメインCPUは STM32F4 にするのが無難だ。

written by higashino [ドリル戦車] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2018年7月13日(金) 21:35

やらかした

 ソフトSPI接続で実績ある液晶に表示できるよう配線を急いで用意し、試す。だが、何も表示されない。そればかりか、データーもクロックも全く出力されない。ソフトで記述しているのに、ずっとLのままだ。いや、使用する3線のうち、RA1は出力されてている。RB8とRB9がLのままだ。
 出力されない2本は、I2Cで使用していた2線である。ここに至り、犯人はI2Cではない可能性が急浮上。

 SPIというよりソフトでしっかり出力制御しているのに、RB8とRB9が反応しない。まずはその理由を探ることにした。
 結論として、PWMが犯人だった。

 PWMの使用は、デバイス・コンフィギュレーション・レジスターで設定する。すなわち、_FPOR である。
 そのため、実行開始後に何もしなくても、PWMは有効になったままである。PWM出力は8本あって、そのうち6本しか使わない。だが、そのままだと残りの2本もPWM用に確保され、一般I/Oとしては使えない。その2本こそが、RB8とRB9である。I2C用の出力ピンでもある。
 そう、設定でRB8とRB9をPWMで「使用しない」ようにしておかねばならなかったのだ。

PWM2CON1bits.PEN1L = 0; // PWM2L1無効
PWM2CON1bits.PEN1H = 0; // PWM2H1無効

 これでRB8とRB9にも出力できるようになり、ソフトSPI液晶に表示成功!
 この手の設定干渉問題はMCCなら簡単に回避できるはずであり、MCC対応が遅れていることは大変なデメリットになっている。
 いずれにしろI2Cで苦労する必要なんか、なかったんだ・・・で済むかと思いきや、かなり不安定。表示更新はしばしば止まるし、dsPIC 自体も止まる。頻繁にリセットボタンが活躍する。
 エネループ4本では液晶電源の電圧不足になっている可能性があるが、それで dsPIC が不安定になるはずはない。電源を共用したせいで、ノイズが載って dsPIC と液晶側PIC の双方に影響しているのではないか?

 PIC16F88 を2つ動作させ、不安定になった経験がある。
 安易に電源ラインを引き回したのは、まずかったかもしれない。使い勝手が悪くなるが、液晶には別電源を用意する方がいい。そう考えて、エネループ6本を独立電源として液晶側に供給。基板にバッテリーケースをハンダ付けし、準備完了。まずは、液晶単体で動かしてみる。もちろん何も表示されないが・・・って表示されているぞ?

 シミのような意味不明なグラフィックが表示されて、アメーバのようにうごめいている。これは?
 パチンと小さな音が鳴って、かすかな煙。やっちまった!
 自作なので分かっていると油断し、キチンと確認せずにハンダ付けしてしまった。そう、極性を逆に取り付けてしまったのだ。かくして、自作SPI液晶は、死んでしまった。

 再びI2Cに戻るしかない。少なくとも、出力が常時Lだった原因は判明した。その問題に関しては解消できているはずだ。

written by higashino [ドリル戦車] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

<< 前のページ

Darkside(リンクエラー修正しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4