東京工業大学 ロボット技術研究会

東京工業大学の公認サークル「ロボット技術研究会」のブログです。 当サークルの日々の活動の様子を皆さんにお伝えしていきます。たくさんの人に気軽に読んでもらえると嬉しいです。
新歓特設ページ        ロボット技術研究会 HP        ロボット技術研究会 twitter公式アカウント

2015年05月

「ロボット技術研究会」通称「ロ技研」は、その名前の通りロボットの制作や研究はもとより、電子工作や機械工作、プログラミングなどの幅広い分野にわたるものつくり活動を行っています。

カテゴリ一覧: loading

第7回rogyゼミ

5月9日に第7回rogyゼミが開催されました(前回までの様子)。

今回のコンセプトは新歓ゼミでした。発表人数17+1+1=19人、 一人当たりの発表時間10分で研究報告会相当の長丁場になったものの、新歓ゼミということもあって内容はゆるふわさがありました。

なお、今回のrogyゼミでは、株式会社SEプラスの広瀬様が以下のイベントの紹介のためにいらっしゃいました。
[勉強会]
・リーダブルコード勉強会(6/6開催) 
・GitHub勉強会(6/20開催)
・OSS Hack 4 Beginners(6/27開催)

[開発イベント]
・OSS Hack Weekend (7/11-12 2days開催) 

そしてなんと、ピザの提供もしていただきました。ありがとうございました!


以下、発表者および発表タイトルです(発表順) 。

1.アカテツ科  Boids
 
2.塩谷 凛     パズルアクションゲームつくってみた
 
3.ymduu   グローバル理工兄弟 and Tech chan(制作物報告)


4.たくあん   春休みでできる!? 二足歩行ロボット 

5.さはら   距離関数の当たり判定への応用

6.おーま     (希望により非公開)
 
7.有塩   マイコンでもできる画面出力・Qtでつくるゲームクライアント
 
9.みかん  自作ペンライトの機械的構造と今後の展望 

10.カイヤン   別に、ツールを使ってしまっても、構わんのだろう? 
11.マハト   RPG王国について及び技名の付け方
12.Linea  Unityは神、Unrealは現実

12.井土  球乗りロボットプロジェクトと制御工学
 
14.したろう  幸福の物理で行う予定の実験・シミュレータの紹介

15.ところ  小さくて賢いロボット マイクロマウスを作ろう!
 

16.ニックさん  貴方が今すぐすずかけ台に来るべき100の理由 
17.ymt  ダンサー衣装へのドットマトリックスLED装着 
 
18.徳久文彬 AI研の活動と趣味の話

最後は株式会社SEプラスの広瀬様によるイベント紹介でした。

(内部向け:スライド・画像を更に公開したい場合はご自分でブログを編集して追記していってください) 

文責:カイヤン 

軌道予測の補足資料:ベイズフィルタについて

軌道予測の補足資料:ベイズフィルタについて


あってぃ(@paste_link)です。
このページは「
東工大Maquinista、ロボミントンの自動化とシャトルの軌道予測について」の補足資料です。あれな資料ですが興味のある方はお読みください。尚、説明に具体的な数式は出さないので、完全に理解したい方は個別に検索や書籍などで探していただくと良いかもしれません。


今年、シャトルの軌道予測で実装しましたパーティクルフィルタはベイズフィルタという理論?を応用したアルゴリズムの1つです。


この理論の根底に存在するのは統計学で用いられる、条件付き確率で授業で学ぶ、『Bayesの定理』と呼ばれる数式です。 

 IMG_20150507_010417

部屋着です。写真はぼくです。

この式そのものについての説明は割愛しますが、この定理はAを「知りたい値」、BをAを知るための手がかり」とおくことで、専ら「誤差のある計測の推定」に用いられます。 

例えば、(A,B)(ロボットの位置,センサの値)だったり、(シャトルの位置,Kinectから得たシャトルの座標)などです。大体の場合はBはセンサの値だと思います。

 

 短くまとめてしまうと、『ちょっと前のロボットの位置(計測ミスで微妙にずれてるかもしれない)とセンサーの値(計測ミスで微妙にずれてるかもしれない)から誤差を少しでも取り除いて今の位置を推定する式』です。

 

これらの理論の特徴は、ロボットの位置などのそれぞれの値を「確率分布」として捉えることです。

例えば、ロボットに「今のきみの位置(A)を教えて」と聞いたときに、同じ「0です」という答えが返ってくる場合にも、下図のようにAを分布として捉えると、同じ「0です」という答えにも様々なパターンが考えられます。

 pic8

赤線のような場合だと「自分の座標は強いて言うなら0かなぁ……」程度のニュアンスな一方で、青線の場合だと「高確率で0だ!!」という雰囲気になります。

これらはそれ以降のセンサによって得られた値(B)に対する影響を大きく変化させます。

ロボットが「自分の座標は強いて言うなら0かなぁ……」と考えている状態でセンサが「今の位置は20です」と出力したとき、このシステムは「じゃあ自分の位置は10くらいなのかもしれない……」と大きめに自分の位置を考え直します。一方で、ロボットが自分の位置を「高確率で0だ!!」と考えていれば、同じようにセンサが20という出力をしたときに「これはセンサのミスか何かだ!……でも念のため自分の位置は4くらいだと少し考えなおそう……」というような反応をするわけです。

 

また、Aの分布が赤線のような状態だったとしても、そのあとにセンサから何度も「今の位置は0です」という値を得た場合は、時間とともに「自分の位置、結構0なんじゃないか…?」「恐らく0だな…」「高確率で0だ!!」というように確率分布がシャープな形に遷移していきます。

 pic10

さて、ベイズフィルタの考え方を説明するために、簡単な例を考えます。

下図のようにロボットが直線上を移動する場合を考えます。図は雑です。許して。

 pic7

マシンにはセンサがついており、どの程度移動したのかを『大体』知ることができます。

センサの値を利用してロボットのできるだけ正確な位置を知りたいとき、Aを「ロボットの位置」、Bを「センサの値」として、ベイズフィルタを行ってみます。

①まず、人間がマシンを位置0に設置したとします。このとき、人間が微妙に位置をずらして設置してしまったりする可能性が存在します。そのため、ロボットの初期位置は大体下図のような確率分布で表すことができそうです。

pic1

②ここで、仮にロボットに「20まで動け」と指令を出したとします。そうしてロボットが移動したとします。このとき、もしかしたらタイヤが滑って20進めなかったかもしれませんし、ブレーキが弱くて20よりも大きく進んでしまったかもしれません。この時に、ロボットの位置の確率分布は下図の赤線のように変化します。動いた分だけ、自分の位置に対する「不確かさ」が上がっているため、青線よりも横に広がり気味な分布になります。

これが、Bayesの定理の式 $P(A|B)=\frac{P(B|A) P(A)}{P(B)}$ におけるP(A)に該当します。イメージとしては「センサの値を得る前の座標の予想」で、これを事前分布と呼びます。

pic2


③ここで、センサの値が「自分の位置は15でした」と出力したとします(B)。でも、この値は『本当はロボットは20の位置にしっかりいるのにセンサが不調で15とズレた値を返してしまった』、『ロボットが17の位置にいて、センサも少しずれてしまったせいで15という値が得られた』などの様々な可能性があります。これらの可能性を総合していくことで、下図の緑線のような「予想していた自分の位置と、センサーの値を総合して得られた自分の位置の分布」が完成します。これが $P(A|B)=\frac{P(B|A) P(A)}{P(B)}$ における「センサBの値15が得られた上での位置Aの分布P(A|B)」であり、事後分布と言います。Bayesの定理の左辺に相当します。

 pic3

注意すべきなのは、センサの出力(B)も確率分布である、ということです。センサに「今の位置を教えて!」と聞き、15だという返事が帰ってくる場合にも、下図の青のように「高確率で15!!」という場合や赤のように「一番可能性が高いのは15だけど……違う可能性も高いかなぁ」という場合などがあります。

もしBの分布が下図青線のような形だったら、事後分布(2つ上の図の緑線)はセンサの値を信用してより15という値に近づくでしょうし、Bが下図赤線のような分布だったらシステムはセンサの値をあまり信用せず、事後分布(上図の緑線)は事前分布に近い位置に来ることになります。
pic9
 

カルマンフィルタやパーティクルフィルタを実装する際には、センサの特性を基に、Bの分布の形状を正しく決定することが肝要です。

 

④最後に、この状態からロボットに「-5へ動け」と指令を出し、センサの値「-8」が得られたとすると、初期状態の分布は③の過程における自分の最終位置の予想の分布と全く等しいものになります(下図の青線)。事前分布(センサの値を得る前「自分は-5まで動いたつもりだからこの辺にいるはず!」という予想)が赤線のような-5を中心とした分布に、そして事後分布は事前分布からやや-8側に寄ったグラフになります。

 pic6

このように、ベイズフィルタは

    初期状態

    初期状態を基に次の状態を予想(事前分布)

    センサから得られた値とセンサ自信の特性(どの程度信頼できるか)、事前分布の3つを考慮して実際の位置を計算(事後分布)

    事後分布は次の初期状態になる

というサイクルの繰り返しとなります。

ちなみに、初期状態、事前分布、センサの特性などのすべての分布を正規分布と仮定した特殊な場合がカルマンフィルタです。上の例の場合も全て正規分布なのでカルマンフィルタです。この場合は正規分布の遷移していく様子の式が現代制御論における状態方程式とマッチするため制御理論的なアプローチと交ざりあうという非常に面白い事実があります(と認識しているのですが制御屋さんの各位、如何でしょうか…?(ゆるして(命だけは)))

また、Bayesの定理の更新式 $P(A|B)=\frac{P(B|A) P(A)}{P(B)}$ においてP(A)が事前分布、P(A|B)が事後分布だと説明しましたが、残る2変数について厳密ではない補足をしておくと、P(B|A)は「センサは『もしかしたら16かもしれない』って言ってるけど、じゃあロボットの座標18ってどれくらい妥当よ?」というニュアンスの値で、尤度(ゆうど)と言います。尤度の「尤」は「尤も(もっとも)」という熟語が表すように、「センサの値を踏まえて、座標が○○であることはどれくらいもっともらしいか」という指標となります。この数字が大きいほど『センサから見て』それっぽい値だったということになります。

P(B)についてですが、これは「左辺を正規化するためのつじつま合わせ」と思ってくれればいいです。左辺P(A|B)は確率密度関数であるため、全域で積分すると1にならなくてはならず、そのための定数がP(B)です。正直あまり重要じゃない気がします。

補足資料以上です。 

東工大Maquinista、ロボミントンの自動化とシャトルの軌道予測について

ごきげんよう。2013年度入学の制御班の鈴木です。大学ロボコンやってる人です。

さて大学ロボコンなのですが、今年のルールはロボミントンというものでした。ルールは非常に非情にシンプルで、

「各チームが2台のロボットを持ち込み、バドミントンのダブルスの試合をしろ」

という無茶振りルールでした。

尚、ロボット2台は両方手動でも自動でも構いません。今まで毎年必ず自動機があった大学ロボコンにしては珍しいですよね。

さて、このロボミントンというやつ、ルール自体は みょー↑にシンプルですが、簡単かといわれるとそうでもなく、一言で表すと
 

研究でやれ!!!!!!!!!
 

って感じでした。

バドミントンを行うロボットについての先行研究はルール発表時にすでに存在していたのですが、(動画: https://www.youtube.com/watch?v=LSax71cn6A4)
この研究の論文(http://www.fmtc.be/downloads/Modeling&Control/BadmintonRobot-MultidisciplinaryTestCase.pdf)の1ページ目の右下あたりの文章を引用・TOEIC500点代前半という圧倒的英語力にて和訳させていただきます。

“The mechanical design of the robot was challenging due to the extremely high acceleration and velocity requirements. The current configuration is the initial design of a multiyear project. Several alternative mechanical configurations were analyzed during the concept phase. This included wheeled robot with omni-wheels and wheel-chair type robots. Some of them were rejected, some of them may be implemented later. The main reason for discarding such options were the very high accelerations and velocities required in the badminton play, which are impossible to achieve in the wheeled robots due to the physical limitations on the wheel traction.”

――最初はタイヤを使ったバドミントンロボットという案が出たが、それは却下された。タイヤを使ったロボットで、バドミントンで要求されるような高加速度・高速度を実現することは”Impossible”だからだ(読めない単語多いけど多分こんなん)。

impossible

音節im • pos • si • ble発音impɑ'səbl | -pɔ's-

impossibles (複数形)

[]

1 〈物・事が〉不可能な,無理な

2 〈物・事が〉とてもありえない,信じがたい

3 ((略式))〈人・物・状況などが〉耐えられない,がまんできない,どうしようもない,手に負えない;いやな

━━[]((the ))不可能(なこと)

というわけでロボミントンは、いんぽっしぶる?ですよろしく。


ところで、うちのチームはルール発表から1か月くらいの間、自動化はつらそうだから手動機で行こう!という方針で行こうと思っていました。
さて、下の画像はぼくが
ロボミントンのシミュレートをするために今年の大会のフィールドの設計図を正確に再現したものです。


a2

コートにある白い大きな円柱形が今年のウチのマシン(の大体のサイズ)、そして円柱形の上に微妙に浮いている謎の物体がラケットの当たり判定の大きさです。

人はフィールドの緑色・黄色の部分には入れません。フィールド外の灰色のエリアから操縦します。


というわけで視点を灰色エリアの後ろ側からで、どんな感じになるのか、実際にシミュレーションで試してみることにしました。あと
地味ですがこれもご了承ください。

※シャトルの軌跡は実際に計測したものを利用しているので速度や軌跡の形状は割と正確です。

……お分かりいただけたでしょうか。

ロボミントンとは、

  1. 奥行き方向がほっとんどわからない地点から
  2. 浮遊時間が1秒強くらいしかないシャトルに向かって
  3. 慣性が働き急加速・急停止が難しいタイヤ駆動ロボットを
  4. 数センチ以内の精度で正確に移動させる

そんな夢とロマンがいっぱいに詰まった全アジア圏を震撼させるサイバーパンクネオロボットスポーツなのだ!!実際難しい!急ブレーキでマシンが激しく上下に動く!!!ほとんど違法行為!!


と、ここまでを踏まえてです。
 

ぼくたちのチームは練習場所は12週間に1度、3時間程度体育館が取れるだけでした。他の練習場所を探すも天井の高さは3.5m程度しかなく、レシーブを行っても天井に当たる始末。しかも肝心の二次ビデオ審査2週間前になると卒業式・入学式でその体育館も使うことができなくなってしまいます。

恐らく練習時間・操縦技術で他校に勝つことはできないでしょう。
 

そこでぼくらが勝つために手を出す手段と言ったらもう……

 

 

 

 







 


というわけで改めてこんにちは。東工大ロボット技研、NHK学生ロボコンチームMaquinista制御班長を担当しました鈴木です。学生ロボコン2015、「ロボミントン」ではシャトル認識・軌道予測システム担当と、試合時での自動機のコントローラ握る担当でした。ぼくの今年における仕事は、ロボットには脇目もふれず軌道予測を完成させることでした。

 

さて、結果から言ってしまうと、ぼくたちMaquinistaは二次ビデオ審査で落選しました。

そして先日、5/5東京農工大学さん、電気通信大学さん、横浜国立大学さんとの交流試合を終え、ぼくたちのロボミントンは終了しました。

 

そのため、一足先に行ってきたことのアウトプットを行っておきたいと思います。

 

ここから話していく内容は恐らく長くて本当につまらない遺言です。また、実用的かも怪しい上に恐らく大学ロボコンで同様のことをさせられる日は来ないでしょうので、価値は低いと思います。また、研究でもなんでもないので既存手法との精度比較の類を真っ当に行っていないため、標準偏差が〇〇パーセント改善された、などの具体的数値を持ち出した説明ができません。それに正直なところ今からそれらの比較を行うモチベーションもありません。論理的妥当性などについてはそこそこは検証したつもりですがツッコミどころは多いかもしれません。以上の点、ご了承ください。

以下、読み飛ばしを推奨する部分は灰水色の蛍光を行います。全部読んでもアレなので適宜読み飛ばしてください。この記事の最後に動画置いてあるのでそこだけ見れば十分かもしれません。



コンセプト
 

ぼくが携わったマシンは下のマシンです(写真は3月中旬くらいのもの。最近写真撮ってませんでした。。。)。正式名称は「黒鷹(コクヨウ)」でしたが通称は「黒」だったり色々でした。適当に呼んでやってください。

 kokuyou

コンセプトは『低重心・高速度・高精度な自動機』でした。

今年はルールとしてフィールド外にカメラを設置することが許可されていたため

フィールド外に設置したカメラが落下地点を演算→自動ロボットが地点まで移動

というシンプルな流れを目標にしました。

また、実際の大会ではロボット・そしてカメラのセッティングはすべて1分以内に終えなければなりません。そのため、フィールド外にカメラを置くとしても、正確に位置合わせを行わなくてもよいようにするため、以下のようなシステムを選択しました。

pic222
カメラ台は高さ2m程度、そして「目印」としての半径200mm300mm円柱形2つが固定された1つのモジュールです。この台をフィールド外のテキトーな場所に置くことで、ロボットはシャトルの落下地点に自動で移動することができるようになります。設置精度を一切要求していないのがポイントです。

カメラがロボットに送るシャトルの落下地点の座標系は「カメラ台からの相対座標」とし、ロボットはカメラ台に取り付けられた目印を測域センサで観測、与えられた相対座標に移動します。

このシステムのメリットとしては、NHK側が用意したフィールドのものを一切目印にしないため、大会会場でも普段の練習でも同じコンディションで行うことができることが挙げられます。

デメリットとしては測域センサが観測できる目印の点数がさして多くないため、得られる座標の分散が大きくなることが危惧されたことです。結果としては測域センサ担当者やロボットの自動走行担当者の努力もあり、今回の使用の範囲内では問題にはなりませんでした。 

 シャトル認識デバイス

シャトル認識デバイスの選定

シャトル認識に用いるデバイスとして、2014年夏に発売された、マイクロソフト社のKinectV2を採用しました。

他にもXtion、初代Kinectなどの選択肢はありましたが、KinectV2はIRレーザの出力がUSBバスからではなく外部電源から供給される(らしい)ためより外乱性能が高いこと、そして他校が同様にKinectなどのIRアクティブカメラを用いた際にもパルス変調ToFを用いている(らしい)ため干渉への対策も十分になされていたこと、一般にIRアクティブカメラは黒い物体を認識するのが苦手な一方で白い物体の認識が得意であり、白色の飛翔体たるシャトルを認識する必要のあるロボミントンに適していたこと、視野角としてもぼくたちが手に入る値段の距離カメラの中ではもっとも広かったことなどが挙げられます。

他の選択肢として高フレームレートを出すことができ、より遠距離の観測が理論上可能であるステレオカメラなどを考えましたが、大会会場は背景が不確定である上にステレオマッチング・キャリブレーションを行うソフト的・ハード的な負担、そして資金的な事情なども考慮して却下としました。

以下の写真は同じ場所に設置した初代KinectKinectV2で天井から吊るされたシャトルを観測したものです。

BlogPaint
↑部屋にシャトルを吊るし、

kinect12
↑Kinect、KinectV2で観測します。
kinect1view
↑初代Kinect
kinect2view
↑KinectV2
 

早い話、KinectV2の方が認識精度が良かったです。初代Kinect4m先のシャトルを観測するのが限界でしたが、KinectV26m先のシャトルの認識が可能でした(シャトルはどちらも静止している物で観測を行いました)

KinectV26m先のシャトルを認識した場合の、このカメラ台でシャトルを認識できる範囲は理想的に下図のようになります(フィールドを真上から見た図です。四角形の板がフィールド全体、四角錐ふたつの和集合が2つのKinectV2を合わせた認識範囲に該当します)

視野の範囲からして相手のサービスなどもある程度は観測できることがロボミントンやってる人には分かっていただけるかもしれません。 

field0307_3

・KinectV2の誤差について  

 次に、KinectV2の距離における分散特性の実験的計測を行いました。

単純に部屋の端にKinectV2を置き、視界中心付近に置いた物体を100mmおきに1000点ずつ観測し、分散・分布を計測しました。

それによって得られた分布は以下のようになりました。

graph1_1025

目盛り振ってなくてごめんなさい。。。

1000~6000の軸がKinectV2からの距離(mm)

100~300の軸は1000点観測した中の点数(個)

そして-20~20の軸は平均値からの誤差(mm)でした。

この分布を真上から見たものが以下になります。

graph2_1025


また、KinectV2からの距離と分散の関係は以下のようになりました。 

 var_1025

結果としては視界中心付近にある限り、

正規分布に十分近似できる分布が得られる

②距離に拘わらず誤差は非常に小さく、標準偏差σは悪くても5mm程度である

ことが分かりました。6m先の物体を標準偏差5mm以下の精度で観測というのはあまりにも革新的なセンサーですよね。しかも20k程度で購買することができます。

さて、今の計測では「視界中心における」分布を見ましたが、次は距離ではなく、視界のどのあたりを見ているかでどの程度 分散特性が変化を調べるために、KinectV2には3.2mほど離れた壁をただただ眺めてもらったのですが……

wall1

wall2

B65YDamCEAAglWb

ということで今のは見なかったことにしました。

以下、KinectV2は、見ている点(x,y,z)に依らず、i.i.dな正規分布N(0,σ²)のノイズが乗るセンサであると仮定します。オフセットについてはKinect表面から15mm程度内側の点から見ているという方針にしました。また、任意の点についてi.i.d.かつ正規分布と仮定したのは前述のグラフの結果に対する近似というニュアンスのほか、今後の過程で最尤推定を行う都合などがあります。標準偏差は具体的な値を設定する必要が最後までなかったです。



・KinectV2の歪み補正について

下の画像はKinectV2で黒板を見たときの距離画像です。白線はエッジです。

kokuban1102

このようにKinectV2から得られる画像は視野の中心から離れるほど歪む傾向がありました。そのため、これに無理矢理補正を掛けました。

これは非線形なタイプの歪みなので、中心ピクセルからの距離の二乗、r²についての関数(a+b*r²+c* r⁴+d*r⁶|a,b,c,dは定数)で強引に補正を掛けました。この補正によって点群を3次元に変換する際の誤差を少しマシにできる気がしたのですが、具体的にどの程度マシになったのかまでは調べていません。しかし、視界に映る直線は曲がることなく座標変換できるようになりました。

シャトル認識

・シャトルの認識アルゴリズム

シャトル認識自体は非常にテキトーに実装しました。どれくらいテキトーかといいますと、昔作りました「部室人多いbotのソースをコピペして一部の定数を少し書き換えて「Kinectの視界に映る半径70mmの球体よりも小さいくらいのサイズの物体を抽出ーー!!」みたいなノリで実装したら完了しましたし、人などが写っていてもシャトルだけを十分に認識することができました。所要時間30分。下はとりあえず物体のクラスタリングの参考画像です。なんというか、これで察してください。

search

これだけで済めばなにもかもめでたしめでたし……だったのですが、ウチのKinectV2の設置位置から相手のサービスを観測するためには約5500mm程度先のシャトルを認識する必要がありました。すると、さまざまな外乱と戦わなければなりませんでした。下図は6m程度先のシャトルや人間を見ているときのスクショです。

recg


ノイズと戦おうにも、シャトルが遠くに離れてしまうとシャトルとして観測できる点も多くて1枚の画像あたりで10数ピクセル程度なのでパターンマッチングなどの類はとてもできるものではありません。つーかパターンマッチング実装めんどいし。

そこで行ったのが、時系列データの処理です。各時間 t₁ , t₂ …… tn の点での「シャトルくらいの大きさの浮遊物体の座標」を全て保存しておき、t=nでの観測が得られた時はt=n-5,n-4,……,nでのすべてのシャトルっぽい大きさの物体の群から「シャトルっぽい動きをしている点列」が見つかれば、それを軌跡とする。という感じです。例えば、「軌跡を真上から見たときにちゃんと直線状の形になっているか?(地面への写像を行った平面上の点列に対して主成分分析を用いて分散から切る)」、「各時系列における速度ベクトルの大きさ・角度の変化量が適切か」などの数多くのフィルタリングをハードコーディングすることで実装しています。ちなみにこれでもノイズは乗ってきます。

だた

この認識方法における利点は、有名な画像処理でのノイズ除去アルゴリズム、「収縮→膨張」を用いないために処理がやや早い上により遠くのシャトルを収縮で潰すことなく認識できる点などがある一方で、シャトルの認識に6点以上前の時系列データをシャトルの軌跡の初期認識に用いるため、シャトルの発見に200ms程度の時間が必要になってしまうことなどが挙げられます(KinectV230fps)。後述しますがシャトルの認識が遅れてしまうのはロボットの自動化において致命傷の可能性があります。
 


3.2.認識したシャトルの三次元座標変換について
シャトルを認識したら、KinectV2から見えたシャトルの点群の重心らしき位置の点を『シャトルの位置』とします。先述の正規分布の仮定を基にここで観測誤差を少しでも小さくできないかなと考えたこともあるのですが、大数の法則やら最尤推定やらのテンプレ計算を経た結果、単純に得られた点の重心を取ればさそうだという結論に至ったので単純に重心とりました。統計は結局最後には数の暴力ですね(?

・シャトルの軌道予測について
・概要

本編です。闇です。まずは下の画像をご覧ください。

02

画像は(http://www.siip.city.sendai.jp/n/2012/1023/01.html)さまから引用・加工させていただきました。

シャトルの動きはとても放物線と呼べる形をしておりません。そのため、シャトルの軌道を予測したいならば、物理学的なアプローチが必要となります。

まず、シャトルにかかる力は以下の2つが支配的です。

・重力

・空気抵抗

空気抵抗はシャトルの進行方向と真逆に以下の大きさの力が働きます。

$D=\frac{1}{2} \rho V^2 S C_D$

ρは流体の密度、Vはシャトルの速度、Sはシャトルの代表面積、 $ C_D $ はシャトルのレイノルズ数などによって決定される抗力係数らしいですが、ぼくは情報工学科なのでその辺よくわかりません。重要なのは、$\frac{1}{2} \rho S C_D$ を定数cと近似すると、シャトルの軌跡は定数cに依存するシャトルの速度Vの関数で表せますので、適当にシャトルの軌跡に当てはまるようにcを変えてみると、こんな感じになりました。

無fadsfaf題
無ふぁdsfdf題




見た感じ、大体合います(赤が予測軌道、黒がKinectV2で観測した実際の軌跡)。尚、物理モデルの数値計算には4次のRunge-Kutta法を用いました。

しかし、この一変数のモデルだと、シャトルの軌跡と完全一致させることはできません、例えば先ほどの図のように大体合ってそうなパラメータでもシャトルの上昇中のデータに適用すると、下のようになります。

shuttle12312
shuttlepoyo

この原因として考えられるものとして、「シャトルの回転によって生じる揚力の類」などが働いているのではないかと考えていますが、これはKinectV2で観測できるものではありません。

また、Kinect30fpsでしか距離画像の取得ができません。

例えば、下図の場合を考えてみてください。これもKinectV2で実際に認識したシャトルの軌跡の平面データです。
recg3

さて、赤い矢印でさされた点での速度はどう推定するのが妥当でしょうか?一個前の点と直線を結ぶ場合、一個後の点と直線を結ぶ場合、など、様々な可能性があってしまい、速度推定が難しいですよね?

ここで速度ベクトルの方向や大きさを間違えてしまうと、予測落下地点は大きくズレます。
 

もしこれが90fpsで観測したデータならば、理想的にこんな感じになり、速度推定が行いやすくなり、精度も上がるはずです。

recg4

また、フレームレートが上がり観測する点の数が増えれば、多少観測誤差があってもローパスなどを通すことで恐らく十分に対応できます。実際に先述した先行研究では100fpsのステレオカメラを用いていました。

このように、フレームレートが低いということは、より少ない情報から正しい値を推測する必要が出てくるために、数多くの闇を伴います。

観測のノイズを対処しながら適切に速度や回転の状態を推定、軌道を予測する手段としてカルマンフィルタや拡張カルマンフィルタ、アンセンテッドカルマンフィルタなどの非線形カルマンフィルタの類が挙げられるますが、学部2年にして情報工学科だった当時のぼくにはカルマンフィルタを理解するだけの力が足りませんでした。ゆえに、11月のぼくは物理モデルを用いた軌道予測については、撤退を余儀なくされました。

・軌跡データを用いた軌道予測

非線形項が渦巻きシャトルのパラメータが、そして数式さえ分からない状態でも、まだ戦う手段はあります。

なぜなら、手元に軌道を予測したい物体そのものと、それを観測する装置があるのですから。(あとついでにそのシステムはカオス力学系でもないのですから。)

数式が分からないなら、数式を一切使わなければいい!

ここで提唱するのは、物理モデルを使わない軌道予測へのアプローチです。
要約すると、軌跡のデータを大量に憶えておき、予測したいデータを受け取ったら、それに近い軌跡を大量に思い出すことで軌道を予測する、という手法です。

 

こんな感じ

①入力 

 mvTemp1
②データベースからの検索
mvTemp2

③出力
mvTemp3

これを実現するために『パーティクルフィルタ』という理論を利用します。別名『粒子フィルタ』です。

パーティクルフィルタはベイズフィルタと呼ばれるデジタルフィルタの一種で、ノイズが乗った計測値から「本当の値」を推定する手段の一種です。ベイズフィルタの派生としては、先述したカルマンフィルタなどが挙げられます。

ベイズフィルタについてもここで説明しようと思ったのですが、説明のしにくさとぼくの説明技術の低さが合わさって最強になってしまったので別のページに資料書きました。こちら
にお願いします。

 

・パーティクルフィルタと軌道予測

シャトルの軌道予測では、ベイズフィルタを応用した、改造パーティクルフィルタを用いました。文字で説明するよりはマシだと思うので図で説明します。下図をどうぞ。
 test1

まず、フィールド横に置かれたKinectV2に接続されたPCから、シャトルの座標がUDP/IPを用いて軌道予測用PCに送られます。

軌道予測用PCには700個程度のシャトルの二次元(横×高さ)の軌跡データが保存されています。計測されたシャトルを二次元に変換するための手段としては主成分分析を利用しました

ここで、例えば下図のようにt=0,t=1の二点のシャトルの座標を取得したとします。test2

得られた速度ベクトルに近いベクトルをデータベースから検索します。赤い丸に囲まれたカラフルな丸がそれに該当し、これらの点の11つを「パーティクル」と呼びます。パーティクルフィルタと呼ばれる所以ですね。これが先ほどのベイズフィルタにおける「初期状態」に該当します。

このとき、なるべく正規分布状になるように抽出を行います。

抽出に正規分布を選んだ理由としては、正規分布を選択しない理由がない、という程度のものです。最も有名かつ対称性のある変数の少ないパラメトリックな分布であり、かつ正規分布自身が自然な共役事前分布であるため扱いやすいという理論的裏付けがあるので想定外の事態が起こりにくいと考えました。

 

次に、それぞれのパーティクルを『次の時刻の点』に進めます。パーティクルはデータベース上の点であるため、物理モデルに基づいた数式を用いた数値計算を行うことなく次のデータをたどるだけで「次の観測するシャトルの位置の予想」が行えます。
test3_1

全てのパーティクルを進めたものが「KinectV2によるシャトルの座標を得る前の予想の分布」であり、ベイズフィルタにおける事前分布に該当します。

 test4_1

ここでt=2におけるKinectV2が観測したシャトルの座標を取得します。この後、得られた観測点を基に各パーティクルがどの程度妥当か(尤度)を計算します。尤度は大きいほど「そのパーティクル付近に本当にシャトルが存在する可能性が高い」ことを意味しています。

ここで念のため述べておくと、今やろうとしていることは「KinectV2で認識した座標は様々な誤差が乗っているので、この誤差を軽減して『本当はシャトルはどの位置にあったのか』を確率的に考える」ことです。

シャトルの真の位置の推定は、先程求めた尤度を用いた重み付き平均を求めることで行います。これは理想的には最小分散推定量に該当します。

 test5

ここで、推定位置を始点としてそれぞれの先の軌跡を最後まで描画し、それぞれの重み付きの平均を求めたものを予測軌道とします。

また、t=1t=2のシャトルの観測点を基にパーティクルの抽出・そして尤度の低かったパーティクルを淘汰させます。これが事後分布となり、次の初期状態となります。

 

この工程を逐次的に繰り返していくことでシャトルの落下地点を予測していきます。


ちなみに、パーティクルフィルタそのものは必ずしもデータベースを用いるアルゴリズムではなく、むしろ今回の使い方が少しメジャーじゃない気がしますのでパーティクルフィルタ=データベース!では断じてありません。よろしくお願いします。
 

・いいからはよ動画だせや 

この軌道予測を用いてロボットを全自動走行させた動画が以下の二つになります。

こちらは3月中旬の動画です。レシーブではなく、150mm×200mm程度の大きさの段ボールにシャトルを入れる試験走行です。足回りは完全自動で、マシンが「ピピピピピ…」と音を発しているとき、軌道予測PCから落下地点を受信しています。

 


3月後半での動画です。移動先を段ボール箱からラケットに変えたものです。シャトルの落下地点が近い場合についてはラケット一本でも場所が合わなくはないくらいの精度が出なくもないようです。あと、背景に映っているのがカメラ台です。

  

・ビデオ落ちとその後の改善

ここでビデオ落ちします。恐らくこちらの自動機については「多種多様な球筋に対応できる」ものと判断されなかったのだと考えています。あと、純粋に他校のクオリティが高かったのだと思います

今回ぼくが用いたシャトル認識・軌道予測の手法は以下のようなメリット・デメリットがありました。

 

シャトル認識

メリット

・遠くまで認識することができ、自フィールドのサービスエリア側にコントローラを置いたにも拘わらず、相手のサービスまで十分認識できる。

・マシンなどが写っていてもシャトルの高精度な認識ができる。

デメリット

・最初に軌跡を認識するために6点一気に必要とするので5点分の時間遅れが生じる。


軌道予測

メリット

30fpsで得られたシャトルのデータを用いてマッチングを行ったため、速度推定を一切行う必要がなかった。

・シャトルの物理モデルや、それに伴う非線形項を考えずに済む。

・そこそこ高精度。

デメリット

・パーティクルが少ないうちは認識精度はそれほど高くないので、パーティクル数がある規定値を超えるまで落下予測地点をロボットに送信しなかった。これによってシャトル5点分程度の時間遅れが生じたうえ、UDP/IPの遅延なども合わせると予測がワンテンポ遅いものになってしまった。

 

つまり、今回のシステムは精度や認識距離と引き換えに時間を犠牲にしていました。素早く落下地点に移動する必要が不可欠なロボミントンではこれは痛手です。そこで、次に行った改良は「全自動化を諦める」ことでした。

操縦者はフィールドの真横に立ち、マシンの前後方向だけを操縦します。一方で軌道予測でマシンの左右方向を自動で移動します。このマシンは右半分のコートしか動き回らない設定なので、自動化部分の移動範囲を小さくすることで遅延をカバーする、という方針です。
auto

操縦者は上画像の視点のように、ロボットを真横から見る視点での操縦を行います。

これによって、ロボミントンの操縦の一番の難関であった「奥行き方向が全くわからない」という問題を回避することができます。

これを実装したものが以下の動画です。


ロボットは横方向の移動を完全に自動で行っています。操縦者は見えていませんがフィールドの側面側の、サービスエリア付近から操縦しています。 操縦範囲が2次元から1次元になり、しかも最も把握し辛い奥行き成分を全く考えないで済むようになったことで、かなり操縦がしやすく、そして全手動の場合と比べで命中精度が大きく上がりました(当社比)





以上がぼくの今年行ったことの大体全てです。ビデオ審査で落ちてからは焦点の定まらない目で壁を眺める生活を続けていますが、ぼくは今B3なのであと1回ロボコンをリトライできるので、それまでにもうちょっとマシな制御屋さんになれるように頑張っていきたいと思います。

MATLAB講習会

部長のおーまです.
先日, MathWorks社の方をお招きしてMATLAB講習会が行われました.

MATLABとはMATrix LABoratoryの略であり, MathWorks社が開発しているソフトウェアです.
「プログラミングで悩むより, その先の本質に集中して欲しい」という思いから開発され, 行列演算ライブラリであるLINPACK, EINACKを手軽に利用するソフトウェアとして開発されましたが, その思いのもと他にも様々なことができるようになっています.

東工大は今年の3月からMATLABのTAH(Total Academic Headcount)ライセンスを締結しており, 全学生および教職員は学内で無制限にMATLABを利用することができるようになりました.
(詳しくはこちらから http://tsubame.gsic.titech.ac.jp/MATLAB-TAH_Student )

今回の講習会では, そんなMATLABの歴史から始まり, 具体的なMATLABでできる様々なこと学び, Simulinkといった他の環境をMATLABと併用しドローンを飛ばしたりKinectの機能を利用したりと, 他のハードウェアとの連携機能についても実演していただきました.
 kinpatsudoroooon
講習会を通し, 今までMATLABを使っていなかった人もその魅力を十分に感じることができました!

また, 講習会開始前にはMathWorksの方からお土産としてMATLABグッズをいただきました!
 omiyaのコピー
これで日常の中でより身近にMATLABを感じることができます. 最高ですね.

部員達からの評判もとても良く, 非常にためになる講習会でした.
本当にありがとうございました! 

【10g】ロボットシミュレーション可視化環境 "torqml" の紹介 ①

みなさんこんにちは,この4月に大学院に入院いたしました,11年度入学のところです.

「忙しい」を理由になかなかブログを書かない罪悪感に苛まれながら $n$ ヶ月を過ごしておりましたが,今回それを挽回すべく,私が現在開発している,ロボットのシミュレーションデータを簡単に3次元可視化するソフトウェアである torqml の開発状況についてご紹介しようと思います.
ついでに数値シミュレーションとはどういうものか,なぜやるのかということも書こうと思います.

1. なぜシミュレーションをするか?

「机上の空論」という言葉は皆さんご存知だと思います.
いくら机の上でゴリゴリやってても内容がないよぅじゃ意味がないということですね.
私の専門分野(制御理論)のように机の上での計算に多くの時間を費やす研究分野では,現実から乖離していく方向に進まないよう,これに十分注意する必要があります.

そのため多くの場合は,提案した手法をいくつかの具体的な例に適用して効果を検証するということを行います.
学術の世界で言うシミュレーションは,数値計算によってこの検証を行うことを指します.
ほとんどの場合はコンピュータを使って想定する条件を作り出し,扱うものや手法の数式に従って計算を行います.
数値で結果や効能が見えるということは大変重要なことです.
例えば,スーパーに並ぶ日用品や食品に「20%増量」とか「30円引き」とかが明確に書いてあることで,お得だと感じて皆さんが手に取るわけです.
つまりは説得力があるのです(ゆえに気をつけなければなりませんが).

また,ロボットの場合は1台作るだけでも高価になることが多いので,予めシミュレーションでうまく行くことを確認しておいてから実機に適用することで,プログラムの不具合による暴走や故障を未然に防ぐことができます.

2. なぜ可視化する必要があるか?

しかし,数値というものは説得力と引き換えに,実際の量との直感的な関連付けがしづらいという側面を持っています.
例えば砂糖20グラムと言われても,それがどれぐらいの量かイメージしづらいでしょう.
また,砂糖をひとつかみ手にとってそれが何グラムか正確に分かる人も多くないと思います.
すなわち,数値という記号の世界と実際に見える・感じる量の世界は,お互いになかなか行き来できないことがわかります.

そこで人間は可視化するための道具を開発してきたわけです.
  • はかり
  • 定規
  • 時計
身近にあるこれらはすべて数値の世界と量の世界を行き来するのに使われています.

ロボットのシミュレーションの話に戻しましょう.
シミュレーションを行うと,東に何メートル・北に何メートル・左回りに何度・… みたいなデータがたくさん得られるわけですが,数字を眺めていてもロボットがどういう状況にあるのかさっぱりわかりません.
したがって,数値を何らかの形式で表現し直すことで,可視化することを考えます.
下に挙げたのはその一例です.

--
方法①:グラフやプロット
scrot_20150310_02:57:22_AM

グラフは,ある量と別の量の関係や規則性,割合などを見るのにとても便利な表現方法です.
しかし,グラフから直接長さや速さといった量を読み取って,物理的な感覚をイメージするのは簡単ではありません.

方法②:静止画や動画
pendulum_quad

静止画や動画…つまり絵で表現すれば,見てそのままですのでかなり直感的です.
しかし,関係や規則性を見つけるのは難しくなります.
--

このように,見せる方法によって,見やすくなる情報と見にくくなる情報があることがわかります.
全てを1つの方法で見せるのは大変難しいことなので,通常これらの方法をうまく組み合わせることをします.

ロボットのシミュレーションでは,ExcelやMATLABを使ったり,場合によっては専用のソフトウェアを自分で作って数値計算をします.
これまでは,数値計算した結果は大抵①に示したようなグラフを作成して満足してしまうことがほとんどでした(少なくともロ技研では).
これでは,出てきた結果が直感的に正しそうなものかチェックする手がかりがありませんし,ほかの人に見せる際にわかりづらいものになってしまいます.
そこで,出てきた数値を簡単に画像として出力できる環境を作れないだろうかという動機のもと,torqmlを開発しています.

3. なにができるのか?

torqmlでは,QMLと呼ばれる言語を用いてロボットなどの対象物の構造を記述し,数値シミュレーションのデータを読みこませることで,アニメーションの再生と静止画・動画への出力ができます.

scrot_20150502_02:52:16_PM


例えば,ビューワに直方体(TQBox)を表示するには次のように記述します:
import TorQML 0.1
import TorQML.Shapes 0.1
import TorQML.Views 0.1

TQBasicView {
models: TQModel {
TQBox { }
}
}
frame_1


基本的な記法はJSONに似ています.形状には様々なプロパティがあり,
TQBox {
xLength: 0.5
yWidth: 0.1
zDepth: 0.1
}
と指定することで,TQBoxの $x, y, z$ 軸方向の幅を設定できます.
frame_1


コンポーネントの入れ子構造を利用することで,構造の従属関係を記述します.
torqmlが主にサポートする,リンクで構成されたロボットマニピュレータの記述に適した形になっています.
回転や並進はtransformプロパティで指定します.
TQBox {
xLength: 0.5
yWidth: 0.1
zDepth: 0.1
TQBox {
color: "green"
xLength: 0.4
yWidth: 0.2
zDepth: 0.2
transform: [
Rotation3D { angle: 30; axis: "0,0,1" }
]
TQBox {
color: "blue"
xLength: 0.3
yWidth: 0.1
zDepth: 0.1
transform: [
Rotation3D { angle: 30; axis: "0,0,1" }
]
}
}
}
frame_1

アニメーションはtransformやその他のプロパティを更新することで実現しています.
次回以降で詳しく説明していこうと思います.

このように,torqmlではQMLを使用して3次元構造を直感的に記述することができます.
XMLをベースにしたものに比べてコンポーネントとそのプロパティ,コンポーネント間の関係がわかりやすく記述できます.
また,QMLを使用することで高い拡張性が実現できており,簡単にビューや形状などのコンポーネントを継承したカスタムコンポーネントを作成することもできます.
工夫すればtorqmlの上でちょっとしたゲームなんかも作れたりするのではないでしょうか.
詳しい記述方法や,ソフトウェアの使用方法についてはリリース後にこのブログの方に書いていこうと思います.


4. 今後の展望

torqmlはまだ正式バージョンをリリースしていませんが,Bitbucketで現在開発中のコードを閲覧・使用することができます.
https://bitbucket.org/tokoro10g/torqml
(ブラッシュアップできていないため現状すごくコードやディレクトリ構造が汚いです)

リリースは5月末ごろを予定しており,それまでにドキュメントを整備したりしながらこちらのブログで宣伝をしていこうと考えています.
また,将来的にはJavascriptやRubyで記述したシミュレーションプログラムを組み込んでの表示や,外部のシミュレーションプログラムからのデータパイプにも対応しようと考えています.

使用しているライブラリの都合上,Mac OS Xと各Linuxディストリビューション(Arch LinuxとUbuntu 14.04で動作確認)のみの対応となりますのでご承知ください.

torqmlの応援,よろしくお願いします!
ギャラリー
  • ABUロボコン結果報告
  • スマホから部屋の電気をつけてみた
  • MakerFaireTokyo2017に出展します
  • MakerFaireTokyo2017に出展します
  • MakerFaireTokyo2017に出展します
  • MakerFaireTokyo2017に出展します
  • MakerFaireTokyo2017に出展します
  • MakerFaireTokyo2017に出展します
  • たのしいロボット帝国 製作物紹介
記事検索
最新コメント