ROS Discussion Group, Dec 2 - Follow-up

[Sergei Grichine]

Hi All,

Just a clarification on some topics I was involved in yesterday:

1. The unrelated parameter for lowering the Nav2 Local Costmap down to the ground level is:

      map_vis_z: -0.19 # place local costmap at the floor level (a wheels radius below base_link)

Sorry for wasting your time on that, sometimes it is hard to remember what you've solved a year ago. The file is here: nav2_params.yaml

2. My understanding is that the "odom" frame is appearing in the system's TF (transform tree) as a result of some node publishing appropriately formed tf2_msgs/msg/TFMessage
 message to one of the topics: "/tf" or "/tf_static". So are other frames. The parent-child relationships is defined by those messages. If in doubt, ask our Overlords: https://chatgpt.com/s/t_69308308f76c81918ab791cb8584bf89 - or have a boxing match with them.

3. It is Localizer's job to relate map and odom frames, they are the only ones allowed to publish those messages to /tf topic. Publishing such relationship to /tf_static can be done for debugging, but not for normal operation. SLAM Toolbox, AMCL, Map Server and Cartographer normally do that. If you see your robot jumping - there is some competing publisher.

4. My robots all have the following section in their "robot_core.xacro" file and never define a relationship of the odom frame to any robot's frame (i.e. never mention odom frame in URDF). You can easily figure out who's who's papa in that tree:

    <!-- ********************** ROBOT BASE *********************************  -->
    <!-- The coordinate frame called base_link is rigidly attached to the robot root body.
         It is recommended to choose the robot waist as its root body.
         The base_link can be attached to the root in any arbitrary position or orientation;
         for every hardware platform there will be a different place on the base that provides an obvious point of reference.
         Note that REP 103 [1] specifies a preferred orientation for frames.
         See https://www.ros.org/reps/rep-0120.html#base-link -->

    <link name="base_link">
        <visual name="baselink_visual">
            <origin xyz="0 0 0"/>
            <geometry>
                <sphere radius="0.04"/>
            </geometry>
            <material name="red"/>
        </visual>
    </link>
   
    <!-- ****************** ROBOT BASE FOOTPRINT ***************************  -->
    <!-- The base_footprint is the representation of the robot position on the floor.
         The floor is usually the level where the supporting leg rests, i.e. z = min(l_sole_z, r_sole_z) where l_sole_z and r_sole_z are the left and right sole height respecitvely.
         The translation component of the frame should be the barycenter of the feet projections on the floor.
         With respect to the odom frame, the roll and pitch angles should be zero and the yaw angle should correspond to the base_link yaw angle.
         Rationale: base_footprint provides a fairly stable 2D planar representation of the humanoid even while walking and swaying with the base_link. -->

    <!-- Define the center of the main robot chassis projected on the ground -->  
    <link name="base_footprint">
        <visual name="footprint_visual">
            <origin xyz="0 0 0.01"/>
            <geometry>
                <!-- box size="${wheel_offset_y * 2 + wheel_thickness} ${wheel_offset_y * 2 + wheel_thickness} 0.02"/ -->
                <cylinder radius="${wheel_offset_y + wheel_thickness + 0.03}" length="0.01"/>
            </geometry>
            <material name="shadow_grey"/>
        </visual>
     </link>

    <!-- The base footprint of the robot is located underneath the chassis -->
    <joint name="base_joint" type="fixed">
        <parent link="base_link"/>
        <child link="base_footprint" />
        <origin xyz="0 0 -${wheel_radius}" rpy="0 0 0"/>
    </joint>
   
    <!-- ********************** ROBOT BODY *********************************  -->

    <joint name="chassis_joint" type="fixed">
        <parent link="base_link"/>
        <child link="chassis_link"/>
        <origin xyz="${-wheel_offset_x} 0 ${-wheel_offset_z}"/>
    </joint>

    <!-- CHASSIS LINK -->

    ......

4. It is VERY easy to see my robots in sim, if you already have a machine with ROS2 Jazzy or Kilted. Seeing them in action allows examining every aspect of the live, working, configured environment (messages, TF trees, code). I am pretty sure that there are dozens of similar examples on github (Turtlebot 3 comes to mind).  See https://github.com/slgrobotics/articubot_one/wiki#2-try-my-robots-in-gazebo-simulation-browse-the-code-no-robot-hardware-needed

BTW, bug/issue reports, pull requests and suggestions are very welcome.

And a side note. It's become a tradition to spend most of the ROS2 SIG meetings time on topics not directly related to ROS2. Yes, we are all friends and everyone has a story to tell. Should we  rename the SIG group accordingly then? Any other ideas?

Best Regards,

-- Sergei

[camp .]

> And a side note. It's become a tradition to spend most of the ROS2 SIG meetings time on topics not directly related to ROS2. Yes, we are all friends and everyone has a story to tell. Should we  rename the SIG group accordingly then? Any other ideas?

    Nope, it's the "ROS Discussion Group," and yes, we might spend 20 minutes discussing capacitors, power supplies, Linux, and other issues, but in robotics, you have to know everything.    :-]]]

- Camp

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVOEksOg-HyUUrn1rA0dwPDrOUup8WnKkc4NWT1ZQLqfLA%40mail.gmail.com.