快捷导航
17 39981

关于GMSL相机的使用问题(二)

light 于 2021-4-21 10:30 发表 关闭 [复制链接]
原有同名帖子超过1个月无法发帖了,新开一个续帖

1、目前我们使用apex2+你们提供的两个deb,使用0143相机,返回减曝光是66ms,那么我们拿到的曝光时间戳,直接就可以使用了吧?不需要再和以前apex1一样(当时返回减曝光是100ms+),手动加上40ms(一帧时间)了吗?



2、目前apex2在使用上,也是要注意两次sdk启动间隔不能太短是吗?


3、后面如果换成Imx390(固件刷为外部触发模式),你们提供的两个deb包仍然适用吗?还是要重新更新deb?
举报 使用道具
| 回复

共 17 个关于本帖的回复 最后回复于 2021-6-2 10:35

Hcheng 游客 发表于 2021-4-22 16:21 | 显示全部楼层
您好:

1. 是的我们改进了代码。处理了这种异常情况。

2. 是的。

3. 适用,不过IMX390目前在30Hz的时候,我们发现有些小问题(30Hz以下是没问题的)。4月30日前我们会通过OTA修复,作为正式的release。这样后续只要是能够点亮的相机,就都可以使用了。
light 游客 发表于 2021-4-22 17:48 | 显示全部楼层
本帖最后由 light 于 2021-4-22 17:55 编辑

我们让森云将390更新为外部触发模式了,但是我们测试依然存在问题;
1. 30fps下,从曝光到获取图像之间的延时在100多毫秒,并且延时在慢慢减少,与之前同步的40ms有较大差别;
2. 我通过命令行更改fps至25hz,则会出现频繁的帧间隔错误,是否需要更新你们新的deb?
>>>>3. 适用,不过IMX390目前在30Hz的时候,我们发现有些小问题(30Hz以下是没问题的)。4月30日前我们会通过OTA修复,作为正式的release。这样后续只要是能够点亮的相机,就都可以使用了。
3. 这个是使用外部触发的390测试出来的么?可否提前release给我们先测试下?

light 游客 发表于 2021-4-25 18:07 | 显示全部楼层
在使用apex2的串口时候,发现一个问题,我们的惯导串口(波特率460800)通过usb转串口线,连接到usb口来读取串口信息(100hz报文),和惯导串口直接连接线束上的ttyUART_232_A, ttyUART_232_C时候,同样版本的软件和固件,同样使用460800波特率接收100hz报文,数据接收延迟变大了(收到时刻的系统时间戳减去报文中的数据产生时间),这个问题你们那边能否同步测试一下呢?不确定是apex2本身的问题还是由于apex2和我们惯导硬件适配上的问题,所以希望能帮忙交叉验证一下。
Hcheng 游客 发表于 2021-4-25 18:14 | 显示全部楼层
light 发表于 2021-4-25 18:07
在使用apex2的串口时候,发现一个问题,我们的惯导串口(波特率460800)通过usb转串口线,连接到usb口来读 ...

您好:

您的意思是:
通过USB口读的延时,相对于通过线束上的延时要大?
还是通过线束的延时,比通过USB的延时要大呀?
light 游客 发表于 2021-4-25 18:21 | 显示全部楼层
Hcheng 发表于 2021-4-25 18:14
您好:

您的意思是:

通过线束直接读取串口,比通过usb转串口读取串口,的延迟更大。
我们惯导目前发送数据存在一定的不均匀性,有的数据有延迟大,有的延迟小,但是一般usb转串口读取时候,延迟30ms左右的报文,线束读取延迟会到90+ms,一般延迟3ms左右的,线束读取延迟会到10+ms
Hcheng 游客 发表于 2021-4-25 18:43 | 显示全部楼层
light 发表于 2021-4-25 18:21
通过线束直接读取串口,比通过usb转串口读取串口,的延迟更大。
我们惯导目前发送数据存在一定的不均匀性 ...

您好:

您的这个用例牛,我们的测试还真没有覆盖。。。

首先想了解一下您是通过什么方式确定这个延时的?是这个惯导是能够接受PPS授时,并且发送带时间戳的数据么?
最后我们通过接收到数据的时间减去时间戳时间,得到这个延时么?

我们分析了下电路,因为线束上您用到的两个串口,都是通过核心模组直接引出的,仅仅经过了232的电平转换,硬件上分析了一下,按理不应该出现这样的情况。

感觉这个问题不进行复现没法定位到原因,但是我们这边还没想到有特别好的方法能够重现您说的这种问题。
Hcheng 游客 发表于 2021-4-25 18:47 | 显示全部楼层
light 发表于 2021-4-25 18:21
通过线束直接读取串口,比通过usb转串口读取串口,的延迟更大。
我们惯导目前发送数据存在一定的不均匀性 ...

另外,这个延迟3ms的报文长度,和延迟30ms的报文长度,方便透露么?
我们也可以帮助分析一下。
light 游客 发表于 2021-4-26 10:13 | 显示全部楼层
Hcheng 发表于 2021-4-25 18:47
另外,这个延迟3ms的报文长度,和延迟30ms的报文长度,方便透露么?
我们也可以帮助分析一下。 ...

我使用惯导进行GPS授时,然后惯导的100hz的rawimux报文(长度小于100字节)中会发送周秒,我把周秒转成utc,和收到这个报文的系统时间(也是utc)进行比较,后者减前者得到延迟,这个延迟由两部分组成,发送延迟+传输延迟,后面说的延迟时间都是包含这两个部分的,但我理解对于发送来说,应该是由惯导本身决定的,所以这部分是不变的,引起变化的应该是传输延时。目前我们惯导的报文在使用usb转串口通过usb读取报文时候,最大延迟30ms,最小2-3ms。但是使用线束上的ttyUART_232_C(对应设备上应该是/dev/ttyTHS4),最大延迟90+ms,最小也是2-3ms。如果使用线束上的ttyUART_232_A(对应设备上应该是/dev/ttyUSB3),这个没有细测,最大延迟小一些,情况应该稍微好一些。
light 游客 发表于 2021-4-26 10:56 | 显示全部楼层
Hcheng 发表于 2021-4-22 16:21
您好:

1. 是的我们改进了代码。处理了这种异常情况。

390相机问题的修复包能否先提供下?我们这边也好先验证下。
您需要登录后才可以回帖 登录 | 点我注册

精彩推荐

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

明星用户