10月10日に開催されたPepperのWorkshopに参加しました。

内容はPepperに関する解説と各自にSDKが配布されてちょっとした開発体験が出来ました。

開発環境はChoregrapheと言われるボックスを繋ぎ合わせるだけでロボットの振る舞いを記述可能なGUI環境で元々はNaoに使用されていたものが流用されています。

choregraphe

明らかに非ロボットエンジニア、非プログラマを対象とした開発環境でロボットに関する技術的な部分はモジュール(ボックス)として隠蔽されています。

ソフトバンクがロボットのデファクトを取ることを考えているとすれば当然の流れなのかもしれませんがNAOqi Frameworkは主にロボット研究者の間で広く普及しているROSとの明確な差別化を狙いまったく別の方向からシェアの拡大を狙っています。

このWorkshopに参加している方々の大半やPepperの説明をしてくれた方までもがロボット開発は未経験ということからもそれは感じ取ることができます。

一般に広くロボットを普及させるためにはロボットエンジニア以外にも多くのアプリケーション開発者を巻き込む必要があることから、いつしかこういったフレームワークが必要となるでしょう。

これは丁度、我々がロボットの研究のためにOS等をゼロから作り始めないのと同じで基盤技術として広く普及するものは必要に応じて抽象化され見えない層を構築するのだと考えます。

では、肝心のモジュール(ボックス)の充実度に関してはどうでしょうか?

まだβ版ということもありますが音声認識や音声合成、タッチセンサやモーション作成等コミュニケーションロボットとして最低限必要な要素以外はあまり充実していない。

地図上の任意の地点への自律移動や特定の物体の検出、把持動作計画等が標準のボックスに含まれていないためロボット技術を知らない方が何か意味のある非常に有用なアプリケーションを開発できる段階にはまだないと感じました。

そもそも、現状のロボット技術自体が豊富なコンテンツを生み出すだけの十分な汎用性と安定性を確保出来るのかということも問われるような気がしますが...

今後、公式の方で機能を更に充実させていくことやユーザがPythonで独自のボックスを追加できることから改善されていくのかもしれません。

公式からQiitaにチュートリアルを用意したり、Workshopやハッカソンを開催することでコミュニティベースの開発スタイルの確立を目指している点は好感が持てます。

しかし、これは鶏と卵の関係で十分な機能が提供されない内はコミュニティに人は集まりませんし、機能を充実させる上で欠かせないユーザが独自開発した機能を中央で管理するための仕組みもまだ用意されていません。

この辺りは、今やほぼデファクトといえるROSが普及する上でも重要なポイントになったと思いますのでこれからの整備に期待しましょう。

ここまでネガティブな意見を並べましたが、Pepperの移動ロボットのプラットフォームとしてのポテンシャルは非常に高いと考えています。

豊富なセンサ群と自由度を持ち12時間の連続稼働が可能でありながら通信料を含めても60万円に収まっているというのは驚きました。

安全性の面で欠かせない衝突検出も優秀でしたし、このプラットフォームの性能を如何に引き出せるかが腕の見せ所ですね。



blog comments powered by Disqus

Published

14 October 2014

Category

Event

Tags

Profile

千葉工大産のロボットナビゲーションエンジニア

ros-jpの勉強会の主催やロボカップ世界大会優勝チームのリーダをやってました。


 
badge_description about badge's

 

Follow me on Github

Follow me on Qiita

総訪問者数

アクセスカウンター