Raspberry Piあれこれ

Raspberry Pi 3B+を更に1台ショートさせてしまった

　7年経過の2Bが今尚健在な中、共に5年経過の3B+ 1台に続き、更にもう1台と2台立て続けにショートさせるというアホさ加減...。

　ラズパイフォーラムの1つに、よくあるケースという話とヒントについて触れられていますが...。

　おっと「Raspberry Pi3の電源が入らなくなった！」原因と不良部品の特定。によれば、ラズパイの電源投入中におけるラズパイカメラのフレキの脱着に起因する可能性が高いことが指摘されています...。

　自身は、これをなんの迷いもなく、何度もやらかしており、思いっきり自覚ありなので原因は、それに間違いなさそうです。

　先日ショートさせた1台もラズパイカメラが届いた翌日...原因はDACじゃなくて、同じでしょ、きっと.......。

　更に同じ方の記事「ラズベリーパイの電源が入らない症状」自力で修理してみた！でIC交換した結果、ICが異なるのか直らなかったとのこと。

　ですが、メーカーのMx7704仕様書によれば、Mx7704-Aは、まさにARM® Cortex®-based processors (A7, A9, and A5)用に設計されたものとある一方、その前の別のリンク先でもう1つ挙げている似たようなMx7704-Xの方は、全く別の用途と書かれているのでMx7704-Aの選定自体は正解かと。

　もう1つの見立てである「他にも破損しているパーツがある可能性」が高いかと。

　尚、Raspberry Pi Dead Part 2に電圧異常箇所により、破損パーツの特定ができるとあるので参考になりそうです。

　もしかしてICはさておき、まずは、3つ並んでいるレギュレータの内、まずRG2を交換、RG1、RG3含め出力が正常になればOK、そうでなければ、おかしな値のレギュレータを交換...で復旧できる可能性もある？

　自身の2台内1台は、大中小の内、大:5.2V、中:1.8V、小:測定不能、もう1台は、大小が同じ、中が1.3〜1.4Vとなりますが、大は3.3V、中は2.5Vで小が1.8Vにならないといけないんですよね？

　っていうか、大でもかなり怪しいですが、少なくとも中小は、仮にヒートガンやホットプレートなどを使ったとしても半田除去＆はんだ付けする自信皆無...。

　よって諦めます...。

　ラズパイは今尚入手困難、少し落ち着きを取り戻しつつある模様も、まだ正規価格には戻るかどうかな状況っぽく、更に円安が追い打ちをかけ、買い増すのは躊躇...。

　一方、先日、我慢しきれず、思わず、オレンジパイゼロ3を買い、性能は申し分ないものの、OSのリポジトリまでどっぷり中国尽くしで不安が残り、バナナパイも台湾とは言え圧政気味の中国を考えると...、ポテトパイとかもそうらしく、これらにせよ、ここ数年の円安傾向からすると、西洋諸国で開発されたものは定価からして尚更、往年のラズパイくらいのスペック＆コスパ同等以下のものはなさ気でラズパイの代替も悩ましい...。

Raspberry Pi 3B+を1台壊してしまった

　デスク上をとっちらかしてラズパイ3B+にDAC＆アンプMAX98357A、その端子台にオス-オスのジャンパワイヤ挿して絶縁もせずに電源入れっぱなしで全く別の作業していてショートさせて壊した模様。

　作業中、結構な音量の破裂音がして、その時点では、ん？なんだなんだ？状態、いつになく、とっちらかってる中、破裂音じゃなくて鉄の定規が落ちて金属のゴミ箱に当たった音だったのかな？と作業に没頭。

　気づけば、ラズパイが壊れており、赤いPWR LEDのみ点灯で一向に緑のACT LEDが点滅も点灯もしない...、GPIOも5Vはきてるも3.3Vはきてない...、こりゃボードいってるよねと思いつつ、検索すると予感的中したっぽい。

　降圧レギュレータ交換すれば直る可能性がある模様も、試してみる気になるかどうかは、自分でもわからない。

　ここ数日、自作予定のドア外監視カメラ兼ドアホンの監視カメラ兼スピーカー＆マイクに3B+を使い、ドアホン子機取付場所にArduinoOTAやmDNSも機能として入れてあるFreenoveのESP32-S3カメラボードとドアベルを付けようとか、次から次へとアイデアは湧いてくるは、想定したものが予定通り形になっていくは、作業は捗るは、怖いほど...と思っていた矢先の出来事。

　とりあえず、もう1つ、自作スマートスピーカーに使っている3B+をスペックオーバーながら、その素性などから使いみちにあぐねていたOrange Pi Zero 3に代え、その3B+を監視カメラで使う予定。

　買ってから7年半経ったラズパイ2Bすらサーバとして現役だっていうのに買ってからほぼ5年のラズパイ3B+を自身のミスで壊してしまった...。

カメラサーバ用SSD換装

　A-DATA ASU650SS-120GT-Rからエッセンコア クレブ SSD 240GB/K240GSSDS3-N40に換装。

　ラズパイ2Bサーバのバックアップ用2TB HDDもそろそろ...、サブとなったdynabookの240GB SSD、もう少し容量アップしておくかと、久々にAliExpressを覗いたら1TBや500GBほかSSDが激安なセラーがあり、購入していおいたのがつい最近、すると意表をついて回り回ってラズパイサーバにたどり着いたTranscend 128GB SSDが怪しくなったと言っても手持ちのSSDの中で最も古株、だいぶ年数は経っていますが。

　でdynabookで使っていた先のエッセンコア240GB SSDからGoldenfir 500GB SSDに換装、カメラサーバのA-DATA 120GB SSDをそのエッセンコアSSD 240GBに換装することにした次第。

　自作ラズパイスマートスピーカーと迷ったが、今のところ使用量はさして変わらず、スマートスピーカーはある程度作り込んだが、カメラサーバは途中ということで。

　でカメラサーバで使っていたA-DATA 120GB SSDをラズパイサーバにもっていこうかと。

localeの警告

　突然？操作による？Debianで次のようなロケールに関する警告が出るようになった話。

[bash warning: bash: warning: setlocale: LC_ALL: cannot change locale (ja_JP.utf-8)]

　自作ラズパイスマートスピーカー及びノートPC、ラズパイ400パソコンに入れてある同機能でラズパイスピーカーにある音源をmpvで再生するスクリプトをssh越しに実行しようとした時に表示されたもの。

　ただ、ラズパイ400パソコン(Raspberry Pi OS)からssh操作すると同警告が表示されたので、確認の為に試したノートPC(Debian)からのsshだと、なぜか、単に意図した操作が未完のまま終了しましたが。

　コマンド実行ではなく、自作QtパネルによるGUI操作だったからか、にしても以前、コマンドライン操作した時にも、今までは見たことがなかった警告。

　当初、その操作がエラーになったので、これ警告じゃなくてエラーなのかと思いきや、確かに単に警告であってその際のエラーの原因は指定したファイルがなかったからで、それを訂正したところ、警告は表示されつつ、再生されました。

　警告も気になるので、ついでに対処、その方法が、ラズパイスマートスピーカー側のLOCALEを修正すること。

　なんとprintenv | grep UTFしてみるとラズパイスマートスピーカーでは、[LANG=en_GB.UTF-8]となっていました。

　そりゃ、そうだ。

　そこでDebianフォーラムのmateusz.burger氏のアドバイスに沿って

sudo localectl set-locale LANG=ja_JP.UTF-8 LANGUAGE="ja_JP.UTF-8"

として一度ログアウト・再ログイン(exit、再sshして)みたら、localectlとしても、printenv | grep UTFとしてもja_JP.UTF-8となり、先の警告も解消しましたとさ。

.htsvoiceファイルにアクセスできないエラー

　aplayで再生できないエラー同様にサブのラズパイ400に自作スマートスピーカー機能の操作パネルを移植した際に遭遇したエラーの話。

[Warning: HTS_fopen: Cannot open /usr/share/hts-voice/path/to.htsvoice Error: Dictionary or HTS voice cannot be loaded.]

　要は、一般アカウントだと/usr/share/hts-voice/path/to.htsvoiceにアクセスできないよエラー。

　最近、システムパスにおいてlsすらもsudoを要求されることが増えた気がしますが、そういう方向性になってる？

　仕方ないのでsudo chown USER:USER /usr/share/hts-voice/pathとして回避。

　ただ、これまでラズパイスマートスピーカーでもノートPCに入れてあるスマートスピーカー機能でも所有はroot:root、スクリプトもユーザー権限での実行であり、対処する必要がなかったはずのエラー。

　やっぱり、仕様変更？

aplayで再生できないエラー

　スペック的にはサブながらメインとして使っているノートPCに入れてある自作スマートスピーカー機能の操作パネルをスペック上はメインながらサブパソコンとして使っているラズパイ400にも入れようと思ったら、aplayできなかった話。

[aplay: main830:audio open error: そのようなデバイスはありません]

　こんなエラーが出て何事かと思ったら、それもそのはず、ユーザーがaudioグループに入ってなかったのでsudo usermod -aG audio USERして解決。

　確かにオーディオ不要用途もあるでしょうが、他に3台あるラズパイ、後でaudioグループに追加した覚えながなかったので、かなり意外でした。

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に乗り換えつつ、検証してみようかな...。