Far too many drone companies have been involved in a journey that has been characterised by a short honeymoon. From an African standpoint, the journey was always delayed.  Most African drone companies have been involved in training initiatives , environmental initiatives and consumer journalism .  But the bulk of the drone development was performed in Asia , USA and Europe .   So it's no surprise that Venture capitalist invested mainly in Asian and American companies.  But given the recent reports and the foreclosure of big startups last year , the drone landscape has changed.  So a question needs to be asked, what would happen to up-coming drone manufacturing companies based in Africa? Below are three key aspects that we believe drone manufacturers need to take into consideration going to the next 3 to 5 years. Focus on Functionality One of the biggest elements when it comes to drone development is the ability to focus not just on the e...

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

So one of the main objectives of my PhD research was to achieve the difficult task of developing a learning algorithm for machine learning ( RBF neural networks to be more specific) applications, that would enable the prediction of drone propeller damage in real-time AND without altering the bought-out flight controller ( DJI Naza , APM , Pixhawk , etc...). The only way it could achieve that was by analyzing the outputs of the flight controller sensors and learn when a fault would occur. Well, I believe I'm getting closer to this objective (submission is Nov 2019). I've decided to include the two figures below which illustrates the training process (0.2 sec on desktop) and prediction time (0.008 sec) and the accuracy to the true dynamics of the quadcopter drone. In this case the pitch dynamics are being predicted. Although noise hasn't been introduced, it's quite clear from the graphs, that the learning algorithm has enabled the RBF network to accurately capture th...

So my pixhawk has finally arrived! Now it's time to get to understand the codebase and integrate my algorithms to the flight control suite. I've also gathered a few parts from a research quadcopter. The plan is to have it takeoff and demonstrate that it works!

So I've had to think hard about which route I wanted to take for my research. On one hand, I could go full customized process with every bit of code written by yours truly (including the the hardware design, soldering, testing and integration). This will mean a serious divergence from the primary focus of my research but the high risk could yield immense entrepreneurial satisfaction. I calculated that this route would probably add another 6 months to PhD research. On the other hand, as I've posted before , buy an off-the-shelf flight controller, focus on integrating the peripherals, up-ramp knowledge on the tested code suite and start working on integrating my research algorithms almost immediately. This route is substantially more expensive (Initial capital), but you then have a large community of users to inquire from. I've estimated about 2 month of extra work towards my PhD research. So the decision is now obvious. I've chosen to buy the Pixhawk 2.4.8 first....

It's amazing how a continuous search at possibilities eventually leads to finding a "needle in a haystack". Introducing the Teensy 3.6 development. It a 32-bit Cortex M4 ARM core with (FPU) at a 1/6th of the price of the Pixhawk (The Pixhawk runs the same chip although has double the Flash memory). Granted, it doesn't have any sensors but man, that's find. Did I also mention that it works straight with arduino code. This means that I've upgraded to the most powerful MCU in the market at the same price as an Arduino Due . Wow! I overcame my shock by going to Robotics in Centurion and getting my hands on this dynamite. It can even run X-plane flight simulation controls in real-time communicating through the USB port! Ok enough ranting and raving! The point is now I can test the embedded algorithms on a similar ARM-based microcontroller as the Pixhawk and conclude the testing and validation up to HILS level with the sensors in the loop (while emulating th...

It was time to decide. Playing small robots and chiefs with the likes of Arduino and the soldering iron was a nice learning curve but it had to come to an end. The bigger objective of this research was to integrate intelligent algorithm on a platform that was accepted by most engineers and hobbyists. The learning pain will be great, but the support community will be there to help. The need to do things properly and start from a good foundation given the experimental nature of this research is key. It's clear there will be limitations, but what's obvious is that whatever software I build will be implemented on an architecture that's continously changing and being upgraded due to the fast changing nature of current drone industry. So the sooner I get into this game properly, the better it will be for future algorithms. Given the function of software in the loop, implementing a whole range of algorithm will now become a breeze. The prospect of using cheaper materials to...

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

It's been a while (over three weeks to be exact) since I've flown the heli. I must say I was quite nervous at first knowing that it's the first few minutes of flying after a long time that are quite critical. I also acquired a headset for my gopro which also worked quite well. But none of that mattered because many headaches have taught me to not have a big head in things that I'm still learning. So only after the third battery did I start with Nose-in maneuvers and a bit of slow circuits. Now that the holidays are upon us (and I still don't have a carry case), I will have to repeat this flight when I come back. I was tempted to take it with so I can get some nice shots of nature and the sea side. But I realised that I can't afford to loose this airframe as when I come back the instrumentation of the IMU will begin. Accumulated flight time: 84 min

So I decided to build a new aircraft since my 2m glider only gave me limited flying options. This is was quite a quick project as all was designed in Solid Edge including the electronics. This enabled me to work out the mass and balance throughout the design process. The total weight sits at 250g. This includes autopilot and GPS. It's designed to have external servos and a shifting wing placement since it will have various payloads like a mini VGA camera. The electronics are housed nicely in the fuselage powered by a 850mAh 7.4V battery. I've removed the redundant magnetometer in the autopilot board. Still not sure on the CG placement, but from the crashed maiden test and the fact that the control moment arm is quite small, it's believed that the C.G. needs to be further aft from the wing main spar (which currently sits on the aerodynamic center).

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

Depicts a traditional PID controller. (Photo credit: Wikipedia ) I'm such an exciting right now. It's been over a year of putting this UAV glider with custom autopilot and electronics together and now we're at the pivotal stage. In-flight testing of autopilot and GPS waypoint tracking!! Decided to go for a flight test on Sunday morning before church (around 7am) eventhough I was performing the church band that morning (crazy I know). It was bitter cold but decided to push through. I must say that I realised that I need a small collapse table/stool to setup the instruments instead of the wet/moist ground. I was great to see that the transmitter code works as expected. There was no lag in the transmission of signals from transmitter -> autopilot -> servos. The turning of aircraft with rudder and elevator control was smooth and consistent. It was refreshing to see that the filtering algorithm worked well. Decided to test the roll autopilot first, this...