# URDF Real robot joint\_states, RViz LaserScan **URL:** \ **Category:** ROSDS Support\ **Tags:** howto\ **Created:** [May 18, 2026, 1:36pm UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065 "2026-05-18T13:36:52Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [May 18, 2026, 1:36pm UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/1 "2026-05-18T13:36:52Z")
Hello, I am working on the Real Robot Project of the ‘URDF for ROS2’ course. 1. I have built fastbot\_real.urdf for the real robot. When connected to the physical robot, I get “No transform from [left\_wheel] to [base\_link]” errors for both wheels in RViz: ![image](https://get-help.theconstruct.ai/uploads/default/original/2X/1/115a824bac2f696bd34a234e7f1ad5e20190f38d.jpeg) I thought the issue is related to joint states and probably a naming mismatch between wheel joints or axle joints). I tried running ros2 topic info/joint\_states to understand what could be going wrong. But it gives me a lot of `cycloneDDS` warnings: ```auto Cuser:~/ros2_ws$ ros2 topic echo /joint_states --once [WARN] [1779103066.934255108] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103066.934339342] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/rosout' with type 'rcl_interfaces::msg::dds_::Log_' from USER_DATA '(null)'. [WARN] [1779103066.934862855] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103066.934898006] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/diagnostics' with type 'diagnostic_msgs::msg::dds_::DiagnosticArray_' from USER_DATA '(null)'. [WARN] [1779103066.934910006] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/scan' with type 'sensor_msgs::msg::dds_::LaserScan_' from USER_DATA '(null)'. [WARN] [1779103066.938364376] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103066.938750632] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103066.938782215] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/lslidar_order' with type 'std_msgs::msg::dds_::Int8_' from USER_DATA '(null)'. [WARN] [1779103066.957494474] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103066.957711417] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/cmd_vel_safe' with type 'geometry_msgs::msg::dds_::Twist_' fromUSER_DATA '(null)'. [WARN] [1779103067.033248626] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.033300064] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/rosout' with type 'rcl_interfaces::msg::dds_::Log_' from USER_DATA '(null)'. [WARN] [1779103067.033315649] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.034448758] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.034633314] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/lslidar_driver_node/transition_event' with type 'lifecycle_msgs::msg::dds_::TransitionEvent_' from USER_DATA '(null)'. [WARN] [1779103067.041336648] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.041390906] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/rosout' with type 'rcl_interfaces::msg::dds_::Log_' from USER_DATA '(null)'. [WARN] [1779103067.041412021] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.041459592] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/cmd_vel_safe' with type 'geometry_msgs::msg::dds_::Twist_' fromUSER_DATA '(null)'. [WARN] [1779103067.042534624] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.042752962] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/cmd_vel' with type 'geometry_msgs::msg::dds_::Twist_' from USER_DATA '(null)'. [WARN] [1779103067.045780352] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.045849642] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/rosout' with type 'rcl_interfaces::msg::dds_::Log_' from USER_DATA '(null)'. [WARN] [1779103067.049286792] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.049316144] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/image_raw/compressed' with type 'sensor_msgs::msg::dds_::CompressedImage_' from USER_DATA '(null)'. [WARN] [1779103067.049753477] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/image_raw/compressedDepth' with type 'sensor_msgs::msg::dds_::CompressedImage_' from USER_DATA '(null)'. [WARN] [1779103067.049795394] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/image_raw' with type 'sensor_msgs::msg::dds_::Image_' from USER_DATA '(null)'. [WARN] [1779103067.049847573] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/image_raw/theora' with type 'theora_image_transport::msg::dds_::Packet_' from USER_DATA '(null)'. [WARN] [1779103067.049990193] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/camera_info' with type 'sensor_msgs::msg::dds_::CameraInfo_' from USER_DATA '(null)'. [WARN] [1779103067.050037391] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.051267361] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.051302351] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.051835365] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.051865672] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/rosout' with type 'rcl_interfaces::msg::dds_::Log_' from USER_DATA '(null)'. [WARN] [1779103067.051883902] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.052215189] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/motor_vels' with type 'serial_motor_msgs::msg::dds_::MotorVels_' from USER_DATA '(null)'. [WARN] [1779103067.052307291] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/encoder_vals' with type 'serial_motor_msgs::msg::dds_::EncoderVals_' from USER_DATA '(null)'. [WARN] [1779103067.052372552] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/odom' with type 'nav_msgs::msg::dds_::Odometry_' from USER_DATA'(null)'. [WARN] [1779103067.052425181] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/tf' with type 'tf2_msgs::msg::dds_::TFMessage_' from USER_DATA '(null)'. [WARN] [1779103067.052451333] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.052494124] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/rosout' with type 'rcl_interfaces::msg::dds_::Log_' from USER_DATA '(null)'. [WARN] [1779103067.052589394] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.052646013] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/tf' with type 'tf2_msgs::msg::dds_::TFMessage_' from USER_DATA '(null)'. [WARN] [1779103067.052667724] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/tf_static' with type 'tf2_msgs::msg::dds_::TFMessage_' from USER_DATA '(null)'. [WARN] [1779103067.052703391] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/robot_description' with type 'std_msgs::msg::dds_::String_' from USER_DATA '(null)'. [WARN] [1779103067.052772427] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_' from USER_DATA '(null)'. [WARN] [1779103067.052837774] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/clock' with type 'rosgraph_msgs::msg::dds_::Clock_' from USER_DATA '(null)'. [WARN] [1779103067.052861125] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. [WARN] [1779103067.052880446] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/joint_states' with type 'sensor_msgs::msg::dds_::JointState_' from USER_DATA '(null)'. [WARN] [1779103067.052898757] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/parameter_events' with type 'rcl_interfaces::msg::dds_::ParameterEvent_' from USER_DATA '(null)'. ``` The real robot publishes /joint\_states, but the joint names it publishes don’t seem to match the joint names in my URDF (joint\_left\_wheel and joint\_right\_wheel). How do I retrieve the exact joint names published by FastBot’s onboard driver on /joint\_states? Also, should the joint names in fastbot\_real.urdf match the real robot’s joint names exactly? I tried renaming my URDF joints to `wheel_left_joint` and `wheel_joint_left` but the error persists. I tested it in simulation, and these issues don’t pop up. For example, the following is my URDF for the left wheel: ```auto ``` 1. Simulation RVIZ Laser Scanner issue: I have the Gazebo simulation working with the LiDAR plugin publishing to `/scan`. The LaserScan display in RViz works correctly when the robot moves straight: the scan dots move with the robot while the grid stays fixed. However, when the robot turns/rotates, the grid rotates along with the robot instead of staying stationary. The expected behavior (as shown in the course instructions) is that the grid should always remain fixed and only the robot and scan dots should move. My Fixed Frame in RViz is set to `odom` `Differential Drive` plugin has `publish_odom_tf: true` and `frame_id: odom`, `child_frame_id: base_link` ROS-Gazebo bridge is bridging `/tf`, `/odom`, `/scan` Is this rotating grid behavior expected in RViz or is it an indication of a misconfiguration? I have set my laser scanner frame as follows: ```auto ``` Would appreciate any advice. Thank you. Best, Ninad Mehta ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [May 21, 2026, 6:12pm UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/2 "2026-05-21T18:12:21Z")
@duckfrost2 @girishkumar.kannan Hey guys, just following up on this post. Did either of you get a chance to look into it? Happy to provide any additional information that might help. ---
**Author:** ![girishkumar.kannan](https://get-help.theconstruct.ai/user_avatar/get-help.theconstruct.ai/girishkumar.kannan/32/6994_2.png) [@girishkumar.kannan](https://get-help.theconstruct.ai/u/girishkumar.kannan)\ **Post date:** [May 22, 2026, 8:11am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/3 "2026-05-22T08:11:58Z")
Hi @ninadmehta34 , Getting straight to your issues: 1. RMW Cyclone DDS: Failed to parse type hash issue: I have not encountered this issue before. Doing a quick Google search for `[rmw_cyclonedds_cpp]: Failed to parse type hash for topic` indicates that there might be a dependency mismatch in the environment, which would be a cross-dependency issue in the VM (virtual machine) environment that you have. I do not know how to fix it, nor have suggestions as to how to fix it. That’s why your simulation works but real robot fails - you’re probably having Jazzy in your rosject but the real robot is using Humble. There is some mismatch somewhere, that I don’t know. 2. Simulation Laser Scanner issue where the laser moves when the robot turns: I do not see any issues here. That is what is supposed to happen. The laser scanner stays fixed in the Gazebo Classic version. Since you are working with the Gazebo Modern version (re-branded Ignition version), what you see is bound to happen. That is in fact the correct form of simulation which properly depicts the drift of odom as the robot moves. Make sure you have the following steps done: I hope my answers helped you. Let me know if you still need any clarifications. Regards, Girish ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [May 23, 2026, 10:45am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/4 "2026-05-23T10:45:00Z")
Thank you, @girishkumar.kannan. 1. Is there someone over at Construct who can help me resolve this? Otherwise, the course can’t be completed as I won’t be able to finish all the parts of the project. @ralves, could you please take a look at this issue? 2. My laser\_scanner\_frame joint’s parent frame is base\_link. I have the static TF for the simulation, but not for the real robot, as I think its primary purpose to pin the odom frame to a world frame is applicable only for Gazebo physics. Is that the correct understanding? ```auto static_tf_world_odom = Node( package='tf2_ros', executable='static_transform_publisher', name='static_tf_world_odom', arguments=['0', '0', '0', '0', '0', '0', 'world', 'odom'] ) ``` Best, Ninad Mehta ---
**Author:** ![rtellez](https://get-help.theconstruct.ai/user_avatar/get-help.theconstruct.ai/rtellez/32/9813_2.png) [@rtellez](https://get-help.theconstruct.ai/u/rtellez)\ **Post date:** [May 27, 2026, 9:22am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/5 "2026-05-27T09:22:52Z")
We are working on this problem. Please allow us a few hours more to solve it and give you a solution ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [May 27, 2026, 9:50am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/6 "2026-05-27T09:50:26Z")
Yes. Thank you for looking into it. ---
**Author:** ![rodrigo55](https://get-help.theconstruct.ai/user_avatar/get-help.theconstruct.ai/rodrigo55/32/7280_2.png) [@rodrigo55](https://get-help.theconstruct.ai/u/rodrigo55)\ **Post date:** [May 27, 2026, 10:38am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/7 "2026-05-27T10:38:46Z")
Hi @ninadmehta34, I looked into your issues. Here’s what I found. 1. The `[rmw_cyclonedds_cpp]` WARNING (Not ERROR) is simply because the rosject you are using for this project has a ROS Jazzy distribution, while the real fastbot you are connecting to in the Small City Lab is ROS Humble. The fastest way to get rid of this message is to downgrade your rosject to ROS Humble. Nothing will happen, and it’s simple. Just click on edit your rosject and select the Humble distribution: ![image](https://get-help.theconstruct.ai/uploads/default/original/2X/5/54e27609ee41e213e80ba73cca3d58a336214c65.png) 2. The different names you are seeing (not the same as in your URDF file) is happening because **the real robot actually runs its own robot state publisher.** All robots should have one running all the time. So, when you run yours, it clashes with the robot’s. The solution here is to **add a namespace to your robot state publisher and the topics it publishes/subscribes to,** since we can’t just turn off the robots RSP (other students that aren’t doing the URDF project need it, i.e. Nav2, ROS2 basics, etc.) So, you can do something like `student/robot_state_publisher`, `student/robot_description`, `student/tf`, `student/tf_static` (this would mean launching `rviz` under the same `student/` namespace so you can see everything). We realize this is not in the instructions and we apologize, we are working to include this in there. 3. The laserscan drift you see _in the simulation_ does seem a little too much (especially since you have `odom` as the global frame. You should see it like the final GIFs showcasing the fastbot going in a circle, both in the simulation and in the real robot. I tried this to see if there was an error with the simulation, but it wasn’t, and the drift was not there. So I suspect there is an issue with either your GZ sensor plugin, or it’s just a finicky simulation launch, so try restarting it. Let me know if I answered your questions and if you have any more. ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [May 27, 2026, 12:37pm UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/8 "2026-05-27T12:37:44Z")
Thank you for a prompt response, @rodrigo55. I will work on this tomorrow and let you know if I have any doubts in a couple of days. Best, Ninad Mehta ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [May 29, 2026, 9:54am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/9 "2026-05-29T09:54:56Z")
Hi @rodrigo55 Following the advice, I downgraded my rosject to ROS2 Humble. Tried it out in Simulation and was able to make it work like in Jazzy with minor changes. With respect to the real robot and the `robot_state_publisher`, I made the following changes: 1. Adding a namespace `student` by making the following changes to the state\_publisher launch file and the rviz launch file: **`state_publisher.launch.py`** : ```auto import os from ament_index_python.packages import get_package_share_directory from launch import LaunchDescription from launch.substitutions import Command from launch_ros.actions import Node # this is the function launch system will look for def generate_launch_description(): ####### DATA INPUT ########## urdf_file = 'fastbot_real.urdf' package_description = "ros2_urdf_project" ####### DATA INPUT END ########## print("Fetching URDF ==>") robot_desc_path = os.path.join(get_package_share_directory(package_description),"urdf",urdf_file) # Robot State Publisher robot_state_publisher_node = Node( package='robot_state_publisher', executable='robot_state_publisher', name='robot_state_publisher_node', namespace='student', emulate_tty=True, parameters=[{'use_sim_time': False, 'robot_description': Command(['xacro ',robot_desc_path]), 'frame_prefix': 'student/'}], # Remap the output topic from /robot_description to /fastbot_description remappings=[ ('robot_description', 'fastbot_description'), #For joint states, to ignore the namespace (Hardcoding/Tunes the wheels back to the lab hardware) ('joint_states', '/joint_states') ], output="screen" ) # create and return launch description object return LaunchDescription( [ robot_state_publisher_node, ] ) ``` **rviz.launch.py** : ```auto import os from ament_index_python.packages import get_package_share_directory from launch import LaunchDescription from launch.substitutions import Command from launch_ros.actions import Node def generate_launch_description(): package_description = "ros2_urdf_project" # RVIZ Configuration rviz_config_dir = os.path.join(get_package_share_directory(package_description),'rviz','fastbot_real.rviz') rviz_node = Node( package='rviz2', executable='rviz2', namespace='student', output='screen', name='rviz_node', parameters=[{'use_sim_time': False}], arguments=['-d', rviz_config_dir]) # create and return launch description object return LaunchDescription( [ rviz_node ] ) ``` Despite doing this, the wheels still refuse to render. With the above setup, I am encountering the wheel TF error and some other warnings in RVIZ. Below are the screenshots of the same. ![namespace3](https://get-help.theconstruct.ai/uploads/default/original/2X/6/6ff0edebad83d0a129da5606e5605e79cf75fa26.jpeg) ![namespace4](https://get-help.theconstruct.ai/uploads/default/original/2X/9/95c6dde1ecab1e89bd4f1bbc4babb25cd7990e93.jpeg) ![namespace1](https://get-help.theconstruct.ai/uploads/default/original/2X/4/43456e7cb5fc71ae3a3a20f4c486d8d6e7ea18db.jpeg) ![namespace2](https://get-help.theconstruct.ai/uploads/default/original/2X/c/ca796d2cc6b7e29d8524b40dfcdea5d4265b1847.jpeg) Below is a terminal snippet as well. Says Incompatible QoS ```auto [INFO] [robot_state_publisher-1]: process started with pid [1343] [INFO] [rviz2-2]: process started with pid [1345] ... [rviz2-2] [WARN] [1780047168.070716278] [student.transform_listener_impl_555d16ebc910]: New publisher discovered on topic '/tf_static', offering incompatible QoS ``` So to summarise: **Current State:** Using the `frame_prefix: 'student/'` parameter, my URDF parses correctly and all of my fixed links are rendering perfectly in RViz (anchored to the `student/base_link` fixed frame). **Problem:** My two continuous wheel joints are failing. RViz continuously throws this error: `No transform from [student/left_wheel] to [student/base_link]` 1. Regarding the laser\_scan drift, relaunching didn’t change anything. Still facing the same problem. But I will get back to it once the above issue is sorted. Is there a specific quirk with Humble namespaces or QoS settings that is preventing the `joint_state_publisher` from broadcasting here? Thank you for your time! Best, Ninad Mehta ---
**Author:** ![rodrigo55](https://get-help.theconstruct.ai/user_avatar/get-help.theconstruct.ai/rodrigo55/32/7280_2.png) [@rodrigo55](https://get-help.theconstruct.ai/u/rodrigo55)\ **Post date:** [June 2, 2026, 10:29am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/10 "2026-06-02T10:29:58Z")
Hi @ninadmehta34, the error tells you that there is no transform connecting those frames. So, what does your URDF look like in terms of joints? you talk of `joint_state_publisher`, but I don’t see it in your launch file? ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [June 3, 2026, 12:59pm UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/11 "2026-06-03T12:59:40Z")
Hi @rodrigo55. Yes. I understand that the error is describing “no transform” connecting those frames and that is why I wanted to know previously, if this was a ‘naming’ mismatch of sorts. Following is what my urdf looks like in terms of wheels and its joints: ```auto ``` And you are right, I completely overlooked not having `joint_state_publisher` in my launch file. So I included it an hour back and tried again: ```auto def generate_launch_description(): ####### DATA INPUT ########## urdf_file = 'fastbot_real.urdf' package_description = "ros2_urdf_project" ####### DATA INPUT END ########## print("Fetching URDF ==>") robot_desc_path = os.path.join(get_package_share_directory(package_description),"urdf",urdf_file) # Robot State Publisher robot_state_publisher_node = Node( package='robot_state_publisher', executable='robot_state_publisher', name='robot_state_publisher_node', namespace='student', emulate_tty=True, parameters=[{'use_sim_time': False, 'robot_description': Command(['xacro ',robot_desc_path]), # FIX 1: The Label Maker (Slaps 'student/' on all body parts for RViz) 'frame_prefix': 'student/'}], # Remap the output topic from /robot_description to /fastbot_description remappings=[ ('robot_description', 'fastbot_description') # FIX 2: For joint states, to ignore the namespace (Hardcoding/Tunes the wheels back to the lab hardware) # ('joint_states', '/joint_states') ], output="screen" ) joint_state_publisher_node = Node( package='joint_state_publisher', executable='joint_state_publisher', name='joint_state_publisher', namespace='student', # Keeps it isolated with the rest of your robot parameters=[{ 'robot_description': Command(['xacro ', robot_desc_path]) }], ) ``` But nothing changed in terms of output. Rviz still displays ‘no transform’ and other errors/warnings I described in the previous message. How should I go from here? Thanks again for looking into this! ---
**Author:** ![girishkumar.kannan](https://get-help.theconstruct.ai/user_avatar/get-help.theconstruct.ai/girishkumar.kannan/32/6994_2.png) [@girishkumar.kannan](https://get-help.theconstruct.ai/u/girishkumar.kannan)\ **Post date:** [June 4, 2026, 12:02pm UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/12 "2026-06-04T12:02:48Z")
Hi @ninadmehta34 , I might need to check your package with all its files put together to see what is causing the error you are facing. Please send me your whole package to me “as-is” so I can look into this and rectify the issue for you. Some things cannot be fixed just by looking at a couple of files. I will send you a direct message with my email so you can share your package with me. I will test it as soon as I can and get back to you with suggestions/changes that you need. Regards, Girish ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [June 5, 2026, 9:16am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/13 "2026-06-05T09:16:38Z")
Thank you, @girishkumar.kannan. I have emailed you all the files. Appreciate your help with this! Best, Ninad Mehta ---
**Author:** ![girishkumar.kannan](https://get-help.theconstruct.ai/user_avatar/get-help.theconstruct.ai/girishkumar.kannan/32/6994_2.png) [@girishkumar.kannan](https://get-help.theconstruct.ai/u/girishkumar.kannan)\ **Post date:** [June 10, 2026, 9:06am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/14 "2026-06-10T09:06:12Z")
Hi @ninadmehta34 , When I took a quick glance into your URDF files, I found out that you did not reference the paths to the mesh files properly. Instead of using the `package` keyword like this: ```xml ``` You should use the `find (package)` keyword like this: ```xml ``` * * * In the `state_publisher.launch.py` file, if you are going to use a namespace, then you do not have to remap the `robot_description` topic to `fastbot_description`. The namespace will automatically keep it distinguished for you. For working on the real robot, you do not need the `joint_sate_publisher` node. * * * In the `control.launch.py`, you need to rename the controller nodes properly. `spawn_controller` indicates that the controller controls the spawn, which is actually incorrect based on the context. You need to rename it as `joint_state_broadcaster`. You are not “spawning” any controllers, you are just activating them. So please don’t use “spawn” with controllers as it makes no sense. * * * Otherwise, there are no issues that I seem to spot. I think having the `joint_state_publisher` node in the `state_publisher.launch.py` file for the real robot is what is causing the “white wheels” issue. Just remove that node and build your project, and it should work fine. Please don’t hesitate to follow up if you still have any issues. Also let us know if your issue is resolved with the above steps. Regards, Girish ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [June 10, 2026, 1:09pm UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/15 "2026-06-10T13:09:37Z")
Hi @girishkumar.kannan Thank you for the detailed inspection of the files. Please give me till tomorrow evening to check all of these things and respond. Apologies. Best, Ninad Mehta ---
**Author:** ![ninadmehta34](https://get-help.theconstruct.ai/letter_avatar_proxy/v4/letter/n/e56c9b/32.png) [@ninadmehta34](https://get-help.theconstruct.ai/u/ninadmehta34)\ **Post date:** [June 11, 2026, 8:43am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/16 "2026-06-11T08:43:46Z")
Hi @girishkumar.kannan, Regarding the points you mentioned above: 1. I have changed the mesh filename as mentioned. 2. I have removed the ‘fastbot\_description’ remap. I was experimenting to see if it would help with RViz. I also removed the joint\_state\_publisher node as you suggested. However, neither of these changes resolved the real robot connection issue. I am still seeing the `No transform from [wheel_left_link] to [base_link]` (or similar) error for the wheels. 3. Regarding control.launch.py, I have renamed the node as you pointed out. Thank you. ![new_try](https://get-help.theconstruct.ai/uploads/default/original/2X/1/1ffd11bad6bcf9e77e320ba2eef8434ecc24fcdd.jpeg) For the real robot, I am currently only launching state\_publisher.launch.py and RViz. Am I supposed to be launching any additional files alongside these two? In essence, the transform issue is still not resolved. Any other steps you would recommend? Thank you for your continued help. Best, Ninad Mehta ---
**Author:** ![girishkumar.kannan](https://get-help.theconstruct.ai/user_avatar/get-help.theconstruct.ai/girishkumar.kannan/32/6994_2.png) [@girishkumar.kannan](https://get-help.theconstruct.ai/u/girishkumar.kannan)\ **Post date:** [June 15, 2026, 11:24am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/17 "2026-06-15T11:24:39Z")
Hi @ninadmehta34 , The issue is you have two TF trees when you are connected to the real robot, which makes you have `student/base_link` frame and the actual `base_link` frame of the real robot. You should have a single TF tree, not 2 trees. You should merge `student/base_link` and `base_link` of the real robot. This is why you **should not use namespace** , which is clearly specified in the project instructions. You should build your TF tree around the existing TF frames of the real robot. Solution is to use the TF frames of the real robot directly, as it will always be published and available. Link all other frames that you created (that is not a part of the existing TF tree of the real robot) to the TF tree of the real robot. Refer to attached image of the TF tree of “Merged” version specified in the rosject instructions. Go over it twice or thrice and understand what has happened there. **THIS IS YOUR HINT.** It is already clearly provided in the instructions. Regards. Girish ---
**Author:** ![system](https://get-help.theconstruct.ai/uploads/default/original/2X/9/9d3ce8305cc0d0d9b6e07d15767a6f245c526f1b.jpeg) [@system](https://get-help.theconstruct.ai/u/system)\ **Post date:** [June 20, 2026, 11:25am UTC](https://get-help.theconstruct.ai/t/urdf-real-robot-joint-states-rviz-laserscan/41065/18 "2026-06-20T11:25:29Z")
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.