[kmcclary]

Originally posted by Nate Smith
I'm not an "official" word on this, but from what I do know, it comes down to one thing: safety. The pneumatics kit is not a random set of parts like much of the rest of the kit is, but rather all of the fittings, etc. are hand selected to work together. As for the electronics, if an "anything goes" solution was allowed, FIRST would lose much of the safety/fairness/rule enforcement controls(emergency cutoff/timer shutdown) that they have with the current system.

Done right, safety should not be a problem.

Pneumatics

With air, all you need is the rule: "All added pneumatic components must be rated for the pressures involved". No sweat. Considering that FIRST already literally uses hardware store parts (such as the basic brass T-blocks which as air couplers are rated WELL above the working pressures we're working at), not allowing ANY extra fittings seems an excessive restriction.

A more reasonable one may be something like: "all additions will either come from [these vendor(s)' line(s)] or else be shown to pass hydro static pressure test <air industry org spec #xxx>". Heck, at least let us add more identical VALVES from the SAME vendors... We have more pistons allowed than valves right now!

Electronics

You don't need a new "Power Cutoff Block". You can use a Spike for that.

I instead propose the following safety rule changes:

Rule [X]: "Custom electronics may move motors, actuators, and RC servos, or interrupt the path between [Victor/Spike] and it's driven component, PROVIDING that ALL of the below are met:
A) ALL motive or actuation power for devices or interfaces driven by custom electronics must be DIRECTLY DERIVED from either the output of a Speed Controller or a Relay Module; AND
B) If custom electronics are used as a current controller or interrupter, the current and voltage specifications of that circuit shall meet or exceed that of the equivalent IFI control normally used. Documentation showing compliance to this spec shall be provided to the inspectors upon request.

Comments:

Rule X.A - You don't need a new "power interface component" from IFI for safety. A Spike is already a great part for this. This new rule would INSURE that electronics CAN'T move the bot under any shutdown condition. This is also easily verifiable by power wiring inspection, without inspectors having to understand the custom electronics at ALL.

Rule X.B - Allows for things like a cutoff circuit to be placed in series with a motor or solenoid and it's IFI driver [Spike/Victor], for faster toggling than the RC can provide (important in some applications).

This, and/or the "additional air parts allowed" rule, could allow things like pneumatic servo valves to be either purchased, or created out of the existing valves with PWM techniques. Either way, it opens up a WHOLE new design arena!

I do like your thinking about creating a general control architecture for ANY robot controller to be used in place of the IFI one, but I'm not sure if that's politically viable, at least in one step.

I do feel we need a MUCH better RC CPU (or opening up the electronics budget) next year, to best accomplish Autonomous Mode.

Yea "Adam Y.", we thought about PICs, and you can do a lot with them. But given only six weeks from the time we found out we needed a PIC expert, it turned out we didn't have one on hand nor time to GROW one. So, we were basically stuck with the RC. Add to that we were a Rookie team with limited experienced personnel, IMHO our Autonomous Mode control system design was painful, crude, limited in scope, and the path was prone to "drift".

Originally posted by ChrisH
On the contrary, I'd much rather see a more restricted list of components. Maybe it's just the industry I work in, (aerospace vehicles) but if it ain't in the spec book, it doesn't go on the bird.
[...] In real life there are often restrictions on materials etc. that are even more stringent than those in FIRST.

Well, let's be fair here. You're talking about "life critical design" applications, an EXTREME design case. This is normally ONLY seen in places like medical, military and aerospace industries. It's one thing when you're where a hardware or software breakdown is fatal either immediately or because you can't get spare parts for the entire life of its mission. That's IMHO an extreme case of "real world", and is not how MOST industries work. (Besides, if you read the fine print on virtually ALL of our part spec sheets, every one of them has something about "not authorized for life critical applications", so we couldn't design for that extreme even if we wanted to.)

IMO, This is a LOT different design situation. I feel this is an "educational exercise for the design and creation of a 'consumer level' product". After all, it only has to run for minutes at a time, and a hour or two at the most over its ENTIRE lifespan. Spare parts, tools, and workers are available on site for maintenance, after every two minutes of operation if necessary.

IMO, here quick repairability in a student's design is much more important to stress than MTBF. As Team 71 did last year with their file card arm crawler system, you may even DESIGN IN and EXPECT wearout of parts virtually every round!


IMO, this contest's model is: "build it on time, within budget/size/weight, make it good enough to perform (and survive) at least two minutes at a time, have it be VERY repairable 'in the field', and don't let it hurt anyone". As long as its breakdown or failure modes are not a threat to participants and viewers, and we meet the above, I'd still go for open part sources.

Besides, I feel that "a student often learns more by something that breaks under usage than by an immediate success."

Also consider: In most industries, if it NEVER breaks, it MAY have been seriously overdesigned for THIS application, and may have room for cost/weight/labor saving redesign to remain competitive. Yes, huge MTBFs are critical in your industry, but with MOST automotive, consumer (et al) products, the OPTIMUM is NOT to design to perfection, but to design to "lifespan expectations and for repairability, without incurring excessive design and/or manufacturing costs".

BTW, At the first major company I worked at after school, I had to have my UM college training of "pour time and money into it, and hold onto it until perfection is achieved" literally beaten out of me as some kind of an "attempt to bankrupt the company". (...and the floggings shall continue until morale improves...)

The painful real world lesson I had to learn was "Working well is one thing, but if it already far exceeds it's design parameters and expected use lifetime, to heck with perfection. It's time to LET IT GO so we can get it into production!"

Honestly, I've STILL found myself dealing with THAT last one in every FIRST contest to date! (Hey, YOU try to take the robot away from the Mech Assembly crew so we can wire and program it... <chuckle> It's always a tug of war. If you let them, I'm sure they'll keep completely redesigning the mechanics on you until ship date!)

You do have an excellent point though. If this WERE a life critical application, I too would be worried about component specs and if the design rules were not stringent enough. If a student's life or safety hinged on their machine working, this would be a whole different ball game!

Hey... Let's simulate a "life critical app" next year... Let's put all of the HPs in carnival 'water dunk tanks', and have the robot perform (and defend their HP against) a release ritual on the push plate!

- Keith