Over the last few years, the engineers at the company have invested both their time and sleepless nights in formulating a process for the development of Machine learning algorithms that will satisfy real-time constraints with minimal RAM usage. This is quite a tall task as per default, that would force one to do their development directly in C language. Although that seems like the right choice, the downside is the direct correlation of the debugging time with algorithm complexity.  Such a time could have been rather used in optimizing the algorithm within the MATLAB environment which has excellent tools for the analysis, plotting and debugging. So it was decided to rather learn the Code generation process with the hope that future algorithm could be designed in a similar fashion without the hassle of the compiler-specific run-time issues. The development of this machine learning algorithm would eventually be implemented in a 32bit, 160Mhz speed, 260KB RAM microcontroll...

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!

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

The generation of embedded aero tables from an automated process which uses Digital Datcom has now been checked. The phased approach was used. The longitudinal dynamics were checked first through effectively flying the glider ballistic in the pitch only. Once expected results were achieved, an initial sideslip (over 10 deg) was introduced at the start of the simulation causing the excitation of the lateral and directional aerodynamics. The checking of these was more tricky as one needs to have a good understanding of the geometrical effects of fixed-wing airplane on its aerodynamics. Below show some plots of the angle of attack and sideslip in a disturbed ballistic trajectory whereby all channels of the aircraft are excited. Given that now we have 6DOF simulation model with a complete aerodynamic model, flight control design and introduction of actuator dynamics can now proceed.

So decided to upload my coding scripts and share it with the world. I'm not officially in the #opensource business. One actually gets to realize that the only to harness an idea, is to throw it out in the open. #uav4africa #coding #movingup http://ift.tt/2f1HHqB via Instagram http://ift.tt/2equZ8k

So as most of you know, I've finally decided to develop a generic script that will be used to generate aerodynamic data using Digital DATCOM. It's been a long-winded process but I'm almost ready to do some testing on it.

So I've decided with the change of the DCM matrix and PI controller for navigation to change fundamentally the code layout with the use of data structures to make more sense of the information been passed on. I also spend most of list night trying to get my head around whether float division is really such a problem. We'll based on references xxx and xxx it is. Float memory allocation is not a real issue but float division can really boggle down your code to the core of tortoise pace. So this reference xxx explains that one can find an alternative around this issue which should speed things up quite a bit.The fact of the matter is that float division should really be an exception in any type of code (irrespective of the compiler and host). A lesson well learnt.

Yeah that's right. Everywhere you go, including some intern projects at my company, quadcopter drones is the current trend. The marketing success is simple. It's a lot cheaper and less complex and than a comparable RC helicopter. They're virtually no mechanical moving parts (expect the platform itself). And it's perfectly suited for camera attachment. So hot combination has spawned the quacopter drone revolution. I've always been against following a trend just for the sake of it. But considering that I need perfect weather test fly my flight controller only makes sense to start modifying my code to accommodate for a quadcopter. The controls are pretty straightforward and the design is incredibly simple. Another design dev coming up!

The Dx4e transmitter (currently that's what I'm using) creates alot of noise when used with arduino. It's quite clear that the receiver has a tuned low pass filter that needed to be emulated for the code. A low pass filter was implemented with a stategy of using a the gradient of 3 values to determine whether allow input to the servo signal stream or not. Here's the pseudo code below:

I finally managed to get my hands on the em-408 GPS receiver. After making provision on the autopilot board for the sensor and making sure that the OpenLog board could save the data, it was time to put this baby to its paces. It was no small feat I must add although the "old faithful" internet  was right there besides me to give me along. I found that there aren't many scripts that give an modular solution to allocating GPS data to variables in Arduino for further processing. So I made my own :). My approach was not to disrupt the internal timers of chip due to servo control. So the GPS board communicated with the rest of the system through the hardware Serial channels. This also enabled the processing of the data coming in prior to it being used in the rest of the system. So the aim of the board is to give heading coordinates to heading tracker function which in turn controls the roll and pitch controller. My plan is to use the haversine formula to calculate th...

The second part of the HILS was a functional test mainly to observe the functioning of the OpenLog board while the IMU and the servos were running. The logging was set at 38400 bps. The aircraft was moved in pitch, roll and yaw to simulate actual flight. The motor was turned on (without propeller attached) to Success Criteria - The logging should not have a loss of data and all IMU and servo variables should be recorded at a rate is for approximately 50hz. Results:  The figures below show that logging was capable at an approximate rate of 50hz. This will be tested in the field prior to the first logged flight.

As mentioned before, the aim of this test was to show that the autopilot board could relay power to the Receiver for servos to work. The InPins of the board connected all Rx signal lines (motor, elevator, rudder, switch (explained later)). The OutPins of the board had the ESC signal line and the corresponding servo signals (elevator and rudder). This configuration could be changed in the future in the event that ailerons are used (different test aircraft). Success Criteria - Displaying transmitter signal pulses coming into the InPins showing on the Serial Monitor.   Results: - The connection test worked albeit for a lengthy debugging exercise. The switch pin on the transmitter was able to enable or disable servo control.The figures of the results are shown below:

As my eyes began to light up thinking that the circuit board that I had built and script that goes along with it, will fast-track the logged flight, I was brought back to earth. Every time the OpenLog board was activated for logging, excessive jitter was experienced by the servos making a successful flight (and landing) impossible. So although the logging was successful (all data was recorded as expected), the jitter in the servos was not. After trying to debug for a few days, I read on the internet above the possible conflict of interrupts of the Arduino when the SoftwareSerial library (for the OpenLog) and the Servo library (Receiver, Transmitter and Servos). One way to solve the problem is to not use the Servo library for servo control and transmit the transmitter signal via digitalWrite command and wait for the next turn to do repeat the process. The problem with this approach though is that if the loop takes too long to come around, the servo will loose holding power and can ...

Over the last few days I took the bold step of putting my entire autopilot concept on a single board . Leaving the convenient use of Arduino shields behind and heading towards developing a full blown flight controller comprising of: - 3.3V additional regulator for sensor power supply. - 6DOF IMU - accelerometer and gyroscope - Magnetometer board - Logging capabilities (with OpenLog board) - 4 servo inputs (can be extended to 5 in the future) - Female headers for quick sketch modification and upload - LED light for testing purposes - Provision for a barometric altimeter and GPS sensor - Total board weight: 30g (as compared to the previous board or 90g) I've tested the logging of IMU and servo inputs and the board is ready for it's first Test bench logging test. I would have taken this straight up in the air but having learned that everything is in moderation, I realised that 'baby' steps is your ONLY friend . Complete Autopilot board bar Altimeter and...

So I managed to wire the OpenLog sensor and ran some few read/write code to make sure the wiring works as expected. And it works!!! This device will enable me to log any data that will be used for the flight controller design. This is prior to mounting a GPS sensor for waypoint tracking. The SoftwareSerial library has been used instead of the serial pins 0 and 1 so that only selective streams will be logged while leaving the option for bebug logging. On the custom board, I'll have to accommodate for quick removal of the OpenLog board in the event Logging us required somewhere else.

Like all electronics projects, the skill of "PCB making" is of paramount consequence. After doing my research, I finally assembled the ingredients to develop a servo control PCB. The Goal: I wanted the UAV to have be capability of Manual or Autopilot Mode while in flight as a safety option. This was to be controlled by the Control Station (RC transmitter for now) using a switch. The Parts: Single sided PCB board PCB toner transfer paper (I tried using HP Photosmart paper - DIDN'T WORK) Clothing Iron - Temperature set on "Medium" Wooden cutting board (Just beg the wife!) Ferric Chloride Solution (Here in SA try Mantech or RS Online Drill Machine Drill bits (0.6mm or 0.8mm). I used 0.8mm.  Plastic gloves (Please wife!) Plastic Container (Any container will do as long as it's plastic). So as the point 2 say, I tried using HP Photosmart paper  but it failed dismally. The glossy side of the paper melted and got stuck to the copper clad and it ...

The SDA and SCL bus lines for the three sensors (magnetometer HMC 5883L, accelerometer and gyro) were joined with not issues checked through the serial communication. (picture below). Biasing was completed with the following pseudo code. It makes use of a  running summation and computes an average once a number of measurements have been collected. /* This is a script to remove signal bias from filtered signal. Author: Paulin Kantue Date: June 2013 */ #define COUNT 50 //Number of values to be counted for biasing boolean computeBias(int raw_vec[], int bias_vec[], int8_t size_count, int8_t *bias_count){   int8_t counter = *bias_count;    boolean flag; // flag to compute sensor bias;   if (counter < COUNT){     for (int i = 0; i < size_count; i++){       bias_vec[i] += raw_vec[i];     }     *bias_count+=1;     flag = true;   }   else {     for (int i = 0; i ...