ダークグリーンと赤の組み合わせが右手、ダークグリーンと青の組み合わせが左手■５月１８日■
引き続きラベリングしたデータでのトラッキングに取り組んでいたのだが、なかなかうまくいかない。 まず一つはラベリングの精度。 時々物体を見落としてしまう。それで注視物体が切り替わってしまうのだ。 他にも、注視対象物体が１つしかない状態から、急に２つになった場合、前回フレームでのデータが役に立たなくなるという不具合に気付いた。
色々試してみたが、これだという対策がないままだが、この状態でこの土日が過ぎ去ってしまうのは本意ではないので、この問題は積み残しで先に進むことにする。 良く考えたらロボビリヤードではラベリングしたデータをそのまま参照するってことはないので。。 (^^ゞ
次に手先をカメラ画像を参照しながら動かすってのをすすめることに。
まずは手先を認識できるようにマーキング。
ダークグリーンと赤の組み合わせが右手、ダークグリーンと青の組み合わせが左手
そしてこの手をラムダが見ると、
露出がおかしいなぁ～。
次にこれをCDT＋ラベリングで切り出し
ダークグリーンのゴミが予想外に多かった。 ベースカラー変えたほうがいいかもしれない。
さらにこれから手先を特定すると
ま、こんな感じです。 光の加減で色の判別が変わってくるので、午前、午後、夜 とCDT用のテーブルを再調整し続けてます。 実はこれがイヤなんだけど、データ量考えると通常のカラー画像は使えないです。
手先座標はわかるので、カメラと手先の距離は判る。この距離を使って、手先をスクリーン平面内の任意の位置に動かすのだが、カメラ姿勢値から逆算して、現状の腕座標からどっちの方向にどれだけ動かせばいいかを計算するのだ。 誤差がどんなふうに効いてくるかが問題。 思い通りの方向に動いてくれるかなー。 「ボールをはじく」くらいならなんとかなるかもしれないけど、「ボールをつかむ」とかになったらきっと難しいだろうね。
■５月１９日■
今日は朝から京都へ出張。 結構早く帰ってきたのだが、飲んだせいでモチベーションが上がらない。 新幹線で寝たから酔いは程よく醒めてるんだけど、もともと酒には強くないので影響大なのだ。
、、というわけで、意味のある作業はできなかった。
ここのところ画像と動作を連携させているわけなのだが、RPU-100で進めていくことが難しいのかなぁと考え出している。 CPUの能力的に完全にオーバーしているのかというとまだそういうわけではないのだろうけど、サーボへのコマンドが時間通りに送られないことがあるというのは相当致命的なことで、大きな問題だなと思っている。
画像処理が今やっていることだけで終わりということもなく、今後どんどんと複雑化していくし、音声合成はまだしも音声認識も相当な負荷なのだ。CPU的には運動制御が一番楽チンっぽいのだが、動作にバッファがないため、時刻どおりに命令を実行する必要があり、それがUNIXには一番苦手なのだ。
プロセスのことを色々と考えながらプログラムするのもちょっとめんどくさいし、ハード的にマルチプロセッサにした方がいいのかもしれないなぁと思ってきている。
でかいCPUを2つ搭載するとなると、ロボットの大型化が必須なのだけど、ちょっとそれはリスクが大きい。 ロボットを作り直すのはまだ早い。 でも、動きをモーション化してでかいCPUから小さいCPUにモーション起動をかけるってのはボツ。今やっているカメラ画像で手を動かすなんてことができないわけなのでダメです。
悶々と考えた結果、 対策の一つとして、小さなCPUボードをサーボコマンドへのバッファとしてつなぐ案がいいかな。 計算すれば、20サーボへの0.5秒分のコマンドで1キロバイトほど。これを460800bpsで送ると20msちょいで送れる。20msといっても伝送路での時間のことでCPUの占有時間はそんなに無いはず。バッファがあるはずだから。。たぶん。。 で、ちっこいCPU側でバッファを持って時間通りに送るって感じならできそうかなと。 これならCPU側で動作指示もできるし、1歩分のデータを送れば1歩ごとで動作のフィードバックもできる。 カメラ姿勢制御のサーボだけはカメラと同じCPUから制御しないとトラッキングできない。 ジャイロをちっこいCPU側につめばジャイロフィードバックもできるのだけど、サーボ単位でしかできないのが問題かな。。。 サーボの結果をIKレベルでは反映できないのはつらいかな。。 あっと、合議制の動作ってのはできないのか。。 ううむ。。ダメかも。。
もうちょっと考えます。。 (>_<)
■５月２１日■
画像処理を検討する上で阻害になっているのがモニター画像。
自律ロボットだから人間が画像をモニターする必要はないのだけど、開発段階ではモニターがなけりゃ何がどうなってるかさっぱりわからない。 それでカメラ画像を無線LAN越しにPCでモニターするようにしているのだけど、これが相当な負担。
小さい画像なんだけど、YUV画像を圧縮せずに送っているので、64800byte（180*120ドット、変則YUVフォーマットなので注意） CDT画像だと1ピクセル1byteだから21600byte CDT画像はまだしもYUV画像を11bで送ると結構な時間がかかってしまう。画像処理などをやってる時間も徐々に大きくなりつつあるのだけど、モニターで時間とられてちゃあ仕方が無い。
で、画像はモニターしたいが時間を食いたくない、、ってことで、モニター用のモノラル画像を送れるようにしました。 更に小さい90*60ドット・モノラル 1フレーム5400byte。 これならモニターデータの送信時間は随分と小さくなる。
YUV画像 
CDT画像 
モノクロ画像
画像処理プログラムの作りも、つぎはぎ状態だったから構造体を作って整理したり、重複している処理を削除したりで整頓したりしてた。
・・・ つまり、「画像データによる手先座標のコントロール」ってのを進めたくないんですねー。 なーんかハマりそうな予感。 ウィークデーの中途半端な時間に進めていいものかどうか。。 うぅ、、そんなこと言ってちゃいかんですね。 明日、早く帰れたら進めましょう。、、きっと。。
あっと、、小さいモノクロ画像だと、フレームレートは相当高くなる。ただし、今日のところはラベリング処理などをやらせてないので実用上の具合はわかってません。フレームレートも測定してないので体感だけでの話ですけどね。
悶々と考えてるRPU-100の続きは、やっぱり小型のCPUでバッファを形成する方向で考えようと思います。 メインCPUからサブCPUへのコマンド送信周期は50msから100msくらい。できればサーボへのコマンド周期は10msくらいにしたい（今は25ms） バッファを何フレーム作ればよいか、2本のUARTの非同期動作ってどんな感じか、不明点が多いのだけど、そんな感じでいいんじゃないかなーと思います。 RPU-11を改造すれば実験できるはずだけど、ATmega128のマイコンボード買おうかな。
■５月２３日■
今日こそはってことで、張り切って帰ってきて「画像データによる手先座標のコントロール」を進めました。
これが初期状態。CDT画像の下の方に両手先が写ってます。
右手を画面の中央に動かせ！ とコマンドを送ったところ、、、
関節角度から計算した手先座標とカメラ座標の差でカメラと手先の距離を算出し、スクリーン上の手先の位置から現在の手先位置を画面中央に移動させる量を計算します。 そして、カメラ姿勢から腕の座標系での移動方向と移動量を計算して、動かしたところです。
意外と精度が出たのでちょっと安心。これを何回かループを回せば中央に収束するはず。
まだ、マニュアルでの操作なので操作が結構めんどくさい。なので、ちゃんと計算できているかの検証ができてません。 明日はマウスで手先の移動先を指示したりカメラ姿勢をもっと大胆に変えた場合でもちゃんと動くことを確認しましょう。
■５月２５日■
マウスで指示した画面位置に手先を動かすようにしてみました。
片手でカメラ持ちながらの操作なので見苦しい画像です。 あと、PC画面を撮影するとモアレがひどくていかんですね。スクリーンをキャプチャーして動画にするツールがあったような。。
実際には腰をかがめたり横を向いたりいろんな姿勢を取りますが、首関節の角度からスクリーンが空間上のどの方位をどういう角度で映しているのかがわかっているので座標変換しています。
今のところでは画面に手が映っていないと位置を把握できないのでコントロールできません。 動画上でラムダの手先が招き猫みたいな動きをしてしまうのは肩関節の動作範囲を超えてしまっているときに肘だけが動いているためにクイクイッって感じで動いてしまっています。動作範囲を超える場合は腰を回転させるなどをしてリーチを伸ばすべきなんですが、まだそこまでは実装できないなー。 以前に実装した合議制のリーチングもしゃがみ込みオンリーしか実装してないのでまだ使えない。
昨日は更に、ラムダを立たせて腰をかがめさせて床にあるボールを弾く動作をやらせていたんだけど、、むずかしい、、。 もうちょっと手を長くしなきゃならなさそう。 それよりも上半身の姿勢の管理がなんだかむちゃくちゃで、昨日はそっちの方のデバッグで相当時間をとられました。 ま、詳細仕様が決まらないままに進めてるのだから仕方ないところもあるのだが、、、ちょっと進めるたびに段々アラがとれていけばそれでいいのかなー。
「さらば愛しきルパン」に出てくるロボット「ラムダ」。 足はまぁムリとしてもあのムカデのような腕を作りたいんだけどなぁ。。アクチュエータいくつあっても足りないし。。。
製作者の腰痛さんのサイトで製作記を見ました。 ・・・しかし、まぁ、モデラーの懲り方ってのはすごいです。しばし見入ってしまった。。
■５月２６日■
腕の動作範囲を超えた場合の処理を追加して、上半身制御部分のコードを改造。 招き猫はしなくなったんだけど、立ち上がりモーションが出来なくなってしまった！？
悩んで悩んで、、結局、リーチングの合議制コードにバグが潜んでいるのを約24時間後に発見しました。 初期調査で思い込みによる見誤りがあり、２～３時間近くは無為に過ごしてしまった(>_<)
やはり上半身制御には魔物が棲んでいる。っていうか、行き当たりばったりのコーディングが魔を呼んでいるのだが。。
腕の動作範囲を超える指示があるとそこで動作が止まっちゃうようにはしたのだけど、どうにも腕の動作範囲が狭い。 腕も短くて、腰をかがめて床にあるものを触れようとすると頭が近づきすぎて影を作ってしまってうまくない。 腕伸ばしちゃうかぁ～。 あと、肩関節の直交軸をやめようかな。 ちょっとしたオフセットなら計算もそれほど複雑ではないし。
なで肩になるけど、そんなにおかしくはない・・よね。 オフセット付けよう！と決意したのが昨日の１６：３０だったので、工作着手は諦めました。来週の週末になっちゃうなぁ。
・・・ならば、手先部分もついでに作るか？ 部品点数多くなるならアルミ切抜きサービスに頼んじゃうか？ どんどん時間がかかる方にシフトしていく (^。^)
■５月３１日■
木曜日～金曜日は九州へ出張。 そして土曜日の昼過ぎに帰ってきました。 外回りの仕事じゃない割りにしょっちゅう出張には行ってるのだけど、泊まりの出張は久しぶり。それも２泊。 金曜日の夜は盛大に飲み歩いて今日は例によって二日酔い。(^^ゞ 二日酔いで飛行機に乗るのは恐ろしかったんだけど、席に着いた途端に爆睡してたので大丈夫でした。 二日酔いでの飛行機は以前に中国出張に行った時、連れが着陸の揺れで我慢できずにリバース。機内は阿鼻叫喚の渦に、、、とはならなかったんだけど随分な思い出がありました。
うちに帰る頃には復活していたんだけど、頭脳労働しようとすると眠気に襲われるので工作してました。
肩関節のブラケットの改造。
なで肩ラムダ
なで肩になった。
肩関節の可動範囲は広がりました。
以前の腕だと肩関節は「前に倣え」までしか曲がらなかったので随分と腕を使いやすくなったはず。
可動範囲が広がったのはいいんだけど、関節が直交軸じゃなくなったので逆運動学計算がややこしくなりました。 今までは直交軸だったので逆運動学計算は解析的に解く事ができました。 今度の関節構造でも肘のひねり角がなければ解析的に解けるのだけど、ひねりを加えると解けません。 ヤコビ行列を使って解かないといかん。 とりあえず、画面データでの腕のコントロールをやる範囲ではひねり角は使ってないので解析解を使えるから、、いいか。
腕の外装もちょっと改良すれば更に可動範囲が広がりそう。 でも、これくらいでいいかなー。
明日はスープカレーの会に参加してくるので日中の作業はできないね。
■６月１日■
スープカレーの会に参加してきました。 ・・・・でも、、集合場所間違いまして皆さんに迷惑かけちゃいまして、スイマセンでした～。 石川さん、待っててもらって申し訳なかったですー。 実は、随分前にアイボのプログラムをやってるころ、Open-Rカンファレンスで知り合った、とある方面では滅法有名な今はとある会社の代表取締役になっている方のブログで「吉祥寺のスープカレー」ってのが出てきまして、何を勘違いしたのか、散財さんお勧めのマジックスパイスがその店だと勝手に脳内で決め付けてたみたいで、何の疑いも無く、吉祥寺に降り立ってしまったんです。(>_<) スープカレーおいしかったです。「涅槃」を頼んだんだけど、辛さ先行じゃなくて味わいがあってどんどん食べちゃいました。最後の方は冷めてきたりしてちょっと辛さが足りないか？とか思っちゃいましたが、あれくらいがおいしく食べられる限界かなーと。
チキンの涅槃のミートボールと味玉トッピング。 涅槃の辛さがわからなかったので、トッピングは非難用にマイルドなのを選びました。
スープカレーの会が終わって、各自散り散りになったんですが、草加のネジ祭、行こうかどうしようか迷ったけどパス。 新宿をぷらっとして帰ってきました。
なで肩になったラムダの、腕のIK計算とDK計算の整備です。IK計算については４関節フル対応ってのはちょっと大変なので３関節対応の関数を作ってとりあえずはこれでOK。DK計算は姿勢算出は変更ないので座標算出だけは、肩関節のオフセットを考慮した計算にして完了。
モーションへの影響などを確認してないなぁ。 しなきゃ。
なで肩になって、更にガチャピンに似てきたような。。 ガチャピンってチョーなで肩だったよね？
パンツ無い方がなんかいい感じがするな。。 パンツやめて腹巻にしようかな。
■６月７日■
一週間ぶりの日誌更新です。
今週は出張やら飲み会やら仕事やらで随分忙しくて、飲んで帰らなくても帰るのが遅かったりでロボット関連の作業はさっぱりできませんでした。
まぁ、そうじゃなくても肩にオフセットをつけて逆運動計算が解析的には解けないとわかった（解けないと判断した、ってのが正解ですが）のでヤコビ行列を算出しなきゃならないとかちょっと足踏み状態であるのもたしか。
足踏みしてても仕方ないのでヤコビ行列の算出をやってみる。
ラムダの腕は4自由度なので、Ｘ，Ｙ，Ｚ，θ（θは手先のひねり）の4パラメータをJ1～J4の関節で表現することになる。
まず、この4パラメータをJ1～J4で表すと、
x = -cos(J2)cos(J3)sin(J4)al2 - sin(J2)cos(J4)al2 - sin(J2)al1
y = -cos(J1)sin(J3)sin(J4)al2 - sin(J1)sin(J2)cos(J3)sin(J4)al2 + sin(J1)cos(J2)cos(J4)al2 + sin(J1)cos(J2)al1 + sin(J1)ao1
z = -sin(J1)sin(J3)sin(J4)al2 + cos(J1)sin(J2)cos(J3)sin(J4)al2 - cos(J1)cos(J2)cos(J4)al2 - cos(J1)cos(J2)al1 - cos(J1)ao1
θ = atan(sin(J3)cos(J2) / (cos(asin(sin(J4)al1 / l) - J4)cos(J3)cos(J2)
+sin(asin(sin(J4)al1 / l) - J4)sin(J2)))
これを微分すると、
x' = -(-J2'sin(J2)cos(J3)sin(J4) - J3'cos(J2)sin(J3)sin(J4) + J4'cos(J2)cos(J3)cos(J4))al2 - (J2'cos(J2)cos(J4) - J4'sin(J2)sin(J4))al2 - J2'cos(J2)al1
y' = -(-J1'sin(J1)sin(J3)sin(J4) + J3'cos(J1)cos(J3)sin(J4) + J4'cos(J1)sin(J3)cos(J4))al2
-(J1'cos(J1)sin(J2)cos(J3)sin(J4) + J2'sin(J1)cos(J2)cos(J3)sin(J4) -
J3'sin(J1)sin(J2)sin(J3)sin(J4) + J4'sin(J1)sin(J2)cos(J3)cos(J4))al2
+(J1'cos(J1)cos(J2)cos(J4) - J2'sin(J1)sin(J2)cos(J4) - J4'sin(J1)cos(J2)sin(J4))al2
+(J1'cos(J1)cos(J2) - J2'sin(J1)sin(J2))al1 + J1'cos(J1)ao1
z' = -(J1'cos(J1)sin(J3)sin(J4) + J3'sin(J1)cos(J3)sin(J4) + J4'sin(J1)sin(J3)cos(J4))al2
+(-J1'sin(J1)sin(J2)cos(J3)sin(J4) + J2'cos(J1)cos(J2)cos(J3)sin(J4) -
J3'cos(J1)sin(J2)sin(J3)sin(J4) + J4'cos(J1)sin(J2)cos(J3)cos(J4))al2
-(-J1'sin(J1)cos(J2)cos(J4) - J2'cos(J1)sin(J2)cos(J4) - J4'cos(J1)cos(J2)sin(J4))al2
-(-J1'sin(J1)cos(J2) - J2'cos(J1)sin(J2))al1-(-J1'sin(J1))ao1
θ'=
えぇぇと、、atan( )とかasin( )って微分するとどうなるんだっけ？？θの式中にl(エル)ってのがあるが、これはsqrt(x^2+y^2+z^2)であるわけだから、、、 なんかとんでもない項数の式になりそうだな。
このθの式は、肩関節と手先を結ぶ線を軸とした時のひねり角度を表している。 肩姿勢を基準としたひねりってのは直感的ではないなぁということでこの表現を使っていたのだが微分する式じゃないなぁ。
どうしよう。。
■６月８日■
今日のヤコビさん
θの算出式が微分しにくかったので、見直しましてこんな風になりました。
θ = atan( cos(J2)sin(J3) / (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4)) )
昨日の式は手先を原点としたものだったのだが、今日のは肩関節を原点としたもの。等価かどうかわかりません。どっちかが間違えているかも。(^^ゞ
これを微分すると、
θ'= ( (-J2'sin(J2)sin(J3)cos(J2)cos(J3)cos(J4) + J3'cos(J2)cos(J3)cos(J2)cos(J3)cos(J4) + J2'sin(J2)sin(J3)sin(J2)sin(J4) - J3'cos(J2)cos(J3)sin(J2)sin(J4)) - (-J2'sin(J2)cos(J3)cos(J4)cos(J2)sin(J3) - J3'cos(J2)sin(J3)cos(J4)cos(J2)sin(J3) - J4'cos(J2)cos(J3)sin(J4)cos(J2)sin(J3) - (J2'cos(J2)sin(J4)cos(J2)sin(J3) + J4'sin(J2)cos(J4)cos(J2)sin(J3)))) / ( (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4))^2 + (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4))^4 )
で、これらをJ1'からJ4'の項でまとめるので整理すると、
x' = J1'(0)
+ J2'(sin(J2)cos(J3)sin(J4)al2- cos(J2)cos(J4)al2 - cos(J2)al1)
+ J3'(cos(J2)sin(J3)sin(J4)al2)
+ J4'(-cos(J2)cos(J3)cos(J4)al2 + sin(J2)sin(J4)al2)
y' = J1'(sin(J1)sin(J3)sin(J4)al2 - cos(J1)sin(J2)cos(J3)sin(J4)al2 + cos(J1)cos(J2)cos(J4)al2)
+ cos(J1)cos(J2)al1 + cos(J1)ao1)
+ J2'(-sin(J1)cos(J2)cos(J3)sin(J4)al2- sin(J1)sin(J2)cos(J4)al2 - sin(J1)sin(J2)al1)
+ J3'(-cos(J1)cos(J3)sin(J4)al2+ sin(J1)sin(J2)sin(J3)sin(J4)al2)
+ J4'(-cos(J1)sin(J3)cos(J4)al2- sin(J1)sin(J2)cos(J3)cos(J4)al2 - sin(J1)cos(J2)sin(J4)al2)
z' = J1'(-cos(J1)sin(J3)sin(J4)al2 - sin(J1)sin(J2)cos(J3)sin(J4)al2 +
sin(J1)cos(J2)cos(J4)al2 + sin(J1)cos(J2)al1 + sin(J1)ao1)
+ J2'(cos(J1)cos(J2)cos(J3)sin(J4)al2 + cos(J1)sin(J2)cos(J4)al2 + cos(J1)sin(J2)al1)
+ J3'(-sin(J1)cos(J3)sin(J4)al2 - cos(J1)sin(J2)sin(J3)sin(J4)al2)
+ J4'(-sin(J1)sin(J3)cos(J4)al2 + cos(J1)sin(J2)cos(J3)cos(J4)al2 + cos(J1)cos(J2)sin(J4)al2)
θ' = J1'(0)
+ J2'(-sin(J2)sin(J3)cos(J2)cos(J3)cos(J4) + sin(J2)sin(J3)sin(J2)sin(J4) + sin(J2)cos(J3)cos(J4)cos(J2)sin(J3) + cos(J2)sin(J4)cos(J2)sin(J3)) / ( (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4))^2 + (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4))^4 )
+ J3'(cos(J2)cos(J3)cos(J2)cos(J3)cos(J4) - cos(J2)cos(J3)sin(J2)sin(J4)
+ cos(J2)sin(J3)cos(J4)cos(J2)sin(J3)) / ( (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4))^2
+ (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4))^4 )
+ J4'(cos(J2)cos(J3)sin(J4)cos(J2)sin(J3) + sin(J2)cos(J4)cos(J2)sin(J3))
/ ( (cos(J2)cos(J3)cos(J4) - sin(J2)sin(J4))^2 + (cos(J2)cos(J3)cos(J4)
- sin(J2)sin(J4))^4 )
合ってるかどうか知らないけど、一応これでヤコビ行列は算出できました。
今日のヤコビさんはこれくらいにして、肩ブラケットにオフセットをつけたことで立ち上がりモーションの見直しが必要かの確認をしました。
オフセットうんぬんじゃなくて、画像データで手先のコントロールをやるときに関節の可動範囲の確認やらなんやらを追加したのが影響してモーションがうまく動作しません。(>_<)
で、色々と調整したところ、足の順運動学計算がおかしいらしいことが発覚。 順運動学ってただの行列計算なんだけど、足裏が浮いた上体やら股関節の姿勢やらをサポートしていて随分と複雑な計算になっている。 いままでうまく行ってると思っていたのだが、確認が甘かったらしい。
また、回転行列との格闘が開始されるのだろうかぁ～、、、 悩ましい。。。
＃秋葉原の通り魔事件、びびりました。 それにしても最近この手の事件が多過ぎる。 物騒な世の中になったもんだ。
・・・・・散々悩んだ結果、計算合ってました。orz 「こういう計算結果にはならないはず！」って思ってたのが間違いでした。。。。 無駄な時間を費やしてしまったぁ～。(>_<)
2008.6.14 数式の間違いを発見したので訂正しました。
■６月１０日■
上半身の管理の整備にてこずってます。 後回し後回しにしてきたツケが効いてきたか。(^^ゞ
でも、徐々に整備はできてきて、もうすぐうつ伏せからの立ち上がりができそうです。
うつ伏せからの立ち上がりは意外にも、上半身の制御の面倒な部分がたくさん含まれておりました。
ラムダは顔が丈夫じゃないので立ち上がるには手先で上半身を支えねばなりません。 そのため、手先を胸元に入れて腕立て伏せの「伏せ」状態のような姿勢になる必要があるのですが、この腕の動きが結構クセモノ。 上腕のひねりを十分に活用しなければなりません。 今回、これは関節角度指定による上半身姿勢指示のコマンドを起こしました。 いままでは座標指示で逆運動学計算で関節角度を出していたのだけど、ヤコビ君もまだしっかりしていないし、冗長自由度を十分に活用した腕の動きを行わねばならず、現状の逆運度学指示だけでは表現できない状態です。 仕方がないので関節角度指示で適当なフレームを起こして細かな指示をしました。
次に腕立ての「立て」状態に持ってくるのだけど、腕で浮き上がったので下半身姿勢が変わってしまいます。 これを下半身姿勢に取り込み、更にその下半身姿勢を上半身姿勢に取り込むという必要がありました。
次に手先の空間座標固定モードの活用です。 膝を曲げてお尻を持ち上げて「へたこいた～」姿勢に持っていくのだけど、手先の接地位置は変わらずに下半身の動きに追随して手が動きます。
次に腰を完全に足に乗せる位置まで移動させるのだけど、もう手先座標を固定していては可動範囲を超えてしまうので、下半身が動きながらも、手先座標を目的座標に動かすというのをやります。 これはちょっと微妙で、 現状では手先座標というのは股関節原点（両股関節の中点）を原点とした座標になってます。 これはロボット原点（股関節原点を床面に投影した点、ただし、オフセットなどが0である前提）にすべきかなぁと思ったりして迷ってるところです。 これから作るアプリケーションによってはロボット原点からの座標指示にした方がいいかもしれない。
そんなこんなでもうちょっとで整備された上半身管理体制でうつ伏せからの立ち上がりができそうな感じです。
ちなみに首のネジヒューズはとんじゃって首はブラブラ状態です。(ーー;)
■６月１１日■
おかげさまで新上半身管理体制の元でうつ伏せからの立ち上がりができるようになりました。 まだ幾つか不満があって、どうやって解消すべきか考え中です。
立ち上がったのですが、旋回から直進歩行に切り替えると、姿勢判定がうまく行かず、延々と姿勢修正を行おうとしてしまいます。この辺り、まだ新体制になじんでいない部分があるようでまだまだデバッグは続きそうです。(>_<)
さて、ヤコビ君の続きですが、ヤコビ行列が出来たので、次にこれを使って逆運動学計算をするためにヤコビ行列の逆行列を計算しなければなりません。
n×ｎ行列の逆行列は学校で習ったので簡単に計算できるのだけど、ヤコビ行列の各項を展開するのは愚といえるでしょう。ここからはプログラム上で実際の値を代入して計算するべきかと思います。
しかし、、、 とっちらかってて何やってるか判らなくなってきたなぁ～。上半身管理の見直しやヤコビ行列での逆運動学ができたら何すればいいんだっけ？？？
■６月１２日■
４次の正方行列の逆行列。。。
について
のときAの逆行列が存在して
ただし
簡単じゃーないね。プログラム書いちまうか。 いや、ベタ書きで計算だな。 エクセルで検証しようかと思ったけど、直接ラムダでやった方がいいかなぁ～。増分の大きさと精度の関係を見たかったのだけど。。
■６月１４日■
ヤコビ行列を使った逆運動学計算をやってみました。
グラフ中に小文字のx y z r と、大文字のX Y Z R とありますが、小文字がヤコビ行列の逆行列を使って計算した関節角度から順運動学で算出した座標と上腕のひねり角度。 大文字がヤコビ行列の逆行列に与えた手先座標と上腕ひねり角度です。 このグラフだと大きな誤差も無く目標座標へ移行しています。
座標と上腕ひねり角度を変えると、 途中までは順調なのだが、後半で乱れがでてしまう。 大文字のグラフも乱れているのは、ステップごとに最新の関節角度から座標とひねり角度を再設定しているため。 そうしないと誤差が大きくなり、うまく計算できなくなってしまう。
うまく行くケースとこうして乱れてしまうケースがある。計算回数を増やして差異を小さくして乱れが収まるケースもあれば、上のケースなどは回数を増やすと乱れが大きくなってしまったりするケースもある。 ここまでくるのにヤコビ行列の算出式の間違いをいくつかみつけたので、まだ数式上のミスがあるのかもしれない。
一応は一通り数式の見直しをしたのだが、もう間違いは見つけられなかった。 乱れてしまうケースがどういう場合なのかちょっとわからないのでこのままではラムダに組み込むことが出来ないですね。
ヤコビ行列を使った逆運動学計算の場合、たとえばすばやい動作をさせたくて、１ステップで大きく動作させたい場合でも、内部的には相応の回数の計算をしなければ正しい関節角度は得られない（はず）。 手足のように使うにはもっと検討が必要ですね。
この結果を見て、やっぱ関節は直交軸しかないかぁ～とも思ったが、この先関節が増えていけばどうしたって解析的な解法で逆運動学計算式が得られなくなる。 そのときの手段がヤコビ行列なのかどうかはわからないが、なにか手段を考えねばならないのだろう。 つまりは直交軸にこだわるのが正しい姿でなないのだろうと思います。
それにしてもヤコビ行列はすばらしい。いままで計算を簡単にするためにラムダの関節構造は直交軸にしてきた。ま、そのお陰でヤコビ行列を使った逆運動学計算をやってみたのは今回が初めてだったのだが、教科書を読むだけじゃなくて演習してみればすばらしさの感じ方も違ってくるというもの。
↑目標姿勢に対してリニアに動作させた場合の関節角度はもちろんリニアにはならない。ヤコビ行列を使って算出した関節角度のグラフが↓これ。
ファンタスティックです。
■６月１５日■
ラムダの今の手先は仮の姿で、最終的にはちゃんとモノをつかめるようにしようと考えています。できればヒューマノイドらしい手をつけたいのだけれど、床のモノが拾い上げられるのが第一条件。 さらにはこけた時の受身で手を着くことを考えるとやわな構造（＝複雑な構造）はダメ。
床のモノが拾い上げられるってのはただ拾えるだけじゃなくて、ラムダのカメラで視認しながら拾い上げる動作ができなきゃダメってことなのでちょっと条件が厳しい。
そういうわけで決めあぐねていたのだが、とりあえずは候補①で作ってみることにしました。
カニ手です。 受身のことを考えて動くのは前側にしました。だからカニのはさみとは逆です。（と書いてから「ホントかな？」と思って調べたら逆じゃなかった。）訂正。蟹と一緒です。ロボットのマニピュレータは普通は親指が動く感じで、画像の状態だと左右にはさみが開く構造が多いですが、ラムダは（画像の状態で）上下に開く構造にしてみました。
これには理由があって、床にあるモノを拾おうとしたとき、上体をかがめて手を差し伸べるのだが、腕はモノに対して横から差し込むような感じで手を近づけていくことになる。腕の自由度が十分ではないラムダの腕でモノに対してアプローチするとき、手先の姿勢は限られる。 蟹手の開閉方向が左右だと、床のモノの下に手を差し込むようにしなければならず、拾い上げるのに失敗する確率が高いだろう。また、開いた手を近づけると手でモノが隠れてしまう可能性も高く、やはり失敗しそう。
本当はハサミのようにどちらの指も動くようにしたかったのだけど、転倒時の受身に耐えられる強度を持たせるには可動指じゃ無理ってことで画像のような構造にしました。
サーボはFUTABAのRS301。 一応はトルクコントロールも出来るし、角度の取得もできるから圧力センサーとかつけなくてもモノをつかんだことを感知できます。
この手のサイズじゃぁつかめるものはたかがしれてますけどねー。(^^ゞ
板金はUMIEさんのアルミ切抜きサービスにお願いしました。サイズ的には1シートだとちょっと足りなくて、ロボトマのサイズがいいんだけど、ロボトマは送ってもらえないので使えませんでした。この部品の曲げって普通の曲げ機じゃ曲がらないので、部品取りに行って帰ってから曲げ加工ってなっちゃうのはちと辛い。
■６月１７日■
思い起こせばロボビリヤードで、ターゲットに近づいて、ターゲットを手で跳ね飛ばす動作をさせようとして、カメラで捉えたモノに手先を伸ばすって事をさせようとしたら腕の可動範囲が狭いもんだから、肩のブラケットにオフセットをつけたところが、逆キネがヤコビ行列を使わなくちゃならなくなったり、立ち上がりモーションがおかしくなったりして上半身の管理方法の見直しやらヤコビ行列の検討やらをしていたのだった。
気がつくとマニピュレータの構造設計とかやってて、、、寄り道しすぎです。(^^ゞ
今日、マニピュレータのツメの開閉に使うRS302（301じゃなくて302だった）の反対軸つきボトムケースとフリーホーンが届きました。あとは板金が切り抜かれて届けばマニピュレータの製作に取り掛かれます。 １２Ｖを７Vに落とすレギュレータも作らなきゃならないけど。。。
オフセット付き肩ブラケットでの逆キネもできて（ヤコビじゃない方。ひねりなし。）、立ち上がりモーションもできたので久しぶりにボールを追いかけさせたり手先を画像データで動かしたりするプログラムを動かしてみたりしました。 手先を画像データでって方はなんだか前より位置の再現性がいい感じ。 なぜだ？
アプローチ動作は、相変らず目標が横にそれた場合の動作がうまく行ったりいかなかったり。 なぜが逆方向に旋回を始めたりする？？ もちろんプログラムを見直していないからおかしかった部分が直ってるはずはないんだけど、判定基準ってなんだっけ？忘れてしまった。(^・^)
あと、、、（だんだん思い出してきた(^_^;) ） ターゲットに近づいて腰をかがめた状態で手先を見失ってしまうんだった。 これはカメラのホワイトバランスとかCDTテーブル値の調整をしてみなくちゃならない。 外光の具合で色認識に変化が出てしまうのはまずいですよね。 オートチューニングできなきゃなぁ。 なんかいい方法ないだろうか。
■６月１８日■
アプローチのための行動決定について考えます。
アプローチするとき、ターゲットに対して歩いて近づくのか、旋回してターゲットの方向を向くのか、大きく分けて二つの選択肢があって、どちらを選択すべきかという判断が必要です。
簡単に考えると、ロボットの正面を中心とした左右のある範囲の角度にターゲットが含まれれば直進、またはカーブ歩行で近づき、それよりも角度が大きければ旋回してターゲットの方角を向くということが考えられる。
ですが、これだとターゲットまでの距離が近い場合、半径の小さなカーブ歩行を選択してしまい、不安定な歩行となってしまう。
ならば、距離に応じて判定の角度を変えればいいのだが、距離を何段階に分ければいいのか？などの問題が出てくる。ま、それくらいは調整すればいい話なのだが、どうも趣味に合わない。
半径が小さなカーブ歩行を選択するということは、ターゲットに向かって大きく回り込むルートを選択するということになる。では、それを判断基準にしてはどうか？
ターゲットまでの距離や方位を考えるのではなく、ターゲットに向かってカーブ歩行を行った場合、どれくらいの角度をカーブ歩行で歩くことになるのか？これがある値よりも大きくなる場合は旋回を選択すればいいんじゃないか。 これだと判定値は一つになってすっきりする。
ターゲットがごく近くにある場合、方位で判断するとうまく行かないことが多いような気がするので、この方がいいかなーと思います。 今日試したかったのだけど、タイムアウトで持ち越し。 明日からしばらくはラムダに関われないかもしれないのでどうしたもんかなー。(ーー;)
■６月２３日■
関東組ロボット練習会に行ってきました。
散財さんところで紹介されているんですが、シグマです。↓
立ってますけどまだ歩いてません。 昨日、練習会場でモーション作ろうと思ってたんだけど、逆キネ関数がやっと作れただけでした。でも、思いのほか好評でちょっとびっくりしました。 もともと、虫類とかの多足の生物やカメみたいなメカニカルな生き物が好きで、メカモとか欲しくて仕方なかった（買ってもらったら意外にしょぼくてがっかりしたりしましたが）クチなので、こういうタイプのロボット好きです。
で、ラムダを作って、ラムダがりっぱな２歳児になるまでは他のロボットは作らないように努力していたのだけど、ついにとうとう手を出してしまいました。 本当はこれにも協力なCPUを載せて自律に向かいたいところなんだけど、それこそ収拾がつかなくなるのでしばらくはラジコンでいこうかと思ってます。
こいつの行く末はわからんのですが、とりあえずテーマは不整地歩行。 ロボカップに出てくるレスキューロボよりはいい動きをさせたいなぁと思ってます。もちろんそれはでかいCPU積んでからのことでしばらくは平地だけで遊ぶつもりです。
散財さんが書いてた３本ずつ束ねて２足にする、ってのは本気でして、関節のインピーダンス制御に近いものができないかを実験してみるつもりです。 まぁこれは作ったからついでにって感じが強いですけどね。
今日こそは歩き出すかと思ったのだけど、帰るのが遅くなったのでまたしても持ち越し。 残念です。 ほんとに。。
■６月２４日■
今日こそはシグマを歩かせるために早く帰ろうと目論んでいたのだが、仕事がなんだか大変なことになってしまって遅くなってしまった(>_<)
だがしかし、６足はバランスとか考えなくてもモーションを機械的に作れば歩けるのでしゃかしゃかしゃかっと作って前進と後退はできるようになりました。足の往復距離を±30ミリにして1周期の時間が0.4秒にして、ガツガツガツガツと歩くようになりました。 歩幅はもっと広げられそうですね。
それにしても打ち込みでモーション作るって大変(ーー;) やっぱ早くでかいCPU積んで計算で歩かせたいです。 今回は単純な歩容なのでどうもマシンっぽい。３足1セットのクローラ歩容でも動かしてみたいのだが、打ち込みじゃ・・・無理です。めんどくさい。。。
で、わんだほーに出たいなぁと前回から思ってたんだけど、今回こいつを更に改造してSIGMA-BIPER（仮）として二足歩行できるようにして出場することを考えておりました。なのになのに今日の日誌の冒頭に書いたように仕事が大変なことになってしまって、、、 ２９日の９時ごろは中国に出張中(>_<) ・・・ 仕事中かも。 運がよければ仕事が終わっていてホテルから出場申し込みできるかもしれないんだけど、、、 ふぅ。
明後日早朝から成田へ向かいます。 今週はロボットは打ち止めだなぁ。。 しょぼん。。
■６月２５日■
明日の出張の準備をさっさと済ませてシグマのモーション作ってました。
昨日とおんなじ調子で横歩きと旋回を作ってコントローラに割り当て。 で、動かしてみたんだけど、、、、 なんか・・面白くないです。 今日は歩幅を大きくしてちょっと周期を落としてみたんだけど、迫力ないし、、動きも単調だし～。 ガサガサって早く動かしてこそのクモ型なんだな～。
画像の上側に向かって進んでいます。
早く上半身作ってなんかできるようにしなきゃなー。
では、中国へいってきま～す。
■６月２９日■
中国出張から戻ってきました。
新しく作ったシグマを２足歩行ロボットに改造してわんだほ～に出るつもりだったのですが、どうやら近いうちにまた中国に行きそうだし、そうなるとロボットの進捗も期待できそうにないので、今回は出場を諦めることにしました。 やはり当初の目的どおりラムダで自律で出場を目指した方がいいのかな～。
中国では取引先での仕事だったのですが、夕食はチャイニーズレストランで食事に連れて行ってもらいました。 日本で食べる中華とは調味料が違うので正直ちょっと苦手なのですが、まぁ郷に入らば郷に従えということでおいしくいただきました。
中国のレストランは生け簀が置いてあって、食材が選べるようになってます。エビとかはまだいいんですけどシャコとかは結構グロいんですよね。（マレーシアに行った時はカブトガニがうようよと生け簀にいたなぁ。。） そんな中、結構珍しい食材が並べてありました。
スッポンですね～。 日本でも生け簀で泳いでます。
同じカメでも凶暴なワニガメ。 噛まれると指が飛びます。 これも食材です。
ちょっと判りにくいけど、ヘビ。 ふっとい～。 食材です。
外の生け簀にはサメが。。。 食材です。
ええと、、、 食材です。 (>_<)
クチはビニールテープでぐるぐる巻きになってました。
同行した香港駐在３年の経験を持つ人の話だともっといろんなえぐい食材を見たそうですが、 さすが4つ足ならばイス以外は食べると言われたお国柄。。 これくらいは序の口のようです。(^_^;)
■６月３０日■
ここんとこ色んな課題を散らかし放題だったので、久しぶりにロボれる状態になったにも関わらず、何から手をつけていいやら判らん状態になってしまいました。
実はラムダのサーボをぜーんぶフタバさんに送ってファームアップしてもらう予定なんですけど、オブジェクトをトラッキングしてアプローチして手でタッチするってところが佳境なもんだから後回しにしているのです。 で、いい感じにカタが着いたタイミングでサーボを送ってファームアップしてもらってる間にシグマを仕上げると、そういう遠大(^_^;) な計画だったのだけれど、どうにもアプローチがうまく行かない。 日誌を読み返すと６月１８日から練習会にシグマを持っていくために浮気して、そのままモーション作成に入っちゃって、さらに急に中国出張になって今日に到ります。 更にはマニピュレータもアルミの切り抜きまで出来ているのに放置状態。
で、気を取り直してやっぱり１８日の続きってことでアプローチの改良に取り組んでいました。
しかし、どうもうまく行かない。 ログを取ってデバッグしようにも情報が多すぎてなにがどうなってるのかさっぱり解析できない状態になってしまった。
普通に歩かせるとひょこひょことある程度は安定して歩くんだけど、アプローチをさせて歩かせると判断が入るせいらしいのだが、途端に歩行が不安定になる。 1歩歩くごとにカーブ歩行の歩行半径を設定しなおしているのがよくないのか？ 処理自体が重くてサーボへのコマンドタイミングが狂ってしまってるのか？ 根本的になにか間違えているのかもしれないなぁ～。(>_<)
シグマに襲われたラムダ。 仲間じゃなかったらしい。。
■７月１日■
とりあえずシグマをやっつけちまおう、ということで、今日はシグマのモーションを再作成。
こないだ作った時より早い動きで前進後退左右移動旋回 をできるようにしました。 でも、やっぱり６本足だと安定して動くので面白くない。 結構誤算だな～。 こいつは悪路歩行させるしか楽しみ方がないかもしれないなぁ。 足が6本もあるので足の動きで色んなポーズや姿勢を取れるのだが、モーション作成って大変ですねー。 胴体の位置を変えた歩行を作ろうと思ったらそのモーションを作り直さなきゃならないわけで、、 6本足歩行こそ逆キネでやるべきものだなと思いました。
シグマを２足ロボにするときは↓こんな感じにして足裏で３本の足をつなぐ。
シグマを立たせたところ
ほぼ球形なので、、
転がったところ
転がります。
重心が偏ってるので元に戻れないですが。(^_^;)
ラムダで自律系のプログラムの検討しているときはすぐこけたり膝が熱でダメになってしまうのが腹だたしかったりするのだが、シグマを動かしていると、不安定感が無いのでハラハラ感が無い。これはこれで物足りない。 うぅ～ん。。 無いものねだりだな。
RPU-10にモーションを仕込んでコントローラで動かすってのを始めてやってみたのだが、RPU-10の標準プログラムって非力過ぎませんかね。 他のをしらないのでなんとも言えないんだけど、仕込めるモーションが少なすぎる。コントローラの組み合わせでモーション発動とかができない？ RとかLとかを押しながら移動させると高速で歩くモーションが起動するとか、 アナログスティックを倒す角度でモーションの再生速度が変わるとかってできないのが普通なのかな？ 時間リンクとかってのがそれか？ マニュアル読んでもイマイチイメージが掴めない。
・・・明日こそはラムダのアプローチのデバッグを。。。
■７月５日■
日誌は書いてなかったけど、ちょこちょことラムダのデバッグは進めてます。進捗はかばかしくないけど。
今日は土曜日。 デバッグの続きをしようかなと思ってみたが、ずっと気になっているマニピュレータの組み立てをやることに。 ホントはこれ、サーボをファームアップに出している間にやろうと思っていたんだけど、工作は休日の午後のいいお題です。デバッグやるのがイヤでついやってしまいました。
カニ手のマニピュレータ。 結構頑丈にできました。
もう両手ともできたけど、画像は左手だけ出来たときのもの。 背景に右手の部品が写ってる。(^_^;)
ツメの開閉はRS302CDに反対軸ボトムケースをつけてます。 まだ配線できてないから動かないけど。 手先に付けたマークがなくなってしまったのでマークもつけなきゃ。 マークをつけるには都合の悪い形になってしまった。
RS302CDに反対軸ボトムケースをつけるにはコネクタのハウジングから一度線を取り外さないとケースの穴を通すことができません。 このシリーズってRS485なので4線あるんだけど、黒2本と灰色2本。 きっと同じ黒でもマークが違うとかで判るようになっているんだろうと思って、サクッと外してしまったんだけど、もう一つのサーボのケーブルと比べても線のマークが統一されていない(>_<) なんだこれはぁ？？ 結局ボトムケースを外して配線の根元から確認してハウジングに収めました。 テスターであたらなくても判るようにして欲しいなぁ。
明日のロボワンサッカーの決勝は、宇宙大会予選目当てで行こうかな～と思っているんだけど、まだ迷い中。 宇宙大会予選は2時半からかぁ～、でも行くなら朝からだよなぁ。。
■７月６日■
ロボワンサッカー観に行ってきました。 本当の目的は宇宙大会予選の見学だったので、昼飯を食べてから出発。 途中、守護霊が邪魔をするかのように、京浜東北線からりんかい線に乗り換えるのに品川まで行ってしまったり（品川乗換えだと思ってた） りんかい線で携帯ゲームしてたら何を思ったか東京テレポートで降りてしまったり、ぼけぼけでした。
宇宙大会予選、レギュレーションがなんだか厳しすぎる感じがするんですけど、KAZZさんのロボットが第一投で成功！ びびりました。 確かに下半身が固定で上半身が９０度回転して「ロンダート」風ってのはアレですが。 宇宙大会にはあまり興味が無くって、重さとか大きさのレギュレーションが邪魔でトライする気が起きないのだが、投げロボ自体には興味がある。 レギュレーション無視して投げても着地するロボットってのを考えてみたいなと思いました。 シグマに処理能力がでかめのCPUを載せてやってみようかな。
サッカー見てて思ったのはイガァさんのサアガの機動力。 転がるボールよりは早く動けてました。すばらしいです。 それにクロムキッド。 すばやい動きの上にスローインでの遠投もしっかり出来てるし。 くぱぱさんは一体どれくらいの時間をロボットに費やしているんだろう。
帰ってラムダのデバッグをやろうとしたんだが、こないだからちょっと気になることが。 なんだかセンサーボード（ジャイロとGセンサー）が反応していない節が。 いつもモニターしているわけじゃなく、デバッグ対象でもなかったので「今度調べよう」程度に思っていたのだが、ちょっと調べてみた。
ラムダはスピーシーズロボットが原型なのでセンサーボードはスピーシーズロボットのセンサーボードをそのまま使っている。 LEDの光り方がいつもと違うのでマニュアルを引っ張り出してみると、、 ファーム書き換えモードになっている？？？ なぜだぁ？ ついこないだまで正常に動いていたのになんかノイズが乗ってモードが切り替わったのか？
工場初期設定に戻すって操作をやってみたがまったく変化なし。 仕方が無いのでこれはスピーシーズに問い合わせ。 多分送り返してファームを書き直すなどの処置が必要になるんだろうな。 これを機会にラムダをばらしてサーボを双葉電子へ送ることにしよう。
ラムダのアプローチ軌道計算はどうやらOKのよう。 今度はこの計算結果を判定に利用してアプローチさせる。 これはサーボが戻ってきてからになるかなー。
■７月７日■
今夜は具合の悪いセンサーと格闘してしまい成果なし。(>_<)
ボードが破損しているわけじゃなさそうなので、ファームを入れれば直るはず。 センサーデータの取得周期を上げたいなとか考えていたのでこれを機会にセンサーボードを作ろうかなとか考えたが、また寄り道が一つ増えてしまうので自粛。 素直にメーカーに送って直してもらうことにします。
もうもうすぐにでもラムダを分解してサーボを送りたいので、最後にアプローチの動作確認をする。
結果はまぁまぁ良好。 概ねおかしな動作はしなくなったように感じる。 それより問題は膝サーボがすぐに熱で落ちることと、アプローチ処理を追加すると処理が追いつかなくなること。
これは致命的。 今はデバッグ中で、telnetに処理状況のデータをばんばん送り続けているからそのために処理オチしていると思われる。
サーボが戻ってきたらその辺も合わせて検証して行こう。 どちらにしてもNetBSDからリアルにサーボデータを送るのは限界っぽい。 サブCPUを積んでバッファを形成する計画を進行させねばならないだろう。
さて、明日はとうとうラムダを分解。 これがいつもゆううつなんだよねぇ～。 ちゃんと組み立てられるのかな(>_<)
■７月８日■
７月６日の日誌に誤りがありました。 KAZZさんの宇宙大会予選での姿勢制御なのですが、上半身が回転しているのではなく、下半身を９０度ひねって着地しているのでした。 会場でリアルに見たときは何がどうなったのか正直判らなかったのですが、ビッグボスが「あれはちょっとなんだけど、、」的な表現をしていましてので、考えた末に上半身が回転したんだろうなぁと思って書いてしまいました。訂正してお詫びいたします。
でも、すると、、 非の打ち所無く規定演技だったのではないかと思うのですが何が気に入らなかったのでしょうか？ ROBOTWATCHの高速度撮影動画を見ながら考えたのですが、もしかして、手が離れる前から下半身の動作が始まっていたと判定したのか？？ いや、動画を見る限りでは手が離れるまでロボットは動いていないようにしか見えません。 ん～、わからんな。
ラムダを分解する前に最後のデバッグ作業。 でも、昨日はうまく行ったと思っていたアプローチ動作はまだ検討不十分。 顔を洗って出直してきます。(>_<)
手足の外装を外して胴体と顔だけ外装。 こっち見てるわけじゃなくカメラ辺りにあるピンクボールを見てる。(^。^)
バキュームで作った外装はあちこちぼろぼろになってます。 作り方とかもうちょっと考えなきゃな。
サーボを外したところ。 顔はRS301とか302なので今回は対象外。
こっから下は自分用のメモ。
うぅ、、こっちもピンボケだ。
腕のサーボ角度ゼロの姿勢はこんなの。 足首はこの状態を作ってから次の組み立てに進むこと。 サーボ固定ネジを差し込んでおくことを忘れないように！
■７月１１日■
サーボが送り返されるまでにシグマをRPU-100で動かしてみよう！ なんて思っていたらすぐにサーボが送り返されてきた。 いや、双葉電子殿、迅速な対応をありがとうございます。<(_ _)>
早速組み立て。 サーボは工場出荷状態になっているので通信速度は115200bps IDは全部1。 それぞれにIDと通信速度を設定して、
腕、足、胴体がそれぞれ完成！
合体！
これを機にケーブルを作り直そうと思っているので今日は配線なし。
さて、サーボのファームアップの成果はどうやって確認しようかなー。
■７月１４日■
この土日はロボットの進捗はまったくなし。
というのも、１２日の夜から富士山登山に出発。 １３日のご来光を拝みに行ってきました。
実は登山の類はまったくの初心者で山に登るっていうのは中学生の頃に近くの鉢伏山（神戸市須磨区）に無線機を背負って昇って以来のこと。 まぁ生きているうちに一度富士山には登っておきたいなぁと思っていたところ、会社の有志で富士登山が企画されていたのを偶然に知ったので酔った勢いで参加表明しちゃいました。
なんとか自分の足で登って帰ってきましたけど、富士登山ってなかなかハードですねー。 どうやら登った人はたくさんいるようで、会社で「今度富士山に登る」って言ったら結構な確率で体験談や注意事項を伝授されました。
驚いたのは登山道の大渋滞。 夜通しかけて登って山頂で朝日を拝むって暴挙になぜにこんなにたくさんの人が集まっているのか？ 渋滞に巻き込まれたせいもありご来光は九合目過ぎた辺りで拝むことになってしまいましたが、天気には恵まれてすばらしい光景を見ることができました。
あと、登山途中に見た満天の星空。 きれいだったな～。感動しました。
この景色を見るためならもう一度登ってもいいかなぁ・・って自分に問いかけたけど未だ返事なし。(^_^;)
■７月１７日■
１５日は山梨へ出張。 １６、１７日は九州へ出張。 今日は佐世保から帰ったのだが、あちらを出発したのが3時半で、家についたのが10時。 6時間半もかかるんだぁ～。
帰ってメールチェックするとスピーシーズからセンサーボードの診断結果が来ていた。 なんか色々書いてあったが理解不能だったのだけど、要は壊れているので有償修理（というかボードを新規購入してくれ）ということらしい。
それにしてもあんなものがハード的に壊れるもんなのかなぁ？ 絶対壊れないわけはないが、壊れるようなストレスをかけた覚えはないのだが。。 戻ってきたらマイコンボードとしてアクセスしてみよう。
色々不満があるボードをまた買うわけにもいかないので、やはりセンサーボードを作ることになりそうだ。ついでといってはなんだが、センサーボードとなるマイコンボードにサーボの時分割データのバッファを作り、リアルタイム性を確保するってのもやろうかと思う。
昨日、飲んで帰ったら（午前２時ごろ）なぜか部屋の電灯がつかない。昨夜はPC机についているスポットライトで用を済ませたのだが今夜までに何とかせねばならない。 というか昼間も部屋が暗いのはいやなので電灯をつけるから電灯が点かないと困る。 蛍光灯が切れたわけじゃなくて電灯自体が壊れたようなので午前中にヤマダ電機に新しい電灯を買いに行った。 電灯はすぐに買ったのだが、そういやデジカメ。。。 デジカメのスイッチが寿命のようでなかなかスイッチが入らないのだ。一度入ると今度は切れないし。 ま、簡単に言うと壊れている。代わりのデジカメを買わなきゃなぁ、、としばらくデジカメ売り場で物色。 あ、そういやこないだの投げロボで活躍してた高速撮影できるデジカメ、カシオの「EX-F1」正直これ、欲しいです。 コレを使うために投げロボ始めようかなーとか思うくらい。
本気で欲しいけど、これはおもちゃだなー、実用的には携帯に便利なコンパクトデジカメが（家族用として）必要。 でも、デジカメの使い方が集合写真を撮るよりも動きのある画面を撮る場合が多いのでコンパクトデジカメじゃうまくないことが多いのだ。 するとデジタル一眼レフ。 これもずっと欲しいんだよね。カメラ趣味じゃないけど実用で一眼レフ買おうかなー、でもコンパクトデジカメも要るし、一眼レフとコンパクト買った上にEX-F1は買えないよなぁ～さすがに。。 ﾌﾞﾂﾌﾞﾂ。。
ということで今日の午前中が終わってしまいました。結局デジカメはペンディングで。(^_^;)
今日こそはロボットの進捗を、ということでやりたいメニューはたくさんあるんだけど、センサーボードが壊れたことが起因してATMEGA128マイコンボードをRPU-100につなげるってのを進めようかな。
で、買っておいたベステクのATMEGA128ボードを取り出してみると、、 がぁ～ん＼(◎o◎)／！ 発振器がむちゃ小さくなってる！
買ってあった発信器は、ちょっとデカめだけどATMEGA32の時は搭載できたのだけど、、 これだとさすがに大きすぎる。ジャンパー張らないといかん。 むぅぅ、、、
ということでもっと小さい発振子をRSコンポーネンツで注文するはめに。1個500円もした。(>_<) （それでもこれより大きい）
じゃそれはおいといて、GDLのインストールしてボードの動作確認やらなんやらをやりましょう～。 ということで、ダウンロードしてインストールすると、、 RPU-10用がターゲットから消えてる！ なぜだ？？フタバからクレームが来たのか？ なんとか旧バージョンを入手できないのか？？
探し回ったが旧バージョンのダウンロードは出来なさそう。 がっくりしてると自分のダウンロードフォルダーにGDL1.7くらいのやつが残っている。試しにインストールしてみると、これにはRPU-10設定が入ってる。どうやら初期バージョンを偶然ダウンロードしていたらしい。
しかし、いまさらGDL1.7を使いたくないのでGDL最新版にGDL1.7のターゲットファイルとかライブラリを放り込んでみたのだが、 案の定リンクエラー。。。
RPU-10用のコンパイルはGDL1.7でやるしかないのかなぁ～(>_<)
なんだか、もうすぐラムダが自律（とは言えないが）しそうなところで色々な邪魔が入ってきた感じ。 はっ！ もしかしてあれか？アトム今昔物語のパラドックス！ どこかで朽ち果てているもう一台のラムダを破壊しなくちゃいかんのかな。
そういやプルートゥの最新刊が出てました。 早く通常版が出ないかな。 それにしても最近ラムダもシグマも全然進まないなぁ～。自分のモチベーションがぐったりしているのが本当の原因なんだろうなぁ～(ーー;)
明日は「わんだほ～」です。 今回も出場しないけど観に行こうと思ってます。 あわよくば打ち上げにも参加するつもりで。
動画