俺の設計指針
俺のロボット設定指針シリーズ
「問題が起きたらまず計測」
これは至極当然で、難しい。設計指針ではないと思うかも知れないけど、先に計測の事を考えて組むのが良い。
ソフトウエアの世界でも機械の世界でも、多分電気の世界でも当たり前なんだけど、ロボット系の世界で経験のある技術者でも、時間に追われてたりして余裕が無いのが日常なので、自分の感覚やカンを信じがち。かく言う僕もそうだから気を付けるための戒め。
よくあるのは、何か動作しないモジュールがあるときに、必死で動作させるためのコードを書いて、こっちなら動く、という謎デバッグ。貴重な情報なんだが、その前にやることが多い。
別の例。あるタスクの達成確率が低い場合。例えば「センサでの対象物位置認識→運動学計算→リーチング→把持」のようなタスクがあるとする。このタスクの達成確率が低いとする。経験がある技術者でも、いきなり、どれか一つの精度を上げようとする。その前にやることがある。
モジュールそれぞれに計測するのだ。先の例であれば、対象物を固定してセンサとの相対位置を測定器で計測して認識誤差をできるだけ正確に測定する。アームの動作も同様にアームが指定した位置に到達しているのか、誤差がどの程度でるのか3次元測定器等で計測する。当たり前なんだけどね。これに対して、場当たり的な手法で都合を付けようとすると、無駄に手数をかけるしシステムの変化に弱くなる。アームを入れ替える、カメラを入れ替える、どこが問題だったのか有耶無耶のままに新しいコンポーネントを選択して泥沼になっていく。
また自分が信じているモノを疑うことも必要。例えばロボットアームは目標とした位置に厳密にリーチングできることは無い。必ずズレる。またカタログスペックだけでは分からないことがある。姿勢による手先位置到達精度や繰り返しの精度、ヒステリシス。
何が原因で信じてたモノが裏切られるかわからない。工業用アームだと設置時に精度よく組み付けるのが難しい製品もあったりする。アームは精度よく動いても組み立て工程が悪かったりする。
別の例を出そう。とても時間が掛かる処理を短縮しようとしたときに、扱うデータのサイズ等で当たりを付けて高速化する対象を決めるのは良い態度ではない。処理時間は比較的計測し易い項目なので測ってみると、他の部分に比べて1桁小さい処理時間だった、なんてのもある。
計測は客観性を担保する方法としても重要である。
自分が所属していた機械系のロボット研究室の話でこんなのがある。あるチームのロボットが、図面通りに組み立て、ソフトを組んだが片腕だけが動かない。最初にソフトが得意なチームの学生が呼ばれた。彼はコードを調べたが答えには行き着かなかった。次にメカ設計が得意な学生が呼ばれた。彼はロボットを分解して図面を確認し、いくつか測定器で計測して「この部分が当たってます」と突き止めて、金ヤスリでゴリゴリと削ったら動いた。
この話は二つの教訓があって、測定をしたメカ側のデバッグの態度が良かったこと。コードを読む、図面を見る、だけだと分からないことが多い。もう一つはエンジニアは問題を得意な分野の問題として捉えがちで、最初はそのバイアスに敏感になるべき。客観性を担保する上でも計測がとても大事だという教訓。
「問題が起きたらまず計測」
Quote
Yuki Suga/編み物ラグビー好きフリーランスロボット屋プログラマー
@ysuga
俺のロボット設計指針シリーズ
「候補とするアーキテクチャを2つ以上つくる」
フリーランスの仕事を始めて、30代後半になってきて、全体設計やチームをコーディネートする仕事も期待されるようになってきた。今でもコーディング等の作業をがっつりやりますけどね。 x.com/ysuga/status/2…