Demonstration

Software

The Software was developed to test and debug the Drone in its developnment stage. It shows live charts with the IMU, engine and controller data and enables the user to capture a trace. Moreover it is possible to do various configurations on the Drone, such as setting the parameters of all Controllers.

Features

• Start / Stop the engines and the controllers
• Control the Drone with sliders or an USB Joystick
• Communicate over a serial or bluetooth
• Configure the PID controllers
• Live 3D view
• Live charts
• …

Serial port / Bluetooth

Windows provides a serial port when connecting bluetooth devices to the pc. The software can connect to bluetooth devices even without the manual connecting process, this simplifies the process and eliminates the manual input of the Bluetooth pin.

It is recommended to use the serial port instead of directly using the bluetooth implementation as the bluetooth stack often times out due to the lack of implementation in the Windows Bluetooth API.

A quadcopter is generally a very unstable system, that is very hard to control. The tricky parts are generally two things:

1. Getting reliable sensor data is very hard
2. The controller needs to be fast enough

Control

Aquiring usable sensor data

As the Quadcopter is floating in space, it has multiple degrees of freedom.

• 3 degrees of freedom for movement (x, y z)
• 3 degrees of freedom for rotation/angle(pitch, roll yaw)

In order to aquire all this data, a powerfull sensor system has to be used. In this case a system that uses 9 distinct sensor values which include:

• 3 axis accelerometer
• 3 axis gyroscope
• 3 axis magnetometer

The sensor we used is a Vectornav VN100 Altitude Heading Reference System (AHRS), this sensor module already implements all compensation algorithms, filters all sensor data and combines them into the current angle the sensor is heading.

Controlling

Controlling the quadcopter is almost as tricky as aquiring usefull sensor data. Our first approach was to control the motor PWM directly, by setting it according to the angle that has been received from the sensor. The problem with this “easy” approach where only one PID controller would have been used was that the system got too slow to react to changes. This resulted in a quadcopter that was not flyable.

Therefore we headed for a different more methodical approach. We started controlling the system from ground up – layer per layer.

So we ended up with a multilayer cascading structure:

RPM controller

The first layer of control is the RPM controller of the brushless DC motors. The small ATmega processors on the outside of the quadcopter only do the basic commutation and the measurement of the current RPM values. As the brushless motors can rotate with up to 32000 RPM, the small 8 MHz clocked ATmega processor can’t do the actual control, so the RPM control has to be done from the main processor. To get an adequat transfer function of the motor and the PWM control a Matlab interface for the drone has been implemented. With this Matlab interface it was possible to do certain measurements for PWM vs. RPM, which allows to measure a precise transfer function of the brushless dc motors.

We ended up with a quite adequat transfer function for motor control:

Transfer function:
           5.363
z^(-2) * ----------
         z - 0.9575
 
Sampling time: 0.005

Using this transfer function – that is basically a PT1 with dead time, we were able to build a simple PI controller, that enabled fast and reliable control of the motor.

With an overshoot of maximum 10% and a desired regulation time of 50ms we ended up with a discrete time PI controller with the following parameters:

Transfer function:
0.02677 z - 0.02498
-------------------
       z - 1
 
Sampling time: 0.005

Kp =

    0.0268

Ki =

    0.3569

Which leads to the following frequency response of the open controll loop of the RPM controller:

Using this regulator resulted to a fairly stable RPM regulation. The simulation results were really close to the actually measured results. The following step response compares the unregulated system with the controlled system.

Rotation speed controller

The next controller on top of the RPM controller is the “OmegaController”, this controller tries to regulate the rotation speed (the change of the angle the quadcopter is heading). This controller gets it’s data directly from the gyroscope on the VN100 sensor module. This gives us a very stable control of the flight of the quadcopter, as there is no need to wait for the angle data from the sensor module (would be additional dead time). With rotation speed controller enabled, the quadcopter ist stable in air, at a certain angle, so it tries to hold the quadcopter by minimizing the rotational movement.

All measurements have been done by tieing the quadcopter to a string, and let it rotate in open space – this resulted in the following step response:

The approximation of this transfer function resulted in a system of third order.

Transfer function:
           1.842 s + 0.8582
---------------------------------------
0.0007561 s^3 + 0.3641 s^2 + 2.01 s + 1

Designing a controller for this wouldn’t be too hard, but there was one massiv problem. An integration was not possible!

The sensor data is sampled using a discrete time sensor (so only one value at a time is sampled) – this has the massiv downside that integration may lead to a continous error as the mean of the sensor values drift due to measurement and sampling inaccuracy. This only allowed us to implement a simple P controller.  (KP = 2500)

Implementing this controller we ended up with the following step response:

Angle controller

The next and final step for a flyable quadcopter is the angle controller. This angle controller is designed to hold the quadcopter horizontal.

For this controller the caculated angle data from the AHRS sensor is used – this data acts as horizon to which the drone can be controlled to. As with the rotation speed controller an integration is not really possible, as sensor drifts are problematic.

The parameters for this controller were hard to measure (step response is not possible) as the system is completely unstable without controller.
Therefore an approximation according to Ziegler & Nichols has been used. This involved:

1. Implementing a P-Controller
2. Incrementing the P value till the system gets at the edge of stability
3. Use 1/2 of P to get a stable system

After implementing this controller the quadcopter was stable in mid air.