あのロボットが私のハードウェア予算を食っている！：SYSTEM DESIGN JOURNAL（2/4 ページ）

ロボットを止めるにはもう遅すぎる――これはハードウェア予算やシステムデザインの話ですが、影響を軽減することは可能です。「あるロボットに未知の地形を滑らかに歩かせる」を例に、エンベデッドシステム化するロボットについて考えてみましょう。

[Ron Wilson，Altera Corporation. MONOist]

6本脚の敏しょう性

　三脚歩行は非常に単純です。3本の脚の新しい脚の位置を計算し、それらの脚を上げ、旋回させて、計算された新しい位置に着地させます。この動作を3本の脚ずつで交互に繰り返せばよいのです。

　しかし、脚が描く計画的な円弧を記述する、脚の速度を調整する、3本以上の脚を同時に動かすなど、より滑らかに歩行させる方法があります。そうした歩行には、20msおきに新しいパルス幅を各モーターに送信することにより、18 個のサーボを全て更新し続ける必要があるかもしれません。つまり、インバース・キネマティクスの計算時間を、パルス当たり1ms未満に抑えなければならないということです。

　三角関数ライブラリの累積誤差が、脚の動きに明らかに現れるほど大きくならないようにするには、恐らく32ビット、あるいは単精度浮動小数点演算が必要です。言い換えれば、計算負荷が20倍〜数百倍に増加するということであり、もはやArduinoで対応できる範囲を超えています。「Arduino を当てにしすぎると、デバイスの性能の壁に間違いなくぶつかる可能性があります」とkrtklのチームは警告します。

　ここで、もう1つ複雑性を加えてみましょう。それは「平らではない地形」です。近所のロボットクラブであれば障害物や階段でのデモ程度で済みますが、捜索救助ロボットなど、アプリケーションによっては不整地の走破が必須条件となります。

　平らでない地形では、脚の軌跡を連続制御する必要があります。標準の脚の動きを記述した脚本を用意するのではなく、しっかりした着地場所を確保し、ヘキサポッドが障害物に一切干渉しないように、かつプラットフォームを安定した状態に保ちながら、各脚の配置の円弧を計算する必要があります。

　これで、ヘキサポッドはガレキの中をゆっくり進むことができますが、膨大な数の立体幾何学計算が計算負荷として追加されたことになります。これは事実上、固体モデルシミュレーションをリアルタイム実行するということであり、最低でも32ビットのマルチコアMCUが必要となるでしょう。

　ところが、ここで新たな問題が忍び寄ります。レースや、よく知っている変化のない地形を航行する場合は、地形の定義済んだ3Dマップを使用することができます。しかし、建物が倒壊した状況での航行を含め、ほとんどのアプリケーションでは、ロボットは移動中に自らが3Dマップを構築し、空間内での自己位置を推定するタスクを少なくとも一部は自ら実行する必要があります。

私はここにいる

　原理上は、ヘキサポッドの周囲の詳細な静的マップがあれば、状況に応じた手法で自己位置を推定することが可能です。例えば、安価な携帯電話部品である加速度計による慣性航法、ラジオ・ビーコンまたはレーザー距離計による三角測量、環境に埋め込んだロケータの検出などが挙げられます。これらの手法はそれぞれ位置推定タスクが必要ですが、いずれも計算的に特に高負荷というわけではありません。

　しかし、位置推定アルゴリズムの入力として、カメラやマシンビジョン・アルゴリズムが使用されることが多くなっています。krtklのチームは、この進化の初期の例として、ラジコンヘリを挙げ、「ヘリコプターの安定性は本当に容易ではありません。かつてはジャイロを使用していましたが、現在はビジョン・プロセッシングをベースにしています」と説明します。

　水平を基準にした姿勢の測定は、加速度計による推定航法に比べて正確かつ確実ですが、コストの問題があります。ビジョンプロセッシングは一連のデジタル信号処理タスクであり、最低でもSIMDハードウェアを備えた高速な32ビットCPU（ARM NEONなど）、できればDSPまたはFPGAが必要です。

　もう1つの例は、小売業の顧客サービスからです。FellowRobotsはイギリスのSFドラマ『Doctor Who』に登場するダーレクとキオスクを足して2で割ったような外観の自律型顧客支援ロボットをフィールドテスト中です。

動画が取得できませんでした