base_link?

[camp .]

    ROS question... how is the base_link being transmitted, or any of the links and joints for that matter? It is not a topic being messaged. I note that a its origin is a "description" file... the URDF Xacro. The basic sam_bot* example launches '/joint_state_publisher_gui  and /robot_state_publisher' (nodes) which then publishes '/joint_states and /robot_description' (topics). Are the links and joints in the "state" publishers and what's the relationship with /tf and /tf_static?

Thanks,

Camp

* Setting Up The URDF

https://docs.nav2.org/setup_guides/urdf/setup_urdf.html

[Michael Wimble]

Don’t mistake topics with transforms, even though transform data is actually transmitted via a topic (or pair of topics, actually).

It’s robot_state_publisher that does what you’re asking about. Here’s what robot_state_publisher does, basically:

• It reads the given text file passed to it by the launch file. This is often a xacro file that was preprocessed by the program ‘xacro’ (a macro processor for XML files) to create an XML text file that has certain preprocessor variables replaced. 
• It finds the ‘robot’ element within the text file. Within that it:
• Finds all the ‘material’ elements.
• Finds all the ‘link elements’.
• Finds all the ‘joint’ elements. For each joint, it:
• Picks up the paren link name.
• Picks up the child link name.
• If there is no parent link name, it recognizes it as the single, root node of the directed, acyclic graph (DAG) forming the URDF tree.
• It creates a publisher for the topic ‘robot_description’ and publishes the text file it was handed by the launch file.
• It creates a subscriber to the “joint_states” topic. When it receives a new message (from, say, the joint_state_publisher node), it publishes a corresponding dynamic tf message. This, of course, usually occurs for your joints that don’t have the type ‘fixed’, like your wheel joints that typically have the type ‘continuous’.
• It creates a publisher for the static transforms. These are are the joints that have the type ‘fixed’. It publishes those static tf transforms just once.

So, any information about ‘base_link’ as a ‘link’ is contained in the ‘robot_description’ topic which can be read by, e.g., rviz2, to display the physical model.

Any fixed ‘joints’ are published once as tf transforms via the  'tf_static' topic.

Any non-fixed ‘joints’ are published as tf transforms over the ’tf’ topic as new joint_state messages are received, usual from the joint_state_publisher node (although you can also publish that data from other means, such via a GUI when you are experimenting setting up a robot).

Base_link has two meanings, as do many things in a URDF. There is base_link as a ‘link’ which describes a physical model. It just sits in a text message, published to the ‘robot_description’ topic. It happens to be in the XML format. Nodes that want to see base_link as cylinders, boxes, etc. and part of a DAG (directed, acyclic graph) read the ‘robot_description’ topic, parse it as an XML file, but their own tree form and do what they want with it, such as show it as a 3D model or use it to compute collision boundaries.

Base_link is also the name of a frame, which part of the tree of ‘frames’ used in ROS. Frames, or joints  are published as tf messages via either the tf or tf_static topics. Joints are just a connection between two frames and a transform just indicates the pose of one frame relative to another frame.

The topic ’tf_static’ is usually published once by the robot_state_publisher node. It only needs to be published once because, well, it’s static. The relationship between static frames (joints of type ‘fixed’) cannot ever change over time.

The topic ’tf’ is published as dynamic state changes for joints, especially as wheels move or servos move. 

tf_static can also be published via a static transform node publisher in a launch file, or by code you write, etc.

tf can also be published by nodes that monitor sensors or actuators (motors), if the relationship of some frame changes with respect to some other frame. If you have a robot arm that moves, someone has to publish a tf message to update the new position of all the parts of that arm relative to other links.

--
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 on the web visit https://groups.google.com/d/msgid/hbrobotics/1469967938.3933002.1729377104235%40mail.yahoo.com.

[camp .]

Thank you, Mike!

Super answer. It will take a while to digest. Here's my current URDF MockBot rebuilt from scratch: https://photos.app.goo.gl/HCheb3ubo2mmUt2V7

- Camp

Yahoo Mail: Search, Organize, Conquer

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/461E4012-1E8D-42AA-85A5-0BB2BE5297F2%40gmail.com.

[Michael Ferguson]

It's probably best to think not of the "links" being transmitted, but rather the "transformation between links":

 * Your URDF defines how the joints and links are connected. In ROS 2, we publish this to the /robot_description topic (in ROS 1, it was a parameter named /robot_description, but there is no longer a shared parameter server between nodes in ROS 2).

 * /joint_state_publisher_gui is used in simulated environments to publish the joint angles for non-static joints on the /joint_states topic. On a real robot, the drivers usually publish that topic, if you use something like Gazebo for simulation then Gazebo would publish /joint_states.

 * /robot_state_publisher uses the URDF + /joint_states to publish /tf and /tf_static - if you echo this to the terminal you will see that it is an array of various transforms - for instance, one entry might tell you how to transform from "base_link" to a "camera_link" coordinate frame, and another element in the array would tell you how to transform "camera_link" to "camera_link_optical".

 * /tf and /tf_static data can then be used by the TF2 library to transform data between connected frames.

As for difference between /tf and /tf_static - there are transformations that do not change (for instance, most cameras have a "camera_link" in the normal X-forward, Z-up orientation, and then also have a "camera_link_optical" frame which is Z-forward orientation). In the original TF, this static transformation would be published at say 100hz alongside the actually changing values based on /joint_states. In TF2, static frames are moved to a separate topic, which is latched (or "transient_local" in ROS 2), meaning that it does not need to be republished at any rate - thus saving bandwidth.

-Fergs

[Tony Pratkanis]

I believe robot_state_publisher uses /joint_states to publish tf frames from the joint states + URDF file.

Sent with Proton Mail secure email.