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

Created on 15 Aug 2018  ·  11Comments  ·  Source: ApolloAuto/apollo

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

cause

@all2one @mbinna @bigwhite @weidezhang @poutyface

image
image

Driver Hardware Help wanted

Most helpful comment

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;

All 11 comments

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

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

Yes, I have checked in the web

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

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

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

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

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

Do your guys have any ideas?

Any update in this @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.

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;

Closing this issue as it appears to be resolved. Feel free to reopen if you have additional questions. Thanks!

Was this page helpful?
0 / 5 - 0 ratings