RaspberryPiのライブカメラ制御系と基板工作

　ライブカメラの可動部のメカは、ほぼ想定どおりに出来上がった。チルトもパンのモーターも順調に回る。次は、ブレッドボードにあるモーター駆動部の基板化や、カメラの動きを制御する系の開発である。

　やることが沢山ある。例によって、メモにDoitリストを書き上げてこれからの作業工程を確認する。まずは、カメラの可動の始点・終点制御の具体化である。

始点・終点処理の実装にはフォトインタラプター(7/18/2013)
　今度の機械は、これまでの自動巻き機と違って回転の範囲を制限しなければならない。ステッピングモーターなので、回した角度を厳密に覚えておけば、始点・終点は考えなくても良い理屈だが、ステッピングモーターはパルスをかけても廻らない、脱調という現象は避けられないので、何らかの対応策は必須である。

　色々な方法が考えられる。マイクロスイッチなどを使った物理的なストッパーが一番わかりやすいが、今回は、以前ライントレーサーを作ろうと沢山買ったフォトインタラプターを使ってみることにする。ここでマスターしておけば、今後のライントレーサー制作にも役立つ。

　しかし、ライントレーサーのような精密なセンシング手法はともかく、こんど実装しようとしている単にカメラの移動を制限するだけの簡単なセンシングは、解説しているサイトが見つからない。どこかに定番の方法があるのかもしれない。車輪の再発明のようなことは避けたいが、参考になる資料がないので自分で考えるしかない。

　まず、ブレッドボードに、むかし脈拍計の実験に使った反射型フォトインタラプターTPR-105をつけてテストを始める。このインタラプターは、かなり近距離（1ミリ以下）でないと出力が出ない。買った当初は、こいつは低性能だと馬鹿にしていたが、ネットから落としたデータシートにはちゃんと明記してあった。そういうためのディバイスなのだ（失礼しました）。

　それはともかく、データシートに従い、LEDに330Ω、集光側のエミッタに10KΩの負荷抵抗をつなぎ、Vccに5Vをかけて出力をオシロで見る。スイープを1秒以上に上げておくと、様子が良く見える。

　予定している反射面は乳白色のプラスティック（ABS樹脂）のギアである。このギアの生地の反射率は、低いのか高いのか、いまひとつはっきりしない。別の白い紙をあてると出力は高まるが、少し離れると一気に下がり、白黒の差がわからなくなる。うーむ、こんなものでも難しいものだ。

　もうひとつのフォトインタラプター(LBR-127HLD)は感度が高く、1センチくらい反射面（紙）を離しても白と黒（マジックで塗りつぶす）の差がはっきり出る。ライントレーサーのセンサーにはこれを使う予定をしているが、これをカメラの始点終点検知に使うには少し大げさすぎる。

　さて、困った。こうなったらギアに反射用の紙をつけて、センサー部を取り付け、実際にギアを回して見て実用になるか判断するのが早そうだ。まずはこの小さい方のフォトインタラプター(TPR-105)を実装してみることにした。

チルトとパンのセンサーが完成。ロジックはこれから（7/20/2013)
　センサー基板の工作を始める。小基板を切り出し、久しぶりのハンダ付けである。まずはチルト部から制作する。モーターの取り付け穴に汎用基板小片を固定し、ここにインタラプターと抵抗2つを載せる。小さいものほど作るのが面白い。簡単に出来た。

　反射型のセンサーなので、反射面を紙で同心円状に作り、ギアの裏側に張ることにする。ここにセンサー部が近接して回るしかけだ。しかし、ギアと軸が正確に垂直に取り付けられていないので、回転させると、センサーの送受光面とギアの間の間隔が一定にならない。それにギア自体が軸上で平行にぶれる。

　まずは、単体で色々な反射面を試しに作ってテストする。センサーに5Vをかけ、オシロで出力電圧を観測する。おお、変化が見える。おやあ、センサーの電位は複雑な変化をする。紙を貼ったところと、マジックで黒にしたところ、紙の黒、何もやっていない素のプラスティック面、それぞればらばらの値で、センサーとの間隔でも大きく変わる。白い紙が一番反射する（Vccに近くなる）ようだが、ぴったりあててしまうと突然0になる。

　どんな反射面にするかは別として、出力がHigh（白のとき）では、その部分の反射率というより、送受光面と反射面との間隔で出力が決まってしまうのが問題だ。一方、反射面がないときや、黒のときの出力は殆ど0で安定している。

　ギアと軸の垂直歪みは、軸にギアを固定するとき調整しておけば減らすことが出来るが、ギア軸が平行に動いて間隔が変化することは、機構上避けられない。そのため安定したHighを作ることが出来ない。受光面と反射面の間隔を一定にする方策を考えなければいけない。

　ギア軸の平行ブレは、ギアの取り付け部と軸の取り付け部との間を狭めれば少なくなるが、余りきつくすると摩擦で回らなくなる。試行錯誤の結果、ワッシャーを1枚でなく、2枚を挟むと、間隔が狭くても軽く回ることがわかった。とりあえずはこれでOKだ。テストに入る。

　心配したが、結果は上々であった。ギアのカメラ支持部をフリーにして回転させると、綺麗なパルス（オシロ画面）が出た。これだけ明解にセンシング出来るなら、マイコンのロジックはChaNさん方式（光照射をパルス状にして、明部と暗部をダイナミックに調整する）を真似るまでもないか。ライントレーサーほどシビアではない。動かないので外光を運転中調整する必要もない。

　チルト部が出来たので、パン部もついでに作ってしまう。パン部はモーター取り付けビスでセンサー部を固定することは出来ない（干渉する）ので、新たに１つ穴を明けて、お遊びでこのあいだ買ったタッピングツールでアクリルにネジを切ってみた。このタッピングツールは、プラスティック歯車の締め付け穴のために買ってあったものである。

　ネジは用心してプラスティックネジを使う。よしよし、うまく固定された。モーター軸を手で回してみる。うーむ、ここも軸がぶれて、インタラプターと受光面の間隔が一定にならない。このままでは出力電圧が振れてまともなセンシングが出来ない。

　モーター軸とカメラ可動部を固定する自家製シャフトマウントのイモネジを緩めて調整する。しかし解消できない。どうも軸ごと歪んでいるような気がする。シャフトマウントの内径は6ミリで、モーター軸の1/4インチ(6.35ミリ）に入るよう、やすりで広げた。

　やすりがけが均等に出来ていないので、イモネジを強く締めれば締めるほど歪んでいくようだ。部品をばらして、この補正をすることにする。下手をすると穴を広げすぎ、収拾がつかなくなりそうなので慎重に少しづつ金やすりで歪んでいる方向を是正する。

　人間の眼というのは結構正確なもので、見た目もはっきり歪みが取れたことがわかる。何とか許容範囲内の歪みに押さえることが出来た。これもぐるぐるまわしてオシロのスイープ波形をとる。よーし、これだけデジタル的に明確な差があればセンサーとしては及第だ。

総合設計が大変だ(7/23/2013)
　センサー部が動いたところで、また進捗が止まった。実は、全体の構成がまだまとまっていないのだ。RaspberreyPi (以下RasPi)を含めたライブカメラの具体的な仕様が決まらない。モーター制御は今のところTiny2313を2つ使うことにしているが、何か無駄のような気もする。

　MegaクラスのAVRなら、1台でPWMチャネルは8つくらいとれそうだし、STM32なら、恐らく楽勝だろう。それにマイクロステッピング制御にする必然性もない。それならTiny861あたりの単体で出来そうな気もする。しかし、どうも調べる気力が湧かない。

　制御の方法も、今のような簡便なスイッチひと押しで一定量だけ動くという制御だけで果たしてうまくカメラを操作できるのか自信がない。RasPiへの接続も問題だ。RaspiとはUARTで良いのか。そのときは、どちらかのTiny2313をマスターとしUART、もうひとつはGPIOでマスターとつなぐことになるが、いっそのことGPIOだけにしてしまった方が、簡便かもしれない。

　RasPiのソフト構成も問題だ。映像データと制御系データとの関係はどうする。Apacheが必要か。motionの制御系が使えるか。ちらっと見た範囲では、motionそのもののパラメーターにこうした制御系のものがあったような。

　迷うことが沢山あって、ぐずぐず先に進まない。暫く、あれこれ考えていたが、不確定要素の多いこういうものにいくら時間をかけても最善策は生まれないということに今さらのように気づき（昔から繰り返している）、何でも良いからとりあえず以下の仕様を決めて先に進むことにした。

(1)チルトとパンのモーターは、別々のTiny2313を使ってマイクロステッピング制御し、2台のスイッチ割り込み入力4本（上下、左右）をRasPiのGPIOで制御する。

(2)始点・終点処理は、センサーがポイントを通過したら、ひとつ前の動作を覚えておいて、同方向の指示を無視する。これにより、RasPi側には始点終点処理を見せない。

(3)スイッチ入力は、立ち上がり（または立下り）エッジのみ有効。

(4)連続入力は、キーボード入力と同じように、一定量受け付ける。これは、信号を送ってから実際に動き出すまで時間差があるためで、そのためのキューをTiny2313に設ける。

(5)電源は、既存の6Vアダプターで、モーターは直接駆動、AVRはレギュレーターを入れて5Vにする。基板は、チルト部は回転雲台に固定し、パン部はベースフレームに置く。

モーター動力部の配線は難しい。ブリッジしていた(7/25/2013)
　暫定的とは言え、とりあえず進むべき方向が決まったので作業にとりかかった。マイクロステッピング制御にこだわっているわけでもない。ただ、既に動いているものを利用するのが一番楽だというだけのことである。これまでのTiny2313のモータードライバーの部分をそっくり2つ作れば良い。

　RasPiからの入力をUARTでなくGPIOにしたのも、GPIOならスイッチで動作確認できるという理由である。手持ちの汎用基板を取り出し、ブレッドボードに作ったモータードライバー一式を基板に移す作業を開始した。

　久しぶりの基板工作である。まずアートワークをやって基板の大きさを決める。こういう何も考えなくて作業できる時間は実に楽しい。時間の経つのを忘れる。

　たいした規模の配線ではないが、TopViewのアートワークをスキャナーで取り込んで反転させ、ハンダ面の図を作る。珍しく周到な準備である。配線部材は、少しこだわって、FETアレイからモーターへの配線は、いつもの0.3ミリのUEW線でなく、太い撚り線を使った。そのせいで半田付けは難儀した。

　こうした動力線に使う適当な太さの耐熱ビニールケーブルを揃えるべきなのだろうが、いつも買ってくるのを忘れる。昔のビニール線が沢山残っているので、これを消化しなければと言う潜在意識があるのかもしれない（究極のケチである）。しかし、こいつらはみな熱に弱い。

　1台目のモーター基板は、半日くらいの作業で全部の接続を終了し、勇んでテストに入る。ところが、これが動かない。UARTが動き、コマンドを送るとモーターが少し動くので、デジタル部はまず間違いはない。しかし、モーターの配線は何度チェックしても間違っていない。顔が段々青ざめてきた。

　これはオシロかロジアナでモーター部の動きを見るしかないかと目検を諦めかけた時、何度目かのテスターによる導通テストで、全く関係のない部分で導通が見つかった。FETのゲート部がVccと導通している！これだ。

　太い接続ケーブルをピンセットで上げてみると、その陰から、パッドのハンダが隣のランドまで流れてブリッジしているところが見つかった！いやあ、線が太いために、その裏でハンダが流れていたのが見えなかったのである。ハンダ吸い取り線でブリッジをはずし、モーター基板は完動した.

　撚り線のハンダ付けは難しい。特に短い部分は熱で被覆が傷むので手早くすませないとみっともない形になってしまう。今度の失敗も見栄えばかりに気を取られ、ハンダがうまく盛り上がったことに満足して、ちゃんとしたチェックを怠ったことにある。今度こそまともな耐熱ケーブルを買ってこよう。

炎暑の中テニスをする(7/27/2013)
　ところで、電子工作とは関係のない話題をちょっとご紹介。今年の夏は、梅雨明けから猛烈な暑さが続き、辟易していたのだが、少し過ごしやすくなったこともあって、今日は2時間、久しぶりのテニスを楽しんできた。

　今日のメンバーは何故か所長と同じ70近い高齢者が多い。しかし、誰も熱中症にかかることなく、かんかん照りのコートの上を元気に走り回った。ちょっと心配だったのだが、テニスが終わったあと、自転車で9キロ近い道のりを何事もなく帰ることが出来た。家に着いて冷えたビールを一気飲み。至福の時間である（ただし、そのあとは使い物にならない）。

　そう、所長は昔から、根暗なプログラマーという職業の割にはアウトドア志向である。カナダの人里離れた湖沼地帯でプログラムを書き、パラボラアンテナで通信衛星に送っていたアップルの天才プログラマー、ビルアトキンソンに憧れていた。

　それはそうと、昨日は、家内とこれまた久しぶりの映画鑑賞を楽しんだ。見た映画は、ご想像どおり前評判の高い「風立ちぬ」である。宮崎駿のアニメはたいてい封切りで見ているが、まあ、今度の作品は宣伝の割には今ひとつ中途半端な作品のように感じた。

　宮崎監督が試写のとき初めて泣いたというけれど、こうあれかしと自分であこがれていた創作自叙伝に泣いたのではないか。あくまでも美しいばかりで、大事なところはみな夢のシーンだ。ゼロ戦が開発された現実の日本の歴史に向き合おうという迫力が感じられない（関東大震災の場面は迫力があった）。

　これまで「もののけ」とか、「千と千尋」、「ハウルの城」などの作品の中に流れる、彼の隠れた強いメッセージ（重低音のような）が不足しているように感じる。宮崎作品の魅力は、ファンタジーという形をとりながらも、「この世の不条理性」を観る人に訴えていたと思うのだが。

モーターの始点・終点処理で良いアイデアのつもりが(7/29/2013)
　電子工作の話に戻ろう。ハードは出来たが、ソフトの部分は、この前の自動巻き機のソースから、不要なコードを削っただけのやっつけで、良い加減なソフトのままである。いくらなんでもこのままではまずい。基本的なプログラムの構造から検討する擬似コーディングをメモに書いてやり直した。

　まず、UARTでの進行指示と、スイッチ割り込み（タクトスイッチ）を共通化し、連続した指示を失わないためのキューリストを新設してリングバッファーにする。実際のモーターの動作指示は、このリングバッファーのポインターが違うときのみ動くようイベントドリブン化する。

　次は、始点・終点処理である。白い部分（光沢紙をリング状に切り抜いて貼り付ける)が運転範囲で、黒（マジックで黒く塗る）が運転停止期間である。光センサーの入力ピンは割り込みを使わず、モーターの動作リクエストが来ると、そのときレベルを調べて動作範囲にあるかをチェックする。

　動作範囲をはずれており、次のリクエストが同一方向だったら、そのリクエストを無視し、逆方向だったら、その動作を行って、そこから脱出するという、まず至極単純なロジックを考えた。

　しかし、もし、逆方向に戻っても動作範囲に帰って来れなかったら、このロジックでは、ここで全く動きがとれなくなる。それに、同一方向リクエストか、逆なのかは、前の動きを記憶しておくロジックが必要でプログラムが複雑になる。どうしたものかと思案していて、ふと気がついだ。

　リクエストが来る前、つまり、動作したあとに動作範囲をチェックすれば、前の動作を覚えておかなくても始点・終点処理が出来るのではないか。動作し終わって範囲を越えていたら戻る動作を加えるだけで良い。動いた分だけ戻るので、はずれることもない。おお、これは良いアイデアだ。

もっと良い方法があった。こいつは素晴らしい(7/31/2013)
　意気揚々とプログラムを書き上げ、テストに入った。確かに動いた。限界点まで来ると、モーターはちゃんと逆回転して範囲内にもどってくる。しかし動きが騒がしい。ステッピングモーターの短時間の逆動作は、モーターに無用な振動を与えて動きがぎくしゃくする。下手をすると前進と後進を繰り返す異常動作に入ってしまう。

　ソースコード上で思いつきの策（元へ戻る時は倍の長さ動く）を入れてやってみても、モーターはさらに不自然に無駄な動きが大きくなるだけで、どうみてもエレガントではない。

　結局、紙に戻って擬似コーディングで検討をやり直し、最初放棄した「限界を越えた時は、それ以上の進行を止め、逆進だけを許可する」というロジックに戻った。このロジックは、逆進してもセンサーの範囲内に戻ってくる保証がないので、そのためには追加のロジックを加える必要があり複雑になるので止めた案である。

　新たに加えた追加ロジックは、「センサーが範囲外にあるときは、前回の動作方向を記憶しない」で、これだけですべて解決したのである。これにより、どんなに逸脱しても、最初この範囲を超えた方向を頼りに、元へ戻ってこれる。

　実際にテストしてみる。実にうまくストップする。暴れることもない。何度やっても素直に戻ってくる。コードからいえば返って最初より少なくなったくらいだ。こういうのが一番気分の良い解決である。

　ささやかな成功だが、無性に嬉しい。久しぶりの茂木健一郎の言う「AHA」体験である。それにしても擬似コーディングというか、徹底的なロジックの検証が結局一番の近道であることを悟る。

　余り嬉しいので、まだ、はんかけだけれど回路図とソースリストを公開してしまうことにする。チルト部の基板で、タクトスイッチと、UARTのコマンドで、モーターを少しづつ動かし（デフォルトは4ステップ。コマンドで変更可能）、カメラを上下に動かすだけの機能である。上記の始点終点処理のコードは、リストの最後部にある。

ここに例によってAVRStudioのフォルダーを固めたソースファイル一式を置きます。回路図ファイルも入っています。

「CAM2313.zip」をダウンロード