2013/Group 4

Objective
This page details the process of building the quadrocopter, the problems we encountered, how we solved some of them and what remained to be done. It also shows some videos and images of what was accomplished. First we provide some block diagrams of how is the system meant to work. Then some images of the quadrocopter while being built and some videos of it flying/attempting to fly. In the end we describe some of the problems we had, and the conclusions we reached. We also include the software employed.

Quadrocopter diagram
The local control is always in charge of sending the appropriate signals to the four ESCs required for a stable flight. It receives inputs from the physical world, collected by the sensors, and external flight commands. According to this data, the controller reacts.

Ideally, in our system, the local control can receive flight commands from two different sources. These would be selected by the position of the 'Flight Mode' switch, located on the RC controller. Depending on its position, the quadrocopter should receive manual flight commands, again from the RC controller, or from the global control (BeagleBoard).


 * quadrocopter_block_diagram.png

Power distribution
The battery supplies power, through the distribution board, to the whole system. The ESCs take the battery input voltage and convert it in an AC signal for the brushless motors and in a DC signal for the electronics, which in this case would be the local and global controllers.


 * power.png

Global-Local control interface
This diagram depicts how should the MAX232 IC be connected in order to "translate" the RS232 voltages to TTL/CMOS levels. In our case, this was required because the serial communication from the BeagleBoard side was going to employ RS232 voltages, whereas the DiscoveryF3 side required TTL/CMOS levels.


 * max232conex.png

Global Control
The global control algorithms are implemented in the Beagleboard Xm, and the concept is that the quadcopter is going to follow a path that looks like this:



So at all times the quadcopter must stay within the two parallel and opposing lines. Along the path there are laid out some markers that can be detected using edge detection algorithms, and then utilizing a feature extraction algorithm to filter out the specific shapes of the markers. The markers can have one of two shapes: either a triangle or an "X" sign. When the marker is a triangle, then depending on the orientation of the triangle, i.e. if the main vertex of the triangle is parallel to the camera -as the first 4 triangles of the path are-, then the quadcopter either moves forward. If the triangle is rotated sideways with respected to the camera -as the 5th consecutive triangle is- then the quadcopter first turns 90 degrees clockwise on the yaw axis, and then continues to move forward. Finally if it detects the "X" marker, the quadcopter just stays still and prepares to land.

At the same time as detecting the markers though, we want our quadcopter to stay within the lines and not divert from the path. Thus, we need to detect and correct the sideways drift that our quadcopter may have. In order to achieve that the optical flow algorithm must run in parallel with the edge detection algorithm, in order to keep a history table of the last movements of the quadcopter. So when the quadcopter strays from the path (i.e. it detects only one line instead of two opposing lines), it can consult this history table to see towards which direction was it's last movement (towards the right or the left of it's previous route) and compensate it accordingly (start moving to the left or right until it can see two parallel lines again).

So the activity diagram (and the main loop) of the global control algorithm looks like this:



Problems encountered
- After trying out some early flights, we discovered that we had 4 clockwise propellers; then we got from Group 3 two counterclockwise propellers.

- Setting up the correct PID values took a lot of time. A big, empty room helped a lot in order to be able to fly more "freely" and experiment more easily the different PID configurations. Matt, from Group 2, helped us at this stage by sharing some tips on the TauLabs Ground Control Station.

- Glue is not enough to ensure that the motors will keep a perpendicular position with respect to the quadrocopter plane. The wooden boxes are easily fixed to the rods; however, the rods tend to rotate around their own axis, giving the motors an angle different to 90°.

- The TauLabs version is easier to build on Linux, however, on a virtual machine, it was impossible to connect the global control to the GCS via Bluetooth. This was only possible on Windows, where building the software is more difficult.

- The first ESCs (RedBrick) were not as responsive as expected. When we tried to reflash them, as Group 1 suggested, we discovered they were already protected against reflashing. We decided to use different ESCs (HobbyKing) to reflash them with the SimonK software.

- The motor/propeller noise considerably affects the readings from the ultrasonic height sensors. An alternative has to be found.

- Setting up the tool environment (Ubuntu and OpenCV) in the BeagleBoard took a lot of time. Also, the drivers for the camera module were not available for use with OpenCV, which was why we were not able to do proper image processing with that camera.

- The hardware for the communication between the two boards worked as expected, so did the software part in the BeagleBoard side. However, the software side on the DiscoveryF3 board did not work. The local control board (DiscoveryF3) was able to send characters to the global control (BeagleBoard), but it was not able to receive any information.

Conclusions
There were two main problems which made it impossible for us to achieve a full autonomous flight: the lack of successful serial communication between to boards and the lack of camera drivers compatible with OpenCV.

Documents
- [[media:Report_group4.pdf|Final report.]]

- [[media:Presentation_group4.pdf|Final presentation.]]

Software
- [[media:flight.zip‎|Local control (only includes the 'flight' folder from the whole TauLabs project (referenced below)]]