turtlebot3_gazebo: no "odom" frame #219
Comments
|
It looks like a problem between turtlebot and gazebo. Perhaps you can check if ros-noetic-turtlebot3-gazebo is installed. If not, the model in gazebo may wrong. |
|
Hi @ZhoZhicheng, thank you for your idea. I listed my ROS-related |
|
Hello @doctorcolossus did you end up resolving this issue? I am facing the same problem with a pioneer3at model |
|
Hey @margaridaaranha7, yes, I think that I eventually resolved the problem by installing apt package |
|
Hello again, @doctorcolossus :) Thank you so much for your quick and detailed response! I really appreciate it. Unfortunately, I already had the My issue was that the However, when I ran rostopic echo /odom, the messages included:
So, after some investigation, I realized the problem was with my It was using this Gazebo plugin (from the last part of the pioneer3at_body.xacro file), which didn’t maintain an odom frame. I believe another tool might be needed to handle this.Since p2os also provides the pioneer3dx model, I gave that a try, and it worked perfectly! I ended up using the pioneer3dx Gazebo plugin for the pioneer3at model (actually two plugins), and that solved the issue.I’m still fairly new to ROS and Gazebo, so I hope this explanation makes sense. I just wanted to share what I learned, and I hope it can help someone else facing a similar issue! |
|
@doctorcolossus, thanks a lot, your solution worked for me. |
|
Apologies for the delayed response. We have assembled a TF team to address TurtleBot3 issues and are actively working on resolutions. This issue appears to be resolved, so it will be closed. |
I am using ROS Noetic on Ubuntu 20.04.6 LTS 5.10.104-tegra on a Jetson NX.
My ultimate goal is to run the example launch file for leggedrobotics/elevation_mapping_cupy, which uses turtlebot3_gazebo in its sourced elevation_mapping_cupy/launch/turtlesim_init.launch.
It gives me a lot of errors like:
"odom" passed to lookupTransform argument target_frame does not exist.full log
Meanwhile the turtlebot in gazebo remains as a white blob.
@ZhoZhicheng opened elevation_mapping_cupy issue 78 for the same problem, and maintainer @mktk1117 closed the issue, stating that it is a turtlebot issue and not their problem. I followed up with the @ZhoZhicheng, who confirmed that it did indeed turn out to be a turtlebot bug which which was supposedly "easy to solve", although they cannot recall how...
The tf tree looks like this:
So clearly, as stated in the error, there is no 'odom' frame, which I guess is supposed to be there.
I found two issues, both unresolved, where people described the "odom" frame being disconnected from the rest of the tree: turtlebot3 issue 7790 and turtlebot3_simulations issue 214. In both of those issues, the "odom" frame exists, but is disconnected from the rest of the tree. For me, it doesn't appear to exist at all. In the first of those two issues, @ROBOTIS-Ashe advised installing all dependent ROS packages and @DingoOz advised remembering to source
devel/setup.bashin the catkin build directory, but OP @abdur78 did not respond further, and the issue remains open three years later. But in my case, I had already remembered to source my/devel/setup.bash, as well as/opt/ros/noetic/setup.bash. Doing so again did not resolve the issue. I had apparently not installed all of the dependent ROS packages, but installing those did not resolve the issue either.Before installing the missing dependent packages, I had these apt packages installed:
output of
apt list --installed | grep "^ros"originallyThe following new packages were installed after following the commands given here to install dependent packages for noetic, but this did not help:
output of
apt list --installed | grep "^ros"after installing dependent packagesI noticed that the author of this official video about getting started with TurtleBot3 in ROS1 Noetic cloned turtlebot3 and turtlebot3_simulations from the github repo and built with catkin, rather than installing them via apt. I tried that, they built fine, and I re-sourced, but this did not resolve the issue either.
With
roslaunch turtlebot3_bringup turtlebot3_model.launch, there's also no "odom":When I run
roslaunch turtlebot3_gazebo turtlebot3_empty_world.launch, the turtlebot visually appears in gazebo:However, no
tfdata seems to be published:It's the same with
roslaunch turtlebot3_gazebo turtlebot3_world.launch:But with
roslaunch turtlebot3_fake turtlebot3_fake.launch, the tf tree shows up and includes "odom":In addition to experiencing the missing "odom" issue on the aforementioned bare-metal Jetson device, I am able to replicate it in a docker container built from the following
DockerfileI've made forelevation_mapping_cupy:`Dockerfile` for `elevation_mapping_cupy`
I run the image with the following script, which assumes that the image is named
elevation_mapping_cupyand whose purpose is to allow GUI programs to run through the host X server:`run.sh`
To run that exact image, you'll need an NVIDIA graphics card with CUDA and the NVIDIA container toolkit, plus an X server, and you'll need to adjust the base image and
pip installed major version ofcupy. But the point with thisDockerfileis to show that the missing "odom" behavior doesn't only happen only in one environment. I've run the built container on a completely different machine and architecture, and still don't see any "odom" frame. ThisDockerfiledoesn't include the so-called dependent ROS packages, but as I noted above, installing those didn't change anything with the missing "odom", and yes, I did try this also in the running docker container and re-sourcing.For a more minimal example, I made the following
Dockerfilewhich includes all of the so-called dependent packages, doesn't require any GPU, and buildsturtlebot3_simulationsandturtlebot3_simulationswithcatkin_build:minimal `Dockerfile` for turtlebot3 to illustrate issue
Run it with:
`run.sh`
Then in another window, to view the tf tree (replace
boring_noetherwith the name of the running container, which you can get fromdocker ps):With this, I again see no "odom":
Am I missing something simple, or is this a bug? In the latter case, is there any fix or workaround?
The text was updated successfully, but these errors were encountered: