Bakulog

獏の夢日記的な何か。

Pepper用のC#ライブラリを頑張ってマルチプラットフォーム化した

C# Pepper Unity ソフトバンクPepper

半年くらい前に公開したBaku.LibqiDotNetのアップデート報告です。

　

注意: 2016/09/22時点でreadmeとかチュートリアルの整備が追い付いてません。ライブラリ公開状況は以下のようになってます。

端的に言うと「慣れてる人は.NETにもXamarinにも持ち込めるけど慣れてないと使いづらいし、Web上のドキュメントと仕様違うじゃねーか！」という状態です。

触りづらいと感じたら情報整備されるまで従来版(ver2.0/2.1)を使うか、あるいは直接質問するかしてもらえればと思います。

　

もくじ

  1. 概要
  2. 現時点で確認している不具合
  3. 実機が無くてもデバッグは出来るんですよ
  4. Baku.LibqiDotNetの使用状況とか
  5. まとめ

　 　

1. 概要

半年前の公開から放置気味になっていましたが、Baku.LibqiDotNetはC#でPepperやNaoを使うために整備したライブラリです。

半年前の公開時点ではBaku.LibqiDotNetによって以下のような事が出来ました。

  • Windowsの(x86)なアプリ / MacがPepperに接続できる
  • 上記環境ならUnityでも使用可能
  • 自動生成コードが付随しておりIntellisenseが活用できる

この時点でもある程度強力でしたが、このたびマルチプラットフォーム化を念頭に以下の通り更新しました。

  • インターフェース周りの設計を見直した
  • Unityで(多分)Unityが対応する全プラットフォームに対応
  • XamarinでAndroidとか(多分)iOSに対応

「対応した」と書いていますが現状でパッケージ化して公開しているのはUnityだけで、UnityについてはGoogle Driveからダウンロードできます。Xamarinとか通常の.NETに関してはGitHubのソースで直接ビルドしないと使えないので注意してください(冒頭にも書いてますが2016/09/22時点ではdevcrossブランチに最新ソースが乗ってることにご注意下さい)。

　

マルチプラットフォーム化させたポイントはPepperとの通信でsocket.ioを使う選択肢を増やしたことです。

公式ライブラリに沿った言い方にすると、公式のJavaScriptライブラリであるlibqi-jsを.NETでマネするように実装しました、というくらいの話です。

socket.ioは根本的に適用範囲が広く実装も完全マネージコードで済むため、Mono Runtimeが動けばどこでも動くだろう、という寸法です。

　

ただし注意としてsocket.ioを用いた通信では音声のリアルタイムダウンロードなど、一部の処理がサポートされません。これはPepper側の仕様です。

というわけで、socket.ioのメリットだけでなく従来のネイティブライブラリをラップした通信のメリットも捨てがたいため、更新版のBaku.LibqiDotNetはライブラリ全体を以下のような体裁に整えました。

  • ネイティブライブラリをラップした従来機能は残す
  • socket.ioを用いて通信する機能も追加する
  • ユーザは通信セッションの生成時に通信のベースとしてネイティブライブラリかsocket.ioを選ぶ
  • 通信セッションに由来するデータをほぼすべてinterfaceベースにして実装を剥がす

クラス設計のコンセプトはおよそ下図のようになっています。ライブラリの使用者からは真ん中のインターフェースだけが見えていて、両脇の実装詳細には触らないような構成です。

blqdotnet

ライブラリ使用者はファクトリのQiSessionFactoryからLibqiSessionかSocketIoSessionを生成し、生成後は通信方式のことを忘れて処理をする流れになります。

参考までに、私が推奨する使い分けとしては原則socket.ioを利用し、ネイティブライブラリが対応しているプラットフォームではネイティブライブラリのラッパーに切り替えるといいと思います。

　 　

2. 現時点で確認している不具合

Baku.LibqiDotNetのKnown Issueとして、Socket.IOのセッションの中でもAndroid版でWebSocketの初期化がたまにコケる現象を確認しています。

手元で確認している範囲では通信用ライブラリのWebSocket4Netの不具合じゃないかと推測していますが、具体的な原因特定には漕ぎつけていません。

他のプラットフォーム(iOSとか)でも同様の現象が発生する可能性があります。

ホントは直してからリリースしたかったんですが、諸事情でリリースタイミングに期限があったため、仕方なく放置しています。

現状ではこの問題の原因は分かってないため、接続問題が頻発するようであれば「接続にトライしてみて一定時間でうまく行ってなかったらリトライ」みたいな処理をユーザ側で実装する必要があります。

もし原因分かる方がいらっしゃいましたら誰か教えてください…。

　 　

3. 実機が無くてもデバッグは出来るんですよ

リリースノートの話ではありませんが今回の開発中にやってた作業なのでついでに紹介。

実機のPepper無しでPepper関連ソフトのデバッグをしたい場合、次の手順でPepperのシミュレータを起動してシミュレータを用いたデバッグが行えます。

手順とは言ってますが、ググったら出てきそうな詳細情報は省いているのでご了承ください。下記では環境としてWindowsを想定していますが、適宜読み替えることでMacとかでもほぼ同じ手順でシミュレータによるデバッグが可能となるはずです。

まずは準備。

  1. Choregrapheをインストール
  2. Python 2.7.xをインストール
  3. NAOqi Python SDKをインストール
  4. libqi-jsをcloneなりダウンロードなりする
  5. 4で持ってきたレポジトリの中にqimessaging-jsonというファイルがあるが、これはPythonスクリプトなのでqimessaging-json.pyにリネームしておく

準備が整ったらはじめにChoregrapheのインストールディレクトリ以下にあるnaoqi-bin.exeを探します。私の場合これはC:\Program Files (x86)\Aldebaran\Choregraphe Suite 2.4\bin\以下に置かれていました。

このnaoqi-bin.exeをダブルクリックで起動します。

次にコマンドプロンプトを立ち上げてipconfigとかでマシンのIPアドレスを確認し、その後qimessaging-json.pyのあるディレクトリに移動してスクリプトを実行。

python qimessaging-json.py

　

最後にChoregrapheを起動してシミュレーターロボットの動きが見える状態にします。

Choregrapheのロボット接続ダイアログを開き、「固定IPまたはホスト名を使ってください」のチェックボックスにチェックを入れ、その右のテキストボックスにローカルホストのIPすなわち127.0.0.1を入力します。これで接続。

　

naoqi-bin.exeがうまく立ち上がっていれば以上の手順でChoregrapheからシミュレータロボットが見えるようになり、実機と同じようなデバッグが出来ます。

通常だとこの方法ではLibqiのネイティブライブラリを用いた通信ベースでのデバッグしか出来ないのですが、qimessaging-json.pyを起動したことによってsocket.ioの通信も行えるようになっています。

というわけで、この手順を踏めば実機なしでもJavaScriptや今回作ったBaku.LibqiDotNetの追加機能からPepperを操作できるかチェック出来ます。

ただしシミュレーターではセンサーのデータが取れないとか、そのままではタブレットのデバッグまでは出来ないといった問題があるため、その辺は注意してください。

　 　

4. Baku.LibqiDotNetの使用状況

ここからはリリースノート等とは関係ない雑談です。

虎の威を借る狐みたいな話ですがBaku.LibqiDotNet関連の使用報告でそこそこ目立ったものがあったので紹介します。

Pepper君を操るのは……Pepper君!? Unityブースの展示に未来が見えた【CEDEC】

ということで、なんとCEDECで使用して頂きました。

Pepper App Challangeのときにも思っていた事ですが、やはりUnityはこういう時にフットワーク軽いのがいいですね。

　 　

5. 最後に

偉そうにこんな記事を書きましたが、じつはマルチプラットフォームなライブラリを作るのは初めてです。というかOSXとかiOSもそこまで好きじゃないし

対応環境は広めに想定したものの、手元で実際に動作チェックしたのはWindowsとAndroidのかなり限定的なケースだけです。

動作の不具合等ありましたらGitHubかTwitterかメール等で報告頂けると非常に助かります。