前へ転倒① エクセルグラフ 0.63秒■５月１日■
カーブ歩行完成！
下半身姿勢移行の一般化も完成した（厳密には踵上げ動作が折り込まれていないから完全ではないが）。歩幅変更も姿勢回転型にしてプログラムコードも簡単になった。曲がりながら歩幅変更とかもできる。
動画をアップしときたいとこだが、これから出かけるのでそれは明日の作業かなー。
さて、次はつまずき対応・踵＆つま先姿勢・転倒対応あたりを攻めよう。受動関節をどうするかなんだよなー。
今使っているサーボはコンプライアンス設定ができるのだが、受動関節を実現するには反応速度が足りなさそう。受身の間はなんとかなりそうなのだが、攻め手になったとき（インピーダンスを上げた時）の挙動がうまくいくかどうか。 そろそろトルクも足りなくなってきたし、サーボの寿命を削りながら電圧を上げていくか、新しいサーボに切り替えていくか。悩ましい。
■５月２日■
カーブ歩行まで完成したので、歩行に関することをラムダのページにまとめておきました。さわりだけしかまとめきれていません。自分のためにも詳しくまとめておきたいのですが、今は開発を進めたい気分なので、折を見て進めようと思います。もし、詳しい解説が欲しいような個所があれば連絡いただければ優先的にまとめようと思います。
逐次計算によるロボット制御はモーション再生式に比べて準備が大変なうえ、計算量も多くなってしまうので小さなマイコンでは制御しきれません。 しかし、カーブ歩行や歩幅変更など、複雑なことができます。カーブ歩行など、カーブの半径を与えれば応じた歩容が計算できるのでロボットが自律するには不可欠だと思います。 カーブまでは逆運動計算を組み込んでいればモーション再生式でもなんとかなると思いますが、次にやろうとしている転倒対応歩行（とでもいうのかな？）は逐次計算式でなければ不可能なんじゃないかと思っています。
歩行は「倒れる前に足を出す」ってことだと思うので、そこからスタートしたかったんですが、それを実現するためにはまず正常な「歩行」ができなきゃならないという結論になり、やっとその準備ができたという感じです。
ただ、どうも歩行をやっていくうちに現状のロボットではトルクやスピードが足りないような気がして、「正常歩行」よりもトルクもスピードも必要な「転倒対応歩行」がうまく実現できるか疑わしい気がしてきています。センサーにしても関節の負荷情報だけでは足りず、足裏センサーや足首の力覚センサーが必要（必須）ではないかと思えてきています。そのあたりは検討を進める中で必要に応じて対応していこうと思います。
■５月３日■
理論面の検討を黙々とやっていたのだが、倒立振子が転倒する運動方程式はやはり難しい。 転倒に必要な時間も数値積分しなければ出ない。
モニター表示していたジャイロデータをCSVファイルに保存できるようにして、同時にビデオ撮影をしてデータ取りをしてみた。
結構勢い良く倒しても0.4秒程度かかる。 対処スタートの判断ができれば反応できるかもしれない。 単純倒立振子になっているところをけり足を加えて線形倒立振子へ持っていく。 それで対処時間を稼ごうって魂胆なのだが、外力による加速に加えてけり足の加速度も加わって水平運動は相当なモノ。けり足の動作範囲が足りなくなるかもしれないな。
0.4秒の速度に対応できなきゃイマイチだなー。0.6秒のケースってチョイってつついてるだけだもん。
ちなみに前後3回ずつサンプルをとって、それぞれ倒す力加減を変えてみた。再現性の高い外力ではないので目安程度のデータだ。全部動画をダウンしても代わり映えしないのでがっかりするかも知れません。ご了承ください。
・
・
・
いろんなところで先日のKONDO CUPの動画がアップされていて、目にするのだけれど、あの、「すばやい横歩き」ってどうなんでしょうかね。あれやっちゃうと２足歩行ロボットじゃない気がするんだけど。。 スポーツでも格闘技でも横の動きは大切だから横歩き自体は問題ないんだけど、前進にも横歩きって反則だと思うのですが。 (-_-;) ＃ゲームとしてはアレくらい速い方が断然面白い。のたのたしてたら緊張感ないからね。
ラジコンロボットの歩行って充分安定していて高速なんだから交互に足を出せばいいのにな、と思います。
もっとも、スポーツの世界でも背泳ぎでバサロに制限がついたりして、ルールはどんどん変わるからそのうち横歩きにも制限がつくのではないかと思ってます。そうなると、審判が大変だろうな。
■５月５日■
大阪までROBOCUPジャパンオープンを見に行ってきました。
見に行ったのは４日だけ。５日は寝坊して行けませんでした。 ヒューマノイドリーグの参加チームは４日の予選で全部見れたのでまぁヨシとしましょう。
ヒューマノイドカップに的を絞って観戦してきました。
安定した歩行ができていないチームが多くてちょっと驚きました。ボールの認識なんて色で判別すればいいから簡単だし、２対２ならパス回しを考えたりする必要はないので処理は簡単なはず。 敵ロボットを認識していないロボットがほとんどのように見受けられた。 さすがにそれはちょっと難しいかもしれない。
その中でヴィジオンの安定性は抜群。しかし、初戦では立ち上がりモーションがうまくなくて転んでばかりでした。次の試合までには修正して来たけど。 はじめロボットも安定しているけどソフト次第なのか、いまいちの動きをしているロボットが多かった。
はじめロボットとヴィジオン以外のロボットはまともに動いているモノはなかったのではないだろうか。
日本の大学チームがぎりぎりまでバタバタしてて、試合開始になっても間に合わないチームが続出なのに対して、ドイツからの参加チーム（やはり大学生）は試合前からノートパソコン一台（指令を出すパソコンらしい）があるだけで準備完了。 レベルの差が悲しかった。
思うのだが、ヒューマノイドを大学生がやるのって時間的にきびしいのかもしれない。アイボや他の車輪型ロボットと違って、ヒューマノイドはロボットの基礎部分が発展途上なのでその部分を仕上げつつ、サッカーをさせるというのに厳しさを感じた。 チーム大阪との差が大き過ぎる。
歩行については特に目立ったものはなくて、驚かされるようなことはなかったのはちょっと残念。
ティーンサイズのロボットはやはりでかくて迫力がある。 ただ、絶対転べない（こけたら壊れる）のはつらい。 あれじゃ使えないよなぁ。まだティーンサイズは早いんじゃなかろうか。
ともあれ、みんな必死で楽しそうだった。来年は状況が許せば出場してみたいと思います。だれか２台目のロボットと共に出場してもらえる人はいないでしょうか。 誰もいなかったら一人で出るしかないなー。
さて、明日はゴールデンウィーク最終日。 転倒回避の続きをやるぞー！ 俄然やる気が出てきた。
アイボが信じられないスピードで動いてた。かわいくない。(-_-;)
TEENサイズのはじめロボット
ヴィジオンのキックシーン
ホープも居た！ 500万円もするのに。。(>_<) ハタラケヨHOPE(~_~)
はじめロボット対はじめロボット。 ソフトが違うから別物か。。
はじめロボットはたくさん出場してました。 １台200万円
■５月６日■
早速、来年のロボカップに向けてヒューマノイドリーグのメーリングリストに参加したのだが、ほとんど投稿されてない。。。 議論とか情報交換とかはないのか。 そういやOPEN-Rのフォーラムに参加した時も議論じゃなくって質問とその答えだけだった。。 議論になったらなったでついて行けなかったりするが、沈黙は寂しいな。
確か、公式ボールが買えたよなぁ。。との記憶から探し回ってやっと見つけた。こんなおもちゃのボールみたいなのが４個で5040円。 だが、まぁ、しかし、買うしかないのかな。どなたか、共同購入してくれる方いらっしゃいませんか？＼(-o-)／
ロボカップに出るには今のままの機体じゃ厳しい。不要な自由度を削減して軽量化しなければならない。腕は立ち上がるためにしか使わないから棒でもいいんだけど、それだと格好悪いのでそのままで行こう。
ずっと先送りにしてきた画像も着手しなければならない。歩行はなんとかなりそうだから、胴体の改良と頭ユニットの改良（というか新設計だな）の方がプライオリティが高いかもしれない。
画像処理はアイボでやった技術が使えるはずだから問題ないだろう。できるだけ早く基礎を仕上げて、行動プログラムに着手しなければならない。
行動プログラムが意識エンジンでできたらいいのになー。
・
・
・
転倒回避を行うには転倒するかどうかを判断しなければならない。 立っているロボットを倒立振子に見立てて、軌道エネルギーにより転倒を判断してみた。
赤いグラフがX軸周りのジャイロデータ（前後の傾き）で、上に行くほど後ろに倒れている。
グラフ中の▽マークが転倒しそうであるとの判断のマーク。はじめの大きなコブは転倒しているところを手で支えている。あとの小さなコブは転倒せずに済んだケース。結構うまく検出できている。 まだ、うまく行かないケースもあるし、速度で判断しているのでゆっくりと傾いていくケースだと検出できない。
いくつかの検出法を併用しなければならないだろう。
ちなみに軌道エネルギーの計算式は速度も位置も二乗するので符号がありません。よって戻りの時にも検出してしまう。今回はテストプログラムなので除外処理していません。
転倒回避のための歩行計画を立てるには遊脚の動作速度限界と指示脚、遊脚の移動限界を知る必要がある。移動限界は計算ででるが、速度限界は測定するしかない。 速度限界測定用のプログラムを作る必要がある。
■５月８日■
ロボカップ出場に向けてラムダの構造変更を検討中。
第一に胴体に設けた旋回軸と仰角軸を削除しようと思っている。
生活行動を行うために設けた軸であったが、このラムダで生活行動を行うところまで進化させるのは難しいだろうという見切りと、ロボカップでの動作においては基本的に不要な自由度であること、基本的にトルク不足であるラムダにとっては軽量化が必要なチューニング項目であることなどから、この２軸を削除することを前提とした検討を進めている。
旋回軸は問答無用で削除であると考えているが、仰角軸は悩ましいところではある。仰角軸は起き上がり動作時に使用することが考えられるからだ。
股関節の可動範囲を広げることで、ある程度は対応可能と考えているが、作ってみて失敗だったという事態は極力避けたいため、十分な検討を行った上で削除に踏み切りたい。
仰角軸の削除のために股関節可動範囲を広げたいところだが、そのために身長を高くすることが考えられるが、これも避けたい。同様にトルク不足である現状を考えると身長は低い方が有利だろう。基本的に現状維持としたい。
さっさと構造検討して組み替えちゃいたいな。
でも、 ラムダの歩行速度では他の出場ロボットに比べるとショボイのは事実。小兵はスピードで行きたいところだがそこが無理ならどうすりゃいいのかな。ま、１年の間に考えよう。
本当はこれを機会にハイパワーサーボに切り替えたいところだが、今のサーボへの不満がDXシリーズで解消できるとは考えられない。 トルク制御は必須だし、近藤科学のサーボもトルク制御はできない。（位置取得はできるらしいが）サーボのカスタマイズをする技術を構築する時間はないと思われるから今のサーボで行くしかないんだよなー。
・
・
・
転倒検出は前後の区別をつけて検出できるように拡張した。 歩行姿勢のパラメータを使うと何かと不便なので、転倒検出用の上半身の重心点を別途管理するようにした。もっとも入力している重心点のデータはあてずっぽう。そのうち部位ごとの重量を測って計算で出すようにしよう。
まだ、角速度を検出した時の姿勢を計算に入れていない。 つまり、ぶっちゃけ既に転んだ状態でも（立っていたら）転倒するくらいの角速度が発生したら「転倒」を予測してしまう。これでは逆に転倒を検出したせいで転んでしまいかねない。まだまだ作りこみが必要だ。
あと、どんな立位でも検出できるように拡張しなければならない。ジャイロもX軸周りだけではなくY軸周りのセンサーデータも合わせて利用するようにしていく。
まぁ、そんな整備は追ってやるとして、まずは転倒を予測したら、転倒を回避するように足を前に出すようにしないと。 ロボカップ対応の改良案のことやカメラのことなど雑念が脳を支配してしまって作業が進まない。 どのように遊脚の着地点を決めればいいのか。計算で一意に決まらないことって難しい。
＃「なに食べる？」って聞いて「なんでも」って言われたときみたい。。
■５月９日■
RobotWatchに九州で行われたヒューマノイドカップについての記事が載っていた。予選はスプリントレースで決勝はバトルという構成らしい。
スプリントレースの結果を見て驚いたのだが、3メートルを5秒とか。 なんじゃそりゃー！動画は出ていなかったけど、静止画を見る限りみんな横歩きだったみたいだ。そんなんでいいのかなー。楽しんでいるわけだし、もちろん構わないのだけど、これってヒューマノイドカップじゃないのかね。人間の真似しなくていいなら２足歩行なんかする必要ないのになと思う。
昔、まだ、ロボカップの４レッグスリーグでのアイボがERS-110だった頃（いや、210かな？このあたり適当です。）、どっかの大学がほふく前進スタイルの歩行を編み出して高速な移動と方向変換ができるようになった。以来、ERS-7タイプになった今でもアイボは、前足は肘をついた状態で歩くスタイルが定着している。安定して、どんな方向にも瞬時に動ける。必要性が産んだ実用的スタイルなのだ。当時、アイボ界の人形つかいさんが、「あれ以来、ロボカップ４レッグスは面白くなくなった」という意味のことを言っておられました。先日見に行った感じではゲームとしては格段に面白くなってます。 動きがゴキブリみたいであのアイボたちは愛せないですが。(^^ゞ
多分、今のラジコンロボットの横歩きも、それと同じなのだろう。レースをするのに無意味な理想など語る余地はないのだ。勝てばいいのだから。 ふう～、これだから競技ってイヤになる。競技は勝つことが正義。だから勝つことこそ美学。ルール内であれば問題ないわけだし。
ロボカップヒューマノイドリーグには高速横歩きはまだ感染していない。 きっとそのうちだれかが持ち込んで蔓延してしまうのだろう。 それを考えるとウツになってくる。少なくともはじめロボットやヴィジオンがその感染元にはなって欲しくないものです。 誰かが持ち込んでも蹴散らして欲しいです。
＃ホームページビルダーを６から１１にしたけどあんまり変わり映えしない。。
・
・
・
転倒検出を一般化するためには支持多角形を算出する必要がある。転倒の恐れがある方向は、支持多角形の辺の中でも重心からの距離が短い辺の方向。難しい計算ではないが、要は、全部計算して短いところを見つけるしかない。 加速度に対する軌道エネルギーの判定を全部の辺に対して行っても良いのだが。
支持多角形
考えると、転倒回避歩行が出来たら、ロボットの手を引いて連れて歩くということができるかもしれない。 腕の受動関節動作とか、他にも必要な機能があるから簡単ではないのだが、そういうのが出来たら生命感があるかなと、思う。
■５月１０日■
キター！
３ヶ月前に注文した板金ベンダーが今日届いた。注文したのが２月９日なのでちょうど３ヶ月。伝票によると発送は２月２６日のスタンプ。今までどこにあったのかなー。１万円以上するから関税がかかるはずだけど、郵便小包で直接送られてきたのでノータックス。どうやら、東京税関でのんびりしていたのではないかと思います。
錆びないようにだとは思うけど、オイルとパラフィンが塗ってあってヌルヌルベタベタする。作りも荒っぽい感じ。レバーなんかすごく遊びが大きくて大丈夫なのかなーという印象。紛れ込んでいた新聞の切れ端は中国語なので製造は中国のようです。そういえば検索した時、中国製のベンダーもあったな。
試しに、アルミの切れ端を折り曲げてみたら、なかなかいい感じで曲がります。これで、改良版ラムダのボディを作りましょう。楽しみだな。
あ、カード会社への調査依頼を取り下げないと。
■５月１２日■
インベンターの新バージョンが届くというメールが来たので、覚悟を決めて一気にハードディスクを移行することにした。
したのはいいけど、はじめたのが１１日の夜２４時ごろ。最低限のアプリの移行が終わったのがさっき（１２日の２０時）実はその間、ほとんど寝てない。 ほんとにいろいろあったなぁ。
今回とうとうウィンドウズをＳＰ２にしたのだけど、セキュリティーが強化されているのをすっかり忘れてた。ファイヤーウォールのせいでVMWare上のNetBSDと通信できない。それに気づくのに数時間（途中、食事休憩あり）かかってしまった。
■５月１３日■
ビルダー１１の反応がにぶいのはページが長すぎるからだよね。
ってことで、カーブ歩行完了のところと月の切れ目がいい感じなので５月からは別ページにしました。今後もページの切り替えは早めにしていかなきゃいかんね。
ページが短くなったらビルダーの反応はよくなった。
・
・
・
やっと、転倒回避に取り組める。
転倒速度を入力として、転倒回避歩行のターゲット姿勢を計算してみた。
ちょいと押して倒れるくらいの時の初速度は360mm/sくらい。 これは相当早い。遷移時間0.3秒で計算すると、遊脚の着地点が300ミリほどかなたになってしまう。
線形倒立振子だと、倒れないようにどんどんと速度を増していくので初速がある程度以上になると短時間でとんでもない移動距離になってしまう。実際には無限に足を伸ばせるわけではなので、途中から落下方向に軌道を変える。
考えると、転倒速度は「2次元倒立振子の頂点を超える速度」なので、頂点では少しだけ減速した速度になっているのだ。 感知した途端、その速度で動作を開始するのはちょっと気が早いかもしれない。次は頂点での速度を初速にして計算しなおしてみることにする。
あと、軌道エネルギーで転倒回避歩行計画の適正さを判断しようとしたが、不可能なことがわかった。エントロピーの山に向かわない場合は、この方法では判断できない。判定したいのはまさにそのケースなのだ。別の方法を考えねば。
初速度360mm/sの時の重心点の動き。遊脚の動きはこの倍になる。
■５月１４日■
今日は飲みに行ってたので進展なし。
ちょっと考えたのだが、転倒外力を押さえ込む力も必要なのでは？ と思って、前後方向に減速の考えを入れ込んでみた。 線形倒立振子で動けば、減速どころか加速する一方。遊脚をだして、受け止めるにしても限度ものだろう。
（昨日のとはちょっとパラメータが違います）
右の前後方向のグラフで「減速付」というのが減速の考えを入れたカーブ。 初速は360mm/sのままでも100ミリまで抑制されている。 もっとも、線形倒立振子ではなくなっているので傾きが生じてしまってうまくないかもしれない。そのあたりの考慮も必要となるだろう。
試してみる価値はあるかなー。
■５月１５日■
外力が加えられた時の、転倒のヤマを超える時の速度を基準に一歩を決めるようにしてみた。
ふむ。。。確かに値は小さくなる。これならいけるかも。 ところで、どれくらいの歩幅までなら対応できるのか？今は遷移時間を0.3秒で計算しているが、もっと速くはできないか？ ということでその辺りを実機で確認してみた。 前側にならば200mm程度。遷移速度は0.3秒が適当。それ以上だとサーボが追いつかない。ただし、歩幅200なら腰の高さは160㎜程度にしなければならない。 後ろへはうまく歩けないラムダは転倒回避でも前からの衝撃には弱い。これは調整しないといかん。前からの衝撃が受けられなかったら意味ないし。
すると外力はどれくらいまで受けられるのか？ 外力による初速が220mm/sくらいまでなら反応できる。大きな歩幅の状態では左右に不安定になるので、足首のダンパーは左右から前後に切り替える必要がある。 問題は、これ以上大きな力が加わった場合にどうするかだなー。
あと、左右方向の初速だが、前後方向の力に合わせて計算してみたが、それは大きな間違い。三次元倒立振子の一般解はX軸とY軸で分離されているため、初期状態の左右の位置と、遷移時間で決めていく方がよさそうだ。
転倒予測も、重心位置のオフセット値で当たり外れがずいぶんと違う。ここも調整が必要だな。
あと、来年のロボカップ出場までの開発スケジュールを作ってみた。もうちょっともんでいかないとだめだが、この様子だと5月中に転倒回避歩行は完成しないなぁ。
スピーシーズからサーボのファームアップの連絡が来た。 フリーズしてしまう件が解決したようだ。 でも、ちょっとラムダを分解したくない状態なので、少なくとも６月に入るまではファームアップできないかなぁと思っている。サーボ送り返したらボディーの設計に入ろうかと考えている。 ん～、５月末死守したいなぁ。
■５月１７日■
転倒回避歩行の初速設定は、左右方向は0.3秒で元の位置に戻る初速設定。つまり、歩行素片と同じような計算になる。 前後方向は対応可能最大値である、歩幅200ミリを基準にそれ以上の初速が入力されたら、複数歩での対応とするようにしてみた。
コーディングはほぼできたので、明日か土日にはテストできそう。
テストでは足をそろえた姿勢からしか対応していないが、立っている状態すべてに対応するためには支持多角形の計算をしなければならない。それも今週末には終わらせたい。今日、テストまでこぎつけるつもりだったのだが。。
■５月１８日■
こけそうになるのに反応して足をさっと出す姿が見たくて、細かいところは後回しで動かしてみた。
・・・ んん～・・ まだまだ検討が必要そう。
大体5回に1回。。いや、10回に1回くらいは成功するかな。 事前実験とは違って前からの力を受けて後ろに足を出す方がうまくいく。 後ろからの力で前に足を出すのはさっぱりとうまくいかない。
まず、転倒速度検出がうまくない。重心位置をもう少し厳密に設定する必要があるようだ。 上半身姿勢から重心を算出できるようにしないと。。
次に歩行の際につまずき防止のために取り付けたつま先の潤滑性テープのせいで前へ足を出すのがうまくいかないらしい。 これは予測していたことだが、こけそうになる前につま先立ち状態になる。そこから遊脚を出すわけだが、つま先は滑りやすいようにしているのでつるんと滑ってしまってうまくいかないのだ。 これに対しては、足を出す前にコンプライアンススロープ設定を変えてべた足になるようにしてみようかな。ちょっとは効果があるかもしれない。
あとは弱い力に対して遷移時間0.3秒での動作はアンマッチらしい。速度が小さい時は遷移時間0.4秒にすべきか。
強い力（速度が大きい時）に対して、0.3秒の遷移時間でとりあえず足を出すのはうまくいきそう。まだ複数歩数での対応がコーディングできていないのでなんとも言えないが、いい感触だった。
⇒ 
後ろに足をだして転倒を回避した様子
ただ足を出すだけじゃなくて、体を開いて足を転倒しにくい方向に向けるとか、受け身の方法はいろいろ工夫できそうでは、ある。
■５月２０日■
やっと転倒軸の一般化算出ができた。簡単だと思ったが、なかなか手間取ってしまった。
ちょっと遠回りのような気がしたが、Windowsで下半身姿勢の床面投影で支持多角形を書き、重心点からの距離を算出するプログラムを作ってみた。
これを転倒判定に適用すればどのような立位姿勢でも転倒軸を見極めて、転倒判定ができる。これができれば複数歩での転倒対応歩行も実験できるのだ。
重心の考え方も整理して、上半身（正しくは股関節より上すべて）の重心点と、前傾姿勢などの体重移動のパラメータを分けた。ボディの旋回やお辞儀をしても前傾パラメータは影響を受けない。 上半身の部位毎の重量を測定すれば、上半身姿勢に応じてバランスを取った姿勢に追随するといった事もできるようになる。
今度はこのテストプログラムをラムダのプログラムへインプリメントしなければならない。 以前はこれをビジュアルＢＡＳＩＣ６との間でやっていたのだが、文法の違いによるバグでよく悩まされた。最近はVC++を使っているので基本的に文法が同じ。くだらないバグに悩まされなくて済むのは精神的にもよい。
・
・
・
支持多角形からの転倒軸算出プログラムのインプリメント完了。 X軸ジャイロとY軸ジャイロの両方を使って転倒検出できるようになりました。
ジャイロデータから重心点速度の変換パラメータをちょっと変更して、転倒検出のしきいを調整したりして、まぁ使えるようになった。
早速、複数歩対応させてみようとしたのだけど、結果はこれ。
倒れてもガシャガシャと動き続けるラムダ。
入力外力の転倒軸に対して平行な力成分の方向によって軸足を決めるようにしていたのだが、転倒軸の一般化に伴って姿勢の回転変換が発生したことにより胴体ロールが発生する。 軸足が同じ方になり続けると画像のように足はねじれ～っとなってしまうのだ。
軸足を交互にするとか、胴体ロール値が小さくなるようにとか、アルゴリズムを考えねば。
弱い外力には遷移時間0.5秒くらいから対応した方がいいような感じがしてきた。 一番簡単なのは小さな歩幅ですばやくちょこちょこと対応すること。 もうすこしやってうまくいかなきゃそれでお茶を濁して次に進もうかな。
それにしても、このサーボ、だんだん好きになってきた。 トルクが小さくて重い、形が悪い、バグが多いと、散々文句言ってきたけど、ホントに壊れないし、負荷取得やコンプライアンス設定、トルク設定と、いう機能部分では頼りにしてる。 今後、違うサーボにした時にこれ以上の機能がないと困る。 正直、トルク不足は深刻な問題だし、困ったなぁ。
■５月２１日■
複数歩での転倒回避歩行の計画アルゴリズムを考える。（こういうのはアルゴリズムというのかな？）
転倒軸は支持多角形の辺のうち、両足にまたがる２辺のうちのどちらかとなる。通常の歩行なら足間隔を保ったまま足を前後に動かすところだが、そのように考えるとどんどんと足幅が広がって、やがては対応ができなくなってしまう。
なので、転倒回復の第一歩は足間隔が広がらない位置に遊脚着地点を設定しなければならない。
この考えの下でどの程度の初速度に対応できるのかを計算してみた。
足間隔を120㎜として、遷移時間0.3秒、初速度を100mm/sとすると、 左右の初速は248mm/s
⇒ 
100mm/sというのは速度が小さすぎるのでどこまで対応できるかというと、135mm/sでこんな感じに（左）。これじゃこけてしまうので、こんな風にしないといけないだろう。（右）
その時の位置カーブは、下の図のようになる。 左右の初速は319mm/s
遷移時間を長くするとさらに短くなる。対応可能な最大足間隔は多分150mm程度。 これを組み合わせて対応可能な初速を探っていくということになるか。
■５月２２日■
つまり、三次元線形倒立振子はX方向とY方向で分離していて、それぞれが二次元線形倒立振子になっているわけだから、初速と遷移時間と重心点の到達座標のうち２つが与えられれば残りの一つは計算できるわけだ。
↑これは間違い。遷移時間を求めるには到達座標での速度が必要。（2007.7.28追記）
歩行の検討をしているときは歩行素片を基本に考えていたため、対象でなければならないとして姿勢を回転させたりしたが、そんなことをしなくても軌道を計算できたのだった。 もっとも、カーブ歩行するためには姿勢回転は必要な概念だったから同じことだが。
足間隔を移行させるために歩行素片を補正したりしたのだが、あれはやらなくてもよかったんだなと。 そのうち修正しておこう。
今日は簡単にコーディングして歩かせてみようと思っていたのだが、ノートパソコンがスタンバイにならないことが発覚。ＯＳ再インストール前は日常的にスタンバイを使っていたから、できなくなったのはOS再インストールからだろう。Windowsの設定？BIOSの設定？サービスパック２のせい？いろいろ疑ってみたが確証ある情報はみつからず、コーディングもできず。 「休止」はできるんだけど、さっと電源を切れて、さっと電源を入れられる「スタンバイ」がいいんだよな。困った。 そしてコーディングも一切できないままもう今日は店仕舞いだ。(ーー;)
■５月２３日■
ノートパソコンのＢＩＯＳをアップデートして、スタンバイができるようになった。 どうもサービスパック２なら最新のＢＩＯＳじゃないとダメなような気がする。（気がするだけで、ドキュメントのどこにもそんなことは書いてない） まーいい。これで一安心だ。早速、転倒回避歩行のコーディングだ。
その前に、今日は早く帰ってきたのでトレーニングで汗を流そう。 ・・・ 今はやる気満々でも、トレーニング後は、ぐったりしてやる気半減なんだけどね。長生きするためだからやらなきゃ。
実はコソコソと新ロボットの調査とか検討をしてる。 ＣＰＵはピノーのCPUボード、ＯＳはART-Linux サーボは近藤化学のKRS-4014HV改 それぞれ敷居が高いけど、一番高いのはサーボの電流制御だろうな。
さて、トレーニング・・・
コーディング完了。 でも、今日はもう遅いので動作テストは明日。この時間から動かし始めると、ハマるとまずい。まだ水曜日だもんね。
それにしても、いろいろなかなか厳しかった。スタンバイできるようになったのはいいけど、VMWareのNetBSDとのsambaが見えなくなったり、ノートパソコンのファンが回り続けたり。サンバはいじくってたら突然に見えるようになった。 すかさずドライブ接続。立ち上げなおしても見えるようになったから一安心だけど、予断は許さない。 ファンは普段はほとんど回らない。たまに回ってもすぐ止まる。 それがずっとウィーーーーンとうなりを上げて回り続けてる。気になって仕方が無い。 一度立ち上げなおしたらちょっとファンの音は静かになった。 ＢＩＯＳアップしたらもう、あちこちから不協和音が聞こえてきているような気がする。 なんでだろぉ～(-_-;)
プログラムした手順を書こうかと思ったけど、失敗したらアホだからやめておこう。成功してからだ。
■５月２４日■
失敗です。。。。
ま、失敗っていうよりバグみたいなもんだからこれからデバッグだ。
初期状態
転倒回避一歩目
２歩目
３歩目 これは、ひざがぶつかってしまってダメ
テイク２
初期状態は同じ。。。
転倒回避一歩目 足がクロスしちゃってます。 ラムダにはこの姿勢はムリ。
さ～て、デバッグだ。
それより、ノートPCのBIOSアップしてから、ほぼファンが回りっぱなし。VMWare使うとフル回転して、その後止まることが無い。これはやっぱり不具合なのだろうな。VMWare落としてもファンは止まらない。 ちなみに一度スタンバイにするとファンは沈静化する。
なんかもう散々です。
■５月２６日■
なんかが憑いてるとしか思えないのだが、、、、ＣＲＴディスプレイが突如壊れた。。
もう10年使ってるものだから壊れても不思議はないのだが、なぜこのタイミングに？おかげで回りっぱなしのファンを目の前にして作業しなければならない。これも大問題で、ファンの音を聞いてると何もやる気がおきない。 ＢＩＯＳ戻しちゃおうと思ったのだが、グレードダウンはできないらしい。ガックリ。。
でも、以前からCRTディスプレイが壊れたら液晶ディスプレイに買い換えようと思っていたので、それはそれでいいだろう。リサイクルステッカー無いから処分するのに4200円かかるけど。
次に買う液晶ディスプレイはWUXGAのを買いたいなと思ったが、DELLのだと75,000円くらいで買える。WSXGA+だとなんと30,000円。やっすいなー。 しかし、WSXGA+だとノートPCの液晶と同じサイズだからちょっとやだなと思ったのだが、値段との兼ね合いもあるし、配置を変えればノート本体のディスプレイと外部ディスプレイでマルチディスプレイにすればいろいろ便利だ。その線で行こうかな。
うるさいファンについては、、CPUファンの制御ができるアプリがあるはずだと思ってさがしてみたらFanSpeedってのがあった。 しかし、ＢＩＯＳがサポートしてなきゃコントロールできないから一緒だ。 ボツ。
本当に温度が下がったらファンは止まるのか？という疑問を解消するため、ノートPCの下に保冷剤を敷いてみた。すると、しばらくそのままにしておけばファンは低速になる。 ふむぅ～、一応温度に反応してるわけだな。 ＢＩＯＳアップでずいぶんと温度に対する反応を変えたんだなー。 うちのは熱暴走なんて一度もないから変えなくてよかったのに。
温度を下げれば音は静かになるとわかったので、ノート用の冷却グッズを探してみるか。ファンを使わないやつ。保冷剤並みの効果があるのって、、、無いよなー。
転倒回避歩行については、デバッグを完了し、更に足首ダンバー設定なども折り込んでまともに動くようにはなった。 実は歩行計画部分にバグがあったのだが、それ以外にも歩容生成部にも大きなバグがあった。通常の歩行だと問題にならない箇所だったのだが、転倒回避歩行では顕在化するバグだった。
動かしてみると、、、、一度動き出すとガシャガシャガシャガシャ動き続けて、最後にはやっぱりこけちゃう。これじゃ意味無いなー。自分が動いたことで転倒速度が発生してしまう。今の設定はちょっと過敏にしてるから余計にそうなってしまうのだが、この辺りも微調整の範囲なのだろうか。
あと、なんていうのか、動作にエレガントさが無い。こけていく様子に合わせて足をふいっと出してほしいのだが、まぁ、簡単じゃないね。基本的に転倒回避は一歩で完結するようにすればまとまりはいいのかもしれない。だが、複数歩での対応は絶対に必要だし、それがないのも不自然。両方がうまく共存できる方法ってあるのかな。安定した動作のためには受動関節の考えが必要なのだろうと思う。
まだまだ手段を検討しなければならないようだ。あと少し動作が安定したら動画アップしておこうと思う。
■５月２７日■
朝っぱらからロボットをガシャガシャ動かしていたのだが、芳しくない。
大体にしてガシャガシャ動き過ぎ。 もう見ていられないくらいガシャガシャしてる。これをなんとかしたいので、遷移時間を0.4秒に固定してみた。 それでもまだガシャガシャするのでいったん落ち着いて再検討。
基本的に1歩で対応する路線で考えて行こうかと思う。ただし、それだと足りないのでこけそうになっても踏ん張るジャイロデータのフィードバックによる安定化を融合して行きたいと思う。
というわけで、ジャイロフィードバックを任意転倒軸に対応できるようにしなければならない。 今はX軸回りでのコーディングになっているのでそれを二次元に展開する必要がある。以前はX軸とY軸で同じようにすればいいと考えていたのだが、今回の転倒回避歩行で行った転倒軸に対応できるようにしよう。
で、早速足首だけをくりくり動かすための数式の検討を始めたのだが、なんせ、もういろいろなパラメータがあるのでもう何がなんだかわからない。
ラムダは線形倒立振子の計算をしているが、動作は単純倒立振子だ。そのため、逆運動計算用のパラメータに「軸足を基準とした左右回転」というのがある。 実際はこれを基本パラメータに反映させるのだが、その計算式が手抜きなのだ。 いや、手を抜いたわけじゃなくて、今日手抜きだったことに気づいたのだが、挙動は問題なかったので間違えていることにきがつかなかったのだ。
ラムダの姿勢は
Rot(z,roll)・Rot(y,pan)・Rot(x,tilt)
という関係になっている。
この姿勢を基本に持ちながら更にパン回転を行うので
Rot(y,pivot_pan)・Rot(z,roll)・Rot(y,pan)・Rot(x,tilt)
とならなければいけないところ、単純に
pan = pan + atan(tan(pivot_panl) * cos(roll))
tilt = tilt + atan(tan(pivot_pan) * sin(roll))
としていた。rollにはpivot_panの影響が出ないようになっていたのだが、出ないはずはないのだ。
じゃ、ちゃんと計算してみようということで、
Rot(y,pivot_pan)・Rot(z,roll)・Rot(y,pan)・Rot(x,tilt) = Rot(z,roll)・Rot(y,pan)・Rot(x,tilt)
という式を立てて、pivot_panを練りこんだroll pan tiltを計算してみた。
s(br1)c(p1) tan(br) = ----------------------------- c(pp)c(br1)c(p1)-s(pp)s(p1)
s(pp)s(br1)c(t1)-s(pp)c(br1)s(p1)s(t1)+c(pp)c(p1)s(t1) tan(t) = ------------------------------------------------------- -s(pp)s(br1)s(t1)-s(pp)c(br1)s(p1)c(t1)+c(pp)c(p1)c(t1)
sin(p) = s(pp)c(br1)c(p1)+c(pp)s(p1)
結構な計算量だ。 でも、今のままでも問題なさげなので、どれくらい値が変わるのかを調べてみると、0.1度くらいしか変わらない。うむむぅ～どうしようか。
でも、よく見ると今の式はあんまりだな。フリージョイントじゃないんだから、panとtiltは計算式が違うはず。それくらいは計算してみようと思ってやってみた。
Rot(y,pivot_pan)・Zu = Rot(z,roll)・Rot(y,pan)・Rot(x,tilt)・Zu
※(ZuはZ方向の単位ベクトル）
これを展開すると、
pan = pan + atan(tan(pivot_panl) * cos(roll))
tilt = tilt + asin(sin(pivot_pan) * sin(roll))
となった。これをさっきのちゃんとした式と比較すると、、、前よりずいぶん悪くなってしまった。 多分考え方がどこか間違えてるんだろうな。
pivot_panは値の小さな部分でしか使わないので今のままでも問題はなさそう。これくらいの計算なら増加しても問題はないのだが、とりあえず保留。
で、本題の、任意の転倒線でのジャイロフィードバックの件は
Rot(z,φ)・Rot(x,θ)・Zu = Rot(y,pan)・Rot(x,tilt)・Zu
φ方向へθ傾くことをtiltとpanで表すと、
sin(tilt) = cos(φ)・sin(θ)
tan(pan) = sin(φ)・tan(θ)
roll = ??????
となります。これを足の逆運動計算に組み込めばいいのだが、今の計算式は「足が水平面に設置している時の股関節の座標と姿勢」を計算する形になっている。
rollは本来のbody_rollとは違って、tilt,pan分回転した結果発生する「ねじれ」です。
その式にこれを埋め込むということは股関節座標を目的の座標からtilt、pan分回転させた値を与えるということになる。
実際には足首の角度になるわけだからそれこそ無駄な計算だ。パラメータを増やして床面の傾斜パラメータということにしよう。 これはかかと上げ歩行にも必要なパラメータだから今後も使い道はあるだろう。
ふぅ、転倒回避歩行については、今日はここまで。 今日中にカタチにしたかったが、もう少しかかりそうだな。
一方、ラムダの改良の方も検討を始めている。基本的な配置は大体決まった。
頭をつけなきゃならないのだが、いま使っているデジタルサーボはあまり使いたくない。 いいのないかなーと考えていたら、フタバのRS301CRがよさそう。基本的にはRS601CRと同じことができそうな感じ。 手に入るのかなーと調べてみるとロボットファクトリーで買えるみたい。
勢いで３個買いました。あ、301は高いのでRS302CRにしました。頭にはこれで十分。 サーボホーンのトルクリミッターもあるみたいだし、直接制御できそうだし、いろいろよさそう。 うまくいけばマニピュレータにも使えるかも。
いつくるかなと思ったら、これ、まだ発売してないんだね。5月中には発売になるみたい。コマンドマニュアルも公開されるんだろうなー。されないと困る。
そういや、LCDディスプレイも注文しなきゃな。出費続きだ。
■５月２８日■
今日は足の逆運動学計算に床面の傾斜パラメータを加えることにする。
足の構造体から逆運動計算から変えないといけないので結構な大仕事。c++なら引数をデフォルト指定することができるので、こういうとき便利だ。 メインプログラムから前のカタチで呼んでいる部分は変更しないでもパラメータを増やすことができる。
これは順運動学計算と逆運動学計算が一意にならないのであまりいい方法とは言えない。その辺りはアプリでカバーするしかない。
検証は静止状態でのジャイロフィードバック動作で確認することにする。 ジャイロフィードバックにはジャイロデータをPIDクラスのインスタンスに入力して補正量を計算して行っている。テスト用にはジャイロデータから角速度を計算してその値を直接入力することにした。
ロボットを動かすとそれに合わせて足首がグリングリンと動く。 見た感じだとうまく行ってる。 今度はジャイロデータ（X軸、Y軸）を、関節構造に合わせたデータ（チルト角とパン角）にして動かしてみる。 これは一度、傾きデータ（X軸とZ軸）に変換してから更に変換する。 予想通りほとんど変わらない。 おかしな挙動をしないからまぁいいのかな？ 大きな値になると違いがあるのだが、小さな値だとほとんど変わらないのだ。ジャイロフィードバックの範囲ならわざわざ変換しなくても問題ないなぁ。
しかし、ジャイロデータを直接入力しているとピョンコピョンコして動作は発振してしまう。PIDデータに戻すと、ふわんと動いていい感じ。なんかいいなぁ。クラスPIDは結構成功だな。ジャイロが大きな値を出しても過敏に反応しないようになってる。
さて、下準備ができたので転倒軸に対してのジャイロフィードバックも完成間近。 転倒回避歩行と合わせるといいことあると良いのだが。
今日はさっさと動かすためにソースの修正が中途半端。こういうのは後からバグになって恩返しされるに決まっているのだが、 明日にでもちゃんと修正するつもりだから恩返ししないでください。<(_ _)>
■５月２９日■
今日で、ジャイロフィードバックの一般化が完成。
結局、昨日コーディングした部分は一般化のために相当書き直した。下半身全体で考えたとき、フィードバックすべきは両足の足首を結んだ直線を軸にした方向のみ。転倒するのは転倒検出でやった支持多角形の重心からの距離がもっとも短い線。 この二つは普通、ほぼ平行になる。ジャイロについては足首を結んだ線でフィードバック軸を決めてみた。
で、足の向きや腰の向きにかかわらず角速度をベクトル分解して転倒線を軸にした角速度を算出し、それをフィードバックするのだ。
ま、まだちょっと調整が足りなくてパラメータの微調整は必要だが、基本的な機構は完成といってよいだろう。
このフィードバックをかけていると、結構な外力を加えても転ばない。
まてよ？すると転倒判定の結果が狂ってくるな。ちょっと判定の検出感度を調整する必要があるかもしれない。検出感度はノミナルにしておきたいなぁ。
では、明日からは転倒回避歩行とのコラボレーションの検討と実装に移ります。
コラボ検討をしなくちゃいけないのだが、気乗りしない。
昨日は急遽飲みに行ってたのだが、家に帰ると新しい家用のノートパソコンが届いていた。今まで使っていたノートパソコンは電源がおかしいらしくって起動に何度も失敗するのをだましだまし使っていた。
最近は使っていたらフリーズするようになってきたので、思い切って買い換えることにしたのだ。
あまりヘビーな使い方はしないのでリーズナブルで、画面が大きなのを選んだのだが、メモリーは別に買ったほうが安いので256MBしか積まなかった。XPも256MBだとまともに動かないんだなー。環境移そうと思ったのだが、カリカリカリカリハードディスクが動くばかりで作業がはかどらない。すぐにでもメモリー増設が必要だということがわかった。
酔っ払い状態で増設メモリーを注文したのだが、大丈夫だったかなー。明日届く予定デス。
プログラムは乗り気がしないので構造検討。胴体の２軸を削除して軽量化と、重心を今より前寄りにすることを念頭に配置してみた。
首から上は、まだまだ検討する予定なのできわめて暫定です。
いままでは隠れていたRPU100も背中側からアクセス可能に。これでRPU100に実装されているスイッチとLEDが使える。これはRS485回線がフリーズした時も使えるインターフェイスなので操作できるようにしたいなと思っていた。RPU100を改造して引き出そうかとも思っていたが、このラムダに関してはそこまですることはないだろう。
前へ転倒②
前へ転倒③
後ろへ転倒①
後ろへ転倒②
後ろへ転倒③