The objective for this milestone was to integrate the same model functionality developed and analyzed within the Matlab/Simulink environment into a mature environment that will be able to test most functionalities of the Flight controller software that will be flashed for real-flight testing. The decision was to either migrate the Ardupilot (in this case ArduCopter ) software into the Matlab environment or integrate the highly nonlinear quadcopter model with flapping dynamics into the Ardupilot environment. The former option would mean no easy integration with Mission Planner and the real-time sofware-in-the-loop ( SITL ) testing tool (which also includes the infrastructure to communicate with the Flightgear 3D visualization environemt, while the later with make use of singular environment although the software development effort would quite tedious and error-prone. It was chosen to go with the first option as this was thought to be lead to more mature verification method prior...

When will I fly again? I've been asking that question for a while now. After that expensive and silly mistake of loosing my Blade 300 CFX to some uncalibrated mass balancing, the wind of excitement was whiffed out of my spirit. I must say, this has allowed me to refocus my energies on the helicopter simulation model and how it should be modeled such that the research of the neural network algorithms could be easily prototyped and embedded into an autopilot software suite for HILS and flight testing. I must say, I feel like I've made quite a bit of progress on this front. Even though my spirit is itching to get something flying in the sky, the notion that I'm getting closer to creating a simulation environment where these algorithms can be tested, explored and refined for flight testing. I'm also grateful that during this time, my company has agreed to fund my research and I now the ability to procure the items that I need to properly get this research off the grou...

So I published a post a few days ago on attempting to write a complete conference paper in 20 hours. I must say, I didn't entirely start from scratch. I had jotted down some ideas, the content and the strategy on what to write was pretty clear in my mind. But yet, we all know that even at this point, conceiving a solid journal paper (6-page mind you) is still a considerable effort. So it came down to tools. I must say I've grown more fonder of the ShareLatex over the past few months. If it wasn't for this online Latex compiling and viewing tool and the use of Mendeley , I wouldn't be writing this post to say that pretty much completed my first journal paper since my M.sc in 2010. It's such a liberating feeling to know that I've got an opportunity to present my thoughts and ideas again. The past two days, I decided to work from home and even though I have other distractions (a two year old monkey a.k.a my son Sam), sitting in that garden and jotting do...

They say that you need to have a vision for yourself. You need to have intrinsic motivation that transcends your current reality and even beyond what makes sense to others around you. I've decided to put together a control system journal paper by using just 20 hours. Wait... what!?! Yep. That's right. Why not? If you try you'll never know! A famous author once said. "It's not what the vision is, it's what the vision does." Even if I don't pull if off, or the submission is rejected and thrown into the trash, the experience will stay and boy will it motivate me to try again! Aluta Continua!

It was another windy day of flying. That's when you appreciate flying the heli calmer weather. Managed to clock in 8 minutes of flight doing various maneuvers. included side hover. I decided to put my Gopro Hero4 silver to good use by capturing some videos from the ground. It was not the perfect angle although the dynamics of my flying in windy weather was obvious. I was very choppy on the sticks (due to wind mainly) which made me question how the challenge that's awaiting me when I turn this heli into autonomous machine. Had a bit of hard landing which bent/broke the landing gear. But the heli does not know any difference. Accumulated time: 52 min

So today was a really good day because I've managed to hit just under 15min of flight using the three batteries show in the picture and most importantly with a failure. The wind was alot calmer today which made flying a breeze (excuse the pun). I was also able to do nose in and slow circuits which was a huge confidence builder. Now on to the specifics: Even though I was doing tail control (and to be fair there's a pretty bandwidth gyro in the loop as well), I found that rotating the heli to get it into a nose in position caused quite a drift away from me so much so that I had to quickly bring to tail-in in order to recover the heli (achieved about two succesful crash-worthy recoveries - Yeah!). This could potentially be a inherent in the dynamics (which i think it is) or there's further tuning that's required. In any case, success once again. I can see why accumulating more flight time in bulk helps. You get to correct and improve that crucial confidence onto th...

So today was a day when I decided to increase my flight time per session. I've started using two battery packs which meant that I know have to change over and also do some tweaking/learning on the transmitter to have a more comfortable flight. Even though It was quite windy (which is pretty normal now), I find myself being quite nervous still, Although It will go away with time. It could also be that I know how powerful this heli is and that I'm really wary about doing too much too quickly. To my credit, the heli got away from to about 50m and 15m in height and almost freaked out. Luckily I didn't panic and slowly brought the heli back in eventhough I was really struggling to make out its orientation. I was tempted to run closer but I must say I froze a little bit. I realize the amount of wind pushed it away and I wasn't actively controlling the throttle on the heli. Now I know better. I decided to have a couple of landings (some of them really hard) s...

So it was my first flight with the Blade 300 CFX yesterday and like anything new, the rush not to end in an epic failure that will leave you gutted for days was upon me. After doing a transmission/range sweep I put the aircraft through its paces. Coming from the Blade mCPX heli, going through the structural modes of the heli caught me by surprise thinking there's something wrong with the heli, Anyway pushing through it, even with a slight breeze, managed to get the aircraft in the air and maintaining tail-in hover. Most of time was spent in getting a feel of the controls and the dynamics on the heli. It looks very responsive which made you think twice about having any sudden knee-jerk reactions on the radio controls. After 4min, I landed the heli with raw smiles all around my face. Good job!

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

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

So I got some flight time under my belt yesterday. I must say there's nothing better than seeing your flying skills improve with time ( I can't wait to get more batteries so I can get my heli in the air as well). Anyway, back to the glider autopilot . Managed to get the roll autopilot to stabilize the aircraft which was a great feat. Although because the glider is inherently unstable during banking (due to the battery pack sitting on top of the wing) the roll autopilot relies heavily in controlling the rates produced by the aircraft. This is still a problem as roll rate doesn't yet have a strong influence in the control loop . The same can be said about the pitch controller (which I had to land the aircraft, upload new code and launch again). Due to the lack of control on the pitch rate, the phugoid mode of the aircraft is activated and the aircraft goes into an unstable dives which eventually would cause a crash. The use of the safety switch mechanism logic has ...