Odometry of robots X1 vs. X2

Issue #243 new
Martin Dlouhy created an issue

Is it expected that odometry for robot X2 is double when compared to X1? “Just for fun” we tried to run navigation code for X1 instead of X2 robot and it turned always half of desired angle … so X2 turned 90 degrees and X1 only 45, but the angles from odometry were the same. If there is a bug, please do not fix it now! 😉

Is there any other team using X1 and X2?

Comments (9)

  1. Arthur Schang

    No, this is not expected. I just tried to reproduce this locally with the most updated version of osrf/subt-virtual-testbed and I was unable to reproduce. Both X1 and X2 odometry registered the appropriate yaw when commanding 0.3 rad/s yaw and I verified by checking the visual feedback on the GUI on a continuous rotation and then stopping every 45 degrees.

    I do want to note that if you send very high commands for yaw you may end up with some funky behavior. When I did a quick test by converting the quaternions on /<ns>/odom to Euler angles by hand and commanding 1.0 rad/s yaw I was getting results that were not what I expected. However, whenever I wrote up a nav_msgs::Odometry to tf converter node and monitoring the published transform’s yaw directly at lower rates (i.e. 0.3 rad/s yaw) I saw the results I was expecting.

  2. Steven Gray

    I’m using the latest osrf/subt-virtual-testbed and noticed this with controller teleop, but it does command about 0.8 rad/s yaw. I spawned an X1 and X2 in the starting area, rotated both by about 90 degrees using controller teleop. Apparently X2 odom is just able to handle 0.8 rad/s , while X1 odom is not. I then tried it again with about 0.3 rad/s for both and both odometries were accurate.

    I’m wondering why X1 is more sensitive to yaw rate than X2?

    Additionally, maybe it’d be good to reduce the controller teleop (just roslaunch subt_example teleop.launch) to 0.4 rad/s

  3. Arthur Schang

    Cutting the controller teleop velocities is a good first step but it seems that the underlying controller is not filtering input velocities appropriately which is a bigger problem.

  4. Arthur Schang

    If the controller is being bypassed and the vehicle is being manipulated in simulation to do exactly what it receives on the cmd_vel topic, yes.

  5. Martin Dlouhy reporter

    @Arthur Schang is there plan for revision/bugfix of the controller for Urban Circuit final release? (in two weeks)

  6. Arthur Schang

    I am not aware of a fix for this issue being implemented. I recommend controlling the X1 at lower speeds to achieve more accurate wheel odometry estimates (I’ve been able to do this in testing). We are cautious to make changes that could having significant effects on the competition close to the code freeze date.

  7. Log in to comment