kakasiのインストール

英語モードと日本語モードを、「話」と「聴き」において自由に切り替える際に、日本語をローマ字に変換するため、kakasiをインストールした。つまり、opennaoでコンパイルしたということだ。これはそのままnaoに持ち込める。
kakasi -Ja -Ha -Ka -Ea -iutf8 -outf8
で、漢字、ひらがな、カタカナ、記号の全てをローマ字に変換する。たとえば、
kakasi -Ja -Ha -Ka -Ea -iutf8 -outf8
お題はコンビニです
odaihakonbinidesu

ALDialogの代替モジュール

ALDialogに変わるモジュールを作成することにした。完全なものでなくてもいい、私が必要な機能が全て含まれるものにしたい。言語の切り替えを、聞き取り、話し、のなかで自由に切り替えることが基本だ。Topicファイルも新しいものにするが、コンセプトやルールの基本的なものはそのままにしたい。私がほとんど使わない機能は組み込まない。だから、結構シンプルなものになると思う。

英語と日本語の混在

英語と日本語の混在としては、ALSpeechRecognitionでは、言語設定を日本語にして、ALTextToSpeechでは、言語設定を英語にする、あるいはその逆にしたりできれば良い。
ALSpeechRecognitionは、文脈ファイルに依存させるので、その言語は、ALSpeechRecognitionの言語設定と同じにしておかなければならない。これについては、かなり自由に操作できるようになった。その認識した言語に沿って、もう一方、トピックファイルには、そのリアクションも書かれているので、それを読み取って、speechrecognitionのイベント処理をやるメソッドを作成すれば良い。
まず、トピックファイルから、うまく、リアクション情報、すなわち喋る情報を取り出す部分を完成させよう。もう、ほぼ、頭の中では出来上がっている。

TopicファイルからBNFファイルへのコンバーター作成

基本ALDialog軸にやってきたが、英語日本語を混在させたりすると、ALDialogではうまく対応できないことがわかって、ALSpeechRecognitionレベルで対応することが便利になってきた。
そこで、どうしても必要になったのが、音声認識の文脈情報を与えているBNFファイルの作成だった。直接作成してもいいのだが、一番いいのは、qichatで書かれたTOPICファイルをBNFファイルに変換することだ。もちろん、これはNAOQIでやれる。ある意味、ALDialogを使っているうちに作成してくれるのだが、そのタイミングが理解できない。実に面倒なのだ。一旦作成してくれれば、ALSPeechRecongnitionで、コンパイルしてlcfというバイナリファイルを作成して、極めて効率よく、ロボットは聞き取りしてくれる。
昨日から今日にかけて、必死で作って、ようやく、まあ、そこそこ正しく作れたようだ。いくつか問題もあるが。ちゃんとロボットは作成したBNFファイルをコンパイルできていて、また、アクティベイトすると、正しく聞き取りしてくれる。
作成した、IbotBnf170328Japanese.bnfというBNFファイルをロボットに転送して、文脈に加えて、活性化させて、登録する。手順をpython SDKでやると以下のようになる。これで聞き取りできるようになった。
>>> from naoqi import ALProxy
>>> spr = ALProxy("ALSpeechRecognition","192.168.1.xx",9559)
>>> spr.compile("/home/nao/.local/share/dialog/IbotBnf170328Japanese.bnf","/home/nao/.local/share/dialog/IbotBnf170328Japanese.lcf","Japanese")
>>> spr.addContext("/home/nao/.local/share/dialog/IbotBnf170328Japanese.lcf","IbotContext")
>>> spr.activateAllRules("IbotContext")
>>> spr.pause(False)
>>> spr.getRules("IbotContext","active")
['IbotBnf170328Japanese#start', 'IbotBnf170328Japanese#take170320 trig']
>>> spr.subscribe("MySpeechRecognition")
>>> spr.unsubscribe("MySpeechRecognition")
聞き取った内容を、受け止めるのは、WordRecognizedのイベントを受け取ってやるので、それはまた別な作業なのだ。

日本語と英語のクロス

ロボットに日本語で問いかけると英語で答える、英語で問いかけると日本語で答えるようにしたいと思って、前回の記事のように、ALDialogでやろうとしたが結局破綻した。
そこで、もっとCoreなところにかえって、ALSpeechRecognitionでやったら、うまくいった。
結果はYoutubeに掲載した。

日本語と英語の会話をさせる

(この記事の方法は破綻した -> 参照
日本語を聞き取って、英語を喋らせたり、英語を聞き取って日本語を喋らせたいと思った。
意外と面倒だった。本当は簡単にできるのかもしれないが。ここまで得た知識でなんとかなりそうなので、記録しておく。
これをやらせるためには、日本語を聞き取った後で、すぐに、ALDialogのsetLanguageを実行させて、英語に切り替え、英語を喋らせるようにすれば良い。ただし、一つのtopicファイルには、英語か日本語のどちらかしかプログラム化できないので、日本語を聞き取った後に、英語のtopicファイルにある、ルールをイベントで起動させることが必要だ。
何れにしても、英語と日本語のtopicファイルを同時にloadTopicをさせなければならない。
ここで大事なことをいかに整理する。
(1)聞き取りのためには、$HOME/.local/share/dialog/ 以下にあるbnfファイル(文脈処理)が必要だが、これはシステムが作る(自分で書いてもいいようだが、何しろ、このフォルダはALDialogが管理しているので、あまりいじらない方がいいよと思う)。このシステムファイルは、コンパイルされて、lcfファイルに変換される。
(2)この文脈処理ファイル群は、ロボットがスタートして、ALDialogがロードされて以降は、ALDialogが管理しているようで、その後勝手に、削除したりするとエラーが報告される。
(3)今まで日本語をやっていたのに、新たに英語のファイルを付け加えると、いろいろトラブルが起きる。
(4)一旦、文脈ファイルができると、別なトピックファイルが組み込まれても、その変更だけになり、新たにbnfファイルが作成されたりしない。
(5)ALDialogには、compileALLというメソッドがあって、これは文脈ファイルつくるのだが、bnfファイルがないときは、それを作成するきっかけにもなる。
(6)何もなければ、すべてのトピックファイルがloadTopicでロードした後に、compileAllを実行するとうまくいくみたいだ。
(7)その後、setLanguageで言語を切れ変えれば良い。
(8)日本語と英語を切り替える上では、それぞれのトピックファイルが共通のトピックを持っているようにするべきだ。
何しろ、文脈ファイルが決定的に重要な意味を持っている。
(追記)上の方法でもうまくいかない。どうしても、日本語のBNFしかつくらないときは、次の方法をとる。
(1)$HOME/.local/share/dialog/ にあるファイル(bnfファイル)等を一旦全て削除する。
(2)ロボットを再起動する
(3)pythonのnaoqi sdkを起動する(PCでいい)。そして、以下のようにやる。
>>> from naoqi import ALProxy
# ALdialogのオブジェクトを取得
>>> dlg = ALProxy("ALDialog","192.168.xxx.xxx",9559)
# 日本語と英語のトピックファイルをロードする
>>> dlg.loadTopic("/home/nao/ibot/user/topic/test170323-enu.top")
'test170323'
>>> dlg.loadTopic("/home/nao/ibot/user/topic/test170323-jpj.top")
'test170323'
# コンパイルする
>>> dlg.compileAll()
これでできるはずである。あとは、bnfファイルを気にせずにやれば良い。というか、二度とbnfファイルを直接いじらない

Docomo API 音声出力結果Jsonファイルのパース

Docomo APIの音声出力は、Jsonファイルとして返される。それをJavaで構文解析をする。使わせていただいたのは、以下のサイトにあるパーサー。
https://www.tutorialspoint.com/json/json_java_example.htm
要領とサンプルを掲載しておく。
(1)サイトから、ソースをダウンロードし、ライブラリ用のjarファイルを作成する。JsonSimple.jar
(2)以下のソースのライブラリに加える。jsonと配列の処理が頭の中でごちゃごちゃになる。(なお、上記サイトのデコードサンプルは、そのままではエラーになる。なんでそんなものを?)

import java.io.BufferedReader;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import org.json.simple.JSONObject;
import org.json.simple.JSONArray;
import org.json.simple.parser.ParseException;
import org.json.simple.parser.JSONParser;
public class JsonParserTest {

    String readJsonFile() {
        // 出力結果をファイルから読み込む場合
        // 通常は、httpレスポンスをそのまま、次のparseJasonで解析すれば良い
        String json = "";
        try {
            File file = new File("/path/to/docomo_output.json");
            BufferedReader br = new BufferedReader(new FileReader(file));
            String str;
            while ((str = br.readLine()) != null) {
                json += str;
            }
            br.close();
        } catch (FileNotFoundException e) {
            System.out.println(e);
        } catch (IOException e) {
            System.out.println(e);
        }
        return json;
    }

    void parseJson(String json) {
        JSONParser parser = new JSONParser();
        try {
            JSONObject obj0  = (JSONObject
            )parser.parse(json);
            //認識テキストの出力
            //出力テキストの全体は、textタグを読み取れば良い
            System.out.println("出力テキスト");
            System.out.println(obj0.get("text"));
            // 以上で良いのだが、分かち書きされた分析結果も受け取るようにして見る
            // resultの値は、配列になっているので、まずその配列を受け取る
            JSONArray results_array = (JSONArray) obj0.get("results");
            // 配列の最初の要素を取り出す
            JSONObject obj1_tokens  = (JSONObject
            )results_array.get(0);
            // 配列の最初の要素が"tokens"というJsonになっているので、それをうけとる
            // そのtokensの値が配列になっているので、配列として受け取る
            JSONArray array1_tokens = (JSONArray) (obj1_tokens.get("tokens"));
            // tokensの配列をループにして回す
            for (Object ob : array1_tokens) {
                JSONObject job = (JSONObject) ob;
                String written = (String) job.get("written");
                System.out.print("書き方:" + written + ",");
                double confidence = (double) job.get("confidence");
                System.out.print("信頼性:" + confidence + ",");
                String spoken = (String) job.get("spoken");
                System.out.println("読み:" + spoken);
                // 他の要素は省略
            }
        } catch (ParseException pe) {
            System.out.println("position: " + pe.getPosition());
            System.out.println(pe);
        }
    }

    public static void main(String[] args) {
        JsonParserTest jparser = new JsonParserTest();
        jparser.parseJson(jparser.readJsonFile());
    }
}

Docomo API の音声認識は使える

Google Cloud APIが何かと使いにくく、レスポンスも遅いのでDocomo APIの音声認識を試してみた。結果的に、Googleより倍速い。認識率も悪くはない。使える。
以下の文章googleだと6秒以上かかるが、Docomoだと4秒かからない。
{
,"confidence":0.700,"starttime":0,"endtime":8300,"tags":[],"rulename":""
,"text":"今日はネタをやりますお客さんからお題をもらって、この第2ついて扇子とか、なぞかけに答えてもらうというもので、"}
}

word2vecのスレッド利用

wprd2vecで、ユニット数を倍の400にしてやってみた。5,6時間かかりそうなので、スレッドを16にしてやってみたら超早い。MacProが8コア、16スレッドなのだが、それを目一杯使っている姿初めてみた。

NAO、コンセプトの搭載可能数

Pepperは、クラウドで、qichatのワイルドカード認識に対応しているようなのだが、NAOについては、NAOQIバージョンもPepperほどにも更新されておらず、対応していないようだ。それはそれでいい。というのは、Qichatでは、conceptにリストアップしておけば、ロボットはかなり正確に人の言葉を認識できるからだ。だから、conceptにどれだけのワードが載せられるかは、非常に重要な仕様になっている。
まえから、幾つもに切り分けしていれば、500個以上のコンセプトを識別できることはわかっていた。それは、実際使っているものだ。
しかし、一つのconceptのなかに、幾つ詰め込むことができるかは調べたことがなかった。実は、多くのコンセプトに分けるよりも、一つに詰め込むと便利なことがある。とても便利になるのだ。今日試してみてとても驚いた。なんと、一つのコンセプトに、2000個以上のワードを詰め込んでも、識別できたのだ。つまり、トピックファイルの中に、
concept:(words) [今日 明日 ロボット などなど ・・・・・・]
と2000個以上の言葉をwordsというコンセプトで登録しておいても、たとえば
u:(お題は _~words です) なになに $1・・・・・・
というかたちで、言葉の認識、変数 $1 への代入が可能になるのだ。もちろん、ALDialogで、そのトピックファイルを読み込み、コンパイルするのには多少時間がかかる。20秒くらいか。それは、スタート時だけだから、全然大したロスではない。
2000個も入れると、言葉の中に変な文字、つまり、ロボットが発音できない文字が入っていると、コンパイルに失敗してトピックファイルが有効化されない。アンダースコアとか、全角の数字(これがエラーになるのはちょっと不思議だが)とか、「つ」の小さい版「っ」がワードの最後に発音しにくい形で入っていても、コンパイルエラーになった。しかし、数の大きさは平気だったのだ。
NAOがワイルドカードの認識が下手なので、やむ負えず、Googleのcloud APIで変換させたりしていたのだが、音源ファイルで送ろうとも、ストリーミングにしようとも、やはり、人が喋ってからその結果をロボットに返すまでに10秒余のロスが発生して、ネタの120秒などという短い尺には、耐えられない長さになってしまう。conceptにおいて、聞き取られレベ、ほぼリアルタイムで時間のロスがない。
2000個というのは相当のキーワード数だ。実際それ以上が可能かもしれない。それ以上を試す気になれないほど、2000という数字は大きかった。