查看: 686|回复: 70

关于gmsl相机的使用问题

[复制链接]

1

主题

36

帖子

117

积分

科员

Rank: 2

积分
117
发表于 2021-3-18 13:17:19 | 显示全部楼层 |阅读模式
关于apex本身和gmsl相机使用方面有两个问题。
1、gmsl相机接口: MvGmslCamera(FLAGS_camera_device, 1, 1280, 720, 25, 1280, 720, "ABGR32")
(1)第5个参数25是否能决定相机的曝光频率,比如这个值填写20,相机是否实际按照20hz工作?如果不能,那么如何设定相机频率?
(2)第6,7个参数1280, 720, 这两个参数是否决定输出图像的大小,比如目前使用1280*720分辨率的相机,那么api中第三第四个参数应该填写1280,720,第六第七个参数,填写1280,720就能拿到原图,填写640,360就能拿到resize一半的图,这样理解是否正确?
(3)设置特定帧率的情况下,比如设置为20hz,调用这个api慢于或者快于这个频率得到的图像时间戳是如何分布的,比如慢于的情况,按照10hz的频率调用这个api,那是否图像的时间戳就是相差100ms?如果快于的情况,比如按照40hz调用api,是否是一次获取不到图像,一次能获取到这种均匀的输出,然后图像时间戳相差50ms?
(4)libmvgmslcamera.so这个提供的动态库,是否按照release模式编译,在sample中提供的CMakeLists.txt示例中,发现编译选项是按照如下选项编译的库 SET(CMAKE_BUILD_TYPE "Debug") SET(CMAKE_CXX_FLAGS_DEBUG "$ENV{CXXFLAGS} -g -O0 -ggdb") 如果是这样编译的那么需要提供release版本的库。
(5)这个api接口中可以直接获得时间戳,那么这个时间戳是否是相机曝光时刻对应的系统时间,系统时间是指clock_gettime或者gettimeofday系统级api获取到的?apex使用gps授时的区别是指系统时间来自于网络还是来自于gps,应用获取时间的借口还是clock_gettime或者gettimeofday这类系统级api,实际测试使用联网后的系统时间打印时间戳,发现有相机曝光时间晚于调用这个api后打印的时间戳的情况

2、关于系统版本,apex的版本是否与官方jetson xavier一一对应,比如官方有4.4,4.4.1,4.5,4.5.1,apex也有完全对应的刷机镜像,刷完机后的库也与官方刷机jetson xavier后的库完全一致(miivii自己新增的除外)?

回复

使用道具 举报

0

主题

92

帖子

200

积分

科长

Rank: 3Rank: 3

积分
200
发表于 2021-3-18 20:50:14 | 显示全部楼层
(1)第5个参数25是否能决定相机的曝光频率,比如这个值填写20,相机是否实际按照20hz工作?如果不能,那么如何设定相机频率?
严格来说,能决定对相机触发曝光的频率,但不能保证决定相机曝光频率。
相机是否能够按照触发曝光频率曝光,属于相机问题,无法保证。
我们只能保证触发曝光的频率。
如果选用我们推荐的相机则可以支持。


(2)第6,7个参数1280, 720, 这两个参数是否决定输出图像的大小,比如目前使用1280*720分辨率的相机,那么api中第三第四个参数应该填写1280,720,第六第七个参数,填写1280,720就能拿到原图,填写640,360就能拿到resize一半的图,这样理解是否正确?
不正确。
摄像头是什么分辨率就需要填写什么分辨率,因为GMSL相机无法通过软件方式知道相机的分辨率。具体请参考SDK头文件。


(3)设置特定帧率的情况下,比如设置为20hz,调用这个api慢于或者快于这个频率得到的图像时间戳是如何分布的,比如慢于的情况,按照10hz的频率调用这个api,那是否图像的时间戳就是相差100ms?如果快于的情况,比如按照40hz调用api,是否是一次获取不到图像,一次能获取到这种均匀的输出,然后图像时间戳相差50ms?

会阻塞。所以不存在你这种情况。


(4)libmvgmslcamera.so这个提供的动态库,是否按照release模式编译,在sample中提供的CMakeLists.txt示例中,发现编译选项是按照如下选项编译的库 SET(CMAKE_BUILD_TYPE "Debug") SET(CMAKE_CXX_FLAGS_DEBUG "$ENV{CXXFLAGS} -g -O0 -ggdb") 如果是这样编译的那么需要提供release版本的库。
目前就是release版本

(5)这个api接口中可以直接获得时间戳,那么这个时间戳是否是相机曝光时刻对应的系统时间,系统时间是指clock_gettime或者gettimeofday系统级api获取到的?
是对应系统时间。

不是从上述API获得。具体如何评估时间准确性可以参考如下链接。物理的评估方式是最精确的。
https://doc.miivii.com/pages/vie ... 5%E6%96%B9%E6%B3%95

apex使用gps授时的区别是指系统时间来自于网络还是来自于gps,应用获取时间的借口还是clock_gettime或者gettimeofday这类系统级api,实际测试使用联网后的系统时间打印时间戳,发现有相机曝光时间晚于调用这个api后打印的时间戳的情况。
这部分是否可以给出详细的设置,以及测试代码?虽然理论会发生,但一般不会发生。
有一种办法可以核对哪个是正确的,即通过核对上述两种方式,所获得的两个图片的曝光间隔是否正确。

2、关于系统版本,apex的版本是否与官方jetson xavier一一对应,比如官方有4.4,4.4.1,4.5,4.5.1,apex也有完全对应的刷机镜像,刷完机后的库也与官方刷机jetson xavier后的库完全一致(miivii自己新增的除外)?
都不一定。
比如Jetpack,如4.4.1等版本,由于没有feature引入,也没有bugfix,我们就不会升级。
如4.5.1,只支持了TX2 NX,对所有其他设备都没有影响,所以也不会有其他设备的版本。
但Jetpack 4.4,Jetpack 4.5都会对应。
刷完机的库是不完全一样的,会有部分依赖库有区别,但nvidia提供的库,和官方刷机中nvidia提供的库是一样的。具体可以用dpkg -l | grep nvidia命令来进行对比。




回复

使用道具 举报

1

主题

36

帖子

117

积分

科员

Rank: 2

积分
117
 楼主| 发表于 2021-3-19 19:27:40 | 显示全部楼层
贺老师 发表于 2021-3-18 20:50
(1)第5个参数25是否能决定相机的曝光频率,比如这个值填写20,相机是否实际按照20hz工作?如果不能,那么 ...

        * @param[in] &devName Camera's device node name.
        * @param[in] camCount Number of cameras plugged into the device node.
        * @param[in] camWidth Single camera output width.
        * @param[in] camHeight Single camera output height.
        * @param[in] fps Frame rate(expressed in frames per second or FPS) .
        * @param[in] imgWidth Output image width.
        * @param[in] imgHeight Output image height.
        * @param[in] format Image format.
1、相机确认是1280*720的分辨率,按照这个函数的参数说明,camWidth填写1280,camHeight填写720,imgWidth和imgHeight看说明是这个api会根据这两个参数resize到这个尺寸,也就是如果imgWidth和imgHeight填写1280和720,那就是直接输出原图,如果填写640和360,那就是会resize到这个尺寸,这样理解应该是对的吧?
2、相机并非使用系统级api得到时间戳,那么我在使用apex时候,使用了gps授时,同时通过can和串口读取了另外两路传感器,那么这两路传感器我只能打系统时间戳(clock_gettime),但是我们对时间同步有严格要求,那么我调用相机api得到的时间戳,和gps授时情况下另外两路传感器的系统时间戳,时钟来源能保证是一个吗?也就是能否满足同步的要求?
回复

使用道具 举报

0

主题

92

帖子

200

积分

科长

Rank: 3Rank: 3

积分
200
发表于 2021-3-19 19:40:16 | 显示全部楼层
light 发表于 2021-3-19 19:27
* @param &devName Camera's device node name.
        * @param camCount Number of cameras p ...

1、相机确认是1280*720的分辨率,按照这个函数的参数说明,camWidth填写1280,camHeight填写720,imgWidth和imgHeight看说明是这个api会根据这两个参数resize到这个尺寸,也就是如果imgWidth和imgHeight填写1280和720,那就是直接输出原图,如果填写640和360,那就是会resize到这个尺寸,这样理解应该是对的吧?
>> 这个理解是对的。

2、相机并非使用系统级api得到时间戳,那么我在使用apex时候,使用了gps授时,同时通过can和串口读取了另外两路传感器,那么这两路传感器我只能打系统时间戳(clock_gettime),但是我们对时间同步有严格要求,那么我调用相机api得到的时间戳,和gps授时情况下另外两路传感器的系统时间戳,时钟来源能保证是一个吗?也就是能否满足同步的要求?
>> 如果对时间同步有严格要求的话,一般会在通过单片机,直接接入另外两路传感器,并且在单片机上添加被PPS的功能。然后把传感器数据上加上时间戳,尽可能通过高带宽的接口回传到设备,这种情况下,才能够叫做"严格"的同步。
对于您提到的场景,虽然通过相机api得到的时间戳,和其他两路传感器的时间戳(通过clock_gettime),物理上是一个时钟来源。
但是因为clock_gettime的实时性问题,以及你获取传感器数据本身linux带来的实时性问题,这种同步是不严谨的(误差应该是10ms量级)。当然一般会直接通过linux接入can或者串口就意味着对同步性要求不太高,所以应该对你来说够用了。
回复

使用道具 举报

1

主题

36

帖子

117

积分

科员

Rank: 2

积分
117
 楼主| 发表于 2021-3-24 13:00:19 | 显示全部楼层
贺老师 发表于 2021-3-19 19:40
1、相机确认是1280*720的分辨率,按照这个函数的参数说明,camWidth填写1280,camHeight填写720,imgWidt ...

您好,我们还遇到两个问题
1、使用GetImageCvMat进行图像读取,在外部gps授时后,使用系统自带的例子测试,比较相邻两帧图像的时间戳,50帧会丢1帧(也就是2秒丢一帧,此时返回的曝光时间戳和上一帧曝光时间相差80ms,正常情况是相差40ms),如果不使用gps授时,则是正常的25hz,不会丢帧。
2、使用系统自带的例子,使用GetImageCvMat进行图像读取,api返回的曝光时间戳和api返回后立刻打上系统时间戳,系统时间戳比曝光时间戳大100ms,为什么会有这么大的延迟?
回复

使用道具 举报

0

主题

92

帖子

200

积分

科长

Rank: 3Rank: 3

积分
200
发表于 2021-3-24 14:36:45 | 显示全部楼层
light 发表于 2021-3-24 13:00
您好,我们还遇到两个问题
1、使用GetImageCvMat进行图像读取,在外部gps授时后,使用系统自带的例子测试 ...

您好

对于第一个问题:
cat /etc/miivii-release 命令查看一下Apex的镜像版本。
如果是4.4-v1.0.0则会存在这个问题。
如果是4.4-v1.3.0,则这个问题修复。

对于第二个问题:
正常的时间应该为67ms左右,见使用手册。但是使用0143的传感器,会出现第个触发没有数据的问题。因此延时会比正常情况多一个周期。
https://doc.miivii.com/pages/vie ... 8%E6%96%B9%E6%B3%95
回复

使用道具 举报

1

主题

4

帖子

37

积分

版主

Rank: 7Rank: 7Rank: 7

积分
37
发表于 2021-3-24 15:09:20 | 显示全部楼层
light 发表于 2021-3-24 13:00
您好,我们还遇到两个问题
1、使用GetImageCvMat进行图像读取,在外部gps授时后,使用系统自带的例子测试 ...

问题1:请安装《miivii-apex-spe-master4.4-1.0.0-aarch64》
仅适用4.4-1.1.0版本软件

miivii-apex-spe-master4.4-1.0.0-aarch64.rar

36.27 KB, 下载次数: 15

适用APEX 4.4-1.1.0版本软件

回复

使用道具 举报

1

主题

36

帖子

117

积分

科员

Rank: 2

积分
117
 楼主| 发表于 2021-3-24 19:35:17 | 显示全部楼层
sky 发表于 2021-3-24 15:09
问题1:请安装《miivii-apex-spe-master4.4-1.0.0-aarch64》
仅适用4.4-1.1.0版本软件

1、我们是4.4-1.1.0的版本,装了您提供的1.0.0的deb也解决了,但是我还想确认下担心有其他问题,就是1.1.0确实是使用1.0.0的deb包,没有1.1.0对应的包吧?
2、对于第二个问题,我们是使用0143相机,您上一个回复没打完整,是指第一次触发没有数据?如果是这样的话,那这个api得到的时间戳是准确的吗,比如第一次触发没数据,是第二次触发产生的数据,那么时间戳打的是第二次曝光的时间戳吗?是否存在需要我们手动调整时间戳的可能?
3、对于0143相机,延时大于100毫秒是不是一个普遍问题,无论以后使用apex2或者升级任何系统版本,都会导致延时大于100毫秒呢?也就是最好使用其他型号的相机?
回复

使用道具 举报

0

主题

92

帖子

200

积分

科长

Rank: 3Rank: 3

积分
200
发表于 2021-3-24 20:03:16 | 显示全部楼层
light 发表于 2021-3-24 19:35
1、我们是4.4-1.1.0的版本,装了您提供的1.0.0的deb也解决了,但是我还想确认下担心有其他问题,就是1.1. ...

1、我们是4.4-1.1.0的版本,装了您提供的1.0.0的deb也解决了,但是我还想确认下担心有其他问题,就是1.1.0确实是使用1.0.0的deb包,没有1.1.0对应的包吧?
>>>
这个其实是这样的,目前这部分因为不是系统镜像的一部分,所以并没有在系统的deb包中存在,所以在系统中不存在单独的版本。
因此我们是单独创建了一个deb包,但目前,以及后续,都不会有这个deb包的release的。(这部分是一个单独的版本管理机制)
因为是特制的,所以目前叫做了v1.0.0,和系统镜像v1.1.0并没有什么关系。

2、对于第二个问题,我们是使用0143相机,您上一个回复没打完整,是指第一次触发没有数据?如果是这样的话,那这个api得到的时间戳是准确的吗,比如第一次触发没数据,是第二次触发产生的数据,那么时间戳打的是第二次曝光的时间戳吗?是否存在需要我们手动调整时间戳的可能?
>>> 由于第一次触发,传感器没有返回数据,所以目前的SDK会把第一次收到的数据,当做是第一次触发的数据。因此打上的时间戳,会比真实的时间戳,多一个帧的时间。
因此实际的时间戳,需要减去1/fps,也就是一帧的时间间隔。如果是25fps,则减去40ms即可。
时间戳本身是准的,只是打到的帧上错开了一帧。


3、对于0143相机,延时大于100毫秒是不是一个普遍问题,无论以后使用apex2或者升级任何系统版本,都会导致延时大于100毫秒呢?也就是最好使用其他型号的相机?
>>> 不是,这部分可以见上面的链接。
真实的延时,只和物理硬件相关。对于GMSL1,大约是60+ms,对于GMSL2,则是40ms左右。
0143,比较奇葩,没法第一帧。所以看上去延时变成了60+ms + 40ms = 100 + ms。
但真实的延时,仍然为60+ms。
回复

使用道具 举报

1

主题

36

帖子

117

积分

科员

Rank: 2

积分
117
 楼主| 发表于 2021-3-24 20:38:49 | 显示全部楼层
贺老师 发表于 2021-3-24 20:03
1、我们是4.4-1.1.0的版本,装了您提供的1.0.0的deb也解决了,但是我还想确认下担心有其他问题,就是1.1. ...

不太理解,麻烦确认下是以下的哪种情况。也就是说对于0143和这个api,假设从0ms开始曝光,调用这个api,0ms曝光的图像返回的时间戳是40ms? 这样理解对吗?我收到图像和时间戳后需要手动减40ms得到真实的0ms时间戳?那这样的话不是和api调用完成后的系统时间差的更多了吗?还是我理解有误,应该是40ms时刻曝光的图像返回的时间戳是0ms,我需要手动加上40ms,是哪一种?
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 点我注册

本版积分规则


快速回复 返回顶部 返回列表