転倒回避歩行■６月２日■
転倒回避歩行が完了してからページを変えたかったのだけれど、すぐ終わるかどうかわからないし、前のページも相当長くなったので今日から新しいページに。
注文していたメモリーが届いたので新しいノートパソコンの設定を一気にやってしまう。 つもりだったのにネットワークがつながらない。IP直打ちでなんとかデータを移管したら、今度は無線LANからインターネットにつなげない。むぅぅぅどうなってんだ。 とりあえず、予定通りに無線LANは11gに変えるつもりなので、アクセスポイントを変えてから悩もう。
パソコンの設定をしてたら、DELLの液晶ディスプレイが届いた。6月7日到着予定だったのに、早いな。これは設置するだけでほぼ終わり。
そうこうしてたら最後に新しい携帯電話が届いた。 そんなにテレビを見ないけどF904i ワンセグ携帯。この設定も面倒だ。とりあえずはアドレス帳だけ移してあとはぼちぼちやろう。携帯の設定は外でもできるもんね。
結局、土曜日の午前中がそんなこんなで終わってしまった。午後からは転倒回避歩行最終章（になればいいのだが）がんばるぞー。
■６月３日■
転倒回避歩行の処理部分にジャイロフィードバック処理を折り込んだ。
転倒回避歩行で１歩足を出したら、0.5秒ほどウェイトする。ウェイト中はジャイロフィードバックで踏んばる。もちろん転倒しないレベルの角速度が発生したときもジャイロフィードバックがかかる。
そういう感じにしてみたら、とりあえず、ガシャガシャとはならなくなった。
まだまだ貴乃花の粘り腰には程遠い。画像はうまくいったところを抜き出した感じです。今は「速度」をキーに動作させているのでゆっくりと押された場合には抗うすべがない。角速度センサーのデータを積分したデータではオフセットの累積でうまく姿勢を検知できない。加速度センサーの出番かな。実測した速度を基準とする歩行計画ではサーボの反応速度の限界を超えている。速度が大きいとトルクは下がるという問題もある。崩れる姿勢に対応するように重傾を適切に変えるなどの小技も織り交ぜなければ安定しないだろう。
あと、あきらめて受け身をとるモードも実装せねば。
だがしかし、転倒回避歩行にばかりかまけていてはこれだけで１年くらいは簡単に費やせてしまう。ちょっとパワーシフトして構造改良案件に着手しなければ！
来週は工作かなぁ～♪
・
・
・
今日の残りの時間で、加速度センサーの処理なぞコーディングしようかと思っていたのだが、インベンターとの格闘で時間を大幅に費やしてしまった。
以下、転倒回避歩行の改良のための気づきをメモのつもりで列挙しておく。
■６月４日■
今日はものすごい脱力感と眠気に襲われたので、とっつきやすい構造検討をすることに。
しかし、まてよ？ 昨日の後半はインベンターと格闘してたのだった。構造検討はプログラム検討以上に脳みそを使う。今日の脱力感は昨夜のインベンターのせいかも？だとすると明日も脱力感か？
明日は気力をこめて転倒回避歩行の改良に取り組むつもりなのだが。。
昨日アップしたビデオを見ると、足を出す寸前まではジャイロフィードバックで踏んばっている様子が映っている。なかなか臨場感あるな。 重心オフセットをコントロールすることでもうちょっと姿勢を崩した状態からでも一歩を出せるのではないかなーと期待している。
あと足首ダンパーの設定も安定度アップに効果あるのではないかと期待している。
転倒回避歩行は膝への負担が大きいらしい。普通の歩行の検討をしていてもサーボが温度異常になることは無いのだが、結構短い時間で膝サーボの温度異常が発生した。構造改良時には膝サーボのモーター部へのヒートシンク取り付けも検討しよう。 転倒時のバンパーも考えておかないとなぁ。改良後の構造は今の構造よりCPUユニットの露出が多い。CPUユニットが破壊したら大惨事だし。(>_<)
■６月５日■
転倒回避歩行動作に伴う姿勢回転での重心オフセットの扱いを考えていて、通常歩行でのバグに気づいた。
重心オフセットを上半身の重心位置と分離したのだが、重心オフセットは姿勢の回転に影響しないようにした。 重心オフセットは制御側の都合で重心をどちらかの方向に傾ける度合いを示しているので、姿勢の回転（＝進行方向の定義の変更）には影響させてはならないはずだった。
だが、実際に重心オフセットを足姿勢に反映させている状態で姿勢を回転させたら重心オフセットも必然的に回転してしまうのは当然だった。
歩行においてはカーブ歩行の際、１歩歩く毎に姿勢回転を実施する。姿勢回転の角度が小さいため事実上問題ないのだが、正しくは姿勢回転毎に重心オフセットも（現姿勢に合わせて）回転させ、1歩の動作の中で本来の重心オフセットへ移行する、という動作が必要だった。
下半身姿勢の一般化やら、カーブ歩行やら、手を入れないといけない部分が増えてきた。この辺りで一度歩行ルーチンのたな卸しを行った方がいいかもしれない。
転倒回避歩行については、重心オフセットの処理をインプリメントした。
加速期間中に倒れる方向と逆の方向にシフトする。ただし、遊脚復帰期間に突入すると、重心オフセットをゼロの方向に戻す動作を行う。このタイミングには加減が必要かもしれないと思っている。
転倒回避の１歩を出した後は０．５秒のためがあり、その間はつま先で踏んばっている。 もし、重心オフセットの戻しをある程度ゆっくり行わなければならないとしたら、踏ん張り動作をしながらも、重心オフセットのゼロ復帰動作も行うということになるのだが、うまくいくのかな？一歩の中で収まってくれればありがたいのだが。
遊脚の足首ダンパーの設定も変更して、遊脚が着地するときには足首を固くするようにしてみた。
あと、転倒回避の成功率を上げるには遊脚のつま先上げが必要。路面の傾斜については逆運動学計算に折込済みなのでこれは意外と簡単にインプリできると思っている。
つま先以外はコーディング済みなので、明日にでも動作実験をしてみよう。
＃多分、一番効果がありそうなのは「つま先上げ」だろうなー。
■６月６日■
こないだの休みに押入れを整理して古いハードディスクやもう使わないＰＣのカード類を処分した。
ハードディスクは破壊して捨てなきゃヤバイっすよ。と言われて、ん～、やばいデータ入ってたかなー？？と思いながらもハードディスクの破壊を。もう夜も遅いから音を出すような作業はできないので、分解してディスクを取り出して、カッターでキーーーーっと傷をつけておいた。トルクス持ってたから分解できたけどなかったら明日の金属ごみ回収に間に合わないところだった。
昨日コーディングした転倒回避歩行のトライアル。
重心オフセットを動かしたり、足首のダンパー設定を変えたりしたが、どうも顕著な違いが出ない。やっぱり、失敗するときは「つまずき」ですね。遊脚のつま先がひっかかって上がらない。上がらないからその後の体全体の動きが全部跳ね返って、もうズデーンとこける。何にもしない方がいいくらい。(T_T) やはりつま先上げが有効だろうなー。
それよりなにより、後ろへ足を出す転倒回避がさっぱりうまくいかない。以前の実験では後ろに足を出すほうがうまく行ってたくらいなのになぜか？動作があまりにもおかしいのでバグっぽい気もしてる。てーか、バグだといいなぁ。
■６月７日■
何が効果があって、何が効果がないのか、組み合わせなども含めて検討中。
やはり、転倒回避歩行は姿勢が崩れた状態で歩行が開始されるのが通常歩行と異なる点。 とにもかくにも床面にグリップしないことには歩行は成り立たないので、転倒回避を開始するときには足首をやわらかくして床面との接触を得るようにしている。
この状態で、足首はプログラムが保持している姿勢とは異なる角度になっている可能性がある。その状態で遊脚を持ち上げようとしたらつま先が床面に引っかかる可能性が高い。 現在の成功率の低さはこんな感じではなかろうかと予想してみた。
なので、遊脚を高く上げたり、つま先を上げるというのはそこそこ有効と思うのだが、決定的効果をもたらさないのではないかと思えてきたのだ。
対策は考えたのだが、うまく行くかなー？？？ うまく行ったら結構成功率が上がるはず。 まずはそのアイディアを試してみよう。
■６月８日■
構造検討と遊脚軌道の検討。
構造検討はやってるとものすごい速度で時間が経つ。 ものすごく集中しちゃうのでほどほどにしとかないとキリがないのだ。
配置やフレーム構造はほぼ決まったが、転倒時のバンパーになるべきあばら骨がまだできない。ロボカップへはできれば外装をつけて出場したいのだが、外装はABSを予定。こけると割れてしまうので衝撃を受けるのはアルミフレームという構造にしたいのだ。
もうちょっと悩もう。 今週の休みの間には板金工作はできないなぁ～。残念。
遊脚の軌道は案ができた！
※昨日載せてたのは数式に間違いがあった。つなぎがわるいなぁーっとは思ってたんだよね。
こんな感じ。 時間グラフになってしまって、遊脚の動きがわかりにくい。 XYデータを受けて、XYグラフにプロットしてくれる使いやすいソフトはないかなー。gnuplotとかでもできそうだけど、使い方勉強したくないから直感的に使えるウィンドウズソフト的なのがいいのだが。。。
歩行（下半身姿勢移行って行った方がいいか）の場合の遊脚は直線の組み合わせだったのだが、今回は曲線で作ってみた。円弧の組み合わせデス。軌道は滑らかになったが、遊脚の移動距離は長くなったはず。対応できる歩幅が短くなってしまう。
■６月９日■
昨日作った遊脚軌道の関数をプログラムに適用してみた。遷移時間0.4秒だと遊脚復帰にあてがえるのは0.2秒ほど。9ステップほどのカーブになる。
動かしてみたところ、効果はある。今は足間隔最大160㎜という設定で行っているのだが、これだと復帰時間が少し足りないか？基本的に足上げ距離も大きめにとる必要があるので遊脚軌道は長くなる一方。サーボのスピードとのトレードオフだが、足間隔最大値をもう少し小さめに設定した方が安定すると思われる。
腰高さもファクターとして大きいようで、ラムダの今の基本姿勢は腰高さ（正確には足首関節から股関節の距離）180㎜。転倒回避歩行では腰高さを少し下げる歩行計画をするようにしているのだが、最低値が150㎜。 転倒回避歩行は腰高さ170～160㎜辺りが具合がいいような気がする。
後ろ側への転倒回避歩行は相変らず具合が悪い。プログラムを見直すとあちこちにバグ（計算値の極性を適切に設定する部分がたくさん抜けていた。算出式に平方根が入っているため、処理しないと何でもかんでも正の値を取ってしまう） だが、後ろへの動きがうまくないのはそのせいじゃないようだ。
後ろ側への動作については、以前上半身の重心と重心オフセットを分離管理するようにしたのだが、その辺りの調整（？）である程度改善するか？ 遊脚軌道は前進を基本に検討していて、後退の場合は極性を逆にするだけという感じなのだが、その辺りに問題が隠されているのか？ 不本意ではあるが、胴体構造の変更後に取り組んだ方が効率的かもしれない。
基本姿勢として、構造に依存する制御はやりたくないのだ。荷物を持ったら歩けなくなるってのだと「制御している」とは言えないし。
ずいぶんとパラメータが増えてきて、ちょっと発散気味ではある。
転倒回避歩行は、安定した繰り返し運動である歩行に比べるとストップ＆ゴー動作なので激しい。 足裏の滑り止めが破れてしまった。取り替えないと。。
「下半身姿勢移行」も「歩行」も、そして「転倒回避歩行」も単独の要素として処理してきたのだが、「転倒回避歩行」については一部ジャイロフィードバックと融合している。どうも単独の処理技術として処理するのは難しいのだろうと感じていたが、そろそろ次のステップとしてマクロな意味で「行動制御」を行わないと実用にはならないだろう。
でも、「状態遷移変数」とか使いたくないんだよなー。葛藤の始まりの予感。
■６月１０日■
速度ではなく、姿勢起因での転倒感知について検討を始めた。ゆくゆくは転倒受け身のトリガーとなるはずだ。
下の画像はXYZの加速度センサーデータ。三角マークは転倒回避歩行を行った箇所である。
Z軸センサーは静止データとして「立っている」ことを示す以外には使えない。強いて言うなら転倒状態での姿勢角度を知ることはできるか。
ロボットが（胴体が）どれくらい傾いているかはX軸センサーとY軸センサーで知ることができそうだ。ただし、加速度センサーは分解能が低くて１Ｇで70程度。あまり細かなデータは期待できない。
直立状態ではXY軸センサー値は０「ゼロ」だが、５度傾くと
70×sin(5deg)≒6
角速度センサーでのダイナミックな判断と、加速度センサーのスタティックな判断をどのようにブレンドするかが問題。
まずは、加速度センサーで転倒角度を監視して転倒回避歩行を軌道する処理を作ってみよう。
「つまずき」は遊脚軌道の工夫で軽減できたと思うが、支持脚がグリップしないせいで失敗するケースが多いのではないかと思う。今は通常歩行でのつまずき防止のためにつま先に潤滑性テープを貼っている。このせいでつま先立ちの状態でのグリップが甘くなっているはずなのだ。このテープを取るには遊脚復帰時につま先上げをサポートしなければならない。 ずっと先送りにしていたが、とうとうつま先上げをサポートせねばならない時がやってきたようだ。 大げさだけど。
転倒回避の実験をやっていると、ロボットがガシャガシャこけてもうなんかかわいそうな気がしてくる。ちゃんと受け身をとるようにしなきゃなぁって真剣に思えてきた。受け身動作をどのようにインプリするか、そして起き上がり動作をどのようにインプリするかも悩ましい。特異姿勢をIKで表現するのもなんだかなぁという感じだし、モーションの再生はなんだかイヤだし。
センシングに関してもやっかいな問題が山積している。立っているか、転んでいるかという２元なら判定は簡単だが、その中間的姿勢を判断するのはどうやればいいのだろう？四肢を含んだ姿勢と胴体の姿勢（傾き）を勘案して判断するってことだが、定量的に表現できるのだろうか？
だらだらと転倒回避の検討を続けているのだが、ロボカップスケジュールを見ると６月中旬までに構造変更も完了させなきゃならないスケジュールだった。もちろん転倒回避は５月末までの予定が今になってもまだこの状態。構造については胴体の基本構造までは固まっているのでそこまでだけでも製作して、ガードなんかの部品はおいおい追加していく格好かなー。６月後半はカメラに着手しなきゃならない。ここでスケジュールが伸びるとずるずる行っちゃうのが目に見えてるから死守しなきゃ。(>_<)
■６月１３日■
昨日、一昨日と飲みに行ったので今日は帰ってからたまったビデオを鑑賞しつつ、恐らく今日発売だったのだめの１８巻を読んだ。
昨日はちょっと深酒だったので今日はすごーくしんどかった。酔っ払ったまま寝ると睡眠にならないと聞いたことがあるが、それは実感があって、今日も一日生気がなかったな。
そういうわけで昨日も一昨日も進捗なし。今日は少しは進捗させなければまずいって事で、加速度センサーデータを使った転倒判定について検討。
角速度では捉えられない動き（速度）によって徐々に姿勢が傾き、最後には転倒に至ってしまう場合の検出を考える。
静的に考えるのだから、重心点に働く力は重力方向。重心点の床面投影位置が指示多角形から出ると転倒してしまう。そのギリギリの状態を「転倒臨界姿勢」と呼ぶ。
この姿勢を転倒回避の開始トリガーとするのだが、角速度で考えていた時と違い、確実に姿勢は傾いているため、通常の歩行と同じには考えられない。 つまり、傾いた姿勢が歩行の開始姿勢として歩容を生成しなければならない。
今は傾きを監視しておらず、角速度のみで転倒回避の起動をかけているので、転倒が始まって加速した結果、転倒予想が成り立って回避を始めるという事態もたびたび発生している。この初期姿勢の適正化を行えば、角速度起因だけでも成功率が上がると思う。 でも、姿勢起因のモードも必要なので、転倒を開始してから角速度起因での転倒回避ということはありえなくなる。 まぁそれでも開始姿勢の適正化を折り込んでおいた方がいいような感じだな。 問題のひとつであったグリップの確保にも効果が期待できるし。
■６月１４日■
筆が進まず、姿勢起因の転倒回避歩行の判定プログラムが書ききれなかった。
その前段としての、「重力オフセットの倒立振子軌道への反映」はできた。
いままでは重力オフセット値は補正値という位置づけにしていた。重心点の軌道計算の段階ではオフセットはなしの状態で計算して、その後にオフセット値をプラスするというカタチにしていた。
傾いた姿勢からの歩行動作開始を行おうとすると下半身姿勢のオフセットパラメータを使うか、重心パラメータを使うかなのだが、重心オフセットが適切だろうと判断して軌道計算に組み込むことにした。
で、これは下半身姿勢移行動作全体に反映することとして、通常歩行の際のコーディングも修正した。なんだか歩行が安定したように感じるのは気のせいだろうか？
この状態で角速度起因の転倒回避歩行をさせてみると、成功率が上がったような・・・ これも気のせいかなー。 まだまだ失敗率が高いです。
このまま、転倒判定ルーチンに姿勢による判定の記述を追加しようとしたのだが、転倒歩行後のウェイトの考え方をどうするか？なんて部分でつまずいてしまってコーディングの進捗がはかばかしくない。今日はもうお風呂に入って寝ようかな。
あぁ～、構造検討が止まったままなのだが、土日に工作できるんだろうか？ 今回つくる部品はあまり多くはないのでなんとかしたいなー。
■６月１６日■
今日は一日姿勢起因の転倒回避歩行と格闘していた。 結果は敗北。
最初、どうしようもないくらいおかしな動きを繰り返していたのだが、いつもどおりの変数の初期化ミスだった。さて～、これでうまく行くはずだと思ったのだが、加速度センサーによる姿勢を歩行開始姿勢へ反映するようにしたら角速度起因の転倒回避歩行もおかしくなりだした。入力速度と反対方向へ足を出すことが多くなったのだ。
結局原因は、傾きによる重心点の移動が、転倒回避歩行による移動の限界位置を超えてしまい、リミッターコードにより反対方向への移動になってしまうというお粗末なもの。
その他、オーバーシュートによる転倒のケースがうまく行くのは、角速度だけを見ていたため、姿勢が正姿勢より上向きになっている段階で転倒予測速度に達してしまい、足を出し始めるからで、つまずきの可能性が低くなっていたからだった。
どうも、まだ姿勢を反映させるための検討・考察が足りていないようだ。
今は、１３日のイラストにあるような限界角度を計算し、それを超えた時点で転倒回避が始まるのだが、これだと、10degくらいになる。すると、前のめり過ぎてうまく歩けないのだ。閾値を下げると、ちょっとでも傾くとバシバシ足を出しまくってうまくないし、ジャイロフィードバックによる「踏ん張り」との融合がうまく行かない。
姿勢を計算に入れた途端に「転倒（こりゃ転倒だねという意味で）」の判定もしなきゃならないわけだ。そういえば、今は 「角速度による判定」⇒「姿勢による判定」⇒「転倒判定」という順番だった。「転倒判定」が先頭なのかー。
あと、感覚的な感想なのだが、外力により傾いているときは足の縁で立っているのだが、姿勢起因での転倒回避が開始されると、姿勢を読み取って床面にグリップするように足をペタリと下ろした姿勢になる（１４日イラスト参照）これが失敗の原因のようだ。つま先を上げたままで歩行開始した方がいいのか？そんなことできるのか？斜めの場合はむりだよなー。遊脚が上がったら１点で立たなければならなくなる。振子だったらできるのかぁ？
■６月１７日■
昨日の後半は今日のために構造検討をやっていた。なんとか、展開データを面付けするところまで終わったのだが、今日はその続きから。
でも、昨夜風呂に入った時点で、うちの工具では曲がらない個所を発見。修正したのだが、更に曲がらない個所を発見してしまった。設計変更と他に問題はないかをチェック。。。
今回はアメリカから個人輸入したシャー＆ブレーキで初めて板金曲げを行うのだが、今までの手作り板金曲げ機ではできなかったZ曲げができるようになったので、結構自由に板金部品を設計していたのだ。
↓これは曲がりません。
胴体ベース
↓こんな風にしないと曲がらない。
カタチはもうちょっと変更を加えました。ちょっと弱いところが気になったので。。
↓これも怪しい。が、これはがんばってやっちゃうつもり。
LANカード固定金具
ポイントは↓ このヤゲンの厚さがZ曲げの最小寸法を決めるのだが、胴体ベースの場合は手前に曲がっている部分がここにひっかかってしまうのだ。
小さい部品なら端っこを使えば結構いろいろな部品が作れるのだけどな。
よく見えないのでここだけ拡大。
結局、穴あけまでしかできなかった。切り出し・ヤスリ仕上げ・曲げ は来週に持ち越し。
転倒回避歩行は行き詰まり感が濃厚になってきた。
つま先で踏んばっている状態のまま、転倒回避歩行へ持ち込む必要があるようなのだが、足先の形を考えるとうまく行かなさそう。 足の構造も変える必要があるのかも知れない。実験してみたいところだが、特殊姿勢を歩行ルーチンに折り込む検討をしなければならないし、もう少し勝ち目が出るまで考察してみようかと思っている。とりあえずは姿勢を検討してみて、簡単にできそうならば実験だな。
■６月１８日■
つま先立ち状態からの歩行について少し考えたのだが、つま先立ちを正しくサポートするにはつま先関節（足の指関節）が必要で、さらには受動関節の技術が必要。これは先々走行を考える時には必須なのだが、今はまだ時期尚早。現状のハードでできる方法を考えねばなるまい。
床が柔らかかったり、足裏のクッションをやわらかくすることである程度は受動関節に近いことができるかとは思うが、別の手段も考えてみよう。
足をそろえて立っているという状態はいいとして、それ以外の状態を下図のような状態とおく。 ちょっとわかりにくいが、外力は向こう側からこちらに向かってかかっていることをイメージしている。この時の転倒線は赤い破線。 正確には外力のうち、転倒線に直交する力が転倒外力として働くと言う方が正しいか。
この事態に対して、下図のように姿勢を変更し、転倒外力を受ける姿勢を規制する。 これは外力が大きい場合やひつこく加わる外力に対して行う動作で、外力すべてに反応するわけではない。 普通は今までどおり姿勢を変更せずに対応する。 外力を受けている状態では転倒線に接する２点のみで踏んばっている状態なので、姿勢変更によるスリップはかんがえなくてもいいんじゃないかと思う。
この姿勢なら、つま先立ちでも足の辺で受けるわけで、グリップもある程度期待できる。自由姿勢からの転倒回避歩行よりは安定して足を踏み出せるのではないかなーと思う。
この先はつま先立ち状態からの歩行ということで、またパラメータが増える事になるなー。 つま先立ちは、路面の傾斜という形でＩＫに組み込み済みなので、歩容生成計算に反映すればいいだけだからインプリメント自体は簡単だろう。多分、遊脚復帰運動が悩みどころになるのではないだろうか。（そうでもないかなー？？）
■６月２０日■
つま先立ち姿勢のデータ化を検討していたのだが、やはり難しい。
なんと言ってもかかとを少しでも上げた瞬間に指示多角形が変わり、大体は重心点が指示多角形の外に出てしまうことだ。つま先立ちするにはまず、重心を指示多角形の端に移動させ、それからかかとを上げるという手順が必要。
下半身姿勢としては重心点の管理もしなければならないのだが、瞬間的に移動する重心位置（相対的に、ではあるが）をどうフォローするかが難しい。かかとを上げるためのプロセスといったものが必要になるのかも。。
下半身姿勢の中でつま先立ちの姿勢に制限を設けるべきかどうかも悩ましい。左右の足毎に路面の傾斜を持たせれば自由度は上がるが、ありえないような姿勢を表現するために通常のほとんどの動作のための処理を増やすってのもどうかなーと考えてしまってなかなかまとまらない。
つま先立ちからの1歩ができたとして、指示脚は1歩後はつま先を降ろすべきだろうか？次の1歩で降ろすべきだろうか指示脚はつま先立ちのままの方がよさげなのだが、２歩で対応する必要があり、更に敷居が上がるような気もして決めがたい。
まー、そんなこんなで悩みは尽きないのだが、今日はサーボの改良について双葉電子へ渡す資料を作るためのプログラム作りとテストをおこなっていた。
いま、ラムダはコマンド型サーボをPWMサーボのように定時周期で角度指示を与えるという制御をおこなっている。もちろん、PWMサーボではないので角度変化がないときはコマンドは送らない。
だが、これだとどうもトルクが目減りするようなのだ。ただでさえトルク不足なのにつら過ぎる。比較的短い時間で時間付きデータを送ると、今度は追随性が悪くなってしまう。トルクも更に落ちるようなのだ。その辺りの状況を示す資料を作っていた。
大体、リニアな角度変化でサーボを動かせることなどほとんどないのにそのケースでしか性能が発揮できないロボット用サーボってどうなんだろうなぁ。
双葉電子のがんばりに期待したい！
■６月２１日■
下半身姿勢に「路面の傾斜」を組み込むとすると、下図のようになる。
路面にもいろいろあるが、体系立てて考えるとなるとこんなとこかと思う。
だが、今やりたいのは斜面を歩くことではないので、次の図のような状態も表現しなければならない。
ということで、表現方法は各足ごとに足部の傾斜を示すパラメータを持たせることになる。
姿勢全体を考えると、次の図のようなことになる。
つま先立ちしていない状態からかかとを上げた途端に、重心の基本位置が変わる。上げる角度によって徐々に変わるなら考えやすいのだが、数値上ちょっとでもかかとが上がったら重心位置がズバッと変わってしまうのだ。これ、どうやって処理しようかなー。いままではなんだかんだといっても線形動作だったのに非線形動作になってしまう。
①先に重心位置をシフトしておいてからかかとを上げる。
②かかとを上げるに伴って最終的な重心位置へシフトする。
②は処理が簡単なのだが、かかと上げ角度が小さい場合はうまくないので、やはり①。 普通人間の動作は①だね。
あといくつか考え方をきめておかなければならないことがあるのだが、細かなことなので省略。 以上のことを配慮してつま先上げのモデル化に着手しよう。
■６月２３日■
今日は先週の続きで板金工作。
朝早くからは音を出せないので、１０時くらいまではプログラム。
今まで座標変換は三角関数に展開していたのだが、回転行列による計算はクラス化して記述した方がいいよなーと今更ながらクラス化したりしてた。
で、夕方まで板金一筋だったのだが、、 今日はもう敗北感でいっぱいです。(T_T)
新しい上半身フレームは板厚1.5ミリで曲げの長さが一番長いところで90ミリくらいある。自作総檜造板金折り曲げ機では100ミリ幅の曲げをすると檜部分がたわんでしまいうまく曲がらなかった。こないだ届いた折り曲げ機はたわんだりはしないだろうが、レバー式なのでねじ式の自作曲げ機に比べるとパワーの面では劣るだろうと思い、どれくらいまでの曲げ能力があるのか事前に確認する必要がある。
で、どれくらい曲がるのかをテストするテストピースを作った。70ミリ～100ミリ
曲げてみる。
結果はこれ。
70ミリがまともに曲がらない。80ミリはぜんぜんだめ。 自作曲げ機だと80ミリはきれいに曲がってるんだよねー。
まぁ仕方がない。レバー式だからある程度は予想していた。それにしてもなんとも曲げ機の動きがおかしい。80ミリを曲げる時に全体重をかけたからおかしくなったか？分解したりしてガチャガチャやってたらレバーがさっきよりもっと回るようになった。（まだ挙動不審だが）鋭角曲げまでできるようになったぞ。ん～、もしかしてストッパーを壊しちゃったかなー？まともな動きがどれかわからんからなんだかわからん。
板厚１．５ミリは60ミリまでしか曲がらないものとして設計を見直す。60ミリ以上の部分は曲げ部に穴を開けて応力を軽減。 この手法は取りたくなかったのだが、仕方がない。
さてー、切り出そうかなと思ったら、、、あれ？バッテリーカバーが板厚1.5ミリに面付けされてる？？おかしいなーと思って確認すると設計は1.2ミリでやってた。あぁ間違えた～穴あけから肉抜きまでやっちゃったよ、無駄作業だったなー。しかたがないので1.2ミリで作り直した。1.5ミリが最大60ミリ程度なら1.2ミリなら100ミリくらいはいくかなーと皮算用で、バッテリーカバーは95ミリ幅を曲げてみることにする。
で、Z曲げ部分で驚愕の事実に直面。 Z曲げ寸法が浅すぎ。。。 がーーーん。 カンペキにチェック漏れです。orz なさけねぇ、なさけねぇです。さらには肉抜き穴がダイから漏れて綺麗に曲がらない。 今回の設計はあせり半分で気合が入ってない気がしていたのだが、ひど過ぎる。
どうしようもないのでヤケになってむりやり曲げてみた。むちゃくちゃデス。
むぅぅ～、ボディーフレームを曲げるのが怖い。。。
バッテリーカバーは設計が気に入らないので、設計見直しします。ねじ４本止めってのは実戦的じゃないもんね。バッテリー交換の手間がかかりすぎ。
■６月２４日■
今日は午前中にマンションの理事会の総会がある。最近は出席していなかったのだが、再来年はまた理事が回ってくるのでそろそろ出席して時勢を認識しておかなきゃならん。 10時から始まって1時間くらいで終わるかなーと思ったら意外と盛り上がって、終わったのは12時だった。
お昼を食べて、午後からは昨日の続き。騒音の出る切り出し作業は昨日終わらせたので、（バッテリー部分は再設計なので、設計したら切り出さなきゃならないが）今日はヤスリ仕上げと曲げ。
どうやら輸入版板金折り曲げ機はダメですね。もしかしたら昨日の限界テストで壊してしまったのかも。幅のある部品はうまく曲がらないので自作折り曲げ機と併用しました。自作版だけじゃできない設計になってるのでどちらも使わなきゃならなくなって余計手間がかかってるかも。小さい部品は概ね大丈夫。レバー式だから簡単に曲げられてまぁ良い。 折り曲げ機の挙動がおかしいのについては、一度分解して何がどうなってるのか調べて見なきゃならないなー。
なんだかんだどたばたしながらもなんとかフレームが完成しました。下半身ベースフレームと上半身ベースフレームの連結構造に（強度的に）気を使った設計をしたのだけれど、板金の製作精度が悪くて組み立てるのが大変でした。
最後にCPUユニットを取り付けようとして、一ヶ所曲げた後に削り込まなければならない個所があったのを忘れていた。 ふむぅ～、分解するのはもういやなのでスペーサーを入れて逃げることに。。
以前から頭ユニットは取り付けないで動かしていたのだけれど、上半身旋回軸のサーボモーターがアタマっぽく見えていたので完成体っぽかったのだが、今回はその辺りがそっくり削除されたせいで本当にアタマがない感じになった。（本当にアタマがないのだけれど。。）
右は取り外した胴体の２軸部分。きっともう二度と使うことはないのだけれど、大事においておこう。
新ラムダフレームにはLEDとマイクが実装されていない。マイクもLEDもロボカップには必要ないんだけど、、、いや、LEDは状態表示用にはほしいかな。マイクは後日検討。
これで、体重は少し軽くなり、重心は少し低くなり、上半身の剛性も少しあがったはず。歩行にはいい条件しかないのだから少しはシャキっと歩くようになってくれよぉ～。
サーボの配線ができていないし、CPUの取り付けが不十分なのでまだしばらくは動かすことができないのだ。部品買いに秋葉原行かなきゃ。
■６月２５日■
CPUユニットの固定や無線LANカードの固定が適当なのではあるが、とにもかくにも動かしてみようということで、動かしてみた。
今回はサーボID1と2をあてがっていた胴体の2軸が削除となったので、全サーボのIDをつけ直した。プログラム的にも配列のアドレスとIDをリンクさせてしまっているところがあって、事実上IDは括り付けになっている。良くない記述なのだが、今回はそのままにしてIDを振りなおした。
股関節の稼動範囲が広がったのだが、おかげで股関節サーボの角度設定にオフセットを設定しなければならなくなった。 で、オフセット値を直したのだが、それに合わせて稼動最大角度最小角度の設定を修正しなければならない。 ここでもまた良くないプログラム。 論理角度で最大最小を設定できればオフセットが変わっても記述を変えなくていいはずなのに、絶対角度で記述するようにしているため、オフセット値に合わせて修正しなければならない。 まぁ、オフセットを変更することがそうたびたびあるわけではないが、比較的簡単に修正できるので、論理角度で記述するように変更した。スッキリ（*^_^*）
いろいろ固定が不十分なので、こかせるわけには行かないのだが、歩かせてみた。
動きが軽い。ちょっと力強い感じ。でもさっぱり歩けない。重心位置が変わったからまー当然かなー。モノを持ったら歩けなくなったりするのはかっこ悪いのでそういう物理変化にも対応できるようにしていかなきゃなー。 で、歩行の方は重心高さ設定値を変更することでまぁ歩けるようになりました。まだ微調整が要りそうだけど、こういうところは計算で歩容を作っている強みですね。 モーションデータで歩かせている場合だと、これはもう大変なのではないのでしょうか。やったことないのでわからないけど、歩行モーション作るのって大変そう。アイボを歩かせていた時もそうだけど、モーションで歩行をさせるのって根気の要る作業だろうなと思う。ぼくはちょっとやってできなくてあきらめました。論理組み立てる方がずっと楽だなーって思いました。
軽いっていっても、バッテリーも頭部ユニットも搭載していないので軽くて当たり前。削減した重量分くらいは増量する予定だから結局重さこないだまでの重さに戻る予定です。こないだよりは重くならないようにがんばろう。 ＃外装つけたらもうオーバーだけど。。。
■６月２７日■
一ヶ月前に注文したRS302CDが届いた。発売が遅れたみたい。問い合わせするまで何の音沙汰もないのはいかがなものかなー。
サクッとCADで描いたのだが、これってどうやって固定するのかなー。このネジは使いたくないなー。
今日現在はどこにもサーボコマンドが掲載されていないようで、RS601CRと同じようなコマンド形態ならいいんだけど、メモリーマップやプロトコルが違っていたら資料がないと使えない。まぁ急がないのでちょっと待ってコマンドわからないようなら問い合わせてみよう。
アタマ設計したいけどなー、何から先に手をつけたらいいのかわからんようになってきた。
胴体の２軸を削減したので、サーボが２個余る。もちろん予備として使うつもりなのだが、膝をダブルにするとか、股関節を２サーボにするとか、使い道ないかなーとか、足の形状をもう少し見直して見栄えをよくすることはできないかなーとか、あまり重要ではない案件でCADを眺めて今日が終わってしまった。いかんなー、せっかく今日は早く家に帰ってきたのに時間の無駄遣いだ。
■７月１日■
この週末はずーーーっとつま先立ちからの歩行と格闘してました。
格闘といってもほとんど脳内。 どうしてもコーディングのイメージができなくて作業をすすめることができなかった。
土曜日にはつま先立ちを含めた下半身姿勢はできたのだが、つま先立ち状態とべた足のときの重心点の変化を吸収するいい手を思いつかなくて歩行（＝下半身姿勢移行）ができなかった。ずーーっと考えてて、どんどんと時間だけが過ぎていくものだから、合間にサーボの動作テストをやってみたり、
サーボの動作テストの様子。ラムダの背中から無数のサーボがうにょろうにょろと。。。
ずっと気になっていたネジが接触する部分を直してみたり、電源をいれずにラムダを立たせてみたり、
立った！ラムダが立った！ こう見るとバランスいいように思うのだが、やはり後ろに重心がずれてる。
買い物に行ってみたり（ふらりと買い物に行ったらバーゲンだった。バーゲンはわさわさしてるのでキライ。 でも安く買えてよかった）
ですが、先ほどとうとうつま先立ちからの歩行のコーディングが完成して、どうやらちゃんと動いているようです。
つま先立ちからべた足へ、またはその逆へ、という移行は今のところ遊脚でしかできません。指示脚がつま先立ちからべた足になるとおかしな動作になってしまいます。使うかどうかは別にして、これも折り込みたいなとは思っておるのですが、指示脚の接地点が移動（ワープといった方がいいか）するのは許容しがたいなぁ。ワープする分を見込んで遊脚の着地点をきめなければならないわけだな。ふむ。。。。
これで転倒回避の成功率が上がればよいのだが・・
つま先立ちでの歩行のプログラムに手間取ったのは、つまずき対策でつま先を上げながら遊脚復帰したり、遊脚がけり足の時につま先立ちになったりする歩行もサポートできるようなプログラム構造にしておきたかったからです。 ホント、歩行だけでメシが何杯でも食べれちゃう。そろそろ転倒回避も佳境なので転倒受け身や立ち上がりのことも考えなきゃならない時期になってきた。立ち上がりってどうやろうかなーとラムダを動かしながら考えていたのだが、四つん這い姿勢とかハイハイからの立ち上がりとか、面白そうだなと思ってしまった。モーションでできることを難しーくやっても仕方ないっていうか、立ち上がり動作だけ考えてもまたメシが何杯も食べれちゃうからいい加減にしないとな。
■７月２日■
つま先立ち状態からの１歩に関していろいろテスト。
思惑では ①⇒② または ①⇒②⇒③ で転倒回避をしたいなぁと考えていたのだが、
① 両足つま先立ち。 転倒回避歩行ではまっすぐ立ってたのに押されて倒れかけの状態を想定している。
② 前に出した足はべた足。 残っている足（この場合は後ろ足）はつま先立ち。
③ 更に残っていた後ろ足も前に出して、べた足に。
最初の１歩はなかなか難しい。 ②⇒③は結構安定しているのだが、②の状態で立っているのが難しいので、不安定な動きの後に②状態というのは考えにくい。そこで、
④ １歩で一気に両足をべた足に。
これがなかなか成功率が高そう。昨日も書いたが、支持脚がつま先立ちからべた足になると歩行計算上の原点が動くことになるので動きがおかしくなる。プログラムは更に改良する必要があるが、ジャイロフィードバックと併用することで少しは安定した転倒回避歩行が期待できる。さらに改良せねば～。
やりかたとしては0.1degだけつま先立ちさせるとかすれば今のままのプログラムのままでもおかしな動きはしないのだが、やはりちゃんとしたいなー。
RS302CDの取扱説明書が双葉電子工業のホームページに掲載されていた。よかったよかった。コマンドは、ほぼRS601CRと変わらないようだ。動かしてみたいな。電源作らなきゃ。あ、コネクタを買っておかないと。
頭部の設計製作はまだ先になりそうなのだが、工作系は前倒しした方がいいかもしれないな。真冬に外での作業はキツイし。早くアタマをつけてみたいし。
■７月４日■
支持脚がつま先立ちの状態から１歩で支持脚をフラットに持っていけるようになった。
支持脚の姿勢が変わるってことは、普通はこんな感じ↓なのだが、
こんな感じ↓になるということ。
指示点はつま先立ちの接地点とするのだけど、ターゲット姿勢ではべた足になるので基準点が変わる。ここでの処理に一工夫いるのだ。 どんどんと判読不能なコードになっていくな。この日誌とソースのコメントだけが頼りになるはず。しっかり書き込んでおこう。
未来の自分へのメモ
・倒立振子の原点はつま先として、スタート座標とターゲット座標を決定する。
・歩幅（depth）の移動量からは図の重複部分を差し引いておく。
・遊脚の着地時点で足の姿勢変更を完了。
・重心点の計算は最後までつま先を原点として計算するので、姿勢に組み込む際につま先とべた足中央との差分を差し引く。
いちおうはできたのだが、まだいろいろと制約があって完成とはいえない。たとえば今日現在は足部のロールには対応していないので、足がロボットの進行方向に向いていることを前提としたプログラムになっている。使うかどうかは別にして、ロールが任意の角度にあるときでも正常に動くようにはしておきたい。
ちょっと動かしてみたのだが、支持脚をつま先立ちにしたままの時よりは安定している。これを転倒回避歩行に組み込めばできることはほぼ全部やったことになるなー。結局は全部入りなんだな。
新ラムダ、 胴体の軸をなくしたので胴体の剛性は格段に上がったはず。 こないだまではこけると、「グシャー」って感じだったのだが、今はこけると「どーん」って感じ。 受け身教えたい。(T_T)
次はとうとう転倒回避歩行への組み込みだ。姿勢のX軸回転の関数を作らないといかんな。
■７月７日■
ロールのサポートとデバッグ。多分、バグは取れたと思うのだが、動きを見る限りおかしくはないし、変数の動きも考えている通りに動いているように見える。 なにせ、妙な操作の塊になってしまっているので変数の動きを見てもうまくいっているのかどうかちょっと判断できない。３日たったらソース読めなくなるんじゃないかと思う。いや、それは言いすぎか。そんな難しいプログラムじゃないもんな。
検証するのにはいろんな組み合わせの設定を試してみないといけないのだが、ざっと試した範囲ではまともに動いていそう。
結局、支持脚がつま先立ち（および踵立ち）からべた足になる場合も、べた足からつま先立ちになる場合もサポートできた。ただし、軸足がつま先立ちから踵立ち（またはその逆）という変化はサポートしていない。
ではでは、これを転倒回避歩行のルーチンにも適用しましょう。 と、思ったのだが、これがなかなか難しい。普通の歩行の場合はターゲット姿勢が決まっているので、そこから逆算して、仮の重心点の到達点を決めて、遊脚が着地する瞬間にターゲット姿勢にすり替えて、、という感じの処理をしているのだが、転倒回避歩行の場合は、ターゲット姿勢が決まってないので、外力などから遊脚の着地点（とか、重心点の到達点）を決めて、最後にターゲット姿勢を決めるという感じなのだ。
処理の順番をいろいろと変更して、転倒回避歩行の関数にも展開することができました。ほぉっ、よかった。
まだ、姿勢が斜めになった時のつま先立ち状態を入力していないのだが、テストしてみることに。明日には転倒回避歩行に終止符を打てるかなー。
そろそろカメラに着手しないとな。
体重が軽くなったせいか、転倒回避歩行の成功率があがってるなー。つま先立ちサポートする必要なかったかも？ まぁ、バッテリー積んで、カメラを積んだら重くなるからあまり意味がないのだが。 それより、歩くのは下手になった。１歩0.4秒はふらふらする。0.3秒の方が安定している感じ。これも重心が変わったりしたせいで、もうちょっと調整がいるのかなと思ってる。
ずいぶんと前に、足構造を変えたとき、ケーブルの長さが不適当になったからそのうち作り直そうと思っていたのだが、それなりに整線したらなんとかなった。明日は腰回りの部品にケーブル固定用の穴を追加しよう。
■７月８日■
うまく動いているように見えた転倒回避歩行はまだバグが残っているようです。今回のコード修正でバグを折り込んだが、こないだから残っていたバグが修正により発覚したかは定かではないのだけど、ひどいバグはとりあえず退治。 まだ支持脚の決定ルールに不足があるようで、動かしていると、だんだん足がねじれてくる。(ーー;)
転倒するときに姿勢を数値だけ回転して、転倒線を進行方向に向けているため、一見前を向いて立っているように見えても姿勢データ的には斜め前に進もうとしている、ということがあるのだが、ちょっと見てもわからない。デバッグがしにくくて困る、自分で作っておいてアレだけどね。
その後、普通に歩かせてみると遊脚軌道にもなんかおかしなところが。足が上がらないのでうまく歩けないんだ！
なんだか、今回の変更でずいぶんとバグを巻き込んだようです。来週はデバッグだなー(T_T)
そういうわけでまだ転倒回避歩行の旅は続きます。これやりながら、カメラに着手することにしましょう。
今日は、サーボのトルクを測定（というのは言いすぎだな）しました。 サーボを時分割データで使っているのだが、時間データを指定して使用するときに比べてトルクが小さくなっているようなので、その辺りを検証しようと思う。
ううむ、ゴミ箱とか写ってるな。みっともない。
紐でつながった重り（雑誌）を肩のサーボで引き上げるテスト。 結果としてはやはり時分割制御の方が少しトルクが落ちるようです。思ったよりは差がなかったな。
それよりもトルクが小さいな。このやり方だとロスが大きいから、この後真下から引き上げるカタチにして、再度トライ。腕の長さ20センチで630グラムを引き上げるのに成功したので12.6kg・cm 腕が重いから、その分も計算したら、大体15kg・cmでした。スペックは21kg･cmなんだけど、動作トルクだとこんな感じなのだろうか？
ちなみに停止トルクだと20kg・cm以上はありますね。
■７月１１日■
転倒回避歩行のバグが大体わかった。
二つの大きな問題があって、まずひとつは以前に気づいていたことなのだが、速度起因での転倒回避を行う場合、そのときの姿勢を考慮していないこと。つまり、速度がある程度以上あれば姿勢にかかわらずに転倒回避歩行が起動してしまう。動作速度が速すぎることからくる転倒は、このモードで転倒回避するのだが、に向かっている状態で起動してしまうと厄介なことになる。 転倒回避開始時の姿勢を加速度センサーのデータで取り込むようにしたところ、転倒方向とは逆に傾いている姿勢から転倒回避が起動していることがわかった。（もちろんそうなるのは必然なのだが）
次に、転倒回避歩行の計画を行う際に、入力データのうち、転倒に関与する方向の速度の何割か（今のプログラムでは5割）を入力速度として計算している。更には入力となる転倒方向の速度は、振子が登頂に差し掛かった時の速度を取っており、転倒動作の中でもっとも速度が小さくなる時の速度を使っている。これはブレーキの概念も必要だと思い、外力にある程度逆らったことをイメージして目減りさせているのだが、一律でこのようにしているため、ギリギリ転倒するような速度の場合には5割減したために倒立振子の転倒方向が反転してしまうケースが発生する可能性があった。
二つのケースが合わさる場合、転倒感知時の姿勢が、倒立振子の重りと支点の関係が大きく傾いているケースで、転倒回避歩行の計算上の初速が小さいというケースが発生し易くなる。 このため、足を出す方向が逆転する、支持脚が逆になる、足がねじれてしまうといった現象が発生してしまうことがわかった。
早い話が、転倒歩行計画には折り込んでいる加速度センサーによる姿勢を転倒判定では折り込んでいないこと、それと、減速することにより倒立振子歩行が破綻することへの配慮の二つが漏れていたということだ。
では、どのように改修するかということなのだが、転倒回避歩行の結果の目標姿勢が反転してしまう件についてはガードすることもできるのだが、転倒反転の方をどうしようか。
転倒判定式に加速度センサーからの姿勢データを取り込む必要があるのは明白だが、接地点が途中で変わる倒立振子となるので計算が複雑だ。
ケースとして、①支点が変わるケース ②支点が変わらないケースに分けられる。
①の場合、支点が切り替わる点の重心点の速度ベクトルが計算できればあとは従来の計算で判定できる。
②の場合、はいままでどおりの計算なのだが、足の姿勢として路面の傾斜（この場合はつま先立ち、踵立ち）を考慮すると複雑になる。これは傾斜をパラメータに入れたことで支持多角形の計算が今までどおりには行かなくなった関係で、支持多角形が直線や点になるケースも発生することをどのように配慮すべきかということ。
もともと、路面の傾斜を足の姿勢に取り込んだのは、この、傾いた状態のコケかけている途中の姿勢を表現するためだったので、②の一般化については考慮しないでもかまわないだろう。①なら計算できそうだ。コケルことがわかるのであれば早い方が良い。
■７月１４日■
転倒回避歩行をどうすればいいのかわからないので、頭部の設計とかカメラの検討とかをしてみる。
左のカラーCCDカメラをラムダに搭載しようと思っているのだが、視野が狭いので、隣のドアカメラの超広角レンズを搭載しようと思っている。でも、レンズマウントは径が1ミリ違うのでマウントから細工しなければならない。ピントがあうかどうかも怪しい。
画角を比較すると、 左がカラーCCD普通のカメラ、右が超広角レンズ
同じ位置から撮影してもこんなに違う。 画角にして、70度と120度くらいの差。結構大きな差。 本当は150度とか180度という超超広角レンズが欲しかったのだが、小さくて軽くて安いのは見つからないのでこれでもいいかなと・・・。超広角になると周辺のひずみが問題になるかと思って補正の数式を考えたりしていたのだが、これくらいなら補正しなくていいかもしれない。ハフ変換で直線抽出するとかしなけりゃまぁいいでしょ。
さて、うまくレンズの移植ができるかどうか。。。
マウントの規格についてちょっと調べてみると、ボードカメラに使われているのはミニレンズと呼ばれていて、マウントの規格はφ12P0.5とφ13P1.0に大別されるみたいです。スピーシーズロボットにについてきたカメラと、改造してラムダに載せようとしているカメラのレンズはφ12P0.5、で、超広角レンズはφ13P0.75というものでした。うむむぅ、規格が大体わかったのでφ12P0.5のミニレンズで超広角レンズを探してみたところ、いくつかみつかりました。下の画像はf1.9mm F2.0という超広角、5800円也 もうひとつはｆ1.78mm F3.0 6200円也 ただし、ピントがあうかどうか微妙。ピントが合わないとゴミだもんな。難しいところだ。
焦点距離と画角の関係と撮影画像の比較が掲載されているページを見つけた。
画角170度は魅力だが、デカい重い長いのに比べて画角150度はいい感じ。4800円だし、これを買ってみようかな。ｆ1.9mmのはどうも怪しい。比較のページでも取り付け不可になってるし、ピントが合わないような気がする。
■７月１５日■
レンズ探しの続き
f1.24mm F2.0というのを見つけた。（左の画像）9800円也。昨日の6200円のより小さい上に画角はもっと広いと思われる。でも、紹介文に「ほぼ、360度に近い範囲を写し込める。」とあったのだが、これは180度の誤植ですね。一瞬「おお、すごい！」と思ってしまった。 小さいといっても十分でかくて長い、軽いといっても昨日のと比べて2g軽い程度。180度の視野には惹かれるけれど、やっぱり（右の画像）こっちのが安くてよいかなー。f2.45F2.0 4800円也。
転倒回避歩行の検討で、ソースコードを眺めていたら、軸足が べた足⇒つま先立ち というパターンを許容しているのにコーディングしていないことに気づいた。
どちらも、遊脚復帰期間に移行するのだが、補正が後にはいるか、先に入るかが異なる。 原理はわかってるので、さっさとコーディングしちゃうおうと思ったのだが、待てよ？チルトとパン角があるのだが、チルトは⇒0 パンは0⇒ というパターンの時はどうするんだ？ ほとんどありえない組み合わせとも思えるのだが、ちょっと興味本位で検討してみた。
図は支持脚の足部を表している。赤丸は接地点、矢印は移行を示す。
いま対応している移行パターンは左上の図。 ついでに実装しようかと考えたのが右のパターン。だが、左下の紫のタイプも対応したくなる。紫の移行タイプは直線的には移行できないので、Aの経路が考えられる。Bの経路は中心が接地点となるのは特異点なので終端にしか置けない。そのため、遊脚復帰期間中に移行することを考えるとA経路になる。
だが、実際、足部の角で接地しても安定しないので事実上使えない実装になる。
そこで、姿勢移行時間（1歩の時間）の4割程度が加速時間（重心移動時間）であるのに着目し、Bの経路を実現する方法に気づいた。つまり、図左上の移行を加速時間に行い、図右上の移行を遊脚復帰期間に行えばグレーとピンクの経路の組み合わせで表される移行パターンはすべて対応できることになる。
図左上のタイプなら両足支持期間に移行するので安定した移行も期待できる。 ただ、加速時間は短い場合もあるのでその辺りで制限が発生する。A経路は事実上１パスなのに対して２パスになるのも気に入らないといえば気に入らない。
ちなみにB経路や角度の符号が反転するような移行を遊脚復帰期間に移行する手段がないわけではない。二つの倒立振子を連結したような軌道を考えれば可能。
加速期間中に足部の姿勢を変更するという考えは、遊脚にも適用すれば歩幅拡大の際に役に立つ。 じゃ、早速ということで実装検討を始めたところ、勘違いに気づいた。
２パスになるわけだし、結局は支持脚の接地点が変更することには変わりがない。二つの倒立振子の連結は必須だった。 せっかくだからいまサポートしている移行パターンだけでも加速期間での移行タイプのプログラムを作って具合を見てみることにした。
マクロで切り替えてコンパイルできるようにして比べてみたが、遊脚復帰期間に移行するタイプの方がなんというか一体感がある。加速期間に移行するタイプは取って付けた感じ。 同じ遷移時間（0.4秒）なのに加速期間に移行するタイプはついて行ってない感じ。
どっちが優れているかは状況で分かれるのだろう。遷移時間が長いときは当然加速期間タイプ、短いときは遊脚復帰期間タイプといったところか。重心位置によっても得手不得手がありそうなので、両方とも実装して選択できるようにしなければならないのかもしれない。
倒立振子の支点移動（二つの倒立振子の連結）の件はまたいつか機会があれば。
転倒回避歩行についても全然進んでないわけじゃない。
問題は
①前後方向の初速に減速限界がある。初速の最低値を守らなければならない。
②転倒判定時に姿勢（足部の一部が浮いてしまっている状態）を反映しなければならない。
この2点である。
特に②は問題の倒立振子の支点移動が発生する場合を考慮しなければならないということ。①は軌道エネルギーから逆算すれば簡単に算出できる。考えねばならないのは最低値を考慮した初速の決定手順。
つま先⇒べた足 と、 べた足⇒つま先パターンを共有できるプログラム記述を思いついてしまったので、結局、図のAルートの移行方法を組み込んでしまった。きっと使わないだろうし、本当は倒立振子の支点移動を実装した方がいいのだが、まぁいいだろう。パズルを解いたようなすがすがしい気分がしないでもない。(*^_^*)
明日こそは転倒回避をやろう。
■７月１６日■
転倒回避歩行のための整備をいろいろ。
いままでは高さパラメータをくるぶしを基準としてきたのだが、足裏に変更。足部の傾斜をパラメータに加えた時に一気に変更すべきだったのだが、影響を検討するのが面倒だったので先送りにしていた。
べた足⇒つま先立ち のパターンで、足部のパン角が加わるとちょっと動作がおかしい。散々悩んだ末、倒立振子動作モードが単純振子の場合におかしくなるらしい。線形倒立振子動作なら問題なし。通常使うのは単純振り子なのでちょっとモヤモヤなのだが、原因の所在がわかったのでおいおい解決方法を考えよう。
これに関連して、単純振子動作に使う振り子動作関数の見直しをした。いままでは接地基準点を中心に回転させていたが、正しくくるぶしで回転させるようにした。
そういった準備がほぼ終わったので、前後方向（転倒線）の姿勢回転を考えたのだが、結構難しい。足部の傾斜がある場合などを正確に考えると転倒線の考え方も変わってきてしまう。現実的な線である程度姿勢を絞り込んで考えねばならないだろう。 ちなみに計算する内容はただの座標回転なので簡単。すべての状態を考えてプログラムするのが難しいということ。
減速限界の考え方がまとまらない。この状態だとプログラムできないんだよなー。イメージがまとまるとするすると進むのだが。
■７月２１日■
昨日は注文したレンズが届いたので早速カメラに取り付けて具合を見てみた。
愕然。。。 全然画角が狭い。。。 大体85度くらい。。 何が何だかわからなくなり更にいろいろ調べてみたら、ちょっとわかってきた。
画角は焦点距離で決まるので、単焦点レンズの場合は結像面での画角は決定。ただし、撮像面の面積で若干変わってくるため、実際の画像の画角はカメラによっても左右されるらしい。
f=2.45ならCCDが1/3インチなら画角105度、1/4インチなら画角80度くらい。f=2.45mmで画角150度ってのはありえないだろうな。誤植か、もしかしたら対角画角で表示をしているのか。 でも、今回レンズを買った通販ショップは画角を掲載してなかったからこちらのミスです。orz
実測で画角が90度程度っていうことはCCDが1/4インチだったのかー、じゃ、1/3インチのCCDカメラを買わなきゃならない、、と思って調べてみたのだが、どうやら持っているカメラはすべて1/3インチらしい。1/3インチのCCD撮像面は4.8×3.6、1/4インチの場合は3.6×2.7。 持っているカメラを調べると見た目には1/3インチ。 じゃ、有効画素範囲がチョイ狭めなのかも知れない。サンプル画像と比べてみても、1/3インチだと4隅にケラレが出だすらしいがケラレはまったく見られない。 どうやらレンズの画角よりせまめにしか撮像できないらしい。ショボン。。カメラも見直した方がいいかもなー。
ここまで調べる間に衝撃的に安い通販ショップを発見！ なんと、f=2.45のレンズだと1800円！ 選択ミスした上に高め引いてしまった。大チョンボ。。 ま、済んだことは仕方がない。せっかく安いところを見つけたんだからここでレンズを買い直そう。
候補はこないだも候補に上がっていた、でかいf=1.78 F=2.5、それと小さいf=1.78 F=3.0。 小さい方がいいのだが、暗いのが気になる。静止画撮影ならば問題ないのだが、動画撮影になるため、シャッタースピードが遅くなる（露光時間が長くなる）と、モーションブラーが大きくなってうまくない（と思う） そのためにわざわざCMOSカメラをCCDに変更しているのにレンズで損したらもったいない。この程度の明るさの差なら、屋外ならば問題ないのだが、室内は意外と暗いので影響は大きい（と思う）
更には小さい方は短いのでピントが合わない可能性がある。その時はカメラ側のマウントを改造しなければならない。 改造するとでかい方のレンズは取り付かなくなる可能性が高い。またまた冒険の予感。ひぃぃ～。 反してでかいレンズはやはりでか過ぎるかなと、顔が目玉親父になってしまうのもイヤだし、なにより重いレンズをブンブンと振り回すのはいろいろ不安。ここは軽い方がいい。 ちなみに9800円のf=1.24という選択もあるのだが、あれはケラレのエリアが大きすぎて別の不安が大きい。値段も高いし今のところはボツ。
各パラメータを比較してみる。
サイズ 重さ 焦点距離 明るさ 期待画角 シャッター速度 でかいやつ φ30×25mm 15g f=1.78 F=2.5 155度 1.6倍 ちっこいやつ φ18×15mm 5gくらい f=1.78 F=3.0 155度 2.3倍
シャッター速度は標準的なレンズ（F=2.0）を基準としたときの遅さで表した。直径が倍くらい違うので正面から見たときの面積は4倍違う。重さは10g程度と思われるが、その10gはほとんどレンズ先端部分に集中している。シャッター速度の違いは気になるような気にならないような。。
でかいやつを採用するときにはレンズ先端に重心が偏るのでブンブン振り回すことを念頭においたカメラの配置をしなければならず、今の検討ではまずい。逆にちっこい方は軽くて小さいので配置には制限はないだろう。 ・・・ 重さに対してサーボのトルクは十分だし、あんまり気にしなくていいって気もしてきた。
注文できるのはどちらにしても週明け。 こればっかり考えていたら土日が終わってしまうのでこの件は凍結冷却。土曜日の夜に注文しよう。
■７月２２日■
軸足がべた足⇒つま先立ちとなるタイプでpan角が発生するタイプの動作だけがうまく動かなかったのだが、やっとこれが解決した。
原因が仮想重心点を使った単純倒立振子動作にあるということを突き止めたので、しばらく考えるのをやめていたのだが、ふと解決策が浮かんだ気がしたのでちょっと手をつけてみた。平行動作の場合は偏差を足したり引いたりするだけで補正できたのだが、回転動作となるとそう単純ではなく、基本姿勢の重心点の位置が違うことであちこちに誤差がでてしまうのが原因だった。
線形倒立振子用のオフセットパラメータを併用したり、さらには初期姿勢からオフセットを線形増加させたりしてやっと落ち着いた。ふぅ。。
で、今日こそは転倒回避歩行に進展を、ということで着手した。
結局、いろいろと検討したのだが、転倒判定は両足ともにべた足で、平面に立っている時を考えることに限定した。そして、支持多角形の辺を直線ではなく、ベクトルとして捉え（つまり方向を持つ）、そこに働くモーメントベクトルの方向で転倒方向を判定することにした。
支持多角形の算出関数から転倒線候補を抽出してリスト化したりベクトル化したりするようにプログラムを修正していくこととなる。
一方、絶対使わないのだろうが、せっかく作った「べた足⇒つま先立ち」動作を転倒回避歩行の関数に適用したりしていたのだが、動作テスト中にあまりにも転倒回避歩行がおかしな動作をするので（くだらないバグをここで発見してつぶした）、問題視している斜め姿勢化の部分を削除して動作させたところ、足のねじれ現象が発生した。
こないだ考えていた重心位置の問題だけではなかったのかー。 ということで、遅まきながら、動作ログを採取できるようにプログラムを修正。動かしている間は様々なログをファイルに残しておくようにした。とりあえずはログがあふれないように通常歩行と転倒回避歩行のみ詳細ログを取ることに。
ログを取りながら動作させてみて、とうとうおかしな部分に突き当たった！ 転倒回避を繰り返して、おかしな姿勢になっているときに通常歩行を行うとその後の転倒回避歩行で足がねじれ出すらしい。 詳細ログが取れたのでおいおい原因は解明できるだろう。
カメラの件だが、CMOSカメラにも取り付けてみた。これはスピーシーズロボット標準のカメラなのでアプリで表示。やっぱりケラレは出ないらしい。手前の湾曲度はCCDよりも大きいような気がするな。
無圧縮で画像を送ると大変だ。1フレーム31kBもある。 圧縮するか間引くかしないとな。 画像処理するにしてもこれじゃ大き過ぎて処理に時間がかかってしまう。
起き上がりや特殊姿勢での動作を考えていたらだんだんワクワクしてきた。そろそろ上半身クラスも考えようかな。
歩行以外の動きもさせてみたくなってきたのでとりあえずモーション再生もコーディングしようかなーとか。やれば簡単だろうし。。
■７月２３日■
昨日の夜に注文メールを出したレンズ。 受注のメールですぐに代金振込み。 今日のうちに発送の連絡が来ました。明日には届くかなー♪ いや、リスクありありだから気を引き締めて！
転倒回避歩行のおかしな挙動は簡単なバグをひとつ発見。相当まともに動くようになった。 重心が変わったおかげで前にだけは結構な確率で転倒回避に成功する。つま先とか検討する必要なかったかーと思わせるほど。 背中をポンポンと押していけば1歩ずつ進んで歩いていく感じ。「さぁさぁ、早く行きなさい。」ってー感じ。 でも、機体のバランスをよくして動きをよくするのって違うんだって位置づけで開発してるのでそれはそれ、これはこれ。相変らず後ろに対しては全然ダメだし。
ちなみに転倒回避の時は（今の重心バランスでは、という前置きが必要だが） 仮想重心点の設定をクリアすると安定する。 歩行は、仮想重心点＋加速時間大、または仮想重心点なし＋加速時間小 で比較的安定して歩く。 ただし、仮想重心点なしの場合は歩き始めにコケルことが多いのでまだ研究が必要。 気づきメモでした。
転倒回避歩行の拡張の件は、転倒線の抽出を関数化し、転倒線リストとして管理する形にした。今回の転倒線はただのラインじゃなくて、ベクトル扱いなので方向がある。ラインのときは傾きは-90度～+90度だったけど、方向があるから-180度～+180度までになる。この方向が転倒方向を考えるのに役立つのだ。
■７月２５日■
レンズが到着した！
早速カメラに取り付けて、ピントが合うかを確認。。。 おぉぉ～、ピント範囲内だ！下の画像は、カメラ画像を表示しているディスプレイを携帯で撮影してる画像なので画質がいまいち。っていうかカメラがたいしたことないのでもともとそんなに綺麗な画像じゃない。 あ、結局、購入したのはちっこい方のレンズでした。安いし小さいしだったし、もしピントが合わなければマウント側を加工すればなんとかなりそうだし、暗さだけがネックなのだが、CMOSではなく、CCDを使うことでなんとかなるかなという判断。
画角は目算では160度くらい。いいねー、これくらいなら視野が広いって言えそうだ。 ・・・でも、ケラレがほんのわずかしかない。いいんだけど、なんでかな？
画角の広さをあらわしてみると、、 こういう感じで矢印の方向にカメラを向けると、
ちょっと見えにくいけど、丸で囲ったところに赤いバッテリーが写ってる。↓
見た目には明るさは問題ないが、早い動きがどう写るかが問題。これはキャプチャーしてみないと確認できない。
まずはこのレンズで進めよう。
画像に関しては、カメラ画像を取り込んでCDTで色検出をできるようにする、というのが第一課題として、超広角画像を補正してパノラマ画面を作るということをやってみたいなと思っている。 ロボットが見た画像なので人間が見る必要はなく、つまりは人間が見やすいように補正する必要もないので二の次三の次の仕事なのだが。 これには、しばらくは手をつけられないのだが「空間把握」の一環で、部屋を構成する直線を抽出して空間の構成（構造？）を認識する、というのを考えている。画像から直線を抽出するのはハフ変換を使うのが一般的だが、ひずんだ画像からではうまく行かないはず。中央のひずんでいない部分だけで抽出するって手もあるが、、、ゆっくり考えよう。
アイボで開発した物体認識プログラムの移植はしばらく先になるかなー。まずはロボカップ公式ボールを認識してトラッキングできるようにすることが先決。
そういや、ロボワンサッカーで、「自律を排除しない」って書いてたのを見た覚えがあるが、ボールっていわゆるサッカーボール柄だったのではなかったか？まだサッカーボール柄をうまく認識するのは難しいな。昔、アイボのカンファレンスでサッカーボールを認識することをテーマに研究している人が発表してた覚えがある。そんな感じだから「排除しない」ってのは口だけで、事実上は自律排除になっちゃってるなと思った。
転倒回避歩行を攻めあぐねてずいぶんたつのだが、今やろうとしている「姿勢を考慮した転倒判定」と、「姿勢を考慮した転倒回避歩行（つま先立ちサポート）」を折り込んだら、結果はどうあれ、一度開発完了にしようと思う。大体思いつくところはすべて実装することになるし、ロボットのような総合装置は各部位やファンクションのバランスが大事と考える。他のことにも力を入れなきゃね。
でも、実は今の興味は転倒回避でもなく、画像処理でもなく、起き上がりなどの動作をどのように表現するか、ということなのだ。今の下半身姿勢表現は立っていることが前提条件になっていて、座っている時・寝ている時・膝立ちといった姿勢は表現の範疇にない。立っている時以外の姿勢の表現と、上半身の姿勢、それも地面に手を付いているときのような姿勢を考え、二つを並べて四つん這いの姿勢を表現したり、それでハイハイをしたり、そこから立ち上がり動作を表現したりということに興味を覚えている。 立ち上がり動作途中でアンバランスになったら、転倒回避で一歩足を踏み出したりする様子を思い浮かべるとちょっとワクワクする。 （アトム派ってわけじゃないが、、、アトムがはじめて覚醒したときにふらふら立ち上がる様子。あれを地でやるような制御ね）
■７月２７日■
あともう少しで「姿勢を考慮した転倒判定」の関数が出来上がる。ひぃひぃ。。 なんだかわからないがなかなか進まない。
レンズを付け替えたCCDカメラをRPU100に接続するためにカメラ用電源を作るレギュレータ回路を作らねばならない。8Vなんだけど、首のサーボに使うRS302CDの電圧とほぼ同じ。全部の容量をまかなえるようにしたいのだが、RS302CDって最大電流はどれくらいなのかな？カメラとサーボの電源を一緒にしてしまうのはまずいかも。RS302CD用のコネクタやら圧力センサーや電流検出に使うオペアンプやらをまとめて発注したいのだが（送料より部品代の方が安いって勢いなので） 回路設計は苦手なので部品が決まらない。 サーボ回路の実験のためにDualFETなんかも注文しておきたいのだが、RSコンポには売ってないみたい。
特異姿勢については少しまとめてみた。
考えられる姿勢タイプは ①立位 ②膝立ち ③膝で四つん這い ④膝を上げて四つん這い ⑤座位 ⑥寝位（あおむけ） ⑦寝位（うつむけ）
これを上半身と下半身に分けると
下半身 ①立位 ②膝立ち ③座位
上半身 ①立位 ②手付き（地面に手を付いた状態）
たとえば上半身：立位 下半身：立位 ⇒立位 上半身：立位 下半身：手付き ⇒膝を上げての四つん這い といった感じで構成される。寝位がちょいと特異かな。
でこれらの姿勢タイプ間の移行動作ってのを考えて相互移行する。 仰向け⇒膝で四つん這い⇒膝を上げて四つん這い⇒立位 って感じで移行しながら立ち上がる。
膝を上げての四つん這いは４足歩行を実装する。 で、手と足の間隔を狭めていけばどっかで２足歩行（立位）に移行するって感じにできないかな。 胴体に軸がないからそこまで柔軟な動作はムリっぽいな。
■７月２８日■
午前中から「姿勢を考慮した転倒判定」の続き。
結局、今のところは倒立振子の支点が切り替わるタイプ・そのまま転倒するタイプ・・などというタイプを判別して切り替わるタイプは切り替わりタイミングを調べて・・という感じの記述になっている。ま、これしかないかな。
ところが、ちょっと考察不足があって、初期位置、初期速度、目標位置がわかっていても目標位置での速度、目標位置までの遷移時間を計算することができないことに気づいてなかった。ある遷移時間後の位置を示す数式に sinh と cosh があり、その中に遷移時間 t がでてくるので t=・・ の式に変換できないのだった。とにかく遷移時間を求めるというなら目標位置に達する遷移時間を探さねばならない。
転倒判定はインターバル時間毎に実施するので探索のような処理はできるだけやりたくないのだ。 精度はそれほど必要ないのでなにか簡単な方法で近似できないだろうか？
いいアイディアが出ないからほかの事をしようかなと思ってたらひらめいた（ってほどじゃないな。気が付いた、だな） 軌道エネルギーから逆算すればいいのだった。この場合遷移時間は不要で目標位置での速度がわかればいいのだ。もちろん、位置も速度もわかったので遷移時間を算出することも可能。よかったー。先に進める。
これから出かけなければならないのでここまででストップ。まだ転倒判定本体部分の記述が完成していない。符号回りに気をつけなければ。続きは夜。
■７月２９日■
「姿勢を考慮した転倒判定」は昨夜、コーディングが完成してデバッグ中。
いくつかのバグを乗り越えて、どうやら思い通りに動いてはいるらしいのだが、転倒判定の正答率が低い。特に前に倒れる時の判定がでたらめになる傾向がある。
入力データとしては加速度センサーデータとジャイロセンサーデータを受け取り、加速度センサーデータから胴体部分の姿勢角度を算出している。ジャイロセンサーは胴体の（ひいてはロボット全体の）移動速度（正確には角速度）を得ている。
判定内容は、現在姿勢と胴体姿勢から路面との接地状態（足のどこが接地しているか）を読み取り、角速度方向から転倒する方向か、正姿勢（べた足状態）に戻ろうとする方向かを判断する。転倒する方向ならそのまま転倒判定へ、復帰方向なら正姿勢になった状態での重心点の速度を計算して、その速度を使っての転倒判定へと進む。
主に判定を間違うのは初期姿勢がべた足ではなく、復帰する方向への角速度を受けた場合、角速度が足りずに復帰ができないと判断されるパターンだ。
考えられるいくつかの問題としては加速度センサーデータの遅延と重心点座標の誤差が考えられる。
加速度センサーデータはノイズが多いのでノイズリダクションを行っているため、若干反応がにぶいと思われる。 重心座標については下半身の重心は両足の股関節の中点にあると規定して計算している。実際にはそれに上半身の重心をオフセットしているので実質デタラメだ。実際にはもっと低い位置に重心がある。
なのに試しに手で転倒間際の状態を作り、加速度センサーからのデータにて計算してみると（静止状態なので遅延は関係なし）概ね転倒側に重心が移っているように測定される。
あ、考えられる誤差がもうひとつあった。加速度センサーデータの変換レートだ。加速度センサーは事実上、重力加速度を測定しているのだが、三角関数にて角度に変換している。そのため、傾きが大きくなると分解能が悪くなる傾向にあるが、30度くらいまでは問題ないはずなのだが。 それに加速度センサーデータの誤差が支配的であれば、前側も後ろ側も同じようにして判定ミスするはずだ。
なんにせよ、もう少しデータを集めつつ、各パラメータの調整が必要なのだろう。 そろそろ全身の重心点を計算しなければならないのかな。
上半身の重心点をＣＡＤデータで計算してみた。
計算上の重心点である、股関節中点とのオフセット値は X=0mm, Y=-32mm, Z=54mm 今の設定は X=0mm, Y=-28mm, Z=50mm なので若干差があった。が、影響度小だな。直接的問題は他にあると見た。
このページも長くなった。６月のアタマからだからまるまる２ヶ月だ、８月からは新ページに切り替えよう。 ６月２日の日誌を見ると「転倒回避最終章」とか書いてる。全然だな。やはり、転倒回避動作のインプリだけで学士の卒論くらいは書けるネタだろうから、１ヶ月でカタチにするという当初の計画に無理があったということなのだろう。見積もりは難しい。やる気だけではダメなのだ。予定の精度を上げるためにはドライな判断、客観的な判断が必要。
またまた勘違いしていた。重心のずれは下半身の重心を無視していたためだ。 ちょうど釣り合うと思ったら計算では転倒と判定してしまうということは重心はもっと低いということだ。 上半身は今のところ動いていないため定数で与えても問題ないが、下半身の重心点は定数で与えるわけに行かない。姿勢が変わると重心点も変わるため、ロボット全体の重心点も変わる。いよいよ重心点の管理もせねばならないか。
ちなみに加速度センサーの変換係数はとりあえず適切だった。４５度くらいまでの傾きに対しては大きなずれはなかった。 それ以上の傾きはずれが大きくなるが係数の問題ではない。利用するならＺ軸センサーを併用するような処理にすべきだろう。
上半身を動かすと上半身の重心点が変わる。上半身を支えている下半身はその変化を受けて釣り合うように動く、ということをさせたいのだが、下半身の重心点が影響しているとなると問題は複雑。上半身の重心移動に合わせて下半身姿勢を変えることは下半身重心が変化することになり、それはまた下半身姿勢の変化を必要とする。。 単純には行かないので重心管理でＰＩＤフィードバックをかけたりしなければならないか。
考えてみると転倒回避動作というのはなかなか的を射たテーマだったようだ。倒立振子を使って転倒を表現し、つま先立ち姿勢をサポートし、とうとう重心点管理までせねばならなくなった。 そのうちやりたいな、と考えていたロボット制御のいろんな要素が必要で、それを実装「しなければならなくなり」少しずつロボットが完成に近づいて行っている。
転倒回避歩行を早々に終結するつもりだったがもう少し先になりそうだ。重心管理といってもモーメントまで見るつもりはなく静的重心点の算出だけでいいだろう。めんどくさいだけで計算は簡単。座標変換と重心合成のカタマリになる。
とは言っても、今日の成果として転倒判定の一応の完成を実感したい。 暫定的に下半身重心と上半身重心を合成した全体重心を動作に反映させるようにして実験してみたが、どうしてもずれが有るらしく、思い通りには動かない。 いままでの簡易的な転倒判定に比べると相当シビアになっている。重心情報の精度もあげなければ使えないということか。適当な値を入れて調整しようとしてみたが、斜めになる姿勢が重要なので前後のずれだけではなく上下のずれも合わせる必要がある。やはりきちんと計算してみなければならないのだろうなぁ。
CCDカメラをRPU-100につないでみた。視野が広いかわりに解像度が低い。 昔はバリフォーカルレンズを搭載してズームできるようにしたいな、とか考えていたが、ここまでの画角をエリアに持つバリフォーカルレンズはないだろう。CCDの解像度を上げるってのが現実的な答えかな。 カメラ２機を搭載してテレ用とズーム用ってのもいいか。 いや、２台載せられるならステレオビジョンの方がいいか。
このカメラは電源電圧8Vなのだが、手持ちの抵抗の関係で7.77Vで動かしている。一方、頭部の制御に使おうと思っているRS302CDの電源電圧範囲は7.2～7.4Ｖ（・・・せまい） たぶん、カメラもその電圧でも動くだろうからレギュレータ回路を一本化してしまった方がいいんだろうな。サーボの突入電流がすごくって、電圧降下起こしたりはしないだろう。
さて、カメラもつながったことだし、画像関連のプログラムにも着手しださないとな。今度こそさっさと終わらせるぞ！
重心計算の仕組みを構築中。
各ブロック毎の重心座標と重量を算出し終わったのでモデル化すればいいだけ。アイボでも同じように重心計算をしたことがあったのでその当時のプログラムを見てみたのだが、アイボは各足の自由度が３しかない。足レベルで計算式を展開して一発で算出するようにしていた。ラムダの場合はそれじゃーなぁ。。。 足は６自由度、腕は４自由度、頭は３自由度で考えているのでそれぞれの展開式を用意するのは馬鹿っぽい。で、関節毎に重心座標と関節情報と接続情報をもったクラスを作成。 リストでつないで順に重心合成をしていくようにした。 今日のうちに全身の重心モデルを構築できるかなーと思ったのだが、クラスを作ってコンパイルが通ったところで時間切れ。続きは明日。
重心計算のしくみを考えると、上半身を動かしたくなってきた。上半身クラスを作って動かせるようにしようかな。上半身の重心の動きに合わせて下半身がバランス保持のために動くようにする。モーメントとかまで計算しなくても使い物になるものかどうか。。。 いままでの経験ではきっとモーメントも計算しなければならなくなるんだろうなぁ。。重心合成のように簡単な計算では済まないのだろうなぁ。
支持脚の傾斜移行