Is this the quadrotor week? :-)
Hi all, on Christmas holidays I have started my DIY project to construct a cheap (but good performance) quadcopter based on ArduIMU hardware only.

I have used standard props (NO counter rotating) that are easy to get and if we want construct the quad on other size you have no problems finding the right prop. To compensate for torque I mount front and rear motor with a small angle (about 6º, see Photos). I first use this concept on this project ( six years ago!!...

Size: 64cm (motor to motor). We can dissasembly front and rear arms with one screw (easy transport)
Weigth: 850g
4x TowerPro2410-9T+ESC18A+Prop1047 combo 4x$15 = $60
3S2200 Lipo Batt = $13
Aluminium and building materials = $12
ArduIMU = $99
Full: $185

Note how small seems the ArduIMU PCB on this quad! and how clean is this setup. We can construct really tiny quads this way and if we use standard props we have a wide range of motors and props to choose...

The first test I did on this project was the vibration test of the ArduIMU with motors running and with the new firmware (I use r20) there are no problems with this. Because we have 4 motors running there are more noise on accelerometers (it´s normal) so I added a new low pass filter on the accels and also adjust the gains for drift corrections...

The main loop with IMU code and PID controls for roll, pitch and yaw runs at 70Hz and the PWM outputs for ESC´s have a 125Hz rate. As always, adjust the PID gains is a very important task . D term is really important for a quad and I am using directly the raw gyro readings (bias corrected) to feed the D term in order to make it more responsive.

The most difficult part was the developing of the function to generate the PWM pulses for the ESC´s because we need 4 PWM servo outputs with very good precision (1-2us) and at a high rate (now is 125Hz).
This code generate more than 10,000 interrupts per second (only ADC generates more than 8,800) so in this enviroment is difficult to generate precise pulses.
The solution was to use the Timer2 overflow interrupt and a "trick" based on Timer 1 counter readings to achieve this high precision. I have also one (or two) more standard servo output for future applications (camera stabilization?)
The radio input is done via the ICP pin and interrupts so high precision is achieved (1us). We need to feed a PPM signal (directly from Rx or via the new Jordi´s PPM encoder...)

On the future we can use the magnetometer of ArduIMU, but now the yaw is like having a Heading hold gyro (note that quads have slower yaw response than helis)

This is the first stage on the development process of this project but I have made some tests with good results.

-More tests, outdoor tests...
-Add ArduIMU magnetometer to correct yaw drift
-Add GPS for position control...
-Add Ultrasonic rangefinger for automatic take-off / landing...
-Add camera with stabilization...
-Find time to all this projects... :-)

Here is the code and some notes:
Some link to photos: Photo1,Photo2,Photo3,Photo4

Jose Julio.

Views: 38576

3D Robotics
Comment by Chris Anderson on January 12, 2010 at 11:04pm
Mook, sure lots of quads do that. But as NS Rana points out above, it's hard to find reverse thrust props, so Jose just angled two rotors to counter the torque.

Comment by Doug Weibel on January 13, 2010 at 8:18am
@Jose - Nice Work! Now I know what you have been up to the past couple weeks...
Comment by Simon Wood on January 13, 2010 at 9:33am
OK your project got my brain whirring last night (when I should have been sleeping!!)... This looks (to me) a really good way to get a cheap solution together, that said there would be a couple of hurdles.

1). Cost of Radio Gear. Is there any reason why this couldn't use serial data for flight control, such as a WiFi/Bluetooth/Zigbee radio connected where the GPS would normally connect. Commands could be step like ie. "move up 5 cm", "turn left 90", etc.

The quad could also be smart enough just to hover when data link was lost, or even land when battery is getting low.

2). Automatic landing would require some form of distance measurement. You suggest UltraSonic, but IR is nice and cheap too...

3). Yaw correction. It might be possible to do some yaw correction by tilting the IMU (so that the gravity vector affects all three gyros in 'level flight'.

I'd love to see a schematic to see what extra pins you have used. Just how small do you think that you can go with this?
Comment by Overwatch on January 13, 2010 at 9:39am
Simon, automatic landing is possible even without distance measurement, just keep going down at a reasonably safe rate (e.g. 1 ft/s) and wait until the accelerometers register a bump on the Z axis and power down.
Comment by Simon Wood on January 13, 2010 at 10:54am
With a distance sensor your quadcopter could be made a little more novice friendly. Imagine someone commanding 'descend as fast as possible', the system could self protect by limiting descend rates when it could 'see' the floor.

It could also allow limiting of maximum height giving a 'nice' indoor flying experience.

Detecting a 'bump' might be a killer, imagine a gusty updraft causing motors to shut down or just clipping a table edge etc...
Comment by Overwatch on January 13, 2010 at 11:10am
The landing bump is specific, a gust or a skid looks different. Also it's only processed when landing is in progress and GPS/baro altitude suggests that ground is near. I've never head a false positive (so far).

Although the safety/indoor experience scenarios do sound pretty good :-)

Comment by Jordi Muñoz on January 13, 2010 at 12:46pm
You are the man Jose!! Congrats!! ;-) I love it!

Comment by Jose Julio on January 13, 2010 at 4:28pm
Thanks for all your inputs...
Simon, we have only one Serial input port in the Atmega328 and I am planning to use it for GPS, but as you say if you are planning to fly indoor (withoud GPS) it´s posible to use this port to receive commands.
I know sharps IRs but I think it has less range (maybe for a small version)
I think we can construct a really tiny version. I am thinking in some 5grams brushless motors with 4x2.5 or 5x3 props... The ArduIMU board is really small and weights only 4.8grams

Comment by Simon Wood on January 13, 2010 at 5:30pm
Regarding control/GPS: The code could understand both, that way it would be up to the user to decide which to use. I would suggest using NMEA for the GPS as this doesn't limit usage to uBlox/SiRFStar, and then have the control instructions as a line of text which looks somewhat like a NMEA log (only with a different prefix).

With some clever flow control you could multiplex two serial sources into the same port, using either timing alone or something which looks for newlines. In fact the Atmega could toggle a pin (CTS to radio?) after receiving the 1Hz data from the GPS to enable the radio to deliver and then toggle it back before the next GPS string is expected.

There is also no reason why code wouldn't expect both Serial and PPM control to be active, it could just update to using the most recent request.

I'm suggesting this as a $30 wireless link is obviously a lot cheaper than a RC controller/receiver and is also a lot less weight to carry.

We have be using LMX9838 BT<->serial modules which are 10mm x 17mm x 2.0mm and weigh next to nothing. With creative wiring they can be placed without a carrier board, soldering directly to module's pads. WiFi or ZigBee would get you some more range though...

And WOW! that's small :-) This is such an awesome project...
Comment by Jianguo Zhao on January 14, 2010 at 7:35pm
I still cannot figure out why the tilted angle can compensate the torques. Can somebody tell me?


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service