Go to Post I mean who does want to write their code like this... [CODE] CANHAZ.VICTOR; GIMME.VICTOR; VROOMVROOM.VICTOR(1); KTHNXBAI; [CODE] - JohnFogarty [more]
Home
Go Back   Chief Delphi > Technical > Technical Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 04-11-2015, 21:44
gblake's Avatar
gblake gblake is offline
6th Gear Developer; Mentor
AKA: Blake Ross
no team (6th Gear)
Team Role: Mentor
 
Join Date: May 2006
Rookie Year: 2006
Location: Virginia
Posts: 1,940
gblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond repute
Re: How do you design a robot that doesn't brownout?

Quote:
Originally Posted by mschwab013 View Post
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
__________________
Blake Ross, For emailing me, in the verizon.net domain, I am blake
VRC Team Mentor, FTC volunteer, 5th Gear Developer, Husband, Father, Triangle Fraternity Alumnus (ky 76), U Ky BSEE, Tau Beta Pi, Eta Kappa Nu, Kentucky Colonel
Words/phrases I avoid: basis, mitigate, leveraging, transitioning, impact (instead of affect/effect), facilitate, programmatic, problematic, issue (instead of problem), latency (instead of delay), dependency (instead of prerequisite), connectivity, usage & utilize (instead of use), downed, functionality, functional, power on, descore, alumni (instead of alumnus/alumna), the enterprise, methodology, nomenclature, form factor (instead of size or shape), competency, modality, provided(with), provision(ing), irregardless/irrespective, signage, colorized, pulsating, ideate
  #17   Spotlight this post!  
Unread 12-11-2015, 19:52
garyk garyk is offline
Programming Mentor: 668, 972, 2643
FRC #0668 (Apes of Wrath)
Team Role: Mentor
 
Join Date: Dec 2006
Rookie Year: 2005
Location: Santa Clara (Silicon Valley) Calif.
Posts: 94
garyk is a jewel in the roughgaryk is a jewel in the roughgaryk is a jewel in the roughgaryk is a jewel in the rough
Re: How do you design a robot that doesn't brownout?

Quote:
Originally Posted by tahmid0517 View Post
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.
__________________

Silicon Valley Regional 2005, 2006 972
Silicon Valley Regional 2007 668 Xerox Creativity Award
Championship Event 2007 668
Portland Regional 2008 668
Silicon Valley Regional 2008 668, 972
Beta Test Team 2008 668 (with 100 & 254)
Silicon Valley Regional 2009 668 Regional Chairman's Award; 2643
Sacramento Regional 2009 668 Winning Alliance (thanks, 1717 & 2473!), 2010 Winning Alliance 3256
CalGames 2006, 2007, 2008, 2009, 2010, 2011 Field Tech
NorCal FTC Regional 2008, 2009 Inspector
Championship Event 2009
San Diego, Silicon Valley Regionals; Champ. Event 2010 668, 2643, 3256
Silicon Valley, Madera Regional 2012 2643
WRRF Programming Instructor 2006-2016
Regional Woodie Flowers Award 2014 2643 Utah Regional

  #18   Spotlight this post!  
Unread 16-11-2015, 10:00
matthewdenny's Avatar
matthewdenny matthewdenny is offline
Registered User
FRC #6054 (Dukes)
Team Role: Mentor
 
Join Date: Jan 2012
Rookie Year: 2012
Location: United States
Posts: 311
matthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant futurematthewdenny has a brilliant future
Re: How do you design a robot that doesn't brownout?

Quote:
Originally Posted by Chris is me View Post
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.
  #19   Spotlight this post!  
Unread 16-11-2015, 10:27
Nemo's Avatar
Nemo Nemo is offline
Team 967 Mentor
AKA: Dan Niemitalo
FRC #0967 (Iron Lions)
Team Role: Coach
 
Join Date: Nov 2009
Rookie Year: 2009
Location: Iowa
Posts: 804
Nemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond reputeNemo has a reputation beyond repute
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.
  #20   Spotlight this post!  
Unread 16-11-2015, 11:09
IKE's Avatar
IKE IKE is offline
Not so Custom User Title
AKA: Isaac Rife
no team (N/A)
Team Role: Mechanical
 
Join Date: Jan 2008
Rookie Year: 2003
Location: Michigan
Posts: 2,151
IKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond reputeIKE has a reputation beyond repute
Re: How do you design a robot that doesn't brownout?

Quote:
Originally Posted by garyk View Post
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.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 11:19.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi