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 (http://www.chiefdelphi.com/forums/showthread.php?t=137231), 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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[garyk]

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?

A simple contributing factor may be crud on your battery terminals & leads (pigtail). This afternoon one of my students at 668 was adding pigtails to a new battery and scrounged some sandpaper from the school's wood shop with which to clean them to bright shiny metal. At 100 amps each hundredth of an ohm is going to cost you a volt.

[matthewdenny]

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.

A mechanical problem is likely, but it could also be a symptom of bad batteries. Take a look at how you charge and store them.

[Nemo]

Let's say you already plan to take the above advice to avoid the various electrical and mechanical problems that can turn your battery power into waste heat. What remains?

You can use bigger gear reductions. That causes your elevator/arm/drive to have slower output speeds, while the motor itself has a faster speed. When the motor is turning faster, it is drawing less current. Drawing less current means not dropping your battery voltage and not hitting the brownout limits.

There are some cases when a bigger gear reduction will actually cause your mechanical output speed to be faster. This is the case when a smaller (faster) gear ratio would put the motor so close to its stall torque that its speed approaches zero.

Fast speeds sound great (and look great on the field when they actually work), but gearing things to go insanely fast isn't always the smartest thing for several reasons:
1) Your mechanical system often won't even start moving until you give it a significant percentage of full power, at which it jerks into fast motion instead of starting up smoothly.
2) You lose the ability to make small, controlled movements because of #1; you're either at nearly full power or nothing
3) You drain your battery a lot faster because it uses more current
4) Any sort of mechanical binding or electrical losses or battery issues can quickly bring your system from "running ok" to "not working at all" since you're pushing the limits pretty hard
5) With the combination of #3 and #4, you often get diminished performance in the tail end of matches as your battery runs down. That's especially painful if endgame is really important.
6) Your motors are producing more heat since they are taking so much more current. This can diminish performance of motors and make them burn out after a while.

You can also make sure your drive train is able to turn well generally. If you have lots of lateral traction in a skid steer drive, and the wheel base is long compared to the track width, you're going to pull a ton of current while turning. And that is compounded if the drive is geared to go really fast already. There are a variety of interesting things to look at in the drive to make it turn well. Drive design is a good topic to research on CD. Since the drive is going to have the most power going to it, making sure it's designed properly is probably the single biggest thing to look at if you don't want to brown out your robot.

[IKE]

A simple contributing factor may be crud on your battery terminals & leads (pigtail). This afternoon one of my students at 668 was adding pigtails to a new battery and scrounged some sandpaper from the school's wood shop with which to clean them to bright shiny metal. At 100 amps each hundredth of an ohm is going to cost you a volt.

I would echo this with ensuring all connections are good, but especially your high current connections. Loose leads can lead to small, but important resistance elements. At the 100 AMP quoted above, the a 0.01 Ohm connection would have 1 Volt drop. During initial acceleration, you can pull as much as 500 amps (momentarily) from a 4 CIM drive. this same 0.01 Ohm would be 5V or thus get you a brownout.

As and LRI, I got to diagnose a few of these last year:

A few were loose PD connections (hard but not impossible with new PD board).
Loose main break connections (every year, even good teams will have loose connections here because it is easy to over-torque and break these as well).
Loose Battery cables at the battery terminals.

Poor battery/robot connection. Often this is either the springs being bent/loose in the connector, or damage on the terminals. Damage often comes from using alligator clamps to charge batteries, of shorting leads on batteries to test systems (this practice can lead to pitting/crud on the connection which shows up as resistance under high loads.

Besides these, the other times I saw brownouts were due to poor gearing. Often with mecanums. These robots were geared to go too fast, and spent the majority of their time in the stall half of the motors power curve. This would lead to hot motors as a symptom beyond the brown out. Often the brownouts would occur after the teams drove into an un-moveable object. This year typically it was trying to get totes from the landfill. The team would drive into the totes repeatedly trying to get a grip on a tote. Every time the drive stalled, they were pulling several hundred amps which would drop the voltage, then brown-out occurs which cancels motor which increases voltage which give control back which leads to stall which leads to high current which leads to voltage drop......

I did see the bad gearing with a couple of the kit-bot chassis too.

I saw a couple times were there were issues of binding in the transmissions themselves. Once corrected, the issue went away. for two of them they had miss-assembled the toughboxes which was causing the gears to rub.

I also saw brownouts due to batteries not being charged enough. Teams with only 2 batteries tended to wear down the batteries

As others have said, mostly mechanical or electrical connection issues causing high currents.