開発日誌(14)

開発日誌インデックスへ
前のページへ

最新へ↓

1月3日

あけましておめでとうございます。 ネットの無いところからネットがあるところへ戻ってきました。でも、まだ帰省先です。

こっちでは朝から晩まで酒びたり、ご馳走攻めで腹が減る暇もありません。もう胃がおかしくなってます。(>_<)

まぁそういうわけでたいした進展はないのですが、親類が来る前と帰った後の時間は暇なのでゲームをしたりパソコンに向かったり。。。

画像処理についてはアイボの物体追跡処理のために開発した物体認識プログラムを改造するために、数年前に書いたコードを解読してました。自分で書いたプログラムでも数年も経てばさっぱり判りません。(^^ゞ 何度も流し読みして段々イメージをつかんだ後プログラムの骨子をメモに書き出しながらなんとか解読ができました。(というか思い出してきた)

今回は、カラー画像用に作ったこの物体認識プログラムをCDT用に書き直して適用するつもりです。 でも、どうやら構造体をちょっと変えるだけでCDT画像データにもカラー画像データにも適用できそうな気がしてきたのでC++のテンプレート機能を使ってクラス化すればちょっとだけ記述が簡素化したりしないかなぁと思い始めてます。

物体認識は、ある画像フレームから物体を抜き出す抽出部と、連続した画像フレームで同じ物体を関連付ける物体追跡部がある。今回のロボビリヤードでは抽出部のみを移植するつもり。 物体追跡部は同じ形のものが複数ある場合でもそれぞれを識別するために作ったのだが、ラムダでは画像フレームが決まった周期に得られない状態なので信頼度が期待できないので使えないだろう。もともとそれほど安定していないし。。

・・・・・・・

あと、家じゃめんどくさくてなかなかやらなかった部位毎の重心の算出なぞやってました。重心計算上、バッテリーを1部位として計算するようにしたので、バッテリーの重量が変わった時もバッテリーのデータを変えるだけで重心計算に反映できるようにします。

  

今夜は移動で家に戻ります。残りの休みの間に色物体抽出を動かしたいと思います。

1月4日

無事、帰省先から戻ってきたので、さっそくロボット開発開始。

では、物体抽出を。。 と思ったのだが、まずは重心計算用データの組み込みをしてしまおうと取り掛かった。 が、頭部分のデータの取り方が間違えているのに気付いてデータを取り直し。そして取ったデータを整理したりしてました。

ま、それはやりなおしなので程なく終わり、今度こそ物体抽出を。。 と思ったところでふいに思い出した。物体抽出のための領域の切り出しってのは画像処理ではラベリングというのです。「画像処理 ラベリング」で検索すると色々でてきます。

で、簡単なアルゴリズムはないかなぁと思ったのだが、アルゴリズムの説明があったりするのはしらみつぶしのタイプばかりで、工夫しているらしいアルゴリズムは秘密みたいです。 結局、自分で作った方法の方がしらみつぶしよりはよさそう(性能というより趣味の問題だが)なので、方針変更は無しで。

アイボ用の物体抽出プログラムをラムダに移植する際、YUV画像用をCDT画像用にしなきゃならないのだが、とりあえずはYUV画像用のまま移植しちゃうことにしました。どうせそのうちやらなきゃならないわけだし。どっちかっていうとCDT用の方がスポット使用になりそうだし。

CDT画像をラベリングする場合、2値データなので閾値をどうするかということは考えなくて良い。対して、カラー画像でラベリングする時の一番の問題は閾値です。

YUV画像から物体抽出するために、まずは閾値設定をする処理をかけます。まぁコントラストを調整したりエッジングしたりするんだけど、最終的に「色の差」を見て、物体の境目を判断します。

 まずは普通のカラー画像

 次に境界処理を施した画像

 最後にCDT処理画像。緑のボールは見えてない。

真ん中の画像で、緑になっている画素は色の境界部分と判断したところ。カラー画像が残っている画素は隣の画素と色が近いと判断したところ。

これで、色のカタマリと判断できる画素だけが残ったことになる。次にこの画像データに対してラベリング処理を行うのだ。

下のCDT画像だと「ピンク」を見ているので真ん中の画像より本当の物体がハッキリと判断できているのだが、これの欠点は万能性が無いということ。判別したい「色」の範囲を事前に明確に規定する必要がある。 色の境目を見る方式だと、事前にデータを用意することなく、モノを「見る」ことができるというスンポーだ。 もっとも今日の例だとモスグリーンのボールはカーペットの色との差があいまいで、はっきり「見えて」無いのだが。そこは愛嬌ってことで(^_^;)

アイボとラムダだとハードの構成が随分と違うのでここまでの移植に意外とてこずりました。では続いてラベリング処理の移植へと進みます。こっちはデータ処理だけだから簡単なはず。  簡単って思ってすんなり行った試しがないんだけどねー。(^^ゞ あと、ラベリングした結果を表示するプログラムも作らなきゃならない。そっちの方がめんどくさそうな感じです。

1月7日

だいじだどころでガゼヴォびいてじばいばじだ。

いつも風邪は鼻からをひいて全身をまわって喉に居座るんですが、今回は鼻だけで収まりそうな気配。。。だといいんだけど。もしまた更新が止まったら風邪がぶり返したんだと思ってください。

5日の午前中には物体抽出のルーチンも動きだして、あとは画面に表示するだけというところで、風邪でダウン。5日の夜からずっと布団に入ってました。

で、今日は動けるようになったので物体抽出の画面表示をさっくり作ってみました。手抜きですけど。(元画像データに直接マークしている)

こんな感じで、ふすまとか、ゴミPCケースとかも物体として見えてしまいます。もちろんこれらも物体なので見えて当然。その後は目的に応じて必要なモノだけを見るようにすればいいわけだし。

黄色のクマも見えてはいるけど、凹凸があるので、顔部分と足部分の合計3つに見えてます。これももちろん、こんな複雑な形状をしたものが一つのモノだなんて知識がなければわかるはずはないのでこれでいいのです。本当は三つに見えた物体が一つのモノであることは今後わかってくる(予定)のです。

ちなみに横に目を向けて本棚を見てみると。。

こんな感じ。なにがなんだかわかりません。まぁこれもいたしかたないでしょう。この世は刺激でイッパイなのです。そのうち、ラムダのために真っ白ななにも無い部屋を用意しなければならないかもしれません。(^_^;) ちなみにラムダの頭部は3自由度を持っていますが、チルトに2軸使っているため、左右を見るとこのようにチルト角との兼ね合いでロールが発生します。このロールの角度は計算で算出できるので画像を回転させることで上下を正しく補正することも可能です。ただし、ロボットにとってはこのロールはそれほど問題にならないので恐らく回転補正は行わないと思いますが。(ただしパターン認識を行うときには適宜部分的に回転処理が必要となったりはします。)

正直、カラー画像からの物体抽出はラムダには荷が重く、ノイズにも弱く、将来的にはこの処理を中心に画像処理から空間認識へと進んで行きたいと思っているのですが、とりあえずは目的のモノだけを見ることができるCDT画像にラベリング処理を施したデータを使っていきたいと思います。

順序的には逆の感じもありますが、次は物体抽出ルーチン(ラベリング処理)をCDT画像に適用したいと思います。

1月9日

物体抽出ルーチンをCDT画像へ適用してみました。

CDTは8チャンネルあるので、物体抽出を8回行わなきゃならなくなるからちょっとぉ〜・・・。と考えていたが、ちょっと考えて、複数の色を一つのオブジェクトリストに格納できるようにしました。 あと、必要なチャンネル数だけをスキャンするようにしたので無駄なループが発生するのは極力抑えるようにしたりしました。

 いつものピンクボールと黄色いクマ

 こんな感じに。囲いの色が抽出色と合ってないですが、気にしない。

 これが自律ロボビリヤード用の紙コップ。底面に貼った色の組み合わせで数字を表す。昨日作った。(^_^;)

この紙コップをCDT版物体抽出で見ると、

 こんな感じに。

カップ毎に二つのマーキングが表示されているのが判ると思います。マークの色と抽出色はやっぱり一致してません。手抜きですね。(^^ゞ

 こんな風に見たとすると、

 ラムダにはこんな風に見える。

これだけ間近に近づいてやっとこのサイズに見える。超広角レンズの中央部だけにズームしてみている状態でこれだからフィールドの端っこから反対側の紙コップを見ても、色を判断することは難しそう。 あと1段階ズームすることもできるが、画角との関係で、ターゲットを正確に捉えられるかどうか怪しいところ。 紙コップの胴体にも識別マークを入れなきゃならないのかなぁ〜。それは避けたいなぁ。

次は、抽出した色オブジェクトの組み合わせから紙コップの番号に変換して〜、、 と進むんだけど、キリがいいところなんでそろそろ年末突入前にやっていた姿勢判定に戻ろうかと思います。

・・・・・・・・・・・・・・

ONO-ONEが終わってしまいました。(^_^;)

ONOの電脳壁新聞に掲載してもらうだけで驚きだったのに、意外とポイントが伸びてONO-ONE回数では上位に食い込んだりして嬉しかったです。(ONOさんありがとうございました。) 昨日、まつしろさんのブログを読んでいると、不意にうちのことが書いてあってびっくりしましたが、この日誌に書いてあることも、本当に自分がやってることの記録だけなので情報の濃度っていうか密度っていうかそういうのでいうとどうなのかなーと思ってます。

活動した日には日誌を書いてアップするようにしているんですが、日誌を書くのに心がけてるのは、基本は「記録」、日誌なのでその名の通り。あと、結果だけじゃなく考えてること(ロボットに関する構想や理論という意味)なんかもできるだけ書くようにしてます。結果という点では成功したことだけじゃなく、失敗したことも同レベルで書くようにしてます。失敗の情報って重要だと思うんですよね。 失敗した案を事細かに書くのは萎えるので、試す前の構想段階から書くってのは正解かもしれないな。書いてるときはうまく行くって信じているわけだし。

あと、心がけてないっていうか、気にしないようにしているのは、人に判り易く書くという点ではあまり気にしないようにしています。わかったことを正しく、それも解り易く書こうとするとものすごく時間がかかってしまって、やがて日誌を書かなくなるような気がしてます。ですので、まぁ簡単にいうと殴り書きです。(判りやすい文章っていうとSISOさんのブログは丁寧な文章でわかり易く書いてあってすばらしいなといつも感心しています。)

でも最近はカウンターが上がるのが嬉しくって、以前よりは判りやすい文章を書くことにも気を回してるかなー。(以前よりは、ですけど。)

ですので、もしここを見ていただいてる方で「何書いてるのかわからん」とか、間違ったこと書いてる、ということがありましたらメールなり掲示板なりで教えていただければありがたいです。よろしくお願いします。

1月11日

こんなの発見。知らなかったー。

まぶたと口がついたキュリオ。 表情の検討用らしい。 インテリジェンス・ダイナミクス(もう随分と昔の話だけど)に出てくるキュリオはオリジナルから色々と手を加えられてるモノが多かった。手首の自由度が増えたヤツとか、カメラを広角にしたのとか。 どれもオリジナルに比べるとデザインが崩れてておかしなふうになっている。このまぶた付きキュリオもなんか変だなー。 

1月12日

姿勢判定と、姿勢移行の検討と実装を進める。

次は座位の判定、というところで年末年始を迎えてしまったので、座位の判定から開始。

座位の判定は、仰向けとうつ伏せのチェックポイントに、座位のチェックポイントを加えて床面との接触をチェックする。緑点グループが接地していたらうつ伏せ、赤点グループが接地していたら仰向け、黄点グループが接地していたら座位、というふうに判断する。黄点の後側と赤点の下側は同時に接地するケースがあるが、その場合は仰向けが優先。

これで胴体接地系の姿勢はいいかなーと。 あとは立位系。 胴体接地がなければ何らかの形で立位系ということになる。手を付かなければ立っていられないという準立位は手が地面に届く必要がある。重心点が支持多角形に入っておらず、手が付かないほど重心点が高い位置にある場合は「転倒中」ということになる。静止状態ならば何かに支えられているということ。

これでまぁ一応は姿勢判定ができた。左右方向の傾きについてはほとんど考慮していないだが、運用で問題があるようならそれも考慮しなければならないだろう。

姿勢判定は、サーボからの角度情報と加速度センサーからのデータで構築した姿勢値を使っている。なので、サーボが脱力していない時でも、足部が地面に対して平行じゃなかったり、腰の高さが一致していなかったりと、ちょっとばらけた数値になっている。 脱力状態からトルクを入れた場合や、転倒受身をした直後などだと、サーボへの支持角度と実際の関節角度が一致していなかったりする場合もある。 これを綺麗な数値に正す必要がある。まぁ、必須ではないが、正した方が判りやすい。

この、整姿勢で、どこまで姿勢値をいじるかなのだが、足のロールなどをヘタにいじるとまたJ2関節が不安定になったりしてしまうので、とりあえずはJ1Z処理をして不安定さを取り除く。J1Z処理が不可能な場合はそのままで。

次に姿勢の移行に進むのだが、これはどう進めていいのか正直判らない。 でも、、悩んでいても解決しそうにないので、一つ一つつぶしていくことにした。

まずは仰向け姿勢から座位姿勢への移行。 単純に胴体のチルト角を0付近にもって行けばいいのだが、胴体が起き上がるのにあわせて膝を上げていく必要がある。つまり、足裏の接地部はできるだけ動かないような移行計画を作成したい。

本当は足裏のスリップをセンスして、スリップしないように足首・膝・股関節を動かす、ということをやるべきなのだが、ラムダにはスリップセンサーがないので、計算でやるしかない。

この計算も、姿勢判定に使ったチェックポイントを利用する。手順は以下のように考えている。

仰向けの姿勢がスタート姿勢とし、床面に接触している点がどの点かを調べる。胴体を起こしていくと、接地点がどんどんと移動してきて、座位になった時には上の画像で言うと左側の黄点が接地点となる。この移動の間の股関節座標の軌跡を移行計画に折り込んでやれば良い。

軌道を細かく追うのは面倒で、それほど意味が無い。なので、軌跡を追うことはせず、スタート点での姿勢(仰向け寝)と終着点での姿勢(座位)で足裏部が動かないような姿勢値にすればいいかなと、思っている。

全身の姿勢を表す姿勢値は下半身の姿勢が大勢を決めているので、上半身については考慮が不足気味。上半身を動かすと、その動作による重心点の移動を補正するために下半身も動くのだが、この時の姿勢が座位だと、J2が不安定な姿勢なのでガシャガシャ動くことが多い。 この辺りも整備して、J1Z処理などを折り込む必要があるようだ。

ふぅ。。立って歩かせるくらいだと、逆運動学計算は簡単だが、座ったり寝転んだりと、複雑な動作が入るとなかなか難しいことが多い。根気良く整備していくしかないのだろうが、大変だぁ。

1月14日

昨日はわんだほーロボットカーニバルの見学に行ってきました。 秋葉原で買い物があったので、買い物してから観に行ったのですが、予選2種目めのボトルトラクションがもうすぐ終わるところでした。 結局最後までいて、見学者なのに懇親会にまで参加してきました。 優勝したくままさん、準優勝のイガァさんおめでとうございます。決勝戦の白熱した試合はホントにすばらしかったです!

前回のわんだほーは台風だったので行かなかったのですが、今回初めて観に行って、思ったとおり和気あいあいとした楽しいイベントで、次回はぜひ参加したいなぁと思います。ただ、自律を目指しているラムダに仕込みをしたくないのでどうしたものか。。 次回までに仕込みなしでゲームに参加なんてできるのか?少なくともキューブは自律じゃぁとても無理な競技だし。。 と、思ってたんですが、人形つかいさんと話をしている時、「リモコンじゃなくて、助言を与えるって考えれば。。」っていわれて、ふむ、そういう考え方もあるかなーと思いまして、ちょっと考えてみることにしました。ランブルはまぁ、まぁ、あれですが。(^^ゞ

・・・・・・・・・・・・・・

今日は姿勢移行の続き、仰向け姿勢から座位姿勢(体育座り)への移行生成をがんばってみようと思います。

図は、ラムダの側面を略して書いています。赤い点は姿勢判定を行う時のチェックポイントを示しています。

仰向け姿勢から座位姿勢へ移行する際に、足裏部を動かないように考えると、股関節の軌道は青い線のようになります。これを忠実に計算で出すこともまぁできるのですが、ぐにゃぐにゃの曲線じゃぁないので直線で近似してもいいかなーと言うところ。ということで始点と終点の座標を計算して、移行後の姿勢値に加味します。

実際に動かしてみると、なんていうか、、うまく動く範囲が狭い、開始姿勢の条件が厳しいというのかな。自由な姿勢からいい感じの姿勢へ移行したいのだけど、なかなかいい塩梅になってくれません。 もっと作りこみが必要なようです。 体育座り周辺はなかなか厳しいです。

・・・・・・・・・・・・・・

ここでは姿勢移行について計算ずくでこなそうとしていますが、本来は姿勢移行の際の足の動き方などは各関節の負荷とか足裏のスリップから、全体の動作目的に外れないように関節を追従させるように動き、更にはその動きを学習して、学習データからフィードバック量が少なくなるような関節の制御カーブ(角度とトルクとインピーダンス)を出力するようにすべきなのだが、そういうことするには今のラムダではちょっと難しそう。学習システムも必要だし、まだまだ先かなぁと考えています。 だからと言ってなにもしないのもいやなので、数値的にどのような要素が必要なのかを考えるためにもできるところからやろうとしている、といったところです。

思うと、随分と前から、モーションの生成については考えているのだが、これといった方向付けができないまま今日に至っている。だから進捗がはかばかしくないんだろうな。

立って歩くだけを考えると、各関節の移動範囲や必要な姿勢範囲はある程度の範囲にまとまっているため、計算などで算出した足座標を再生するだけでよかった。 これが、立ち上がりや、しゃがみ込みなどの動作を考えると、途端に可能性と制限が増えてくる。 各部位の干渉や、関節の可動範囲や重心などがあり、更には動作速度が実行可能な範囲なのか、動作によって生じる慣性はどう働くのかなど、簡単な問題から複雑な問題まで幅広く存在する。

これは物理的な問題として捉えれば、動力学シュミレーションなどを行って、適切な動作軌道と動作速度(と動作加速度)を算出する、、ということになる。 でも、それはやりたくないなぁと思っている。 難しいし、時間かかるし、動力学はよく判らないし。。(>_<) なにより人間は繰り返し学習によって最適なモーションを見つけ出して記憶して、それを実行していると思われる。 これと同じこととは無理としても概ね同じ考え方で動作を構築できないかなぁ〜、というのを考えているのだ。

色々な問題のうち、ロール軸消失問題やJ1Z処理などは関節工学の範疇に入るのだろうが、自由度だけで考えると可能な姿勢でも実時間処理では不可能な姿勢などがあり、実運用では排除して考えなければならない姿勢があるということだ。これらは歩く動作の範囲では発生しにくい問題です。

モーション生成エンジンの理想的なイメージというのはおぼろげには有りまして、なんていうのか、、社会システムのような働きで動作を生成させたい。 各部位では目的に対して最適な動きというのがあるのだが、他の部位の要求と綱引きをして、結果的に全体のバランスを重視して、各部位としては不満を持ちながらも全体としては有効に働く、というシステムです。

客観的には最適かもしれないけど、それを導き出したシステムは最適とは判断せずに結論付けるような、もっというと結果的に最適ではなくても構わないような結論を導き出すシステムを考えたいのです。

まー、いまんとこ「たわごと」ですが。(^^ゞ

1月15日

まずは仰向け寝から座位への移行ができるようになったようです。上半身の同期をとるために移動中の姿勢値もキチンと整備しておかなければならなかったのだけど、上半身と下半身の協調ってのをやったのは随分前で、色々忘れてました。

 こんなふうに適当に寝転がってるところで、

 まずは姿勢の整備。足が地面に面するようになって、膝が逆関節になってたのが順関節になってます。

 で、上体を起こす時に、お尻の接地位置にあわせて膝を曲げる。 J1Z処理をやっているので右足はちょっと回転してる感じ。

腕は下半身の動きに合わせて肘が曲がっていますが、これは下半身と上半身を協調動作するようにしているためで、上半身へは明示的な指示は出してません。・・・でも、接地している足に対する手先座標を固定しているはずなのに、見た感じは股関節に対する座標が固定されているように見える。バグかなぁ〜。ちょっと調べてみなければ。

姿勢の整備の段階では上半身は手付かず状態。 座位姿勢の生成に関してもエラー処理を行っていないので、トンでもない寝姿だと、ちゃんと座れません。そのあたりがこれからの作業になるのかな。。

課題を残しつつ、座位から準立位への移行へと先に進めてみたいと思います。

1月16日

昨日は仰向け寝から座位への移行の移行姿勢の生成をやってみたんだけれど、移行姿勢の適正チェックなどはまだやってませんでした。 その辺りについて、どのようなアプローチで考えていくべきかを黙々と考えてました。

昨日の例でいうと、仰向け寝と座位の姿勢の大きな差は胴体のチルト角にあります。とにかく仰向け寝の姿勢値からチルト角を0度にするのだが、その動作の際に発生する接地点の動きに合わせて膝を立てていくという姿勢の動きを生成しました。ですが、仰向け寝の状態で既に立て膝であったり、大の字の姿勢で寝ていたりすると、その変換ルールは通用しません。前述の変換ルールをヨシとしたときに生成した座位姿勢に修正を与えたいのだが、どのような考えの元に修正を加えるのか?理想姿勢があるのなら、その姿勢に移行すりゃいいじゃんということになってしまいます。そのように話を進めていくと、結局は座位に移行する前の仰向け寝は「このような」姿勢でいなければならない、といったことになり、つまりは従来のモーション再生になってしまいます。

ぶっちゃけ、立ち上がり動作をさせるだけなら普通のモーション再生でまったく問題はないのですが、モーションの生成というのは、将来的には’ある状況における「身ごなし」を自律的に生成実行する’という遠大な目標に向かうための検討の一部なのです。

自分の頭の中ではいくつかのキーワードがあり、それらがうまく結びつくようなアプローチはないものかと考えていました。

そのキーワードというのは「逐次的」というものと「計画的」というものです。(このような単語をキーワードとしているのではなく、イメージなんですけど、あえて単語にするとこのようなもの。ボキャブラリーが乏しいのでもっと適切な単語があるかもしれない。)

「逐次的」というのは単純動作のカタマリというのがロボットの制御には必要な考え方だということで、「計画的」というのは3次元空間や時間空間に存在するロボットというのは時間の概念(予見とか予測と言ってもいいのかな)が必要だということ。

これらはつながりが疎な考え方のように思えて、うまくつながらなかったのだけど、今日、ふいになんとなくつながった気がしました。この二つのキーワードをつなぐのは「学習」というファクターです。「逐次的」な行動で得られた結果を「学習」に役立てることで、「計画的」な行動が出来るようになる、といった具合です。 「学習」もロボットにとって重要なファクターなのでこの要素でつながったということはとても気持ちがいいのです。広域的な部分では予見要素を加えつつ、狭域では試行錯誤的動作で必要十分(最適ではない)の微結論を探す。

ある程度は具体的な実装の方向も見えてきているのですが、もうしばらくはこの「ふわふわした」感覚のままで暖めてみたいと思います。早熟なアイディアは早い結末を迎えるというのがオチなので。

・・・・・・・・・・

さて、大枠の方向性も少し見えてきたので、手元の問題を片付けて行きたいと思います。

昨日、おかしいな?と思ったのはバグというか考慮不足で、重心オフセットパラメータを上半身と下半身の連動動作に加味していなかったためのズレでした。 四つん這い動作の時は不要な要素だったので無配慮だったのです。

今日はこの辺りを修正しつつ、新しいアイディアの実装方法の骨子を検討・実験していきたいと思います。

1月17日

姿勢移行の続き。

重心オフセットの考慮を加えて、上半身も思い通りの動きをするようになってきました。 途中、重心補正のパラメータの取り扱いを間違えていて、思い通りの動きとならず随分と悩まされました。立ち上がるまでは重心補正はオフのままでいいってことです。 ただ、重心補正のかかり方が大きすぎたり左右にぶれたりして納得いかないので原因を追究しておく必要があるかも。 潜在バグは早めに叩いておくべきです。

色々と問題を残しつつ、次は座位から準立位への移行を検討します。準立位という位置付けは「四つん這い」といってしまってもいいのだけど、今は「両足で立っているけど、手をつかないと維持できない」状態です。 でも、実はうつ伏せからの立ち上がりでは膝を使った「準立位」を定義せねばならないので先の表現は仰向けからの立ち上がり過程での「準立位」に限ったものとなるのでしょう。

「準立位」状態から重心を支持多角形に入れることで「立位」へと移行します。

下の図はラムダの下半身を略して描いたものです。 ラムダを右側面から見ている図です。 @が座位を表しています。

今、座位から準立位になるということは両手の先を地面につけた状態で、Aのように腰を持ち上げた状態となります。 その後、重心点をずらして行き、Bの状態までもっていけば「立位」への移行もできるということです。

ただ、ラムダの手の長さは、真下に伸ばした時にAの姿勢にギリギリなれるくらいなので、手を着く位置によっては地面に手が届かない場合も出てきそうです。すると、Cのように上体を後にそらしながら、手先を地面につけて重心点をシフトさせなければならないかもしれません。

@→A→B のケースでできれば簡単なのですが、Cのケースを考慮しないわけにはいきません。 考えなければならないことが多そうです。

まずは簡単にABのケースでの立ち上がり移行まで作ってみようと思います。

・・・・・・・・・・

Cのケースになると、各部位間での干渉が問題になってきます。昨日、問題にしていた移行姿勢の適正チェックについても問題の半分は干渉です。干渉についてケース毎に検討するのも面倒っていうかロボット的ではないので、大々的に干渉チェックのしくみを構築しなきゃならないなと思っています。

これは上半身の動作生成には欠かせないと思っていて、腕の軌道生成を行う段階で実装しようと思っていたのですが、下半身についても必要なようです。

ロボットの身体データを簡単なポリゴン集合化して、関節角度を適用した状態で干渉をチェックします。重心計算で近い計算を行っているのでやれば結構すぐにできるんじゃないかと思っているんですが、、、ここでそれに手を出すか。 ここは最低限の機能の実装で終わらせて、ロボビリヤードの早期実現を目指すか、迷うところです。

実は昨日考えていた大枠の方向性の件も、干渉チェックの仕組みが必須で、フレーム毎に干渉チェックをしなければなりません。なので、全ての組み合わせの干渉をチェックするのではなく、動作に応じた最低限のチェックができるような方法を考える必要があります。

1月18日

今日、ラムダロボット研究所のアクセスカウンターが10000を超えました。 訪れる人もまばらなこのHP、10000まで行くのにちょうど1年かかりました。カウンターを設置したのはサーバーを変えてから。調べてみると、サーバーを移転したのは去年の1月22日でした。20000になるのはまた1年くらいかかるのかなー。(^_^;)

今日は、昨日の続きをやろうと思ってたんだけど、実はこの週末に顔の外装を完成させようというひそかな野望がありまして、木型をちょいといじってました。気がつくとこんな時間(合間にゲームやったりしてたせいもあるのだが、現在午前3時半(^_^;) ) あと隙間をパテ埋めしたりしなければならないけど、後頭の木型と顔部分の木型の修正が終わりました。 姿勢移行はまったく手つかずになってしまったが。

 向かって左が後頭、右が顔の木型です

姿勢移行は明日やろう。 

1月19日

ある程度の決めうちでの姿勢移行なら簡単だろうな、 と思っていたのは間違いであった。引き続き苦戦中。

ラムダの足の腕の長さは220ミリ、股関節から肩関節までの寸法は110ミリなので、股関節から下側に腕を110ミリ伸ばすことができる。 なので、大体100ミリ程度、腰を浮かせることができる。手を着く位置が悪いとこの寸法がもうちょっと目減りする。 さらに、仰向け寝の姿勢の時の腕の位置が下の画像のような姿勢ならば、(手先が股関節の辺りより上なら) こんなふうに腰を持ち上げることができる。 手を下に下ろした状態で移行していくと、お尻より手が前になってしまい、後に転んでしまう。

 

腕の長さにも限界があるので、腰を浮かせる寸法を決める必要がある。寸法を決めるには、手を着く位置から逆算すればいいわけだが、今回は、この先の「姿勢を模索する」ための仕組みを考えて、トライしてだめなら寸法を変えて再トライ、というふうにループを回して腰を浮かせる寸法を探すようにしてみた。

そのためには検査をする仕組みが必要で、それを実装するためのプログラムの改造量が大きくなってしまった。 そのためなのかどうか判らないが、妙なバグを抱き込んでしまったようだ。 腕の位置がちょっとでもどうにかなると(傾向がまだわからない)、うつ伏せ寝から座位への移行の際にニョーーーーーっと右か左へずれてしまう。また多分、くだらないバグなんだろうなぁ〜(>_<) いまのところ原因不明。

それはそれとして、仰向け寝の時の腕の位置を限定するわけにはいかないので、座位になってから手を着くプロセスで、お尻を持ち上げる時の重心位置との関係を考えて手を着く位置を決める計算が必要。

明日はバグ取りと、その部分方法の検討とコーディングだな。

この次にはついに立位(で、しゃがんでいる状態)への移行となるのだが、重心を両足の上に持っていく軌道の導出が難しそうなんだよなぁ〜、だいたい、このルートで立ち上がることってできるんかなー(^_^;) エビ反って、膝立ち状態になって、それから立ち上がる方がいいか? 要検討。

1月20日

今日は予定通り頭の外装作りから取り掛かりました。

後頭部の成型テストをやってみましたが、空気漏れがあるのか、失敗。 空気漏れ対策を施して再チャレンジしましたが、ちょっとましになった程度。 失敗です。 原因と対策を考えねばならないので外装作りはここで終わり。 空気漏れ対策をカンペキにすれば改善するのかな、掃除機のパワーが足りないのか。 パワー不足だとちょっと困るな。

 

失敗作をラムダに取り付けてみました。

   散髪失敗して刈り上げ過ぎみたいになっとります。

色も塗って無いからイマイチだけど、カンジはでてます。 いい感じ。 顔面部も後頭部もまだ最終版ではないのだけど、連結部分の長さが足りなくて隙間が開いちゃってます。 ラムダはまだ赤ん坊なので、頭蓋骨がつながってないんですね。これから徐々に伸びて最後にはがっちり連結していくのでしょう。(^^ゞ

・・・・・・・・・・・・・・・

さて、姿勢移行の方ですが、昨日のバグは無事取れました。まぁやはり下らないミスでした。

手を着く位置をどうするかって話でしたが、ちょっと図にしてみました。下の図の左側が各ポイントの位置を示してまして、それを地面に投影したのが右の図です。

重心点ってのが股関節の近くにありまして、これが、両手両足で作る支持多角形に含まれるかどうかを検査して、そうなるように調整します。

本来は重心点が支持多角形に含まれるかどうかを検査するべきなのだけど、今回のケースだと、両手の手先座標の中点をとって、その点と比べて重心点が後にあればダメで、前にあればOKって判定で十分でしょう。

これも大体できてきました。もうちょっと作りこみが必要かなって感じです。 さっさと立位への移行に進まねば。 仰向け寝からの立ち上がりを先にやっているのは簡単だからなのにてこずってます。 この後やる、うつ伏せからの立ち上がりは膝立ちの判定などをせねばならないのでもっと大変になりそうなのに。。 

1月21日

今日は帰るのが遅かったので作業は無し。

ですが、検討はやりました。 準立位から立位への姿勢移行の移行軌道生成方法について。

準立位から立位への移行軌道の生成は先日思いついた「逐次的」と「計画的」云々の構想を部分的に取り入れます。解析的に算出する方法もあるかとは思いますが、構想の実現化に向けての実験も含めていきたいと思います。

準立位は、手を着いて立っている状態です。 立位は両足で立っている状態です。 19日の画像にあるような準立位状態から立位に持ってくるには重心を両足の上に移動させるということです。 ラムダの論理重心点は両股関節の中点です。 実際には姿勢によって重心位置は変わるので、その位置を重心補正値として持っています。

下の図の左上の状態が準立位で、薄く描いた姿勢へ移行したいと思います。薄く書いているのが理想目標姿勢です。

そして、直線軌道で移動を進めていくと、途中で干渉したり、体を支えている手先が浮いてしまったりします。 これらのエラー検出は制御フレーム毎に、移動を実行する前に検査を行います。

エラーが検出されたフレームは修正を加えます。干渉については移動方向を上側に回転させていき、干渉が起こらない移動方向を見つけます。 手先についてはチルト角を調整し、手先を地面に近づけるようにします。この二つのパラメータを徐々に変更し、干渉・腕長さの条件が満たすまで探索します。

この動作を理想重心点が目標位置に到着するまで繰り返します。 理想重心点の目標位置とは「両足の真上」なので、高さは状況によって変わるかもしれません。

結果として、左下のような姿勢になったりします。 今度はこの姿勢での重力補正値を参照し、真の重心点を「両足の真上」に移動させていきます。

足の位置と手が着いている位置は固定という条件を守ったままで移行できるのか? この条件を解除して、手先を滑らせながら重心を移動するという手段も複合的に取り入れるべきか。 探索の結果、1制御フレームでの移動量が大きくなってしまったりしないか? など、検討しなければならない点はまだ沢山残ってます。 あと、まったくもって静的な動作しか扱っておらず、加速度や慣性モーメントなどの物理量は考えていません。 そういう物理量も考慮できればおもしろい動作が生まれそうな気もするのですが。。

うまく軌道が生成できるようなら軌道の最適化(学習)も考えてみたいです。

1月22日

こないだ失敗した後頭部のバキュームに再挑戦。 まだテストなので、数年前に買って放置していたプラバン(黄ばんでる)を使ってテスト。

空気漏れが問題と断定して、徹底的に密封し、プラバンを押し付ける面にスポンジでパッキンまでしてトライ。 その成果もあって、すごい吸引力でプラバンが吸い込まれます。 で、吸い込まれすぎて撓んでしまってまた空気漏れ? 成型具合は対策前よりはよくなったけどやはり失敗です。 特に後側が失敗。 うしろだけでもうまくいけばごまかせたのになぁ。

 

後頭部のトラ刈り部分はそのままでした。(ーー;) 加減が難しいなぁ。 どうやら掃除機の吸引力は十分なようです。木型の形やプラバンの熱し方も影響しているだろうからもう少し研究しなけりゃならないようです。 他の外装部分もバキュームを使うつもりなので精進せねば。

あと、1ミリのプラバンで顔部分を成型してみました。 強度は随分上がって、いいのだけど、しわが入ってしまって失敗。 0.5ミリ素材より1.0ミリ素材の方が熱したらとろけそうになって成型が難しい! やってみなきゃわからないことばっかです。

残りの黄ばみプラバンは、劣化してしまってバキバキに割れてしまいました。 日陰に置いててもダメなのね。(T_T)

・・・・・・・・・

昨日の日誌がONOさんの電脳壁新聞に「準立位から立位への軌道生成」ってことで掲載されました。 すぐ下にもやねさんのもやねのロボット三昧も軌道生成。 同じ軌道生成でもレベルが違い過ぎ(^_^;) コンセプトは違うにしてもちょっと恥ずかしい。。。 

その「準立位から立位への軌道生成」をやらなきゃなぁ・・・、いつまで経ってもロボビリヤードにトライできない。

1月23日

「準立位から立位への軌道生成」のプログラムコーディングを開始しているのだが、いままでの動作の仕組みと随分と違うため、難航中。 せっかくだから「準立位から立位への・・」に限らず一般化したプログラムにしようと考えているのだが、一般化できる概念なのかどうか?

足先や手先の移動、股関節の移動と考えるとパターンとしては干渉をさけた「迂回」とか、干渉する直前まで動作する「限界移動」くらいのパターンかな?と思っているのだが、股関節の移動って足先の移動(ただし両足)と同じだよな?とか、チルトを移行するときには「迂回」なんてできないよな?とか、一般化するにはパターンが多すぎて発散してしまいそう。

あと、手先の件も合わせて考えると実装の方法も随分と変わっちゃうなぁ〜とか、まだまだ迷いも多い。

この仕組みが一般化できると、床にあるものを持ち上げる動作なんかが、ほぼ自動的に生成できることになります。対象物の座標を与えることになるので、位置あわせのためにちまちま動いたりする必要はありません。 更には持ち上げるモノの重さが判れば、持ち上げる時に重心補正計算にモノの重さを加えることで重いものを持っても重心がずれてこけたりしないように、なんてことも可能です。 当面はロボビリヤードで的をポコンと倒す動作に活躍させたいなと。 ・・・楽しみだなぁ〜。 ピンクボールに近づいて、ボールを持ち上げるラムダ (*^_^*) アイボでもボールをけることはできてもボールを持ち上げることは出来なかったから、これができたらラムダはアイボを超えることになる!(ホネを咥えるってのはできたけどね。)

・・・・・・・・・・

もうすぐロボワンのテクニカルカンファレンス。 興味のある講演もあるので聞きに行こうと思っている。懇親会にも参加するつもりなんだけど、石川さんの話だと「自分のロボットを自慢する場」だって (^_^;)  ラムダ持って行ってもいいものなんだろうか? 重装備じゃ話になんないから軽装備で動かせるようにするってのが前提だけど。

1月24日

引き続き「準立位から立位への軌道生成」について。

姿勢値を使ったモーションも、関節角度列を使ったパラメータも、二つの姿勢を示すパラメータの差分を縮めていくということには違いがないのだが、干渉を迂回する軌道を探索しながら移行するという今回のケースは一味違う。

それは姿勢の移行が「何を目的にした」移行なのかを知る必要がある、ということだ。 スタンスを変えることなのか、重心オフセットを変えることなのか、しゃがんでいる状態から立ち上がるため、または立っている状態からしゃがみ込むためなのか、 それがわからなければ干渉に対して迂回に利用するパラメータは何なのか、また迂回する方向を決めることも出来ない。

ざっと検討したところ、以下の3つのパターンが有力

@股関節中心座標の移動(重心点の移動)
A両足の位置関係の移動(スタンスの移動)
B股関節姿勢の移動(上体姿勢の移動)

@〜Bは利用頻度順のつもり。 恐らくBの上体姿勢の移動で自身の干渉を避けるために迂回を行うケースは無いだろう。 @とAを同時に行う場合も考えられないこともないが、それは多分「歩行」などのように十分に管理された動作と思うので、考えなくてよいだろう。

というわけで、移動目標姿勢との姿勢の比較を行い、@のケースなのかAのケースなのか、はたまたBのケースなのかを判断する。

次に、移動面を特定する。3次元空間上の移動なので、正確には三次元空間上の直線が描けて、その直線以外のすべての曲線が「迂回路」となるのだが、そんなのは意味がないので、主だった2軸を選び出し、迂回路はその2軸を持つ平面上での曲線に限定する。

下半身の干渉に対する迂回路は大体見えてきた。次に、手先の座標を維持するための下半身の姿勢生成。

手先座標を維持するために調整すべき下半身姿勢のパラメータは、チルトと高さの2パラメータとなるだろう。左右方向での座標が問題になることは少ないだろうから、まずは前後方向の座標で考えればいいはず。

準立位から立位への移行だとチルトだけの調整となるが、モノを拾う動作だと、チルトと高さの両方を使う。どのケースのどのタイミングでチルトと高さのパラメータを使い分けるのか。 干渉からの迂回で、「高さ」を使ったとすると、手先座標維持のための調整で「高さ」を使ってしまうと打ち消しあってうまくない。そういう状況をどうやって識別するのか?

身体の動作というのは関節の方向や動作域の広さなどで自然と優先順が決まっているのだろうと思う。物理的な制限から優先順が決まれば、J1が不安定になるような姿勢は避けて動くのが自然な振る舞いなのだろう。ロボットの場合は人間のような繊細な関節の情報が得られないのでムリムリにでも思い通りに動かそうとしてしまう。

むずかしいなぁ〜、つい幾何学計算で計算したくなってしまう。

1月26日

やっと休みに突入しました。 休みのうちにやっておきたい事が沢山あるんだけど、さて、いくつできるか。。

バキュームの改善をどうやろうか?パンチングメタルにすれば強度が上がってよさげなんだが、値段がなぁ〜、今更金をかけるのも、、と迷っていたのだが、昨日の出張の帰りに秋葉原、ツクモのロボット王国に寄ったら、アルミのパンチングメタルが売ってました。そういや売ってたなぁ。アルミなので結構安い。800円ちょっと。 これで、掃除機の吸引力に負けてへしゃげることは無いだろう。 念のため側面に空気抜きを空けておいた。吸引力調整用、適宜テープなんかで塞ぐ。 試すのはこれからなので効果の程はまだ不明です。

 

ラムダを家から持ち出すときにできるだけ軽装にしたいってことで、バッテリー充電用の12VのACアダプターを買ってきた。12V4Aで800円。安い。秋月で発見。普通は4Aだと1600円くらいするから半額だ。 1Aじゃ少ないし、4Aは値段が高いし、2Aくらいのはないかなぁ〜と探してたところだったのでうれしい。ただし、ジャックのサイズがチャージャーと合わないので付け替えてます。 電圧を測ると12.2V、ACアダプターって意外と高めの電圧を出してたりするので要注意です。 この電圧ならRPU-100を直接動かせる。ラムダに電源供給するためのケーブルも作っておこうかな。 あとはPCだが、出先でコンパイルをしなけりゃ小さなノートPCでも十分なので、荷物は小さくなったはず。

で、ラムダには取っ手をつけました。 キュリオみたいに取っ手もデザインに組み込みたかったんだけど、諦めた。 しっかし、やっぱり冬に板金加工はできないな。凍え死ぬかと思った。 早く部屋に入りたかったので雑な仕事になってしまった。(>_<)

 


で、肝心の姿勢移行の方は、ベクトルベースでの移行処理までは完成。 股関節の移動、胴体姿勢の変更、軸足を中心とした足先の移動、足先姿勢の変更(左右)という5つの移動ベクトルを、指定の速度で移動させるようにしました。胴体姿勢の変更については、胴体質量による慣性モーメントの影響を考慮して、股関節を軸に、肩関節部分が移動する速度を角速度に変換するようにしました。 次は必要に応じてこのベクトルを回転させて迂回路を発見できるようにします。先に上半身との協調動作をやろうかなー。それができたらボールを拾えるようになる。。 ちょっとよこしまな気持ちになってます。 迂回路関連の、ベクトルの回転と干渉チェックは、今回は「準立位から立位への移行」専用に作ります。汎用化するいい手段が思い浮かばないのと、他への適用がしばらく必要なさそうだってことで容易に実装できる手段にしておきます。

1月27日

とうとう休みも終わり、思ったほど予定をこなせなかった。

姿勢移行は、ベクトルベースでの移行処理にJ1Z処理を加えました。

J1Z処理は股関節の左右軸(J1関節)を0度にして、足先のロール角を変えることで足先座標だけを帳尻を合わせるという処理で、J1関節の角度を0度に決めうちすることで、J1関節の不安定な領域を安定させるという処理です。

これは股関節の前後軸(J2関節)が胴体に対して垂直な角度になった場合にJ1関節角度が急峻に変化する問題を回避するものです。 スタンスが股関節間隔に対して差が小さい程、J1の変化は急峻になり、その角度範囲は狭まります。

つまり、モノを拾うとか準立位から立位への姿勢移行とかは腰が曲がった姿勢が多いのでJ1Z処理は必須。 ただ、J1が不安定になってから処理を入れたのでは遅いのでどのようなタイミングで処理を挿入するかを考えねばなりません。

迂回とか、手先座標への協調とか、計画を立てられない動作をするのがベクトルベースでの移行処理なので、全体の動きの流れを見てどの辺りにJ1Z処理を挿入するか、といったコトは出来ない。 更に、重心補正を考慮するともっと複雑なことになってしまう。

J1Z処理をした後に重心補正を加えると、その差分のせいでJ1が不安定になってしまう。 なので、重心補正を加えた姿勢に対してJ1Z処理を行わなければならない。 だが、姿勢に重心補正が入ってしまうとちょっとやっかいなことが起こってしまう。この姿勢移行処理は移行ルートが決まっていないので、移行の終了判定は、目的の姿勢になったかどうかで判定している。そのターゲット姿勢には重心補正は入っていないので、姿勢移行の終了判定ができなくなってしまうのだ。

一応は動くようにしたのだが、目標の姿勢によってはうまく動かないんじゃないかと思う。もう一工夫いりそうな感じ。 目標姿勢に重力補正値を入れ込んでしまえばいいのだが、重力補正値は真値ではなく近似値を計算するようにしているので、事前に計算しても数値が合わないのだ。 その辺を見直す必要があるかもしれない。

この休みで、手先座標への協調動作か、迂回動作までコーディングするつもりだったのにできなかった。(>_<) あと、仰向けからの立ち上がりができたとしてもうつ伏せからの立ち上がりはまだまだかかりそうなので、モーションを作って練習会とかでデモれるようにしたかったのだが、それも未着手。 なかなかなか思い通りにいかないもんです。

1月30日

J1Z処理の挿入方法についてはスマートな挿入方法を考えて試してみたが、イマイチうまく行かない。 今後の課題ということで先に進むことにした。

J1Z処理の適用範囲をJ2関節角度がπ±0.2radian と設定しているが、もう少し広めがよさそう。このJ1不安定範囲はスタンスが狭いほど狭く、変化が急峻になる。 ある程度の速度で動かしても不都合が起こらない範囲を調整しなければならない。

ラムダ動作セットの軽装化の一環で、ラムダのプログラムの各種設定値を外部設定ファイルで設定できるようにした。 簡単な設定変更ならソースファイルとコンパイラがなくてもテキストエディタとFTPがあれば簡単に設定変更できるようにしました。 今後の設定パラメータは出来るだけ外部の設定ファイルから指定するようにすればいつか役立つこともあるだろう。

とりあえずの設定パラメータとしては、 カメラのONOFF 転倒受身のONOFF 転倒判定パラメータ各種 転倒時の発動モーション番号 なんかを設定できるようにしておいた。

テクニカルカンファレンスまでにそこそこ動かせるようにして、一応はラムダも持っていきたいな〜と。 それまでにボール拾えるようにしたいなぁ。

このページの先頭へ