In 1999, when this project first began, we sent the commands to a transmitter connected to the parallel port on the computer. This may be because the transmitter board was a pre-built kit. However, there was no reason not to communicate through the parallel port. We were running Windows 98 on our computers, which had no security features to prevent such communication.

In 2000, we began using Windows 2000, which has more protection features. In order to communicate through the parallel port, it was necessary to run a separate program, "network giveio", which would essentially disable the security. Running this program required adminstrator access to the computer, and was essentially just a cheap fix rather than a real solution. We have yet to find an appropriate way to send data through the parallel port. It may require writing a Windows driver.

In 2002, we altered the system to send wireless commands through the serial port. There were three reasons for this change. First, the code to send data through the serial port is extremely simple and straightforward. Second, we needed to build a new transmitter board. The boards from 1999 were becoming older and less reliable, and no one really knew how they worked anymore. Finally, we had several different types of radio transmitters for the 2002 system. The new boards needed to be able to interface with any of them. The old boards could only interface with Radiometrix transmitters.

One of the main objections to using a serial port is that they are being gradually phased out of new computers. Future teams should examine the possibility of using the USB port to communicate to the transmitter. Our current research has suggested that USB adds too much latency to the system. However, future advancements may reduce this latency.

The Radiometrix transmitters can send 25 bytes per packet. We decided to send commands for all the robots in one single packet. For the RoboCup team of five robots, we could send five bytes per robot. However, we want the same robots to be used for the RoboFlag environment and the 11 vs 11 RoboCup exhibition match. Therefore, we have chosen to allocate four bytes per robot, so that each packet contains commands for up to six robots. For teams with seven to twelve robots, we will send two packets per frame.

The structure of the packet is as follows:

• Byte 0: Identity byte - this identifies whether the packet controls robots 0-5, or 6-11. For robots with duplex communication systems, this byte also identifies which robot is allowed to communicate back to the Intelligence and Control System.
• Bytes 1-4: Commands for robot 0 (or robot 6)
• Bytes 5-8: Commands for robot 1 (or robot 7)
• Bytes 9-12: Commands for robot 2 (or robot 8)
• Bytes 13-16: Commands for robot 3 (or robot 9)
• Bytes 17-20: Commands for robot 4 (or robot 10)
• Bytes 21-24: Commands for robot 5 (or robot 11)

Each set of four bytes is organized as follows: For 2000 and 2001 robots:

• Byte 0: Velocity magnitude of Wheel One
• Byte 1: Velocity magnitude of Wheel Two
• Byte 2: Velocity magnitude of Wheel Three
• Byte 3: Directions for each wheel velocity, plus commands for kicking, dribbling, side dribbling

• Byte 0: Forward velocity (magnitude and direction)
• Byte 1: Sideways velocity (magnitude and direction)
• Byte 2: Rotational velocity (magnitude and direction)
• Byte 3: Commands for kicking, dribbling, side dribbling

The exact packet structure can potentially change throughout the development process. To find the most up-to-date packet structure, you should examine the code directly. The packet structure is built in the file, "WirelessSender.cpp", in the functions "buildRobot2000", "buildRobot2001", and "buildRobot2002". Note that the packet structure for 2000 and 2001 assumes that the robot is a three-wheeled omni robot. Also, in order to calculate the correct velocities for each individual wheel, the Intelligence and Control system must be aware of the geometry of the wheels. For the 2002 packet structure, the only assumption required is that the robot has omni-directional capabilities. The robot's onboard electronics are responsible for converting the commands into individual wheel velocities. This requires more computation onboard the robots, but it allows us to send more detailed velocities to the robots, and could potentially allow us to field hybrid teams of robots (with different wheel geometries) without changing our code.

As of this draft of the documentation, the transmitter board can only interface with Radiometrix transmitters (418 MHz and 433 MHz). The new transmitter boards have been designed but not constructed yet. The interface to the serial port has been finalized, however. In order to signal the beginning or end of a packet, the code sends header and footer characters to the transmitter board. The board then makes sure that exactly 25 bytes were received between the header and footer. If so, the packet is sent.

If we are sending one packet at a time (in order to control up to six robots):

1. To start sending the packet, we send 0xFF
2. To end the packet, we send 0xFE

While the packet is being transmitted, a new packet can't be sent for approximately 10 ms

If we are sending two packets at a time (in order to control seven to twelve robots)

1. To start sending the first packet, we send 0xFF
2. To end the first packet, we send 0xFD (indicating that another packet is coming)
3. To start sending the second packet, we send 0xFF
4. To end the second packet, we send 0xFE

While the packets are being transmitted, a new packet can't be sent for approximately 20 ms If new packets are sent to the transmitter board while the board is transmitting, the new packet will be dropped and the yellow LED will turn on.

If the system is running properly at sixty frames per second, the transmitter light on the Radiometrix should be a solid red. In 2001, this was not the case. The transmitter light tended to blink semi-regularly. Unfortunately, this problem was ignored since the robots were still being controlled successfully. It was later discovered that a network problem was causing the system to transmit at approximately twenty frames per second instead of sixty. The system is transmitting properly at sixty frames per second now, although a packet is occasionally dropped. Packets are not dropped enough to cause a problem with the system, however it would probably be wise to explore the source of these dropped packets more fully in 2003.

One of the best ways to debug the transmitter system is to connect an oscilliscope to the transmitter board to directly observe packets being sent. A working system should send one new packet approximately every sixteen milliseconds (a certain amount of jitter is unavoidable). This is one of the first tests that should be done if the overall system starts behaving incorrectly.

More detail information on the RoboFlag Wireless system can be obtained by contacting David Schneider.