How do you design a robot that doesn't brownout?

[tahmid0517]

We've had problems with out robot in 2015 browning out. It used 4 cims on the drivetrain and 2 cims on the elevator. How would we design a robot in 2016 so that we don't have anymore brownout problems?

[GeeTwo]

There are more details in this thread, but the bottom line is that you need to monitor your battery usage and actually brown out your motors (reduce the voltage you give them) rather than black them out as the RoboRIO will. The RoboRIO can monitor battery voltage and current draw on each circuit (that is, each large motor) through the CAN from the PDP. Probably the simplest thing that will reduce the problem is not to run all of your big motors hard (with high torque) at the same time. For shooting and lifting mechanisms, it may become more common to stretch a spring (or other energy storing mechanism) over a longer period of time to achieve a faster lift or throw than it has been in the past, especially if a team desires to shoot game pieces while engaged in heavy traffic.

[Chris is me]

Originally Posted by tahmid0517

We've had problems with out robot in 2015 browning out. It used 4 cims on the drivetrain and 2 cims on the elevator. How would we design a robot in 2016 so that we don't have anymore brownout problems?

6 CIM motors, moderately loaded, without real defense or much resistance, really shouldn't cause brownouts. I would take a careful look at your systems and see if there are some glaring inefficiencies anywhere, like a binding gearbox, gear ratios that are way too low (low in reduction / high in speed), etc. It sounds like a mechanical problem.

[Jon Stratis]

Originally Posted by Chris is me

6 CIM motors, moderately loaded, without real defense or much resistance, really shouldn't cause brownouts. I would take a careful look at your systems and see if there are some glaring inefficiencies anywhere, like a binding gearbox, gear ratios that are way too low (low in reduction / high in speed), etc. It sounds like a mechanical problem.

I'll echo this... We've run at least as much motor power without issue before.

Without seeing your robot in action, I can't be sure... but taking a shot in the dark, were you stalling your elevator motors to hold the totes up? Because if you were stalling 2 CIM motors at full power for any extended amount of time, especially if you were driving around at the same time, that could cause some significant power issues. Motors don't like to be stalled, and when stalled they pull an amazing amount of current - enough that they can drop your voltage enough to cause the roboRio to turn everything off. You should always try to design your systems to avoid stall conditions - mechanical brakes, limit switches to tell you when to stop, that sort of thing.

[Greg McKaskle]

Could you please give more details about your robot and post a picture or copy of the DS log file? I'd also like to know if this happened regularly, or when you had a bad battery -- in addition to a juice-hungry robot.

Greg McKaskle

[Zebra_Fact_Man]

ITT: smart people that need more info to diagnose your robot problems.

I echo the gearing sentiment. Sounds like not enough torque coming out of your transmissions.

[GeeTwo]

A bad battery that you could have gotten away with in 2014 could have caused the problem. Perhaps we'll write a general battery monitor class that tracks the voltage and total-current over time so we can track battery health as well as provide the needed info for brownout management.

[Jared Russell]

Originally Posted by GeeTwo

Perhaps we'll write a general battery monitor class that tracks the voltage and total-current over time so we can track battery health as well as provide the needed info for brownout management.

This is a great idea, and I recommend it to any team that has the time to implement it. I've done this in the past (2012 and 2013) and you can learn a lot about your robot and batteries by watching what happens to voltage over time. Pretty soon you'll have a pretty good idea of what nominal should look like on your robot, and be able to spot anomalies (bad batteries, binding transmissions, damaged motors) just from looking at the data.

Actually implementing an intelligent load-shedding algorithm is pretty tricky to do - you don't have that much time or voltage overhead before the built-in load shedding kicks in, and depending on your robot's particulars there may not be that many things you can safely shed without affecting your ability to play the game. But just knowing what the general profile of energy usage looks like will give your drivers a great intuition for which "button combos" are okay and which aren't.

[gblake]

Folks,

I understand the notion of figuring out why a past robot browned out (that is what motivated the OP to ask about 2016), but notice that the OP asked for advice for designing a new/next robot that won't brown out for any reason, and didn't ask for help diagnosing the reason their 2015 robot had trouble. They might have already diagnosed and fixed their 2015 robot.

Blake

[mschwab013]

Originally Posted by gblake

Folks,

I understand the notion of figuring out why a past robot browned out (that is what motivated the OP to ask about 2016), but notice that the OP asked for advice for designing a new/next robot that won't brown out for any reason, and didn't ask for help diagnosing the reason their 2015 robot had trouble. They might have already diagnosed and fixed their 2015 robot.

Blake

How can you change a design to fix a problem if you don't know what is causing the problem?

[Doug Frisk]

Originally Posted by mschwab013

How can you change a design to fix a problem if you don't know what is causing the problem?

You can ask for best practice and bad practice so you know what to avoid and what to do as far as construction and programming. That's how.

The most common factor in brownouts is motors under stall or near stall loads. So, what can be done mechanically, electronically and programmatically to address this?

[mschwab013]

Originally Posted by DareDad

You can ask for best practice and bad practice so you know what to avoid and what to do as far as construction and programming. That's how.

Wouldn't the best practice be to identify the problem to ensure the same mistake won't happen again? Finding problems and identifing how to fix them can be a great learning experience.

[Michael Hill]

We are budgeting several things, not only cost, but weight, power, and air pressure. I've come up with several states (and will add/remove as necessary to fit next year) as well as what subsystems will be on during those times. (See attachment). I then calculate the total amount of power draw during those times to calculate the voltage drop. I've also thrown in stuff that can tell me if I'm going to pop the main breaker. The model I'm using is somewhat crude and not exact, but it's in the ballpark (I hope). It will tell us if there are any states we should be particularly concerned about, and whether or not we can do things like run the compressor.

[aciarniello]

Originally Posted by Michael Hill

We are budgeting several things, not only cost, but weight, power, and air pressure. I've come up with several states (and will add/remove as necessary to fit next year) as well as what subsystems will be on during those times. (See attachment). I then calculate the total amount of power draw during those times to calculate the voltage drop. I've also thrown in stuff that can tell me if I'm going to pop the main breaker. The model I'm using is somewhat crude and not exact, but it's in the ballpark (I hope). It will tell us if there are any states we should be particularly concerned about, and whether or not we can do things like run the compressor.

Michael,

I like this concept, its a good way to think through a match--particularly in a game like 2015, where the procedures are fairly consistent.

Do you plan to use this to do load-shedding programmatically? Or is the plan more to use it in terms of training your drive team on what actions can occur simultaneously?

[Michael Hill]

Originally Posted by aciarniello

Michael,

I like this concept, its a good way to think through a match--particularly in a game like 2015, where the procedures are fairly consistent.

Do you plan to use this to do load-shedding programmatically? Or is the plan more to use it in terms of training your drive team on what actions can occur simultaneously?

Ideally we won't have to do any load shedding, but we'll see how that goes. An easy target is selectively running the compressor. From a non-FRC robot programmer's point of view (i.e., mine), it would seem trivial to cut off the compressor when, say, I activate manipulator 2 and turn it back on when manipulator 2 deactivates (ignoring any effects from the momentary in-rush current of the compressor motor).