3行まとめ
このテーマをもう少し広げて見るなら、NVIDIA World-Action Models確認：Cosmos 3とAlpamayoでロボット方策を試す前に見ること と NVIDIA Cosmos 3確認：Alpamayoと閉ループ検証でPhysical AIを試す前に見ること も合わせて確認してください。カメラ入力やJetson側の移行が、Physical AIやロボット方策評価の前段にどうつながるかを補えるため。
SIPL、GMSL、Camera over Ethernet、Holoscan Sensor Bridge、UDDFドライバの移行点に絞って確認します。
UDDFドライバの配置先、確認ツール、SensorSystemConfig JSON、Query APIの名前をJetPack 7.2前提にそろえます。
コンパイルの成功だけで終えず、Query database、JSON overlay、ドライバ名、ネットワーク経路、長時間ストリーミングを確認します。
確認日: 2026年6月13日。JetPack 7.2全体ではなく、SIPL API Package v2.0.0まわりのカメラ移行リスクを整理します。
NVIDIA JetPack 7.2は、Jetson Linux 39.2、CUDA 13.2.1、TensorRT 10.16.2を含む更新として公開され、SIPL API Package v2.0.0も含まれます。この記事ではJetPack 7.2全体ではなく、SIPL、GMSL、Camera over Ethernet、Holoscan Sensor Bridge、UDDFドライバの移行だけを扱います。
JetPack 7.1から7.2へ上げる場合、UDDFドライバの再ビルド、配置先の /usr/lib/nvsipl_drv/ 変更、nvsipl_camera と nvsipl_query への手順更新、SensorSystemConfig JSONの大文字小文字一致、raw10tp、CoE bridgeのvector化を先に確認する必要があります。
GMSL/CoEカメラは、コンパイルが通れば完了ではありません。Query database、JSON overlay、ドライバ名、stereo、HSB、ネットワーク経路、長時間ストリーミングまでつながるかを、公式ドキュメントと実機ログで分けて見るのが安全です。確認日は2026年6月13日です。NVIDIA Watch JapanはNVIDIA Corporationおよび関係会社とは非提携の独立ブログであり、掲載内容は投資助言ではありません。
JetPack 7.2のSIPL移行で最初に分けること
GMSLとCoEのカメラサポートを広げる統一カメラフレームワークとして、移行時の影響を見ます。
UDDF driver model、CameraHAL、Query/Control API、SensorSystemConfig JSON、実機テストの関係を整理します。
CUDA、Yocto、MIG、Super Modeなどの採用判断は別記事の範囲として、ここでは深掘りしません。
アプリ、ドライバ、JSON、配置、テストのどこにJetPack 7.1時代の前提が残るかを確認します。
SIPLはサンプルアプリだけの差し替えではなく、アプリ、ドライバ、JSON、配置、テストにまたがる移行として見ます。
JetPack 7.2は、NemoClaw、Jetson agent skills、Yocto、MIG、Super Modeなど、話題が多い更新です。すでに本サイトでも、全体像は<a href="https://nvda-watch.blog.mo-gmo.com/nvda-21-jetpack-72-jetson-nemoclaw-cuda13/" rel="noopener">JetPack 7.2全体の確認記事</a>で扱っています。
この記事では、あえて範囲を狭めます。見るのは、JetPack 7.2に含まれるSIPL API Package v2.0.0と、GMSL/CoEカメラをJetPack 7.1系から上げるときの移行点です。CUDAやYoctoの採用判断ではなく、カメラ入力が壊れないか、UDDFドライバが読まれるか、JSONとQuery APIが新しい形に合っているかを確認します。
SIPL API Package v2.0.0を何の更新として読むか
JetPack 7.2のダウンロードページでは、Jetson Linux 39.2のハイライトとしてJetson SIPL API Package v2.0.0が示され、GMSLとCoEのカメラサポートを広げる統一カメラフレームワークとして位置づけられています。SIPLの概要ページでも、SIPLはカメラセンサーからの連続ストリーミング、画像処理、制御のためのモジュラーなフレームワークとして説明されています。
ここで大事なのは、SIPLが単なるサンプルアプリの差し替えではないことです。GMSLとCoEで同じQuery/Control API、UDDF driver model、CameraHALの考え方を使うため、アプリ、ドライバ、JSON、配置、テストのどこかにJetPack 7.1時代の前提が残ると、移行時に詰まりやすくなります。
根拠
この記事の事実認定は、NVIDIAのJetPack 7.2 downloads and notes、SIPL Migration Guide、SIPL Query JSON Guide、Camera Development、Introduction to SIPL、CoE Overviewに限定します。Developer Forumや専門メディアの投稿は、リリース後にセットアップや生産導入の関心があることを示す需要シグナルとして扱い、仕様の断定には使いません。
JetPack 7.1から7.2への移行項目を先に棚卸しする
SIPL Migration Guideは、JetPack 7.1から7.2へ移るときのSIPL applications、UDDF drivers、SensorSystemConfig JSONの変更点をまとめています。まず見るべき順番は、ビルド、配置、Query API、JSON、CoE bridge、stereo、実機確認です。
移行を「ソース修正」とだけ捉えると抜けます。nvsipl系のツール名が変わり、UDDFドライバの配置先も変わり、Query APIの型名も変わります。JSONの名前一致は大文字小文字まで厳密になり、CoE bridgeでは固定数のセンサーを前提にした実装を見直す必要があります。
評価基準
完了条件は、コンパイルが通ることではありません。CameraHALがUDDFドライバを見つけ、Query databaseを読み、カスタムJSONをoverlayし、GMSLまたはCoEのストリーミングを開始し、再起動後も同じ構成で復帰できるところまで見ます。
UDDFドライバは再ビルドと配置先を先に直す
古い /usr/lib/nvsipl_uddf/ 参照が残ると、成果物が存在してもCameraHALから読まれない可能性があります。
JetPack 7.2で最初に見るべき実務項目は、UDDFドライバの再ビルドと配置先です。SIPL Migration Guideでは、JetPack 7.2に合わせてインストール済みソースツリー、ドライバ配置先、サンプルアプリ配置先、統一ツール名、ビルドターゲットが変わっています。
たとえば、インストール済みソースツリーは sipl/ から /usr/src/jetson_sipl_api/sipl/ へ、UDDFドライバ配置先は /usr/lib/nvsipl_uddf/ から /usr/lib/nvsipl_drv/ へ変わります。サンプルアプリ配置先も /usr/bin/ から /usr/sbin/ へ変わるため、手順書やCIの確認先が古いままだと、ビルドは通っているのに実機で読まれない、という形で失敗します。
/usr/lib/nvsipl_drv/ を前提に成果物を置く
CameraHALはJetPack 7.2で /usr/lib/nvsipl_drv/ からUDDF driver librariesを発見する前提です。ここを見落とすと、古い /usr/lib/nvsipl_uddf/ に成果物を置いたまま、アプリケーション側でドライバが見つからない状態になります。
確認するのは、開発機の手元だけではありません。rootfs生成手順、Debianパッケージ、Yoctoや社内ビルドレシピ、量産イメージ、OTA差分、CIの成果物収集先まで含めて、古いパスが残っていないかを見ます。
確認項目
- UDDFドライバのインストール先が
/usr/lib/nvsipl_drv/になっているか。 - サンプルアプリや確認ツールの配置先を
/usr/sbin/前提で見ているか。 - 古い
/usr/lib/nvsipl_uddf/を参照するスクリプト、README、CI、OTA manifestが残っていないか。 - 実機イメージに入った共有ライブラリと、開発環境でビルドした共有ライブラリのバージョンが一致しているか。
JetPack 7.2ヘッダーで再ビルドする
SIPL Migration Guideは、out-of-tree UDDF driversをJetPack 7.2 headersに対して再ビルドするよう求めています。理由は、IGmslDeserializer、IGmslModuleControl、IGmslSerializer、ICoEBridgeControl のUDDF interface UUIDがJetPack 7.2で変わっており、JetPack 7.1 UUIDでビルドしたドライバは読み込まれないためです。
ここは、バイナリ互換性に期待して古い共有ライブラリを流用する場面ではありません。ドライバを再ビルドし、JetPack 7.2のヘッダー、リンク先、配置先、Query JSON、DriverInfo.name まで一つの移行単位として扱います。
注意点
ビルド成功だけを採用判断にしないでください。DriverInfo.name とJSON側の名前、NITOの解決、Query database、module/transportの対応がつながっているかを、nvsipl_query などの確認手順へ落とす必要があります。
nvsipl_camera と nvsipl_query に手順を寄せる
JetPack 7.2では、統一カメラアプリが nvsipl_coe_camera から nvsipl_camera へ、統一queryアプリが nvsipl_coe_query_test から nvsipl_query へ変わります。手順書やテスト自動化が旧コマンド名を前提にしていると、移行後のトラブルシュートで混乱します。
特に、カメラベンダー、BSP担当、アプリ担当が別チームの場合、誰かの手元だけ新しいコマンドに変わり、量産手順には古いコマンドが残ることがあります。記事を読んだ段階で、確認コマンド名、配置先、ログ採取方法を同じ名前に揃えるのがよいでしょう。
評価基準
旧コマンドが残っていないこと、/usr/sbin/ 配置を前提にしていること、nvsipl_query でQuery databaseとJSON overlayを確認できること、nvsipl_camera で対象configを選び、ストリーミング開始まで確認できることを見ます。
Query APIとSensorSystemConfigで壊れるところ
機械的な置換だけではなく、camera configurationをmodule単位とtransport単位で扱う形へ寄せるのが移行の要点です。
JetPack 7.2のSIPL移行は、ドライバ配置だけでは終わりません。アプリケーションやツールがSIPL Query APIを直接使っている場合、型名、名前空間、メソッド名、取得できるリスト構造の変化を見ます。
SIPL Migration Guideでは、camera configuration typesが nvsipl:: から nvsipl::sensorconfig:: に移ったと説明されています。CameraSystemConfig は sensorconfig::SensorSystemConfig、CameraConfig は sensorconfig::ModuleConfig、CoECamera は sensorconfig::CoEModule、GmslCamera は sensorconfig::GmslModule に変わります。
SensorSystemConfig を中心に読み替える
名前が変わった型を機械的に置換するだけでは、移行としては弱いです。JetPack 7.2では、camera configurationをmodule単位とtransport単位で扱う読み方へ寄せる必要があります。
GetCameraSystemConfig() は GetSensorSystemConfig() へ変わります。CameraDeviceInfoList も、coeModuleList、gmslModuleList、coeTransportList、gmslTransportList のようなmodule-levelとtransport-levelのリストを持つ形になります。古い sensorInfoList、eepromInfoList、serInfoList、deserInfoList に直接依存するコードがあるなら、ここで直します。
根拠
SIPL Migration GuideのQuery and Configuration API Changesは、JetPack 7.1名とJetPack 7.2名を並べています。本文で触れている型名とメソッド名は、この移行表をもとにしています。
ParseDatabase() を先に呼ぶ
JetPack 7.2では、INvSIPLCameraQuery::ParseDatabase() を ParseJsonFile() より先に呼ぶ流れが示されています。これは、ビルトインのsensor、module、transport databaseを先に読み、その上にカスタムJSONを重ねる考え方です。
JetPack 7.1でカスタムJSONだけを直接読み込ませていたテストがある場合、移行後に同じ順序で動くとは限りません。起動時オプション、エラー処理、ログ、CIのquery確認手順を、ParseDatabase() 失敗時に止める形へ見直します。
確認項目
ParseDatabase()の結果を確認してからParseJsonFile()を呼んでいるか。- カスタムJSONを複数重ねる場合、読み込み順とエラー時の扱いが明確か。
- Query databaseにない名前をJSON側で指定していないか。
- 古いcomponent listを直接読んでいる独自ツールが残っていないか。
SensorSystemConfig JSONは名前とformatでつまずく
module、transport、sensor、serializer、deserializerの名前をdatabase entryやUDDF DriverInfo.nameと文字列として合わせます。
virtual channel input formatの表記を更新し、stream、embedded lines、CFA、ISP出力まで確認します。
JSONのmodule driver名とUDDF側のexport名が混ざっていないかを見ます。
CoEのstereo表現やbridge関連の指定がJetPack 7.2の形に合っているかを確認します。
人間が見て同じに見える名前ではなく、JSON、driver、database、NITO解決名が同じ文字列としてそろっているかを見ます。
JetPack 7.2のSIPL移行で、実機前に必ず見たいのが SensorSystemConfig JSONです。SIPL Query JSON GuideとMigration Guideでは、名前一致、入力format、stereo表現、moduleDriverName など、移行時に効く変更が複数示されています。
JSON名は大文字小文字まで合わせる
JetPack 7.2では、module、transport、sensor、serializer、deserializerの名前が、database entryやUDDF DriverInfo.name と大文字小文字まで一致する必要があります。公式の例では、"VB1940" のような正しいexported nameを使い、"vb1940" のような小文字variantを避ける形が示されています。
これは、小さな表記揺れでは済みません。ドライバ名、module名、transport名、component database名、NITO解決名を、人間が見て同じに見えるかではなく、文字列として一致しているかで確認します。
確認項目
JSONにある name、UDDF側の DriverInfo.name、module driver名、NITOの解決名、社内ドキュメントに書かれた通称が混ざっていないかを見ます。移行前に、JSONから名前の一覧を抜き出し、ドライバがexportする名前と照合する作業を入れておくと、実機での切り分けがかなり楽になります。
raw10packed は raw10tp へ置き換える
Migration Guideでは、virtual channel input formatとして、"raw10packed" を "raw10tp" へ置き換える項目が示されています。ここは文字列置換だけで済ませたくなる場所ですが、実機ではセンサー、virtual channel、embedded lines、CFA、ISP出力まで確認したほうが安全です。
format名を直してストリームが出ても、左右、露光、metadata、ISP出力のどこかが期待と違う可能性があります。特にstereoや複数sensorを扱う構成では、frame timingやsensor groupとあわせて確認します。
注意点
記事では、raw10tp にすれば全構成が通るとは書きません。公式ドキュメントが示す変更点は、移行前に見るべき最低ラインです。読者のsensor datasheet、vendor driver、NITO、ISP設定は別に確認します。
moduleDriverName はdriverとNITOの再利用で見る
JetPack 7.2では、cameraConfigs[].moduleDriverName というoptional aliasingが示されています。これがある場合、runtimeは name ではなく moduleDriverName を使ってUDDF module driverとNITOを解決します。一方で、name は nvsipl_camera -c のようなツールで選択するconfiguration nameとして残ります。
つまり、name は選ぶための名前、moduleDriverName はdriverとNITOを解決するための名前、という役割分担です。既存module driverを単眼configや複数configで再利用する場合には便利ですが、必要がない構成に無理に入れるものでもありません。
評価基準
moduleDriverName を使うなら、どのconfigがどのUDDF module driverとNITOを再利用するのかを表にします。使わないなら、name でdriverとNITO解決が成立することを確認します。どちらの場合も、選択名とdriver名を混同しないことが大切です。
CoEとHoloscan Sensor Bridgeはbridge側の前提を変える
- 1camera sensor
sensor数、出力format、virtual channel、embedded lines、露光やmetadataを確認します。
- 2Holoscan Sensor Bridge
bridge driver、HSB ID、制御方法、vendor資料で示される更新状況を確認します。
- 3Ethernet/MGBE
IP、MAC、VLAN、interface名、packet loss、latency、frame timingを実機構成に合わせて見ます。
- 4SIPL
CoE transport、JSON、Query database、UDDF driver modelが同じ構成を指しているかを確認します。
- 5application
nvsipl_query、nvsipl_camera、長時間ストリーミング、アプリ側ログで切り分けます。
公式例は出発点です。実際の可否はcamera module、bridge、network構成、driver、JSON、ログを分けて確認します。
Camera over Ethernetは、従来のVI/NVCSIだけを見る感覚では確認が足りません。CoE Overviewでは、CoEはEthernetベースのcamera data pathを使い、Jetson AGX Thor Developer Kit boardのMGBE controllerやIEEE 1722b protocolを使ってcamera dataを受けると説明されています。
また、Holoscan Sensor Bridgeはcamera sensorをEthernet networkへ接続する構成として扱われ、VB1940 with HSBのEagle cameraがrelease packageでout of the box対応として示されています。ただし、公式例があることと、自社のcamera module、bridge、network構成がそのまま動くことは別です。
CoEはEthernet側の確認が増える
CoEでは、camera sensor、HSB、Ethernet/MGBE、SIPL、applicationの間に、ネットワーク設定が入ります。IP、MAC、VLAN、interface名、HSB ID、packet loss、latency、frame timingなど、CSI接続だけを見ていたときとは違う確認項目が出ます。
MIPIやGMSL cameraをHSB、つまりCSI2Eth bridge経由でCoE architectureとSIPL frameworkに載せられる場合もあります。ただし、この「載せられる」は実装作業が不要という意味ではありません。transport設定、driver、JSON、bridge側の制御、実機の信号品質を分けて見ます。
注意点
CoEのネットワーク構成は環境差が大きいため、この記事では特定のIP設定やスイッチ構成を推奨しません。公式ドキュメントで確認できるのは、CoEの考え方、MGBE/IEEE 1722b/HSBの位置づけ、SIPLとの関係です。読者の実機では、vendor資料とログで確認します。
ipAddress と channelNumber はvectorとして扱う
Migration Guideでは、ICoEBridgeControl が固定の HSB_MAX_SENSORS capや hsbMetadataResolution を公開しなくなり、CoEBridgeContext::InitConfig::ipAddress と channelNumber が std::vector fieldsになったと説明されています。custom CoE bridge driverを持っている場合、ここは見逃せません。
固定2センサー前提でarray indexを組んでいる実装、metadata line数を固定で見ている処理、接続sensor数を実機ではなく定数で決めている処理は、JetPack 7.2移行時に見直します。接続されたsensor数に合わせてvectorをsizeする、という設計に寄せる必要があります。
確認項目
HSB_MAX_SENSORSを前提にした実装が残っていないか。ipAddressとchannelNumberを固定長配列のように扱っていないか。- 接続sensor数の増減で、bridge initialization、ログ、エラー処理が破綻しないか。
- CoE bridge driverとJSON側のtransport設定が同じsensor数を見ているか。
CoE stereoは sensorGroup と sync_sensors を見る
JetPack 7.2のMigration Guideでは、CoE stereo markerとして cameraConfigs[].CoECamera.isStereo を使わず、non-zero sensorInfo.sensorGroup と transportSettings[].sync_sensors を使う形が示されています。Stereo groupsでは、secondary sensorがprimary sensorのISP programとauto-control outputを再利用することも説明されています。
GMSL stereo側では、HAWK AR0234 modulesでexternal FSYNCを使う文脈が示され、driver-facing public hooksとして IGmslModuleControl::GetModuleFsyncTxId() などが挙げられています。stereoは、ストリーミングが開始すれば完了ではありません。左右のsensor index、primary/secondary、VSYNC、auto-controlの扱いまで確認します。
評価基準
左右を取り違えずに取得できるか、同期が崩れないか、片側だけ露光やISP設定が違わないか、custom auto-control pluginがstereo groupを前提に動くかを見ます。実機確認では、短時間の起動確認だけでなく、長時間稼働と再起動後の復帰も確認したいところです。
GMSL、CoE、Thor、Orinで確認順を変える
採用可否は、ThorかOrinか、GMSLかCoEか、既存製品か新規評価機かで確認順が変わります。
JetPack 7.2は、Jetson AGX Thor Developer Kit、Jetson T5000、Jetson T4000、Jetson Orin Familyをsupported hardwareとして示しています。ただし、対応ハードウェアに名前があることと、読者のcamera構成が移行済みでそのまま動くことは同じではありません。
Jetson AGX ThorではCoE/HSBを先に見る
Thor環境では、CoE、MGBE、HSB、VB1940 with HSBのような公式例を起点に、自社のcamera moduleやbridge driverとの差分を見ます。SIPLが主要camera software pathとして示されているThorでは、CoEとSIPLの関係を先に理解しておく価値があります。
Thorで確認する順番は、JetPack 7.2の対象ハードウェア、SIPL API Package、CoE transport、HSB、bridge driver、JSON、nvsipl_query、nvsipl_camera、実機ストリーミングです。途中でvendor driverやNITOが絡む場合は、NVIDIA公式ドキュメントだけで完結させず、vendor側の更新状況も確認します。
条件
公式のout-of-box例がある場合でも、自社camera構成が同じ名前、同じtransport、同じsensor数、同じNITOを使うとは限りません。公式例は出発点であり、採用可否は実機構成ごとに見ます。
Jetson Orinでは既存GMSL構成の影響を先に見る
Orin環境では、JetPack 7.2でOrin Familyがsupported hardwareに入っている点と、既存GMSL構成のSIPL/UDDF/JSON移行を分けて見ます。既存製品でArgus、V4L2、独自camera stack、古いGMSL driverを使っている場合、SIPL移行を前提にできるかは別問題です。
Orinでまず見るのは、現在のJetPack/Jetson Linux、camera driver、GMSL serializer/deserializer、NITO、JSON、CI、OTA、rollbackです。JetPack 7.2が使えることだけを理由に、本番fleetへ直接入れるのは避けたほうがよいでしょう。
注意点
Camera Developmentドキュメントでは、SIPLはJetson Thorから主要camera software pathとして示され、GMSL/CoEはJetPack 7.2でのサポート範囲として整理されています。一方、MIPI supportはfuture releases予定とされています。自分のカメラがどのpathにいるのかを、最初に分けてください。
vendor確認が必要な場所を残す
SIPL、UDDF、GMSL、CoEは、NVIDIA公式ドキュメントだけで読める範囲と、camera vendorやbridge vendorに戻るべき範囲が分かれます。driver source、NITO、sensor characterization、カスタムauto-control、bridge firmware、ケーブル、熱、電源、長時間安定性は、vendor確認や実機ログが必要です。
確認項目
vendorからJetPack 7.2対応のドライバ、NITO、サンプルJSON、既知問題、推奨firmware、テスト済みcamera module、support statementが出ているかを確認します。出ていない場合は、Ask vendor として本番導入を止める判断を残します。
移行前チェックリストと止める条件
JetPack 7.2 with Jetson Linux 39.2、SIPL API Package v2.0.0、UDDF、JSON、Query API、CoE bridgeの影響範囲が整理できています。
旧パス、旧ツール名、旧型名、旧JSON field、raw10packed、大文字小文字不一致が残っている場合は実機投入前に止めます。
driver、NITO、bridge側の対応状況や更新時期が不明な場合は、vendor資料とサポート窓口で確認します。
CIで落とせる文字列と配置の問題を先に落とし、最後に実機でしか見えないストリーミング、画質、同期、長時間安定性を確認します。
最後に、JetPack 7.2のSIPL移行を進める前のチェックを、短時間で見るもの、CIで見るもの、実機で見るものに分けます。
30分で見る公式ドキュメント
最初に開くのは、JetPack 7.2 downloads and notes、SIPL Migration Guide、SIPL Query JSON Guide、Introduction to SIPL、CoE Overviewです。この5つで、JetPack/Jetson Linuxのバージョン、SIPL API Package、対象ハードウェア、UDDF配置先、Query API、JSON、CoE bridgeの主な変更を確認できます。
ここで、既存構成がGMSLなのか、CoE/HSBなのか、Argus/V4L2中心なのか、SIPL Query APIを直接使うのかを分けます。すべてを一度に直すのではなく、影響範囲を小さく切るのが現実的です。
確認項目
- JetPack 7.2 with Jetson Linux 39.2が対象環境に合うか。
- SIPL API Package v2.0.0の移行対象に自社コードが含まれるか。
- UDDF driver、SensorSystemConfig JSON、Query API、CoE bridge driverのどれを持っているか。
- 旧パス、旧ツール名、旧型名、旧JSON fieldが残っていないか。
CIとパッケージで先に落とす
実機に入れる前に、CIで落とせるものは落とします。たとえば、旧パス /usr/lib/nvsipl_uddf/ の残存、旧コマンド nvsipl_coe_camera、旧query app名、raw10packed、大文字小文字不一致、CoECamera.isStereo、古いAPI名は、grepやJSON検査で見つけられる可能性があります。
CIはコンパイルだけを見ず、成果物の配置、rootfsへの反映、パッケージ名、JSON差分、手順書の旧文字列まで確認します。カメラ移行は、最後に実機でしか見えない問題も多いですが、文字列と配置のミスは実機前にかなり減らせます。
評価基準
CIの合格条件は、JetPack 7.2ヘッダーでの再ビルド、/usr/lib/nvsipl_drv/ への成果物配置、JSON lint、driver名一致、ParseDatabase() 順序、旧文字列の除去、手順書の更新です。どれかが未確認なら、実機投入前にHoldにします。
実機で止める条件を決める
実機では、nvsipl_query で対象configが見えること、nvsipl_camera でストリーミングできること、左右やsensor groupが正しいこと、frame dropやnetwork errorが許容範囲にあること、再起動後に復帰することを確認します。長時間稼働、温度、電源断復旧、rollbackも必要です。
Forumで似た回避策が見つかっても、公式ドキュメント、vendor確認、読者自身の実機ログが揃うまで量産イメージには入れないほうが安全です。SIPL移行は、API名の修正だけでなく、カメラ入力という製品体験の入口を守る作業です。
Go / Hold / Ask vendor
Goにできるのは、公式ドキュメントの移行項目を確認し、ドライバ再ビルド、配置、JSON、Query、実機ストリーミング、長時間確認、rollbackまで見えた場合です。Holdは、CIで旧前提が残る場合、実機ログが不安定な場合、stereoやHSBの確認が終わっていない場合です。Ask vendorは、driver、NITO、bridge firmware、sensor characterization、support statementが不足している場合に使います。
本文の主目的を満たした後の補助導線として、NVIDIAの公式発表、Jetson、SIPL、カメラ開発まわりの更新を追いたい場合は<a href="https://nvda-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>も使えます。まずはこの記事のチェックリストと公式資料で、自分の構成の未確認点を潰すのが先です。
次に読むなら
参照した主な情報源
- NVIDIA JetPack 7.2 downloads and notes: https://developer.nvidia.com/embedded/jetpack/downloads/archive-7.2
- NVIDIA JetPack 7.2 SIPL Migration Guide: https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/CameraDevelopment/SIPLFramework/SIPL-for-L4T/SIPL-Migration.html
- NVIDIA SIPL Query JSON Guide: https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/CameraDevelopment/SIPLFramework/SIPL-for-L4T/SIPL-JSON-Query-Guide.html
- NVIDIA Camera Development: https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/CameraDevelopment.html
- NVIDIA Introduction to SIPL: https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/CameraDevelopment/SIPLFramework/Introduction-to-SIPL.html
- NVIDIA Camera-over-Ethernet Overview: https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/CameraDevelopment/SIPLFramework/SIPL-for-L4T/CoE/CoE-Solution-Overview.html
更新履歴
- 2026年6月13日
JetPack 7.2のSIPL/UDDF/GMSL/CoE移行チェックとして初稿を作成しました。
JetsonとSIPLの資料は更新される可能性があるため、公開後も公式ドキュメントの変更を確認します。
- 2026年6月13日: NVIDIA公式ドキュメントを確認し、JetPack 7.2のSIPL/UDDF/GMSL/CoE移行チェックとして初稿を作成。