Overall Software Design
Alastrrrgh the Pirate Ship
Overview
The code that drives the helm and the boat is written as a quasi state machine with three states: waiting for an iButton, waiting for a boat match, and executing helm commands or playing game. While several elements of a traditional state machine exist in the code, each state is written as blocking code – the software may not proceed to a subsequent state until conditions satisfying a given state are fulfilled. This implementation is a result of the modular development of individual components of the software and proved convenient for methodical and modular debugging purposes. Due to the complexities of wireless, multi-nodal communication, all packet recognition occurs within an interrupt service routine that ensures that once complete packets are received, they are identified immediately and without interruption.
1. Waiting for an iButton
In this state, the helm waits indefinitely for an iButton. It may additionally respond to pings from the admiral and hard resets, but nothing else. Once a legal iButton has been received and identified in the interrupt service routine, the code light a lamp to indicate team association and then proceed to the next state – waiting for boat match.
2. Waiting for a Boat/Helm Match
In this state, the boat/helm waits indefinitely for a helm/boat to broadcast a matching iButton serial number. It may additionally respond to pings from the admiral and hard resets, but nothing else. Once a matching iButton serial number has been received and recognized by the interrupt service routine, the boat (or the helm depending on which one reads the iButton first) will begin to broadcast a transmit received message directly to the boat at 5Hz. It will continue to do so until a no action command is received directly from the matched helm/boat. Code is in place to filter out no action commands from address other than the paired helm/boat. Once the no action command is received, the boat will proceed to the next state – executing commands from the helm and in the case of the helm, it will start reading its sensors and send commands out to the boat.
3. Boat: Executing Commands from the Helm
In this state, the boat is set up to receive and respond to navigation and special commands from the helm. It may additionally respond to pings from the admiral, hard resets, soft resets, and stand down commands. The servo motor and propulsion motor receive PWM drive signals that operate based on timer interrupt overflows that prompt the setting of each line high or low according to commands from the helm. As per the project specifications, if no command is received from the helm, which should be sending no action commands while idle, over a span of three seconds, the boat will cease all function. This is the final state in which the boat will come to reside until a hard reset is received or a physical reset is executed.
3. Helm: Sending Commands to the Boat
Two 16F690 PICs are used on the Helm—one PIC (XBee PIC) that communicated with XBee Radio and sensors and another PIC (LED PIC) to control the LEDs for boat number display, team, active zone and game status. The XBee PIC communicates with the XBee Radio through EUSART at a baudrate of 9600.
The LED PIC and the XBee PIC also communicate via EUSART at 9600 baudrate. The Multiplexer on the transmit line of the XBee PIC is controlled by switching one control line between logic level high and logic level low depending on the intended audience for the transmission.
All sensors used for the Helm are continuously active, but are only read at 5 hertz. Every 200 milliseconds the microprocessor sweeps all sensors to determine which commands are active and relays that information to the Boat. The magnetic sensors are read with the assistance of a multiplexer. The code cycles through all of the magnetic sensors until a logic level high signal is found at which point it stops cycling and translates the value of the particular sensor that is triggering “high” into a direction and speed control byte. This “cycling” is accomplished by writing values 0 to 7, incrementing one value at a time, in hex to the lowest pins on Port C of the PIC which controls which input to the mux is active. The default value in the event that no magnetic sensors are triggered is to write 0x88 to the byte to stop the boat actuators.
The PIC also reads the special and water byte information at this same time. It checks first the water pump switch value. If the signal for the pump is high, 0xF is written to the special-water byte, otherwise 0x0 is written to the same byte. The signals are then read off of the respective pins for Specials 1 and 2 and these bits are written to the special-water byte in their respective locations.
After all sensors have been polled, a packet of information containing these bytes is formulated and sent to the boat.