Plant Robot Motor Controller Serial Communication Protocol Interface Contents - Purpose - Physical Layer - Command Packet Format - Packet Details - Commands - Updating Firmware Purpose This document describes the physical and data- link layers of the communication protocol between the main robot controller and the motor controller unit (MCU) being built by the locomotion team. The MCU communicates with the main controller over an RS232 link. A multi- byte command packet is described with rudimentary error prevention. The protocol was built to be extensible and provide great flexibility between the main controller and the MCU. Physical Layer Data is sent over an RS232 link. The baud rate is fixed at 57.6 kbps. A frame consists of 8 data bits, no parity and one stop/start bit (8N1). There is no flow control. Communication is full- duplex capable, although normal communication flow is half- duplex (request packet is serviced with a response packet). Communication signal should respect RS232 standard levels, namely +3 to +15V for logic 0 and - 3 to - 15V for logic 1.
Command Packet Format This section describes the format for MCU command packets. Table 1 Command Packet Format Overview Byte # Value Meaning 0x01 0x55 Start of Packet (SOP) 0x02 0xNN Transaction ID 0x03 0xNN* Length 0x04 0xNN Command ID 0x05 0xNN 0xNN* Payload (last byte) 0xNN* Checksum Note: When the SOP byte value is required in any other byte position than the Start of Packet position, an escape character (0xAA) is required as a prefix. The escape character must also be escaped in a similar fashion. Packet Details The start byte is a signal to the packet builder state machine that a new command packet is present. The transaction ID is a single byte that aids in pairing a request packet with a reply. The initiator of a packet generates a random transaction ID between 0x00 0xFF. The replying packet should reply with the same transaction ID. Note: The SOP and escape characters are NOT valid transaction IDs. The length byte is the number of bytes in the packet, not including the SOP, Transaction ID, and the Length byte itself. That is, it is the length of the Command ID and Payload bytes. The Command ID specifies the command that is being sent. For more details see the Commands section of this document. The Payload contains meaningful values that correspond to the particular Command ID. For example, in a Set Board State command, the payload contains the value of the new desired board state. See each Command ID description for details.
The sum of all bytes from the packet payload Command ID to and including the checksum is 0x00. The Checksum must be calculated, by adding up the Command ID and payload bytes as 8- bit signed values, discarding any overflow, and then negating the sum to create the checksum. Escaping Since it is possible that the SOP byte value may be needed in the length, payload or checksum, a prefix escape character is necessary to signal to the packet parser that this value is not to be interpreted as a start of new packet. Example Packets: Figure 1 Mal- Formed Packet SOP TransID Length Command ID Payload Checksum 0x55 0x01 0x02 0x01 0x55 0xAA This packet is a Set Board State command packet that attempts to set the board state to 0x55. However, the payload value of 0x55 will appear as a SOP to the packetizer and thus the packet will not be handled correctly. Figure 2 Well- Formed Packet SOP TransID Length Command ID Escape Char Payload Escape Char Checksum 0x55 0x01 0x03 0x01 0xAA 0x55 0xAA 0xAA NOTE: This is not a VALID packet and should not be used for validation purposes. Purely an example to show possible escape character scenarios. This is a well- formed packet that includes the escape character as a prefix to the payload value. This tells the packetizer to handle the next byte not as a signal character, but as a value. The length was also updated to reflect the escape character addition. Any escaping done in the payload portion of the packet DOES affect the checksum. Similarly, the escape character must also be escaped when used for its value. Notice in the above packet that the checksum is escaped, since the value happened to be the same value as the escape character. The checksum and any escaping to the checksum do NOT affect the length value.
Commands This section describes each Command ID and its purpose. Table 2 Command List Command ID Origin ACK 0x00 MCU SetVelocity 0x01 Controller GetVelocity 0x02 Controller ReturnVelocity 0x03 MCU GetWheelRotationCount 0x04 Controller ReturnWheelRotationCount 0x05 MCU ResetWheelRotationCount 0x06 Controller GetEncoderPulseCount 0x07 Controller ReturnEncoderPulseCount 0x08 MCU
ACK: 0x00 Direction: MCU Controller The ACK command is sent from the MCU to let the main controller know it has received a set state command (e.g. SetVelocityLeft) The payload consists of two bytes, the ACK d Command ID and the ACK payload message. The ACK payload message informs the host of the packet status. Byte # Value Meaning 0x01 0x55 Start of Packet (SOP) 0x02 0xNN Transaction ID 0x03 0x02 Length 0x04 0x00 Command ID 0x05 0xNN Command ID being ACK d 0x06 0xNN ACK Payload Message (last byte) 0xNN Checksum Table 3 ACK Payload Messages Byte 0x00 0x01 0x02 Status Message Command Success Faulty Payload Length Faulty Command ID SetVelocity: 0x01 Direction: Controller MCU This command changes the speed of the motor for the left and right wheels. The new speed is represented in the payload as an 8- bit signed integer (positive velocity corresponds to forward motion, negative velocity for reverse motion) for each wheel. The first byte set the velocity of theleft wheel and the second byte sets the velocity of the right wheel.
Figure 3: SetVelocity Payload Bytes 15 14 13 12 11 10 9 8 LEFT_VEL[15:8] 7 6 5 4 3 2 1 0 RIGHT_VEL[7:0] Bit 15:8 LEFT_VEL Bit 7:0 RIGHT_VEL Signed 8- bit integer to set speed of the left wheel. A positive velocity describes forward motion and a negative velocity corresponds to reverse motion. Max speed achievable (0x7F) is 10 inches/min. Signed 8- bit integer to set speed of the right wheel. A positive velocity describes forward motion and a negative velocity corresponds to reverse motion. Max speed achievable (0x7F) is 10 inches/min. Response: An ACK packet is returned to the host in response to the SetVelocity command. The ACK packet will return either Command Success or an error message outlined in the ACK command section. GetVelocity: 0x02 ReturnVelcoity: 0x03 Direction: Controller MCU (CMD ID:0x02) MCU Controller (CMD ID:0x03) The GetVelocity command is sent from the Controller to the MCU. The command requests the current velocity setting for both wheels. The payload of the command is empty. Response: The return command (CMD ID: 0x04) is sent from the MCU to the controller with the signed 8- bit values as its velocity. The first byte in the payload represents the left wheel velocity and the second byte represents the right wheel velocity. Note for checksum calculation all values are treated as unsigned 8- bit characters. Figure 4: ReturnVelocity Payload Bytes 15 14 13 12 11 10 9 8 LEFT_VEL[15:8] 7 6 5 4 3 2 1 0 RIGHT_VEL[7:0]
GetWheelRotationCount: 0x04 ReturnWheelRotationCount: 0x05 Direction: Controller MCU (CMD ID:0x04) MCU Controller (CMD ID:0x05) The GetWheelRotationCount command is sent from the Controller to the MCU. The command requests the current wheel count since the previous reset or initialization. The payload of the request command is empty. Response: The return command (CMD ID: 0x05) is sent from the MCU to the controller with the number of wheel rotations. The wheel rotations for each wheel are represented by two bytes each. The result is a 16- bit signed integer for each wheel. A positive value indicates rotations forward and a negative value represents reverse motion. Figure 5: ReturnWheelRotationCount Payload Bytes 31 30 29 28 27 26 25 24 LEFT_ROTATIONS[15:8] 23 22 21 20 19 18 17 16 LEFT_ROTATIONS[7:0] 15 14 13 12 11 10 9 8 RIGHT_ROTATIONS[15:8] 7 6 5 4 3 2 1 0 RIGHT_ROTATIONS[7:0] ResetWheelRotationCount: 0x06 Direction: Controller MCU The ResetWheelRotationCount command is sent from the controller to the MCU. It resets the internal counter that keeps track of wheel rotations Response: An ACK packet is returned to the host in response to the SetVelocity command. The ACK packet will return either Command Success or an error message outlined in the ACK command section.
GetEncoderPulseCount: 0x07 ReturnEncoderPulseCount: 0x08 Direction: Controller MCU (CMD ID:0x07) MCU Controller (CMD ID:0x08) The GetEncoderPulseCount command is sent from the Controller to the MCU. The command requests the raw pulse count from the encoder of each wheel. The payload of the request command is empty. Response: The return command (CMD ID: 0x08) is sent from the MCU to the controller with the number of raw pulses counted. The pulse counts for each wheel are represented by two bytes each. The result is a 16- bit signed integer for each wheel. A positive value indicates rotations forward and a negative value represents reverse motion. Figure 6: ReturnEncoderPulseCount Payload Bytes 31 30 29 28 27 26 25 24 LEFT_PULSES[15:8] 23 22 21 20 19 18 17 16 LEFT_PULSES[7:0] 15 14 13 12 11 10 9 8 RIGHT_PULSES[15:8] 7 6 5 4 3 2 1 0 RIGHT_PULSES[7:0] Updating MCU Firmware (MSP430) All host communications are processed by the on- board MSP430 microcontroller. The MCU has a 2x7 JTAG connector that is standard to the MSP430 microcontroller family. Texas Instruments offers a USB JTAG communication tool that provides USB JTAG connectivity (MSP FET- 430UIF). When programming the board, the MSP430 must receive power, either locally or from the JTAG tool.