VLP-16 /apollo/sensor/velodyne16/PointCloud2/header Timestamp is not GPS Time

[carlin314]

VLP-16 /apollo/sensor/velodyne16/PointCloud2/header Timestamp is not GPS Time

cause

[ WARN] [1534337139.532238124]: Can not find transform frame: velodyne16. 1534337850.896429 Error info: Lookup would require extrapolation into the future. Requested time 1534337850.896429062 but the latest data is at time 1534337139.200000048, when looking up transform from frame [velodyne16] to frame [map]. canTransform returned after 0.101808 timeout was 0.1
@all2one @mbinna @bigwhite @weidezhang @poutyface

[carlin314]

Left is the /apollo/sensor/velodyne16/PointCloud2/header's Time,Right is novatel inspva time

[YangHan101]

Is the GPS synchronization signal connected to the VLP-16?

[carlin314]

Yes, I have checked in the web

[carlin314]

I also used the official velodyne driver, the lidar time is correct,same with inspva time

[snehagn]

Hi @carlin314 - Is the velodyne getting the PPS and GPRMC signal from the Novatel?

[YangHan101]

@carlin314 Could you post a screenshot of the web interface?
Do you have valid GPS localization solution?

[carlin314]

@snehagn @YangHan101 Thx dude,the screenshot is as follows

I really dont know,what could be wrong, the header time is from the packet time?

Do your guys have any ideas?

[carlin314]

Any update in this @xinwf

[xinwf]

We haven't met this problem any more.

You can do two following things:

1. Make sure the processing of IMU time is right. Once one of my colleagues treats the us as ms when dealing with IMU's time, it caused this problem.
2. Make sure the apollo is broadcast extrinsic all the time from velodyne16 to world frame.
   Besides these two reasons, if the machine runs very slowly especially the disk has an very high I/O ratio, it will also cause this problem, but this is not the apollo's problem.

Good luck.

[carlin314]

We haven't met this problem any more.

You can do two following things:

1. Make sure the processing of IMU time is right. Once one of my colleagues treats the us as ms when dealing with IMU's time, it caused this problem.
2. Make sure the apollo is broadcast extrinsic all the time from velodyne16 to world frame.
   Besides these two reasons, if the machine runs very slowly especially the disk has an very high I/O ratio, it will also cause this problem, but this is not the apollo's problem.

Good luck.

Thx for your reply, I have solve this problem I think

I find basetime in Velodyen_Parser.cpp confusing, gps_base_usec_ is the hour , and this is right, but basetime in it, what I think should mean the minute, but the minute mess the thing, it can lack 15 min, 45 min 30 min, or when a hour passed ,it will advance current time, but I find the time in the packet is same with the gps,which is right. So I use this time to substitute it.

// double basetime = raw->gps_timestamp;  // usec
double basetime = (pkt.stamp.toSec() - gps_base_usec_/1e6)*1e6;