search

ros-drivers / velodyne

ROS support for Velodyne 3D LIDARs
http://ros.org/wiki/velodyne
Other
647 stars 643 forks source link

Proposed addition of GPS and IMU data #24

Closed ibaranov-cp closed 1 year ago

ibaranov-cp commented 10 years ago

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 commented 10 years ago

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

Which model are you interested in?

See also: #15

ibaranov-cp commented 10 years ago

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 https://github.com/ros-drivers/velodyne/issues/15

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

jack-oquin commented 10 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Sounds great, thanks!

ksatyaki commented 7 years ago

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

ibaranov-cp commented 7 years ago

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 commented 7 years ago

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 commented 1 year ago

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