Odometry value suddenly becomes large.

[akibako115]

ISSUE TEMPLATE ver. 0.4.0

1. Which TurtleBot3 platform do you use?

   • Burger
   • Waffle
   • 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
   • ROS 2 Foxy Fitzroy
   • etc (Please specify your ROS Version here)

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

   • Intel Joule 570x
   • 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)
   • 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)
   • 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.

   • Run
     turtlebot3_bringup robot.launch.py
     turtlebot3_navigation2 navigation2.launch.py
     and move the robot.

8. Copy and Paste the error messages on terminal.

   • No error messages.

9. Please describe the issue in detail.

   • When I run turtlebot3_bringup and turtlebot3_navigation2, the robot works fine at first. However, after about 10 seconds of movement, the odometry value suddenly increases.The odometry value immediately returns to normal, but navigation2 is still affected and cannot estimate the self-position correctly.

[akibako115]

I was able to solve the error of the large initial value of odometry when starting turtlebot3_bringup by referring to the comments in the following link: #880 issuecomment-1166455498　.However, even if I set the initial value of odometry to 0, I still get errors like this one and cannot try self-position estimation or navigation using navigation2.

[kgallowa]

Looks like this is similar to issues described in #821 and #880 and others like that, all apparently stemming from the issue described in #901. Hoping we can get a fix for this soon!

[foxydevelby]

Looks like this is similar to issues described in #821 and #880 and others like that, all apparently stemming from the issue described in #901. Hoping we can get a fix for this soon!

Hi @kgallowa any idea of when will the fix be available? or any workaround you can recommend? highly appreciated. thanks a lot!

[kgallowa]

Hi @foxydevelby , unfortunately I don't know of any fix yet. Thanks for posting, because I want to keep attention on this issue. As far as a workaround, here's what I've done so far.:

1. Followed the suggestion here SLAM generates multiple maps. #899 (comment) to revert the opencr firmware to version 0.0.3. That seemed to stop the problem where odometry would occasionally jump in the midst of operation.
2. With regards to odometry having really large values at startup, I found that if I just kept running the turtlebot bringup command (i.e. ctrl-C to bring it down and then ros2 launch turtlebot3_bringup robot.launch.py) eventually I'd get a launch with reasonable odometry values. Since this is really annoying to check odometry each time, I wrote some basic code that would monitor odometry at startup for large values and then continue to monitor for any jumps. I can clean up and post that code on Github if it would be helpfull.

[ROBOTIS-Will]

This issue looks like the OpenCR doesn't correctly handle the exceptional position reading from the DYNAMIXEL.
Please allow me a couple weeks for the release of the OpenCR firmware.
The hotfix firmware will be released no later than Jan 19th.
Thanks!

[akibako115]

Thank you for the reply @ROBOTIS-Will . Looking forward to the release!

[kgallowa]

Thanks so much, @ROBOTIS-Will! I appreciate your work on this and look forward to the release!

[ROBOTIS-Will]

I confirmed that the present position data read from the OpenCR and saved in the Memory struct somehow saved as values that doesn't make sense.
I made a filter to filter out the case when the wrong position data is used in joint state calculation which was pretty successful, but still working on the odom calculation as they seem referring different data so I'm thinking that the filter is only a temporary measurement.
I'm sorry but please allow me a few more days so that I can identify the root of the problem and provide the reasonable solution.
Thank you for your patience!

[kgallowa]

Thanks @ROBOTIS-Will! Your work on that is much appreciated, and I'm glad to wait for a fix that gets to the root cause. I'm hoping it will fix both issues, i.e. 1) oddly large odom values at startup, and 2) odometry jumping in the middle of operation.

[shubhamnagla]

@ROBOTIS-Will , Any update on the fix and release ?

[ROBOTIS-Will]

Hi,
I found the cause of the problem.
The byte stuffing of the DYNAMIXEL2Arduino library reproduces the 0xFD infinitely when a hex value ending with 0xFD is followed by any negative value that is represented with a hex value starting with 0xFFFF.

DYNAMIXEL saves data with little endian which causes FF FF FD sequence which happens to be identical to the packet header of DYNAMIXEL 2.0 protocol.
When Raspberry Pi requests the entire control table data to the OpenCR, this unusual sequence gets stuck in the byte stuffing and keep appending FD as below

We finally found the root of the problem, so this will very soon be fixed.

FYI, the reason only ROS2 have this issue is because ROS firmwares don't request the entire control table to the OpenCR.

I'll keep updated with the progress.
Sorry about the delay and thank you very much for your patience!

[kgallowa]

Thanks for the update @ROBOTIS-Will. Nice to find the root cause. Sounds related to what @jobst-n found in #901 (comment). Looking forward to the fix. Thanks for your work on this!

[ROBOTIS-Will]

I'm reviewing the below hotfix.
Once it is confirmed, I'll release the TB3 ROS2 OpenCR firmware today.
Thank you!
ROBOTIS-GIT/Dynamixel2Arduino#118

[ROBOTIS-Will]

The hotfix looks good to me.
I'll proceed with the DYNAMIXEL2Arduino library update and OpenCR firmware release!

[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!

[kgallowa]

Thanks, @ROBOTIS-Will! Sorry for the slow response; I've been out of the office the last few days but will be back in tomorrow and plan to download and test out the new firmware then.

[kgallowa]

Thanks for your work on this @ROBOTIS-Will! I had a chance to download and test the new firmware today. It does look like it has fixed the odometry jumps, which is great. I drove around for a while and didn't have any jumping. However, as mentioned in #880 (comment), I am still occasionally getting the extreme large odometry values at startup, i.e. the issue raised in #880. The problem here is that slam-toolbox crashes if I try to run it with these large odometry values ("terminate called after throwing an instance of 'karto:Exception'"). Is it possible to get a fix for this issue as well? Thanks!

[akibako115]

Thanks, @ROBOTIS-Will! Sorry for the late reply. Same as @kgallowa, I sometimes get errors with very large odometry values on startup and still setting odometry values by referring to #880 issuecomment-1166455498.

[ROBOTIS-Will]

Hi all,
Thanks for the feedback :)
I'll review this and modify the bringup code to reset the odom to zero at startup.

[matheuslara]

Hello @ROBOTIS-Will, I appreciate your help with these matters.

"I sometimes get errors with very large odometry values on startup and still setting odometry values by referring to #880 issuecomment-1166455498."

Please let us know when you have a solution.

I'm using Turtlebot Burger, ROS 2 Foxy Fitzroy, Raspberry Pi 3B+

[kgallowa]

Hi @ROBOTIS-Will, just checking if there was any progress towards a fix for the large odometry data at initialization. Thanks!

[kgallowa]

Hi @ROBOTIS-Will, just checking in again to see if there was progress on the firmware fix to initiatilze odometry at 0 instead of having the random large number described in the comments here. Thanks!

[spolstra]

Hi,

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

[sunghowoo]

This issue will be closed due to prolonged inactivity. Please try again with the Humble or Noetic versions, and if the issue persists, feel free to reopen it.