■10月1日■
今日から10月。ページの長さも頃合なので新しいページに切り替え。
ラムダの、開発中のプログラムには既知のバグがいくつかあるのだが、それほど支障がないし、バグ取りはすごく時間がかかることが多いのでほっておいてるケースがある。
昨日の夜、そのバグのうちのひとつ、電源を入れてから第一歩目に腰砕けになる、というのがあるのだが、イラっとしたのでバグ取りを決意。
ところが、電源を入れて一歩目に必ずなるわけでもないし、発生条件がわからない。 なんどかトライしているうちにデータを採取することができた。
うまい具合いにデータが採取できたのでそこから類推してバグの個所を突き止めようとしたのだが、どうもコンパイラバグか、ライブラリバグか?
電源を入れて一回目の cosh( ) の計算がおかしな結果を出すと思われるのだ。そんなことあるのかな?
昨夜は時間切れ、今日続きをやろうと思ったが、予定外の残業でもう遅いし。。。 確認と対策は明日かなー。
いま、ラムダの歩行は倒立振子動作なのだが、計算は単振子として扱っている。振子の重りの位置はロボットの重心点だ。
だが、実はこれはダメで、せめて剛体振子として計算しなければならない。実際、重心点をそのまま計算に使うとロボットは吹っ飛んでしまう。計算上は重心点の高さに補正を入れてもっと高い位置に重心があるように振舞っている。
高さに補正を入れたのは試行錯誤だったのだが、これは剛体振子を単振子に置き換える相当単振子の計算をすれば補正量が計算できるようだ。
倒立じゃない振子での計算しかわかってないので倒立振子の場合もまったく同じかどうかはわからないが大体同じだとすると、
L=I/M・h
L : 単振子の腕の長さ
I : 剛体振子の慣性モーメント
M : 剛体振子の質量
h : 剛体振子の支点から重心点までの長さ
振子の等時性から単振子の場合は重りの質量は関係ない。が、剛体振子の場合は慣性モーメントが関与するため質量が影響する。
L=h となるには I=M・h^2 となる必要があり、それはつまり質点ということになる。普通は L > h となるのかな。
やっぱ慣性モーメントも計算しないとダメかなー。
というのも、昨日の足踏み運動で足上げをしない場合なのだが、あれは重心点が十分に目標到達点に到っていないなと。。。高さ補正が適正ではないらしいなと。。。適正な振子動作であれば遊脚は足をあげなくても荷重が抜けるはず。その補正点を知るには慣性モーメントが必要。 ということだ。
その他、遊脚を上げる動作についても反動が生じないような動作を考えなければならない。 要するに足が重すぎるんだな。
教科書「ヒューマノイドロボット」によると質点として計算しても差し支えないと書いていたが、あれは相当単振子のことをさしていたのか、重心点を基準とした単振子としてみていたのか。どちらにしてもプロメテとラムダでは重量分布が違うということだ。
■10月2日■
ラムダの慣性モーメントを計算するのはちょっと手間がかかるので簡単なモデルで計算してみよう。
上半身と下半身の重量と重心が同じというロボットを想定する。床との接触面が支点となる振子を考えた時の相等単振子を算出してみる。
慣性モーメント
I=w・(h/2)^2 + w・(3h/2)^2
=5wh^2/2
相等単振子の腕の長さ
L=I/Mh
L=(5wh^2/2)/(2w)h
=1.25h
相等単振子の腕の長さは支点から重心点までの長さの1.25倍にもなる。
ラムダの場合、高さ補正は200ミリにしており、この時が結構安定した動作をする。ラムダの重心高さは、路面を支点とすると、175ミリくらいにある。だいたい中央である。1.25hとすると、高さ補正値は43.75ミリ、随分と小さい。
関節の柔らかさや足の裏のクッションでロスがあるから計算値(論理値)と実験値とのズレは大きいとは考えていたがこれほど大きいものか。
もう少し詳しく計算してみて計算値で実験してみる必要がある。 足の裏のクッションはロスとなるはずだが、関節の柔らかさは位相遅れによるゲインがあるんじゃないかなと思っている。
で、実機で実験したところ、ぎりぎりまで補正高さを下げていって、160mm。 それ以下だと横に吹っ飛んでいく。概算結果とは大幅に違うなぁ。・・・ さて、では慣性モーメントの計算をコーディングしますか。。。。 慣性モーメントはもしかしたら動作安定化の要かもなぁと思ってる。たとえば、左右動作をさせても前後のふらつきがどうしても発生する。静的には重心位置を補正してるのだが、部位により左右動作による慣性力は異なるわけで、その違いが前後のふらつきになると考えられる。その現象が予測できれば上体で補正することができるかも。 重心補正と違ってフレーム毎に計算する必要はないと思っているのだが、、、計算すべきことは増える一方だなぁ。
cosh( ) のライブラリバグの件はまだ不明。今日の一歩目もおかしかった。main( )の先頭辺りにcosh( )をダミーで計算させて、問題が発生しないかどうか様子を見る。それまではcosh( )は2回計算して、結果が異なったらプログラムをとめるというコードを埋め込んでおく。
■10月4日■
◇歩行安定化
きちんと慣性モーメントを計算しないと始まらないだのが、、、相等単振子と考えた場合でも、理論値と計算値は一致しない。振子(振子を単振子と見た場合)の振幅が理論値と合わないということは
@与えられるエネルギーが理論値と異なる
A振子が単振子ではない
ま、どちらも当てはまるだのが、乖離が大きいことからAの可能性を検討してみる。
もともと単振子ではなく剛体振子でもなく二重振子でもないということは判っているのだが、どこまでモデル化の手を抜けば実用に値するモデルになるかって話。
色々考えてはいるのだが、今のところ二重振子構造しか思い当たる節がない。
二重振子構造だとしても振子の一重目と二重目がまったく同じように動けばそれはもう単振子に置き換えることができる。違うと言うことはまったく同じには動いていないわけだ。
二重振子はカオスを見ることができるという題材に使われているケースが多いようで、それくらい複雑な動きをするということだ。 そんなにまで複雑な動きをしているようには見えない、というか二重振子と言っても二重目はフリーではなくダンパーとリミッターが入った振り子なので自由には動けない。動作を解析するよりも単振子として扱えるようにするにはどうすればいいのかを考えるべきなのだろう。
そんなふうに考えると、大抵のロボットはラムダとは違って胴体の姿勢が保持できるように動いているケースが多い。あれは二重振子の一種だろう。倒立振子として扱ったとすれば二重倒立振子だ。そのように扱っているのだろうか?
動作の安定化を進めるにはフィードバック制御がどうしても必要。 まず不安定具合の取得。胴体姿勢については別途検討中なので、その他について。
往復動作の安定性を制御するのが随分と前からの課題で、未だにできていない。もう一度それにトライしてみるつもり。
前回は振幅の大きさを監視していたのだが、重心点の速度を監視すべきかもしれない。 そういや、実際の速度と指示速度の比較をしてみていない。速度やタイミングの実際を測定してみる必要がありそうだ。
もうひとつ大事なことはフィードバックをどのようにかけるかということ。オーバースピードを検出しても簡単にはブレーキがかからない。なにせロボットは路面に固定されていないわけだから動作を抑制しても物理的に動き続ける。そこのところが難しいところ。
ひとつはジャイロでの安定化でよくやっている足部分で踏んばるように角度を調整するってことだ。左右振幅でこれをやるとばたばた暴れてしまって安定どころか不安定になるか、さっぱり効果がないかのどちらかだった。 今考えているのは振子の腕の長さ、重心高さを上げ下げすることだ。
倒立振子の場合、センター部での速度が同じなら重心高さが高いほど振幅は大きくなる。 ならば、想定速度より早ければ重心を下げてやれば適性に近づく。逆に速度が遅ければ重心高さを上げてやれば適性に近づくはず。 理屈の話だけで、どのように実装するかってことも大きく影響すると思うが。
◇加速度センサー
今日はシーテックへ見学に行った帰りに秋葉原へ寄り道してきた。目的は3軸加速度センサユニットの購入。 秋月は月曜日と木曜日が休みなんだけど、最近は月木はパートのおばさんが店番をやっていて、POS対応の商品だけは売ってくれる。3軸加速度センサユニットはPOS対応だったんで無事買えました。というか売れ筋商品なのか、レジ横の袋にザクザク入ってて、新刊の漫画みたい。 これでニューセンサーボードの部品は一通り揃いました。早いとこ仮組みしてどれくらいの周期でデータ取得可能かを試してみたいところ。
シーテックは規模が大きくてあんまりゆっくり見て回れなかったけど、ソニーの超薄型有機ELディスプレーとムラタセイサク君は見てきました。ムラタセイサク君始めて見ました。
ムラタセイサク君キーホルダーと3軸加速度センサー
◇転倒判定再び
それはそうとこないだ諦めた揺り返しでこけてしまう場合の判定なのだが、やはりあれは判定しなければならないらしいということで再度検討してみた。
こないだはロボットのインピーダンスの低さが要因で結果が大幅にずれると結論付けたがそれだけではないかもしれない。
外力により転倒するかしないかというときは、線形倒立振子ではなく、単純倒立振子だ。すると振子の連結による軌跡は、、、なんていうか、、カモメみたいな形になって、あまり効率よく力の授受が行われないはず。そこでのベクトルの違いによるロスは考慮に値するはずだ。
復帰方向の倒立振子動作で加速した重心点の速度は支点と重心点を結ぶ線と直交した方向。次の倒立振子に受け渡すエネルギーは黒い矢印のように分解され、ちょっと上向きのベクトル成分が受け継がれるはず。線形倒立振子は高さが変わらないから上下方向の速度は発生しないので、いうなれば緑の水平な矢印に相当するエネルギーが引き継がれている。 程度の問題ではあるが、黒いベクトルの方が受け継がれるエネルギーは小さそうなので判定が変わる可能性もあるかなぁ〜と思う。
これだと単純倒立振子で計算せねばならないので計算量がべらぼうに増えてしまうのだが、一度やってみるしかないかな。
なんだか発散してしまって何をやればいいのか何がやりたいのかわからんようになってきた。 カメラ部の構造設計のことすっかり忘れてるなぁ。。
■10月5日■
なんだかんだで週末である。待ちわびたようでもあるし、週末までになんかこなしたかったけど出来なかったというあせりもあるしで複雑な心境。
依然、発散してしまっている状況が続いている。ちょっと整理してプライオリティーを明確にしなければずるずると時間ばかりが過ぎてしまう。 ざっと項目を挙げてみよう。
@転倒回避歩行 歩行ルールの洗練の前に転倒判定の見直しが必要か。胴体姿勢取得も関連。@-1:転倒判定の見直し @-2:歩行計画ルールの洗練 @-3:胴体姿勢取得→新センサーボードの開発 @-4:転倒受け身動作
A歩行安定化 基本的な安定化の検討と、外乱や同期外れからの回復の手法の確立。 A-1:倒立振子の検討(二重振子化防止とか。。) A-2:慣性モーメントの算出 A-3:位相差測定 A-4:重心移動速度の指示値と実測値の比較 A-5:足上げ動作の改良 A-6:振子動作の安定化制御実験(振子の腕の長さを変えることでフィードバックができるか)
B全身運動の準備 歩行もいいけどやはり早くロボットを自律させたい。歩行はへたくそでいいから全身動作させたい。 B-1:逆運動計算の連続性確立手法(解が2通りある場合の処理) B-2:干渉の回避 身体をデータ化して身体との接触を計算によって感知する。 B-3:動作計画立案ルール 未検討だからよくわからん。 B-4:外装作る 全身動作させるとフレームだと引っかかったりしてよくない
Cカメラ関連 C-1:頭部フレーム設計・製作 C-2:画像処理(いっぱいあるから十羽ひとからげ)
・・・・
これ以上書いてもきりがないのでここまで。
CDT関連とかサッカーモーションは計画にない。 もうロボカップヒューマノイドリーグにはあまり興味がなくなってます。3体出すってのは無理だし、サッカーをさせるのは今後の自分が作りたいロボットのための要素技術を含んでいるとは思えない。逆はあるけど。 散々回り道してるからもう回り道はよそうかなと思う。そういう意味では歩行に執着していつまでも歩行とか転倒回避をやってるのもまずいなぁと思い出している。転倒判定から受け身動作を起動するようにして、早々に自律ロボットを立ち上げた方がもっと広範囲な問題が見えてくるのではなかろうか。
とはいえ、直近の興味はいまだ倒立振子の挙動操作にあるのでその辺りはもう少し詰めつつ、自律ロボットへ急接近せねばならないなというプライオリティー付けをしていきたいと思います。
とりあえずはA全般を進めるって感じだなー。合間を見て@関連を研究する感じ。 BCはAをひととおりやった後着手。BCが自律化に対しては大きいから片手間というよりメインにしていかなきゃならない。
・・・・・・
一番簡単に出来る、指示速度と実測速度の比較をやってみた。
水色のラインが計算値で、それにかぶっているラインが実測値。
2割から5割増しってとこか。。 指示値よりも実測値が上回っている。上の画像は高さ補正が200mmの場合なので、高さ補正を相当単振子並にするととんでもないオーバースピードになるんだろうな。
どうしてスピードオーバーしてしまうのか。一歩目の遅れと二歩目のオーバースピードが気になる。
■10月6日■
慣性モーメントの算出ができました。
歩行に即した軸の算出がまだできていないので正確な軸位置ではないのだが、大体の軸座標をマニュアルで設定したところ、
慣性モーメント : 126798800.000[g・mm^2]
質量 : 2618.000[g]
重心高さ : 186.191[mm]
相当単振子の腕の長さ : 260.128[mm]
となりました。高さ補正は74mmと、概算の時に比べると高くはなったのだが、調整値の200oには程遠い。
・・・・・・
次は速度オーバーをキーに左右動作にフィードバックをかけるという試み。
正常動作の時に、既に2〜5割増しで動いているのにフィードバックかけるってのも無謀だな。さらにはピーク点に遅れがあるので単純に比較は出来ない。
とりあえず、二重振子化しないようにする試みをいくつかやってみたのだが、ことごとく失敗した。
もうちょっと観察かなぁ。。
#モニターグラフを見る限り、そこそこいい感じとも思えるのだが、足上げもしていない緩やかな動作でこのずれは大きい。フィードバックかけるとなるとこれじゃ暴れだすだろうな。
■10月7日■
さて今日は左右往復運動の速度監視からオーバースピード防止のフィードバックをかけるという実験をやってみようと思い、昨日までのソースコードの整理などやっておりました。
で、ちょっと確認したいことがあったので、整理したところでロボットを動かしてみたのだが、
out of Memory
なにぃ〜!!メモリーは腐るほどあるだろうがぁ〜! と思って調べてみた。
まず、立ち上げなおしても直らない。ブートミスの可能性は軽減。ハード障害はまだ疑惑内。
プログラムのバイナリーサイズは今日現在536kB C++、STLを使うと驚くほどバイナリーが太る。が、RPU-100はRAMを128MB積んでいて、ストレージがCFカードだから通常はRAMDISKにメモリー空間を割り当てているくらいだ。この程度で物理的なメモリー不足になるとは考えにくい。
起動してもすぐにコアダンプしてしまうのでどれくらいメモリーを消費しているのかわからん(コアファイルはいつもより小さいくらいで650kBくらい)
で、よく挙動を見ると、とりあえずプログラムは起動して、初期設定段階でコアを吐いて死ぬ。んじゃ、プログラム中でメモリー不足が発生するわけか。
プログラムの初期段階ではロボットの関節構造とか質量セグメント構造とかのロボット構造データを構築しているのでここでメモリーが追加消費するはず。で、質量セグメント構築部分をすべてコメントアウトしてみたら、、、動きだした。 なんだかショック。
・・・・ 昨日はこれで動いてたのになぁ。 で、ちょっとずつコメントアウト部分を減らして行ったら、、、元に戻しても動くようになってしまった。なんだかなー(ーー;)
依然原因はわからないまま。 メモリー使用制限にひっかかったのかと思ったりしたが、rootで動かしてるんだよね。
psの結果
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 252 25.1 2.4 512 1444 p0 S+ 1:38AM 0:47.67 ./lmd
起動した状態のvmstat
%vmstat
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr w0 m0 m1 m2 in sy cs us sy id
0 0 0 15536 33756 9 0 0 0 0 0 0 0 0 0 565 3322 55 2 3 95
rootでのlimitとlimit -h
%limit
cputime unlimited
filesize unlimited
datasize 131072 kbytes
stacksize 2048 kbytes
coredumpsize unlimited
memoryuse 53216 kbytes
descriptors 64
memorylocked 17738 kbytes
maxproc 160
%limit -h
cputime unlimited
filesize unlimited
datasize 1048576 kbytes
stacksize 32768 kbytes
coredumpsize unlimited
memoryuse 53216 kbytes
descriptors 1772
memorylocked 53216 kbytes
maxproc 532
さっきは何が起こっていたのだろう?
システムがまともに動いているように見えるのでハード障害の可能性は低いとは思うが・・・、いままであまり気にせずにガツガツ転倒させていたのだが、転倒衝撃で壊れたりしないか急に心配になってきた。機械的に壊れるとしたら基板撓んでハンダ付け部分にクラックが入るということが考えられるが、軽さとか大きさとか衝撃の大きさから考えるとほぼ問題ないとは思うのだが。
・・・・・・
オーバースピードフィードバックの前に、足上げをもっと軽やかにしよう、ということで、今までは台形波だったのだが、曲線を使うことで足上げによる加速度の発生を抑えようという試み。
サインカーブの合成で作ってる。立ち上がりをもっと緩やかにしたいくらいだが、加速時間との兼ね合いも考える必要がある。 効果はあるような無いような。。。 パラメータいじったりして様子みましょう。
アイディアとしてはかかと上げで膝を上げておいて、足首を返すだけで足上げを完了させるっていうのもあるが、コーディングが大変なので後回し。足を下ろす時もつま先から下ろせば軽やかになる? 忍び足って感じで。
・・・・・・
速度監視をしたいのだけど、位相が遅れているから、正確に最高速度を測るには1周期またなければならない。フィードバックの対応は出来るだけ早く、というよりその周期に対応しなければ手遅れと考えていいだろう。すると位相遅れがわかっていなければならず、位相遅れを知るには1周期測定せねば・・・。
って感じでいいアイディアが出てこなくてオーバースピードフィードバックは停滞。
何にもしないのもなんなので、急に思い立ってモーション再生プログラムを作ることにした。関節角度ではなく、上半身姿勢と下半身姿勢で管理する。そうすることで色々とやっかいな問題が発生するのだが、姿勢で管理する利点は、、あるような、、ないような。
大体材料は揃っているのでサクサクっとできるかな?と思ったら、なんか知らんが放置バグのせいでへんな動きをする。 うーん、なかなかすんなり進まないなぁ。続きは明日にするか。 まずはバグ取りからだな。ふぅ。。。
速度監視のアイディア(っていうか折衷案)はモーション再生プログラムをコーディングしている最中に思いついた。それで行ってみよう。
・・・・・・
明日は関東組練習会。 ラジコンロボじゃない自分が参加してもいいものか、ラムダは持っていく方がいいのか?ちょっと考えたが、持って行ってみんなにダメ出ししてもらうのもいいだろうってことで持っていくことにしました。 ラムダを動かすにはノートパソコンと無線LANアクセスポイント、バッテリーはまだ搭載できないので電源。その他ネジ・工具などなど。。。 結構な荷物だな。更に明日は昼から雨らしい。 人に見せることになるんならさっさと頭部を作ればよかったなぁ、頭なしかっこ悪い。
■10月8日■
姿勢ベースのモーション再生に意外とてこずっている。
昨夜のバグは調べたらすぐにわかったのだが、モーション生成で問題になりそうだなと思っていた逆運動学計算の冗長解問題がモーション再生でも問題になる。(考えれば当然なのだが)
いい機会なのでここで逆運動学計算解と関節角度の連続性について実装上の解決を取りたいと思う。
思い返してみると、転倒回避にてこずっていた時(今もてこずっているが) 上半身との協調動作とか姿勢の取得とかをやった結果、転倒開始の姿勢取得が出来るようになったり、胴体姿勢の取得についても開発が進んだりで、いろんな要素があちこちでつながっているのを感じる。
歩行ばかりに執着しないで他の要素技術についても出来るだけ並行に開発するのが袋小路からの脱出の秘訣なのかもしれない。
・・・・・・
関東組練習会行ってきました。
いやー、楽しかったデス。やっぱ同好の士はいいですね。ラムダは動かせなかったんでアレなんですが、みんなのロボット見せてもらって色々勉強になりました。
キノピー見て、早くラムダにも外装着けなきゃって焦りを感じてしまった。キノピー出来過ぎです。イガアさんにはリポとかサーボについて色々教えてもらってラムダにも早くバッテリー積まなきゃと思いました。あと、、、やっぱ4000番サーボはパワーありますね。あこがれます。
ラムダは初めての外出だったんですが、無線LANが不調で有線LANでしか使えませんでした。家じゃない環境で色々と試したかった事もあったんですが、何もできなかったのは残念です。APのせいならいいんだけど、PSコントローラとの干渉のせいとかなら問題です。ロボットが集まるところじゃ使えないってことになる。そのへんは課題だなー。ラムダは11bオンリーなんで、11bがダメなら有線しかない。
これからラムダ立ち上げて、ハード障害で動かなかったわけじゃないことを確認だけして寝よう。 明日からまたがんばらねば。
■10月9日■
昨日の練習会で無線LANが不調だったのはラムダのハード障害ではありませんでした。APが環境に耐え切れなかったらしい。新しいAPならなんとかなるのかなぁ。
キノピーといしかわさんのSDレイズナーを見て、やっぱり外装つけなきゃと思いたって、今日はずっと肩の外装の構造を考えてた。(^_^;) ジョイントボールを肩にまわして、肘は普通のブラケットにした方が外装は作りやすいかも。。
あと、クロムキッドの手を見てマニピュレータも早く作らなきゃと、、 アタマとマニピュレータと外装と、、次に練習会に行くときには外装つけて行きたいな。
姿勢ベースでのモーション再生をやっちまおうと思って、色々調査。わかったのは、、ラムダは体育座りが苦手。
姿勢ベースと言っても最終的には足の座標と姿勢に変換して関節角度に変換するのだが、 体育座りに近い姿勢だと、股関節と足首関節の高さ(Z軸座標)の差が近くなる。
逆運動計算では、やり方はまぁ色々あるのだが、ラムダの場合は膝関節と足首の左右の角度をまず算出する。 この足首左右の角度を計算する時にZ軸座標値とX軸座標値を使うのだ。この値が共に小さいとき、少しの誤差が大きな差となって現れてしまう。
いま、ウィンドウズのコントローラソフトとラムダの間の座標値は下3桁で行っているので、数値が小さくなった時の誤差が大きく影響しちゃうらしい。ケタ数増やせばいいんだけど、更に数値が小さくなったら結局は一緒のこと。できればケタ数を増やさないで実用的に処理したいのだが〜。。
・・・ いや、違う。よく考えるとそうじゃない。(実際にケタ数増やしても全然改善しないし) 膝が股関節より上に上がった場合は膝が股関節より下の場合とは足首の角度の考え方が違う? 違うんじゃないか? そこかな? そこんところをもうちょっと検証してみる必要アリのようだ。
って気付くと、うぉーもう1時だ。意気込んで帰ってきたのになんにもできなかった。
■10月10日■
検討の結果、体育座り問題の解決策が見えてきた。
まず、問題の原因はやはり数値の精度。IK計算式は間違えてないようだ。
図はラムダの関節構造。 精度が問題になるのはロール角度の精度。 IK変換としては股関節の三つの姿勢角度のひとつでZ軸周りの姿勢角度。足姿勢としては足部の向いている方向として使用される。 そのロール角に対して、Zの値が小さい時にはJ3の関節角度が非常に敏感に反応するのだ。
ラムダの逆運動学計算では第一にJ4とJ6が決定し、次いでJ5、最後にJ1〜J3が決定する。
第一段階でJ6が決定する際はXとZの値から決定する。そのときの足部の向きはY軸の方向を向いているため、Zが小さいとJ6が非常に大きくなる。たとえばZ=0ならJ6は90度になってしまう。
ところが、ロール角を少し変更し、股関節と足首を結ぶ直線と平行にすると、そのラインをY軸としたときのXは、X=0となる。 tanJ6=-x/-z なので、J6=0となる。
つまり、姿勢値のロール角がほんの少し違うだけで、J6は非常に大きく影響を受ける。
IK計算としてはJ6を決めないと先へ進めない、かといってロール角の精度を上げてもキリがなく、Z=0の場合はやはり不都合が生じる。なので、こちらの都合のいいようなJ6を設定し、それに合わせたロール角にすることで体育座り姿勢近辺の「姿勢<=>角度変換の不安定さ」を解消できる(はず)。
指示したロール角どおりにはならないのだが、この場合はロール角は大した意味をもっていないため、膝の位置を優先にした方がよいだろう。名付けて「J6角度優先変換」・・いや、「膝位置優先変換」かな。
さて、これから実証に入ります。
■10月11日■
体育座り問題、結構根が深いです。
問題の発生原理は昨日の検討結果でほぼ間違いなさそうだし、修正方法もほぼいいんだけど、修正の適用範囲が判らない。 同じように動かしているつもりでも盛大に関節が踊りだす場合もあれば、ひっそり静かに指定の角度に収まる場合もある。 あまり修正の適用範囲を広げたくないし。。。
体育座り姿勢には、今回のモノの他に「股関節冗長問題」(命名シマケン)というのが存在します。存在は随分前から知っていたのですが、今まで放置してました。モーションを動かす事を機に、それも対策を折り込みたいと思っています。思ったより長引きそうだなー。
■10月12日■
週末に向けて、体育座り問題を片付けて、モーション再生を完成させてしまおうと思っていたのだが、成り行きで飲んで帰ったもんだからできなかった。
それでもがんばって関数だけは手直しを終えて、上位関数の修正を残すのみ。・・そこが大変なんだけど。
昨日までは「J6関節角度におかしな値が出てきたら前回の値を使ってrを適切に設定しなおす」というルールだったのだが、あまりうまくいかなかった。今日の案はもう少し積極的にJ6ベースでのIKを行う。 Z値がある程度の範囲で小さかったら r は無視してJ6ベースでモーションを実行する、というルール。IK関数を呼び出す側で積極的に膝位置優先を切り替えるということ。
うまく行けばよいのだが。。 結果は明日。
・・・・・
この週末は機械設計、できれば工作までやりたいなと思っている。 設計してすぐ製作だと間違いの元なので製作は来週かな? そのためにもモーションは終わらせておかないとね。 しかかりジョブ多過ぎになってきた。 マリオギャラクシーが発売になるまでになんとかせねば〜。
■10月13日■
<体育座り問題まとめ>
いままで数値精度の問題だとか、いやそうじゃないとか言っていたが、一言で何が原因と言えるほど簡単ではないらしい。
この姿勢から この姿勢へ移行する。
移行中の姿勢値をグラフにすると、
こんな感じ。すべてのパラメータが直線になっている。そのようにプログラムしているので当然。1秒で移行しているので、1s/25ms=40コマある。
この時の足の姿勢値は
こうなる。(左側が右足で、右側が左足 (^_^;) ) 31コマあたりから、乱れがあるが、さっきの姿勢値を守ろうとするとこうなる。 そして、そのときに関節角度の動きは、
こうなる。28コマあたりからぐぐ〜っときてその後は大騒ぎ。 上の足姿勢を守ろうとするとこうなってしまうのだ。
姿勢値を使ってのモーションを行うと、動作途中の姿勢を規定することが出来るが、関節角度への反映を考慮しなければこのようになってしまう。腕の制御を考えるとき、このような事態があるなぁと予感していたが、「どうすればいいかなぁ〜、まぁそのとき考えよう」と思っていた。ここで考えなければならなくなったのは予想外。
総論で対策を言うと、必要な姿勢を守りつつ、関節角度の遷移がスムーズに行われるような姿勢の移行計画を行わなければならない。今回の場合はJ6関節値をベースにした姿勢の移行軌道をいい感じで適用し、そのしわ寄せをロール角を指示からずらすことで補う。
精度が問題になるのは目標姿勢を低い精度でやり取りした場合、関節角度を保存できないことだ。上の姿勢移行を実行すると、下の写真のようになる。目的の姿勢とは膝の位置が大きくずれている。このズレは各パラメータが新値からズレているため、上のモーション移行途中の不安定状態に陥ったわけだ。
ちなみにこの体育座り問題は普通のロボットの足関節構造では起こらない(はず)。足のロール軸(普通はヨー軸って言ってる軸)が股関節最上部にある構造だと膝位置にラムダのような自由度がないからです。
今日一日がんばったけど、まだ完了していません。Z値の極性が変わった時の処理が必要であることが新たにわかって膝位置優先のIK変換の実装が難しくなっていた。キーフレームだけおかしな姿勢にならないように検査と姿勢値の修正をして、やばいエリアでは角度ベースで移行するって処理すれば終わるんだがなぁ〜。なんか負けなような気がしてできない。。(>_<)
■10月14日■
体育座り問題続き。<敗北宣言orz>
Z=0越えについて色々考えていたのだが、真の原因か、もうひとつの原因かはまだわからないが新たな問題をみつけた。
それは「ロール軸消失問題」。 4足歩行の時、既に気付いていて問題にしていたが、ここでも問題になることにはさっぱり気付かなかった。
体育座り姿勢の近辺ではロール軸が効かなくなるのだ。具体的には胴体と大腿の交差角度が90度になった時、J1軸とJ3軸が重なり、自由度がひとつ下がる。静的な姿勢で考えるとJ1関節を90度にすればJ2関節が前後の軸から左右の軸と見なせるようになるため、不可能な姿勢があるわけではないのだが、連続性はない。これが世に言うヤコビアンの特異姿勢(でいいのかな?)。
自由に通過できないということは今までやっていたように姿勢パラメータをリニアに変化させて、、ということはできないということ。このエリアを通過するには特異姿勢を決まった方向に通過するしかないということだ。
ちょこっと考えたが、難問そうなので解くのはやめておく。残念だが、ロール軸消失点を使う姿勢移行については角度ベースに切り替えて実行するという方針に切り替えます。
ちなみに普通のロボットの足構造の、股関節の軸消失点も有ります。有りますけど、ざっと考えたら普通は使わないような姿勢なのであまり問題になることはないように思える。(よく検討していないから適当だけど) 歩くだけならいいけど、生活姿勢全般を行うつもりなら大腿ロールの関節構造は適さないようです。
ロール軸消失点を通過するかどうかはJ2関節の角度が90度を超えるかどうかを判定すればわかるはず。
このロール軸消失問題は結構問題。 軸消失が起こる姿勢としては体育座り姿勢への移行中とか、四つん這い姿勢とかがあるが、
ヘタこいた姿勢とも言う
このように腰を曲げて姿勢を落とした時にも通過する。ラムダは生活空間で活動するロボットを目指しているので、モノとの関わりが大事。床に落ちている物を拾うという動作は重要なのだ。この辺りも踏まえて考えていかねばならない。 難しいなぁ。 (T_T)
直線軌道じゃ全然だめで、足首座標と股関節の関係を指示して、膝関節座標の軌跡をコントロールするとかしなきゃだめなのか? どうやるんだろ?
ターミネータ姿勢とも言う
・・・・・
角度ベースでの移行できました。
角度ベースで動かした時に姿勢値はどのように動くのかを確かめてみました。
↓姿勢の偏移。ほぼ直線になってる。
↓足姿勢。Z値が若干カーブを描いている他はほぼ直線。
↓もちろん角度は直線移動。
全部が全部こんな感じではないが、概ね美しいカーブを描く。 美しくてよいのだが、ジャイロフィードバックや重力補正が入れられない。 ま、とりあえずいいか。J2関節が±5度の範囲でモーションにかかる時は角度ベースになるようにしたが、もう少し広い方がよさそう。±10度くらいにしておこうか。
・・・・・
モーションのキャプチャ、セーブ、ロードが出来るようになったのでとりあえず〆。 モーションの編集とかまだやらなけれいけないし、動かしてみると他にも特異点のようなものがありそう。 考えると、コマ送り再生とかを出来るようにして、特異点対策の検討に使える。
しかし、関節工学も難しい。 たかが位置を指定するだけで大騒ぎ。 産業用ロボットの世界では既にあらゆる物理量に対して理論が整理されているわけだから今やっている事って何年遅れてるの?って感じで悲しい。
さて、アタマ部分の構造設計に取り掛かろう。 早く設計しないとマジで冬が来てしまう。冬は寒くて工作できません。(外作業なもんで)
■10月15日■
マニピュレータ用に買ったRS302が届きました。 ロボットファクトリーで買ったんだけど、一緒にRS601用のサーボホーンやらネジ(M2.3っていうレアなネジ)を買いました。
RS302はいいんだけど、、、サーボホーンとネジ。。 なんか日に焼けてないか?長い時間吊るされていた感じ。これってもしかして、ラオックスのあのロボットコーナーに吊るしてたモノなんじゃ???
アタマ部分の設計はほぼ完了。週末には工作できる感じ。 カメラだけだとはじめロボットに似てるから目をつけてみた。外装はキュリオをイメージ。 でも、周りの評判はいまいち。そういや、「飾りで目をつけるってのはアレだよな。」って昔言ったなぁ。。。 カメラがでかくなったからカメラはセンターに配置したいし、一つ目だと愛らしくならないんだよなー。グラフィックとか造形でバランスを取るっていうデザインの素養はないもんで、どうしたもんかな。
■10月16日■
今日は山梨へ出張。特急あずさの中でロール軸消失姿勢を含むモーションについて考察してみた。検証とか実験とかはまったくなのでメモ程度に記しておく。
J2関節が-90度の時、J1軸とJ3軸が重なり、ロール角を制御できなくなる。膝関節はJ1に関わらず同じ座標となる。
ロボットがしゃがんでいく場合を考える。この動作の途中にJ2関節が-90度をまたぐので軸消失姿勢を通過する。つまり、この点での足首座標は膝関節の座標に縛りがあり、Z値についても希望の座標があるが、そのときのX値とY値は選べない。もちろん足部のロール角も選べない。
足のグリップを前提としているので、ロール角は仕方ないにしても足首座標は制御したい。
問題になるのはJ2が-90度の時なので、その時の股関節姿勢を選ぶことで目的のXY値は設定できるはず。その姿勢でのZ値は選べない。
次にJ2が-90度付近の場合の各パラメータの自由度を検討する。
J2≠-90度でJ2≒-90度の場合
sin(J2)は-90度の時-1となり、-90度付近は-1付近の値をとる。
対してcos(J2)は-90度の時は0で、-90度付近では大きく値が異なる。
よって、cos(J2)を含むパラメータはJ2が-90度付近では-90度の時とほぼ同じ値をとり、sin(J2)を含むパラメータは角度のズレに応じた(比例した)値をとる。
んん〜、こういう考え方で挙動が判るのかどうかわからんが、変換式を眺めながら考えてみることにしよう。
J2=-90度を通過するか否かは開始姿勢と目標姿勢での逆運動学計算結果を見ればわかるはず。通過する場合はJ2=-90度となる姿勢を境にモーションを分割し、更にそこから目的姿勢へ移行するように考えればよい。ただし、J2=-90度付近での挙動を考え、どのような進入経路でJ2=-90度の姿勢に近づいていくかを検討しなければならない。
ちなみにがに股になれば、問題の軸消失姿勢を通過せずに大腿が胴体に対して直角になる姿勢を通過できるのだが、通過後にJ3やJ1の可動範囲を超えてしまうため、完全に立ち上がったりしゃがみきったりできない。 通常の動作を考えると軸消失姿勢を通過するように考えるのが正解らしい。
J2=-90度としたときの姿勢値を逆算することってできるのかな?これも要検討。
アタマ部分は再検討中。やっぱりレンズは目の位置にしようかな〜と考え中。カメラはひとつなので、もうひとつの目に何を実装するかを考えなきゃ。以前のバージョンはPSDを搭載していたのだが、今回は「目」っぽくしたい。有力なのはサーチライトの目。暗い場所なら光らせて光量を稼ぐって感じで。
■10月17日■
とあるブログで紹介されていた「ロボットにかける夢」(有本卓著)を読みました。
有本先生の著書なので読んでみました。有本先生の本は大抵難しくってほとんどわからないんだけど、いくつかは入門向け(学部向けかな?)の易しい本があって、自分が理解できる範囲で読むようにしています。
その本に「ロボットの反語として『哲学』という考えがある。というくだりがありました。それを読んで結構びっくりしました。自分としてはロボットって「哲学の体現」という位置づけがあったんです。反語かぁ〜、日本のロボットの第一人者の言葉だし、それは大事に受け止めなきゃダメなんだけど、相当真逆な話だし、どう受け止めていいのか考え込んでしまいました。
新書でうすっぺらい本なんでちょっと物足りないんだけど、ロボットへの取り組みに未来を感じるいい感じの本でした。判りやすーい話から急に運動方程式(それも結構ディープな)が出てくるあたりが有本先生っぽくて笑ってしまったり。
■10月18日■
ロール軸消失姿勢を通過するモーションの生成方法を考えていてふと気付いた。J1とJ3の可動角度を外側にずらせば姿勢移行の不連続点が消えるなと。
正確には不連続点が可動範囲外になるということなので事実上不連続点が消えるということ。
だが、可動角度をずらすと内股系の姿勢がものすごく弱くなる。もしかするとカーブ歩行の時に可動範囲を超えてしまう恐れも。内股と外股のいい感じの角度というのがあるかもしれないのだが、内股姿勢というのはロール軸消失姿勢の通過姿勢で使うわけで、内股が弱くなるというのはなかなか難しい決断。
悩んだ末に今のままの可動角度でいくことにした。その代わり(ってわけでもないが)がに股の場合の不連続点判定をIK関数に入れてがに股での姿勢移行を最大限使えるように考えてみようかと思っている。
がに股姿勢での姿勢移行に注目しているのは、ロール軸消失姿勢を通過するモーションが生成できたとしても、そのモーションを実行する際には重心補正ができないという問題があるから。 計算ずくで軸消失姿勢を通過しようとしているのに重心補正で姿勢がずれると途端におかしなことになってしまうのだ。しゃがむ動作なんかは、できればがに股で行えば結構綺麗に問題が片付く。
色々難しいです。
・・・・・・・・・・・・・・
転倒回避歩行やら、歩行安定化やら、胴体姿勢の取得やら、ハードの設計(アタマ、マニピュレータ、外装、それにバッテリー搭載)やら、そして姿勢ベースでのモーション再生やら、やりかけのサブジェクトがいっぱいなんだけど、兎にも角にもいっぺん自律で動くようにしてみようかなと思ってます。自律っていうからには命令なしで動く何らかのルールを持つことになるのだが、それも含めて「自律行動事始め」ということで、取り組んでみたいと思います。画像はCDTが動いているからとりあえず目標を補足することくらいは出来るはず。音声認識が組みこめられればそれらしいけど、ダメならキーボードから会話を試みるとか。
まずは週末のアタマの製作に向けて構造設計を完了させねば。 どんどんと難しいアタマ構造になってきてます。(^^ゞ
■10月19日■
ロール軸消失姿勢への突入経路を考える。
J1とJ2だけを取り出して、膝小僧の位置で突入経路を考える。 図で、棒の先の玉の部分が膝小僧、根元のサーボがJ1で原点位置にあるのがJ2。半透明のドームは膝小僧の存在できる曲面を表している。ロール軸消失姿勢というのは縦の軸に膝小僧が重なった時のこと。
膝小僧の座標(x,y,z)からJ1、J2を求めると、
J2 = acos(z)
J1 = - asin(x / sin(J2)) または
J1 = acos(y / sin(J2))
となる。
たとえばXを一定にしてYを振らせてみると、
こんな感じ。 今のラムダのIKは紺色の値を出す。 赤色にすればスムーズなのだが、可動角度の問題がある。
ところが、一定にしたXを限りなく小さくしてみると、(ただしゼロではない値)
こんな風な角度遷移になる。こうなるともうサーボは暴れてしまってこけてしまう。Xが小さい程急峻なピークか、がけっぷちができてしまうのだ。
次にロール軸消失姿勢にリニアに突入してみると、
ロール軸消失点を通過して逆側に抜けていく場合。消失点ではJ1の角度は任意なので計算不能になっている。つまり、J1は常に一定でいいのだ。
でも、これは逆に抜けていくときの計算だからいいのだが、実際にはここでカクンと角度が急激に変わってしまう。
最後にサインカーブでロール軸消失点に突入してみる。
緩やかな直線になった。J2のカーブはリニアな場合とほぼ一緒。
やはり大方の予想通り、ロール軸消失姿勢へはサインカーブで突入、 そのときのJ1、J2は決めうちの角度(J1=0、J2=-90)となるようにするしかなさそうだ。
がに股での移行はX値が大きい場合は問題ないが、小さくなるほど角度の変化が激しくなる。要注意だ。
ちなみにグラフは結構適当。acosとかasinを使って計算しているので符号の検証をしなければならない。雰囲気だけ感じ取ればいいってことで。
#そういや、足をそろえた状態でしかできなかった四つん這い。がに股にすれば出来るってことだな。がに股四つん這い、いいかも。
■10月20日■
今日は切り出しくらいまでしかできないだろうなぁ〜、 なんて思っていたら穴あけまでしか終わらなかった。
明日は切り出し、ヤスリ仕上げ、曲げ、タップ立てまでやらねばならない。できるかなー。ま、どっちにしてもスペーサーやらなんやらを買わないと組み立てられないから板金部品だけできても仕方ないのだ。 最低切り出しまで終わればあとは部品が届くまでにウィークデーにこつこつと仕上げればいいということ。
今回はアタマにも外装をつけることを意識して設計した。前に作ったアタマはこけるたびに首が折れていたので、今回は頑丈にした上にサーボの軸で直接支える構造にはしなかった。サーボが302CDでプラギアなのですぐに壊れるからリミッターをつける予定。色々考えたが手狭なので自動復帰するリミッターはできなかった。ずれたら人が直さなければならない。自律ロボットじゃないなぁ〜。アタマが随分と複雑な構造になったので重すぎて首が上がらないなんてことは。。。無いと思うが、リミッターが働いてしまう恐れは大きい。うまくいくかな。組み立てられるのは来週後半くらいか?(注文した部品が届いたら) 動かせるのはサーボの電源基板とか配線を作ってから。プログラムで動かせるなるにはまだしばらくかかりそう。
夜は工作ができないのでモーションプログラムのエディティング部分を作ろうとしたのだが、どうもテンションが上がらない。工作で疲れたってのもあるが、やはりロール軸消失問題が気になってるようだ。でも、「とにかく自律」方針だとロール軸消失問題をクリアして姿勢ベースでのモーションを実装するのはもうちょっと先になる予定。とにかくモーションエディターを作って起き上がりモーションを実装しないと曲がりなりにも自律できない。葛藤です。
他にも転倒回避歩行は転倒検出だけ生かして、転倒受け身にして転倒回避を失敗しての大怪我を避けなければならない。歩行安定化は、、、進めないと行けないな。
「とにかく」といっても自律で動かすのってやはり大変。何が必要なのかを洗い出してみたが、たくさんありすぎて気が遠くなりそう。まずは難しい行動計画は考えないで、「モノを見つけて近づいて手に取る」というのをマイルストーンゴールにしてやってみようとしている。
#実は先々も「行動計画」という類の実装はやらないつもり。意識を持たせるのが当面の目標で、(ちなみにここでは「意識」というのは集中思考という位置づけ)意味のある「仕事」を行うために合目的行動を立案実行するというハイレイヤーな行動は目標としない。人間でいうと2歳くらいかな?うまく行って賢い犬くらい。自分が興味があるところに行って好きなことをやるって感じ。
・・・・・・・・・・・・
とうとうマリオギャラクシーのCMが始まった。11月1日が待ち遠しいような、来て欲しくないような。ゲームやっててロボットが手薄になるのがちょっとつらい。でもやっぱり楽しみ。
■10月21日■
午前中からベルトソーをガーガー言わせるのをはばかって午後から作業。午前中にモーションのプログラムを整備したりしていたんだけど、動かすまでは行かなかった。
午後から工作開始。マンションのベランダで作業するのだが、騒音が大きいのでちょっと気が引ける。今回は板厚1.2mmと1.0mmで設計したのでざっくりと切り出しだけベルトソーでやってから、細かい部分はハンドニブラーでやってみた。1.5mmだと、手が痛くてもう勘弁してくれって感じになるけど、1.2mmだとさくさくいける。細かいところはベルトソーかヤスリで仕上げ。
でも、ヤスリ仕上げが終わったところで17時半。もう日が暮れて暗くて作業できなくなるギリギリでした。
夕食食べて曲げに入ったんだけど、チェックしたつもりがヤゲンにかからない寸法になってる部品を発見。下の画像がそう。
どうしようかなーとしばし悩んだが、曲げが短いので下に捨て板を当てて一緒に曲げたらうまくいった。よかった。
よかったのもつかの間。調子に乗ってどんどん曲げていったら、間違えた。(>_<) 面付けする時に面を間違えて山折にケガいてしまった部品が3つほどあって、そのひとつの一番切り出しが複雑なのを間違えてしまった。ショック。。 どうせ作り直さなきゃならないのになんとか救済できないかって悩んで悩んで作業が止まってしまった。
それらしくうまくいった部品も多数。これは顔の目の部分の部品。角度曲げがいまいち精度が出なかったけど、角度が出てないだけだから調整可能な範囲。
今回は曲げ寸法が小さくて、ヤゲンにかからない部品がたくさんあって、曲げた後に更に削りを入れなければならないのだが、タイムアウトで今日は終わり。
ネジとかスペーサを発注して寝ましょう。 あぁ〜、明日仕事休んで工作したいなぁ。(~_~;)
ヤゲン跡を残さないように紙を挟もうと思ってたのを忘れてた。まぁいいけど。
・・・・・・・・
のむむさんの買ったマイクロMB。自分も欲しくなって調べたら、今の最安値で32000円くらい。メモリーとDCDC基板を買って、全部で45000円くらい。CPUが1G、メモリーが1G。対してピノーのSizkaProが62000円くらいでCPUが500M、メモリーが512MB。消費電力はピノーが12WでPico-ITXが24W。いいところも悪いところも倍の関係。ちっさいけど普通のPCってところでPico-ITXの勝ちかなー。のむむさんの測定によると重さも思ったほど重くない。
調べるとピノーはSizkaMiniってのを用意していたみたいなんだけど発売される様子はまだない。CPUボードだけは売り出してるけど個人じゃ買えなさそうだしな。大きさは更に小さくなってるみたいで魅力なんだけど、ピノーはドライバーも専用みたいだからRPU-100の呪縛ほどじゃないけど縛りが残るってのもちょっとマイナス。
買うか?買っちゃうか?ピコの方。
■10月22日■
仕事から帰って曲げ加工の続き。
折れちゃった。ちょっと曲げすぎたので戻そうとしたら折れた。小さい部品は力が逃げないので曲げ部分に力が集中してしまうんだな。気をつけねば。
失敗した部品2点と、あとはすぐには曲げられない部品ばかり。今回はアタマ部分で体積が限られているからちょっとムリめの設計をたくさんやってる。どうやって曲げるか、これから考えねば。
下のひとつは手段を考えていたんだけど、上の3つは「何とか曲がるかな?」って感じだったのだがどうも無理そう。治具が要る。治具は週末にならなきゃ作れないから工作は週末までお預け。
■10月23日■
今日は仕事後に出かけていたので作業進捗は無し。
もんもんと思考するロール軸消失姿勢問題に対して方針を決めなければならない。
一度は「J1=0度、J2=-90度となるロール軸消失姿勢は使用しない。」という方針で固まりかけた。この場合、がに股になってロール軸消失姿勢を超えるのだが、実際にロボットで色々と試してみると取りえる姿勢の制限が大きい。肝心の床のものを拾う動作が難しい。
がに股を基本動作にしようと考えた決定要素は重心補正。ロール軸消失姿勢を通過するケースで重心補正をかけると少しだけ姿勢がずれることになる。だが、ロール軸消失姿勢近辺での不安定度合いは大きく、ちょっとずれると角度が大きく変わり、サーボがついて来れない。反してがに股姿勢はある程度融通の利く範囲をもっているため、重心補正は可能と思われる。
折中案としていま有力なのは股関節を畳み込む姿勢ではJ1関節角度は0度で決めうち。内股姿勢のまま膝は開かない。こうすればJ1J2の動作は緩やかになり安定した動作が出来る見込みが大きい。重心補正については左右の補正は行わず、前後の補正のみを行うようにすればいいかなと考えている。
がに股ベースでの動作もシームレスという点では捨て難く、悩ましい。この場合、股関節を大きく曲げ込む時は膝を外から回し込んでJ1関節をぐるりと回しながら畳み込む。
←この股関節の折りたたみ方の方が取れる姿勢範囲が広い。シームレスな動作は足幅が股関節幅と同じときだけ。
←この足の上げ方はシームレスな動作が売り。上と見比べるとJ2関節サーボが裏返っていることに注目。
なんかまとまりがないのだが、できるだけ良いところを切り捨てずに済むように考えたい。
あまりすっきりした結論ではないが、今の「角度ベースでの動作に切り替える」ってのよりは良いかと。。。 問題は実装だなぁ。できるのかなぁ。。
帰ったら広杉計器からスペーサ各種が届いていた。あと精密コネジが届いたら購入部品は揃う。
出かけ先で時間があったらハンズに立ち寄って加工治具の材料を買いたかったのだが、時間が取れず。金曜日にチャンコ屋(チャンコ屋で宴会の予定)に行く前に渋谷に買いに行くかなぁ。
■10月24日■
ロール消失姿勢問題。 対策方針がほぼ決まったので実装の検討。
既に構築したIK変換の式を眺めてどうやって関節角度を決めていこうかと考えていた。いままではJ4,J6→J5→J1,J2,J3という順番に決定していた。
今回はJ1=0で決めうち。J4は決まるから問題ないけど、その他の角度の決定順序はどうするのか?式を見る限り同じ順番とはいかないらしい。落書きしながら考えて、なんとなく見えてきた。
足首の座標は決まっている(条件だから)から膝の座標は足首座標を中心とした球面上(半球上)に限定される。J1が0だから膝はY-Z平面上にある。つまり、膝の座標は球面をY-Z平面でスライスした円(半円)上にある。
股関節から言うと膝は股関節座標を中心としたY-Z平面上の円上にある。 つまりこの二つの円の交点が膝の座標ということ。これでJ2が決まる。膝の座標が決まればJ3,J5,J6が決まる。
これでJ1=0の時の任意姿勢が算出できる。ただし、p=t=0,rは問わず。pやtに0以外を設定する場合はJ5J6が変わるので注意。まぁ、それは角度列から逆変換した方がいいかも知れない。 求めたい姿勢(胴体姿勢と足首座標)を座標回転してt=p=0の時の足首座標に変換してから先の方法で各関節角度を算出する。
J1が0なので足首座標の可能範囲も限られている。当然範囲は狭まるから対処不能の場合もありえる。
J1J2で決定する膝の位置は股関節を中心とした球面を描く。その面積の1/3はJ1J2の組み合わせで二通りの解がある。問題はその冗長エリアから任意の位置に移行する場合はJ1の(J3も関係するが)関節角度の可動範囲の制限があって、自由には行き来できない。そしてロール軸消失点では冗長度が無限大でJ2は任意となる。そして任意のJ2から他の点に移行する場合はある2方向以外は不連続となる。
これに対する処理はちょっとインテリジェントにしなければならないかなーと思っている。ロール軸消失点だけはJ1=0,J2=-90で決めうち。突入方向も固定とするしかないかと思っているが、関節角度の可動範囲の方は動作の連続性制御(前回の変換角度を参考にどちらの組み合わせを採用するかを決定する)だけでは不足。回り道したり、姿勢を整えてから別方向へ突入するといった手順が必要になる予定。
ここは今回は見送りで、連続性制御とロール軸消失点の処理だけでとどめておこうと考えている。
さて、週末が近づいてきたのでそろそろ検討モードから工作モードへ移行かな。 ロール軸消失問題の対策がだんだんと見えてきてちょっと晴れやかな気分です。
■10月25日■
予定変わって今日、ハンズに買出しに行って来た。(明日のチャンコは取りやめ。(T_T) )
どうやって曲げようかってやつのひとつは加工成功。 寸法ばっちりってわけじゃないから組み立ての時に微調整は必要だけどね。よかった。(*^_^*)
残りの部品はこれを使って加工。 切り出しの時にベルトソーが折れるかも知れないと思ったので既に切り出してあるのを買ってきた。刃の方がはるかに高価だし。本当は3通りの辺の長さを持つ直方体が良かったのだがなかったので立方体でガマン。
M1.4×5の皿ネジ。 100本で1000円もした。高い!ちなみにナットは20個で500円。もっと高い。
今日はJ1=0限定IK関数を完成させようと思っていたのだが、帰るのが遅くなってしまったのでもうムリ。明日になっちゃったし。コンパクトな関数を作るべきなのだが、検討とか検証が大変なのでいままで作った関数を駆使して作る予定。またはまらなければ良いのだがぁ〜。(^_^;)
ちょっと前から「ONOの電脳壁新聞」に載せてもらったりしてます。うれしい。早く「問題」じゃなく「成果」で取り上げられるようになりたいものです。
■10月26日■
昨日の日誌でM1.4のネジをハンズで買ってきたみたいになってるけど、ネジは通販で買ったものです。念のため。
今日は打ち上げが中止になって、予定より早く帰ってきたのに板金部品にタップを立てて一部仮組みしただけで終わってしまった。おかしいなぁ。
アタマ部分の一部を仮組みしてカメラも取り付けてみた。 ・・・暗くてよくわからんな。
明日は先週の続きで工作をする予定なのだが、どうやら台風の影響による雨らしい。雨で工作が出来そうになければ秋葉原に買い物に行った方がいいだろうか。
カメラじゃない方の目の目処がついてない。いい感じのLEDライトとかレンズとか探しに行かねば。
・・・・・・
J1=0でのIK変換関数を作るのに、「同一平面上の任意の二つの円の交点」を調べなければならない。2次元だし簡単、と思って解こうとしたが解けない。ネットで調べてみると片方の円の中心を座標原点に移動して、二つの円の位置関係を水平に並べるように座標回転してから交点を算出。その後、座標を元に戻す。というめんどくさくも判りやすい方法が紹介されていた。これって正しい解き方なんだろうか?
■10月27日■
予定では今日にも工作が終わる予定だったが、台風の影響の雨風がひどく、外作業はムリ。切り出しとか穴あけはできなかったので作業は明日に繰り越し。
それでもタップ立てとかその他の作業でほぼ一日かかってしまった。今日中に作業完了はどちらにしても無理だったかもしれない。実は工作が完了してもサーボの電源供給用の基板を作ってないのでサーボを動かすことはできない。明日、動かすところまで行けるかな。
仮組みで本体に取り付けてみた。 片目だと感じでないなぁ。
外装はバキュームフォームで作ってみようと思って材料を買ってきた。MARU Familyホームページの教えによりすべて100円ショップで買ってきた。ホントに買い揃えられた、驚いたな。 胴体の部品を作ることを考えるとちょっと小さかったかもしれない。 ま、いいか。だめならまた100円ショップで買ってくれば。
でも、外装に着手するのはもうちょっと先になりそう。先にマニピュレータをやりたいんだよね。
・・・・・・・・
今は工作脳になってしまっていて、プログラムに取り掛かるのにものすごい抵抗感がある。でも、せっかく(?)雨だから工作じゃなくてロール軸消失対策、J1関節0度のIK変換をコーディングしてしまおう!と思って重い腰を上げてプログラムしてみた。
全然ダメでした〜。 まだバグなのか検討ミスなのかわからんけど、J1を0にしようと変換すると、元の姿勢を関節角度に変換したときより0度から遠のいてしまう。。。 と、書いていて間違いに気付いた。バグじゃないからもう一度検討しなおしだ。OTZ
あ、二つの円の交点の算出は余弦定理を使えば簡単に算出できた。余弦定理はJ4関節角度の算出でも使っている。便利。
■10月28日■
アタマ、一通り作ったのだが「完成」とはならず。
作り方が難しい幾つかの部品はことごとく成功していい気分だったのだが、トルクリミッターがうまくいかず、設計変更しなければならない。そういうわけでサーボは取り付けたけど相変らずクタクタジャガーです。 あと、ものすごく恥ずかしいチョンボをしちゃったんだけど恥ずかしいので書けない。すごいショック。対策はすぐに出来たけど1部品追加になってしまった。
トルクリミッターは結局RS302に添付してたダボ付きホーンに勘合するリンク部品を作ることになりそう。過大負荷がかかったときは、リンクがアルミだからホーン側が壊れるはず。このダボ付きホーンだけで購入できるんだっけ?通販メニューには見当たらなかったような。。。
サーボ付けると結構な重さ。これで全体重心がちょっとあがる。上がった方が安定歩行し易いらしいからいいかも。
カメラを取り付けるスペーサが、手持ち部品の勘違いで欠品。早急に発注せねば。その他、設計変更に伴ってネジやらスペーサやらが必要になった。発注せねば。
いままでは曲げられなかった形状を曲げれるようにした治具。多分純アルミだから5052より柔らかいけど、小さい部品だったら全然問題ない。ただ、溝が浅くて90度まで曲げるのにコツがいる。
・・・・・・・
昨日、ダメだったJ1=0度のIK変換は簡単な思い違いでした。「股関節・膝関節・足首関節の3点を通る平面と、足首座標を通るX-Y平面の交線を求めて、その直線の傾き」を求めなければならないところを「膝関節と足首関節を結ぶ直線を足首座標を通るX-Y平面に投影した直線の傾き」を求めてた。
すぐにでも直して検証したいところだが、もうその気力は、、、ない。やっぱ今は工作が第一優先だし。。
■10月29日■
キタキタキタ〜(^・^) J1=0でのIK変換がでキタ〜。
下の画像の右足に注目。この状態でJ1=0変換をすると、
DISCONNECT SKT > jz
x:82.280 y:37.888 z:112.167 r:-12.433 t:79.238 p:-1.528 ft:88.348 fp:43.466 ←姿勢を反映した足座標
a1:-0.564 a2:-2.443 a3:-0.873 a4:1.646 a5:0.387 a6:-0.187 ←その時の関節角度
J1=0での姿勢に変換
tt:-8.254101 ap:32.515229 ←J1=0の時の膝関節座標計算の中間情報
足首 : x:85.242 y:115.075 z:-16.693 ←胴体を垂直と考えた時の足首座標
膝 : x:0.000 y:96.638 z:43.555 ←胴体を垂直と考えた時の、J1=0とした時の膝座標
法線ベクトル : x:6625.299 y:-3712.720 z:8237.661
交線の傾き(Y軸を0として) : -29.265630
<res>
x:85.242 y:115.075 z:-16.693 r:-29.266 t:0.000 p:0.000 ft:0.000 fp:0.000 ←胴体を垂直と考えた時のJ1=0の足姿勢
0.000000 -1.994233 -0.938109 1.645845 0.576216 -0.825989 ←その時の関節角度(J1=0になってる)
x:82.280 y:37.888 z:112.167 r:-52.758 t:79.238 p:-1.528 ft:0.000 fp:0.000 ←胴体姿勢を現状値にした時のJ1=0足姿勢
0.000000 -1.994233 -0.938109 1.645845 1.658374 0.173278 ←その時の関節角度(J1=0になってる)
ちなみに角度列はJ1 J2 J3・・・J6と並んでいる。単位はラジアン。下から3行目と一番下の行でJ5とJ6の角度が違っているのは胴体姿勢だけが違って足は水平面に平行な姿勢にしているため、同じではない。当面はこれでいいかなと、斜面でのこの動作をさせたりすると足の傾斜角も考慮しなければならない。めんどくさいなぁ。
まだエラー処理とかやってないのでこれも完成とは言えないのですが。。。 山は越えたかなぁと。できると簡単なんだけどねぇ。ふぅ。
J2が不連続となる動きを行う場合はこの変換をかけて、J1を0度に決めうちして動作させる。あとは、規定の姿勢からこの姿勢への移行点を決めてそこまでスムーズに持っていくような動きを生成させればよい。(って簡単に書くけど、どうやるのかまだ考えてないのだが)
・・・・・・・・・
今日は帰ったらすぐにでもアタマ部品の追加分と改造分の製作をして、とりあえずリミッターじゃなくて固定でいいから首が座るようにして、電源回路をつくって、、という気分だったのだが、どう考えても発注した部品が届くまでは大きな進捗がないことは明らか。ここはひとつロール軸消失問題の解決を優先するとこだなと考えて、わき目も振らずプログラムに取り掛かった。関数できたからこれから電源回路でも作ろうかな〜♪
■10月30日■
帰ったら注文していたスペーサ類が届いてた。予想より1日早い。せっかく届いたのに、まだ追加部品や改造部品を作っていない。
今日はバキュームフォームをやってみる。外装はまだだけど、ひとつ作りたい部品があるのでまずはそれでやってみる。
これが用意した木型
100円ショップで買ってきた部品でつくったバキュームセット。電熱器はアマゾンで2000円。
バシューっと吸ってみたところ。 板厚0.5oのプラ板を使ったが、吸引すると破れてしまった。でも、一応成功。
設計では引いた後の部品の厚みは0.3mmで考えていた。材料板厚0.5oから作ると大体0.3mmになってちょうどよかったんだけど、0.3mmじゃ薄いね。ちょっと弱いかなー。
1mmから引いて部品の厚みは0.7mmくらいで設計してもよかったかもしれない。ちなみに材料の厚さと引いた後の厚みは勘デス。
初めてバキュームしてみたけど、なかなか面白い。プラ板を温めるのが緊張するんだけど、0.5mm材での感じだと、1o材とかで温めるのはもっと時間がかかって緊張しそうだな。うっかり温め過ぎるととろけそうだし。
今回、木型が一個だったのでこのプラ板から1個しか部品を取らなかったんだけど、プラ板がもったいないね。計画的にバキュームしないといかんですね。
なんとか!なんとか、今日中にアタマの工作を終わらせようと仕事から帰ってからがんばってみたが、ドリルの音が気になって途中で中止。あと4つの小さな部品の製作を残して今日の工作は終了。なんとか部品の改造(穴追加とか調整とか)だけは終わらせることができた。明日は帰るのが遅くなりそうだし、金曜日は飲み会(それも出張先で)なのでやはり作業は土曜日に持ち越しの様相。
なんだかんだで工作開始から3週間もかかってる。かかりすぎって感じだなぁ。それも機械工作だけの話で配線関連はまだ手付かず。動作プログラムの進捗に戻れるのはいつのことになるのか。。
でも、、、これでこけた途端に壊れたりしたらショックだなぁー。一応前よりは頑丈に作っているつもりなのだが、実力はわからないし、仕掛けが多い分重いし、心配は尽きません。
明日から11月。このページも随分と長くなってしまったので明日からは新ページに切り替えよう。