 |
■１１月１２日■
ラムダの開発作業が出来ないでいる。なぜ出来ないかと言うと、気分が乗らないのだ。次に行いたいのは足上げ動作なのだが、これをどのようにプログラムするかがさっぱりまとまらない。左右往復動作での重心移動で荷重が抜けるポイントを知ることができたのだが、そのポイントで足上げ動作を行わせるプログラム構造がしっくり行かない。モチロンどうともすれば作れるプログラムなのだが、プログラムの形が納得いかないとさっぱりと手が止まってしまうのだ。
左右往復動作での補正が出来た時点で少し記述が雑然としてきたのでクラスを作ってオブジェクト化したのだが、歩行の全体像が決定しない間にオブジェクト化したので当然しっくり来ない。 アイボを使って開発をしていたときも、雑然と書き進めていって、コードがまとまってくるとオブジェクト化して整理するというスタイルで形を整えるのが習慣（？）になっている。今回もその流れなのだが、歩行となると４足歩行ほど単純ではないのでなかなかうまくいかないのも当たり前ではあるのだろう。
考えたのだが、歩くということをもうちょっと分解整理する必要があるようだ。
足を使って体を移動させるということは足を進む方向と逆方向に動かすことで相対的に体を目的の方向に進めるということになる。足を互い違いに出すのは足には長さの限界があって、一方方向に動かし続けることができないからである。足を上げるのは、これ以上一方方向に動かせなくなった足を戻したいのだが、地面に着いていたままでは摩擦が発生して逆に体が動いてしまうからで、重心を左右に動かすのは足が体を支えていたままでは足が上がらないからである。
つまり、歩く動作の一つ一つはそれぞれ次の工程のために必要なための動作であり、言えば当然なのだが、後引き要求となり、要求は工程順を逆に流れていくわけだ。
これをうまく表現すれば、歩行のパラメータ全ては要求により決定されるという美しい形で表現されるはずである。最終的には「２足で胴体を支える」オブジェクトの上位に「歩行」という動作が表現できれば良いなと思っている。立っていることも転びそうになって足を出すことも歩行の一部となるのだ。
ちょっとすっきりしたのでまた進捗するかなー。すればいいな。
■１１月１９日■
あまり問題は進展していないのだが、実験するごとに動作が不安定になって行ってるようなのでラムダの構造に問題があるんじゃないかと思って、じっくりチェック。
どうも股関節のサーボホーンの軸の滑り止め部分が削れてしまい、かみ合わせにガタが来ることで足のがたつきが大きくなっているようだ。６０１の軸形状を見たときに強度重視だなーと思ったのだが、耐久性に問題があるみたい。サーボホーンを交換すればいいわけだが寿命が短すぎると思う。ちょっと削れても締め直せば復活するような締め代があればよかったのだが。
あちこちチェックしてガタが大きいのはやはり片持ちになっているところ。ラムダでは股関節の前後・大腿のロール・肩関節の前後・上腕のロール・肘関節と、片持ちになっている関節が結構ある。股関節の前後軸と肩関節の前後軸が荷重も大きくガタつきによる影響も大きい。なんとかガタを抑えたいのだがぁ～。
恐らくではあるが、スラスト荷重がサーボホーンの寿命を縮める要因になっているのではないかと思う。大腿ロールにはスラストベアリングを挿入しているのだが、ここのガタ付きは非常に少なく感じる。肩と股関節にもスラストベアリングを入れてみよう。
スプリングなどでガタを引っ張り込むという手段もあると思うのだが、構造的にスプリングを挿入するのが難しい。遊脚になった足の股関節のガタが解消されれば安定性は上がるはず。
とにかく、歩行安定化には遊脚が着地した時の位置精度を上げるのが最重要課題。
順運動計算
このガタつきが足先座標に対してどれくらい影響するのかなーと思って確かめてみた。このときに気付いたのだが、ラムダの順運動計算・逆運動計算は足裏が水平になっているという前提で計算しているので、股関節のガタつきは胴体姿勢に影響することになる。計算は正しいのだが、直感的じゃない。足首サーボで確認すると、１degで5㎜くらい。ガタが1degあればサーボ自身のガタと合わせて15mmくらい開きが出てくることになる。由々しき事態である。この辺りがお手軽ロボット構造の限界かなー。本来関節角度を測定するセンサーは関節構造の外側にあるべきだけれど、ユニット化したモーターを使うことでの構造簡略化を優先してユニット内部に納めてしまっている。関節構造の外側にポテンショメータを設けてサーボに引き込むべきなのだろう。 今後どのようにホビー系ロボットが進歩するのかわからないが、高度かするのであればこの辺りの問題も解決されなければならないはず。関節自体がユニット化されて「股関節ユニット」などの形になっていけばよいのであるが、汎用的なアクチュエーターとして進んでいくのであれば角度フィードバックセンサーを外部から取り込む機能を備えるようになるべきだろうな。リニアアクチュエータやストリングアクチュエータ（人工筋肉）が進化すれば様相はまた変わるが。
動的歩行
気になるページのQRIO Tech. Holder's Blogの昔（と言っても今年の７月）の記事でビジオンが切られてます。35年前の技術だそうです。（恐らくですが）所詮、あらかじめ用意したモーションを再生して、せいぜいジャイロセンサーのデータから不安定動作をキャンセルするということを行っている程度だから、キュリオに比べたらまったく制御されていないとも言えるんでしょう。それはさておき、ここで山口博士は「体重が3kg以下程度になってくると，人間と同じような周期の運動では，動的バランスを用いた歩行には達しないのです．」と書かれています。「動的要素を用いるほど，重心の軌道は，腰の据わった軌道になってきて，安定してきます．逆に，動的要素を用いないと，重心の軌道は，激しく動いてしまうため，姿勢の変化は大きくなります．」と続けています。これはきっと完全動的歩行とでも言うのか、逆に重心位置をあまり動かさないような歩き方とでもいうのかその状態のみを指しているのではないのかと思います。なぜなら、歩行は倒立振子で表現されたりする（これも単純化しすぎていて面白くないのですが）形態なので、運動の停止の状態が含まれているはずです。なので、動作を停止しても転倒しないフェーズが存在し、部分的に静歩行が含まれるのはおかしくないと思うのです。
たとえば、足を肩幅に開き、できるだけ腰を左右に動かさないように歩くとすると周期を早めないと歩けません。これが山口博士の言う動歩行。ドロボウのようにどの瞬間でも停止でき、転倒しないような歩き方を静歩行。で、足を肩幅に開いて腰を左右に動かして歩けば動静歩行とかいうんじゃなかったかと思うのですが。片足状態のある期間では静歩行と同じで停止できるけど、その他の期間では停止すると転倒するので動歩行となると。
それは言葉尻の話で、要は制御されているかどうかということで、キュリオは制御されていて、ビジオンは制御されていないということですね。動的状態が発生するか否かではなく、動的状態を制御できているかどうかということ。モーション再生（もちろんそれが逆運動計算を行った重心軌道計算であっても）するだけで動歩行とは言えないと。
そういや、ビジオンが歩いてるとこって見たことない。
ＨＭＭ
ロボット学会誌が来ました。掲載論文に「隠れマルコフモデルと動作の階層構造の木表現による日常動作認識」というものがありました。
ＨＭＭは音声認識に使われている時系列の状態遷移確率のモデルで、色々な使い道がありそうだなーと思っているものの一つです。ここでは人の動作を木構造で表現したもので動作を認識するということをやっているようです。よく似た発想だけど、ロボットの最適動作生成に使えないかなと思っています。参考になりそう。
■１２月１７日■
久しぶりの日記更新。ずっと左右重心移動のコントロールについて実験や検討を続けているのだがあまり目立った進捗はない。
進展といえば、上半身と下半身をある程度の位相ずれをもって動作させる方が動きが安定しやすそうだという発見くらい。
うまく行かない原因のひとつにジャイロデータの取り扱いがある。ジャイロデータで姿勢を知りたいのだが、角速度センサーなので実角度を知るには定期サンプリングと積分値を使うことになるのだが、センサー自体の誤差も累積してしまうため、あまり信用できるデータにならない。
実際に停止状態での姿勢センサー（加速度センサーと角速度センサー）の値をグラフ化してみた。角速度センサー値は累積値（積分値）です。横軸は１目盛り40ms。
|
データ取得に先立って100回のサンプルを取って平均値をオフセット値としてます。Z軸回転は直線で誤差が増加しているので誤差が一定しているため実はあまり問題じゃない。問題なのは値がフラフラとふらついているX軸回転とY軸回転。これじゃ補正のしようもないなぁ。動作時の加速度センサーもあてにならないので、動き続けている時の姿勢はどのように受け止めればいいのか。。 画像解析を進歩させればもうちょっと手が出てくるのでしょうが。
アシモがパワーアップしてる。 アシモはちっさな子供くらい大きいから時速６キロで走るってすごい。顔振りながら走ってるから画像処理とかはできなさそうだなー。
キュリオがモデルチェンジしてる。 一気にかっこ悪くなったなー。前のキュリオがデザイン的にバランスとれてたからくずれると目立つ感じ。手首もカメラもかっこ悪いです。なんとかして欲しい。
■１２月２３日■
やはりバリスティックな動きをモニターするにはジャイロセンサーの監視は必要だろうと考えているのだが、誤差の累積を排除できないのであれば値を信用できない。何度も色々なパラメータで動かしてみると、なかなか左右対称には動いてくれず、左や右に偏った動きをするのだ、それも長い周期で左⇒右⇒左、、と偏りが移動する。この動きは拾いつつ、誤差の累積は排除する、というのは単純に考えて不可能に見える。 なので、他のセンサーデータも同時に監視し、２面からデータを分析することで誤差の累積なのかどうかを判断することはできないものかと考えた。
やはり使えそうなのはサーボの負荷情報くらいである。しかし、負荷情報も左足と右足で随分とデータが違うようなのでどうしたものかと思ったのだが、ちょっと確認してみることにした。つまり、サーボによって特性があるのではないかということだ。このサーボはあらかじめ補正がかかっていてサーボ個体の差を考えなくてよいようになっている。しかし、負荷データはどうも同じ状態で同じ値を示さないように感じるのでそれを確認することにした。
負荷のかかっていない状態で 10回の測定を行い、もっとも小さな値を無負荷時のオフセットとした。
| id: 1 ld: 1 id: 2 ld:13 id: 3 ld: 6 id: 4 ld: 2 id: 5 ld:13 id: 6 ld: 1 |
id: 7 ld: 5 id: 8 ld: 3 id: 9 ld: 9 id:10 ld: 2 id:11 ld: 2 id:12 ld: 1 |
id:13 ld: 1 id:14 ld: 1 id:15 ld: 9 id:16 ld:12 id:17 ld:14 id:18 ld: 1 |
id:19 ld: 6 id:20 ld: 1 id:21 ld: 1 id:22 ld: 6 |
こんな感じである。 オフセット１から14まで随分と開きがあるようだ。 いまのところ足の接地検出をするために使っているサーボが７と13なのだが、ＩＤ7のオフセットが5に対してＩＤ13のオフセットは1である。コレくらいオフセットが違うのに同じ閾値で接地検出をしていたのだから偏りが生じても当然だろう。
しかし、これはこれでいいんだろうか？
■１２月２４日■
先日のキュリオの記事からちょっと製作意欲が沸いて来た。新型キュリオに搭載されているカメレオンアイ。これいいなーって思ったんだけどよく考えると魚眼レンズをつけてるだけ。ドアスコープに使ったりするなら画像補正が必要かもしれないけど、ロボットが画像認識するためなら必要に応じてソフトで行えばいいわけだし、多分注視物体を中央にもってくれば補正は要らないんじゃないかと。 （ 稜線検出とかで空間認識をするときにはちょっと歪が邪魔かもしれないな。。。 ）
ならば、10万円も出さずとも市販のドアスコープ使えばいいんじゃないかと。
ドアスコープね。
そして、カメラは暗視型カラーCCDを試してみよう。なんせ、アイボで画像認識をしようとした時は、自分の影で対象物を見失ってしまう。輝度差は出るけど、暗視型ならイイ事あるかなと。 モチロン、悪事には使いませんので。。(^^ゞ
最低照度１LUX スゲー。
おまけにカメレオンアイ。 画像補正まで入ってすごくコンパクト。10万円は高いけど（サンプル価格だけどね。）
アイボも魚眼レンズを使うべきだよなー。そしたらモノや人ももう少し探しやすくなるだろうに。
■１月８日■
年末の話（魚眼レンズ）
年末に渋谷に出かけた機会にドアスコープを買って来た。視角１６０度のと１８０度の２種類があるんだけど、あまり差がないから安い１６０度の方にした。
どうやってカメラに取り付けようかなーと考えながら分解などしてみたんだけど、筒の長さが扉の厚さ分あるのが気に入らない。ピントを合わせるのにはこの距離が必要なのだろうか～ってことで、分解して試してみることに。
でも、このレンズ、接着されてるみたいで分解できない。。 ハンズに吊るしてたモノのうちにレンズが外れていたのがあったからすぐ取れるかと思ったのだが。。 結局、ガリガリやってるうちにレンズはパキンッと割れてしまった。。。 あぁ～ぁ・・・ あの外れてたやつが当たりだったのかぁー（普通なら不良品なんだけどね）
結局、次の日（１２月３０日）にもう一度渋谷まで行き、レンズが外れた不良品を買ってきました。よく見ると外れたレンズの一部が欠けているのだけど、像には影響ないみたい。魚眼レンズが１０００円かそこらで手に入る訳だから、まーいいかと。
 |
 |
画像じゃわかりにくいけど、この魚眼レンズは２枚で１セット。それぞれ球面の掘り込みがあって、掘り込み同士を合わせるようにすると球状のレンズ面が作れるというわけで、安いのは製造方法に依るものらしいね。 どうやら１８０度モノは球面形状をしていると思われる。そっちも欲しくなってきたなー。（主旨が変わってきてるけど）
右のがレンズが取り付けられている胴体。上側のシルバーが分解に失敗したモノで、下のが始めからレンズが外れていたいもの。この胴体には接眼レンズが仕込まれているのだけど、接眼レンズがきちんと取り付けられておらず、その結果魚眼レンズ側のハメコミが甘くなって分解してしまったらしい。うれしい誤算だ。(^.^)
早速、魚眼レンズをデジカメのレンズにくっつけてみたんだけど全然ピント合わないね。しかし、この長ーい胴体をCCDの前に取り付ける訳にはいかないし、何よりこのままだとCCDの周辺画素が無駄になる、解像度が下がるなど、メリットよりデメリットが多い。このままでは使えない。
広角視野の周辺部を歪ませて円形平面に投影しているわけだから矩形のCCD面にはマッチしない。円形平面を全て矩形に収めても周辺部分に無駄が相当できてしまう。円形の端を若干削って、できるだけ画素全部を活用できるようにしないとならない。 できるのかなー、光学系勉強しないといかんか。
デジカメの前においてみた。ロボット的には解像度より視野かな、と。 魚眼のいいところは中央部分の解像度は周辺部より高いところ。これは人間の目と共通するところがあってなんか良い。周辺部に動くものを見たらそちらを振り向くって感じにできればいいかと思う。中央部だけを切り出せば歪みは無視してもよいかもしれないな。
VMwareのネットワーク
帰省中はいつもダラダラと年末年始テレビを見たりして過ごしてしまう。去年まではアイボとＰＣを持って帰ったりしてたんだけど、一度も開かずに終わったりしてた。
今年はラムダを持って帰るってわけにもいかないのでRPU-100とＰＣを持って帰ってみた。サーボ系は置いといて、放置してたサウンド系の整備をしてみようかなという計画だった。
で、ネットワークに激しく引っ掛かった。 WindowsXP上にVMwareを入れて、そこにＮｅｔＢＳＤを入れているのだが、LANなしでもネットは成立するの？ ⇒ しませんでした。
VMwareのネットワークにはブリッジ・ホストオンリー・ＮＡＴの三種類の形態が用意されているのだけど、デフォルトはブリッジ。ブリッジはホストＰＣにあるＬＡＮポートにゲストＯＳのポートをブリッジすることになっている。家で使っている時のＬＡＮポートは有線ＬＡＮで、ゲストＯＳはこれにブリッジしているらしい。帰省先では有線ＬＡＮ環境がないのでRPU-100との通信をするために無線LANのAPだけ持って帰るから、AP内臓のDHCPサーバーを使って、無線LAN環境を作ることになる。後で調べたら無線LANでも同じようにブリッジするはずなのだけどしない。 結局、ホストオンリー形にしてゲストOSだけの仮想LANを構築することでなんとかなった。しかし、これだとゲストOSからRPU-100へはつながらなくてホストOSで一度仲介しないとならないのですごく不便。。 せっかく自宅環境を持ち出せる様にメインPCをノートPCにしているのにこれじゃまずいね。 整備しなきゃ。
帰省から帰ってから元に戻そうとしたのだけ、ブリッジ環境にしても戻らない。（が～ん） 困った困った困ったと数時間格闘したらフイに復帰。。 解せないがまぁいいやと思ってたら一度電源を切ったらまたダメ。 結局、仮想LANポートをもう1ポート作って、一つをブリッジに、一つをホストオンリーにするという事で安定したみたい。なにか設定が足りない部分があるのだろうとは思うのだが、そのうちに考えよう。 一日フイにしたよ。。。
RPU-100のサウンド
随分前にサウンドデバイスをちょこっといじったっきり放置だったので、すっかり忘れてしまった。おさらいからやりなおし。
書きかけのテスト用プログラムを動かしてみたり読んでみたり、NetBSDのマニュアルページを読んでみたり。。
目的を明確にすると、 理解できる形でサウンドデバイスからデータを取り込む、ってこと。 サウンドデバイスからデータと取り込んで、サウンドデータにデータを送り込むと再生するってことは出来るのだがそのデータを覗いてもよくわからん。初期状態のサウンドデバイスの設定もわからん。ここをクリアしないとね。
いろいろいろいろいろいろいろいろ試した結果、今のところわかったのは、
・ サンプリング周波数は8000ヘルツしか受け付けない
・ チャンネルは１と２（モノラルとステレオ）の設定ができる
・ ビット数は８と１６
設定（ビット数とかチャンネル数）を変えてもデータブロックサイズが変わらないのが気になる。サンプリング周波数はホントに8000ヘルツオンリーなの？せめて16kHzは欲しいな。
エンコーダの設定を変えるとエンディアンは反映されるのに符号付と符合なしではあまり差が見られない。（あ、リニアオンリーね。μlawとかは見てない） 符号付きで録音して符号無しで再生すると、無音時のノイズ（？）が発生するから値は違ってるはずなのだが数列見るだけじゃわからんなー。 ちなみに音量は変わらない。
さて、続きをやるかぁ～。
■１月９日■
サウンドの続き
８日～９日にかけてサウンド関係の続きをやった。結構、悲しい結果に終わった。
まず、、、設定を変えても反映されるのはエンディアンだけ。 サンプリング周波数は8000しか受け付けない。チャンネル数は１と２を受け付けるが、吐き出すデータに変化はない。ビット数も同じで、１６ビットでしか吐き出さない。
更に、サンプリング周波数とデータサイズが一致しない。サイズと再生時間から逆算すると14000Ｈｚくらいのサンプリング周波数ということになる。でもなー。スピーシーズの標準のソフトだとウィンドウズからWAVファイルを送り込むことになっているわけだからもしそうならレート変換をしているって事になる。うーむ。。
データは２チャンネル分のデータなのだが、どうも不審な部分があるから片側のマイクを取り外してみたら・・・ 片方のマイクからしか音を拾っていない事が判明。どうして片側からしか拾ってないのに左右で違うデータが吐き出されるのだろうか？
最悪、ステレオマイクはどうでもいいんだけど、サンプリング周波数だけははっきりさせてもらわないと音声を生成したいのに出来ない。
あまり詳しくはなかったんだけど、調べてみると、/dev/audioのデフォルト設定は8000,1ch,8bit,mulaw らしい。これはSun標準らしい。で、設定を変更しても/dev/audioにアクセスするとこの設定に戻るというのが仕様らしい。 設定が戻るところだけは合ってるけど、他は全然違う。これだけ違うなら情報公開して欲しい。 つーか、ステレオで音とってないのは不具合だろう。 ドライバーソースの公開と、カーネルオブジェクトの提供くらいはして欲しいなー。
とりあえずは質問メールをスピーシーズに投げておいた。ちゃんとした回答希望。
おいでよ どうぶつの森
あまりに世間で話題になってて、楽しそうなので年末に買ってしまった。 ネットゲーとは言えないかもしれないけど、ネットゲーの要素をうまく取り入れたゲーム。
ネットゲーといえば、ウルティマオンラインが公開された時から１年半ほど毎晩３時くらいまでやったなー。あのころはまだテレホーダイでしかネットにつなげなくてつらかったけど、すんごく面白かった。 どうぶつの森でもネット詐欺とか居るみたいで結構ワクワクする。
どうぶつの森の世界も結構ウルティマオンラインと似ているところがあって、戦闘オンリーじゃないＵＯの生活の部分を思い切りライトにした感じ。 ＵＯが懐かしくなってきたなー。
実は一度ＵＯが懐かしくなって、再度始めた事があったんだけど、キャラクターをこつこつと育てる根気がなくなってて、すぐにやめてしまった。友達ができなかったのも原因の一つ。始めのＵＯはＰＫっていうキャラクターキラーが可能で、それも面白さの一つだったんだけど、今のＵＯは何でも有りの世界（サーバー）とＰＫなしの安全な世界（サーバー）に分かれているみたい。 ネットワールドでは神様（サーバーソフト）には隠し事ができなくて善人がつらくなりすぎるんだよね。悪人はすごしやすい。
１年も続くかどうかわからないけど、しばらくやってみようかなーとか思ってる。
キャラのかわいさもちょうどいい感じ(^.^)
■１月１５日■
サウンド問題
２チャンネルとも同じマイクからデータを取得していた件、サンプルレートがおかしいかもしれないという件について、スピーシーズに問い合わせたところ、２チャンネルの件についてはドライバーかチップの問題の可能性があるとのことで調査待ち。サンプルレートについては設定用のコマンドがあるらしく、コマンドを教えてもらった。早速コマンドを使ってみたところ、8000Hz、16000Hz、24000Hzに設定して録音したデータが計算値とほぼ一致した。
サンプルレートについては一応片付いた形だが、この辺りは情報公開してくれないと意味のない時間を使ってしまう。サポート悪いな～。
２チャンネルの件はまだ原因未確定なんだけど、ちゃんと再現してみて回答しているのか不明。対応の悪さを感じた。
音声合成
サウンドをいじっているのは何も帰省の荷物を少なくするわけじゃーなく、ラムダに音声合成でしゃべらせるため。僕の考えるロボットは、なにも、人間と同じ知能を想定しているわけではないので人語を操る必要は無いのだけれど、意思伝達（状況報告？）のアイテムとして発話は有用だし、ロボットとして見栄えがすると考えている。モチロン、ゆくゆくは音声認識での情報入力もしたいと思っている。
音声合成はそれだけで、大きな一分野のアプリケーションだし、幸いフリーの音声合成プログラムがソースも公開されている。Galatea Project (ガラテア・プロジェクト)
ガラテアプロジェクトは音声認識・音声合成・顔画像合成で対人対話するマンマシンインターフェイスアプリケーション、これの音声合成と音声認識をラムダに移植しようと考えているのだ。
音声合成部分はGtalkという単独のアプリケーションになっている、Gtalkは音声合成シンセサイザーと、形態素解析プログラム「Chasen」、さらにイントネーションを制御するための「ChaOne」を組み合わせたものだが、これをラムダに移植する考えだ。 これはアイボにも移植した経験があるのだが、そのときには発話部分のみの移植だったので、単語発話のアプリケーションにはならなかった。今回は発話部分と、形態素解析部を移植しようと考えている。
すぐ終わるかなーと考えていたのだがなかなか手ごわい。cygwinでコンパイルした時は結構すぐに動いたのになぁ。
歩行制御は・・・
帰省が機になってサウンドに着手したのだが、ここで手放すと次に着手したときにまた始めからになってしまう。歩行が行き詰っていることでもあるし、音声合成の移植までは完了させてから歩行制御に戻ろうかと思っている。５月のロボカップオープンも難しいなー。
ただ、このまま歩行制御を棚上げにすると現在の問題点ごと記憶から消え去ってしまうのでカルテだけは整えておこうと思う。
■１月２１日■
ＰＳＰで自作プログラム
ＤＳだけじゃなく、ＰＳＰも持ってる。 ＰＳＰを買うとき、きっとメモステからブートできるはずだし、きっと開発環境が整うはず。そしたら、ロボットの端末に使えるかも。と思ってた。 もうそろそろそういうのも出揃ってるかなーと思って少し調べてみた。
・最近のファームバージョンはVer２．６まで上がってる。
・Ver.１．０だと、自作プログラムがコンパイルできる環境（PS2DEV＋いろんなユーティリティー）がある。
・最近はVer.１．５でもブートできるらしい。
・うちのＰＳＰはVer.１．５をファームアップして２．０にした。
・２．０に脆弱性があり、それにつけこんだダウングレードプログラムが存在する。
ふむふむ・・・、では、Ver.１．５にダウンしておくべきだな。Ｗｅｂブラウザは全然使えないし、使う機会もない。ただ、１．５にしたら、表示をサポートしている画像フォーマットが随分と減るのがちょっと心残りだが。
緊張しつつ、ダウングレード成功。ちゃんと表示はVer.１．５になった。ただ、環境設定が壊れるはずなんだけど、壊れないんだよね。う～ん。。
で、自作ソフトやらを動かしてみようと思ったら、色んなゲームが用意されてる。おぉぉぉ、Ｄｏｏｍもあるし、Ｑｕａｋｅまである！！すごいなー。・・・・ 動かない。落ちちゃう。ブートに失敗する。どうなってんだー。 まぁ、いまＰＳＰで動くソフトを作るつもりはないからいいのだけれど、マニュアルどおりにはいかないなぁ。そういえば、２．０にアップする時もなかなかうまく行かなかった。個体の問題があるのか？？
ＤＳで自作プログラム
ってのもあるらしい。どうやってプログラムを挿入するんだろ？？って思ったらＧＢＡ用のフラッシュロムカードが使えるんだね。なっとく。それにしても世のハッカーたちはすごい人ばかりだ。これだけのことを開発メーカーの資料なしにやってしまうのだから。ありがたいことです。 ホントに内部資料なしかどうかはわからないけどね。
ニンテンドーＤＳ Wifiアダプター
これ、なんだか欲しいなーって思って買おうかとも思った。もしかして、ノートＰＣに付けたら無線ＬＡＮのAPになって、ＤＨＣＰサーバーにもなるとかならないか？って思って調べようとしたんだけど、多分、普通の無線ＬＡＮアダプターかも、ＤＳとアドホック通信してるのかも。と思ったらその通りだった。ＸＰしか対応していないのはブリッジしないとＬＡＮと接続できないかららしい。
音声合成
形態素解析プログラム（Chasen）と、その辞書のコンパイルまで完了した。 で、軽ーく、単純な日本文をChasenにかけてみたら文字化けした出力が出る。
■１月２７日■
音声合成
ChasenにはDartsというSTLライブラリが必要なのだが、一筋縄ではいかない。
ライブラリといってもヘッダーでソースが記述できる程度のボリュームなので、インストールは簡単なはず。 だが、動作を確認しようと思って、サンプルプログラムをコンパイルしようとしたところうまく行かない。
サンプルプログラムはhttp://www.chasen.org/~taku/software/darts/に掲載されているものを使ってみた。ちなみに、配布パッケージに同梱されているプログラム「darts」「mkdarts」は問題なくコンパイルされる。問題なく動作するかどうかは不明。
gtalkをコンパイルしてる時からあったのだが、c++の仕様として引数のデフォルト設定がされている場合、引数を省略できるというものがある。これがうまく行かずにコンパイルエラーとなるケースがあった。引数を明示的に指定することでコンパイルを通してきたのだが、Dartsでも同じことが起こっているように見えた。Dartsのサンプルプログラムでも同じことが起こっているように見えたので引数を明示的に指定してみたがうまく行かない。どうやらテンプレート型が確定しないのが問題のようだ。
で、テンプレートの勉強も兼ねてちょっとヘッダーファイルを読んでみた。
まずは、サンプルプログラムで返り値の型が確定しない、Darts::DoubleArrayImpl::exactMatchSearch(
) の返り値型名を指定してみる。
cout << da.exactMatchSearch<int>("ALGOL") << endl;
これでcygwinや、netbsd(ネイティブ）ならうまくコンパイルできた。
肝心のpowerpcクロスだとエラーが出る。文法がおかしい。どうも、コンパイラーが古くてテンプレートの型名指定の部分で細かい仕様変更がされているのではないかと思われる。（事実関係は調べてない）
でも、それではまたクロスコンパイラーの構築からやらねばならないということで、またクロスコンパイラービルド地獄に入るのはいやなのでなんとかしのぎたい。で、更に更に考えてヘッダーファイルを読んでみたのだが、なにかおかしい？
exactMatchSearch( )の返り値はDoubleArrayImplのテンプレート型名が確定した段階で確定しなければならないはず。仕様を見ても、ヘッダーファイルを読んでもそのような扱いである。すると、
cout << da.exactMatchSearch("ALGOL") << endl;
で良いはずなのだ。他のメソッドにも返り値の型名がテンプレート指定になっているものが沢山ある。クラスのテンプレートが確定する時点で返り値の型名が確定しないって状況が想定できないのだが、どういう意味があるのだろうか？
結局、darts.hを若干修正して、返り値の型名が確定するようにしてクロスコンパイラーでのコンパイルが可能になった。さっきのサイトにはもう一つサンプルプログラムが掲載されているのだが、こちらもそのままではコンパイルできない。 #include<iterator>を追加しなければならないようだ。STLに慣れてないのでそれに行き着くのに悩んでしまった。
せっかくだからここに修正済のサンプルプログラムを載せておこう。（いいのかな？）
↓マニュアルでデータベースを作って、検索してみせるプログラム。作ったデータベースはファイル出力している。
↓さっき作ったデータベースから、キー入力した単語を検索してみせる。コモンプリフィックスサーチだと、”ABCD"という検索対象には”A","AB","ABC","ABCD"が合致する。
これでDartsはうまく行ったので次はiconvライブラリ。さっくり行ってくれぇ～。
■１月２９日■
libiconvを移植するのがイヤだなー、よく考えると漢字コードが混じらなきゃ要らないわけだし、Chasenを修正してlibiconvなしでいいようにしよう。 と、思って調べていくと、どうやらuni-dicはエンディアンに依存するデータらしい。すると、cygwinで作ったuni-dicは使えないわけだ！ ちょっと道のりが長くなってきた。unidicの辞書ファイルのサイズも無視できないくらい大きい。なんせRPU-100はメモリーはそこそこ積んでいるがストレージが悲しいほど少ないのだ。節約せねば。 音声合成より音声認識のデータサイズが大きいのにこれじゃ完全にスタンドアロンは無理っぽいな。もっと容量が大きな小型コンピュータを探さねば。
Chasenは後回しにしてgtalkを動かそうと、方向変換を行ったのだが、動作確認のため、i386-netbsdで動かしてみることにする。こっちで動かなきゃRPU-100で動かすのは無理だもんね。 動かして、その後にChasenを切り離す改造をして、それからRPU-100に移植。 ところが、まともに動かすにはChaOneも必要らしい。
早速改造して、ChaOneなしで動くようにするって手もあるが、ChaOneも作ってみておこう。 ・・・と思ったのが運の尽き。 ChaOneは昔はJAVAで動いていたのだが、C言語に移植されたらしい。そのときにXMLベースで動作するようになったらしく、libxml2 というのと、libxstlというライブラリを要求してくる。聞かない感じのライブラリーだなーと思ってなんとか見つけてきた。で、インストールも簡単にできた。だが、ChaOneがコンパイルできない！ うう～ん。。 どうもおかしい。
あ、書き忘れたけど、powerpc-netbsd-gcc で、vfprintf vsprintfなどがうまくコンパイルできないという現象が発覚した。これもわからん。
ChaOneもおいといて、gtalk動かそう。それがいいよね。きっと。。
■２月１１日■
＜音声合成＞
すったもんだがあったけど、ＲＰＵ－１００で音声合成で発声できるようになった。随分と遠回りしたなー。
結局、よく考えた結果、日本語普通文を入力して、形態素に分解して発話するというのはロボットが発話する場合にはおかしいと思い立ち、形態素解析部の移植はやめることにした。Chasen、ChaOne、iconvは移植しない。
今後、発話文章を合成するプログラムを別途作成して、それをそのままGtalkに入力することで発話するって感じにしようと思う。
Gtalk自体もキーボードUIがついてるんだけど、これは全然必要ないから削除するつもり。ログとかメッセージ機能も基本的には要らないね。スリムアップスリムアップ。
きっと、PowerPCとインテルCPUではエンディアンが違うから作成データのエンディアンが問題になったりしててこずるんだろうなーとか思って、まずはPC上のNetBSDでデバッグしてからPowerPC版に手をつけようと思ったのが運の尽き。なんか、VMware上で動くNetBSDのオーディオデバイスは動作がおかしいです。バッファがバッファになってない。10秒くらいの発話データが5秒くらいで終わってしまう。再生は飛び飛びになってしまったりして。はじめ、それをNetBSDのせいだと思って、オーディオデバイスの使い方を色々と調べたりしたのだけど、結局VMwareのオーディオデバイスの振る舞いがおかしいという結論になった。
RPU100用のコーディングしたらあっさり動いてしまった。(-_-;)
＜サウンド問題＞
サウンド問題は片側のマイクは動作していないことが確認された。ハード的には切り替えて使うことになりそうだ。マイク二つあって、切り替えて使用ってどうなんだろう？どうやって使えというのだ？とにかく、これでステレオ的音声入力を期待することはできず、キュリオのような音源方向認知はできなさそう。
しかし、、、採取データはステレオで、マイクは二つあるのに片側は動いてない。。 ボロボロですね。スピーシーズ。
■２月２６日■
＜音声合成＞
どうも、最近のバージョンはイントネーションに関してはすべてChaOneで決定しているらしい。なんだかソースはあるけど動かない部分が多い。コレってChaOneがあればちゃんと動くのかなぁ。音素列への分解ができればあとは呼気や区切りをどこに置くか、イントネーションをどこにおくかといった制御。カタコトでしゃべるロボットには無くてもいいかなーとも思うが動かし方だけ確認しておこう。
普通文を形態素解析するChasenも入れないし、どうやって発話を制御するかしばらく考えたが、直ぐに結論を出そうとすると、発話するセリフを用意しておいてそれを送り込んで終わりと言うことになりそう。ちょっと面白くないのでそこんとこはもやもやとした感じで置いておこうと思う。考えているイメージを実現するには簡単でも人工知能が必要。いまはそれに相当するものが全然ないからなぁ。
＜音声認識＞
音声合成をやってたら音声認識もやりたくなってきたので、同じガラテアプロジェクトのJuliusをダウンロードしてきた。
２年ほど前にCygwinでコンパイルしたときは随分と苦労して、Cygwinでコンパイルできたバージョンを探したりしたが、どんなもんだろー、、って思ったらすごくソースが洗練されたようで、Cygwinではconfigure makeで完了した。驚きと喜び。
実はこれはRPU-100に積めるレベルじゃないなーと思ってる。サイズでかすぎ、処理重すぎ。処理系をロボットの外にだすのはいやなんだけど、音声認識はしばらくはＰＣからかな。アイボはやってるから単語認識レベルならできるのだろうけど、Ｊｕｌｉｕｓをスリム化する能力は今のぼくにはない。
＜画像転送＞
画像認識を行うにはＰＣでモニターするものが必要。ところがＵＮＩＸでのネットワークプログラミングってやったことないんだよね。アイボのときはアペリオスとＶＢで通信した。
まずは、サンプルプログラムで画像取得。 おぉ～でけたー。 今度はＶＢ側でこのファイルを表示しなきゃならない。なんせサンプルプログラムで作成する画像ファイルはＲＧＢ値にはなっているけど、どの画像ファイル形式でもないので（ヘッダーもない、データだけ）
しばらくぶりのＶＢでちょっともたついたけど、表示は無事できた。
次はネットワーク接続関係。色々調べたりして、だらだらやった結果、１週間もかかってやっと連続画像転送ができるようになりました。画像の表示が遅いので転送を間引きしないとバッファにたまったフレームデータのせいでリアル感がない。どちらかというと、レゾリューションを下げてフレームレートを上げた方がいいかなー。
ソケットを使ってデータを送るんだけど、受信側のバッファサイズによるところがあるのだろうが、フレームの区切りでパケットが分かれなくて、フレームが区切り無く送られる。受信側で美しくフレームに分割するためのコーディングに悩んでしまった。フローチャート書くのが嫌いで構造化言語風に考えたいんだけど、美しくまとめるには結構考えなきゃならない。まぁまぁ綺麗にまとまったからそこそこ満足です。 ヘッダーがパケットで分割されてしまった場合は想定してないから完璧じゃぁないのだが、勘弁してもらう。
ラムダのカメラで撮ったラムダの体。 ＢＢＳに貼ってるのと同じだけど。
■３月１９日■
久しぶりの更新。最近、作業メモをテキストファイルに書き出すようになって、こちらの更新をしないようになってしまった。いかんな～。
＜音声合成＞
Gtalkを形態素解析なしで動かせるように改造。一応、形態素解析したテキストファイルも再生できるようにはしておいたけど、基本は全角カタカナで記述されたセリフを再生するようにする。カタコトでしゃべるって雰囲気なのでイントネーションなどはあまり厳密に再生しないでいいかなーという考え。
半角数字を読み上げることや時刻や日付を半角テキストから読み上げるくらいのことは出来た方がいいかなということで簡単なテキスト解析をすることに。
テキスト解析といえば正規表現だがC++だとPerlみたいなすばらしいテキスト処理ができない。どっかにライブラリが無いかと思って検索したらboostっていうどうやら有名なC++用のライブラリがあることがわかった。さっそくダウンロードしてインストールしようとしたのだけど、なかなかできない。最後にはコンパイラーの内部エラーとかでお手上げ。。
やりたかったことは簡単なテキスト解析だからまぁベタで書いてもいいのだが、、便利なライブラリが使えなかったのが残念。
数字読むだけでも色んな変化をするので形態素解析が欲しくなってしまう。が、流暢な日本語をしゃべる必要はないから我慢。なんとか、数字だけはそれらしく読み上げることが出来るようになった。
アイボなどを見てて思うのは知能が低いくせにちゃんとしたセリフをしゃべらせようとしているのに無理があるのだと思う。言葉なんて高度な知能からしか発生しないのに低脳のロボットが正しい言葉をあやつれるわけがない。なのに簡単な状況判断だけであらかじめ用意したセリフをしゃべるものだからとんちんかんな発言になったりする。セリフから知能がばれるわけだからごまかしは不要。知能レベルに合わせた発言をするしかないのだ。
そういうわけでラムダにはキチンとした日本語をしゃべらせるつもりはない。 まぁ、システムメッセージとか、特別なものはあらかじめ用意したセリフを一方的に発するだけだからそれはそれで構わないとおもっているのだが。
なにはともあれ、これでRPU-100が立ち上がったら合成音声で発話するようになった。いままで自分の声を録音したものを再生していたから早く合成音声にしたかった。
ちょこっと発話させるだけで４MBくらいのメモリーを消費する。はたしてだとうなのかどうなのか、もっとスリム化したいという気持ちもあるが、そろそろ音声合成は〆た方がいいよなぁ。
続きは発話衝動とか、知識データベースとかと連携してやらないとあまり意味がないだろう。
＜そろそろ歩行＞
年末から音声関連と画像関連に取り組んできて、気付いたら３月も下旬。・・・もう３ヶ月もこれをやってるのかー！！ 歩行制御がうまくいかないし、帰省にラムダを持って帰られないからと思って音声に取り組んだんだが、そろそろ歩行に戻らないとなぁ。しゃべれたって歩けないロボットじゃしかたがないし。
■４月１日■
＜そろそろ歩行＞
そろそろ歩行の検討を再開、と考えてどういうアプローチで進めるかを検討していた。たしか、左右の反復動作が安定しなくて・・という状態だったはず。ジャイロのデータはどうしても誤差を累積してしまうのでバランスがくずれているのか誤差の累積によるズレなのかの判定ができず、補正ができないこと。サーボの負荷データにはばらつきがあり、無負荷状態での数値がオフセットとして存在すること、もっともこちらは無負荷時のオフセットを測定し、オフセット値をセットするところまでは実装したので影響は少ないはず、といった状態だった。
角速度センサーというと、人間で言えば三半規管に当たるセンサーで、人間が目を閉じて激しい動きをすれば自分の姿勢が判らなくなりやはり、今のラムダと同じ状況になるだろうことは想像できるが、人間には目があるし、相当激しい動きをしない限りは立っていられないようにはならない。やはり、動作中の姿勢安定性を今以上の精度で取得することは必要事項である。加速度センサーの値を監視し、角速度センサーの値の妥当性を確認していくという線で検討することにする。静的に見ると加速度センサーの垂直方向の値はロボットの姿勢に対してCOSで効いてくるので細かな姿勢は読み取れない。水平方向の加速度は静的にはゼロなので意味を成さない。 今問題にしているのはロボットが歩行動作をしているときの姿勢安定度の測定、具体的には左右の反復動作においてアンバランスな状態の発生を感知したい。これは水平化速度の動的取り扱いで抽出できるのではないかと考えている。加速度センサーの値はノイズが多く、安定した値を得にくいが、絶対値なので測定時間をある程度調整すればバランスを測ることができるのではないかと考えている。
＜VisualC++＞
いままではセンサーデータなどはファイルにしておいて、ロボットを停止した後にダウンロードしてエクセルでグラフを書いていたのだが、リアルタイムでグラフを書かせてもいいかなーと思い出した。 ビジュアル的な表示が必要な時、いままではVisualBasicVer.6を使ってきた。これは非常にお手軽にウィンドウズプログラムを作ることができ、重宝している。VisualC++やVisuaｌ.Netももっているのだが、勉強するのがいやで、簡単なVB6を使ってきた。
しかし、VB6はCとは言語仕様が異なり、細かなデータ操作をする場合などに不都合が生じることも少なくなく、VCの採用を検討していた。何年か前にVCの本を読んでMFCなどを使ってみようかと思ったのだが、クラスライブラリを調べたり覚えたりするのがイヤで敬遠していた。Win32APIなどもっと面倒で、実用のために勉強する気が起こらなかった。 昔、XWindowに興味があって勉強したころはシステム自体に興味があったので一生懸命調べたり勉強したりしたのだが、大まかなウィンドウシステムの考え方がわかったら興味は半減した。 仕様が違うだけで元の概念はおおむね同じなのでめんどくさくて扱う気にならない。。
でも、アイボからこっち、ずっとC++を使っていて、クラスライブラリの概念や使い方もだんだんと馴染んできたのでMFCを使うのも苦じゃないかなと思って、今後はモニターアプリをVC++で作ろうかと思っている。.NETがいいのかもしれないけど、インストールしていないのでVer.6で。
とりあえず、ソケット通信プログラムと画像表示ができないとお話にならないので、こないだVB6で作った画像転送プログラムを作ってみることに。 ソケットプログラムにしても画像表示にしても、それぞれ流儀があってやっかいである。通信はまだいいが、画像表示はいろんな書籍やヘルプでデバイスコンテキストの存在と考え方が解説しているのだが、さっぱり理解できない。詳しく書いてあるモノは難解で、簡単に書いてあるのは手順を示すだけで応用しにくい。高度な概念と使いやすさを（もしかしたら理解しやすさ？）を追求しているのだろうなぁというのは感じ取られるのだが、解説が不十分な気がする。きちんと理解している人が正しく解説してくれたらその高度なシステム概念が理解できるであろうと思うと少し残念な気がする。 どちらにしてもロボットプログラムに直接関係しなさそうなウィンドウズシステムを深く理解する余裕はないのでユーザープログラマ的立場での理解に留めておきたい。
結局、いまのとこ24bitカラーデータを32bit形式に変換して表示することができている。が、これしか方法がないのだろうか？VB6ではWin32APIを使わないとできなかったBitbltでのデータ転送ができてうれしい。でも、無線LANの速度が遅いので360×240の画像データだと高速表示は不可能なのだが。。圧縮とかまでして画像データを再生するつもりはないのでこれはこれで完了。 MFC使えそうでよかった。コーディングがC++で統一されてうれしい。
＜関節制御の方法＞
ずーっと考えていることなのだが、関節制御の方法である。サーボに目的角度を指令してコマ送りで姿勢を変化させていくというやりかたをやりたくない。モーションデータの再生という方法は始めから除外しているのだが、計算歩行というのも除外している。 おおまかな動きの雛形は（じつは）もっていて、おおむねそれに合わせて動くのではあるが、詳細はその場で決定するという方法をとりたい。それもできるだけ物理的計算を使用したくない。予測値によるフィードバック制御で足の制御、具体的には歩行を行いたいのだ。
思いつきの感が強いのではあるが、関節の柔らかさが必要になるはずである。これは、コンプライアンス制御といわれるものに含まれるのかどうかはわからないのだが、必要に応じた応力への反応、「順応と反発」が必要となる。目的に応じて順応と反発を切り替えなければならないのが問題で、単純な自動制御機構だけでは実現できない。
もしかしたらまずは、４足歩行のプロセスが必要なのかなぁなどと考えている。赤ん坊がハイハイをし、つかまり立ちを経由して歩き出すというプロセスがロボットの歩行制御のパラメータ決定の中に必要なのかもしれない。
つかまり立ちはロボット、特にモーション再生的なプログラムや座標計算、物理計算によって制御されているロボットには困難な課題である。関節の負荷をフィードバックして現状の動作を決定する必要があるので、適したモーションを準備しておくことは不可能だし、物理計算するための物理的条件やパラメータを準備しておくことも難しいだろう。センサーなどから得られた情報からそれらを得たとしても精度の問題から使用可能なレベルのデータを得ることは困難だろう。
また、２足歩行の場合、関節負荷に順応するだけでは立つことができない。「立つ」ということに関しては関節負荷を立位姿勢状態で最低に持っていく必要がある。つかまり立ちの場合は必ず負荷が下がる方向に最適点があると考えて間違いなさそうだが、立位を保つにはそうとは限らない。恐らくほとんどの場合、負荷の山と山の間にある谷間に最適点がある。これを見つけなければならない。目的点が予測されたとしても、リニアな動作では到達できない場合が多く、姿勢を大きく変えて（たとえば一歩前に足を出すなど）到達点への経路を確保するなどのプロセスが発生するだろう。
足に自由度が６もあるとはいえ、一般的に必要と思われる関節の動きはある程度限定されている。たとえば「歩行」しかできない足があるとすると、関節に６自由度があったとしても足が取る姿勢は常に歩行の１コマとなる。実際にはそのときの外部条件により微調整が入るのでまったくの固定ではないが、この関節間の連携性も必要になるのではないかと考えている。この関節間の連携性は計算歩行やインバースキネマティクスから計算される関節角度列に置き換えることもできるだろうが、外部情報からのフィードバックによって微調整されるべきものだろう。
と、こんな感じに思考していて、構想が飛躍してしまっている部分も少なくない。少なくともラムダのシステムで実現できる構想にしなければ、またはラムダのシステムの見直しの要否を判定しながら進めなければならない。できることからやらねば、一歩も進まない。
■４月１９日■
＜歩行制御＞
モーション再生とはまったく違った形で関節制御を行いたいので、プログラムも全面作り直し。
基本的にはトルクを制御することで関節の動きを制御したい。いままでは角度と移動時間で動作していたが、角度とトルクで動作させる。不十分なトルクで動作させるので遅れが発生する。これを利用する。足首はできるだけトルクを小さくし、接地面に慣らされるようにする。これはコンプライアンススロープを使うようにすればよいのではないかと考えている。
関節の動作自体を他の関節と連携し、ここに遅れや反発を取り入れることで複雑な動作を再現できないかと考えている。 もちろん字を書くような動作は不可能だが、歩く動作などは可能ではないかと考えている。
荷重に対する関節の動作は大きく分けて「反発」と「順応」の二つになる。これをどのように切り替えて制御するのかが課題。（というか肝）
形になるかどうかはわからないのだが、実験的にやってみようかと思っている。 ロボカップジャパンにはまだまだ出れそうにないなぁ。
■５月２８日■
ロボットの制御手段がまとまらなくて、ゴールデンウィークに本屋で物色してきた。まだ斜め読みなんだけど、面白そう。
人間の脳の構造、特に言語の獲得についての考察と記号化と言語の関係について概論的に説明している。
分散システムと連続システムをつなぐ仕組みが必要とか、力学的情報処理など、興味深い概念が説明されている。
分散情報システムと連続システムをつなぐためにＨＭＭを利用する例などが紹介されていて、参考になりそう。
＜ISBN4-00-011151-5＞ \1300
こちらは数年間くらいかけて勉強するための教科書って感じのボリューム。カバーしている範囲も広い。
普通コレくらい広いと概論になってしまって、参考にならない本が多いけど、相当詳細に書かれていて、これに書かれていることを足がかりに勉強できそうなくらい。
「動的システムとは」から始まって、空間、感覚、運動制御、CPG、運動のプランニング、最後は身体知までカバーしてる。
これまでこの分野で研究されてきた内容とその成果がまとめられている。こちらの方面でロボットを考える上で参考になると思った。
ゆっくり読んで身につけたいと思います。
＜ISBN4-320-12135-X＞ \5500
上の本でも、関節角度をアウトプットにしてHMMデータを作成したりしているのだが、関節角度って監視情報なんじゃないかと思ってる。出力はトルクじゃないかと。
HMMの出力は監視情報であるところの関節角度群の記憶で、その記憶している関節角度になるようにトルクを与えるって考えると同じなんだけど。
あと、人間の関節は関節を曲げる筋肉と伸ばす筋肉のバランスで、関節の柔らかさまでコントロールできる。この関節の柔らかさはトルクスロープで表現できないかなーと考えている。
タイミングはCPGでとることで決まりみたいなんだけど、CPGってのをもっと広く捉えて関節動作条件の相互組み合わせもCPGって考えるべきじゃないかなと思う。あと、CPGの引き込みって考えが重要なんだけど、CPGが引き込みで動作周期を変化させるってより、外部環境に応じてタイミングを可変するって考えた方が自然。「CPG」を「素子」のように考えるとズレてしまう気がする。
というのも、町でポテポテと歩く幼児を観察していると、大人の歩行に比べて歩みのテンポが不規則。バリスティックな歩行ってのはアレくらい不規則な周期になるんじゃないかと思った。大人の歩行はテンポを一定にするために随分と力を使ってるんではないかと思う。目指すは幼児の歩行だ。
■６月１９日■
アイディアはまとまらないは、変な風邪をひくは、ワールドカップは始まるは、Newスーパーマリオは面白いは、ですっかりロボット開発から離れている。ある関節の動作をある関節の動作を起点として動作させ、それを連鎖させることによってモーションを形成する、という方法でそれらしい関節の動きを生成することが出来そうだということがわかってきた。またその動作をする時には関節に与える指令をできるだけ単純にすることでバリスティックな動作をさせることができる。関節間の連携をうまく組み合わせることで歩行時の足の動作などを作ることはできそうである。
ただし、左右の足を互い違いに動作させることが今のところうまくできない。
試行錯誤を繰り返すことでそれらしい動作を作ることはできるかも知れないが、イマイチすっきりしない。CPGのような基準になるような「なにか」が必要な気もする。 色々と試行錯誤をしているうちに、足の動作を制御する時のCPGは足の関節の動作から生まれているのではないかと思えてきた。 いま、足の往復動作を行うのに、股関節前後関節の関節角度を起点として関節にトルクを与えている。これにより、股関節前後関節はある程度一定周期で前後運動を繰り返す。この前後運動を起点として、もう片方の足の股関節前後関節に前後運動を発生させようとしてもうまく反転同期した動作を生成できない。
これはリズムを生成するのに片側の関節しか使用していないからではないか、リズム自体を左右の股関節前後関節で起こすことで反転同期したリズムを生成できるのではないかと思い出した。できるんじゃないかなー、ちょっと考えてみようと思ったのが既に２週間くらい前、それから先に書いたような様子でさっぱり考えていないので未だ白紙なのだが、、、。
以下にそのあたりをまとめてみた文章を２週間前に書きかけたので一応載せておく。
多くのロボットの関節制御として、ある時間における関節角度を指定するという方法が取られている。
人間などの小脳や大脳の内部で、どのような処理が行われどのような出力がされているかは未だ解明されていないが、とどのつまり正しい関節角度を必要に応じて指定することができれば問題は無いわけである。
そういった意味では必要十分なトルク（関節インピーダンスというべきか？）が出力できる前提で、時系列に沿った関節角度を再生することができればもっとも簡単にもっとも確実に多関節肢を制御することができる。
ただし、これは「答」がわかっている状態でしか言えないことである。つまり、ロボットとは次元の違う超存在、ロボットの創造主となる人間が何らかの方法で導き出した答がすでに用意されている必要がある。これは力学的問題を数式などで解くことによって適切な関節角度やトルクを得ることができるとするZMP基範の制御でも言えることである。
時間軸をある単位に区切り、区切った時間のある瞬間における各関節角度を決定して、これを再生する方法は動画の記録方式やアニメーションの作成手段がそうであるように、表象を記録・再生することのみを目的とすれば必要十分かつ非常に論理的といえる。
翻ってロボットの関節制御について考える。
ロボットは少なくとも未知の環境に対して柔軟に対応できなくてはならない。
これは「未知の環境」というものがある範囲での不確定要素や誤差などで表せるものであれば「ロバスト性」として捉えるべきであろう。簡単なところでは足の接地面積を大きくすることで誤差や外乱に対して安定動作を確保する、といった類である。
であれば、ロボットの制御を考える上での未知の環境とは明らかにロバスト性を高めることでクリアできるものではない。もっと積極的に未知の環境を捉えて、それに応じる状況のことを考えるべきだろう。つまり、未知の環境に対する「学習」である。
ロボットの制御に関して「学習」を避けて通ることは出来ない。必ず、どこかの時点で学習に対する考慮をしなければならない。
以下単語メモ
関節間の相関関係
離散データである。
各関節の角度を含めた足先座標の位置や姿勢を再現するために制御の対象を動作には論理性が伴うと考える。
評価関数と乱数試行により最適解を求めることは不可能ではないとは思うが、関節は物理的な関係を持っており、関節の相関関係は最適解を求める以前に明らか
バリスティックな制御を行うためには
ＣＰＧの機能を実現する
ニューラルネットワーク的な
本大会の本命だったブラジルとイングランドがベスト８で姿を消した。どちらも調子を上げられないでいたので予想された結果かもしれないがちょっとさびしい。
ま、ワールドカップはさておき、関節角度をトリガーにして連鎖型モーションを形成しようとしているのだが、左右の足の動きのような反転同期がうまくいかない。
トリガーとするパラメータを角度だけ（それも単一関節の）で考えるのは限界があるのかもしれない。複数関節の角度のAND条件なども考えてみよう。
単純な動作ルールで同期を取るということが難しいことが判った。ここでも発想の転換が必要だ。