過去の開発日誌1へ
過去の開発日誌2へ
過去の開発日誌3へ
過去の開発日誌4へ
過去の開発日誌5へ
■４月１日■
４月ということで日誌も新しいページにしました。
これからゴールデンウィークまでの間は色々と忙しくなるのでロボットゴトができるか心配だけど、なんとか頑張っていく所存です。
歩幅変更のコーディングがなんとかできて、一応動き出した。 一応というのも歩幅をどんどんと変えていくと思い通りの動きをしなくなる部分があるのでまだ考慮漏れがあるらしいから、というのと、今はまだ歩幅変更に２歩～３歩（歩幅変更開始から２歩）になっていて、１．？歩～２歩にまで短縮するつもりだったり、歩幅変更中に次の歩幅変更命令を受けられるようにするといった課題が残っているから。
calc Z のラインが歩幅を表すライン。右足が前に出ている状態をプラス、左足が前に出ている状態をマイナスで表している。このグラフの場合、歩幅30㎜から始まって40㎜、50㎜と増えてから40㎜に減ってから停止している。
gyro Xのラインが胴体の前後傾きであるが、歩幅50㎜になるまでのけ反る方向に傾いていたのが歩幅を40㎜に縮めた辺りから回復しているように見えるのは偶然のようです。 これは手動で歩幅を変えているのだが、5㎜の歩幅変更は大きすぎると思っていて、歩行安定化ではもう少し小さい値でフィードバックをかけてみようと考えている。
なんにせよ、３次元倒立振子の軌道を変形させずに歩幅変更ができて、5㎜程度の歩幅変更では大きく姿勢を崩すことがないようなので安心した。
その後、色々と試してみたら、それほど安定していない。歩幅を変更すると旋回が発生し出すケースが多い。それに歩幅を広げて直進速度を上げたら反り返るはずが、前のめりに転倒してしまうケースが。。 つまずいてるような感じだからなんともいえないが、まだまだ先は長いな。
大きな歩幅でのっしのっしとゆっくり歩かせたいのだけど、ロボワンのロボットのようにしゃかしゃかと歩けるのかと思って遷移時間0.3秒で歩かせてみた。
遊脚の動作を随分と変更することでまぁ歩ける。動作時の反動が大きいので歩き始めはよたよただが安定しだすと結構大丈夫。滑る床だと歩き始めのスリップでこの辺りを吸収してくれればいい感じなのかな。
遷移時間0.4秒の場合。加速時間が長い、足上げはゆっくりめ。
遷移時間0.3秒の場合。加速時間を短くしないとすっ飛ぶ。足上げはすばやくしないと間に合わない。
歩行中に遷移時間を変更できるようにもしたいのだが、軌道パラメータも変えていかなければならないのは大変だなー。
■４月２日■
歩幅変更のプログラムにはまだバグが残っているみたいだし、歩幅変更処理自体を改良もしなけりゃならない。 でも、なーんだかやる気が出ない。 オレにはうだうだやってる時間なぞ無い筈なのだが、どうにもエンジンがかかるのに時間がかかってしまう。遅筆の作家みたいな感じだ。
歩幅変更プログラムを改良することよりも、どうしても気になることがあるのだ。それは、昨日の日誌にもかいているが、歩幅を変更すると旋回してしまう場合があること。
旋回は足首左右のサーボにダンパー特性（コンプライアンススロープ設定）を与えることで解決しており、今はそれ以前に比べると見違えるように安定している。それなのに歩幅をちょっと、それも３次元倒立振子軌道を守ったままで変更しているのに不安定になりすぎなのだ。
なにか原因があるはずで、これを放置したまま先に進むと禍根を残しそう。やはりここは突き詰めて旋回が発生するメカニズムを突き止めてみよう。ダンパー特性をちょいといじれば治るかもしれないしね。
とはいえ、バグが残ったままのプログラムでテストを続けるのもどうかと思うので、その辺りもなんとかせねば。今日のところは、歩幅変更プログラムの改良のためのアクションアイテムまとめ。
１．歩幅変更途中で次の歩幅変更を開始するには「歩」の途中から歩幅変更プロセスに入れるようにしなければならない。
２．「歩」の途中から、とはいえ、開始できる限界がある。それを決める必要がある。「歩」の途中から歩幅を変えると遊脚復帰速度が途中から変わることになる。その速度変化は復帰動作の完了間際ほど大きい。特に歩幅が大きくなる場合、残りの時間で歩幅の増加分を移動しなければならないため、限界がある。
３．遊脚の上げ降ろしのタイミングについては、遷移時間が変わらないため、そのままである。なので、特に考慮する必要はない。
４．歩幅変更は遊脚の復帰動作が全てである。途中で移動距離も移動速度も変わることに対応しなければならない。 現在は関数型の処理なのだが、積分型の処理に変更した方が良いだろう。
５．歩幅変更中に更に歩幅を変更する場合を全て検討。 ・・・ あ～、これは結構大変そうだ。歩幅変更量変数を使いまわしできないから困ったな。どうやって変数を使わないようにするか。 うむむむ。。 単に２度目用の変数を用意するってのはイヤだなー。
・・・こんな感じかな。
■４月３日■
連続して歩幅を変えられるようになりました。
おかしな動作をしていた部分も、少なくとも１つは解消した。プログラムの構造も歩幅変更データが流れていくパイプライン方式で美しくなった。 結構そういうところでこだわってしまって時間がかかってしまうことが多いのだが、今日はすんなりとアイディアが出てきて気持ちよかった～。
バグがわかったり、プログラム構造が決まったりするのはお風呂に入っている時が多い。悩んで悩んで諦めてお風呂でほぉ～っとしているとふとアイディアが浮かんでくる。かといって、あんまり考えずにお風呂に入ってもなんにも浮かばないのはもちろんなんだけど。
最近は、ウォーキングをしている時に浮かぶことが増えてきた。お風呂ほどリラックスしていないからあんまり鮮明に浮かばないんだけど、似たような状況なのかなー。
今日は夜も遅いのでサーボは動かさずにプログラムの動作確認だけ。あとは、「歩」の途中から歩幅変更が開始できるようになればコーディングは完了。次は旋回の問題解明に着手だ。
■４月５日■
つま先が作りたい。
歩行の安定化を検討していくと足裏感覚が重要なのだろうなという思いが強まってきている。更に進むと走るということになるのだが、しっかりと足裏に体重がかかっていることを感知できる足裏感覚と足部の受動関節構造が必要になってくると考えている。もっともこれは普通に歩く時にも必要な感覚だから先の話でもないか。
あと、踵というのはどうしたものか。 今の多くのロボットの足裏はつま先から踵までを支持多角形のエリアとして考えている。 まぁ、竹馬のようにほぼ点で接地して安定動作することは容易ではないので、支持脚の接地部が多角形となるのは自然なことだが、それは静止状態だけの話で、歩行中、動作中のほとんどはつま先部分のわずかのエリアで支持しているのが実際だろう。つま先は小指部と親指部の２部でなり、つま先から足首に掛けての関節は受動関節として働く足構造が必要となってくるのではないかと思う。
ただ、今現在はたわ言に過ぎなくて、今すぐにつま先を作ってどうこうできる気もしないのだけど、もう少し今の構造で検討して、できれば足部だけでも実験的につま先構造を作って、試したい。
問題は足裏感覚。力覚センサーがたくさんいるのだろうか。圧力センサーくらいでいいのだろうか。
■４月７日■
このウィークデーは色々ゴタゴタしていて気分的にもブルーだったので全体的にぼへーっとしていた。精神的にも肉体的にも毒出しリフレッシュ期間だったのかも。
「歩」途中の歩幅変更開始は、少なからず歩容が崩れるので安定化検討の邪魔だと判断してとりあえずは保留。歩幅を大きくすると不安定になり旋回が発生する件について検討を始めた。 これは、歩幅変更によって不安定になるのではなく、単純に大また歩きで不安定になっているということなのだと（今は）思っている。とりあえずはそういう見方で検討を進める。
まずは旋回抑制として足首のコンプライアンス設定を変えて効果を見てみた。
スロープ設定100（8度）
スロープ設定200（16度）
スロープ設定255（最大値、20.4度）
いずれも最後は地獄行き。設定255はあんまり綺麗なデータになっていないので参考にならない。 スロープ設定を大きくするだけじゃダメってことで。。。
設定100より設定200の方がgyroZの振幅が小さいのがわかる。gyroYと比べると設定100の時は位相ずれがほとんどないのに対して設定200だとgyroZには遅れが出ている。設定100だとgyroYの振幅も大きくなり始めていて、左右動作もオーバーシュートしているが、設定200ではほぼ抑制されている。 足首のダンパー効果はあるようだが、これだけでは効果が不十分ということだ。
こんなにはっきりと旋回しているということは路面とはグリップしておらず、滑ってしまっているということ。単純に重心のバランスのズレが歩幅が大きくなったことで露呈してしまっているだけなのだろう。
しかし、、歩行時の重心は少し前のめりに設定していて、静止時には足首ジャイロにはちょっぴり負荷がかかっている。 なのに旋回は後ろ側が振れるカタチで起こってしまう。 ・・・ いや、「なのに」ではなく「だから」か。 グリップが発生するには荷重が必要なのに前のめりになった上に速度が上がっているので加速度（速度変化）も大きくなっている。それで後ろ側のグリップがなくなって旋回を始めてしまう。 というメカニズムかなと想像できる。リアのトラクションが足りないのでリアがフラフラするね、という状態ですね。
さて、対策は、、、リアウィングをつけてダウンフォースを発生させる、、ってわけには行かないので、単純に歩幅変更に同期して前後重心オフセットを変更できるようにしてみよう。ゆくゆくは旋回を検出して補正をかける形にしたいが、歩幅変更と同期して予防的にオフセットを変更する処置は必要だろう。
注意点は
①歩幅を小さくしたときにはオフセットを大きくすればいいのか？ 多分、うまく行かない気がするな。初期値より大きいオフセットにするとつまずいてしまうのでは。
②オフセット変更は歩行素片のどのあたりでシフトさせるか。歩行素片全体に薄めて？ 速度が安定しているエリアで？ 両足支持期間にシフトする？
・
・
・
予備実験としてオフセットを小さく設定してみたが、イマイチ変化が見られない。もう少し検討すべきかもしれない。
それにしても畳の上にタイルカーペットを敷き詰めた環境だと路面のうねりとかカーペットのつなぎ目とか障害が有り過ぎだな。不確定要素が多過ぎて分析できなくなってしまう。やはり開発段階ではある程度限定された環境を作るべきなのだろう。
・
・
・
重心のズレは当たりかもしれないけど、だからといって補正がうまくいくかというと、難しそう。 単純に足裏のグリップが足りないのと、偏平足だから路面の凹凸に影響を受けているかも知れないと思って足裏の滑り止めを見直してみた。
⇒ 
「土踏まず」を作るためにつま先部と踵部をケタ上げしないといけないので３㎜厚の衝撃吸収シートを貼った。その上に滑り止めのゴムシート。踵部分の荷重が抜けてもつま先部だけでグリップできるようにつま先部の面積を大きめにした。
結果は全然だめでした。つま先まで滑り止め貼ったせいなのか、衝撃吸収シートのせいなのか、随分とつまずきやすくなってしまった。左右のスイングが足りなくて足が上がりきらない感じ。でも、さっきまでの旋回は起こってない気がする。つまずきがひどいから方向が変わってしまうので見極めが難しい。もう少し足裏を改良すれば望みが有るかもしれない。
重心位置の補正は補正の起点が難しい。旋回が開始してからだと遅いので足裏がスリップしそうなところで補正を始める必要がある。大腿のひねり関節の負荷抜けで感知できないかと思ったのだが、検出できるほどの負荷がない上にコンプライアンスを与えたら旋回しやすくなってしまった。
・・・ 次は足裏の改良と、つま先上げでの遊脚復帰を折り込むってとこかなー。 つまずきを解消しないと効果が見られない。
■４月８日■
簡単に、つま先につまずき防止策。潤滑性テープを貼ってみた。
効果は絶大。つまずきは皆無になった。変更前の足裏でもつま先でつまずいてたもんな。滑り止めのゴムシートが磨り減ってたし。
だからといってうまく歩いているわけじゃあない。相当千鳥足である。
考え直して大腿ひねり関節のコンプライアンス設定を変更（ダンパー特性を固くした）して旋回方向の滑りが検出できるかどうかを試してみて。 ん～、関節の負荷値での検出はやはり難しそう。
こけそうでこけない千鳥足 グラフでは歩幅30となっているが、歩幅変更して50ミリ。足裏がグリップしているので力の逃げどころがないらしい。上半身が反り返っては戻ってきて～、、の繰り返し。反動で旋回を起こしている様子。これはもう上半身のふらつきをナントカしなきゃならないレベルだなー。
元々は歩幅変更で上半身のふらつきを抑制するって事だったのだが、なんか主旨が変わってきている。歩幅・重心オフセット・遷移時間全部使わなきゃならないのかもなぁ。
操作するパラメータが多くなりすぎてきてロボットを見ながらのマウス操作が出来なくなってきた。ゲームパッドでの操作ができるようにしようかと思ってる。
プレステ２－USB変換で考えているのだが、アナログスティックを使うにはDirectXを使わなきゃならない。またまた勉強しなきゃならない(>_<)。 ＶＲ検討してたころDirectXの本を結構買ったりしたのだが、もう情報が古いだろうなぁ。
・
・
・
グラフをよく見ると旋回してしまうときは上体はのけ反っている場合が多いみたいだ。すると、トラクションが足りなかったのはつま先側ということになる。踵を中心にして旋回しているってことだろうか。 ふむーーー、改良した足裏で役にたってるのは踵側のゴムシートということなのかな。
そうであれば歩幅を変更することで前後姿勢の補正が出来るってことになる。 それはそれでいい感じ。
では、今度は歩幅変更とは分離して重心オフセットを移行できるようにしてみよう。せっかくだからX、Y、Z全部サポートすべきだな。特にコーディングが変わるわけでもない・・・はず。
・
・
・
少し前に自転車の「キャスター角」について話を聞いた。自転車が操縦可能なのは、前輪のハンドルの傾きがあるかららしい。その傾きを「キャスター角」と言うらしいのだが、もしキャスター角がなく、ハンドルが垂直についていて、その線上に前輪の軸があるような構造だと、自転車は操縦できない乗り物になるらしい。 聞いた時は「へぇ～、そうなんだー。」と思っただけであったのだが、今日、買ったけれど読んでいないロボット関連の専門書「身体知システム論」という高い本を斜め読みしていたら、こないだみつけた二関節筋のことがちゃんと載っていた。それを読んだ記憶を持って、ウォーキングしにいくとなぜだか急に例の自転車のキャスター角を思い出して（いや、単に多摩川サイクリングロードで自転車とたくさんすれ違ったからか？）ハンドルを切った時の自転車の挙動とかを考えていて、なんとなく二関節筋とつながったような気がした。イメージだけれども二関節筋というのは自転車の「キャスター角」の役割を持っているのではなかろうか。
自転車はハンドルを切れば曲がれるわけじゃなくて、車体を倒してハンドルを適度に切らなければ曲がれない。逆にキャスター角のお陰で手放し運転なんてことも出来る。不安定そうに見えて結構安定したシステムになっている。 安定したシステムというのは自転車のハンドルの様にパラメータが独立しておらず、関連する要素との持ち合いになっているという特徴があるのではなかろうかと感じた。
二足歩行ロボットはどうにもこうにも不安定でしかたない。 あちこち不安定なのだが、なにかキャスター角のような安定化構造が組み込めないものか。なかでも扁平足裏が気に入らなくて仕方ないのだ。どんどん気に入らなくなっていく。なんで、QRIOもASIMOも扁平足なんだろうか。うむぅ～。
はっ！ もしかして直交軸がダメで、オフセットが必要だとか・・。 可能性があるのは足首かなー、やっぱ。
・
・
・
歩幅50㎜を安定化させるべく頑張っているのだが、50㎜になると遊脚の復帰が間に合わないっぽい。 トルク（正確にはパワーウェイトレシオ）の問題なのかもしれないが、一つは加速時間（両足支持期間）の問題が有るだろう。 今のプログラムでは歩幅を５０㎜に増やしてもでも加速時間設定は１歩目と同じ。 今は遷移時間0.4秒のうち復帰に使っているのは0.2秒くらい。歩幅が30㎜から50㎜になっても0.2秒だと厳しいか。
だが、ロボワンのロボットなどは秒速30㎝で移動するらしい。これはものすごく速い。1歩0.2秒としても歩幅は60㎜という計算になる。すごいなー。
とうとう封印していたトルク100%の時か！と思ったけど、まずは歩き始めとその後で加速時間を変えられるようにしてみようかな。 そろそろRS601CRの重い割にトルクがないという根本的問題が表面化してきたかも。
■４月９日■
重心オフセットの移行をインプリメント。 単純に一歩の中でリニアに移行させるようにした。 大体２㎜くらいなら変更の影響は小さいようだ。 歩きながら変更するのは前後のオフセットがメインだと思うが、XYZ全てのオフセットをサポートした。
で、色々と試してみたのだが、お尻がふりふりになるのはやはりのけ反ってしまうのが直接原因のようだ。 そして重心移動で回復することができるようである。ただし、移動したままだと更に姿勢を崩した時の調整代がなくなってしまうのでちょっとずつデフォルト値に戻すような配慮が必要なようだ。
そして、試行錯誤の末、歩幅50㎜が見えてきた。重心オフセットを調整すれば60～70㎜も不可能ではない感じだ。 ただ、歩幅50㎜を有る程度再現性をもたせるには股関節サーボのトルクを100%にする必要があるようだ。遊脚の復帰が間に合わなくてつまずいてしまう。
足幅を120㎜から110㎜にすることで左右のスイングを小さくした。 この辺もポイントだなー。
遷移時間をベースに歩幅ごとの詳細パラメータテーブルを作って、歩幅移行に対応できるようにすべきか。 それを作らないと遷移時間の移行はできないしなぁ。
今後の予定。
①重心オフセットで上体傾きのフィードバック
②方向変換
③下半身姿勢移行の一般化
④つまずき対応
⑤受動関節
⑥転倒対応（上半身動作）
⑦段差・傾斜（不整地）対応
・歩行パラメータテーブル
・遷移時間移行
・後退
ううむ。。 やること一杯あるなぁ。
■４月１１日■
歩行が以前に比べるとましになってきたのでここらで動画アップしておこう。今後の成長の証のためにも。。
歩行の練習してると、ころころ転んで心臓に悪い。こけるところを助けようと足や手を出して打ち身きり傷を負ってしまったり。。。 早く⑥転倒対応をやりたいんだよなー。２年くらい前から言ってるし。
ただ、今のところ特異姿勢はサポートしていないから歩行以外のポーズが取れない。ごちゃごちゃ言わずにモーション再生もインプリメントしないといけないかな。つまずき対応するためには下半身姿勢移行の一般化が必要。更にはつま先立ちやつま先上げの姿勢もサポートせねばならない。方向変換も早くやってみたいし、どういう順番で手をつけるか悩むところ。
方向変換が簡単そうで、出来上がったらファンクションが増える感じだし、いいかなー。
問題はセンサー系。 ジャイロも関節負荷も制御のために有効な情報を抜き出せないままになっている。ジャイロの累積オフセットもなんとかしなきゃならない。
■４月１３日■
仕事から帰ると、ゲームパッドコンバータが届いてた。これでPS2のゲームパッドをPCにつなげる。
さっそくドライバーをインストールしてDirectXのプロパティで動作テスト。 ふむふむ。。。アナログジョイスティックもちゃんと使える。 じゃぁDirectInputの導入手順を調査してみよう。
DirectX9.0 SDK 432MB でかいなー、まだ光になってないからダウンロードひとしごと。ま、でもまぁまぁ。。。
VC++から使うのはどうやるのかなと、調べてみると、 「DirectX9.0はVC++6.0には対応していません。」 んがぁ～。。orz
VS.NET2003も持ってるんだけどね。インストールするのやだなぁ。使いたいのはDirectInputだけだからVS6.0でも使えないかなぁ。
試してみるか。
カーブ歩行を実装するための幾何学的準備が終わったのでコーディングしていかなきゃならない。
もともとは足1本に関節が6だから、両足で12次元なのだ、 ただ、関節角度だと相関が不明瞭でプログラムしにくいからIK表現にする。 すると、xyzとtprでやっぱり両足で12次元。 これでもやっぱり表現がしにくいから下半身姿勢ってのを作った。これだと、width depth height tilt pan roll_right roll_left hungで8次元だったのだ。
ところが、歩行するために wshift dshift panshift が必要になり、11次元。 さらに今回 body_roll が加わってとうとう12次元になってしまった。表現しやすくはなってるのだけれど低次元化することはできないんだなー。
■４月１４日■
コーディングを始めると、幾何学的準備が全然終わってないことが発覚。 再考に時間がかかって、プログラムのテストまではできなかった。姿勢の表現性をよくしようとすると姿勢の記述が冗長になってしまい、パラメータはどんどん増えていく。実際、胴体のロールは今までのパラメータで表現可能なのだが、歩く時の進行方向とのズレを別途記述しなければならず、それは美しくないのでまたパラメータを増やしてしまった。 あと、つま先立ちを組み込めばほぼ完璧だと思う。
姿勢安定化にジャイロを使いたいのだが、サーボの振動で発生するオフセットを消去せねば使えない。ジャイロの感度ってどんなだろうと調べてみると、測定範囲ってのがあって、クリスタルジャイロだと300deg/sくらい、セラミックジャイロだと90deg/sくらい。これってスタンダードなのか？スピーシーズロボットのジャイロはどうなんだろ？セラミックジャイロの測定範囲だと、転倒のデータは正確に取れない、飽和してしまうはず。サーボの微振動を拾ってオフセットが出てる件とは別なのだろうか。 測定範囲であったとしても、転倒みたいな加速運動だと、積分もただ累積するだけじゃなくて補正（というかちゃんと積分）しないといけないのだろうか。
明日は朝からチェックだな。 そして、カーブ歩行にとりかかるか、ＰＳ２のデータ取り込みに取り組むか。
■４月１５日■
胴体のロールは無事完成。両足を動かさないで胴体だけ回転させると両足がクルンとねじれる。 なかなか面白い。 はじめ、どうも動きがおかしいので調べていくと、どうも足のIK計算がおかしいのでは？？ という疑いがかかったが、足首のロールと股関節のロールを勘違いしていたのが原因だった。ふぃ～、いまさらIKがおかしいとかになるとちょっと大変なところだった。よかった～。
動きが面白いので動画をアップしようと思ったんだけど、PS2コントローラで動かせたらいいなー、ということでPS2のアナログスティックでグリグリと動かすことにしたの、だ、が、 やはりDirectInputもめんどうだったー。 なーんでこんなに手順をふまないとデバイスを使えるようにならないんだ？？？ なんかおかしいよ。
ってことで、コントローラはまだ使えてません。 こういう主題じゃないところで時間を取られるのってほんとに邪魔。Windowsってとっても複雑なシステムだからOS側にもいろいろと都合があるのはわかるけど、めんどくさすぎ、判りにくすぎ。 ずっとWindowsと共に生きている人だともしかしたら問題ないとか、必然だったりするんだろうけど、僕の場合はツールに使っているだけだから困っちゃいます。 使えそうなサンプルプログラムを見つけたのでそれを流用できるようにして効率化を図ろうと思います。
DirectX9のDirectInput8はVC++6.0では使えないという話と、実は使えるという話があってどっちなんだろう。今の感触だと使えなさそう。DirectInput7を使わなければならないらしい。7って8より更に手続きが面倒。 道のりとおいなぁ。
戻って胴体ロール。 ちょっと前から思っていたのだが、ラムダの胴体にはロールとチルトの２自由度があるのだが、これって要らないのではないだろうか。ありていに言えば時期尚早だったかなと。 この２軸を削減して上半身のスリム化しようかな。
■４月１６日■
やはりVC++6.0でDirectInputを使うにはDirectX7が要るらしい。Direct7SDKにある。dinput.lib（ライブラリーファイル）さえあれば、プログラムについては懇切丁寧に解説してくれているサイトを見つけた。 だがしかしっ！！DirectX7SDKがないのだ。 家捜しすると５と６のCDはみつかったのだが、７、８はなかった。(>_<)
しかたがないのでﾄﾞｯﾄネットをインストールすることにした。もうすぐHDDが一杯になってしまいそうなのでおっきなアプリは入れたくなかったのだが。。
ドットネットインストールするのは時間がかかるのだ、全部ぜんぶ入れるとHDDパンクしそうなので色々と加減して減らしたのだが、更新なんかも入れて２時間以上かかった。サービスパックでかすぎなんだよー。早くBフレッツにしないとな。
.Netを入れて、いつものラムダ操作アプリもコンパイルできた。DirectInputのサンプルプログラムはというと、、、エラーがでるけど、「ライブラリが壊れてる」とかいう致命的なエラーメッセージは出ない。ふむ。。こっちの方がVC6より使いやすそうな気もしてきた。
今夜はDirectInputの目処がつくまでは寝ないぞーと意気込んでいたが、明日も仕事だしもうねちゃう事に決定。
＃あ、明日は「鬼嫁日記」だ。 ロボットゴトできるかな～。
■４月１９日■
・・・さっきやっとPS2のコントローラがつながった。コントローラのアクセス権を得るにはウィンドウがフォーカスされていなければならないとか、アクセス権を得てもフォーカスがはずれるとアクセス権がなくなるとかってのが判らなくてひっかかってしまった。経過情報をダイアログに表示して確認していたのだが、そのダイアログのせいでアクセス権がなくなってしまっていたのだ。むぅぅ。 VC++のドキュメントにもDirectInputの初期化手順などが載っているのだが、サンプルのままだとフォーカスが無い状態で初期化した場合がカバーできない（エラーコードを調べれば判別できる）のだが、これでいいのだろうか？
ラムダ用クライアントはモードレスウィンドウを開いて複数のウィンドウを持つのだが、これはフォーカスが外れた状態じゃないよなぁ。。 ってーか、フォーカスが外れてもアクセス権を維持することはできないのだろうか？
ラムダの胴体ロールをコントローラでグリグリするのはもうちょっとかかりそうだ。
週末にはカーブ歩行をインプリしてコントローラで歩かせたいと思っていたのだが、難しいかもしれない。。 頑張らねば。
■４月２１日■
ウィンドウズメッセージのWM_ACTIVATEをきっかけにデバイスを取得したりタイマーをON/OFFさせたりすることでいい感じになってきた。
PS2コントローラをアナログモードで使いたいのだが、右のアナログスティックをどうやって取得するのかがわからない。これはおいおいやっていくとするかなー。コントローラでの操作はこんな↓感じにしたい。
VS.NETの「変数の追加ウィザード」が使い勝手が悪すぎ。コントロール毎にウィザードを立ち上げなければならない。めんどくさいなー。 あと、コントロールIDとコントロールに結びついたメンバー変数の関連がさっとわからない。変数の削除は手作業でしなければならないみたいだ。VS6.0の方が使い勝手がよかったのはなぜなんだろう？C＃はすごく使い勝手がよかったりして。。 移行コントロールだったりして。
コントローラのボタン構造体への割り付けはこんな感じ。 まだ、右のスティックはわからない。 コントローラで歩かせたり歩幅を変えたり前後重心の調整をしたりはできるようになった。 まっすぐしかあるけないし、外部電源の状態だからリモコンって感じじゃーないなー。
結局、コントローラでグリグリってのはやらなかったけど、胴体ロールの動画もアップ。
↑この動作が出来ないとカーブ歩行ができないのだ。
■４月２２日■
ようやくPS2コントローラの全ての入力を取得できるようになった。DirectInputにあらかじめ用意されているデータタイプでは2本のジョイスティックを取得することはできないらしい。3軸って書いているが、1本につき2軸使うので1軸足りない。追加軸2軸となっているが、これは使われていない。 もちろんこれは僕が購入したUSBアダプタ用のドライバーがそうなっているからなので、すべてがそうとは限らないのだが。
新しいデータ型を起こすことで2本のアナログスティックと方向キーと全てのボタンデータを取得できた。アナログモードにすると方向キーは方向コントローラに割り当てられる。右のスティックの左右はZ軸に割り当てられる。右のスティックの前後は何に割り当てられているかわからないのでワイルドカードで取得している。独自型ってのがあるのかもしれない。
忘れないうちにまとめてアップしておかないとな。 参考になったサイトはたくさんあるけど、決定打はここでした。
あ、あと、バックグランドジョブになってもジョイスティックを手放さないようにするのは協調モードをバックグランドにすればいいだけだったようだ。恥ずかしい・・。 バックグランドに設定すればInitDialogメソッドからでも初期化できそうな感じだったけど、WM_CREATEメッセージを受けて初期化するようにしてみた。
さて、次はカーブ歩行のプログラムコーディングだなぁ、と思いながらネットをふらふらしてたら、Robot.Mとの優雅な平日でこんなのをみつけた。
ANYBOTS社のデクスターとモンティー。左がモンティーでセグウェイみたいなタイヤの足。 右がデクスターで、人間と同じくらいのスケールの足を持ってる。エアシリンダーらしいけど、すごいなー、ジャンプもできるし。
YOUTUBEにとんでさらにフラフラしてて目に付いたクモ型ロボット。普段は６足で歩き、前足２本を腕のように使うことも出来る。 こういうの見ると無性に作りたくなってくる。
１足当たり４自由度あるのかな？歩くだけなら３自由度ずつあればいいはずだけど。
ラムダを構想している時、ゴリラ型を真剣に考えた。（今でも考えてるけど） これはそれと一緒だな。 ゴリラ型、、 短い足にしないとバランス取れないんだけど、意外と難しそう。２足歩行も出来なきゃならないし。
・
・
・
カーブ歩行をするためには歩きながら姿勢を変えられなければならない。この次に控えている下半身姿勢の一般化の特殊パターンみたいなもんだ。
胴体ロール、胴体チルト、胴体パンは歩行素片全体で移行するのだが、足首ロールだけは遊脚復帰期間に移行しなければならない。
組み込んで歩かせてみると、結構歩けるみたい。 これは、、胴体ロールを使わなくてもカーブ歩行できそうだ。
カーブ歩行するためにはとにかく胴体が旋回しなければならないわけだが、グリップ歩行なので、足首のロールを利用することになる。ただ、倒立振子軌道で歩いているので、支持脚の足首がロールすると、その分だけ倒立振子軌道がずれることになる。もちろん、回転を考慮して計算することもできるのだが、ちょっと計算が面倒かな。
そこで、指示脚のロールは固定したままで遊脚の足首と胴体をロールすることで倒立振子軌道を守りながら歩かせようとしている。胴体ロールによって重心オフセットはずれるんだけど、その計算は比較的簡単なので考慮している。 ただし、回転によって発生するモーメントまでは計算していないけど。
恐らくは指示脚のロールを使うよりは大きな角度で旋回できる（つまり小回りが出来る）はず。
・・・ その場旋回は指示脚ロールを使うしかないんだけど、まーできそう。問題は横歩きだな。単純には倒立振子軌道ではできないのだ。（移行前と移行後での対象軸がないので）
あ、足幅の移行を組み込むのを忘れてた。
■４月２３日■
胴体ロールを使ってのカーブ歩行インプリの準備を進める。 カーブ歩行を行う時の幾何学的準備。イメージとしては円弧軌道というより多角形軌道に歩く感じになるのだが、一歩毎に下半身姿勢を回転変換することになる。
胴体ロールの概念を導入したので下半身姿勢を座標回転できるようになったのだ。
カーブ歩行のタイプは、左カーブ、右カーブ、さらに左足が前か右足が前かという組み合わせがあるのでちょっと面倒。
話は変わるが、PS2コントローラで操縦してみて感じたことがある。前後方向の姿勢安定化だが、ジャイロデータの累積による姿勢データを使って、重心オフセットを調整し、安定化を図ろうと思ったが、この方法はダメっぽいので見送ることになりそう。やはり、ジャイロデータそのまま、つまり角速度データでちくちくとフィードバックする方向で実験してみることにする。
前後はそれでよいが、左右についてはちょっと検討が必要。 単純倒立振子なので左右については角速度が発生してよいのだ。角速度を相殺するような制御をすると思い通りの速度が得られないことになるはず。目的の角速度との差分をフィードバックしなければならない。そんなことできるかな？
もう一つは、クライアントからロボットへのコマンド送信の手段。いままではウィンドウアプリをマウスでクリックしてたのでコマンドを送る速度は問題にならなかったが、PS2コントローラだと複数のコマンドが連続して送られることになる。 そういうことは想定したコマンド方式になっていなかったのでデータが飛んだり間違えたりすることがたまに起こる。 歩行テストをしていると、急にとんでもない格好になってすっ飛ぶことがあった。こわかったー(>_<)
そうだ、もう一つ。 足幅の移行はさっくりと組み込んだものの、倒立振子軌道が狂うことを忘れてた。通常歩行中の移行は難しい。カーブ歩行と同様の、軌道の回転変換を使うことになりそう。 難しいな。
■４月２４日■
「パパと花嫁」見て、「鬼嫁日記」見て、ジャポニカロゴス見て、ぷっすまをちょっと見てからストレッチと筋トレを少しやって、風呂入ってからロボットゴトに着手。
というわけで大したことが出来る時間はないです。
歩行時の安定化にジャイロの角速度データを使ってみようということで、今は前に実験してた時とちがって、胴体ロールや足首ロールをサポートしているので、簡単にジャイロデータに応じて補正するわけにはいかない。
足の逆運動学計算は足部が地面に接した状態で軸に対して正面を向いている状態の股関節の位置と股関節の姿勢を計算するようにしている。そのため、ジャイロの補正角度は胴体ロールと足首ロールの差分の角度で座標軸を回転させた値となる。
この計算を考えているところで、ふとこないだからちょっとおかしいなと思っていたことに気付いてしまった。
やっぱり逆運動計算間違えてる。股関節のZ軸回転（ロール）の符号を反転させただけで、「足部の向きを表している」としていたが、X値、Y値もZ軸周りに回転させなければそういう意味合いにはならない。 そういや動作検証してるときもちょっと軸がずれるみたいなんだけど、工作精度の問題でずれるんだって思ってた。
いまさらなので、Z軸回転角度の符号を戻して、表現は「胴体姿勢」で通すことにしよう。 いや、待てよ。やっぱり足部のロールにした方がすっきりするか？
XとYをZ軸回転角度で座標軸回転させる計算をどこでやるかって話だけだからどっちでもいいか。どっちでもいいならIK計算部でやった方がいいかな。
カーブ歩行のインプリはＧＷにまで突入しそうだなー。 誤算だ。
■４月２６日■
今日も12時過ぎからロボットゴト開始。
早速逆運動計算の変換関数を修正して、胴体ロール角度を足部のロール角度に変換するようにした。 動作テストしてみると、、、確かに違う。足部のロール角度を与えるとちゃんと足首の軸で足部が回転するようになりました。 ちょっとずれるのは工作精度のせいじゃなかったんだな。うれしいやら悲しいやら。。
ロール角度を90度として、足を前後動作させると一目瞭然でした。 ・・・ 思い込みって恐いな。。
今度は動作時のジャイロフィードバック。足ロール角度やら胴体ロール角度やらを入れたから色々計算しないとイカンと思っていたがこれも思い違い。補正角度は足クラスに与えて処理するようにしているのだが、足クラスは股関節を原点として処理している。ジャイロは腰部に実装しているので、何がどうロールしようがジャイロセンサーの値に従って補正すればいいだけだった。 まったくもってアホでした。 それもこれもロール角度の部分が間違えていたから勘違いしたのだけれど。
組み込んで歩かせてみたが、、 どうかなー。「効果が歴然」とまではいかないな。補正極性を変えてみたり補正角度の倍率を変えてみたりして効果の程を確認していきたいと思います。効果がみえないからちゃんと補正してるかどうかも確認できてないので。 今日はもう夜遅いし、ロボット歩かせるのもいい加減にしないとね。
■４月２７日■
こないだコーディングし損ねた下半身姿勢を座標回転させる関数をコーディング。 関数っていうか、簡単なんだけどね。
そして、色々考えあぐねた末、足幅については、倒立振子軌道を変形させて組み込むことにした。あまり大きな変化じゃない限り問題ないであろうという読みだ。 うまくいけば歩幅変更もこれの応用で一歩でできるようになるんだけどね。
そして、これでいつの間にやら下半身姿勢移行の一般化が出来たことになる。 高さ移行だけはまだ組み込んでないから正確には違うのだが。
あとは、踵上げ姿勢をサポートすればつまずき対応や転倒対応へとつながるはず。
今日はもうロボットの電源は入れない。 テストは明日やろう。 そして一気にカーブ歩行コーディングまで終わらせたい。 ぐずぐずしているとＧＷ終わってもカーブインプリ終わってないっていう悲惨な結果になりそうな気がしてきた。
RobotWatchでTeamOSAKAのTEENタイプロボットが紹介されている。身長80センチらしい。はじめロボット研究所も身長１ｍのTEENタイプロボットがロボカップジャパンオープンに出場するらしいが、どんなのか楽しみだ。 TeamOSAKAの方は動画が紹介されているが、デザインは別としてしっかりと組み上がっているように見える。 ソニー・ホンダ・トヨタなんかの大企業は別としても、ベンチャー企業が作るロボットでさえ、大学のロボットに比べて完成度が高い（外装がついているだけなのかもしれないが）のはなぜなんだろう？ 学生は別としても教授や助教授はそういうのは気にしないのだろうか？いつも不思議に思う。
■４月２８日■
Bフレッツ光（マンションタイプ）になりました。46Mbpsくらいだそうです。ん～、まぁそんなもんなのかなー。とりあえず、YouTubeのダウンロードが早くなった。でかいファイルのダウンロードしてみたいな。
このロボット、イカす。 リモーブレインなのだろうけど、ステレオビジョンカメラはどこに積んでるんだろう？ ちっこい目の部分？
・
・
・
昨日コーディングした下半身姿勢の座標回転のテスト。
判りにくいのだが、右10度の方向にちょっと歩いて、左10度の方向にちょっと歩いている。
姿勢を-10度回転させた状態から直進し、その後+10度回転させて直進したということ。斜めに歩けるということなので、条件が揃えば真横にも歩けるかもしれない。 ただし、通常の歩行なのでカニ歩きは出来ないのだ。遊脚が指示脚を追い越す必要がある。動画だと左右の歩幅が違うように見えるが、実は一緒なのだ。 片足を引きずっているように見えるなぁ～(-_-;)
足幅変更は検討不足だった。そんなに単純じゃなかったらしい。orz。。。
・
・
・
カーブ歩行できた～(^^)v 準備期間が長かったからすんなりうまくいった。 カーブ開始がどちらの足か（もしくはどちら側にカーブするか）で曲がり具合が違ってしまう。 ちょっと対策がいるかも。 足首ロールで曲がるよりは安定して曲がれる感じ。 よかったー。 明日、コントローラーで操縦できるようにして動画撮ってみましょう。
それと、、 ジャイロは効いてるかどうかわからんなーと思ってたら、プログラムが動いてなかった。(^^ゞ でも、今度こそ動作させたのだが、あまり顕著な効果がない。 これももうちょっと検討が必要。 ちなみに単純倒立振子モードのときは（当然だが）Y軸（左右）のジャイロフィードバックをかけるとうまくない。逆に線形倒立振子モードにするとジャイロフィードバックをかけるとちょっと安定度が増す。（これも当然なのだが） 一応はジャイロの効果は出てるってことなんだろうな。
カーブ歩行。 まだまだ問題だらけですが、ここまでの状態で動画アップ。
急激なカーブは曲がりきれない。 カーブから直線に移る時に歩幅が変わってしまう。姿勢を回転させながら歩いているので、歩幅が変わると足幅も変わる。カーブ開始時の軸足がカーブの中心に違い側の場合は歩幅が小さくなる（足幅は大きくなる）のだが、軸足がカーブ中心から遠い時は歩幅が大きくなり足幅が狭くなる。この辺りは検討不足デス。
歩幅は移行できるのだけど、足幅の移行がまだできないからダメだー。カーブに入るタイミング（軸足）やカーブを終了するタイミングを制限したくないのだよ。
まずは足幅変更の見直しから。
さっきちょっとフカフカカーペットの上を歩かせてみたら、そこそこ歩けた。 歩けたと言っても以前よりは、ということで、まだまだ改善の必要がある。 ふかふか床だとベタ足が浮いてしまって不安定。フカフカ床を歩かせるには足の指が必要だな。
・
・
・
カーブ歩行から直進に戻る部分が、自分のイメージどおりにコーディングできない。歩幅変更がシフト方式（←自分で名づけたんだけど）なので２ステップ必要。さらにはカーブ中にも歩幅変更が起こる可能性も考えると、とても複雑になり、イヤ。
足幅移行はうまく行ったので、歩幅変更の方式を、シフト式から姿勢回転式に変更しようかと思う。そうすれば１ステップで移行できるし、カーブ歩行の場合、どのような状態でカーブに突入しても歩幅を適切な値にあわせこむことが出来る。
結局、カーブ歩行より姿勢移行の一般化が先だったわけだ。
カーブ歩行させると、当然だがZ軸周りのモーメントが発生する。以前直進歩行にてグリップが足りず、旋回してしまった件と同じ。旋回が発生するとやはり背中側に引っ張られてやがては転倒してしまう。半径が小さなカーブ歩行はもっと考慮が必要なようだ。
あと、左右スイング動作がオーバーし、同期が外れてしまうことが多くなった。フレームががたついてきたせいかも知れない。 現象としては、遊脚となるべきタイミングになってもまだスイングが終わっておらず、支持脚のままになってしまっている。遊脚から着地する時は足首をダンパーにして勢いを吸収する必要があったが、そのあとは同期外れを防ぐためにもダンパーの硬度をあげなければならないのかもしれない。
実は遷移時間を0.3秒にすればスイング動作が小さくなり、結構安定して歩けるようになってきている。（歩幅は小さいが） でも、どうもバタバタ歩いている感じで好きじゃない。いましばらくは0.4秒での安定化を目指そう。
ラムダ歩行動画
胴体ロール動画
下半身姿勢の座標回転
カーブ歩行動画