Attached is an example Labview implementation of a Talon SRX Feedforward and Feedback Motion Profile on an arcade drive robot. The purpose of the example is to help someone understand the various settings, parameters, and unit conversions needed so that a target motion profile (in meters/sec) can be sent to the Talon SRX’s controlling the drive motors.
This is a great paper (you should upload it to the white papers section of CD as well)! I do have one question after reading through it: On page 3, you explain the F gain value and how it’s related to the Talon’s measured throttle. You say that “For the left side of the robot at full throttle, the Talon SRX reported a speed of 1210” but I don’t see 1210 anywhere in the image. It sounds like you logged the data to a file and grabbed from that. Can you explain where you got 1210 for the throttle? Is it the “Velocity” measurement in the image? If so, was the velocity still positive 1210?
You’re welcome. Just to be clear, my paper does not cover the “buffered” motion profile capability of the Talon SRX. We did not get a chance to try that before releasing this paper, although Omar from CTRE did provide the essential parts of an example during the latter part of Beta testing. I know he plans to have a separate user manual for that feature soon.
In our case, we did log data to a file. Time-stamp, throttle value, and speed as measured by the Talon SRX. I wanted to see how everything behaved. I took the image for illustration when I was building the document. The easiest way for you to get that value is to drive at full speed and then refresh the web page. If you don’t have the room to do all that at once, you can grab the logging VIs from our Marvin T code post or build your own.
There is one error in that document that I need to fix and repost. I said to take the cycles per rev from the spec sheet and multiply by 4. This is not correct. The help screen in labview for the configuration VI is confusing. It says:
“Allows setting the Counts Per Rotation of the Talon SRX’s connected quadrature encoder. This is also referred to as the ‘Number Encoder Lines’, ‘Counts Per Revolution’, and ‘Cycles Per Revolution’.”
It turns out that the number you send to the config should be Cycles Per Revolution (128 for my Grayhill encoder). The Talon SRX multiplies it by 4. To me, this help text includes contradictory terms. Cycles do not equal counts or lines.
Now, you would rightly say “Dang didn’t he notice a 4 to 1 error?” Well, unknown to me at the time, the encoder in our gearbox is not on the wheel shaft. It has a 4.14:1 ration with the wheel. Divide by 4 and multiply by 4.41 and you don’t notice much So in the end, my number ended up being 565 fed into the Config VI. Beware a shifting transmission! This ratio will probably change with gear shifts, but you can just change it on the fly in code depending on the status of the shifter.
The end performance of this approach is striking. Tuning the PID gains was really easy (just as the Poofs claimed in their presentation). Very tolerant of values (you see my round numbers…no fine tuning needed). This controls our wheels to within a tenth of a rotation or less every single time.
We have a VI in Periodic Tasks that logs data to a file. We logged throttle setting and speed as reported from the Talon SRX status VI. We drove the robot at full speed (joystick full forward) down a hallway keeping it straight as much as we could, and then looked at the data log. We looked for areas of data where throttle and speed were close to constant and close to maximum and then took those as the data pairs. Since motors behave differently going forwards or backwards, it is typical that for driving straight, one side will be at a higher throttle than the other.
The important part is to get a relationship between throttle and speed. The process assumes the relationship is linear, and with today’s speed controllers that is true. So, theoretically, you could pick your data pair anywhere along the line. Choosing a point near maximum throttle, however, will reduce your error resulting from variations that happen during the measurement process.