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

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

[Ron Wilson，Altera Corporation. MONOist]

キュートがパワフルに

　脱線して途中でテーマを変えることで、重要な問題を避けていました。それは「3D地形マップがなかったらどうなるのか」という問題です。その答えとしては、ヘキサポッドにカメラを搭載し、移動中に SLAM（Simultaneous Localization And Mapping：カメラなどを用いた自己位置推定）アルゴリズムを実行できるようにする必要があります。

　ROSライブラリにいくつか収録されている最も単純なSLAMアルゴリズムは、2D LIDARを入力として使用し、ロボットの周囲環境の2Dマップを作成します。コインブラ大学の2013年の論文によると、ゆっくり動くロボットに対応するために必要な性能は通常、Core i7 CPUの5〜20％です。しかし、それでは難しい地形を避ける助けにはなっても、難しい地形を進むには役立たず、さらに何かが必要です。500ドルもするLIDARは、できれば使いたくありません。

　そこで、話はビジョン・プロセッシングに戻ります。2015年5月に開催された Embedded Vision Conference に投稿された論文の中で、Videantisのマーケティング担当バイス・プレジデント Marco Jacobs氏は、プラットフォームの動きを利用して、2Dビデオストリームから3D SLAMを抽出するアルゴリズムについて論じています。原理は、両眼視でない鳥と同じく“頭”を動かして視差データを取得します。

　そのアルゴリズムは、一連のデジタル・フィルターを通じて画像から追跡可能な特徴を抽出し、その特徴が後続のフレームでどう動くかを予測します。そして、推定されたプラットフォームの動きを前提として、各特徴までの距離を計算することができます。これには明らかに大量の計算が必要であり、Videantisの場合、独自のメニーコア・ビジョン・プロセッサでOpenCVを使用して実行しています。比較的単純なヘキサポッドの例では、ほとんどのCore i7、あるいは数値アクセラレーションを追加したマルチコアMCUかASSPで実行可能と考えられます。

まとめ

　たった1個のカメラを追加することにより、ヘキサポッドに平らではない未知の地形を滑らかに横断させることができるようです。

　ですが、移動にはマルチコアMCUが必要であり、ビジョンプロセッシングと3D SLAMにはデスクトップ用高性能マルチコアCPUレベルのデバイスと大量のDRAMが必要になります。あるいは、DSPチップから専用ビジョンプロセッサ、小型FPGAまでの数値アクセラレータのいずれを使用することも可能です。さらに、Linuxカーネルと恐らくは何らかのRTOSも必要となるでしょう。

　これだけのデバイスを搭載すれば長時間のバッテリー駆動は難しくなり、ワイヤレスネットワークを用意して計算の大半をクラウドなど外部リソースへオフロードする必要があるかもしれません。ですが、そうした準備があれば、将来、さらに高度な自律性が要求された場合に、物体分類や状況認識のためにディープラーニング・アルゴリズムに接続することも可能です。

　最初はおもちゃでしたが、アルゴリズムと計算能力を加えることにより、ヘキサポッドに洗練性、機動性、自律性を与えました。しかし、ここに至るまでに、コンピューティング・アーキテクチャは大きく変化しました。しかも、消費電力を抑えようとするほど、アーキテクチャは劇的に変化しました。それに伴って不確実性も高まりました。より高度な自律性をヘキサポッドに加えるにつれて、同じファミリ内のより高速なチップに変更するのではなく、基盤となるハードウェアの変更を余儀なくされるタイミングの予測が困難になります。

　この新しい環境では、スケーラビリティとは単純なMCUの交換やメモリ搭載量の増大などを指すのではなく、アルゴリズムとコードへの投資を保護しながら、全く異なるアーキテクチャに移行できることを意味します。この先、ロボティクスがその他のエンベデッドデザインの世界に浸透するに従って、うまく対応する賢い技術者が現れるでしょう。

（本稿はSYSTEM DESIGN JOURNALに掲載された「That Robot is Eating My Hardware Budget!」の翻訳です）