Faulty Odometry - pose value published at startup is very large and makes no sense

[sudar1220]

ISSUE TEMPLATE ver. 0.4.0

1. Which TurtleBot3 platform do you use?

   • Burger
   • Waffle
   • [x ] Waffle Pi

2. Which ROS is working with TurtleBot3?

   • ROS 1 Kinetic Kame
   • ROS 1 Melodic Morenia
   • ROS 1 Noetic Ninjemys
   • ROS 2 Dashing Diademata
   • ROS 2 Eloquent Elusor
   • [x ] ROS 2 Foxy Fitzroy
   • etc (Please specify your ROS Version here)

3. Which SBC(Single Board Computer) is working on TurtleBot3?

   • Intel Joule 570x
   • [x ] Raspberry Pi 3B+
   • Raspberry Pi 4
   • etc (Please specify your SBC here)

4. Which OS you installed on SBC?

   • Raspbian distributed by ROBOTIS
   • Ubuntu MATE (16.04/18.04/20.04)
   • [x ] Ubuntu preinstalled server (18.04/20.04)
   • etc (Please specify your OS here)

5. Which OS you installed on Remote PC?

   • Ubuntu 16.04 LTS (Xenial Xerus)
   • Ubuntu 18.04 LTS (Bionic Beaver)
   • [x ] Ubuntu 20.04 LTS (Focal Fossa)
   • Windows 10
   • MAC OS X (Specify version)
   • etc (Please specify your OS here)

6. Specify the software and firmware version(Can be found from Bringup messages)

   • Software version: [x.x.x]
   • Firmware version: [x.x.x]

7. Specify the commands or instructions to reproduce the issue.

   ros2 launch turtlebot3_bringup robot.launch.py

8. Copy and Paste the error messages on terminal.

9. Please describe the issue in detail.

   Odom x value is a very high value (10^204) at startup(check the above image). Unable to use odometry due to this.
   Power cycling , pulling any changes from the git repo and also reflashing the OpenCR board doesn't make any difference.
   Unsure why this issue is being caused

[ROBOTIS-Will]

Hi @sudar1220

Thanks for reporting the issue.
Not sure if it is related to this, but my team also found that the odom jumps around during simulation SLAM which causes failure in mapping.
I'll look into the OpenCR firmware and see if I can find more related information regarding this.
Thanks.

[sudar1220]

Hi @ROBOTIS-Will

Thanks for your reply,
I have discovered one thing, in the /home/ubuntu/turtlebot3_ws/src/turtlebot3/turtlebot3_bringup/param/waffle_pi.yaml params file when I set the use_imu setting under odometery to false and run colcon build, sometimes the huge x value goes down to like 0.1.

But is there a way to reset the odom value at startup to zero? Maybe that can help me work around this issue for now until a fix is issued.
I would greatly appreciate some help in this regard as my project is blocked by this issue.

Thanks in advance

[sudar1220]

Hi @ROBOTIS-Will,

Possible cause for the odometry issue

• I made some tests today and discovered that i get these huge values on either the X or Y odometry pose at startup, if the wheels haven't moved between restarts .

• I started the robot and ran the bringup robot.launch file with the wheels not rotated and rotated, in this case the issue doesn't occur when the wheels have been moved.

I took a peek at the odometry code and think that the issue may be related to calculation of diff_joint_positions_[] and the data that is coming from the openCR board.

turtlebot3/turtlebot3_node/src/odometry.cpp

Line 203 in 8237b79

diff_joint_positions_[0] = joint_state->position[0] - last_joint_positions[0];

This is just my guess, as I am not sure since I am unaware of how the openCR board's firmware is written.
But I was able to reproduce the error when the wheels haven't moved. Maybe this is something you can also test.

A temporary fix that I thought of was to set the robot poses to zero, the first time the script starts. Could this work? I am unable to make this change and test this because my RPi is woefully under-powered to build any code on it.

Can you please let me know how this could be fixed?

Thanks in advance

[sudar1220]

I also found another issue with people stating similar issues to mine: #821 .Tagging it here so that it is easy for reference.

I ended up using the solution from this github issue #750 (see the last comments). What it does it to reset the odom values to whatever pose you want. But I instead use it to set the odom values to zero at the start. I also set the use_imu setting to false in the params file to use only the wheel encoders for odometry.

You can just use ros2 topic pub -1 /pose_relocalization geometry_msgs/Point this command to set everything to zero.
Thanks to the author of #750

[huybeme]

Hello @sudar1220 , I have opened up a ticket on this issue via ticket #847 . I will be trying out your suggestion and suggestion from ticket #750 but am curious what your results were. Does the odometry frame move along with the base_footprint frame and all its children or is it just staying at the 0 position (or position where its reset to). Is this just a band aid to stop the cartographer package from crashing? I just want to make sure mine is behaving similar to what yours is to ensure what I am doing is consistent. Thanks in advance.

[EndlessLoops]

I had the same problem with the noetic version of TB3.Any update about this problem ？ @ROBOTIS-Will

[sudar1220]

Hello @sudar1220 , I have opened up a ticket on this issue via ticket #847 . I will be trying out your suggestion and suggestion from ticket #750 but am curious what your results were. Does the odometry frame move along with the base_footprint frame and all its children or is it just staying at the 0 position (or position where its reset to). Is this just a band aid to stop the cartographer package from crashing? I just want to make sure mine is behaving similar to what yours is to ensure what I am doing is consistent. Thanks in advance.

Its been a while since I posted this issue. From my understanding, what I did is just a band aid solution to stop SLAMTOOLBOX from crashing. I didn't use Cartographer. So the odom frame is reset to (0,0) using the idea from #750. Whenever I started the TB3, I had huge values either in the X or Y co-ordinate of the odom frame. Therefore, when i started the TB3, I ran the command
ros2 topic pub -1 /pose_relocalization geometry_msgs/Point

In order to run this command, a small change in the odometry.cpp file of the Turtlebot is required, this can be seen in the issue #750. This publishes 0, 0 to the X and Y co-ordinates of the odom frame. Once the odom frame is set to this (0,0) value it does not move with base_footprint and I no longer had any issues with SLAMTOOLBOX. Also to note, this odometry issue caused other problems for me as well, with RVIZ crashing etc. This all went away when I did the above solution.

In my attempts to debug and properly fix this issue, I also tried looking at the odometry.cpp script to see if there was any bugs in the initialization or calculation of the X, Y values, as huge values could sometimes be caused by overflows or garbage values. However, I was unable to figure out if there was an issue with the odometry.cpp script. I am not an expert on these things, rather was trying to learn and use this platform for my project.

But I hope that one of you guys fix can this, seeing that multiple people seem to have this issue.
Wishing you success!

[ROBOTIS-Will]

An updated OpenCR ROS2 firmware V220127R1 (0.2.1) is released.
Please download and upload the new firmware and let me know if this doesn't fix the problem.
Thank you very much for your patience!

[sudar1220]

Hi Will, Thank you for the update. Unfortunately my project has ended, therefore I don't have the tuetlebpt with me. I hope that the others who had this problem find use with this solution. Thanks

…

On Fri, Jan 27, 2023, 9:46 AM Will Son ***@***.***> wrote: An updated OpenCR ROS2 firmware V220127R1 (0.2.1) is released. Please download and upload the new firmware <https://emanual.robotis.com/docs/en/platform/turtlebot3/opencr_setup/#opencr-setup> and let me know if this doesn't fix the problem. Thank you very much for your patience! — Reply to this email directly, view it on GitHub <#880 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJYFM2JI5FO3D625TZXPYRDWUODN5ANCNFSM5ZRHNR6Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[EndlessLoops]

Hi Will,

I have tested with the new ROS2 firmware V220127R1 (0.2.1) . Now odom data does not suddenly get larger when the robot moves.
But it also have a problem that the odom initial position data is not 0. The following data is my robot‘s odom initial position data after power failure reboot.

First test:

$ ros2 topic echo /odom
header:
  stamp:
    sec: 1675220230
    nanosec: 45116417
  frame_id: odom
child_frame_id: base_footprint
pose:
  pose:
    position:
      x: -1.9033964117091945e+269
      y: 0.019489470600044953
      z: 0.0
    orientation:
      x: 0.0
      y: 0.0
      z: 0.06443127530679697
      w: 0.9979221466438851

Second test :

$ ros2 topic echo /odom | grep -A 3 'position'
    position:
      x: 0.05602774804476126
      y: 0.008842592351953098
      z: 0.0
--
    position:
      x: 0.05602774804476126
      y: 0.008842592351953098
      z: 0.0
--
    position:
      x: 0.056052749775743295
      y: 0.008846534976974617
      z: 0.0
--

An updated OpenCR ROS2 firmware V220127R1 (0.2.1) is released. Please download and upload the new firmware and let me know if this doesn't fix the problem. Thank you very much for your patience!

[EndlessLoops]

Hi @ROBOTIS-Will ,

The noetic v1.2.6 fireware also has the the same probrem that odom data does not suddenly get larger when the robot moves.Did you encounter the same problem when testing? The following data is my robot‘s odom position‘s data after the robot moved for a while in the small room.

test data:

$ rostopic echo /odom | grep -A 3 'position'
    position: 
      x: 11.94414234161377
      y: 36.8416748046875
      z: 0.0
--
    position: 
      x: 11.944507598876953
      y: 36.84312438964844
      z: 0.0
--

When I reran the turtlebot3_robot.launch, the odom data was confusing.

$ rostopic echo /odom | grep -A 3 'position'
    position: 
      x: -5.1089625585643006e-11
      y: 3.8035792293555915e-09
      z: 0.0
--
    position: 
      x: -5.1089625585643006e-11
      y: 3.8035792293555915e-09
      z: 0.0
--
    position: 
      x: -5.1089625585643006e-11
      y: 3.8035792293555915e-09
      z: 0.0

Is the problem of noetic v1.2.6 firmware the same as the ROS2 firmware？

[spolstra]

Hi,

I ran into the same issue where the turtlebot would have very large x and/or y positions. I fixed this by initializing the pose member in the Odometry class. See #750 for my solution.

[dlwlrma1516]

Hi @ROBOTIS-Will ,

In ROS 1 Melodic Morenia, I've encountered an issue where the X, Y values in the /odom position and the Z value in orientation are significantly large and unstable, fluctuating around -5 to 5. This issue emerges after launching with roslaunch turtlebot3_bringup turtlebot3_robot.launch. Despite attempting restarts and resets, the problem persists. However, when I control the TurtleBot3 to move a short distance using roslaunch turtlebot3_teleop turtlebot3_teleop_key.launch, the values in /odom return to normal. Yet, this initial instability leads to failures in establishing SLAM positioning.

I installed OpenCR following the instructions provided at https://emanual.robotis.com/docs/en/platform/turtlebot3/opencr_setup/#opencr-setup. I found many solutions related to ROS2, but none for ROS1. I am unsure where the problem lies, and this issue has been troubling me for a while. I would greatly appreciate your assistance.