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 PartQuest Explore, 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.

Background

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.

 PartQuest Explore 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.

Live Designs

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. 

Simple Open-loop Control

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.  

Feed-Forward speed control

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.

PIDF Feed-Forward + Closed-Loop Speed Control

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.   

PID Closed-Loop Position Control

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.

PIDF Feed-Forward + Closed-Loop Motion Profile Control (plus Motion magic)

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 PartQuest Explore 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:

PartQuest Explore provides a great design platform for sensor signal conditioning circuits, as well as for verifying sensor systems in the context of their external applications. A key feature PartQuest Explore that makes this possible is the ability to create a “just right” model of the sensor itself. This can be a detailed physics-based model that captures both the internal behavior and the electrical interface characteristics of the sensor, to accurately represent its interaction with the signal conditioning circuit. Or it can be a “graphical model”, based on transfer functions or abstract math-blocks, to be used for performance and stability assessment of the system in which the sensor is placed. The IEEE Standard VHDL-AMS hardware description language covers the broad range of modeling capability needed to represent the sensor, the analog and digital aspects of the signal conditioning circuit, as well as the complete mechatronic system.

LVDT Sensor Signal Conditioning Circuit Design

An LVDT, or Linear Variable Differential Transformer, is a translational position sensing component. It is essentially a transformer with position-dependent variable coupling between its primary and two secondary windings. These are passive components, so active signal conditioning is required to use them. This includes an oscillator to drive the primary winding and a demodulator to convert the secondary output signals into a variable “DC” voltage level proportional to the mechanical displacement.

Macro Sensors™ PR-750 LVDT Series

The schematic below shows a complete LVDT sensor system. In the upper left, a force source, mass, damper and spring represent a simple dynamic mechanical load. The core of the LVDT (highlighted in light green) is attached to the connection point that represents the load position. The user can specify the LVDT windings’ electrical parameters (Rp, Lp and Rs), as well as its sensitivity and mechanical stroke length. Inside the model, these values are converted into the fundamental physical equations that define the electrical behavior of the device.

Position sensing system with LVDT and signal conditioning circuit

The design focus is on the demodulator circuit, which includes two full-wave rectifiers, two low pass RC filters (highlighted in light blue), and a differential amplifier circuit. The simulation results show the sensor’s output response (orange waveform) resulting from a 70 mm step of the underdamped mechanical load (green waveform).

The unfiltered outputs of the rectifiers (magenta and blue waveforms) clearly illustrate the variable coupling that occurs, between the constant amplitude primary input signal and the two secondary winding outputs, as the core position changes over time. The low pass filters must be designed to remove the 2.5 kHz oscillator signal, but pass all the important frequency content of the actual mechanical position, such as vibration modes that need to be sensed or the overshoot and ringing seen in this example.

You can view the “live” version of this LVDT design here. You can move waveform probes around and look at any signal in the system, or make a copy of this design and modify/add/delete components and run new simulations to see the effect of those changes. You can also view the open-source VHDL-AMS model of the LVDT, or any other component used in the design.

Temperature Sensor in a Thermostat Control System

An alternate method for sensor modeling in PartQuest Explore is to graphically assemble a set of transfer-function or math-block models, to represent all the behavior of the device that is relevant to the system design objective. A graphical model of a temperature sensor is shown in the schematic below, where a thermal connection point (red net) on the left can be attached to any thermal network to read its temperature. The electrical connection point (black net) on the right drives the sensor output voltage and current into any external signal path or conditioning circuit.

“Graphical Model” of a temperature sensor

All of the intermediate math-blocks operate on generic continuous quantities, and model the sensor’s fundamental static and dynamic characteristics. From left to right, this includes a low-pass filter with user specified pole frequency set to 0.1 Hz, which operates on the instantaneous value of the sensed temperature. The filter output goes to a gain stage, with gain value set to 0.01. This defines the sensor’s static sensitivity as 0.01V/degree-C. A fixed bias value of 0.1 is added with a summing block, to set the output voltage level to 0.1V at temperature 0C. The limit function keeps the output open-source voltage between 0.0V and 1.5V, and the resistor provides an effective 1.5kOhm output impedance to complete this sensor model.

PartQuest Explore provides a library of “Technology Converters”, like the temperature-to-continuous-quantity and the voltage-from-continuous-quantity converters used in the graphical temperature sensor (the left-most and right-most blocks, respectively). These converters allow our math-block models to operate on any physical nature or type of quantity, such as current, pressure, torque, magnetic flux, etc., and therefore support graphical modeling of almost any type of sensor. To learn more about using these converters, please see this blog and associated video.

The same temperature sensor is included in the thermostat controlled coffee cup heater shown in the schematic below. (Note: This schematic is "Live", you can move probes around to see other signals and click on components to see their parameter values). This closed loop system also has an analog amplifier stage, a digital thermostat with a voltage threshold or trip-point, a clock to set the sample-rate and a flip-flop to preserve the heater switch state between samples. A 12V automotive battery provides power to the heating element when the heater switch is closed. The resulting heat-flow enters a thermal network that models the thermal behavior of the coffee-cup itself. This includes conduction and radiation heat transfer to the ambient environment, as well as heat capacitance.

Automotive coffee cup heater with thermostat temperature control

The light blue waveform shows the thermostat output state that controls the heater switch, as it regulates the temperature of the coffee cup (red waveform). Inside the temperature sensor model, the effect of the low-pass filter can be seen by comparing the instantaneous temperature value (green waveform) and the filtered output value (magenta waveform). The smoothing and delay effect of this filter, which represents the internal time constant or detection speed of the sensor itself, can have a significant impact on the overall loop temperature regulation.

In the waveforms shown in the graph below, the red waveform is the coffee cup temperature as shown in the design above, with the sensor bandwidth set to 0.1 Hz, and the thermostat temperature sampling period set to 1 second. The blue waveform corresponds to the use of a faster sensor (1 Hz bandwidth) and faster temperature sampling (0.2 second period). This type of “in context” assessment of system performance can be very helpful in choosing the right sensor for a particular application.

Compare temperature regulation for fast vs. slow sensor

You can view the “live” version of this Coffee Cup Heater design here. As with the LVDT example discussed previously, you can interact directly with the live design, or make a copy and modify it as desired, then run new simulations to see the results.