3D Mapping with 2 LiDARS + GPS + IMU #1268
Comments
|
Hi,
If the GPS follows same convention described in http://docs.ros.org/en/noetic/api/sensor_msgs/html/msg/NavSatFix.html, it should be fine. However, if the "position_covariance" doesn't represent well the actual error, it may make the optimizer diverges. Anyway, the loop closure error you want to correct would probably not be corrected by the GPS anyway.
Based on your parameters and the small error in that picture, a proximity detection should have been detected. Are there warnings in the terminal when the loop occurs that could explain if the proximity is rejected?
With rtabmap-databaseViewer, you can export the poses in KML format (Google Earth). The point clouds are exported in ENU local coordinates (which the origin 0,0,0 would match the first GPS value). It is possible to export an OBJ, then convert it to DAE with MeshLab, to create a KMZ. I fixed some conversions in this commit to make it possible. For all the questions above, if you can share the database, it could be useful to doublecheck if everything looks fine from here. I have been researching what is the standard to share georeferenced point clouds, and it seems specific to each lidar surveying companies. For example, there is an example here with PDAL converting CSD file (Geodetic WGS84 coordinates: latitude/longitude/altitude) to LAS file in UTM coordinates. This USGS dataset provides LAS files in UTM format, though it seems we cannot save the UTM zone in LAS format, so an external XML file for metadata is required to keep the UTM zone. These leica sample point clouds are not georeferenced. It seems that saving LAS file in WGS84 format is not great either, as softwares like CloudCompare expects georeferenced LAS in XYZ metric values (like UTM) to correctly offset the clouds and display it. Instead of UTM, we could convert to Geocentric WGS84 instead, though not sure what is the standard in the industry. At least as explained in 3., the point cloud origin in local coordinate should match the first GPS pose, that way someone could manually transform the point cloud afterwards. For my own reference, code to convert from WGS84 to UTM: // Convert to UTM
originX=originGPS.latitude(); // latitude
originY=originGPS.longitude(); // longitude
originZ=originGPS.altitude(); // altitude
int utmZone = pdal::SpatialReference::calculateZone(originX, originY);
pdal::SrsTransform wgs84ToUtm(
pdal::SpatialReference("EPSG:4326"), // WGS84: latitude/longitude in deg, altitude in meters
pdal::SpatialReference::wgs84FromZone(utmZone));
wgs84ToUtm.transform(originX, originY, originZ);
// then originX, originY and originZ would be added as offset to all points |
Hello,
I try to do 3D Mapping with 2 LiDARS + GPS + IMU mounted to a car. My position data that is published as
odom->base_linkshould be pretty good because its coming from a high quality positioning system. The maps are looking pretty good as long as I dont scan the same area multiple times in one drive. In the example below we drove 2 loops in a local neighborhood in one session. You can see a clear offset between the 2 loops in the exported 3d map.I have a couple of questions:
"Optimizer/PriorsIgnored": "true"because when I disable it the map gets completely misaligned. Might this be because the GPS data and the Odometry are not the same projection? (GPS is LLH while odometry is in ENU)This is a dump of my params:
The text was updated successfully, but these errors were encountered: