I hope this message finds you well. I am writing to seek assistance with an issue we are currently facing regarding the integration of the odometer and LiDAR systems in our setup.
We are using the rplidar, which is publishing values with the frame ID set to ‘laser’ under the topic name ‘/scan’. We have encountered a couple of challenges, as detailed below:
Static Transformation Issue:
We initially attempted to connect the sensor using the static_transform_publisher. For this, we commented out the ouster.launch.xml part in map_navi.launch and added the following node: <node pkg="tf" type="static_transform_publisher" name="lidar_to_robot" args="0.05 0 0.08 0 0 0 /base /laser 100" />
However, we observed that when the frame is set to ‘base’ or ‘odom’ in RViz, the /scan values are not visible. These values can only be checked when the frame is set to ‘laser’. The TF tree confirms that ‘odom’, ‘base’, and ‘laser’ are connected.
Xacro Connection Issue:
Next, we connected the laser to a joint under the trunk using xacro. In this configuration, the /scan value is visible when the frame is set to ‘laser’, ‘trunk’, or ‘base’ in RViz. Unfortunately, when the frame is set to ‘odom’, the /scan value disappears. The TF tree again shows that ‘odom’, ‘base’, ‘trunk’, and ‘laser’ are connected.
It appears that the issue of not receiving laser scan messages might be related to the connection not being properly established with ‘odom’. Could you please provide guidance on how we might resolve these issues to ensure proper linkage and visibility of scan values across all relevant frames?
Thank you very much for your time and assistance. We look forward to your expert advice on this matter.
OS: — (e.g. Ubuntu 20.04)
ROS Distro: —
Built from source or installed: —
Package/SDK version: — (if from the repository, give version)
Real hardware or simulation: —
Robot Type: —
Sensor Type: —
Expected behavior
A clear and concise description of what you expected to happen.
Actual behavior
A clear and concise description of what you encountered.
To Reproduce
Provide the steps to reproduce:
run something
launch something else
see the error
Other notes
–
On first glance:
This should work, please use rqt to first ensure that you can see that the base and laser frames are connected in the tf_trees.
It seems that the odom tf is not being published correctly. This seems to be a weird issue, please increase the publish_rate of the odom tf. Furthermore, this issue might be from the rp lidar driver, please post the launch file and its configuration
Ideally, post all the relevant code and pictures so that we can help debug!
OS: Ubuntu 20.04
ROS Distro: noetic
Built from source or installed: Establishment of qre_go1 workspace on ubuntu20.04 noetic PC.
Install and run the RPLiDAR package on Go1 raspberrypi (18.04 / melodic).
host: 192.168.12.1 and linked with Go1 using WiFi.
Package/SDK version: qre_go1 / noetic-robotic
Real hardware or simulation: real hardware
Robot Type: GO1
Sensor Type: RPLiDAR A1
Expected behavior
The tf tree connection is expected to be formed as follows. map - odom - base - trunk - scan
And amcl and move base packages are expected to work.
Actual behavior
However, map nodes are not created and laser scan data is not connected to odom.
Even if the sensor is connected using static_transform_publisher, it appears to be connected to the tf tree of rqt, but data is not transmitted to odom.
To Reproduce
roslaunch go1_bringup bringup.launch
roslaunch go1_navigation map_navi.launch
Please verify if there are name_spaces in the go1 launch files that you are running as that changes the tf prefix. Incase you are using the go1_om repository then simply add the same namespace to the rplidar as well.
I don’t understand what you mean by adding a name space.
On Go1 RaspberryPi :
roslaunch rplidar_a1 Run rplidar_a1.launch
rplidar_a1.launch is as follows:
I ran rosnode kill -a in the go1 raspberrypi terminal.
Configure ubuntu20.04 and noetic docker on your PC and run the qre_go1 (branch: noetic-robotis) package in a container.
The rostopic list is as follows.
/amcl/parameter_descriptions
/amcl/parameter_updates
/amcl_pose
/battery_state
/camera5/point_cloud_rearDown
/clicked_point
/diagnostics
/go1_controller/cmd_vel
/go1_controller/imu/data
/go1_controller/odom
/go1_controller/state
/initialpose
/joint_states
/local_ekf/set_pose
/map
/map_metadata
/map_updates
/motor_states
/move_base/current_goal
/move_base/goal
/move_base/recovery_status
/move_base_quadruped/cmd_vel
/move_base_simple/goal
/odometry/filtered
/particlecloud
/rosout
/rosout_agg
/scan
/tf
/tf_static
Please disable the ekf_localization in the map_navi and check. It might be the case that there are 2 ekf localization modules running! Also please post the ros node list and the info of the ekf nodes.