Long story short:
We have a 4 wheel drive system, using pneumatic wheels, a 3-CIM transmission on each side.
We are using Talon SRX controllers via CAN bus.
Big surprise (maybe not, in hindsight) - a lot of brownouts at Madera last weekend.
a) I have seen some notes here on Chief Delphi on brownout prevention algorithms - including the intention to write them up, but haven’t yet found any write ups.
b) Thinking of using isBrownOut() - does anyone have any good sample code?
c) Thinking of using the Talon current limiting mode. Any guidance on what parameters to use?
d) Thinking of using the Talon Ramp mode - Any guidance on what parameters to use?
FRC 3045 The Gear Gremlins
PS - yes, we also note that it’s worth doing a lot of electrical tidying - planning on doing that in advance of our next qualifier
I don’t condone/recommend doing this but as far as I know the way the rules are currently written you can make a solid argument that it would be legal to wire the roboRIO in parallel to the 12v supply from the VRM and remove the fuse from the PDB effectively powering the roboRIO from a regulated supply and eliminating brownout protection.
If someone can find a reason this wouldn’t be legal, let me know.
So ultimately what causes brownouts is the battery voltage draw that happens when you pull a lot of current. All of your methods listed do that in some form or another, but all create limitations.
What scenarios led to your brownouts? If you know a specific application was causing it (your drivetrain for example), what sensors do you have that measure performance of it (encoders, IMU, etc)
I’m going to assume a 6 CIM drivetrain to explain some of the parameters. 6 CIM drivetrains are a common root cause for brownouts because they can pull large amounts of total current from the battery while not individually being anywhere near stall. A CIM on a 40A breaker can pull 50A nearly indefinitely, but 6 CIMs at 50A each pulls 300A and will almost always cause a brownout. Drivetrains require the most torque (and thus the most current) in the following situations: turning, pushing, and accelerating.
Voltage ramp rate helps alleviate current draws from accelerations by limiting how quickly you can change the voltage command to the motor. This reduces torque available for acceleration and may cause some slowness/lag in how the robot feels when driving it. It also does not help in a prolonged pushing match as once the voltage scales up to its maximum, you’ll still face the brownout issues. Personally, I am not a big fan of voltage ramp rate, but how I set the values is to figure out how long I am willing to wait for the voltage to scale up to its maximum. 12V takes 1s from zero throttle to max (or 2s from -1 to +1). I usually like between 24-48 on this number but it is dependent on the inertia your robot has. I like using this for things that need a spinup time that have a hard time getting going like shooter flywheels. Especially when you use closed loop control that sends a huge error signal when your first start it up.
Setting the max current is my preferred solution. But it does have its drawbacks, mainly being if you set it once, you might be giving up a lot of overhead. You could budget 200A and set max currents such that everything that can be running at once will sum to less than that. But say you budget so you’re able to push a robot and rev up your shooter at the same time. If you’re not in a pushing match, you’d sure like to dump that extra current into your shooter if you can. For many teams, giving up that extra current as overhead is worth it. For here, I’d just put a limit of 40 or 50A on all of your CIMs and live with the added sluggishness when your first lay on the throttle.
The next thing is some level of current monitor. This is difficult to work in afterwards, but the idea is to have a monitor shut down or throttle back on nonessential during high demand times. Get in a pushing match and current starts to spike? This thing will be in charge of shutting down your intakes and compressor and limiting the drivetrain currents.
You also did not mention where you are seeing the brownouts. The common cases are listed below. Also do you have a shifter?
Pushing another robot (or the wall)
Accelerating from a stop
We (862) are running a 6cim drive train this year, with a shifter. Our low gear is traction limited (below max torque the wheels will spin, rather than the motors will stall). If you have a traction limited low gear, the fix for each of these cases is to ensure we are in low gear. We detect these cases in the following ways:
Pushing: watch for initial impacts (via accelerometer), watch total current over calibration for longer than calibrated time
Turning, if commanded turn is greater than calibrated
Accelerating from a stop, if our speed is below calibrated for longer than calibrated downshift
If you do not have a low gear, you need to detect using similar methods, but your response will be different:
Pushing: give up, better to fight another day and you will lose when you brownout anyway, just turn off the motors for a bit
Turning – this is a mechanical problem that cannot be easily fixed in software
, if you are geared too high that your drivetrain brownouts while turning and do not have a lower gear, the best you could do is reduce the max allowed turn to a safe level and force the driver to make slower turns
Accelerating from a stop, ramp rates will help here, with testing make your ramp rate as short as possible to prevent the brownout – note that this time will vary from a fresh battery to a the end of a match, either calibrate for the worst possible case or increase it as the battery weakens.
In a command based Java program, we found separating our shifter into its own sub-system, where we have a default command of “Autoshifter” works well (we have a fall back manual shifter if it fails to work well, but one competition in so far so good). The other command based approach would be use triggers (we started this way), but we found the logic was too separated and disabling triggers to be a pain (probably a better way, we will investigate more in the off season). Feel free to checkout our code on github.
The DS log files include the currents of every circuit from the PCP taken at 20ms intervals. You can view them in the Log File Viewer by turning on the plots. You could also write your own code to request and log the currents of your subsystems.
I would suggest you first determine what type of operation causes the system to enter into brownout prevention mode. At that point, you can use any of the techniques you’ve already listed, or you can continue to let the roboRIO’s generic prevention kick in.
You could also change wheels and wheel bases, I would perhaps go to an omni wheels on one end. What configuration are you in, if you are long and wide you might see many problems. We did in Northern lights, but on our practice bot back at home we changed wheels to have a omni’s on one end geared our boxes down slightly by about 20%. The omni’s made us agile, as well as helped with turn resistance, the 20% gear reduction helped with torque and pushing ability overall a great addition to our bot for North Star.
Lead acid batteries feature something called an internal resistance (one can model a battery as a voltage supply + resistor in series). This internal resistance is approximately .011 ohms when the battery is fully charged.
When large currents (100s of amps) are drawn from the battery, the voltage at the battery terminals can drop to levels that are too low to power critical parts of the robot such as the RoboRIO.
This isn’t to be confused with a blackout, where the current draw trips the main breaker and the entire robot loses power.
It sounds to me like this issue ties back to your drive setup. 4 pneumatics wheels, is likely a setup that simply resists turning. Adding a dropped center wheel can help, but is in most cases is quite a hefty change to be making at this point.
A few recommendations have been made for omni wheels. I like this. However I also wanted to throw out another very simple alternative.
I remember in 2016 seeing a handful of robots with pneumatic wheel drivetrains adding tape around the wheels to reduce the traction of particular wheels. I want to say they just wrapped the tires in duct tape (sticky side in) so that the rubber tread always had duct tape (pretty sure it was duct tape) between it and the carpet, reducing the friction. It isn’t going to slide as nice as an omni wheel. But given that it only takes a few cents worth of tape, and you likely won’t have to disassemble anything at all to try it out… perhaps this is a good place to start.
Edit: This isn’t the robot I was remembering, but it is another example. There is some talk of the tape trick in the comments below the picture. Looks like they did all 4 wheels. I would start with just 2 (front 2 or back 2) so that you keep some traction.
I watched a qual match and can tell you are having problems turning. It seems you have a longer than wide wheelbase which maked the turning issues worse. I think the fix to your brownout issues isn’t software, it’s mechanical. Here’s a couple ideas from simple to more complex:
Duct tape the front wheels to reduce the scrub (aka friction needing to be overcome to steer). This was not all that uncommon last year.
Larger gear ratio: takes away top speed but leaves more torque to overcome scrub.
Swap the pneumatic wheels with kit bot wheels on one end and omni wheels on the other.
If hardware solutions fail you, here’s my quick thoughts on your initial questions.
Not sure if these were mine or others… Regardless, 1736 did use an algorithm in 2016, where we dug into the physics of motors and batteries quite a bit. I can shoot you an unreviewed draft of our whitepaper if you’re interested.
This will tell you only if you are already browned out - information useful for recovery from a brownout state, but it won’t tell you if you’re about to brown out or not… In Java, the method should just return true or false, which can be used to trigger other logic.
We took a quick look at this in 2016. It looked like it could be promising, but I am fairly certain you have to tune the PIDF to get the current correct. Tuning a motor-current PIDF sounded difficult (constant current from a motor requires constant load, which is usually done with a dyno, which we don’t have). Proper tuning was important because we presumed:
Overdamped would make the drivetrain feel sluggish
Underdamped would have lots of overshoot, which could cause brownout anyway.
We also weren’t certain what that the control around current versus the control around voltage would change in the “feel” of operating the robot.
Given this, we decided to table the idea in 2016, but I am not yet certain if that was the right choice or not.
I’d be curious to see if other teams have had success with this or not.
This is one of the more common methods I’ve heard of. I’m not certain what parameters teams use for sure (although it’s definitely going to be dependent on electrical system design, robot weight & drivetrain, battery age, etc). I’d start at a ramp rate that gets you from 0 to full in half a second, then start ratcheting it down on a half-dead battery until you get issues. I’d suspect anything longer than that half-second ramp will start to make the drivetrain feel sluggish… but just a guess.
Team 2485 tried using current mode on CANTalons this year because we too have a 6 CIM drive train and were worried about browning out. We set the current limit at 20 A / motor, and it hasn’t seemed to substantially impact our acceleration, because once we are moving the current draw at full voltage quickly drops below 20 A anyway.
To tune the PID controllers on the talons we manually stalled the DriveTrain and tuned to that. The only issue we had was that the CANTalons only have 1/8 amp resolution, so we could not tune the PID loop as tightly as we would have liked.