Category Archives: hw config

myR: How to control DC Motor -part 2

So, let’s first complete the wiring.

Each motor needs 2 signals, one for the clockwise movement, one for the counterclockwise movement.

I’m using the  GPIO 18 ,23,24,25  connected directly to the 4 inputs of the bridge. See the diagram below.

DCmotor4

Consider Motor 1. When GPIO 18 is high , the bridge set the Out1  also High and Out2 is the ground. And the motor turns cw. When GPIO23 is High the bridge inverts the outputs, so Out1  become the ground and Out2 is High and the motor turns ccw.

Finally , as we see in preview post, modulating the pulse width of the signal we can control the speed of the motors.

Beta1test. Bugs and a steps ahead

Yesterday I got this result:

beta1_graph1

Thanks to the following actions:

1)The test with the ball on the bottom of the drone,did not convince me. the friction on the ball, the  rotation limits due to the basement, were all components that are not present during the flight.

So I decided to switch to the more used and recognized  solution with the quadcopter tied up with 2 wires.

beta1_tied_up

2) I realized  that something was wrong on the motors behaviour.When I  run the beta1.py   the motor sound  was unstable and unconstant evenif  I was not  controlling it with PID ,just make them run in throttle speed.

This is not happening if I run the motor_test.py.

Finally I was able to reproduce the problem and I realized there is a bug (or better an unexpected behaviour)  in the  library RPIO. If I run this loop (that reproduces the main loop of the beta1) I got the unstable motor rotation:

while true:

mymotor.servo.set_servo(self.pin, PW)

sleep(0.01)

 

My explanation is everytime  calling the set_servo()  function, it resets to zero the signal than set it to the desired value PW).

Instead of that funciont I introduced the lower level function

myMotor.PWM.add_channel_pulse(1,self.pin,0,PW)

When I put it in the test loop I got a perfect, stable, constant sound for the motor rotation.

This 2 improvements gave me the opportunity to move  a  great step haed. Now the tuning can be faster and more consistent.

Above just a graph showing the current behavior.In blue the requested   roll , in red the real roll when  the quadcopter is  using the pid controller. I still need to  tune it to reduce the time to reach the target (5/6 seconds)  and to avioid the oscillation ( +/- 3 degrees).But I’m really satisfy about the current situation.

Beta1 test preparation

This post introduces you the next test session.

In this phase I’m  developing the software to manage the 4 motors and the IMU.

I made the following modification on the frame:

beta1_frame_bbeta1_frame

 

I added an half sphere attached in the bottom, in order to create an unstable condition on the drone.I double check that  the blades can not touch the field with any orientation.

The target is to see the quadcopter to stay horizontal adjusting  the orientation (roll and pitch) by itsself.

Let’s try!

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.

 

Test_Frame

 

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.

wiring_IMU_MOTORS

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

 

 

 

Tutorial: How to read data from IMU

In the previous post I described how to setup raspberry pi for connection with the IMU.

Now it is time to see how to read some data from the sensor.

First yuo need sw that manage the i2c interface.there are many examples.You can find one called adafruit_i2c.py on github.

Then it is necessary to have the code specific for the sensor,in my case a MPU6050.

I tryied for some days to build my own code, but I encountered problems related to unconsistent results: even if I did not move the sensor, the returned results were always different. I suspect it was a problem on how I formatted the values.

Finally, Thanks to the great job done by Hove in  his blog, I used his code and I’m now able to collect correct data from the sensor.

I did some minor modification and prepare this IMU_test files.

So I started some preliminary tests to verify which is the sensor behaviour.

I fixed the sensor on a bar ,horizontally, than turned the bar by a known angle ( 13 degrees,measured with my smartphone level) then move back to horizontal.

IMU_test1

I recorded on a file the sensor data : acceleration along axis (from ACCelerometer) and rotational speed (from GYRO scope). On excel sheet  I calculated the angle around x  respect the ACC and respect the GYRO:

  • rx ACC=DEGREES(ATAN2(accZ+9.8;accY))
  • rx(i) GYRO=wx(i) *dt+wx(i-1)

Below you can see the graph.

IMU

I underline in the picture the 2 tipical problems on the IMU :

  • the Gyro drift (you can see an angle of 1  degree while it reality it was 0)
  • the Accelerometer sensibility to noise.

So next  development step is to filter/reduce this 2 problems by combining the 2 sensors results.