【Python】Pepperのメタプログラミング【qi Framework】

Pocket

アプリ向けのtipsではなくライブラリの内部に興味がある人向けのお話です。

 

もくじ

  1. とりあえずサンプルやってみよう!
  2. このJSONなんて書いてあるの?
  3. メタデータの使い道の例: コード生成
  4. まとめと注意

 
 

1. とりあえずサンプルやってみよう!


qi Frameworkのメタデータって何、というような話題の前にまずこのサンプルコードをデスクトップかどっかにコピペして実行してください。実行にはPython 2.7系とPyNAOqi SDKが必要です。

 

実行に際しては下記のように、接続先になるPepper/NaoのIPアドレスを指定します。

これを実行するとスクリプトと同じ階層に”QiFrameworkMetadata”フォルダが作成され、その下にjsonファイルがバババッと保存されます。

 
 

2. このJSONなんて書いてあるの?


保存されたJSONを見てみましょう。ここでは典型的な例として合成音声APIである”ALTextToSpeech.json”の中身を一部抜粋します。

 

長々と書かれていますが、そこまで変な内容ではありません。内容は下記の通りです1

  • description: サービスの説明文(「このサービスは合成音声のAPIです」等)
  • methods: メソッド一覧
    • description: メソッドの説明文(「この関数でロボットが喋ります」等)
    • name: メソッド名
    • parameters: メソッド引数の説明文的なデータ
    • parametersSignature: メソッド引数の型情報
    • returnDescription: 戻り値の説明文的なデータ
    • returnSignature: 戻り値の型情報
    • uid: 一意識別用に割り振られてるID
  • properties: プロパティ一覧
    • name: プロパティ名
    • signature: プロパティの型情報
    • uid: 一意識別用に割り振られてるID
  • signals: シグナル一覧
    • name: シグナル(イベント)名
    • signature: シグナルとともに送られる型の情報
    • uid: 一意識別用に割り振られてるID

 

一言で言うと上記JSONは「サービスの中身をクラス定義っぽく表したもの」程度に解釈すれば問題ありません。データを取得してJSONデータに変換し、保存するまでの処理はsaveJson関数で定義されています。

サービスに対してmetaObject関数を使うことでメタ情報を拾い、それをjson.dumpsですぐに文字列化しています。案外シンプルに捌けていることが分かります。

 
 

3. メタデータの使い道の例: コード生成


前節まででサービスの中身を表すJSONが拾える事自体は実証できましたが、コレだけだと「なんか複雑なデータだね」程度の感想しか出てこないので、具体的な使い道を一つ紹介しておきます。それはqi Frameworkのサービスの静的コード化です。

 

「静的コード化」と言われてもピンと来ないと思うのでもうちょっと掘り下げてみます。はじめに現状のqi Frameworkにおける問題点(というほどでもないですが)を一つ指摘します。PythonでのみPepperとやりとりする場合あまり意識しないと思いますが、qi Frameworkはほぼ動的呼び出しのみに頼ったフレームワークです。たとえばHello Worldコードを見てみます。

このコードで動的呼び出し感の高い処理は以下の3点です。

  1. 居るかどうかわからないロボットを指定して接続(session.connect("192.168.xx.xx"))
  2. 接続先のロボットが持っているかどうか不確定なサービスを文字列指定して取得(tts = session.service("ALTextToSpeech"))
  3. サービスに登録されているのか不確定なメソッドを、合っているか不確定な引数リストを与えて呼び出す(後述)

 

3つ目の「不確定なメソッドを不確定な引数でリスト呼び出す」はコードだけ見るとそう見えないかもしれませんが、実は

この呼び出しは糖衣構文で、内部処理的には下記に近い事が行われます。

つまりメソッド呼び出しも文字列をベースにした動的呼び出しです。

 

ということで、繰り返しですがqi Frameworkは動的呼び出しベースのフレームワークです。一部の人は「はいはい分かった。で、それの何が悪いの?」と思われるでしょうが、この仕様はインテリセンスの大敵です。ALTextToSpeechサービスを実際にロードするのはプログラムの実行時であるため、コーディングの時点ではエディタやIDEから見ると”ALTextToSpeech”サービスや”say”メソッドに関する情報が何もありません。そのためインテリセンスやドキュメント文字列無しでのコーディングが必要になってきます。おもにコンパイラ型言語(C++/Java/C#など)において、この問題はより重要になります。

この問題を解決するために一つ提案をしてみます。インテリセンスが欲しいならラッパークラスとしてALTextToSpeechクラスを定義してしまってはどうでしょうか。

 

こう書いておけば、例えばIPythonのインテリセンスが保障された環境でコーディングしている場合に下記のコード

コレがALTextToSpeechへと補完でき、同様に次のコード

これもインテリセンスでsay関数に補完されます。sayが(オーバーロードが二つあるので)引数を1つか2つしか取れない関数であることもコーディング時に確認できます。なかなか悪くないですよね?

 

ただ、上のALTextToSpeechクラスのようなラッパークラスは手作業でいちいち書いてたらキリがありません。そこで役に立ってくれるのが、最初の節で紹介したメタデータjsonを取得するプログラムです。具体的な実装の話は冗長になるので割愛しますが、少なくとも下記のメタ情報

これをうまく変換すると下記のようなPythonのメソッド定義(とdocstring)が作れそう、という見通しについては納得してもらえると思います。

実際にテキスト変換のプログラムを作る場合parametersSignatureやreturnSignatureに記載された”v”や”(s)”といったシグネチャ表現文字列の意味を把握する必要があるのですが、これについてはqi::signatureとかを読んで勉強してください。

 
 

4. まとめと注意


qi Framework流のメタプログラミングサポートとその恩恵について紹介しました。ただし重要な注意が一点。

 

最初の節で紹介したサンプルコードですが、コレは特定のロボットに接続してサービス情報を拾ってくるプログラムなので接続するロボットが違うと微妙に異なる結果を得ます。どのロボットに対しても使えるサービス情報を割り出すには公式ドキュメントに名前が登場するサービスだけを用いるか、あるいは下記の手順を踏むべきでしょう。

  • 複数台のPepperを用意する
  • それぞれのPepperからJsonをまとめて拾う
  • ぜんぶのPepperから同じJsonが返ってきたサービスは「どのロボットでも共通で使えるライブラリ」と認定し、標準的に採用(そしてPythonコードなどに変換して利用)
  • 同じJsonが返ってこないサービスは非標準サービスとみなし、使わない

 

ともかく互換性に注意してください、という蛇足でした。今回は以上です。

 


  1. 些末ではありますが、実際はmethods, properties, signalsの各要素は配列じゃなくて「一意識別ID:データ本体」の形式で辞書式データになっていることに注意してください。 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です