• results
  • appendix
  • future work
  • analysis
• user interface
  • control protocol
  • GUI
• software
  • extra functionalities
  • height control
  • motor control
  • wireless communications
  • UART communications between subsystems
• hardware
• cse 466 project home

Results > Conclusion

Contents:

Results and Analysis | Discussion | Conclusion

Results and Analysis

For the blimp’s height control performance, we performed some measurements by first placing the blimp into autonomous height control at a set height. Then, the blimp was moved to a different height (in order to simulate the abrupt change in height) where the blimp would then stabilize itself. Because our design didn’t include the feature to manually change the set height from the GUI, we then simulated another abrupt change in the set point value by moving the blimp to a different height location and then let the blimp stabilize (entire method is given in third lab specification). Throughout all of this, data was collected and then analyzed by graphing the height of the blimp height as well as calculating the mean squared error (MSE) to determine the overall performance of the height control.

Looking at the graph, it would seem that the blimp seemed to do a relatively adequate job of maintaining a certain height. After initial stabilization, the height of the blimp didn’t vary much , maintaining the height around the set point (150 throughout both readings). However, this changed once the blimp detected some noise (sensor value read 0 a few times), causing the blimp to oscillate with some intensity. Before the blimp was able to stabilize at the set height, our group moved the blimp to a much lower value as our measurements already went beyond the 20-second limit. However, the blimp seemed to do a better job after this as it instantly reached the measured height. Unfortunately, despite the performance seen by the graph, the mean squared error calculated from these data points resulted in an error of 1218.922 using the set height of 150 and the respective 157 data points (sum of 191370.8 calculated), a incredibly large number when looking at the relative differences between the set height and the measured height. Ultimately, the MSE was quite high because the blimp detected irregular sensor heights of zero, throwing off any sort of stabilization. But, when analyzing the overall performance altogether, the high error could be due to our failure to implement a height control algorithm that would account for the oscillating movement of the blimp (e.g. Kalman filter).

n addition, our group measured the performance of the control loop using the continuous sampling of the IR sensors by the GUI. By default, our user interface sent packets to the blimp to for sensor information with the respective IR sensors to be read. Thus, we utilized a counter (on the user interface side) to keep track of the time and then kept track of when the GUI received the data packets from the blimp with the IR sensor values. For our test, we kept track of the packet arrivals within a time interval of 30 seconds and then averaged the total number of packets received with the total sampling time to get the control loop rate. After sampling, we found that a total of 62 packets arrived, meaning that our control loop rate was held at about two packets per second which is a relatively slow rate. However, we realized only afterwards that this rate was much slower than it should be partly because the packet data sent back to the blimp accounted for sampling of all the sensors, resulting in a much higher delay than expected. Unfortunately, due to time constraints and code implementation, we were not able to measure the faster control loop rate.

In terms of the overall wireless communication between the user interface and the blimp, our group tested the communication link by using Realterm with the wireless communication modules by itself to send data back and forth between computers. For this test, we sent packets of data with varying sizes at varying sending speeds to determine the reliability of our UART and wireless design. From this, we determined that with small packets (ranging from 1 data byte to 10 data bytes), regardless of the transmission speed, always were received without any errors. However, with large data packets (above 15 data bytes), a byte or two would on occasion be dropped at high transmission speeds, which was understandable when accounting for noise and wireless communication speeds using radio frequencies. | Back to contents |

Discussion:

Within the project, one of the challenges we faced was designing a communication protocol that met the asynchronous requirement. Initially, we had designed a communication protocol that would allow the user to send a command to the blimp and receive data back reliably using a back-and-forth data relay. However, we realized that this design blocked any reception from one particular device when listening to the other (blocked either UART or wireless reception), violating the asynchonrous requirement (stop-and-wait approach is considered synchronous). To overcome this, we analyzed another method with the lab TA and implemented that method. Another challenge faced was understanding the SimpliciTI API. Because of the lack of examples or clear documentation, our group had a hard time trying to get the wireless modules to link correctly, taking us about a week to establish a connection with the SMPL_Commission function. To overcome this, our group looked at sample code from the website and the code provided by the lab TA to understand how to set those functions up and use them. Also, getting the IR sensors to work was a considerable challenge for our group. Unknown to our group, there were several pieces of equipment that had the potential to interfere with the IR sensing capabilities of the blimp (the fluorescent lamps). As a result, our group consistently got a zero reading from our sensor and kept trying to “fix” the sensor. Our group finally overcame this when the lab TA noticed this unusual behavior and pointed this out. | Back to contents |

Conclusion:

Overall, the primary goal of this project was met as the blimp bot, user interface, and communication protocol allows for user operation of the blimp. The features defined in the lab writeups were all implemented and met; motor control with PWM, IR sensing and height control, a start/stop command, asynchronous communication over a wireless protocol, UART functionality, a blimp GUI, and static communication linking. Maybe in the future will this blimp module see more functionality or application in the real-world. But, all-in-all, the overall goals outlined in the CSE466 syllabus have definitely been applied and understood by all members of our group. | Back to contents |