Gibbot User Interface Communication v1

Communication Method

To communication between the robot and a PC, XBee wireless communication is being used. One XBee is connected to the PC being used for the user interface, while the second XBee is attached to the primary control board inside the robot. Currently, the baud rate being used for this communication is 115,200 bps; however, it should be noted that this speed for the XBee is really 111,111 bps.

Communication Protocol

As of July 31, 2014, the current protocol involves sending a one character command to the robot to initiate the data transfer. Once the robot receives this command, it will request all the data (encoder values, current, IMU data, etc.) and convert all of them from counts to their real-world value (i.e. angles (°), angular accelerations (°/s), linear accelearation (g), etc.).

Converting the values on the dsPIC as opposed to the PC as the benefit that if the resolution of any of the sensors is changed, the data received by the PC will already be updated to these changes; whereas, if the data is converted on the PC, changing sensor resolution on the board will result in changing code on the PC.

Another benefit is that if the robot is not moving, some of the data, such as the encoder values and others, are not going to be changing, thusly the time between updates can be slowed down if wanted during these idle times and then sped back up during active times.

String Format

To send the data as a human-readable string, the command character is 'q'. After converting all the data to their real-world values, the data was then made into a string using the sprintf command. After this was completed, the data was sent over the XBee link using the printf command. The main benefit of this format is that when the data is received, no typecasting or conversion is necessary as all the data is human-readable.

Information about the data sent can be found in the table below, where the first entry corresponds to the first data value sent out.

Sensor Data | Units | Data Type ---|---|---|--- |Lower Magnet Angle | ° | %i |Motor Angle | ° | %i |Top Magnet Angle | ° | %i |Motor Current | A | %05.2f |Motor Torque | mNm | %05.2f |Motor Temperature | °C | %5.2f |Battery Voltage | V (or percentage) | %4.2f |Accelerometer-X (Primary) | g | %5.4f |Accelerometer-Y (Primary) | g | %5.4f |Accelerometer-Z (Primary) | g | %5.4f |Gyroscope-X (Primary) | °/s | %5.4f |Gyroscope-Y (Primary) | °/s | %5.4f |Gyroscope-Z (Primary) | °/s | %5.4f |Accelerometer-X (Secondary) | g | %5.4f |Accelerometer-Y (Secondary) | g | %5.4f |Accelerometer-Z (Secondary) | g | %5.4f |Gyroscope-X (Secondary) | °/s | %5.4f |Gyroscope-Y (Secondary) | °/s | %5.4f |Gyroscope-Z (Secondary) | °/s | %5.4f

Although this method works and has its benefits, there are some problems with sending all the data out in a string. The main issue has to deal with the speed of sending. Once the dsPIC receives the command to start the data transfer until completion was timed at about 60 ms. This corresponds to roughly 16Hz if it was constantly streaming out data. This is much slower than the 30Hz update rate desired for the user interface GUI.

After timing different functions during the data transfer, it was discovered that the primary culprit for the slow speed was the sprintf function, which took about 33-40 ms with printf taking 11 ms. To increase the data transfer speed and meet the 30Hz goal, the string format was abandoned and replaced with a data stream format discussed more in the data stream format section.

Data Stream Format

To send the raw data, the command character is 'r'. In the data stream format, the functions sprintf and printf are no longer used as they slowed down the data transfer rate to a speed below the desired 30Hz update rate. Instead, a struct was used. After converting all the counts to their corresponding real-world values, they are put into a struct, before the whole struct is sent out in a stream of characters.

Information about how the data is sent out in the data stream format can be seen in the table below, where the first entry corresponds to the first data value sent out.

Sensor Data	Units	Data Type	# of Bytes
Lower Magnet Angle	°	int	2
Motor Angle	°	int	2
Top Magnet Angle	°	int	2
Motor Current	A	float	4
Motor Torque	mNm	float	4
Motor Temperature	°C	float	4
Battery Voltage	V (or percentage)	float	4
Accelerometer-X (Primary)	g	float	4
Accelerometer-Y (Primary)	g	float	4
Accelerometer-Z (Primary)	g	float	4
Gyroscope-X (Primary)	°/s	float	4
Gyroscope-Y (Primary)	°/s	float	4
Gyroscope-Z (Primary)	°/s	float	4
Accelerometer-X (Secondary)	g	float	4
Accelerometer-Y (Secondary)	g	float	4
Accelerometer-Z (Secondary)	g	float	4
Gyroscope-X (Secondary)	°/s	float	4
Gyroscope-Y (Secondary)	°/s	float	4
Gyroscope-Z (Secondary)	°/s	float	4
Total			70

Although the data received is no longer human-readable, there is a huge improvement as to the data transfer speed. The total time from when the start transfer command was received until completion was only 10 ms as compared to 60 ms when the string format was utilized. This would allow for 100Hz if constantly streaming, thus meeting the 30Hz goal and allowing additional time for sending the command over.