手抜きで取り込んだからちっこい画像になってしまった。過去の開発日誌1へ
過去の開発日誌2へ
過去の開発日誌3へ
過去の開発日誌4へ
■１月５日■
帰省中はＷｉｉ三昧。(^.^) ２個目のＷｉｉコントローラーも要るだろうから、「はじめてのＷｉｉ」を買って帰ったんだけど、なかなか面白い。 周りの人の受けもいいので「Ｗｉｉスポーツ」も買って来た。これがサイコーに面白い。 Ｗｉｉコントローラの真価を発揮できるのはやっぱりスポーツゲームだね。なかでもテニス・ゴルフ・ボーリングが面白い。エキサイティングなのはテニス。 誰でもできるのはボーリングかな。 パーティーゲーム的にやるのがいいのはもちろんだけど、一人でも出来ちゃう面白さ。 さすが任天堂。すごいなぁ。。 あとは期待のマリオを待つばかり。
親類のちびっこどもがＷｉｉに興じている間は「ロボットのこころ」を読んでいた。
この本ではロボットに知能を持たせるための数々の問題のうち、言葉を理解すると言う点に焦点を合わせて話を進めている。 言葉を理解させる上で、言葉の「意味」をどのように表現するかということが第一の問題となるのだが、これは「身体運動」と結びつけた「身体運動意味論」を展開している。想像することやイメージすることも「身体運動」を伴う活動として表現するが、実際に行動を起こさないことが異なるとしている。基本的な言葉・単語の表現としては自分が考えていたこととほぼ一致する。問題はそれらの実現方法なのだが、この本では、実現するためのハードルとして
って、そこがキモなんじゃないの？それら一切合切が白紙ってのはちょっとアレだな。 ・・考えている視点が近いので問題を整理したりするにはいい本を見つけたなとは・・思う。
だがしかし、この本で書かれている身体運動意味論というのは出来るだけ速やかに実現させなければならない。なぜなら、小脳運動もある意味身体運動意味論で活動していると考えているからである。下半身運動の多くのパラメータを一括して管理し、運動から学習を進めるためのデータ管理学そのものが身体運動を物事の意味として位置づけることとなるはずだからだ。
以前からコネクショニズムについては着目し、なんとか活用できる手段がないかと考えてきた。コネクショニズムは論理処理を自動形成する手段ではないかとも考えていたが、ちょっと違うのではないかと思えてきた。 どういうことかと言うと、記号処理は記号間の関係において論理を必要とする。それに対してコネクショニズムとは量子表現の延長にあるのではないかと考えられる。量子表現は連続のものを細かく区切って表現することで、無限に細かくすることにより、量子間距離はほぼゼロになる。量子間距離がゼロであれば量子同士の値に差はなくなる。つまり量子間において論理演算は必要がなくなるのである。 反して実際には非常に緩やかに値が変化するのでマクロで見ると遠く離れた量子の間では結果として演算のようなことが行われるのである。 つまり、コネクショニズムにおいては隣り合った量子間では隔絶した表現は行えないことになる。 実際には有限数でネットワークが形成されるわけだから、隣り合った量子間においても値に差があってしかるべきであるのだが、そこにシグモイドカーブのような関数が登場する余地が出てくるのではなかろうかと考え出した。
でも、そのような形でのネットワーク形成を実際に構成しようと考えているわけではない。 論理ブロックに分けるでもなく、微小な量子に分解するのでもなく、その中間的な存在のユニットをネットワーク接続することで知能ユニットを構成できないかと考えている。 着地点は未だ見えない。
■１月６日■
手抜きで取り込んだからちっこい画像になってしまった。
Ｗｉｉでスポーツゲームをやるときに使う、自分キャラ「Ｍｉｉ」。 これがなかなか良い。がんばってその人に似せて作ると結構受ける。それが画面上で一生懸命プレイする姿はなかなかけなげ。 「はじめてのＷｉｉ」の中のゲームの一つ、「あのMiiを探せ」も、この実物キャラを作っておけば盛り上がる。 上の画像は娘が作った俺キャラ。結構似てる。(^^ゞ
ゲームばっかりやってるわけじゃなくて、ラムダもちゃんと（ちゃんと？）進めてる。 年末にカタがつかなかった通信部分の不具合がやっと解消した。通信部分はサーボ制御のプログラムとはプロセスを分けたいと思ってるから送るデータはプロセス間通信でやり取りする。パイプだとブロックのことも考えないといけないので、共有メモリーのが扱い易いかな。
ところで通信プログラムの確認用にラムダのカメラで撮った画像を送信して、Windowsクライアント側でそれを表示するということをやっていたのだが、RPU-100から無線LAN経由で送ると４フレーム/秒くらい。 これは無線LANのせいなのかRPU-100のせいなのか。無圧縮のデータだから、結構なサイズはあるにはあるのだが、どんなもんなんだろう。きっと全部だろうな。画像データが360×240×3＝259200byte 無線LANは11bなので、フルレートで10Mbpsだけど、せいぜい2～3Mbpsしかでてないだろうから10fpsくらいはでてもいいのか。
■１月７日■
夜中に自分の部屋でWiiをやるために、センサーバーがもうひとつ欲しいなと思って調べてみたら、面白いことになっていることを知った。
Wiiリモコンって、ブルートゥースで接続してるらしいのでPCと接続することが出来るらしい。ゲームパッドなんかに分類されるインターフェース機器として認識される。で更に、センサーバーってのは単に赤外線を出しているだけでリモコン側でその光を受信して位置を測定しているらしい。そういうことなのでセンサーバーは簡単に自作できるのだ。パソコンディスプレイでゲームするため、ともうひとつパソコンのマウスとしてWiiリモコンを使うためにセンサーバーを作ってみよう。 Wiiリモコンって3次元加速度センサーがついてて、センサーバーで位置情報出せば完全な3次元マウスになるな。VRとか3次元CADのポインターとして使えそう。 ロボットのコントローラーにならないかな。両手に持って操作すればマスタースレーブはできそう。 ラムダロボット研究所で扱うロボットは自律ロボットだからコントローラなんか要らないか。
そんなことばっかりやってるわけじゃなくて、ラムダもちゃんと進めた。ラムダの関節制御プログラムから子プロセスを作って通信専用のプログラムを呼び出して共有メモリーを使って親プロセスと通信をするってとこまで行った。 ソケット通信・プロセス制御・共有メモリーと、UNIXプログラミングっぽくなってきたな。面白いがめんどくさいね、これ。
やりとりしたい情報が可変長だから共有メモリーじゃなくて双方向パイプの方がいいのかな？音声合成で共有メモリーを使ったからこっちにしてみたけど、パイプにするかー。
■１月８日■
自作センサーバーが完成した。
これでセンサーバーまで持ってこなくてもパソコンディスプレイでWiiが出来る。 電源はACアダプターで5Vを供給してるんだけど、ゆくゆくはUSBから電源をもらおうかと思ってる。iPod用のAC⇒USB充電アダプタを使えばパソコンの電源が入ってなくても良いって感じで使い分けられるかなと。。
でも、Wiiだとちゃんとイメージセンサーが働くのにWiinRemoteだとうまくいかない。 一度だけイメージセンサーが使えて、感動してたのに、その後は一度もちゃんと動かない。なんでかなー、ドライバーのせいかなー。
センサーバーの製作に意外と手間取ったので、ラムダの通信プログラム作りに着手したのは夕方から。。 サーバー側（ラムダ側）は形になってきたのでクライアント側（Windows側）を作ることに。 ところが、WinSockを使ったアプリケーションの作り方手順をさーーーーーっぱり忘れてる。随分と調べまわって、やっと手元にある本を詠みながら作ったことを思い出した。本をパラパラしてたらだんだんと思い出してきた。 もう忘れないように、忘れてもさっと思い出せるようにエッセンスをまとめてWebに載せておくことにした。
それにしてもUNIXもWindows（VC++６）でも、ネットワークプログラミングのめんどくさいことといったら。。。 いままでOPEN-RとVB6でやってた時は本当に簡単だった。・・・OPEN-Rも基本はWinSockと手順は同じかな。でも、UNIXより、WinSockより判りやすい。 こういうところで時間使って本題になかなか入れないのってムダな感じ。 さらさらとネットワークプログラミングができるほど作り込むつもりもないし、雛形を作って手を加えていくってのが現実的なんだろうな。それでもキホンはきちんと理解しておかないとバグにはまって大変なことになってしまう。理解したことや調べたことはいちいちノートしておかないとムダになってしまうってことをまたまた痛感しました。 いつもこれなんだよね。。そのときは「あーーわかった」って思ったらもう先に行っちゃってノートしたり書きとめたりしない。。 悪いクセだ。
■１月１２日■
最近、ずっとロボットの行動プログラムをどう進めるべきか頭を悩ませてきた。昔の人工知能工学は廃れてしまい、最近では身体知システム論・身体性人工知能といった言葉ができてきて新しい局面に入って来ているようだ。だが、極論かもしれないが、要は人間を模倣する、それも細胞レベルで模倣すればいいのではないかという方向に来ているようで明確な答えが出るまではまだまだ時間がかかりそう。 もちろんそんなのは待てないし、そのアプローチ （知能が成り立つには身体が必要である。）には賛同するにしても細胞レベルで捉えるのはやり過ぎだろう。まさか進化の過程も同じように経過させるわけには行かないわけなのにちょっと無謀と思う。
では違ったアプローチをしなければとういうことで、中間解となりえるようなモノにしたいのだがさっぱり見当がつかない。
そんなことを、昨日、ラーメンを食べながら友達に話をしていた。その友達はロボットも人工知能も詳しいわけじゃないので簡単な例を上げたりしながら話たりしていた。説明するために設定した話なのだが、内心、「その設定でプログラムを作ってみるって手もあるな。」と思ってフツフツと考えていた。
目に映った映像から注視すべきモノをどうやって決めるかということを考えていたのだが、今朝、布団から出た時にふいにイメージが閃いた。 意識・・集中・・時間の概念・・ネットワーク といったキーワードをつなぐプログラムモデルができそうな気がしてきた。うまくすると「意識」をモデル化できるかもしれないなと思っている。 実はまだ「記憶」をどう実装すべきかが決まっていないので成り立たないのではあるが、「意識エンジン」と銘打って詳細検討・コーディングと進めて行きたいなと思っている。
あぁほんの少しだけど道が見えてきてうれしい。(^.^)
■１月１４日■
昨日、今日で下半身姿勢エディターを形にするつもりで取り組んだんだけど、Wiiが邪魔ばっかりする。(>_<)。。。 精神力の問題ですが。。(^^ゞ
でもなんとか下半身姿勢データと移行タイミングデータをラムダに送り、それを実行するところまできました。実行するのはまだ下半身姿勢データのみで、姿勢の移行は実装していない。時間とか速度設定とかまだまだやらなきゃならないんだけど、データのやりとりさえできればあとは枝葉をつけていくだけ。
下半身姿勢で「左向け左」 → 「右向け右」 畳が傷みそう。
Ｗｉｉリモコンの接続でＩＲが効かなかったんだけど、BlueSoleil ver.2.3 をインストールしたら動くようになった。 動作が不安定だったので、BTアダプタについてきたドライバーを抜いて、BlueSoleil を入れなおしたら動くようになったみたい。
BlueSoleilの画面とWiiｎRemoteの画面
Wiiリモコンを使って、ペイントで書いてみた。
意識エンジン
データの処理イメージが固まってきた。昨日はラムダやるつもりが、ずーっと意識エンジンのデータ構造ばっかり考えてた。 内部処理を言語で行おうとすることに問題があるとみた。言語って断定的で時間が止まってるんだなー。初めて判った。
まだ、記憶の構造が決まってない。とりあえず全部記録しておくしかないかなーと思ってる。早くコーディングしたいし。
■１月２０日■
ウィークデーはなんだかんだで日誌を更新できなかった。
本屋でなにげなくコミックの発売予定一覧を見ていたら「風飛び一斗」の24巻が発売になっている。
これって発行部数少なくて置いてる本屋が少ない上に大抵一冊しかない。売り切れたらネットで注文しなきゃならないってやつなので早速探して買って来た。 「かっとび一斗」の頃から読み続けてるんだけど、もう20年位になるんじゃないかな？会社の10歳年下の友達に言ったら小学生の頃読んでたとか(^^ゞ 未だに楽しみに読んでる。。 風飛び一斗は高校生編なんだけど、高校生になったらなんだか登場するキャラが地味な感じでかっとびの頃のマンガ的面白さが薄くなってた。 で、多分、苦情ってか要望がたくさんあったんだろうけど、中学編のころのキャラが続々登場するって展開になってきた。 和馬が出てきた時もわくわくしたけど、24巻の最後では伊緒に平木に三宅、とうとうアキラまで登場。 25巻からやっと本編開始か～って感じです。 続きが楽しみだな。
他にも書きたいことあるけど、もう3時だからやめとこう。
■１月２１日■
このホームページはOCNのドリームネットホームページサービスで公開している。 でも、容量は10MB（無料）だし、容量増やすのは5MBで月額200円だし、CGIは使えないしで全然使えない。レンタルサーバーも調べたりしていたんだけど、金出してやるのもなぁってことで、インフォウェブのフリースペースと併用して無料でやってきた。 10MBだと画像や動画を入れるとすぐに満杯になってしまうので、今は画像はフリースペースからのリンクで読み出している。でも、これっていちいち画像をフリースペースにアップしにいったりでいい加減面倒なんだよね。 で、また最近レンタルサーバーを調べてみたら、前に調べた時より更に安くなってて年額1500円（300MB）とか。それでCGIも使えるしメールも使える（メールは使わないだろうけど）んじゃーまぁいいやってことで、レンタルサーバーを契約ことにしました。 これでBBSの上下にくっついてる広告バナーがなくなります。だれも書きこんでないから関係ないけど(^^ゞ。
ドメインまではいらないからレンタルサーバーにサブドメインを設定することに。 ここでサブドメイン名にすごーく悩んだ。「shimaken」も「lambda」も使用済。 「gooo」とか「wiii」とか意味のないドメイン名も考えたけどしっくりこなくてやっぱレンタルサーバー要らないや、となりかけた。 悩んだ末、自分が目指しているロボット、生活するロボットということで「Life of Robot」にした。「ロボットの生活」と「ロボット人生」がかかってる感じ。準備ができたら移転します。
Wiiのゲーム「はじめてのWii」
９つのミニゲームが入ったWiiリモコン練習用のゲームソフト。もうすぐ全種目金メダルとなるんで終了かなーと思ってたら金メダルの上の「プラチナメダル」があることが発覚。「振り出しに戻る」である。 そろそろゼルダ買っちゃうかもなぁって思ってたけどまだ買わなくて済みそう。(^^)v でも、どのゲームももう限界っぽいんですけど。。
マニピュレータ
ラムダのプログラミングにはC++を使ってる。変数の宣言やメモリー管理が簡単なのと、記述が厳密でバグが出にくいってところがいい。あと、STLが使えるのが便利。Cだと文字列はcharの配列を使うのだが、C++ならstringが使える。 これがまた便利なんだけど、sprint( )みたいな書式整形（ってのかな？）ができないのでchar[ ]で書式整形してからstringに代入とかやっていた。これだと必要な文字数を計算して変数を確保するか、必要十分なサイズの変数を確保するかをしなきゃならない。せっかく文字数管理を勝手にやってくれるstringを使っているのにちょっと残念。 で、なんか手段があるだろうと思って調べてみると入出力ストリームを使うらしい。 ストリームはなんだかよくわからないので使っていなかったのだが、いくつかのフラグを持っていてそれを切り替えながら使うらしい。そこに使うのがマニピュレータという仕組みらしい。（よく理解していない） 固定小数点表記か指数表記か、桁数はいくつか、小数点以下の有効桁はいくつかなど。 ところが教科書どおりの記述をしてもコンパイルエラーを起こしてしまう。 結局、ストリームに対してsetf( )というメンバー関数を使ってフラグをセットして使うことになった。 使いにくそうだが今の用件には合ってるかもしれない。使ってみよう。 ちなみに、クライアント（Windows）とサーバー（ラムダ）の通信は文字列でやりとりする。画像はバイナリーだけど、設定データなんかは文字列。 デバッグしやすいからね。
※調べているとき、「STL マニピュレータ」で検索したらここの開発日誌が出てきた。(-_-;)
昨日はやりかけたプログラムを放置して寝たから今日は早起き。では今日も一日がんばろー。
・
・
・
下半身姿勢移行のエディタープログラムは大枠が動き出した。 ラムダが歩くような動作も出来るようになってきた。 だが、しかし、 また問題発生。 サーボがロックする。 以前にもあったのだが、またロック現象が発生。 どうやらどれか一つがロックしてRS485回線を占有してしまうらしい。他のサーボも一切制御不能になる。ロックも問題だけど、このシステムも問題だなー。 ロックの原因はわからないが恐らくは角度データ取得とコマンド送信がぶつかっているのではないかと思う。それ以外は単にマルチサーボコマンドで角度データを送っているだけだから。 発生確率もまちまちで確認するのに手間取った。 しっかし、こんなハングしやすいシステムでいいのかなー。ダイナミクセルもこんなのだろうか？ どちらにしてもこの程度の制御もできないようじゃ実験システムにもならない。ま、実験用って考えるとサーボの電源を単独でオンオフできるようにすれば使えるかもしれないけど。 角度情報はサーボの外部に専用のポテンショメータを設けるべきだと考えているのでそれだけなら情報取得ができないサーボでもいい。ただ、負荷情報が取れないのは困るな。負荷情報は先々必要になる。先々のロボットで考えればいいかもしれないが。
とりあえず、ハングアップの直接原因を究明してソフト的に回避する方法を考えよう。
■１月２２日■
サーバー移転しました。アイボウェブリングも修正しました。でも、中身は何にも変わってない。 (-_-;)
サーボのフリーズで意気消沈とする中、もうこれ以上はもたもたできないから勇んで下半身姿勢移行のパラメータ調整をやってみた。 あ、サーボのフリーズについてはスピーシーズにメールを送っておいたけど、フリーズが発生する最小構成を作らなきゃならないだろうな。 もしかしたらＲＳ４８５の信号が汚いせいかもしれないな等と思ったりもするのだけど、フリーズはまずいよね。エラーくらいでなんとか勘弁して欲しい。 あんまり問題が多いから、システムを根本から見直さなきゃならないかと考えてみたんだけど、いま、自分の要求に答えられて、かつ手が届くのはコマンド型サーボだけだし。 減価償却も終わってないからもう少し頑張ってもらおう。 でも、、スピーシーズを買ってまもなく２年。フレームから作ったりしたせいもあるし、普通のモーション再生はいやだって言ってるせいもあるけど、まだ形になってない。 ちょっとあせりを感じてきた。
それで、冒頭のパラメータ調整。 カーペットだとうまくないからってんでボードの上でやってたんだけど、ゴロンとこけてあちこち負傷。ココんところはケーブルホルダーみたいになってて割れやすい。 ガードするプレートを作らなきゃなー。 カバーだけ売ってくれるかな？（割れてても支障ないと言えばないのだが。）
パラメータ調整の結果、歩行とは言えない歩行ができるようにはなりそう。まだエディターでマニュアル操作だし、まっすぐ進めないけどね。(>_<)
姿勢移行は形になったけど、これに姿勢安定化のしくみを組み込まないとなぁ。 あ、学習機能も。
今日、サーボのフリーズに心奪われながらも、意識エンジンの「記憶」についてイメージをすすめることができた。だんだんと人手が欲しくなってきたな。できれば俺が２～３人。
■１月２５日■
今日はドラマの日。 昨日は飲みに行ってたので「ハケンの品格」が見れなかった。でもビデオがあるので晩飯食べながらビデオで鑑賞。今日あるのは「拝啓父上様」（だっけ？）と「キラキラ研修医」。仲間ゆきえは好きだけど、「えらいとこに嫁いでしまった」（だっけ？）は全然見てない。 今回のドラマはどれもびみょーなのだが、「キラキラ研修医」と「華麗なる一族」がまぁいいかなー。華麗なる一族はほとんど見てないけど。。(^^ゞ 更に言うと「キラキラ研修医」がおもいの他面白くって気に入ってる。 小西真奈美もかわいいのかどうなのか、あの表情の出し方ってわざとらしいぃ～なぁぁぁとか思うのだが、うさ子はなかなかイイです。(^^)v てなことをやってたので今日も昨日もロボットには触れてない。 下半身姿勢で動かしている時にくらんくらんするからジャイロフィードバックかなにかをしなきゃーなぁ。左右の往復動作に対する動的ジャイロフィードバックは以前に失敗したのだが、前後動作は静的なジャイロフィードバックでいいだろうからそれを組み込んでみよう。 でも、どうやってたのかすっかり忘れてる。 ああいうのもまとめてアップしておかなきゃならないね。 確か、、PIDクラスを作ってコンプライアンススロープを使ってトルクをかけたはず。。。 どう考えてもジャイロデータを生かすには周期の短いサーボ制御が必須のはずだよなぁ～。ビジオンとかはじめロボットはどうやってるんだろう？？
■１月２７日■
下半身姿勢移行動作を使った歩行のパラメータ調整と、サーボフリーズの原因究明。 スピーシーズに連絡したところ、再現プログラムを作ってくれと言われた（言われると思ってたけど）めんどくさいけどやるしかないので、今のプログラムから関係ない部分をどんどん削っていった。 で、全サーボに対して30ms毎に0.3度移動するコマンドを発行するようにしてみた。 すると全然フリーズしない・・・、通信系が問題だとしたらトルクは関係ないかもしれないと思って、トルクを入れずに30分くらい流したんだけど、フリーズしない。 で、元のプログラムだと見事にフリーズする。ん～、関係ないと思ったところに原因があるのかー、そうか！IPソケット通信か！シグナル受けるとだめなのかー！！わかったー！ちょっと手抜きで同じプロセスでソケット通信してたけど、分けなきゃだめなのか、めんどくさいけど原因がわかればまあいいや、とか思っていた。 再確認のためにIPソケット削った方でもう一度確認したら、あらら、、フリーズするやん。orz 結局その後は順調に再現して、原因はコマンド送信後に現在角度要求のコマンド送信をしている部分であることが判明した。間に1msのウェイト入れたらいまのところフリーズしない。 フリーズは現在角度要求を送ったサーボで起こっているらしく、特定のサーボにだけ要求コマンドを送るとそのサーボがフリーズする。 つまり、ジャイロフィードバックのためのコンプライアンススロープ設定データを送るようにしたら更にフリーズの可能性が高くなるわけか、、 25ms周期にしたいけど、30msより短くは出来そうにないな。。 ま、でもとりあえずこれが原因だとすればこちら側でフリーズを防止できるのでよかった。 でも、フリーズしないようにファームは改善して欲しいね。
ウェイトを入れてからパラメータ調整をしばらくやったけど、フリーズしない。 (^.^) まだまだ要注意だけど、いけそうです。
ガシャガシャ動かすようになるとさすがにあちこちのネジが緩んでくる。 構造上の制約で分解しないと締められないネジがたくさんある。 メンテのことも考えて設計しないとダメだな。 サーボホーンが緩んだまま使ってるとサーボホーンが削れていくら締めこんでもガタつくようになる。（この部分の形もあんまりいい設計とはいえないね）。 ホーンの方がアルミで出来ていて、ホーンが削れるから（当然だけど）、ホーンを交換すれば直るのだが、、すぐ削れちまうんだよね。
バーニング・スターの宮田さんがロボワンに復活らしい。最近のブログを読ませてもらっているのだが、この方はすさまじい技術者です。 市販のコマンド型サーボに満足できなくてうだうだしているオレと違ってサーボは自分で作るのがデフォルトなんですね。 やはりそれしかないでしょうか。 プログラムはなんとかなるだろうけど、回路設計や回路デバッグが問題なんだよねー。でも、がんばってラムダのアクチュエータも近藤科学のKRS-4014HV（改）にしようかなー。 RX-64を買うよりは安いし、自分の思い通りにプログラムできるのはすごいメリットだし。 （あ、安いかどうかはわからんな） スキルと時間が問題だが。
歩かせてみると関節が結構ガクガク。関節にトルクが入った状態で手でクリクリしてみると結構遊びがある。アクチュエータのバックラッシの問題はどのサーボを使っても残る。構造的問題です。 解決策としては人間のように伸筋と縮筋を持ってテンションをかけるしかないかなーと思っている。でも、アクチュエータの数が今の倍必要な上に二つにしたからといってトルク的に得はない。この構造を採用するのは、まだ時期尚早なんだろうな。
※トルクが要らない方をバネで引っ張るってのを友達が提案してくれた。バネの分だけトルクが目減りするから却下してきた案なんだけど、必要十分なトルクがあれば使えるかも。
足首や股関節は関節当たり３個使えば使い物になるかも。 足首は脛の筋肉を、股関節は内股の筋肉を第３のアクチュエータで引っ張る。
サーボがこれ以上壊れないようにガードの金具を設計してみた。コネクタの着け外しがやりにくくなるけど仕方ない。考えたら腕のサーボって全然活躍してない。なのに足のサーボより先に壊れるなんてカワイそうなことしてしまった。(-_-;)
■１月２８日■
もうこれ以上壊れるのはいやなので、寒いけど板金部品作り。設計が悪くて曲げ位置がずれてしまった。まったく情けない。(>_<) 最後の１個（一番右）だけはなんとかまともに曲げることができた。作り直すのも面倒だし、この曲げ位置がずれてもさしつかえないからこのまま使うことにする。
取り付けてみた。サーボコネクタの着け外しが格段にやりにくくなった。 メンテをしやすく・・とか言ってたがこれはなぁ。。
下半身姿勢制御に前後方向のジャイロフィードバックによる安定化を組み込もうとしているのだが、なかなか難しい。 ザクっと組み込んだら止まっている時も動いている時もフィードバックがかかるようにしたかったのだが、どうもそう簡単ではない。動いている時のフィードバックはそれはそれで、止まっているときのとは別にコーディングする必要がありそう。さらにはフィードバックによる差分も算出しないとコンプライアンススロープの設定値が決まらない。軽い気持ちだったのに結構大変そうだな。 昨日、１２時から初めて寝るまでに組み込めるかな、とか考えていた。相変わらず読みが甘い。
まずは静止時、そして動作時と段階踏んだ方がよさそう。 なかなか進まないなー。意識エンジン、進展なし。ウィークデーに考える時間取れなかったな。
はじウィー金メダルコンプ。 タンク完全制覇しびれた～(>_<)
■１月２９日■
ジャイロフィードバック、意外とてこずる。以前の、ベタで作ったプログラムと違って、今は、関節⇒足⇒下半身 という風に構造化してて、細かいことを組み込むにはちょっと面倒。 まーでも、きちんと組み込んだら読みやすいソースになるはずだからいいだろう。 前に作ったプログラムを読んでもコンプライアンススロープの計算の意味がわからん。 しばらく考えたけどわからんので当時の検討用ノートをみたらちゃんと書いてた。 読むと、そういやそう考えてたなぁ～、ってすぐ理解できた。ノート書いててよかった。 最初に読めってことだな。
はじウィー、コンチン、牛レースでプラチナメダルゲット。おめでとー！(^^)v 全かかし＋２５秒残りなんて、オレには無理！(>_<)
■２月１日■
ジャイロフィードバック（静止状態）は、やっと組み込めた。 動かすの優先でまだちょっとむりやりのコーディングが残ってるけど、いい感じでくにゃくにゃしてる。 でも、下半身姿勢移行動作の安定化には全然貢献しないんだなー。まだまだ工夫が要りそう。 今はちょっと手抜きになっててコンプライアンススロープも両側同じ値で設定していたり、補正が必要なくてもスロープ値を戻していなかったりするのでもっと詰めたコードにしていけば挙動も変わってくるだろう。 なにより動作時の反動を吸収するような動きを組み込みたいので、その辺りはこの土日で頑張りたい。
とりあえずは静止応対でのジャイロフィードバックをまとめておこう。これも土日の作業かな。
＃プログラム動かす過程で、サーボがジャキジャキ動きだして通信エラーか！と思ってうんざりしてたが、自分のチョンボってのが判ってほっとした。 変数の初期化忘れって・・・初歩や～ん。(>_<)。
はじウィー、みーやん、あのMiiを探せ、自力プラチナメダルゲット。おめでとー！ オレはピンポンでプラチナゲット一番乗り。 ２９９って、、３００行きたかったなー。
■２月３日■
ジャイロデータの校正と積分の見直し。どうしたって誤差が累積してしまう。加速度センサー情報も使わないといかんかな。 さらにジャイロフィードバックのコードをちょっと整理して、X軸だけではなく、Y軸に対してもフィードバックをかけるようにした。スロープ設定は補正方向にだけ行うようにしたのだが、あまり違いは出てない。 というか、スロープ設定を使わなくても顕著な違いはないんだよね。
ジャイロフィードバックは、傾きを受け取って、それを回復する方向へトルクを発生させる。その際に姿勢も若干補正するのだが、補正する姿勢のカタチがいくつもパターンが考えられる。 足首だけで行う方法。足首と腰で行う方法。足首と腰のタイプは２つくらいパターンが考えられる。 今は、前後は足首だけ、 左右は足首と腰のタイプ１にしてる。左右は足首だけにしようとすると計算が面倒なのでこのタイプにしてみてる。 これも調整できるパラメータが山ほどある。クライアントで設定できるようにするだけで結構めんどくさい。 ま、今だいたいいい感じでフィードバックかかってるからいいか。 それより動作中のフィードバックのコーディングをしてみないとね。動作中のフィードバックは強くかけなきゃならなのか、弱めの方がいいのか？？以前はトルクを調整したり、タイミングを調整する手段を試してみたがうまくいかなかった。今回は静止時のフィードバックと同じ手段を組み込んでみる。 これが一番うまくいきそうな気がして怖い。
動作中のフィードバック量を蓄積して動作情報へフィードバックする。次回からフィードバック量が減る。繰り返せばやがて適正な動作になる。って感じにならんかな？ 外乱は学習できないからジャイロフィードバック自体はなくならないけど。
下半身姿勢移行も、上体姿勢（腰の姿勢）の移行や腰の高さの移行もインプリメントしないといかん。 歩き始めに重心を進行方向にちょいとずらすって感じの調整も要りそう。
今やってるジャイロフィードバックは「角速度をゼロにする」という制御になってるので、本当は姿勢の回復が出来ない。くらんくらんするのを抑えたりするにはいいんだけど、場合によってはこけそう～・・・な感じで耐えて・・・こける。ってケースがあって、姿勢は崩れてるんだけど、角速度がゼロなので回復補正が生まれない。これを救済する方法も組み込みたい。ジャイロデータの積分値を使うしかないかな。
はじウィー、ポーズミーでプラチナゲット。1201点でした。あとはプラチナ誰も出してないのはタンクだけ。 なかなかむずい。 それにしても、ゲームがヘタでよかった。こんなに楽しめるなんてね。
■２月４日■
姿勢補正のやり方を比較するためにジャイロデータの姿勢へのフィードバック方法を５種類ほど考えて、クライアントから切り替えられるようにして試してみた。 結果は、足首だけで補正かけるのが一番効果がありそう。補正量は固定なので補正量をそれぞれ適正にするとどうなるかわからないけど。
で、今度は動作中にも同様の方法でフィードバックがかかるようにしてみたのだが、、、ほとんど効果がない。 すぱーん！って安定化するのを夢見てたのにな。そんなにあまかぁないか。 補正量を見直すのも必要だけど、角速度じゃなくて姿勢の回転角に反応するようにしないとうまくないかもしれない。
今の姿勢補正は、足が揃っている前提の計算をしてる。 そのためかどうか、足が揃っていない時はフィードバックによる効果が見えない。 これも考え直さなくては。もしかしたら動作中にフィードバックによる効果が見えないのもこれが原因なのかも。
■２月７日■
ジャイロフィードバック（静止時）について まだまだなのであるが、ちょっとまとめてみた。
結果をまとめると以下のようになる。 予想では股関節で対応することで大きな傾きにも対応できるのではないかと思ったがそんなに単純ではなさそうである。
足が揃っていない場合でも倍率を上げると十分にフィードバックの効果は見えてくる。 動画とっとこうと思って忘れてた。(>_<)
 |
足首だけで対応 これが一番よさそう。 足首から上が動かないために振動などを 起こしにくいらしい。 |
動画 倍率：1.0 倍率：2.0 倍率：2.5 |
 |
足の位置を前に出すことで対応。 倍率を大きくすると振動がしやすいようである。 |
動画 倍率：1.0 倍率：2.0 |
 |
足首だけではなく、胴体も傾きを打ち消すように動く。 効果あると思ったが意外とダメ。発振してしまう。 |
動画 倍率：2.0 |
 |
腰だけで対応 全然だめ。効果ない上に発振してしまう。 |
動画 倍率：2.0 |
 |
足首は傾きに準じる。腰は対応 立ってられないくらいダメ。ちなみに倍率を落としたら フィードバックなしと変わらない。 |
動画 倍率：2.0 |
| フィードバックなし | 動画 |
そんなことより、静止状態での安定化と動作状態での安定化では対応する動きがまったく逆になるということに気付いていなかった。はずかしい。 動作状態のフィードバックは全面見直しです。
・・・
大きくくくって「安定化」を目的にフィードバックをかけているのだが、歩行などのモーションを終えて、動かなくなった時、グラグラと揺れている姿がみっともないのでそうならないようにというのがココロであった。 なので、動画で示すような倒立振子のような力の加え方をしている。これは登頂付近で角速度がもっとも大きくなるので角速度に反応させている今のプログラムには適しているのかもしれない。だが、立っているロボットに外力が加わった時には角速度より角加速度に反応するようにした方がいいのかもしれないし、さらにはゆっくりと押された時には傾き角度に反応させた方がいいのかもしれない。つまり、角速度情報を入力としているＰＩＤ要素ではＩ要素やD要素を大きく扱った方がいいのかもしれないと思ってきた。
■２月１０日■
板金曲げ機。アイビーの方はいつまでたっても入荷しないので、高い方の店を覗いたら、店じまい？ サイトが変わってるだけのようだけど、これ（曲げ機）は扱ってなかった。 きっとアメリカ本国で販売しているサイトがあるはずだと思って検索してみたらeBayでも手に入れられそうなことが判った。ちなみにAmazon.comでも買えるみたい。 eBayの方が安かった（$149）のでそっちで注文してしまった。 ちゃんと届くかなー。ちなみに送料は$56くらいしたから全部で$205。 それでも随分安い。 左が$500 右が$149 。 でも・・・・、しばらく板金工作する予定ないのに勢いで買ってしまった。
ジャイロフィードバックで、積分要素や微分要素を大きくしたら、反応はよくなった。積分要素は積分時間が短いからあまり影響してないかな。積分時間延ばしてみるか。
下半身動作の不安定さはZ軸回転なのかな？とも思ってる。ジャイロは３軸積んでいるのでＺ軸のジャイロデータも利用できるのだがまだやってない。一昨年の後半に取り組んでいた左右振幅動作でのジャイロフィードバックを試していたのだが、致命的な不安定さだ。軸足の違いによって体重移動時の安定さに大きな差がある。 左右の重心のずれなのかと思って、左右で重心移動率を変えてみたが、どうにもクリティカル過ぎる。 納得がいかない。
関節のガタが大きいことやトルクが十分ではない・重心が高すぎるなどのマイナス要因はたくさんあるのだが、そういうことで不安定になるのは当り前で、それでも安定制御ができなければならないのだからなにか考えるしかない。
静止時のジャイロフィードバックでも腰（股関節）の動作というのは不安定さを生んでいるのではないかと考えている。左右の体重移動に際して、股関節（左右）を積極的に利用してはいけないのではなかろうか。重心から遠い足首関節での制御をするのが正解ではなかろうか、と思ってきた。いまの下半身姿勢表現では足りない動作が必要となる。支持脚の足首関節を中心とした回転動作を表す必要が出てきた。
すると、胴体は左右に揺れるわけだから角速度をゼロにするという安定制御はうまくないかもしれない。 かわりに足裏の荷重センサーが必要となる。センサーだけ買ってあるからあれをモノにしなければならないわけだ。
＃久しぶりにサーボが熱でダウンした。前は足首だったけど、今回は膝にきた。
はじウィー、タンクでプラチナゲット。30面までクリア。21面からさくさく進んでちょっと残念。 これであのMiiとウシレースでプラチナコンプ。もうすぐ終わりかぁ～。残念だな。
■２月１１日■
股関節のガタつきが気になるのでスプリングでテンションを入れてみる。効果がわからないのでバラックで。
手で触った感じだとこれくらいのバネではなにも変わらない。 動かしてみると・・・、ちょーーっとだけよくなった気もしないではないこともない。。。
股関節を動かすと安定性を欠くのは関節角度によってガタの方向が変わることがあるからという要素が大きいだろう。ガタをなくせば相当改善するはずなのだが、歯車メカでバックラッシをなくすのは難しい。 それより股関節サーボのギアがなまってきてるのかもしれないな。
動歩行を行っている時は重心の軌道はフラフラしないそうだ。 今考えている下半身姿勢移行は基本的に静的な動きを根本においているようだ。動的な動きをさせる時には反動ができるだけ少ない動作を考えなければならない。このあたり重要。
みーやん、「あのMii」完全制覇おめでとー(^.^) すると、タンクにも完全制覇があるわけか。。。
■２月１２日■
やはり、サーボのバックラッシが大きくなってきたのかなと思い、ほとんど使っていない腕のサーボと交換してみることに。交換前は15ミリ程度だったガタつきが交換すると7～10ミリ程度にはなった。でも、腕に取り付けた、いままで股関節サーボだったものが劣化した感じはまったくない。うーん。。。判らないけど足の重みと長さから考えてこれくらいの振れはどうしてもでてしまうのかもしれないな。
サーボを交換して、更にサーボへのコマンド周期を25msに縮めてみた。動かしてみたところ、随分と安定するようになった。サーボのコマンド周期は30msくらいまではいけると思っていたのだが、25msと30msの差は大きかったようだ。ちょっと厳しいが25msで行こう。
でも、、、股関節のがた付きはいつかはなんとかしないといかんと思う。やはり速い動きについてこさせようとするとどうしても剛性が高くないとまずいし、股関節はその要となるはずだ。
で、朝からやるはずだった股関節サーボを動かさないで体重移動を行うというのを、夕飯後にプログラムし始めた。着手前の恒例のうだうだもそこそこに机上計算して実装方法を検討したのだが、下半身姿勢表現は回転モードには弱いな。足座標を極座標形式で表現したらちょっとは簡単になるのだろうか。
で、動かしてみたのだが、これはなかなか良い。腰を振ってた時に比べると格段に安定した動作が期待できる。よっちよっちとあるく感じがおぼつかないが、カーペットの上でも歩けそう。しばらくは股関節のガタと付き合いながらこの形式をつきつめていこうと思う。 股関節を動かさないようにプログラムしたはずなのにちょっと動いてる。バグなのだろうが、いまのところわからん。でも、今日はここまで。もう寝なきゃ。
ガタつきはロボット全体の周波数応答特性に関わるのだが、ロボットは多関節構成なので所詮は剛体には程遠いくにゃくにゃボディーなので、力の伝達には遅れが生じる。動作を制御するにはこの遅れも考慮していかなければならない。難しい。
■２月１３日■
昨日の続きでパラメータを色々と変更して歩かせてみた。はじめ、どうにも歩かなくてあせったがいくつかのパラメータを昨日と同じように変更すると歩き出した。どうやら下半身姿勢移行の考え方の中で、「足間隔をせばめてから角度変更することでモーメントの影響を小さくする」というのがあったのだが、これは見当違いだったようだ。基本的に遊脚期間は短いからごちゃごちゃ言わずに動けって感じで反動もモーメントもうまく使わないといかんみたいだ。
安定したといってもジャイロフィードバックがなければ立っていられない状態。 まぁ、全ての移動パラメータはリニアに動くようにしてるから反動がでかいのは仕方がない。
いくつかの重要パラメータがあって、それがある範囲じゃないとちっとも歩かないのだが、上体を水平に移動させていた時にいつも転んでいた、左右の振幅に関してはパラメータの調整範囲がとても広くなった。不思議なものです。 下半身姿勢移行を見直してもう少し安定したらとうとう転び方（というか転ぶ時の回復と受身）に着手できるかもしれない。歩かせるより楽しみだったりする。
やらなきゃやらなきゃと思いつつ2週間くらいほったらかしになっていたサーボのフリーズ問題のテストプログラムをスピーシーズに送った。 コマンドの間にスリープを入れるようにしてからはサーボのフリーズは発生していない。時たまフリーズするが、プログラムの問題のようで、再起動しなくても復旧する。とりあえずは困らなくなった。それでもフリーズして電源切断しなきゃ直らないってのはまずいから修正はして欲しいね。
■２月１５日■
今日は悲しい出来事が。 うちのマンションにもBフレッツ光が入るっていうので説明を聞くと宅内まで光が来るって話だったので、んじゃー申し込みます。光電話もセットで。で、工事費は？「はい。無料です。」光電話も工事費要らないの？「はい、要りません。」 ってー話だったのだが、、、
工事日のお知らせ（というか予約）の電話がかかってきたときに、「光電話もお申し込みですね。 現在お使いの電話番号を続けてお使いの場合は、ナンバーポータビリティーサービスにて工事費が2100円。。固定電話権を停止する工事費として1050円。。 」 ちょ、ちょっと待ってよ。きーてないよ。 一切合財工事費は無料って聞いたけど？ 「そうですか。説明が悪かったようで。。」 なんかむかつくなー。
で、そんな話を会社でしてたら、「マンションタイプなら宅内まではVDSLでベストエフォートですよね。」 いや、俺もそれだとあんまり興味ないからじっくり聞いたけど、宅内まで光だって言い張るんだもん。 「そんなはずないですよー。」って声揃えて言われるから心配になって確認してみたら。。。 「宅内まではVDSLでメタルですね。」 がーーーーん。 恥ずかしいやら腹立たしいやら。。 あの代理店のヤツ ウソつきやがったな。 んじゃ、興味ないんでキャンセルします。 ってキャンセルしておいた。 ウソつかれて契約して泣き寝入りって図式がどうしてもいやだったのだ。
本当は100MbpsメタルでもVDSLでも大して構わないし、 （まぁ今よりちょっと高くなるし、そんなに速い必要全然ないんだけど） 光電話は今の固定電話の半額になるしで、マンションタイプでも構わないっていやぁ構わないのだが。
聞くとBフレッツって接続の時に認証しなきゃならないって話なのでちょっとめんどくさいからとは思ったけど宅内まで光のLANタイプならそれでもいいやって思ってたのだが、VDSLなら他のキャリアが入ってくるのを待ってもいいかなぁーと。
固定電話はろくに使わないのに月額2000円も払ってるし、プロバイダーはドリームネットなんだけど、なんか知らないうちにOCNに統合されちゃってドリームネットはなんだかわからない状態になってるし、ADSL接続はイーアクセスの8Mだったかのままだし、携帯はドコモだし。 なんか色々NTTと関わってるけど（イーアクは関係ないか） むかつくので全部NTTから縁を切ろうかと思ったりした。
携帯はアウにしてみたいなーって思ってたし、サーバーレンタルしたからドリームネットのメルアドももう要らない。インターネット接続サービスはヤフーBBでもいいかもね。固定電話も解約しちゃうか。ヤフーBB契約したらなんか安く買えたりするからなー。 秋葉原でiPod １円 とかWii 9000円とかあったね。
・・・まー、光の話はなかったことに。。。
スピから早速メールの返事が。 なんだかわからんが、「ヒントになった」らしく、お礼を言われた。フリーズ問題は既知だった？オレが書いたメールでフリーズ再現問題で動いてた？（←これはちょっと考えられない） 有力なのは、オレが問い合わせる前からフリーズ問題を抱えてて、おとといだしたメールで解決（再現？）の糸口が出来たって話かなぁ。。 ま、お礼を言われて悪い気はしないし、ファーム修正の方向らしいのでよかったよかった。 とりあえず困ってないので気長に待ちましょう。
うさ子先生、あんまり面白くなくなってしまった。パパイヤ鈴木、演技下手すぎ。 二宮君のが面白いね。古めかしい脚本がなんだかノスタルジックで笑える。
eBAYから広告メールばっかりくる。モノはまだかモノは？？？
そんなこんなで今日もラムダのこと検討する時間は取れず仕舞い。 もやもやもやもやしたのがアタマの中を渦巻いてるなー。忘れる前にどっかにどっさり落としたい。
■２月２２日■
本屋で「知能科学」－ロボットの”知”と”巧みさ”－ （有本卓著） というのを見つけた。パラパラっと見て面白そうなので買って帰ったのだが、読んでみるとアイボやキュリオが出てくる。それはまだいいとしてレッサーパンダの風太くんまで出てくる。いつの刊行なんだー？？と思ってみたら2007年1月22日初版。 ほんの一月前。ちょっとびっくり。こういう本って結構古い刊行のしか見たことなかったからなんだかうれしくなってしまった。
専門書は、できるだけピンポイントに絞った本の方が役に立つことが多いという経験からそういったものを選ぶのだが、この本はロボット技術の歴史やらコアとなる技術の解説やらが概論的に揃っている本で、普通なら買うのを控えるところ。だが普通の概論本と違ってコア技術の解説が丁寧なところが惹かれて読むことにした。有本卓博士の著書（技術書だけど）はいくつか持っているし、学会誌にも寄稿していることが多いのだが、文章の言い回しがとても難しい。脳みそをキリキリさせないと何を書いているのかついていけない事が多いのだが、この本は結構読みやすいみたいでツン読にならずに済みそう。
サイバネティクスの章で、「ロボティクスの分野では、動く物体の追跡を行うロボットビジョンにはカルマンフィルタは基本技術である。」とある。カルマンフィルタを使うとノイズに埋もれた信号を抜き出せるらしい。聞いたことはあったが、基本技術であるからには詳しく理解しておく必要がある。有本卓教授の「カルマン・フィルター」、注文しておこうかな。絶版になっていたけど復刻か再版されたみたい。論証と推論の章では「・・・この意味でコンピュータは論証できるし、推論することができる。」とくくっている。 ん～、それはどうなんだろうなー。「論証と推論は事象を記号化することで計算することができる。」という表現なら違和感ない気がするが、事象の記号化が難問なのだろうから記号計算による論証推論がどれほど意味をもっているのか疑問だ。
カルマン・フィルターについて調べていたらこんな古い記事を見つけた。なかなか面白い。 でも、このインタビューに出てくるカルマン・フィルターと有本卓教授のカルマン・フィルターって同じものなのだろうか。
今のADSL環境をチェックしたら40Mbpsでも月額が一緒なんで切り替えようかなーと思ったが、切り替え手数料モロモロで7000円くらいかかる。 それじゃぁBフレッツの方がいいなぁ。 いい特典がついてるのを探してBフレッツに変更する線で考えることにしよう。
「カルマン・フィルター」は一度廃刊になって手に入らなくなった時期があったみたい。こないだ買おうかと思ったけど、「いつでも買えるからいいや」と買うのを止めた「インテリジェンス・ダイナミクス①②」もそのうち手に入らなくなるかも。買っとこうかな。インテリジェント・ダイナミクス研究所も閉鎖してしまったしなぁ～。
下半身姿勢移行はモデルを見直して移行動作を少し簡略化した。以前は
①重心移動 ⇒ ②遊脚を上げる ⇒ ③足幅を狭める ⇒ ④角度を変更 ⇒ ⑤足幅を拡げる ⇒ ⑥遊脚を下ろす ⇒ ⑦重心を戻す
だったのを
①重心移動 ⇒ ②遊脚を上げる ⇒ ③足位置を変更 ⇒ ④遊脚を下ろす ⇒ ⑤重心を戻す
とした。足位置移動は最短距離としているので遊脚と支持脚がぶつかるケースもでてきてしまうが、まぁいいでしょ。 重心移動は左右要素と前後要素で異なり、左右要素は軸足の足首を中心とした回転、前後要素は胴体を平行移動させている。この基本動作にアレンジを加えて安定化させようとしている。 うまく歩けるポイントというのは結構狭い。今は連鎖的に動作を行う仕組みになっているので、今後タイミングを保存できないのが難点になるかもしれない。
いろんなモノを読んでいると、やはり足首の力センサーは押えておくべきだなと思い始めた。チョロメテに使っている３軸力センサーを調べてみると１個６万円らしい。ふむぅ～、サーボと違って２個あればいいから手が出せないわけでもないなー。でも買えるのかが心配。
ちょっと調べるとJS-ROBOTICSで買えそうなことがわかった。
センサーだけあってもだめで、関節の力制御ができなきゃ意味ないわけだが。（意味なくはないか。威力半減ってとこか。）
■２月２３日■
人間でもすばやく動こうとすると体全体に力を入れる。体の力を抜いている時にすばやく動こうとすると上半身が追随できずに姿勢が崩れてしまう。
下半身姿勢移行で歩行の１歩に相当する動きを開始する瞬間には大きな加速度が加わる。その時に姿勢が崩れてしまう。これを防ぐには加速度をできるだけ小さくするか、ロボット全体の剛性を高くしなければならない。体重が大きすぎると重心点の慣性力も問題となる。 加速度を小さくするということについては制約があり、あまり小さいと必要なタイミングで重心を移動するだけの加速度を得られない。
剛性を高くするには関節を硬くすればいい。人間の体の構造だと関節に対して、関節を伸ばす筋肉と関節を曲げる筋肉があり、両方の筋肉を縮めることで関節を硬くすることが出来る。体に力を入れた状態がこれ。しかしラムダも含めて普通のロボットの関節構造では関節一つにつきモーターが一つなので関節を硬くすることができない。そこで考えたのだが、加速度が加わるタイミングで、剛性を上げたい関節にもトルクを発生させる。厳密には剛性ではないが、見かけの剛性が上がり、加速度による反力を相殺することで姿勢が崩れるのを防ぐ。動作が終了する場合も同じで、反対方向にトルクを発生させる。 問題はトルクを発生させる期間は姿勢が変わってしまうこと。 姿勢を戻そうとすると逆方向への力が発生してしまうため、トルクを発生させる期間は限られている。
あとはジャイロからのフィードバックを姿勢変更曲線に反映させることでフィードバック量を減らすという学習を組み込んでみようと考えている。
転倒しかけている状態の姿勢というのを表現しなければならない段階にさしかかってきた。 うむぅ～・・・できるかなぁ。
買おうかと思っていた本（カルマン・フィルターとかインテリジェンス・ダイナミクスのこと）だが、会社の図書館の蔵書を検索したらみんな揃ってた。とりあえずカルマン・フィルターとインテリジェンス・ダイナミクス②を借りてきた。 パラパラと見てみただけだが、カルマン・フィルターは買ってもいいかもなー。インテリジェンス・ダイナミクスは興味深いけど家になくてもいいな。 カルマン・フィルターは廃刊になった昔のやつ。わが社の蔵書すげー。
■２月２４日■
そういえばフタバ産業ONLINE-SHOPでRS601CRやRS401CRが取り扱われているのをこないだ発見した。401は使おうかと思ってた時期があったのだが、スピーシーズで扱うのかな、、とか考えているうちに買う機会を失った。 既に気持ちはオリジナルサーボに傾いているからRS401CRを買ってみる機会はないだろうな。近藤の4014をRS485化する。プロトコルは独自という感じ。
eBayで購入した板金折り曲げ機遅いなぁと思って調べてみたら輸送に28～42日かかるらしい。船便か。船便なのに7000円もかかるんかー。驚き。 最短でもあと1週間はかかるということだ。ひとまずは安心・・っていうのかなんてのか。。
はじMii、プラチナコンプリート。「あのMii」は最後のステージでアウト。完全制覇を惜しくも逃す。まぁみんなの協力があったればこそなのだが。そろそろゼルダ買おうかなー。
姿勢の移行で、重心の移動や遊脚の上げ下げ、足位置の移動などはリニアに動かしているのだが、動作開始時の反動を軽減するためにカーブを適用するようにしてみた。 が、さっぱり変わらない。大体にして１歩は0.5秒くらいの動作である。その時間内に「重心移動・足上げ・足位置変更・足下げ・重心戻し」という動作を行っているのだ。周期が25msなので20程度のステップしかない。そうなるとカーブでの移行は意味がなくなっているのだろうか？ジャイロデータを動作カーブの改善の入力にしようと考えていたのだが、うまくいきそうにない感じだ。
現在はマニュアルでパラメータ調整をしているのだが、なんというか、パラメータを調整していても「いい感じ」のタイミングというのはそんなにたくさんはない。恐らくはロボットの大きさや形からほぼ決まった固有値になってしまうのだろう。足の高さを180ミリとした時は１歩の周期が０．５秒くらいがいいらしい。今の仕組みだと周期は積み上げの結果となってしまっているため、0.5秒周期となるようにパラメータを調整するのは大変だ。パラメータの設定方式を変えるか、設定から周期を即時計算できるようにした方がよさそうである。
歩行の学習で、パラメータの調整をプログラムで行うようにしたいのだが、この「うまくいく」というのはセンサーデータで見れるのだろうか。おととしの後半に頑張ってみたがあまり成果はなかったのだが、状況はあまり変わってないな。
ジャイロデータを記録してグラフ化してみると、やはり足位置を変更する時に上体が後ろに反り返ってしまっているのが判る。反り返った上体が戻ってくるのは１歩が終了した後となっている。明日はこれを解消するために動作開始時の股関節へトルクを入れるようにしてみよう。だが、思ったより緩やかな動作となっている。ゆら～っと上体が反り返る感じである。剛性が低いから高周波成分は伝わらないってことなのかな？
■２月２６日■
股関節にタイミングを合わせてトルクを入れる対策はまったく効果なし。結構自信があったのにがっかり。
どうにも思い通りに進まないのはいつものことだが、とりあえずのアイディアが尽きてきた。絵を描いたり部屋をうろうろ歩いてみたりして検討する。・・・ どうもタイミングの考え方が間違えているような気がしてきた。また下半身姿勢モデルを見直す必要が出てきた。 やはり大事なのは倒立振子として考えた時の足の長さで決まる周期なのではないか。具体的には腰の高さと足の位置で決まる真の足の長さで重心移動のための「倒立振子が頂点を乗り越えられない」ぎりぎりの初速があり、それを下回る範囲での往復動作の周期というのがある。これが歩行のタイミングの基本単位。 いままでは動作をステップに分けてステップの起動のタイミングを調整して動作を連鎖させるという構造にしていたが、重心を移動して戻すという一連の動作が基本となり、その範囲で何をどう動かすかという構造の方が良いようだ。
・・・だとすると、始めの体重移動は両足を結ぶ直線上ではだめなわけだ。根本的に見直しだな。 三次元倒立振子の式を見直して考えてみよう。
歩行検討の変遷をまとめておこうと思い、昔の検討メモを読み返したが、なかなかいいことを書いてる。やはり足首サーボの負荷データを見るようにすべきかもしれない。 今はジャイロデータでの動作をフィードバックに使えそうな気がしてきている。
■２月２７日■
三次元倒立振子の運動方程式の解（線形倒立振子）
x = X0・cosh(t / Tc) + Tc・V0x・sinh(t / Tc)
y= Y0・cosh(t /Tc) + Tc・V0y・sinh(t / Tc)
ただし Tc ≡sqrt(z / g)
グラフにするとこんな形 ( Zは一定 ）支持脚の接地点を原点としている。
ちゃんと計算してもいいんだけど、どうせ２０ポイントくらいしか計算できないんだから大体の形でいいかなーと思ってる。大体でやってみよう。だめならちゃんと計算してみることに。
これは支持脚の動き。 遊脚の動きをどうするかがポイントかと思ってる。論理的には両足で支持している期間は一瞬しかないんだけど実際はそうは行かない。両足での支持期間は支持脚切り替えと、加速期間（ある意味減速も）となる。
前後動作は線形倒立振子でもいいんだけど、左右は普通の倒立振子にしたい。 あと、重心は一度ちゃんと計算してみようかな。手抜きで、論理重心で計算しちゃってるから、足の長さを変えた影響を考慮すべきだし。
やっぱりタイミングの問題だな。動的な歩行を前提として考えると動作をステップに分けて考えるという発想自体がずれているということだった。アタマ悪いからそういう手順で考えないと受け入れられないんだよねー。ｶﾅｼｲですが。。
この線でコーディング方法を見直しです。。。 週末コーディングできるかなー。
■３月１日■
インテリジェンス・ダイナミクス②「身体を持つ知能」を読み進んでいる。
読んでいて、たまに「ほほう。そうなのか！」 「なるほどー」という事があるのだが、すぐにどこの何にどう思ったのか忘れてしまう。付箋つけてても後で見ても何のことかわからなかったりするんだよな。思ったことをいちいち書きとめておくしかないかな。
[P139]ドーパミンニューロンが報酬に反応するのだが、学習が進むと、報酬に、ではなく報酬をもらえることを予期して興奮するらしい。ピピン！と来たのだが、具体的に何ということはない。何かのヒントになるかも。
[P142]遅延報酬のくだり。遅延報酬といってもものすごい長い時間じゃなくて結構短い時間のことを指しているのか？文章では「何年も練習を重ねて･･」という記述になっているが、さすがにそれはもっと高次の意識で考えていると思うのだが。。
[P146]脳内物質の役割の仮説。セントロニンがうつ病や暴力性と関係しているとか。なんか読んでいてセントロニンって「がまんする」ための物質ではないかと思った。その他の脳内物質の役割も興味深い。
■３月３日■
インテリジェンス・ダイナミクス②「身体を持つ知能」
[P160]知能の創発的構成論 「知能とは変動する複雑な環境中で安定に目標を達成する行動を生成する能力」 と定義しているが、寸足らずだと思う。目的を達成する行動というのが良くない。間違えているとは言えないと思うが、このような着眼で検討を進めても核心に至らないのではないかと思う。
まず、「理解」ということを達成しなければ「知能」はありえないだろう。理解とは認知で、ロボットが自分が存在している空間（世界とか宇宙とか）を認知しなければならない。そしてロボット自身もその世界の構成の一部であるという前提での認識が必要だと考えている。もちろん、人間でも森羅万象を極めていないのであるからレベルはどうでもいい。理解し、矛盾なく構成されていればよい。それはつまり、近い過去・現在・近い未来のあらかたの予測がつくこととほぼ同義だと考えている。そして行動は目的を以って実行されるのではなく、「何か」の玉突きにより創発されるものと考えるべきだろう。すべては流れの中にあるということだ。
何より身体性知能とか言ってる割に「センサー入力」⇒「処理」⇒「モーター出力」 ってなんだよって感じ。今までの考え方となにも違わないようにしか見えない。
土曜日の日も暮れてしまった。 ３次元倒立振子の軌道を下半身移行動作に適用するつもりなのだが、結局は動作カーブはそのつど計算することにした。というより都度計算しないと成り立たないのでした。それに、歩行ではなく、姿勢移行にしたいので軌道の中央がグローバル座標のX軸と一致するとは限らず、支持脚足首点を通るある角度の線となるので座標を回転させなきゃならない。漸近線＝「開始姿勢の両足を結ぶ線」と「目標姿勢の両足を結ぶ線」ではないので計算上の目標重心点を算出しなければならない。 とかがあり、都度計算の方が簡単だろう。
遷移時間を０．５秒として20ポイントをとったグラフ。20ポイントあれば結構いけそうだな。
考えりゃ、転倒時は倒立振子になるわけだし、ジャイロで速度もわかるわけだから、倒立振子を使った歩行モードを考えないわけには行かないのだった。
これだと学習する余地はどこらあたりにあるんだろうなー。
今回のコーディングでは姿勢移行（一歩のみの歩行）だけではなく、連続歩行も同時にインプリメントしてしまおうと考えている。
■３月４日■
まずは姿勢移行じゃなくて、歩行の１歩が出来るプログラムをコーディング。一気に自由に姿勢移行させるつもりだったが、色々難しいことが判ってもうちょっと検討が必要。普通の歩行ならもう関数はできてるんだし、難しいことはない。
足上げのカーブやタイミング調整の部分はちょっとコードが面倒なので足上げなしの歩行で味見。
数値で確認してみたら大丈夫そうなのでさっそく歩かせる。 ふむぅ～、滑らかな動きだ。突入が最高速度から始まるから心配してたけどあまり問題なさそう。ただ、重心は実際の重心点（らしきところ、ちゃんと測定・計算してないから）よりも遥か彼方の上空に設定しないと横にすっとんでしまう。
遷移時間を設定すればそれに応じた軌道を生成するのだが、やはり機械的な適切値があるのだろう。いろいろな数値で試して最適値を探してみよう。歩幅も大きくできそう。とりあえずこないだの倍まで歩幅を広げたら、その方が安定したみたい。 動力学バンザイです。
実は倒立振子の式をそのまま使うのは避けていた。もちろん受動的動作をさせるから結果的には倒立振子を使うことになったのだろうが、柔軟性や学習での歩行獲得なんかを考えるとすでに解けている物理学を持ち込むのはイヤだったのだ。センサー信号から物理学相当の相関関数を導けるようになるにはまだかかりそうだし、しばらくは三次元倒立振子軌道での歩行で進めて行こうと思う。
ちなみに今は数式どおりの線形倒立振子の動作をしている。左右の動作については普通の倒立振子にした方が動作が安定すると思うのでそれもやってみよう。普通の倒立振子の運動方程式とその解を探したのだが、ずばりなのが見つからない。 角度が小さなところでの動作に限られてるから線形倒立振子で近似できるかなと思ってる。角度ベースじゃなくて直交座標ベースでやってみましょう。
そういや、パスワードが必要なページを作りたかったのだが、レンタルサーバーがライトプラン（一番安いやつ）だとできないらしい。がっかりだ。アクセス制限だと外からアクセスした時に入れないからダメだし。。 1500円/年 を5000円/年 にすればできるらしい。。やってもいいけど。。
むっ？スタンダードプランにすればサーバー容量が１Ｇになるーーー！！ ･････ 要らないなぁ。
■３月７日■
足上げ部分の処理を書き加えて、歩行動作を行えるようにした。
加速時間というのは両足支持期間のこと。 これが短いと上体がついていかないからうまく遊脚が上がらないとは予想していたが、0.4とは予想より長い。遷移時間は１歩の時間。0.5秒くらいにしたいのだが、ちょっと難しい。0.4秒くらいならだいぶ安心な感じだ。できれば遷移時間を0.5秒にして歩幅を80ミリくらいにしたい。これだと0.4秒で40ミリ。
振子前の歩行だと、Z軸周りのモーメントが発生してしまって、一歩歩くごとにクルンクルンまわっていたが、振子軌道だとほぼまっすぐに進む。よいね。
次は連続歩行へ拡張。 あ、その前に姿勢移行をやったほうがいいのかな。
■３月１０日■
連続歩行へ拡張。それから左右の動作を単純倒立振子タイプにもしてみた。
数式どおりの線形倒立振子のタイプと単純倒立振子タイプで連続歩行動作をさせてみた。 ちなみに単純倒立振子タイプでも使った方程式は同じです。どうやら単純倒立振子の解析解は求められないらしく、数値解析しなければならないらしい。 ・・・どちらにしても歩き始めと２～３歩目くらいは動作の具合が随分と違う。特に顕著なのは単純倒立振子タイプ。明らかに３歩目くらいから上体も往復動作に同期をしてくるのだが、すぐにまた脱調し、また同調するという感じ。 動作の安定具合は今までの検討結果と同じで単純倒立振子タイプの方が明らかに安定している。※線形倒立振子は安定域が狭いので、同調・脱調といった変化というか動きは観察できないということです。
どちらの場合でも、まともに歩けるのは一歩0.3秒から0.4秒くらい。 単純倒立振子タイプなら、重心点の高さの調整も加えてなんとか0.4秒まで引き伸ばせるといったところ。 0.5秒くらいにはしたいけれど、このロボットサイズ（構造もか？）だと無理な感じだ。１歩0.4秒にして、ちょっとウェイトを入れるとかしないとゆっくりは歩けないかもしれない。
歩けそうだなーというのはパイル地のカーペットタイルの上での話で、部屋に敷き詰めてあるもうちょっとふわっとしたカーペットの上だと足をとられて歩けない。 基本的に部屋のカーペットの上を歩けなければならないと考えている。
明日はジャイロデータを採取してフィードバックの方法を検討しよう。 姿勢移行に拡大したり、円弧歩行などは制御ができてからだな。 フィードバックの手段を考えてみたのだが、前後方向へのフィードバックは色々と考えられるのだが、左右方向のフィードバックがやはり難しそう。有効な手段が思い浮かばない。
■３月１１日■
ジャイロデータをCSVに吐き出せるようにしてみたのだが、姿勢データは時間累積なので、データ取得に失敗すると誤差が発生してしまう。それにX軸周りのセンサーがやけにオフセット値がでかい。今はソフト側でもオフセット値をもっていて、そこでも補正するのだが、オフセットがでかいとデータ取得に失敗した時のあおりがでかくなってしまう。そんなこんなでクライアント側でジャイロのデータをグラフ表示させた方がいいなぁ。。と今までめんどくさいからやらなかった事をやることに決定。
VC++で、ダイアログにグラフィック表示を行うためのサンプルプログラムを探してて、Visual C++ 2005 Express Editionが無償配布されていることを知る。知らなかった。でも、いろんな情報を見ると、それほど敷居が低くないのか、初心者には勧めていなかったりする。 本格的なWindowｓプログラムを作る予定はないのでどうでもいいっちゃどうでもいいのだが、ダウンロードできるのは1年らしい。今年一杯だ。 一応、ダウンロードだけしとこうかなー。
ある人のインストール記事にＭＦＣはもう要らない。ドットNetフレームワークが使えれば充分という感じのことを書いてあった。 ・・・そうなのか。Windows開発は大変だ。覚えるそばからどんどん変わって行ってしまう。
歩行して、転んでしまうのは①上体が後ろに反ってしまい転ぶ ②上体が前に倒れてしまい転ぶ ③遊脚の戻りで路面につんのめってしまい、転ぶ などのパターンがある。いずれも前後方向。 左右方向では、①左右運動で、上体が遅れて揺れることで同期が外れて横にすっ飛ぶ ②支持脚で立っているところに外力が加わり転ぶ あたりか。 左右の②は当面対策なしだが、①はナントカせねばならない。
■３月１２日■
ダイアログへのグラフィック表示とかモードレスダイアログとか随分と手間がかかったけど、ジャイロデータをモニターできるようになった。まだオートスケールになっていないのでフルスケールを越えてしまうと見えなくなってしまうのだが、こけずに歩いているうちはモニター可能。
赤：X軸（前後） 緑：Y軸（左右） 青：Z軸（旋回） となっている。 前傾だったのが、徐々に後傾になっていっているのでこのまま歩き続けると仰向けに倒れそう。
見た目にはあまり感じないが旋回軸も徐々にずれて行っている。 まずは、X軸の姿勢をみて、歩幅を調整するようにしてみようか。
１～２歩目と３歩目からは左右の振幅が倍くらい違う。（グラフは振幅ではなく角度ですが）
あ、そうだ、サーボに与えているカーブのグラフをこれに重ねるようにした方がいいな。遅れはどれくらいなんだろ？
ジャイロって安定するまでに時間がかかる。。 電源入れてしばらくは値が安定しない。30分くらいかな。。それくらい経つと安定してくる。それからキャリブレーションしなおさないといかん。 ・・・寝起きに30分かかるってことでしょうか。
歩幅を調整するとなると、姿勢移行の一般化に近いことをしなければならない。
最近、ラムダの足に土踏まずを作りたくて仕方ない。アシモもキュリオもHRP-2も足底にゴムを実装して衝撃吸収をしているらしいが、土踏まずで、骨格的にクッションを作れないものか。 不整地歩行する場合でも土踏まずがある方が有利だと思うのだが。 その前に力覚センサーをつけた方がいいかも。
■３月１５日■
今日は昔の上司のお母様のお通夜に行って来た。 小田原まで小田急ロマンスカーで１時間・・・ なのだが、特急券を買って町田で乗り換えようと思ったのだが、なんの根拠もなく各駅停車でも間に合うだろうと思ってたら、途中駅で追い越されました・・ 特急に。。orz こないだもスーパーあずさに乗り遅れるし（それは単なる寝坊だけど） 慣れないところに行くと大抵逆の電車に乗ってるし。。 成田エクスプレスが全席指定って知らずにトランク持って乗り込んじゃったり。マジで鉄道音痴です。(T_T)
前後方向の速度調整をどのようにしようかと考えあぐねている。
歩行素片の遷移時間を変えればいいかというと、これは一番簡単なのだが、うまくいかなそう。なぜなら遷移時間はロボットの固有値に近いものがあって、特に長くするとうまく歩けない場合が多い。それに歩幅が一緒で遷移時間だけを変えると軌道も変わるので不安定になりそう。あと、終端速度が変わってしまうので速度不整合が心配。では、遷移時間を変えないで歩幅を変えるとどうかというと、簡単に歩幅を調整すると言っても３次元倒立振子の軌道を使っているので簡単には切り替えられない。 軌道は左右対称となるので歩幅を変えるとなると、座標を回転させなければならない。 すると支持脚交換の地点が変わるので終端速度が変わる。さらには着地点が進行方向からずれることになるので速度調整すると直進性が悪くなる。千鳥足だ。もともと座標軸に対して対象となるような軌道だから指示脚交換地点での左右オフセットはゼロである必要があるのに座標を回転させるとそうはならない。 ちょうどよい指示脚交換タイミングを計算できないからつまりあらかじめ一気にスキャンでもしない限り遊脚の動作タイミングを決定できない。終端速度の不整合は深刻で、指示脚交換のタイミングは最も重心点移動速度が速いとき。その速度が合わないわけだからうまくなさそう。・・・
とかなんとか問題があって、ぐるぐるループしていた。結局は満点の答えはなくてどこかに折り合いをつけなければならないのだが、どうするか悩ましい。
今、一番有力なのは重心点移動の軌道はそのままにして、遊脚着地点を変更することで、「次の」一歩の進行速度を変えるという方法。
これだと左右方向のパラメータは一切変わらないのでX方向（左右方向）の軌道は変わらない（厳密には速度カーブが変わらない）。終端速度も変わらない。遷移時間も一緒。で、Y方向（進行方向）の速度だけが変わる。（つまりベクトルとして考えた時の終端速度は変わる） もともと調整したいのは進行速度だし、遷移時間を変更しないことも無理なくできるし、直進性も阻害しない。 考えられる中では一番いいのではないかと思う。 唯一、調整範囲が小さくて、あまり大きな調整をすると転倒の危険性があることだ。
プログラムも恐らくは「遷移時間を変える」案の次に簡単だと思われるので、まずはこの２案を試してみることにしよう。
案１ 遷移時間を変える
案２ 遊脚着地点を変えることで次の１歩の進行速度を変える。
■３月１７日■
計算した軌道をモニターに表示するようにした。
赤：前後ジャイロ 緑：左右 青：旋回 水色：左右軌道 紫：前後軌道
４～５歩目辺りは左右軌道と左右のジャイロデータに位相ずれが顕著になっている。この時はうまく同調を保つことが出来たが、失敗する場合も多い。 このグラフを見ると５歩目で左右振幅が小さくなっている部分がある。その後、６歩目から一度位相ズレが小さくなっているところを見ると５歩目のポイントでのズレが、ある大きさ以内であったから同調に向かうことができたと思われる。 この辺りを制御できないと先がないな。
やはり右に旋回していっているが、確かに観察していると右に旋回している。 というのも、左右同じ歩行素片を使っているのだが、反応が異なるため、足の運びが思い通りにいっていない。ボディーのバランスが悪いのか、右足のケリが弱いのか、どこかのガタツキのせいなのかはわからないのだが。。
どうも後ろに倒れ気味である。かといって、デフォルトの姿勢を前傾にするとバランスを崩してしまう。（左右動作の際にバランスを崩してしまう） これは加速時間（両足支持期間）を長くすることで改善することがわかった。遷移時間0.4秒・歩幅40ｍｍの時だと、加速時間は0.2秒（現在の最大値）にした方がいい感じなのだ。
加速時間が長いと遊脚の復帰時間が短くなるため、遊脚動作の反動が気になるところだが、それよりも両足支持時間の方が大事ならしい。
ジャイロはサーボにトルクを入れた時の微振動でのデータで誤差累積するらしい。これはどのようにノイズキャンセルすればいいのだろう。特にX軸ジャイロ（前後）が顕著。
前後の傾き補正よりも左右同調の方が優先。この問題は難しいなぁ。
左右の重心移動を線形倒立振子モードと単純倒立振子モードに切り替えられるようにした。
でも、線形倒立振子は全然ダメだ。うまく歩けそうなのはピンポイント。そのうえ不安定。やはり単純倒立振子モードで進めることにする。
同じパラメータでもさっぱり歩かなくなったり、スタスタ歩けたりする。どうやら、遊脚の復帰の時につま先が路面に引っ掛かってしまうのが大きな阻害要因になっているらしい。 反面、遊脚を持ち上げる高さは少ない方がスムーズに歩けているような気がする。 そこで、今までは遊脚の足上げ速度と足下げ速度は同じにしか設定できなかったのだが、足上げ速度と足下げ速度を個別に設定できるようにした。 これで、すーっと上げて、ザッと降ろすということが出来る。
歩くというのは「倒れる前に足を出す」のだと思って、重心を前のめりに設定していたのだが、もしかするとこれは遊脚の復帰の邪魔になっているのかもしれない。
・二足支持期間をできるだけ長く。
・遊脚の復帰に注意
遷移時間0.4秒で、遊脚復帰時間0.2秒くらいまでは出来ているが、これ以上歩幅を広げるとサーボの速度がついてこれなさそう。 ２足支持時間を延ばすためにつま先立ち姿勢も検討する価値があるかも。
■３月１８日■
赤：前後ジャイロ 緑：左右 青：旋回 水色：左右軌道 紫：前後軌道
足幅120㎜ 歩幅45mm 遷移時間0.4秒
こけなかったが、もう少しでこけそうな感じ。軌道と左右ジャイロの位相ずれが増えていく一方。
足上げ寸法を小さくしてみた。さっきよりはちょっと同期が保てている。
赤の前後ジャイロが大きくふらついている。最後は転倒して終わったらしい。。。 ３歩目が大きくなり過ぎたのだが、かろうじて踏みこたえた。５～７歩目辺りは相殺されて振幅が小さくなっている。 ８歩目はその反響で限界を超える振幅になってってしまった。
足上げ寸法は小さい方がいいようだ。カーペットの上を歩かせるのが最低条件だからこれもできるだけ大きくしたいところ。
あと、前傾を止めてみたらやっぱり後ろに反り返ってこけてしまう。前傾の寸法はこれでいいでしょ、とりあえず。。 じつはラムダはまーーーったく後退が出来ない。前にしか進めないマリオのような攻撃的なロボットだったのだ。 なんでだろうな。
ニュースーパーマリオはバックスクロールできちゃうけど。
とりあえず、位相遅れを計算できるようにしよう。簡単にゼロクロスでみたかったのだが、だめだね。ピークで見ることにしよう。
遅れの原因は歩行素片の突入速度のオーバーだろうと思う。 その原因はロボット構造の剛性の低さにあるのだろう。剛性の低さはおいといて、突入速度オーバーの対策は、、、①歩行素片計算上での重心点高さを変える。 ②加速時間（２足支持期間）を変える くらいかな。。
「待って」あげた方がいいのかなー。
設定値を表示するようにしたり、ダイアログのサイズを変えられるようにしたら、グラフのスケールを間違えたらしい。ちっこくなってしまった。 軌道の左右成分だけをわかりやすい形にして表示、前後成分は要らないね。
これは結構同期が取れているデータ。それでも最後の方で少しズレが顕著になってきている。 位相遅れは判るとして、つまずきは検出できるかなー？？ どうすりゃいいんだろう。
■３月２０日■
やるべきことは３つ。
① 同期ずれからの回復。 ⇒ 「待つ」でやってみる。
② つまずきの検出 ⇒ 股関節と膝の関節の負荷を監視してみる。
③ つまずきにくくする ⇒ 遊脚の復帰時につま先を上げてみる。
つま先重視で、滑り止めはつま先だけに取り付けようかと考えている。 踵は逆に潤滑性のあるテフロンテープかなんかを貼ってみようかと。
■３月２１日■
ウェブの巡回していて、アイボ愛護プランの話が出ていて思い出した。そういや、うちのアイボも愛護プランに入ってた。一度チェックに出してみようと思って、アイボ愛護プランの保険証みたいなのを探し出して愕然。。 去年の11月で期限切れだ。。 結局一度もアイボクリニックに出すことなく愛護プランの３年間が終わってしまった。とたんに壊れたりするんだろうなぁ、やっぱり。。ソニー製だし。 orz...
ERS-7のオークション価格は結構高値安定です。２１０もいいけど、７はもっといいので２１０を処分して７に買い換えようかとも思ったけどとても買える値段じゃない。２１０も昔に比べたら高くなってるかもしれない。（正確には２１０Ａ）
遅れの測定をしてみた。
ダメダメの結果だけど、同期遅れ測定にはいいサンプル。サイクルは25msなので、8サイクル遅れということは200ms遅れてる。遷移時間が0.4秒（400ms）だから半分遅れてる。
この遅れ値をつかって「待って」みた。
５歩目とか８歩目で待ってる様子がわかる。 が、結果は全然だめ。５歩目は遅れも小さかったから影響が少なかったらしいが、８歩目などはジャイロデータも顕著に反応してしまっている。「待って」も同期合わせにはならない。
遅れてから対応しても遅い。遅れる前に対処しなければならない。遅れと言っているが、遅れていることが問題ではなく、オーバーシュートが問題。３歩目のような振幅が大幅に増大することが問題。
遅れ検出のテストをしているときに気付いたのだが、このオーバーシュートが起こる前のステップではどうも同期進みが起こっている。２歩目と５歩目が「進み」になっていて、３歩目６歩目がオーバーシュートになっている。
進みが発生するのは突入速度が足りないことが原因らしいが、ここは置いといて「同期進み」を検出して次のステップでのオーバーシュートを迎え撃つ作戦に切り替える必要がある。 あと、やっぱり軌道は歪ませちゃだめっぽいね。合気道の精神で受け流せるようにならないと。 修行だ。。
これもサンプル。これは「待つ」のをやめてる。３歩目での進みがその後の姿勢崩れの原因になっている（らしい）。
位相進みがあったら重心高さを高くして振幅を小さくしてみた。まず＋100ミリ。 ３歩目で位相が進んでいるので４歩目の軌道はちょっと振幅が小さい。ジャイロデータはお構いなしですが。
それでは＋200ミリ。 ３歩目、４歩目は位相が進んでいるので４歩目、５歩目は振幅が更に小さい。 ジャイロデータはやっぱりお構いなし。
ということでこの方法もダメっぽい。 補正入れない方が安定してるんだもんな～。
旋回が起こっているのもオーバーシュートからのケースが多い。オーバーシュート撲滅しないと明日はないな。
■３月２４日■
位相が進んだ次の一歩でオーバーシュートが起こるのはわかったのだが、なぜそうなるのかがいまいちわからなかった。足首の動きと重心点の動きが同期してしまうとかそういう感じかと思っていたが、グラフを見ていてはっと気がついた。
位相がなんたらとか言っているが、要は振りが狙いより小さいわけで、振りが小さいので早く戻ってきてしまったという状態が位相としてみると「位相が進んだ」状態。 で、現状の遊脚の動きは加速時の二足支持期間を大きく取るために、遊脚の復帰タイミングと着地タイミングが一緒だったのだ。 重心が早く戻ってきてしまうと遊脚がまだ着地していないので反対側に倒れこんでしまうのだ。 悪いことにつまずき対策に着地はできるだけ待って、最後の最後にドンと着地するような設定にしているので条件は悪いわけだ。
で、着地タイミングを少し早めてみたのがこれ。
振幅が安定している。ピンクっぽいラインは遊脚を持ち上げるタイミンググラフ。 たまたまだが、ジャイロＹのデータにｵﾌｾｯﾄが現れなかったので確認するのには好都合。途中、振りが小さくなっている部分があるが、着地したことでブレーキがかかってその後の影響は抑えられている。重心点復帰タイミングより50ms早く着地させている。
ブレーキがかかるポイントでは見た目はカクカクとしてイマイチなので、ダンパー要素が欲しいところだ。今後検討していこう。
これで随分と安定化してきた。結局はオーバーシュートしないようにしただけで、「オーバーシュートした時」の対策は取れていないから外乱には弱い。 オーバーシュートしてしまった時は着地タイミングだけでなく着地点も変更しなければならないと考えている。 次にやろうとしている前後方向の安定化のためには着地点を変更することを考えているので、その延長にオーバーシュート対策も入るだろうと思う。
それにしても遊脚の振る舞いはキモである。 やること多すぎて0.4秒では忙しすぎ。 せめて遷移時間を0.5秒にしたいところであるが、まだ0.45秒が限界らしい。
まぁちょっとはましになったかと思うので動画を撮ろうとしたのだが、カーペットの目や畳の微妙な傾きにも大きく左右されるのがわかった。 そりゃまだなんの制御もしていないわけだから当然といえば当然なのだが、はかないねぇ。。
苦労して撮影しながらグラフのログを取った。
まだ１歳の幼児の歩行にも及ばない。 でも、結構似てる。 歩幅が50ミリくらいになるとちょっとイメージが変わってきて歩行らしくなる。早くその域に行かなきゃな。
■３月２５日■
スクロール長過ぎなんだけど、あと１週間で３月も終わりだから、新ページは４月からにしよう。
昨日のグラフを見ると、始めの横長いのは旋回（Z軸）はふらついてはいるが安定している。 動画と一緒にとったやつは歩数は短いのに左右のスイングに合わせて旋回してしまってる。何が違うのかなーと考えると、足上げ寸法が10ミリと15ミリの違い。
足上げ寸法を大きくすると反動がつくのか、左右のスイングが増幅してしまう。そして、足裏が浮いてしまい、外側のエッジで立っている状態になるらしい。 エッジだとグリップがないので胴体の重量分布に従って回転してしまうようだ。データによると背面の方が重いらしい。
カーペットの上を歩くには足上げ寸法も高く上げられなくてはならないので、対策が必要だ。
これは対策なしで足上げ15ミリ。７歩目から明らかに旋回し始めている。６歩目辺りからスイング振幅が大きくなっている。
これは足首の左右回転サーボにコンプライアンススロープ設定をしてみたところ。足上げは同じく15ミリ。効果あるなぁ。 （CW,CCW共に100を設定。(8deg) )
サーボの設定記述を見てみたら、膝サーボ以外はトルク90%で設定している。そういや、余力残しておかないと、とか思ってそんな設定にしたなぁ。。。 これを全部100%にしたらもっとマシになるかもね。 まだしないけど。
上体のホームポジションがずれているのに気付かず、全然歩けなくなってあせった。 ホンの少し腕の位置がずれてただけなのにダメだった。 色々とシビアだな～。 この違いってジャイロとかサーボの負荷とかで感知できるのだろうか？ できなきゃ困る。。
前後の重心は感知できれば調整できるし、姿勢から重心位置を計算することも出来そうだが、左右の不均衡は歩行に大きく影響しそう。 左右で歩行パラメータを変えたりするのかなぁ？？
足首の前後軸サーボの負荷をモニターしてみた。
手でロボットを前後に揺らしてみる。データから動きを見ることはできそう。
歩行用に少し前傾で立っている時。ひいている方の足はあまり負荷が見えない。
前傾をやめると関節への負荷が減っているのが判る。 ひいている方の足も心なしか負荷が減っている。
でも、前傾過ぎても歩けないのだが、「歩ける」「歩けない」の判別がつくほどはっきりとした値がリニアに見えるわけじゃない。
サッカードみたいに自分で前後に揺すってみるとか。
この、サーボの負荷値でつまずきを検出しようと思っているのだが、判定が難しそうだな。
■３月２６日■
運動方程式とか微分方程式の解法の教科書とか参考書を探してたらこんなのをみつけた。
直ぐに役立ちそうにないし、安い本じゃないから会社の図書館にないかなーと調べてみたが、残念ながらなかった。。 図書紹介を見ると「２関節筋」がポイントらしい。２関節筋てのを調べると色々とヒットする。どうやら生物と同じ動きをさせるには有効な構造らしいが、２関節あたり６つのアクチュエーターが必要だし、ストロークが相当必要。 まだ採用できる構造じゃないな。
さらに２関節筋を調べてたら、こんなのが出てるのを知った。
人気あるらしいからそのうち DVDになって出るだろうと思ってたけど、もう２まで出てる。 そういや、昔、デジタル所さんがDVDになったら買おうと思ってたけど、買ってないな。風の便りでDVDになってると聞いたが。。。
歩行の安定化の件だが、次はつまずき検出⇒回復と、歩幅変更⇒姿勢回復。
スイングの安定化は結局はブレーキを適度にかけることでスイング振幅が増幅することを抑制しているだけ。 それも２足支持期間を長くしているだけなんだからなんの制御をしているわけじゃない。
つまずきからの回復や歩幅変更による姿勢の回復ができれば安定化制御といってもいいかなと思ってる。頑張らねば。
ただ、路面が平坦じゃなかった場合の制御が何をやるべきかまだイメージできない。 理想としては受動関節動作をさせたいのだが、今のラムダじゃ無理かな。静止状態でのジャイロフィードバックのようには行かないだろうし、こないだまでやっていた動作時のジャイロフィードバックだと３次元倒立振子軌道が阻害されるからいいとは思えない。
ここは足首関節をダンパーにしてしまって、不整地に適応させたいところ。 倒立振子なんだから、足首関節がダンパーになっていてもうまく行きそうなものだが、計算どおりには動いてないんだから（というか正確な計算をしていないので当然である）きっとダメそう。 なにより(タイムラグがあるから）受動関節で、受身な状態から能動的状態への移行をスムーズに行えないだろう。 何ができるかを考えるべきか？？？
歩幅が50ミリを越えた辺りから歩行に勢いがつく。バリスティックな感じでイイ。まずは目標は歩幅50ミリ遷移時間0.4～0.5秒ってとこだな。
■３月２７日■
つまずきが検出できるかどうかのテストをやってみた。
遊脚の股関節と膝関節の負荷をグラフにしている。茶色っぽいのが股関節・エメラルドグリーンが膝関節。
遊脚を持ち上げて復帰運動に入る瞬間に負荷が大きくマイナス側に振れている。負荷が大きいのは瞬間で、遊脚を降ろすとまたほぼゼロに戻ってる。
対して膝関節は法則性がありそうではあるが、ノイジーでちょっとデータとしてはよろしくない感じ。
これがわざとつまずかせた時のデータ。
旋回軸が大きく下に振れてる部分の少し手前でつまずいている。 ６歩目のところだ。 股関節負荷のグラフ形状が乱れているのがわかる。これはデータ処理で検出できるかなー。ちょいと難しそうだ。なにせ、つまずいたところで遊脚の復帰をやめて即座に着地しなければならない。最低でも遊脚期の前半か後半かくらいは判別できないと、動作を変えられない。
負荷データより指示角度と実際角度の方がいいかもしれないな。 足首の受動関節はそれでできないかなーと思ってる。着地検出は足首の負荷とかで見れるかなと。
で、支持値と実際値を採取してみたが、、、全然わからんなー。これで見るにはやはりダンパー特性にしておかないと検出可能なレベルでは差が現れないね。
やはり、負荷値の線を詰めるしかないかな。 ジャイロでの姿勢値と合わせれば実用レベルで検出できるようになるだろうか。 それにしてもそろそろグラフの線が多すぎて見づらい。どうしてやろうか。
家に帰ったらピタゴラスイッチのＤＶＤが届いてた。見てるとなんだか和んでくる。かわいいってのかなー。それにスゴイ！ アマゾンのお勧めに「子供がはまって一生懸命見てます」って感じで書いてたけど、思わず見入ってしまう。でも、３３本収録で１９分、あっというまに終わってしまった。 2300円くらいしたんだけど、、ヒューマノイド工学買った方がよかったか？って自問してしまった。(>_<)
会社の図書館に「カルマンフィルター」を返しに行った代わりに「微分方程式の数値計算」って本を借りてきた。常微分方程式とか偏微分方程式の数値解法について判りやすく書いている。。。。 判りやすく書いているように見受けられた。 微分方程式とは曲線群を表している。数値を指定して曲線を確定することが特定解。って感じで書かれているのでとっつきやすそう。学校ではるか昔に勉強した微分方程式は定義と簡単な例をいくつか習っただけで概念がわからんままだったので勉強しなおしたいなとずっと思ってたので。。 カルマンフィルターはさっぱり読めなかった。確率は更にわからん。。
今夜は歩幅変更のアルゴリズムを実装するための準備をしていた。 明日、明後日はロボットゴトができないので土日でコーディング～デバッグまで速やかに進められるように検討しておく。 今考えている手順は軌道も直線性も阻害しないけど、歩幅を変えようとしてから実際に歩幅が変わるまでに１歩分余計にかかる。１歩目で準備して２歩目で歩幅が変わる。これがちょっと引っ掛かってる。 ギリギリまで縮めて、現在の１歩を準備歩にすることはできるかもしれない。この応答性の悪さがフィードバックの役に立つのかどうかが問題だな。