[Official 2008 Game Design] New Technology Discussions

[dlavery]

This thread is a spin-off of this discussion, and has been started to present ideas for new technologies that could be introduced into the game or kit of parts. Particularly, suggestions for technologies, capabilities and design elements of the new control system to be introduced in 2009 are requested. If there is a capability that you always wanted to see in the control system – different development environments, more processing power, alternative communications schemes, new sensor compatibility, enhanced I/O options, etc. - this is the place to suggest it. Likewise, while autonomy need not be a part of a specific game, creative uses of autonomous components in any game are sought. Ideas about new drive technologies or inter-robot communications may be reviewed.

-dave

[artdutra04]

1. New 2009 Control System: The new control system should still run (or be able to run) with the C-programming used in the current controllers. Right now, with the Vex controllers having very similar architecture to the FRC Controller, the programmers can write and debug code (especially for advanced sensors like CMUcam) without having to worry about a 50lb FRC-scale test chassis running out of control.

1a. If the new controllers for 2009 will not run C, then a low cost alternative processor (similar with the Vex/Robovation controller) should be available to teams, and should be cross-compatible with the Vex/Robovation hardware for prototyping.

My suggestions for the new controller would be a basically upgraded version of the current controllers, with a more powerful/faster processor. A radical change in technology should be avoided, since many teams may not prototype ideas and advance their knowledge during the off-season if they suspect that all their work won't have any impact on future games.

Also, if new control system could adapt a new way of storing its onboard program that would be cool. Serial cables are becoming harder and harder to find on computers (especially laptops), and a new technology would be nice. One thought that came to my head is storing the program on a SD card, as many laptops and computers nowadays come with built-in memory card readers, and SD cards are one of the most common types used. (Idea being to plug SD card into computer, download code to it, pop SD card into controller, turn it on, and go!)

Or the SD card could also be used for more advanced CMUcam features, where images of what the camera sees (with crosshairs of the object centroid and a timestamp superimposed onto the image) could also be stored onto the card, to be viewed later on the computer.

2. Sensors: Sensors are good! (If anything is to be changed about the sensors, add more of them to the KOP). Especially the gear tooth sensors, the gyro, the accelerometer, and the CMUcam. Maybe if one or two IR short/long sensors could be thrown in as well, that would be awesome.

3. Code development environments: Defintely keep EasyC PRO. If someone is looking for a more textual-based IDE, then MPLAB is fine. If anything occurs here, a Mac (universal binary) or Linux compiler would be a nice addition.

4. CMUcam: Keep this as well, but include an "alternative" technology for autonomous. A good example was the 2004 season, there the IR beacon or line following could be used to get to the 10-point ball. However in future games, the use of the CMUcam to find the "better scoring" target, and an alternative technology to a "lower scoring" target, would be a nice compromise.

5. Inter robot communications would be fun to tackle, but standardizing communications of some kind would be necessary. If every robot could broadcast a standard set of parameters* to be readable by other robots on the alliance, they that could open up some interesting ideas and concepts. (After all, drivers/coaches can plan and coordinate their actions before the match with the other alliance members; robots should be able to do the same thing for autonomous.)

* A short example of autonomous mode parameters: (most are 0 or 1 answers)

ATTEMPT_AUTONOMOUS = [0 or 1; yes = will try to attempt autonomous]
RUNNING_AUTONOMOUS = [0 or 1; yes = autonomous code is running]
AUTONOMOUS_GOAL = [pre-definied by game design committee. in this year's game, it could be something like 41, 42, or 43 if you were scoring on column 4 in row 1, 2, or 3.]
EXPECTED_SUCCESS = [0 or 1; if the robot thinks it successfully scored.]

et ceteria, et ceteria

[David55]

Field Enhancement

As the webcasts and TV broadcasts become more common in FIRST events (more and more people are watching events on the internet), I think the video coverage of the field should be upgraded from the traditional 2 camera setup. What I am suggesting is integrating video cameras into the field (similar to the way sensors and the green light have been integrated into the field in previous years). This has happened several times in the past (for example having a camera inside the high goal in 2006 or having a camera inside the Rack in 2007 - as seen here). Obviously this generates new expenses for FIRST, but I think they are unsubstantial:
Camcorders can be bought relatively cheap (300-400$) which provide great video quality (especially for a webcast and even for TV standards). These cameras can be used year after year, which make it a one time expense. I also believe that most (if not all) video production companies at events can handle the switching with an extra camera.

I believe that having more video angles (or even on-robot video) will help make the game look a lot more interesting for people watching on the internet or on TV (especially people who have never heard of FIRST before).

(If this is not the right thread for this idea feel free to move it).

[raymaniac]

Originally Posted by dlavery

There are no assumptions about the need for three-team alliances, limiting each round to just six teams, play fields in a single plane, real-time radio communications, etc.

So we could throw in a slight delay between a command and the robot's responce?

This could create an interesting challenge for the drivers, having to anticipate what will happen and react accordinly, making controlling the robot much harder, especially when it comes to avoiding defense. Longer delays would make it more challenging and interesting, but anything more than 3-5 seconds might require longer match times.


This could simulate the delay in response times when commands are sent to the Mars rovers.

[Billfred]

Technologies I'd like to see in a new control system:

1) Integrated disable/autonomous dongle. No team should be without one, but there's a lot of things that can go terribly wrong with the ones we build ourselves (frying the OI processor, bad soldering jobs keeping the robot from disabling, a short triggering autonomous, etc.). My ideal setup would be putting a Big Red Button for disabling the robot and a covered switch for enabling autonomous operation right on the OI itself. If everyone's running the same dongle, every team member on every team in FRC will know what to hit to stop a robot in an emergency.

2) Secure connectors for cables. Vex robots already get RJ11 jacks for their radio and tether ports--what's stopping us from sticking the same on the motor controllers and RC? As a bonus, you're far more likely to find a handset cable in a hurry than a PWM cable.

3) The return of some sort of large, bright, visible-from-four-sides flashing light. Require teams to have a patch of Velcro and two spade connectors from the kit handy for the light, hand it out in the queue and take it back after the match. The flags, though cheap and modestly effective at showing alliance color, don't seem to impart the same "GET THE HECK AWAY FROM THIS THING, IT'S TURNED ON!" attribute as even the brighter IFI lights. Speaking of lights...

4) Red LEDs are fine, green LEDs are fine, but do something about yellow LEDs. If I'm checking an RC to make sure it's functioning, I can easily tell the red lights and the non-red lights. But discerning the blinking yellow lights from the blinking green lights takes more time. Maybe it's just me.

Other than the new control system, I'm largely fine with the level of technology in the KOP as it stands. Some refinements would be nice, but overall it's fine for me as it sits.

There are, however, a few other areas where things could be improved. I'm stretching the definition of "technology" here, but I think it's the best place:

1) Be more specific about team numbers on robots. We all know 4" high, 3/4" stroke, but sometimes that still results in numbers that are less-than-great in their visibility. Compare the numbers in this picture with the numbers in this picture. Both were to the satisfaction of the inspectors at the Palmetto Regional, but one is clearly easier to read. Granted, the inspectors could hold a team back until they made theirs more distinctive, but some examples in the manual of what should and should not be done here would probably be helpful to teams.

2) Change out the flags. Ringing issues aside, the flags tend to go projectile a little much--and as an inspector, the flag holder is definitely on my Top Five Things I Despise Inspecting for the simple reason that it is often the one thing holding a team from passing. Yes, it should be in place when they ship. Yes, it should be easy to inspect. Somehow, though, it is a thorn in the side for both the teams (who have to listen to me say they can't pass yet) and for myself (who has to listen to the teams gripe about how they can't pass yet, then invariably pass their flag holder thirty seconds before their first match). There has to be a better way.

The idea in my mind is to require a large trading card holder mounted upright on the top of each robot--let them extend beyond the maximum height like the flags currently do, and give teams an inch at the bottom to modify for their mounting needs. They're durable, easy to mount, and run about 40 cents each in quantity 100 for a good-sized one. Get to the queue, get a slip of (laminated) paper, slip it in the toploader. Get a yellow card? Get the slip with a yellow stripe. Done.

3) Steal the NASA Field's clock and put it on each FRC field. The white tape on the clock LED sign this year was a step in the right direction, but the rack still could block the view at times. A nice big one off to the side of the field would all but eliminate such problems for all time.

I'll think of more, I'm sure.

[EHaskins]

(1) Field positioning system(s)
One thing I think really needs to be added is an easy to implement, accurate, field positioning system. Many teams have been developing positioning systems, but a standardized system that any team could implement would open so many possibilities for autonomous operation.

(2)Inter-robot communitcation
Assuming a field positioning system was developed, then inter-robot communication specifically for position data would, I think, be reasonable and fairly easy to implement. Knowing the position of the other robots opens so many possibilities for autonomous modes and user control modes.

[EDIT] I don't believe inter-robot communication could be implemented for data not specified by FIRST. Un-regulated inter-robot communication could be an unfair advantage for teams which work together during the build season. [/EDIT]

(3) Processing power, and remote processors
I also would like to see the ability to have two-way communication between the robot and an off board processor, such as a laptop at the OI. The ability to have the almost unlimited processing power, compared to that of a PIC, of a laptop computer would open so many possibilities for programmers.

I see no reason why the RC programming should be limited to the embedded programming of the PIC, or a low power co-processor, when most real-world applications allow access to the processing power of one, or more, PCs.

Sorry if this is an incoherent rant.

[Madison]

I think it'd be interesting to see the rules regarding the control systems and electronics open up a bit more and reflect the change that was made to hardware limitations several years ago.

Effectively, I think there ought to be something for control systems that's analogous to the kitbot -- a sanctioned, provided system that accomplishes the most basic tasks. However, teams should be allowed to use alternative systems at their discretion, provided it meets certain requirements that ensure it will function with field control hardware and software. There's no reason why, as with many other things, we shouldn't be given enough rope to hang ourselves by.

(In reality, I don't care. I think the GDC should force us to use steam engines, but the electrically-inclined folks on my team might stop whining if they're given more to work with.)

[Tottanka]

I would suggest in improvement is sensors, especially the gyro. In aim high we had some trouble with it, as it restarted its values tozero every time it the robot hit something, or justt bumped. I believe adding some sort of an anti-shock system to the sensors will solve this.

More ideas:
*possability for 2 CMUcam on a robot, ofcourse if it could help the game. (one camera tracking two lights isn't always that good).
*A camera that transports image to the driver.
*Omni wheels included in kit (or cheeper to be ordered).
*A cahnge in the custom chasis provided, or more aluminum profiles included in the kit, so we have sevral options of designing the cahsis, withot having to find out-of-kit parts.
*USB-chicklet included in kit of parts.

[Billfred]

One thing I'd love to see in the manual: allow some media equipment to be attached to robots at the discretion of the lead inspector or FTA (or someone else, if the GDC feels it appropriate), even if it falls outside the regular bounds of the rules.

The production crew or FIRST-badged media would work with a team and the aforementioned authorities to mount the equipment in a manner that is safe, functional, and doesn't impart any particular competitive advantage. Wireless cameras would still require FIRST Engineering's approval.

I'd be inclined to allow such mounting outside of the weight limit, as I doubt anyone could mount anything bigger than a Mini DV camera to the satisfaction of everyone (and those things weigh little compared to batteries and bumpers), but feel free to change that if it actually makes more of a difference than I think it does. In any event, I'd argue that the value of getting footage that excites TV viewers or the folks at the events outweighs the fact that the zoom on the camera uses a non-kit motor.

[Billfred]

Okay, double post I know (but I can't edit the last one).

One more request on the new control system: screw terminals. I forgot about it until seeing an 2004-vintage picture of the RC of that era--but I now vividly remember having to yank everything off our RC to let the IFI rep at Palmetto re-solder the spade connector. (Tom is the man.)

Granted, screws can come loose--but they're more easily replaced than a spade connector as it is.

[Scott L.]

1. I liked the arena cameras from AIM High that counted the balls as they went through the lower goals. Maybe for 2008 we could have game peices that were scored this same way, or maybe through RFID.
2. Using the CMU camera having the robot score a particular color game peice during autonomous for a bonus, where the color is sent to the robot from the compition port at the start of the round.
3. Ultrasonic distance sensors would be nice to measure distances to a goal or other objects in the arena.