Pi controlled Quadcopter

Since the last post, The motors have been replaced. I have spent a lot of time trying to get the quadcopter to level nicely, however  I’m still getting a lot of osculations and the system is still not complete.  I have attempted to use the accelerometer from the multiwii board instead of the sonar alone and found it to be quite smooth. However due to time constants I have been unable to fully integrate it to the auto-level part of the program.

I have however managed to write code for an automated landing. The uses the accelerometer to gently lower the craft until it is close to ground, at this point it starts lowing the throttle until the value is lower then a preset value and turns the craft off. At this point the craft is always on or very close to ground.

Unfortunately I very much doubt I will be able to dedicate any more time to this project for the time being, as I now have to finish up the documentation for this project as well as other paper based work for other modules for my  course. However I will likely continue this further after the final write up is handed in and will definitely will be posting again before the conclusion of my degree.

 You can also follow my personal blog Here

Unfortunately one of the motors on the quadcopter had died. This directly affected the tuning of the PID controller and until I can get my hands on a spare one, or more specifically install one next week I can’t test.

For the moment I have focused my attention on one of the substantial problems I have encountered over the last weeks is bad network reliability, where how of the blue I would lose connection to the PI on the LAN. Considering I’m using adafruits web ide that needs a connection to bitbucket to function correctly this has caused many issues.

I initially thought the problem may be with the router I was using, however after switching it out for a newer one I have still being having same issues. So I changed my focus to the PI as the likely cause of the problem.

I have thus far been using wicd, which is a console based wireless networking client that allows easy connection to new networks. This automatically switches between the networks and monitors the connection. To rule this out I’ve switched the manual approach of entering the wireless settings manually.

I have also seen various posts and discussions about the some wireless adapters dropping their connection randomly due to power management settings. For this reason I have disabled the power management by placing “wireless-power off” in my /etc/network/interfaces.

So far so good, It seems to be working very well. However being Easter holidays the UNI is shut and I won’t be able to test this properly until it is open again next week.

Since the last post, I have added a PID Controller to the quadcopter in the hope of stabilizing the oscillations experienced from my last test. I have also notice that the application causes a considerable amount of CPU load which intern has an adverse effect on flight and data communication. For this reason I have spent some time optimizing code and removed one of the three threads that were running.

I have been using a PID controller for python located here, However I have been unsuccessful in tuning it, In order to ensure I have a firm grasp of how these controllers work I decided to build one in C# from scratch.

As you can see from above the controller is fully functional, the main thing I learnt was how simple PID controllers actually are. Implementing the c# test application did not take very long at all. I have since ported the code to python for use on the quadcopter, to replace the existing one I’m using, Hopefully this will rule out external code as the problem source.

As far as tuning is concerned I have been using the Ziegler Nichols method of tuning, Where initially the Integral (K_i) and Derivate (K_d) are set to zero and the Proportional (K_p) gain is then slowly increased from zero until output of the controller oscillates at a ultimate gain (K_u), When oscillations level out. The ultimate gain and time constant (T_c) of oscillates is then used to set the gains using a table.

Thus far I have unsuccessful in tuning but intend to continue working on the problem over coming days and weeks until it solved as it is a key part of my project.

 

Unfortunately the replacement Ardunuo board took longer than expected to arrive which delayed getting the ultrasonic sensor working considerably. Once assembled the sensor worked very well, however it was observed that when it is powered from the 5v out from the PI the values unusable, this is likely because the PI did not have enough power for the sensor and the Ardunio board, However the sensor works fine when powered from an ESC.

Additionally the control board for the quadcopter has been replaced with a smaller version which does not have a barometer, However this is not a problem as the barometer is not accurate enough the keep the quadcopter as a certain height at low altitude.

Flight Test:

For this test the Raspberry PI is controlling just throttle and attempting to keep the copter at 30cm from the ground where as the rest of the movement is controlled manually. The test is using a simple bang-bang controller so once it reaches a certain height it lowers the throttle and once is under it increases the throttle. This creates extreme oscillations in flight, which is unsuitable for a sustainable flight. However considering the obvious problems the flight was very successful in the sense of the PI being able to control the quadcopter.

The next stage is to implement a PID controller that will generate an error value which will be used to increase or decrease the throttle, hopefully creating a smooth movement.

Currently the Raspberry PI is putting a considerable amount of load on one the ESC’s which is getting pretty hot, Additionally the PI has had poor performance when connected to copter which has made it hard to test. For this reason the next step is to replace 5v power from the ESCs (Powering the control boards) with an independent BEC (battery eliminator circuit) providing higher power.

I have spent a considerable amount of time working on the code to get the sonar working straight of the PI. However because of the lack of interrupt support. This approach is not suitable for the project due to amount of errors and the high load on the CPU.

Instead, I’ve tested with the sensor connected to a Ardunio Uno and the PI. Instead of using serial I have used I2C to get the values. This was very successful and I was able to get >20 results per second. I did also look at using SPI but opted for I2C because is seemed easier to integrate and less wires.

The next step will be wiring this up with a smaller Ardunio board and testing this out in a flight test.