Welcome to ArduPilot! Here's how to compete your new board:
You should have received the basic ArduPilot board with all surface-mount components already soldered and the essential firmware already loaded on the chips. All you've got to do now is to solder on some connectors and load the autopilot software. For this first part of that you'll need a strip of breakaway headers, and three female-to-female servo connectors.
You'll also need an FTDI cable if you don't already have one.
The first thing to do is to solder on the connectors. Many of the holes on the board are for optional upgrades, such as sensors and additional RC channels, but for the basic board you only need to solder on three breakaway connectors. From your strip, use a pair of pliers or a snipper to cut off two 3-pin segments and one eight-pin segment.
First, solder the two 3-pin headers and the one 8-pin header in the circled holes above. The long side of the headers should be on the side with the chips. The easiest way to do this is to place all the pins in the holes, then place a pad of paper on top of the pins. Holding the board and the pad, turn them over so the board is on top of the pad, with the pin nubs showing through the board. Then solder just on pin in each segment. Turn the board over again and make sure the connectors are straight (if they aren't remelt the solder joint on the one that's tilting and finger-push it upright...make sure you're not touching the pin you're heating!). If they're all straight, solder the rest of the pins.
Next, we'll solder on the RC inputs. You can either use three more 3-pin headers in the holes circled in red above (in which case, you'll need female-to-female cables to connect to your RC receiver), or make and use "pigtails" instead, which is one less connector to potentially fall off. If you want to make the pigtails, cut two 12" female-to-female connectors in half, and split the wires on each end down about a half of an inch. Strip the insulation of each about 1/8th of an inch in. Now we're going to solder them in in the three sets of holes marked in red above. Black goes on the outside. This is a bit of a fiddly soldering job and it's easier with a helping hand.
If you'll be using the ArduPilot 2.0 or above code, you'll need to add a few more connectors for sensors and a calibration jumper. Solder a five-hole female machine pin header strip in the five holes marked in blue at the top in the picture above. Then solder a regular two-pin header in the holes marked in blue at the bottom.
[Note: the board comes from the factory set up to get power from your RC system. If you want to power the board from a separate power source, you can do so--the board has a built-in power regulator that can take power from 5v-15v. Instructions to make that change are here.]
Now the basic hardware is complete. It should look like the below (connectors just used in ArduPilot 2.0 and up are marked in blue):
If you are making an ArduPilot 2.0 or above, you must now connect the FMA sensor to the ArduPilot board. Instructions for doing that are here.
Now it's time to connect everything, plugging your female-to-female cables (or pigtails) into your RC receiver. CTRL should go to channel 5 or 6 (whichever has a toggle switch; if you're using ArduPilot 1.0 the other channel, which should have a knob, will be used to control the FMA Co-Pilot).
For ArduPilot 1.0: Input 1 should go to your receiver's Channel 3 (throttle) and Input 2 should go to Channel 4 (rudder). Then plug your ESC (motor speed controller) in the ArduPilot Out 1 and the rudder servo into ArduPilot Out 2.
Here's a diagram that shows all the components and how they should be connected (Rx is your RC receiver and ESC is your electronic speed controller):
Here's what ArduPilot 1.0 looks like in real life:
ArduPilot 2.0 and above: Input 1 should go to your receiver's Channel 1 (aileron) and Input 2 should go to Channel 2 (elevator). If you've got a three-channel plane like an EasyStar, connect the rudder servo to Out 1. For a four-channel plane with ailerons, connect the aileron servo to Out 1 (the rudder, which ArduPilot doesn't use in this configuration, can remain connected to your RC receiver for manual use). The elevator servo should be connected to Out 2, as shown below. Throttle is connected directly to the RC receiver; it is not used by ArduPilot in this configuration.
Here's a diagram that shows the whole setup:
Software
Now it's time to load the software. Download and install the latest version of Arduino, if you don't already have it.
First, it's best to run some test code to ensure your board is set up properly. Dowload "ArduPilotNE" from our Google Code repository. This code just flies the plane in the NorthEast direction, so you can test it in the air, but for now, let's just test it on the ground by walking around with the autopilot on and GPS locked and watching the rudder move, as shown in this video:
To load this code, power on the board by plugging your ESC into a battery or using some other 5v power source (do not attempt to just power the board with the FTDI cable. We did not connect the power pins on the FTDI port to the processor to avoid power conflict when the board is powered by the Rx and you're using the FTDI as a serial monitor). The red power LED should go on. Now plug your FTDI cable into the board (with the black wire or, in the case of the Sparkfun board, the GND pin on the side marked "BLK") and plug it into your computer's USB port.
Here's what the Sparkfun FTDI board looks like when it's plugged in properly:
Then in the Arduino software in the "Tools" menu make sure you've selected the right serial port (the FTDI cable will create a new one, which is probably port 5 or higher). Also ensure that the board selected is "Arduino Diecemila or Arduino Duemilanove w/ATmega168" if you have one of the older 168-based boards, or .Arduino Duemilanove w/ATmega328" if you have the newer 328-based boards.
At this point unplug your GPS module if it was plugged in. The Arduino code will not load if the GPS module is attached, because they share the same serial port. Once you've uploaded the code, you can plug your GPS module back in. Please remember this in the future as you're uploading code: you must ALWAYS unplug the GPS first.
Load the ArduPilot "sketchfile", ardupilot.pde, which will load the rest of files in tabs.
Now press the "Upload to I/O board" icon (the little arrow point to the right). Nothing should happen for about 30 seconds, and then at the bottom the software should report that the sketch was successfully uploaded by reporting "Done uploading" and reporting the Sketch size. If not, check out the Arduino debugging tips here. [Note: if you're still having trouble, you can upload the code with AVR Studio using the AVRISP2 programmer. Just connect to the Atmega168 chip following these direction, and program it with the ardupilot.hex file that Arduino creates in your ArduPilot folder's Applet subfolder.]
Now you can disconnect the FTDI cable, reconnnect the GPS module and do the ground test as shown above. For this one, use the ArduPilot 1.0 connections: connect the throttle channel (Rx channel 3) to ArduPilot's Input 1 and the rudder channel (channel 4 from the Rx) to ArduPilot's Input 2. The toggle channel (Rx channel 5) should go to the ArduPilot's CTRL input. The ESC should go to Out 1 (you can disconnect your motor from the ESC, since you'll be testing this on the ground) and the rudder servo should go to Out 2.
If your rudder servo is reversed (it would turn the plane in the opposite direction from that required to go NorthEast), look in the first tab of the code and change the number to 0:
#define reverse_yaw 1 // normal = 0 and reverse = 1
[NOTE: If for some reason you have run the ArduPilot 2.x code first--naughty! follow the instructions!--the NE mode code won't work. That's because the 2.x code programs the GPS module into binary mode, while the NE code requires NMEA mode. All is not lost, however. If you let the GPS sit without power for a week or so, the internal capacitor will run down and it will return to its default NMEA mode and you can use the NE code again.]
If everything checks out, you can now run the full autopilot. Download the latest ArduPilot code (1.x or 2.x, depending on which hardware configuration you want to use), which can always be found on the ArduPilot home page.
Repeat the loading process as above.
Congratulations! You have a functioning autopilot. You can now plug the GPS module back in and test the basics by toggling your enable channel (5 or 6, whichever you've connected) and confirming that the "MUX" status LED turns on and off.
If you're using ArduPilot 2.0 and above, you now you need to go through the initial setup process for the GPS and/or sensors (depending on which version of ArduPilot you're using). Instructions for that are here.
For version 1.0, there is no setup process. When the autopilot is enabled, it should move the rudder servo a few degrees in one direction on its own (it is doesn't, you may have reversed your channels--make sure that throttle is in Output 1 and rudder is Output 2). Also, if you're outside or near a window, your EM406 GPS should get a lock after a minute or two. When the LED starts blinking on the GPS module, a blue LED ("Lock") should light up on the ArduPilot board to indicate sat lock.
A table showing all correct LED displays in each ArduPilot mode is here.Next, you can learn about using Arduino to set up an autonomous flight here.
We haven't had any reports of problems with the CKDIV8 fuse since the first batch of Attiny chips back in January (and never on the Atmega). It's possible that one board got screwed up in manufacturing more recently, but I think it's unlikely you got two bad boards. So it's probably something else. Let's take this off line (PM) and I'll try to get it sorted out for you--I still suspect a configuration error.
Thanks for the reply Chris, I appreciate your time greatly > "At this point the boards and code are pretty well tested,..." - so, you mean there's QA performed on the chips for each board after manuf? I mean, I understand there's plenty of good performance data from users succeeding, but this would appear to be a chip programming problem, and I think I've read a fair amount of that ??
Yup, I've been through all the ATmega debug tips and how to program the ATtiny, etc. I have no COMM port or physical connection issues (and correct RTS setting, no GPS connected), am using Arduino 013 (remembering something back in time where there was an entry about staying with that version?). With 013, the board selection must be "Arduino Diecimila or Duemilanove" or "Arduino w/ATmega328" (slightly different than I've read - those selections are not available to me). I've tried both FTDI breakout and Adafruit cables. I started off with the sync error that is shown at the top of your referenced page and, after having difficulty with the ICSP interface (info follows), the code upload now just plain hangs (no info, no results, IDE hangs up - prob'ly makes sense).
After initially having trouble with the sync error on upload, I moved to an issue with reading the chip signature using AVR Studio/AVRISP mkII and attempting to upload either the 168/328 bootloader or the Failsafe code into the 45 chip. I have no known port/driver issues, and can connect to either chip but, again, the AVR programmer must connect to each chip at 1/4 the clock rate divided by 8 (as if the fuse setting is wrong).
Let's see, what else.
I'm powering the board(s) using RC power (although I've noted that it's 6V out of my ESC/BEC, so I'm at the top of the chip limit).
I've attempted to burn the failsafe code into the ATtiny45 regardless of connection speed - this leads to proper led behavior, but incorrect function (no RC control no matter what, on the bench).
I've attempted to burn my compiled hex ArduPilot code into the ATmega168, but the NE test code does not function properly (both this and above suggesting an inability to read pulses based on goofed up clock rate?)
Whew! Now you see why I haven't written before. I apologize for my long-windedness and "newbie" struggles, and appreciate any and all help in understanding the internals. I'm reticent to fire up my new board(s) until I know what I may have done to the last. (I will also try your suggestion, although I've uninstalled and re-installed).
THANKS!
Really sorry to hear about your problems. At this point the boards and code are pretty well tested, so there must be something unique about your setup or you're missing a key step. I assume you've run through all the debugging tips here? If so, then I suspect you've got a problem with your FTDI cable or driver. You might want to try a fresh install on another PC.
All,
My apologies for my last entry starting with @Chris - my minds eye caught the previous entry and I copied that. If ANYONE out there can help, please do.
@Chris
Hello! I've been pouring over the site for a couple months now, intermittently (the kids win all dad resource battles), while simultaneously joining the RC and autopilot communities. I've been building up a ground vehicle (refer to previous blogs re: crashing on the ground vice INTO the ground - oh, and I don't wanna call the Boulder Fire Department ; ) with a few different control mechanisms, one being ArduPilot (the others being a Sun SPOT base/remote, another being a PCTx interface). I believe I am now beating the dead horse that ranges from sync failures to clock rates to all-things-ICSP programming. I was able to program/load my first 168 board, once, using the FTDI breakout board, but began running into "the sync error" thereafter. While purchasing parts/learning AVR stuff, I purchased a 328 board. This board I've never been able to program (immediate sync errors). Here's my problem - for both boards, for both CHIPS (168/328 AND ATtiny45), the behavior I see is the same - it 'appears as if' the fuse settings are wrong, i.e., the clock is being divided by 8. I say 'appears as if' because the settings are cleared, per previous postings & images, AND I can actually measure the 168/328 clock at 16MHz - BUT, and again for both programming interfaces - I can only connect my AVRISP mkII at 1/4 the clock rate/8 (i.e., 500KHz and 250KHz) and still get a good signature. Is there a way that these settings can get 'hung' in the processor? If so, is there a way to clear them and recover the board? I eventually fried my 328 board (watch those probe pins boys!), and have now purchased 2 additional 328 boards (what a great machine for $25!!!), but am unwilling to just let this go without an understanding of what is going on in there. Thanks in advance.
BTW, I'll confess to being a member of the industrial machine in my other life, and this site and all that goes on around it kicks butt. This is the way open source developments, and perhaps developments in general, are s'posed to work. Hats off Chris & Jordi, and thanks to all out there.
Michael, if you're using the 2.1 code, you should be using this setup procedure (jumper over D6 and D7), which will program the GPS to go into binary mode. That will turn off the LED on the GPS, so the fact that you're is on means that it hasn't been switched into binary mode. (That said, the fact that it's blinking is good: it means it got a lock) .
One the GPS is in binary mode, the autopilot will be able to read it and the blinking blue LED should turn solid when it locks.
[The instructions were unclear on this, so thanks for the catch. I've updated them.]
Is there a way to test the gps module? I am unable to get the gps lock light (blue led) to go on. I am wondering if the module is having issues. I checked all the lights after i soldered up the new board and everything worked fine. Then i eventually loaded the code and now the blue led will not come on. The red led on the gps blinks so it is fair to say something is happening in there, just not sure what.
Comments
We haven't had any reports of problems with the CKDIV8 fuse since the first batch of Attiny chips back in January (and never on the Atmega). It's possible that one board got screwed up in manufacturing more recently, but I think it's unlikely you got two bad boards. So it's probably something else. Let's take this off line (PM) and I'll try to get it sorted out for you--I still suspect a configuration error.
Yup, I've been through all the ATmega debug tips and how to program the ATtiny, etc. I have no COMM port or physical connection issues (and correct RTS setting, no GPS connected), am using Arduino 013 (remembering something back in time where there was an entry about staying with that version?). With 013, the board selection must be "Arduino Diecimila or Duemilanove" or "Arduino w/ATmega328" (slightly different than I've read - those selections are not available to me). I've tried both FTDI breakout and Adafruit cables. I started off with the sync error that is shown at the top of your referenced page and, after having difficulty with the ICSP interface (info follows), the code upload now just plain hangs (no info, no results, IDE hangs up - prob'ly makes sense).
After initially having trouble with the sync error on upload, I moved to an issue with reading the chip signature using AVR Studio/AVRISP mkII and attempting to upload either the 168/328 bootloader or the Failsafe code into the 45 chip. I have no known port/driver issues, and can connect to either chip but, again, the AVR programmer must connect to each chip at 1/4 the clock rate divided by 8 (as if the fuse setting is wrong).
Let's see, what else.
I'm powering the board(s) using RC power (although I've noted that it's 6V out of my ESC/BEC, so I'm at the top of the chip limit).
I've attempted to burn the failsafe code into the ATtiny45 regardless of connection speed - this leads to proper led behavior, but incorrect function (no RC control no matter what, on the bench).
I've attempted to burn my compiled hex ArduPilot code into the ATmega168, but the NE test code does not function properly (both this and above suggesting an inability to read pulses based on goofed up clock rate?)
Whew! Now you see why I haven't written before. I apologize for my long-windedness and "newbie" struggles, and appreciate any and all help in understanding the internals. I'm reticent to fire up my new board(s) until I know what I may have done to the last. (I will also try your suggestion, although I've uninstalled and re-installed).
THANKS!
Really sorry to hear about your problems. At this point the boards and code are pretty well tested, so there must be something unique about your setup or you're missing a key step. I assume you've run through all the debugging tips here? If so, then I suspect you've got a problem with your FTDI cable or driver. You might want to try a fresh install on another PC.
My apologies for my last entry starting with @Chris - my minds eye caught the previous entry and I copied that. If ANYONE out there can help, please do.
Hello! I've been pouring over the site for a couple months now, intermittently (the kids win all dad resource battles), while simultaneously joining the RC and autopilot communities. I've been building up a ground vehicle (refer to previous blogs re: crashing on the ground vice INTO the ground - oh, and I don't wanna call the Boulder Fire Department ; ) with a few different control mechanisms, one being ArduPilot (the others being a Sun SPOT base/remote, another being a PCTx interface). I believe I am now beating the dead horse that ranges from sync failures to clock rates to all-things-ICSP programming. I was able to program/load my first 168 board, once, using the FTDI breakout board, but began running into "the sync error" thereafter. While purchasing parts/learning AVR stuff, I purchased a 328 board. This board I've never been able to program (immediate sync errors). Here's my problem - for both boards, for both CHIPS (168/328 AND ATtiny45), the behavior I see is the same - it 'appears as if' the fuse settings are wrong, i.e., the clock is being divided by 8. I say 'appears as if' because the settings are cleared, per previous postings & images, AND I can actually measure the 168/328 clock at 16MHz - BUT, and again for both programming interfaces - I can only connect my AVRISP mkII at 1/4 the clock rate/8 (i.e., 500KHz and 250KHz) and still get a good signature. Is there a way that these settings can get 'hung' in the processor? If so, is there a way to clear them and recover the board? I eventually fried my 328 board (watch those probe pins boys!), and have now purchased 2 additional 328 boards (what a great machine for $25!!!), but am unwilling to just let this go without an understanding of what is going on in there. Thanks in advance.
BTW, I'll confess to being a member of the industrial machine in my other life, and this site and all that goes on around it kicks butt. This is the way open source developments, and perhaps developments in general, are s'posed to work. Hats off Chris & Jordi, and thanks to all out there.
One the GPS is in binary mode, the autopilot will be able to read it and the blinking blue LED should turn solid when it locks.
[The instructions were unclear on this, so thanks for the catch. I've updated them.]
Is there a way to test the gps module? I am unable to get the gps lock light (blue led) to go on. I am wondering if the module is having issues. I checked all the lights after i soldered up the new board and everything worked fine. Then i eventually loaded the code and now the blue led will not come on. The red led on the gps blinks so it is fair to say something is happening in there, just not sure what.
Thanks for the quick reply. I found the issue. Turns out my drivers were faulty, once I re-installed a new driver it worked like a charm!
-
1
-
2
-
3
-
4
-
5
of 13 Next