My team is thinking for an off season project making are drive train be velocity controlled instead of open loop control during telop. Do any teams do this. If so why did you
We do it, and if you’re going to, I highly highly highly highly recommended using CANTalon SRXs for your motor controllers. They have built-in PID velocity control and really well written documentation and tuning guides (can’t link on mobile, sorry), and the internal loop operates at a kilohertz, meaning you just have to use a PD loop. If you do decide to use them, don’t use their internal unit scaling, just write your own converter method and use that.
Team 1595 did that this year and I (the driver) loved the results. Past robots I’ve driven had issues when doing precise movements (ex: aim for goal) because you wouldn’t quite have enough power to turn until you turned too much. PIDs on the speed fixed this problem. In addition, the transition from this to include automatic shifting (if you run them) is fairly easy.
Did you use CAN Talon SRX motor controllers built-in PIDF?
If not, what did you use?
Seconding autoshifting as a great way to accelerate/deccelerate faster while using less battery power.
Note that an aggressively-tuned velocity loop combined with a 6 CIM drive and a 2-speed shifter can easily result in brownouts when commanded to a stop from full speed in high gear.
We’ve managed to avoid the worst of this so far this year (immediately shifting to low gear when the setpoint is below some threshold helps a lot here), but we’ll likely be looking at some combination of setpoint and voltage ramping to avoid this in future iterations.
Check this out.
This is a really sensible approach, and the math is fairly simple, but I’m rather uncertain how smoothly it would integrate into CANTalon-based PID control - my only immediate thought for how to do it is to constantly have our code calling configPeakOutputVoltage(), and it seems possible to me that this could lead to problems due to a) lag between the main loop on the RIO and the much faster loop on the talons or b) the talon not responding well to the constant config function calls (I believe I recall reading that this can cause issues).
Yeah we did. With the software manual providing examples, it was quite easy to do.
Interesting. We also run 6 CIMs and have had no issues with brownouts. Granted, we do as you describe and when the setpoint becomes 0 shift to low gear, but still we have had no issues.
From SRX manual:
9.3. Current Limits Talon SRX has the ability to limit the output current to a specified maximum threshold. This functionality is available in all control modes.
I previously thought you had to tune the PIDF in current control to limit current. Has anyone tried this?
What speed is your high gear?
Try disabling the downshift functionality, and then command a dead stop from full speed in high gear.
Our top speed in high gear is ~17 fps (measured), or 19fps (theoretical, from the WCP website). We found during tuning that a sufficiently high P gain would result in the aforementioned situation causing either a comms brownout or a 40A breaker trip (we did not have enough time to see which was actually occurring).
Nope. I did this on our gear intake without any PID.
So far, we have only used computer closed-loop controls on the drive train for autonomous and semi-autonomous activities (e.g. hanging a gear), letting the driver close the loop in teleop. Even with this limited use, I concur with Noah back in post 2 that using the SRX is easier to program, faster, more reliable, and quite flexible. Budget was the only thing which kept us from moving all of our closed-loop controls to SRX this year. Smartly using the SRX for your feedback loops can also reduce and organize your wiring.
We’ve just switched to velocity control on our drivetrain. Doing so has noticibly improved how well our robot strafes in mecanum mode.
1 Like
Thanks for all the replies. Has anyone seen any down side to moving to velocity control.
My other question is what do teams like 254, 1114, 2056, and other top level teams do for there drive code. They always seem to have amazing driving. I figured most of it was the drive but am wondering if some of it come from there drive code
Have you looked at Cheesy Drive?
Interesting. It looks like there code does constant turning regardless of throttle and everything is open loop. Am i reading that correctly?
Mostly opportunity cost. As an example, if you give up so much time to it that you don’t get your autonomous routine coded, you lose auto points. You also become vulnerable to a lost encoder or broken encoder wire; this can be mitigated with defensive programming and backup modes.
Yes, they do special things with drive code. As I understand it, 254 invented a distinctive joystick paradigm to control swerve. [SNIPED!] Also, I believe that they publish their code after each season, so you can go dig into the details.
Probably even more important though: they have the resources to build a full practice field and drill the drivers intensely and with high fidelity.
I spent some time thinking about this, I’m not sure if I have a good answer. The limiting algorithm, as designed, is set up to sit between a voltage command from a driver or PID output, and the actual value sent to a motor controller.
There could be some potential for limiting the speed command at the input of the PID as a proxy for limiting the output, but how you do your limiting depends on your PID gains… probably pretty nasty.
Jeremeylee’s answer is probably the better approach - just tell the talon how much current you’ll allow it to pass, that should help prevent excessive current draw. You could potentially update this number much more slowly than a max-voltage number (as max current draw depends on battery conditions, but max voltage applied additionally depends on motor speed).
Buyer Beware - I have not tried this. Yet.
Velocity control adds a bunch more corner cases. What happens if you are trying to slide along a wall? Hit another robot? Brown out? Blow a fuse? It took 971 ~3-4 years before we felt comfortable enough to switch.
A lot of that is practice. 1678 was running tank drive for a while. On 971, we run a variant of ChesyDrive with velocity control. We open source it every year, though it hasn’t changed in a couple years. It makes our robot drive like a car. We find that that is intuitive to our drivers.
254’s 2016 code is essentially arcade drive where the turning is scaled by the throttle.