Skip to main content

Initial In-flight Testing of autopilot SUCCESS!

Depicts a traditional PID controller.
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 was a very nervy time as this could potentially lead to a uncontrollable airframe. But the safety switch algorithm was tested before hand it worked as expected on the day. This roll autopilot is a simple P of a PID controller which was not suitable. Although the PID architecture is coded, only the P gain factor is non-zero.

During flight (abeit short), the error gain was too aggressive which caused the glider to violently bank from left to right leading me to quickly switch back to full transmitter control mode.

The biggest headache of all this is not being able to have enough flight time at the park. Since these are soccer fields, I always have to look over my shoulder to see if people are about to invade the pitch. Very frustrating If you ask me.

Nonetheless, the autopilot in-flight testing has started and this is really exciting. It's now a matter of tuning the controller such that it enhances the stability margin of the airframe and not deteriorates it.

Exciting times ahead...

Comments

Popular posts from this blog

Setting up the Tarot T4-3D gimbal on the Pixhawk 2.4.8 with Specktrum dx6 Gen2 toggle switch

So i took the challenge of setting up the Tarot gimbal not just for inherent stable video footage but also the flexibility of controlling it from the radio control. However, I encountered quite a few challenges which made me aware that I'm not the one only in this battle . It's quite clear that the setup of the Tarot gimbal using its own software is completely different from how it's been described in the Ardupilot/Arducopter webpage and in mission Planner. In Mission Planner and it's associated site makes one believe that it should be done through software, only to realize that in actual fact the setup is more complex than that.  After two evenings of trying various combinations, I realized the getting the pixhawk Aux channels to communicate with the T4 gimbal requires the following steps: - The Pixhawk Pin9 (Aux1) needed to be activated to pass through user-chosen channel from the transmitter. For the Dx6 Gen2 it was the channel 6, which can assigned the ...

Setup ArduPilot flight modes with DX6 Gen 2

Hi, I've looked around the web to get an understanding the setup of the Ardupilot flight modes with a Spektrum DX6 2nd generation and there was none. So I decided to write this blog. The few things to consider when doing this: Please follow the instruction given on the ardupilot webpage . Have the Pixhawk hardware connected to Mission Planner (I have 1.3.50 - Copter V3.5.3)  Use the display bar in the Radio Calibration page as a guide while changing the rate pulse widths on your transmitter. I've used switch D to change the pulse width ranges on channel 5.

Matlab to C/C++ code development - Some learning points

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