A flat state machine was used to control the spectacoal. The state machine consisted of 4 states: InitPstate, Wait4Connect, Wait4Inputs and Charging.
The SPECTACOAL will receive (RECEIVE event) 10-byte messages from the BARNACOAL and transmit 13-byte messages to the BARNACOAL. This RECEIVE event is done using an interrupt to efficiently check for received messages. It checks each 10-byte (as specified in the communications protocol) message received byte by byte and adjusts the fuel servo motor position on the SPECTACOAL accordingly or confirms pairing (byte 9). When the SPECTACOAL first receives a byte of data, it will check it with respect to the Xbee RX packet frame structure and increment a bytecounter that starts at 0. If the 3rd byte of the message received does not have the correct LSB of 0x06 (the expected length of the packet), the rest of the message is ignored but the bytecounter will be continually incremented to reset at the false length to properly process the next packet received. The messages containing button, switch, and joystick values are sent using a bool and an event checker.
The initPstate contained all of the initial configuration needed for the spectacoal. This included setting all the respective pins as outputs or inputs and as digital or analog inputs, connection to the servo motor using the provided PWM library, the interrupt for receiving from the Xbee, the transmission to the Xbee, and starting off the blinking of the connection LED at 5 Hz.
The Wait4Connect would wait for the connection button to be pressed. Once this button was pressed, the potentiometer value would dictate which of the 6 boats we would attempt to pair to and we would begin to attempt to connect. The potentiometer was split up into 6 regions, with boat 1 being position 0-170, boat 2 being position 170-340 and so forth. To attempt to connect, a byte of 0x02 was sent on the 9th byte. In this state, the connection LED would continue to blink at the 5 Hz until a connection was established. Once the respective boat sent back the 0xFF value on the 9th byte (as per the comms committee), we could transition into the Wait4Inputs state. In the case where a connection was attempted but no message was received within 4 seconds, we would return to the InitPState to reinitialize and wait for another connection button press.
In the Wait4Inputs state, the joystick data (bytes 10 and 11), dumping and anchoring data (byte 12), and charge limit switch data were checked, updated, and sent every timeout at 5 Hz using a bool and an event checker. In this state, byte 9 was 0x00 (driving). If the charging state were to have changed (the limit switch pressed), then a CHARGE event would be posted, which would move the state machine to the Charging state. Same as the previous state, if no message was received within 4 seconds, we would return to the InitPState to reinitialize and wait for another connection button press to repair or pair with another boat. In this state we also were receiving (RECEIVE event) the gas data using an interrupt from the BARNACOAL. This gas data would update the gas variable which would update the gas servo motor position. If the gas got to 0, the charge LED would light up.
In the Charging state, data was still sent at 5Hz, but now a byte of 0x01 was sent on the 9th byte. The gas data received would update the servo motor to an amount of gas proportional to the time charged where 5s provided 30s of charge. If the gas data that was received got to 150, then the charge LED would go off to indicate that there was full charge. Again, if no message was received within 4 seconds, we would return to the InitPState. The moment that the charge limit switch was let go, an EXIT_CHARGE event was posted, charge LED turned off, and the state machine transitioned back to Wait4Inputs.