開発日誌(30)
■３月７日■
まだまだ仕事は炎上しているのですが、この休みに出来ることがないので土日とも休み。 気持ちはすごくあせっているので精神衛生上良くないですね。
せっかくの休みなのでシグマを一気に進めました。
まずはとにかく歩くようにと言うことで、土曜日のうちに歩行のための基本的仕組みとして、各脚の基本姿勢を表す変数とは別に動作を表す変数を用いて、脚一本だけの歩行動作、 水平に動いて足を持ち上げて戻す、という一連の動作を組み込みました。
そして今日、とうとうコロンを使って逆キネでシグマが歩き始めました。 連続歩行する仕組みを組み込めてないのでまだ1歩ずつマニュアルでコマンド送る形式なのですが。
前回のシグマは脚3本がセットになって２相で動作する単純な歩容だったのですが、みんなが多脚を作り始めた今、あれでは面白くないので各脚の動作が異なる６相で動かしてみました。 これはなかなかモーションじゃマネできないでしょー。 なんとなくグリップがいいような気もします。 きっと気のせいだけど。。
今回はコントローラのアナログスティックを使って、全方位移動をさせたいのですが、歩行の方向が変わることでのモーションのつなぎ部分の補正が組み込めていないし、無線コントローラの接続がまだできていない、マイコン類がロボットに実装されていないってことで、自由に歩かせることは後回しにします。 まっすぐ動く分には移動方向のベクトルを作って与えればそちらに歩くように作ったので、まぁできたも同然だし。
それよりも旋回歩行が組み込めていない。 今回は直線＋旋回という動作じゃなくて、カーブもさせたいので、回転中心座標を指定することで色んなカーブを歩かせたいと思います。 ロボット中心に回転中心を設定すれば旋回歩行になるので、旋回動作だけを組み込むことはしません。
ミニ電動の照準用のサーボは組み込まないことにしたので、姿勢で照準を合わせることになります。 これも前回のシグマでは組み込まなかったこと。
めんどくさいなぁ～、と思ったけど、やってみればすんなりできました。計算量を減らす工夫をしていないので、まずは動作確認レベルで。 Coronの計算速度が限界に達したら絞っていくことにしましょう。
左が真正面に向いている場合、 右が体をくねらせてミニ電動の向きを変えているところ。 わかるかなー。 左の方が銃口が下を向いている感じがするけど、カメラの位置の関係でそんな風に見えています。
照準を動かしながら歩くこともできます。 いや、できるようにします。
CPUの利用率を稼ぐために、計算した動作データをストックして、割り込みからそれを読み出す形式にしてみました。1000ブロックのバッファを用意したのだけど、18個のサーボの、20ms毎のデータをストックすると1秒分しかストックできない。 どこまでバッファ広げられるのかなー。
■３月１２日■
実験室にこもって実験することは楽しいのだが、今日も帰りは11時過ぎ。
あっちゅう間に3月も半ば。 ロボでサバゲに間に合わないよー。 まだSPIインターフェイスを使えていないのでこのままだと無線操縦ができない。 最悪キーボードで操作ということになる。 それは避けたいな。 電源監視のためのADCも必要だし、残弾カウンターも実装しなきゃならないんだよな。 ロボでサバゲ、なかなか大変ですよ。
練習会がある土曜日はなんとかフリーにしました。でも、練習会に行くべきなのか家で開発すべきなのか悩むところ。 アイボで開発していたときに実装した歩行方向変更時の同期の取り方を思い出したので実装したいのだが出来てない。 それが出来ないと無線操縦で全方向移動が出来ないんだよー。 練習会に動かないロボット持っていきたくないし、、、仕方ないから練習会会場でやるか！と思ったりもするが、開発進めるならば練習会会場より自宅で黙々とやる方がいいのは確かだし。でも、、飲みにも行きたいしなぁ。 夕方から向かうには草加は遠い。。orz もやもやもや。。。
Coronの電源コネクタをJSTのネットショップで買ったのだが、コンタクトがべら高。 1個22円もする上に30個でしか売ってくれない。 2個でいいのに。。 まーしゃーねぇなぁと思ってポチっとしちゃったあと、マルツで売ってるの見つけました。 マルツだと10個単位で売ってましたよ。 ・・・送料と部品代が一緒くらいでした。(^_^;)
Gロボの無線機が5Vを欲しがっているのですが、5Vを用意するのが面倒だなー。Coronは3.3V駆動なのですが、 あれですね。小容量でいいから5V出力があると便利ですね。 欲しいです。 それか、電源電圧そのまま出す端子があればいいな。
ジョニーがテンションダウンと、、、 サッカーがんばってるなーと思ってたんだけどな。 それよりモチベーションダウンの最近例に名前あげないでよ(^_^;) 確かに方向性見失ってるところあるのですが。 いまは仕事が忙しいのが一番の障害です。 ロボットOS研究室を見学したりしてモチベーション持ち上げたのに自然放電してしまいそうです。
■３月１３日■
ロボでサバゲの開催時期を考えると一刻の猶予もない、ということで練習会に行くのは諦めて、SPIの立ち上げをやることに。 インターフェイスの立ち上げはいつも時間がかかります。 今回も丸1日かかってしまった。
SPIのサンプルソースを参考にプログラムしようとしたのだが、GPIOの設定がイマイチ理解できない。 SPIだと、今回はマスターなのでMISOは入力、MOSIは出力のはずなのだが、どちらも同じピン設定になっている？？？ 答えは、STMのSPIはマスターとスレーブを動作中に入れ替えたりできるので、入力設定出力設定はマスター・スレーブで切り替わる仕組みになっており、そのような使い方のピンがオルタネートファンクション設定ということらしい。
NSS（スレーブセレクト）という信号があって、STMにはソフトNSSというのとハードNSSと言う設定がある。 ソフトNSSというのがよくわからんのでハードNSSを選んで、NSS信号をイネーブルすればスレーブデバイスが動くように接続したのだが、動かない。。
動かないので、色々と設定を変えてみて、ソフトNSSにすれば送信は出来るようになったのだが、受信がからっきしできない。 そういや確か、RPU-10ではNSSの立下り後、150us位は空けないとダメだとか言うことがあったなぁ。 と思い出し、SEMB1200Aで動作確認。 立下り信号が必須ということがわかりました。
そしてやっと先ほどGロボ無線機からデータを取り出すことに成功しました。 10時から初めて21時。 途中、テレビ録画4本と昼飯、晩飯をはさんだので実働は5時間くらいかな。
さて、これからSPIをDMAで受信できるようにせねば。 今夜中にできるかなー。
あと、ADCを立ち上げねばならない。 ロボでサバゲにADCは必須です。
SPIをDMAで受信するのはやめました。 SPIに割り当てられているDMAチャンネルがUART1とかぶるので、のちのち足かせとなりそうだし、SPIの転送速度は少なくとも3Mbpsで動きました。 更には転送データ量がたったの8byte/20msなのでわざわざDMA転送する必要は無いでしょう。 NSSをイネーブルしてからの待ち時間だけはループを回すのがイヤだったのでタイマー割り込みにしました。 動いたあとでタイマーを詰めていったら50usでも動いたので、これも割り込み使う必要なかったかもしれないです。
データ読み取りの成功率が低いので、オシロで確認しようとして、NSSにプローブを当てたら読み取りエラーが解消します。 どうやらLVCCでVCCロジックを引っ張れないので失敗するみたいですね。 レベルシフタが必要なようです。 データ線は問題ないみたいなんですけどね。 （内部回路の関係かなー？）
STMのインターフェイス系はADCを残すのみ。 モーターのONOFF回路と残弾センサー回路もさっさと作らねば。。。
明日の仕事、早く終われば無線コントロールで全方位移動まで進めるはずだけど、、無理だろうなぁ。 あ、明日は仕事なんです。(ーー;)。。。。
■３月２５日■
気がつくとほぼ2週間ぶりの日誌更新。 仕事も大詰めに入って家にいる時間が極端に少なかったもので。。 むりやりロボワンの日は仕事休みにしたのだけど、あの日以外はずっとYRP野比の研究所に詰めてました。
いい加減にシグマの進捗がヤバイので、12時くらいに帰ってからデバッグしたりしていたのですが、やっと全方位歩行の実装ができたようです。 未だに旋回歩行を実装できてないけど。。。 (^^ゞ
明日も休みをもらって三連休、 ほかに用事もあるのだけどこの休みに頑張って進めます。
久しぶりにシグマが動くのをみました。（前とは歩き方がちょっと違うけど） 家の中だと結構きびきび動いているように見えても、広い場所で動かすと様相が変わるんですよね。 驚くほど遅く感じる。。 家の中だと暴走ってくらいの速度で動くようにしなきゃ広い場所ではきびきび動くようには見えないでしょうね。
今日の帰りに本屋によって、ふと目にとまった「インターフェース」、組み込みソフトの月刊誌だけど、「リアルタイムOSを使おう」という特集のようです。 少し立ち読みしたのだけど、どうやらターゲットのCPUでRTOSを移植して動かしてソフトを開発すると、、 OSの移植も自分でやるって話のようなんだけどその理解でよいのかな？ ペリフェラルインターフェースのドライバーはだれが作るのだろうか。。 スケジューリングなんかは便利なのだろうけどデバイスドライバーが一番の問題のような気がするのだが違うのかな？ SEMB1200AもCoronもOSなしでの開発なのだが、やっぱりOSは必要に感じます。 スケジューリングやらデバッグ環境やらはやっぱり大切ですね。
ロボワン後の打ち上げでジョニーに「ラムダの作り方」は載せないんですか？と聞かれました。 作り方を載せるほどの完成度がないので載せようがないのが真実なのだけど、わからない人に伝わるような日誌の書き方をしていないことも事実。 メインがソフト開発になってるから画像や文章にしにくいのも手伝ってなにがなんだかわからない日誌になってしまってるのも気付いてはいるんですけどね。 一応は3ヶ月後の自分が読んだ時の手がかりになるくらいの気持ちでは書いてます。
万が一疑問などあればスパム気味のBBSかメールをもらえれば反応します。
■３月２６日■
今日は休みをもらったので、朝からシグマの工作。 朝と言っても連日の睡眠不足のせいか、起きたら10時前。 普段なら休みの日は7時に目が覚めちゃうはずなのに、、やはり疲れがたまっているのか。
SPIのインターフェイスにはレベルシフタが必要のようだったので、レベルシフタ基板を作成。 ついでにその基板からRS485基板への接続と、RS485基板からの5V電源の供給を行う。
Coronの電源をバッテリー供給とするためにDCDCコンバータからの電源ケーブルを作成。 これでシグマをバッテリー動作させる手はずが整った。
CoronはUSBでのプログラム書き込みなので、書き込みは有線。 USBの延長ケーブルは持ってなかったなー。 明日買いに行かなくては。
↓ケーブルが暴れてきれいに並べられなかった。 それぞれを絶縁して、シグマのボディーに詰め込むつもり。
レベルシフタを入れたことでSPIの通信は安定して受信できるようになりました。 必要なのはNSS信号の強化だけだったのだけど、ついでだからSCK（クロック）にもレベルシフタを通しておいた。
で、オシロでSCK信号を確認すると↓
← 変換前
← 変換後
ってことで、プルアップ抵抗がでかすぎたらしい。 こんなんでもちゃんと動くんだなー。 ってか、これだとレベルシフタを入れない時の方がいいやん。 ・・・・抜いちゃおう。
では、シグマをラジコン操作できるようにするプログラムに着手します。
■３月２８日■
ラジコン操作しだすとマイコンボードやインターフェイスボードを引きずっている状態だと不意にショートしてしまったりする恐れがあるので危険です。 まずはシグマに制御ボード類を搭載するようにしましょう。
やっとここまでできた。 結局制御ボード類の実装までたどり着かなかった。 ベースど真ん中にガンが鎮座しているので、制御ボードは立てて実装しなきゃならないのだけど、簡単で丈夫な構造が思いつかない。 悩んでても仕方ない。作っちゃえ！ と思って図面引いたけど、12時過ぎてから音出す作業はできないので断念。サバゲまでの休みは次の土日しかないのだが、休めるのだろうか。
電動ガンのトリガーはうまく動きました。 手元にある部品だけで作れました。
適当に電動ガンのモーターをつないで動作確認しちゃったけど、これ（電動ガン）ってモーター逆回転させたら壊れたりするのかな。 気にしてなかった。。
進捗してるようでしてないなぁ。。(ーー;)
■３月２９日■
やっとコントローラで全方向移動ができるようになりました。 なんだか長かったなー。 まだ旋回動作ができていないのでアレですけど、まぁそれはもうできたも同然なのでよいでしょう。あと1時間もあれば旋回動作も組み込めるはずだけど明日も仕事なので次回に繰り越します。
以前のシグマの歩行と違って、６本脚すべてがずれて動作します。 より生物的になった感じがしますね。 グリップもよくなった気がする。 今回はその他に旋回動作を同時に行う（要はカーブ歩行だけど）とか姿勢を変える（これで照準を取る）ということもできるようになったのがわずかな進歩。
逆キネ計算は、整数化とかは一切行っておらずfloatで計算していますが、20msに5ステップ程度の計算ができるようです。1ステップ4ms以下ってことですね。 これはCoronの処理能力ってこともあるけど、UART通信を全部DMAに丸投げしているお陰でハードの待ち時間というのが無く、割り込みでもないのでレジスタ退避などのオーバーヘッドも無いお陰かもしれません。
つまり、もっと複雑な計算もリアルタイムに行えるということなんだけどよく考えると3自由度の脚6本分の逆キネ計算5ステップ分なのであまり余裕が無いとも言える。 （姿勢変換もあるからもうちょっと計算量多いけど）
せっかく腕をつけたけど、腕まで手が回らないな。（ってなんか変な言い回し）
■４月４日■
マイコンと、WLANカメラと電動ガンをシグマに載せて無線コントロールできるようになりました。
予定通りに全方向移動に旋回、それと姿勢を同時に制御可能です。
WLANカメラで録画した、シグマ目線の画像です。 うーん、家の中が写っちゃってるなー。 ちなみに仰角は±11degしか動かしていないので盗撮には使えません。(^_^;)
マイコン、電源ボード、カメラの本体はしっかり固定したのだけど、いくつか仮固定のモジュールがある。 両面テープで固定しているだけだと動かしているうちにポロポロ外れてくる。やっぱりちゃんと固定しないとダメか(>_<)
ADCに取り掛かれなかったので、肝心の被弾センサーが未実装。 今週できるかなー。 ADC動かさないとバッテリー監視もできないんだよなー。
今度は人間目線。 部品や工具は片付けました。(^_^;) カーペットの上だからいいけど、畳部分を歩かせると畳がむしれちゃいました。 歩きながらロボット全体の姿勢を変えてカメラ及び銃の照準を変えているのがわかるでしょうか。 カーブ歩行は、半径を指定してカーブするのではなく、直進しながら旋回しています。 全方向移動に対しても旋回できるので結構複雑な動きもできます。 慣れれば回りながらまっすぐ進むってのもできるかも。
■４月１８日■
ひさしぶりの日誌更新。 今日はロボット練習会だったのだけど、休養決め込んで家でごろごろしておりました。
先週の、大日本技研での「ロボでサバゲ」実験大会の出場も随分無理しての参加だったうえ、日曜日から仕事でてんてこ舞いの一週間だったので土日ともどもホゲホゲ～と過ごしておりました。
「ロボでサバゲ」は、被弾センサーまでなんとか動くようにしていったのですが、装弾数が電動ガンの製品から増加できていなかったのが致命的でした。参加機体では比較的よく動いた方だと思うのだけど、GONSさんの電竜（でよかったっけ）を倒すことは出来ませんでした。 かわロボベースだとちょっと強過ぎですねー。
さすがに複数機体が動いているところでは無線の問題が多発しまして、シグマではコンソールに使っていたXBeeの通信が不調でした。操作側での受信は大丈夫だったけど、操作側からの送信はなかなか受けてもらえない時がありました。 コマンド送信はコントローラで一本化して、情報はカメラに写る位置にLEDなどで表示するって方法（イガアさんがやってた）を取ればXBeeは無くせるはず。 そこ、がんばるとこかどうか微妙ですが。
準備が間に合わなかった工作部分はビニテで応急処置していったのだけど、そこをちゃんと仕上げて、ソフトももうちょっと仕上げて、装弾数増やして、あ、あとやっぱり残弾センサー欲しいな。
それより、シグマには開発当初の目標であった悪路走破のための制御を組み込みたいなー。 作ってみたら、結構走破力が無いってのがわかってしまったのだが。。 悪路走破の考察をもうちょっとキチンとやってみるか。
■４月２５日■
ずいぶんと前から ZMP歩行で、試してみたいことがあったのだが、Colonを立ち上げたり、シグマを組み立てたり、仕事が忙しかったりで試せていなかったことがあったのだが、不意にそれをやろうと思い立ち、半年振りにラムダ・マーキュリーを動かした。
シグマの動作確認やらなんやらでSEMB1200Aを使ってたので、組み立てから始まって、ラムダのプログラムを書き込んで、、 コントローラの操作とか立ち上げとかどうやるんだっけ？ 半年手付かずだったから忘れてる。(^^ゞ
歩行はいいとして、モーションの割付とか困るなぁと思い、モーションに名前をつけてキー割付をヘルプコマンドで見れるようにしないとだめだなぁと思い立つ。
フルカスタムだとこういうのも自分で作らないといけないからめんどくさい。 また、作るたびにちょっと変えて作るから前に作ったのが使えなかったりして。。
ラムダのモーション作成は、無線コントローラで編集できるようにしています。 その方がコンパクトだし、Windowsプログラムは何かとめんどうだし。 さすがにコントローラでモーション名は入れられないのでそこはコンソールで。
フラッシュの領域にモーション名を入れる領域が足りなかったので、今のモーションを読み出して、ずらして書き込めるようにして、そのあとにずらしたモーションファイルを読み出せるようにして、、というふうな作業を経て、モーションに名前をつけて、ヘルプコマンドでキー割り当てを表示できるようにしました。
でも、、キー割り当てがハードコーディングになってて編集不可能になってます。 これも編集できるようにしなきゃな。
とかやってるうちに今日が終わってしまいました。 ZMPで試したいことは次の機会に持ち越しです。
■４月２９日■
先日の仕事が大失敗に終り、大変なところが更に敷居が上がってしまい、仕事のプレッシャーに押しつぶされそうです。
そして、当然のことながら今日も仕事だったのですが、半ば逃走のごとく早く帰ってきたものだから、精神状態が落ち着くのを待ってラムダの続きをやることに。
モーションに名前をつけるところまで出来たので、今度はモーションの割り当てを編集できるように、、と言うところからだったのだが、 さて、軽くやっちまおうと思ったところ、あれ？？あれれ？？ もう出来てる。。。。(^_^;) どうやら仕事で数日家を空けている間に小人たちがコーディングしてくれていたようです。
ってこたーないので、どうも半年前にちゃんとモーション割り当てを編集できるようにしてあったみたいです。 覚えてないや。。(ーー;) （これ書きながら段々思い出してきた。。）
せっかくだからモーション名を表示できるように拡張して今日の作業は終り。 全然進まないな。
■５月１日■
昨日の失敗とは別件で、客先でレビュー。 信じられないことが起こり、お客さんが大激怒！！ 大阪に拉致されて、最終の新幹線で帰れず、大阪に一泊。 お陰で友人と飲みに行けたけど、またまた大変な状態なのに更に課題が増えることに。 この泥沼状態はいつまで続くのでしょうか。
ロボットビルダー御用達のCASIO FX-150を買ったので、ラムダの歩行を撮影。 ロール軸の補正がまったく足りていないことがわかりました。
ピッチ軸はリンク脚にしていて、２軸で動かしているので、剛性が高いし、ガタも少ないのだが、ロール軸はシングルなのでガタもあれば剛性もいまいち。負荷に対する補正値パラメータがどちらも同じではいけなかったようだ。
そして、先日に続いてフラッシュメモリーにセーブするデータを拡大して、補正パラメータをダブルリンク用とシングル用のそれぞれのCW、CCW 合計4種類に増やしてみた。
すり足は軽減したのだが、根本的な解決にはならないらしい。 両足支持になったり、支持脚が切り替わった瞬間に負荷が軽くなり、補正値も不要になる。 そのキックバックで歩行が不安定になるケースが発生する。
いままでは前進歩行はすり足気味で、後進歩行はちょっとすり足傾向が軽かった。 補正パラメータを分けて、シングル軸に対する補正を大きくしたら、後進歩行の際にキックバックが起こり、こけてしまう。 旋回も不安定になる。 なかなか難しい。。
やはり、機械的に剛性を上げる必要があるな。 リンク構造にすべきなのはピッチ軸ではなくて、ロール軸なのかも。 （モンスター型にすればいいのかな？ やだけど(^^ゞ
■５月７日■
２日は出勤、３日は買い物に出かけ、４日５日は風邪引いて臥せっておりました。ＧＷってなんですかぁ？ って感じですが(^_^;)
ロール軸をダブルにする構造を検討中。 元々実験機体であるラムダ・マーキュリー。 実験機体らしく、できるだけ今の構造のままロール軸をダブルにしたいと思います。 ですのでかっこ悪いのは承知の上で機能確認優先ってことでさっさと構造設計して板金発注してしまいましょう。
これで計算歩行の再生精度があがればしめたものなのですが。。
ロール軸シングルのままで負荷補正だけでうまくいかないのはトルクのせいか、ガタ付きのせいか。。。 感覚的ではあるが、計算歩行を行うための関節再生精度の向上をはばんでいるのはやっぱりガタ付きの影響が大きいように感じます。 オフセットと考えられればいいのだけど、フェーズが変わると途端に極性が変わる。 バネなどを使ってキャンセルしようとすれば可動域（というか直線域？）が狭まります。 いや、バネもモデル化して計算に加えればいいのかな。
いやまてよ。トルク不足のせいで補正量が大きくなり、負荷変動での補正量変動にサーボが追随できないでオーバーシュートしてしまうってのが今の現象にマッチしているのかな。 すると今はトルク不足の方が支配的かも。
いずれにせよダブルにすればどちらの要素も解決してしまうので切り分けはできないな。
しかし、、、関節を全部ダブルにすると、もう、伸筋－縮筋がセットになった筋肉構造と同じになってしまう。ちょっと冗長過ぎるよなぁ(>_<)
なにか妙案はないものか。
■５月８日■
股関節ロール軸をダブルに。マーキュリーの部品を出来る限りそのまま使うようにしました。 でも、KRS-4014が売ってないみたいなので、4013のギアを入れ替えて4014にするってことで実験してみます。 ただ、、来週は仕事が山場だからなぁ。 できるとしたら練習会明けの日曜日か。。
■５月９日■
股関節ロールのダブル化に関する部品は発注完了で、部品が揃うまでやることがなくなってしまった。 板金はアミエさんにお願いしたのだけど、混んでるらしくて今週中は無理みたい。 練習会には間に合わないの確定です。
ではその間に違うこと、、 ってのがなかなか出来ないタチで、どうしたものかな。 ラムダつながりと言うことで足裏センサーについて検討してみることに。
足裏の４隅に感圧センサーをつけて、ZMPを測定し、歩行へフィードバックをかける、 というのをやりたいのだが、感圧センサーをどうしようか。 ニッタのフレキシフォースボタンセンサーってのを使ってみたいのだけど、片足分で１万円。 オペアンプ回路でドライブする必要があるので立ち上げが面倒そうだし、 実はまだアナログデータは要らないなぁと思っているのでこれは見送り。 ・・・一つ買ってテスト回路組んでみようかな。
ZMP歩行でのセンサーフィードバック事始めなので、簡単なセンサーデータから始めたいと思います。 フィードバック手法が、通常のクローズドループで、フィードバック時間が短いというのでは無いわけだし。
ということで、今回は足裏の４隅にスイッチをつけて、時間軸でスイッチの状態を取得することにします。
8ビットデータなので、GPIO4本で読み取るか、DA変換回路（ラダー回路）を組んでアナログ1ポートで読み取るか。SEMBにはアナログポートがついてないのでお手軽なのはGPIOだけど、今後のこと考えてアナログセンサーボードを搭載しようかな。
■５月１６日■
昨日は練習会。 今回の練習会は武蔵溝ノ口ということで電車で10分のところです。 やっぱり近いと楽ですねー。
アミエさんにお願いした股関節ロール軸のダブル化部品ですが、アミエさんが融通を利かせてくれて金曜日に受け取ることができました。（ありがとうございます。アミエ殿 クボさん (^^ゞ ）
金曜日はどうやら早く帰れそうな雰囲気だったので7時くらいには仕事を切り上げて帰宅。 改造組み立てを開始しました。 音が出る作業があるので金曜日中には組み立ては完了しませんでした。 土曜日の朝から作業再開。 ２時半くらいにやっと組み立てが完了。 配線とかソフトの変更は練習会会場でやることにしました。
股関節ロール軸をダブルにしたラムダマーキュリー 軸間とか直交とかは前のままなので逆キネ関数などはそのまま使えます。 変わるところは、質点データが変わるのと、負荷配分をプログラムに組み込まないといけないって部分です。
練習会会場で配線して、動かしてみたところ、質点データ変更しないでも普通に歩けました。ですが、追加したサーボにはトルクを入れていないので、ガタ付き防止のダンパーになっちゃってます。 つまり、ダンパーを組み込むことで（トルクはムダになるけど）場合によっては動作安定化の対策になりそだというです。
日曜日はだらだらと過ごしたので質点データの更新しかできなかった。 来週辺りからちょっとだけ時間が取れるようになるはずなのでウィークデーの作業に期待。
■５月３０日■
いやぁ～、 股関節ロールダブルのインプリ。 意外にも苦難の道でした。
股関節ロール軸をダブルにしたことをどのようにプログラムに反映するか散々悩んだ末、一番めんどくさいけど一番キチンとした書き方をすることにしました。 逆キネ関数も関節列の行列（リスト）もサーボ数に合わせて変更しました。 この際だからということで、今までサーボIDと逆キネ上の関節番号を一致させていたのだけど、これらを個別に管理するようにしました。
すると、、、例外らしきエラーが出てプログラムが動かなくなりました。(^^ゞ
「らしき」 というのは、SEMBのコンソールをXBEEでつなぐためにボーレートを下げているためEXCEPTIONメッセージが文字化けしてしまって読めないのです。
ほぼ間違いなくサーボ数を増やしたことによる変更を書き漏らしているのだろうと思ってデバッグを進めていたのだけどさっぱり判りません。 デバッグ用の、PCで動かすプログラムだとちゃんと動き出したので残るはメモリーアロケーションなどのシステム関連の問題か？ と、思ってみたが、怪しい変数をアクセスしても例外を起こしたりしない。
こういうのって集中的にやらないとなかなか進まないのだけど、いま仕事が忙しくてこのデバッグに集中できない。 この土日に集中してデバッグしてしまうぞ！と意気込んで金曜日に帰ってきたら、、なんとPCの挙動がおかしくなりはじめました。
何かにアクセスすると、考え込んで返ってこない。 初めはリアルプレイヤーを起動したときだけだったのにとうとうマイドキュメントフォルダーを開くだけで固まってしまうようになりました。
困ったなぁ、そろそろPC買い替え時かな？ とか考えていたが、再インストールもPCの買い替えも環境構築を考えるとやりたくない。 とりあえずチェックディスクをかけて様子を見ることに。 チェックディスクをスタートしたのが土曜日のたしか20時くらいで、終わったのが日曜日の18時くらいでした。 色々メッセージを出していたので、なんか事故が起こっていたらしいです。で、なんとか今、PCは使えているようなのでひとまずは直ったのかな？ 危なかった。。 再発せねばよいが。
そして、デバッグ再開。
PCではちゃんと動くのにSEMBでは動かない。 SEMBで動かすと補正値がとんでもなくデカイ数値になってしまうようだ。 （メモリーの不正アクセスではないらしい。） それも指数関数で大きくなってしまい、最後にはNaNになってしまっているらしい。
ソースを眺めてもおかしなところは見つからないので、おかしな値になりはじめるのはどこなのか、、順を追って値をモニターしていくと、、関節負荷計算の、支持脚の計算部分でおかしくなるらしいことを突き止めた。
ここを集中的に洗いなおすと、質点座標の変数が設定されずにループが始まる部分を見つけた。 でも、これが設定されなくても指数関数的に大きくなったりしないよなぁ～。 と思いつつ、ちゃんと設定すると、ちゃんと動き出しました。
この変数、ローカル変数なのですが、無設定だと値は不定です。 でも、いままでも設定されてなくてもおかしな動作はしていなかったのに、関節角度列のサイズを変更したことでメモリーアロケーションが変わったのか、指数関数的に大きな値を取るようになったようです。 コンパイラについてはよく知らないのですが、ローカル変数だからといって宣言されたところでメモリーが確保されるのではなく、あらかじめアサインされているのかもしれないと思っていたのですが、ちゃんと宣言されるたびにアサインされるようです。
ちゃんと動くからと言ってバグが無いわけじゃないのは理解しているつもりなんだけど、変更したところと関係ないところでバグが顕在化すると原因見つけるのに苦労します。動作からおかしな場所を類推しようとするのも時と場合によるようです。
これ以外にも結構たくさんバグを見つけて修正しました。たまには完成したと思ったプログラムも眺めてみる必要があるみたいです。
ちなみに、いまんとこ補正をかけてもかけなくても歩行の様子に変化はありません。 関節がシングルの時は見るからに補正が必要な感じだったけどダブルにしたあとの関節負荷値を見る限りは股関節ロールには補正はほとんど必要ではないようです。 動かして見た感じでも遊脚が円弧を描いて動く （実際には支持脚の股関節が荷重に負けていたのだけど） のはなくなりました。
やっと本題の作業に進めそうです。 疲れた～(ーー;)
■５月３１日■
やっと歩行テスト。
まずはトリム調整。 ダブルの締め代は考えず、それぞれのサーボをニュートラル位置でトリム調整しました。
MDFボード上で歩かせてみると、いままでよりはスリップが減りました。 いい傾向です。 これならばずいぶんと路面を選ばずに歩けるようになったかもしれません。
ということでカーペットの上を歩かせてみました。
カーペットの目の方向によってはこけてしまうので、完全制覇ではないですが、いままではさっぱり歩けなかったカーペットをまっすぐ歩けてるから大進歩でしょう。
実はボードの上だとまっすぐ歩けないんですけどね。 もうちょっと色々試してみます。
■６月２日■
カーペットの上での歩行は結構な確率で失敗します。 更には、ボードの上での歩行だと、関節が硬くなった副作用として跳ねてしまうようになりました。
跳ねたせいで荷重の移動が安定せず、まっすぐに歩けない原因になっているようです。 カーペットの上だと、カーペットが衝撃を吸収する事になり、結果的に荷重の移動が安定してまっすぐ歩けるのではないかと思います。
そこで、足裏に衝撃吸収ゲルシートを貼り付けてみることにしました。 接地はゲルシートというわけにはいかないのでアルミプレートです。
結果は、ボード上でもまっすぐに歩けるようになりました。 足裏が少し大きくなってしまったので旋回の時に支持脚と遊脚がぶつかってしまうため、脚幅を少しだけ大きくする必要がありました。
これでカーペット上での歩行も随分と安定するようになりました。 なぜか後退だけはつまずいてしまい、横に転んでしまいますが。
ボード上の歩行の際、まだ少しスリップしています。足裏をグリップさせると恐らくはちゃんと歩けないような気がします。 まだまだ再生精度が低いのかとも思いますが、どうしたって計算どおりには動けないだろうし、そのために接地衝撃というのは必ず発生するでしょう。 この接地衝撃をスリップで逃がしてやることで歩けていると思います。
ならば、グリップ歩行にするには接地衝撃をスリップ以外で逃がしてやる機構を持たせる必要があるということになります。 今回のゲルシートもその一案だったのですが、まだ足りないようです。
さて次は足裏センサーだ。 やっとフィードバック系に入れそうです。
■６月３日■
４隅にスイッチを配置した足を作製。 このスイッチの上にアルミプレートを貼り付ける。
スイッチは押下力が小さくてストロークが小さいものを探したつもりなのだが、恐らくは耐久力が無いのですぐ壊れちゃうんじゃないかと思われる。
シュミットトリガー入れて、GPIOで読み取ればいいかなー程度に考えている。 読み取り周期がサーボの制御周期と同じ25msになってしまうのが残念。
・・・ てか、まずはこの足でまともに歩けるかどうかが問題。 少ないとはいえストロークがあるので、荷重が抜けた途端に良くないことが起こりそうな予感がする。
■６月６日■
足裏センサーを組み立てて歩かせてみたところ、快調です。スイッチのストロークがクッションの役割になるのか、バスタブソールの時よりもいい感じです。 ただし、足裏の固定が甘いので、自分の足を踏んじゃうと足裏が外れてしまいます。
そこで次の段階として、足裏センサーの回路組み。
デコーダーでスイッチを選んで、スイッチの開閉を読み取ります。切り替えてから読み取るのでチャタリング防止回路が役に立たないので、バッファのつもりでインバータを一つ入れるだけで読み取ります。
まずは片足を完成させてテスト。。 うむむ。 電圧が下がりきらない。 逆流防止用のダイオードをスイッチについてたLEDで代用したのがダメか。LEDって普通のダイオードの代わりにはならないんすかね。
続きは後日。 今週は仕事が山場なのでロボ作業ができるかどうか不明。 練習会も行けるかどうか微妙だ。 ついでにわんだほー出場も。(>_<)
■６月１２日■
やっと足裏センサーができました。 GPIOを節約するために、デコーダーでスキャンするようにしました。 手元にあった2ビットデコーダー74HC139を使ったのですが、負論理でキーマトリクスって組めないんですね。 できそうな気がするんだけどな。 諦めてインバータ入れて正論理にしました。
まだSEMB側の配線が出来ていないので完成していないのだけど、今夜はもう疲れてしまった。
①今夜がんばって完成させて、明日の練習会に行く。
②明日朝からSEMB側を配線して、完成してから練習会に行く。
③諦めてラムダをおいて練習会に行く。
④練習会に行くのを諦めて、ゆっくりと明日配線とプログラムを組む。
①はくじけそうな気がする。 ②は、結局④になっちゃうような気がする。 ③ならばシグマ持っていくのかな？
明日早起きして②で頑張るか～。
■６月１５日■
練習会は②で頑張って、配線だけ終わらせてから急いで準備。 ラムダとシグマを積んで車で行こうかとも思いましたが、うちの車にはナビがないので下調べせずには目的地に到着しそうにないので取りやめ。 ラムダだけ荷物に詰めて出発しました。
秋葉原で買い物をしたかったので、日比谷線の入り口付近のコインロッカーに荷物を預けて買い物。 ところが、目的のお店が軒並み休みで、買おうと思っていた部品はほとんど買えませんでした。 がっかり。。。
練習会場に行くと、ものすごい人口密度。 ま、真ん中に蚊帳張ってるせいもあるんですけどね。 多脚を動かしているのをみたら、シグマ持ってくるんだったなーと少し思ったり。
でも、足裏センサーを肴に歩行のフィードバック制御について吉田さん、イガアさん、えまのんさんと技術系談義。 色々と参考になりました。 メモってないので半分くらい蒸発してしまったかも。(^^ゞ
配線を終わらせたつもりだった足裏センサーは、電源電圧を間違えて3.3Vを配線してしまったらしく、SEMBから動作を確認することができませんでした。 さっきやっと配線を修正しました。 早くセンサーで足裏の動きを確認したいところだけどプログラム作って動かせるのはもう少し先になりそうです。 ちょっと時間が取れなくて。。
足裏センサーを取り付けた状態で、練習会場で歩かせて見たところ、なんだか家で動かした時よりも跳ねます。 試しに補正をはずしてみたら跳ねが収まりました。 なんだかなー。
■６月２０日■
パソコンがヤバイ状態です。
なんかのアップデートに失敗したのをきっかけにまたおかしくなってきました。 立ち上げて、まともに使えるようになるまでに30分以上かかる。。。
そんななので、なんかやるテンションが全然上がらない。 再インストールとかやれば少しは改善しそうな感じだけど、もうそろそろって頃なので新しいPCを買うことに。
ロボット開発をやる前はPC事情にも詳しかったのだけど、最近のPC事情にはさっぱり疎くてどんなPC買えばいいのかさっぱりわからん。 持ち運び考えて小さめのPCにしようかと思ったけど、そうなるとあんまりパワーがなさそうな構成しかない割りに高くなっちゃう。
結局、悩んだ末に今のと同じくらいのサイズのPCになりました。 届いたら環境設定をしなくちゃならないんだよな。 これがまためんどくさくてヤなんだよ。
ロボットぜんぜん進展なしです。(ーー;)
■６月２７日■
仕事が全然ヒマになりません。
先週もイベント盛りだくさんな上、マッチポンプ的な仕事で大騒ぎになり、土曜日の２３時ごろ工場から帰って来れました。 そして今週もイベントたくさんです。(ーー;)
この先の予定も立たないので今回のわんだほーも見送りです。 思えば去年のわんだほーにラムダで出場し、自慢の計算歩行(^_^;)がへろへろだったのがきっかけでマーキュリー脚にしたりZMP軌範の計算歩行プログラムを作ったりしたのだった。
仕事が忙しいとか何とか言ってるが、去年の11月ごろマーキュリー脚での計算歩行が出来た段階で、カメラを積んで画像処理との連携に着手しておけば、自律でダッシュ2000のリベンジくらいは出来たのだろう。 コロンに手を出してシグマを動かそうとしなかったらいまごろは。。 なんて言ったりしても、そのときにモチベーション無かったから仕方ないっすね。
コロンが動いてからもロール軸をダブルにしたり、足裏センサー作ったりしてたし。 自律でダッシュ2000がメインストリートだとしたら脇道にそれすぎだな。(^^ゞ
足裏センサーのデータバッファの組み込み。 足裏センサーのデータは8ビットデータ。 さすがにリストにしたら無駄にデータがでかくなるだけなのでリングバッファにしました。 今後リングバッファを使うかどうかはわからんけど、色んなフレームサイズのデータが扱えるリングバッファクラスを作ったりしてました。 C++ならテンブレート機能があるからそこんとこは簡単なのだが。 それ以前にSTLがあるからリストなぞ宣言するだけで使える。 C++使いたいなぁ。
オシリから伸びるシリコンチューブ2本。 カテーテルではありません。 最終的には足のフレーム内に組み込む予定。
■６月２８日■
1ms単位のデータを取りたかったですが、うまくいかなかったのでまずは20ms単位のデータ。
グラフで15というのが完全に足が浮いている状態を示します。 それ以外は足裏のどこかしらのセンサーがONになっているということ。
初めの1歩以外は接地（0)の時間がほとんどないので、どちらかに傾いているんですね。
右足の初めの1歩を追いかけてみると、まず、内側だけ接地(6)状態となり、それから完全に足が浮く(0)。 外側から接地(9)して、接地に到るのだけど、もうバウンドしてますね。
最後の1歩を歩きおえて両足が揃ってからは左右にぐらぐら揺れている様子がわかります。（わからんかな。(^^ゞ ） 足上げタイミングの理想値を一緒に描かなければわからんですね。
前のめり(12）や、後のめり(3)が余り無いので前後のバランスは良いみたい。 左右に振れちゃってるようです。
って感じの分析がプログラムでされなければならないわけだけど、結構タフですなーこれは。。 計算上、接地していなければならないタイミングでどちらに傾いているかを判別すればよいのかな。
■７月３日■
数字のままだと状態がわからないので、出力方法を変えてみた。
スイッチのONOFF状態を前後方向と左右方向のZMPのズレに置き換えて表示してみました。 赤丸がONのセンサーです。 ※実際のZMPとは異なるので注意。
左右の＋側がロボットの外側になります。 つまり、下の図は右足の場合を示す。 左足は左右が反転します。
足が完全に浮いているときは前後左右とも（３，３）という値を取ることとしました。 また、Aとか5とかの基本的にはありえない状態の組み合わせは0として処理します。
まず、MDFボード上（スリップしやすい床）でのデータ ↓ 先日のデータと違って、歩き初めでおかしな振動が無いようにしました。 上側が右足、下側が左足です。
続いて、 カーペット床（スリップしにくい）でのデータ。
やはり、スリップが有るほうが衝撃が逃げるようで、MDFボード上の歩行データの方がココロモチおとなしいです。
どちらにしても足裏が完全に接地している時間ってほとんどないですねぇ。 このガチャついたデータでパラメータ修正の方向性を判断するのはなかなか難しいです。
■７月４日■
ZMPの調整をすれば足裏センサーの取得データが変化するのかを確認するために色々実験。
足の運びを同じにして、目標ZMPだけを変化させるのはちょっと作り込みが必要なので、まずはスタンスを変えてセンサーデータの結果が変化するかどうかを確認したのだが、さっぱり変化しない。 これじゃフィードバックかけられないよなぁ。
いや、ちょっとだけ外側接地時間が短くなってるか？ それより補正による変化がないなぁ。 どちらもMDFボード上での歩行です。
そういや、ホントに外側から接地しているのかどうかをスロー撮影で確認すると、、ふむ、確かに外から接地しているっぽいな。 というか、右足遊脚時は左足に重心が移りきっていないように見える。 これを調整するってことかー。 遊脚が外側から接地する場合は支持脚の目標ZMPを少し外側にする、 でいいのかなー。
スローで撮ってみて、やっぱり股関節ロールの再生精度にまだ問題を感じたので再生精度のチェック。
右足の股関節ロール軸。 支持脚になってる時にオーバーシュートしてます。 やっぱり補正効いてないなぁ。
そんなこんなで色々模索していたのだけど、どうもサーボ通信によるデータ取得がノイジー。 上のグラフもエラーデータを補正している状態。
で、SEMB1200Aのオプションボードであるレベル変換基板を使うと、驚くほどエラーが無い。 そっかー、エラーがあったのは俺の配線した基板のせいなのね。 パスコンいっぱい入れてみよう。(^^ゞ
関節の再生精度がまだまだ補正の余地があるということで、関節角度列からZMPを計算してみて、足裏センサーの結果と照合してみようかと思ったのだけど、それはちょっと違うなと。
多質点モデルからのZMP計算は足裏がちゃんと接地していることを前提としているので、足裏がどこかしら浮いている今の状態では関節角度からは正しい計算は導出できない。
足裏センサーの結果から直接フィードバックするのではなく、まずは足裏がきちんと接地するようにする。 その後ZMPにフィードバックしていくって感じかなぁ。
■７月１１日■
今日はわんだほーの日。
しかし、仕事で火がついてしまい、土日とも出勤。 仕事が終わったあと、打ち上げだけでも参加しようと思って参加しているはずの人々に片っ端から電話したのだが、だれもつながらない。 やっとちくわさんと電話がつながったのだが、これから打ち上げ会場に向かっても間に合わなさそうだったので、打ち上げ参加もあきらめました。 とほほ。。。
出場できるできないのレベルじゃなく祭りに参加できず。。
注文していたPCが届いた。 注文して２週間。 春モデルを注文したのだが、届いた時には夏モデルが発売になってた。(ーー;)
仕事がそんななので、届いたPCのセッティングもままならない状態です。 やっとHPの更新ができるよういビルダーのインストールが完了しました。
プログラムを続行するにはCygwin入れてクロス環境を構築せねばならない。 前回、必要なツールの見極めをサボってCygwinをフルインストールしたのだが、今回はぜひとも必要なパッケージだけインストールしたい。。。。 けど、フル入れちゃった方が色々早いかなぁ。
■７月１７日■
すっかり週一更新になってしまった。
仕事から帰ってコツコツとSEMB1200Aのクロス環境を構築（と言ってもmakeするだけですけど）していました。
先ほどやっとSEMB用ライブラリのインストールが終わって、ラムダのプログラムをコンパイルしてみました。 一応動いているみたいだけど、無線コントローラを受け付けない。 CSIの関数が変わったのかな？
でも、今日はここまで。 明日はまた出勤です。 ここんとこ全然休んでないなぁ。
■７月１８日■
会社からの帰り道でカブトムシを捕獲。
ひとしきり懐かしんだ後、逃がしてきました。
逃がす道すがらマンションの通路にいたゴキブリ3匹退治しました。 同じ昆虫なのに扱いが違い過ぎる。。。。(^_^;)
明日は久しぶりの休みです。 呼び出しがかからなければ、、、ですけど。
■７月２０日■
日曜日月曜日は休めたので、CSIの不具合やらサーボのキャプチャーの読み取りエラー対策やらをやっておりました。 月曜日はロボでサバゲの日だったのだけど、家から出られなかったなぁ～(^_^;)
まず、CSIはなんだかわからんがおかしかったのが直ったようで、Coronで読み取ったフォーマットと同じになっていました。SISOさんのブログにあった情報と一致したので、今までがおかしかったらしい。タイミングの問題かな？
そしてキャプチャーエラーの方だが、SEMBのオプションボードならエラーがほとんどないってことで、自分で配線したバススイッチ部分に問題があるらしい。 ただレベル変換機能付きのバススイッチをかましているだけなので、ノイズかな？ってことで、電源供給部分にパスコンを追加。 A電源・B電源があるので双方に追加。
ついでにコネクタを1.25mmピッチのモノに交換し、被覆が溶けちゃうアースラインを増強しました。 いままではハーフピッチのユニバーサル基板に1.5mmピッチのコネクタを無理やり取り付けていたのだが、1.25mmピッチのコネクタを見つけたので♪(~_~)
配線もきれいになったので、「これでエラーフリーだぞ～」と自信満々でキャプチャーしたところ、対策前とまったく変わらない。 がっくり。
今日、会社に行って同僚に話したところ、ロード側のプルアップ抵抗が怪しいですねー、LOWに下がりきってないんじゃないですか？ ってことなのでオシロで見てみることに。
左側が、SEMB1200Aからのコマンドで、右側がサーボからの応答。下がりきってないけど、0.5V切ってるから大丈夫なのでは？と思ってSEMBのオプションボードで同じように見てみると。
きれいにほぼ0Vまで下がってる。これかぁ～。SEMBのオプションボードはロード側にプルアップ抵抗がないからなんでかなぁと思っていたのですが、サーボ側にプルアップ抵抗があるのかな？もしプルアップしているならパラでつなぐとLOWに引っ張れる個数は限られてしまいますね。抵抗値がでかいのかな？
ちなみに下がりきらないのが負荷のせいかということでサーボ3個だったところを1個にしてみても下がりきらないことには変わりませんでした。
コマンド部ではちゃんとLOWに下がっているので引っ張りきれていないのはサーボのドライブ能力のためか。バスファイトで壊れるのを避けるためにオープンにして、パラ接続を考えてでかい抵抗でつっているとすると、、こちら側のプルアップ抵抗は要らないですね。
ロード側のプルアップ抵抗取っちゃうか。。。。。。 めんどくさいなぁ～(ーー;)
■７月２１日■
出張から比較的早く帰れたのだけど、一杯飲んでたので酔いが醒めてから作業開始。
ロード側のプルアップ抵抗を取りました。 バススイッチのICはSSOPなので作業は難航を極めたのだけどなんとか完了。 テストなので８回線あるうちの1回線だけから抵抗を削除しました。
まず、波形は。
オプションボードほどじゃないけど十分にレベルが下がってます。 では！ということでキャプチャーしてみました。
上がプルアップ抵抗を取っていない回線でキャプチャーしたもの。（左足） 下がプルアップ抵抗を取った回線でキャプチャーしたもの。（右足）
効果ありそうです。 んじゃー、次の休みにでも全回線に改造を適用です。
■７月２５日■
プルアップ抵抗全部取りました。 こないだはずいぶんと苦労したのに、全部外すのは思いのほかあっさりと作業できました。 そして、キャプチャーは概ね良好。 でも、たまーに失敗するのでプログラムでのエラーキャンセルは結局はしなきゃなさそうです。
キャプチャーがちゃんとできたので、補正の見直しを。 ダブルにしている関節の補正を相互に逆に入れていたりしてたバグを発見してびっくりしたけど、考えると剛性が上がっていいかもしれない。
もともと、補正できてないやーん！ と言っていた股関節ロール軸だけど、よく見るとスケールが違っていたので大きく見えていたことに気づきました。
上が股関節ロール。 下が大腿ピッチ。 どちらも補正なしです。グラフ中でc*-t*というのはキャプチャーとターゲットの差を5倍にして表示しています。 u*ってのは関節負荷値を適当なスケールにして表示。
指示値と実値の差が、関節負荷の影響を受けているのはわかるけど、関節の移動速度にも影響受けてますね。 早く動くとついて行けてません。こっちの方がずれが大きかったりして。
ずれの大きさだけ見ると股関節ロールのずれは小さいのだけど、なにせ股関節なわけだから影響が大きいのです。 やっぱり補正値の算出関数の見直しは必要そうです。 ずれは関節負荷の影響を受けると言っても、反応には遅れがあるようなので、補正値計算も遅れを配慮した方がいいかもしれないな。
あと、前からやってみようと思っていた、キャプチャーした関節角度からZMPの逆算をやってみましょう。 関節角度のずれがどの程度のZMPのずれになるのか。 まー、スリップや傾きが配慮できないので目安計算でしかないのですが。
■７月２５日■
関節角度列からZMPを計算するのは結構めんどくさいことに気づきました。 とりあえず、いままで要りそうで要らなかった順運動学計算関数（順キネ）。 ま、これは簡単なのでさくさくっと作れますが。
で、キャプチャーした関節角度列から順キネで目標値と比較してみると、
左右。 Cって入ってるのがキャプチャーです。 股関節の角度だとわずかなオーバーシュートも、足先では5ミリも誤差がある。
前後。 これも似たようなもの。 歩幅は70ミリなのに両足支持期間がほんの少しあるだけで前後振幅は100ミリくらいある。 そして、なんだかわからんが左足の再生誤差がずいぶんと大きい。 なんだろなーこれは。
上下。 やっぱり左足が変だ。 確かに歩いてるの見てても片側に偏ってる感じはある。 どっかのねじがゆるんでるのかな？
関節角度からのZMP計算ができたら、足首関節のならい制御に再挑戦して、足裏を接地するようにしてZMPフィードバックをしようかと考えていたのだけど、もしかしたらそれじゃだめなのかもしれないなーと思えてきました。
踏ん張りもサポートせねばならんかと。
色々試行錯誤を繰り返した結果、Y方向の大きなずれはなくなりました。 支持脚となっているときは２～３ミリは沈み込んでいるようです。
まず、股関節ロールをダブル化したときに作ったリンク部品に軸方向の余裕が有ったためベアリングが外れてガタ付きがあるのを発見したのでそれを直し、 続いてトリムを再調整。
すると、なぜかおかしくなかった右足までおかしなデータを吐くようになってしまった。
とにかく、Y軸方向（前後方向）には重心補正のために10ミリほどオフセットがあるのだが、見た目にもきちんと10ミリほどのオフセットがある。 それなのに関節角度から計算するとオフセットがほぼ0ミリだというのだから納得がいかない。
色々と疑っては確認する中で、しゃがみこむとサーボの指示値と実値のずれが大きくなることを発見。 リンクを固定している軸をはずしてみると全然穴位置が合わない。 なんだこれはー！！ 右足はあんまり問題ないけど、左足はどうしようもないほどずれている。
何かがおかしい、としげしげと眺めていて思い出した。
左足の大腿に使っているサーボは、このサーボを買って色々と設定している時に操作を誤って違うサーボの固有値を書きこんでしまったやつだった。 やっぱりあの固有値が変わるとまずかったらしい。
よく調べると、たとえば90degとなる値を設定しても90degにならない。
なんとなく大丈夫そうだから、と思ってそのまま使っていたのだがとんでもないことだった。(^^ゞ
仕方がないのでこの固有パラメータの調整に挑戦。
まず、固有パラメータは、16byte。 上位4ビットは常に０らしい。 そして、たぶん4桁がひとつのデータらしい。
09000000 09000000 09000000 09000000 ←こんな感じ。
4byteずつの4パラメータと判断して間違いあるまい。 多分第一ブロックから第四ブロックまでで全角度をカバーする補正値になっているらしいのでその前提で調整。 それっぽく調整できました。
さて、これでうまくいくだろうと思ったら、調整前とほとんど変わらない。 確かにずれが大きくなるのはしゃがみこんだ状態なわけだから歩いているときはそれほど影響ないよなー。 ただし右足と左足での違いはなくなった。
まぁ、左右が同じになったのでよしとしよう。 それより、固有パラメータがおかしいと気づいた段階で、適当な固有値をほりこんだらずれがきれいに消えたことがあったのだ。 それを再現すればうまくいくかもしれない！
それは、 大腿リンクの、角度が再現できている方のサーボに大き目のトリム値を設定して、リンクをちょっと絞めるということだ。
上のグラフは、左右ともサーボの角度パラメータで60ポイントほどトリム値をずらした場合のキャプチャー結果なのでした。 関節角度ごとのずれ具合はどうかというと、
縮小しちゃってるからアレだけど、まぁ問題なさそう。 これでよしとすべきかどうかは別として、関節負荷と角度ずれが相関するようになっているのでまぁまぁ。。。。 ここまでが土曜日の夜の状況。
そんなこんなで朝方までサーボと格闘していたもんで、夕方くらいに練習会に参加。
足裏がうまく着地しないことをどうやってフォローするかを考えていたのだけど、弟子を連れて練習会に参加していたGIYさんの、あの地面に吸い付いているかのような重心移動の極意を聞いてみる。 あれは膝のクッションを使っているそうで、姿勢が崩れないように足首・膝・股関節とストレッチ設定を調整しているのだそうだ。 重心がきちんと乗っていないとあんなに安定して踊れないよなぁ～。
すると～、ストレッチを使わなきゃならないわけかぁ。 計算歩行で再生精度を上げようとするのとストレッチでクッション働かせようとするのは相容れないなぁ。ストレッチ設定値と関節負荷値の相関とれればよいのだが。