So I've been battling to establish a simple method in mimicking rc control inputs during a sustained or coordinated turn of the aircraft. This is quite important as it's not the same as stabilizing controller which reacts to dynamic events while having a static reference. A coordinated turn has a dynamic reference which is coupled to the turn rate experienced which directly related to the speed and the roll command inputs. But since the turn rate of the aircraft can be extracted from the gyroscope measurements, it can be stated that post processing of these signals (using a low pass filter) should give an indication of whether such method can be used alongside a stabilizing controller. This is such that once a coordinated turn can be achieved even in adverse weather, waypoint tracking is closer to being realised. Amendment 15/1/2015: It was found after careful analysis of the flight dynamics of a simple aircraft that gyroscope measurements was not a fool-proof way of ...

So I had a brainwave the past two days in how to test various aspects of the autopilot modes without having to land and flash new software. It became very frustrating that for each morning, I had to land the aircraft 5-6 times and increase the risks crashing and even worse loosing the instrumentation on board the glider. This approach could potentially allow me to analyze various options of flight modes and optimize which one best suited for that function. The ultimate goal is of course, the speed at which each flight modes can tested. So I manage to devise a method that allows me to use a switching mechanism such that I can switch between each programmed flight modes by using transmitter only. The code was tested and seems to work just fine. Now it's just a matter of testing in flight.

This one is going to be quite short. Yesterday was the turn of the heading error algorithm to be tested. This heading error is calculated based on the heading the between two waypoints and heading measurement from the GPS module. This error will then be fed into a the roll controller as an input for roll command to reduce it to zero. But for the roll controller to work accordingly, the input must be right and within certain bounds. Same as the previous ground test, waypoints were loaded unto the autopilot and serial debug data was monitored using my Asus TF101 Tablet. It's worth saying that I managed to get serial data output straight from the LINUX command line . So the command line integration with VIM is complete. So it takes approximately under 10sec to upload and start debugging data of the autopilot. Sweet! Anyway, it was found that the GPS accuracy should be considered at 10-12m. Anything less than that and you'll be running for trouble. That is not a real conc...

So after a period of absence of over a month (feel depressed everytime I say it), I got back into the groove of things. Decided not to wait to get back on the field to test the pitch and roll autopilot and decided to start working on the waypoint tracking algorithm . The advantage of having your own home with a garden is that you no longer struggle to get a GPS lock (There's no more concrete flats surrounding us yeah!!!). So got familiar with my gear again. Also decided to buy a piezo buzzer that could be used as a replacement of the serial monitor. The aim was to increase the intensity of sound as you got closer to the next waypoint. In such a way you will know if you're going the correct way. Decided to use GPS Visualizer to get waypoints on the property. Re-formatted the points into the code uploaded it onto the controller. It must add that I managed to successfully run arduino from the linux command line and use the program screen as a serial monitor. Not only is it m...