search

ROBOTIS-GIT / turtlebot3

ROS packages for Turtlebot3
http://turtlebot3.robotis.com
Apache License 2.0
1.46k stars 1.01k forks source link

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

Open sudar1220 opened 2 years ago

sudar1220 commented 2 years ago

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.

image

  1. 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 commented 2 years ago

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 commented 2 years ago

Hi @ROBOTIS-Will

Thanks for your reply, I have discovered one thing, in the _/home/ubuntu/turtlebot3_ws/src/turtlebot3/turtlebot3_bringup/param/wafflepi.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 commented 2 years ago

Hi @ROBOTIS-Will,

Possible cause for the odometry issue

I took a peek at the odometry code and think that the issue may be related to calculation of diff_jointpositions[] and the data that is coming from the openCR board. https://github.com/ROBOTIS-GIT/turtlebot3/blob/8237b796ea1571033bf3230fbc78d1143968ddd1/turtlebot3_node/src/odometry.cpp#L203 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 commented 2 years ago

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 https://github.com/ROBOTIS-GIT/turtlebot3/issues/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 commented 1 year ago

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 commented 1 year ago

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

sudar1220 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/ROBOTIS-GIT/turtlebot3/issues/880#issuecomment-1406188381, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJYFM2JI5FO3D625TZXPYRDWUODN5ANCNFSM5ZRHNR6Q . You are receiving this because you were mentioned.Message ID: @.***>

EndlessLoops commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

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 commented 5 months ago

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.

odom1 odom2