Developer

ArduIMU quadcopter part III

Hi all, I have a new drone in the family...

This tiny drone is able to do completely automatic flights, it can perform altitude hold (based on sonar sensor) and obstacle avoiding based on IR distance sensors (you could see the "black stange eyes" on the photo). It´s your personal droid...

Look at the video (the "tennis game" part it´s funny. Thanks to Ramon for the idea!!)

There are some new features in this thrid part... This is the list:

For outdoor configuration:

- GPS library support (actually UBLOX or NMEA)

- Position hold based on GPS

For indoor configuration:

- 4x IR distance sensors to detect obstacles (1.5m range)

- Obstacle avoiding (using distance sensors)

Common:

- Altitude hold based on Sonar (LV-EZ0)

- Automatic flight pattern (experimental).

--- Automatic takeoff

--- Position hold [outdoor] or obstacle avoiding [indoor] during a predefined time

--- Automatic descend

--- Automatic landing

- Added XBee for telemetry (and debug)

And some improvements in the code:

- New "radio test mode" to test radio equipment

- Revised control routines

Development

For the GPS position hold I had to implement the navigation algorithms for the quadcopter because it´s really different that the one used for planes...For this navigation it´s necesary to have the magnetometer to cancel the yaw drift in hover conditions. One thing I have observed is that you can only fly this tiny drone on very calm days because it´s too light for the wind... so it´s better suitted as an indoor drone. Then I started to think how to make a cheap way to navigate on indoor enviroments... I have one sharp IR disntace sensor so I start making some tests mounting the sensor in a servo to make a 180º scan. The idea was to mount 2 (or 4) of this sensors in the moving head.
On the tests I found that in this little machine the moving head caused some inestability, so I decided to mount 4 sensors in a fixed way. OK, this the cheap DIY version of an EXPENSIVE laser range finder, but it works...
there are many thing to improve and test, but it´s a promising start...


Details

Sonar module is an LV-EZ0. Because we don´t have any analog input available I use the PWM interface in a Port Change pin (PCINT20) to use an interrupt to read the sensor. (It´s recommended some solder skills to make this modification).

For the IR range finder (Sharp GP2Y0A02) I needed to use a separate Arduino Pro mini (again we don´t have any analog input free). This module connects to the ArduIMU via Serial port so we need to choose between GPS of range finder (outdoor-indoor decision).


On this III part, the hardware (ArduIMU) really show it´s limits... it´s not a problem of CPU power, it´s a problem of the limited I/O as I said before, so it´s time to move to the big brother, the new ArduPilot Mega Hardware... this new platform will be fantastic for this projects...


Behind the scenes

During the test of position hold I have some crashes (nothing important, only some broken propellers...) and there was a moment in that the quad performs not so good, so I start searching the reason. Again I suspect that it could be a vibrations problem so I decided to make a modified code to test the vibration on each motor.

As you can see I have problems on left motor, so I change this prop, also add a new layer of doubled sided foam tape to the ArduIMU and problem gone.

The code is here: Quad1_mini_test_motor_vibrations.zip (If you want to use it read the instrucctions)


Respect to the IR distance sensor, the first version was a moving head with a servo but this had some problems with vibrations that affect stability and also has a poor scanning rate, here is a photo of this prototype. Finally I decided to use 4 fixed sensors.

Codes

Some parts of this codes are still experimental but you can get it here:

Outdoor code (GPS): Quad_mini_1_27.zip . GPS libraries : GPS_libraries.zip

Indoor code (IR sensors): Quad_mini_1_29_rangefinder.zip External Arduino pro mini code: IR_distance1.zip


Old posts of this project: http://www.diydrones.com/profiles/blogs/arduimu-quadcopter-part-ii


Jose.




E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Hi! jose
    you did good job and amazing!!!
    could you attach more detail pictures.
    I fixed my board and is alive.
    now try quadcopter part III
  • Developer
    @Jhon you're right about it. Outside isn't the goal. The benefit isn't on the main loop frequency or outside transmitting speed. It's the clock inside the SPI transmission session. We need to create the data buffer on normal loop rate and, after that, our code will open a high speed session to spend a short time to send it to other board. It will send your GPS data quickly to another board. That's all. But it's not related with ground station, etc... There you have the limitation of modem and other issues that not exists between two boards wired. In that case, the transmission is asynchronous and USART is the best and cheapest way to go.

    Furthermore, that was my first test. I need to do a lot of tests with large buffers, etc. If it really does the job as it promises, I will share it with the DIY Drones community. I'm totally newbie on those things but I'm working a lot to learn the most that I can. So, by sharing it, I'm sure that the improvements will go one thousand miles from my vision. I know the risk of being very ingenuous in a sort of times... but OK. Is the way that children go through for learn a lot in short time. :)
  • w0ow are you planing to sell them? :P

    if outside perfrming is bad then is notvery usefull for GPS navigation, thats a bit bad, but anyway... looks very good and sexy
  • Developer
    Jose, I'm very happy here, man. I achieved a fast SPI connection between ArduIMU_v1 and another Arduino board. By now I'm insisting on the idea of isolate the IMU on my quadrotor's project, because is more easy to eliminate vibrations and make it more modular with possibility to add new resources like dedicated ESC control with fast pwm on 16bits, camera controlling and stabilization, etc.

    So, I'm using the SPI hardware to controlling the communication. I defined an delay of 1usec per byte on Master with a clock prescale of 4Mhz (16Mhz/4) on SPI Control Registers. This is the result:

    bit per sec on spi: 4000000 (theoretical 4Mbps with SCK at 4Mhz)
    sec per bit on spi: 0,00000025 (0,25usec)
    delay per bit on master: 0,000000125 (0,125usec -> delay per byte / 8)
    sec per bit + delay: 0,000000375 = 3,75Mbps (real speed)

    Man, at this speed, We can transport the entire binary IMU buffer on an SPI session with less than 60usec... :)
    So I ask you... Why not move the flying control to a generic board and use the ArduIMU only for attitude reading? By this way we would use the latest unmodified ArduIMU firmware (with an SPI transportation class included on newest versions, of course).
    头条 - 第一区块链{etc.so}
    第一区块链{etc.so}
  • Hey Amir ! I remember your Avtar @UAVP NG, it is same.
    For the last two years I have been closely following up your virtually daily posts and video of your Quadrocopter.
    So what you have been up there ?

    Regards

    Rana
  • Developer
    Jani, all the props are spinning in the same direction, you could find more info on this part on the old post (part II)

    Sandro, you are right! it would be more easy. The problem is that I implemented first the sonar (I didn`t know that I would need an Arduino Pro mini at this moment...) and then I started to play with the distance sensors...

    Jose.
  • Very nice demo! Never saw someone playing copter-ball before... :)

    Congratulations!
    - Amir
  • Developer
    Jose, excuse my newbie question but... why didn't you connected the Sonar into the Pro-mini sending altitude info together with IR sensors info? At 70hz on the main-loop, seems to be possible to read it and use on the PDI calcs. By this way we wouldn't needs to do the ninja's solder. I'm wrong about it?
  • Developer
    Jose, if i go tomorrow to office, I could try to get accurate measurements from AI+ and also look the speed of I2C bus. Ok that bus should not be a problem due there is only one device now. But good to know if later on using i2c ESCs.

    Actually implementing i2c escs should be rather easy it also gives full scale adjustment.

    you still spinning all props to same direction or did you implement counter rotation already?

    --jp
  • Developer
    Thanks Rana, Thanks to all,

    Jack, this sensors works nice for this application but also has some problems, for example it fails on windows and mirrors (there are light sensors). I think I need a minimun of 4 because this quad could move on all directions...

    Dave, I agree with you, it could be possible...

    Jani, I have not measured cpu usage but I know that my main loop executes at 70Hz wihout problems and probably more (100hz).

    Loris, I´m only made 2 or 3 test of the GPS position hold. I could see that the algorithm works but I need to adjust better the control gains. I will make this tests with a bigger prototype. As I said, you need a very calm day to test things outside with this one.

    Jeff, the Arduino Pro mini is connected to the four IR sensors to read the analog signals and send to the main board (via serial port) but all the processing stuff it´s inside the ArduIMU.

    Jose.
This reply was deleted.