odom frame not consistent at startup

[huybeme]

ISSUE TEMPLATE ver. 0.4.0

1. Which TurtleBot3 platform do you use?

   • [ ] Burger

2. Which ROS is working with TurtleBot3?

   • [ ] ROS 2 Foxy Fitzroy

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

   • [ ] Raspberry Pi 4

4. Which OS you installed on SBC?

   • [ ] Ubuntu preinstalled server (20.04)

5. Which OS you installed on Remote PC?

   • [ ] Ubuntu 20.04 LTS (Focal Fossa)

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.

   on tb3_SBC: ros2 launch turtlebot3_bringup robot.launch.py on remote computer: rqt

8. Copy and Paste the error messages on terminal.

   rviz2: /tmp/binarydeb/ros-foxy-rviz-ogre-vendor-8.2.6/obj-x86_64-linux-gnu/ogre-v1.12.1-prefix/src/ogre-v1.12.1/OgreMain/include/OgreAxisAlignedBox.h:225: void Ogre::AxisAlignedBox::setExtents(const Vector3&, const Vector3&): Assertion `(min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed. Aborted (core dumped)

9. Please describe the issue in detail.

   When I launch robot.launch.py, everything launches fine with no error messages, sometimes. I am trying to understand why the odom frame starts at seemingly random positions at launch. Ideally, I want to start the odom frame to start at 0,0 or where the base_footprint starts for localization.

Sometimes one of the positions is so large I get the error message stated above and crashes the rviz2 gui.

please refer to the attached image and please let me know if I need to include more details or information.

[ROBOTIS-Ashe]

Hi @huybeme. Thank you for your questions. I'm not sure what's wrong with your configuration, but I'm attaching an issue with a case similar to yours. #594

Thank you.

[huybeme]

Thank you for your response @ashekim, I looked over that ticket and am not sure that our issues are the same.

I also want to clarify that I am using an actual turtlebot3 burger and am not running simulation. Also both my computer and pi only have ROS foxy distribution installed.

Currently, I am only running rviz2 and repository: https://github.com/ROBOTIS-GIT/turtlebot3/tree/foxy-devel

[ROBOTIS-Ashe]

Hi @huybeme . I'm sorry for the misunderstanding that the environment consists of Gazebo.

It appears that RVIZ crashes and throws an error if the robot position is outside of the grid. In rviz2, Fixed Frame should be odom. And odom should be at the top of the TF Tree.

Could you please run the the command attached below on RemotePC?? $ ros2 launch turtlebot3_bringup rviz2.launch.py I'd appreciate it if you let me know the results after you try.

Thank you

[huybeme]

@ashekim,

please no need to be sorry. I appreciate your helping of my issues.

I have launched your statement as requested but still have the same issues. When robot.launch.py is launched, I sometimes get an spawn way off map and get the same error code as originally stated. Whenever I keep re-launching the robot until I get within the grid, I am able to run that command successfully.

I just want to clarify my end goal of my project is to write my own SLAM code. I am building a map to be the parent of odom, so odom will not end up on top. This should be okay, since I seen a few other people do this as well but if I am wrong please let me know.

I also noticed that when my battery gives me the initial low battery indication, my positions actually resets to near 0,0. Not sure if this is related but thought I would bring it up in case it is.

[ROBOTIS-Ashe]

Hello @huybeme.

I want to know if you are using the slam package you developed instead of the slam package we provide. Sorry for the trouble, but can you explain your running process?

Thank you.

[huybeme]

@ashekim,

I am only launching robot bring up on my tb3. Prior to launching any other slam packages such as turtlebot3 cartographer, I have to check my position of my odom->base_footprint frame. Please refer to the photo containing translation of the frames below. The translation.y is very large and is what prevents rviz2 from opening and likely the cartographer as well.

In order to get rviz2 or cartographer to run/launch successfully, I must end the robot_bringup and re-launch until I get translation values that is within the grid.

Here is my rviz2 window with a robot bringup where translation is near 0.

Is this normal? Using teleoperation, I am able to move the robot around in rviz2 (and live) starting from that point. Also, I have tried to transform odom>base_footprint frame to set it to 0,0 without success. It seems like its original points takes precedent.

Let me know if there are any additional details that I can lay out.

[xinxing-max]

@huybeme Hi, I have same problem using TB3 Burger and rviz2. The translation.y is often out of the grid. Sometimes, it will be small, like 2 or 10, but not 0. Did you solve this problem?

[huybeme]

@xinxing-max Hello! I have not solved this issue definitively but as a bypass to getting things going, I sort of just keep re-launching the robot bringup through ROS until the random coordinates doesn't crash rviz. Please do keep me posted if you catch onto something that is causing this issue.

[JLBicho]

Hi,

I'm having the same problem. My tf between odom and base_footprint is:

transforms:
- header:
    stamp:
      sec: 1668100040
      nanosec: 707374661
    frame_id: odom
  child_frame_id: base_footprint
  transform:
    translation:
      x: 0.2770956275728272
      y: 8.311419928698475e+19
      z: 0.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.003235359852538116
      w: 0.999994766209616

As @xinxing-max said, the value of translation.y is huge! @ROBOTIS-Ashe , is there a way to "reset" or "recalibrate" the odometry, so it starts again at 0?

Thanks!

Edit: I've found this issue which is similar: https://github.com/ROBOTIS-GIT/turtlebot3/issues/880

Edit2: Based on the comment https://github.com/ROBOTIS-GIT/turtlebot3/issues/880#issuecomment-1166304271, I've followed these steps to "calibrate" odom:

1. ros2 launch turtlebot3_bringup robot.rviz on the turtlebot3
2. rqt_robot_steering or any similar way to publish a /cmd_vel. Move the robot a little
3. Stop the turtlebot3 launch and relaunch again.
4. Now the odom tf should be correct.

[huybeme]

hello @JLBicho , thanks for referencing this issue to #880. Were you successful in those steps? I won't have a chance to try it out for a few days but definitely will.

[JLBicho]

Hi @huybeme, Yes, I was able to make it work correctly following those steps. It can happen more than once after each launch command.

If this doesn't work for your, please let us know.

[xinxing-max]

Hi @JLBicho ,

Thanks for your suggestions. Your Edit2 did not always work for me. I could only restart turtlebot or relaunch bringup files to reset odom. Did those steps always work for you?

After burning the ros2 foxy into the turtlebot, it has been working very well. I am using two turtlebots at the same time. So I added then the tf prefix in the robot's urdf file and also added namespaces to the published topics. I don't know if this will affect the initialization of the odom.

[JLBicho]

Hi @xinxing-max , For me it always works after stopping the bringup and launching again.

I'll try to burn again the foxy image to see if the problem disappears.

Thanks