RobustFieldAutonomyLab / LeGO-LOAM

LeGO-LOAM: Lightweight and Ground-Optimized Lidar Odometry and Mapping on Variable Terrain
BSD 3-Clause "New" or "Revised" License
2.36k stars 1.11k forks source link

Coordinate 'Transformation' between poses #131

Closed YangSiri closed 4 years ago

YangSiri commented 4 years ago

Hi, great LeGO contributors. A samll or maybe stupid question arises since i have been reading the codes: I notice the coordinate between the 'globalmap' and vlp is different. So the 'cloudkeypose6D' becomes weird while using it to build the map in ordinary laser-scanner frame. I see this 'transformation' many times in the codes and I think its pretty confusing. I start to wonder why would you do that. There's gotta be a reason, right?

Example 'transformation' in codes: odomAftMapped.header.stamp = ros::Time().fromSec(timeLaserOdometry); odomAftMapped.pose.pose.orientation.x = -geoQuat.y; odomAftMapped.pose.pose.orientation.y = -geoQuat.z; odomAftMapped.pose.pose.orientation.z = geoQuat.x; odomAftMapped.pose.pose.orientation.w = geoQuat.w; odomAftMapped.pose.pose.position.x = transformAftMapped[3]; odomAftMapped.pose.pose.position.y = transformAftMapped[4]; odomAftMapped.pose.pose.position.z = transformAftMapped[5];

_cloudKeyPoses3D->points[i].x = isamCurrentEstimate.at(i).translation().y(); cloudKeyPoses3D->points[i].y = isamCurrentEstimate.at(i).translation().z(); cloudKeyPoses3D->points[i].z = isamCurrentEstimate.at(i).translation().x();

            cloudKeyPoses6D->points[i].x = cloudKeyPoses3D->points[i].x;
            cloudKeyPoses6D->points[i].y = cloudKeyPoses3D->points[i].y;
            cloudKeyPoses6D->points[i].z = cloudKeyPoses3D->points[i].z;
            cloudKeyPoses6D->points[i].roll  = isamCurrentEstimate.at<Pose3>(i).rotation().pitch();
            cloudKeyPoses6D->points[i].pitch = isamCurrentEstimate.at<Pose3>(i).rotation().yaw();
            cloudKeyPoses6D->points[i].yaw   = isamCurrentEstimate.at<Pose3>(i).rotation().roll();_

void adjustOutlierCloud(){ PointType point; int cloudSize = outlierCloud->points.size(); for (int i = 0; i < cloudSize; ++i) { point.x = outlierCloud->points[i].y; point.y = outlierCloud->points[i].z; point.z = outlierCloud->points[i].x; point.intensity = outlierCloud->points[i].intensity; outlierCloud->points[i] = point; } }

Please some smart guy help me, thanks very much!

YangSiri commented 4 years ago

@TixiaoShan Brother?

TixiaoShan commented 4 years ago

Hi @YangSiri ,

Please refer to https://github.com/laboshinl/loam_velodyne/blob/0030b6a6b579fe2169ec36ffa939c7dd92f4275c/src/scanRegistration.cpp#L221 for the conversion. I followed their changes.

YangSiri commented 4 years ago

Yes, @TixiaoShan Thanks. I just want to know why they change the order of 'xyz'. Better calculation? Or more convient? And no offense, there is little notes for the codes... Looking forward to your explaination~

andre-nguyen commented 4 years ago

The original LOAM code has a lot of mysterious parts and you should probably not read it too much unless you want your eyes to bleed. The coordinate switching here probably has to do with projecting the lidar points in the camera frame. I believe that historically the "open source" LOAM was published as Ji Zhang was preparing V-LOAM.

YangSiri commented 4 years ago

Yes, @andre-nguyen ,i guess you're right. There is '/camera' in the codes. Do you know where does the function void transformAssociateToMap() come from? I mean the formula and theory stuff.

andre-nguyen commented 4 years ago

I mean the formula and theory stuff.

To the best of my knowledge, it solely exists within Ji Zhang's head and internally at Kaarta. Personally, reading it makes me think it was code-generated through matlab because no human could possibly write and understand such a horrible function... I think.

YangSiri commented 4 years ago

well, fair enough, thanks all of you.

tejalbarnwal commented 2 years ago

@andre-nguyen I apologize for asking such a silly query but is it like base_link is where the code assumes the lidar's frame and the camera can be treated as just another sensor attached to base_link if I wish to perform only Lidar Slam? While laser_odom represents the odometry of the lidar with respect to the camera_init frame? What does the camera_init frame signify? Also, how is the transform between the camera_init frame and the camera frame calculated?

daohu527 commented 1 year ago

I'm going to optimize it, but at the moment why the coordinate system of lidar and imu is not explained clearly : )