no local costmap for nav2 on humble (but works in foxy)
Hi ROS 2 community,
over the last weeks I tried to get nav2 running with humble (real hardware and in simulation), but it looks like the local costmap is just not working while it was fine in foxy.
I created docker-container for quick testing for both, for foxy and humble
Does anybody have an idea how to get a local costmap for autonomous navigation in ROS 2 humble?
There are no errors or tracebacks in the logs, humble seems a bit more verbose with its infos but it looks fine.
According to this issue its a problem with FastDDS, but switching to cyclondds does not solve the issue (see my docker setup here and here ), same for installing the current versions of ROS humble as suggested here (see docker setup here and here). I also tried to compile the humble-branch of navigation2 from source.
Interestingly even in the gif from the official documentation the local costmap is not shown:
while it is shown in foxy:
Asked by brean on 2023-01-24 04:07:19 UTC
Comments
You've checked the topic to make sure it's really not being published?
Asked by billy on 2023-01-24 23:37:44 UTC
Thank you very much for your comment!
There is data on
/local_costmap/costmap
, that gets received on the "remote-pc" (where the nav-stack with rviz2 is running) but rviz2 does not show the local costmap on humble, only in foxy I see the costmap! I also have the warning message in rviz2 that no data has been received on the topic whileros2 echo topic /local_costmap/costmap
prints data.There is no data on
/local_costmap/costmap_updates
but I think that is not used anyway (also on both foxy and humble).rviz2 shows the local plan (
/local_plan
) and Obstacle avoidance and replanning on dynamically appearing obstacles seems to work fine.Asked by brean on 2023-01-25 05:04:04 UTC
I also see that the frame header in humble have a timestamp while the ones in foxy don't!
Asked by brean on 2023-01-25 05:22:06 UTC
Have you read about QoS and the many poeple, myself included, that can't get maps to show up on RIVIZ2 becuase of QoS setting?
Asked by billy on 2023-01-25 12:25:44 UTC
Yes, I read about QoS. In Rviz2 itself I can set some QoS-settings to the topic, I tried moving from "Reliable" to "Best Effort" and "Transient local" to "Volatile" but I still did not get any data. I tried both FastDDS and Cyclon.
Asked by brean on 2023-01-26 07:33:28 UTC
It also looks like the timestamps do not match. while tf-frames have a stamp that is local to the starttime of the simulation:
transforms: - header: stamp: sec: 247 nanosec: 403000000 frame_id: base_link
while messages on/local_costmap/costmap
have timestamp from the local clock:header: stamp: sec: 1674736954 nanosec: 492295014 frame_id: odom
(but this probably isn't an issue because global_costmap is shown although it has the same timestamp as local_costmap)
Asked by brean on 2023-01-26 07:44:14 UTC
I set the map parameters in RVIZ2 all to "System Default" on the /map topic I was struggling with. That is the only thing that worked for me.
Asked by billy on 2023-01-27 01:29:42 UTC
So, setting everything to "system default" and re-publishing the costmap by setting
msg.header.stamp.sec = 0 msg.header.stamp.nanosec = 0
works but why? The global costmap is published with valid non-zero timestamps and is shown fine in Rviz2. I don't even know if this a rviz2, ros-nav2 or communication bug?Asked by brean on 2023-02-01 04:53:28 UTC
also the local planer seems to have some issues, if I put an obstacle very close to the robot it just "wiggles" on the spot and stops (only after a few minutes it slowly moves backwards and tries some other paths but it is still not reaching its goal and goes into an "aborted" state) - from there it does not accept any new waypoints and continues this wiggling behavior. If the obstacle is further away and the robot is not in the state it just drives around it. So I assume the global planner is working but the local planner is not. I created a new bug-report on github for this behavior: https://github.com/ros-planning/navigation2/issues/3392
Asked by brean on 2023-02-01 08:31:41 UTC
Your planner issue could be a settings issue. I haven't seen that behavior on my physical robot, but also have not tried to produce it.
Asked by billy on 2023-02-01 13:52:00 UTC