Hi Husarion Team,
While trying to start your new feature release that allows Nav2 to be started via the rosbot snap command rosbot.navigation-start, we noticed that the prelight script keeps failing with the error below:
husarion@husarion:/var/snap/husarion-rplidar/common$ sudo rosbot.navigation-start
Running autonomy preflight (controller mppi). Please wait up to 30 seconds…autonomy preflight — namespace rb8005, timeout 30 s
[ok ] driver TF odom → base_link is available
[ok ] odometry /rb8005/odometry/filtered is publishing
[ok ] velocity sink the driver listens on /rb8005/autonomous/cmd_vel
[ok ] lidar /rb8005/scan is publishing (frame_id ‘rb8005/laser’)
[FAIL] laser TF no transform base_link → rb8005/laser— laser TF —
The scan is published in frame ‘rb8005/laser’, but that frame is not in the robot’s
URDF, so nav2 cannot place the measurements. The robot configuration most
likely has no lidar mounted.
sudo snap set rosbot driver.configuration=autonomy
sudo rosbot.restart
(ROSbot 2/3 uses driver.configuration=basic — it already includes a lidar.)[ros2run]: Process exited with failure 1
However, this we found weird because we have the RP-Lidar s3 connected to our Rosbot-XL , and its topics are being published to the topic /rb8005/scan (where the ‘rb8005’ is the current defined namespace).
What we think might be the issue is that the LIDAR keeps appending the namespace 'as a prefix to its frame-id (currently set as ‘laser’). And since the robot_state_publisher’s tree on /rb8005/tf_static is given as (base_link → body_link → cover_link → rplidar_link → laser), there exists no transform base_link → rb8005/laser.
husarion@husarion:/var/snap/husarion-rplidar/common$ sudo snap get husarion-rplidar driver ros
Key Value
driver.angle-compensate true
driver.channel-type serial
driver.frame-id laser
driver.inverted false
driver.model s3
driver.scan-mode DenseBoost
driver.serial-baudrate 1000000
driver.serial-port auto
ros.automatic-discovery-range subnet
ros.domain-id 0
ros.localhost-only
ros.namespace rb8005
ros.static-peers
ros.transport fastdds/udp
We have tried to fix or debug where the additonal prefix is coming from but have not been successful. We would appreciate your help. Thank you