TROS下,图像采集与算法推理耦合问题

图像采集节点发布图像数据速度较快,而推理节点处理速度较慢的情况。

1. 图像数据会不会出现堆积。

2.如果图像出现堆积,那么会导致t时刻采集到的图像,延迟相当长的时间才能推理并发布。有没有途径能降低这种延迟。换句话说,能不能只订阅最新图像进行推理。

问题1:会出现数据堆积,当订阅到图片后处理耗时大于图片发布时间间隔就会出现堆积。

问题2:解决方法

使用create_subscription/create_subscription_hbmem接口创建图片数据的订阅者时会通过qos参数指定缓存数据量,一般是10,可以将参数指定为1(需要修改源码后重新编译),即只缓存一帧数据,能够保证订阅到的数据时最新的图像。

mipi_cam图像发布节点的发布者队列长度需要设置为1吗?发布者和订阅者两个队列长度之间有什么关系?

不需要,发布和订阅是完全解耦的,所以两者的队列长度之间没有关系。

改了订阅的队列长度之后,拿到的图像数据延迟有多少?

把订阅者队列长度设置为1后,采用同步模式推理,task_num=1,图片订阅延迟为40+ms,还是偏高。

这里图片订阅延迟是这样算的:

在订阅回调函数起点clock_gettime时间戳 - img_msg中的时间戳。

不做推理延迟是多长时间,也就是回调里面订阅到图片,统计后直接返回,不做后续处理。

延迟为27ms,这个时间是否正常

那说明推理耗时比较长,订阅回调被长时间阻塞导致没有及时处理订阅到的图像数据。可以设置成异步推理模式。

队列已设置为1的情况下,没有及时处理的数据应该被丢弃了吧,此时为什么推理耗时还会影响订阅延迟呢?

另外,不做推理时,订阅延迟27ms是不是也偏高了,我理解应该1-2ms就被订阅到。

1、推理影响订阅延迟。

摄像头采集图像的帧率是30fps,也就是两帧图像数据的时间间隔是33ms。

队列长度设置为1时,一帧图像数据最长在队列里面缓存时间是33ms。

如果图像数据从产生到进入到订阅队列的延迟是N ms,推理耗时比较长(超过帧间隔也就是33ms)的情况下订阅回调中订阅到图像数据时最大延迟是N+33ms。

2、订阅延迟。

不做推理的情况下,图像数据从产生到订阅到的延迟时间主要有三部分组成:图像曝光时间、图像发布前的处理、传输时间。

图像数据的时间戳是开始曝光的时间,曝光时间大概是30ms左右,图像发布前的处理在几个ms,对于零拷贝传输时间也是几个ms。

所以不做推理的情况下延迟时间是30ms左右。做推理并且队列长度为1时,最大延迟是30+33=63ms。

1. “图像数据从产生到进入到订阅队列的延迟是N ms“应该怎么理解呢?如果图像采集的帧率是30fps,那么采集间隔应该固定为33ms,延迟N应该就是在33ms的基础上增加了传输时间几个ms吧,延迟N>33?。

2. 《队列长度设置为1时,一帧图像数据最长在队列里面缓存时间是33ms。》缓存时间为什么是33,而不是延迟N呢?队列里的图像在新的图像进队之后才会被替换掉。

2. “回调中订阅到图像数据时最大延迟是N+33ms“这个应该怎么理解?

1、首先要理解帧间隔和延迟这两个概念。

帧间隔指的是两帧数据之间的时间间隔,由帧率决定。如果帧率是30fps,帧间隔就是固定的33ms(假设图像处理、传输的总时间小于33ms)。

延迟指的是一个过程的耗时。例如图像采集完成到订阅端订阅到图像,这是一个过程,这个时间就是图像的延迟。对于图像的延迟(例如N毫秒),可以理解成订阅到的图像数据是物理世界N毫秒之前的状态。

2、缓存时间是由帧间隔决定,而不是帧延迟。

因为在下一帧数据来之前,当前帧可以一直存在于缓存中,而下一帧是33ms之后才会到来。

3、理解了帧间隔和延迟这两个概念之后,回调中订阅到图像数据的最大延迟是N+33ms这一点应该能够理解吧。

4、可以做下实验,对比下发布和订阅端图像数据的时间戳,以及每个处理步骤的时间戳。