关于gmsl相机的使用问题

light 发表于 2021-3-24 20:38
不太理解，麻烦确认下是以下的哪种情况。也就是说对于0143和这个api，假设从0ms开始曝光，调用这个api，0 ...

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

因为：
第一帧的触发时间为t，则正常收到的时间为t + 延时。
第二帧的触发时间为t + 40ms，正常收到的时间为t + 延时 + 40ms。
但由于第一帧没有数据，因此第二帧的时间戳被认为是第一帧的，被设置成了t，但实际应该是t + 40ms

贺老师 发表于 2021-3-24 21:25
您需要在拿到的时间戳，+40ms。

因为：

好的，理解了，总结来说，就是使用api得到图像和曝光时间戳，对于0143相机，这个曝光时间戳需要加上40ms才真实的曝光时间戳，加上后和api返回时的系统时间只差60+ms了，就正常了。
另外还有一个疑问，就是在安装deb包修复50帧丢一帧前，我们已经采集了一批数据，那么这批数据的曝光时间戳修正，也是直接加上40ms就可以继续使用了吗？丢帧问题会导致这种修复方法失效吗？

light 发表于 2021-3-25 09:10
好的，理解了，总结来说，就是使用api得到图像和曝光时间戳，对于0143相机，这个曝光时间戳需要加上40ms ...

您好：

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

因此，可以在原有数据上+40 ms，能保证时间戳正确。但是无法弥补之前数据的缺失。

贺老师 发表于 2021-3-25 09:13
您好：

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

您好，我仔细打了日志，发现刷了这个deb包，解决了2s丢一帧的问题，但是长时间运行还是会导致一个新的问题，会返回两次一样的时间戳（类似于会出现相邻4帧的时间戳是0ms，80ms，80ms，120ms的情况），测了大约4分30秒，这种情况发生两次，这种情况下第一次80ms的时间戳和其对应的图像，图像是正确的40ms时刻的曝光图像，只是时间戳错了吗，还是图像和时间戳都错了？请问这个问题如何解决呢？

light 发表于 2021-3-26 17:08
您好，我仔细打了日志，发现刷了这个deb包，解决了2s丢一帧的问题，但是长时间运行还是会导致一个新的问题 ...

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

喵喵 发表于 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: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 12:08
另外今天在测试的时候我还发现有一个其他问题：
就是在刚开始启动程序的时候偶发时间戳还是相差80ms，见 ...

这会导致一个问题就是，我手动加了40ms的时间戳，和api返回的系统时间戳只差27ms，正常应该是67ms，而上一种情况，有重复时间戳的情况，手动加40ms后，和api返回的系统时间戳还是差67ms左右，是正常的。所以这种情况下，我觉得时间戳就不可用了，因为有了这种随机性。

light 发表于 2021-3-29 14:29
这会导致一个问题就是，我手动加了40ms的时间戳，和api返回的系统时间戳只差27ms，正常应该是67ms，而上 ...

有两个问题需要跟您同步一下：
1.您测试时候用的是几个相机测试的
2.您运行摄像头程序的时候有没有运行其他CPU占比比较高的算法之类的程序，如果有的话提供一下cpu占有率。

喵喵 发表于 2021-3-29 16:06
有两个问题需要跟您同步一下：
1.您测试时候用的是几个相机测试的
2.您运行摄像头程序的时候有没有运行其 ...

我们只使用1个相机。测试的时候没有开算法程序。只有传感器本身的程序，可以排除cpu负载的问题