Choose your own control-system adventure

[SoftwareBug2.0]

Here's a list of possible things one might want in a robot control system:

1) Processing speed
2) Code space
3) User-available RAM
4) IO capabilities
5) Radio bandwidth
6) Code download time
7) Clean programming interface
8) Durability
9) Software reliability
10) Radio connection reliability
11) Boot time
12) Price
13) Compactness

If you were designing a new robot controller for FIRST what would you prioritize?

(I've been inspired by the thread about the new control system and seeing the "FIRST team survival excercise" thread. )

[flameout]

1. Radio connection reliability -- this is a fairly difficult thing to achieve in FRC's atmosphere, and it often (in my experience) makes the difference between a fun event and a frustrating one.
2. Software reliability -- reliability is important, although software tends to be far more reliable than the radio, so I'm ranking this lower on the list.
3. IO capabilities -- it needs to be able to easily talk to the robot's sensors and outputs
4. Clean programming interface -- teams with all-rookie programmers (and possibly no programming mentors) don't want to have to fight with integer-only idiomatic C programming.
5. Processing speed -- this probably has more to do with software than hardware, but we've repeatedly run into processor performance limitations with the cRIO, and I've had to cut back on functionality to gain acceptable performance in the remaining systems.
6. Price -- I'd love to be able to buy a new controller each year and not have to tear old bots apart.

In general, reliability is important, and I don't want teams to be limited in what they can accomplish with the system (due to limited IO or performance issues).

[EricH]

You forgot one.

Gotta make sure that it's simple enough that a bunch of mechanical types can use it--at least at a basic level--without too much hassle. Not all teams have an army of programmers... I'll drop that in the very last spot, though.

Anyways, the topic at hand.

1) Reliable radio connection. Until FRC goes fully autonomous, if the radio isn't working, the robot isn't working. If the radio isn't working, you paid HOW much to sit there?*
2) Durability. A banged-up controller doesn't do anybody any good, and FRC hits hard.
3) Price. Cheap enough that just about any team can get another, via discount if need be.
4) Boot time. Note that this is of the system and of individual components. If one component takes 2 minutes to boot, and the rest is under a minute, replace that component with a faster bootup!
5) Software reliability. Lots of libraries, not a lot of bugs, as bulletproof as possible to guard against the aforementioned mass of mechanicals pressed into service as programmers.
6) Processing speed--needed for more complex instructions.
7) Code space--large user code, or lots of libraries loaded, need lots of space.
8) Code download time--can you load code between finals matches if you need to?
9) Compactness--as a mechanical, a small control system is a good thing, because we don't have to work around it. Or, failing that, small components that can be spread out throughout the robot--sometimes it's a lot easier to deal with a flood of small items.
10) IO capabilities. More ports, more motion, more feedback, better control.
11) Radio bandwidth. (insert geezer comment about back in the day when we could only dream of robot-eye-view in the driver's station here, you don't know how easy you kids have it, etc.)
12) Tie: User RAM and clean programming interface.


*A common point made when dealing with dead robots that may have been the field's problem--you pay $5K for the first event, $4K thereafter. Roughly $400 a match at minimum, not counting all robot costs. Too high to just sit there...

[Greg McKaskle]

If I'm defining my dream robot control system from stuff I saw on the NIWeek expo floor, I'd want some of the following or related products...

Main Camera

Main brain

Or PXI if it doesn't need to be quite as rugged.
A stack of modules.
S.E.A has sweet radio options.

But I think I'd go for one of these to make my own radio. FCC will understand, right?

For the eyes in the back of my robot's head, some of these.

Moving beyond the control system, I'd attach one or two of these these.


I'd want some LIDAR, and IMU options.

I'd program it in a combo of LabVIEW and C++ and since I don't really know how to use this stuff I'd spend the next few years in training courses and reading manuals.

Greg McKaskle

[evanperryg]

Arranged them in order of importance

10) Radio connection reliability: I will be honest, it makes me furious when a robot loses connection mid-match, especially when the refs ignore it.
6) Code download time: Again, this makes me mad. Either the event needs to compensate for poor upload times or the poor upload times need to be fixed. It is not the fault of the team that code takes 20 minutes to upload.
9) Software reliability: Even if it isn't the fastest, or the most efficient, it should work as intended at least 98% of the time.
4) IO capabilities: More IOs make for more options for robot design. I have a feeling that in 5 years, FIRST will have outgrown 10 PWMs. As it is, my team was planning on using all 10 this year(ended up using 8)
8) Durability: It should be solid. I'm not saying every electrical component should be in a huge enclosure, but a control system shouldn't be/feel flimsy.
5) Radio bandwidth: We maxed out at 6fps@160x90 on our camera. Bad, but few teams actually end up effectively using their camera, anyway.
1) Processing speed: It should be responsive. I'm not saying we need some kind of quad-core, dual FPGA thing but we shouldn't be trying to use an Arduino, either.
13) Compactness: Tiny=better. Trying to cram a cRio and sidecar into the amount of available space on my team's bot this year was a nightmare.
11) Boot time: If you can get it under 20 seconds, great. But, what is more important is performance after the boot sequence is over. Anything over a minute, though, is a problem.
2) Code space: Has anyone ever actually run out of code space on the cRio? The amount we have now is fine.
12) Price: As long as we still get one free one from FIRST, there is any huge concern over controller cost.
3) User-available RAM: We've got plenty right now, but more is always nice.
7) Clean programming interface: I prefer text-based coding to gui, so I don't particularly care about this one.

tl,dr: Vex does everything right that the cRio does wrong, and the cRio does everything right that Vex does wrong.