![]() |
How do you design a robot that doesn't brownout?
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?
|
Re: How do you design a robot that doesn't brownout?
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.
|
Re: How do you design a robot that doesn't brownout?
Quote:
|
Re: How do you design a robot that doesn't brownout?
Quote:
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. |
Re: How do you design a robot that doesn't brownout?
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 |
Re: How do you design a robot that doesn't brownout?
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. |
Re: How do you design a robot that doesn't brownout?
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.
|
Re: How do you design a robot that doesn't brownout?
Quote:
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. |
Re: How do you design a robot that doesn't brownout?
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 |
Re: How do you design a robot that doesn't brownout?
Quote:
|
Re: How do you design a robot that doesn't brownout?
Quote:
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? |
Re: How do you design a robot that doesn't brownout?
Quote:
|
Re: How do you design a robot that doesn't brownout?
1 Attachment(s)
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.
|
Re: How do you design a robot that doesn't brownout?
Quote:
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? |
Re: How do you design a robot that doesn't brownout?
Quote:
|
Re: How do you design a robot that doesn't brownout?
Quote:
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 |
Re: How do you design a robot that doesn't brownout?
Quote:
|
Re: How do you design a robot that doesn't brownout?
Quote:
|
Re: How do you design a robot that doesn't brownout?
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. |
Re: How do you design a robot that doesn't brownout?
Quote:
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. |
| All times are GMT -5. The time now is 05:41. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi