|
|
Spockie-Tech
Site Admin
Joined: 31 May 2004
Posts: 3160
Location: Melbourne, Australia
|
quote:
Originally posted by Grotto:
SpockieTech -
I agree with the failuree point concept, but shouldnt
it be balanced with the "dont keep all your eggs in one basket" concept?
That is definitely worth considering as well.. Then you start getting into Failure-Modes and "soft-fail" and other design concepts like that.
Decentralising does increase your resistance to localised failures, but also increases the likelyhood of failure since there are more points and exposed channels to fail.
Ideally you want the "all in one box" design, and then have *two* of them onboard. (Then the backup changeover relay fails - I've seen this happen ) with a dual-redundant security system setup - or, closer to home - One of the US BattleBots (Minion) had a lot of redundancy in it, only to have a hammer bot stick their spike right in the only point that would take down the whole bot with one blow - the radio receiver.
Thinking about how a design might fail can seem defeatist to some, but its worth considering when the consequences of failure are so high. Heres a list of the most common failure points from the guys who built Hazard.
-- from http://www.legalword.com/tips.html --
TOP TWENTY COMBAT ROBOT FAILURES
One thing that is helpful to think about when designing a robot are the possible ways the robot can fail during combat. Indeed, one of the primary reasons robots lose matches is not that their opponents beat them -- it's because some part of the robot fails. Listed below is my top twenty list of robot failures. Prior to any competition you should test your robot thoroughly to ensure that none of these failures will occur. By designing your robot to avoid such failures, you will have a much improved chance of success.
1. Battery connections and other wires coming loose
2. Chains falling off sprockets
3. Set screws and other shaft couplings becoming loose
4. Radio interference and/or insufficient range
5. Batteries that are not properly charged or do not have enough capacity for the robot's drive or weapon motors
6. Speed controllers that cannot handle the current of the drive or weapon motors
7. Motors, batteries, and other components insufficiently mounted and coming loose
8. Wires and electrical components shorting out from improper mounting or foreign debris
9. Robots that do not have enough ground clearance
10. Drive and weapons motors that do not have enough power for the robot design
11. Underrated fuses that blow
12. Undersized motors that overheat
13. Undersized and/or misaligned gears that strip
14. Gas engines that stall and/or do not start
15. Wheel interference as a result of floor debris or bent frame and body materials
16. Punctures of inflatable tires
17. Breakage of substandard fasteners (bolts, nuts, rivets, etc.)
18. Breakage of undersized shafts and axles
19. Insufficient protection against arena hazards
20. Home built components (speed controllers, electronics, etc.) failing under combat conditions
---
Note the #1 reason and also 7 and 8. Distributed designs will make these even more likely unless great care is taken in connecting and supporting a distributed design. _________________ Great minds discuss ideas. Average minds discuss events. Small minds discuss people
|
Wed Nov 22, 2006 12:09 pm |
|
|
Valen
Experienced Roboteer
Joined: 07 Jul 2004
Posts: 4436
Location: Sydney
|
I think that you really need to look at the probability of failure for a given component/design and based on that look at making that component more reliable or redundant.
ESC's themselves should be made more reliable, putting them in a few places reduces the reliability as spockie has said. a pick through the ESC is going to fry stuff, rather than putting a few ESC's in, with all the crud you need for that to work, spend the weight on armor. The big area I see regular and preventable failures in is radio. Typically radios need to be put "in harms way" to get good signal, and often get occluded by the body when the bot is upside down etc. A distributed radio system could be a good thing. The difficulty is in removing common mode failures from the system.
IE powering all the radios off one supply isn't going to be a good thing, when one radio gets smashed it runs a good risk of shorting the power rails and there go all your other radios.
My thought was to use optic fibers in a point-point configuration from radios back to a protected box with the esc in. Each radio (bluetooth, IR,zigbee, other cheap thingie) runs off its own lithium coin cell and reports it battery charge status at poweron.
(flat logic batteries have cost us a battle or two) For the data rates we need the fiberoptics found in xmass trees is all thats needed i thinks, with photodiodes and the like for sensors and LED's for outputs.
For the ESC itself, Putting redundancy in is usually going to be self defeating, you would be better off spending the mass on protection and bulletproofing whats there. Thermal sensors, current sensors, monitoring bus voltages, battery charge monitoring etc.
Stopping cascade failures is also worth it in my book. a Zener here, a diode there can mean the difference between a fet blowing and something that takes out the fet, driver , power supply, and controller chip. _________________ Mechanical engineers build weapons, civil engineers build targets
|
Wed Nov 22, 2006 12:49 pm |
|
|
Grotto
Joined: 30 Aug 2005
Posts: 38
Location: Morisset NSW
|
Thanks guys, sorry for the delay in replying but it is Christmas after all.
Taking all this info account I must say that my first (few?) battle bots
will not be distributed power, but Im not ruling it out in the future.
Im going to continue with my ideas (one at a time) in a non-combat
robot, ie a R/C electric lawnmower, as a testbed. Im not giving up
on distributed design as I have some
very
long range plans
that will more or less require it. (
dont ask what, its a secret
)
And yes, it will end up in a battlebot if I can make it all work. Little hint,
it
will
make the bot an effective hunter, but not necessarily a killer.
The killer part will come later. Hehehehe
So I'll pull out of this thread at this point, but I need someone to bounce
by mosfet switching designs off (by PM I would guess, you're choice).
Any volunteers ? Bear in mind Im rusty with electronics, having spent
most of my time with microcontrollers lately. So I will have some VERY
stupid mistakes regularly. Im also new to mosfets, so please be gentle.
Thanks for the input all.
Regards _________________ "The future is not set. There is no fate but what WE make."
........CEO Cyberdyne Systems
Last edited by Grotto on Tue Jan 09, 2007 1:24 am; edited 1 time in total
|
Fri Jan 05, 2007 4:04 pm |
|
|
maddox
Joined: 21 Dec 2006
Posts: 786
Location: Belgium
|
I must agree with Spocky-tech.
Home build speedo's are in most cases a money pit filled with exploded mosfets, blown pcb tracks, smelly capacitators and such.
I'm not even close to an electronics guy, but if I would attempt to solder a "build yourself speedo package" like the OSMC package, I will have a commercial set to fill in the mean time.
I'm not intending to end up with a robot in the shed, because I fried to much electronics.
Oh well, speedo's over here in The Netherlands (Belgium acutally). The 4QD's and Electronizes did well in the past. But currently, the majority of the heavies is driving the Dutch Mythras speedo, and with the Sidewinder as newcomer for all weight classes.(no superheavies here)
Feathers, the speedo's found by Inventor and distributed by Leo are getting very popular- they have an obvious disadvantage- 12V max. But they are dirt cheap, small ,light and easy to use.
|
Fri Jan 05, 2007 5:08 pm |
|
|
|