So, today we (finally!) got Talon SRX motion profiling with Pathfinder-generated trajectories working acceptably well on our practice bot.
We noticed a couple of things during the process, and were wondering if other teams have had similar experiences:
Measured wheel diameter does not seem to correspond exactly to “effective” wheel diameter. That is, we measured our 4’’ Colsons at ~3.85’’, but empirical tests (i.e. having the robot run a linear trajectory and measuring distance traveled) indicate that they’re “effectively” closer to ~3.75’’. This may be due to wheel slippage, but our profiles are pretty tame. Perhaps it’s due to wheel compression? We don’t quite know.
Similarly, measured wheel base size does not seem to correspond to “effective” wheel base size. That is, when we generate profiles with our measured wheel base width of ~24.5’’, the robot notably under-turns - the “effective” wheel base width for turning correctly seems to be closer to 30’’. We think this is due to wheel scrub, but again, we’re not quite sure.
After empirically “fudging” the aforementioned quantities, the profiles seem to work quite well. Have any other teams done similarly?
(We have, indeed, verified that the profiles are being followed reasonably well - so this is not due to poor control loop tuning or unachievable profiles)
This might be related in a way to rolling radius. Have you tried running the bot on both compliant (e.g. carpeted) and non-compliant (e.g. hardwood or concrete) flooring to see what difference that makes?
Understeer was an issue for 1736 last year for our low bar high goal due to our high scrub drivetrain with encoders only. We added a gyro with a P gain loop to maintain heading and the result was night and day when it came to repeatability of our path plan. We also had a fudge factor adjustment for distance traveled due to pneumatic wheels to get distance to within inches. With a known wheel diameter, the factor should be much closer to 1, but I wouldn’t be surprised if you still need a small adjustment to get actual measurement close to your theoretical calcs. Other tweaks like preloading your gear mesh at start of the path can help a little also also.
We’re using a NavX similarly this year (simple P loop to keep us driving straight), but only employ it in teleop. It’s not clear to me how we would integrate it with running motion profiling on the Talons.
We had left and right velocity control loops for our 6wd. Then we add the output from our gyro P loop to one side (+ 1 rpm) and subtract from the other (-1 rpm) causing it to turn in the direction the heading is off. Main issue is this can cause some overall error in distance by the end of the path. More complicated implementations account for this, but we stopped here and added to our path as needed based on what happened on the field.
Yeah, we’re not using our velocity servo to follow paths - we’re using the Talon SRX motion profiling, which runs a position servo with a velocity feedforward. All of it is run on the motor controllers (you send them a buffer with the whole profile and then the motor controllers execute it), and I don’t see any obvious way to add gyro feedback to it.
We started out using the Talons built in motion profiling, but decided (after some testing) to use the talons in closed loop velocity mode and run our motion profiles on the RIO, so we could add in gyro compensation.
Can you elaborate on what you did? If the Talons are in closed loop velocity mode, are you only following the velocity portion of the profile and not the position? Are you somehow modifying the velocity setpoint based on the position and gyro error?
What resources would you recomend to learn more about this (Control theory?)? I know there is a lot on Chiefdelphi but it is all very spread out. I have a lot of questions.
V_setpoint is the velocity setpoint we send to the Talon SRX controlling the drive motors (in velocity control mode). Alternatively you could multiply the V_desired term by a gain to do unit conversion and get a voltage to command.
For learning more about this stuff, there are two categories of resources (and approaches in general) that I find useful. The first is looking at literature from the industrial motion control community. For example, see this article about using feedforward with PID. Industrial motion control in this context is basically using COTS servo drives, PID controllers, and trajectory generators to do (generally single input, single output) feedback control of industrial processes. This community skews towards the practical and intuitive without getting too math-heavy. This makes it a good match for most FRC applications where students don’t already have a strong controls background. The Talon SRX documentation also falls into this category and is must-read, IMO.
The second category is “formal” control systems literature, more akin to what you would learn in a college class. There are many textbooks and online resources for this. You’ll read about “classical” control systems in the frequency domain (Laplace and Z transforms, Root-Locus plots…eww, etc.) and also “modern” control systems in the time domain (state-space, pole placement, LQR, etc.). There is a ton of material to cover, so absent a mentor who is fluent in this stuff and/or a very motivated student with a strong math background, it’s easy to drown before you can swim. The upside of this approach is you learn some very powerful tools that can help you design complex control systems (multi input/multi output, nonlinear systems, etc.) with confidence that they will behave as expected on real world hardware.
Motion profile and path planning is a bit of a separate beast, and you can find resources in the robotics and video game communities. Some buzzwords to search for: “Motion profile”, “Pure pursuit”, “Motion planning”, “Path planning”, “A*”, “spline”
So, your acceleration feedforward cascades to the setpoint of a velocity loop? That seems a bit counterintuitive to me; it seems like it would create unwanted interactions.
A point of personal curiosity: how much practical difference is there between velocity integral error and position proportional error (presuming your velocity setpoints do actually integrate to your desired position)? The only difference ought to be due to sampling rate and roundoff error; but those can be substantial.
Our path follower feedback controller and our Talon SRXs use different reference frames. The profiles we were using were generated with respect to the center of our robot, so our path follower generates a desired linear and angular velocity for the robot as a whole. The velocity setpoints for the left and right sides of our drive are derived from these two quantities (using a model that attempts - with varying levels of success - to compensate for the significant wheel scrub we had with 6 Colsons and very little drop). So Kv in our path follower is not quite the same as Kp on the Talons (when we are turning).
I’m still having trouble understanding, however, the motivation for having your acceleration feedforward add to the velocity setpoint, as opposed to directly adding to the voltage output. It seems that would result in it interacting in undesirable ways with the velocity control loop - if you command an acceleration and this increases the setpoint itself as opposed to only the feedforward, the velocity loop’s error will also increase and you’ll have additional output from its attempt to compensate, which seems like it would behave less-predictably.
In practice our velocity controllers didn’t have an integral term, so the unpredictability wasn’t too bad. But in an ideal world, we would have done it as you described and just manipulated feedforward to avoid the interaction altogether.
The only way I know of to use velocity PIDF on the Talon and adjust feedforward on the fly (without affecting setpoint) is by changing gains, which would require sending a separate CAN frame at a very high rate. We were already pushing 80% utilization on our CAN bus after carefully choosing frame rates for each Talon, so we didn’t really have the overhead to do this.
Using profile mode would have been preferable, and we may go that direction next season depending on the requirements. However, that also tightens the timing requirements on the RoboRIO side to ensure we don’t starve the controller (doable, but was out of scope for 2017). With velocity mode, missing a timing deadline by a few tens of milliseconds isn’t that big a deal; your motor will hold a constant velocity setpoint, which is usually not far from the desired behavior, and we can account for this during planning. With profile mode, missing a timing deadline causes an underrun and the Talon will attempt to hold the last position, which could cause a dramatic change in speed or even a reversal.