-
Notifications
You must be signed in to change notification settings - Fork 6
Gibbot User Interface Communication v1
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.
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.
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 | °F | %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.
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 | °F | 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.
Although a lot of data is being collected, not all of it is being used by the user interface GUI. For that reason, there is another command besides 'q' and 'r' used for the methods above that return all the data. For just the data needed by the GUI, the character 's' is sent to the robot. The data returned in the data stream format is seen in the following table.
| Sensor Data | Units | Data Type | # of Bytes |
|---|---|---|---|
| Motor Current | A | float | 4 |
| Motor Torque | mNm | float | 4 |
| Motor Temperature | °F | float | 4 |
| Battery Voltage | V (or percentage) | float | 4 |
| Gyroscope-Z (Primary) | °/s | float | 4 |
| Gyroscope-Z (Secondary) | °/s | float | 4 |
| Total | 24 |
When the robot detects that the battery voltage has dropped below the set threshold, the robot should send out some notification to the PC. Once this occurs, the touchscreen window could change from the steel sheet - banana control panel to a "sleep" screen. This could entail an animation of the gibbot sleeping in a small part of the screen and information about the gibbot (history, internal components, etc.) on a larger part of the screen. This would allow for greater user interaction and better keep their interest during the periods of charging before user control can once again begin. Additionally, since there is no real data being sent out, the PC does not need to be collecting data at 30Hz at this time. Either that rate can be slowed or the PC can wait until the robot is charged-up.
Once the robot is fully charged, another command should be sent from the robot to the PC to change back to the user control screen and to resume collecting data at 30Hz.
The commands the robot would send to initiate these state changes have not yet been determined.