Seemingly there is no such file ‘compose.ros1_bridge.yaml’ in branch ROS2-devel. Should there be or is document somehow flawed?
I try to compose demo as per instructions given:
login to user computer via ssh
cd panther-navigation
source setup_virtual_desktop.sh
export POINTCLOUD2_TOPIC=/panther/velodyne/velodyne_points # topic published by velodyne container that is running on the same user computer
export USE_SIM_TIME=False
when commanding the given compose commands (without missing ros1_bridge file) I get infinite amount of error messages from various containers:
< rviz2 Message filter dropping message: frame ‘panther/velodyne’ at time … for reason ‘discarding message because the queue is full’
< and very similar lines for mapping container.
Nothing is published in topic /map, /map_updates or /map_metadata and no map files are generated to /maps.
If there are some mistakes in instructions, please fix them and if not, then what should I do to get navigation demo running?
At this point, I can tell you that ros1_bridge is most likely a remnant of the ros1 demo and is not needed for ROS 2.
With the second point, everything works fine in the simulation, so if the API is consistent with the settings in the simulation, it should also work on the hardware.
I updated the readme and simplified the configurations in this PR
In Github repo there are commit comments telling " Only PC2 support & nicer readme", does it refer to user computer option PC02 (Intel NUC)? And if it does, should this demo still be usable with our configuration (Jetson Orin)?
Please clarify, what does this “if the API is consistent with the settings in the simulation” actually mean. I followed the instructions given in README.md to point and apart from configuring topic for pointcloud2 messages I have not made any customizations to settings. However, the demo still doesn’t work, and I keep getting the aforementioned error messages from docker logs.
By PC2 I meant the PointClound2 message for ROS2, which is the most popular msg type for 3D LIDAR.
As for the API in simulation. I don’t currently have a Panther configured with 3D LIDAR. Therefore, I performed the tests using simulation. As the parameters for nav2 are common to both hardware and simulation. So there should be no problem running nav2 when all topics and tf tree are compatible.
If the simulation differs from the hardware, it is worth making a note of these changes and:
a) or make corrections to the nav2 configuration file
b) or adapt the API to that from the simulation, then the robot should behave similarly to that observed from the simulation.