Results
Summary
We found that using the same code on both the radio chips was a good strategy. By making them as “dumb as possible,” writing the code was simple and short. Things (like real checking) were done on the end points. For the motors, we felt that our mix of hardware and software interrupts was a good combination that was very power efficient. The MSP430F5510 was the real powerhouse that took in inputs, buffered them, read them, and depending on the opcode, put data to go into an output buffer. We felt that this flow control was very extensible with new features and provided us the leeway to do more taxing processing because it could buffer new input while it was doing the long task. The Java GUI was cumbersome to make but it provided the right libraries to make this work well. One of the issues that really caused a lot of trouble was the fact that all primitive numbers in Java are signed.
Finally, we did a computation on the performance of our autonomous altitude control system by computing the mean-squared error between the sensor value and the desired set point over a 10 second period after 10 seconds of making a change to the set height. In our test we went from about XXXXX feet to YYYYY feet.
Even with all this good performance, we would like to highlight some of the issues that plagued us while writing our code.
Unreliablity of Network
Even though the messages that were sent via the radio connection were ACK’ed there were some messages that were not correct (we saw this with the packets that did not start with the byte we were looking for). This can be due to the fact that some messages could not be sent due to the receiver being out of range or other errors while reading the UART. Unfortunately, on both the blimp and PC side there is no feedback saying explicitly that a message was interpreted correctly (this is a stronger guarantee that just ACK-ing the packets at the lower levels). With this improvement, communication would be a lot better between the end nodes of the system.
Compilier Issues
When writing code, there were some issues that came haunt us throughout our work. One of the most painful to debug was a line of code below (where sendChar is pointer to a char array and int_value is an integer).
*((int*)(sendChar+3)) = int_value;We found that this would give us bizarre results and the fix we used to get around this was:
sendChar[3] = int_value>> 8;
sendChar[4] = (unsigned char) int_value;Sensors Readings
One other issue that was not completely documented well was the fact that the leds used in IR sensing were not set to a constant value but was instead straight from the battery. So, a new battery could have completely different IR readings when in the same place than it would if it had a battery that had much less charge. This made it harder verify what the issue was among different runs when the battery changed. Regulating the led input voltage would be better. Furthermore, we found that the three colors of the lab floor was a huge source of errors. After some experimentation, we found that (at a specific battery) the black tiles gave an IR reading that was 1/3rd greater than the values of the beige and light blue tiles (which had similar readings). We found that keeping the blimp over the same constant floor type was key to good and consistent readings. Furthermore, we found that there was reflection around walls, so that is something that others working on this project in the future should anticipate.