トレッドなしのスリック■３月１６日■
関東組練習会に行ってきました。
ロボワン直前ということもあって、今回は参加者が少なかったようです。 今回のロボワンはスロープだのロンダートだのがあって、その調整が出来るロボスポなんかに集まってるんだろうなー、、ということでした。Kさんのブログを見る限りその通りだったようですね。
ラムダは外装をつけて（裸エプロンだけど(^_^;) ）初めての外出。 皆さんの評価は、、さておき、(^_^;) 一応は人目にさらせるようになったつもりです。
残りの外装とマニピュレータ部はぼちぼち進めるとして、動作プログラムの方に戻っていきましょう。
今日はラムダを初めて（多分初めて）リングの上で歩かせました。家のカーペットと違ってグリップしないのでなかなか進まない。 もうちょっとグリップさせたいな。スリップすると倒立振子にならないから色々ダメなはず。
あと、膝のサーボがすぐへなへなになって、仰向けからの立ち上がりモーションが出来なくなります。 これは膝の放熱対策も必要だけど、立ち上がり方を工夫する必要もあるなぁ。
練習会後は食事をしながらホビーロボット界の今後について熱い議論を交わしました。 ライトなユーザーがもっと楽しめる場を作らなければならない。 学校や幼稚園でイベントを開催するのはどうだろう。。 などなど。。 正直、ライトなユーザーのことを気にかける余裕はオレには無いなぁと、自分の作りたいロボットが自分の脳みそが元気なうちにできるのかどうか、そっちの方がが心配で心配で。(^_^;) 石川さんはホントにすごい人だと思いました。 でも、こんなオレにもきっと協力できるところはあるかと思います。
明日は朝から大阪へ出張。 帰りの新幹線は酔っ払って寝てるかと思うのだが、行きの新幹線は、、、 酔っ払ってはいないけどやっぱり寝てるかなぁ。 一応ロボット検討を進める用意はして行こう。
■３月１７日■
今日は朝から新幹線で大阪へ。 予想通り家に帰ったのは深夜になってしまった。
ここ1ヶ月は外装作りにどっぷりだったのだけど、外装が8割方終わったのでここらでアクションアイテムを整理しておこうと思います。
1.背面側外装の製作
8割方終わったと言っても後ろ側に回られると素っ裸なので背面側の外装も早々に完了させてしまいたいと思ってます。実は前側のカバーと後ろ側のカバーの接合方法が確立していないのでそのあたりの問題が積み残しになってます。
現状では足部と上腕は前後のカバーを作っているのですが、テープで貼り合わせている状態です。これを最終的な組み立て方法とすべきかどうかも含めて検討が必要です。
同色のテープで接合部をカバーすると綺麗に組み立つのですが、カバーをはずすたびにテープを消耗するってのはいかがなものかと。。
2.仰向けからの立ち上がりモーションの改善
膝サーボがすぐに熱ダレを起こすので、仰向けからの立ち上がりができなくなります。
熱ダレ自体の対策が必要なのはもちろんなのだが、膝に頼らない動作を模索する必要もあります。
うつ伏せからの立ち上がりでは股関節を使うことで膝に頼らない動作となっているので、仰向けから上体を起こして体育座りになり、そこから下向きの（お腹を下にする）四つんばいに移行するべきかな、と考えています。モーション生成の観点からは単純化のためにひねり姿勢を入れないで立ち上がりたいというのが条件です。
3.速度ベースの姿勢移行での台形加速のインプリ
リーチング動作などのための上半身と下半身の連動動作で、速度ベースでの姿勢移行を組み込んだが、わずかな姿勢移行を行う際も指定速度でドンと動いてドンと止まる、ということが起こります。これは不安定さを呼び起こしてしまうので、台形加減速を導入する必要があります。
ずっとやりたかったのだけど、外装優先にしてたので積み残し状態です。 さっさとやっつけちゃいたい。
4.足裏のグリップ改善
昨日の練習会でリングで動かした時のスリップの対策です。
家で動かす範囲では問題ないのですが、外で動かす場合は基本リング上でしょう。自律でロボビリヤードをやることを考えてもスリップ対策が必要です。
足裏のゴムシートを交換するだけでグリップするようになるかな？
5.無線コントローラの接続
7月のわんだほーには出てみたいな、と思ってます。そのためにはPS2コントローラと直接通信できるようにしておく必要を感じてます。
コントローラとインターフェースで1万5千円くらいするらしい。ちょっと高いんだけど、これでまた1ヶ月取られるってのもいやだからなぁ、、、PIC使って簡単にできないかなぁ。。
歩行の改善とか自律のためのいろいろとか根本的なテーマはもちろんあるのだが、一旦は「電源を入れて動き出す」、という基本的な部分を形にして、その後各要素の機能拡大、精度向上を行おうと思います。
■３月１８日■
練習会でのラムダの様子が散財さんとこで紹介されてました。 散財さん、ありがとうございます。 外装がつくとロボットらしくなるなぁ、よかったー。
さっそく昨日あげたアクションアイテムを潰していこうと、仕事の帰りにハンズに行って滑り止め素材を探してきました。
靴の裏のようなトレッドパターンができないかなーとか考えていましたが、滑り止め具合を比べてみてエラストマシートに決定。ゴムシートより粘り気があるし、軽い。
トレッドなしのスリック
土踏まずがあるのは愛嬌じゃなくて、小さな段差などにかかってしまった場合でも、つま先とかかとで接地するように。 どれほど効果があるのかわかりませんが。。 つま先はつまづき防止のため、フッ素テープを接地面に少しかかる程度貼ってます。 このエラストマシート、粘着材をまったく受け付けない。 粘着テープも剥がれてしまうのでテープを足部の表側まで巻き込ませてなんとか固定しています。
我が家にはラムダを歩かせるほどのメラミン樹脂のデコラボードはないのでどれほど効果があるのか確かめることができません。 てか、これ、カーペットの上で1ヶ月も動かしたらホコリを吸着して粘り気がなくなるような気がする。拭けば取れるかな。
ということで、一応アクションアイテム４完了。(^。^) ろぼとまで歩かせるのが楽しみです。
ラムダ、というかうちのRPU-100にはGtalk(google talkじゃない）を搭載していてテキスト文を発声させることができるのですが、練習会で少し発声させる機会がありました。
声はGtalkと一緒に配布されている男性の声です。 これが結構野太い声でかわいくない。 イガアさんに「ラムダなら少年の声でしょ。」と言われたのですが、もっともです。自分でも少年の音素データが欲しいなぁと思っていたのだが、無いものは仕方ない。ロボットだし、無感情な男性の声ってのもアリだなと妙な納得をしておりました。
これをきっかけに、きっと音素データの生成方法が提供されているはずだなぁと思って探してみたらすぐ見つかりました。
ところが、これがなかなか敷居が高い。 500～1000文章の音源データを音節に区切ったデータと、読み上げた文章の音韻データが必要で、これをHMMデータベースに学習させて作るらしい。（相当適当な説明なので鵜呑みにしないように） ちなみに配布されている男性と女性の音素データは1000文章から作ったデータだそうです。
単に読み上げただけじゃなく、文章が持つイントネーションを正しく発声しなければならないという条件までついてます。（または音韻データのイントネーションを発声文にあわせても良いが）
ううぅむ。ラムダの声のイメージの（きっと）女性に最低でも500文章を側音が無い状態で録音してもらう、、なんてできないなぁ。 ボーカロイドの音素データもそんなふうに作ってるんでしょうね。声優さんじゃなきゃできない仕事だなぁ。 知り合いに歌手なら二人ほどいるんだけど声優はいない。 一度頼んでみようかな。
とりあえず、ラムダは2歳だけど野太い男性の声ってことで(^^ゞ
＃ちなみに2歳ってのは設定とかじゃなくて、2歳の人間の知能と運動を目指しているということです。
■３月２０日■
昨日はたらふく飲んで帰ったので、今朝はゆっくり朝寝。 昨日は事務所移動があったせいか、腰が痛い(>_<)。
足裏の素材を変更したのに、まだ歩かせてみていなかった。 今日歩かせてみたら旋回歩行が不安定？スリップさせてるわけじゃないんだけどなぁ？ グリップ力が上がったら、もしかしたらJ1Z処理での動作がうまく行かないかもしれない。。と心配してみたが、大丈夫みたい。 足裏変更の影響はもう少し様子を見てみよう。
今日は背中の外装を手がけたかったのだが、気になって仕方が無い仰向けからの起き上がりモーションの改良をまずやっつけることに。
腰を足部の上に乗っけることができたら、上体を起こしてしゃがみ姿勢になる。 次にそのままぐいぃぃっと立ち上がるのではなくて、上体は前に伏せるようになりながら腰は持ち上げていく。 腰が十分に持ち上がった後に上体を起こす。 というふうに作ってみた。 膝に負担がかからなくて、熱ダレした膝にも優しいモーションである。(^。^)
モーションを作っていると、プログラム上のいろんな不具合が発覚して、デバッグしながらの作業になってしまった。 モーションを作るだけだったのにあれやこれやで1日終わってしまった。まだ手を加えたいところが沢山あるのだが、これまた一応アクションアイテム２が完了。
ラムダの声について、自分の声をボイスチェンジャーで変えてみては？と人形つかいさんからの助言をもらって、早速ツール「Morph VOX」をダウンロードしてみた。 フリーのツールは声のいじりかたを編集するってことは出来ないみたい。 Proの方は有料だからまだ試してません。 とりあえず、男性の声を女性にすることはできる。相当それっぽい。 でも、少年の声、、ってかラムダの声ってどんなんがいいのか？イメージ無いなぁ(^_^;) おっさんの声で慣れちゃってるからあれがラムダの声って感じだ。。。 あと、声をいじった音声データを音声認識ソフトで音素分解できるかどうかが問題。 あ、あとツール一式をダウンロードできるかどうかも確認できてない。HTKのユーザー登録したのにパスワード送ってこないなぁ～、何か間違えたかな？？？
■３月２２日■
今日はロボワンの予選。 観に行くつもりだったのだけど、迷って迷って、予選はパス。 アクションアイテム①をやってました。
一日やったのだけど、バキュームまででやっと。 時間かかるなぁ～(>_<)
背面カバーの仮組み。 背面中央部にはRPU-100のスイッチとかLEDとか排気口とかがあるので加工が必要。
真後ろから見るとちゃんとできてるように見えるのだが、側面がダメです。 このサイズだと深いバキュームはできないので、側面の立ち上がりはプラ板を接着する。 前側カバーとの勘合は考えてないので、隙間ができてみっともない。(ーー;) でも、この辺が限界っていうか、これ以上の精度を出すにはプラ板バキュームじゃちょっとねぇ。
機会があったら、もっと綺麗に作る方法（手順？ 構造？）を考えて見ます。
足の後ろ側カバー各種
足の後ろ側カバーもバキュームしました。妙なふくらみはケーブルダクトになっている。またまた深く考えずに作ったので、どっかで干渉が発生するかも。
まだ仕上げも塗装も残ってるけど、これで外装で残るはお尻とマニピュレータ部。 背中や足はケーブルが汚かったから隠したかったけど、お尻はサーボむき出しでもいいかなぁ。
明日はロボワン決勝。 フラリと観に行きます。 枠が空いてるようなら石川さん主催の打ち上げにも参加したいなー。 いいスよね？いしかわさん。
■３月２３日■
ロボワン決勝、観に行ってきました。 そして打ち上げに行って飲んできました。
観戦しただけなんだけど、楽しかったですよ。 くままさん準優勝おめでとうございます。テコンVに負けはしたけど、やっぱくままさんの操縦は上手い！ でも、、打ち上げでくぱぱさんにダメ出しされてましたけど(^_^;)
開場前に並んでたら石川さんに遭遇。 なんでも昨日の懇親会でのONO-ONE表彰でラムダ研究所も４位で表彰されてたとか！ おーすげー、表彰してくれたんだ。そして打ち上げの席でキノピーに（いや、キノピー声で(^。^) ）表彰していただきました。
これって受賞者ごとに台詞が用意されているんですねー。すごい！うれしい！
打ち上げではSISOさんにお初でお目にかかりまして、投げロボ用の機体を見せてもらいました。変形ロボはSISOさんの真骨頂。完成度高いですねー。 投げロボももうすぐ3度投げて3度立つロボットが出てきそうな雰囲気。 完全に自分の予想を超えてます。 自分の尺度で物を考えちゃダメだと痛感しました。 努力が足りないな、いろいろと。。
その後、JinSatoさんと網野さんとロボットの制御と将来について侃々諤々と話しました。 自律、もっとがんばらねば。 前回のカンファレンスの時にも思ったけど、網野さんはすごいです。 こういうのどうだろうって思ってるアイディアを既に実験して組み込んでしまってること多数。 いつか先を越したいです。 もっとクールにもっとクレバーに。実験は実験要素以外は不純物なので、できるだけ排除して、結果を客観的に分析する。 会話していると、そういった基礎を思い出さされます。
よしっ、明日からまたがんばろう！
■３月２４日■
最近の日誌を読み返してみると、テクニカルカンファレンスで湧き上がったモチベーションはほとんど外装作りで費やした感じ(^^ゞ まぁ外装も大事だからいいんだけど～、、、ホントにホントに外装はもうほぼ終わりだから次に進まねば。
あれこれ食い散らかしている状態なのだが、とりあえずの目標は自律でロボビリヤードをやること。 これは自律行動を行う基礎を構築するってことで、ビリヤードをやらせるためのビヘイビアってのか行動規範ってのか、行動ルールってのか、そういうのは難しいものではない。ちょっとしたスクリプト的なもので十分できるはず。
行動ルールよりも下層の行動の実行とその隙間処理みたいなのが結構大変でめんどくさい。 めんどくさいけどやらなきゃ仕方ないのでしばらくはそこんとこの整備を進めるってことになるんだろうなー。 外装に続いてまたあんまり面白くない作業なのでさっさとやっつけちまいたいところ。 ロボワン後の湧き上がったモチベーションをそんなのに費やしていいのだろうかぁ～。 いや、めんどくさくって面白くない作業だからこそモチベーションが高いうちにやっつけちまうべきなのか？ カンファ後に外装やったのも正解だったか。(^。^)
その下層処理の整備で、割り込み処理の改善も手をつけたいと思っている。 いま、ラムダは25ms周期にサーボの処理とセンサーからのデータ取得を行っているのだが、この処理はシグナルで呼び出している。 シグナル処理は結構CPUを使うみたいで（そこんとこはよく知らない）、 プロセスを分けてループで回した方が処理的にムダがなさそう。サーボの制御だけなら今のままでも問題ないのだが、画像処理や音声認識を同時に処理したいと思っているのでこの辺りの処理の見直しをしたいなぁとずっと思っていたのだ。 下層処理の整備とインターバル処理の見直しでどれくらい時間かかるかなー。 また大体1ヶ月ってところか？
外装が大体できて干渉チェックのために立ち上がりモーションなんかを動かしてみたら、うまく行かないことが多々あって、モーションの見直しをしたりしていた。 どうやら、手先がカーペットの毛並みにひっかかってしまうことが失敗する場合の原因らしい。 家の中で動かすのが前提のラムダでこれはいかんことです。手先を滑らす動作はできるだけやらないように考えてはいるのだが、徹底的にそうしてはいないのでちょっといかんです。 でも、どちらかというと、手先がひっかかって上手くいってないことを感知できるようにしたいところ。書くキーフレーム毎のあるべき腰姿勢角度をモーションに組み込んで、異常値を取ったらリトライするような手段が必要か？
てか、手先が引っかかって立ち上がりを失敗するときって豪快にひっくり返ります。それも頭からゴツーンと。(^_^;) うまく動いてないことをダイナミックにセンスしなきゃならんわけだが難しいなぁ～(>_<)
■３月２６日■
地道なプログラム整備がスタート。
今日は歩行時の歩行姿勢セットの整備。 歩行の基本姿勢を、前進、後退、旋回という区別でパラメータ化して外部ファイルにして保持しているのだが、この歩行用の基本パラメータファイルに上半身の姿勢を追加した。
物を持って歩く、などという時は別にして、今の不安定な歩行の状況を考えると、上半身の姿勢も歩行種別毎に持っておいたほうがよさそうな気配だったので追加した。
上半身姿勢のデータを追加したところ、ヘッダーファイルに不具合が出て、コンパイルが出来ないようになってしまった。 調べると幾つかの宣言で相互に呼び出す形になってしまっていた。 追加追加で書き足して行ったのでもう宣言文がぐちゃぐちゃなのだ。(ーー;)
結局、更にインクルードファイルを分割して、相互呼び出しを回避。一応プログラムが動き出したところでタイムオーバーである。
次は、動作命令のスタックを作る。
これは、「歩こう」としたとき、または「歩け」という命令を受けたとき、でもいい。 歩行の基本姿勢になっていなかった場合、まずは歩行の基本姿勢に移行しなければならない。 この時、「歩く」というコマンドの実行の前に「姿勢を移行する」というコマンドを生成して、実行する。「歩く」コマンドは消滅するのではなくスタックに格納されて、姿勢の移行が完了した後に参照されて歩き出す、というスンポーだ。 今のプログラムの組み立てにこれを組み込むのがちょっと面倒。 もしかしたら大幅改造になるかもしれない。やだなぁ～。 でも、やらなきゃ仕方ない。 明日できるかな。
■３月２７日■
今日は残業で、帰るのがちょいと遅かったのだが命令スタックを作るのはそんなに難しくない、とタカをくくって今日中にコーディングだけでもしちゃおうと思っていた。
ただ、命令スタックを作るのが簡単でも、スタックする命令を生成する部分は簡単じゃない、というか簡単だけどいろんな場合の処理をすべてべったりと書き出さなければならない。 実はこのべったり書き出すというのが大の不得意で、もしかするとモーションを作る根気がないのと関連しているような気がする。
立っている時なら歩行姿勢へ移行してから歩けばいいが、 旋回歩行中なら一度止まって上半身姿勢を切り替えてから、 更には座っている状態ならばまず立ち上がって、そして姿勢を移行してから歩く、という具合に様々な状況のすべてをコーディングすることになる。考えていると無限の組み合わせがありそうな気分になってゲンナリする。
なにか、ルールのようなものがあればいいのだが、、 べったり書き出した方が簡単なのかもしれないなぁ。
明日は飲み会。 なので、続きは土曜日ということになる。土曜日は外装の残り作業が優先なので、外装工作が終わったらこの続きを。
■３月２９日■
請け負ったDVD作成をやりながら、外装の取り付け作業。
外装はとてもとてもタイトに作ってあるし、部分的には肉厚が薄くなっていて組み立てを失敗するとクシャリと行ってしまう。前側と後ろ側をあわせるために端を切りそろえるのだが、切り過ぎてしまうといかんので、慎重に～、とやっていると時間のかかることかかること。大腿部分の後側を取り付けるだけで半日くらいかかりました。 DVD作成しながらだけどね。
夜になったら加工はやめて、プログラム作業に切り替えて～、、と思っていたのだが、大腿ロール部サーボの後ろ側カバーの取り付けをやっていたら深夜になってしまった。
明日中には完成するかな～。
大腿ロールのカバーは未塗装。
大腿カバーができたところで塗装までやってみた。 重ね塗りするつもりで軽く吹いて乾かしてって感じで慎重に塗装したので、今日の塗装は成功。 後ろ側なんだけどね。(^^ゞ
請け負ったDVDも完成。
■３月３０日■
ダラダラとAM11時くらいから外装の続きを再開。 膝関節のケーブルルーティングで致命的なチョンボが発覚してモチベーションが下がりかけたけど、とりあえず干渉部分を切断したりしながらなんとか組みあがった。 色々不具合を抽出してから作り直そう。
うっしゃー、あとは塗装したら完成！ ってことで塗装の準備をしてベランダでたところで雨がぽつりぽつりと。。 orz 。。。 雨の中塗装はできまへん。
↓呆然と雨を見つめるラムダ
背中のカバーをつけたとこ。 胸カバーと背中カバーのつなぎ部分もむりやりカバー。
来週までまたカバーつけれないのもなんなので、塗装してないけど、仮組み立て。
膝下部分のカバー設計がボロボロ。
外装関係はほぼやることがなくなったので、コマンドスタック周りのプログラミングを開始。
ラムダの命令系統は、ネット接続からの命令、 コンソールからの命令、 あとはバッテリー切れとか転倒時などに対する反射動作がある。 これにコマンドスタックによる命令実行が加わる。まだ自律系による命令実行がないのが悲しいところ。
コマンドスタックは主にネット接続からの命令実行の際の動作のつなぎを行うための仕組みになる。将来的には自律系の命令実行の（自律層が上位レイヤーだとして）中間レイヤーとなる。
コンソールからの命令は試験やマニュアル操作系になるので基本的にどのような状態にあっても命令実行する（たとえ実行して不具合が発生しようともマニュアルなので関与しない）
それに対してコマンドスタックはロボットが動いていない状態でしか起動しない。 つまり停止命令はスタックしない。 当たり前だけど(^_^;)
ネットからの命令系はコマンドによって振る舞いが変わる。
ネットからの命令系ではコマンドを調べて現在のロボットの状況によって実行するかしないかを仕分ける。 または、状況によってコマンドスタックを生成し、姿勢などの不具合を解消してから実行するようにする。
そういうわけでネットからの命令系がメインの命令系ということになる。
今のラムダの実行コマンドは文字列でやりとりをしています。 ラムダはネットから文字列を受け取ったらそれを解析して実行します。 コマンドスタックも同じく文字列のリストです。 すべての有効な単語毎に処理を記述しているので、文字列を整数などに変換して格納すればデータ量が小さくなるのですが、新しい単語を組み込むたびに変換テーブルを更新してなんやらかんやらするのは結構めんどくさい。 なので、メモリーの浪費ではあるのだけど、文字列のまま処理しています。まぁ浪費と言ってもたかがしてれるし。
実はクイックモーションのデータは、ファイル上ではテキストファイルだけども、プログラムの読み込まれた時に整数値に置き換えられて格納しています。そのため、コマンドの変換テーブルの管理もせねばならなくてめんどくさい思いをしてます。 こっちも文字列のまま格納するようにしようかな。(^_^;)
遠い将来、自分で動作を生成するようになったら、このような「命令実行」というようなはっきりした記述はなくなるはずです。状態子（と仮に呼ぶ）同士の情報のやりとりである状態が生まれ、それによりもたらされる情報が状態子の入力となる。 そのループで「行動」が生成される、 といった感じになるのかなと考えてます。
早くそんなプログラムを書きたいなぁ。
あっと、、、コマンドスタックは出来て、あとはコマンドスタック生成部分を書き足していけばいい状態にはなりました。 とりあえずは歩行姿勢への移行とかウェイトとかの記述を追加していこう。
■４月１日■
プログラムを始める心のスイッチが入らなかったので、音声合成用音素データ作成の続きを調べていた。
音素データを作るための文章読み上げデータが必要なのだけれど、音素バランスが取れた文章データでなければ「良い音素データ」が作れない。
音素ってのは母音と子音のデータがあればいいわけじゃなくて、音素間のつながりがスムーズになったデータじゃないといい感じの合成音声が出来ない。 隣あった音素同士のつながりを考慮した音素データを「２音素連鎖」、前後のつながりも考慮した音素データを「３音素連鎖」の音素データっていって、２音素の場合は音素数の二乗、３音素の場合は音素数の３乗の組み合わせがある。 ただし、普通にしゃべった場合には発生不可能な組み合わせやほぼ使わない組み合わせもあるので現実にはもうちょっと少ない数の組み合わせになる。
音素バランスがとれた文章データを使うと、この「音素連鎖」のデータが程よく出現してよい音素データが出来上がるというスンポーだ。
ちなみに音声認識も同じ考えの音素データを持っていて（こっちはいろんな声の平均をとったデータ）、３音素連鎖の方が認識率が高い。（が、時間がかかる）
そういった文章読み上げデータがCDROMなんかになって売ってるらしくて、音声合成や音声認識の研究に使われてるらしい。
ラムダの声を自前で調達するとしたら、その音素バランス文が欲しいところ。 これをネットで探したんだけど、売り物なのでダウンロードなんかはできないらしい。 「ATR音素バランス文５０３文」ってのが有名どころみたいで、gtalkに添付してあるデータもこのバランス文から作られているみたいだ。
で、このCDROM、 買うと、367000円。。。。 たけー！ たけぇよ。 ま、研究用だからそんなもんなんかなー。 バランス文だけでも安く売ってないかな。
バランス文があったとしても分析データなんかは作らなきゃならなそうなので、それほど労力が減るわけでもなさそう。 ならば、適当な平文を１００文章くらい集めて作ってみてもいいのかもしれない。 音素データ構築の環境ができたらやってみましょうかねぇ。 そのうち。。。 (^^ゞ それまではおじさん声ってことで。
ルーク（レイトン教授の、ね。）の台詞を集めて堀北真希の声（ってか、ルークの声ね）を作るって案も出たんだけど、それって肖像権の侵害になるよねぇ (^_^;)
あ、２音素連鎖か、３音素連鎖かは別にして、必要な音素が出現する文章を集めなきゃいけないってのを忘れてた。 テキトーな平文じゃだめだ～。
＃女の子なら断然スペチャンのうららの声だなー。 音声データ少なすぎ、そのうえ側音ありだからダメだが。
■４月５日■
仕事とか飲み会とか送別会とかで、ウィークデーはほとんど作業できずに週末に突入。
今日はとうとう最後の外装部品の塗装が完了しました。 塗装は随分と上手になって、今となっては前半に塗装した部品は見るのもイヤになる出来なので作り直したい気分。（作り直さないけど）
カバーの固定はネジ止めできるところとできないところがあるのでしばらくはテープ固定で様子見。基本的にはカッティングシートを固定に使っているのだけど、セロハンテープで貼ってるだけでも十分な取り付けが出来てる。すごいな。
マニピュレータが完成するまではこの状態で打ち止め。 あ、気が向いたらお尻の外装を作るかもしれないけど。 一応の完成となった時点で既にあちこちの塗装が剥がれかかってる。でも、最後の外装部品を塗装したところでスプレーがカラになってしまったので補修もできない。(>_<) ちなみにパンツ部分と背中部分はひっかけているだけで固定していない。なんだかうまくひっかかって取り付いてる。 背中についてはネジ固定する手段も用意しているので必要に応じてネジ固定にするつもり。
結局、カラーリングはなし。 もともとモノトーンが好きだし、ラムダの位置づけ的にもカラフルなカラーリングは有り得ないのでこれでいいかなと。
コマンドスタックは動作の一部分についてだけスタック生成の記述をしてみて、正常に動くことを確認した。
あるコマンドを実行する際にチェックすべき状態変数は、①下半身の動作状態 ②上半身の動作状態 ③モーションの実行状態 ④姿勢 とある。 その上、それぞれの変数のとる値によっても対応が変わってくるケースがあるので、全てのコマンドに対して記述を行うと膨大な量になってしまう。
なので、やはりビヘイビヤではないが、動作ルールのような記述を用意してコマンドを実行する際にはその動作ルールリストに従ってコマンドスタックを生成するという仕組みにすべきかと考えている。
例えば、「前進歩行」のコマンドを実行するためには ①立っている ②止まっている ③歩行姿勢である または ④前進歩行をしている という条件がある。 ①～③はAND条件で、④はOR条件。 ①AND②AND③OR④ という関係かな。
寝転がっている状態で「前進歩行」のコマンドがくると①に反するので、それを解消するために立ち上がりを実行するコマンドを発行する。 立ち上がった後に歩き出すために「前進歩行」コマンドはコマンドスタックに収めておく。
立ち上がりモーションが完了すると、コマンドスタックから「前進歩行」コマンドが取り出されて、再び実行条件を満たしているかどうかを調べる。 今度は①も②も成り立っているので、③が成り立っているかどうかを調べる。
で、成っていたらいいのだが、成り立っていない場合は姿勢移行のコマンドを発行し、「前進歩行」コマンドはコマンドスタックに再び収められる。
で、姿勢移行が終わったら、今度こそ条件成立で「前進歩行」が実行される。
あと、「止まっている」といっても、動作を終了してすぐだとまだ勢いが残っていて、そのまま動作を開始するとウマク無い場合が考えられるので「止まっている」が成立する条件についても考慮する必要があるだろう。
明日はこの仕組みを作って動かしたいなぁ。 うまくするとクイックモーションの実行ルーチンとマージできるかもしれない。 だったらどうなんだって話ではあるが(^_^;)
ところで、足裏の材料を変えたことでグリップの効果はあるみたい。 足裏を変えてからすぐに転ぶようになった。(^_^;) いままではカーペットの上ではスリップしていないように見えていたのだけど、実は微妙にスリップしてたんだなーと、思ってる。 真偽のほどはわかりませんが。。。 歩行安定化の対策を加えないといけないようです。
■４月６日■
朝からプログラム、時々工作。
外装は昨日で打ち止めって言ったけど、両面テープで仮どめしている後頭部カバーがすぐにペリっと剥がれて気になるので、固定用のネジ穴を開けたりしていた。ついでに足のカバー固定用のネジ穴も開けたりして、結構な作業になった。 なんせ、足のカバーはすべて取り外し、板金部品を取り外さなきゃならなかったので足もほぼ分解状態。
プログラムの合間にちょっこりやるつもりが夕飯後までかかってしまった。 でも、まぁとりあえず、固定できる部分はネジ固定できたので気分的にはすっきりした。
動作ルールのインプリについては、やっぱり外部ファイルにルールを記述してそれに従って、判断するようにした。プログラムに直接インプリするとコンパイラが無い環境だと修正できないってのはやはり不安。 あと、データ構造にしておけばダイナミックに修正することも可能だし。
どの程度の記述内容が必要か考えたのだが、結構複雑になってしまった。
基本的には「実行したコマンド」 「状況を示す変数など」 「代替動作」 という記述。 これを複数記述することで複雑な条件を表現する。
状況を示す変数ってのはグローバルな変数はすべて利用できるのだが、そこんとこはプログラムが必要なので、考えていなかった変数をコンパイル無しで出現させることはできない。
変数同士の演算も必要で、 イコール（＝） ノットイコール（！＝） 大なり（＞） 小なり（＜） くらいは用意した。 複数の条件大してはANDとORを表現できる。 ORは複数行書けばいいから必要なかったかも。
ルールの記述はこんな感じ。 記載の無い状況ならコマンドはそのまま実行する。
WALK lb_walk&fb_now!fb_cmd'WALKOFF ← 今、既に歩いていて、進行方向が逆なら止まる。
WALK lb_turn'WALKOFF ← 今、ターンしているなら止まる。
WALK qm_on'CLEAR ← いま、モーション再生中ならコマンドは無効。
WALK poschk,walk'POSSET,walk,fb_cmd ← 歩行姿勢じゃなければ、歩行姿勢になる。
TURN lb_turn&rl_now=rl_cmd'WALKOFF
TURN lb_walk'WALKOFF
TURN qm_on'CLEAR
TURN poschk,walk'POSSET,turn,rl_cmd
立ってなかったら立ち上がるってのが無いなぁ。
構文解析部分がすんなり動いたので、休憩して工作していたら夜になってしまった。 poschk からPOSSETのくだりをどうやってインプリするか悩み中で今日中にはコーディングできず。最近忙しくってウィークデーはコーディングできなさそうなので完成まではもう少しかかるんだろうなー。
■４月７日■
予想通りに残業で帰るのが遅くなったのだが、プログラムを進める時間は取れた。 動作ルール解析実行部分のコーディングがあと少しで完了。 いや、違った。動作ルール部分はコーディング終了。 あとは動作ルールの実行用にコマンドを追加しなければならないものがいくつかあるだけ。
ルールの記述が少し変わった。 完成までにはまだ少し変わりそうだ。
WALK lb_walk&fb_now!fb_cmd'WALKOFF
WALK lb_turn'WALKOFF
WALK qm_on'CLEAR
WALK poschk,data[0],data[2]'POSSET,1000,data[0],data[2]
TURN lb_turn&rl_now=rl_cmd'WALKOFF
TURN lb_walk'WALKOFF
TURN qm_on'CLEAR
TURN poschk,data[0]'POSSET,1000,data[0],data[2]
送られてきたコマンド列から必要なデータを展開流用できるようにした。
続きは明日。
■４月８日■
今日も残業で遅く帰宅。 最近忙しいのだが、まだ疲れてヘトヘトというところまでは行ってない。 どちらかというと脳が活性化していて、遅く帰ってもプログラミングに取り掛かれるモチベーションが出る。 いい高揚感。 と、呑気なことを言っていられるのも今のうちかもしれないけど。。(ーー;)
動作確認をするために最低限必要なプログラム記述は完了した。 さて、動作確認とデバッグなのだが、デバッグしだしてはまってしまうと眠れなくなってしまうので注意深く動作確認を行っていくことにする。
兎小屋からのリンクで自律バトル競技会の存在を知る。 ほー、すごいなー。 ラムダにできるかな？ ラムダの物体認識は主に色のカタマリで認識するからできそうにも思うけど、どんなものか？ それにしても、自律させてもやっぱりバトルなんですねー。(^_^;) ラジコンロボットとして考えるとバトルやサッカーで新しいラジコンの世界が広がったと考えることができるけど、ロボットとして自律させてもやはり闘争の世界に放り込んじゃうんですねー。 そういや相撲ロボットもかわロボもバトルか。。。 相手を見つけて攻撃するだけって考えると単純な動作だから実現しやすいのか？動く相手を捕捉して攻撃するのってそんなに簡単とも思えないが。 エンタメ的にはわかりやすくって盛り上がるっていえばその通りだと思うが。 やはり人間は戦闘民族ってことなのかな。
明日から動作確認とデバッグに着手。 論理演算部とか構文解析（ってほどじゃないが）があるので、動作確認は慎重に進めましょう。
■４月９日■
ちょっと早く帰れたので、張り切ってデバッグを開始。 基本的な部分は動きだしました。 あとはルールファイルを充実させていけば良いってことです。 ま、上半身の比較関数がうまく動かないとか、まだまだ挙動不審な点が多々ありますので完成したわけじゃーありません。
これでちょっとだけ自律に近づきました。 ただ、、 最近のラムダはめっきり転びやすくなって、自律動作させても転んでばかりになりそうです。 メカ的なオーバーホールが必要なのか、歩行安定化のための仕組みが必要なのか、恐らくは両方なのだろうけど、もうすこし安定しなければ自律動作どころじゃないです。
転倒受身から立ち上がりモーション起動、 バッテリー監視とバッテリー切れの場合のモーション起動あたりが出来たら画像認識に移ろうというつもりだったのだけど、歩行安定化が先なのかなぁ。 そこそこ歩ければ画像認識との連携を行って、ロボビリヤードを実行できるようにしたいところです。
■４月１２日■
なかなかうまく行かないもんです。
動作ルールについては少しずつバグが取れては行っているのだが、細かなところがなかなかうまくいかない。
転倒状態で歩行コマンドを送ると、姿勢に従って立ち上がりモーションを起動してから歩き出すのだが、姿勢の判定がダメ。 姿勢の判定については随分と前にコーディングしたのだが、プログラム読んでもイマイチわからん。 うまく行ってないから何か間違えているんだろうな。 ここんとこはちょっと真剣に見直さないといけないみたいだ。
あと、歩行がダメ。 もうなんかこけ過ぎ。 グリップするようにしたら全然ダメになりました。 今までグリップさせていて、そこそこ歩いていると思っていたから結構しょんぼりです。 とりあえず先に進むには、足裏を元に戻すなり、改良してグリップし過ぎないようにすればよさそうなのだが、 「そりゃーちょっと違うだろー。」と思う自分がいて手が止まってしまっている。 転倒受身を有効にして、こけても立ち上がって歩くようにすればいいのだが、あんまりにも安定していないのに、それもなんだかなぁ～。。
歩行安定化のための策は幾つかあって、試してみたい方式もあるのだが、それはそれでじっくり取り組みたい気持ち。 早く画像認識と連動させて歩かせたい気持ちと歩行安定化に取り組みたい気持ちがあって、もやもやして挙句の果てにテンションが落ちちゃってる。 いかんなぁー。
■４月１３日■
昨日はモチベーション下がり目だったけど、「今日はもうやめだ～。続きは明日だっ。」と決めて片付けた途端に明日アレやろうコレやろうとなんだか「やらなきゃ」って義務感にも似た感情が出てきた。(^_^;) でもさすがに深夜２時から作業を再開するわけにも行かず、「やることリスト」を書いて就寝。 やることリスト（TODOリストね）書くとそれだけで安心しちゃうんだよね。 仕事で切羽詰って眠れなくなるとやることリスト書いたりしてたな、昔は。
なんだかモチベーションを取り戻したので今朝は早起き。 平日より早起きだったりする。 平日より睡眠時間少ないかもなぁ。
昨日、直し損ねたバグを修正して、続いて姿勢値の判定ルーチンの見直し。 ちょこちょこ直して大体は使えるようになったのだけど、おかしい動きをする場合がある。 ん～、「仰向け」で寝ている時、足の裏が真上を向いてると「うつ伏せ」判定になってしまうんだな。 接地点判定の手段が甘いってのがわかった。 ←ぱぱっと直らないから放置。
これを「うつ伏せ」と判定してしまう。
加速度センサーで判断すりゃいいじゃーん、って言わないでくださいね。物を拾う姿勢なんかだと胴体は水平よりも下を向いた状態になってる。それでも立ってるんだから加速度センサーの値だけじゃ判断できないんです。
次に転倒受身モーションの見直し。 コレも前にやってたのの続きなのだが、前側に転倒した時の受身が満足できてない。成功率低くて、失敗すると顔面から激突するので実用にならない。 転倒受身をする目的は顔面が壊れないようにするため。 なので、腕を前に出して、顔が地面に激突しないようにしなければならない。 最初は膝を落とし転倒する力を吸収して時間を稼ぎ、そのうちに腕を前に出すという方法だったのだが、これだと、腕が前に出ても、勢いは吸収できず、首がむちうち症になってしまう。 ならばと、いっそのこと首は下に垂れさせて勢いをいなし、腕は伸ばして体を支える。 これだと首は折れないのだけど、手を出すのが間に合わない。失敗すると顔面で受身なので最悪である。 どうしたものかと思っていたのだが、良く考えると勢いを吸収するのに膝を落としていてはいかんのだ。 足を伸ばして重心を上にしなければならない。回転半径が大きくなると速度は遅くなる。足を伸ばすだけじゃ足りないのでつま先立ちになって勢いを殺して、そのうちに腕を伸ばす。 これはなかなか成功。 実際に歩かせてこけても、ちゃんと腕が出ます。まー100%とは言えないけど、まえのよりはマシってとこかなー。
つま先立ちで時間を稼いだあと、膝を着いて脱力。顔面激突を阻止したラムダ
転倒している状態で歩行コマンドを送ると立ち上がって歩き出すはずなんだけど、立ち上がった途端に卒倒してまた立ち上がりモーションを始めちゃう。 これは立ち上がった時点で姿勢値を見て、（立っているのに）転倒姿勢だと判断してしまって立ち上がりモーションを起動してしまうケース。 加速度センサーのノイズの問題なのか、姿勢値の計算の問題なのかまだ究明していないけど、このケースだと転倒受身が効かないのでよろしくないのだ。 これをなんとかしないと使えないなぁ。 （あれ？なんで転倒受身が起動しないんだろ？？ 良く考えるとおかしいな？）
これはウェイトを入れてセンサーを見るようにすればある程度は安定すると思うのだけど、それだとなんだか面白くない。もうちょっとダイナミックな方法で打開したいのだが、いまんとこアイディアが形になってない。 加速度センサーを使ってうまく監視すれば歩行の安定化とか、モーション再生時の動作の正常性の監視とか、ロボットにいわゆる身体感覚を与えられる方法がありそうな気がしている。
歩行の方は随分とマシになりました。 ネジを締めなおして、歩行パラメータをちょっといじったりして。 リングだとどうかなー。来週歩かせて確認してみよう。
そうしてこうして、歩かせたりこかせたり立ち上がらせたりしてると、塗装は剥げるは、カバーは割れるはで、結構ボロくなってしまいました。でも、しばらくはこのままだな。修理できるところは修理して、次作る時には改良して干渉を減らしましょう。
色々と安定していないのでストラップをつけて動かしてます。で、こけそうになったらストラップでぐいっとひっぱったり。 いすに座って床を歩かせてるんだけど、あっちに行ったロボットをストラップでひきずってきたり。 そんなことしてたらとうとうハンドルを固定しているネジのタップが飛んでしまいました。 あらら。。 一番ベースの部品なのにな。ナットだとちょっと都合が悪い位置なので、ナットプレート固定するように改造しなきゃならない。ふぅ。
■４月１５日■
姿勢判定の改良。 加速度センサーで判る胴体の角度と関節角度を使ってどんな姿勢になっているのかを計算します。 で、胴体のチェックポイントがどの位置にあるのかで転倒しているのかどうかを判定します。
今までは足が床に触れている前提で計算していたのですが、足が浮いている場合もあるのでそのケースも含めて判定できるようにしました。 ついでに、今までは前後と上下の２次元の座標で計算していたのを３次元の座標で計算するようにしました。横転してても判定できるようになりました。
見えない部分も含めて１６ポイント
接地点になりそうな１６ポイントについて姿勢角度から座標を求めます。
これで「仰向け」を「うつ伏せ」と判定するケースは激減しました。 ・・・まだたまーに間違える。 止まっている状態じゃ間違えないのだけど、動いてるとダメっぽいですね。 使っているセンサーが加速度センサーなので、動作時は重力以外の加速度も感知してしまいます。そのデータで姿勢角度を判定すると失敗するんじゃないかと思ってるんですが、動いている状態でのできごとなのでなかなか尻尾をつかめません。 あ、仰向けとうつ伏せを間違えてるわけじゃなくて、多分、転倒状態（前）と転倒状態（後）を間違えるんだと思います。 転倒状態というのは立っているんだけど、重心が支持多角形に入っていなくて立っていられない姿勢です。 手を着いていることを判定すれば静的に安定しているのかどうかを判定できるはずだけど、そこまではまだやってません。
あと、立ち上がった後の姿勢判定で、立っているのに転倒状態と誤判定するケースで、加速度センサーがふらついているのかと思ったのだけど、どうやらそれは違うらしい。 転倒判定の判定基準が厳しくて計算上、1ミリでも支持多角形から出ていれば転倒姿勢と判定してしまう。 加速度センサーから得たデータでの姿勢なのでそんなに精度ないからちょっと厳しすぎるようです。 ここは判定をちょっと甘くしておきました。
その他、直進からカーブ歩行への切り替え時には姿勢判定をやらないとかそういう微調整をしてそこそこ動かせるようになりました。
散々安定化電源でデバッグ動作させた後にバッテリーで動かしてみたら、旋回歩行が全然できない。 多分、膝が熱ダレ起こしてるせいだと思うんだけど、熱ダレで姿勢が乱れているのをフィードバックできるようにしなきゃならんですね。
ちょっと冷ましてから動かしてみたら、旋回歩行はちょっとマシになりました。 だけど、前方転倒受身がまだダメ。 ダメってのはモーションじゃなくて転倒判定がダメ。 モーションの発動が遅くて間に合わない。モロに顔面で受身ですよ。 久しぶりに首のネジヒューズが飛んじゃいました。(ーー;) サーボをメタルギアにしてからはギアが飛ばなくなったので、プラネジを２本から４本に増やしていたのでなかなか首折れにならなかったけど、さすがに度重なる顔面受身は耐えられなかったらしい。
転倒判定ももっとダイナミックな手段をとらなきゃねー。 まじめに考えよう。
そんなこんなでまだ満足する運動性能となったわけじゃないのだけど、そろそろ上位レイヤーの実装を検討しようかなーと思ってます。
■４月１７日■
昨日は幕張まで出張。 帰りに少しだけ秋葉原によってついでの買い物をいくつか。 水曜日だし、もう７時過ぎてたし、目当ての店の幾つかは閉まっていたのだが最低限の買い物はできた。
その後、川崎まで帰り着いたところで飲みの誘い。 そっから代々木に出てって飲んでました。 なんだか一日中電車に乗ってた気分。
買って帰った部品でRPU-100をACアダプターで動かせるようにしました。 ところが、バッテリーコネクタがまたもや不良品。 (ーー;) 今回はハウジングを削っていって原因究明してみました。
すると、コンタクトの上にハウジングからのバリが乗っかっていて、それがコンタクトの接触を阻害していたらしい。 バリをカッターでこそいだら、ちゃんとつながるようになりました。 ただし、ハウジングをけずってしまったので、変な方向に力を加えると電源が落ちちゃいますが。(^_^;) 安心してつかえねーな。
更にはACアダプターは４Ａモノなので、サーボを動かしたら電圧が垂下してリセットがかかります。 まぁこれは予想どおり。 サーボを動かすときはリポをつなげばいいわけで、設定やらなんやらをやるときはACアダプターで動かせばバッテリーをムダに消耗しなくてすむ。 本当は電源の２系統化を組み込めば設定時はACアダプターで行い、動かすときにバッテリーに即時に切り替える。なんてことが出来るのだが。で、これがあれば練習会には安定化電源もって行かないで済むかなーと思ったのだが、甘いか。 こっちにつないでるうちはバッテリーの充電も出来ないし、ちょっと寸足らずな感じだな。 まぁ万が一使うこともあるかもしれないからおいとくか。
■４月１８日■
今日は嵐の中、山梨へ出張。 特急かいじが1時間も遅れていて指定席を取ってたのに無駄になってしまった。 立川から特急かいじに乗ろうとしたらちょうど１時間前のカイジが来て出張先へは時間通りに行けたんだけど、他の人たちが集まらず会議は時間変更。 帰りの時間になってもまだちょっと遅れてました。 相変らず南武線も中央線も天候に弱いなぁとか思っていたら本当に大変な嵐だったらしく各地での災害は相当なものだったみたいです。 チョイ遅れくらいで済んでよかったー。
今日はドラマ見たり、新刊マンガ読んだりしてすごしたのでラム研は休業状態。 転倒判定がイマイチなのをどうするかってのと歩行安定化のための仕組みをどうにかしたいなと思案中。 転倒の兆しを見極めるという考え方より、歩行を続けられるかどうかを判定した方がいいんじゃないかと思い始めてる。 歩行自体も、同じタイミングで同じ歩調で歩き続けるのではなく、現状をフィードバックするように次の一歩を出すようにしたい。 で、次の一歩が出せない状態ってのは転倒と判断してよいのでは？ という感じ。
実装のアイディアはいくつかあるので早速基礎データを取ってみようかと思っていたけど、今日は休業状態だったので、具体的な進捗は無し。 あした練習会でそういう込み入った作業ができるもんかなー。
ロボワンHPでお手伝いロボットプロジェクトの正式発表があったことをのむむさんとこで知る。 見てはみたけど、ちょっと違うかなー。ロボカップホームの方が共感できる部分が多い。あっちは２足歩行じゃなくてもいいんだけど、新聞とかジュースをとってくるとか、付いて来るとか、指示に従うとかなんか「生活」を感じさせるお題なので共感できる。やっぱエンタメ部分なのかなぁ～。
明日の練習会。 ろぼとまは判りにくい場所らしくって無事行き着くかどうか心配。 方向音痴にだけは自信があるので。。(^^ゞ
■４月２０日■
昨日は関東組練習会に行ってきました。 ろぼとまにはでかいリングが常設してあって、いつでもバトルが開始できるようになってるんですが、ラムダ君（2歳）にはまだ早い。 隅っこにおいてあるスロープやらステップやらのエリアで動かしたりしてました。
足裏のグリップはリング素材でも十分。 うまく歩けなくなるほどの威力です。エラストマ、えらい。 グリップが十分だと歩行のいい加減さが露呈する。 特に旋回動作が不安定になりました。 こないだまでは直進より安定してたのに。(ーー;)
今回はいつもにもまして見学者の風情で参加しておりました。 リングを目の前にした特等席に陣取ってみんなの練習の様子を眺めつつ、歩行のログを取ったりしていました。
あ、でも一つだけ前進したことがありました。密かな野望なのでここでは書けないのだけど、1歩前進です。(^。^) 野望達成のためがんばるぞー。
今日は昨日のログから歩行の安定化についての考察をしようと思いまして、考え込んだり実験してみたり。
↓これが練習会で取った歩行ログ。
1歩を0.3秒で歩かせているのですが、ブルーの波形が胴体を左右に揺らしている様子。 それに対してピンクがY軸ｼﾞｬｲﾛの値です。積分しているので回転角度になってます。 随分と位相がずれているのが判ると思いますが、調べたところ同期してないわけじゃなく、位相ズレがおきてるらしい。
そして問題は黄色のライン。これはZ軸ｼﾞｬｲﾛの積分値なのですが、胴体が随分とロールしてしまっているのがわかります。 そしてX軸回転とY軸回転が同位相。 これが問題ぽいですね。
じゃ、このロールを消すことを考えよう。 そのまえにサーボはちゃんと追随しているのかを確認。
ふむ。。。 ずれてはいるけど致命的にずれているわけじゃない。大体2コマ遅れているので50msというところ。 正確には25ms以上50ms未満というところでしょうか。 急峻な変化に対してもほぼついてきているように見えるのでサーボの反応が遅れているために位相差が出ているわけじゃなさそうです。
ちなみにJ1～J6が指示値でA2～A6てのが実際角度です。J1やらJ3やらは変化がないので実際角度のデータは無し。
で、ここから先は色々と実験したりしてロールを消すことはできないか試してみたのですが、結果としてはいまのところ消せてません。
ロールの原因はどうやら重心点に対して力を与える時に芯を外してしまっているのが原因のようです。スイートスポットはずして打っちゃったって感じ。 具体的には、歩くために重心点を斜め前に押し出すのだけど、足の位置の関係からちょっとずれた位置から押すことになり、重心点にモーメントが発生してしまうようです。
これが、できるだけスイートスポットを押すようにした歩行。左右動作の位相ズレは周期を0.4秒にすればなくなります。 黄色のZ軸ｼﾞｬｲﾛ値がピンクに同期せずにふらふらしているのがわかると思います。 でも、歩幅はたったの15ミリ。これじゃよちよちにも程がある。 ちなみに20ミリにしたらロールが発生しました。
対策としては、発生してしまうモーメントを打ち消すモーメントを発生させるというのが有力だろう。他にはZ軸まわりの慣性モーメントをできるだけ大きくして、回転しにくくするって手もあるかな。
左右動作の位相遅れについては周期を0.4秒にすれば基本的には解決。でも、できれば周期0.3秒でも位相遅れを起こさないように制御したい。 機械的な剛性を上げるというのが正しいのかもしれないが、そりゃ難しいかなー。 ラムダサイズになったら剛性でなんとかなるものじゃない気もするし。
一番簡単なのは足裏をスリップタイプにすること。同期ずれもロールも緩和すると思われます。 でも、、、 昔のえらい人が「滑ったらもうどうしようもありません。（制御できません）」と言ってました。 すべり量がセンスできないのです。
＃でも、チョロメテの足裏はつるつるりんだったな。。(^_^;)
そうだ。ここで知ったメカナムホイール。 これ欲しい。 オムニホイールじゃダメなんです。 売ってないかなぁ。1個1万円くらいなら買うんだけど。作らなきゃだめ？難しそうだな。
■４月２３日■
昨日、一昨日と飲み会続き。 実は明日も明後日も飲み会なのでウィークデーで家で夕飯を食べるのは今日だけ(^_^;)
家に帰ると注文していたG-ROBOTS用のコントローラと受信機が届いてました。合わせて12000円也。 ラムダにリモコンつけることを考えてはいたんだけど、ロジクールのPS2コントローラとなんかでつなぐってのが常套かなと思ってました。けど、RPU-10を使って～、ということも考えているのでそっちにも流用できるこっちにしました。
でも、RPU-10がないから受信機の電源電圧さえわからない。バッテリー電源の７．４Ｖを入れる？それともRPU-11の中で作った5Vとか3.3Vとかで動くのかな？ もちろん信号接続も不明。どんな信号で送受信してるんだろ。 コントローラにバイブのスイッチがあるってことは双方向通信ができるんだよね、これ。 ネットを探してみたけど、これの解析やってる人は見当たらなかった。SISOさん、知ってたら教えて～。
素直にRPU-11を買えばいいのだけど、ATMEGA128ならばベステクのATMEGA128ボードにRS485とか加速度センサーをつなげばいいわけだからそっちの方が安いかなとか考えてしまう。 ・・・いかんいかん、時間を金で買った方がいいはずなのだが、、。
コネクタは６ピン。うち２本は電源とアースだとすると信号接続に４本使ってる。 相手がATMEGAだし、RPU-11はシリアルポートを２ポートもってるけど、RS232CとRS485にそれぞれ割り当てていると考えると、こいつはI2CかSPI（だっけ？）あたりのシリアル通信接続かな？I2Cだと信号線は３本で半二重通信できる。１本余るな。。。 調べるとSPIも３本らしい。
それにI2CとかSPIとかよく知らないんだよね。
今週唯一のロボット活動日だったのだが、そんなこんなでうだうだやってたら時間がなくなってしまった。ロールの抑制策の検討は週末まで持ち越し。 ＧＷ突入やーん。(>_<)
■４月２７日■
昨日は二日酔いで一日ぼけ～っとしておりました。せっかくの休日が無駄に。。。 金曜日の飲みはみんな張り切っちゃうのでついついペースに引き込まれてしまう。自重せねば。
ロールを抑える手段を考えるために歩行時のログを眺めて気がつきました。ロールの発生は足を上げるタイミングにリンクしているらしい。重心のズレが主原因かと考えていたが足を上げた状態では重心のずれ（この場合は重心点に働く加速度も影響するのだが）もシビアになる上に足を上げるという動作の反動も働くためだろう。
↓上が足を上げないで左右にゆらゆらさせただけ。 下のは20ミリほど足を上げて足踏み
黄色のラインがＺ軸回転角度を示す。 足を上げると前進しなくても回転動作が発生してしまう。
で、これを抑える手段だが、同じタイミングで逆方向へのロールが発生するような動作を発生させてみる、ということで腕の振りを作ってみた。
ピョコンと上下に出てるのが腕の振りで発生したロール。両足を着いた状態なので、パルス状になってしまっている。
これを作るのは結構苦労で、単に前後に腕を振っただけじゃこんな風にならずに止まった時の反動もロールになってしまう。なので、ブンっと振って、ふわっと止めるということをしている。 始めはそうなるようなカーブを再現させたのだが、脈動ができてうまくない。 結局はブンと振って、その後にトルクを抜いて反動が発生しないようにした。
普通のＰＷＭサーボでPWMの周波数を下げるだけで同じことができるかどうかはわからない。
で、これが足上げ10ミリのデータに腕振りデータを重ねてみたところ。こんな雑な感じで相殺できるのかどうかはわからんけど、やってみるかー。
・・・・・
とりあえずやってみたけど。。
キャンセルどころかひどくなってる。。 べらぼうな調整をすればちょっとはマシになるかな？
もともとの、歩いている時のログではこんなに脈を打った動きはしていない。 ほぼ三角波になっていた。つまりはガツンという衝撃ではなく、すいーっと回転しているわけだ。 ちょっとアプローチを変えた方がいいのかもしれない。
■４月２９日■
いろいろいろいろなパラメータを調整してロール動作を抑制しようとしたがすんなりとは抑制できない。 だが、腕の振りをうまく使うことで歩き出しの重心点の加速に一役買うことがわかった。 重心点の加速ができれば、遊脚の離地タイミングを早くすることができて、それはつまり歩幅を大きく出来ることにつながる。 今のプログラムは歩き出しの腕の振りがうまくなくてもうちょっとプログラムの作りこみが必要。
あれこれいじり回したお陰でこないだよりは安定した歩行パラメータを見つけることができたらしい。 次の日に同じパラメータで動かしたら全然ダメってことも多々あるのでここは「らしい」ってことで。
歩行は午前中のお題で、午後はプログラム全体のプロセス管理を検討することにしていたのでそれに取り掛かる。
インターバルタイマーを使ったシグナルハンドラを使ってサーボに指示を出していたのだけど、プロセス管理的にはどうなのか？ってのがずっと気になっていたのでその検証と検討。
まずは25ms周期ってのをもっと短くできないものかということでシグナルハンドラの処理時間を測定。 ちなみに関節角度の取得を一切行わなければ15msくらいでは回せる。
25ms（25000）のラインを簡単に上回ってる！ どうしたものか。これは画像処理ルーチンの処理ループにusleep(0)をたくさーん入れたバージョン。たくさん入れすぎて１フレームの画像処理に0.2秒から0.5秒くらいかかってる。 画層処理プログラムが直接原因なのかと思って比較したりしたが、画像処理プログラムを動かさなくてもあんまり変わらない。
で、これはラムダのプログラムを最優先で動かした時。画像処理は無し。 これだと25msに収まる。20msでも大丈夫っぽい。
いろいろ調べた結果、子プロセスは親プロセスと同じ優先度ということがわかった。なので、最速にしても画像処理プログラムが動くと間に合ってないフレームがたくさん出てくる。
今日の最後のデータがこれ。 サーボ制御は最優先(-20)で、画像処理は普通(0)これでもこんだけひげが出てしまう。 でも、見かけ上は、サーボは影響なく動いている感じだ。
最初のより悪くなっているように見えるが、画像処理プログラムにもほどほどにＣＰＵタイムを回しているためだと思う。 ボールを追うラムダの首の動きも以前より軽やかになったようでよい感じ。
でもでも、この上に音声合成と音声認識を動かすのはＣＰＵパワー的にはムリっぽいし、こんなゴツイＣＰＵをもう一つ詰めるはずも無く、ここはリソースをうまく配分してやりくりするようにするしかないでしょうね。 ①サーボ ②画像 ③音声合成 ④音声認識 この中で完全に同時に動かさねばならないのは ①サーボと②画像、 音声認識も同時にやりたいところだがちょっと無理っぽい。 自律だし、画像優先だろうなー。 あとはシチュエーションで切り替えてリソース使うことになるかな。
それはそうと、今日現在、５月５日の練習会って参加表明者だれも居ないんですけど、これは決行されるんでしょうか。 ロボカップジャパンオープンのヒューマノイドリーグの決勝トーナメントと重なってるのでどうしたものかと思ってたのだけど。。
ロボカップといえば、ヒューマノイドサッカーは実はあんまり見所がない。なのでどうせ観に行くなら今回初お目見えのホームリーグを観に行った方がいいかな。ホームリーグだと４日と５日。沼津まで通うのはちょとしんどいのでどちらか一日だけになるでしょう。 ４足ロボットリーグもあるけど、これはアイボ？アイボは去年で終わりかと思ってたのだけど、どうなんだっけ？
■４月３０日■
さて、とうとう自律動作の設計に入らなければならないときがきました。 早くやりたいと思いつつ、実はどうすりゃいいのかわかんないままなので先に先に送っていた節もないではないといった状況です。
ラムダにロボビリヤードをさせるにはロボビリヤードのルールを教え込む必要があるんですけど、どうやって表現すべきなのか？？？ 出来るだけハードコーディングは避けたいので悩みどころです。
まずは、トラッキング（目標物を捉える）、 アプローチ（目標物に近づく）、 リーチング（目標物に手を届かせる） といった基本行動を組み込みつつ、数字の序列をどう表現すべきか、とか、「目標物を倒す」という上位レイヤーの目標行動をどう表現するか、などを検討していきたいと思ってます。 難しそうだなー。
■５月２日■
トラッキングとアプローチの実装について検討中。
「<目標物>を<倒す>」という指令の実装方法を色々と考えているのですが、ちょっと発散気味。
後引きの考え方を導入すると、「目標物に手を伸ばしたが届かない」ので「目標物に近づく」 という感じで、リーチングからアプローチを起動して、、という形を考えていたのだが、これだと汎用性がない。ある動作を行うたびにハードコーディングするか、コンフィグのような設定を更新してリンクを張るような仕組みが必要。 もうちょっと曖昧というか柔軟なシステムをイメージしているので更に検討が必要。
他にもアプローチしていて、アプローチ命令が取り下げられた場合、アプローチ処理部より歩行停止命令を出していいものか。 イメージとしては「アプローチ部門としては歩行の必要性がなくなったので歩行してもらう必要はなくなりました。」という連絡を入れるだけで実際に停止するかどうかは歩行部門で決めてもらおうというふうにすべきかと考えている。 つまり、歩行の開始停止に対してもフロントが必要で、フロントを通して依頼すると。。
アプローチ指令が来たけど、現在トラッキングしている物体は無い。 じゃどうするんだ？トラッキング指令を出せばいいのかというと何をトラッキングすべきかをアプローチ部は知らないわけだから、、 うーん。。。 これはもっと上位レイヤーの仕事か。 アプローチ指令が来てもトラッキングしてなきゃキャンセルだな。
全体的には後引き処理の形をしつつ、後引き体制＝上下関係 にならないような協調システムにしなければならない。 ・・・ううむ。。 ・・・ 秋葉原行ってきます。
■５月３日■
昨日は秋葉原行ってからそのまま飲みに。。。 飲んだ次の日は午前中はヘロヘロなのだけれど、せっかくのＧＷを無駄にしたくなかったのでなんとか11時ごろには持ち直して昨日の続きにとっかかりました。
昨日はRTでRPU-11を買ってきました。イメージよりもちっこいですねー。 考えると、RPU-11のプログラムをいじればRPU-100とつないでラムダにコントローラをつなげそう。
秋月でこんなのみつけました。ハーフピッチのユニバーサル基板。 小さく作りたくてSMD部品で回路を組む時、レギュラーピッチのユニバーサル基板で作るとあんまり小さくならないですよね。 基板起こすほどじゃないから苦労してました。 ハーフピッチコネクタとセットで売ってました。
さて、昨日の続きでトラッキングとアプローチの実装を進めました。
今のところはロボットが歩き出すきっかけは<アプローチ>しかないのだけれど、この先はどんどんと増えてくるはず。 歩き出すだけじゃなく、なにかの動作を行うのは大抵一度に複数のことはできないから（モノを持ちながら歩くとか、複数要素だな）歩き出すだけじゃなく、例えばトラッキングの延長で、首だけで追いつかずに体の向きを変えるってのも動作になる。その要請元は一つじゃないけど請け口は一つ。 そこで、要請を提出して、吟味の結果、どれを実行しますって処理を行わせます。
アプローチは必要に応じて歩行の要請を出すけれど、ターゲットに十分近づくと歩行停止の要請も出す。 で、受付側は要請に従って行動を決定するのだけど、たとえばアプローチ処理を行わなくなってしまったら、歩行停止命令もこないので歩行を停止するきっかけがなくなってしまうのだ。
なので、歩行の要請は常に行い続ける。 そして歩行要請が無かったら歩行を停止するという処理にすることにした。
だんだんだんと処理が複雑になってきて、なかなかバグが取れなかったのだが、（なぜだか停止命令が実行されないというバグがなかなか取れなかった。）やっと先ほどボールに十分に近づくと歩行停止ができるようになった。 (^。^)
まだ、目標物に向かうカーブの処理が甘いし、カーブ歩行か旋回するかの判定も甘い。 いまは首の向いている方向で歩く方向を決めているが、例えば目標物が後にあって、首を下に曲げて脇から後を覗き込んでいるような場合は正しい方向に歩けない。 やっぱキチンと目標物の位置を座標で表して、歩く方向を決めるようにしなけりゃダメですね。
でもまぁ、なんとなく自律の処理の形が出来てきた。 まがりなりにも自律したせいで不都合もでてきた。 歩行要請がないと停止命令を発行するようにしたので、マニュアル操作で歩かせようとしても止まってしまう。(^^ゞ 自律モードとリモコンモードっていう切り替えがないから理由もなく動かせなくなってしまったのだ。 リモコンモードを作るよりも、コマンドによって動作要請を出すようにした方が簡単そうだな。
というところで続きは明日。 明日はロボカップを見に沼津まで行ってきます。 去年も二日目だけ観に行ったなぁ。 ヒューマノイドサッカーのレベルが上がっていれば面白いのだが。 あと＠ホームリーグがどんなんかを見たい。 サッカーより興味あるし。
■５月４日■
ロボカップジャパンオープン２００８に行ってきました。
（画像が粗いのは携帯でハイレゾで撮ったのを切り出したため。やっぱりちゃんとデジカメ持って行かなきゃダメだな）
沼津での開催なので去年の大阪よりも更に近いんですが、新幹線で行っちゃうと片道5000円くらいかかる上に最寄駅からだと1時間半はかかる。なんだかなぁってことで調べた結果、登戸から小田急で新松田まで行って、そこから御殿場線で沼津まで。所要時間は2時間10分くらいになるけど、交通費は1500円くらいで済む。ってことで、小田急＋御殿場線で沼津に向かいました。
ゴールデンウィーク中ってこともあって御殿場線は大混雑。新松田はスイカが適用外なので行楽客が大勢自販機と窓口に群がる結果に。更には御殿場の手前までは座れないくらいの混みようでした。。 地元の高校生が「何でこんなに混んでるの！」と困惑しておりました。(^_^;)
いつも出張で中央線で山梨に行ってるので富士山を見てるのだけど、御殿場線からの富士山は本当に裾野から見上げる感じで雄大にそびえ立っていました。御殿場線で行ってよかったー。
ロボカップ会場はキラメッセぬまづと沼津市民体育館に別れてまして、目当ての出し物のうち、ヒューマノイドリーグと4足リーグはキラメッセ、＠ホームリーグは体育館と分かれてしまってます。 結構距離がありそうだし、まいったな。
まずは駅に近いキラメッセに向かいましたらヒューマノイドリーグにくぱくま夫妻が。(^_^) 大きな荷物持ってましたけどガルーとクロムキッドが入ってたのかな？
チーム大阪のティーンサイズロボット。 どんどんと大きく成長してます。
こちらははじめロボットのティーンサイズ。 去年よりやせたか？
フィールドはチームオリエントがＣＩＴブレインスに圧倒的に負けている状態で後半戦が始まるってとこでしたが、チームオリエントの調整が終わらずに相手チームが無人のゴールにシュートし続けるという状態。 ・・・ ヒューマノイドリーグの夜明けはまだのようです。
それにしてもチームオリエントは去年は確か富士通のHOPEで、ほとんど動かないで惨敗してましたが、今年はZMPに機体が変わっての出場。すごいっすね。500万円のロボットを使い捨てですか。 それより買い換えるなら実績十分のはじめロボットやVISIONにすればいいのになにか目論見でもあるのかな？
ヒューマノイドリーグの試合の様子。 実況席はまだいいとして、出場者が邪魔で観客席から見えない。 入場料取ってるんだからちゃんとしろよ！と言いたい。 ちなみにチーム大阪が出る試合はこういうところはキッチリ押さえてました。 なお、この画像はチームオリエント対CITブレインズではないのでご注意を。
４足リーグはやっぱりアイボがエキジビションマッチをやってるってことで、まだアイボは現役のようです。 こちらは非常に洗練されてまして、スピード感もあるし、面白い。タイヤで動く小型機や中型機よりも足を使って動いている分生命感があっていいですね。数年後には４足リーグは同一機体を使った2足歩行リーグに移行するらしいけど、ここまで育った4足リーグを消滅させるのは忍びないですね。採用が決まったヒューマノイドも安定しているとは言い難いように見えたし。
カニボ（青アイボチーム）初めてみました。でもこけやすい。 赤アイボの方がいい動きしてたな。 （画像じゃわかりにくいですね。スイマセン）
レスキューリーグもちらりと見ましたが、でかいクローラ式ロボットがゆっくりと動いてました。こっちもまだまだだなぁ。災害地って想定の不整地を歩かせるならクモ型で決まりじゃないのかな。月面探査機はクローラーや特殊タイヤだけど、被災地って月面より不整地度が高い思うのだけど、クローラで大丈夫なのかな。
レスキューロボットを操縦するヒト。 こうやると口が開いちゃうって信じてたけど、このヒトの口は開いてなかった。 挙動不審だったけど。(^。^)
ところ変わって沼津市民体育館。 こちらは初お目見えの＠ホームリーグがあるので見に来ました。
今日の午前中はオープンチャレンジで午後からが本番のスケジュールだったと思ったのに午前中に今日の競技は終わってしまったらしい。 ちょうど12時くらいに見に行くと調整中のドラム缶みたいなロボットがスタッフに囲まれてました。 これの競技ってヒューマノイドでやるべきだよなー。ヒューマノイドの本領発揮じゃないかと思うのだが。・・・本領ってのもおかしいか。 似合うっていうか、そういう感じ。
１時くらいからエキジビションということで午前中にやった競技をもう一度やってました。あらかじめカメラと音声で教えたモノを家の中から探すという競技。こちらもこれからって感じでした。
フューチャーロボ的な＠ホームロボ。中身はノートパソコンでした。(^_^;)
一通り見回ったので、キラメッセに戻ってアイボリーグとヒューマノイドリーグを行ったり来たりしてました。ヒューマノイドリーグは実力に大きな差ができてしまったようで数チームの点が取れるチームと、残りは点が取れないチーム。各試合のスコアは０－？とか？－０とか０－０とか、点が取れた方が勝ち。 更には点が取れるチームが決勝トーナメントチーム数の４チームに満たないので、失点差（得失点差ではない）で決勝出場が決まるという状態でした。
今日の試合を全部見たわけではないのだけど、今回のチーム大阪は準備不足という感じがしました。 外装が間に合ってないし、シュートも失敗が多い。 今回から３ON３になったのだけど、フィールドプレイヤーの２台の連携ってのが皆無でお互いに球を取り合って共倒れでこけてしまったり。 外装が間に合わなかった以上に仕上がっていない様子でした。
明日の決勝までには調整してくるんでしょうかね。 見にはいけないけど。。。
波動というチームが学校でもなく、企業でもないフリーの集団からの出場でした。 KHR-1をベースにした機体でまだまだって感じだったけど、フリーで出場ってすごいですね。4人も同志が居るってうらやましいです。
去年の今頃は自分も「来年は出場するぞ。」って思ってたのですが、同志が居ないのと３ON３になったってことがでかくて、そうまでして出場する目的を見出せずに出場を目指すことをやめてしまいました。去年見たときには「今年のレベルならなんとかなりそうだけど、来年はレベルがあがってもう追いつけないかも」って思いましたが、今年のを見てもやっぱり追いつけそうかもと思ってしまったのがちょっとアレですね。(^^ゞ
ラムダはというと、この１年で進歩したようなしてないような。 とうていロボカップに出られるほどの仕上がりにはなっていません。 でも実は、あちこち寄り道をした割には進化したかなとちょっとだけ自画自賛してるのは秘密です。
最後のヒューマノイドリーグの試合が終わったところで会場を後にし、帰路につきました。 くぱくま夫妻はそのままアイボの集会に参加するとのこと。今日の荷物はアイボだったのか！
■５月６日■
アプローチの特訓中。 (^_^;)
トラッキングでカメラは目標物の方を向いているので、カメラの姿勢を頼りに歩かせていたのだけど、接近の処理がうまくいかないのでダメ。
やっぱり、手抜きじゃうまくいかない。 下半身姿勢の上にカメラ姿勢が乗っかったモデルで計算して、ロボットの位置から目標物の位置を計算してみました。 使っている値は各サーボに対する指示値なので実際とはズレがある。 そのため、遠くの目標物の位置は大きくずれるのだけど、近くのものはそれなりに精度良く計算できるようなのでまぁいいでしょう。
歩く条件やら止まる条件やらはなんとなくうまく動き出したようだ。 方向を変えるのも１歩単位が最小単位。 なので目標物に近づくための歩行半径の計算も、次の1歩の計算をする直前に計算するようにしたら、それなりに歩くようになってきた。
まだだめなのは目標物が横にある時。 旋回歩行をして目標物が正面になるように動くのだが、なんだか挙動不審。 旋回してはカーブ歩行、また旋回というふうに変な具合になってるみたい。ログをちゃんと調べてないのでわからないけど。
近づいて止まったとこ。 もうちょっと安定したら動画に撮ってみます。
カメラ姿勢の計算なのだが、ラムダの頭部構造はチルト（上下）の上にパン（左右）が乗っかった構造になっている。これだと、チルトした状態で横を見るとカメラが傾いてロールが発生する。 パンにチルトが乗っかった構造にすればロールが発生しないのだが、ダブルチルトにしたかったのでこの構造にした。
ちょいと計算すれば済むからどっちでもいいって言えばいいんだけど、本当はロールが発生しない構造にすべきだなー。
トラッキングの不具合で、カメラが左右にブン回ることがあるんだけど、そのせいでカメラのズームコントロールのコネクタが抜けてしまった。 それで気付いたのだが、こんな感じ。
←これはズーム画像。大抵これで検討している。
←これが超広角画像。ほとんど真横まで見える。
←これが顔面外装をつけた状態での超広角画像。 せっかくの広角が外装で埋まっちゃっている。
外装の不具合も徐々に直していかなきゃなー。
■５月９日■
アプローチの特訓を進める前にトラッキングの不具合、、、というか、カメラ姿勢の管理のしかたに問題が出てきました。
ま、問題というより検討不足が露呈したというところなので大したことはないんですが。。
ラムダのカメラを向ける方向を指示する数値として、今は投影角度を使ってます。投影角度というのはカメラが向いている方向を向いた矢印を考えた時、その矢印をX-Y平面に投影した時の角度とY-Z平面に投影したときの角度で方向を表すものです。スクリーン平面を表す法線ベクトルを角度で表したものとほぼ同じです。
カメラの方位を指示するのはトラッキング時がメインと考えたので、画面上の追尾物のズレをそのまま指示すればいいわけで、簡単だと思ったわけです。
関節角度ではなぜまずいかというと、例えば下の画像のような状態になった時、カメラロールが発生します。 CDT画面なのでよく判りにくいけど、緑色が畳を感知した部分なので90度以上ロールしていることになります。 この状態でも、ボールが（画面上の）左右にずれていたら（ボールがラムダの方向へ近づいたり遠のいたりしたら画面上は左右にずれることになります。）パン関節をその分だけ動かせばいいのですが、上下にずれたからといってチルト関節を動かしても思い通りにはカメラが動いてくれません。
なので投影角度に変換して指示を行い、それを関節角度に分解してカメラを動かす必要が出てきます。 そういう意味ではロールが発生しないカメラ姿勢で指示しても同じ効用があります。
ですが、投影角度表現をした場合、計算にタンジェントを使うため、90度を超える状態ではうまく表現できません。 90度を超えた場合には更に換算したりする処理が必要です。
そういうわけで、すくなくともカメラ姿勢の管理はpan-tilt-rollタイプの回転座標角度で管理するように変更すべきだなと。
さらには、下の画像のような状態になった場合には胴体の姿勢も画像のロールに影響し、とうとう逆さまになってしまいます。頭部関節だけでトラッキングするだけなら今までと同じ処理をすればいいのですが、トラッキング不可能になった場合に体を動かすべき方向を知るにはロボット全体でのカメラ姿勢、カメラロールを知る必要が出てきます。
そんなわけで、頭部の管理変数と管理関数に変更を加えることにしました。 今日はもう遅いから明日の午前中の作業かなー。
■５月１０日■
昨日の宿題だったカメラの姿勢表現変数は全て変更して投影角度から姿勢角度にしました。 トラッキング時にはカメラロールも反映してアプローチについても大きなバグは取れたようです。 まだ全体的に動作が不安定で、コアダンプを起こしたり、フリーズしたり、想定外の動きをすることがあるのであちこちにバグが潜んでいるんだろうなぁ～。
ま、精度を上げたりデバッグしたりするのはおいおいやるとして、次は目標物を触るってのをやってみたいと思います。ロボビリヤードの的を倒すのはキックでも構わないのだけれど、せっかくだから手を伸ばしてプインとはじき飛ばしたいなと思ってます。 ところが、ラムダは実は単眼なので物体までの距離を知ることができません。床においてあるものは大体の距離がわかるのだけど、手を伸ばして触るという精度は期待できません。
そんなこんなで、今回は手を伸ばして自分の手を目標物に重ねるということをやってみたいと思います。 距離を測り間違うと空振りしちゃうんだけど、目標物は大きさで距離の目算をつけようと思います。 つまり、正体が判っているものが対象ということです。
↓こんな風に対象物に手を差し伸べて対象物と手を近づけていきます。
ボールを触りに行くラムダのイメージ図
手を認識するために手先にわかりやすい色を取り付けます。
ラムダのカメラから見るとこんな感じ。↓
CDT＋ラベリングで物体を認識しています。
CDT画像。緑の四角いのがラムダの手先。
これだけ間近になるとズーム状態だと画面がボールだらけになってしまうため、超広角画像にしています。
トラッキングとアプローチについては目標物の追尾にCDTを使っていました。 なので物体を追いかけているわけじゃなく、ピンクっぽい方向に引き寄せられるという感じになってました。 ですが、そろそろ物体を対象にしたいのでCDT＋ラベリング処理のデータを使うようにしたいと思います。 ラベリングデータを使うと、トラッキングなどが難しくなります。なんせカメラも動くので相対的に物体が動くことになります。すると、さっきと同じモノを追尾しているのかどうかがわからないのです。
■５月１１日■
今日は午前中から画像処理部分の見直し。
画像処理プログラムはCDTエディタとして作った物を転用して使っていたのだが、その名残で、IPSOCK接続が成立しないと画像取得を行わない作りになっていた。
IP接続処理も決めうちになっていて、クライアントからの接続要求をずっと待ってる作り。 なので、クライアントがなんらかの原因で終了してしまうと、画像処理が更新されず、直前の画像を見続けるという。。
そのあたりをもうちょっと汎用性のあるように改造したりしてました。
で、それが終わって、さて、ラベリング処理データでのトラッキングにとりかかろうとしたところ、ラムダの腕が。。
外装被ってるからフレームが折れているのに気がつかなかった。二つの部品でつながっていたのに両方ともちぎれてる。早く気付いてたらどちらか一方はちぎれなくて済んだのにな。
すでに夕方だったので今日は修理できないなーと思ったのだが、来週末までこのままだと不便ていうか、ラムダを動かせない。 ２部品だけだからと、大急ぎでフレームを再製作しました。
おかげでラベリングデータを使ったトラッキングは完成しませんでした(>_<) ま、これがなくても完成してなさそうですが。。(^^ゞ
ラベリングした画像データでのトラッキングとアプローチってのはアイボでやったことがあります。 アイボのＯＳはよくできていて、画像が来る時間もサーボを動かす時間や周期もきっちりしてます。 それでも相当苦労して動かしたので、ラムダではちょっと難しいぞってことで構想しながらしり込みしてました。
今回はCDTデータをラベリングするってことで、通常のCDT画像の重心とラベリングデータを併用してトラッキングしてみることにします。 ちょっとどうなるのかわからないけど、なんとなくいいアイディアである気がしてまして、うまく動くのが楽しみです。
それができたら、今度は画像に写る自分の手先を希望の場所に動かすというのをやってみる予定です。 目標物をトラッキングしたまま、手先を目標物に近づけなきゃならないってことで。
考えてるときはワクワクして楽しいんだけどなー。コーディングを始めるまでが大変なんですが。。。
MARU Family や、Kino部屋 で、お手伝いプロジェクトの様子を知りました。 ロボワンよりは自律ロボットネタなのかなと思っていたんですが、お題がヘビーなのであんまり興味なかったんです。 5月7日まで申し込みできたみたいなんで、見学だけでも行けばよかったかなと、ちょっと後悔してました、近くなのに。。。 でも、やっぱりリモコンなんですね。 ヒノキオ（だっけ）みたいな感じですかねー。
■５月１３日■
ラベリングデータを使ったトラッキング。 昨日からコーディングして昨日今日とデバッグ。
一応は動くようになりました。 まだもうちょっと練りこみが必要だけど、仕組みとしてはうまく行ってる方かなー。
なかなかまだまだうまく行かないけど、方向としては間違ってないかなーと。 動画の最後で上の方に視線を奪われてしまいますが、視線の先は。。。。
これかぁ～
いや、、、もしかしてこれか？？ 顔が似てるし。(^_^;)
画像のフレームレートが低い上に不安定なので、移動量予測などがうまく働かないと思い、はなっから移動量予測は組み込んでいません。 代わりにCDT重心からの位置ずれを記録しておき、次のフレームでもその関係が保たれていることを期待してます。
ただ、ラベリングを１フレームでも失敗した場合、容赦なく、違うラベリングデータに注視が移行してしまうプログラムになっているので微妙な色合いや明るさでは不安定な動作になってしまうらしい。 数フレームくらいは待ってみるとか、予測座標からかけ離れたらロスト扱いにするとかの処理が必要なようです。
さて、その改良もやりながら、次のお題は決まった大きさになるまで近づくってのをやってみよう。手が届くところまで近づくということです。
いや、画面に映った手を指示通りに動かすってのが先かなー。
次にやることの検討。
まず、大きさがわかっているモノの距離を画面に映った大きさで知るには、、、画角とモノの大きさがわかっていれば簡単な計算で出る。 ラムダのカメラレンズは超広角でひずみが大きいため計算精度は低いはずだが、使い物になるか？？
上の□がスクリーン。 下の三角は視野角を表している。
ええと、、
XとLが未知数。、、、画面の幅に対してモノの幅が占める割合を ｒ = W/X とおくと、 L= 2W / r tanαなので r = 2W / L tanα
画面に映るモノの画面上のサイズが判ればモノまでの距離が判る。 モノが床にある前提で、視線方向で距離を出すのとどちらが正確かな。 視線方向で算出する場合はカメラの高さが計算値どおりでなければ誤差が出るので画面上のモノ大きさの方が精度が高いはず。 モノの本当の大きさが判ってないといけないという制限があるから、使えないかも。。(^_^;)
で、画面に映る手を画面上のある座標に移動させるって方は、、 視線方向を法線ベクトルに持つ、手先座標を通過する平面を算出して、目的座標をその平面に投影した時の空間座標へ手先を移動する、、ってやろうかなーとも思ったが、なんかちょっと違う気がしてボツ。 計算めんどくさいし。
頭も腕も胴体についているわけで、胴体を基準とした視線方向はわかる。手先の座標はわかる。すると、画面に映る手先とカメラの距離もわかる。つまり、移動先の空間座標もわかるわけだからさっきみたいな3次元幾何を使わなくても座標変換でわかるはず。 こっちの方が関節の準運動学や逆運動学計算で慣れてるから簡単そう。
手先は2色のカラーのカッティングシートでマークしようと考えている。 デザイン的にはアレだけど、まぁこの際仕方ない。 ラムダは基本的に最低４色の色識別ができるようにしておいて、そのうちの2色の組み合わせでマークを見分けるようにするつもり。 4×3=12 の組み合わせのマークが識別可能。
そのうちの2種類を左手と右手に割り当てる。 どのような場合でもこのマークを見つけたら、それは自分（ラムダ）の手先だと認識する。 自分の体をカメラを通して客観的に認識することって大切なことだと思うんです。
ここんとこ寝るのが遅いせいか、今日は激烈に眠い。 今日はここまでにして早めに寝よう。(-_-)zzz
ラベリングデータでのトラッキング