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

[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).

[gblake]

Originally Posted by mschwab013

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

The OP didn't ask us to help change any existing designs, or help fix any existing problem.

I'll bet a nice lunch that you have some anti-brownout guidelines you would apply to a clean-sheet-of-paper, design-me-a-STEM-robot exercise. If you do, CD and the OP would like to learn them from you.

Blake