Background

For PC-Arduino communications, a basic serial protocol was established for fast and efficient communication of data. Any changes here must be made in both the Arduino side software and PC side software. For octave scripts, the common, tested serial functions are in \RoboSim\Octave\SerialUtils

Arduino Serial Configuration

For proper behavior, the Arduino requires the serial port be set to 115200 baud, 8 data bits, 2 stop bits, and an even parity bit. Having a timeout is also a good idea (length is application-specific)

Packet Definitions

Arduino->PC Packet Definition:

byte	Description	Units	Conversion
0	start of packet marker	N/A	always '~'
1	bit-packed digital inputs	N/A	N/A
2	motor 1 voltage	signed int8	0.09375 V/bit (-12 to 12 V range)
3	motor 2 voltage	signed int8	0.09375 V/bit
4	motor 3 voltage	signed int8	0.09375 V/bit
5	motor 4 voltage	signed int8	0.09375 V/bit
6	motor 5 voltage	signed int8	0.09375 V/bit
7	motor 6 voltage	signed int8	0.09375 V/bit
8	checksum	bits	bitwise XOR of all other bytes

0'th byte is rxed first, nth byte is rxed last.

PC->Arduino Packet Definition:

byte	Description	Units	Conversion
0	start of packet marker	N/A	always '~'
1	bit-packed digital outputs	N/A	N/A
2	analog output 1	unsigned 8	0.019607 volts/bit (0-5V range)
3	analog output 2	unsigned 8	0.019607 volts/bit (0-5V range)
4	Quad Encoder 1 output MSB	signed 16	(1ms/bit)
5	Quad Encoder 1 output LSB
6	Quad Encoder 2 output MSB	signed 16	(1ms/bit)
7	Quad Encoder 2 output LSB
8	Quad Encoder 3 output MSB	signed 16	(1ms/bit)
9	Quad Encoder 3 output LSB
10	Quad Encoder 4 output MSB	signed 16	(1ms/bit)
11	Quad Encoder 4 output LSB

(0 txed first, n txed last)

Note - quad encoder outputs are in ms per full period of quadrature output. Values are signed, where positive times yield forward motion, and negative times yield backward motion. Any specified period longer than 30 seconds (ie, value > 30,000 or < -30,000) will mean "Stopped"

Timing Considerations

On the PC side, it is best to transmit a packet as soon as it is ready, and then listen for the arduino's packet. Block until a packet is recieved, then read it, process it, generate a new one, tx it, and wait again.

This should ensure that the arduino will always have a packet ready as soon as it tries to read, and sent packets are processed as swiftly as possible.

Additionally, at least one side (possibly both) should flush the IO buffer after every read to ensure that the most up-to-date packet was read, and the buffer isn't building up (not desired in a real time system).