Tag Archives: IMU

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 :

  • The cycle time average is = 11ms, sometime I get a pick up to 21ms.I need to investigate on this .beta1_cycletime
  • I need to compare data from different logs coming from different threads (main loop and sensor for the moment).So I just modify the code including a column that reports the absolute time. This can allow me to match the 2 logs.
  • When I switch from command 0 (no PID controller) to 1 (roll PID controller) I notice a pick on the motor speed. I find a bug: one data initialization missing.Now it is corrected.
  • When I switch from command 0 to 1 it takes around 1,5 sec to start to balance,evenif the  difference in motor speed is already high. Possible explanation (to be investigated) is the inertia effect (to start the movement).I should allow a bigger speed correction.
  • Right now the best result is obtained with Kp= 0.6 Ki=0 Kd=0.5. I will try increasing a little the Kp and reducing the Kd.beta1_balancing


Alfa3test. PID introductionand more…

Starting with this series of tests Alfa3,I added some new features that move the project to the final setup.alfa3_pic1In particular I add the following modification that allow the system to work wireless:

  1. I added a second ESC and a second motor.
  2. I modified the connector board adding a new 3 pin connector (C in the photo) where there is the zero volt (black wire),  the signal (white wire) that is bridged with the 4th signal (green wire), and also added the 5 volt (red wire) .connector_board In this way I can choose if rpi is powered by  the ESC (C connection) or not (B connection).
  3. So the schema for this test consist of the connection of motor M[0] in A and motor M[1] in C.
  4. I connected also my wifi dongle in the rpi usb port. I discovered that neither the pc nor the wifi dongle can act as access point. You can verify this using the comand:

iwconfig ap

So I used my smartphone activating the router wifi function,building up a network including the PC and the rpi.

Below the references used in the test:


  • M[0] turns counterclockwise, the red wire is connected to the “T” wire of the esc (the one that is closer to the T of the Turnigy logo),and the yellow wire to the “Y” wire , the black wire with the center wire of the esc.
  • M[0] mounts a standard left prop.
  • M[1] turns clockwise, the yellow wire is connected to the “T” wire of the esc ,and the red wire to the “Y” wire ,the black wire with the center wire of the esc.
  • M[1] mounts a right prop. (marked  R).
  • According to the position of the IMU,I have a negative roll rotation if M[0] moves down.

I did already some tests with this configuration. In the next post the first results and the description of th enew sw module rc.py that is the remote control module.

Alfa1test. First results

After some delay I’ve been finally able to test the  alfa1 test.

As programmed, I first checked out the motor control.

After the start up phase (push enter when requested),a simple user interface shows the current roll , pitch and yaw. I can increase (a button)  and decrease (z button) the motor speed.Press space bar  to quit.

I can save the hover speed Wh ( n button) and set it again (h button).

For the specific setting that you cna find in th epicture the Wh is around 15/17%.


Below some practical notes:

  • If the motor is turning clockwise (looking fro the top), mount a rigth prop.
  • Respect the first tests done , it is possible to simplify the esc start up procedure ,so i can leave the esc power on , evenif the pwm is still not  pulsed. I would underline that this tests are done specifically for my own hw set up. So first of all, put all teh necessary attention on safety.
  • Put a nut and a nut over the first one. The vibrations are so important that a sigle nut bifore or after will fall down, indipendently from which force you put to close it.

The sensor is recording for every cycle :total time,cycle timedt, r,p,y calculated by complementary filter  r_rate,p_rate,y_rate, from gyro e x_acc,y_acc,z_acc from accelerometer.

If we now take a look on the recorded data, the first thing that pops up is the cycle time increasing along time:


In this example,it moves from 8ms to 12ms in 2 minuts.

The possible causes are:

  • a bug in the sw for the dt measurements. I can exclude it after a first check.
  • a delay proportional to the dimention of the log.A simple test can confirm me this theory:it is enough to store for every cycle 3 time the nformation. If the dt will rise 3 time faster, it will confirm the theory.
  • a problem on the sensor. Could it be that I’m requiring  data from sesnor to frequently?I’ll investigate this case only if the second one is false.

Let’s now have a look on the result itself. The graphs with the roll below show the measuraments done with different sensor low-pass filter setting ,with motor running on the same speed.

The first case is a DLPF = 40Hz : (roll varies between  8 and  13 degrees)


In the second case DLPF: 10 Hz: (roll varies for some tens)


The last comment is the analisys of the roll obtained from gyro, acc and from complementary filter:


The comp roll (gray) has still a lot of oscillations. This graph has been obtained using a time constant tau of 0,005s.

The same log recalculated with a tau 0,2 s results as this:


Now the roll has no disturbance at all.

For time periods less then 0,2 seconds the value of the gyro is predominant (so we can eliminate the vibrations from acc) .For greater time periods the accelerometer value gets predominant ( so the gyro drift effect diasppears).

In conclusion , in the next steps of my development I ll use DLPF=10 HZ and tau=0,2 (those value are already in the available code).

Alfa1 test.Preparation

During the last wekend I have been busy,so it was not possible to continue the testing.

By the way now it comes a new post where I describe the code I created for what I called alfa tests, a session of experiments to prepare the final code.

Alfa1 test includes the following functionalities:

  1. manual motor jogging
  2. IMU reading
  3. data logging (motor w,and IMU angles)

The actions I want to take during this test are:

  1. verify the disturbance on  IMU data due to motor vibrations
  2. test different IMU filter values
  3. start the motor and  try to understand which is the hover w  (motor angular speed) according to the current configuration
  4. Start the motor and understand  how a deltaw can influence angle of the quadricopter
  5. mount different weights on the quadcopter arm and see the different  wh (hover w) in order to verify my math model.
  6. measure the actual motor angular speed with my smartphone (just curious abuot the possibility to measure the real w  with a sound spektrum analyzer).

Hope to start tomorrow the alfa1 test, than I will share the  code.

Preparing test session

It’ is now time to move from my desk to the garage to start the second phase of the development.

The targets are:

  • verify the start up procedure of the esc. I want to see if and how  I can start up properly the esc evenif it is already power on. This is useful in case I want to power rpi directly from  one Esc BEC.
  • verify the disturbance in the IMU data due to the motors vibration.Setup in the best way the filter severity
  • verify the control loop and tune the pid parameters for quadcopter rotation
  • develop the user remote control via wifi to control motors and quadcopter position

To do this tests I build up a frame that I hope it can allow me to stay safe.Here the picture of the original design and the final result.




I’ve  also finalized the wiring of the system including the IMU and an home-made board for the motors connections.rpi power is still via usb and ethernet connection via wire.


So the new motor connection setup is:

  • GPIO 18 (pin 12) >M0
  • GPIO 23 (pin 16) >M1
  • GPIO 24 (pin 18) >M2
  • GPIO 25 (pin 22) >M3




Class sensor.py ready!

After some complementary activities (build a new table for next experiments, for example) I finalized the test on the IMU and created this sensor object  that can run in a parallel thread , so I can get last updated sensor information anytime (every 5 -8 ms) while my main quadcopter loop is running.
You can find and download the sensor_test  example.When you run it you can see on the terminal the current roll,pitch and yaw of your IMU.

The available data are: angular position [deg],angular rate[deg/sec], linear acceleration[m/sec]

The main differences respect the IMU_test are:

  • I saw that the  mpu6050 initialization of same parameter can fail.The order on how you set the IMU parameter can affect the setting itself. So I added a function to verify the parameters are in fact what I decide.
  • The accelerometer vector has been normalized, so the lenght ,when not moved is equal to the gravity. this can help if I want to integrate it to extimate the linear speed and the linear movement
  • the class sensor.py  can run in a parallel thread, so anytime I can have the current sensor values.
  • minor adjustments done on the naming of the variables.

Next steps are:

  • Buy some connectors and do some soldering to have a final version of the wiring
  • mount the sensor on the frame and test it with running motors and see if i need more severe filtering.

How to combine data from Gyro and Accel

Ok, so after some experiments on different approach in filtering the data,I’m now interested in how to mix data from GYRO and ACC in order to get optimized results.

As always, also this time I found out a very interesting article that describe exactly this type of approach: kalman filter vs complementary filter.

Here it is possible to find how to implement 2 type of complementary filters, and the kalman filter to solve our problem.If you are interested in the kalman filter I strongly recommand to have a look on it since it is really simple to be implemented.I have to say that is is written for Arduino, not in python, but I don’t think this can allarm us.

Personally I just implemented the first order complementary filter and it seems to solve both the noise and drift problem.


In the picture you can see the comparison between the returned angle from gyro, from acc,  from the complementary filter and also from the complementary filter  using the acc data filtered with kalman filter.

As you can see the gyro drift that is really evident in the right (the blue line) is completelty deleted .


Here it is the pic zoom of the left side, where the registered acc noise is clear (red line).Look as the complementary filter reduces it strongly.

So finally after this test I decide to implement the complementary filter on my sw.

You can  find it here as IMU_Test3.

Note that the complementary filter is included directly in the imu_test.py code in the getAngleCompl() .

Now I can say that the development related to the IMU can be frozen at this stage. Now I want to move this into a python object that runs in a parallel thread so  I can monitor the IMU data anytime. After that It’s time to investigate in the PID.