板金曲げ木(^^ゞ 総檜作りなのだぁ。■２月８日 ＜スピ届く＞■
スピーシーズがとうとう届く。
センサーボードとオプションのジャイロがまだ届かない。それは事前連絡どおりなのでまぁ。。でも、いつ届くんだろう。あとはライブラリーもＬｅｂｅｌ２＆３になってるし、サービスのバッテリー充電器も入ってたし、問題なさそう。部品が揃ってるかどうかチェックしようかと思ったけどたいへんそうなのでヤメ。サーボとかは入ってるのでまぁ大丈夫だろう。それにサポートしてくれそうだし。
今日はかねてからの予定通り、板金折り曲げ機の製作に取り掛かる。材料の切り出しケガキをして、、ダラダラやってるからなかなか進まない。それに、工作は久しぶりだし・・・。結局、切り出し作業だけで終わってしまった。穴あけは後日だな。それにしても外作業は寒いぃ～。寒すぎ。
マニュアルを一通り読んでみた。ソフトウェア開発者向けっぽく、組み立て説明書はなかなか細かい。あ～、でも大変そうだなぁ。フレーム設計する前に組み立ててみようかなとか思ってたけどヤメかな。下半身は。。ＣＰＵユニットとか、サーボの動作とか確認しなきゃと思いつつ今日はやめ。
開発環境はCygwinでクロスコンパイルって考えてたけどダメだって返事が。おかしいなぁgccでできそうだって思うのに。
■２月９日 ＜クロスって深い＞■
ノートにデュアルブートでNetBSD入れるのもいいけど、うーん。。。ＨＤＤに余裕あれば入れておいてもいいけど、環境再構築はいやだな。デスクトップに入れるように考えよ。ネイティブのNetBSD有った方がよさそうだし。いろいろ。られたけど、買わなきゃならないし、イマイチ趣味じゃないから乗り気がない。その後、ソフト担当からクロスコンパイル環境の条件が届いた。いけるかも、しばらくはCygwinでのクロスコンパイル環境構築にこだわってみよう。
ここらへんが参考になりそう。
http://www.sixnine.net/cygwin/translation/devel/cygwin-to-newlib-cross-howto.html
http://www.asahi-net.or.jp/~wg5k-ickw/html/online/gcc-2.95.2/gcc_toc.html
さっくりとgccのビルドをしてみたけどうまくいかない。うまくいかないとなるとなかなか先に進まないんだよね。configureとかすごく良くできてるんだけど、仕組みが巧妙過ぎてよく知らないと追跡できない。ケースとしては必要なヘッダーファイルが見れないってパターンが多いかな。その辺りをエラーメッセージとソース見ながら追跡。でも今日はダメなままあきらめる。
■２月１０日 ＜今日は乗らねー＞■
昨日の続きでクロスコンパイル環境構築と、明日の穴あけのためのケガキをしようと思ってがんばってケガキまで。やっぱり動作確認しなきゃなぁと思ってCPUユニットに電源を入れてみる。ちゃんと動いた。UNIXが動いてるのはやっぱびっくりですな。こんなちっこいのに。。
ノートＰＣにCOMポートがないのでこの日のために買っておいたUSB-COMアダプターをインストール。これってあんまり売ってなかった。値段もあんまり安くない。（３５００円くらい）買いに行ったとき、ロボット王国なら売ってるだろうって思ったけど売ってなかったと思ったら次に行った時は売ってた。見つけられなかったのね。値段変わらなかったからいいけど。つないでみて思ったけど、無線LAN設定しちゃえばこのアダプターって要らなくなるのかな？デスクトップで設定すればよかったんかなぁ～。ま、いいか。
ラムダの足の逆運動計算を考えておこうと思って出張の移動時間なんかに考えてみてる。ラムダはロール軸を太ももに持ってくるつもりだけど、計算的にはどうなんかなー。色々と考えたけど、ロールはロールという結論。問題なさそう。ロールを持った関節の場合、逆運動計算は一意に決まらないんだけど、ロール角だけ与えれば決まるようだね。あとは大体アイボの逆運動学計算の経験でなんとかなりそう。数式までには落としてないけどそれはまた脳みそのクロックを徐々に上げてから。。
お風呂に入りながら、UNIXでのロボット制御プログラムを考える。アイボのアペリオスは完全なイベントドリブン型で、色々と簡単だったけど、（理解するまではなんだかたけど）RTLinux見たいなんじゃないからどうやるんかなぁ～って感じのこと。調べると、インターバルってシグナルがあるんね。実行して、関節制御とか画像処理とかのジョブにフォークして、メインはインターバルシグナルうけてそれぞれのジョブに指示を送るって感じかな。
■２月１１日 ＜ツール作りはつらいよ＞■
予定通りに板金折り曲げ機の作成とクロスコンパイラのビルド。
板金折り曲げ機はあとはブレードを作るだけ。これが大変なんだけどね。あ、あと、木をちょっと削らなきゃ。ベースの木材はＤＩＹ店で端切れを安く買ってきた。なんか知らないけど檜。穴とか開けるといいにおいがする。
クロスコンパイラは難航中。なんとか、gccだけはコンパイルできたけど、newlibができん。毎度ながらビルドはつらい。わからんもん。ドキュメントは英語だし。クロス環境ってみんな苦心してるみたいで、ネットで探すと色々と出てくる。あまり詳しくないけどこんなのをみつけた。
「あら不思議、Windows(Cygwin)でコマンドを打ったら、NetBSD/PowerPCのバイナリを吐くようになったよ。」
おお、やっぱできるんじゃん。がんばろーっと。ま、でも、もうちょっとやってだめならファンの音がうるさいデスクトップマシンにNetBSDをインストールするつもり。そっちでクロス環境できたらライブラリとかはコピってくればいいだけだから楽だし。邪道全然オッケーだし。
binutilsとgccの第一段階はこんな風にしてコンパイルできた。newlibも展開しておかないとだめ。あと、ライブラリ作るところで -lc が見つからないって言われるからlibgcc.mkから消した。いいのかどうかはまだわからん。
binutils:
$ /usr/src/binutils-2.15/configure --with-included-gettext --target=$target --host=$host --build=$build --prefix=$prefix -v
$ make > make.log 2>&1
gcc:(cコンパイラだけ）
$ /usr/src/gcc-3.4.1-1/configure --enable-languages=c,c++ --with-included-gettext --target=$target --host=$host --build=$build --with-newlib --with-headers=/usr/src/newlib-1.10.0/newlib/libc/include/ --prefix=$prefix -v
$ make LANGUAGES=c all-gcc > make2.log 2>&1
細かい手順はここを参照に。
http://www.sixnine.net/cygwin/translation/devel/cygwin-to-newlib-cross-howto.html
しかし、ツール作りはツライ。なんか主旨が変わってきそうになる。
■２月１２日 ＜続つらい＞■
出かけてたので日中は何もせず。クロス環境ができるまでほかの事する気にならない。でも、ちょっとめんどくさくなってきた。一応、NetBSDのファイル群をダウンロードしとこうかな。newlibのビルド。どうもおかしいのでconfigureから再度チェック。ん？もしかして、ターゲットって「powerpc-elf-netbsd」じゃなくて「powerpc-unknown-netbsdelf」が正解？arch-maker-osだもんな。*-elf-*ってーのはおかしいな？とは思ってたんだ。今日はもう遅いから明日初めっからやり直してみる。
■２月１３日 ＜続続つらい＞■
日中は板金折り曲げ機のブレードを作ったり曲げ加工について研究したりするべきなのに、クロス環境が気になってしまう。工作は外でやるから寒そうだってのもあるけど。powerpc-unknown-netbsdelfでやってみたけど、やっぱりnewlibは失敗する。やっぱりインクルードファイルに問題がありそうだ。
こんなページを見つけた。
http://netbsd.tale.net/ja/Documentation/cross/#terminology
これによるとBeBoxはpowerpc-netbsdでelf。BeBox用のバイナリーからライブラリー持ってこれないかな。その辺どうなんだろ？万策尽きたらやってみるか。このページによると、やっぱりインクルードファイルが問題らしい。newlibのビルドでやってるのを見ると、binutilsでコピーしたsys-includeを参照しているらしい。ここってnewlibからコピーしたんだからまずいよね。やっぱりここにNetBSDのソースに入ってるincludeファイルを入れるってのが正解のように思える。（昨日はこれをやっててきりがないからやめた。）そろそろデスクトップにNetBSD入れる準備を始めようかなぁ。。。。
がんばって板金折り曲げ機は完成させて、トライ。うまく曲がるけど９０度で止めるのは難しいな。これ、職人技だ。でも、ブレードは真ちゅうで十分ということが判った。ブレードもうまく削れたし、なんかいい感じ。残るはクロス環境。どうにもうまく行かないのでやっぱりNetBSDをインストールすることに。デスクトップＰＣのバックアップ用HDDに１ＧＢくらいスペースを作って、そこに入れることに。結局、ＣＤイメージからブータブルＣＤを作ってインストールしたんだけど、FreeBSDに比べてインストーラーが不親切過ぎっ。バックアップデータを２回もコピーしなおして、さらにそれは無駄だった。インストールが終わったからもう一回バックアップしなきゃ。今日、寝れるかなぁ。FreeBSDはインストーラだけじゃなくその後も不親切。ってか、FreeBSDやLinuxが親切なんだろうな。UNIXって本来こんなもんか？違うなぁ。これじゃこの時代生きていけないって気がするけど、フリーＯＳだから生きていけるんかな。ま、いいや。こっから先はどうするんかなーって思ってネット検索したらやっと見つかった。「NetBSDはさまざまなプラットフォームで利用できるように工夫されており、 FreeBSDのportsに相当する pkgsrcを利用すれば非常に用意にクロスコンパイラがインストールできる。」そうです。
http://www.tokuda.net/NetBSD/OBS/index-1.5V.html
がんばってpkgsrc.tgzを展開したけど、powerpc-netbsdは無かった。しかたないので昔のバージョンのパッケージを見つけてきてインストールした。あとはインクルードファイルとライブラリのビルドをすれば一応できたはず。できたのかなぁ。
板金曲げ木(^^ゞ 総檜作りなのだぁ。
初めての板金曲げ(^.^)
■２月１４日 ＜続俗族つらい＞■
眠いけど、昨日の続きでインクルードとライブラリを作る作業に着手。
ソースは全部要るみたい。src syssrc sharesrc gnussrcまで全部展開。ビルド用のスクリプトを作って、試行錯誤しながら進める。
make do-tools
buildppc.sh do-distrib-dirs
buildppc.sh includes
includesの前に足りないインクルードファイルのリンクを張らないとだめ。その後、色々あって、結局 arch/powerpc/include の中身を全部 mpc5200/includeにコピーすることになった。で、インクルードファイルはできたけど、csuのコンパイルでアセンブラがエラーを出したこけた。お手上げです。。（泣）冷静に考えると、アセンブラがエラーを出すのはコンパイラのせいかも。コンパイラとアセンブラの不整合か？パッケージでインストールしたのになぁ。やっぱり（泣）。
■２月１５日 ＜で、でけたぁ～＞■
試し曲げしたアルミ板を会社に持っていってエイスケに見せる。出来がいいのに驚いてくれた。うれしい。
アセンブラがエラーを出したらおしまいだなぁ。。 配布のpackageをインストールしたらシェアライブラリが入ってない。なんだこりゃ。一応、pkgsrcからbinutilsをインストールしなおして、再度挑戦するが、同じ結果に。csuをビルドする際に、crtbegin.cにある、「.hidden」についてエラーが出る。crtbegin.c .hiddenで検索すると同じエラーで悩んでる人がメーリングリストに投稿してる。英語だから良くわからんが、build.sh でbuild treeを構築しなさいとの答え。なら、同じことをってことで、同じことをしてみた。
# mkdir /usr/obj
# cd /usr/src
# ./build.sh -m macppc -T /usr/cross -D /usr/destdir tools
がんがん処理していくけど、風呂から上がったらエラーで止まってた。うまく行くと思ってログ取って無いからどこでエラー起こしたか判らん。もう一度やりなおしだ。どうやら、ライブラリは完成しているようなので、あとはもういいや。ライブラリとインクルードファイルを/usr/pkg/cross/powerpc-netbsd/配下にリンクして、
/usr/pkg/cross/binをパスに通して、完了。 動作確認で、Hello Worldを。
さて、実行ファイルらしきものができたのでこれをスピのCPUに送り込まなければならん。無線LANカードの設定もしてなかったので、設定して、ユーザー作って、telnetで入れるようにする。そしてそして、作った実行ファイルを転送。んで、実行。あ、そういえば転送したらパーミッションが変わってた。いいのかな？
helloworld
ほぉぉぉぉぉぉ、、、、でけたぁ～～～。スピのライブラリとのリンクとかまだやってみてないけど、とりあえずは実行できるファイルを作ることができました。寝れるぜ。
■２月１６日 ＜アイボ＞■
未納だったセンサーボードが来た。
モノは来たけど、ライブラリが無いから動作確認もできないんだよね。ライブラリはいつ来るのかな。クロスコンパイラがなんとかなったので、今日はアイボを進めたい。
アヒルちゃんに近づけるようになったけど、くわえられるような姿勢に移行するまでの手順っていうか仕組みがうまくまとまらない。イメージ的には、首を伸ばしても届かないから歩いて近づくという感じで動作を進行させたい。生き物っぽくていいと思う。あと、目標を見落とした時にフォローするのとか、姿勢情報を要求する仕組みとか、近づく時の歩行を連続歩行にして、歩行方向をシームレスに移行できるようにするとか、組み込まないといけないことや組み込みたいアイテムはいっぱいある。いっぱいありすぎてヤになるくらい。まとまらないからとりあえず、お風呂へ入る。
板金折り曲げ。補正するツールが要るね。構想はあるから今度の休日にでも工作するか。
お風呂で鼻歌を歌いながら考えた。やっぱり行動の基点は咥えに行った時に届くかどうかがポイント。本当に咥えに行くのは届くと確信してからで良い。問題はアヒルちゃん近くで姿勢を調整しているときに近づきすぎて見落とさないようにちょっと遠目になること。生き物的な行動じゃないもんね。
■２月１９日 ＜スピ上半身＞■
気持ちのバランスを取るためにスピーシーズの上半身を組み立てる。
サーボモーターのひとつにギアのいやな音がするやつがあったけど、ねじを緩めて締めなおしたら直った。直らなきゃ修理に出すとこだった。組み立てはまぁ順調。予想通りケーブリングがめんどくさそう。そういや、頭のパン角とチルト角が恐ろしいほどに範囲が小さい。頭の改造は先だなと思ってたけど、前倒ししなきゃならないかも。アイボみたいに２段チルトにしなきゃだめかな。自律動作させるにはキュリオもそうだけど、足元見れなきゃならないと思う。
ＣＮＣフライスの導入を予定していたけど、ちょっと考え中。用意する板金部品の数を考えるとフライスは割りに合わないかも。騒音問題も気になるし。難しめの部品を作ってみて精度をみてからかな。そうすると、オプティカルセンターポンチとセンタードリルは買わなきゃ。オプティカルセンターポンチは浅草ギ研さんで売ってた。12,000円。意外と高いなぁ。。迷ったけど、ポチッと決済ボタンを押しちゃった。そういや、フライス無いと肉抜きできないね。
結局スピは全身組み立ててしまった。思ったより簡単だし、上半身だけだと、配線ちょん切れそうだったから。ずぅ～っと同じ姿勢で居たから体が固まってしまった。背中が痛いぃ。
そういや、全身の画像撮ってないや。(*^。^*) ま、いいか。
相変わらず、アイボの行動制御の考えがまとまらない。スピの組み立てをしたり、ラムダの構造を考えたりしながらボケ～っと考え続けて、なんとか見えてきた。
アヒルを咥える行動。
①常に見つけた目標に口を持っていこうとする。ただし、届かないことが判れば足が動く。
①－①水平方向に届かないのであれば、歩く。近ければ微調整。
①－②上下方向は姿勢移行。上下は、高さ（一段目チルトの軸位置）と角度（一段目チルトの回転角度が足りない分を補償）するという感じ。
姿勢を正している最中はアヒルに届くか届かないかというエリアに来ているので首を伸ばしていると、近すぎてアヒルを見失う恐れがあるから首をすくめておきたい。これは、トラッキングの基本方針として、近づきすぎないという行動を組み込む。近づき過ぎるとロスとしやすいので。調整は一段目チルトの角度で行う。アヒルを咥えたら首を戻して歩行姿勢になるのだが、姿勢を調整する－咥える－首を戻す－姿勢を正すというのはシーケンスっぽい。シーケンス制御的なプログラムは作りたくないので、以下のような考えとすればどうか。
基本方針として、安定した姿勢をとろうとする。無理な姿勢は疲れる（バッテリー消費を早める）。（これは長時間立っていたら、座る→伏せる→寝ると移行する特性につながって行く）だが、目的があるときはこの限りではない。アヒルを咥えようとしている最中は安定した姿勢をとろうとする欲求は抑制されているためである。だが、ひとたび目的を達成したら、安定志向が復活し、安定した姿勢へと移行する。アヒルを咥え損ねた時のフォローはこれとは異なる。目的を達していないわけだからまだ安定志向へと移行しない。ここでは目標の最終捕捉座標を元に、トラッキング方針の基、捕捉しやすい姿勢・位置へと移行するために首をすくめ、姿勢を移行させる行動をとる。
こんな感じかなー。これをプログラム化してみようと思う。こういった方法は一見めんどくさくって遠回りっぽいが、まとまれば細かな行動は自動的にとってくれる。姿勢を正す行動をあらかじめ組み込んでおくことで、咥える行動をプログラムするだけで、後始末は自動発生するのだ。
■２月２０日■
昨日組み立てたスピ。
胴体サーボからのケーブルがどうも短い。長いのに交換するのには相当分解しなきゃならん。そういや、３ＤＣＡＤのデータが実物と違ってたところがあるから取り出して寸法取り、データ修正。本日のノルマは板金折り曲げ補正機の作成。折り曲げ機へのアダプターだけど、どうも曲げ角度がうまくいかないので補正は必須かなと。ちょこちょこっと作って試してみた。補正用ブレードの厚みが３ミリではちょっと厳しいようだけど、なんとか補正はできそう。ブレードの厚みは５ミリくらいがよさそう。今度アキバに行った時、材料調達だな。
今日もアイボを頑張る。ロボットのプログラムは運動制御と行動制御の２本柱。アイボは４足歩行なので安定した動作が期待できるので行動制御に活用していくつもりなのだ。
近づいたところで止まりたいんだけど、止まった時にはアヒルはアイボの顔の下。電灯の光は天井からだから影になってしまって見失ってしまう。近づく毎に姿勢を低くしたりしてできるだけ横から近づくというアイディアはあるけど、どうも自然じゃない。方針的にイヤだ。今はカメラの座標・姿勢、胴体の姿勢からアヒルの位置を計算してるけど、カメラとアヒルの位置関係も監視しなきゃダメかなー。トラッキングの間は、カメラとアヒル（目標物）の距離ができるだけ大きくなるように動くようにしよう。手段は①第一チルトを大きく（第一チルトは角度が大きい時は「前後」の意味合い、角度が小さいと「上下」の意味合い）。②前傾姿勢を取る様にする。前傾になった上に第一チルトを大きくすれば、アヒルとの仰角が大きくなるはず。③近づくのを止める。「行動抑制」の仕組みを組み込んで、これ以上近づくのを止める。
③はどこかで必要となる仕組みだけど、解除の仕組みや抑制拒否とか、色々ルールが要りそう。とりあえずは行動管理構造体に変数だけは作っておこう。
アイボで悩むのも飽きてきたんで、スピの動作確認を。肩と膝のサーボの取り付け角度が間違ってたりしてちょっとあせったけど、動き出した。でも、なんか歩行不安定だな。調整すれば歩けるのかな？どうせ歩行エンジンは使わないけど、ちょっと気になるね。コントロールソフトでは頭のサーボの動作確認ができなかったので、モーションエディターもインストールして確認。ま、一応動きました。このサーボでトラッキングってできるのかな？動きがぎこちない。ここも改良かな。あと、スピーカーがノイジー。ジジ、ジジって言ってる。 確認が終わってないのはＬＥＤ、マイク、スピーカー、ジャイロ、加速度センサー。あ、手首のサーボを回してみてないな。ま、いいか、大丈夫そうだし。それにしても、あっちゅう間にバッテリー無くなる。立ってるのって大変だろうけど、アイボって凄いなと改めて思う。１時間半も動いてるんだもんな。スピの体重は3.5キログラムあるから、パワー的にはこんなもんかなー。
■２月２１日■
完全にラムダ検討デー。
ココロのどこかにアイボは残っているが、昨日の夜から始まったラムダの身長およびプロポーションについての検討が気持ちを支配しちゃってるので、突っ走っちゃおう。バッテリーやＣＰＵモジュールを３Ｄデータ化して、配置。腕の検討。で、随分とラムダが見えてきた。なんだかうれしい。っていうか、もうラムダ詳細設計・製作に入れる材料は揃ったのでもうはじめなきゃね。
■２月２２日■
不意に思い出した。
設計に使ってる３ＤＣＡＤは図脳ＲＡＰＩＤ３ＤというＣＡＤで、機能はしょぼいけど、安いっていうシロモノ。使い込むたびにしょぼさが目に付いてしまうのだが、３ＤＣＡＤは高いので我慢しなきゃならんかなーとも考えてた。その試用期間が今週中に切れる。さて、決断しなきゃ設計が止まっちゃう。結局、こいつのしょぼさと、インベンターのすばらしさから、インベンター採用の線で落ち着きそう。せっかく構想がまとまって突っ走るところだったけど、ここでＣＡＤが変わって失速しなきゃいいのだが。
オプティカルセンターポンチが届いた。よさげなのだが、これ、12,000円は高いよね。たとえ威力がモノすごくっても。。。あとはセンタードリルと、折り曲げ角補正用の材料を買いに行かなきゃな。そのうちでいいか。まだ設計終わってないし。昨日、なんかよさげーって言ってた腕と足と胴体部分をつなげてみた。ぅんっ、よさげだっ。これで進めよう。足だけとか下半身までとか言ってたけど、全身設計して、作っちゃいたい気分になってきた。
早く作って早く歩かせたいぜ。
■２月２３日■
眠い。。最近、何もしないでも遅くまで起きてるので眠い。深夜になると目が覚めてくるんだけどね。
センサー関連のライブラリーがリリースされて、すべてのデバイスを動作させることができるようになった。会社でメールを受け取って、「今日はセンサーボードからデータを取得するプログラムを書こう。」と思って返ってきたが、いざ帰って来るとなかなかやる気にならない。とりあえず、こないだ動作確認をしていなかったマイクとスピーカーの動作確認をしようか。デバイスだからリダイレクトでデータを入出力すれば、簡単に・・・あれ？ザーッとしか言わないぞっって、マイクがダイナミックマイクだから電源が要るのね。電源を入れたらマイクから録音。スピーカーから再生できました。意外と綺麗に音が拾える。よかった。でも、このデバイスからのデータってどういうフォーマットなの？えと、生データか。フタバの６０１ＣＲはコマンド形式のサーボモータなんだけど、これって同期動作ってできないんだな。数個程度なら事実上の同期ずれはないのだろうけど、１２７個つないだとしたら１個目と１２７個目の動作開始時間が異なるはず。データ受信して待機、一斉連絡で動作開始ってコマンドが無いのかな。有るべきだと思うけどなぁ。レベル２のライブラリ関数を見る限り無いみたい。
メカ設計に関してはインベンターが来るまではやる気しない。妄想だけで済ませとこう。
■２月２４日■
UNIXでのインターバル処理はインターバルシグナルを使えば出来そう。（って、前にも書いたか。）OSはマルチスレッドではないのでマルチプロセスとしたほうが考えやすいだろう。
方針としては
メインプログラムがフォークし、子プロセスにてそれぞれ処理を実行。
メインプロセスはスケジューリングだけを行う。（時間を守るため）
考えられる子プロセスは
A)サーボ制御 身体制御全てを行う。よってジャイロ・Gセンサーデータ・関節角度データもここで取り扱う。
B)画像処理 カメラからのデータ取得と認識処理。行動制御もとりあえずはここか。
C)音声認識処理 更に子プロセスを作って、マイクからのデータを常時受信する必要がある。
D）発話処理（LED表示なども含む） 合成・発話それぞれに実時間がかかる。
音節ごとにパケット化して発話するなどの工夫くらいが必要になるだろう。
フォークとかパイプとかシグナルとかUNIXプログラミングを駆使しなければならない。OPEN-Rをやり始めたころを思い出す。懐かしいなぁ。つらくなければいいのだが。
サーボモータの制御を考える。どう考えても同期動作できないと思う。角度データ・移動時間データをセット。一斉通知で動作開始っていうコマンドがいると思う。とりあえず、足一本、手一本分の動作だけ考えたら誤差は考えなくてもいいくらいだとは思うが。ジャイロのデータって角速度データ。レートジャイロ。姿勢じゃなくて、振動抑制にならそのまま使えるけど、積分して姿勢データにしようと思うと、休まずにデータ取得し続ける必要がある。オフセットもでるだろうから管理難しそう。
アイボでやろうと思っていた関節制御なんだが、足先座標を制御しようと思っても、単に目標値を与えるだけでは周波数応答に相当する位相遅れで実際には目的の座標位置へは至らない。限界はあるのだが、各関節が目標どおりの時間に目標角度を通過するためには遅れを見越した角度指示が必要と言うことになる。歩行モーションで考えると歩行パターン毎に補正値が変わってくることになるがそれではあまりにもローテクなので、加速度毎及び負荷をパラメータとした関数を学習して適用する。ある程度目標に近い動作が出来れば安定度の補正もやりやすくなるのではないかなぁ。
今日はスピーシーズのライブラリをリンクしてハードウェアを操作する簡単なプログラムを書いてみる。アーカイブ展開するとサンプルプログラムみたいなのがある。まずはこれをコンパイルしてみるか。Makefileがついてたけど、コンパイラが違うのでマニュアルで。。
powerpc-netbsd-gcc -D_SPSDEV_LEVEL2 -D_SPSDEV_LEVEL3 -L../lib -I../include robo_main.c -lm -lspslv2
ってやって、転送。
これって、ロボットコントロールプログラムのメインルーチンのスケルトンなのね。ＣＰＵユニットのＬＥＤがチカチカして、Ｂスイッチを押すと終了するってものでした。
明日はジャイロと通信してみます。（今日やるつもりだったんだけど。）
■２月２５日■
アイボの行動制御が行き詰っている。膠着状態を打開するためにも、問題の内容を整理してみる。
・目標に近づいて行った時、自分の影で見失ってしまう。アプローチ到達距離を設定しても移動単位が１歩なのであまりうまく機能しない。
・咥える動作開始直前の姿勢、どうやら首から上だけの動きでは目標を見失わない状態を確保できなさそう。
・首を伸ばしつつ、口を開け、目標位置についたら口を閉じる。という一連の動作を美しく記述できない。（シーケンス的記述はしたくない。）
動作の流れはこうだ。
情報の根源は視覚なので常に目標を捕捉していたい。ところが、口は目より後ろについているので咥える時に目標を捉える事は物理的に不可能。仕方ないのでできるだけ寄って、あとは目測でぱくっと行く。目測は補正ができないからできるだけ確実な動きとするためには少ない関節の動きで済ませたい。あるところまで近づくと目標を見失ってしまう点がある。これが近づける限界位置（接近臨界点とでもいうのかな？）この位置は光源の位置によって差があるが、概ね、アイボ自身の頭が目標物の真上付近に来ると見失ってしまうと考えられる。（つまり概ね光源は天井にあるということ）この位置からできるだけ確実な手段で口が目標に届く位置へ姿勢及び胴体移動をしなければならない。目標を見失った時のリカバー動作を繰り返すことにより、接近臨界点（の１つ）を見つける。そこから首関節の移動だけで口を目標へもっていけるかを確認し、不可能な場合は胴体移動を併用する。胴体の移動手段としては歩行があるが、歩行は位置再現性が低いのでこの場合には使えない。姿勢移行を利用した体運びを行うことで、胴体を移動（及び姿勢移行）させる。目標を視認しながらの動作ではない首の動き・胴体移動・顎の動きは、オープン制御である。唯一顎の動きはうまく咥えられたかどうかを認識することが出来る。
この中でも、「目測で」とか、「胴体移動」とかは「工夫」の賜物だ。本来、ロボット自身が試行の上に発見するのが理想だけど、現状ではちょっと無理。既知のものとして取り扱う。
まず、動作単位は徹底して単動作とする。その上で後引き処理を徹底する。
具体的には
○咥える →条件→ 口が開いている →リクエスト→ 口を開ける
→条件→ 目標位置に口がある →リクエスト→ 目標位置まで口を近づける（アタマ）
○口を近づける →条件→ 目標が可動範囲である →リクエスト→ 胴体位置を近づける
見失った場合のリカバー動作を組み込む。条件を与えて、条件に合致する物体を捜索しなければならない。接近のリトライは前回の状況を加味した動作を取るようにできないか。
【コラム】シーケンス制御 ～～～
ロボットの制御を考える時、シーケンスによる制御方法はとるべきではないと思っている。シーケンスはいわゆる手順。手順とは経験を積んで、先を知ったうえで、効率的に間違いなく事を行うために取る知的工夫の結果だと思う。知的と言う割りにはそれ自体に知的な部分はなく、実行者にはスキルや思考を要求しない。
ロボットそれ自体は知的生産物だとは思うが、目的は上記の「手順」で事を済ませるような便利物ではないはず。（便利物：ソロバンとか） 低レベルの制御部分にシーケンスが含まれるのは問題ないが、行動制御や、できれば運動制御についてもシーケンスとは違ったアプローチがされるべきだと思う。とはいえ、「行動」レベルでは結果として手順を踏まなければならないのは明白であるから、なんらかの方法で「結果的に正しい手順」を生成しなければならない。今回あいぼで考えている行動制御は「後引き」方式。後引きは計画性の無い生産方式なのでアプローチとしては、まぁよいかなと。
やりたい方法としては、後引き方式の改良型。後引き公募式。
ある動作の条件が整っていない時、それを整えてくれるジョブを公募する。「咥える」ジョブは「口が開いてないぃ～」「口の位置が違う～」と叫ぶ。「誰か口を開けて～」と言ってもよい。「口を開く」ジョブは立候補し、口を開ける。公募案件は「口開く」ジョブに引き継がれ、完了を「咥える」ジョブに通達する。今でも出来そうだけど。。 これがいいのは各ジョブ間の連携をプログラムしなくていいところ。ジョブの会話フォーマットと要求事項を取り決めておけば、新たなジョブを投入するだけで働いてくれる。衝突や最適化など学習要素を同処理するかなど面白そうな課題もある。
～～～～
とにかく、目標を見失わずに近寄っていき、トラッキングしたままで立ち止まるということができなければ話にならない。歩いて近寄るのは限界があるので、姿勢移行での接近を確立し、どれくらい手前で立ち止まれば良いかが算出できる状況を作る必要がある。あとリカバリーができなけばならない。
姿勢移行での接近は２回の姿勢移行で成る。
第一段階は準備段階として、姿勢を低くとり、移動距離に応じて前足を手前に出すような姿勢になる。
後ろ足は関節付近まで近寄らせておく。
第二段階として、スタンスを変更せずに胴体をスライドさせる形で胴体移動を行う。今度は後ろ足が後ろ側に伸びた形となるため、前傾姿勢をとるのには不利な形になる。接近後の姿勢によって接近できる距離が変わってくる。
移動距離と移動後の姿勢を引数として、姿勢移行パラメータを返す関数を用意する。
最近のサーボ事情では２０㎏・㎝というトルクは高トルクといえなくなってきているみたい。
鉄人プロジェクト「http://aitech.ac.jp/~furuhasi/robo/」の比較表によると、双葉の601RSはでかくて弱くて重くて高価。いいとこなし。重いのが致命的なんだよねー。電圧をもうちょっと上げればトルクは増すからトルク不足を感じたら電圧上げるしかないかな。あと、センサー情報が要らないサーボにはＰＷＭサーボを使えるようにしないとまずいかな。そうすると６０１の買い増しはないかも。ＤＸシリーズは小さくて強いけど、遅くてすごく高価。耐久性があるようなら膝だけでもＤＸにしてもいいかと思ったけど電圧が違うからダメかな。まぁ大枚はたいて買っちゃったからなんとか使いこなさないとね。動かしてみた感じは普通のサーボより高級感のある動きをしてる（どんなんだ？）ジジジジいわないのはいいね。
PWM制御ができるちっさなマイコンにRS485を組み込んでみることを考えないと。
■２月２６日■
昨日、センサーボードの受信をしてみたが、うまくいかない。いかない。いかない。 で、朝方諦めて、寝た。今日は朝から予定がいっぱいだったけど、サーボを動かしてみるところからやってみた。サーボはすぐ動いたんだけど、サーボからの情報も来ない。来ない。来ない。。。
板金曲げ補正機の材料を買いに行く予定だったからとりあえず頭を冷やそうと思って出かけた。
帰って続きをやったけど、どうにもうまく行かない。業を煮やして、RS485で直接受信するプログラムを書いたら、タイムアウトを長く取ることでうまく受信できた。なんだかなぁ。どうなってるんだろう。ライブラリ関数の使い方がおかしいのかなー。とりあえずこれじゃ話にならないからスピーシーズにメールしようっと。
受信に成功したサーボからのデータ。コメントつけて内容確認してみた。
fd df // header
15 // ID(21)
00 // flg
00 // adr
1e // len(30)
01 // fix
10 60 //モデルナンバー
03 //バージョン
00 //reserved
15 //ID
07 // ボーレート
12 // リターンディレイ
ce 04 // 右回転リミット角度(1230)
32 fb // 左回転リミット角度(-1230)
30 01 // 負荷リミット(304) default(240)
00 00 // 温度リミット(0) default(925)
64 // 最大トルク(100)
00 //加減速時間
01 //コンプライアンスマージン
01 //
00 //コンプライアンススロープ
00 //
ff 00 // パンチ
00 00 00 00 00 00 00
d0 // sum
fe ef // footer
ヘッダーなども入れて40byte。受信データ数を指定して受信しなきゃならない関数なのに、ライブラリ関数はデータ数の確認もしない、ヘッダーも確認しない、もちろんチェックサムも確認しない。なんなんだろーな。このライブラリは。
オプティカルセンターポンチも買ったし、あとは穴精度上げるためにセンタードリルを買おう。板金折り曲げ角度補正には刃厚が3ミリじゃ足りないからもっと分厚くしなくちゃと言うことで買出しに行った。が、しかし、秋葉原にはセンタードリルが売ってなかった。ネットで買うことに。CNCフライスの導入を見送ったから、でか径の穴が開かないんだよね。とりあえずは大腿付け根の直交ユニット部にベアリングを取り付けるためにφ１２をあけなきゃならない。φ１２のドリルが2400円くらいする。うーん。。。高いけど要るしね。ホールソーの方が安いけど、精度はドリルの方がありそうだし。ドリルを買うかなぁ～、設計が終わってからね。
スピについてたベアリングを流用するんだけど、直交軸両方ともその構造にするかどうかは悩みどころ、ベアリングの値段とか軸構造とかの兼ね合いで。スピはアルミホーンを裏返しに使ってうまいことやってる。これをいただこうかな。ベアリングはシムとセットで2個で2000円。あ、これならいいや。じゃ、φ１２も決定だね。今度行った時買うことにしよう。
■２月２７日■
タイムアウトの設定が40000。単位が判らんけど、たぶんμsだろう。すると、0.04秒。モーター一個のデータ取得で0.04秒ってなにっ！？ ２５個で1秒。泣きたくなる。実際に試すと、1秒かかる。サーボの通信速度はデフォルトで115200bps。1.3Mbpsまで設定できるけど、CPUの方がどこまでいけるかわからんから、安心なとこで、460,800bps。センサーボードの上限もこれだから。これで早くなるかな？って、全然変わらない。これはどうも、なんかのバグだなー。ライブラリのバグならいいんだけど、デバイスドライバーがおかしいんなら致命的。
もともとやりたかったセンサーボードのデータ取得をやってみる。できるんだけど、８０回きっかりであとは通信放棄。動作からすると、CPU側が放棄してるように見える。バッファをフラッシュしても、ポートをオープンしなおしても、状況は変わらない。たぶん、デバイスイニシャライズからやりなおせば直るかも。
どうにも話しにならないのでスピーシーズに連絡を入れることにする。
バグだとして、直ったとしても、この様子だと関節角度データの取得周期は50msくらいはかかりそう。アイボは8msなのにえらい差だ。アイボよりずっと難しいことをしなくちゃならないのにこれではまずいので二の矢を考える事にする。１チップマイコンにてRS485をインプリメントし、RS485を6チャンネルくらいつなぐ。。通信速度は最低でも、691,200bps。1,382,400bpsを目標にする。タイマーにうまく組めば6チャンネルくらいは平行処理できるだろう。691200bpsで通信できれば、1モーター当たりのデータ取得時間は1ms。チャンネル当たり5～6モーター見たとして、8～10ms毎のデータ取得が可能と思われる。取得したデータは（1モータ当たり2byteで、25モータとして、50byte)ある程度まとめてメインCPUに転送。3～4回分まとめると、150～200byteか。460800で転送して、40msくらい。ジャイロのフィードバックをどうやってかけるかな。リアルタイムにかけるなら、30msでフィードバックか、1チップマイコンでフィードバック。メインCPUでは画像処理と音声認識・音声合成・行動制御。悪くないかも。この構成、インテリサーボじゃなくてもいいってとこが悲しい。
板金折り曲げ補正アダプタの製作。オブティカルセンターポンチを初めて使ってみる。すっごく気を使ってケガキを入れて一生懸命ポンチを打ってやってみた。Ｍ３ねじ用の穴をφ3.0で明けて、３㎜厚のアルミと真ちゅうがほぼばっちり穴が合った。きもちいーーー。アルミ板の穴が一箇所だけちょいずれてて、φ3.2にしたら合った。言うことナシ。どんどん職人になっていく。
曲げ補正も前のとは比べ物にならないくらい簡単に補正が可能。補強リブ曲げみたいな短い曲げだと使えないけど、リブ曲げは補正しなくってもいいよね。
RS485のドライバーやライブラリがどうあれ、１チップマイコンに485インプリの話は進める必要があると判断して、ベストテクノロジーでATmega32のボードを注文。って、いまどき注文書を送らなきゃいけないのね。ジャパンネットバンクなんだけど、振込み通知書じゃなくて振り込み予約のメールでいいかな？MAX485も6個ほど注文。ちっこいけど送料は1,000円。なんか他に買うもの無いかなーって思ったけどない。いいや。買っちゃえ。あと、秋葉原で見つけられなかったセンタードリルも1.0と1.5のを買う。ついでに作業用ゴーグルも。
通販で1万円ほどお買い物。うち送料が2500円くらい。でかいなぁ。アキバで全部そろえばいいんだけど、売ってないからしかたない。買いに行く時間と交通費を考えると安いもんかな。そう思わなきゃ。あと、支払いがカードでできればもっといいのに。それにしても、ベステクの注文は振込み後に注文となってる。なんか、売り手がえらそうだ。納期も2週間だって。なんだかなー。結局、ツクモでカード払いで買えることが判ったからそっちで。もしかして、王国に行った時に買えたのか？
■２月２８日■
考える程に、アペリオスがどれほどよく考えられているかが判る。アペリオス（というかアイボのハードウェア）がオープンになればどれほどよいかと思う。しかたが無いから、有る材料で似たようなことを考えなければならないが、オーバーヘッドが大きくなるなぁ。
サブCPUを使った分業を行うとデータ転送のための時間がどうしても必要。それをどのようにカバーするかがひとつの課題。メインで詳細な関節角度データが得られないのであれば、サブCPUでそれを行うしかない。集計して送り出すだけの作業なので、１つのCPUでどれぐらいの面倒が見れるかを考える。今考えているマイコンは16MHzRISC。複数のRS485を使って、数チャンネルからサーボに対して角度データを取得し続ける。メインCPUからの要求に対して、数パケット分のデータをまとめて送出するということを考える。角度データ送信はできればメインから直接行いたいところだが、そうも行かないのでサブが複数サーボ分の角度列を受け取って転送。RS485は半二重だから関節角度送信時は関節データ受信は出来ない。このあたりはタイミングの調整でなんとかするしかないな。
RS485の受信があれで正しいのであれば論外なのだが、正常になったとしたらどうなるのか。460800bpsで転送したとして、１サーボ当たり500bitの転送時間に1.1ms。25個分として、27ms。データ取得周期は最短で30msくらいか。その上、逐次処理なのだから、1個目のデータと25個目のデータの取得タイミングはほぼ30msずれていることになる。グローバルフェッチコマンドが無い限り、話にならないな。分解能も30msだし。
では、サブCPUにRS485を複数実装し、複数チャンネルで分業した場合はどうか。１サーボ当たり500bitの転送時間に1.1ms。6個分として、6.6ms。分解能は8msを確保できそう。で、メイン側へは25個分のデータを転送するのだが、4フレーム分として、200byte。460800bpsで転送したとして、2000bitだから、4.4ms。これでアイボ並み。フェッチコマンドが無いとしても6.6msのずれなら許容できるかな。6個というのは足1本6自由度から来ている。では足1本の中でのフェッチタイミングのずれが6.6msというのはどういう意味か。足の長さが30㎝で、歩幅10㎝で歩いたとする。1歩が大体、0.25秒とすれば、付け根サーボの移動角度は約9.5度。250msで9.5度だから、6.6msだと、0.25度。足先での距離にすると、1ｍｍ程度だ。無視してよさそう。一応、根元側のサーボから処理するようにすればよいかな。
＃先端で1ミリなら、分解能をもう少し長くしてもいいかも。15msくらいまで伸ばせばずいぶんと処理は楽になる。動作として同期をあまり考えなくてもいいのはグリップ（掴みと手首回転）くらいか。 すると、
第１グループ：左足
第２グループ：右足
第３グループ：左手＋胴体＋第一チルト
第４グループ：右手＋センサー
第６グループ：メインＣＰＵと交信
別ＣＰＵ：両手グリップ＋手首
かな。
次にサブＣＰＵ側での作業を検討。RS485のビットレートでタイマー割り込み。サーボ用のポートは8ms（または16ms）周期で、角度データ送信コマンドを送出して、受信を行う。担当サーボ分おこなって待機。受信データは所定のメモリー（リングバッファ状になっている）にストア。CPUのポートは受信で待機。CPUからの送信があると、受信して、コマンド解析。
コマンドに従って処理する。
・目標角度データ受信→各サーボに転送
・角度データ送出要請→バッファのデータを送り返す
・処理開始→開始
・処理停止→停止
など。厳しいかも。何ポート実装できるかなー。処理時間に余裕があれば、トルクなどもバッファしたいな。スルーモードも必要か？（欲張り厳禁だぁ～。）
サブＣＰＵの案として、上半身、下半身分離とか、左半身、右半身分離とかが考えられる。上下分割のがいいかな。分割した場合はサブＣＰＵ同士の同期が要りそう。これはハンドシェークでもなんでもいい。1ビットあればできるのでは。メインから、グローバルで指令すれば済むか。後は個別にデータの取得要請すれば。あ、これだと、ジャイロセンサー値のフィードバックはメイン経由だ。早くて32ms後か。効かないかも。
サーボがインテリになるのはまぁ賛成だけど、今のコマンド型サーボって全然足りないな。サーボ間の協調みたいなのができるようになって初めて活きてくるんだろうな。まずは一斉動作と、データフェッチタイミングなどのグローバルコマンドが最低限必要。あとはコマンド列を処理できないと。到達通知も欲しいけど、RS485を使ってるうちはできなさそう。
頭部のサーボは、しょぼいRCサーボだけど、物体認識・位置把握のための大事な部分。601並の精度は欲しいけど、601は重くて（高くて）使えない。角度データを戻せるRCサーボを使うか？ポテンショメータつけてADCで読むか？身体データと合わせて使う必要があるからやっぱり同期は必要かなぁ。大変だ。2本足で立ってるわけだから、4本足の時より位置精度は出ないはず。すると大体の座標として扱うしかないかも。ジャイロのデータと合わせたら補正できるかなー、それこそ同期してなきゃ意味無いね。
帰るとスピからメールが届いてた。ライセンスキーがうまく働いてなかったとか。代替のライブラリーが届いてた。差し替えたらばっちり動いた。各通信関数にタイムアウトが指定できるようになった。センサーボードのデータ取得にかかる時間は4ms～5msくらい。まぁ、まともな線だな。問題は関節角度の取得タイミング。一斉取得命令は無い模様。順次取得だと、やっぱり結構な時間がかかる。25個で、100msくらい。目標はサブCPU使って分解能8msだなー。
■３月１日■
インベンターが届く。（センタードリルとかICとかも届いたけど）インストールする。すごいね。普通のソリッドCADに、ケーブル・シートメタル・解析までついてこの値段は安い。サーフィス（とか、自由曲面）が弱いみたいだけど、どうなんかな？操作はI-deasにそっくり、エンジンかフロントエンドが一緒なのかもしれない。ってことで、会社で使ってるOSDよりは難しい。ちゃんとチュートリアルやっておかないと能力半減かもな。さっそく、図脳RAPIDで作った部品データをIGES経由でインポートしてみる。サーフィス欠落してソリッドにならない。で、補正する方法わからん。やっぱ一から入れなおし？その方が早いかもね。
コマンド型サーボの未来を考える。ロボットへの活用を考えると、コマンド型のメリットってなんなのかな？ロボット制御って枠で考えるとリアルタイム処理は避けられない。それは外界のフィードバックを必要とするから。外界の状況が変わらないということは産業用ロボット。ここでオープンループ制御でかまわないインテリジェントなサーボを入れるということはもしかして意味がないかも。制御しないとイコール脱力って感じの方が自然なのかもしれない。命令が無いからずーっとトルクがかかりっぱなしってのはインテリジェントだとはいえないもんね。コンタクトが途切れたら、徐々に脱力とか。そういうイメージのインテリジェンシーが欲しい。サーボ単位での処理って脊髄反射または小脳的な処理を思い浮かべる。まだそんな段階じゃないかな。
■３月４日■
ウィークデーも、この土日もインベンターにかかりっきり。やはり、初めはチュートリアルからやらないとそのCADの実力を発揮できない。早速チュートリアルをやってみる。「被拘束駆動型」（だったと思う）と、なってるけど、どうなんだろうなぁ。いいのかな。正直設計しにくい。何度かの入れ直しの末に、サーボユニットのモデルが出来上がったのが、金曜日くらい。それを基に土日は構造設計に取り掛かる。
■３月５日■
ＣＡＤの操作もなんとかなってきたので板金ブラケットの設計に取り掛かる。なんか使い慣れないから思うように作業が進まない。ＣＡＤの思想は、「まず形を作って、その寸法を拘束しないでおくことで、（配置とかの）条件を与えていって形がフィックスする」って感じなんだけど、それってなんかおかしいと思う。少なくとも今やりたいのはサーボユニットは固定、配置も既に決まっている。で、考えたいのは「形」なんだよね。形を試行錯誤したい。どうも「そういうやり方をしたい時」の手段は考えられてないらしい。結構狭いね。Ｉ－ｄｅａｓはもっと柔軟だったな。
結局、サーボ同士を仮のリンク部品でつないでおいて位置を決定し、その状態で部品を設計してつないでいくという手法で進めることにした。足首は構想がまとまった。悩んで考えた直交配置になってるんだけど、ブラケットがすごく複雑。でも結構お気に入りの配置になった。全体の重量を抑えることは大事だけど、抑えなきゃいけないのは腰から上の構造。腰から下は軽さより剛性が重要。
構造も決まって、さて、ミラー部品を作成・・と思ったらできない。ＣＡＤが落ちちゃう。なにぃ～！こんな簡単な構造で落ちるのかぁ？使えねー。しばらく悩んでパッチがあたってなかったことに気づく。サービスパック２まで当てたら落ちなくなった。つーか、ミラーも出来ないのをリリースしたんだよね？信じられない。段々とＣＡＤのくせもわかってきて順調に進んでいく。関節をくりくりと動かしながら検討を進めるのってなかなかいいなぁ～って思ってたら、なんか関節が動かないっ。うぅぅぅん・・・。おかしい。ってとこで今日は終わり。
■３月６日■
昨日に続いて構造設計。昨日は動かなくなって終わった。なんだかやだなぁと思いながらも続きを、、やっぱり動かない。なーんとなく、被拘束寸法を決定するための「アダプティブ」が怪しいような気がするのでどんどんと解除していく。やたらと解除していくと「寸法が決定できない」ってエラーが出る。暗くて深いラビリンスに迷い込んだかなぁ。もしかして一からやりなおし？とか思ったけど、新しいアセンブリファイルで部品を構築していってみると、ちゃんと動く。アダプティブって使えるような使えないような。大体原因はわかってきたからそれはおいといて、設計を進めることにする。
股関節は直交ブロックになっていて独立してるからいままでの経験を使って効率よく作っちゃおうってやってみた。途中でやっぱりアダプティブのせいで不本意に動いてしまった穴位置以外はまぁ順調。位置が決まった時点でアダプティブは切断するようにしないとね。直交ブロックの強度が足りない気がするけど、細かいのは後回しにして足の（ほぼ）完成をこの休日の目標にしよう。先に進める。
膝まではなんとか納得行く形で出来た。股関節の直交ブロックもまぁ、出来た。しかし、最後の足部品。膝のロールサーボの部分で、問題発生。かっこ悪い。なんか致命的。このまま進める気が起きないので大いに悩んでみる。
横にして奥行き側にオフセットをつけると可動範囲がべらぼうに大きくなっていいんだよね。サーボの可動範囲超えるくらい。でもかっこ悪いから縦に配置してみる。更に、膝は逆関節不能にするつもりなのでモーターが膝パットになる感じで配置してみる。ん～この形でいいかなー。でも、縦配置だと、細くなるけど厚みが出るから関節の可動範囲がすんごく狭くなる。歩くだけならこれでも良さそうなんだが、折り畳めるってが気に入ってしまった。膝が胸につくような形じゃないとなんだかイヤになってきた。もうちょっと悩む。
土日はCADに釘付けでした。風邪っぽかったからちょうどよかったかも。できれば板金部品作成までやってみたかったけど、寒そうだからそれはまた今度。
■３月７日■
膝ロール、更に悩んでみる。ロール角の可動範囲も確保しなきゃならない。股関節の可動範囲は確保したいので奥行きオフセットはつける。ので、縦配置はボツ。結局、元の案からサーボをさかさまにした配置で落ち着いた。サーボのモーター部が膝サーボの欠けた部分にはまりこんでいい感じ。後ろへの可動範囲を狭くして、大腿部を短くした。膝下と大腿が大体１００㎜ずつくらい。なんか気に入ったなぁ～、この配置。悩んだ分だけ納得がいく形になっていくね。
仕事で簡単な強度解析をしたくって（I-deasのライセンスサーバーがおかしくてI-deasが動かないので）会社で使っている三次元ＣＡＤ（ＯＳＤ）で作ったIGESファイルをインベンターに読み込ませてみた。ちゃんとソリッドモデルになるね。やっぱ図脳RAPIDが悪かったのかな。ちなみにそれだと構造解析できなかったから結局インベンターで作り直して強度解析した。
■３月８日■
膝ロールが解決したので大体足はまとまってきた。
ここで全体像を見ようとおもって脚だけだけど、ミラーで両足にしてイメージ確認。うっ、股関節の直交ブロックがでかすぎ。オムツしてるみたいだ。気に入らないのでここを考え直すことにする。骨盤部分の板金構造がちょっと複雑になるけど、いい構造をみつけた。股関節のヨー・ピッチの連結は随分と簡単な構造になって、これならいいかな。大腿部のブラケットもいい感じ。曲がってる部分を違和感無くおさめるためにＲを多様した形にして・・ってこれじゃ補強用のリブが入らないやん。ブラケットだけは直線形状で作り直し。
■３月９日■
一日出張なので、移動時間や空き時間に検討しようとＰＣを持って出かけた。すげー重い。
なんか、検討してるのかＣＡＤに遊ばれてるのか段々わからなくなってきた。そうはいいつつもちょっとずつは進んでる。ブラケットにリブ立てて、足は完成。細かいところにまだ変更がいるけど、基本構造はこれで行こう。サーボが生きている時はコンプライアンスで角度が行き過ぎたりしないようにできるけど、電源が入ってない時のことを考えて角度限界ではフレーム同士がぶつかるようにしたい。ガッツガッツとサーボケースに負荷かけると歪んじゃうから。
世間からは随分と遅れて２足歩行をやりだすからには今までと同じのを作っては意味がない。ラムダの歩行制御は人間に近い形での制御をしたいと考えている。スピーシーズで聞いた話で、膝サーボの負荷が高くて発熱するってのがあったのだけど、人間も膝を曲げて体を支えるとすごく負荷が高い。スクワットとかキツイし。つまりは人が歩く時は膝をあんまり使ってないってことだ。起立して立ってる時も、膝はちょっと逆関節気味になってて骨の上に骨が乗ってる感じにしてる。こういったあたりを取り入れたいと思ってる。歩行に関しては、今流通してる歩行は、舞踊の「能」での歩行に近い感じ。腰を落として上体が水平に移動していくように歩く。ちなみに「能」だと左右もぶれない。人が実際に歩く時には勢いに乗って歩く。勢いっていうのはこの場合はモーメント。設置している足先を中心として体全体の重心点が回転動作をしながら進んでいる。けり足は、倒れこもうする重心点を前に押し出す事により、倒れる事を先送りするように動く。人工衛星が墜落しないで済んでいるのに近い。前に出した足はけり足の働きと倒れこむ力によって生まれた前向きの力がモーメントとなるような位置に着地する。発生したモーメントを使って前に進む。といった形。
実際の動作速度限界もあるので、応答速度を考えた動きをしなきゃならない。すると、バランスを崩してしまうことになるので崩れるバランスを補正する意味で上体を動かす必要があると思う。バランスの取り方は点対象。右足が前に出た時は左足を後ろに出す。これでいいだろう。そういった制御を行ううえで必要な計算を考えてると、体全体の重心点計算と動作することによる重心点の移動速度。重心点の移動軌跡を完全にコントロールすることは困難なので、数回の補正計算が必要になるかなー。問題はつま先を上げた状態での重心計算と重心位置計算。かかとにＰＳＤを取り付けたらもしかして床面との距離を測定できるかも。あ、いいかも。
■３月１０日■
歩行に関して、ZMPというのをよく聞くが、これがいまいち理解できてない。昨日の話もZMPを持ち出すと判りにくくなるから自分の理解の範囲で考えてみただけ。で、あらためてZMPについて勉強してみた。ZMPを理解するために倒立振り子を考える。振り子の錘が柱の真上にあるときは倒れない。これは柱に垂直に錘の力がかかっているから。もし柱が斜めになっていたら、振り子は倒れてしまう。この状態で静止させるには水平方向に加速度を与え、錘の力のベクトルと柱の方向を合わせることである。加速度を与え続けないといけないということは実際だと加速し続けないといけないということだ。なるほどそうすれば確かにこけない。でもこれをロボットでやろうとするともっと難しい。加速し続けるにも足の長さは有限だし、錘（重心点）を加速するために足を伸ばすと柱（設置点から重心点の距離）は長くなっていき、必要な加速度は大きくなっていく。アイボのクロール歩行の時は基本的に等速で進むための足先運動を計算していたのだけど、２足歩行の場合は重心点の運動を加速度をベースに算出しなきゃならないわけだ。有限の範囲でしか加速度を与えられないし、その時間内に軸足を移動させないとならない。次の足が目的地に着くための移動速度との兼ね合いで、歩ける（動歩行）できるかどうかが決まるわけだな。
なんとか、膝を曲げずに歩きたいと思っているのだが、そのためにはかかとをあげなければならず、そのときに転ばないようにするというのは針の穴を通すコントロールが必要となるわけだ。少なくとも前にこける方向に制御すれば前へは進めるんじゃないかな（相当希望的な考えだけど）。あと、遊脚を前に持ってくる動作も結構なスピードを要求される。（こける前に出さなきゃならないわけだし）これによって起こる重心点への力（モーメントかな）も考慮しなければならないだろう。難しそう。
■３月１２日■
構造設計していると段々とトリップしてくる。ずっと構造設計していたい気分。ソフト作ってる時のような苦しみがない。パズルを解いている時の集中している感覚と同じ。もうすぐ構造設計が終わりそうなのに終わりたくない。
■３月１３日■
今週も週末はＣＡＤとどっぷりと付き合った。外出したのはホワイトデーのためにケーキ屋さんに行っただけ。駅前のマリアツェルというケーキ屋だが、ショートケーキがちっこくて高い。そのうえポイントが１０００円ではんこ一個しかくれない。もう１０年近くかかってまだたまらない。バカらしいからポイントカード出すまいと思ってたけど、会計したら４０００円超え。カード出しちゃった。はんこ４個ゲット～っ。
とうとう胴体に四肢がくっついてそれっぽくなった。真正面から見たときのシルエットにちょっと不満があるけど、なかなかよろしい感じ。腕を弓なりにしたのは吉と出るか凶とでるか。
脚は今度こそ完了にしたい。気持ち的にもまとまってるので大丈夫かな。腰周りが思ったより難しい。歩くだけの自由度なら十分だけど、いろんな姿勢を考えると出来るだけ可動範囲は大きくしたい。すると腰の構造が難しい。大腿部のブラケットを片持ち構造にしたいなぁって真剣に思い始めた。今の腰構造は弱すぎて遅かれ早かれ改良を余儀なくされるだろう。切削部品の部分採用を検討しようかな。
全体像が見えてきたから頭の大きさとかデザインを考え始めようと思ったけど、顔って難しい。こいつの性格（？）ってどんななのかな。顔大きくしたい（キュリオくらいに）気持ちあるけど、顔を駆動させるサーボのことや動作速度のことを考えるとちっこくしないとまずいかなぁ。一応カメラにパン・チルトのサーボをつける程度の骨組み設計だけはやった。あとはマニピュレータ、サスガに601は使えないからマイクロサーボで考えてみる。
■３月１４日■
２足歩行ロボットを今までやらなかったのは結局は今の２足は結局は「ラジコン」だから。あれはオレの定義じゃロボットとは言えないなぁって気持ちが強くってどうしても踏み切れなかった。実験体としてなら考えられるけど、モーション再生で歩くだけってのは趣味じゃないし、だからと言って逐次計算すると高速処理が必要になってしまうし、ひも付きやリモート処理も趣味じゃないからやる気がしなかった。アイボベースの２足歩行ロボットじゃなきゃやる意味ないなと思ってた。スピーシーズはその点、価格も機能もアイボに迫るものがある。で、踏み切ったのだ。
アイボが２１０から７になってすごく良かったのは首関節が２重関節になり、物をくわえにいくことが出来る運動機能を持ったこと。本当はカメラが二眼になってステレオ画像が扱えるってのも希望だったんだけど・・・。ロボットにとって、移動する機能、モノを認識する機能、モノに働きかける機能は必須。アイボは７になってやっとそれが揃った。
で、７ではモノを認識し、近づいていき、くわえるというソフトに取り組んでいたのだ。（まだできてないけど）
２足をやるからと言って、その定義が壊れるものではない。２足歩行それ自体でメシが５杯はおかわり出来るくらいのパワーがあるけど、マニピュレータの無いロボットなんて考えられない。だからラムダにもマニピュレータは必須。そういうのを踏まえてマニピュレータを考えた時、グリップを除いて６自由度は欲しい。最低でも５自由度は必要。手首の空間座標までで３自由度。手首姿勢の制御のためにあと１自由度必要でマニピュレータの姿勢で２自由度が必要になる。人間の手首は３自由度あるけど、さすがにそれは無理かな。ロールはいいとして、チルトとパンはどっちが必要か。ずっと、チルトが必要と思ってたけど、真剣に考えるとパン角が必要なのがわかった。つまり、ラムダがコップを持ち上げる時、グリップの開閉方向と直交方向に関節がないとコップがつかみ上げられないって事だ。で、ミニサーボ３個でロールとパンとグリップを構成してみたけど、どぉぉぉにも気に入らない。腕が長すぎる、グリップがでか過ぎる、ロールした時かっこ悪い。腕を弓なりにしたとこからもう一度検討しなおしだ。
■３月１９日■
第７回ロボワンの予選を観に行った。
決勝トーナメントだけにしようかなと思ったけど、予選落ちするロボットたちが見たかったので予選から。その割りに出かけるのが遅くて午後からしか観れなかったけど。一番観たかった前田さんのOMNI-Zeroは始めの方に出てきちゃってたのでデモは観れずに終わってしまった。ガッカリ。。午前の段階で予選１位だったから決勝トーナメントでは見れるはず。みんなのロボットを見て、見た目はみんなしっかり作ってるんだけど、歩かせるとたいてい不安定。はじめロボットと、アリウス、ダイナマイザーの安定性が飛びぬけてた。一台、つま先を持ってるロボットがあって、膝をあまり曲げずに歩いてたんだけど、あんまり注目されてなかった。あれは決勝に残ったのかなぁ。（判らず仕舞い）ちなみにアリウスにもつま先があるみたいだった。決勝トーナメントより予選のデモに期待したんだけど、あんまり刺激的なことは無かった。デモは自律って言ってるけど、ろくに自律できてないのに無理やりスクリプトで動かしてる訳だからあんまり大したことができないんだね。操作とか許可してアピールさせた方が前向きな気がした。規定動作に本への登り降りがあるけど、自律してないから本の位置がすごく重要らしい。すごい時間かけて準備して、失敗するロボットばっかり。あれはあんまり良くないな。そろそろロボワンも次にステップに行かないと頭打ちするような印象を受けた。出てきてる人は常連さん以外はあまり変わり映えしないのも結構不思議。どうしてかな、大型新人的な人が見られなかった。
■３月２０日■
ロボワン決勝トーナメント。例によって、午後から観戦。１回戦の最後の２戦くらいから後が見れた。常連はすべて２回戦に上がってて、韓国の１位２位も２回戦に残った。やはり今回は大型新人は居なかったみたい。韓国の巨大ロボットがどんどん勝ち抜いて優勝する勢い。これが優勝しちゃったらなんだなぁって思ってたけど準決勝まで残ってグレートマジンガァが辛くも勝った。ぶつかってこけたのはダウンにカウントされないらしい。「有効な攻撃じゃないからスリップ」とのことだけど、ちょっと日本勢に甘い判定の気がした。実況も、韓国勢のことを「敵」とか言うし、完全にホームタウンデシジョン。しかし、韓国の巨大ロボははじめロボット・メタリックファイター・マジンガァ・ＹＧ不知火と戦って、ほとんど無敵状態だった。問題はやはり、モーション再生を主とした攻撃。痛みを感じない相手にパンチなんか出しても意味ない。今の攻撃の主流は倒立から体を相手に預けるボディスラム系の攻撃。これも相手の大きさが同じくらいか相手の方が小さい時に有効。歩行も、スリップ気味にすることで、加速度を逃がすようにしている。だから踏ん張りが効かないので、慣性質量が大きな相手には無力。巨大ロボットが必要十分な安定性で動いている時点でほぼ優勝確定って気がした。ロボワンがこのまま無差別状態で開催されるなら巨大ロボを作れる資本があるなしで勝ち負けが決まるようになるから白けちゃうんじゃないかなぁ。ちょっと心配になった。ロボワンはホビーレベルでのロボット開発という意味で興味深いから注目してるけど、「操縦」と「格闘」の２点が趣味に合わないのでちょっと引いて見てた。でも、巨大ロボットにやられていく日本勢を見てて、「オレならこうするな。」とか、「操縦系はマスタースレーブがいいかな。」とか結構興奮しながら観た。現状の技術では足裏スリップは必須で、歩行も攻撃に対する防御もスリップありきで成り立っている。ここを打破しないことには今後のロボワンの発展は難しいと思った。まさにこれは今、ラムダを作ってやりたいことなので、これが十分な性能で完成したならば、出場してみるのもいいかなと思う。やっぱり「こけない」ってのが重要。今はサーボにジャイロかまして振動を打ち消してるだけだから、歩行安定性には役に立つけど、攻撃受けてよろけた時に受身姿勢にはなれないもんね。この受身を行ってこけないようにするのはモーションじゃ基本的に無理。あらゆる方向の力に対しても適切な受身動作を取らないとならないから事実上、高度な小脳活動レベルの反応が必須になるはず。
ベテラン（常連）も含めて、ソフトウェアの占められているウェイトが低いのが気になった。大体にしてちっこいワンチップマイコンで作れるソフトなんだから大したことはできないことも確かにあるだろうが、ここから先のソフトウェアは非常に敷居が高い領域になるのだろうと思う。ＰＩＤ制御などのミクロなコントロールと動作レベルでのフィードバックや学習といったマクロなエリアを融合したソフトウェアが必要となるはず。メタリックファイターの製作者森永さんのカンファレンス資料を見ると随分と以前から自律の必要性と取り組みを考えているようだが、未だに成果には結びついていないようだ。難しさも判ろうというもの。
■３月２１日■
そろそろ作り始めないとこの盛り上がった気持ちがどっかに蒸発しちゃうなぁと思い、製作のための準備を始める。インベンターで作った部品データを展開して図面に貼りこんでみる。印刷してみると十分な精度なのでこのままケガキにしよう。これで労力は１０分の１くらいだ。検討する段階では最終的な穴あけ位置をきめていなかったりしてるからその辺を見直す。しかし、、検討データ見るたびになんか触りたくなってくる。ロボワンに出てたロボットはみんなお辞儀のサーボがついてた。基本検討段階で、お辞儀は諦めて肩を振れるようにしたのだけど、どうもお辞儀も要りそう。６０１サーボを増やしたくないのだけど、手首サーボも第一チルトもマイクロサーボにすれば、お辞儀と肩回転を６０１にできるかな。ＣＰＵユニットもでかいし、お辞儀サーボをどこに組み込むか考えてもいなかったけど、みんなのロボットを見て、胸辺りに組み込んでみることにする。胴体がぱっくり割れて、バッテリーとＣＰＵはベースの胴体に実装することにしてみた。バッテリーの固定とか、センサーボード取り付け板が振動しそうだとか、細かな検討点はいっぱい残っている。
■３月２４日■
悩んでた胴体部分。バッテリー収容部とセンサーなどの小基板の収容スペースがなんとか形になった。バッテリーは出来るだけ重心中央に置きたいし、交換できなきゃならない。センサーも胴体につけたいけど、装甲で覆って隠したい。メンテナンス性はどうかわからんけど、一応形は出来た。あとは作ってみて改良しかない。センサー基板ってジャイロデバイスの配置から、基板を縦に実装しなきゃならない。三軸とも実装しちゃえばよかったなぁ～。って思ってセンサー付け替えようかと考えたけど、Ｚ軸のモーメントによる姿勢も見なきゃならないだろうということで、３軸目も実装することにした。購入時に買えば8000円だったのに失敗したなぁ。
■３月２５日■
ロボワンを見てからこっち、受身のしかたを考えている。歩くより重要かもと思い出してる。というか、歩行に通じてるってのかな。
みんな、押されて倒れるんだけど、倒れるまで感知してないし、倒れ方って色々だから受身モーションじゃ対応できない。倒れる時って置物の人形が倒れるか、倒れてるのに脚をばたつかせてる（歩いてるつもり）。あれはどうにもかっこ悪い。あれを何とかしたい。まず、こけそうだっていう事をジャイロで感知できるか？当然、回復動作が間に合う範囲で。単に姿勢の変化を見て閾値を超えたかどうかというだけでは間に合わないような気がしている。倒れるに到るまでのパターンってのがあるんじゃないかと思うので、それを感知すれば閾値よりは良いのではないだろうか。たとえば突き飛ばされてこけるのと地面が傾いてこけるのではそれまでの動きの流れが違うのでは？当然、突き飛ばされる方向によっても変わるけど。HMMなんかで最尤度をみて判定するとか？受身動作については、前に倒れるパターンでは歩行の考察にほぼ近い。後ろに倒れる場合、直立状態からだと、つま先が使えない分動作が変わるはず。自分がどうやるのか考えてみると、手を前に出して、上体を前に倒すようにし、腰を落として膝を曲げる。その後、ためた膝を使ってZMPを確保し、片足を後ろに出して体を支える。手と胴体を動かすのは、膝を曲げる時に足裏が地面から離れてしまわないようにモーメントを発生させているのではないかと思う。単に重心をZMPにもって行こうとする動作ともいえるけど。
■３月２６日■
ウィークデーに買っておこうと思ってた、タック用紙をやっと買いに行った。なんとなく衝動買いでＮＤＳのパックマニアも買う。思ったより面白くないかなぁと思ったけど、ステージが上がると結構難しくなってきて良いかも？でも、ちょっと単調だな。あと、カバーやスタイルを考えたりするのにガンプラを参考にしようかなと思ってその手の雑誌を買ってみた。モデルの世界ってすごいなぁ。ラムダは手足が太いのでドムとかのデザインが参考になるかもと思ったら買ったのにはガンダムばっかしか載ってない。手足の先が太いのはちょっと気にしてて、末端が肥大になってるのって、末端重量が大きくなるからすばやい動きが出来なくなる。姿勢によって重心の位置がぶれ易いから安定動作も難しくなる。課題多いなぁ。
結局、工具を買いに行くことまでは出来ずに一日が終わってしまったので、タック用紙にテスト用板金の展開図を印刷して、アルミ板に貼るとこまで。曲げは、内Ｒの適正値を見つけるためにR0.3、R0.4、R0.5の３種類の内Rを持った単純な部品を作ってみる。センタードリルも使ってみるので穴も開けておく。ここで初めて気づいたけど、インベンターが作る展開図ってどういう基準で表裏を決めてるんだろ。折線が谷側に必要だから、それに合わせないといけない。とりあえずテスト用のは裏返しだったけど、まぁいいか。曲げ方向が複数有る部品とかの時にどうするかを考えとかなきゃいかんな。
マニピュレータをどうするか、ずっとココロに引っ掛かってたけど、届いたマイクロサーボをモデリングして、配置してみたが、どうにもイメージが沸かない。なんかかっこ悪い。なんてか、本末転倒なんだけど、体のサイズにあった手の大きさにしないとバランス悪いんだな。幅が小さくなるように配置してやっと気持ちが落ち着いた。こんな感じをベースに洗練させていこう。
■３月２７日■
午前中は工具を買いにＤＩＹ店に行く。折りたたみ式の作業台が2,000円台で出てた。買っちゃえ。スパナも13㎜のがあればいいけど、フルにしても200円アップしかしないからフルで。M2.5のタップ（ネジの入手性を考えて、M2.5にした。）と、それに合わせたドリルのビット。3㎜か4㎜で切れ味が悪いのがあったけど、たしか3.2㎜は大丈夫で、それ以外の径は使う予定が無いから今日はパス。帰って早速切り出しを始める。その後にオプティカルセンターポンチでポンチ打ち。これはもう、ばっちりセンターに。気持ちいい～。次にセンタードリルでもみつけ。んん？これがうまく行かない。なんとなく予想してたけど、普通のドリルでもみつけしてたようにはいかない。もみつけの練習をするべきか、従来どおり普通のドリルでもみつけするか、課題だな。で、きれいに端面を整えて曲げテスト。結局高さ15㎜の刃で曲げれたのは最初の曲げだけ。あとは折り曲げ木を削ったり、30㎜の刃を作ったりしてやっと出来た。内Ｒは0.4がいいみたい。幅精度も誤差0.1㎜くらいで出来たし、いけそうだ。今日はもう暗くなってしまったので本番部品はまた今度。
■３月２８日■
スピーシーズのジャイロ１チャンネル15,000円。結果的にだけど、ジャイロはフル実装。フレームは不必要だった。なんかもったいないなぁ、フレーム。使い道ないかな。フレームは迷って迷ってその末に買った上に流用できる個所が全然ない。ほんと、まったくないや。失敗の記憶を削除するために早いとこ処分しちゃおっと。 どうも最近、無駄遣いが多くなってる。ＤＱ８も全然やってないし、ＰＳＰもＮＤＳも放置状態。買って使わなかったのと、もっと安く買えたのとはどっちが無駄遣いなんだろう？と、無駄な思考をしてみたりして。。
■３月２９日■
コマンド型サーボにジャイロで補正することを考える。
サーボのジャイロ補正というのはラジコン飛行機などで、横風にあおられてぶれるのをキャンセルするためにある。ジャイロ出力をロールサーボに接続し、あおられて傾く方向と逆に振るわけだが、人為的なロールによるぶれは感知できないのでロール操作にはラグが発生する（はず）。ロボットの場合、歩行によってまたはぶつかった（ぶつかられた）衝撃で、グラグラとゆれる振動をキャンセルしたいということで補正をかける。ここで、問題は平地でグラグラする場合と、不正地歩行つまり、床面が斜めになってしまった時の補正方法が異なるということ。
理想的には、振動をキャンセルする方向へ補正をかけるということになるが、センスしてからの時間遅れがあるので正確には不可能。通常のPWMサーボの場合でも、補正をかけられるのはPWM信号を入力するタイミングとなる。これは15msくらいに決まっているので補正タイミングは15ms毎ということになる。コマンド型サーボの場合では、常時信号を与えているわけではないのでジャイロ補正をかけるとコマンド型サーボの利点を捨てることになる。将来的にはサーボにジャイロが搭載されるだろうが、現状でPWMサーボと同様なジャイロ補正（振動キャンセル）を与えるにはサーボコントロールＣＰＵを設けて、センサー情報にて指示値に補正をかけるまたは、メインからのサーボ制御を15ms程度まで細分化させる必要がある。
歩行させることを考えると、時分割処理をしなければならないのは必然なので、その処理周期での姿勢フィードバックで補正効果があるのかが、問題。
■４月１日■
脚の逆運動学計算を本格的に数式化する。
股関節を直交軸にしなかったので計算は大幅に複雑化するはず。と思ってはいたけど、解法が思いつかない。ロール軸を腿に持ってきたのは失敗か？いや、股関節の直交を止めたのが問題か。しかし、左右の脚間隔を小さくするのは必須だったから、間違いではないはず。がんばろう。
■４月２日■
今日から板金工作に入る。
注文したホールソーが届かないと大きな丸穴が開けられないからそういった加工が無い、比較的単純な部品からってことで、腿部の板金を作ることに決めてた。ホールソーが届いたからそれにこだわらなくてもいいんだけど、まぁ、そこから。
センタードリルの作業性に疑問があったから、適当な穴をいっぱい開けた平板を作ってみる。だ、だめだぁ。全然真ん中に穴があかない。結局モミツケは今までどおり1.0のキリで開けることに。
腿部の板金って形状の割りに強度が必要なので、3部品を組み合わせるようになっている。組み合わせには6本のネジをつかってるのでサーボホーンの止めネジとかを合わせると穴だらけの部品郡なのだ。
タック用紙に展開図を印刷してアルミ板に貼り付ける。もったいないからパズルのように組み合わせて無駄が少しでも少なくなるように・・って考えたんだけどこれが切り出しの時に災いに。
オプティカルセンターポンチでポンチを打って、モミツケを。これが結構神経を使う。切れ味があまりよくないようで、バリが結構でる。いちいちバリ取りをした。モミツケが終わったら、正規の径に拡げていく。これも、もみつけた穴に合うように慎重に。その後に切り出しなのだが、バンドソーを使っているので直線の切り出しはらくらく。けがき線ギリギリに切れる。ところが、直線性を出すために刃幅の大きな刃を使ってるから、カーブが出来ない。（ジグソーじゃないから）切り出すのにすごく苦労した。バンドソーの刃を折っちゃったら大損害だから結構ヒヤヒヤだったし。その後、切り口をヤスリで整えて切り出し完了。
最後に曲げなんだけど、ここで問題発覚。ヤゲンにかからない曲げが一箇所あった。万力で挟んで九大風に曲げてみたけど、勝率2分の1。失敗しちゃったぁ。またこれが一番穴が多くて、切り出しに苦労した部品なんだよなぁ。。。ってがっかりしているところに追い討ちで、大問題発覚。なんと、材料板厚が1.2mmだ。がーん。。設計は1.5mmなのに。。。1.2mmなんて使う予定無いから持ってないはず。。あれれれ、間違えて買ってる。今まで気づいてなかった。王国の売り場で混ざっちゃってるのかなぁ。見て気づかなかった自分が悲しい。しかし、板厚0.3㎜も違うのに結構寸法合うんだな。強度もまぁいけそうだし、このまま使うかなぁ、どうしようかなぁ。
板金加工は結構時間がかかる。朝９時過ぎから初めて、ここまでで５時過ぎだ。もう薄暗いし、今日は外作業は出来ないな。左右で６部品、穴は合計４６個所（タップは１２箇所）、曲げは合計１４箇所。で、この時間だ。外でなきゃ出来ない作業は大径穴開け・切り出し・ヤスリがけ。ポンチ・もみつけ・小径穴あけ・曲げは屋内・夜間でも出来るから、外作業を休日に集中してって感じかな。試作＝本番だから、一箇所づつ確認しながらやりたいんだけどなぁ。
■４月３日■
昨日の続き。
結局、昨日の部分は1.5㎜で作り直すことにする。出来栄えもイマイチだしね。曲げはヤゲンにかかるか？内向きＲはドリルか、ホールソーで加工できる寸法にする。切り出しは板取効率ではなく、作業効率重視で配置。そんな教訓を胸に板金加工二日目。
1.5mm材での加工になるから、簡単な部品からやりたい。今日はホールソーも使ってみたいから膝部品を作ることにした。左右で４部品、穴明けはホールソーも入れて３８箇所（タップ８箇所）、曲げは８箇所。昨日より早くは終わったけど、１１時開始の５時に完了。出来栄えも手際も昨日よりはいいけど、やっぱり相当な時間がかかるなぁ。今日はサーボのモデリング漏れの突起があってそこが干渉してしまった。曲げ部だから追加工で穴を開けることもできないからヤスリで逃げる。隠れる部分だからいいけど、ちょっと悲しい。夜にかけて次の部品のモミツケをやっておこうと思ったけど各部見直し、設計変更でそれはできず。今週のウィークデーにはモミツケ済部品をいっぱい用意しておこう。タップは曲げ加工後の方がよさげなので今後はそのように。
それにしても、曲げ機の寿命が来そう。締めて緩めるたびにバキバキとラップ音が出る。鉄鋼溶接できればなぁ。
■４月８日■
逆運動計算を解こうと悶々と考え続けたけど、太ももにヨー軸を持ってきた場合股関節が直交してなければ簡単には解けない様だ。股関節の上にもってくるか、足首のヨー軸として脛にもってくるかしないとだめ。今後、直交できない構造が有った時を考えて粘ってみようかとも考えたけど、諦めて股関節を直交させるように設計変更する。あまり美しい構造にはならないけど、身長もちょっと低くすることが出来そうな雰囲気。でも、股関節から腿の接続部が片持ち構造になるのが条件。たわみとか出ないかなぁ。ちょっと心配。
足首も腿も直交させることで計算はとんでもなく簡単になる。
そういうわけで、ウィークデーにモミツケをしておく計画は総崩れ。今日は金曜日だから設計は置いといて、モミツケに専念した方がいいだろうな。そういや、脛部の固定で、決まってない部分が有ったのを思い出した。脛部までは今週末はできないかなぁ。うーん。でも、下半身完成を目標にしたいところ。
振り返るとスピーシーズが届いたのは２月８日。構造設計ばっかりやって既に２ヶ月が過ぎてしまった。歩き出すまであとどれくらいかかるのだろう。考えると焦りを感じる。
■４月１０日■
昨日今日は先週の続きで板金加工。
穴加工まではウィークデーに済ませておこうと思っていたのになんだかんだで全然出来ず。なんとか展開図を材料に貼り付けるところまではやっておいた。
出来ればこの週末に下半身が完成すればいいなぁって思っていたけど、先週の構造変更で、腰の部品がまだ確定していない。９日の夜に設計して１０日に作るとか皮算用してみた。結局９日は足首部品と股関節部品の切り出しと曲げをちょっとして終わり。１０日加工分の貼り付けまでやっておいた。ポンチ打ちも夜中になるとちょっとはばかるので夜が明けてから。
日曜日、作業再開・・と思ったら、ボール盤が動かない。なんで？？、分解してみたらモーターが問題らしい。ブラシはまだ大丈夫そうだし。。でも、ブラシの片側が異常に硬い事を発見。交換してみたらスムーズになった。で、回りだした。交換したブラシを見ても見た目は全然正常。どういう現象なのかなぁ？？１時間ロス。日のあるうちに切り出しを終えて、曲げやタップ立てをやる。仮組みしてみようと思って気づいた。部品が一個足りないぃぃ。なんかすげーがっかり。
■今週のがっかり■
・10㎜穴あけに失敗。へんな饅頭みたいな穴になった。8mmも12㎜も成功してるのに10㎜は軒並み失敗、なぜだ？
・足首サーボブラケットの取り付け穴が非対称になってるのを後から発見。足裏もちゃんと非対称になってたのに、足裏部品だけは勝手違いにしてなかった。裏返しに使う事で対処。
・足首の直交ユニット部。なんとなくいびつ。複雑な形状だから仕方ないかなぁ。
・Ｍ２．３ネジの長さが足りない。これは困った。入手困難だ。
・Ｍ２サラモミしたけど、深さが足りずに浮いてる。曲げ後だから修正加工大変。
・股関節部品（強度が気になってたヤツ）うまく組めなくて無理やりネジ止め。
・足首直交部のベアリング軸。ずれてる。これも複雑な構造してるから軸ずれて当然なんだけど、やっぱちょっとがっかり。
・足首ベアリング軸受け。弱いと思ってぎりぎりに設計変更したけど、変更しちゃまずい部分だった。なんとなくギリで大丈夫だった。
■今週のヒヤヒヤ■
・足首部、なんとなく形状変更をしたおかげで干渉回避。前の形状のままだと可動範囲少なかったはず。あぶねぇあぶねぇ。
■今週の宿題■
・足首の直交ユニットの複雑さは問題かもなぁ。メンテナンスしにくくって仕方ない。足首はよく壊れそうな気配だから余計心配。改良の余地アリ。ってか、削りだし部品で対処って手もあるかも。
・足裏をサラモミにしてみたけど、間違いだな。丸穴にして誤差吸収させるようにしなきゃならん。
■今週の教訓■
・モミツケは１．５キリが最適。ポンチにはまってくれるし、慎重にやれば補正も効く。それに多分折れにくい。
曲げ部の幅が50㎜程度になると、板金折り曲げ機での作業は困難を極める。板金折り曲げ機２号を考えなきゃならないかもしれない。当面は曲げ易いようにＶ溝を掘ってやってみるか。
■４月１４日■
ウィークデーに曲げ加工とタップ加工。
Ｖ溝掘ってやってみたけど、意味がある位の溝が掘れないから意味無い感じ。逆に曲げ加工の時の位置あわせで、溝に頼ってしまってずれてしまい、曲げ失敗。慣れてきたせいか、失敗が目立つようになってきた。そうは言いつつ、騙し騙しに脛部品を曲げ加工して脚部がほぼ完成。
＜失敗部品一覧＞
①腿部品１（右）．曲げ位置間違って失敗
②股関節部品（左右）そもそもコの字が深すぎて曲げられない。
③足裏部品（左右）刃の長さが足りない。
④足首ベアリング部部品（右）うまく行ったと思ってたら曲げ位置が微妙にうまくない。穴を広げれば使えるかな。
刃の長さが足りないとやっぱ曲げられない。少なくとも曲げ始めは全長に刃が当たっていないとうまく行かない。
板厚1.5ミリで曲げ長さが100ミリ付近になると、板金折り曲げ機の能力を超えている。ぶっとい檜の角棒がしなっているのが見える。折れはしないけど、曲げにムラが出来てうまくない。その上がんばって締め続けると急に板金が負けて曲がり過ぎちゃう。そろそろ板金折り曲げ機２を作る時が来たかな。今度はＺ曲げもできるようにする予定。ベースを檜材を縦に使うってことでよいのだろうか。もっと硬い木材がリーズナブルに入手できるかどうか。
2.3ミリのネジ棒は2.5ミリの真鍮棒にネジを切って使ってみることにする。ネジだと35ミリの長さが必要。Ｍ２もＭ２．３も入手は簡単ではないようだし、仕方ないな。ただ、サーボの取り付け穴が細くて２．５ミリ棒でも太すぎるので全ネジを切る必要があるみたい。Φ2.5をΦ2.3に細めるのは旋盤が有っても無理そうだからまぁ仕方あるまい。
両足がほぼ完成。形になるとやっぱ楽しいな。早く腰部を作りたい。胴体部の配置は二転三転してCPUモジュールを胸部分に収納。バッテリーは変わらずに小基板はお尻部へ。これで股関節を開くサーボがきれいに配置できる。CPUモジュールをここに配置することでガードを作ったりする必要が無くなった。LANカードガードも不要になったのでなかなかの妙案かも。
のばしてぇ 
ちぢめてぇ
■４月１９日■
土日で下半身の部品ほぼ全てと、両腕の部品の穴あけ、切り出しまで終えた。日曜日のうちに下半身完成！とか目論んでいたけど、全然無理。
夜になって、前回失敗した右足の太もも部品の曲げにトライ。穴が全然あわなぃ～。なんで左足はうまくいったんだろ？不思議だ。。と、不思議がってもいられないので穴を広げて使えるようにする。
昨夜は、ドラマでも見ながら部品曲げよーって感じで取り掛かった。股関節のブラケット（これは前回、深すぎて曲げられなかったから分割してリトライ）左足を作るとなんかメカメカしくっていい感じ。乗って来た。でも、ネジ頭が干渉するから腿フレームをチョイ削り。削る場面が多くなってきたなぁ。乗って来たからそのリズムで両足のブラケットを完成。更に腰部品も作ってとうとう両足連結。両もちにしないとサーボが壊れちゃいそうだから腰部分をほぼ作っちゃう。この時は、もう夜中でへとへと状態だったから曲げの順序間違えて苦労したり、曲げすぎて補正したり結構適当。
でも、下半身がほぼ出来た～。なかなかいい感じだ。今晩にはCPUユニットも搭載できるからサーボつなげば動かせる。
切り出してバリ取りとか完了。 
切り出しっぱなしの腕部品。
CPUユニットも乗ってる。 
うしろから。
■４月２５日■
コマンドサーボ部分の構造体完成。正確には足首の軸受けがまだだけど、サーボホーンが足りないからそこは今はまだできない。土壇場で腕を短くする設計変更をしたから腕部品は全部作り直し。簡単でよくなった。ちょっとごつくなったけど、筋肉で覆われてる感じの風貌になった感じで、許容範囲かな。このサーボはでかいからそのへんは我慢しないと仕方ない。今回も色々と設計チョンボがあった。一番でかいのが上体旋回部分。お辞儀サーボの固定金具にぶつかってしまって左右９０度までしか旋回できない。Ｍ２．３の皿ネジ、そして長ーいのが手に入ればよいのだが少なくとも1000本。多分特注で数万本になっちゃうからだめだろうなぁ。そのうち設計変更しよう。
３大オオモノ部品のひとつ肩部分。肉抜き穴３つもセンターラインを書き漏らした。肉抜き穴でよかったよ。で、組んでから気づいたのが上体旋回サーボのコネクタ穴を開けてなかった。これはなんだかしらんがショックだった。（ちなみに腰部分・脛部分のフレームが残りの２大オオモノ部品。難しいし重要個所って辺りがポイント）
困ったのがロボットを持つところ。お辞儀サーボがあるので肩あたりを持つとうまくない。股下に手を回して持つのが今のとこ正しい持ち方なのだが、お尻部分あたりに実装したセンサーボードに触れてしまう。ジャイロセンサーを壊す前にカバーをつけなきゃ。
そのほか、旋回用サーボホーンの止めネジがＣＰＵユニットにちょこっとだけ触れてる。とりあえずネジを削って対処しておこうかな。それにお辞儀サーボがちょっと辛そう。多分トルク不足だろうなぁ。手や旋回をうまく使って動作させないと壊れちゃいそうだ。それ以前に、お辞儀した時のストッパーが無い。サーボの動作限界角度まで行って止まってる。これは考慮不足だ。ホームポジションでも、サーボハウジングで荷重を受けちゃってるし、全部ひっくるめて設計変更対象だなぁ。
あとで気づいたけど、サーボの動作範囲の半分しか使ってない。全部手前に振り向けたらフレームがぶつかるまで曲がるはず。とりあえずはそれだな。トルクかかってる時は別で。。
肩サーボと腿サーボにはメンテ上の問題がある。サーボを外そうとすると反対側のネジが緩んでしまう場合があって、そうなるとドツボにはまる。六角レンチの短い方が更に短いやつがあればよいのだが、探したら「ボンダス社 スタッビー・アーム 税込価格：7350円 」買えないなぁ～。（泣き）工具なんて硬くって切断できないよぉ。
結局２２個目のサーボがないから左腕は組み立たない状態。サーボホーンさえあれば、腕は付くんだけどサーボホーンがないからね。ホントは２２個目のサーボがお辞儀サーボなんだけど、それだと仮組みできないから、お辞儀→上体旋回って流用して、その流れで 左手首旋回→上体旋回 って流用したけど、考えたらアホだった。左手首旋回→お辞儀 にすれば良かった。
アイボのウェブリングのメンテを人形つかいさんが引き継ぐ件でメールが来た。うちのＨＰはリンク切れになってた。そういや、ＯＣＮになった時にＵＲＬかわったなぁ。リンク直したら「わくわくしながら」読んでくれたらしい。どの辺りがわくわくだったんだろー。どれも中途半端なんだけど。案外アイランだったら笑う。
スピーシーズからメールが来る。
新しい制御ソフトでは２１個のサーボに同時にコマンドを送っていると、、これはどういうことかなぁ、、グローバルコマンドあったのかな？あったのならうれしいな。
さて、それではいよいよ人型ロボットの制御プログラムの開発に着手。マニピュレータと頭がないけど、今は要らない。こけて壊れるのがオチだしね。設計まとまってないし。 まずは「こけない」制御をやりたい。押しても引いてもこけないってのが目標。歩くのはそのアト。
バランスで立ってる。 オトコなら立て！
■４月２８日■
サーボ。一斉コマンドがあるらしい。有るなら有ると早く言ってくれればいいのに。現在はレベル２関数をテスト中らしい。レベル３用にコマンドだけ公開して欲しいなぁ。
昨日は久しぶりにＣＰＵユニットを動かしてサーボを動かしたりしてみた。1ヶ月ぶりくらいだから手間取ってしまった。こないだはＲＳ４８５の通信がうまくいかなくて、結局ライブラリーのＩＤ認証問題とかだった。試行錯誤したまんまのソースファイルでしばらく悩んだ。ボーレートを変えたりレベル３関数を使ってみたり。。 上半身全部を支えるお腹サーボのパワーは足りてるかどうかってのが確認したかったんだけど、なんか大丈夫みたい。
でも、重心がサーボの軸とずれてるからサーボに負担がかかりそう。コンプライアンスとか設定して、負荷軽減するようにしなきゃならないだろうな。
■４月３０日■
一斉コマンドを含んだ最新ライブラリのベータ版が送られてきた。うれしいな。こういう心遣いされると更にモチベーションがアップする。
マニピュレータとカメラアイの構造が決まらなくて気が気じゃない感じ。PWMサーボのコントローラを全然用意してないからほっといていいんだけど、気がそうさせない。カメラはなんとか形を作ったけどマニピュレータはなぁ。。 結局、手はこけた時の受身なんかの関係で必要だからダミーの手を作った。しばらくはこれで。
で、各サーボのノーマルポジションとか可動範囲を調べて、各サーボに可動範囲を設定する。その後、全サーボにトルクを与えてノーマルポジションにしてみる。硬いなぁ。。 やっぱりお腹サーボは負荷が大きいらしい。ここだけモーターが熱くなってる。コンプライアンス設定もしなきゃ。
さて、ではソフト開発なんだけど、どっから手をつけようか。①逆運動学 ②重心計算（加速度を含む） ③タスクスケジューラ これだけ揃ったら姿勢制御にトライできるはず。
直立不動で記念撮影(^.^) ぎりぎり立ってる。
今日じゃないけど・・、浦沢直樹の「プルートウ」の２巻が出た。面白いけど、あぁアメリカバッシングっぽい話だったんだ。ちょっとがっかり。それよりもガッカリなのは手塚プロ。2巻の特別版の付録がアトムとプルートウのシール？？買ってないからどんなのかわからんけど、シール付きで１５００円っておかしくないか？それ目当てで買う人がいると思ってるのか？なんか時代錯誤っぽい。いい加減手塚治虫の財産で食う事諦めればいいのにとマジで思う。それに引きかえ、浦沢直樹はすごいなー。アトムを原作に置く必要なんてないのにぃ。って思ってたら２巻のあとがきが手塚治虫の息子さん。「浦沢直樹の作品として、浦沢直樹の絵柄で書くこと」ってのが条件だったと。。 はじめは手塚風だったのか。。。 それもちょっとなんだな。。
■５月２日■
立つということを考える。
ガワ（機体）は出来た。んじゃ、動かそうってことなんだけど、モーション再生による制御を否定してる身としてはどういうアプローチをすべきか。
（アイボの時はよくわからなかったからモーション再生から入ったなぁ。。）アイボは足首がないので逆運動学で軌道を生成させるってことがメインの課題だった。今度は足首持ってるし、脚は２本しかないから、とにかく「バランス」がテーマ。負荷の支え方には「ぶら下げ型」と「持ち上げ型」がある。肩は腕をぶら下げてるけど、足は腰（体）を持ち上げてる。 「ぶら下げ型」のバランスは比較的簡単。脱力した腕で、肘だけを曲げると肩関節が若干動く。これは肘だけ曲げると重心がずれてしまうからで、補正のために肩関節を動かす。もちろん、肩関節の位置が決まっているなら動かないが、条件なしで肘を曲げたら肩は自然と動く。 「持ち上げ型」の場合だとこんなに簡単ではない。持ち上げた負荷の重心がずれてしまうと落っことしてしまう（こけてしまう）から重心位置にいち早く回りこまなくてはならない。倒立振り子のような感じ。ただ、足にはタイヤがついていないので倒立振り子と同じようなわけには行かず、もっと複雑な動きが必要。バランスのずれ具合が大きい場合はそれが歩行に移行するってイメージだが、まずは接地位置を動かさずに補正できる範囲でのバランスをやってみよう。
■５月３日■
UNIXでちゃんとしたソフトウェアを作ったことがない。今回はハードウェア制御なのでいきなり敷居が高い。とりあえずはインターバルタイマーでの定時割り込みができないと話にならないのでシグナルハンドラーの設定から。。 って思ったら、こないだから悩み続けた腕の構造が気になってきた。結局回りまわって一番単純な構造に戻ってしまった。これは上腕が妙に長くなってしまって却下してたんだけど、まぁいいや。気に入らなければまた直せばよい。ちょっとだけスマートになりました。(^^ゞ あと、LANカードガードも作った。腕の可動範囲内で触れてしまうんだよねー。ソフトがうまく動いてればカードに触らないようにもできるはずだけど、暴走考えて、ガード。
バランスで立ってる。結構立つもんだな。
後ろから。ケーブルの塊だ。この処理は、注文してるコネクタが届いてからやる。
■５月４日■
今日は午前中からプログラムの勉強。なんせ、UNIXシグナルを使ったプログラム書かなきゃならないから判らないことばっか。 でも、インターバルタイマー使って、定時割り込みはすぐ出来た。タイマークリアしないとうまく動かなかったけど、そんなことはどこにも書いてなかったなぁ。あと、昔買った、アスキー出版局の「UNIX Cプログラミング」のitimerval構造体の説明が間違ってるみたい。it_interval がインターバルで、it_valu がタイマー値です。NetBSDのマニュアルページ見ればいいんだけど、英語だからぁ～(>_<)
さて次はサーボの負荷情報を読み込んで角度にフィードバックしてみる。これで倒立振り子の基本ができるはず。 人や動物はIK（インバース・キネマティック）計算してるわけじゃないから、簡単な動作なら、各関節の役割（負荷に対するフィードバック方法・度合い）を与えてやるだけでそこそこ正しく動くはず。 もちろん、動作目的（モード？）に応じた動きを指令するとかそういうことも考える必要があるけど。
昨日、サイエンスZEROを再放送で見た。愛・地球博に出るっていう「鉄犬」もそんな感じで動いてるんではなかろうかと思った。
＜負荷情報取り込み FutabaRS601CR＞
んん？？負荷情報って方向データが無い！なんで？？まぁ、指示角度と現在角度の差で方向を見るしかないのかなぁ。回転移動方向に荷重がかかってる時は検出できないことになってしまう。
データ読み取り、結構な確率で失敗する。失敗データを無視するようにしないとまずいな。更に、おかしなデータをサーボに送り込むと簡単に暴走（通信できなくなる）しちゃう。暴走しだしたら電源切断しないと復旧しない。（そのたびにコネクタを抜き差しするのってすごくいやだな。サーボ電源線にスイッチ入れて部分的に切断できるようにしようかな。なんせ、OSがUNIXだから立ち上がるのにそれなりの時間がかかる。結構面倒。
全サーボ対象のトルクフィードバック（ってのは言いすぎだけど(^^ゞ ）プログラム。ループで回してるだけ。一応ポージングとか取れる。でもやっぱり通信が出来なくなることがある。おかしいときは全サーボ一緒になる。つまりこれはCPU側の問題？？ でも、サーボ1個でやってたときはそいつだけ切り離した直るな。 ・・ おかしいサーボがRS485インターフェースを乗っ取っちゃうのかな。
こんなかっこでも結構立ってる。
■５月５日■
古本屋に立ち寄ったら全巻パック半額セールやってたんで、懐かしいパトレーバーを買ってきた。あると読んじゃうね。(^^ゞ これに出てくる「イングラム」も結構すきだけど、「グリフォン」がスキ。
珍しくプラモデルを買おうかと真剣に思ったくらい。 結局、所詮は動かないから要らないやってことで買わなかったけど。
鍛えられた機体は動作が最適化するってんで、主人公の操るイングラムは腕を上げただけで、スムーズに体重移動をしたりする描写（？）があったりする。まさにそういう動作プログラムを目指してる。
本編のラムダだけど、RS485回線がおかしくなる問題は深そう。おかしくなったサーボ（がわからないんだけど）をつなぎ直したら復旧する場合もあるし、全サーボを切り離しても復旧しない場合もある。どうも萎えが入るような症状。(>_<)
一度おかしくなったサーボは電源を入れなおさないと復旧しないから、現状では「おかしくならない」ようにするしかない。どんなときにおかしくなるのか？ 一個だけでループ回すぶんにはおかしくならないようになったのになぁ。←と思ってたら、やっぱり１個でもだめだぁ～。でも、タイムアウト値を変えたりして試しているうちに再現しなくなってきた。
＜やったこと。＞
①受信を失敗したら止まるようにした。⇒継続しても失敗続き。復旧しない。
②送受切り替えタイムアウト値を大きく⇒エラーの頻度が下がったような気がする。
③受信タイムアウト値も大きくする。⇒これ以上はエラー頻度下がらないっぽい。（タイムアウト値を大きくしてもエラーは起こる）
④送受切り替えタイムアウト値を徐々に小さくする。⇒エラーは起こすが、復旧する。
⑤そして、最初の設定（タイムアウト値）まで戻す。⇒復旧不能に陥らない。。(>_<) むぅぅぅ～ あ、やっぱダメだ。
⑥送受切り替えタイムアウト値をちょっと大きくして、受信失敗後にウェイトを入れる。これでいまんとこ大丈夫。でも、1秒も待つのやだな。ウェイトを減らして行くと・・・0.1秒までは確認できた。これならいいかなぁ。状況的にポートフラッシュじゃ意味なさそうだしな。
⑦更に更に試してると、ウェイト１秒でもやっぱり固まる。 (-_-;)
⑧ループの最後にウェイトを入れてみたら、エラーの頻度がめちゃくちゃ増えたけど、エラー後のウェイトを入れなくても固まらなくなった。
なんだかなぁ～ (-_-;)
受信と送信の切り替えが問題なのかな？ これなら複数サーボの時でも固まることの説明はできる。シビアなのは判るけど、固まっちゃうのはちょっと許せないなぁ。ソフトでリブートできなきゃロボット部品じゃないよぉ。サーボのファームバグってことで上げとこう。
■５月６日■
話題の等身大ボトムズを見に水道橋へ。記念のボルトを購入してきた。ボトムズすげーけど、実はその他の展示物の方にタマシイ感じました。急がされたのか、疲れたのか作品（？）の細やかさが足りない感じ？ いろんな意味でいいもん見せてもらいました。
刻印見えないね。(^^ゞ まーいーか。
その足でやっぱり秋葉原へ。今日はラムダの配線用材料と板金折り曲げ機Ⅱに使うボルトを買いに。忘れるところだったけど、こないだ刊行された「ヒューマノイドロボット」も買って帰ろう。近くの本屋には置いてないんだもん。まだ読んでないけど（ってか、読んでどうなるって本じゃないけどね）ロボット制御のための教科書的位置づけにはなるかな。これだけメニューを並べたら一つ一つの項目は薄くなるもんね。概論以上の役に立つかどうかは不明。画像処理の専門書はたくさん買ったけど、メニューが多い本は失敗が多い。自分が知りたい事柄もたいてい載ってるけど、役に立たないの。 そうならなきゃいいけどなぁ。
サーボが暴走する件は未だ回答なし。（サーボのファームバグだとして、）ファームアップとかできるのかな？このサーボ。 心配だな。
■５月８日■
バリスティック歩行、人形つかいさんに教えてもらう。要するに勢いを使って力を使わずに歩く事のようだ。それそれ。教えてもらった論文概要には最適点の探索が困難と書いてある。そりゃそうだわな。できればもうやってるって。
２足歩行ロボットの制御の第一として「こけない」、外力や重心の変化に対応してこらえるって制御をやってみようと思ったのだけど、足首サーボの負荷読み取りからそれを位置制御にフィードバックとかやってみたけど、どうもしっくりこない。やはりフィードバックサイクルが長過ぎるよね。こらえるのは制御的には難しそうだと判断して、こけそうな時に足を出すための制御を考えることに方向転換することに。早速だけど、来るべきバリスティック歩行の予備実験として、けり足での初速付与で、重心移動最小での体重移動ってのをやってみることに。足首にそれだけのスピードとパワーがあるのかな？
それついでに、複数サーボ制御コマンドのテストもやってみよう。 で、やってみたんだけど、、、メールではデータは上位、下位の順で収めろとあるけど、どうも間違いじゃない？下位、上位の順だよね。メモリーマップもそうなってるからおかしいなと思ったんだ。コマンド説明のメールでは指示角度データを指定してる。移動時間のメモリーにデータ書き込むと、書き込んだ時点で動作を始めるんだよね。思ったとおり。時間、角度の順で入れればまぁいいか。って書いてて気づいたけど、指示角度と移動時間のメモリーは隣あわせだから、一度に指定できるのかも。後ほどやってみよう。
キュイキュイ動かしてたらケーブルの被覆がやぶれてきた。(>_<) ちゃんと配線しなきゃなぁ。
やっぱそうだね。まとめて転送できる。これなら使えるね。＞複数サーボ制御
■５月９日■
久々に会社。会社に転送している自宅メールを見るとスピーシーズからサーボ暴走の件でメールが。 あれぇ～気づかなかったな。帰って見てもうちのメールボックスには無い。広告メールと一緒に捨てちまったか？ 結局サーボの問題はフタバに上がったようで、しばらくは回答待ち。
バリスティック歩行を考える。
勢いを使って動くってことは遊脚は振り子？だとすると移動速度は足の長さで決まるのかな。ちっこいロボットだとチャカチャカ歩かないとダメだ。サーボがついてこれるのか？サーボモーターにもギアが入ってるから受動動作は無理。トルクをちょっとだけ与えて補償してやればいいのかな。でも線形動作じゃ補償にならないかも。それにせっかく与えた初速に対してブレーキになる？
左右の体重移動に関しては支点を乗り越えない倒立振り子。これなら初速次第で往復速度が調整できる。もっとも足の長さと重心のずれは影響するから難しいってことについては一緒だけど。
足首が勢いに応じて曲がってくれないとまずいわけだから、サーボのコンプライアンススロープ設定を試してみた。おっ、これは面白い(^.^) 足首サーボに設定してみると、サスペンションが入ったみたいにふにゃふにゃする。スロープが直線しかないのが残念。指示角付近はトルクが弱すぎる感じ。←パンチの設定すればましになるのかも。 これ、足首に使ったら、指示角度で止まらなくなるわけだから、サーボはしんどいのかな？
■５月１０日■
左右体重移動の検討を行うために簡単なモーション再生プログラムを作ることに。
アイボの場合は、最大16フレーム分のデータを1パケットにまとめることができて、パケット処理時間毎に関数が呼ばれた。しかし、かならず8ms毎のフレームデータを用意する必要があった。フタバのサーボの場合、指示角度への到達時間を指定できるからかならずしも最小フレーム毎のデータを用意する必要はないのだけれど、関数呼び出しをそれに同期させるってのが難しいので関数呼び出しは定時にしてインターバルタイマーで呼び出す。必要に応じてサーボにコマンドを送るって感じかな。サーボに問い合わせれば目標への到達をチェックできるけど、処理時間がもったいないからそれはやらない。 それより、検討用なんだから、各フレームでの角度データとか負荷データとかを取得できるようにするべきだな。このサーボ、情報取得の時のパケット長が長くってデータ取得に時間がかかるのがちょっと問題。そのあたりも改善して欲しいな。
モーション再生より単一動作をパラメータで設定できるようにすべきかな。最適点の探索もやってみたいし。・・・やっぱりＩＫ関数作った方がいろいろ便利かな。さっさと作っちまおう。
けり出しが適切かどうかを判定しなければならない。この情報はジャイロを使えないかなーって考えてた。本当は加速度情報が一番なんだけど、加速度センサーのデータってノイジーだった覚えが。アイボの歩行検討でも似たようなことやったなぁ。そういやうまく行かなかったな、あの時は。。(~_~)
浦沢直樹の「PLUTO」が第９回手塚修文化賞を受賞した。以前に浦沢直樹がなんかを受賞した時に弘兼憲史が、この人は早く審査員にしないと賞を全部取っちゃうってことを評に書いてた(^_^;)。 それは冗談にしても、賞を取るような作品をどんどん創造する人にはどんどん作品を作ってもらってどんどん賞をあげればよい。審査員はそういうのを作れなくなった人がやればいいもんね。つまり審査員の依頼って、創造者に対する最後通達か。
フタバのサーボ、メーカーで障害再現したらしい。ヨカッタ(^_^;) さぁ、さっさと対策しとくれぇ～。
■５月１１日■
逆運動学の計算めんどくさいなー。高校数学とはいえ、数学苦手だ。そういや、こないだ買った「ヒューマノイドロボット」に逆運動学計算の解析的解法の例が出てたな。 ふむ、ふむ・・・、atan2( )ってなんだろ使ったことないんですけど(-_-;) 関節構成がちょと違うので参考にしかなりませんでした。（判ってたけど）
ラムダ（実物）をいじくりながらやってたら、可動範囲を拡げたくなってきた。将来に渡って不要かもしれないけど、へんな形になるけど、これで可動範囲が随分と広がる。今度の休みにやる気になったら作ろう。
影になっちゃった。 
へんてこな形だなぁ～。(>_<)
■５月１４日■
逆運動計算式がやっとできた。大腿にひねり軸持ってきたからちょっとめんどくさかった。アイボと違って足首もあるしね。踵を上げた時の計算はまた今度。一応この計算式で動かせるようにしてみよう。でも検算してないからマズイかな～。
腰部フレームを作り直すのに部分的に分解したんだけど、結構ネジ緩んでるね。締め忘れかもしれないけど。ロックタイトしたくないけど最終的にはゆるみ止めしないとまずいよなぁ。
腰部フレーム作り直し。可動範囲がそこそこ広がった。
■５月１５日■
逆運動計算式でラムダを動かしてみた。まーちょっと間違いもあったけど、タンジェント使う時は異常値の処理とかがめんどくさいね。あ、atan2(
)を使ってみたんだけど、エクセルのとlibmのatan2( )で、引数が違うことを知らずに悩んでしまった。大腿の関節構造がちょっと特殊なんで、角度がリニアに動いたら補間しないとうまくないときもあるかも。その辺も考慮して制御周期を決めなきゃ。
まったくもって単純なプログラムだけど、スクワットをさせてみた。WMVでアップしたかったけど、変換がうまくいかなかったからMOVで。
横向きだし、MOVだし、屈伸してるだけの動画だけど、５MBもあるし、クリックして後悔しないようにお願いします。<m(__)m>
MOVからMP4にしてみた。これでWMPだけで見れるんじゃないかな？７５０KBにまでちっこくなったし。ただし横向きのまま。
■５月１６日■
こないだ新聞を読んでたら、天外伺朗さん（土井利忠さん）が「考える脳 考えるコンピューター」の書評を書いてた。ああ、あちこちで紹介されてた本だ～。 人間の行動・思考は予測より成り立っている。 ある程度前提だと思ってたんだけど、世間的にはそうでもなかったのかなー。どうりで「人工知能学」って分野がパズルの解法とかでもたもたしてるわけだなとか思ってた。面白そうだから買って読むことに。 その書評に、私もパームパイロット（のようなもの）を作ったが、早すぎて失敗だったって書いてたけど、ソニー、そんなの出したっけ？
あと、「アンドロイドの脳」ってのが面白そうだっていうんで買おうかと思ったけど、内容紹介を読むとなーんとなくいやな予感。２２００円（税別）もするし、ちょっと警戒して中身を見てから読むかどうか決めようと思った。今日、会社の帰りに本屋でペラペラ見てみたけど予想どおりの感じ。ロボット作りたいってヤツ（自分のような）には面白そうな、ヒントになりそうなこと満載なんだけど、なんであっちの人の文章ってこう、、、読みにくいんだろう。いらんこと書かないとすぐ書くこと無くなるからかな？ でも、人工生命を作っていく様子は高校1年生の時に読んだ「マイコン・ロボットの作り方」を思い出させてくれた。ものすごくテンション上がって本のまねをしてロボット（ワンボードマイコンでモーターを制御してソナーとかタッチセンサーを搭載してる）を作ったのが僕のロボ道の始まりだったな。 あの時と同じ高揚（？）を得られるとは思わないけど、読んでみよっと。
■５月１７日■
逆運動計算式を用意して、2状態を往復させるだけで屈伸運動が完成しちゃう。十分に足裏が広いからって話なんだけど、足裏の床反力をフィードバックしてバランス取りながらの屈伸とかさせたい。
人が同じ動作をやるときは常にサンプリング－フィードバックしてるわけじゃなく、十分に最適化された後は「監視」しつつ、最適化された動作を実行するって感じに思える。十分に学習された状態だと、逆運動計算に近い動きをすることができるけど、イコール「制御された動き」ではない。必ずフィードバックが必要なはず。合目的的な成功のイメージとのずれを補正しながら動作するはず。
最適化のための学習のシステムが必要。できれば学習結果から相関関係をみて最適パラメータ予測できないかな。分野的にはニューラルネットとか良さそうなんだけど、なんとなく使いたくない。ちょっと勉強しよう。
逆運動計算に胴体の仰角を入れてみた。簡単そうだけど結構難しい。屈伸は簡単にできたけど、お辞儀はバランス取れなかった。簡単じゃないや。とりあえず、腹筋運動に変更。(^^ゞ あとはつま先立ちを組み込んだら逆運動計算（足偏）は終了。実は足を上げすぎると計算結果がおかしくなる。符号が変わるとこだな、きっと。
（MP4：445KB）
胴体の仰角を逆運動計算に入れたのはちょっと前後バランスってのをやってみたいかなーって思ったから。
こうなると手が邪魔だなー。今は手にはトルクを入れてない。ブラブラ状態。
■５月２２日■
胴体の仰角を加えた逆運動計算はいろいろ間違ってた。何度かの挑戦の末にやっと正解に至ったようだ。ほぉ～。。
ラムダの関節構造の場合、左右の傾きなら簡単なのだが、前後の傾きは計算が面倒。 でも、これでつま先立ちの逆運動学計算も出来たも同然。
っていっても関節角度計算できるようになっただけだからさしたる進歩ではないのだ。
「アンドロイドの脳」まだ読み終わってないけど、Webページを見た。ルーシーが動いている動画がアップされてるんだけど、あの動きは本に書いてあるアプローチでルーシーが自発的に動かしてるのだろうか？そうであればすごいけど、プロモっぽいな。
ルーシー開発のアプローチはすごく興味深い。触発されて同じ事をやりたくなる（っていうか、ロボット工学を勉強しないでロボットを作ろうとしたらああいうアプローチになるんじゃないかと思う。）もっとも、そのアプローチを実際に行うためにはロボット工学を勉強するよりも遥かに多岐に及んだ知識と考察が必要であるのは間違いないのだが。 僕も逆運動学式を準備しないで、ラムダの関節を自由に動くようにして逆運動学に相当する関節の動作法則（？）を会得するような学習システムを作ってみたいが、意味のある動作を行えるようになるまで何十年かかるかわからん。 ルーシーのアプローチはハードウェアは進化により会得したシステムを準備して、ソフトは学習にて形成しようとしているが、ハードとソフトの間にあるファームウェア的な部分にはあまり目を向けていないように見える。ソフトとして位置づけているものが生まれてから学習する後天的部分としても、ハードとファームは同時に進化してきたはずだからハードだけ準備してもソフトは形成できないはず。そのあたりはどう考えているのかなー。 まだ読み終わってないので後半に語られるのかも、期待しよう。 これから視覚の部分に入るけど、一番力入ってるところらしく、面白そう。いろいろと学ぶところがありそう。
さて、、、次は加速度を制御しなきゃならないはずなんだけど、コマンド型サーボでそれは難しい。 なんとか回避する手立てはないものか。。
今日は逆運動計算のまとめ（検算と記録を兼ねて）と、センサーボードをちょこっといじってみた。ジャイロを３軸にしてからセンサー情報って取得してみてなかった。うん。ちゃんとデータ取れてるねー。こうして出来合いのボードを買ってつなぐと楽チンで仕方ない。取り付け方を変えているのでデータの割り当てが変わってるのに注意して、加速度データも角速度データもOKです。
さて、これを使って簡単な姿勢制御のプログラムを書いてみよーっ。 明日から。。
■５月２３日■
「アンドロイドの脳」を読むと感慨深いところがある。
人工知能について一生懸命考えていた頃がある。その頃、人間の脳の本や認知工学の本などを結構読んだ。また人工知能工学の本も読んだのだが、人工知能工学については首をかしげる事ばかりだった。研究に従事している人たちは本当に、ゆくゆくは人工知能を作りたいと思っているのだろうか？なぜ異常なまでに条件を絞り込んだ状態での問題（サラリーマン巡回問題とか）の数学的解法なんかを考えているのだろうか。不思議で仕方なかった。結局、自分が人工知能に少しでも近づくには人工知能工学は不要だと判断してその類の勉強はやめてしまった。（ニフティーサーブのＡＩフォーラムで、人工知能上で時間の概念ってどう表現するんですか？って質問してみたら、「タイマーでいいんじゃん？」って答えが有ってから不信感が募ってたってのもあるけど。）
その後、知能には外界に働きかける能力が必要で、視覚・移動能力・物体を触れたりつかんだりする能力が最低限必要と思うようになった。移動能力は車輪と操舵でもいいんだけど、「移動手段の獲得」というテーマも面白そうなので足が面白いかと思った。アイボはそういう意味で研究にはうってつけの題材だったのだけど、身体制御という観点では自由度が足りないとか２足をやりたいとかいう気持ちから２足に手を染めようとしてる。
考えると自分の思うところがありながら色々な理由を盾になんとなく流行に流されたり考えを修正したりしている自分がいて、恥ずかしい気持ちになった。身体制御の学習・最適化などの研究をするにはコマンド型サーボはうまくなく、また、トルクやコンプライアンスをリニアに制御できない通常のラジコンサーボでは機能が足りなく、またリアルにサーボを制御するためのマイコンと脳（大脳とか小脳）となるコンピュータをリアルにつなぐシステム（せめて共有メモリシステム）とか、自分で構築しなきゃならないんだろうなと思う。
まぁ、それはさておき、意見としては、ロボット（アンドロイドでも）を構築するのに人間や類人猿をいくら真似ても追いつかないと思う。上下からの攻めが絶対に必要で、制御工学に固められた部分とコネクショニズム（みたいなの、どんなのが正解かわからん）に導かれた部分がうまく融合するシステムを作り出さなきゃならないと思う。偶然に頼るわけには行かないだろう。ルーシーでのアプローチだと昆虫は超えられないような気がするなぁ。あと２～３段のジャンプがいる。この調子だと次のルーシー（手足が揃う予定）も床でもぞもぞするだけなのではなかろうか。歩き出したりしたら多分宗旨替え。
そういうわけで、足レベル、腕レベルでの逆運動学計算ってのは折込済みでよいと思ってる。そこから先のダイナミック部分をどうするかってのがメインになりそうな予感。そこでＣＰＧに期待大。引き込み現象ってのをじっくりと吟味したいと考えてる。
ところがＣＰＧに関する資料ってあんまり見ない。CPGで検索しても専門書らしきものに当たらないし。こまったな。
５月２４日■
身体動作との同期
関節で接続された身体を、いくら大まかに計算しても１点重心として捉えて運動を考えるわけにはいかないだろう。関節でのがたつきや実際の関節の動きなどから構造の「やわらかさ」が出てしまう。その動作については支点部と作用部で相当な遅れが生じてしかるべきで、１点重心の考え方だと、常に剛体として捉えている事になる。
人の場合でも、力を抜いた歩行をしている時は剛体とは程遠い、やわらかい状態なので同期するには非常に低い振動数となるはずである。力を抜いた歩行ではその低い振動数に合わせた歩調となるため、ゆっくりとした歩みになる。 反して急いで歩く場合、これは各関節に力を込めて同調する振動数を上げて、目的とする歩調を確保することになる。更に素早い動作が必要な時は、出来るだけ剛体として考えられるように力を込めて体を丸め、目的とする速度（振動数）での動作が可能なように調整すると考えられる。
CPGは周期を出力できて、外乱に対して同期することができるけど、周期内のカーブを記憶・再現することはできるのだろうか？
たとえば、ブランコ。要は振り子なのだが、子供はブランコに同期して揺れを増幅させる。あの時、感じているのは揺れの周期だけではなくて確かに揺れのカーブを感じている。振れが最大の部分では速度が遅くなりやがて戻っていくことを、もっとも地面付近ではもっとも速度が出ていることを体験から知っている。そして、揺れに同期させる時にはその感覚を利用していると思われる。
なんとかこれをモデル化するアイディアはないだろうか。
人間はどのようになっているのか内観してみる。
感覚が感じられる時間の長さは有限で、結構短い。大体、タンタンくらい。あとはそれを意識的に計数して長くする。
ターーンというのはココロのなかでタアアアンと変換している。感じられる範囲での時間の分解能は相当細かい。ただ、意識できるかどうかは小脳の発達具合で変わるような気がする。（ここでは小脳の感覚を大脳が受け取るといった意味での発達）
なかなかいいアイディアも浮かばないのでとりあえずは左右に体を揺する無限モーションを作ってみた。片道０．３秒に設定したら、大体同期した感じ。ひょこひょこと歩き出した。いまはサーボのコンプライアンス設定を相当緩めにしてるからゆっさゆっさしてる。こんなんでも動き出すとうきうきするね。まぁ、制御してないから直ぐコケルけど。この同期周波数を自分で見つけるようにしたいんだよね。そして、同期して吹っ飛ばないように制御できるようにしたい。
５月２５日■
ラムダの外装を作りたいなー。っていうか、設計してる時からちゃんと外装つけようって思ってたんだけど、外装なんて、外装ありきで設計しなきゃうまくできるもんじゃないね。３ＤCADの前で何度書いては消してを繰り返したか。実際に作れる形・構造で、デザイン的に優れている、そして内臓物がすでに決まってるって条件だもん。なかなか出来ない。手足のイメージから、参考にするのはガンダムに出てくるザクかなーって考えてたけど、ザクはあんまり好きじゃないし、ガンダムは嫌いじゃないけど、ガンダムライクのロボットを作ってるんじゃないからあくまでデザインの参考ってことで。ガンプラ雑誌をパラパラめくってて、かっこいいのを見つけた。ポケットの中の戦争（だっけ？）に出てくる、ケンプファー。そういやむかーし、ビデオ借りて見たな。これは気がつかなかったけど、すっごく僕が好きなスタイル。ちなみにバーチャロンで言ったらアファームドが好き。そういう感じ。これを参考に外装をデザインしていってみよー。でも、兵器っぽくなるのがちょっとね。夢はコロ助なのに。あ、コロ助も武士だから兵士だ。(^^ゞ
ケンプファーね。1/100MG 部屋に飾りたいな。
５月３１日■
ほぇ～～。 なんとか、Cygwin上でRPU-100で動くバイナリーを生成できるコンパイラーを作れた。(>_<)
スピーシーズが届いた頃にCygwin上で開発環境作りたくて頑張ってたんだけど、うまく行かなくてデスクトップにNetBSDをインストールしてクロス環境を作ってた。（それも結構苦労したんだけど） Cygwin上で、コンパイラは作れたけど、ライブラリが出来なかった。今回はどうやら、「クロスコンパイラはgcc2.9.3で作るのが良いらしい」とかいう情報と、ライブラリはNetBSDから持ってくるってことで再挑戦。 しかし、やはりというか前回よりもうまく行かなかった。コンパイラのコンパイルさえできなーい。 でもー、なんのことはない。初めに挑戦した時にgcc3.4.1で作ったクロスコンパイラにNetBSD上で作ったライブラリを入れたらワーニング出しながらも実行ファイルが出来た。なーんだ、ライブラリ持ってくるだけでよかったんだ。随分と無駄な時間を過ごしてしまった。さあこれでファンの音がうるさいデスクトップマシンを使わずにプログラム開発ができる。VMWareの導入も検討してみたけど、有料だし、コーディングをWindows上でしたかった（NFSとかsambaとか使えば出来そうだけど。）ので、ちょっと躊躇だったんだよね。 思い切ってVMware買っちゃわなくてよかったー。
まっ、まだ使い込んでみないと、gcc3xxにはコンパイバグがあるとかいう話も聞くので要注意。
ちなみにワーニングはインクルードファイルでの各種宣言が重複してるとか。ぼちぼち直すか。
＜おそらくここらへんがポイント＞
・gccのソースはCygwinのアーカイブから持ってくる。←Cygwin向けのパッチが当たってるところがポイントかと。
・ターゲットは「powerpc-netbsdelf」←どこで得た情報か？前回すでにこれで作ってた。
・configureのオプションに--with-newlibをつけて、とにかくコンパイラだけ作る。
・crt0.oとかはNetBSDから持ってきた。←この辺はgcc3.4.1のライブラリディレクトリにないとダメみたい。
６月５日■
プログラム開発はC++でやりたいと考えているのだが、cygwinで動くクロスコンパイラではC++（g++）ではリンクがうまくできない。調べた結果、原因はコンパイラバージョンにあるということがわかった。どのバージョンからかはわからないが、C++の時はlibstdc++を明示的にリンクしないと
undefined symbol: __gxx_personality_v0
とでてしまう。cygwin上の環境だと、ライブラリは多分gcc2.9.4で構築したもので、コンパイラはgcc3.4.1だ。libstdc++.aをojbdumpしても、__gxx_personality_v0なんてシンボルは出てこない。（MLの書き込みなんかを見ると出てくることになってる。）
もう一度gcc2.9でのクロスコンパイラ構築に挑戦するかぁ？？もうやだなー。2.9のcygwinパッチが見当たらないしなぁ。3.4.1でのライブラリ構築も道が長そうだし。 でなければ、一度は却下したVMWareの導入。これは一見良いのだけど、イマイチ使い勝手がよくない。XWindowがサポートされてないしねー。3万円くらいするし。 あとはC++を諦めてCで書く。これも難しい。STLとか一度使うと便利なので、その他の細かい言語仕様の改善も合わせてCに戻るのはつらい。簡単なプログラムならどっちでもいいけどね。
６月１２日■
結局、開発環境はVMWareでやることに。しばらくは試用版で。とりあえず、VMWare立ち上げるたびにスピーカー音量が最大になるのが困る。うっかり音が出ることやると大音響でびっくりする！！一応、C++でリンクもできたし、STLも問題なく使えるのでよしだ。一気に動作用基本ルーチンを書き上げてしまおう。どうも、動作の制御をどのようにするのかが決まらない（浮かばない）ので基本部の構成も決まらない。全身同時なのか、上半身下半身なのか、四肢ごとに制御とか、、、 ま、あとで変えればいいんだけどね。
サーボの不具合が解消したらしい。ファームアップするためにサーボを全部送り返す。（RS485経由で送り込めるようにはできていないのかな。）そのためにラムダを一旦ばらすことに。サーボが戻ってきたらちゃんと組み立つのか心配になってしまった。 膝関節部分のでっぱりがちょっと気になってたからこれを機会に構造変更しようかなと思ってＣＡＤでちょこっと検討したけど、どうも気持ちよい形にならないからやっぱ今のままで。構造改良はもうちょっと動かしてみてからの方がアラが出ていいかなーとか、都合のいいように考えて先送りにする。
外装を考えたけど、服っていうか、ガーターみたいなのでいいかもと思い出した。剣道の防具みたいな感じで胴体や腕・足に取り付ける。衝撃吸収剤なんかを入れ込めば結構いけるのではないかと。 メンテも楽そうだし、ちょっとやってみようかな。ロボットぽくないからだめかな。
６月２５日■
イロイロあってラムダごとあんまりやってなかったんで、日誌の更新もしてなかった。
先週無事サーボが戻ってきてラムダを組み立て直した。足だけ組んだところで一度動かしてみて問題が解消しているか確認。うん。。。とりあえずサーボが固まることは無いみたい。データ取得時間が長くなったかどうかとか性能がらみまでは見れていないけど一応ＯＫってことで全組み立てした。
予定通りケーブルをラムダ専用のマルチケーブルにしてすっきりと・・・、なかなか難しいけど、標準のケーブルでつなぐよりは綺麗につなげてるからこれもＯＫにしちゃおう。標準のケーブルよりはちょっと細いんだけど、最大でも足１本当たり２～３Ａだろうから十分かな。きっと。
VMWareの試用期限がとうとう切れそう。 あと３日、使い勝手も慣れて来たからご購入で。 ライセンス買うのはいいけど、試用版をそのままライセンス継続できるのかなぁ。またＯＳインストールするのめんどくさくってやだな。ＯＳ入れて設定して、サンバ動かして、コンパイラ入れて。。
ケーブルも配線できた（片足だけだけど、）し、C++でのプログラム体制も大体見えてきた。あとは外装かな。 あ、頭も。手も。肝心の制御プログラムはまだまだだし。orz
綺麗に配線した左足。良く見えないな。(>_<)
７月７日■
なんとなく、心のうだうだしたところが晴れてきて、プログラミングが出来る精神状態になってきた。（大げさか？）やらなきゃやらなきゃと思いつつやってなかったシグナルを使ったスクリプトプログラムに着手。
やれば結構簡単で、もうすぐできそう。やっぱりC++を使ってSTLでデータ管理するようにするとコーディングは数段楽になる。Cに比べたら記述性もいいし、C++だなぁ。マイコンのプログラムなんかはCで問題ないと思うけど。
キーフレームの列を用意しておいて、それを順次実行するってプログラムなんだけど、常に全身のデータを用意するのってナンセンスだから、部位毎にデータを持つようにする。足・腕・胴体・手・頭ってカンジ。最終的には各部位が協調動作しなければならないわけだけど、それは各処理の結果として扱いたい。手だけを動かす時にも胴体や足は「こけないように」フィードバック制御がかかってたりしてデータが不要なわけじゃないんだけど、スクリプト実行して終わりってプログラムを書く気は毛頭ないから基本設計は試行錯誤が必要。考えていくとどんどん先に行っちゃってまとまらなくなってしまうから程ほどにしないと行かんけど。
アイボの歩行の時は、クロール歩行のみって考えて、足の動きを関数化して、各足の位相遅れを設定してってカンジに仕上げたけど、２足歩行や上体との同調動作ってそれほど簡単じゃない。動きも複雑だから関数化ってのもどうかと思う。でも、突き詰めて考えるとある意味関数化して、位相遅れ、、かどうかはわからんけど左右の足や胴体、腕との同調動作で歩くことには変わりないはず。パラメータや動作パターンがべらぼうってだけかも。
問題はデータの表現方法。（直交）座標列じゃないし、角度列でもない。本質的な動きをデータ化したいって気持ちなのだが、結局は物理量にしなきゃならないんだろうな。関節の構造から考えると角度で管理したいところだが、座標と角度の関係が複雑なのでどうなのか？バリスティックな動作を目指すなら角度で考えるべき。足だけならそれでいいが、腕は用途によっては直交座標の方がいいのか？ あ、そうか。極座標系だ。極座標なら根元関節は角度で表現して肘角度や膝角度は長さ表現になる。極座標⇒直交座標⇒角度列（サーボ角度）って感じか。
パターン記憶にはアソシアトロンを使った連想記憶なんかも使ってみたいけど、それはそのうち実験してみよう。記憶すべきパターンの中にコンプライアンスやトルクなんかも必要。コンプライアンスコントロールって各関節毎に必要なのか、部位全体でやるべきなのか。部位毎でいい気もするけど、色々試すとこかな。データが多くなるのはいいとして、データの生成手段が必要。学習の仕組み考えなきゃ。
７月１０日■
右腕まで配線したところで材料が切れてしまって、作業が止まっていたケーブル配線もとうとう完成。下半身と上半身をつなぐ配線に相当悩んだ。考えたら頭も手も上半身に有るから電流も大きくなる。電源ライン太くしても１本じゃ心細い。考えた末に両手の配線と、胴体と頭の配線を分けることにした。関節の軸部に配線を収容するつもりだったけど、ザクのエネルギーチューブみたいな配線になってしまった。これも身長を低くするために詰めた構造設計をしたあおりだな。仕方ないとしよう。いくつかケーブルサポート金具を作らないとイケない感じ。仮止めしてるけど、頭部金具作る時に一緒に作るとするか。そういや、カメラを収納するプラケースを探したけどいいのが無かった。プラ板張り合わせて作るのがいいかな。
配線ができたけど、腕の逆運動計算も胴体の計算式もまだ作ってない。さっさと作っちまわなきゃ。
線材を買いに行ったついでに頭部サーボモーターの制御マイコンのための部品も買って来た。次はマイコンプログラムだ。RS485のインプリメントしなきゃ。
外装は装甲にするのは大変だから、アイスホッケーのプロテクターみたいな形式はどうかな？と考えてる。マジックテープで止めれば分解取り付けも楽だし、緩衝にもなるんじゃないかと思う。胴体部分は自由度増やしたおかげでカタチが複雑。どうしたって外装は難しそうなんだよなー。困った。
・・わかんないな。 
やっぱわかんないね。
７月１７日■
逆運動ベースでのデータスタックからモーションを再生できるようにはなった。四肢と胴体用のデータスタックを持っているので部位ごとに動作させることができる。逆に同期動作させるには、それを気にしてデータを作らなきゃならない。同期キーとかも要るね。 歩行動作なんかを計算かなんかで生成して、スタックに入れていけば順次実行するって感じにしたいと思ってる。当然、手作りモーションも再生できるけど、逆運動データでモーション作るのってイマイチ。
次にできる一番簡単なことは関節角度ベースでの再生とモーションキャプチャーでモーションデータを作る。ただ、これはあんまり乗り気がしない。ラムダに、踊りを踊らせたり、観客に手を振るとかいう、仕込み的な動作をさせる気はない。立ち上がる動作とか、座る動作、転倒からの復帰など、使わなけりゃならない部分もあるから実用的には必要ななずなんだけど、それさえも自律動作で実現したいなぁという思いが先にたってしまう。早く自律させるには必要なんだけどぉ～・・・
さっさと作っちゃえばいいやとか思っても、すぐに思考が自律動作での立ち上がりモーション作成のアイディアとかに摩り替わっちゃう。またいつものパターンだ。(>_<)
７月１８日■
と、いうわけで、モーションキャプチャーして、モーション再生をするプログラムは出来た。くだらないバグのおかげで、何度もラムダの足があらぬ方向に曲がったりした。(>_<)
せっかく列挙型変数を使ってるのに違う用途に流用して使ってたのが仇になった。列挙型にする意味がないってば。(T_T) 全身のサーボデータをキャプチャーするので無駄に大きなデータになる。やっぱ、ブランクデータ（何もしない）や同期キー、トルクやコンプライアンスをデータに折り込むなんてのをしなくちゃならないなと改めて思った。 それだけでも意味があるかも。 立ち上がるモーションを作ってみたけど、編集機能が十分ではないせいか、うまく立ち上がれない。
片足を上げるための体重移動動作のコントロールについて思案中。姿勢（足の長さとスタンスの広さ）と、速度と移動量をパラメータにした時にどういう動作が最適なのか、ヒトが調整するのではなく、ロボット自身に判定させるようなことはできないか。関節の負荷情報でなんかできないかなー。そういえば、ジャイロデータをうまく使えない。オフセットがあるから直読みデータのままじゃ使えない。閾値も設定しないとまずそう。
アイディアというか、やってみたいこと、やらなきゃならないことがごちゃごちゃしてて整理が必要。今年は帰省しないらしいから、お盆辺りに集中して検討・作業できればいいんだけどな。 それまでに事前検討を進めておこう。
７月２４日■
足踏みするための確認なんぞをしてたら、足の逆運動計算がおかしいことが発覚！ 結局、腕の逆運動計算を組み込んだ時に足の長さパラメータと腕の長さパラメータを間違ってしまっていたことに気付く。 逆運動計算の式を別ページに掲載しているが、イロイロと間違いがあるのが発覚したので、関節番号の整理とかも含めて全部直してみた。順運動計算と照合したりすればいいことなんだけど、なーんとなくまだ間違っている気がするんだよね。ま、いいっか。発覚した時に考えよう。
７月３０日■
足踏みのパラメータを色々と変えたりしているのだが、どうもモーション再生プログラムに不備がある。モーションのつなぎ目で一旦動作が止まってしまう。そのため、反動が起きてしまって美しい動きができない。割り込み処理が間に合ってないとか、サーボのタイマーと割り込みタイマーがあってないとか、色々確認したけど、そのあたりは問題なさそう。サーボへのデータの与え方かもしれないな。メモリーに直接書き込んでるんだけど、動作開始のためにラグが発生してしまうのかも。このサーボはしっかりした作りをしてるんだけど、まだロボット用には洗練されてない。バッファがないし、リニアな動作しかできないし。FIFOバッファは欲しかったなー。
インターバルタイマー割り込みが動いている時にサーボを読みに行くとうまく読めない問題で、受信データのチェックサムなど確認してみた。標準のデータ取得関数はチェックサムの確認を行っていない。 確認してみたら、結構な確率でエラーが発生してる。こんなにエラーが発生するならチェックサムの確認は必須だな。標準関数にも折り込むべきだ。 結局、インターバルタイマーを止めないとまともにデータ取得は出来ないってことで、割り込み関数内での取得は別にして、その他の箇所でのデータ読み込みの際にはインターバルタイマーを止めるようにした。
頭のサーボの制御用のマイコンに着手したいんだけど、なかなかできないね。マイコンイジッてサーボ動かしたりRS485 をつなげたりする方が没頭しちゃいそうだからちょっとがまんだ。
７月３１日■
サーボデータのつなぎ目がうまくいかないので、頭のRCサーボ制御用のマイコンをいじることに。 この手のマイコンを触るのってすっごく久しぶりだな。結構楽しいんだよね。ベストテクノロジーで購入したATmega32マイコンボード。こんなにちっこいのにすごいね。
サーボの制御信号はサンプルプログラムも有って、大丈夫っぽいから、RS485の方を心配してみる。RS232Cに使ってるUARTをそのまま使おうかと思うので、デバッグ時に表示手段がなくなっちゃう。ってことで、ごそごそとむかーし買ったLCDモジュールを取り出してみた。これはV25マイコンボードで動かした事があるぞ。あるけど、もう忘れちゃったな。V25のソース探そうかと思ったけど、チップデータデータや当時の資料が出てきたからそれでドライブしてみることに。
うぅぅぅ、自分のメモがめちゃくちゃいい加減だ。でも、まぁ動いたからいいや。 ATmega32のコンパイラ、ライブラリは非常によくできてるのでRS485も簡単に動くかも。
ちょーバラック状態
８月１０日■
サーボデータのつなぎ目がうまくいかない件などで、スピーシーズに問い合わせをしたところ、きちんと制御すれば十分できるという答えが返って来た。ふむ、確かにきちんとはしてなかったし、サーボの応答曲線（というか、サーボがコマンドに対してどのような制御をしているか）を確認もしてなかったからちょっと反省。コマンド実行時の応答曲線とか取得してみて、再度検討してみることにしよう。
それはさておき、マイコンの方は結構順調。一生懸命モニター用にＬＣＤをつないだけど、GCCライトのUSARTライブラリーを使って一発で通信できた。通信ははまると大変だから心配してたけど、よかったぁ～。RS485のA線B線もどっちがどっちかわからんかったけど、2分の1の確率で正解だったみたい。マイコンからの送信のテストはしてないんだけど、まぁとりあえずは受信さえできればいいやってことで後回し。今度はサーボ信号の生成なのだが、サンプルプログラムの高速PWMが理解できない。ってーか、ATmega32のレジスタ設定わからなきゃなにも出来ないな。英語マニュアル大変そうだから探してみたら有志にて日本語訳されたデータシートが見つかった。ありがとう、有志のみなさん！サーボのＰＷＭ信号ってデューティー比がいびつだから感嘆には作れないんだよね。なんか細工が必要。こういった組み込み用のタイマーカウンターにはPWMがついてるけど、普通はデューティー比0～100までカバーしてるのが普通。RCサーボの方が特殊なんだろうな。
結局、割り込みを使いまくって16ビットカウンター1本で４個のサーボをカバーする事にしよう。計算では８個くらいまでカバーできそうだけど、そんなには要らないな。
とりあえず、位置指示ができるようにはなった。あとは速度パラメータを受け取れるようにして、RS485で通信すればできあがりだな。結構簡単にできた。(^・^) 一番苦労したのはLCDの表示だったりして。(>_<)
あした、秋葉原にいって、本組用の部品類を買って来よう。無計画に部品をつけていったからすごいガラクタ状態。作り直しても変わらなかったりしてね。本番の基板にはLCD接続用のコネクタはつける必要あるかなー。迷う。
とうとう板金部品を作らなきゃ。夏はやだなー。
８月１１日■
今日は秋葉原にお買い物。マイコン部分が大体できたので本番用の基板を作る。木曜日なのにすっかり日曜日気分で行ってしまったので、秋月電子が定休日だった。幸い秋月じゃないとだめな部品は無かったから問題なかったけど。秋月の定休日は月曜・木曜でした。
いろんなネジが売ってる西川電子の2階にはRPU-100で使ってるEHRタイプコネクタを扱ってる。ケーブル側はスピーシーズで買った方が安いけど、基板側が手に入るのは良い。
表面実装部品各種は鈴商と千石電子で買えた。どこの店もリール品を切り売りしてて大体10個100円とか。高いけど仕方ない。そんなに数要らないしね。チップLED各色とチップ抵抗。あと、チップダイオードを購入。チップスイッチもいくつか買っておいた。
SMD用基板（サンハヤトのシール基板）が欲しかったけど、売り切れでなかった。仕方ないな。バラックと同じ、空中配線でやるしかないか。
マイコン基板をどうやって取り付けようか困ってたけど、とりあえずはプラケースに押し込んでボディーのどこかにくくりつけることにする。構造がまとまったらスマートに取り付けよう。 カメラ基板と同じケースが使えそう。サーボのコネクタって極性が無いから怖い。逆につないでも、電源逆接にならないようにはアサインされてるけど、ここは一つ、EHRの3ピンに取り替えておこうかな。安心だし。
若松は店舗移転したの知らなかったけど、なんだかさびしくなったな。移転してからあそこで買い物したことない。
ヒロセはコネクタいいのないかなーと思って行ったけど、意外とコネクタは品薄。なんだかネジが豊富なんだよね。小径ネジのタップバイスが全部揃ってたりして、不思議。
M2.3のネジもちょびっと売ってる。
LCD接続用のコネクタを実装するかどうか迷ってる。最低でも5ピン要る。要らなさそうだしなぁ・・・。代わりにモニター用のLEDをいくつかつけようかな。
８月１２日■
昨日買ってきた部品で、マイコン部分の作成。回路は簡単なもの。一応回路図描いたけど、書くほどじゃないなぁ。
基板から作ったらもっともっと小さくできるはず。でもまぁ手間を考えたら上出来。
LCDモジュールの接続コネクタは結局設けなかった。USARTの送信ポートだけはRS232CとRS485で共用。（受信はスイッチで切り替えて使う。）初めっからLCDなんて要らなかったってわけだ。ハハハ(>_<)
サーボモータのコネクタも3Pの極性付きコネクタにしてみたけど、位置情報を取りたいからポテンショメータから線を引っ張ってこようって思ってたのを忘れてた。ま、アタマはいいか、オープン制御で。あと、3～4Pのコネクタが2個くらいは乗るからとりあえずは間に合うかなー。
サーボモータ用の電源はダイオードかまして電圧落としてる。まだちょっと高すぎるんだけど、支障なく動いてるからまぁいいかと。リポ乗っけたら電圧高過ぎてまずいかもしれん。
結局昨日買ってきたケースには納まらないサイズになってしまった。プラ板貼り合せて作るとします。
８月１３日■
お尻にスピーカーを実装。(^.^)
スピーシーズOSが立ち上がるのをＬＥＤ見ながら待つのがいやなんで、「立ち上がりました。」ってしゃべらせる。 /dev/sound から出てくるデータってどういうフォーマットなんだろ？ヘッダーとかないからホントーに生の音声データなのかな？モノラルならわかるけど、マイクはステレオ。なのにちゃんと再生できるのはなぜだ？
あとは、カメラとマイクとLEDだ。（アタマと手もあるな。） おとといに秋葉原行って、PSDは要るなぁって思った。
８月１４日■
なんだか、工作したい気持ちが強い。
アタマ用マイコンの実装ブラケットを作る。これは下半身と上半身間のケーブルのホルダーも兼ねている。プラカバーはヤメ。
アタマ部分の構造も出来てきたから来週の土日くらいに作ろうかな。しかし、真夏に板金工作はキビシイね。汗まみれだ。
最低でもあとカメラ用の配線を下半身－上半身に引き込まないとならない。ちょっとキビシめだけど、ギリなんとかなるかなー。身長が低くなるようにって考えて設計したから、ケーブルスペースが足りない。
ついでにLEDも作ってみた。これはまぁ、ご愛嬌。チップＬＥＤが気に入ったから作ってみた。スピーシーズロボットキットでは目の部分に入ってるLED6個。 アイボのときもLEDってほとんど使ったこと無かったし、ラムダできっと使わないんだろうけどね。状態表示くらいには使えるだろう。RPU-100に付いているスイッチとLEDが事実上使えない。（上半身に隠れていてアクセスできない）代わりになるものは要るのだ。あと、スイッチが要るな。アタマ用マイコンからケーブルで引き出すかな。
配線がモロだしだから、スモークのかかったアクリル板とかでカバーした方がよいな。 とりあえずです、とりあえず。。
LEDは胸に光らせたいんだけどなー、構造上、胸に実装するのは結構大変そう。
８月２１日■
とうとうラムダにもアタマが出来た。 この土日で基本的構造部分はほぼ完成した。メインになるフレーム部品を二つも作り直したりして、結構大変だったー。でも、アタマが付くと、それだけでなんか愛着が更に深まった感じ。うれしいな。 板金部品の精度のせいで、設計どおりの可動範囲がなかったり、まだ改良しなきゃならないけど大筋OK。
アタマが無いときは上体旋回用のサーボモータがなんとなくアタマみたいな感じになってた。小顔の感じで、巨大ロボのプロポーションだったんだけど、こうしてちゃんとしたアタマがつくとプロポーションも変わってくる。下の画像だと、床に寝かせた状態で、足首が伸びてるから身長がちょっと大きめの印象があるけど、頭が無い時に比べたら随分と子供体型になったかな。身長相応の印象で良い感じだなと思ってる。こんなに小さいのに「巨大ロボ」のイメージだったらおかしいもんね。
構造的にはあとはマニピュレータだけだな。マイク取り付けとか、外装とか残ってるけどね。
LEDの取り付けとか、ケーブルサポートとかもちょっとずつ変わってる。
これで身長はいくつになったのかな？
サイトのメニュー画面の画像とかも変えないとね。
そういえば、、、 ロボワンの参加申し込みが終了した。もしかしていい感じで仕上がったら出てみようかなとか思っていたけど、まだまだだなぁ。次回も危ういかも。 ロボワンより、ロボワンダッシュ（だっけ？）とかロボカップの方がラムダの開発コンセプトにはマッチしてる気がするからそっちへの出場を考えようかと思ってる。
実はこの土日のメニューはまだ他にいくつもあったのだけど、機構構造関連の作業しかできなかった。最近、ウィークデーに仕事から帰ってからあまり作業ができないからちょっと進捗が少ない。
８月２３日■
首の可動範囲を思惑どおりに広げるためにいろいろと加工。ちょっとみっともなく板金を削ってしまった。 で、電源入れてポーズ。(^.^)
ケンプファーがいいとか言ってたが、この顔のでかさはボトムズだな。
そのあと、足ふみの練習をしてるときに、つんのめってコケてしまった。 すると、あらら、首のサーボのギアが飛んでしまった。 とりあえず、アルマイトギアに交換するとして、こけた時のガードは必要だな。 なにより、何の仕事もしないままに昇天してしまったファイナルギアよ、ごめんなさい。 あと、パラメータ調整中はアタマは外しておかないとね。
足ふみしてたらだんだんと膝のサーボモータが熱くなってきた。やっぱヒートシンクいるかなぁ。つけたくないんだけど。。
８月２７日■
やっとコンプライアンス設定のインプリメントのイメージが出来てきたのでコーディングを進める。
せっかくのコンプライアンス設定を関節のケイレンを止めるだけに使うのはもったいないから、着地時のクッションなどに使えるように考えている。使えそうな設定はコンプライアンスマージン・コンプライアンススロープ・トルク率・パンチなど。結局、スロープとトルク率をメインで使って、マージンも一応使えるように作りこむことにする。 パンチは初期設定だけでよさそう（実際はデフォルトのままでよさそう） その他、加減速時間というのもあるが、これも操作する必要はないかと思ってる。
結局、
１．初期設定：パンチ・加減速時間・コンプライアンスマージン・コンプライアンススロープ・トルク率
２．状態にて切り替え：加減速時間
３．動作に応じて逐次切り替え：コンプライアンスマージン・コンプライアンススロープ・トルク率
という感じか。
アイボでは8msという最小フレームごとの角度データを指定していたが、ラムダでは基本的にリニアな動作に限定して、サーボへの動作指示は最小限に少なくする方向で考えている。構想段階ではフレーム単位の動作指示をすることを考えていたが、バリスティックな動作をするにはそうではなく、ゆるい関節にて低いトルクで動作すべきなんだろうと考え出している。実際、細かな指示をしても、関節のがたつきなどからそれほど厳密な再現性は得られないのであるから、CPUの負担を小さくすべきなのだろうと思う。（その分その他の制御・分析にパワーを回す）
そういった考えをまとめつつも、気になるのは工作の進み具合。アタマ部分のケーブリングや、カメラ信号のRPU-100への引き込みをどうするかということばかり気になる。気になって気になって仕方ないので先にそちらを片付けることにした。(^^ゞ
RS485のケーブルは、適宜アセテートテープで固定して、外装で隠そうと思っていたが、あちこち仕上げていくうちにちゃんとナイロンバンドで固定したくなってきた。 下半身は1箇所を除いてケーブリングは完了。残った1箇所は難しいな。テープのままの方がいいかも。 あと、腕のケーブルは板金部分が少ないからテープ固定のままの方がよさそう。
注文しておいたアルマイトギアが届いた。早速ギアが飛んでしまったサーボに取り付ける。硬いと聞いていたが硬いっていうか手じゃ入らない。万力でぐりぐりっと押し込んだ。センター合わせに苦労した。
アルマイトギアと、プラギア。アルマイトギアは1500円もするんだよね～。高いよ。高い。
足首部分のアップ。ナイロンバンド用の穴を開けて、きれいに整線。関節の動きでケーブルが摺れたり挟まったり引っ張られたりしないように注意。
配線周りもだいぶんまとまってきたなぁと思っていたのにあまり綺麗じゃない。これからRCサーボを使った頭部分の配線をしなきゃならない。カメラも、PSDも3本ずつ出てくる。もっとぐちゃぐちゃになるのか。。。やだなぁ。(>_<)
さて、工作はこれくらいにして、サーボ制御を進めなきゃ。頭ユニットのマイコンソフトとかPSDとか、カメラ画像とか、サウンド設定とかやりたいことがいっぱいあるのだ。
８月２８日■
昨日に引き続き、コンプライアンス設定のインプリメント。加減速時間設定というのがあって、スムーズに動くために動作開始、動作終了付近で加速減速動作をするもの。初期のサーボの設定では10msという数値が設定されている。このためにモーターを反転させるような動作をさせても無理の無い動きをするのであるが、同じ方向への動きを連続させるといちいち減速するためにカクカクする。
この設定を動作に合わせて入れたり消したりしようと思ったのだが、ここで問題発覚。サーボが動作している最中に加速設定を入れると、おかしな動きをする。グラフで妙な振動がでているところがすべてそれである。 またもサーボの問題なのかなぁ。。。
とりあえず、トルクとコンプライアンススロープ・コンプライアンスマージン設定をモーションデータに埋め込めるようにした。
動かしてみると、、、 柔らかい関節設定を硬い関節設定に切り替えると、その瞬間にビキッと音を出して硬くなる。使い方難しそうだな。 胴体や腕は歩く時はスロープ緩め設定。足は硬め設定。こけそうな時などはの関節だけゆるめにするとかね。
さて、次はセンサーボードからジャイロデータを取り込んで、姿勢安定にフィードバックをしてみる。これがやりたくてやりたくて。。 (>_<) ふらふらしながら立ってる方がロボットっぽいし、動いてる感じするもんね。 何度かジャイロデータを取り込んでみたんだけど、積分のしかたとか、オフセットの処理とか調整が必要そう。
あと、アタマユニットを仕上げてしまおう。ケーブリングとか、マイコンのソフトとか。
ジャイロのデータ処理に着手する。ジャイロからのデータを積分して姿勢角度を出してみる。 放置していたら変な値になるからよく見ると、数十秒おき（不定期）に「25087」というデータが送られてくる。ロボットは静止しているのに？？？
放置中。ちょっと悲しげ。。。
よく見えないけどエラーって書いてる。なんだろなー。サーボとセンサーボードは中身に手を出せないからちょっと困る。とりあえず、25087というデータはエラー扱いにしてみた。