Ardupilot

back to http://scratchpad.wikia.com/wiki/Sasecurity

ardu mega
http://code.google.com/p/ardupilot-mega/

Arducopter
http://code.google.com/p/arducopter/ has forked to http://code.google.com/p/ardupirates/

China clone

 * http://item.taobao.com/item.htm?id=9130085673&frm= chinese clone
 * http://opuav.taobao.com/?search=y&scid=158480951&scname=QVBNt8m%2F2M%2B1wdA%3D&checkedRange=true&queryType=cat

http://diydrones.ning.com/profiles/blog/show?id=705844%3ABlogPost%3A1579790&commentId=705844%3AComment%3A1581128&xg_source=activity

http://www.goodluckbuy.com/px4-flight-controller-protective-case-protector-shell-black.html

http://www.goodluckbuy.com/pixhawk-pix-pxi-px4-32bits-flight-controller-driver-for-multirotors-fixed-wing-copters.html

http://www.getfpv.com/flight-controllers/3dr-pixhawk-with-gps.html

Links
http://www.diydrones.com/notes/ArduPilot diydrones专区

http://code.google.com/p/ardupilot/wiki/ArduIMU google代码库

http://code.google.com/p/ardupilot-mega/wiki/home?tm=6


 * http://www.diydrones.com/profiles/blogs/more-arducopter-gps-and-alt GPS and altitude hold on Hex copter
 * http://diydrones.com/profiles/blogs/arduimu-quadcopter-part-ii?xg_source=activity ArduIMU mikrokopter
 * http://www.diydrones.com/profiles/blogs/arduimu-quadcopter-part-iii
 * http://code.google.com/p/lnmultipilot10/wiki/MulboarNaviExp Fork of imu

http://www.diydrones.com/profiles/blogs/arduimu-quadcopter-part-ii

http://www.diydrones.com/profiles/blogs/arduimu-quadcopter

which links to http://code.google.com/p/uavp-mods/updates/list and http://www.diydrones.com/profiles/blogs/return-to-home-quadrocopter which is needed.
 * http://www.diydrones.com/profiles/blogs/ardupilot-ground-control Ardu ground station

Poster Yun reproduced another prototype at http://diydrones.com/profiles/blogs/arduimu-quadcopter-part-ii?xg_source=activity&id=705844%3ABlogPost%3A141326&page=16#comments from the original code by Jose

Jose's code extention:http://code.google.com/p/easy-imu-pilot/source/browse/trunk#trunk/EasyIMUPilot

Merging of AeroQuad and ArduCopter: http://www.diydrones.com/profiles/blogs/announcing-arducopter-the?id=705844%3ABlogPost%3A163519&page=3#comments

Complete built quad drone
http://diydrones.com/profiles/blogs/want-a-plugandplay $890 or about R6400

Stick resolution and channel loss
This is going to be my first and only post in this thread, and is in regard to the DIYDroneSafety articles about ArduPilot and PPM. I found those articles to be a very funny read btw. Weird in a reality distorted way, but still funny. Here are some simple facts to keep in mind if/when you read those articles. - ArduPPM, the current PPM encoder used in all APM2.x boards and APM1.4 board when firmware updated. Does not contain a single line of code from the original Paparazzi PPM Encoder. It is a complete rewrite, using a completely different approach to deal with PWM pulses, interrupts and timing issues. - The primary goal and origin of the rewrite/recreation was to move the PPM encoder from the APM1.x 328p chip to the new APM2.x 32u2 (8u2 in original Arduino boards) chip used in newer Arduino boards to replace the costly FTDI USB to serial conversion chip. That meant that we could get away with one less chip, since the PPM encoder and USB to Serial conversion would be running on the same processor (32u2). But the design of the Paparazzi PPM Encoder would not play nice together with the Arduino USB-To-Serial code. So a complete redesign was necessary. - The second reason we did a complete rewrite. Was that Olivier found and documented some very real and very serious problems with the original Paparazzi PPM Encoder used by APM 1.x. What Olivier found and proved by extensive testing, was that that PWM channel sequences from certain R/C receivers would confuse the Paparazzi PPM Encoder. Resulting in the throttle channel (among others) locking up. So on the one hand we have the Paparazzi PPM Encoder with a confirmed and very real safety issue (throttle channel sporadically locking up during normal flights, with certain receivers).

On the other hand we have the new ArduPPM encoder whose that has been designed from scratch to have less input jitter and handle any sequence of PWM channel inputs. Performance that has been proven with extensive testing over long periods of time. In fact the only known (and reported) weakness for the ArduPPM, is that it will not enter a "single channel" fail-safe if there is a problem with a receiver wire. If the receiver dies completely fail-safe will active, but a single channel disappearing will not activate fail-safe. Instead the last known position if that channel will be used. This has always been a known weakness, and has to do with how much code we can run in each interrupt and still maintain low jitter and good stick resolution. With the discovery that the Turnigy 9x radios using original receivers and firmware, would act in a non-standard way and completely drop the throttle signal during fail-safe (same effect as a broken wire). The detection of single channel loss became a real problem, and a patch was made to detect single channel loss (throttle only) at the expense of some jitter and stick resolution. So that's it. The complete history of the ArduPPM and the reason behind the "storm in a glass" regarding PPM.