Proposed addition of GPS and IMU data

[ibaranov-cp]

Hey,

I was wondering why no one ever added in the GPS and IMU data.
I am going to be working on this, and might ask for a merger later.

[jack-oquin]

I have not done it because I lack access to those devices.

Which model are you interested in?

See also: #15

[ibaranov-cp]

32 model, I am working with it now :)
On 28 Mar 2014 21:07, "jack-oquin" notifications@github.com wrote:

I have not done it because I lack access to those devices.

Which model are you interested in?

See also: #15 #15

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-38982290
.

[jack-oquin]

If you are only concerned with the 32E, it publishes these data to a separate UDP port. So, the simplest GPS solution is a small Python node that unpacks those Velodyne packets and sends them to the nmea_navsat_driver, which can interpret NMEA sentences. If you dislike Python, that node could be written in C++ instead.

@gabor-meszaros is interested in similar support for the HDL-64E S2.1, which unfortunately sends the data in the same packets as the LIDAR readings. That would have to be done in the velodyne_driver node or nodelet, I believe.

For the IMU, I am not sure how best to proceed.

[Bramharpan]

I don't know if someone has successfully done it yet. However, once I tried to do such integration of GPS & IMU data logged with my Android phone. Being a second order derivative of position it is very heard to link up acceleration with gps position. and integration of IMU data (area under the curve) do not give reasonable results.

[PatrickHussey]

I'll put up an IMU driver for the HDL-32E soon, we used it to gather IMU data for online 3D mapping but gave up the 32 for a few 16's. I have quite a bit of inertial estimation experience and I must warn that the 32E inertial sensors are not temperature or bias corrected; they are good enough for gross correction since they are frame aligned with laser data and the accs are redundant.

More useful is the GPS NTPD server I used that aligned the laser firing data with our odometry data on the embedded side, it eliminates ghosts at high speed (>6m/s). But since it is so tied into our embedded state estimate it'll probably be a while before I can come up with some way include that. I will include it with the Segway RMP V3 stack that we'll be releasing soon.

[jack-oquin]

Sounds great, thanks!

[ksatyaki]

Is there any update on this? Has the GPS been interfaced?

[ibaranov-cp]

We ended going with an external, higher quality data source anyway.
The onboard IMU and GPS re-boradcast is not great.
Possibly this is being eliminated in the newer small "puck" velodynes anyway.

[PatrickHussey]

Agreed we ended up standardizing on the VLP-16 which does not have the IMU data, we usually use a MicroStrain 3DM-GX3-35 (or 45) in conjunction with the Velodyne sensors.

Like ibaranov-cp said, the Velodyne inertial sensors are not calibrated and the GPS re-broadcast is pretty limited. Go with a good calibrated inertial sensor and a GPS that doesn't get relayed by the Velodyne.

[JWhitleyWork]

GPS data was added some time ago. IMU data does not seem to be wanted. Closing.