Our H1 drone was finally ready to be tested with new detachable landing gear, 3-axis gimbal and the Gopro camera (powered by an extra 3S-lipo battery). The objective of the test was to test the flight modes (mainly altitude control and position control) via 3DR telemetry connection to an Android phone and the Tower app. It was quite noticeable that the quad needs alot more power to overcome in-ground effects at take-off. This is mainly due to the mass balance with the camera at the nose of the airframe. The altitude control mode worked quite well even at low elevation of 3-4 metres. Unfortunately, at low-battery voltage an automated landing doesn't occur and this resulted in hard-landing (more like a hard crash!). This piece of software will have to be investigated. The manual operation of the Gopro is a bit cumbersome. The alternative of using the WIFI link to operate the camera was investigated but was not deemed a good idea given the potential inteference...

So it turns out that I was very optimistic about just using a gain mixing of accelerometer rand gyros than computing a DCM matrix of the aircraft rotation. So I decided to overhaul the code by creating data structures that will hold the information requires for such computation. I must say that at the back of my mind I was really worried about the computational time that these calculations will take in the small Atmega328 micro. To my surprise, provided that one sticks with a minimum of division operands, float arithmetic is actually quite fast even in an 8-bit controller. Given that this application is for high L/D aircraft and who’s mission is mainly waypoint tracking, the slow changing dynamics can be reasonably captured with this environment. The bad part of the implementation was to discover how quickly the gyro drift (especially in the roll channel) hurts the computation of the Euler angles. (See the pics below), even-though all sensor are bias compensated fro...

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 ...

deadband diagram (Photo credit: Wikipedia ) Managed to squeeze another flight test on Sunday morning (the usual madness occurred afterwards). Had about 7 - 8 hand launches to test the pitch autopilot with the gyro measurements integrated in the PID loop . It was quite that some adjustment to the how these inputs are being used was needed. So after each landing, adjustment to the gains was made. The erratic nature of the control requires a deadband filter approach which would enable the airframe to settle on a particular flight path naturally (restoring motion). A crude logic was implemented and tested and seemed to work although further test will need to confirm such approach. From a kinematics point of view, it makes sense and prevents excessive servo control usage which decreases the life of the part dramatically. Once confirmation that the logic is sound, the same approach will be made on the roll and speed autopilots which will allow us in the next 2-3 weeks move towards...

We've been having quite bad (windy) weather that It has been almost impossible to get the glider up in the air to gather more flight data . But nonetheless, I managed to analyse the data that I have come to some interesting conclusion on the behaviour of the aircraft in flight. The post-filtering of the IMU euler angles prior to controller design only add approximately 4/10th of the second in lag (guestimate). The servo limiter which I set on all channels is which what a normal flight actuation is experienced (considering wind factors). It's quite clear from the graphs that GPS velocity is expected to change with aircraft pitch although the nature of the sensitivity over a 1Hz update was not expected. The noise factor in launch in both roll and pitch channels shows that an alternative method needs to be established for a take-off and landing autopilot mode. There seems to be a considerable lag in pitch servo input and pitch change. This makes sense for the fact that t...