Joint Command Overview
Baxter's arm controls flows through on four layers of operation:
1) User Code running via workstation or SSH (Python Joint Control or Joint Trajectory Action Server or your custom interface)
2) Joint Control Listeners via ROS topic (on Baxter's internal Gentoo Linux PC)
3) RealTime Motor Control Loop (the highest priority process on Baxter's internal Gentoo Linux PC)
4) Joint Control Boards (microcontrollers attached to each arm joint)
The bottom three layers (2-4) are not accessible for user modification because they run on the robot itself and its microcontrollers. Baxter does have three joint control modes for the user to choose from at the top level: position, velocity, and torque control. Each controller has a subset of Motor Controller Plugins associated with them.
By default, all the joint control publishers and subscribers provided by the Baxter SDK run at
100Hz, but can be run up to a rate of
800Hz reliably. See the links for more detailed explanations.
Joint Command Timing
Start to finish, a joint is commanded from the user's python code. This message flows over the ROS network and is picked up by the Joint Control Listeners which store the command for it to be retrieved asynchronously by the RealTime Motor Control Loop once per
1KHz). The command is then sent to the Joint Control Boards (JCB) and executed within the same
1ms timeslot. On the next 1ms cycle, the joint position and spring deflection sensor are read and transferred back to the Joint Control Publisher. The result is read over the ROS network by the user's code. The total timing looks approximately as follows:
1.6ms for the Command to publish over ROS to the Joint Controller over rostopic (via network)
1ms for the Joint Controller Listener to command the Motor Controller (MC), running an async real time loop of 1KHz
1ms for the MC to transfer to the Joint Control Board (JCB) and evaluate the command
1ms for the JCB to read the updated status and give a response to the MC
1ms for the MC to report back to the Joint Controller Publisher
1.6ms for the Joint Controller to publishing the State back over rostopic (via network)
~ 7.2ms total round trip ROS User Publisher to ROS user Subscriber
RealTime Motor Controller
The RealTime Motor Control loop on the robot executes over the course of
1ms, and approximately
700us of this loop is used on average. Occasionally you may find an overrun of the RealTime loop around
100us. This overrun usually does not propagate forward to other cycles because the next loop will likely take
700us. To verify this you can look at the diagnostics messages via "rostopic echo /diagnostics", and look for the "Realtime Control Loop".
The RealTime Motor Controller has plugins that run simultaneously with joint commands. These are Collision Avoidance and Detection, Gravity Compensation and Spring Hysteresis/Crosstalk Compensation. On top of these plugins, when Baxter's cuff pressure sensor is activated, Zero-G enables, allowing the arm to be passively back driven. Upon releasing the cuff, the motor controller returns to the controller it was using previously.