Frame [odom] does not exist

[umsh315]

Check this before filling out

• I have checked that this question has not been previously resolved.

What is your question? What do you need help with?

Hello, I have encountered a problem during the bringup process that has made it impossible to proceed and would appreciate help if you have a solution.

I found a similar situation in a closed issue, but the problem is slightly different, so I am posting it here.

As shown in the image, it is an odom issue and I can't find anything about tf, including the base_link.

The environment is using an external PC on ros2 humble, communicating wirelessly with the PC on the back of go2 edu with cyclonedds. ros2 topic pub/sub confirmation and ping communication are confirmed.

Thank you in advance

[umsh315]

As per that issue, I tried adding joint_state_publisher and changing the global frame to base_link, but this just shows the initial posture of urdf instead of communicating.

Does this mean that confirming ros2 pub/sub and ping communication is not enough to establish a communication environment? If there is any operation necessary to synchronize the actual device with rviz, please let me know.

[umsh315]

Does this mean that this project is still under development and only part of it is available to the public yet? I am supporting this project.

I am also in the process of developing this project using r-tab map and nav2, and am currently at the stage where if I can output a synchronized tf, I can move on to validate the mapping and path planning.

The first of the demo videos in this readme is ideal and I would like to ask how to do this output! I know you are busy, but I would appreciate any advice you can give me when you are available!

[Juancams]

Hi!

I've been looking into your problem, and it may have to do with the robot's firmware version.

As far as I remember, the humble/foxy version uploaded is using the odom provided by the lidar, but I think that topic has been modified in the latest updates, and now you have to use a different one.

In these humble or foxy branches, which should be merged between tomorrow and the day after, I think it should work correctly for you.

[umsh315]

Understood! Thank you for the prompt response.

On a side note, regarding our plan to implement the navigation stack in a wireless environment with go2: We intend to run the programs on an onboard PC (Jetson Orin), and handle RViz visualization and Nav2 goal setting from an external PC wirelessly connected to the onboard PC. Do you have any concerns about this plan?

I'm worried that if we were to wirelessly transmit the onboard PC's display via HDMI to a monitor and do all RViz visualization that way, there would be significant latency.

This might be a basic question, but please let me know if you have any concerns or points to consider.

Also, when developing on the onboard PC, is there any difference between setting up a Humble container and using Humble branch packages versus simply using the Foxy branch directly?

[Juancams]

Regarding the rviz visualization and using nav2 from outside, there shouldn't be any problems. You can use the go2_rviz package to load the default configuration I use or open your own visualization, and as long as you have the communication with your robot properly configured, there shouldn't be any problems.

Regarding the differences between the Foxy and Humble versions, I'd say they are only the use of callback groups and a few other minor details. You shouldn't notice any differences when using them between the versions.

I'm closing the issue until I finish the changes I mentioned.

Regards ^^

[eastseaking]

@umsh315 Have you been able to resolve the issue? It works fine on another laptop, but the same problem occurs on the new laptop.