Something about function getNextPose() in odom

[piluohong]

hello,good lifes for yours!

this->T = this->T_corr * this->T_prior

why matrix T_corr need mutiply current T prior? T_corr is the relative transformation to submap, T_corr is not current global pose?

[kennyjchen]

Hi @piluohong -- everything is performed in the global frame.

[juliangaal]

the scan is transformed into the global frame with this snippet, correct?

this->T_prior = this->T;
pcl::transformPointCloud (*deskewed_scan_, *deskewed_scan_, this->T_prior * this->extrinsics.baselink2lidar_T);

If that's the case, why is the line @piluohong posted necessary? Thanks

[piluohong]

@juliangaal T as the next matching's prior, may be the reason of the continous pose estimation.

[juliangaal]

If I understand correctly:

First, the point cloud is transformed into the global frame:

this->T_prior = this->T;
pcl::transformPointCloud (*deskewed_scan_, *deskewed_scan_, this->T_prior * this->extrinsics.baselink2lidar_T);

Then, after scan matching is performed, the local change of Scan -> Submap registration (T_corr) has to be applied in the global frame (the snippet you, @piluohong, posted)

this->T = this->T_corr * this->T_prior

This is then applied to this->lidarPose in propagateGICP() to add the keyframe in the right position in the map.

Is my understanding correct @kennyjchen ?

[whw-create]

Hi, i am curious that why do you need one more imu_it++; in the line 1047 of odom.cc. i think imu_it must be the first one IMU on the left of start_time.