# Beta1test. Some remarks

During last days  I did some test with the following setup:

• Throttle speed = 30 (this value does not permit the drone to fly but it can balance itself on the semisphere mounted on its base ).
• Roll target=pitch target =0.
• Command =1 ( only the PID controller for roll is active).When it is in this mode the motor1 and motor 3 ( pitch) are spinning at throttle speed.
• PID k : I change them in different tests to have a first comparison .
• Cycletime = 10ms.

Analizing the logs saved I find out those remarks :

# Alfa3test. Updated situation

I’m still operative…even if a couple of weeks ago I had some problem with the battery pack.It discharged and didn’t have any idea to be recharged again….

This happend while I was recording some data.In particular I was verifying the test structure behaviour in relation to the variation of the PID parameters.I did some recordings and I can now describe a little sucess: my theorical mathematical model is quite reppresentative of the real quadricopter behaviour.Here you can find the link

In those pics you can see the theorical (blu)  roll and real (red) roll while the pid control is working.

This is the case P=0.3 I=0 D=0.05 This is the case  P=0.5 I=0.7 D=1,75 I can use this important information because I can  verify in the math model the quad behaviour playing with the  P,I and  D , waiting to find a solution with the battery pack!

# Alfa3test. First tests and rc.py module

I did recently the first tests on alfa3.py.

I found some points where I have to work.

First of all the test structure is now limiting the quadricopter frame  to rotate without be affected by friction.So, when thw qpi is closed o zero degrees, The friction is higher and this riduce the rotationl speed of the qpi, so the system become more stable that expected.I have to review this part of the  structure.Maybe one test I can do is to increase the throttle, so the motor will push higer the qpi frame , reducing the friction.

Now the roll is mechanically limited at +/- 10 degrees. I now prefer to give more freedom on the qpi rotation, so I have to remove this constrain.

Let’s go now to the sw side. In alfa3 test I included a new module: rc.py (remote control).It has the target to leave indipendent the command input from the main control loop.So rc.py includes an object that can run as a parallel thread , that has the olny tak to wait for the user input. In this phaes the input is given by a keyboard, but I’m still already working on a web server that can receive input from any device with a browser (my smartphone , for example).

I’m not yet publishing the alfa3.py code , since the rc.py has a bug that I want investigate.There is  a delay between the input and the answer of the system.

# SW Dev: Math model for control loop

Before to start development of the python code, I tryied to create the math model that can reproduce the theoretic dynamic behaviour of a quadcopter.You can find it in  control_loop.xls.[Rimoved. See here]

Please, if someone interested can send me its own quadcopted data (length motor-quad center,arm mass,motor mass,total mass,hover motor speed,PID parameters)I’d like to put in there to validate my model.

Hypothesis:

• configuration +copter
• case study: Roll

Data:

• R.target is the desired roll angle
• R.acc is the angular acceleration(calculated respect the angular motor speed w of the previous )

Dynamic balance is given by:

(F1-F3)b=I R.acc Kprop(w1^2-w3^2)b= I R.acc

with Kprop=(Mtot*g)/wh^2   I=(Mbar*b^2)12+2*Mmotor*b^2

R.acc=Kprop*(w1^2-w3^2)b/I

• R.vel is the angula roll speed calculated as integral of R.acc
• R.curr is the thoretical roll angle calculated as integral of R.vel. This value should correspond ot the return of a gyroscope mounted on board of the real quadcopter. So using this model I can play with P,I,D parameters and find out teh best configuration.

# SW Dev: Intro controller loop

So far the sw development included basic functionality of jogging going to directly modify the speed engine and leaving the user to their modulation.

At this point I want to introduce the concept of control in which the ‘operator indicates the’ desired angle and the controller, our rapberry pi, must decide the speed ‘of the engines. The theoretical relationship between the quadcopter angle (be it roll, pitch, yaw, or a combination of them) can be found on the page of the quadcopter. The balance that you get is unstable and just a minimal disturbance (such as a breath of wind) can cause this balance is lost.

In reality we must also consider asymmetries of construction (structure, propellers, etc..), Or non-constant behavior of the motors.

That translates into the need to know:
• what ‘s the instantaneous behavior of the aircraft
• what ‘s the real relationship between angles and speed engines as different from the theoretical

For the first point we must introduce something that can read the current state of the quadcopter, say a sensor. In most cases, a sensor mounted on board as a gyroscope or gyro+ accelerometer.

The gyro returns the angular velocity from which the integral angle is achieved. The accelerometer returns l’ acceleration in its components x, y, z

Thus, known the current angle and the  target angle,it  can be possible to calculate the error and decide a strategy to modulate the speed of the engines.

This strategy results in a control method called PID.

It is assumed that the relationship between two variables (in our case motor angular speed and angle) is approximated to three components:
• Proportional (P) = kp * Ei
• Integral (I) = Ki * sum (Ei) * t
• Derivative (D) = kd * (Ei-Ei-1) / t

Where Ei and ‘target error between w and w ith current instantly, you’ cycle time of the loop where the various k must be determined empirically.

The pid so returns the variation of the motor speed in order to minimize E.

A loop that reads from the sensor, calculates the  correction with pid,applies the motor w is the basis of the angle control loop

In the future posts I will dedicate a specific description of the following blocks: sensor, PID and  control loop with the purpose of defining the final structure of the program.