開発日誌(33)
■２月８日■
気づいたら２月も８日になるまで日誌の更新していなかった！
と言うのも、１月末から仕事で工場に張り付いて戻ってきたのが２日だったのだが、体調が優れなくてもやもやもやもやしておりました。 未だに体調不良の原因はわからず。
もやもやしつつも２月７日のROBO-ONE onPCを見に行くことに。 カンファレンスはドカさんとか網ちゃんとか聞いてみたい講演はあったのだけど、有料だし、西さんとフロスティさんがエントリーしているonPCを選びました。 観覧無料だし（笑）
実はonPCを見に行くのは初めて。 ネタ的に自分寄りだとは思いつつもお題に興味がなかったりして足を運ぶに至りませんでした。 顔ぶれが大幅に違うだろうなと思いつつ会場に着くとAIBO OPEN-R時代の知り合いに久しぶりに会ったりしてびっくりしたり。
西さんの、「梶田先生より『ヒューマノイドロボット』を読み込んでいる」と杉浦さんに言われてた「モデルZMP制御のシミュレーション結果」の発表すばらしかったです。 審査員はあの辺りの解析的手法はお好きじゃなかったようですけども。 でもシムリンク使うってことは運動方程式立てるってことなんだから（だと理解してるんですが、違うかな？） もうちょっと評価してもよかったんじゃないかと思うのだけどな。
で、今回改めてレッドリボン軍に入隊しようかと思わせたのがDrゲロさんの発表。
人間の小脳をモデル化してシミュレーションで繰り返し訓練することで歩行パターンを生成することに成功。 前提条件がいろいろあるようなので手放しで「創発」と言えるのかどうかは不明ですけど最適化の処理は功を奏しているように見えました。
また、歩行リズムはCPGを使い、接地センサーを外乱入力とすることで歩調を合わせるようにしているそうです。
シミュレーションでは運動会の大玉にぶつかっても回避運動を生成して転ばないところを見せていました。 もう、やりたかったことのオンパレードでハラハラし通しでした。
発表されたDrゲロさんのHPはこちら。 でも、今回の竹馬ロボット関連の情報はあがってないですね。 早くアップしてくださいね＞ゲロどの
帰り道、南武線でフロスティさんとゲロさんの所業や今後の展開について盛り上がりつつテンション上げて家に帰ったら、ぐずぐずしていた体調不良に火がついたようで発熱ダウン。 テンション空回りに終わってしまいましたとさ。ｼｮﾎﾞﾝ
とりあえず、CPGの微分方程式でも調べようかな。。。
あ、そういえば体調不良の間、何もしなかったわけじゃなくてヤコビアンを計算する手間を省くため、順運動学で導いた角度列＝座標式を微分するプログラムを作ってました。（文字列処理だけ、それも座標式だけだけど） これで腕の関節構造を変えても比較的簡単にヤコビアンを構築できるぞ。
■２月１１日■
雪だし体調がどうなんだろう？ってことと、いろいろ届いた部品と、わんだほー見学と、どれにするか迷ってわんだほー見学に出かける。 マゼル代表の奥様がひょんなところで知り合いだってことに今日知ったりしてびっくりしたり。
そんなことよりオサルくんが準優勝。 おめでとう〜♪
打ち上げではしゃいじゃったもんで、帰ってから喉がいがいがしています。
打ち上げ途中、もう落ちちゃうんじゃないかってほど眠かったけど、その後復活して、帰った今はすでに酒は抜けた様子。
こないだのonPCのショックが抜ける前に少し調べたCPGを計算してみる。
CPGは連立一階微分方程式で表されるで、解析解はありません。 なので数値計算で解いてみると、
文献どおりできました。 そして、2セルの発振を計算してみると、
そして、周期の異なるデータを入力してみると、
これが引き込みですね、面白い。 これは、早いとこ歩調をCPGにして、センサー入力をフィードバックできるようにすべきだな。
■２月１２日■
打ち上げで騒ぎすぎたせいか、体調悪化。 具合が悪いのはハナとノドだけなので作業に支障はないのだけど、ズルズルゴホゴホしててうっとおしい。
昨日の打ち上げでくままさんとonPCについて話をしていたのだが、先週のonPCを見ていて、少し前から考えていたODEなどを使った物理シミュレーションを取り入れていかねばならないなと改めて思いました。
仕事でもシミュレーションは使っていて（ODEとは違う分野のシミュレーションだが）有用性はもちろん理解しているのだが、シミュレーションする時間があれば実機を動かしてデータをモニターした方がいいんじゃないかと考えていました。
ま、今もそれは言えるんじゃないかと思ってますけど、onPCの発表を見る限り、システムに思っていた以上の能力があるので使えそうだし使っての検証は大事だなと思えました。
onPCに出るかって話になるとなかなか難しい。 自分がやっていることの延長か途中に「お題」があればいいのだけど、あまり興味がないお題に取り組む気がさらさらないんですよね。
さらにお題の公開から発表まで3ヶ月程度しか時間が無いのが致命的。 そんな短い時間じゃできないです。 最低半年。 できれば1年くらい欲しいな。
さぁ、明日はbeagleboardにカメラと無線LANをつないで11aを使った無線カメラを構築します。 ノボリサカさんのブログを見ながらやれば早々に完了するはず。
■２月１３日■
予定通りbeagleboardにカメラと無線LANをつなぐ。
無線LANは今回５G帯を使う。 よく使う11gは２．４G帯で、他の色々な機器と干渉してうまくいかない場合がある。運よく他との干渉がなくても1chから13ch（一応14chもある）の13チャンネル（＋１チャンネル）あるにはあるのだが、周波数が完全に外れて干渉しないチャンネル関係は３つしかないのだ。
なので、ロボでサバゲのように複数台が一同に会して使うにはチャンネルが足りなくなってしまう。 そこで５G帯。こちらはW52とW53で周波数のかぶらないチャンネルが8チャンネルも取れるのだ。
そこで、ロボでサバゲでは11aでの無線LANカメラを構築しようとしている。
ノボリサカさんから接続報告のあったコレガの無線LANアダプタをbeagleboardにつなぐと、ドライバーがロードされて「よしよし」。 PINGを打ったらちゃんと返事があります。
ところが、有線LANのケーブルを抜くとPINGが通らなくなる。 なんか迂回しちゃってるらしい。
色々調べてもわからなかったのだが、どうもアクセスポイントが５Gでは見えない。（２．４Gなら見える） AP側では受信パケット数が出てるのでなんか動いているらしいんだけどなぁ。
これがつながらなきゃ話にならないな。
カメラの方は、昔にUVCカメラで画像認識をやろうとしたときに買った安物カメラ。 あんまり良くないのでLOGICOOLのいいのを買おうと思っているのだけど一応つないでみる。
uvc-streamerはカメラを選ぶらしくてあんまりオプションが豊富ではない。 どうもこの安物カメラはYUVフォーマットしか出せないらしく、サバゲのMLで報告したところノボリサカさんからmjpg_streamerなら動くのでは、という助言が。
言われたとおりに確認してみると、「おお、見える。僕にも見えるぞ！」 でも、ブラウザーで見えるのは1秒後の世界。 遅すぎるなぁ。
昨日からやっていた工作の方はというと、まず、ラムダのひざ関節にテンショナーを入れてみました。（あ、画像無いな。） 靭帯と、アシストの役割があるので安定した歩行になるはず。
歩かせてみると、概ね安定しているのだけど、右足首がおかしいのかな？ 左脚が接地するタイミングが少し早くなってしまっている。。。。サーボ変えてみるか。
シグマは、電池の持ちが悪いので、電池をダブルで入れられるようにベースを大改造。 そして、股関節の負荷が大きすぎてすぐに熱で落ちてしまうので、こちらにもテンショナーを入れました。こっちはアシストが主の目的。
シグマの腹 飛び出していた電池を引っ込めてすっきり。
アシストスプリング（今回はラバーだけど）は関節の動作範囲が小さい時は良いのだけど、範囲が広いとうまくない。 広い動作範囲に対応できる構造を考える必要があるね。
アシスト目的のテンショナー
こちらの効果はまだ見れてません。 次回のサバゲに間に合うのかな。
■２月２０日■
今日はアソビットシティで「ロボでサバゲ」第５回大会で、参加予定だったのだけど家に居ます。
またも仕事上ので問題が発覚で出張やら後始末作業やらでおおわらわでシグマを動かすに至りませんでした。 関係者の皆様申し訳ありません。 今回は少なくとも無線LANカメラを５G帯にしての参加が（自分的には）最低条件だったのでそれも達成していなかったというのも無いではないです。
その無線LANカメラですが、ソフト設定的には完成したようです。
beagleboardにubuntuを入れてuvc-streamerでモーションJPEGフォーマットでストリームデータを流すというだけなのでソフトをインストールするだけなのですぐ動くかと思っていたのですがなんだか苦労しました。
問題のひとつは、ubuntu上のドライバーが5Gの一部のチャンネルをカバーしていなかったため、接続できない設定でうんうんやってたってのがあります。Windowsではサポート範囲だったのでうっかりしていました。
次がubuntuのリリースバージョンの問題。 ノボリサカさんが「動いた」と言ってたバージョンはubuntu10.10-r3、自分がインストールしたのは10.10-r2でした。 修正差分を確認したわけじゃないのだけど、基本的な部分で動作が変わるようなバグは無いだろうと思っていたのだけど、10.10-r4にアップしたら、安定性ががくりと変わりました。
ま、それでも十分近距離なのにPINGが落ちたり動画が止まったりしますけど。
あとはカメラ。 うちにある安いカメラ（でも当時は3500円くらいで買ったけど）だと、YUVをそのまま出すだけなので、beagleboard上でモーションJPEGにエンコードしなければ使えない。
これだと少し（1秒くらい）遅れが発生するのでサバゲ目的だとちょっと使いにくい感じです。 エンコーダーなしで使えるwebカメラを注文しました。
それはそうと、ラムダが納得する歩行をしてくれません。
ねじの緩みをチェックしたけど問題なし。 なのでトリムをチェックすると、あちらもこちらも結構ずれている。ううむ、テンショナーつけるのにあちこち分解したけど分解していないところでも結構トリムずれるのですね。
再調整して引きずる脚は治りました。こういう調整ってオートでできるようにならないかな。。。
こないだ日誌に掲載したCPGの話。 どうやってあれを歩行に組み込むのか手法を考えています。
あれはある周期で動作するタイミングを生成するのだが、引き込み信号の波形に影響を受けるので波形自体はそれほど使い道があるわけではない（と思っている）。
ある瞬間、動作が始まったとして、その周期が何秒後に完了するのかがわからないんですね。一周期遅れでいいのかなー。呼び込みで周期ずれが発生した場合の追随速度はどのようなものなのだろう。 追随するときにはどのような遷移をたどるのだろう。 特性をしらねばならないことがたくさんありそう。
でもとにかくフィードバックできる信号を生成せねばならんな。 足裏か、ジャイロか。
もろもろ考えているうちに、初代ラムダの頃から考えていたカメラポイントでの揺れをどうやってキャンセルするかの課題が（自分の中で）クローズアップしてきた。
今の歩容の考え方だと、必ずロボット全体が重心移動しなければならずカメラポイントはそれに釣れて移動してしまいます。 首の自由度を増やせばキャンセルすることもできますが、人間はほとんどそんなことをしていません。
人が歩くときにひざが曲がらないのは、脚の自由度が６以上あるからです。具体的には脚の長さが足りなくなる瞬間では踵が上がり、つま先だけで立っています。 なので、ヒールを履いている若い女性では、膝を曲げて歩いている人も居ます。せっかく脚を長く見せているのにひざ曲げて歩いちゃ魅力半減です。
今回の新型ラムダも、いくつかの目的のひとつとして足首関節とつま先部分の構造を二つ目のひざ関節で表現することを考えました。
でも、ヒールを履きなれてかっこよく歩いている女性は、かかとの代わりに腰を振ることで脚の長さが足りない部分を補います。 いわゆるモンローウォークです。 これでヒールを履いてもひざを伸ばして歩くことができます。
つまり、踵が無いロボットでも腰を振る構造を追加すればひざを伸ばして歩くことができるのです。 これが早稲田の新腰構造（だっけ）です。
実際、走る場合などは左右への体重移動を行うと速度が出せないので腰を含めた体躯全体を使った加速度を使った重心移動を行います。これはヒール関係ないですね。
今回の新型ラムダでは同じスタンスでZMPを移動できるようにしたのでZMPの違いによる上体の左右の揺れ具合を見てみました。
↓まず、ZMPを足裏の外側（中心より5mm）に設定した場合
↓次にZMPを足裏の中央に設定した場合
↓そしてZMPを足裏の内側（中心より5mm内側）に設定した場合
わかりにくいけど、ZMPを内側に寄せるほど、上体の振幅は小さくなります。
小さくなったとはいってもカメラポイントから見れば相当な振幅なので画像認識をしながらの歩行だと不利になるのは必至。
腰のロール軸と首のロール軸は必要なのかもしれないな。できればカメラポイントだけじゃなく、肩も回転させたくないので首のロール軸じゃなくて胸あたりにロール軸を入れると良いかもしれない。
歩容生成の関数を考えて、ODEかGOシミュレーションを使って歩かせてみようかな。
■２月２１日■
サバゲ用のWebカメラが届きました。
さっそくこれをbeagleboardにつないでUVC-Streamerを動かしてみると、
きれい。 これ、オートフォーカスが入ってて、ジジジジ言ってます。 いま、WLAN接続の速度を11Mに設定しているせいか、VGAサイズにすると動いたり止まったりしますので、320×240で動かしてみました。 ラグもほとんどなくて快適です。
結局、推奨品を買い揃えてしまったのでロボでサバゲの環境構築にはなんら貢献できませんでした。
BB弾が当たってもいいように保護パネルをつけてシグマに取り付けるようにしよっと。 BB弾が当たったらひび割れするくらいの強度がいいな。
■２月２４日■
新型ラムダの歩行の様子をYOUTUBEにアップした際に、リンク脚のラムダの歩行と見比べたりしたところ、遊脚接地時のスリップ具合なんぞは新型の方がいい感じ。（スリップしないってこと）
さらにZMPを足裏のどこに設定するかを変更できるようにしたので、ちょっと重心を後ろに置いた歩行、という微調整ができるようになりました。20日にアップしたZMP比較では左右方向にずらしてみたのだけど、ZMPを後ろにずらせば、少し体重が後ろに移動するので接地の具合がソフトになったりします。 カーペット上を歩かせるときは少し後ろ気味の方がいいようです。
まぁ、概ねそんな具合でいい感じなのだけど、少し動かしていると急に足を引きずり出したりします。 あれ？トリムが狂った？ねじがゆるんだ？と思ってチェックしても問題ない様子。 サーボが熱だれを起こすというほど熱くもなっていない。 なんなんだろうな、これは。
ああでもないこうでもないと、いじっているうちにガスンとこけた拍子に何が起こったのかわからんけど、右回りのその場回転するとコケるようになってしまった。 ううむ。。。テンションのかけかたが安定さを呼び、そしてまた不安定さを呼んでいるのだろうか。 そんな気がする。
歩行に対するフィードバック制御を色々と模索中。 シミュレーションにはGoシミュレーション！を使って簡単にやりたいなと考えているのだが、制御ソフトと連携せねばならない。 どうやら現バージョンではそれほど有効な制御が行えそうにないのだけどバージョンアップ待ちかな。
■２月２５日■
度重なる仕事上の危機で、ストレスが半端じゃなくなって来た週後半だったのだけど、金曜日にあれこれ（作業的に）落ち着いてきてストレスも昇華の方向に向かってきているようです。今夜はぐっすり眠れそう。（昨夜もぐっすり寝たけど）
昨日のラムダの乱調不調は結局はトリムのせいらしい。 右回転が怪しかった状態でトリムを再調整。 それなりに狂ってる。 もう一度その場旋回をやってみると右回転は安定して左回転が少し怪しくなって、と言う感じ。 トリムがシビアに効きすぎる感じです。
これはこれでやだなぁ。ロバスト性が低いってことでちゃーんと制御を入れないと悪路はぜんぜんだめってことです。 耐久性も無い。 とりあえずはねじのトルクを上げてねじ本数を増やしてみるか。
CPGの引き込み信号をどうやって作ろうか、ええとジャイロで、、、と思ったがよく考えると上体も腰も回転しないのだからダメか。では足踏み信号かな、とか考えつつ、 ZMP規範のオフライン歩容生成が仕上がってきたということはCPGの出番がなくなってきたことか？と思ったり。
でも、歩行制御でロバスト性を上げるにはオフライン制御じゃないし、でも仕上がってきたZMP歩行をあっさり捨てるのも惜しいし。。。 と考えがまとまらない。 西さんは動力学ベースの制御でがんばると言ってたけど、Dr.ゲロさんが言ってた人工知能ベースの歩行生成・制御はラムダの目指すところでもあるのでゲロさんの発表を見たことは転機だと思うべきかもしれないなと思ったり。
ということでラムダには手がつかなかったのでODEを体験してみようと思い、CodeBlocks+ODEをインストールしてみました。VisualC++2010EEもインストールしたけど、CodeBlocksの方が軽くていいね。
ボールが跳ねないからもやもやしていたのだけど、反発係数を設定してぽよんぽよんと跳ね出しました。 おもしろいね。
ODEはなかなかわかり易いというか簡単に物理シミュレーションができそうで好感持てます。 でも、ロボット実機を作るためにシミュレーションするっていうのならば手間を考えるとGOシミュレーションを使うのが正解っぽいな。 シミュレーションだけで研究論文書くってシチュエーションなら別だけど。
どちらにしても今のGOシミュの機能では実機の開発には使えないのでバージョンアップ待ちです。それまでに今後の方針を決めねば。 いや、それともUVCで顔認識にでもトライするかなー。
■２月２６日■
せっかくの休み、とにかく手を動かさねば始まらないのでシグマで作ったコントローラ部のプログラムをラムダに移植する作業をやっておりました。 ラムダではべた書きだったコントローラからのボタン情報をコンフィグできるようにしています（変数の初期設定部分で記述している）ので、キーアサイン変更などに対応しやすくしています。
少し前からコマンドラインエディタやコントローラ処理やらをラムダとシグマでできるだけ共通のソースを使えるように整備していています。 意外とこういう部分の記述には時間をかけているし、作るたびにそれなりに改良が入っているので水平展開することで開発の効率化にならないかと思っています。
やってみると、ラムダとシグマではコントローラの使い方の違いでソースに改良が必要だったりで、簡単な作業にはなりませんでした。まだ終わってないし。 終わったらシグマ側に書き戻さないといけないし。。
ロボでサバゲ用にこないだ買ったWebカメラはものすごくきれいでオートフォーカスまで入っているのだけど、ラムダに積むにはちょっとでかい。 ステレオマイクを外せば良い感じになるかもしれないが、分解してオートフォーカス部分が壊れるのがこわくてばらすのよそうと思ってます。
替わりにラムダ用にロジクールのもうひとつ下のランクのWebカメラを買うことにしました。大きさはあまり変わらないのだけど、安いので分解するのに躊躇しなくて良いかと。
アマゾンで頼むと週明けになりそうだったので、無料の当日配達サービスを使ってみることに。 これ、アマゾンプライム会員の無料体験で1ヶ月有効なんだけど、解除しないでいると有料サービスに自動的に切り替わるので緊張します。 年額3900円だったかな？
午前中に頼んだら、夕方6時過ぎに来ました。 ついでにODE本も買ってみた。 GOシミュでやるなら要らないかもね。
届いたのでBeagleBoardにつないでみた。
↑きれいです。 でもオートフォーカスがないので近い距離はちょいぼける。
C510のレビューに、「これで印刷物を相手に読ませるのは無理です。」って書いてたけど、このぼけて写っているC910なら
同じ距離でもちゃんとピントが合う。 これなら文字が読めそうな気がします。このふたつはほぼ同じ距離で撮ってます。
ちなみにBeagleBoardへ同時につないで両方とも同時に認識できてました。video0とvideo1、同期はとれないけどこれでステレオグラフやってみるか。 よし、C510をもう一個買うか！
昨日の続きのコントローラコンフィグ部分には随分悩んだ末なんとか解決。 改良版をシグマ側に戻すところまで完了。 途中、自律させるつもりなのになんでコントローラプログラムに時間かけなきゃならないんだろうと我に返ってしまった。
コントローラ部の確認のつもりでラムダを動かしていたら、いつのまにか歩行の調整になってた。
いくらトリムを取ってもあんまり良い感じにならない。 ううむと眺めてみると、歩行準備姿勢で脚が揃っているはずなのに10ミリくらいずれがある。色々比べてどうやら、昔個別設定データを別のサーボのデータで上書きしてしまったサーボが指定どおりの角度になっていない様子。 一個だけある予備サーボと交換しました。 ちょっとだけ改善したような。
でも、これは多分根本原因ではないな。。
歩幅をどんどん広げていくと、120mmを越えた辺りで急激に不安定になる。 もしかして股関節ピッチのトルクが不足しているんじゃないか？6003を投入せねばならないのか？と思ってキャプチャーで確認をすることに。
歩幅130mmで、まず股関節ロール↓ あれ？テンショナ入れて、誤差は消したんじゃなかったっけ？ 日誌で確認すると12月31日のデータだと一歩歩いた時のデータだけどきれいに消えてる。
その後、記憶をたどって、テンショナ入れても尖頭部分ではずれがあったような記憶が。 ただ、戻りの傾斜が指示値に近くなっているのが効果なのだろうという結論でした。 ううん、でもちょっと気持ち悪い。 ほんとに消せないかな。 角度にすると1.7degってとこなんだけどね。 足先では7ミリくらいになります。おそらくは状態が内側に倒れこんでしまっているのだと思うけど未確認です。
各サーボを順にチェックしていって、、、あった！ サーボが追いついてない。 でも、よく調べるとこれは遊脚の復帰部分。脚を上げるところで遅れが生じているのだけど、歩行には直接関係ないなあ。
ちなみに速度を調べてみると↓
赤いラインがサーボの無負荷時速度スペックのライン。 限界速度ちょっと超えるくらいで遅れがでてくるんだな。ただし、テンションラバーを引っ張ってるから遊脚復帰時とはいえ負荷はあります。 マイナス側は遅れていないのはテンショナーのおかげだと思われる。
このあたり、冗長構成をとっているので最適化していけばよいのだけど、シミュレーションで回してみるか。