[Official 2008 Game Design] New Technology Discussions

[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.