Do you struggle to understand how to use the Talon SRX controller effectively? What is PID and PIDF? How does feedback control work? What is feed-forward control? How are values of P, I, D, & F determined? How is the new Talon SRX "motion profile" feature supposed to be used?
If these are your questions, this blog is for you.
The material that follows will help you to better understand and implement motion control on your own robot. Interactive simulation models, implemented using SystemVision Cloud, are used to illustrate the concepts and allow you to interact with a variety of virtual motion control system configurations. You can copy these models, modify the selected motors, gear boxes, control parameters, loads, and inputs to tune the PIDF constants, predict responses, and troubleshoot issues.
Motors are used for controlling mechanical speed and position in a vast number of applications. Motors are a primary source of motion control, for example, in Robotics. The First Robotics Competition (FRC) is a popular robotics activity for high school students. This competition constrains the motors that can be used on robots, by rule, to those chosen from a fixed list (see my previous blog on FRC motor modeling).
In addition to motors, motor controllers are key to successful motion control applications. The motor controller makes it possible for each motor to be powered, from the main power source, but with variable strength. By sending signals from the main robot program to this intermediary, the motors can be manipulated to move forward or backward, at various speeds and to various positions.
FRC restricts the motor controllers that may be used to those from a fixed list. This blog will focus on the Talon SRX, available from Cross The Road Electronics, and the application of this versatile component for robotic motion control.
The Talon SRX Controller
The Talon SRX controller is the most sophisticated controller product allowed on an FRC robot. It is small, light, robust, and versatile. Included inside the passively-cooled package are power electronics, a powerful microcontroller, and CAN bus communications. There is also support for directly connecting sensor feedback, such as encoders and limit switches, to enable self-contained closed loop control. The onboard microcontroller is programmable, at a high level, via an application programming interface (API) that communicates with the device via the CAN serial bus. All of this makes it possible to offload sophisticated motion control functions entirely to the Talon SRX, reducing the compute load of the main robot controller (typically a RoboRIO for FRC). Using the Talon SRX for independent control also has performance advantages, since it has a dedicated real-time response loop of 1 millisecond, compared to a 20 or 25 millisecond loop on the main processor.
Talon SRX Motor Controller
The Talon SRX is programmed through a sophisticated API. This is well-documented in the Talon SRX Software Reference Manual. Programming examples are available for LabVIEW, C++, and Java. But programming is not the focus of this blog -- rather, the materials that follow are designed to help you understand, derive, and troubleshoot the PIDF control constants that are an integral part of the software controls.
CIMple Box With Dual CIM Motors
For this example, we are modeling a commonly used CIMple Box gearbox, fitted with two CIM motors. Our example also uses a quadrature encoder with 250 codes per revolution (CPR), which attaches directly to the output shaft of the gearbox, via a shaft that extends between the two motor mounting points.
This assembly can be seen in the schematics that follow by looking for this pattern -- two motors attached to a gearbox. The CIMple box gear ratio of 4.67:1 is used here. But this can be changed when you copy and edit any of the circuit designs.
SystemVision Model of CIMple box and two CIMs
Another popular gearbox is the Toughbox Mini. It is the standard gearbox available with the FRC kit-of-parts (KoP) chassis. The Toughbox Mini is available with the following optional gear ratios: 12.75, 10.71, 8.45, & 5.95. The default is 10.71.
The designs on this blog are live -- you can interact with them without leaving the page. Watch this short video to see how it works.
The simplest control that can be used with a Talon SRX is open loop, using the PercentVBus mode. In this mode, an input devices, such as a joystick, is used to simply send a command to the Talon SRX to set the output voltage at the specified percentage of the maximum voltage bus (typically ~12 Volts). The set point is a number between -1 and +1, representing the bipolar output range (e.g.., -12V to +12V).
The following simulation shows this scenario. The motor_cmd_percent_bus signal is stepped from 0 to +1 and then back to 0. The resulting voltage is applied to the motors, the motors deliver power through the gearbox to the load, and both the speed and position of the load can be observed.
Notice that a full speed (motor_cmd_percent_bus = 1.0) the motor RPM is 1.0621k, or 1062.1. This number is useful to us, as it represents the maximum motor speed that we can expect.
You will notice, if you change the loading (watch the video above to see how), that the maximum speed is not affected by the load -- only the time it takes to get to full speed. If the gear ratio is changed, however, the maximum motor speed can change significantly. See here for a version of this design with a Toughbox Mini gearbox.
The next step in our progression is to use feed-forward control. This is only slightly more sophisticated than the previous example. In this configuration, the input mode changes from PercentVBus to Speed. The desired speed of the load, set_speed_rpm, is scaled by the value of the feed-forward gain, F-gain, before applying it to the Talon SRX output. It is important, however, to fully understand the assumed units for all of the quantities used in this calculation. This can be tedious to keep straight, but paying attention to these details will significantly reduce downstream headaches!
The Talon SRX software reference manual provides a detailed description for calculating the F-gain Feed-Forward constant, taking care to use the correct units (see section 12.4.2. Velocity Closed-Loop Walkthrough – Calculating Feed Forward).
In this example, the quadrature encoder we are using produces 250 codes per revolution (CPR). From section 17.2.1 in the reference manual, we see that the native units for this encoder are 4 X CPR. The maximum velocity that we measured using our first experiment, above, was approximately 1062 rotations / min.
For the F-Gain calculation, velocity is measured in change in native units per TvelMeas=100ms.
( 1062 Rotations / min) X (1 min / 60 sec) X (1 sec / 10 TvelMeas) X (250 codes / rotation) X (4 native units / code)
= 1770 native units per 100ms
Now let’s calculate a Feed-forward F-gain so that 100% motor output is calculated when the requested speed is 1770 native units per 100ms.
F-gain = (100% X 1023) / 1770
F-gain = 0.5780
Let’s check our math, if the target speed is 1770 native units per 100ms, Closed-loop output will be (0.5780 X 1770) => 1023 (full forward).
This is convenient, as we can now directly ask the motor to go to a specific speed. Notice, though, that the accuracy of this method relies on our prediction that motor output speed is a linear function of the motor_cmd_percent_bus signal. We can see, though, by comparing the set_speed_rpm to the load_speed_rpm signals, that this prediction is only approximate. Otherwise, these signals would be identical.
This discrepancy is because feed-forward control is an open loop form of control -- the encoder information is not used here to actively correct the motor_cmd_percent_bus signal in order to bring it into alignment with the set_speed_rpm signal. In the next step, we will add feedback to improve the performance.
In this step, we add feedback control, to achieve a better match between the speed set point and the measured result. The structure of all feedback control systems is similar: a set point is compared to a feedback value (by subtraction) to determine the error (difference). This error is used to drive the actuator in a way that will hopefully bring it closer to the set point (drive the error to as close to zero as possible).
Look for this pattern in the diagram below. The feedback speed, load_speed_NU is subtracted from the set point, set_speed_NU, to produce the error signal. The error signal is, in turn, processed by three different math operators: a simple multiply by P_gain, integrate and multiply by I_gain, and differentiate and multiply by D_gain. These three terms are then added to produce the PID response to drive the motor. But before they are applied to the motor, the feed forward F_gain term, from above, is added to the PID terms. But this is all still in the native units internal to the Talon microcontroller, in which full scale output is represented by a value of 1023. So, before applying this to our model, which expects a value between -1 and +1, we need to divide by 1023 (i.e.., multiply by 9.775E-4).
Remember, now, that all of this is happening inside the Talon SRX, as software functions running on the embedded microcontroller. All of the green signals in this diagram (and their respective function blocks) represent the functionality of this embedded software. This model is convenient, as it lets us try different values of the PIDF gains to verify that we will get the results that we want. This can be difficult and/or time consuming to do with a real robot. If you have tried this with a robot, you will know that if you make the P_gain value too small, nothing happens. If you make it too big, the robot can oscillate wildly.
The Talon SRX software reference manual provides a detailed description for determining in the proportional gain (P-gain) constant, taking care to use the correct units (see section 12.4.3. Velocity Closed-Loop Walkthrough -- Dialing Proportional Gain).
Suppose given our worst error so far (~150 native units per 100ms), we want to respond with another 10% of throttle. Then our starting p-gain would be…. (10% X 1023) / (150) = 0.682
Now let’s check our math, if the Talon SRX sees an error of 150 the P-term will be 150 X 0.682 = 102 (which is about 10% of 1023)
P-gain = 0.682
Notice from the simulation below, though, that even a P-gain value as high as 20.0 does not cause oscillations.
Position closed-loop control is similar to speed control, with the exception that feed-forward is not used (only PID). This is because while voltage level is a good predictor of speed, it is a terrible predictor of position. Feed-forward can still be useful for position control, but it requires careful coordination of the setpoint of both speed and position (see Motion Profile below).
In the example below, notice that the value of F_gain is 0.0, so there isn't any feed-forward contribution to the control. Notice also that the feedback signal is load_pos_NU (position of the load in native units), verifying that our control loop is a postion control system.
Notice that the speed of the load, load_speed_nu, ramps up to ~400 counts per 100 ms and then back down to 0.0, as the position setpoint is reached. Compare this to the position setpoint, set_pos_nu, and you can see why feed-forward is not well-suited for direct use in position control. In the next section, though, we will see that if we provide two coordinated setpoints, one for position and one for speed, that we can achieve better control for a motion profile.
Often it is desirable to control the position of a load according to a desired profile. This can include scenarios such as pointing a camera in a certain direction or moving a robot to a predetermined position on a field. The Talon SRX has built-in support for this function. See Motion Profile for detailed documentation on the API and how itworks.
To make motion profiles easy to use, the Talon SRX provides an operating mode called Motion Magic (see Motion Magic for documentation and examples). Motion Magic leverages the motion profile functionality by providing a higher level API that generates, behind the scenes, the detailed motion profile needed to accomplish a motion control task.
Notice that a motion profile requires a setpoint profile for both the position and velocity (see the signals set_pos_revs and set_speed_rpm, respectively, below). If it is possible to anticipate the motor speed setting required to achieve a certain position, then the control algorithm can efficiently take advantage of feed-forward control. This takes away some of the burden of feedback control. You can think of it as using feed-forward for gross tuning and feedback for fine tuning. This approach is efficient, responsive, and stable.
It only takes a bit of physics knowledge, however, to understand that the speed and position of an object are NOT INDEPENDENT! Therefore, these two profiles -- speed and position -- must be carefully coordinated.
The developers of the Talon SRX have provided an Excel spreadsheet to help make this process easier. The spreadsheet allows specification of some parameters of the desired motion profile and then produces a complete, coordinated profile that can be plugged into the motion profile functionality of the Talon SRX.
Motion Magic works slightly differently. The equivalent of the spreadsheet is built into the firmware of the Talon SRX. You only need to specify the maximum velocity, maximum acceleration, and position setpoint. The Talon SRX, when using the motion magic mode, will then internally generate both the position and speed profiles. The motion magic function also gracefully handles changing of these parameters on-the-fly!
The value of F-gain should be the same as in the feed-forward speed control example, as the input is a speed profile.
The values of P-gain, I-gain, D-gain, however, will not necessarily be the same as in the closed-loop position control example, even though the setpoint is a position profile. This is because the feed-forward control helps make it easier for the feedback control to do its job. You may find that you get good results by lowering (or perhaps increasing) the other PID gains. Use SystemVision Cloud simulation to experiment with different PID values and their effect on performance and stability.
The simulation below uses the motion profile (sequence of corresponding position, speed, and duration values) from the example available on github. The speed profile is provided by the piecewise-linear source speed_profile, resulting in the signal named set_speed_RPM. The corresponding position profile is provided by the piecewise-linear source pos_profile, resulting in the signal named set_pos_revs.
Notice that the signals set_speed_rpm and load_speed_rpm match well, even though the load_speed_rpm signal is not used in the feedback control. This is because the position and speed are physically related. This physics relationship is built into the generation of the profiles (in the excel spreadsheet or in motion magic), making it possible to approximate the control of position by setting the speed! This is a relatively sophisticated control strategy and part of the reason that the Talon SRX is so useful.
Toughbox Mini Gearbox
The Toughbox Mini is also a popular gear box, as it is the standard gearbox on the AndyMark Kit Chassis.
See below for a version of the motion profile design, from above, but with a Toughbox Mini gearbox instead of a CIMple Box: