The joints are position/velocity controlled. Here’s the documentation for the arms that mentions all the actuators and encoders used:
Here are the ROS messages used to control the 3-DOF arms:
- Velocity control: str1ker/msg/VelocityCommand.msg at master · 01binary/str1ker · GitHub
- Position control: str1ker/msg/PositionCommand.msg at master · 01binary/str1ker · GitHub
This is the firmware that carries out the commands:
Velocity commands go straight to the motors/actuators, and position commands go through a PID controller:
In the video the joints were velocity-controlled in open loop, because I lost some of the encoders in the chaos before the shows, and didn’t have time to install others. RQT was used to play sine waves through all 3 joints of each arm by typing in math expressions for various members of the ROS messages sent once per second (1 Hz):
If the encoders were hooked up and the joints were position-controlled, then the Motion Planning plugin in MoveIt framework would be responsible for creating the smooth curves, and the PID controller would be responsible for tracking them.
I wrote my own motion planning plugin:
It uses Quintic splines for smooth motion between the start and end “keyframes” output by MoveIt: start from current robot state and end from Inverse Kinematics plugin.
The last missing piece (the middleware between MoveIt executing the motion plan and the firmware receiving ROS messages) is the Robot Hardware class.
When MoveIt sends off commands they are routed to a ROS Control, and ROS Control connects to a custom implementation of RobotHW class for the particular robot that’s going to carry out the commands. Here’s mine: