Developer

ArduIMU Quadcopter

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 (http://www.rcgroups.com/forums/showthread.php?t=297067) six years ago!!...Size: 64cm (motor to motor). We can dissasembly front and rear arms with one screw (easy transport)Weigth: 850gComponents:4x TowerPro2410-9T+ESC18A+Prop1047 combo 4x$15 = $603S2200 Lipo Batt = $13Aluminium and building materials = $12ArduIMU = $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...Development: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.

Future:-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: Quad1_15.zipSome link to photos: Photo1,Photo2,Photo3,Photo4Jose Julio.
E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Can a Futaba Fasst 24ghz TX and Rx be used?
  • What kind of power-to-weight ratio do you shoot for, on a quadrotor design in order to get decent maneuverability and flight times?

    Also, if you didn't want to get into Tx/Rx style control (as Simon Wood mentioned earlier), is it feasible to use the SoftwareSerial library for remote control via bluetooth or whatever? Or, if SoftwareSerial is too slow, put the GPS on it and use the normal serial?
  • Developer
    Hizan, I am using Spektrum equipment (module) with AR6110 receiver and PPM encoder.
    You can use the HK-6X also with the PPM encoder.

    Dee, I am not using autopilot now... future?

    Jose.
  • The range of props with complementary pushers is increasing all the time. The GWS EPP props have been the main type used but APC do 10x3.8, 10x4.7, and 12x3.8. There are also German companies that have a range of props including carbon types.

    Peter
  • Nice job!!! R u using any autopilot?
  • Hello Jose Julio

    Congratulations! You've done a great job. I'm looking forward to build a Tri with ArduIMU. Perhaps I could build one based on your Quad code and custom it a bit.

    By the way, what Tx would you recommend? I've seen in many projects people are using DX7. Any chance that I could use something cheaper?

    e.g: HK-6X http://www.hobbycity.com/hobbyking/store/uh_viewItem.asp?idProduct=...

    Thanks

    Hizan
  • Thanks for your explanation! As what you said, the side motors then should have tilt in opposite directions. Say if one motor tilt 10 degree, the other one should tilt -10 degree. Am I right?

    I almost get it. Thanks a lot!
  • So say the front & back props are level and the sides are tilted... the front and back motors rotate and cause a rotary motion on the frame (so my mate Newton says), but mostly their force is vertical upwards.

    The side props also rotate in the same direction causing a similar rotary force and an almost upward force. As this upward force is tilted slightly in an opposite direction to the rotary force it can cancel it out.

    I assume that the angle is set for all motors spinning at the same speed, as the speed of the motors change during flight (all at the same time) the 'cancelling' force would change resulting in less cancellation of the rotary force.

    However there is nothing stating that the all motors would have to spin at the same rate. As long as the pairs were at the same rate the UAV could be kept in level flight, and the speeds set so that the rotary force is cancelled.

    Of course in a perfect world all this happens automatically and the operate only needs to work out where to fly.

    Hopefully that's a clear explanation.
    Munge.
  • I still cannot figure out why the tilted angle can compensate the torques. Can somebody tell me?
  • 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...
    Mungewell.
This reply was deleted.