Raspberry Piあれこれ

USBカメラが認識されず対処したら割当デバイスが変わった？

　サブパソコンとして使っている(というほど使ってないですが)ラズパイ3B+においてタイミング的には、bullseyeにアップグレードした後、USB|Webカメラの認識に変化が。

　bullseyeへのアップグレード後も認識はされていたはずのUSB|Webカメラですが、今日試してみたら、いくつかあるカメラ全てCheeseでもguvcviewでもgst-launch-1.0でも表示されないことに気づきました。

　v4l2-ctl --list-devicesしてみるとbcm2835-codec-decodeやら、bcm2835-ispに複数の/dev/video*デバイスが割り当てられている一方、[Cannot open device /dev/video0, exiting.]となり、従前あった/dev/video0がない...。

　これらをキーにカメラの有効化にたどり着いてみると/boot/config.txtの[all]下に[start_x=1]、[gpu_mem=128]を追記せよとあり、自身の環境では項目自体はあるものの、前者の値が0だったので変更後、再起動してみると確かに/dev/video0が復活していました。

　が、USBカメラを抜いて再度挿し込むと/dev/video0喪失、どうしたことかとv4l2-ctl --list-devicesしてみれば、/dev/video1などに各USBカメラが割り当てられていました。

　Cheeseやguvcviewは起動後、設定からカメラを選択すれば、gst-launch-1.0も妥当な/dev/video*デバイスを選択すれば、つなげた2種のカメラ共、認識、映像表示されました。

　が、結構不安定でこれらアプリの内、GUIアプリの1つが表示できなくなったり、デバイスがbusyになってUSBポートにカメラを挿し直すと正常になったり...。

　guvcviewはつないだカメラをデフォルトと認識する一方、以前からですが、同一カメラに2つ選択肢があり、常に選択を求められ、一方のみ有効、他方はエラー。

　Cheeseでも同様、Cheeseでは、起動後のデフォルトがbcm2835-ispになっている...、bcm2835-ispなんて以前はなかった気がしますが、一体これはなんぞや？どうすれば、つないだカメラをデフォルトにしてくれるのか...。

　そもそも/boot/config.txtの値をいじらなくても普通に認識され、表示されていたのに、なぜ、ここでこれを書き換える必要があったのか...、4Bとの兼ね合い、bullseyeの仕様変更？

有線/無線共にIP固定化

　いろいろあってパソコンやスマホ(Android)からLAN内から、また、VPN越しのLAN内でESP8266/ESP32/Raspberry Pi製等々の自作スマートホームガジェットなどのアクセスを確認している中でRaspberry Piライブ・見守り・防犯等々カメラサーバにおいてeth0、wlan0共にIPアドレスを固定化した話。

　ESPモジュールやラズパイ2Bもドングルをつけない限りは有線のみですが、ラズパイ3B+製スマートスピーカーやこのカメラサーバは、有線も無線も使えます。

　今のところ、スマートスピーカーの遠隔操作はパソコンからのみですが、カメラサーバは、mDNSを素直に使えないAndroidからも表示・操作することもあり、Androidの場合、VNC経由、または、独自アプリでも作らない限り、ブラウザ表示するにもIP直指定を要します。

　当初は、eth0の固定だけでアクセスできていたカメラサーバ、別件でDHCPサーバを初期化したりしていたからか、なぜか、今日になってwlan0を優先して認識するようになり、eth0を前提に考えていたAndroidからのIP指定に誤算が生じました。

　これに対し、最初は、wifiパワーマネジメントを無効にするのようにwlan0を無効にしようと思ったのですが、今回の場合、消費電力云々は無視するとすれば、そこまでせずとも/etc/avahi/avahi-daemon.confでallow-interfaces=eth0(か、deny-interfaces=wlan0)とすれば良さげも、電源さえ確保できれば、LANケーブルに縛られない可搬性とか、内蔵無線LANに不具合があった場合などを考えると、どっちも使うっていう手もあるかというわけでeth0もwlan0も固定することにし、Androidには、ホーム画面にカメラ用のブラウザショートカットを2つ用意することにしました。

　ちなみにmDNS(Avahi)が使える環境だけ考えれば良いのであれば、そうするまでもなく、/etc/avahi/avahi-daemon.confでallow-interfaces=eth0(か、deny-interfaces=wlan0、もしくはdenyが優先されることを利用して両方)とすれば良さげですが。

　IPアドレスを固定していないものについては、IPが変更になった場合、IPアドレス指定のAndroidについては変更を要しますが、AndroidでmDNS前提ブラウザ版スマートホームパネル操作に書いたように対処すればよいかと割り切っています。

　Raspbian(今はRaspberry Pi OSか)は、Debian系であり、最新は、/etc/network/interfaces(/etc/network/interfaces.d)ではなく、/etc/dhcpcd.confを編集するようになっているのでそうしましたが、どちらにもloの行はいるのかわからないものの、念の為、interfaces.dにもネットワークインタフェースごとにeth0.confとwlan0.confを併せて追加しました(後者は、以前作ったようで既にありました)。

　もちろん、指定する固定IPについては、メインルータなどのDHCPサーバで配布されない任意のIPアドレス範囲を確保しておく前提です。

Juliusの認識精度に異変！？

　我が家には、ラズパイスマートスピーカーと、この自作スマートスピーカー機能をパソコン/Debian(Linux)にも入れて運用中で、PC版で検証後、ラズパイ版に反映させており、いわば同期を取っています。

　が、ESP-01/12/ESP32でSHARP AQUOS TVをWiFi操作する機能を実装、自作ラズパイスマートスピーカーでテレビを音声操作できるようにしたところ、ラズパイ版スマートスピーカーでもパソコン版スマートスピーカーでも急にJuliusの認識精度が見る影もなくガタ落ちしてしまった...。

　なぜか、ラズパイ版が先にこの症状に見舞われ、1日遅れ程度でパソコン版スマートスピーカーも同様となりました。

　何れも少なくとも機能追加した直後は、何の問題もなく、音声認識できていたため、辞書追加に起因しているようだということに、気づくのが遅れました。

　Juliusでは、dictation-kit 4.4を使っており、-moduleモードを外し、入力モード？として確認、明らかに認識精度が落ちていることに気づき、オリジナル辞書からテレビ操作関連を除いた(バックアップから元に戻した)ところ、何れのスマートスピーカーでも以前のように正常に認識、機能するようになりました。

　このテレビ操作用に追加した辞書は、パソコン版からscpコピーしたものを使ったのでパソコン版とラズパイ版は同じもの。

　「テレビつけて」「テレビ消して」は以前から登録済みなのでさておきます。

　茶色の太字部分が、テレビ操作用に追加したもので、これらを削除し、元に戻したら、ラズパイスマートスピーカーでも、あっさり、音声認識できました。

　これは、ファイルエンコーディングがutf8ですが、もちろん、Julius dictation-kit-v4.4用辞書として反映させるには、eucjpに変換する必要があります。

　テレビ関連の操作ワードしか考えなかったけど、他の家電と被るワードは、「テレビの」など枕詞を付けないと区別できなくなるので注意。

　ちなみに気づけば、[今日]の読み[ky o]に長音記号[:]や[u]を付け忘れていますが、なぜか、影響なく、ちゃんと機能しています。

　そこで今度は、テレビ操作用ワードを割と実用的なもの、チャンネルと音量、要らないかもしれませんが、番組表と番組情報だけに絞ってみることにしました。

　ちなみに音量については、「テレビの」も追加してみました。

　現在のところ、認識精度に違和感なく、正常に機能している...ので様子見。

　ワード数の限界？というほど多くありませんが...標準辞書も含めるとオーバーってことか？それともエラーにはならかなったものの、実はJuliusを惑わせるNGワードがあった？

　尚、Juliusの認識精度は、デフォルトのスピード重視しつつ、精度も良いモードであり、これを精度重視にもできるとはありますが、精度向上は、1%程度とあり、あまり意味はなさげと思い、試してはいません。

　ちなみに激安USBハブに起因するのか、修正後、PCを再起動するとUSB系のエラーが出たり、これが出ず、PCに挿し直しても、なぜか、マイクを認識しなくなることがあり、sudo modprobe snd_usb_audioしてみたら、PCに挿した状態では、認識するようになりました。

　と思いましたが、そもそも直挿しのラズパイでも同じようなことがあったため、USBハブの問題はさておき、sudo modprobe snd_usb_audioする必要に迫られることもある模様。

　ただ、実行前後でsudo modprobe -cした時にsnd_usb_audioの設定値は変わってないんだけど、たまたま改善されたように見えただけで実は、この操作関係ない？

Juliusの単語辞書と文法辞書

　Julius/Open JTalkベースの自作ラズパイスマートスピーカー、ESP8266/ESP32による自作スマートリモコン、自作スマートコンセントがあるのですが、家電を無線操作するにあたり、Juliusの辞書の扱いをイマイチ理解できていないのか、判然とせず、明快な答えを探しています。

　現在は、単語辞書で実装して、うまく機能しているので良いのですが、文法辞書を併用すれば、単語辞書の行数を低減できつつ、より柔軟に音声を認識してくれる気がしなくもないと思うのですが、考えれば考えるほど、やっぱり、そうはならない気がする...。

　いや、音声の認識だけでよいのなら、併用すれば、思惑通りにはなりますが、Juliusから応答スクリプトにテキストを渡そうとすると...。

　もちろん、単語辞書は「単語」であり、文法辞書が「文法」なのは、わかるし、単語辞書を補う形で文法辞書を併用できることもわかる。

　つまり、「テレビ」「エアコン」「扇風機」などにおいて重複させることなく「つけて」「けして」などを共用できることはわかる。

　が、単語辞書なら、第2フィールドの[]でJuliusから出力するテキストを明示できますが、文法辞書では、たぶんできない。

　となると応答スクリプト側でテキストを受け取ることを考えた場合、操作呼びかけワードに「揺れ」があるとすると、この揺れのバリエーションを含めて複数行を「単語辞書」に書くことになるんだよね？だとしたら、文法辞書で揺れを補完できても意味ないんじゃ？というのが、自身の今の認識。

　たとえば、「テレビをつけて」「テレビつけて」「テレビONして」という音声の場合、それら全てを[テレビをオン]とテキスト出力させたい場合、単語辞書にそれら3行を全て書くことで実装できます。

　でも、これを文法辞書で「つけて」「をつけて」「ONして」を「扇風機」などと共用できれば、より合理的に辞書を作ることができそう...だけど、そうだとしたら、「単語辞書」の出力テキストとなる[テレビをオン]を応答スクリプトに渡すためには、「単語辞書」においてテレビをつける操作の場合、その行の第1フィールドをどう書けばよいのか？という疑問が残る。

　仮に文法辞書で助詞や後置子を共用して単語辞書に「テレビ」と書くとして「をつけて」「つけて」「ONして」全てのバリエーションを音声として正しく認識はしてくれるのでしょうが、これらが何れも「テレビをつける」という意味であることを認識することは、できない...できるとすれば単語辞書の出力テキスト[テレビをオン]しかないのではないか？...と。

　結局、この場合、文法辞書を使わず、単語辞書に3行書くしかないってことなら、自身の認識と合致はするけど、なんかモヤモヤする...みたいな。

　第7章 言語モデル by Juliusが、これに関わると思われますが、自身が読解できていないだけ？

　ん？「つける」と「けす」...を別々の文法辞書にすればよいのか？

　「つけて」「をつけて」「をONにして」など「つける」意味のみから成る文法辞書を作成しつつ、単語辞書には、その一例としてテレビなら"テレビをつけて [テレビをON] t e r e..."と書いておけば、「テレビつけて」「テレビをONにして」と音声操作しても認識してくれる...のか？

　でも、それだと「テレビの音量上げて」、「テレビの音量下げて」...も別々の文法辞書になってかえって非合理的か...んーーー...。

　気づけば、2019/01/03にリリースされてたJulius 4.5に乗り換えつつ、検証してみようかな...。