Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Common Lispを使ったローバー制御プロトタイプ
ICFP'08コンテストへの挑戦
Salvi Péter, 黄涧石
Image from NASA
概要
ICFPって何 ? コンテストについて 今年度の課題 解答方法の概略 Common Lisp参上 デモ 結論
Original animation from www.sooner-robotics.org
ICFPって何?
国際関数型プログラミング学会(International Conference on Functional Programming)
1998年以来毎年プログラミングコンテストも主催− 成績は学会にて発表される
優勝に伴うプログラミング言語の名誉− 1位:目が効くハッカーの言語− 2位:多くのソフトのためのナイス・ツール− 雷光派:迅速なプロトタイピングに相応しい
– 前のコンテスト 2004年
主催大学:ペンシルバニア大学蟻コロニー(蟻のオートマトンを設計)
– 前のコンテスト 2005年
主催組織: PLT警官・強盗ロボット・プログラミング
– 前のコンテスト 2006年
主催大学:カーネギーメロン大学 (CMU)− 発掘された古文書を基に古代文明のパソコンをエミュレート
− 古代人が残した課題
– 前のコンテスト 2007年
主催大学:ユトレヒト大学二段階のオートマトンで DNAを変えて非常着陸した異星人を地球に順応させる
今年度のコンテスト
7月 11日〜 14日(金【土】〜月) 主催大学:ポートランド大学・シカゴ大学火星ローバーを障害を避けながら基地に導く( TCP/IPを通じて)
雷光派の締切りまでは 24時間 Linux LiveCDで実行できるファイルを提出
...そして我がチーム「 Epsilon」が形成された
…主催者がやってくれたのは
Wikiページ( FAQ等) メーリングリスト IRCチャンネル ホームページの更新通知( RSS) 実験用のサーバー(グラフィカル)〔 SMLで開発された物〕
コンテストの間:− LiveCDに新しいソフトを追加− サーバーのバグ修正
使われたプログラミング言語
ICFP'08 (9月 22日〜 24日 )で発表 ネットで様々なビデオが見られる 336 提出 (+ 140 雷光派 ) プログラミング言語 :
− Java, Python, C++− Haskell, ML所属− ...− Lisp (7つだけ )− 他にも色々 (LaTeX (!))
参加者
世界の各地から 日本 : 106 (!) [アメリカ合衆国 : 192]
今年度の課題
TCP/IPを通じてローバーと通信 情報速度: 1秒当たり約 10メッセージを受信 内容は地形データ:
− 巨礫、クレーターと火星人(全て円形)− 楕円形の視野
ローバー・モデル
制御:左折・右折・加速・減速(ブレーキ) ローバーは二重オートマトン:
地図
各地図でローバーが5回走る(スタート位置が違う)
一番いい三つしかカウントされない
基地は真ん中にある 地図の大きさ、障害や火星人の数などは地図ごと異なる
解答方法の概略
モジュール:− 通信器− 構文解析器− 地図製作器− 経路生成器− ビークル制御器− ロギング・グラフィック(デバッグ用)
抽象的から具体的へ
通信器
ビークル制御器 構文解析器
経路生成器 地図製作器
データベース
経路生成
簡単な方法:基地を目指せ! 実際にこれを利用していた(少々改修して)
− 障害があると、近い方の正接点を目指す
火星人は円形の物体として扱われる
(半径は速度に従属)
経路生成
問題例
この方法の長所:− 「よっぱらい運転」の現象はない− 簡単で早い
解決策:両側が閉ざされた場合障害が(短距離で)見えなくなるまで左折・右折を繰り返す
選択した方向を記憶
経路生成
問題点:− 火星人モデルが簡単過ぎる
楕円で近似移動予測シミュレーション
− 考慮範囲が浅い(一点だけ)
− 目的点までは辿り着けないかもしれない
理想的なルート
経路生成
A*サーチでやってみよう!− ノード:ダイナミック格子の点− 基地まで(今の世界の知識だと)絶対辿り着ける
経路生成
A*サーチでやってみよう!− ノード:ダイナミック格子の点− 基地まで(今の世界の知識だと)絶対辿り着ける
地図製作
保存するのは:− 永続性の物(火星人とローバーを除く)− 火星人
最後の幾匹だけ固定サイズのキューに入れる見えなくても最近みた火星人は覚えている
保存方法− ただのリスト(簡単の経路生成には充分)− ダイナミック格子( A*には必要)
ダイナミック格子
四分木(二分木の2次元版) 各セルに同じ点数 どの物体の周りにも点があるように
運動制御
運動モデルは次のパラメータで定義される− 速度 (S
t)
− 加速 / ブレーキの (a, 初期値不詳 )− ドラッグ係数 (k, 初期値不詳 )
方向の計算に必要なのは:− ソフト角加速度− ハード角加速度
パラメータの推定は毎回自動的に計算される
運動制御
目的は与えられた経路でローバーを走らせる
運動制御
制御器の三つの要素− ローバーのモデル− 入出力の決定− 制御アルゴリズム
運動制御
モデル− ローバーの運動モデルは理想的 (課題により )− 運動方程式
運動制御
入力− 経路との最短距離− 経路の切線との角度
出力− 加速度− 角加速度
運動制御
微分方程式は解かなかった!:) シミュレーションを基にした制御アルゴリズム
− 簡単で効率的− 比例ゲインだけで十分− パラメータチューニングはより少ない− ただし、計算量が多くなる (ここは問題ない )
運動制御
他について− 動作装置の仕組みは加速度と角加速度を連続値からサーバの受けられるコマンドに変換する
− パラメータチューニング trial-and-errorの方法だけ使ったもっとも重要なパラメータ
− シミュレーション期間− ターンの閾値(ソフト角加速度とハード角加速度)
運動制御
問題点− 振動が発生するかもしれない− ブレーキは考えてない
速く走りたい!最適化で探索する空間は二次元になる(最適化アルゴリズムを導入する必要)
メッセージ
メッセージというのは:− 識別子の一文字− データ(物体はまた識別子で分けられている)− セミコロン
物体はセミコロンなしのメッセージ I dx dy time-limit min-sensor max-sensor ... ; T time-samp vehicle-ctl ... object* ; b x y radius m x y direction speed
内部のメッセージ形式
以下のようなメッセージは
T 123 aL ... b 13.5 23.47 4.3 m 3.2 4 45 4.1 ;
... このような形式になる:
構文解析
こんな書き方ができたらいいなぁ: これはメッセージ
これらは物体
構文解析
展開するとこんな感じになって欲しい:
メッセージ・ハンドラのハッシュテーブル
セミコロンを食うかエラーを投げる
結果はデータの連想リスト
構文解析
マクロ自体は:
parser-telemetryみたいな名前を生成する
構文解析
構文解析のメイン関数は簡単:
…これは無論一つの段階に過ぎない抽象化を更に進めることもできる
ロギング
デバッグには欠かせない 大切な条件:
− 消すのは簡単(効率面ではないと同然)− ログ形式などのオプションが選択できる− グラフィック表示(後で)
Lispのマクロを活かす絶好のチャンス− C(++)でもこれは普段マクロを使う:
#ifdef DEBUG ...#endif
ロギング・マクロの使用例
ロギング・マクロの性質
ロギングを設定するには一つの関数を編集してコンパイルすれば充分
− ログはどこへ書くのか− どの部分がロギングすべきか等
*LOGGING*変数を NILにして完全リコンパイルすると、元々ないと等しい
WITH-LOGSはただWITH-LOGを繰り返して呼び出す:
ロギング・マクロ
設定マクロ:
Hash of streams/options
ロギング・マクロ
ロギング・マクロ:
簡単で効率的 重複コードが減って、整理がアップ!
PostScriptでグラフィック・ログ
PostScriptでグラフィックログは簡単!
PostScriptは Forthみたいなスタック指向言語
PostScriptでグラフィック・ログ
カラーを幾つか定義して地図の大きさをセットアップ:
これで苦労なく、読みやすく地図が書ける!
PostScriptでグラフィック・ログ
ログ自体はこう言う感じになる:
PostScriptでグラフィック・ログ
出力:
CL-SDLでグラフィック・ログ
…しかしコンテストでは CL-SDLを使用 ログは CLOSオブジェクトとして(ほぼ)直接に読めるような形式で書く
ログの第 k行は:
…ここの ROVER、MARTIAN、 BOULDER等は CLOSのクラス
CL-SDLでグラフィック・ログ
READで読み込んでMAKE-INSTANCEを呼び出してオブジェクトを作る
メインループ:− フレームを一つずつ読み込んで− すべてのオブジェクトで表示メソッドを呼び出す
最適化のため、新しい物体だけをログする(そしてローバーと火星人)
グラフィック表示担当のソース全体は100LOC(行数)位
デモ
結論
SBCLを使って実行ファイルを作成 コンテストではレベル7まで行った … ♪けど 楽しかった 来年はエディンバラで!
− http://icfpconference.org/
− リスパーが増えればいいが スライド(英語・日本語)はここに:
The slides (in both English and Japanese) are here:
http://www.den.rcast.u-tokyo.ac.jp/~salvi/archives/text.html
御清聴ありがとうございました !