安いの買えば?
View quoted note →
たさし
npub1t2kv...asfq
奥様とわんのすけラブ
指示したら少し増しになったよ
表現がAIくさいからあとで直そう
こんなかんじになった
Jetson Orin/Nanoでネットワークカメラの自動起動が失敗する？ systemdとethtoolで物理デバイスを待つ確実な方法
エッジAIカメラや監視システムの開発において、NVIDIA Jetson NanoやJetson Orinシリーズにネットワークカメラ（IPカメラ、GigE Visionカメラ、PoEカメラなど）を接続し、映像を取得・推論する構成は定番です。
しかし、システムを組み上げて「いざ現場へ！」と意気込んで電源を入れたものの、Jetson起動直後に実行されるはずの映像取得プログラムが立ち上がらない（カメラに繋がらない）……そんな経験はありませんか？
後から手動でプログラムを再起動すると、あっさりとカメラの映像が映る。これは典型的な「起動時のタイミングシビアな問題」です。
本記事では、Convergence Labの現場でもよく遭遇するこの問題の原因と、Jetson Orin特有のネットワークトラブル、そしてsystemdとethtoolを使った確実な解決策（技術パッチ）を解説します。
1. 現象の定義：なぜ自動起動時にカメラに繋がらないのか？
自作の映像取得アプリやROSノードなどをsystemdで自動起動させようとしたとき、失敗してsystemctl statusを確認すると、以下のようなエラーログが残っていることがあります。
Error: RTSP connection failed. Network unreachable.
# または
netlink error: no such device
「.serviceファイルに After=network-manager.service を指定しているのになぜ？」と思うかもしれません。
実はここに、ソフトウェアとハードウェアの同期ズレの罠が潜んでいます。
network-manager.serviceが立ち上がった（Activeになった）瞬間というのは、あくまで「Jetson内のネットワーク管理ソフトウェアの準備ができた」状態に過ぎません。OSが物理的なLANポート（NIC）を完全に認識し、デバイスファイルとして準備が完了するまでには、わずかなタイムラグが存在します。
プログラム側がカメラにアクセスしようとした瞬間、物理レイヤーの準備が間に合っておらず通信経路がないため、「デバイスがない」と怒られてしまうわけです。
2. 解決策その1：物理レイヤー（NIC）の出現を待つ
この問題を根本から解決するには、抽象的なネットワークサービスを待つのではなく、カメラが接続されている「物理デバイス（LANポート）そのもの」の出現を待つようにsystemdに指示を出します。
ステップ1：実際のインターフェース名を特定する
ターミナルで以下のコマンドを実行し、カメラが繋がっているインターフェース名（例：eth0、eth1）を確認します。
$ ip link
ステップ2：.service ユニットファイルの修正
カメラが eth0 に繋がっているとします。systemdにおいて、この物理デバイスは sys-subsystem-net-devices-eth0.device という名前のデバイスユニットとして扱われます。
あなたのサービスの .service ファイルの [Unit] セクションを以下のように書き換えます。
[Unit]
Description=Network Camera Application
# 物理デバイスへの依存を追加
Requires=sys-subsystem-net-devices-eth0.device
After=network-manager.service sys-subsystem-net-devices-eth0.device
これにより、「eth0というLANポートがシステムに認識されるまで、このカメラアプリの起動を保留する」という厳密なルールが適用されます。
3. 解決策その2：【Orin特有】オートネゴシエーションの罠と ethtool による強制
物理デバイスの出現を待つように設定しても、Jetson Orinシリーズ（AGX, NX, Nano）でGigEカメラなどを直結する場合、もう一つ厄介な物理レイヤーの問題が潜んでいます。それが**「オートネゴシエーション（通信速度の自動調整）の不安定さ」**です。
カメラとJetsonを繋いだ際、「1Gbpsで通信する？ 100Mbps？」という機器間のやり取りがうまく噛み合わず、リンクアップに数十秒かかったり、1Gbps対応のカメラなのに100Mbpsでリンクしてしまい映像がコマ落ちしたりします。
nmcli 等でOS側の設定を固定しても、ドライバの仕様で再起動時に設定が飛んでしまうことがあるため、ここでは ethtool を使って物理NICのステータスを直接・強制的に書き換えるのが最も確実です。
現在の状態は以下のコマンドで確認できます。
$ sudo ethtool eth0
これを「オートネゴ無効、1000Mbps(1Gbps)、全二重」に強制固定するには以下のコマンドを打ちます。
$ sudo ethtool -s eth0 speed 1000 duplex full autoneg off
4. 仕上げの「おまじない」：systemdに全てを組み込む（最強の構成）
これまでの対策（NICの待機、ethtoolでの強制固定）に加え、**「カメラ自体のOSが立ち上がり、映像配信の準備が終わるまでの時間」**というマージン（ゆとり）を持たせます。
これら全てを、あなたの .service ファイルの [Service] セクションに ExecStartPre として組み込んでしまいます。
[Service]
Type=simple
User=root
# おまじない1: プログラム起動前にethtoolでリンク速度と全二重を強制固定する
ExecStartPre=+/sbin/ethtool -s eth0 speed 1000 duplex full autoneg off
# おまじない2: カメラ本体の起動とリンクアップが完全に終わるまで数秒待機する
ExecStartPre=/bin/sleep 5
# 本命のプログラムを実行
ExecStart=/usr/local/bin/camera_app
(※ ethtool はroot権限が必要なため、ServiceのUserがroot以外の場合は + 記号をつけて ExecStartPre=+/sbin/ethtool... とすることで特権実行させます。)
この構成こそが、組み込み開発の現場でシステムを安定させる「最強のハック」です。
ethtool で物理層の迷いを断ち切り、sleep でデバイス間の起動ラグ（ゆらぎ）を吸収する。スマートな解決策には見えないかもしれませんが、現場で起こりうるあらゆるトラブルをねじ伏せてくれる実用的な手法です。
まとめ
Jetson環境でネットワークカメラの自動起動に失敗する場合は、以下の3点を適用してみてください。
* 物理デバイスの待機: .serviceの [Unit] セクションで対象NICの .device を Requires / After に指定する。
* ethtoolによる物理層の固定: [Service] セクションで ExecStartPre を使い、ethtool でオートネゴシエーションをオフ・速度固定する。
* 起動マージンの確保: 同じく ExecStartPre=/bin/sleep を追加し、カメラ側の準備が整うのを待つ。
ソフトウェア的な理想論だけでなく、物理的なハードウェア（PHYの挙動とカメラ機器の遅延）に寄り添った泥臭い設計をすることで、エッジAIシステムの信頼性は格段に向上します。
Convergence Labでは、こうしたエッジコンピューティング実装時のノウハウや技術情報を引き続き発信していきます。システム構築でお困りのことがあれば、ぜひ過去の記事も参考にしてみてください。
技術ブログは書きやすいな
FPSで奇声を発して寮を追い出されそうになってた後輩を思い出した
思いっきり技術ブログだけどネタもないしいいか
こういう記事を書くかな
Jetson Nano/Orinでネットワークカメラの自動起動が失敗する？ systemdで物理デバイスの出現を待つ確実な方法
エッジAIカメラや監視システムの開発において、NVIDIA Jetson NanoやJetson Orinシリーズにネットワークカメラ（IPカメラ、GigEカメラ、PoEカメラなど）を接続し、映像を取得・推論する構成は定番です。
しかし、システムを組み上げて「いざ現場へ！」と意気込んで電源を入れたものの、Jetson起動直後に実行されるはずの映像取得プログラムが立ち上がらない（カメラに繋がらない）……そんな経験はありませんか？
後から手動でプログラムを再起動すると、あっさりとカメラの映像が映る。これは典型的な「起動時のタイミングシビアな問題」です。
本記事では、Convergence Labの現場でもよく遭遇するこの問題の原因と、systemdを使った確実な解決策（技術パッチ）を3つのステップで解説します。
1. 現象の定義（Symptoms）：なぜカメラに繋がらないのか？
自作の映像取得アプリやRTSPストリームを受信するノードなどをsystemdで自動起動させようとしたとき、失敗してsystemctl status [あなたのサービス]を確認すると、以下のようなエラーログが残っていることがあります。
Error: RTSP connection failed. Network unreachable.
# または
netlink error: no such device
「ネットワーク起動後に実行するように、.serviceファイルに After=network-manager.service や After=network.target を指定しているのになぜ？」と思うかもしれません。
実はここに、ソフトウェアとハードウェアの同期ズレの罠が潜んでいます。
network-manager.serviceが立ち上がった（Activeになった）瞬間というのは、あくまで「Jetson内のネットワーク管理ソフトウェアの準備ができた」状態に過ぎません。OSが物理的なLANポート（NIC）を完全に認識し、デバイスファイルとして準備が完了するまでには、わずかなタイムラグが存在します。
プログラム側がカメラのIPアドレスへアクセスしようとした瞬間、物理レイヤーの準備が間に合っておらず通信経路がないため、「デバイスがない」「ネットワークに到達できない」と怒られてしまうわけです。
2. 解決策（Resolution）：物理レイヤー（NIC）の出現を待つ
この問題を根本から解決するには、抽象的なネットワークサービスを待つのではなく、カメラが接続されている「物理デバイス（LANポート）そのもの」の出現を待つようにsystemdに指示を出す必要があります。
ステップ1：実際のインターフェース名を特定する
まずはカメラが接続されているネットワークインターフェース名を正確に把握します。ターミナルで以下のコマンドを実行します。
$ ip link
標準のLANポートであれば eth0、USB-LAN変換アダプタや増設ボードを使っている場合は eth1 といった名前が確認できるはずです。
ステップ2：.service ユニットファイルの修正
ここではカメラが eth0 に繋がっているとします。systemdにおいて、この物理デバイスは sys-subsystem-net-devices-eth0.device という名前のデバイスユニットとして扱われます。
あなたのサービスの .service ファイル（例: /etc/systemd/system/camera_app.service）の [Unit] セクションを以下のように書き換えます。
[Unit]
Description=Network Camera Application
# 既存のネットワーク依存設定を残しつつ、物理デバイスへの依存を追加
Requires=sys-subsystem-net-devices-eth0.device
After=network-manager.service sys-subsystem-net-devices-eth0.device
Requires= と After= の両方にデバイスユニットを指定することで、「eth0というLANポートがシステムに認識されるまで、このカメラアプリの起動を保留する」という厳密なルールを適用できます。
3. 仕上げの「おまじない」（Optimization）：組み込み開発ならではの心のゆとり
理論上は上記のデバイスユニット指定でJetson側のポートは準備完了になりますが、ネットワークカメラを扱う泥臭い現実として、「LANポートが認識された直後は、まだIPアドレスの割り当てが完了していない」、さらに言えば**「カメラ自体の起動やネットワーク配信の準備が終わっていない」**という問題が残ります。
DHCPからのIP取得が数ミリ秒遅れたり、PoE給電で同時に立ち上がったカメラの準備完了を待たずにプログラムがストリームを要求してしまうと、やはりエラーで落ちてしまいます。
そこで、現場でシステムを安定させるための「仕上げのおまじない（マージン）」を追加します。[Service] セクションに以下の一行を書き加えます。
[Service]
Type=simple
User=root
# 本命のプログラムを起動する前に、数秒待機する（環境に合わせて調整）
ExecStartPre=/bin/sleep 5
ExecStart=/usr/local/bin/camera_app
ExecStartPre=/bin/sleep 5。
たったこれだけです。JetsonのLANポートが認識された後、メインプログラムを実行する前に強制的に「ゆとり」を持たせます。（※カメラの起動時間に合わせて 2〜10 の間で調整してください）
スマートな解決策には見えないかもしれませんが、デバイスの個体差、OSアップデートによる挙動の変化、DHCPの応答遅延、そしてネットワークカメラ特有の起動ラグなど、現場で起こりうるあらゆる「ゆらぎ」を吸収してくれる、非常に強力で実用的なハックです。
まとめ
Jetson等のエッジ環境でネットワークカメラを利用するサービスが自動起動に失敗する場合は、以下の3点をチェック＆適用してみてください。
* エラーの確認: systemctl status でネットワーク到達不可やデバイス不在エラーが出ていないか。
* 物理デバイスの待機: [Unit] セクションに Requires= と After= で対象のNICの .device を指定する。
* マージンの確保: [Service] セクションに ExecStartPre=/bin/sleep を追加し、カメラ側の準備が整うのを待つ。
ソフトウェア的な理想論だけでなく、物理的なハードウェア（Jetsonのポートとカメラ機器）の挙動に寄り添った設計をすることで、エッジAIシステムの信頼性は格段に向上します。
Convergence Labでは、こうしたエッジコンピューティング実装時のノウハウや技術情報を引き続き発信していきます。システム構築でお困りのことがあれば、ぜひ過去の記事も参考にしてみてください。
元気になってからだな。今、打ち合わせ入っても困るし
しかしやる気がないな
三郷は寒め
月10万ぐらい行ってみるか
komurasoftの様子を見るか
サイトがパワーアップしてるからなあ
私もまたGoogle広告やってみようかなぁ
リードの質は下がる
問い合わせも来る
Google広告はアクセス増える