Our 6-CIM drive (geared for about a theoretical 16 fps top speed in high gear) has a nasty habit of browning out the control system unless the battery is in absolute top shape.
We’re using velocity control with CAN Talons, which have a supported voltage ramp rate feature. Could anyone, based on their own experience, give a ballpark estimate of an appropriate ramp rate for avoiding brownout under these conditions?
Also, have people noticed if the amount of voltage ramping required to avoid brownouts makes a noticeable impact on system behavior otherwise (i.e., that would require us to re-tune our control loops)?
We had the same problem this year. We are geared for 18.5 fps. We could hardly accelerate, but we solved it by simply making sure all of the wiring connections are tight and the wires coming from your battery to the pdp are as short as possible. Our connections to and from the pdp and main breaker were super loose and the crimps on the 6 gauge were not great. After fixing this we had no more problems.
Make sure your connections are tight! You should not be able to wiggle the 6 gauge attached to the breaker. The tighter the better.
Also, I may or may not have almost run over a mentor while implementing voltage ramping on the talons. It doesn’t just ramp up, it also ramps down, so when I tried to stop it kept going and took 5 seconds to ramp down from 100%. :ahh:
My 2 cents: If you need voltage ramp to stop you from browning out, you’re toast. You’ll brown out during your very first pushing match.
Be sure that whatever ramping you do doesn’t stop you from being able to make the robot stop moving on a dime. This was a big challenge with ramping code; it usually ramps down too…
I would really just not worry about it, maybe a very small ramp, and if it becomes an issue swap a CIM for a mini on each side.
I accidentally put a really small number into the talon’s voltage ramp function not realizing that that was the allowed change in voltage per second. So it ramped really slowly… It didn’t brown out though
Be sure that whatever ramping you do doesn’t stop you from being able to make the robot stop moving on a dime. This was a big challenge with ramping code; it usually ramps down too…
I would really just not worry about it, maybe a very small ramp, and if it becomes an issue swap a CIM for a mini on each side.
Swapping two of our CIMs for mini-CIMs did cross my mind.
There’s no obvious supported way to do this with the Talons in velocity closed-loop control mode (if there is, it’s pretty well-hidden in the documentation). Also, don’t you mean current limit?
I assume you’re talking about browning out in high gear when accelerating from a stop? The best solution would be to start in low gear and auto-shift to high at speed. Avoiding browning out during acceleration is half the reason we’re shifting.
Auto-shifting seems a bit beyond the scope of what our team is able to do right now, unless there’s some very simple implementation of it that we’re not aware of.
(It seems to me that a simple “if current speed is above X, shift to high gear” is probably not robust enough, we don’t want to rapidly oscillate between gears - it also might run into problems with our gain scheduling between high and low gear. I suppose you could put in a bit of hysteresis and have the shift-up point higher than the shift-down point, but it still seems to me like there’s probably additional fanciness needed to keep the thing well-behaved.)
Edit: I’m also not sure our spread is ideal for auto-shifting; our low gear caps out at 5.4 FPS (measured), while our high gear caps out at 15.1 (also measured).
Yeah, your instinct is right. The simplest effective implementation is a speed to up-shift and a lower speed to down-shift. Our implementation is a bit more complex*, but even the simple implementation would solve your problem. Upshifting at 4 or 5 fps would help. It wouldn’t make you much faster, but it would help your current draw a lot and eliminate brownouts. It’ll also save your batteries. We drained batteries like crazy in the few days when we didn’t have auto-shifting yet and were stuck in high.
Anyway, you can voltage ramp if you want, but by taking that approach, you’re giving up some performance.
*Our ideal speeds are 10 and 21, so a little faster than yours. Our implementation sees the robot hit a speed, then waits a fraction of a second to ensure the robot doesn’t go back. So if we hit 5 fps, after some amount of time (a couple hundred milliseconds, I think) if the robot stays over 5, it upshifts. Downshifting is the same at 3.5 fps.
If we’re not happy with voltage-ramping, we’ll give this a shot - thanks for the advice. Do you do anything special to detect the case of “pushing against something?” Seems possible that the speed thresholds would catch that automatically, but maybe current sensing would be more robust.
driveSubsystem.leftMaster.getSpeed() is the speed of the left, driveSubsystem.rightMaster.getSpeed() is the speed of the right, and UP_SHIFT and DOWN_SHIFT are constants calculated to be 5 and 4 fps respectively.
You could clean up your logic there with math.min (or math.max), and we probably want to not call the subroutine if we’re already in the correct gear, but yes, this is the idea.
We’d also have to get rid of our current joystick-rescaling functionality that’s tied into our gear shifting, but that’s easy enough.
This is correct, so we’ll have to change that - but we should probably carry on technical discussion of our own code on basecamp rather than on Chief Delphi
While working on our auto shifting code, we had to sort out some issues we encountered. Even though having two thresholds - one for high gear, one for low - would solve most of these issues, a few still had to be fixed:
Depending on the placement of your encoders (or whatever method you use to get your drivetrain speed), you may also need to calculate the speed by using the ratio provided with each gearing.
We didn’t want to shift too rapidly, so we introduced a threshold timer. By waiting for a certain amount of time before shifting to another gear, we can avoid this issue.
In addition to that, a moving average prevents any fluctuations from affecting our results too much; we found that around 3 samples works well (although we may want to test this further). Note that this will be used with the timer, so anything too large will increase the time it takes to shift.
Lastly, we are using absolute values to allow shifting when going either direction. Getting the absolute values of the speeds may cause problems (shifting when turning) if you aren’t doing it after you get the average.
We implemented autoshifting today with the discussed features - hysteresis between the two thresholds, and a 250ms buffer time before shifting after crossing a threshold.
The results are quite nice. Overall, I’d say I’m pretty surprised at how easy it is to implement a decent autoshift - and we are no longer murdering our batteries, which is a huge relief. Thanks for the help, everyone.
