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.
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.
You need to be a member of diydrones to add comments!
Comments
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?
You can use the HK-6X also with the PPM encoder.
Dee, I am not using autopilot now... future?
Jose.
Peter
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
I almost get it. Thanks a lot!
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.
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.