開発日誌(39)
トップへ戻る
開発日誌インデックスへ
前のページへ
次のページへ
■１０月２日■
月が変わったので改ページ。
ラムダの頭部は、根元のパン軸があまりにぐらぐらなのでサーボ変更＋構造変更で再設計製作中。 ROS-3101は軸がものすごく弱そうです。使い方は要注意です。
頭部部品が届くまでにZMPスライドをやってました。
人間の歩行は下の図のように踵から着地して、つま先で抜けるようになっています。
そして重心位置は、その動作に合わせて踵からつま先に移動、接地状態の半分はつま先付近に重心があるということです。
こうすることで進行方向に対しての重心の移動速度が一定に近くなります。
具体的には、今までの目標ZMPが歩幅80mmの時にこうなっていたとすると
こんな風にします。
足裏の後ろの方から前にスライドし、歩幅80mmなのに100mmの付近にZMPをおいて次の歩に進みます。
で、そのスライドの効果がこれくらい↓ あるかないかわからんけど確かに直線に近くはなってそう。
そして、実機に組み込んで動かせるようになったのだが、意外と、というか予想通りというかあんまり効果はなさげ。
歩幅を100mm以上にすると重心の移動速度の変化が顕著になるので効果ありそうでした。特に歩調を遅くした場合はですね。
で、逆に歩調を早くして、、とか色々実験してたところで、足と足が絡んじゃってまた股関節ヨー軸のサーボケースが破損。 今回上半身も組み立て済みだから交換が大変で大変で。 もっとメンテしやすいように、あとヨー軸のスラスト強くなるように構造変更することを誓いました。 とりあえずは単なる修理ですけどね。
分解ついでに電源スイッチ近くに、電源を入れたままバッテリー交換するための外部電源コネクタを追加しました。
更に、今度は足裏のスリップ具合を変化させてどうなるかとかやってたところ、派手に転んでしまったんだけど、その時運悪く背中の基板露出部分が椅子の足に激突したらしく、激しくサーボが暴れたと思ったら、、二度と動かなくなりました。(ーー;)
サーボもCPUボードも無事で、レベル変換部だけがとんじゃったみたい。
レベル変換ICがとぶのには振り回されたのでモジュール化して交換しやすくしたのですが、まだ交換モジュールを作ってなかった。 急いで交換モジュールを作ってみて動作させたところ正常に復帰。 よかったー。 壊れた方のモジュールもICを貼りなおして修理しました。 モジュール化の成果があってよかった。 つーか、基板露出させたままで動かすなって話ですが。
なんか破損と修理に明け暮れた週末でした。(-_-;)
■１０月４日■
ZMPスライド続報。 動かしてみると何か少しひっかかりを感じるので調べてみると、
赤丸の部分に段差が出来ている。 ZMPスライドをしてない時はもっとスムーズに接続できたのに。
この接続部分は初速ベクトルの設定を設定することで計算するのだけど、ZMPがスライドすることで初速ベクトルへの収束がうまくいかないらしい。
そこで、最低歩行歩数を1歩から2歩に広げてみると
きれいにつながった。 2歩先まで確定しないと計算が収束しないということらしい。 速やかに止まれないってことだ。
これはオフラインパターン生成での計算方法を使っているのだけど、オンラインパターン生成でも一緒なのだろうか。
なにより、ZMPスライドを実装しようとすると、後退、カーブの関数、あとその場旋回はスライドする必要ないからスライドなしとスライドありでの接続をきれいにやるとか色々検討しなきゃならない。 重いな。(-_-;)
■１０月８日■
今日はロボワン。 だけど、それはちょっと置いておいて、ラムダの歩行モーションについて
どうしても股関節ロールのたわみが収まらず、結果として胴体が倒れこんで接地タイミングが合わない。関節のトルクを上げても速度を考えるとちょっと現実的じゃないなと思えてきたので補正を入れることにしました。
補正は、以前に計算していた関節負荷から算出。
まずは補正なしの足踏みの様子
遊脚が浮く瞬間に支持脚にかかる負荷が増大し、関節が負けちゃっているのがわかります。 その結果、胴体が倒れこみ、接地タイミングが合わなくなるので接地時に足が地面と衝突して跳ねてしまっています。
次に関節負荷を元に補正値を算出して補正をかけてみます。ただし、負荷値から補正値への変換パラメータは調整で決定しています。
補正値の入る瞬間となくなる瞬間がスムーズではないけれど、胴体の倒れこみがなくなったので、接地時のタイミングも予定通り。跳ねたり泳いだりしなくなりました。
これならフルグリップ歩行も夢ではありません。
ロボワン予選を観て来ました。 ライト競技はさておき、予選の徒競走。 フロスティーもオムニもGIYさんも完走できないという波乱でした。 みんな左側に転落するという状態で、おそらくは路面の水平は出ていなかったように思うのですが、安定した歩行でトップのタイムで完走したホリポンさんはすごいです。
スピード競技にも格闘にも興味はないのだけど、今日の競技は昔のOPEN-Rでのアイボプログラムコンテストを思い出しました。 まっすぐ進んで壁にタッチして戻ってくるというだけの競技だったのだけど、反転して進むというのをプラカードを使って指示するのがほとんどだった時に、自分ひとりだけ自律で歩行して自分で判断してターンをして戻ってくるように作りました。
競技の順位自体は全然ダメだったのだけど、自分ひとりだけ自律で動かせたのが誇らしかったのを覚えています。 今日の競技もラムダが出走するなら自律でまっすぐに歩くようにして出場するだろうなと。 まぁまだ自律で歩けないから言ってるだけですが。
明日は決勝トーナメント。 ややこしいことを抜きにして楽しんできたいと思います。
■１０月１１日■
知らないうちにロボワン決勝トーナメントから日が経ってしまった。 夫婦合体ガルムキッドのくままさんそして名メカニックくぱぱさんおめでとうございます。
今後は自動操縦、、みたいな話になってましたけど、相手の引き手に合わせて攻撃を繰り出すようなレベルになっている格闘戦に投入できるセンサーシステムってどんなんやねん！ということで少し考えてみたけどさっぱりできそうな気配がないですよ。 姫路ロボ・チャレンジからスタートしましょう(^_^;)
とうとうラムダの画像関連を進めるのだけど、とりあえずアタマを動かしてみることに。 まだ画像認識とか入っていないのでコントローラのジョイスティックで動かしています。 歩行、これじゃまだ自律で動かせないなぁもっと安定しないと。。。アタマ付いたからってわけじゃないよなぁ （質点データに頭部は入ってない）
■１０月１２日■
昨日の動画撮影の際、歩行がいまいちだなぁと思っていたら、撮影後にネジが緩んでいるのを発見。 みっともないので撮り直しました。
そういや、胴体が傾くことに対応するために足上げの関数に細工をしていたのを思い出したのでそのパラメータも外したり。
それにしても安定域が狭くてピーキーちょっとでも触れると安定域を逸脱してこけそうになります。 ロボワン機でもこれくらいの足裏の機体はあると思うんだけどな。 とりあえず画像処理を進めながらも歩行安定化については進めて行く必要があります。 全然達成感がないんで。
それにしても、顔が動くと生命感が出ます。 今回は顔認識して人と目線合わせるようにしたいなぁ。
■１０月１５日■
色々有って、旋回歩行と後退が安定しなくなりました。 (ーー;)
股関節ロール軸に関しては計算した補正を入れることでなかなか良い動きとなったのですが、歩行全体では左右どちらかの足だけひきずるような感じがあって満足できないでおりました。 これはトリムが十分取れていないせいだということで一生懸命トリムを取ったりしていたのだがどうも旋回や後退で不安定。
その調整の中で、ZMPを足首関節直下よりも少し内側にしてマージンを取りたいなと思ったのがきっかけ。 ZMPをシフトしてみると、もうなんだかものすごく不安定になる。 あれ？昔、シフトできるようにした時はそれなりに動いたのになと思って気がついた。
ZMPを足首直下からずらした場合に関節負荷を計算すると、足首関節にかかる負荷は股関節のそれを大きく上回るくらいの負荷になります。 今は、各関節ともに平等に負荷計算をして決まった比率で補正値を算出しています。
つまり、足首関節には股関節ロールより大きな補正値が加わることになり、歩行が不安定になったと。
そっかー、すると関節毎に補正を入れるか入れないかのスイッチが必要だなと思って、プログラム上のデータ構造に負荷補正のスイッチ変数を追加しました。 その他にも色々とデータを追加したりして、 そして、トリムデータやらなんやら、いままで調整したフラッシュ保存しているデータを新しいデータに移行するときに間違えて消してしまいました。(>_<)
で、一生懸命データを復元したのだけど、補正パラメータだけは最新値がわからない。 多分、初期に決めたデフォルト値より結構変えていたらしいんですね。 どうも補正値が大きめになってます。
そこで問題が発覚。
どうしても旋回歩行でこけてしまう。 何が起こっているのかわからんので例によって高速度撮影してみると、
直進の場合は計算とほぼ一致する着地タイミングが、旋回歩行やカーブ歩行の場合はずれるらしくて、（あ、モーメント計算してないせいかな？、いや後退の場合もだめだから違うか。。）着地する前に補正が入ってしまって着地足がぶれてしまっています。
つまり、補正を入れた場合には外乱にものすごく弱くなってるわけです。
このことをフェイスブックで書き込んだところいろんな意見やアドバイスをもらいました。 それを整理して自分の考えも入れてまとめてみると
PID制御サーボは偏差に対して働くため、急激な負荷の変化に対して擾乱が生じる。アクチュエータのトルクが十分であれば擾乱はやがて終息するが、擾乱期間はサーボシステムの周波数特性によって決まる。
両足支持から片足支持に遷移する際の急激な関節負荷変動で位置制御のジッタが増大するのが問題。
・関節負荷に応じた補正値を計算し、目標角度に加えて支持を与える。
これにより一定の効果が得られるが、タイミングの微細なズレで補正値と負荷のタイミングがずれると破綻する。
・関節の減速比を大きくし、負荷増加での関節のぶれを抑える。また保持トルクを大きくする。
・サーボのパンチを大きくする。パンチは位置制御時の起動電流値。大きくすると微小な位置制御に対してはハンチングを起こす可能性がある。
・股関節の間隔を小さくする。 そもそも股関節負荷が大きいのは胴体の重心と股関節の位置にオフセットがあるため。
これを小さくすることで関節負荷は小さくなる。 ただし、股関節ロールのサーボが飛び出しているので股関節ヨーの可動範囲が狭まる。
・重心移動の際、上体を平行移動するのではなく、回転させ、重心を股関節軸に乗せる。股関節間隔を小さくしたことと等価の効果があるが、
回転移動のため、頭部の移動量は大きくなる。カメラの移動量が増し、回転も加わるため画像処理には負荷が大きくなる。
以上が、関節負荷に対する直接的な対策案
関節負荷に応じた補正値を与える場合に限らず、計算歩行は外乱に弱い。（モーション歩行も一緒だけど）
□ ＣＰＧの導入
歩行タイミングをセンサーから取得し、タイミング同期を行う。
→ 純粋な計算歩行との融合が難しい。
→ タイミングシフト幅を事前に決めておき、いくつかのモーションを生成しておく？
→ オンラインモーション生成を行う。 こっちが本命だなー。
□ ジャイロとの同期
外乱を受けると機体が回転運動を行うため、ジャイロにて検出が可能。 ジャイロに同期して接地タイミングをダイナミックに移動させる。
□ 機械的対応
関節にダンピング特性を持たせて状態変化に対して受動的に動作する。 当面、計算歩行とは相容れない。
つまり、
① やっぱり補正を入れないで股関節ロールがよれないようにする方法を考える
② やっぱり外乱に対応するしくみ
ってことですね。 とりあえず、6003HVの底力に期待してパラメータ調整をしてみます。
■１０月１６日■
さっそく、サーボのパラメータのうち、パンチを大きくして反応が変わるかどうかを確認してみましたが、結果はダメ。
パンチを大きくすると、サーボの動作が少し跳ね気味になるのだけど、負荷変動に対する応答が大きく改善するってことはありませんでした。
外乱への対応を考慮してCPGの導入を検討します。
以前の実験ではCPGに正弦波を入力するとその入力信号の周波数（位相）に引き込まれるという引き込み現象が確認できました。 今回、着地タイミングにより外部入力信号を作り、それをCPGに入力してロボットの動作と歩行モーションの同期をとるということをやってみたいと思ってます。
で、着地タイミングをZMPセンサーから作るのだけど正弦波じゃなくてデジタルの矩形波になるのだけど、CPGは大丈夫かな？
大丈夫でした。 ただし、プラス方向とマイナス方向に振らせないと出力波形がえらく歪みます。
次にZMPセンサーから矩形波を作ってみると
途中にちょっと足が浮いた瞬間があるのかな？ デューティーの短い方が足が浮いている期間。 左右の着地タイミングを入力すればいいのかな？このまま入力してもいいかもしれないが、途中のちょっと浮きが気になる。こいつを消すにはハイパスフィルターを通さねばならないが、処理時間の遅れがやだな。積分値にしようかな。 デューティーがちがうからオフセット出るか。。良い手を考えねば。
■１０月１７日■
考えると矩形波にする必要はないなぁと思ってできるだけ採取したデータをそのまま使う方向で検討してみる。
まず、足裏センサーデータをああしたりこうしたりしてこんなふうな波形に加工します。 この加工は実時間で実行可能。
それをCPGの外部入力に入れると、
見事に引き込んで同期します。
大脳の方も緩やかに進行中。 ラムダに搭載するビーグルボード。 アルミでカバーを作りました。 端面には強度アップのために曲げが入っていますが、側面は隙間あきあきです。必要ならプラ板で隠そうと思います。
ロボット本体で隠れる裏面は軽量化のため びんぼっちゃま 状態。 ラムダ本体に実装するSEMB1200A側も、ビーグルボードで隠れる面はむき出しになってます。
せっかく肉抜きしたのに拡張コネクタは隠れちゃってるという片手落ち(^_^;)
そして画像処理プログラムにも着手せねばならないのだけど、モニターとかエディターとか準備がいっぱい有ってなかなかやる気にならない。 今年中に形にしたいのだけどな。
■１０月３０日■
気がつくと10月も終わり。 今月もあんまり日誌を更新できなかったな。
先週後半は飲み会続きでへとへとになってしまいました。 予定の画像のプログラムも思うように進まずなので練習会はお休み。 飲み会も欠席だなーと思っていたらなんとくままさんの誕生日会をやると。 む、それとわかってれば無理しても行ったのにな。 それも石川さんの情報によるとかわいい店員が揃ったお店とか。。 色々残念でした。(-_-;)
練習会を休んで、体を休めつつプログラムもそこそこ頑張ったおかげでmjpg-streamerプログラムを改造して、同一スレッドで2カメラのグラブ（画像取得）ができて、それをブラウザーでモニターできるようになりました。
本来、横向きに使うカメラを縦に実装しているのでブラウザーで見ると横向きになります。 回転処理してもいいけど勿体ないのでしてません。 まーデバッグ時は回転処理してもいいかもね。見難いから。
カメラの正面に緑っぽい色の玉を持ってますが、左右の視差でこれだけずれます。これから物体の距離を測定します。
あと、左側はカラー画像から彩度を削除する処理をしているのでモノクロです。本来は右側と同じカラーです。
カメラの様子。LEDが点灯しているのが撮影の証となりますが、プログラムがフリーズしてもLEDはつきっぱなしだから証じゃないな。
では、お手軽なCDTで色重心処理を行って、色重心の視差で色重心の深度を見るというのをやってみようかと思います。
■１１月１日■
ボストンダイナミクスのPETMANはすっごいですね。 ワイヤーなしでもあれだけ安定して動くのかな？
とりあえず、カラーディテクトを組み込んでみた。 片側で抽出した検出画素をもう片側の画像に書き込んでみました。これだけ視差があるわけです。
カメラに近づくほど視差は大きくなり、遠くなるほど小さくなりますが、結構遠くにターゲットを置いても視差はなくならないですね。後ろの本棚のピンクの背表紙にも反応してますけど、高さ方向の視差があるのはカメラが傾いていたからだと思います。
■１１月６日■
１１月３日は祝日だったのだけど、うちの会社は夏季休暇への振り替えで出勤でした。 でも、草加ふささら祭りと同時開催の草加商工会祭り内で行われる「できんのか！」の手伝いをするために休暇を取って行ってきました。
イベント自体は大成功で、いままでにないお客さんの食いつきでした。 ところが、盛り上がり過ぎたせいもあるのか無いのか、キノピーが（おそらくは）盗難に会ってしまいました。 気付いてほど無い時間にあちこちを見回ってみましたが、それらしい荷物を持っている人や投棄物は見つからなくて、後は警察のお世話になることに。 多分価値がわからない人に持ち去られたのだろうけど、 実は自分自身「自作のホビーロボットなんて持っていく人は居ない。」とタカを括ってたところがあったので大いに改めないといけないなと思った次第です。
画像処理です。
同じスレッドで二つのカメラのグラブを行うようにしたところ、二つのカメラでのグラブタイミングに予想以上の時間差が発生することがわかりました。 カメラ自体は30fpsくらいが可能なものなので連続してグラブ処理をすればほとんど気にならない程度のずれで済むだろうと思っていたのですが、キャプチャー時間を比較すると0.15秒程度の差がある。 これだとステレオ処理をしながらトラッキングは難しい。ロボットが静止していることを確認しながらの画像処理はありえないのでまずいなと。
下の画像はピンクのボールを上下に動かしているところをキャプチャーしたものです。 左が青いボールになってるのはカラーディテクト処理のためです。
試しに、カメラ単位にスレッドを起こす、オリジナルタイプで確認するとほとんどずれが無い。時間で0.0x秒単位のずれです。これなら許容できるはず。 （というかこれ以上の同期を求めるならハードでの同期処理が必要）
スレッド間のデータの受け渡しはJPEGデータで行うようになっていたので、グラブしたスレッドでJPEG圧縮するようになっていたのだけど受け取り側で圧縮処理するようにします。
下のがそれ。 受け渡しのデータ構造体にレゾリューションデータがなかったりしたので力技で実装してます。
どちらもボールを上下に振っている状態なのでブラーがありますが、左右で遅れの度合いが違うのはよくわかります。
次回の練習会は１１月２３日らしいけど、この祭日も出勤日なんだよね。 武蔵小杉で開催らしいので仕事終わりに立ち寄ります。 仕事場が武蔵小杉なので(^_^;)
■１１月２７日■
実に三週間ぶりの更新。 開発日誌なのに「日誌」じゃないな。
途中、国際ロボット展を観に行って、めざましテレビの取材にを受けているくままさんの後ろの方に居たら写りこんでしまってたり、 風邪引いて仕事を休んだ上に予定していたゴルフもいけなくなってメンバーもろともキャンセルさせてしまったりしてました。
二つのカメラでのキャプチャーを大きな遅れなく取得できることはわかったのだけど、二つのカメラからの画像データをステレオ処理する記述をどのような仕組みにするかを検討しておりました。
というのも、二つのカメラを動かすプログラムを二つのスレッドで動かしていて、でも、同期は取れていないものだからいいタイミングで二つの画像データにアクセスする必要があります。でも、「マルチスレッド」プログラミングというのは経験も知識もないのでそっちの勉強からはじめなきゃならないという状態です。
なんとなくプログラムソースを読んで改造してみたのだけど、予想以上に処理が重くなってしまい気持ち的にも萎え萎えだったのですが、思い直してスレッドの仕組みから勉強することにしました。 調べてみるとマルチスレッド処理は今後のロボットプログラムを考えても避けて通れない概念（仕組み？）なのでいいトレーニングになりそうです。
元々はカメラから画像を取得すると、画像がアップデートされたことを通知し、出力用のスレッドがそれを受けて起動（通知を受けるまでは休止している）します。 出力すべき画像が複数ある場合は待機している出力用スレッドも複数あるのだが、それぞれ自分の担当するカメラの画像がアップデートされたことで起動するようになっていました。
つまり、カメラ毎には非同期で動作する作りになっているので、ステレオ処理のように2つの画像を使う場合には二つの画像がアップデートされたところで通知を発行する必要があります。
ステレオ処理が終わったら、必要に応じて画像を加工して出力用スレッドに通知すればよいと。 この時の通知は出力用スレッドに対して一斉通知（broadcast）するようにすればよいか。
ってことで、これからやっとその記述を作って見ます。
他にもいろいろと作業アイテムや注目アイテムがあるのだけど、日誌に書くほどのモノになっていない。 そういう感じだから日誌もかけてないのかな。
■１１月３０日■
やっとスレッドをつかったプログラムが思った通りに動くようになりました。 ま、大したことはしてません。キソです、基礎。
二つのカメラから画像を取得して、両カメラのキャプチャーが完了したところで画像処理スレッドが起動。 二つの画像データにアクセスして画像処理を完了したところで画像送信のスレッドが起動。jpgに圧縮して画像を送信します。 これを延々と繰り返す。
こないだまではスレッドの処理を見様見真似でテキトーにやっていたので画像処理スレッドと画像送信スレッドが優先権を取り合ってたので画像処理が歯抜け状態、または動画がカクカクしてました。 ちゃんと同期処理ができたので安定した速度で画像処理も画像送信も行えるようになりました。よかったよかった。
ちなみに画像を送信するのはモニター用なのでロボットが動き出したら送信スレッドは立ち上げないようにもできます。
上の画像は、両カメラのカラーディテクト処理をした結果、規定の色を持ったピクセルの色を変更しています。ただし、検出した画面とは違う方の画像データに反映しているということです。単画像で行える処理はキャプチャースレッドで実行することもできるのですが、ステレオ処理を前提に構成したかったので画像処理スレッドを分離しました。 今後は画像処理スレッドだけを修正していけばよいことになります。
ここまでステレオカメラにこだわってたのだけど、それは物体認識から物体へのアクセスをする時の奥行き情報が欲しいから。 画像処理でやらなきゃいかんと思っているのは「空間認識」。 ステレオカメラを使う手もあるのだけど、アフォーダンス理論をほのかに応用した直線検出からの空間認識ってのをやりたいと思ってます。物体認識からの物体アクセスには腕の制御というまた難物が残っているのでまだまだ先は長いのです。
■１２月７日■
風邪が治ったと思ったら、なんかのウィルスにやられたとかで胃痛に続いて下痢に。。 やっと久しぶりの空腹感を味わえた。 腹が減るって幸せ～。
ちんたらやってますが、色重心を表示。
■１２月９日■
だいたいできた。 画像サイズはこれが限界で、奥行き分解能が洒落にならん。 色重心じゃダメかなー。 パターン照合による奥行き検出もやってみるかな。 ラベリングがないと意味がないんだけどなぁ。
明日は毛色を変えて、エッジ検出からの壁検出や床検出を試してみる。
■１２月１２日■
こうすりゃいいんじゃないかなーってのを思いついたので実験してみる。 画面を空間周波数で分析してみる。
左の画像を空間周波数分析してます。右の画像は生のまま。 視差があるけど、ほぼ分析前の画像と思ってよいでしょう。
なるほど。。。 使えそうな気もするが、高速化が絶対条件だなー。 高速アルゴリズムを調べてみよう。
■１２月１３日■
高速化した関数を拾ってきて、更に２次じゃなくて１次を使う。 ２次じゃ目的に合わない。
画面下に行くほど周波数が高いということ。 この解析結果を使って壁とか床とか、できればモノを認識させる。 ま、モノはこれだけじゃ無理だけど。
１次だし、畳み込みを使ったりでめちゃ早い。さらにテーブルを使えばもっと早くなる。これなら使えそうだ。
テクスチャーが見えるかな、と思ったけど、この解像度では無理みたい。 エッジ処理すると高周波成分が立ちすぎてなんもかんも一緒になってしまう。 すこしぼかした方がいいくらいかも。
■１２月１８日■
昨日は練習会＆忘年会。 寄り道していたら練習会場のロボスポに着いたのは５時でした。 ラムダの頭部だけ持っていったんだけど、それも通電せず仕舞い。 まぁ予想の範囲。
練習会で田中さんが、ロボットに積むカメラを２台にしたいと。 だんだん敷居が上がっていくなー。(^_^;)
以前の調査では、ロジテックのC5XXを2台つなぐと二つ目のデバイスはオープンできなかったので、それより下の機種、確認したものでいうとC270ならば3台はつないだ実績があります。 また、C525とC270という組み合わせならば2台接続が可能でした。
ただし、C270をBeagleBoarde上で使った場合、MJPEGで接続することができなくて、やむなくmjpg-streamerを使う必要がありました。 これだとYUV形式で受け取った画像データをMJPEGに変換してから送ることができます。（PC＋VMplayer＋ubuntuならMJPEGで動く）
更にmjpg-streamerならプラグイン指定で複数の入力を指定することができます。
ということで、C270とC525でツインカメラにしてみました。 目的はタンデム操縦、もしくはバックモニター。 バックモニターならば１画面に２つの画像が必要だけど、タンデム操縦の場合は二人の操作者のPCそれぞれに画面が表示できたほうが良かろうということです。
mjpg-streamerで出力にoutput_httpを指定した場合、出力形式をhtml形式で指定することができるのでどちらの形態にも対応できます。
↓ バックモニターじゃなくてサイドモニターになってますが、、、
それぞれのカメラ画像を別のブラウザーに表示。 ラムダでやってるみたいに同じブラウザー画面に出すこともできます。
実は、Beagleboardのubuntuがまたもや飛んでしまったので再インストールをしたのだけど、バージョンが11.04に上がってます。（11.10もあるけどうまくいかなかった）
バージョンが上がった影響なのかもしれないけど最初はうまくカメラ（C270）が動きませんでした。
モジュールを外したりロードしたりしてたら動くようになったけど１からの手順を明確にしなきゃならないです。 動いている状態のlsmod
Module Size Used by
uvcvideo 58379 0
v4l2_mem2mem 8744 0
videobuf2_core 17264 1 v4l2_mem2mem
v4l2_int_device 3120 0
v4l2_common 9015 0
videodev 85717 2 uvcvideo,v4l2_common
smsc95xx 10966 0
snd_usb_audio 90248 0
snd_hwdep 5587 1 snd_usb_audio
snd_usbmidi_lib 17193 1 snd_usb_audio
rtc_ds1307 6386 0
rtc_twl 4402 0
gpio_keys 6841 0
C270の画面が小さいですが、これをVGAサイズにすると遅くて使い物になりません。
ところで、今までの手順では動かなくなったということはドライバーも変わったってことだろうからもしかして、、、と思ってC270をMJPEGで動かしてみると動きました！
これだとどちらのカメラもVGAにすることができますが、ちょっと不安定。 試したときはC525の画像にノイズが乗るようになりました。
一応、マルチカメラの場合のmjpg-streamerの起動コマンドを載せときます。スペースの有り無しがわかるようにアンダーラインを入れておきます。
./mjpg_streamer -i "./input_uvc.so -n -y -d /dev/video0 -r 320x240
-f 15" -i "./input_uvc.so -n -d /dev/video1 -r VGA -f 15"
-o "./output_http.so -p 8080 -w www"
1行で書いてください。
■１２月２５日■
アイボがお亡くなりになりました。
年末の片付けのついでに久しぶりにバッテリーを充電して動作確認をしたところ、一番新しいアイボERS-7が立ち上がらなくなってしまいました。もしかしたらバッテリーがへたれていて起動できないのかもしれないですが、どうしたものか。
一方、ERS-210は起動するんだけど関節がビクビクビクビクしてまともに動けない。 関節のポテンショメータがダメになっちゃってるようです。
ちなみに中古ユニットを買い集めて組み立てたERS-210が他に2台あって、ダンボールに納めて物置にしまっていたんだけど、そちらの2台は関節ビクビクにはなっていませんでした。部屋のホコリがだめなんだなー。
あと、当たり前だけどバッテリーが経たれていて、ERS-210も起動したらすぐに落ちてしまいます。 でもスーパーコアだとちゃんと起動して動き出す。 コアの消費電流が小さいのか、シャットダウン電圧が違うのか。 まぁ210はバッテリーをなんとかしたら使えるかな。（使うことないだろうけど） 関節ビクビクの1台はもうだめだなー(>_<)
２１０はいいとして７は諦めきれないのでバッテリーをなんとかして動作確認をしてみるしかないか。 バッテリーじゃなきゃもうどうしようもないからゴミだなぁ～。
マルチカメラ
WLANの設定をして自動起動をするようにしようとしたところ、問題発生。
どうやらC525＋C270＋WLANだとC525が動かなくなる。 データ量からするとUSBホストの容量を超えていないと思うのだけど、どうもしんどいらしい。 Linuxの作りが影響しているらしいが、そこまではちょっとわからない。
ちなみにC270×２＋WLANの組み合わせでもしんどいらしくてカメラの1つが落ちてしまいます。 ううむ、もしかするとUbuntuのバージョンのせいかも。以前のバージョンだと3個まで動いてたはず。
問題が同一のUSBホストを使っているからだとすると、WLANとカメラのUSBホストを分ければよいはず。 BeagleBoard-xMにはUSBホストの他にUSB OTGポートってのがあります。OTGってのはホストになったりクライアントになったりするPDAなんかのためのUSB規格らしいのだけど、これをホストモードで使えばWLANをつなげられるかも。 カーネルがサポートしていれば、だけど。 ただ、OTGポートは電源供給可能容量がすごく小さいので、デバイス（クライアント）に電源供給してあげないといけない（らしい）。
ということで、OTGポート用のUSBミニAオスケーブルをアマゾンで発注。ちゃんとホストモードになってくれればいいんだけどな。
ちなみにその問題は別として、C270を使った場合でも自動起動できるようになりました。 rc.localのアタマに sleep 10 って入れただけですけど
BeagleBoardのバックアップ
ビーグルボードはシステムがマイクロSDに入っているのだけど、ちゃんとシステムをシャットダウンしないで電源を切ったりするとタイミングによってはファイルシステムを壊してしまいます。
ということでシステムの入ったマイクロSDカードをまるまんまバックアップしておけばいざという時便利だろうということで、バックアップしてみました。
ネットを検索してココとココの情報からバックアップできるようになりました。ふぅ、よかった。 ４GBのマイクロSDが400円くらいだからいくつでもバックアップできるなー(^_^;)
一応手順を載せておきます。 参考URLと合わせて参考にしてください。 特にFDISKのシリンダ数はSDカードの容量で変わりますので注意。
仕事から帰るとUSBOTG用のminiAケーブルが届いていたので早速実験です。 しかし、アマゾンで500円くらいで買った20センチ長のUSBケーブルをでかいダンボールで送ってくるのはいかがなものなのか。
結果は成功。 WLANを使って、メインカメラからVGAで、サブカメラからCVGA（だっけ？）が送られてきます。
接続はこんな感じ↓ わかるかな？
BeagleBoard-ｘMの電源コネクタの横にあるminiABコネクタからminiAケーブルを使って引き出し、外部電源供給ができるHUBにつなぎます。 直接アダプタをつないでも電源供給ができません。（やってみてないけど） そして、HUBにはWLANアダプタを接続。
カメラ側はこんな感じでバックビューカメラとして仮固定
そういや、USBホストが2本できたわけだからC270よりもいいカメラが2本つなげるんじゃないかと思って色々試しましたが全滅でした。
OSはUbuntu 11.04 なのですが、例の超美麗オートフォーカスWebカメラのC910も、C525の前身のC510もID登録なしで名前がでてきませんでした。 古いのは排除されていってるんですかね。
ちなみにラムダのアイカメラの、C270×２の構成だと、つながるはつながるんだけど画像がとぎれとぎれ、どうしてかなー。 C270をMPEGで動かすのも不安定です。
つまり、いまのところツインカメラにするにはC525（C510でも可）とC270、そしてWLANアダプタはUSBOTGポートに（HUB経由で）つなげるという構成のみで可能という結果です。（OSがubuntu 11.04の場合）
ちなみによく目にする標準USBコネクタとミニタイプコネクタの接続ケーブルはminiBオス－標準Aオスケーブルです。これは今回の用途には使えないので注意してください。
さて、実用化するにはHUBを除外する必要があるんですけど、どうやればいいのかわかる人居ませんでしょうか。 今回買ったminiAオス－標準Aメスケーブルを改造して５V線に電源を接続するだけで良いのでしょうか？逆流防止用のダイオードとか過電流防止のポリスイッチとかいるんじゃないかと思うのですがわかる人教えてください。