開発日誌(35)
■５月１日■
今日から５月。 おもいっきり話の途中だけど改ページします。
足裏センサーのデータをフィードバックするためにSEMB1200Aに取り込む。
STBee-MINI側の空きがUARTしかないのだが、SEMB側で空いているのはRS485仕様となっているUART2しか空いていない。 厳密にはサーボ操作に使っている1WireUARTが1ポート空いているが、開放するのが面倒なのと今後のサーボ増設のために空けておきたいので、、 そう言っちゃうとRS485も空けておきたいなぁ。
昨日まではPCにつないでたSTBeeの出力をRS485 ドライバーを介してSEMBに接続。もうだんだんとぐちゃぐちゃになってきた。
取り込んでモニターしてみたところ、データ落ちが頻繁に起こる。 なんでこの程度でデータ落ちが起こるんだ？ 通信速度は115200baudと大して速いわけじゃない。
考えられるのはモニターのために受信データを（受信速度より遅い速度で）コンソール出力しているところ。 センサーデータの量が表示量を超えてしまっているのかもと思い、データ頻度を落としてみたがデータ落ちの具合は変わらない。 SEMB側の処理を割り込みでやってみるかなー。割り込み要因を増やすと色々面倒になりそうなので避けたかったのだが。
ZMPのフィードバックはやっつけ仕事じゃないのでこの連休でこなそうとは思っていないので、ハマりそうなところは避けて消化量重視でこないしたいのだが。
ここでハマる予定はなかったんだけどなぁ。
■５月３日■
ええ、ハマってます。 UARTの割り込み処理に。
とにかくUARTの割り込みを動かすと色々と動かなくなる。 調べていくと、UARTは、UART1/UART2/CSIで同じ割り込みチャンネルを使うのだが、CSIは割り込みのディセーブルができないらしい。 なので、まずはCSIの割り込みを刈り取ります。 でも、なんでCSIの割り込みをディセーブルできないんだろう。
すると、ぼちぼちとUART2での受信ができるようになってきたのだが、割り込みで処理しているのにメインループでポーリング受信している時よりも文字落ちが多い。。。 いや、よく見ると同じデータを2度受信している。 マニュアルを調べると 受信データの存在フラグがどういうわけかわからんが、受信が完了する前にフラグが立ってしまうらしい。 そこでフラグが立ってからちょっとだけ待ってから受信せねば2重受信してしまうと。 ちょっとだけというのは最大でストップビット分。 なので、115200baudで通信しているので9usほど。 でも、ウェイトを入れると2重受信がひどくなります。 わっからんなー。 さらに、ふむーーと悩んでいると、UART2はFIFOがOFFになっていることにやっと気づく。 ＃だって、UART1はFIFOはONになってるんですもん。。。
これかー、そうだよなぁ。とか思いながらFIFOをONにして動かすと、まったく受信しなくなってしまった。 いや、挙動が思い通りにならない。多重割り込みになってしまっているのか？
そろそろ出かける時間がせまってきたので半ば諦め気味にソースを眺めていると、、、あら、メインループでの受信処理も生かしてた。 そういや昨日、操作ミスでSTBee-MINI側に12Vを印加してしまって、動作確認のためにメインループ処理に戻したのであった。 すると、二重受信はこいつのせいか？ ＃通信レートが十分に低いと影響してくると思われる。
というわけで、やっとUART2を割り込み処理で操作してセンサーボードからのデータ受信ができるようになりました。
考えたら、FIFOをONにして、ポーリング受信すりゃいいのかも。 ま、こういうのは割り込みの方がいいのでこれで行きましょう。 まだ少し受信に失敗するのだが、タイマー割り込みとセンサーからの割り込みのどちらの優先度を上げるべきなのかちょっと考えて処理することを考えよう。 あと、センサーボードからのデータにチェックサムとかつけないとね。
さて、この先はラムダにセンサー用マイコンを搭載してからにします。 バラックのままでロボット動かしながらの開発は無理なので。 センサー用マイコンを積む場所が無いので腰部の構造を見直そうかと思ってます。 ついでにジャイロと加速度センサーも積もう。
■５月４日■
今日はシグマを動かす。
シグマは、ラムダのモニターソフトとできるだけソースを共用する作業を進めている途中、さらに圧力センサーの動作確認のためにソースをいじり回したところなんだか動かなくなってしまっていたのだ。
コンソールがろくに動かなくなったり、コントローラがさっぱり動かなくなっていたりでどっから手をつけてよいやら判らない状態だったので、まとまった時間が取れるまで放置していたのでした。
結局、コントローラのソース共用のあおりと、ラインエディタのソース共用のあおりと、ADC部分を適当に修正したあおりで動かなくなっていたのでした。 ついでにロボでサバゲで動かしている時からナゾであった、電源ONでサーボがONしてしまう現象のバグも取れました。ふう、疲れた。
というわけで無事シグマが動き出しました。 あとは、無線カメラを積むための工作をするのだけど、今度はビニテで固めるんじゃなくてちゃんと作りたいなぁ。
すぐに熱を持ってしまう足の付け根の関節にテンショナーを入れて自重を殺すようにしてみたのだけど、まぁまぁ効果はありそうです。自重でのサーボのたわみも少なくなったようで、歩行音が少し静かになったようです。
明日はとうとうUVCカメラに取り組む予定。
■５月５日■
今日は連休最終日。 ま、一日出勤したら土日なんですけどね。 多分休日出勤はしなくてよいはず。
UVCプログラムの調査と、ラムダにセンサーボードを搭載するための構造設計の見直しを。 ついでにシグマのボディ構造もちょっと見たりしててどちらかというと構造設計の方に比重があった一日でした。
一日座ってたので肩も腰もバキバキになってしまった。
構造の方は大体固まったのだけど、センサーボードを搭載する予定の腰部分を変更すると上半身が取り付かなくなってしまうのでどうしたものか。 上半身の構造の見直しも考えていて設計中なんだけど、そっちを待っていると時間がかかってしまいそうなのでアダプタでも作って今の上半身を搭載できるようにしようかな。
UVCプログラムの方は、ソース読んだり色々試したりして、大体わかってきた。 カメラ二つの同時キャプチャーはまだ未トライだけど何やればよいかは判ってきたので週末には何かできそうな気がしてきた。
画像処理をする関係上、JPEGやらMJPEGだと取り扱いに不便なのでYUVU形式で処理したい。 すると今度はモニターができない。 YUVU->MJPEGにしてストリーミングってとこまで行くには時間かかりそうだな。
このゴールデンウィークはほとんど出かけずに作業ばっかり（って眠りこけたりだらだらテレビを見てた時間も相当だったけど）やっててなかなか充実してました。 ロボカップ観に行こうかとも考えたけどスルーしてよかったんだろうな。 （ロボカップがつまらないという意味ではないですよ）
仕事の合間にやっててグタグダになってた諸々が少しずつ形になってきたのでやる気も出てきました。 引き続き頑張りましょう。
■５月７日■
UVCプログラムを調査中。
fswebcamという静止画をキャプチャーするプログラムを使って調査しています。 このプログラムを改造して二つのカメラの同時キャプチャーのテストをしようという試みです。
同時にキャプチャーするには二つのデバイスを同時に開いてトトンと二つを順にキャプチャーする、という形で考えます。 動作が速いと二つのカメラの画像が視差以上の差ができてしまってまずいのですが、同期させるのは無理っぽいのでこれで我慢。
ロボでサバゲ用に買ったロジクールのC910とC510があるので二つを同時につないでテストです。
すると、二つ目のカメラのデバイスをオープンするところで失敗します。 調べると、オープンした後にストリーミングをONにしたところで失敗しているようです。 ではストリーミング使わなきゃいいじゃんとも思えるのですが、単純なリードでも失敗するらしい。 要するに二つを同時に使えない！
でも、ネットで調べてみると複数同時に動画取得はできているらしい。 なので何らかの方法はあるはず。 OpenCVでできたってのがあったのだけど、OpenCVを使わねばならないのか？
色々調べてみると、USBの帯域を使い切っているのが原因らしい。 ならばとレゾリューションを思い切り小さくすればうまくいくかもと思って試してみたら高解像度のC910は返事さえ返ってこなくなってしまった。
もしかすると、帯域圧迫の原因はC910の高解像度にあるのでは？ と、部品箱から昔1500円で買ったWebカメラをつないでみることに。 すると、特になんの手を加えることも無く二つのカメラで同時にデバイスオープンしてキャプチャーができるようになった。
試しに100フレームのキャプチャーの時間を調べると、、、6秒。 6fpsしか出てない。 ええぇ〜、そんなー。。
いや待てよ。 安物のカメラは安物だからこうなんじゃないのか？と思って個別に調べてみると、C910が25fps C510が24fps そしてバッファローの安物が6fps
この安物が足を引っ張ってたんだな。 予定ではC510を二つつなぐつもりだったので可能性はありそうです。 安物に比べるとC510は性能高いので二つ同時使用ができるかどうか心配ではあるけれど。
早速もうひとつC510を買って試そうとしたら、アマゾンで買えない？？ なんで？ 価格コムで調べると一つ目を買った時に比べて送料込みで1000円も高くついてしまう。 人気で品切れなのかなー。 2010年秋発売の新しい製品らしいからもうちょっと様子を見てみるか。
■５月８日■
今日も昨日に引き続きUVCプログラムの調査。
今日でゴールデンウィークは完全に終わり。 ずっと机にかじりついていたため、疲れもピークになっている。連日午前3時までおきてたのだけど、昨夜は１時頃から眠くてどうしようもなくて早めに布団に入ったり。 今朝も、７時に起きたのはいいけど朝飯食ったらソファーで１時間くらい寝てしまった。
でも、今日で一連の休みは最後なので頑張る。
今日は本命のストリーミングプログラムの調査。 ロボでサバゲでの無線カメラ検討の折にノボリサカさんに紹介してもらったmpg-streamerというプログラムを使う。
これは入力部分と出力部分をプラグインで指定することができるようになっている。 画像処理ではYUYV形式の画像データを処理したいのだけど、モニターするには伝送量を考えてもJPEG形式がよい。 このプログラムだと、カメラからのYUYV形式を画像処理し、デバッグや動作確認のためにモニターするときにはモニターデータをYUYVで用意すればJPEGにしてWebブラウザーでモニターすることができる。
さらには各種コントロールを行うためのフォームもあるので改造して使うのにうってつけ。
このプログラムはスレッドを使っています。 スレッドプログラムはよく知らなくてちょっとしり込みしたのだが、分散処理ってわけじゃないから特に問題なさそうです。 昨日調べた結果を頼りにソースを読んでいくと程なくおおむねの流れは把握できました。
今日はキャプチャーデータを取得している現場を押さえることと、データの格納形態（構造体とか）を調べるだけにしました。 カメラのツイン化は後日行います。
あとはBeagleBoardとSEMB1200Aの通信を確立すれば基本的準備が整います。 でも、SEMB側にもうポートがないなぁ。
ところで、mjpg-streamerはVMware上のFireFoxから、ローカルホストを指定すれば動画を見ることができたのだけど、uvc_streamだとローカルホストだとうまくつながらない。Windowsからcromeでモニターはできるんですけどね。 なんでだろう？
そのほか、カメラを二つ搭載した頭部の構造検討を開始しました。 でも、新しい足構造の検討ばっかりやってたな。 頭部は部品を軽く配置しただけで終わったのに足構造は完成してしまった。 うむ〜、どうしよう、気に入ってしまったぞ。新しい足構造。
■５月１０日■
昨夜、なんとはなしに自分のサイトを眺めていて驚いた。 ずっと日誌をさかのぼっていくと、ROBO-ONE onPCの頃にCPGの記事が載っていた。 そういや、CPGを使って歩かせたいと思って同期信号を作るために足裏センサーやジャイロセンサーに取り掛かったのであった。 あまりにもすっかり忘れていてびっくりしてしまった。 どうも流され過ぎだなぁ。ちゃんと目的意識を持たなければいかん。
会社から帰ってからセンサー用のCPUボードと電源ボードの組み立てをやっておりました。
完成。 CPUボードの下にはRS485ドライバーが隠れています。 右は５V３AのDCDCコンバータ基板。カタログどおりならば効率80%くらいで12Vを5Vに変換してくれます。
あとはアミエさんから注文した部品が届くのを待つばかり。
■５月１５日■
金曜日に会社から帰るとアミエさんに注文していた部品が予定通りに届いていましたので早速組み立て。
腰部分にマイコンボードと電源ボードが収容されています。 さらに今回、電源スイッチも取り付けました。 今まではラジコン流にバッテリーコネクタを抜き差ししていたんですけど、スピード競技をするわけじゃないのでスイッチが入って便利になってもロスで困ったりはしないだろうと。
いままで、５V〜９Vで動くSEMB1200Aに対する電源はバッテリーの11.1Vからレギュレータで落として入力していましたが、DCDCコンバータを取り付けたので効率の悪いレギュレータは取り外しました。 さらにBeagleBoardとカメラも搭載するつもりなので効率よくしないとね。
さて、これで足裏にZMPセンサーがついて、腰部分にはジャイロと加速度センサーもつきました。 センサーフィードバックプログラム、足踏み動作を抽出してCPGでの歩行、そして２眼のカメラと、やっとロボットらしくなってきたぞ。
ところで今回、腰部分の構造を変更する際、成り行きで（腰部分だけ）外装がつきました。 これってものすごく気持ちいい。 胴体も外骨格型にしようかな。
■５月１６日■
今日は朝から大阪出張だったのだけど、目的地での滞在時間は約30分でした。 そのままとんぼ返りだったので、一日中新幹線に乗ってた感じ。 なんだか眠くて眠くてずっと寝てた（帰りはビール飲んで寝てた）のだけど、ほとんど誰ともしゃべらない一日で、さらに活動もしていないので存在感が少し希薄になった気がしてしまった。
組み立てた腰部分を早速分解して、プログラムの開始です。 今はアスキーコードで数字を出力しているのだけど無駄にデータ長が長くなってしまうのでHEXコードで出力するように変更します。さらには、今のテストプログラムはループで送信しまくっているのですが、タイマーで定時出力します。 サーボの制御周期が20msくらい（25msだっけかな？）なので、10ms程度の周期にします。できるだけ最新データでフィードバックがかかるように。。
これ、センサーマイコンを変更すると、Windowsのモニタープログラムも、受信側であるSEMB1200Aのプログラムも変更しなければならない。 するとうまく行かないときどっちにバグがあるかわからんようになるんですよね。 あーめんどくさい。
でも、ロボットの外装をはずしてケーブル引き出してデバッグしている姿って、アムロがハロを組み立ててるシーン（回想シーンだけど）みたいでいいですね。
このプローブ線を取り付けているのはSTBee-MINIを取り付けているピンソケットです。 STBee-MINIに添付しているヘッダーとピンソケットだと無駄に背が高くなってしまうので秋月で背の低いのを探してたところ、1列ものでは見つからなくて2列ものしかありませんでした。
仕方ないのでこの2列ものをつかっているのだけど、余った1列はSTBee-MINIの外側になるように配置して、信号引き出しに使えるようにしています。ジャイロ＆Gセンサーも、I2Cの信号の並びが一緒だったのでこの余った1列を利用して簡単に取り付けることができました。
早速プログラムに入ろうとしたら、Windowsのモニタープログラムがエラーを起こして動かない？？？ これはジャイロ＆Gセンサーを取り付けたことでエラーコードが出なくなってしまったのでモニターのデコード部がエラーを起こしてたと。 しかし、エラーコードを使ってデコードするって間に合わせに作ったにしてもいい加減過ぎだぞ＞1ヶ月前のオレ
スマスマに出てた北川景子を観たりしてたので取りかかったのが遅かった。もう遅いので続きは明日ということで。
■５月２３日■
あれ？１６日から日誌を更新していなかった？？ そうだっけかな。
ええと、センサー用CPUからの送信フォーマットをバイナリーにしてチェックサムつけて短くするのだけど、Windowsでのモニタープログラムに難航。 テキストデータで受けるのは簡単なのにバイナリーだとどうすればいいのかな？ VisualC++ってもうこれってCでもC++でもないですね。ちょっと調べて、バイトごとにバッファから取り出すメソッドを使っても思い通り動かない。どうも、バッファにあるデータ数を調べてそのバイト数だけ受信しなきゃならないのかな？ 調べたりトライするのがめんどくさくなってWindowsのモニタープログラムは放置。 あとでどうするか考えよう。
ってことでSEMB1200Aの受信プログラムを作ることに。
と思っていたのだが、木曜日の夜からなんだか体調がおかしいぞ？？ 金曜日は午前中だけなんとか仕事して午後からは早退。 そのまま土曜日〜日曜日とぐだぐだになってしまいました。 風邪みたいな感じなんだけど熱はほとんどなし。ただし頭痛がひどくって頭使うような作業はさっぱりできない。 じっとしていると頭痛も治まるのだけど動き出すと吐き気がするほど頭痛がし出す。 そしてまた寝る。 こういうときっていくらでも寝れるんですね。
そうして日曜日の夜くらいにやっと頭痛が治まって活動を再開できるようになりました。
それからもあれやらこれやらあったのですが、省略してSEMB1200Aの受信側のプログラムができました。 チェックサム付きのバイナリーデータで送ることで圧力センサーとジャイロ＋加速度センサーの測定結果を31byte（ヘッダー込み）で送るようにしました。 10ms周期で受け取っているので、25ms周期のサーボ操作と同期はしていないのだけど十分に利用できるデータとなっているはず。 ずーーっとランニング動作させていると、3％くらいの確率で通信に失敗しているようです。 おそらくは他の通信（多分サーボ通信いやCSI通信の可能性もあるか）とかぶってしまう周期で取りこぼしをしてしまうらしい。 ホントならお話にならないエラー量なんだけどまぁいいか。 エラーデータは廃棄できるようにしているのでよしとしよう。
ほんとは空き時間にデータ送れって指令を出すようにするべきだろうな。 通信料も減るし。
ここまでは昨夜の話。 昨夜は病み上がりで午前2時くらいまでやってたのでさすがに日誌を更新する作業はまずいと思って寝てしまいました。 さて、これから昨日の続きをやるかー。
そういえば、等身大スコープドッグを作ったKOGOROさんが今度は油圧で動く巨大ロボットを作ってるとか、それの制御部分をV-sidoの吉崎さんが担当するとか。 すげー！２足の巨大ロボがとうとう歩くのか！？ と思ったら、これは２足じゃないんですね。４脚で、モデルを見る限り足の先にタイヤがついている。 ううむ残念。 油圧じゃ速度的に歩くのは無理かな。
■５月２４日■
昨日の日誌を書いた後、やっぱモニター環境が要るでしょうってことでセンサーボードから受信したバイナリーデータを既にできているWindowsのモニタープログラムが理解できるテキスト形式に変換して出力するようにしてました。
センサーボードからSEMBへのデータ送信は10ms毎なのだけど、そのペースでSEMBから出力すると間に合わない（SEMBのモニターは無線にしているために速度を遅くしている）ということで10分の1である100ms毎に出力しモニタープログラムで受信できるようにしてました。 モニタープログラムはもうすぐお役御免なのでこんな感じでいいでしょう。 ま、ものすごく不便なんですけどね。 ないよりマシって程度かな。
そして、早速ZMP測定結果をフィードバックしてみることに。 一番簡単なのはZMPのX方向Y方向のずれに合わせて足首のサーボにフィードバックをかけること。 これだとすぐにできそうなんだけど一つ心配が。
ZMPがずれている方向に重心がずれているわけだから足首にフィードバックした結果さらにZMPはずれてしまう。 なんか発振してしまいそうだなーと。。
ほかのフィードバック方法だとZMPのずれにあわせて上体を傾けるとかかな。 重心軌道そのものに補正をかけるなら補正の計算をしなきゃならないし、その予測って地面が平坦であることが前提となるわけだからロバスト性にかけるんじゃないかなと思って敬遠してる。
まぁ考えてもわからんからとにかくやってみることにする。 まずは単純に足首サーボにPID制御でフィードバックしてみるのだが、このケースだと積分要素って不要かな。 PD制御って聞いたことないけど、積分要素の係数がゼロだと思えばよいだろう。
ということでとりあえずP要素（比例要素）だけでフィードバックしてみると、
立ってるだけでぐらぐらと（笑） じっとしてるとぐらぐらしてるんだけど、この状態で歩かせるとまぁまぁ歩く。 フィードバックの効果も感じないけどね。
じゃーD要素（微分要素）も入れてみるか。普通、微分要素って追随速度を上げるために入れるけど、このケースだと微分要素の係数はマイナスにすれば良いのかな？ ・・・それとも上体の傾きにトライかなー、そっちは結構大変なんだよな、変更点が多くて。
さて、あてずっぽうばっかりじゃなくて制御の教科書も調べてみるか。
■５月２６日■
昨夜は飲み会だったので作業はできず。
PD要素で係数を色々変えてみても変化なし。
では、ってことで、足首だけじゃなくて股関節も逆位相でフィードバックしてみることにしてみました。 足首だけだと重心が変化する前に足裏の圧力の方に効果が出てしまうのでうまくない。股関節も逆位相で変化させることで重心は移動するけど足裏にかかる圧力は直接変化しない。
というのでやってみたところ、効果があるような気がしてきた。 なにせフィードバックなくてもそこそこ動くので劇的変化が起こらないわけで効果のほどがわからない。
変化と言うと、フィードバックをかけたほうがガシガシと動く。 フィードバックなしだとスタスタ〜って感じなんだよね。 フィードバックなしの方がスマートな感じ。
でも、歩幅を変えたり色々やると、フィードバックをかけないと不安定になるようなパターンでもフィードバックがあれば歩けるような感じになってきた。 でも、それでもまだ完全グリップ歩行はうまくないんだよなぁ。
あと、股関節も動かしているので制御量が大きいと足が絡んじゃう場合もある。 リミットも受けないといけないな。
ジャイロも動かして、転倒回避に再トライしたいな。 その前にカメラをなんとかしないとなぁ。
■５月２７日■
フィードバック制御もなんとなく成果が見えてきたので２眼カメラに取り組みたいなと。
ちょくちょくアマゾンをチェックしていたら売切れていたC510が入荷したらしいので買っておいたのが届いている。 早速２台のC510を接続してみましょう、 と作業をしだして思い出した。そういえばC910とC510の組み合わせだと帯域オーバーらしい問題で２台目のカメラが使えないのであった。
C510×２台だとどうか！？ ダメだとせっかく買ったC510は無駄買いだったってことなのだが。。。
って即ダメが出ました。（泣）
レゾリューション落としてもダメ。何してもダメ。 ふぅ、失敗ですか。
でも２眼やりたいからなぁ、ということでもっと帯域が細そうなカメラを探すことに。 バッファローみたいに暗くて遅いのは要らないからやっぱりロジクールから選ぶことにしよう。
ロジクールのWebページに行くと、、 あらららら、C510の後継のC525ってのが載ってる。 同じサイズで同じ定価でAF付ですよ。 AFの威力はものすごいものだから欲しいけどなぁ２眼できないから意味ないか。 （でもそのうち買っちゃいそう） ちなみにアマゾン価格ではC510より1000円くらいは高い。
ということで、さらに格下のC270ってのを買うことに。 アマゾンで1,500円なので一気に2個買っちゃうことにします。 これでだめならC525で1眼で進めるかなぁ、いまいち乗り気がしないけど。
その他の方法としてはUSBホストを2本にしてそれぞれにカメラをつなぐというのがありそうです。 でもBeagleBoardにUSBホストを増設ってのはできそうにないしねぇ。
ZMPフィードバックの歩行の様子を動画で撮影しました。 フィードバックによって劇的な安定性が生まれたわけでもなく、フィードバックしないでもまぁまぁきれいに歩いていたので差があんまりわからないのだけど、フィードバックかけないときは足を高く上げると不安定になりがちだったのが、あまり不安なく歩けたりするからきっと効果はあるのだろう。
劇的ビフォアアフターじゃないのが残念ですが。
いままで股関節高さ設定を230mmにしていたのだけど、この動画は股関節高さ設定は250mmです。ここまで足を伸ばすと結構見栄えがいいと思うのですがどうでしょう。 ひざ曲げ歩行よりは人間に近いと思うのだが。 もう一息だな。
■５月２９日■
土曜日は練習会でした。
会場は草加の商工会議所なのですが、草加は遠いのでいつも二の足を踏んでしまいます。 さらに最近、荷造りするのが異様に嫌になってまして、結局ロボットもって行かなかったり。。
今回は更に更に天気が雨なので車で行くことにしました。でも車だと飲めないんだよなー。 昔は飲まなくても盛り上がれるって思ってたけど最近どうもダメですね。 酒の力を借りないとテンション上がらない。。
今回も雨天という悪条件に関わらず相当たくさんの参加者でにぎわいました。 最近は大学生のグループがたくさん参加するのでいい傾向ですね。 大学生たちは傾向として、練習会に来ても自分たちだけで盛り上がる傾向があったのですが、最近は学生一人ひとりが「ロボット見せてもらっていいですカー」って感じでやってくるので進歩です。 何が変わったんだろう？？
で、今回は車で参加ってことだったのでラムダもシグマもトランクに放り込んでやってきました。 ラムダはZMPセンサーができたのでちょっと見て欲しかったし。
で、ラムダを見に来てくれた学生が、「足が2重になっているのはなぜですか？」という質問を。 おお、良くぞ聞いてくれた！ 「これはZMPを測定するための圧力センサーが仕込んでるんだ」 とか説明したら 「ZMP測定して何するんですか」 えーーーと、 その質問は想定外だな。 「ZMPって何ですか」ならまだしも。。。
センサーに反応してくれそうなのは吉田さん、小泉さんくらいか。 でもお二人とも今日は居ない様子。 で、くままさんに「吉田さんに見せたかったんだよなー」とか言ってたら練習会終わり間際に吉田さん登場。
ひとしきり出来具合を見せたところ、「歩行時の負荷のカーブはどんな感じですか」 「反応速度は？」 とかイイ反応です。 あ、でもそこらあたりの分析がまだできてないんですよね。 ということで歩行時の圧力変化のカーブを取得してみましょう。
今日の朝、練習会の疲れか、いつもより朝寝。 起きて朝飯食べてからもうとうとしていましたら、アマゾンから荷物が。 金曜日に頼んだC270×2台がもう届いたようです。 早いなぁ。 外装の設計をしていたのを中断して早速2台同時に使用できるかどうかをテスト。
なんか、タイムアウトエラーがでやすいのが気になるんだけど、2台同時にデバイスオープンしてグラブ（画像取得）も同時（というか並行っていうか）にできました！ よかったー、答えはこれか。 3000円で済むところWebカメラにいったいいくら使っただろう。
速度も2台でキャプチャーしている状態で、29〜31fpsくらいです。
このまま２眼カメラに突入したい気持ちを抑えて外装設計の続きと、ZMPセンサーを使った分析をやることに。
センサー値を記録するには大量のメモリーが要るのだけど、歩行時の関節角度値を記録しているのでそんなに余裕がありません。 ということで、関節角度キャプチャー機能にスイッチを追加してメモリーに余裕を持たせましょう。 ついでにスイッチ関係の変数を統合管理して、、、 という整理をやってたら時間がなくなってしまった。
続きはあした。
昨日の続き、 キャプチャーできるようになりました。 10ms周期のデータです。
まず、ZMPフィードバックなし
次にZMPフィードバックあり 左、右の順です。
ガッチャガチャですね。 そして、フィードバックの有り無しはさっぱりわからない。
足が浮いている時間が随分と短いです。 両足支持期間は設けてはいるけどこんなには長くないはず。 この辺りがフルグリップでは歩けないというところですね。 足上げ関数をいじってみるかなぁ〜。 4歩目（左足支持）の時はなぜかイイ感じにZMPが中央付近に来ているようです。 なぜだろう？？
スタート時点でZMPが中央に来ていないのは両足接地時のトリム調整が不十分、または股関節のテンショナーが効きすぎているせいかと。