Brownout Prevention?

[gerthworm]

We took the N'th degree approach this year, and it turned out relatively well:

-Monitor battery condition over time. Generate an adaptive model of the battery to determine how much current can be drawn from it before system voltage drops too low.

-Proactively estimate how much current draw a given driver command will pull from the battery. Involves knowledge of the physical parameters of the motor, and its present speed (measured via encoders)

-If the estimated current from the driver commands is sufficient to cause the system voltage to go too low, scale back driver commands.

The algorithm we used this year is still in trial - it kicked in plenty during competition, and we never browned out. However, we don't have good enough data yet to support that it was 100% necessary. We are working on a whitepaper (there are a few drafts of it floating around the internet), and will hopefully by end of summer have more data on the limits of what we came up with.

[chloe]

We actually came across this exact problem earlier this season. We tried a purely software approach by writing a "power controller" that essentially monitored all the current draw by all the systems (RIO, drivetrain, intake, outtake, compressor, etc), then the controller would dynamically modify the current flow to or from these systems depending on priority. The priority changes when the particular subsystem is being used, and takes into account the battery voltage.

The numbers we used were based on a lot of testing (we generated a linear regression model for current - speed of the drive train motors, for example, so we'd know how much current each motor would pull depending on speed) and didn't really seem to match up perfectly all the time to what the WPILib tells you about your max current. ie we would draw up to 200 amps sometimes for a second before the brownout sequence kicked in.

Obviously, it's not /perfect/ since the power methods in the WPILib are pretty noisy, so we had a switch on the driver station to turn the power controller on or off. We had a match at champs where it was pretty clear that the power controller was modifying currents -- and we never had a brownout during a match our whole season!

We had a very extensive flowchart for the logic and passed out flyers to people explaining how awesome it was :^)

[Al Skierkiewicz]

Originally Posted by Sir_Fenwick

Instead of running the compressor off of the PCM as is normal, run it instead off of a spike using 20 Amp breaker. Connect the spike directly to the power distribution board with a 20 Amp breaker, then connect the spike's PWM to one of the RoboRIO's relay pins. Connect the compressor to the spike, and with a little coding, the compressor will be unaffected by any brownouts. This is also completely legal. While this may not fix your problem, hopefully it mitigates the effects.

Yes this is legal but, the Spike has been discontinued from what I have been told.

[codedr]

+1 Everything Al said.

In every case of brownouts I investigated at champs, 100% of the time there was at least one of (A) loose battery cable, (B) loose connection at breaker, or (C) loose connection into the power distribution board.

If you can move the battery cable up and down, the bolt isn't tight.
If you can move the cable back and forth at the breaker, the bolt isn't tight.
If you can move the cable back and forth at the PDP, the bolt isn't tight.

The PDP connector is harder to reach because the covers.

[Michael Hill]

Was anyone brave enough to run a 6-CIM drive this year? If so, how frequent were brownouts? Also, what were the gear ratios and wheels used?

[GeeTwo]

Originally Posted by MrRoboSteve

One test I use is to put the robot, with battery and bumpers installed, on carpet. Put a sheet of paper underneath each of the corner tires, and pull it out. If the force needed to pull the sheet out varies dramatically, you need to balance the robot.

If all four corner wheels of a drop center robot carry significant weight, you don't really have a drop center. If you want the turning advantage of drop center, you either need more drop or to stiffen your wheel motion (e.g. inflate the wheels higher). Further, many 6-wheel drop-center robots are intentionally designed with the CoG offset from the center axle. This is most commonly done to improve stability when manipulating game pieces (pickup, launch or placement), but can also be used to help cross obstacles such as the step in 2012 or the defenses in 2016.

[Chris is me]

Originally Posted by GeeTwo

If all four corner wheels of a drop center robot carry significant weight, you don't really have a drop center.

This isn't true. Even if all six wheels on a 6WD drop touch the ground due to compliance in the wheels, dropping the center wheel increases the normal force that wheel carries. For situations like roughtop treaded wheels, this makes a big difference even if all wheels don't leave the ground fully. More drop and less contact from the outer wheels does mean better turning though (to a point).

[Al Skierkiewicz]

Alan,
Many of the terminals look like the one I included except for one difference. The part that normally would be a wire clamp is actually welded or mechanically held in place such that the screw becomes the only wire retention device. Those terminals where the retention device moves and the wire has no contact with the screw work OK, if one removes enough insulation to allow at least 1/8" to 1/4" or bare wire to extend beyond the retention clamp. When the clamp screw is tightened, it should produce a compression on the captive wire and the remaining wire will actually expand a little. This expansion will keep the wire from pulling out during vibration. If no wire is exposed, the vibration will actually push the wire out of the terminal (like squeezing the end of a banana).

[Joe Ross]

Originally Posted by Michael Hill

Was anyone brave enough to run a 6-CIM drive this year? If so, how frequent were brownouts? Also, what were the gear ratios and wheels used?

We used a 6 CIM drive, geared for 18fps, with 8 8" pneumatic wheels. The only time we had trouble was when we ran two practice matches back to back on the same battery.

[marshall]

Originally Posted by Joe Ross

We used a 6 CIM drive, geared for 18fps, with 8 8" pneumatic wheels. The only time we had trouble was when we ran two practice matches back to back on the same battery.

That seems awfully high... what were the gear ratios and how did you make the robot drivable at lower speeds? Anything fancy with the controls to limit speed?

[Ether]

Originally Posted by marshall

...what were the gear ratios and how did you make the robot drivable at lower speeds? Anything fancy with the controls to limit speed?

did you mean limit acceleration (or current)?

[marshall]

Originally Posted by Ether

did you mean limit acceleration (or current)?

Both really... I'm curious as to if they have done either... like I said, 18 FPS seems high.

[Chris is me]

Originally Posted by marshall

Both really... I'm curious as to if they have done either... like I said, 18 FPS seems high.

Perhaps you're thinking 18 FPS adjusted speed? With JVN's calculator, a free speed of 18FPS roughly corresponds to an adjusted speed of 14.5 FPS, which is fast but plenty reasonable.

[Joe Ross]

Originally Posted by marshall

Both really... I'm curious as to if they have done either... like I said, 18 FPS seems high.

We did nothing in programming to limit velocity or acceleration. Like Chris said, 18FPS is the geared speed, not the JVN calculator speed or the measured speed.

[marshall]

Originally Posted by Michael Hill

Was anyone brave enough to run a 6-CIM drive this year? If so, how frequent were brownouts? Also, what were the gear ratios and wheels used?

We did! No brownouts but we took the breaking the defenses a little too literal.

Originally Posted by Joe Ross

We did nothing in programming to limit velocity or acceleration. Like Chris said, 18FPS is the geared speed, not the JVN calculator speed or the measured speed.

Good to know. What was the JVN speed?