[This original ArduPilot board, now called the "Legacy ArduPilot" is no longer produced or officially supported by the DIY Drones dev team, and this page is maintained just for historic reasons. However, there are still many users of it out there and it still works fine. The user group for Legacy ArduPilot users, for both thermopile and IMU use, is here.]
ArduPilot is a full-featured autopilot based on the Arduino open-source hardware platform. It uses infrared (thermopile) sensors or an IMU for stabilization and GPS for navigation. It is the autopilot used to win the 2009 Sparkfun Autonomous Vehicle Competition.
The hardware is available from Sparkfun for $24.95. An expansion board ("Shield") kits that includes an airspeed sensor, a 3.3v power regulator for 3.3v GPS modules and other sensors and cables and connectors for easy attachment of the XY and Z sensors, is available from our own store for $57.20.
User f
ArduPilot features include:
- Can be used for an autonomous aircraft, car or boat.
- Built-in hardware failsafe that uses a separate circuit (multiplexer chip and ATTiny processor) to transfer control from the RC system to the autopilot and back again. Includes ability to reboot the main processor in mid-flight.
- Multiple 3D waypoints (limited only by memory)
- Altitude controlled with the elevator and throttle
- Comes with a 6-pin GPS connector for the 4Hz uBlox5 or 1hz EM406 GPS modules.
- Has six spare analog inputs (with ADC on each) and six spare digital input/outputs to add additional sensors
- Supports addition of wireless modules for real-time telemetry
- Based on a 16MhZ Atmega328 processor. Total onboard processing power aprox 24 MIPS.
- Very small: 30mm x 47mm
- Can be powered by either the RC receiver or a separate battery
- Four RC-in channels (plus the autopilot on/off channel) can be processed by the autopilot. Autopilot can also control four channels out.
- LEDs for power, failsafe (on/off), status and GPS (satellite lock).
Resources:
ArduPilot requires the free Arduino IDE to edit and upload the code to the ArduPilot board.
The code is currently optimized for the Mutiplex EasyStar three-channel powered glider and FMA sensors, but can be modified for other aircraft and sensors. It uses the rudder/ailerons and elevator to maintain level flight and navigate to GPS waypoints. It supports a desktop setup utility and ground station software. It also includes a "fly-by-wire" mode that simply stabilizes RC flight. The main code is ArduPilot2.x.zip in the download section of our Google Code repository, where x is the latest version.
What you need to make a fully-functional autopilot:
- ArduPilot board
- Shield expansion kit with airspeed sensor
- GPS module (uBlox5 recommended)
- XY and Z sensors or ArduIMU+
- FTDI cable for programming
- [Optional] Two Xbee modules for wireless telemetry. This one in the air and this one with this antenna on the ground/laptop side. You'll also need two Xbee adapter boards. You can connect the airborne Xbee adapter to Ardupilot Mega with jumper wires.
Open source extras:
- If you want to build your own board from scratch, the necessary files and component lists are here.
- [Note: you shouldn't need this, since this code is loaded on the ArduPilot board at the factory] Latest multiplexer code (for the board's second processor, an Attiny, which runs the failsafe system) is here.
Instructions for loading this code are here.
Recommended UAV setup:
Airframe option one: Hobbico SuperStar (49" wingspan, $95, shown above). This is an inexpensive, good flying high-wing trainer with ailerons. It can be hand launched in a park or take off from a runway, and replacement parts are readily available in case of a crash. If you want much better performance with this aircraft, you can upgrade it to a brushless motor, speed controller and a LiPo battery. [If you don't already have one, you'll also need a balancing charger and power supply.] Note: any stable aircraft with both ailerons (for stabilization) and rudder (for navigation) can work, so feel free to experiment with what you've got.
Airframe option two (recommended for ArduPilot 2.x): EasyStar (shown above). Performance can be improved with the modifications described in this post.
You'll also need:
- A six or seven channel RC transmitter and receiver, with at least one toggle switch (ideally three-position but two-position will work, too, although you will have to mix channels to have access to both autopilot modes in the air), such as the Futaba 7C.
- Some servos (at least three for ArduPilot 1.0; at least two for ArduPilot 2.x) and at least three female-to-female servo cables to connect the RC receiver to ArduPilot.
Cool optional extras for your UAV:
- A GPS logger to record your mission and play it back in Google Earth
- A tiny video camera to record the flight
- A wireless video setup to see realtime video from the air
Comments
Also, you don't need any of those ArduPilot files you mentioned. The failsafe firmware comes pre-loaded in the board, and ArduPilot 1.0 has been replaced by a configuration option in 2.3. Spend a little more time with the manual and all will become clear.
i got the code(ArduPilot1.0, Fail_Safe_v15, and so on) from the your libraries(http://code.google.com/p/ardupilot/).
But i cannot find the header files(WProgram.h, pins_arduino.h ...).
let me konw where it is exactly or send me by e-mail?
Good catch! Fixed....
i'm reading the manual again and i found that those sentences looks not right to me:
"placing your palm in front of a pair of sensors on the fore, aft, port or starboard sides simulates the IR signature of that side tilted up to the sun. So if you put your hand in front of the XY sensor (which looks to the autopilot like the plane is pitching up), the elevator should go down. If you put your hand behind the sensor (simulating pitching down), the elevator should should go up. Likwise for the two sides."
the hand is simulating the ground temperature not the "sun" ground is "hotter" than sky IR temperature...
so if you put you hand in front of the plane it is simulating a nose down position so the elevator should move up etc...
it is the same when you put your hand to the right of the sensoit simulate a right wing pointing down to the ground so the ailerons should counter this situation : right aileron down and left up
pretty sure about that... but if somone can recheck (i'm not home) to be sure
regards
fefenin
Try reloading the FTDI drivers. One of my computers seems to frequently switch the driver and I have to reinstall. I get a message similar to the one you posted, but reinstalling the driver solves the problem.
i went for a fly today and it worked great but only the ailerons were connected to the ardupilot ,
i kept manual control on pitch and throttle...
you are right Chris it my be a GPS lock problem :
i did modified the soft a while ago to accept lock only when in 3D mode with a least 4 sats!!
never loses lock but still this dive issue.
anyways i'm waiting for the Ublox to come , will be better anyways...
here is the programmed path:
here is my flight log:
in the second part you can see that it loses WP4 few times (wind was very high) , i could propably set the soft to make the plane turn harder but i'll first make the pitch thing working:
I'm not sure what the problem is but it might be related to lost or poor GPS lock. ArduPilot gets its altitude data from the GPS, and if you don't have enough sats acquired, that altitude data is unreliable/random. We've now switched to the uBlox GPS with the helical antenna (we'll be releasing them soon) and it keeps lock better and have much more accurate altitude readings than the EM406, so we don't see this problem, but we also haven't written the code to be very tolerant of lost GPS lock and bad altitude data. Might be something to look into....
no sun, but no rain too, so go fly >:-)
I made some changes to the .h code. The code is here.
First flight (thr auto):
- model overshoot
- speed was not held (why if speed is setted at 20m/s the plane only will fly at about 11m/s?)
- altitude was not reached/held (because of lack of speed?)
Second flight (thr manual, no calibration so it was the same as the first flight):
- model flyes well without overshoot (now I can guess that speed is an important factor for this point)
- altitude was held
- heading was good
- wp reached at first attempt
- model turned tight and precise to the next wp
- sequence terminated fast and well
... but...
it happens that the model dives!
The last time I waited to long it recover itself. I had then to recover it manually at 10m. It asked my little EasyStar a little to much. A wing broke in the air :.-(
Anyway this is not the first time and will shure not be the last.
Another strange behaviour was that the plane after a dive usually reset the sequence from the beginning. This time it continues it from the last wp reached. I did not change the code at 1-10. It is set to 0.
How could this happen?
Thanks and best regards.
Ric
i'm also waiting for a sun windows to fly this afternoon!!
for your questions i'm not able to answer that i fear... ( i guess all of that should be possible)
i don't quite know what elese to try ...
i'll try first the config tool mod by Happykillmore that allows to save and load missions ...
will be better to just connect the ailerons to ardupilot (not pitch and not throttle) to make sure the waypoint missions works
after that try with the pitch , but i fear it'll do the same as the last time...
and after that i'm waiting for a mail from Jordi to try something else to be sure all separate functions works
i'll post the result only if that works.
hope we will find what's going on
fefenin
thank you very much for your interest!
No, things are not really fixed. The plane flyes well and it reaches waypoint programmed. But randomly at a certain point it dives. Normally it recover itself but the sequence is resetted to 0 and the plane will restart the sequence. I know that I can change this in the code, but it does'nt solve the problem.
I'm convinced that thermopiles calibration is a problem. I'm not able to reach a satisfactory calibration. With the plane leveled the Ardustation alway show some degrees roll and pitch. I tryed and I tryed...
In flight this translate in a habit to turn always in the same direction (the left).
The route is not clean, I had to work on the code. Better if I can solve the calibration issue too.
Nobody answered my questions :.-(
- is it possible to modify the thermopiles gain?
- what exactly does roll_abs and is it used or not?
- is it possible to zeroing the plane attitude (char roll_trim, pitch_trim?)?
I'm waiting for some sun in the afternoon to try some changes in the code, especially to make the throttle working as desired.
Is there in the forum a code repository (not the official one) where we can deposit all our .h files to share them?
Thanks and best regards.
Ric
-
43
-
44
-
45
-
46
-
47
of 84 Next