快捷导航
70 129037

关于gmsl相机的使用问题

light 于 2021-3-18 13:17 发表 [复制链接]
贺老师 游客 发表于 2021-3-24 21:25 | 显示全部楼层
light 发表于 2021-3-24 20:38
不太理解,麻烦确认下是以下的哪种情况。也就是说对于0143和这个api,假设从0ms开始曝光,调用这个api,0 ...

您需要在拿到的时间戳,+40ms。

因为:
第一帧的触发时间为t,则正常收到的时间为t + 延时。
第二帧的触发时间为t + 40ms,正常收到的时间为t + 延时 + 40ms。
但由于第一帧没有数据,因此第二帧的时间戳被认为是第一帧的,被设置成了t,但实际应该是t + 40ms
light 游客 发表于 2021-3-25 09:10 | 显示全部楼层
贺老师 发表于 2021-3-24 21:25
您需要在拿到的时间戳,+40ms。

因为:

好的,理解了,总结来说,就是使用api得到图像和曝光时间戳,对于0143相机,这个曝光时间戳需要加上40ms才真实的曝光时间戳,加上后和api返回时的系统时间只差60+ms了,就正常了。
另外还有一个疑问,就是在安装deb包修复50帧丢一帧前,我们已经采集了一批数据,那么这批数据的曝光时间戳修正,也是直接加上40ms就可以继续使用了吗?丢帧问题会导致这种修复方法失效吗?
贺老师 游客 发表于 2021-3-25 09:13 | 显示全部楼层
light 发表于 2021-3-25 09:10
好的,理解了,总结来说,就是使用api得到图像和曝光时间戳,对于0143相机,这个曝光时间戳需要加上40ms ...

您好:

另外还有一个疑问,就是在安装deb包修复50帧丢一帧前,我们已经采集了一批数据,那么这批数据的曝光时间戳修正,也是直接加上40ms就可以继续使用了吗?丢帧问题会导致这种修复方法失效吗?
>>>> 1. 安装deb包之前,曝光时间戳是正确的。因此,+40ms就能够得到正确的时间戳。
>>>> 2. 安装deb包之前,是少了一个触发,因此每2s少了一帧数据。这个是物理上的缺失,没有办法补回。

因此,可以在原有数据上+40 ms,能保证时间戳正确。但是无法弥补之前数据的缺失。
light 游客 发表于 2021-3-26 17:08 | 显示全部楼层
本帖最后由 light 于 2021-3-26 17:26 编辑
贺老师 发表于 2021-3-25 09:13
您好:

另外还有一个疑问,就是在安装deb包修复50帧丢一帧前,我们已经采集了一批数据,那么这批数据的 ...

您好,我仔细打了日志,发现刷了这个deb包,解决了2s丢一帧的问题,但是长时间运行还是会导致一个新的问题,会返回两次一样的时间戳(类似于会出现相邻4帧的时间戳是0ms,80ms,80ms,120ms的情况),测了大约4分30秒,这种情况发生两次,这种情况下第一次80ms的时间戳和其对应的图像,图像是正确的40ms时刻的曝光图像,只是时间戳错了吗,还是图像和时间戳都错了?请问这个问题如何解决呢?
喵喵 游客 发表于 2021-3-26 19:34 | 显示全部楼层
light 发表于 2021-3-26 17:08
您好,我仔细打了日志,发现刷了这个deb包,解决了2s丢一帧的问题,但是长时间运行还是会导致一个新的问题 ...

请您提供一下以下信息以便于我们定位:
1.dpkg -l | grep miivii 的输出
2.cat /etc/miivii_release
3.返回两次一样时间戳的日志log

light 游客 发表于 2021-3-29 12:05 | 显示全部楼层
喵喵 发表于 2021-3-26 19:34
请您提供一下以下信息以便于我们定位:
1.dpkg -l | grep miivii 的输出
2.cat /etc/miivii_release

两个命令的输出如下:
nvidia@miivii-tegra:~$ cat /etc/miivii_release
MIIVII APEX XAVIER 4.4-1.1.0
nvidia@miivii-tegra:~$ dpkg -l|grep miivii
ii  miivii-accelerator                            2.1.0                                            arm64        miivii accelerator sdk
ii  miivii-accelerator-data                       1.0.0                                            arm64        miivii accelerator data
ii  miivii-accelerator-models                     1.6.0                                            arm64        miivii accelerator yolo models
ii  miivii-apex-spe                               4.4-1.0.0                                        arm64        fix gmsl drop frame
ii  miivii-autostarter                            1.0.0                                            arm64        MiiVii Autostater Service.
ii  miivii-fusion                                 1.0.0                                            arm64        mvfusion built using CMake
ii  miivii-gmsl-camera                            2.0.0                                            arm64        MiiVii sensor Dynamic Library and demo.
ii  miivii-human-bike-car-detection               2.1.0                                            arm64        miivii algorithm sdk for human, bike, car detection
ii  miivii-msgs-demo                              1.0                                              arm64        MiiVii miivii_msgs demo.
ii  miivii-perception-demo                        1.0                                              arm64        MiiVii miivii_perception demo.
ii  miivii-sensor-sync                            1.4.0                                            arm64        MiiVii sensor sync demo.
ii  miivii-settings                               1.4.0                                            arm64        MiiVii Settings.
ii  miivii-yolo_batch-models                      1.6.0                                            arm64        miivii yolo batch models

重复的时间戳的日志如下:
W0329 11:18:25.988214 11226 camera_gmsl_component_v2.cc:28]  Proc Camera
I0329 11:18:26.027459 11226 camera_gmsl_component_v2.cc:38]  debug camera timestamp: origin is 1616987905920 , rectified is 1616987905960
I0329 11:18:26.030608 11226 camera_gmsl_component_v2.cc:63]  camera_component_v2: aquire timestamp 1616987905960, send timestamp 1616987906029
W0329 11:18:26.030845 11226 camera_gmsl_component_v2.cc:28]  Proc Camera
I0329 11:18:26.067422 11226 camera_gmsl_component_v2.cc:38]  debug camera timestamp: origin is 1616987906000 , rectified is 1616987906040
E0329 11:18:26.067515 11226 camera_gmsl_component_v2.cc:45]  CAMERA THROW FRAME!!!
I0329 11:18:26.068449 11226 camera_gmsl_component_v2.cc:63]  camera_component_v2: aquire timestamp 1616987906040, send timestamp 1616987906067
W0329 11:18:26.068567 11226 camera_gmsl_component_v2.cc:28]  Proc Camera
I0329 11:18:26.107473 11226 camera_gmsl_component_v2.cc:38]  debug camera timestamp: origin is 1616987906000 , rectified is 1616987906040
I0329 11:18:26.108309 11226 camera_gmsl_component_v2.cc:63]  camera_component_v2: aquire timestamp 1616987906040, send timestamp 1616987906107
W0329 11:18:26.108378 11226 camera_gmsl_component_v2.cc:28]  Proc Camera
I0329 11:18:26.147814 11226 camera_gmsl_component_v2.cc:38]  debug camera timestamp: origin is 1616987906040 , rectified is 1616987906080
I0329 11:18:26.148794 11226 camera_gmsl_component_v2.cc:63]  camera_component_v2: aquire timestamp 1616987906080, send timestamp 1616987906148
注释:debug camera timestamp那条日志,origin是你们api返回的时间戳我使用毫秒进行显示,rectified是因为使用0143,我手动补了40ms得到真实的曝光时间,aquire timestamp也就是rectified的时间,send timestamp是你们api返回后我做简单处理后的发送时刻的系统时间,从日志中可以看出,你们api返回的时间戳有两个1616987906000毫秒,是重复的
light 游客 发表于 2021-3-29 12:08 | 显示全部楼层
light 发表于 2021-3-29 12:05
两个命令的输出如下:
nvidia@miivii-tegra:~$ cat /etc/miivii_release
MIIVII APEX XAVIER 4.4-1.1.0

另外今天在测试的时候我还发现有一个其他问题:
就是在刚开始启动程序的时候偶发时间戳还是相差80ms,见如下日志:
I0329 11:00:00.877877 10212 camera_gmsl_component_v2.cc:38]  debug camera timestamp: origin is 1616986800760 , rectified is 1616986800800
E0329 11:00:00.877969 10212 camera_gmsl_component_v2.cc:45]  CAMERA THROW FRAME!!!
E0329 11:00:00.878000 10212 camera_gmsl_component_v2.cc:49]  FATAL ERROR STEP OF TIMESTAMP TOO LARGE!!! 1.61699e+09 SECONDS
I0329 11:00:00.880393 10212 camera_gmsl_component_v2.cc:63]  camera_component_v2: aquire timestamp 1616986800800, send timestamp 1616986800880
W0329 11:00:00.880479 10212 camera_gmsl_component_v2.cc:28]  Proc Camera
I0329 11:00:00.906880 10212 camera_gmsl_component_v2.cc:38]  debug camera timestamp: origin is 1616986800840 , rectified is 1616986800880
E0329 11:00:00.906970 10212 camera_gmsl_component_v2.cc:45]  CAMERA THROW FRAME!!!
I0329 11:00:00.909646 10212 camera_gmsl_component_v2.cc:63]  camera_component_v2: aquire timestamp 1616986800880, send timestamp 1616986800909
W0329 11:00:00.909715 10212 camera_gmsl_component_v2.cc:28]  Proc Camera
I0329 11:00:00.947062 10212 camera_gmsl_component_v2.cc:38]  debug camera timestamp: origin is 1616986800880 , rectified is 1616986800920
I0329 11:00:00.950012 10212 camera_gmsl_component_v2.cc:63]  camera_component_v2: aquire timestamp 1616986800920, send timestamp 1616986800949
这个问题和时间戳重复那个问题都是偶发,比较随机
light 游客 发表于 2021-3-29 14:29 | 显示全部楼层
light 发表于 2021-3-29 12:08
另外今天在测试的时候我还发现有一个其他问题:
就是在刚开始启动程序的时候偶发时间戳还是相差80ms,见 ...

这会导致一个问题就是,我手动加了40ms的时间戳,和api返回的系统时间戳只差27ms,正常应该是67ms,而上一种情况,有重复时间戳的情况,手动加40ms后,和api返回的系统时间戳还是差67ms左右,是正常的。所以这种情况下,我觉得时间戳就不可用了,因为有了这种随机性。
喵喵 游客 发表于 2021-3-29 16:06 | 显示全部楼层
light 发表于 2021-3-29 14:29
这会导致一个问题就是,我手动加了40ms的时间戳,和api返回的系统时间戳只差27ms,正常应该是67ms,而上 ...

有两个问题需要跟您同步一下:
1.您测试时候用的是几个相机测试的
2.您运行摄像头程序的时候有没有运行其他CPU占比比较高的算法之类的程序,如果有的话提供一下cpu占有率。
light 游客 发表于 2021-3-29 16:12 | 显示全部楼层
喵喵 发表于 2021-3-29 16:06
有两个问题需要跟您同步一下:
1.您测试时候用的是几个相机测试的
2.您运行摄像头程序的时候有没有运行其 ...

我们只使用1个相机。测试的时候没有开算法程序。只有传感器本身的程序,可以排除cpu负载的问题
您需要登录后才可以回帖 登录 | 点我注册

精彩推荐

  • canbus与vcu相连接,出现bus-off状态
  • 有线连接失败
  • Apex 串口通讯
  • 关于SPI通信问题咨询
  • MIIVII APEX DUAL ORIN米文域控制器产品合

明星用户