简介:面向英伟达 Jetson 嵌入式平台,围绕 GMSL2 接口相机驱动的安装与使用整理而成的 ROS 工作空间资源包,适用于 Jetson 开发板和 ROS 环境,适合涉及 ADAS、计算机视觉与远程摄像头部署的开发者参考。GMSL2 较传统 MIPI CSI-2 拥有更高数据速率和更长线缆支持,是高速图像传输的重要接口方案。包内共 281 个文件,压缩后仅 104KB,以 CMake 构建脚本、make 配置、shell 脚本、Python 辅助脚本、ROS 节点源文件和 launch 启动文件为主,文件结构清晰,便于在 catkin 环境下完成编译与参数调整。目前已有 1584 人浏览学习。资源提供了 GMSL2 相机驱动从环境准备到编译安装、配置参数和运行调试的完整链路,包含工作空间常见的 setup 脚本、缓存标记及功能测试文件,可帮助开发者对照检查依赖与编译状态,缩短驱动部署和排错时间,为后续集成图像处理、目标检测或 SLAM 算法打下坚实基础。
1. Jetson上装GMLS2相机驱动:为什么一上来就翻车
做视觉的开发者拿到Jetson板子,第一件事往往不是跑模型,而是把摄像头点亮。GMLS2是一款常见的MIPI CSI-2接口工业相机,分辨率、帧率都能打,但驱动安装比USB摄像头麻烦得多。很多人按普通摄像头的思路来,insmod个文件、打开/dev/video0就完事,结果在Jetson上连设备节点都看不到,dmesg里全是“无法识别”的报错。更麻烦的是,JetPack版本、内核头文件、设备树dts,任何一个对不上,驱动编译就失败,或者系统直接起不来。
我原来也以为装个驱动半小时搞定,实际折腾了大半天,把烧录、dtb、内核模块全走了一遍。GMLS2这类相机的驱动不是独立的,它要挂在Jetson的Tegra摄像头框架里,依赖设备树和v4l2子设备,光有.ko文件远远不够。这篇文章就按我实际操作的顺序来写:先确认环境版本,再编译模块、覆盖设备树,最后用v4l2和GStreamer验证,并把踩过的坑列在后面。如果你正在Jetson上接GMLS2或同类MIPI相机,照着走能少走好几段弯路。
2. 装驱动前的环境确认:JetPack版本与内核头文件
驱动装不上,十有八九是环境版本匹配出了问题。GMLS2厂商给的驱动源码一般不会适配所有内核,它是针对某个L4T版本写的。Jetson上的JetPack版本直接决定内核版本,而内核版本又决定编译驱动的KERNELDIR和头文件路径。所以拿到板子第一件事不是跑make,而是先把系统版本核实清楚,这一步省不了。
2.1 先查JetPack版本和内核编号
在Jetson终端里执行两条命令,一条看JetPack/L4T版本,一条看内核版本。
cat /etc/nv_tegra_release uname -r第一条会输出类似R32.7.1或R35.4.1的版本号,这个R开头的是L4T(Linux for Tegra)版本,不是JetPack。JetPack版本和L4T不是同一个编号,比如JetPack 5.1.2对应L4T R35.4.1,内核是5.10。第二条uname -r输出当前内核完整版本,比如5.10.104-tegra。后面编译驱动时,KERNELDIR必须指到这个内核对应的头文件目录,否则make会直接报错,找不到linux/version.h。
我把几个常见的对应关系整理成了表格,方便你对照。不同批次Jetson产品用的内核版本不太一样,比如早期TX2和Xavier的L4T 32.x系列都是4.9内核,新出的Orin NX在5.1.2之后改用5.10。你可以先跑命令确认自己的组合,不用背表。
| JetPack 版本 | L4T 版本 | 内核版本 |
|---|---|---|
| JetPack 4.6 | 32.7.1 | 4.9.140-tegra |
| JetPack 5.0.2 | 35.2.1 | 5.10.65-tegra |
| JetPack 5.1.2 | 35.4.1 | 5.10.104-tegra |
| JetPack 5.1.3 | 35.5.0 | 5.10.120-tegra |
从实际体验看,GMLS2驱动对5.10内核适配比较好,我建议如果你手头板子能刷JetPack 5.1.2或5.1.3,还是尽量用新版本,别停留在4.9。当然如果你现有项目已经基于旧版跑起来了,升系统代价大,那还是按当前版本去找对应驱动源码,版本对不上后面全是坑。
2.2 检查内核头文件是否完整
编译驱动需要内核头文件,Jetson系统一般带了预编译头文件,在/usr/src目录下,但不一定完整。先检查这个路径是否存在,以及版本号和uname -r是否一致。
ls -d /usr/src/linux-headers-$(uname -r) 2>/dev/null || echo "头文件目录不存在" ls /usr/src/linux-headers-$(uname -r)/include/linux/version.h 2>/dev/null || echo "version.h缺失"如果头文件目录不存在,或者有目录但version.h缺失,说明你烧录系统时没有勾选“预编译内核头文件”组件。这种情况下不要偷懒去编译驱动,我一般会直接下载对应L4T版本的完整内核源码,放到/usr/src里再创建软链接,否则编译报错找回来又得绕一圈。
获取内核源码的方式有两种:一种是通过Jetson自带的源管理工具,另一种是去开发者站点下载L4T源码包。我常用的做法是下载与当前内核版本一致的源码包,解压后把内核配置文件和模块头文件放到/usr/src下。注意源码包的版本必须精确到小版本号,比如5.10.104-tegra,如果下载了5.10.65,编译GMLS2驱动时头文件版本对不上,同样会报错。
2.3 确认GMLS2相机的接口代数和接线
GMLS2相机通常是MIPI CSI-2接口,有数据通道lane和I2C控制线。Jetson板卡上可能有多个CSI接口,接错位置会直接导致I2C通信失败。先看板卡的使用手册,确认摄像头连接的csi端口编号,以及使用几个lane。GMLS2如果是四lane模式,dtb里必须写对lanes数量,写成两lane的话带宽不足,高分辨率下会出现花屏或丢帧。
另外确认供电,GMLS2有些型号需要5V独立供电,如果只靠CSI接口的电源线供电,启动时会拉低电压,驱动加载后传感器没有输出,dmesg里看到的是“timeout waiting for sensor”。这个问题看起来是软件故障,实际是硬件供电不足。我的习惯是先用示波器或万用表量一下摄像头供电脚的电压是否稳定,再动软件,省得后面排查半天。
3. 编译GMLS2驱动:从源码到内核模块
环境确认没问题后,开始编译驱动。GMLS2驱动的编译并不复杂,但有一个关键点:你要先弄清楚Makefile里把内核路径写死成了多少。很多厂商给的Makefile默认指向下载源码的相对路径,在Jetson板子上直接make根本找不到。这一步最耗时间,我把整个过程拆开讲。
3.1 解压驱动源码并检查Makefile
拿到GMLS2驱动包后,先不要急着make,把所有文件解压到一个固定目录,比如/home/$(whoami)/gmls2-release。
cd ~/gmls2-release ls -la一般里面会有gmls2.c、gmls2.h、Makefile,以及几个dts文件。如果包里有README,最好先扫一眼,里面通常会标注这个版本对应的内核范围。打开Makefile看看它怎么写的。
obj-m += gmls2.o KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) EXTRA_CFLAGS += -DCONFIG_VIDEO_GMLS2 all: $(MAKE) -C $(KERNELDIR) M=$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M=$(PWD) clean这个Makefile写的比较正常,KERNELDIR直接用/lib/modules/$(uname -r)/build,这个路径在头文件完整的情况下是可以的。但如果你看到KERNELDIR被硬编码成某个交叉编译工具链路径,比如/home/xxx/kernel/linux-headers,那就必须改成板子上的实际路径。用命令查看build链接是否指向真实头文件目录:
ls -ld /lib/modules/$(uname -r)/build如果显示是一个符号链接,指向/usr/src/linux-headers-xxx,那就没问题;如果显示“No such file or directory”,说明头文件没装好,回到上一章去补齐。
3.2 原生编译生成gmls2.ko
在Jetson板子本机上编译,不需要设置交叉编译器,直接用gcc就行。执行make,目标模块是modules。
cd ~/gmls2-release make如果Makefile里没有写目标,默认就是all,和make all一样。编译过程中会打印一堆go和一些warning,只要没有error最后就会生成gmls2.ko。用ls确认一下:
ls -l gmls2.ko如果看到文件大小是几十KB,说明编译成功。如果报“错误:unknown type name 'u32'”之类的,说明内核头文件不匹配,通常是内核源码版本和当前运行内核不一致,回去核对头文件版本。
有一点要注意:如果Makefile里加了EXTRA_CFLAGS的某些宏,比如让驱动支持RAW10的某种排列,编译时不要随便删,否则跑起来会出现图像错位。我遇到过一次,厂商给的驱动默认是BGGR排列,但实际相机是RGGB,改宏重新编译后正常了。这个在后续配置里也要对应。
3.3 安装模块到内核extra目录
编译完成后,需要把gmls2.ko复制到内核模块目录,并运行depmod建立依赖关系。
sudo cp gmls2.ko /lib/modules/$(uname -r)/extra/ sudo depmod -a sudo modprobe gmls2 dmesg | tail -80depmod -a的作用是扫描模块符号表,后续modprobe时才不会报“unknown symbol”。modprobe加载后,dmesg里如果出现“gmls2: probing chip on i2c-1”这样的日志,说明驱动和传感器已经建立I2C通信。如果报“i2c transfer error”,说明接线或设备树中的I2C地址不对,这时候驱动加载了也不会出现v4l2节点。
这里我一般用modprobe而不是insmod,因为modprobe会解析依赖,如果gmls2.ko依赖其他内核模块,比如video和v4l2-core,modprobe会自动先加载。如果你用insmod gmls2.ko,可能报“Unknown symbol in module”,就是因为依赖没加载。
3.4 覆盖设备树:最容易翻车的一关
驱动模块加载成功后,还差最后一步——设备树。Jetson有一套复杂的摄像头设备树结构,厂商会给一个dts片段,需要你覆盖到系统启动时加载的dtb里。操作前一定要备份原来的dtb,不然改坏了系统起不来,我只能靠USB恢复模式重新刷一次,非常折腾。
先从驱动包中找到dts文件,或者厂商直接给你dtsi,需要include到板子的主dts里。我建议用最简单的方式:直接编译一个独立的dtb,然后在extlinux.conf里指定FDT路径。
cd ~/gmls2-release dtc -I dts -O dtb -o gmls2.dtb gmls2.dts sudo cp gmls2.dtb /boot/dtb/ sudo cp /boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.bak sudo nano /boot/extlinux/extlinux.conf在extlinux.conf中找到以FDT开头的行,默认指向板卡自带的dtb。把这一行改成指向新的gmls2.dtb路径。注意如果你的板子有多行kernel和FDT对应不同启动项,要改的是当前默认启动的那个。改完后保存,重启。
sudo reboot重启后如果系统正常进入桌面,再查看设备节点。如果卡在开机Logo,说明dtb有误,按住板子上的Recovery键进入USB恢复模式,把备份的extlinux.conf和dtb还原,或者直接重新烧录系统。这个我在后面还会详细讲。
4. 驱动配置与图像采集:v4l2、GStreamer和OpenCV联动
驱动和设备树都装好后,摄像头应该能在/dev目录下出现节点了。但要真正拿到图像,还需要配置v4l2格式和帧参数。GMLS2是比较标准的v4l2子设备,Jetson的cpu或vi会把它注册成video节点。第一步先确认节点编号,然后再调格式,最后用GStreamer或OpenCV取帧。
4.1 确认摄像头节点和媒体拓扑
重启后先看看设备列表,有时GMLS2会占两个video节点,一个capture一个output,不要搞混。
ls -l /dev/video* v4l2-ctl --list-devicesv4l2-ctl --list-devices会输出每个设备对应的名称,一般能看到“gmls2”字样,记下设备路径比如/dev/video0。如果看不到GMLS2的名字,只看到tegra摄像头的节点,可以用media-ctl看一下拓扑:
media-ctl -p -d /dev/media0media-ctl会打印出所有子设备,包括sensor实体。如果你能看到“gmls2 1-0010”这样的子设备名,说明驱动注册成功了,只是video节点绑定关系没对上。这时候要看vi和sensor的pad连接,确认sensor的pad0是否连接到了vi端口,如果没有,用media-ctl设置路由,否则采集不到数据。
4.2 设置GMLS2的输出格式和常用参数
GMLS2支持多种分辨率和像素格式,常见的RAW10输出用RG10或BG10。先用v4l2-ctl查看当前格式,再修改。
v4l2-ctl -d /dev/video0 --get-fmt-video v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=BG10不是所有GMLS2型号都支持1920x1080,如果你的相机是200万像素,那么用1600x1200或者1920x1080都没问题。像素格式这里要注意,GMLS2默认可能是RGGB拜耳排列,有的驱动包编译时加了宏,把输出固定成了BAYER_RGGB,那应用层用RG10就对了。如果设置格式失败,返回Invalid argument,先查驱动源码里定义的format,看看是不是只注册了RG8。
曝光和增益是通过v4l2控制接口调的,GMLS2支持手动曝光和自动曝光。设置曝光时间时要先关掉自动曝光,否则你写入的值会被覆盖。
v4l2-ctl -d /dev/video0 --set-ctrl auto_exposure=0 v4l2-ctl -d /dev/video0 --set-ctrl exposure=500 v4l2-ctl -d /dev/video0 --set-ctrl gain=16exposure的单位是微秒还是行,不同固件不一样,你可以先设一个值然后抓图看亮度变化。gain一般是线性增益,值范围看驱动实现,典型是0-255,16表示约1x。如果设得太大画面过曝或出现横条纹,调小就行。
4.3 用GStreamer管道实时预览
Jetson上最常用的取图方式是GStreamer,配合硬件解码和显示效率比直接读v4l2好。GStreamer管道的核心是v4l2src,之后接一个videoconvert再显示。GMLS2输出的是RAW格式,必须指定format。
gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=30 ! \ "video/x-raw,format=GRAY10_LE,width=1920,height=1080" ! \ videoconvert ! ximagesink这里GRAY10_LE表示10位小端灰度,如果你的像素格式是BG10,那么video/x-raw的format也换成GRAY10_LE,因为v4l2的RG10在GStreamer里映射为GRAY10_LE,它不区分拜耳排列,只是把10位数据放进去。如果要显示成彩色,需要加一个bayer2rgb或者用videoconvert做去拜耳。但videoconvert对GRAY10_LE的支持不一定好,我更推荐用raw2rgb这类的插件,或者直接用OpenCV在Python里转。
如果你只想验证输出,不加显示,可以用fakesink,只跑数据不渲染,节省资源。
gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=100 ! \ "video/x-raw,format=GRAY10_LE,width=1920,height=1080" ! \ fakesink运行后看控制台有没有报错,如果没有,说明采集链路是通的。如果报“Buffer has no PTS”,大概率是驱动没配置好,需要在v4l2src后面加一下buffer-size或num-buffers,或者检查是否设置好了frame rate。
4.4 用Python和OpenCV读帧
很多做算法的同学还是习惯用OpenCV读相机。但OpenCV自带的VideoCapture在Jetson上对raw格式支持不好,直接读RG10会报错。我的做法是用GStreamer管道作为后端,让OpenCV通过管道接收数据。
import cv2 import numpy as np cap = cv2.VideoCapture( "v4l2src device=/dev/video0 ! " "video/x-raw,format=GRAY10_LE,width=1920,height=1080 ! " "videoconvert ! video/x-raw,format=BGR ! appsink", cv2.CAP_GSTREAMER ) if not cap.isOpened(): print("无法打开相机") exit(1) for i in range(30): ret, frame = cap.read() if not ret: continue print(f"第{i}帧,shape={frame.shape}") cap.release() cv2.destroyAllWindows()这段代码里,关键的管道部分是videoconvert把GRAY10_LE转成BGR,转换会做一点自动增益,如果你需要精确的RAW数据做ISP处理,就不要用videoconvert,直接用appsink拿GRAY10_LE的buffer再自己处理。OpenCV读取后的frame是一个HxWx3的BGR数组,可以用于显示或保存。
如果你的项目不想依赖OpenCV,也可以用Python的v4l2接口直接mmap读帧,但代码量大得多。在Jetson上我一般直接用GStreamer管道省事,性能和稳定性都更好。
5. GMLS2驱动安装避坑:六个常见问题和排查方法
这部分是经验沉淀。GMLS2驱动安装不复杂,但坑特别多,每一个我几乎都踩过。下面这六条是出现频率最高的,你在实际操作中遇到类似现象,可以先按这个思路排查。
5.1 编译时报错:linux/version.h没有那个文件
现象:make执行后,第一行报错“error: linux/version.h: No such file or directory”,然后整个编译中断。
原因:这个报错几乎可以确定是内核头文件目录不完整或者路径不对。Jetson上/lib/modules/$(uname -r)/build可能是一个无效链接,或者/usr/src下对应的linux-headers目录里缺少include/generated。
解决:先运行ls -ld /lib/modules/$(uname -r)/build确认链接是否存在,如果不存在,就下载对应L4T版本的内核源码包,解压后把include目录补齐。不要尝试在别的机器上编译好.ko再拷过来,因为内核模块版本校验会失败,除非你用了正确的modprobe强制加载,但那样运行时不稳定,还是推荐在板子本机编译。
5.2 覆盖设备树后系统开机卡在Logo或黑屏
现象:做完dtb覆盖重启,Jetson停在开机Logo界面,风扇狂转,SSH也连不上,系统没有正常进入桌面。
原因:这个基本是dtb错误导致的。可能是你覆盖的dtb不是当前板型对应的版本,比如Xavier NX用了TX2的dtb,或者dts里引用的GPIO号与板子原理图冲突,导致上电时序异常,系统初始化失败。
解决:我有一次直接把原dtb覆盖掉了,没备份,折腾了好久。现在每次改dtb前,我都会把extlinux.conf和当前dtb拷贝到external存储或者电脑里。如果系统起不来,需要按住Jetson的Recovery键,进入USB恢复模式,用另一台电脑通过工具把备份的extlinux.conf和dtb刷回去。如果你手头没备份,就只能重新烧录整个系统,代价很大。所以改dtb前一定备份,这个是血泪教训。
5.3 摄像头输出画面是绿色条纹或者一团花瓣
现象:驱动加载成功,v4l2也能读帧,但画面完全不对,像绿色噪声,或者有条纹。
原因:一般是像素格式不匹配,尤其是GMLS2的拜耳排列和驱动定义的排列不一致,还有可能是曝光时间设置过长导致过曝,但绿色噪声更多是格式问题。比如驱动编译时用的宏定了RGGB,但你的GMLS2实际传感器输出是BGGR,那么数据对不上。
解决:先确认GMLS2传感器具体使用的拜耳排列,可以通过查看驱动源码里的原厂寄存器配置,或者运行v4l2-ctl --get-fmt-video看current pixelformat。如果格式是RG10但画面不正常,可以试试BG10,或者直接改成RAW8看是否有正常轮廓。我在一个项目中就是改了一下Makefile里的EXTRA_CFLAGS宏,把RGGB改成BGGR,重新编译驱动后画面就正常了。
5.4 modprobe加载时报“Unknown symbol”错误
现象:执行modprobe gmls2后,dmesg里出现“gmls2: Unknown symbol xxx (err 0)”,模块加载失败。
原因:使用insmod或modprobe时,内核找不到模块依赖的符号。gmls2驱动经常依赖video和videobuf2相关的内核符号,如果这些模块被编译进内核静态部分,共享符号表不一样,或者/lib/modules/$(uname -r)/modules.dep缺失,就会报这个错。
解决:先运行sudo depmod -a重新生成依赖,再modprobe。如果还不行,检查驱动的Makefile里是否有额外的模块加载顺序,或者手动先加载video模块:
sudo modprobe tegra_video_dev sudo modprobe videobuf2-core sudo modprobe gmls2tegra_video_dev是Jetson摄像头框架的核心模块,必须先加载。如果这个模块不存在,说明你的内核配置里没有包含Tegra camera框架,那就要重新编译内核,把对应的配置选项打开,这样才能和GMLS2驱动配合。
5.5 长时间采集后摄像头断流,v4l2返回EIO错误
现象:预览十分钟半小时后,画面突然停止,控制台报“select timeout”或者“VIDIOC_DQBUF: Input/output error”,只能重启应用。
原因:常见原因是CSI信号不稳定或者供电不足,也有可能是驱动中有内存分配的问题,长时间运行后缓冲区泄露。GMLS2在高温下也会出现帧率抖动。
解决:我一般先降低分辨率测试,看是否还断流,如果降低分辨率就稳定,那基本是CSI带宽或供电问题。检查电源适配器是否功率足够,Jetson板子如果从USB口供电,CSI摄像头很容易掉信号。软件层面,可以试着增大v4l2 buffer数量,在GStreamer的v4l2src里加上num-buffers参数没有直接意义,这里推荐用ioctl设置请求缓冲数量。在v4l2-ctl里可以用--set-ctrl吗?不行,需要修改驱动源码里的queue->min_buffers_needed值。如果不想改驱动,可以在应用层做好重连机制,捕获到EIO后重新open设备。我最后是用了一个重启摄像头的脚本,定时检测帧间隔超时后自动重新初始化。
5.6 用OpenCV打不开摄像头,返回False
现象:Python的cv2.VideoCapture("gmls2.mp4")当然不存在,有人用cv2.VideoCapture(0),但打开返回False,gst-launch却能正常工作。
原因:OpenCV默认的VideoCapture(0)走的是V4L2接口,但它不支持RAW10格式,也没有经过GStreamer的videoconvert,所以直接打开失败。这不是GMLS2驱动的问题,是应用层格式适配问题。
解决:OpenCV在Jetson上一定要用GStreamer后端,且管道里要显式转换。具体写法见4.4节的代码。如果你不想写长管道,可以用cv2.CAP_ANY后端,但Jetson上必须确保OpenCV是带GStreamer支持的版本,可以用cv2.getBuildInformation()查看到GStreamer: YES。如果没有GStreamer支持,重新编译OpenCV时加上-DWITH_GSTREAMER=ON。这个坑也很常见,编译OpenCV时关掉了GStreamer,后面用起来处处受阻。
6. 装完怎么验证跑通:一条命令看帧率并录一段RAW
验证驱动装没装好,不是看一眼/dev/video0存在就行。我习惯用一段带帧率统计的命令,既能确认采集链路,又能判断稳定性。GMLS2在1080p 30帧下应该稳定输出,如果帧率掉了,说明驱动或配置有问题。
先把分辨率锁定,用v4l2-ctl统计流式传输100帧的耗时,计算实际帧率。
time v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap --stream-count=100执行完会输出Real time,比如100 frames in 3.3sec,帧率就是30fps。如果实耗是4秒,说明只有25fps,检查曝光时间是否太长,曝光时间超过帧间隔会直接压帧率。再检查GStreamer管道的实际处理速度:
timeout 10 gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=300 ! \ "video/x-raw,format=GRAY10_LE,width=1920,height=1080" ! fakesink300帧除以耗时就是管道能处理的帧率,注意fakesink不渲染,只测采集和拷贝速度。如果这里只有20fps,问题多半在v4l2的驱动队列,而不是编码或显示。
最后录一段RAW原始数据存到本地,验证长时间抓帧不会断流:
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 \ --stream-mmap --stream-out-file=gmls2_test.raw --stream-count=300得到gmls2_test.raw文件后,检查文件大小是否接近30019201080*2字节,如果有偏差,说明中间有丢帧。还可以用ffprobe或ffmpeg确认一下录入的视频是否能正常解码:
ffprobe gmls2_test.raw -f rawvideo -pix_fmt gray10le -video_size 1920x1080如果你不是只想看RAW,可以直接用gst-launch创建一个包含GMLS2实时预览的脚本,我在项目中就是用一个shell脚本把上述命令打包,每次装完驱动跑一遍,输出帧率和丢帧统计,一屏就能看出驱动是否合格。
我的习惯是:每次重新烧录Jetson系统或换一块新的GMLS2摄像头,都会强制把这套验证流程走一遍,而不只是看一眼dmesg就了事。从那次长时间断流排查之后,我再也不跳过稳定性测试了。希望这套安装步骤和避坑记录能帮到你,祝你的Jetson和GMLS2一次点亮。
本文还有配套的精品资源,点击获取