URDF Real robot joint_states, RViz LaserScan

ROSDS Support
1

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
image1490×812 83.4 KB

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:

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:

  <!-- Wheel Left -->
  <link name="left_wheel">      
    <visual>
        <origin rpy=/>
        <geometry>
            <mesh filename="package://ros2_urdf_project/stl_models/wheel_left.stl"
            scale="0.001 0.001 0.001"/>
                  
        </geometry>
        <material name="white"/>
    </visual>

    <collision>
        <origin rpy="1.5708 0 0" xyz="0 0 0"/>
        <geometry>
            <cylinder length="0.025" radius="0.0325"/>
        </geometry>
    </collision>

    <inertial>
        <origin rpy="- -" xyz="0 0 0"/>
        <mass value="-"/>
        <inertia ixx="1.106e-05" ixy="0" ixz="0"
                 iyy="1.106e-05" iyz="0"
                 izz="1.848e-05"/>
    </inertial>
  </link>

  <joint name="wheel_left_joint" type="continuous">
    <origin rpy="0 0 0" xyz="0 0 0"/>

    <child link="left_wheel"/>
    <parent link="left_wheel_axle"/>

    <axis xyz="0 1 0"/>
    <limit effort="1000" velocity="1000"/>
  </joint>
  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:

  <link name="laser_scan_frame">
  </link>

  <joint name="laser_scan_frame_joint" type="fixed">
    <origin rpy="0 0 0" xyz="0 0 0.029"/>
    <parent link="Lidar"/>
    <child link="laser_scan_frame"/>
    <axis xyz="0 0 0"/>
  </joint>

Would appreciate any advice.
Thank you.

Best,
Ninad Mehta

2

@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.

3

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:

    • Make a static TF link between world and odom frames at the same position ans orientation.
    • Make sure that the parent frame id for the laser link frame is base_link.
      Only when you have ROS2 Navigation, the laser visuals with stay consistent at one place, right now you are not implementing any ROS2 Navigation, so what you see is right.

I hope my answers helped you.

Let me know if you still need any clarifications.

Regards,
Girish

4

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?
    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

5

We are working on this problem. Please allow us a few hours more to solve it and give you a solution

6

Yes. Thank you for looking into it.

7

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
    image1197×409 86.7 KB
  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.

8

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

1 Like
9

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:

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:

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
namespace31920×1047 129 KB

namespace4
namespace41920×1044 138 KB

namespace1
namespace11920×1046 135 KB

namespace2
namespace21920×1044 137 KB

Below is a terminal snippet as well. Says Incompatible QoS

[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

10

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?

11

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:

  <!-- Wheel Left -->
  <link name="left_wheel">      
    <visual>
        <origin rpy="0 0 0" xyz="-0.032 -0.080 -0.0325"/>
        <geometry>
            <mesh filename="package://ros2_urdf_project/stl_models/wheel_left.stl"
            scale="0.001 0.001 0.001"/>

            <!-- <mesh filename="file:///home/user/ros2_ws/install/ros2_urdf_project/share/ros2_urdf_project/stl_models/wheel_left.stl" -->
            <!-- scale="0.001 0.001 0.001"/> -->
                  
        </geometry>
        <material name="white"/>
    </visual>

    <collision>
        <origin rpy="1.5708 0 0" xyz="0 0 0"/>
        <geometry>
            <cylinder length="0.025" radius="0.0325"/>
        </geometry>
    </collision>

    <inertial>
        <origin rpy="1.5708 0 0" xyz="0 0 0"/>
        <mass value="0.035"/>
        <inertia ixx="1.106e-05" ixy="0" ixz="0"
                 iyy="1.106e-05" iyz="0"
                 izz="1.848e-05"/>
    </inertial>
  </link>

  <joint name="motor_left" type="continuous">
    <origin rpy="0 0 0" xyz="0 0 0"/>

    <child link="left_wheel"/>
    <parent link="left_wheel_axle"/>

    <axis xyz="0 1 0"/>
    <limit effort="1000" velocity="1000"/>
  </joint>


  <!-- Wheel Right -->
  <link name="right_wheel">      
    <visual>
        <origin rpy="0 0 0" xyz="-0.032 0.080 -0.0325"/>
        <geometry>
            <mesh filename="package://ros2_urdf_project/stl_models/wheel_right.stl"
                  scale="0.001 0.001 0.001"/>
            <!-- <mesh filename="file:///home/user/ros2_ws/install/ros2_urdf_project/share/ros2_urdf_project/stl_models/wheel_right.stl" -->
            <!-- scale="0.001 0.001 0.001"/> -->
        </geometry>
        <material name="white"/>
    </visual>

    <collision>
        <origin rpy="-1.5708 0 0" xyz="0 0 0"/>
        <geometry>
            <cylinder length="0.025" radius="0.0325"/>
        </geometry>
    </collision>

    <inertial>
        <origin rpy="-1.5708 0 0" xyz="0 0 0"/>
        <mass value="0.035"/>
        <inertia ixx="1.106e-05" ixy="0" ixz="0"
                 iyy="1.106e-05" iyz="0"
                 izz="1.848e-05"/>
    </inertial>
  </link>

  <joint name="motor_right" type="continuous">
    <origin rpy="0 0 0" xyz="0 0 0"/>

    <child link="right_wheel"/>
    <parent link="right_wheel_axle"/>

    <axis xyz="0 1 0"/>
    <limit effort="1000" velocity="1000"/>
  </joint>

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:

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!

12

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

13

Thank you, @girishkumar.kannan. I have emailed you all the files.
Appreciate your help with this!

Best,
Ninad Mehta