RON-V #24 — RONV1 / RONV2の実機構成・UPSの接触不良・復旧用バックアップ

RON-V 連載リンク
← 前の記事：#23 — 4モデル画像AIと根拠画像の保存・転送
→ 次の記事：準備中

実機構成と保守の記録（2026-10-20）

機器の接続、UPSの通信不良への対応、復旧パッケージとSDイメージを別媒体へ保存したところまでを整理します。

はじめに

RON-Vは、Raspberry Pi 5にカメラ・無線・車両側の機器をつないだ観測ノードです。前の記事で扱った画像AIを含め、「どうつながっていて、故障や更新にどう備えるか」を説明します。

接続する機器	接続・役割
AtomS3R	USB SerialでCAN／OBD-IIの記録、ボタン・衝撃イベントを受け取る
RTL-SDR Blog V4	USB接続。RF測定とLTEのcell searchで共用する
USB GNSS	観測の位置・時刻を得る
Logicool C270	USB接続。RingCamで画像を蓄え、イベント時に保存する
Meshtasticノード	構成に応じてメッシュ通信に使用する
UPS	電源状態を監視し、安全にLinuxを停止する

写真を追加するなら、この表の後に機器全体、7節にUPSとPiの接触部を置くと、文章と照合しやすくなります。これは接続の概要で、端子ごとの製作配線図ではありません。

1. RONV1とRONV2

RONV1は比較の基準と実車評価、RONV2は新機能の先行導入に使います。アプリケーションはGitHubの共通コードを使い、ノード別の設定はそれぞれの config/ronv.toml に残します。

今回の更新後、両機で cd0a94e のコードと同じ4モデル構成を確認しました。Wi-Fi、認証情報、保存先、UPSなどのノード固有設定を、もう一方のPiの設定で置き換えないことが重要です。

対象	管理・保存する場所
アプリ、設定例、導入スクリプト	GitHub
そのPi専用の設定・認証情報	実機。復旧用には暗号化して保存
ONNXと保存済みの学習済みモデル	Gitとは別のバックアップ
観測のDB・画像・結果	Pi内に保存し、通信可能なときに外部へ転送

GitHubのコードを取得するだけでは、認証情報、モデル本体、観測データまで復旧できません。

2. Raspberry Pi 5の役割

PiではSQLiteへの保存、各観測機器の処理、カメラ撮影、画像AI、Web・Grafana、非同期転送、UPS監視を動かします。

外部通信が止まっても、観測結果をPi内へ残す構成です。DriveやSheetsへの送信は別の処理で行い、撮影・保存の成否と転送の成否を分けて記録します。

3. AtomS3Rとカメラ

AtomS3RはCANのListen Only、条件を満たした場合のOBD-II Mode 01、IMUのSHOCK、ボタンのMARKERなどを担当し、USB SerialでPiへ伝えます。詳しくは #21を参照します。

PiのRingCamはカメラの画像を蓄えます。BUTTONで代表画像を保存し、SHOCKでは発生前後の6枚を選び、代表画像を道路・冠水・煙・視界の4モデルへ渡します。撮影処理とAI、L3／L4、Drive・Sheetsの関係は前の記事で扱いました。

Serial機器は可能な限り /dev/serial/by-id/ を使い、挿す順序で変わる機器名への依存を避けます。別ノードのUSB固有IDをそのままコピーしないようにします。

4. RTL-SDRとGNSS

RTL-SDR Blog V4はRFとLTEで共用します。同時に使わないよう /tmp/ronv-sdr.lock で排他制御します。USBから消える場合に備え、SDRの状態確認とUSB電源の回復処理も用意しています。

GNSSは「いつ・どこで」の基準です。位置が取得できなかったイベントも、記録自体を捨てず、位置未取得の状態を区別して扱います。

5. 電源・USB・発熱をまとめて確認する

Pi本体だけでなく、カメラ、SDR、GNSSなどにも電力が必要です。車載では、車両電源、DC-DC、UPS、USB機器、起動時の負荷、ACC OFF後に停止する時間まで合わせて考えます。

単に起動できるかに加えて、機器が途中で消えないか、ケーブルに無理がないか、熱がこもらないかを確認します。車載時の長時間運転や固定方法は、今回の机上確認とは別の評価対象です。

6. UPSの構成

ノード	監視するハードウェア	外部電源の判定
RONV1	INA219を使う構成、I2C 0x42	放電電流を利用
RONV2	Geekworm X1201、MAX17040、I2C 0x36	GPIO6を利用

RONV1の表はこれまでの構成の整理で、今回の接触不良の調査対象はRONV2です。

RONV2の設定では、外部電源の喪失を20秒確認すると安全停止を要求します。また、UPSを読み取れない状態が30秒続いた場合も停止を要求します。充電できていても、PiからUPSの状態を読めなければ停止することがあります。

状態は /run/ronv/ups-status.json へ出し、ronv-ups-guard.timer が監視します。ronv-ups-shutdown.path が停止要求を受けます。RONV2では以前に外部電源断からの安全停止と給電復帰時の起動も確認していますが、今回改めて行ったのは次節の通信回復確認です。

7. RONV2が起動後に停止したとき

充電ランプだけでは原因を判断できなかった

起動からしばらくするとRONV2が停止しました。X1201の電池は充電されていましたが、UPSの状態には次のエラーが出ていました。

status: UPS_READ_ERROR
OSError(121, 'Remote I/O error')

この時点では電池電圧を読めず、残量不足かどうかも分かりません。I2Cアドレス 0x36 にも応答がありませんでした。読み取りエラーが継続すると停止する設定と一致する状況です。

脱着・清掃後に読み取りが戻った

PiとUPSの接触部を確認し、脱着・ポゴピンの清掃後に再確認しました。接触部を扱う際はLinuxを停止し、外部電源・電池・USBからの給電を外します。

その後、5秒間隔で7回、約30秒間にわたって読み取れました。

項目	読み取り結果
電圧	約4.216〜4.218 V
残量	100%
外部電源	True
監視状態	NORMAL

調査中に停止していたUPS監視と停止要求の監視も、有効化して active に戻しました。夕方のプログラム更新後も NORMAL、約4.21 V、外部電源ありを確認しています。

接触状態を変えると通信が回復したため、接触不良が有力です。 ポゴピンだけが唯一の原因と断定したわけではありません。再発する場合は、基板の固定・接点・I2C配線や給電状態も含めて確認します。保護機能を止めたまま使う対応にはしません。

状態を確認するコマンド

以下はRONV2の状態確認です。UPSを停止させるコマンドではありません。

cat /run/ronv/ups-status.json
systemctl is-enabled ronv-ups-guard.timer ronv-ups-shutdown.path
systemctl is-active ronv-ups-guard.timer ronv-ups-shutdown.path
sudo journalctl -b -u ronv-ups-guard.service -u ronv-ups-shutdown.service -n 20 --no-pager

NORMAL と監視の有効状態を両方確認します。状態ファイルの日時が古ければ、最後の値だけが残っている可能性もあるため、更新時刻とログも見ます。

基板については Geekworm X1201公式を参照します。

8. Wi-Fi設定の消失と、接続できない状態を区別する

今回、家庭内の5 GHz側SSIDへ接続できない問題もありました。Piには5 GHz・2.4 GHz側の設定とパスワードが保存され、5 GHz側の過去の接続時刻も残っていました。Windowsでも5 GHz側へ接続できず、ルーター再起動後に接続できるようになりました。

この記録から「GitHub更新でWi-Fi設定が消えた」とは判断していません。ルーター側の不調を示す状況はありましたが、内部の原因まで特定したわけではありません。この件の追跡はここで終了しています。

HDMI画面に出ていた 172.17.0.1 はDockerの内部ネットワークでした。この値が見えてもWi-Fi接続済みとは限りません。現在の接続先とWi-FiのIPは、次で確認できます。

nmcli -f GENERAL.CONNECTION,IP4.ADDRESS,IP4.GATEWAY device show wlan0

9. バックアップは3種類を分けて残す

今回の保守が一段落したところで、RONV2のバックアップを取りました。

保存物	入るもの	復旧時の役割
GitHubのコード	アプリ・設定例・導入手順	プログラムを取り直す
復旧パッケージ	モデル、構成記録、暗号化した設定・認証情報・SQLiteなど	そのノードの設定とデータを戻す
SDの復旧用イメージ	OS・導入済み環境・保存データを含む起動用イメージ	別のSDへ環境を戻す

同じSD内のコピーだけでは、SD故障への備えになりません。復旧パッケージをWindowsへ退避し、USBメモリーへSDイメージと一緒に保存しました。

9-1. 計測を止め、再開できる状態を残す

保守では ronv-measurement-control を使いました。計測処理の停止前の状態を記録し、終了後はその時に動いていた処理を戻します。Web、SSH、ネットワーク、Grafana、UPS監視は維持します。

sudo /usr/local/sbin/ronv-measurement-control status
sudo /usr/local/sbin/ronv-measurement-control stop

これはLinuxのシャットダウンではありません。バックアップ終了後は、成功・失敗にかかわらず状態を確認し、計測を再開します。

sudo /usr/local/sbin/ronv-measurement-control start
sudo /usr/local/sbin/ronv-measurement-control status

以下は実施内容の記録です。保存先の確認やエラー時の再開を含む一括手順は 復旧用バックアップの手順と実機のスクリプトを確認します。リポジトリを読む権限が必要です。

9-2. 復旧パッケージを暗号化して保存する

tools/ronv-backup を使い、設定、認証情報、Wi-Fi接続設定、SSH関連、SQLiteの整合したスナップショットなどを収集しました。秘密情報はパスフレーズで暗号化し、復号確認も行いました。

公開用の構成記録と、暗号化した秘密情報は分けています。モデルはONNXに加え、手元に保存してあった道路・冠水の best.pt も追加しました。今回のパッケージは約44 MBで、全体とモデルのSHA256を確認しています。

モデル追加後は照合一覧も作り直しました。以前のスクリプトでは照合一覧自身が対象に入る箇所があったため、モデル用はその一覧自身を除外し、全体用は最上位の一覧自身だけを除外して再作成・検証しました。本文のログは、この補正後の成功結果です。

Windowsへコピーした後にもSHA256が一致しました。パスフレーズはバックアップ本体とは別に保管します。暗号化したファイルがあっても、パスフレーズを失うと復旧できません。

9-3. USBへSDの復旧用イメージを作る

今回は約64 GBのmicroSDを使い、ルート領域の使用量は約12 GBでした。空き容量を確認した約256 GBのexFAT USBメモリーへ、既存の image-backup で復旧用イメージを作りました。

image-backup は、ファイルをコピーして起動用のパーティションを含むイメージを組み立てます。64 GBのカード全体をそのまま読み出す方式とは異なり、今回の保存サイズは約16 GBでした。

USB側には、次の3ファイルを同じフォルダーへ保存しました。

ファイル	用途
RONV2_20261020_205141.img	SDへ書き戻すための復旧用イメージ
RONV2_recovery_20261020_203818.tar.gz	暗号化した秘密情報などを含む復旧パッケージ
SHA256SUMS	上の2ファイルの照合値

既存ファイルを消したりUSBを初期化したりせず、日時付きの新しいフォルダーへ保存しました。保存先の装置名とマウント先は、毎回 lsblk、findmnt、df -h で確認します。/dev/sda1 が常に同じUSBとは限りません。

9-4. 完了の確認をする

検証	今回の結果
SQLiteスナップショット	整合性確認OK
秘密情報の暗号化・復号確認	OK
復旧パッケージとモデルのSHA256	OK
Windowsへ退避後のSHA256	一致
イメージ内のFAT・ext4の読み取り専用検査	OK
USB上のイメージと復旧パッケージのSHA256	両方OK
計測再開	mode=running、対象サービスを再開
USBのアンマウント	完了
別のSDへの書き戻し・起動試験	未実施

最後に sync とアンマウントを行い、USBを取り外せる状態にしました。

ファイル検査とSHA256が通ったことと、予備SDから起動できることは別です。今回の記録では「復元して起動まで確認済み」とは書きません。次の復旧確認は、予備SDへ書き戻して起動し、ノード名・ネットワーク・UPS・モデル・観測と転送を確認する作業です。秘密情報を含むSDイメージ自体も公開しません。

10. 写真とログを公開するとき

全体写真では機器の型番と接続を、UPSの写真では取り付け位置や接触部を見せると説明しやすくなります。Wi-Fiのパスワード、認証トークン、QRコード、個体のserial、車両情報、自宅位置が分かる地図などは掲載前に確認します。

次の実車試験では、取り付けの固定、ケーブル、熱、電源断時の挙動、長時間の記録と転送を評価します。