velodyne
velodyne copied to clipboard
ros-drivers
Proposed addition of GPS and IMU data
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.
I have not done it because I lack access to those devices.
Which model are you interested in?
See also: #15
32 model, I am working with it now :) On 28 Mar 2014 21:07, "jack-oquin" [email protected] 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 .
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.
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.
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.
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.
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.
GPS data was added some time ago. IMU data does not seem to be wanted. Closing.
