本文首发于公众号：【事件相机】，CeleX5相机使用系列 - 相机的时间戳

CeleX5相机在使用时有多种时间戳，包括事件产生时间戳inPixelTimestamp，事件输出时间戳offPixelTimestamp，还有机器（例如ROS）收到时的时间戳。本文详细介绍这些时间戳的内容，并指出CeleX官方提供的库函数中的一个bug。本文将上述三个时间戳简称为inTs，offTs和rosTs。

事件产生时间戳inTs

顾名思义，inTs是某个Event在芯片上产生时的时间戳，从0开始记，单位为us。时间依据是相机自身的晶振。需要注意inTs只有在Event In-Pixel Timestamp模式下才能产生，在其他模式下inTs为0。

事件输出时间戳offTs

一般事件相机只会泛泛的说“时间戳”，而不会像CeleX这样有产生、输出时间戳。这里详细介绍二者的区别。

（图：事件从芯片到外设）

offTs是某个Event从芯片输出到相机板卡时的时间戳，从0开始记，单位为us。时间依据是相机自身的晶振。上图展示了芯片内部数据到板卡数据的传输过程：左边芯片的事件经过编码后，经过AER总线，到板卡，板卡再进行解码得到数据。所谓AER总线，全称是“Address Event Representation”，是一种事件相机数据通信协议。

由于CeleX分辨率极高，数据量较大，事件输出并不是按照产生顺序的，而是逐行进行。下图介绍了输出Event的顺序：每次从某一行开始输出，往下逐行进行（到799行后回到0），直到再次输出到这一行。我将这一个过程称作一个“输出循环”。输出到某一行时，如果在上一个输出循环中经过这行到这次输出这行的过程中，这一行产生了Event，则会输出新产生的Event。所以offTs是“扫到某行数据”时的时间，而并不是数据本身产生的时间。

（图片来源：CeleX官方SDK文档）

inTs和offTs存在的问题

一张图解释清楚了二者的问题。我的PC端每次收到一组Events后输出每个event，可以看出，由于PC接收顺序是相机的输出顺序，故offTs是连续增加的，且对应某一行（例如y=500）的时间戳是相同的（图中打错了应该是“同一行”而不是“同一列”）。再看inTs，并不是递增的。

再多说一段解释为何inTs不是递增的：例如在某一次输出循环中的三个事件e0,e1,e2在产生时间上是先后发生的，但位置分别发生在第0,100和1行，那么从第0行开始输出e0后，逐行扫描到第1行时输出e2，之后需要等到第100行时才能够输出e1，即输出顺序为e0,e2,e1。

PC端接收的时间戳rosTs

PC端接收时，如果采用ROS，会有一个Ros::Time()或header的时间戳，对应的是PC端的时间戳。这里暂时不细说，后面准备写一篇总结事件相机数据延迟的问题推送，到时候详细介绍。

时间戳对齐问题（ROS）

上面说到，inTs和offTs全部是从0开始递增，按照相机的时钟计时。那么自然想知道，相机的ts和rosTs即PC端时间戳的关系。严格来讲，在打开sensor即调用函数openSensor()后，CeleX就开始从0计数。我们可以通过这个来对时间戳进行对齐。但我实际使用时发现，启动指令下达后，到相机真正开始计时还是有一段儿时间的。

另一种方法，是调用getEventDataVector时采用下图第三个形式，获取PC端的时间戳。这样获得的是收到数据时PC的时间戳，理论上（我没有验证）为最后一个offTs的PC时间，但这也会存在PC到相机的时间延迟。

（图片来源：CeleX官方SDK文档）

CeleX官方ROS驱动的Bug

某次我在测试ts时，发现在经过大概30秒后，ts会回到0。inTs和offTs都会发生这个问题。查看了inTs和offTs定义，都是uint32，理论上不会在这个数越界。后来查找问题发现是ROS下源码在计算ts时发生了越界。相关的源码我已修复上传到了GitHub：https://github.com/LarryDong/CeleX5_source。请大家下载重新编译libCeleX.so后使用。

（图：官方源码部分修改）

另外，官方很久没有对该代码进行更新维护。如果有人遇到其他bug，请不管您是否已经解决，都在上述代码中提个issue，大家一起解决。谢谢。

欢迎关注微信公众号【事件相机】，分享和交流事件相机的相关研究与应用。