search

MAPIRlab / rf2o_laser_odometry

Estimation of 2D odometry based on planar laser scans. Useful for mobile robots with innacurate base odometry. For full description of the algorithm, please refer to: Planar Odometry from a Radial Laser Scanner. A Range Flow-based Approach. ICRA 2016 Available at: http://mapir.isa.uma.es/mapirwebsite/index.php/mapir-downloads/papers/217
GNU General Public License v3.0
379 stars 219 forks source link

Pose with wrong direction #20

Open ivywongkk opened 5 years ago

ivywongkk commented 5 years ago

Hi there I'm using rf2o for the navigation stack. I rotated my lidar 90 degrees around z direction, and flipped upside down, and it scans only half range, from -180 to 0 degree. There I got a problem: tf goes to mirrored direction( x axis)...i.e. when I move robot to right, the tf goes to left.. The tf setup seems to be correct because I run the same tf for hector slam to create a map, and no problem with the pose direction. I'm new in ROS, could anyone advise how to solve it?

CodesHub commented 5 years ago

I am having the same issue. I simply added the negative sign in LaserOdometry2D::PoseUpdate(). in file CLaserOdometry2D.cpp Line 923: pose_aux_2D.translation()(0) = -acu_trans(0,2); pose_aux_2D.translation()(1) = -acu_trans(1,2); Line 956: lin_speed = -acu_trans(0,2) / time_inc_sec; Then I get the right direction.

ewerlopes commented 5 years ago

Really helpful, thanks!

amgaber95 commented 3 years ago

Hi, I have the same problem, but when tried to make this solution, the problem got worse, now the odom is calculated in the reverse direction

Can you please help me with this one.

jacob-02 commented 4 months ago

The above solution works but could the repository developers let us know if this a proper solution or is there something we should know about the way the algorithm expects the scan data to solve this problem. @JGMonroy @jgoppert @famoreno @mertsaadet

nourani commented 3 months ago

I have a similar problem, but might be different. During initialization the setLaserPoseFromTf() function is called and if everything is published properly with TF it should work. However, I noticed that occasionally it doesn't read the TF correctly, or if the node comes up before the TF publisher then this doesn't work. On line 101 (https://github.com/MAPIRlab/rf2o_laser_odometry/blob/b38c68e46387b98845ecbfeb6660292f967a00d3/src/CLaserOdometry2DNode.cpp#L101), the return argument is not checked and call it initialized (even though a retrieved = false; is returned.

Maybe for some, ensuring we keep trying to get the TF, would solve the problem!?