What Team 568 is cooking up.

[Draqo]

First off since this is my first post I'll say hello, and FIRST is awesome.

So, from day one when I joined 568, which was already 3 weeks into the build, I devised a display written in VB6 for the camera by sniffing "printf" statements sent through the PRG port on the RC. However, now I'm sniffing the dashboard port on the OI. Instead of using an ActiveX or the current Dashboard program, we are building a full-out display (and settings) of anything and everything needed, including CamU data, Joysticks, software shifting, etc. Even devised a UI to set variables within the RC via joystick.

For some who think this is too complicated or just plain impossible, I'll give you the run down on how our program works. (Leaving some things out so that everyone doesn't clone the method.)

First off, sniffing RS-232 com ports can be done in both VB6 and .NET, source code is available from MSDN. Once gotten that done, time to ID the packets. Here are some stats on how the packets function mostly based from the Dashboard PDF documentation:

There are 3 packets, each arriving 13 frames per second, making the total to be 40 frames per second.
Each one is ID'ed by CTRL_A and CTRL_C bytes (actually a bit in each byte), read the PDF for more info.
Once divided into three parts in code, custom byte-to-bits conversions can be done for Aux_Byte, LED's, etc. to display graphical indicators on a form.

The 6 user bytes are the ones needed to do custom packets, unless using unused PWM's. But 6 should be enough to make packets within the Frame #2 packet. Now, since arriving at 13 FPS, for every custom packet, the FPS drops.

For what we're doing:

We have about 5 custom packets, and 1 command-feedback packet.

Packets 1 & 2 are Camera data to display graphically. (A real sight to see, pun intended.)
Packets 3 to 5 are Joystick data.
Packet 6 is command packet for displaying the menu interface; calibrating joysticks, manually setting switches, relays, software shifting, etc. All on-the-fly (some writing to the ROM not RAM) and some automatically inputted into a C file for next upload. Manually setting values is done with a game pad, joystick, or an EDU-RC (not telling ), the information is relayed to the RC via OI, the RC makes changes to the menu, and then sends back the command data to the OI via 6 user bytes. Each custom packet contains a byte header for their ID. The menu can even override and limit the joysticks, comes in handy if someone goes 0 to 255 and trips the breakers when software shifting is set to off. Also some other features I won't mention until the final program is complete. (Basics are done, advanced configuration needs more work)

I would give you all a screen shot but that'll ruin the surprise.

I give ya'll a hint, I don't know what would be harder, keeping my eyes on the field or watching pretty colors on screen bounce around.

See ya all in San Jose.

David (Programmer)
Team 568
Anchorage, AK
Nerds of the North, Dimond High

P.S. If anyone is desperate or curious enough to want to make their own full-display of the RC & OI data, I'm willing to help. As for the menu interface to send data to the robot and display it back to a PC, I'll help with that also.