13. Back on track at last, found the solution to our UAV simulation problem!

Well here is the summary of the whole root of the Problem and its solution:

What we faced:

Its the own designed DSPIC30F4011 board (UDB3), which is designed for Simulation in Xplane specifically . We are using the latest code version. It simulates all the modes well without telemetry (with Serial_None in options.h). But if we enable any telemetry in options.h, micro-controller works well in manual and stabilized mode and in Auto-Pilot mode it gets reset.

We discussed this at the Gentlenav Group at Google Discussion Forum: You can access it below:

uavdevboard › GPS resetting in AutoPilot Mode

So coming back what the actual problem was?

We were using the older version of MPLab IDE (Version 8.36) which did not use legacy-libc file (meaning you could not use it in this version). This file is generally required to reduce the processing power of cpu accessed by the printf and scanf functions in the programs. Due to this the printf and scanf functions increased the micro-controller's cpu processing upto 65% which led to the micro-controller/G.P.S. resetting whenever we switched to the Auto-Pilot mode (ideal cpu processing is around 8%).

How did we solve it?

With the suggestions from - 

uavdevboard › GPS resetting in AutoPilot Mode - We switched to MPLab IDE Version 8.9 which used the legacy-libc file and thus we were able to reduce the processing of the cpu of our micro-controller to 10%.

(How to enable legacy-libc? Go to MPLab - Project - Build Options - Project - MPLAB Link30 - Use alternate settings - add/type " -legacy-libc' at the end)

We simulated our program again and this time when we switched to the Auto-Pilot simultaneously with the telemetry it worked just fine.

Special thanks to Robert, Pete and Bill at Gentlenav's Google Discussion Group and Morli at the DIY Drones discussion forum!!!

You may also access this conversation below:

UDBDevBoard Chats

DIY Drones - A newbie's guide to UAVs

12. Reading now-a-days

Now a days reading - A coupled estimation and control analysis for attitude stabilisation of mini aerial vehicles, by - Robert Mahony, Sung-Han Cha & Tarek Hamel.

11. MoBee - Video rights belong to Havard

The Harvard Monolithic Bee is a millimeter-scale flapping wing robotic insect produced using Printed Circuit MEMS (PC-MEMS) techniques. This video describes the manufacturing process, including pop-up book inspired assembly. This work was funded by the NSF, the Wyss Institute, and the ASEE.

10. Wow, this #UAV simulation is really testing our brains !

The problem of resetting G.P.S. is still persisting. We are trying to figure whats wrong. With the whole telemetry setup (Post 8. Simulation to confirm the U.A.V. telemetry) our micro-controller resets the G.P.S. when we switch to the autopilot mode. We thought that this was happening as individual components on the board (like the transmitter) may also be deriving voltage from our supply and also since data had to be simultaneously sent to two programs (Happy-Killmore G.C.S. & X-Plane Demo 9), this process may also be consuming our voltage. 

Therefore, we built a separate power supply for our transmitter on the testing kit. We used a 9 volt DC adapter and 7805 voltage regulator with 100 micro-farad capacitor. But we are surprised that the problem is still persisting. 

We also changed the serial data transmission mode also in the options.h file of the Matrix-Pilot code (from SERIAL_NONE, SERIAL_ARDUSTATION, SERIAL_UDB to SERIAL_UDB_EXTRA) and changed the UDB Board (tried UDB3_BOARD and RED_BOARD), but there you go, no improvements. 

Maybe there is something wrong with the program or maybe we are overloading our CPU. We are still checking it out.

Wow, this #UAV  simulation is really testing our brains !

9. What more do I want to do?

1. I am programming the U.A.V. with a couple of colleagues but I want to design a small robot on my own and,
2. Try to build a 3D model of our drone in a designing software (I think Solid Work will be good).

8. Simulation to confirm the U.A.V. telemetry

Today me and my team tried to test the setup that we had planned to perform the experiments for confirming the telemetry (mentioned in the  7th post of this blog). We built this set up to get an aerial view of the U.A.V.'s path and also to confirm the programming.

We utilized our DSPIC testing kit and two FTDIs - 

1. One to transmit the data from the DSPIC30F4011/4012 to Happy Kill-More Ground Control Station software (by enabling telemetry in options.h file) and 
2. Second to transmit the program data from the PIC to the X-Plane 9 (demo), which is a flight simulating software.

The video showing our setup working is below:

Since the DSPIC had to send data simultaneously to two locations, therefore it needed more power and hence consumed more voltage. 
Due to this during the simulation our U.A.V. was switching, uncontrollably, between the three modes of 1. Manual, 2. Stable and 3. Autopilot.
We concluded that this was happening as the two capacitors - each of 10 micro-farad (which you can see on the DSPIC test kit) were enable to handle the troughs in the voltage supply effectively. Hence to solve this situation we have decided to use a capacitor of 100 or 1000 micro-farad (16 or 25 volts). 

I hope that this will work and we will be able to perform our experiment soon. Wish us luck!

7. Testing - Comparing the original and modified code

1. First we will appropriately place (at 0,0 waypoint according to the runway of out topology in X- Plane 9) the U.A.V./drone both in gentlenav and gentlenav1 code (matrix pilot) and study the behavior of the U.A.V./drone.
2. Second we place the U.A.V./drone both in gentlenav and gentlenav1 code (matrix pilot) at some inappropriate point (i.e a lot away from 0,0 waypoint) and again study the behavior of the U.A.V./drone.
3. Then we will compare the results of the 4 flights and conclude which code is working better.

PS: Will try to get the videos uploaded of all the four flights in the next post (Post - 8).