057、英伟达Jetson ISP的Argus框架编程控制：自定义ISP参数管线与多相机同步的实时性优化

057、英伟达Jetson ISP的Argus框架编程控制：自定义ISP参数管线与多相机同步的实时性优化上个月在给一个车载客户调多目环视方案，Jetson Orin上接了六颗GMSL相机，客户反馈一个诡异现象：车辆低速绕桩时，左右视角拼接的车道线总在抖动，不是那种均匀的延迟，而是像抽风一样每隔几秒跳一下。一开始怀疑是相机硬件触发抖动，拿示波器量了FSYNC，干净得很。后来在Argus回调里打了时间戳，发现丢帧倒是没有，但部分帧的曝光时间明显偏长，而且集中在某一路相机上。查了一圈，最后定位到是ISP的自动曝光收敛和Argus的请求队列调度打架了——默认的AE算法在低照度场景下会频繁调整曝光参数，而Argus的CaptureRequest提交是异步的，参数更新和帧出图之间隔了好几个buffer，导致某一路相机的曝光参数总是慢半拍。这个问题折腾了三天，最后是绕开Argus的自动控制，直接接管ISP参数管线才解决。今天就把这套东西拆开讲讲。先说Argus这个框架的本质。它不像V4L2那样把ISP的控制权完全交给用户，而是搞了一套基于请求-响应的异步模型。你提交一个CaptureRequest，里面塞上你要的曝光、增益、白平衡这些参数，Argus内部会把这些请求排队，然后由ISP的硬件状态机逐个消费。听起来很合理对吧？但问题就出在这个“排队”上。Jetson的ISP硬件其实只有一个，多路相机是靠分时复用跑的，Argus为了平衡各路相机的帧率，会在请求队列里做调度。如果你的某一路相机提交请求的频率不稳定，或者请求里的参数变化太剧烈，调度器就会为了照顾其他相机而推迟你这路的参数生效时间。我见过最夸张的情况，参数延迟了整整三帧，这在环视拼接场景下就是几十毫秒的误差，车道线不