開発日誌(36)
■６月１日■
今日から新しいページに。
両足支持期間が長すぎるんじゃないのか？と思って色々と足上げと足の運びの関数をいじってみました。
もともとは下段右端のカーブで、ゆっくり上げてゆっくり下げるというタイプでした。
ゆっくり下げるのがあだになって、早めに着地してしまうのかなぁと思ったので早く遊脚を前に出してできるだけ長く滞空させる（おろすときはさっとおろす）というのを試してみたのだけど、跳ねてしまってダメ。 リンク脚の時は、それでもまぁ歩けたんだけど今の足構造だとダメでした。
足上げはあんまり問題なさそうだってことで、ゆっくり上げるけど、すばやく前に足を送って、ゆっくりおろすという上段左端のタイプに落ち着きました。
見た目には早めに着地しちゃってるってことはなさそうなのでZMPをキャプチャーしてみたところ、、、、月曜日となんら変わりなし。 ちゃんと計算してみると、1歩が0.5秒で、両足支持機関は0.08秒 キャプチャーデータによると、両足支持期間が0.16秒くらいになってる。 うううううんんんん、、わかんないからまぁいいかー。
相変わらず左足はイイ感じになってるのでトリムをしっかりとればZMPは改善するかも、、、ってフィードバック関係なくなってるし（笑）
でもでも、フィードバックかけてると粘り強くなるのは確か。 もちょっと色々試してみたいですね。
この、両足支持期間の割合は初代ラムダで、倒立振子モデルで歩かせている時に調整したものを使ってます。 今回色々変更してみたけど、今の割合がほぼベストな感じでした。
※zmpfbk 0.01 0.01 0.03 0.03 0.1 shiftzmp -5 5 0 0
■６月２日■
昨日、日誌をアップしてから色々パラメータを変えて歩かせているうち、 「そういや、1歩のペースを長くして歩けるかな？」と思い試してみることに。 というのも、ペースを長くしていくと静歩行に近づくわけだけれど、加速度も考慮して計算している以上、静歩行にはなりません。 すると、意外と不安定になって歩けないと言うことが以前（リンク脚のころ）ありました。
で、歩かせてみると、1歩を1秒にしても歩けるやん！ ということでなかなか面白いので動画アップを。 抜き足差し足って感じです。
これは、一歩が０．６秒、 歩幅が100ミリです。
で、これが一歩が1秒で歩幅が140ミリです。 相変わらずフルグリップでは歩けないんですけどね。 遊脚を早く前に送ってゆっくりと降ろす様子がよくわかります。
計算歩行でこれができたのって感慨深いですねー。 機構とか、関節構造とか、センサーフィードバックとか、テンショナーとか、歩容とかの総合的な成果だと思いたい。
■６月５日■
フィードバックパラメータをフラッシュ領域に保存するとか、まだ作業はあるのだけど、歩行はちょっと休止。 カメラの二眼化を進めます。
晴れてUVCカメラ2台を同時動作することができたので、mjpg-streamerを細工して2台を同時キャプチャーできるようにしようと思っています。 mjpg-streamerはいろんな入力出力をプラグインで選択することができるようになっていますので、この場合はinput_uvc.soを改造して2台キャプチャー、output_http.soを改造して2画像を同時配信できるようにします。
まずは、input_uvc.soを改造しようとして画像関連の構造体を調べていたところ、あれ？これもしかして、インプットをいくつも受付られるのか？ プログラム的には複数の入力を許しています。 ではと、インプットプラグインを二つ指定してそれぞれのビデオデバイスを指定します。 おお、ちゃんと認識してるやん！
では、出力側は？認識はしているけど表示を選択できないな。
じゃあと、プログラムを読んで行くと、、、、見つかりました、入力IDを読み取っているところが。 それにあわせてブラウザに流すデータを修正したところ、、、できました。
これは静止画だけど、ちゃんと動画で表示されています。 VGAサイズだとちょっともたつくのでQVGAにしたところなかなか快適。 MJPEGにしないでも実用範囲かも。
ラムダの目のための二眼化なんだけど、このままサバゲに使えそう。 ビーグルボードに載せても同じように動くよねぇ。
ひとつのスレッドで二つのカメラからキャプチャーするつもりだったのだけど、そういうわけで現在は二つのスレッドで動いていることになります。 これってどうなんだろうな、オーバーヘッドが大きいってことは無いのだろうか。 あ、それよりどこで画像データをいじればいいんだっけ？？？
とりあえずはお手軽なCDTを実装して、色重心をステレオ化して奥行き情報を生成してみよう。
■６月６日■
じゃあまぁ、まずはBeagleBoardで同様の動作をさせてみましょう。 ということで久しぶりにBeagleBoardを取り出して動かしてみたところ。
・・・・パニック！？ あらら、ファイルシステムがぶっ壊れてOSが立ち上がりません。 最後に電源を切った時ってどうやったっけか。。
というわけで、BeagleBoardにOSから再インストール中です。 apt-get upgrade の時間のかかること。。 upgradeするくらいならダウンロード済みのアーカイブを使わないで最新のリビジョンをダウンロードしてくるべきだった。
今夜はこれで終わっちゃいそうだな。orz
■６月７日■
やっとOSをインストールして、uvc_streamerをインストールしてみる。
あれ？ うまく動かない。 何かが以前と違う感じ。 カメラをC910にしてみても動作が不安定。
lsmodしてみると、v4l1_compatモジュールがロードされていない。 おっかしーなー。 C910はたまにうまくいくのだけど、C270はSegment faultまで起こしてしまう。 なんか絶望的。
昨夜は諦めて、後ろ髪を引かれながら寝てしまった。
今日は朝から大阪出張だったので、新幹線でサバゲMLをチェック。 どうやら最近はv4l1_compatじゃなくて、v4l2-commonになっている上に強制ロードせねばならないらしい。 どうやらapt-get upgradeのおかげでモジュールも更新されたのか。
家に帰って（帰って作業するために帰りの新幹線はノーアルコールで）早速動作確認。
強制ロードはできたのだが、事態は変わらない。（C910は安定している様子） C270がダメだと２眼がダメになるから困るんだけどなー。 結局、uvc_streamerだと安定動作は無理ということで、mjpg-streamerに切り替え。 とどのつまり、こっちで動けばラムダ的には困らない。 シグマはC910でも良いし。
mjpg-steamerで試したところすんなり動作しました。 mjpgフォーマットでの出力とCPUのパワーと、LAN回線を通しての話と、どれが決定的なのかわかりませんが、YUV出力でOKならよかったー。 そして、２眼での動作確認に。
CPUか、LANのスループットに問題があるらしく、CVGAにしても２眼だと画面が欠けまくり、、、mjpegの時のようにSegmentfaultは起こさないのでまだよいのですが。
結局、180×120まで小さくすることで２眼が成り立ちました。 これ、キャプチャーの問題なのか、伝送路の問題なのかはっきりさせないとだめですね。
これだけ小さくするとmjpg-streamerでもラグはほとんどありません。 画面小さすぎだけどなー。
モニターできるかどうかはわからないけど、BeagleBoardで、C270で２眼で同時動作できることはわかりました。 よかったー。
■６月１２日■
今日は川崎での練習会でした。
昨日はアミエさんに注文していたアルミの切り出しが届くのを待ちながらCoronで動かしていたシグマのプログラムをSTBee-MINIで動くようにプログラム修正しておりました。「JTAG端子を無効にする」ってのに引っかかって数時間ロスったけどあとは順調に移植作業は進んでいます。 SPIもなんかおかしい気がするけどおおむね動作しているようす。電源系をちゃんとしたらきっと動いてくれるだろう。
間もなく待ってたブツが届いたので工作開始。 ところが、サイズが大きくて切り出しが簡単な１ミリ厚部品の加工が終了するころ、２０年愛用のボール盤が壊れてしまった。 あらら～まだサラモミが残っているのに。。。
電動ドリルでサラモミしようとしたら勢い余って抜いちゃったりしてダメです。 急いで修理しなきゃ、、、 なんだけど、なんせ２０年前に買ったもの（正確にはわからんけど確か学生時代から使っていたような気がする）だし、安物だから補修部品がありません。 昔、一度ブラシがおかしくなってモーターが回らなくなったときはどっかから持ってきたブラシを削って直したなぁ。
で、今回は実はベルトが切れただけなのだけど、これって規格品なのかな？ 寸法測ってネットで探したけどずばりのものがありません。 径も長さも合わない。 インチ系なのかな？？
しょぼいボール盤だからいいの買わなきゃと以前は思ってたんだけど、いざ買うとなると色々迷ったりして。 いっそのこと憧れのフライス盤を買おうかと思って色々探してみたけれど安いのでも４０キロくらいあるし、そしてボール盤の代わりになるかっていうと微妙。
結局、決めかねて、それらしいサイズの丸ベルトを注文しておきました。 １個５００円くらいだけど、送料と代引き手数料で１４００円になってしまった。 無駄にならなければ良いが。
シグマの工作は時間切れ＋ボール盤作業待ちで停止。 そろそろ時間的にやばくなってきたぞ。
実はシグマのフレームの一部に、軽量化のためにABSを使おうとしています。 Webで売ってるところを探してみると、こういうとこが見つかったので注文しておきました。 今日の練習会でオサル君にいつもどこで買っているのか聞くと、ここだそうです。 品質が良くて一番安いらしい。 でも、買った2ミリ厚で計算するとほんのわずかだけど、自分が買ったところの方が安いみたい。 送料とか送金費用を合わせるとどうなるのかわからんし、品質が不明ですけどね。 ご紹介だけ。
その、今日の練習会だけど、まれに見る盛況ぶりでした。 更に、みんなロボット作ったり調整したり、ロボット談義したり、まるで関東組ロボット練習会じゃないみたい。 長いことやってるとこういうこともあるんだなーと。
終わりかけの時間に珍しくフロスティデザインさんがやってきて、先日アップしたラムダの歩行動画に対してアドバイスをもらいました。 フルグリップ歩行への着眼点をいくつか。 いやその、自分ももっと試したいことあるんだけど、他にも進めなきゃならない（というか進めたい）アイテムがたくさん有って、歩行だけやっててもご飯何杯でもおかわりできるボリュームなので、そこんとこはバランス取りながらやってるつもりなんですよ。
今日もらったアドバイスは、ビール飲み始める前にしっかりとメモ取りましたんで、折を見て実験＋実践していきます。 フロスティデザインあにきにもらったアドバイス、簡単に列挙しておきます。
5msにすると計算量とデータ量がべらぼうに増えるのでメモリーが足りるか心配だな。 精度落とさないと無理かも。
あと、アミエさんにも工具に対するアドバイスいただきましてありがとうございました。 フライス盤は欲しいけどやっぱりマンションじゃ難しそうです。 でも、欲しいなぁ。 パワフルなフライス。 やりたいこと考えるとパワフルなCNCじゃないとダメだから更に敷居が高いけど。
再来週はロボでサバゲです。 しばらくはシグマの仕上げに全力そそがないとやばくなってきた。
■６月１８日■
ほぼ一週間ぶりの更新です。
先週の練習会でもらったフロスティデザインさんのアドバイスから、今一度再生精度の確認をしてみました。
すると、ひどいことに股関節ロール軸のオーバーシュートが復活してまして、上体が遊脚側に倒れこみ、遊脚の着地タイミングと着地位置がでたらめになっておりました。 ロール軸に入れたテンションラバーを調べてみたところ少しゴムが伸びてしまっていて張力が低下していました。
しかし、ゴムを交換して済む話ではなさそうです。
さらに、フロさんからは「支持脚の沈み込みはないですか」という指摘ももらっていたのでそこんとこもちゃんと確認してみました。一歩0.7秒のデータです。
上から股関節ロール軸、右足高さ、左足高さ です。 高さデータは関節角度から順運動学計算で求めていますが、股関節を原点としているので沈み込みの値はあまり正しくないですね。 せめて、足裏が接触している前提での値にすべきだった。
股関節ロールの角度が目標値からずれている範囲でラインを引いてみると、ほぼ支持脚となっている期間と一致します。 つまり、上体の重さに耐えられていないということですね。
支持脚の高さは、目標値-250ミリに対して、2ミリほどずれが出ています。 股関節ロール軸の影響は、大体1ミリくらいなので膝の関節角度のひずみにより、1ミリ程度は沈み込みが発生しているようです。
・・・明日時間があったら姿勢変換したデータにしてみようかな。
こうして股関節ロールがひずんでしまうのを見ると、股関節間距離が大きいのは不利です。 初代ラムダのように股関節間距離を小さくして、股関節ヨー軸は大腿に持たせるというのが正解なのかもしれないなー。 あれはあれで色々難しいところがあるのですが。
で、対策なのですが、アシストを強くしてもよいのだけど、まだ機体重量はまだアップする予定だし、アシスト強化は可動範囲が狭くなるばかりなのでやはりまずはトルクアップから。 今はKRS-4014なので、6003を投入するか！ 股関節ロール軸にだけ6003を投入する人って居ないかも。
■６月１９日■
次の週末は「ロボでサバゲ」。 今回は参加予定なのでシグマの組み立てをやっております。
サバゲ機体は、ロボット本体に銃や被弾センサーやカメラやほとんど標準装備となっているレーザーサイトなどを積まなければなりません。 いつもガムテで無理やり搭載していたのですが、今後のシグマのことも考えてちゃんとすることにしました。
いままではコロンで動かしていたのだけど、STBee-MINIでも容量的には大丈夫だろうということでCPUはSTBee-MINIを、カメラ用、ゆくゆくは脳みそとして使う予定のBeagleBoardも積みます。更には電池の持ちが悪いので２パラで動かせるようにバッテリー搭載エリアも拡大しました。 リポの２パラちょっと怖いですけどね。 メーカーと電圧を合わせれば大丈夫なはず。
で、やっと先ほど操縦用の無線と、サーボ制御用のRS485が動いてシグマが再び動き出しました。 STBeeはちっこいのがいいのだけど、取り付け穴が無いので良し悪しです。
RS485コンバータと無線コントローラ用のレベルシフタも小さく作り直しました。 本当はSTBeeのベースボードに実装したかったのだけど、サイズ的に無理だったので分散搭載としました。
でも、これから銃を載せてカメラ載せてセンサー載せてプログラム修正して、、、 間に合うのかなぁ。 土曜日があるからなんとかなるかな。
小さくなったレベルシフタ基板とRS485基板。 以前のサイズがわからないと意味無いけどね。
BeagleBoardとSTBee-MINIを搭載している様子。 左上の基板は電源基板 手前の柱についているのがSTBee
フル装備で何キロになったかなー。 バッテリーが切れる前にサーボが熱で落ちたりしてね。(^_^;)
■６月２６日■
今日は「ロボでサバゲ」でした。 このウィークデーは最後の追い込みでできるだけ飲まずに帰って作業を進める予定だったのですが、出張になったり急遽の飲み会になったり、暑くてやってられなくなったりで、結局は土曜日の時点でまだ配線が完全に終わっていない状態でした。
土曜日は歩いてレーザーサイトがONOFFできて、カメラは電源入れると自動起動できるようになって、、 あとは電動ガンのトリガーと被弾センサーの処理を実装すれば一応はゲームに参加できるようになるって状態で２８時（今日の午前４時）くらいでした。
日曜日は１２時半に大日本技研に集合。 車で行く予定だったので、技研までの時間を調べると３０分（グーグル調べ） あら、近いやん。 ってことで、ガンとセンサーの処理は日曜日の午前中にこなすことで寝ることに。 いや、徹夜にはめっぽう弱いタチなので(^^ゞ
いつもなら７時には目が覚めるのに、今日に限って目覚めるともう９時！ 疲れている上に涼しくてすごしやすい気温だったもんだから寝過ごしてしまった。 でも、１１時過ぎにプログラムの実装がなんとか完了。 ガシャガシャと荷物をまとめ、急いで出発しました。ふぅ、間に合った。
今回のシグマ（サバゲ仕様）
今回はバラック状態でお茶を濁していたシグマ（サバゲ仕様）を、まともにすることだったのだけど、結局ビニテは完全追放できませんでした。
ビニテのお世話になった部分
・ レーザーサイト取り付け
・ カメラ取り付け
・ コントローラ用受信機の取り付け
・ 弾倉のフタの固定
・ バッテリーの固定
そして、実戦。 自分が用意した802.11aの無線LANアクセスポイントだといまいち安定しないのでドングルと同じコレガのAPなら安定するかもと思って田中さんにコレガのAPを借りて接続にトライ。 こないだの練習会では田中さんが接続テストするのを手伝ったりしていたのだけど、どういうわけかつながらない。
結局、ルーター機能を切って、暗号化をすべてなしにして、ビーグルボードを再起動することでつながりました。 ふぅ、あせった。
でもその後もゲームが始まるたびに接続が途絶え、最後まで安定して動かすことはできませんでした。 どうもおかしくなるタイミングは電動ガンを打つことと同期しているように思えるので、そこからのノイズが怪しいなと、 ノイズ対策してリトライしてみます。
シグマベースにも大きく手を加えてメンテ性と安定性を向上させようと思ったのですが、思い通りに行かなかった点も多々あり、９月のSF大会までには修正していきたいと思います。
修正点
・ 無線LANの不安定さを解決 → 電動ガンのノイズ対策
・ UVC-streamerをストリーム化できないか？ → 今でも動画部分はストリーム（UDP通信）になってませんか？＞ノボリサカさん 多点で動画受信できるならTCP通信じゃないと思うのですが。 それよりも無線LANプロトコル層ではアクノリッジを待つのでUDP接続になっているのが無駄になってるとかじゃないですかね？
・ 電源周りの見直し 電池のパラ化と待機時には安定化電源から電源供給できるようにできないか。 → 安定化電源からのラインに逆流防止ダイオード入れれば良い？ バッテリー側には入れたくないので、バッテリー側にスイッチを入れる。 両方接続する場合はバッテリー側のスイッチを切っておくようにすれば長時間バッテリーに電流が流れ込むことは（運用で）防げるはず。
・ バッテリーの交換方法を再検討。 上からは無理っぽい。 せっかく２個まで格納できるようにしたのに使えず。
・ ビーグルボードの付けはずし構造 再検討
・ ビーグルボードのUSBポートが全部使えるように再検討
・ CPUブロックから上部への配線方法再検討
・ リセット状態では電動ガンが発射状態となる。 論理を反転した方が良いか。 （現状は正論理）
・ バッテリーの過放電防止機構を検討する。 CPU用リザーブバッテリーとメインバッテリー切り替えはできないか？
・ つま先のブーツを付け外し可能なものにする。 （今はビニテ）
・ 電動ガンの電源は別にしたい → ノイズ対策と、５Ｖだとちょっと弱い。
・ 弾倉をＡＢＳで作り直す。 スチロール板はいまいちの気がする。
・ 操縦をアナログ指示しているのをやめる。 思い通りに進まないので。。
・ 方位指示はちょっとディレイしてアナログスティックのふらつきを排除する。 ブルブルしすぎるので。。
・ カメラのオートフォーカス採用は成果みれず。
・ チームフラッグを取り付けられるようにする。ＬＥＤも対応する。
・ マイコンのリセットボタンを作る。 （作らないと困るかも、 と思っていたが今回は困らなかった）
そんなもんかなー。 あと２ヶ月のうちに修正できるだろうか？？？？
さて、明日からはラムダに移行。 サーボの一部チャンネルが不具合ってとこで止まってる。 うんざりだな。。
昨日は残業して帰ってからラムダのシリアルポートが2ポートほど動作不良になっている件の調査をしておりました。
結果的には素子破壊と思われるため、バッファＩＣを交換せねばなりません。 こないだも交換したよなぁ。 スペックオーバーな使い方をしているのかな。
でも、SSOPなので二度と交換したくないと堅く誓ったし、大体にして基板が汚くてもう品質が期待できません。 なんらかの方法で作り直すこととして、当面は壊れた2ポートにつないでいたサーボを、空きポート2ポートにつなぎなおすことでしのぐこととしました。
当面やりたいことは色々あるのだけど、ラムダが壊れる前にやりたかったことをやろう。
関節角度から足先座標を計算し、足裏の姿勢を使って（足裏がちゃんと接地している前提での）足先座標と胴体の姿勢を算出します。
上から①右足の左右方向の足先座標、②右足裏のロール軸姿勢（角度）、符号を逆に読めば胴体のロール軸姿勢、③右足の上下方向の足先座標
これは、常に足裏が地面と平行になっているとした場合の足先座標です。 実際には遊脚の時には胴体姿勢を基点に足先座標と足裏姿勢が定まるので、参照すべきではありません。
姿勢を配慮すると、10日前に採取した時よりも座標自体は再現度が高いのが判ります。 でも、胴体の姿勢はガクガクと振動しています。 支持脚になったところで大きく揺らぎ、着地とともに姿勢が戻ってきます。
遊脚でもブラブラと揺らぎがありますが、オフセットは小さく、足先がフリーになった影響で揺れているようです。
実際には胴体の揺れと、遊脚の揺れが合成されて遊脚の足先が振れるわけで、着地点がさだまらないこと著しいという結果になっているようです。
ここには掲載していませんが、ピッチ軸のずれとピッチ軸の姿勢の揺れが大きいです。足首と股関節のピッチ軸にはテンショナーを入れていないのですが、入れる構造を考えた方がよいかもしれません。
それにしても0.05ﾗｼﾞｱﾝは2.5degくらいです。キビシーですね。