Ultrasonic Sensor Approach

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.

Progress Update

The main focus has been on getting all the individual components working together, It was decided quite early on that because the Barometer is not accurate to the ground that it would be hard to use to keep the quadcopter at a specific height during autonomously flight. To this end I’m using an Ultrasonic sensor as well as a MultiWii control board and Raspberry PI.

Already the MultiWii board and the PI are connected using a custom firmware I wrote on the MultWii to cut communication with the PI in the case of anything going wrong in flight, Returning control to the radio transmitter. The PI sends control signal through a serial connection to the MultWii with a level shifter in the middle.

I also looked into various ways of connecting an ultrasonic sensor and tried three approaches:

Sonar to MultiWii – This involves writing custom code in the firmware to send and receive signals from the sonar. The drawback is this uses one of the auxiliary channels for the controller, which is being used as a safety feature. The other channel is being use to arm the device making it possible to very quickly take control and turn the quadcopter off.

Sonar to PI – There is two ways of connecting sonar to the GPIO. Using resistors to divide the power or using a level shifter on the sonar’s echo wire. I went for the level shifting as I already have one being use and 2 free channels. The problem is the PI does not have a real time operating system making the sonar readings not accurate and causing the PI to have a high CPU load.

Sonar to Ardunio (With serial bridge) –   The sonar connects directly to the Arduino and using the new ping library the readings are incredibly fast and accurate. The problem with this is that is only one UART on the PI. To solve this I’ve tired making a serial bridge the forwards the serial signals between the Multwii and Pi through the Ardunio board, and sending the sonar data to the PI. In testing this works very well.

Looking at these approaches the last two actually would work. The Ardunio approach has the best result however the MiniPro board I was using stopped working while I was re-soldering some connections. So it has been put on hold until I can get a new one or fix it. (Note that other boards are two big to fit). For time being I’m trying to improve my code for the Ultrasonic sensor on the PI as this does work.

In addition to the problems with the MiniPro my Control board stopped working, so I’m using a spare until a new one turns up next week sometime.

Code wise I have a working PID controller and have writing a class for communicating with the MultiWii board, so I can fly the quadcopter using the PI. Everything just needs a little optimization and testing. I should soon be ready for a flight test; however I predict the outcome being bad because of the sonar sensor problems.

Hopefully in the next few weeks I will be testing autonomous flight and trying the Arduino approach in practise which should solve the problems.

Quadcopter Lives again!

As I mentioned in the previous post, The quadcopter had an issue where some of the ESC’s caught fire, This is likely to poor manufacturing.

This week I rebuilt the quadcopter using 4 brand new Lulin 30 amp ESC’s and a F450 frame. I used a commercial fame instead of 3d printed one because of structural weaknesses in the printed frame design. However I am very likely to switch to another printed frame design once it’s tested out.

The construction progress did take a fair amount of the time mainly because it was a different frame and the ESC’s had to be calibrated.  The end result was a pretty smoothly flying quadcopter.