I am extremely confused about the relationship between the /joint_states topic, Joint State Publisher, Joint State Controller, Joint Command Interface, and Joint State Interface.
From my understanding, the Joint State Interface automatically(?) receives the real-time joint states from all the joints (defined in the URDF file of the robot) in the real-life robot or simulation. The Joint State Interface then automatically(?) publishes this data to the Joint State Controller as well as the numerous controller plugins (ex. effort controller) according to their target joints.
The controller plugin receives the joint state published by the Joint State Interface (?), compares the joint state to the setpoint, and outputs to its Joint Command Interface (after calculating PID), which publishes this output data to the target joint and moves the target joint (which is assigned in the transmissions tag of the URDF file) to reach the goal/setpoint (which the Joint State Interface receives data about and publishes to the controller plugin, repeating the process).
The Joint State Controller, which received the joint state published by the Joint State Interface, uses the Joint State Publisher (?) to publish the joint states for each joint (?) to a topic called /joint_states. The Robot State Publisher then receives the JointState.msg of all joints from this /joint_states topic and publishes it to the TF, so all links and fixed and non-fixed joints are correctly connected to one another in the TF tree.
I think my understanding of the /joint_states, Join State Publisher, Joint State Controller, Joint Command Interface, and Joint State Interface is wrong, especially in the (?) parts. Can anybody explain their relationship to me and tell me what I am wrong about?
I am very sorry for the lengthy question.
Thank you in advance.
I will do my best to answer your question,
First of all let my say that I totally agree that the naming may be confusing. Here I will try to clarify the meaning of each of these terms.
The terms you mentioned are:
- joint_states topic
- Joint State Publisher
- Joint State Controller
- Joint Command Interface
- Joint State Interface
Now, just for a moment, let’s imagine the same terms without the prefix “Joint”, we have:
- states topic
- State Publisher
- State Controller
- Command Interface
- State Interface
Next lets differentiate between state and command.
A command in an instruction or a value that you want to be executed. Hope this term is clear, so far.
A state is the current value of something. For instance the state of a rotary joint could be the current angle, the state of a linear actuator could be a distance, but the state could also be a temperature of something. It it just the current value that you get by using a sensor that measures that value.
The distinction between state and command is a very important one. Let’s re-arrange the above list and split between states and commands:
- states topic
- states publisher
- states controller
- state interface
Now let’s explain one by one:
state topic is the ROS topic that publishes the current reading of a sensor.
state publisher refers to a ROS publisher that publishes the messages with the sensor readings into the state topic.
states controller this is tricky because a this isn’t really a controller but a broadcaster of current states. It is in charge of reading the sensor data stores in variables by the state interface (defined below) and translate that data into a ros message and publish it via the state publisher into a state topic.
state interface is the software part that can interface (it can communicate to) the hardware. A state interface communicates with a sensor device. It contains the neccesary code (normally via imported libraries) to read out data from the device and store them into variables so that the state controller (which in reallity is a state broadcaster) can transmit them as described above.
I hope this clears your doubts.