0
$\begingroup$

Rosanswers logo

Hi All,

I am very new into understanding a lot of concepts in ROS, so far I have successfully ran autonomy_create software package and used a simple keyboard_node to drive my create2 robot.

So far this is what I have done. My linear velocity is 0.2 to drive create2 forward in typical square tile carpeted floor. When I subscribe to topic \odom, the initial value is as follows:

 pose: 
x: 0.000963
y: 0
z: 0
orientation:
x: 0
y: 0
z: 0
w: 1

I moved 1m forward and see if I can get 1meter value in my odom pose

 pose: 
x: 1.27661
y: -0.074605
z: 0
orientation:
x: 0
y: 0
z: -0.070646
w: 0.997501

I moved 1m forward again

    pose:  
x: 2.192413 
y: -0.298672 
z: 0
    orientation: 
x: 0 
y: 0 
z: -0.138908 
w: 0.990305

Based on simple calculation, 19cm is around 10% difference in 2m expected and even y position have some change in value.Currently, I got to know that odometry from wheel encoders alone is erroneous in nature that is why more complex processing is needed (EKF etc.,) now, I would like to know if this 10% error in odometry of autonomy_create that is acceptable to be as input in other package like robot_localization, AMCL etc?

I hope I could learn from you guys. Thanks in advance!


Originally posted by fj138696 on ROS Answers with karma: 30 on 2017-06-05

Post score: 0


Original comments

Comment by Humpelstilzchen on 2017-06-06:
Changes in y are usually because of changes in heading angle. What I do not understand is how you compared the odometry value to the real position of the robot.

Comment by fj138696 on 2017-06-06:
I am trying to drive the robot in straight line marked by a tape on the floor. I aligned the bottom of the CLEAN button in the middle on the marked tape (which is only based on my visual estimation). Any suggestion to measure the change in x and y of the robot manually? thanks!

Comment by Humpelstilzchen on 2017-06-07:
Thats fine I guess. I glue plastic tape measures on the floor.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

My thoughts on this:

  1. If you have a good map and not-so-challenging environment, I think it is ok if your odometry is not so good, because you can always tune AMCL to perform localization intensively.
  2. If you have a good laser, you can consider using laser odometry to replace wheel odom completely. Hector SLAM (http://wiki.ros.org/hector_slam) and Laser Scan Matcher (http://wiki.ros.org/laser_scan_matcher) could be some good options.
  3. I personally think a good odometry should have error not more than 5%, most of the time should be less than 2%. A good option is to perform sensor fusion between your wheel odom and other sensor (gyro, IMU, laser odom...) using UKF or EKF which is part of robot_localization package itself.

Originally posted by DavidN with karma: 544 on 2017-06-05

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Humpelstilzchen on 2017-06-06:
Or he could try to calibrate the odometry first e.g. with umbmark

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.