For frame [rplidar_gpu_laser_link]: Frame [rplidar_gpu_laser_link] does not exist

[fjp]

Hello again.

I've successfully got my RPi4 based diffbot driving around using rqt (robot steering) from my development system (Ubuntu on VirtualBox on a Mac). Now I’m trying to move to the next step and enable navigation. I start roscore on the development system and point the diffbot to it and then launch ‘bringup_with_laser.launch’ and everything seems good. I get valid looking data in /diffbot/scan on both systems.

But when I ‘roslaunch diffbot_slam diffbot_slam.launch slam_method:=gmapping’ on the development system I don’t see any lidar data points in rviz I get two errors that I don’t quite know how to interpret:

In rviz:

Transform [sender=unknown_publisher]
For frame [rplidar_gpu_laser_link]: Frame [rplidar_gpu_laser_link] does not exist

and in the terminal from which I launched diffbot_slam I get this repeating warning:

[ WARN] [1635345613.864692611]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.gmapping.message_filter] rosconsole logger to DEBUG for more information.

Any help on why the points don’t seem to be registering in rviz would be appreciated. After a lot of googling this seems to be a TF issue perhaps? I’m a ROS newbie so I must admit I get lost in all the discussions about frames. I did check that the date/time on both systems is correctly synced to ntp.ubuntu.com but I still have the problem.

Regards,

Ian

Originally posted by @joeuser846 in #40 (comment)

[EldarKurbanov]

I had the same problem. It turned out that on my dev machine I set the ROS_MASTER_URI environment variable pointing to my robot. But I completely forgot to set the environment variable ROS_IP, which should be equal to the IP address of the dev machine on the local network.

I would also check that the ROS_IP variable on the robot is also set correctly.

@joeuser846

[fjp]

Thanks for the hint @EldarKurbanov to check for ROS_IP being set correctly.

Regarding the wrong naming of frames I created commit 60750e9 which should fix the issue. There is now a new rplidar.launch that accepts a frame_id argument which is set to rplidar_laser_link by default. This new launch file is also being used now inside of bringup_with_laser.launch instead of the original rplidar.launch file from the rplidar_ros package, which didn't allow to provide frame_id as an argument.