Images

HappyKillmore · 10:07 PM

Introduction with Disclaimers
This thread was created to help people get started with the ArduPilot (not ArduMega for right now) and it's integration with ArduIMU, Remzibi OSD and using the NMEA GPS unit that came with Remzibi's OSD. This project is not for the faint of heart. It requires time, money and at the very minimum the use of programming cables to update the firmware on 3 different devices. It might not require any actual programming knowledge to complete all the steps listed below, but you're going to have to install software and open uncompiled source code to upload it to your devices. Just fair warning. It's not rocket science, but it is going to require thought, some skill (making cables) and LOTS of patience. Please don't think you can follow these directions and get everything working in an hour (but who knows, maybe you can). The stuff below won't be at 100% newbie level but I'm also hoping it won't require that you be a programmer or an engineer to follow along. With that said (I hope I've covered my butt enough there)....

Everything you will need (does not include video/audio equipment for FPV)
Boards & Sensors:
ArduPilot ~$25 + Shipping
ArduShield V2 ~$57 (with cables, headers, etc) + Shipping
ArduIMU ~$100 + Shipping
Remzibi OSD ~$114 + Shipping

Cables & Connectors:
FTDI Cable ~$20 + Shipping
Straight Headers ~$5 (Might want to get 2-3 of these) + Shipping
.1" Connectors ~Depends. I bought a bunch of different sizes from 1x1 to 1x6 so I could make all the different connectors I'd need
Servo Cable ~$4 + Shipping
EasyCAP (Optional) ~$10 + Shipping (This will make life easier during step #5 testing)

Tools you will need:
Soldering Iron
Crimping Tool ~$15 + Shipping - You might want to consider a kit
Servo Driver ~$9 + Shipping (Makes life easier so you don't have to use your RX to cahnge modes)
BEC to use as 5V Power supply (optional)

So you're looking at about $325 + connectors and tools

Steps in the Process
To make life easier, you may want to complete the steps listed below in the order I have them listed. Trying to jump to the last step without completing those that come before it is a recipe for disaster. There is troubleshooting required at each step and since the software is a compilation of several people's work and enhancements are made from time to time, it is best to make sure one thing works at a time.

Step 1) Getting the ArduPilot to work with the Remzibi GPS unit.
Step 2) Getting the ArduPilot to work with the ArduShield and the Remzibi GPS unit (optional if using ArduIMU).
Step 3) Getting the ArduIMU to work with the Remzibi GPS unit.
Step 4) Getting the ArduPilot to work with the ArduIMU and Remzibi GPS unit.
Step 5) Getting the Remzibi OSD to work with the ArduPilot, ArduShield, ArduIMU and Remzibi GPS unit.

A few decisions to make
While this code generally aims at using the NMEA GPS unit that ships with Remzibi's OSD, you have the option of using other GPS units. Currently, uBlox and NMEA are the only two units fully supported, but Sirf (EM-406) support will be added shortly. Listed below are your options and some pros and cons to the decisions you make:

1) Which GPS to use?
The NMEA unit that comes with Remzibi's OSD is very inexpensive. If you purchased an OSD then you already have one. It's accuracy isn't fantastic (+/- 9 ft) but it is 5V (instead of 3.3V) which means it will work with the IMU, the ArduPilot, the OSD or the Shield and it's capable of up to 115,200 baud (not recommended) and 10Hz (not really necessary).

Your next option would be another inexpensive NMEA GPS like the one sold by OHARAP. The unit is $25 and you might want to get the breakout board for another $12.50 (since the GPS itself has 2mm pins instead of the typical .1" header pins). This is a 3.3V unit and will require the use of the ArduShield which has a 3.3V voltage regulator on board. In reality, you probably don't want to use a 3.3V GPS for this reason. Your hands will be tied and require you to use the ArduShield.

If your GPS is broken, lost or you just need another one, Jordi has started selling the same unit as Remzibi's for only $35. If you've got one routed through one plane and you're building another, you've got the option of buying more...

Next, you can get a Sirf GPS from Jordi for $60 or from Futurelec for $40. I can't say why you'd want to go this route since I don't know what the advantage to Sirf or this module is, but it's going to be supported by this thread shortly.

Lastly, there's uBlox. To my knowledge, it's considered to be the best. It has the biggest antenna, it can go NMEA or uBlox binary protocol and on "warm" starts, it aquires GPS lock in about 2 seconds (which is waaaaay faster than the NMEA units). The uBlox GPS is $90 plus $20 for the adapter so it's by far the most expensive. The accuracy is also supposed to be the best on this unit. One minor perk to the uBlox is in the current edits to the ArduPilot firmware, the uBlox code allows for a "timezoneoffset" selection so you can show actual time on your OSD instead of UTC time (Greenwich mean time).

2) To shield or not to shield...V1 or V2?
I can't say for sure what's different between the two versions of the ArduShield...other than an additional mux (I think) to enable or disable different serial ports (3 on the shield but all connected to one serial port on the ArduPilot). The benefit of using the shield is it has the built in 3.3V voltage regulator as mentioned above, so if you've got a 3.3V GPS, you need to use it. The other thing it provides is a pressure sensor to determine if the plane is moving forward. If you don't have this, when the plane is flying itself, it will have to use a fixed throttle position instead of varying the throttle to keep it moving. Also, if you're using the thermopiles (not the ArduIMU) the shield has a nice connector for attaching them. You may also want to try this stand-alone pressure sensor instead of the whole shield.

3) Which OSD firmware?
There are currently 3 versions of firmware available for Remzibi's OSD. Here we're only focused on OSDV1_68 (standard) and ARDU1_3. The standard firmware contains all the logic of the stand-alone OSD where it's expecting to just have a NMEA GPS unit connected. The additional display variables shown are sent through a custom command message called $M commands. These can be configured to show anything you want from debug messages to contol mode messages (like which mode, waypoint, distance, etc). Only text strings can be added to your existing layout that was configured through the Remzibi OSD config tool.

The Ardu firmware V1.3 uses !!!*** and +++*** status messages from the ArduPilot to show all of the same data except for UTC date and time and does not include any logic for distance to home or direction home. So why would you want to use this firmware? Because it includes a rather basic artificial horizon. There are a series of dashes that appear in the middle of the screen and get updated about 10 times a second. So there's very little lag. The other data gets updated about twice a second since it's not so time critical. $M commands are not compatible with Ardu firmware 1.3 on the OSD and if you try sending them, it will detect 9600 baud rate no matter what...and then nothing will work.

Remzibi's next release of the Ardu firmware will support a few new messages and will no longer support the !!!*** and +++*** status messages from the ArduPilot. Instead $M, $A (replaces status messages), $I (IMU data for pitch and roll) and $SH (to set home location) will be available.

4) How fast should I go?
So everything here has the ability to go 115200 baud and some GPS's can do 10Hz...so why not? Here's the reason. Most of the ArduPilot source was written to work best with uBlox which is fixed at 4Hz. That means 4 times a second, the uBlox sends a message to the ArduPilot. Then the ArduPilot has to do something with it just as fast as it comes in. If you start cranking out data 2.5 times as fast, then the ArduPilot is going to have a hard time parsing all that data. Plus, do you really need the data that fast? Usually, the answer is no. So my suggestion is to stick to between 3 and 5Hz. Another thing to remember is your base station software. It's been my experience that even at 5Hz, the base station software can't handle it....

Baud rate is typically 38,400. That's fast enough to give you lots of bandwidth but not so fast that you get a bunch of checksum errors and re-sent data. By my calculations, the uBlox at 4Hz sending it's 4 messages (NAV-POSLLH, NAV-VELNED, NAV-STATUS and NAV-SOL) it's using 18% of it's bandwidth at 38,400. With NMEA's 2 messages (GPGGA and GPRMC) at 4Hz and 38.400 baud, it's using 16% of the available bandwidth. So the faster you go, the more bandwidth available and the more error prone things will be due to outside interference.

Other places to go to read and get help
ArduPilot Homepage
ArduPilot Manual
ArduPilot Code Page
ArduIMU Code Page
DIYDrones.com
Remzibi (Poor Man's OSD) Thread
Remzibi OSD FAQ Page
NMEA Sentence Detail

Parts List Photo

What's not shown above is all of the video equipment required to use the OSD. Video transmitter & receiver, camera, antennas, etc.

Here's a very impressive example of the end result from cholo!!!!

ArduPilot + ArduIMU + Remzibi OSD (AXN Floater Jet) (6 min 18 sec)

HappyKillmore · 02:02 PM

Step 1 - Getting the ArduPilot to work with the Remzibi GPS unit.
The very first thing to do is go and get yourself something to drink. Make sure you're relaxed because there's lots to read and do below. It's not impossible, just make sure you do everything one line at a time. If you skip anything, you'll have a hard time figuring out what you've done wrong.

So let's get started. You'll need to download the Arduino development environment from Arduino.cc. It's free (as is all of the other software you'll be using for this project, so you've got that going for you!). At the time of this writing, Arduino Development environment 0018 was the latest and greatest. http://arduino.googlecode.com/files/arduino-0018.zip

To make life easier, I'm going to assume everything you're doing is in a folder called C:\Projects\ArduPilot. That will be the "base" folder for all the instructions to follow.

Download the developement environment and unzip it into the base folder. It will create a subfolder called arduino-0018 (Full path of C:\Projects\ArduPilot\arduino-0018).

In the C:\Projects\ArduPilot\arduino-0018 folder double click on the Arduino.exe executable. It will open the program and make life easier when you double-click on a .pde file in the future.

NOTE: If you're an existing Arduino user and you're putting this in a "new" folder (C:\Projects\ArduPilot) you might get a launch4j error message. To fix this, click ok to the error, close Arduino and open your "My Documents" folder. Delete the folder named "Arduino" in this folder. Then run Arduino.exe again. It will give you a different message about creating a default sketchbook.

Next you'll need to download the ArduPilot source code from the ArduPilot Code Page. At the time of this writing, the version number was 2.6 Beta. http://ardupilot.googlecode.com/files/ArduPilot_2_6.zip

Unzip this into a folder called ArduPilot_2_6 in the base folder (Full path of C:\Projects\ArduPilot\ArduPilot_2_6).

At this point, connect up the hardware. All you need is your fully assembled ArduPilot (headers soldered on and jumpers on the back in the photos shown below). You'll need the FTDI cable and your servo driver/tester.

I must be going blind...these closeup photos always suprise me. Look how awful that solder job is on the green wire! I've got to fix that!!!

You can get more info on soldering in the ArduPilot Manual

At this point, you're ready to plug in your FTDI cable to a USB port on your computer. The FTDI cable in particular will find it's own "drivers" in Windows. Very easy to get started since it's built-in to Windows.

Once your FTDI cable is connected you should be able to click the Windows Key + R (or Start, Run) and enter devmgmt.msc and ok. Click the + next to (Ports COM & LPT) and look for the one that says "USB Serial Port." You can right click and select properties and then the Driver Tab. It should say "Driver Provider: FTDI." You need to know the COM port number (in the example below it's COM16).

While you're here, make sure the "Set RTS on Close" setting is set correctly.

Click Port Settings, Advanced, Make sure "Set RTS on Close" is checked
*NOTE: You don't need to mess with any of the baud rate settings. Even though it says 9600, don't worry. This has no effect.

You should be able to double click on any of the .pde files in C:\Projects\ArduPilot\ArduPilot_2_6 and it should open the Arduino development environment (also called "Processing" if it pops up asking what program to open with).

Click the tab labelled "ap_2_6_header.h" and change line #define GPS_PROTOCOL 2 to #define GPS_PROTOCOL 0. This will enable the NMEA protocol. NOTE: Be SURE to hit the SAVE button after editing anything on a tab!!!

Next Click the tab labelled "ArduPilot_2_6" and edit the "GPS_PROTOCOL == 0" if statement to use "THIRTY_EIGHT_K_BAUD" instead of "FIFTY_SEVEN_K_BAUD"

Code:

void setup() {
	#if GPS_PROTOCOL == 0
		Serial.begin(THIRTY_EIGHT_K_BAUD);
	#endif
	#if GPS_PROTOCOL == 1
		Serial.begin(FIFTY_SEVEN_K_BAUD);
	#endif
	#if GPS_PROTOCOL == 2
		Serial.begin(THIRTY_EIGHT_K_BAUD);
	#endif
	#if GPS_PROTOCOL == 3
		Serial.begin(THIRTY_EIGHT_K_BAUD);
	#endif
	#if GPS_PROTOCOL == 5
		Serial.begin(THIRTY_EIGHT_K_BAUD);
	#endif
	
	init_ardupilot();
}

NOTE: Be SURE to hit the SAVE button after editing anything on a tab!!!

Now we're ready to connect the FTDI cable to the ArduPilot. See the photo below. Only connect the FTDI cable and the Servo tester to the CTRL connection. DO NOT CONNECT THE GPS at this point.

Please note that in reality, the blue GPS lock light is blinking at this point. It appears to be on solid in the picture. Yours may not be blinking at all.

Next, you'll need to select the COM port for your FTDI cable in the Arduino Editor under Tools, Serial Port and then select your COM port. Please make sure that you've hit the save button after editing the two tabs above and then click the "Compile and Upload" (shows just "Upload" when you put your mouse over it) button.

After about 25 seconds, your blue light should start blinking. Place your servo tester setting to the "middle" of the dial (1.5ms).

Next, run the installer for the ArduIMU Test program which includes the GPS Emulator v2.0.0. http://www.happykillmore.com/Softwar...etup/Setup.exe

Uncheck the "Launch ArduIMU Test" and leave "Launch GPS Emulator" checked.

We're going to do a quick test to make sure things are working alright before hooking up the GPS. When you launch the emulator, chances are good it will automatically find the right COM port. Click the button "Disconnect" and select Options, Baud, 38,400, Click Connect and then Start at the bottom left.

So you should be able to look at your ArduPilot and the blue light should be on solid. This indicates you have a GPS lock. It is important you get the solid blue light at this point.

The lights should show as follows (on the ArduPilot)
Power - Solid Red
Lock - Solid Blue
Mux - Solid Red
Mode - Solid Green

If all of these lights are correct then proceed to the next step

Click Exit on the GPS Emulator

Disconnect the FTDI cable and leave the Servo tester connected.

Take the Remzibi GPS module and plug it in as shown below and reconnect the FTDI cable.
NOTE: The blue and white wires MUST be switched on the GPS' plug. So it should go white, blue, red, black!

The blue light will start flashing again. This step can take 2-3 minutes depending upon where you're working. If you're like me and you're sitting in an upstairs bedroom, expect to wait for about 2 minutes. If you're outside, you can get a lock in as little as 30 seconds.

What will happen is the blue light will start blinking and then go solid and then blink and then go solid. This means you've got it! What's happening right now is the output buffer on the serial port is crapping all over itself. If you open HyperTerminal and connect to your COM port (ie COM16) and select a baud of 38,400 with all other settings as the default... you'll see LOTS of data start scrolling past and the blue light will go solid on the ArduPilot.

Congratulations! You survived Step #1!!!!

Don't worry, it gets easier from here!

HappyKillmore · 06:59 PM

Step 2 - Getting the ArduPilot to work with the ArduShield and the Remzibi GPS unit.
NOTE: If you're planning on continuing to step #3 and are going to use the ArduIMU then this step is not necessary. Your GPS will be connecting directly to the ArduIMU and you don't need to worry about getting a GPS lock through the ArduShield. You may still want to use the shield for the pressure sensor (provides feedback that the plane is moving forward for throttle control) but all this testing is not needed. It will be plug-n-play. So you can skip to step #3.

If you're not using the ArduIMU and will be using a co-pilot or thermopiles/infra-red sensors instead, then you'll want to complete this step.

First, you should give yourself a pat on the back for completing step 1. You've set the stage for the future steps and most of the "hard" stuff is behind you. This step will be pretty quick and easy.

These initial instructions only apply to the ArduShield V1 (red colored PCB board) since I seem to have fried my V2 board during this testing process.

First, solder the headers onto the ArduShield (Top and bottom).

Then plug the ArduShield on to the ArduPilot.

Next, connect the GPS unit to the "vertical" pins at the bottom left and connect the FTDI cable. It's helpful to leave the servo tester connected for debugging purposes.

The blue light should start blinking at this point.

Click Start, All Programs, Accessories, Communications and open Hyper Terminal (you can also use Start, Run, "hypertrm.exe")

Type the COM port you're using for the name of the connection (ie COM16)
Select your COM port from the drop down selection under "Connect Using" and click ok
Select 38,400 for the baud rate, everything else as the defaults (8, None, 1, Hardware) and click ok

You should be able to see text that you can read scrolling across the screen. If you can't read it, then you've selected the wrong baud rate either in the Hyperterminal software or you didn't set it right in step 1.

Watch on the screen for a message that says "no GPS, last 20s." If you see this message, your GPS is not sending any information to the ArduShield or ArduPilot.

If you don't see this message, then the ArduPilot is waiting for GPS lock which can take several minutes.

You should be able to turn the knob on your servo tester while you're waiting and see the mode changing.

Once you get GPS lock the lock light will go solid blue and you'll start seeing messages like the ones below.

HappyKillmore · 10:38 PM

Step 3 -Getting the ArduIMU to work with the Remzibi GPS unit.

This step will require your Remzibi NMEA GPS, ArduIMU and your FTDI cable. Our mission is to get the GPS talking to the ArduIMU and passing all of the roll, pitch and yaw data along with the GPS lat, long, speed, etc all in one message. We're working towards getting everything working using the "new" binary protocol to talk between the ArduIMU and the ArduPilot.

So solder your headers on the IMU board and connect everything as shown below:

The pins on the top edge of the board are for an optional magnetometer which can be added to increase the accuracy (and remove drift) of the IMU.

Next, download Doug Weibel's code from the ArduIMU Download Page. At the time of this writing, v1.7 was the most current http://ardu-imu.googlecode.com/files/ArduIMU_1.7.zip

Unzip the contents into a folder called C:\Projects\ArduIMU

Double-click on any of the .pde files (ie arduimu.pde)

Once the editor opens, you're going to need to edit a few of the settings in the arduimu tab (far left)

Code:

#define BOARD_VERSION 2 // 1 For V1 and 2 for V2

// Ublox gps is recommended!
#define GPS_PROTOCOL 3    // 1 - Ublox,  2 - EM406,  3 - NMEA    We have only tested with Ublox

// Enable Air Start uses Remove Before Fly flag - connection to pin 6 on ArduPilot 
#define ENABLE_AIR_START 1  //  1 if using airstart/groundstart signaling, 0 if not
#define GROUNDSTART_PIN 8    //  Pin number used for ground start signal (recommend 10 on v1 and 8 on v2 hardware)

/*Min Speed Filter for Yaw drift Correction*/
#define SPEEDFILT 2 // >1 use min speed filter for yaw drift cancellation, 0=do not use speed filter

/*For debugging propurses*/
#define PRINT_DEBUG 0   //Will print Debug messages

//OUTPUTMODE=1 will print the corrected data, 0 will print uncorrected data of the gyros (with drift), 2 will print accelerometer only data
#define OUTPUTMODE 1

#define PRINT_DCM 0     //Will print the whole direction cosine matrix
#define PRINT_ANALOGS 0 //Will print the analog raw data
#define PRINT_EULER 1   //Will print the Euler angles Roll, Pitch and Yaw
#define PRINT_GPS 1     //Will print GPS data

// *** NOTE!   To use ArduIMU with ArduPilot you must select binary output messages
#define PRINT_BINARY 1   //Will print binary message and suppress ASCII messages (above)

// *** NOTE!   Performance reporting is only supported for Ublox.  Set to 0 for others
#define PERFORMANCE_REPORTING 1  //Will include performance reports in the binary output ~ 1/2 min

/* Support for optional magnetometer (1 enabled, 0 dissabled) */
#define USE_MAGNETOMETER 0 // use 1 if you want to make yaw gyro drift corrections using the optional magnetometer                   

/* Support for optional barometer (1 enabled, 0 dissabled) */
#define USE_BAROMETER 0 	// use 1 if you want to get altitude using the optional absolute pressure sensor                  
#define ALT_MIX	50			// For binary messages: GPS or barometric altitude.  0 to 100 = % of barometric.  For example 75 gives 25% GPS alt and 75% baro

In that same tab scroll about 1/2 way down to the function "void setup()"

Replace the function from the lin void setup() down to "debug_print("Welcome...");" with the text below.

Code:

void setup()
{ 
  #if GPS_CONNECTION == 0
      pinMode(2,OUTPUT); //Serial Mux
      digitalWrite(2,HIGH); //Serial Mux
  #endif
  //Serial.begin(38400);
  
  //Serial.begin(57600);
  pinMode(5,OUTPUT); //Red LED
  pinMode(6,OUTPUT); // Blue LED
  pinMode(7,OUTPUT); // Yellow LED
  pinMode(GROUNDSTART_PIN,INPUT);  // Remove Before Fly flag (pin 6 on ArduPilot)
  digitalWrite(GROUNDSTART_PIN,HIGH);

  init_gps();
  
  Analog_Reference(EXTERNAL);//Using external analog reference
  Analog_Init();
  
  debug_print("Welcome...");

Next, click the tab for GPS_NMEA

Highlight all the way down to the end of the init_gps function (right above where it says void decode_gps(void) and delete everything you just highlighted. Replace it with the code below. I have added some more options in the PMTK strings that don't exist in Doug's online version.

Code:

#if GPS_PROTOCOL == 3

// LED Status indication
//----------------------
// Blue + Red flash twice = Sending GPS configuration commands
// Blue flashing = Receiving data from GPS but no fix lock yet (flash rate shows hertz/messages per second)
// Blue solid = GPS fix locked
// Red solid = Gyro saturation
// Yellow solid = Speed too slow and yaw correction supressed

//*********************************************************************************************
//  You may need to insert parameters appropriate for your gps from this list into init_gps()
//GPS SIRF configuration strings... 
#define SIRF_BAUD_RATE_4800    "$PSRF100,1,4800,8,1,0*0E\r\n"
#define SIRF_BAUD_RATE_9600    "$PSRF100,1,9600,8,1,0*0D\r\n"
#define SIRF_BAUD_RATE_19200    "$PSRF100,1,19200,8,1,0*38\r\n"
#define SIRF_BAUD_RATE_38400    "$PSRF100,1,38400,8,1,0*3D\r\n"  
#define SIRF_BAUD_RATE_57600    "$PSRF100,1,57600,8,1,0*36\r\n"
#define GSA_ON   "$PSRF103,2,0,1,1*27\r\n"   // enable GSA
#define GSA_OFF  "$PSRF103,2,0,0,1*26\r\n"   // disable GSA
#define GSV_ON   "$PSRF103,3,0,1,1*26\r\n"  // enable GSV
#define GSV_OFF  "$PSRF103,3,0,0,1*27\r\n"  // disable GSV
#define USE_WAAS   1     //1 = Enable, 0 = Disable, good in USA, slower FIX... 
#define WAAS_ON    "$PSRF151,1*3F\r\n"       // enable WAAS
#define WAAS_OFF   "$PSRF151,0*3E\r\n"       // disable WAAS

//GPS Locosys configuration strings...
#define USE_SBAS 0
#define SBAS_ON "$PMTK313,1*2E\r\n"
#define SBAS_OFF "$PMTK313,0*2F\r\n"

#define DGPS_OFF "$PMTK301,0*2C\r\n"
#define DGPS_RTCM "$PMTK301,1*2D\r\n"
#define DGPS_SBAS "$PMTK301,2*2E\r\n"

#define DATUM_GOOGLE "$PMTK330,0*2E\r\n"

#define NMEA_OUTPUT_5HZ "$PMTK314,0,5,0,5,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n" //Set GGA and RMC to 5HZ  
#define NMEA_OUTPUT_4HZ "$PMTK314,0,4,0,4,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n" //Set GGA and RMC to 4HZ 
#define NMEA_OUTPUT_3HZ "$PMTK314,0,3,0,3,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n" //Set GGA and RMC to 3HZ 
#define NMEA_OUTPUT_2HZ "$PMTK314,0,2,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n" //Set GGA and RMC to 2HZ 
#define NMEA_OUTPUT_1HZ "$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n" //Set GGA and RMC to 1HZ

#define LOCOSYS_REFRESH_RATE_100 "$PMTK220,100*2F\r\n" //100 milliseconds 
#define LOCOSYS_REFRESH_RATE_200 "$PMTK220,200*2C\r\n" //200 milliseconds 
#define LOCOSYS_REFRESH_RATE_250 "$PMTK220,250*29\r\n" //250 milliseconds
#define LOCOSYS_REFRESH_RATE_333 "$PMTK220,333*2D\r\n" //500 milliseconds
#define LOCOSYS_REFRESH_RATE_500 "$PMTK220,500*2B\r\n" //500 milliseconds
#define LOCOSYS_REFRESH_RATE_1000 "$PMTK220,1000*1F\r\n" //500 milliseconds

#define LOCOSYS_BAUD_RATE_4800 "$PMTK251,4800*14\r\n"
#define LOCOSYS_BAUD_RATE_9600 "$PMTK251,9600*17\r\n"
#define LOCOSYS_BAUD_RATE_19200 "$PMTK251,19200*22\r\n"
#define LOCOSYS_BAUD_RATE_38400 "$PMTK251,38400*27\r\n"
#define LOCOSYS_BAUD_RATE_57600 "$PMTK251,57600*2C\r\n"
#define LOCOSYS_BAUD_RATE_115200 "$PMTK251,115200*1F\r\n"

//**************************************************************************************************************

/****************************************************************
 Parsing stuff for NMEA
 ****************************************************************/
#define BUF_LEN 200

// GPS Pointers
char *token;
char *search = ",";
char *brkb, *pEnd;
char gps_buffer[BUF_LEN]; //The traditional buffer.

void init_gps(void)
{
	Serial.begin(38400); //This value must be the original "default" GPS speed
	delay(2000);
        digitalWrite(5,HIGH); // Turn Red LED ON to indicate PMTK strings sending
        digitalWrite(6,HIGH); // Turn Blue LED ON to indicate PMTK strings sending
	Serial.println(LOCOSYS_BAUD_RATE_38400); //This is your desired speed
	delay(500);
        digitalWrite(5,LOW); // Turn Red LED OFF to indicate PMTK strings sending
        digitalWrite(6,LOW); // Turn Blue LED OFF to indicate PMTK strings sending
        Serial.end();
	Serial.begin(38400); //This is your desired speed
	delay(500);
        digitalWrite(5,HIGH); // Turn Red LED ON to indicate PMTK strings sending
        digitalWrite(6,HIGH); // Turn Blue LED ON to indicate PMTK strings sending
	Serial.println(LOCOSYS_REFRESH_RATE_200); // Edit this to change Hertz. 100 = 10Hz, 200 = 5Hz, 250 = 4Hz
	Serial.println(NMEA_OUTPUT_1HZ); // Don't edit this
	Serial.println(SBAS_ON); 
	Serial.println(DGPS_SBAS);
	Serial.println(DATUM_GOOGLE);
	delay(500);
        digitalWrite(5,LOW); // Turn Red LED OFF to indicate PMTK strings sending
        digitalWrite(6,LOW); // Turn Blue LED OFF to indicate PMTK strings sending

/* EM406 example init
	Serial.begin(4800); //Universal Sincronus Asyncronus Receiveing Transmiting 
	delay(1000);
	Serial.print(SIRF_BAUD_RATE_9600);
 
	Serial.begin(9600);
	delay(1000);
	
	Serial.print(GSV_OFF);
	Serial.print(GSA_OFF);
	
	#if USE_WAAS == 1
	Serial.print(WAAS_ON);
	#else
	Serial.print(WAAS_OFF);
	#endif*/
}

Once you've got that code pasted in, look for the line that reads "Serial.begin(38400);" If you have one of the older Remzibi units, your GPS may default to 9600 baud. You can tell when you first start up the OSD and you're looking at the monitor/goggles it will tell you what baud rate it's using. Newer units will use 38400 baud by default.

Simply make sure the line "Serial.begin(38400);" is filled in with the default speed of your GPS.

Next, edit the lines "Serial.println(LOCOSYS_BAUD_RATE_57600);" and "Serial.begin(57600);" to be whatever speed you'd like to use.

I recommend 38400 or 19200. You can try 57600 if you want, but I'd strongly suggest not trying 115200 in flight. There will be far too much noise in the plane to use this baud rate without shielding on your wires (or that is my assumption anyhow).

NOTE: If you mess around with your baud rate and you're setting the "default" value of your GPS to something else, you'll need to unplug your GPS or FTDI cable (remove power) to the GPS to get it to recognize the new desired baud rate. It's a bit confusing, but if you change the default from 9600 to 19200, for example, and then decide you want to change it to 38400, disconnect power to the GPS first. You NEED to use the default that's burned in the memory on the GPS (ie 9600 or 38400) as the starting value or when you get out in the field, it won't work right. To get it back to the factory defaults, pull the power.

You can try editing the LOCOSYS_REFRESH_RATE_200 value if you want. In theory, this command determines how often the GPS messages get sent. 100 = every 100ms or 10 times a second = 10hz. 200 = 200ms or 5 times a second = 5hz. 250 = 4hz. Those are the only 3 options I have in there right now but if you need more options, let me know and I'll calculate the checksum and post them here. In practice, you won't get anywhere near this rate even with 115200 baud... so I'd stick with 200 or 250.

Finally, you can edit NMEA_OUTPUT_1HZ if you'd like. The naming convention for this variable is a bit deceiving since these settings do not determine the Hz. These settings have to do with how often each message gets sent. The 1HZ setting means all messages get sent every LOCOSYS_REFRESH_RATE_200 milliseconds (in the case of 200). On the 2Hz setting, all messages will get sent every 200ms X 2 = 400ms. It's a bit confusing, but it would allow you to have the GPS send different messages at different intervals. In our case, we just want them as fast as we can get them and we want both messages (GPRMC and GPGGA) every cycle.

Make sure to save your work and upload to the ArduIMU.

Next, download the latest version of my software found here: http://www.happykillmore.com/Softwar...etup/Setup.exe and run the ArduIMU Test application.

Make sure you have selected the right COM port and baud rate (the baud rate you specified on the GPS_NMEA tab Serial.begin(57600); //This is your desired speed).

Your output should look something like what is shown below:

Your blue light "should" be on solid on your ArduIMU (give it at least 3 minutes!!) and you should be able move the ArduIMU and see the plane move on the screen. The performance data is updated every 20 seconds by default except the "health" field which gets updated every cycle.

You'll notice the "GPS messages" field near the bottom right. This is how many messages came in over 20 seconds. The best I've seen here in my office is 42 in 20 secs or just over 2 per second with 38400 baud, LOCOSYS_REFRESH_RATE_200, NMEA_OUTPUT_1HZ, SBAS_ON, DGPS_SBAS.

HappyKillmore · 07:49 AM

Step 4 -Getting the ArduPilot to work with the ArduIMU and Remzibi GPS unit.

For this step, you'll need the GPS, ArduIMU, ArduPilot and a servo tester (or powered up radio system with a 3 positions switch for testing).

The wiring in this step is a "little" tricky and I plan on making a custom cable for this setup....but that's a project for later.

You're going to need to go in and edit the ArduPilot source code again so connect just the FTDI cable to the ArduPilot (servo tester optional)

Go in to the folder C:\Projects\ArduPilot_2_6 and double click on any of the .pde files (ie ArduPilot_2_6.pde)

In the ap_2_6_header.h tab, you'll need to edit the line below

Code:

#define GPS_PROTOCOL 3

It will be near the top of the page.

Depending upon what you selected as your "desired" baud rate back on step #3 you might have to edit the ArduPilot_2_6 tab to your desired baud (if you are using 38400, then you don't have to change anything).

Code:

// Basic Initialization
//---------------------
void setup() {
	#if GPS_PROTOCOL == 0
		Serial.begin(THIRTY_EIGHT_K_BAUD);
	#endif
	#if GPS_PROTOCOL == 1
		Serial.begin(FIFTY_SEVEN_K_BAUD);
	#endif
	#if GPS_PROTOCOL == 2
		Serial.begin(THIRTY_EIGHT_K_BAUD);
	#endif
	#if GPS_PROTOCOL == 3
		Serial.begin(THIRTY_EIGHT_K_BAUD); // Change this to your desired baud rate
	#endif
	#if GPS_PROTOCOL == 5
		Serial.begin(THIRTY_EIGHT_K_BAUD);
	#endif
	
	init_ardupilot();
}

Now it's time to wire everything together. Disconnect your FTDI cable (so the power's off) and make sure you wire it correctly before re-connecting the FTDI cable.

For more detail on how this is connected, take a look here: http://code.google.com/p/ardupilot/wiki/ArduIMU

This photo is so nice and clean! I'm not so sure about the location of the connections since with everything hooked up this way, you can't connect your FTDI cable and see what's going on!

Here's how I connected everything:

Now plug in the FTDI cable.

Click Start, Run, hypertrm.exe, ok

Enter your COM port for the name (ie COM16), ok
Select your COM port under "connect using", ok
Select your baud rate, ok

Within 3 minutes your GPS lock light should go solid blue on the IMU and stay on rock solid. The ArduPilot is a different matter entirely. Min is flashing and then solid, flashing and then solid. I'm going to do some testing to see what I can do to improve this.

Here's a screenshot of my HyperTerminal window. You'll notice that RLL and PCH actually change as you move the IMU!!! I think it's working!!!

EDIT: I just did some testing with the uBlox GPS and the amount of data streaming out of that thing is about 10 TIMES the quantity. It also goes GPS lock in about 10 seconds instead of minutes. I hate to say it, but the uBlox is so much better than the NMEA GPS it's rediculous....

I still haven't ruled out a bad parsing routing or some error somewhere in the code...but wow, this uBlox works great!

HyperTerm window for comparison. You'll notice that the GPS data comes about every 2 IMU position updates.

HappyKillmore · 09:23 AM

Step 5 - Getting the Remzibi OSD to work with the ArduPilot, ArduShield, ArduIMU and Remzibi GPS unit.
Alright, it's time to make sure you've got a comfortable chair and all the tools you will need for this lengthy step.

What you need for Step #5
Hardware:
ArduPilot
ArduShield (optional)
ArduIMU
Remzibi NMEA GPS (or uBlox or EM406)
Remzibi OSD

Tools:
Servo Tester (or RX and powered up radio)
2S or 3S Lipo
.1" header crimpers (http://hansenhobbies.com/products/co...ools/crimp_ec/)
About 30 .1" Female Gold Terminals (http://hansenhobbies.com/products/co...1inconnectors/)
An assortment of .1" housings from 1x1 to 1x5 (http://hansenhobbies.com/products/co...1inconnectors/)
Some multicolored ribbon cable (http://www.futurlec.com/Cable.shtml)
Wire stripping tool (http://hansenhobbies.com/products/co...trip_20-30awg/)
EasyCAP
5V BEC (optional) http://www.hobbycity.com/hobbyking/s...idProduct=4319

Cables:
Remzibi USB to serial cable
FTDI cable
A video RCA cable with one end chopped off and a JST or 1x2 .1" header installed (for video out on OSD)

Overview of Cabling Requirements
Note: The color of the wires in the photos below do NOT follow any coloring convention. Red is NOT always 5V and black is NOT always ground. Please pay CLOSE attention! Wiring up your system incorrectly CAN cause you to FRY components!!!!

Note: There are several ways to wire everything together. The ArduShield, ArduIMU and ArduPilot each have multiple TX/RX connections so this is not the only way to do it. One thing to keep in mind with the ArduIMU is that it has a "mux" onboard which enables or disables the different TX pins from inside the software. The lines pinMode(2,OUTPUT) in void setup() on the main arduimu.pde tab is where you can enable or disable the ports as needed.

Programming your hardware
I was hoping I wouldn't have to do this, but I've made so many changes to both the ArduIMU 1.7 and ArduPilot 2.6 source code (and I'm not done yet) that I might as well just post my entire folder.
Download ArduPilot 2.6 and ArduIMU 1.7
You'll also need to download the latest GPS Emulator and ArduIMU Test app again (still a work in progress) as I'm adding ArduIMU binary protocol support.
I guess you'll need the Remzibi Config Tool too to setup your OSD.

Once you've got everything downloaded again, you'll want to connect your FTDI cable to your ArduIMU and write the new firmware. One nice thing about the ArduIMU is that you don't have to disconnect anything during the software update process. It has that build-in MUX that disables the other ports so you're not trying to write stuff to your GPS instead of your ArduIMU.

Next, connect your FTDI cable to your ArduPilot and write the new firmware. You'll want to make sure you have set the parameter #define GPS_PROTOCOL 3 in the ap_2_6_header.h tab. I keep posting updates to the source code and sometimes I'm working on the ArduIMU binary protocol and sometimes I'm not...so I've forgotten to change this a few times....so check it to make sure. Another thing to watch out for is there is a variable called #define GCS_PROTOCOL which is not the parameter you want to change. GPS not GCS. I've made that mistake a few times....

Note: I'm going to tell you this, but you'll forget just like I did... when writing the firmware to the ArduPilot you MUST disconnect the ArduShield and the cable to the ArduIMU but you can leave the servo tester connected. If you don't disconnect this wire you'll get an error message during the write process. Something like:

Code:

avrdude: stk500_getsync(): not in sync: resp=0x10
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x10

Now wire everything together

Displaying the ArduPilot Mode on Remzibi's OSD
If you've got a Remzibi OSD, then I'm assuming you've got the config tool and know how to use it

So get that thing fired up and setup your layout.

A few things to note. My edits to the ArduPilot firmware will pass all of the NMEA data that gets shown on the Remzibi OSD... only if you're using a NMEA GPS. If you're using uBlox, then GPS Date and Time will not work and I haven't changed anything for Sirf to identify the number of satellites (so it will never auto-set home or show number of satellites).

The OSD uses a custom output message ($M) that's included in the GPGGA and GPRMC message sentences sent from the ArduPilot to the OSD. To edit the location, wording and custom graphics, you'll need to edit the tab called "remzibi" in the ArduPilot 2.6 source code in the section called "print_remzibi."
You can have more than one of these messages. The messages use the format below:

Code:

$MCCRRFFLLMessage<CR><LF>
$M = Header
CC = Column (Hex), add 80h for "small fonts"
RR = Row (Hex)
FF = First Character ID (Hex) - Symbol in front of message
LL = Last Character ID (Hex) - Symbol at end of message
Message = Any text - Max length is 85 characters 

Example 1: $M8102A900Hello World<CR><LF> = Column 1 with small fonts, Row 2, character from font file A9 at beginning, nothing at end
Example 2: $M0102A900Hello World<CR><LF> = Column 1 with large fonts, Row 2, character from font file A9 at beginning, nothing at end

If you're using an EasyCAP, then launch AmCap to view the output from the OSD. I've found it's easiest to use a 5V BEC to power everything and I connect it to the ArduIMU. Alternatively, you can connect a 2S to 3S LiPo to the Remzibi OSD and use it's onboard voltage converter....but things on the OSD get HOT quick and I prefer to keep everything cool during testing.

Another solution is to use the !!!*** status messages from the ArduPilot (OSD firmware Ardu1.3 or older) or the new $A status messages in OSD firmware Ardu 1.4 or newer. The downside to this method is the OSD does not set a home location and give you any directional way home or distance from home. It also will still require the $M messages to show the current mode the ArduPilot is in. The upside to using this firmware is you get a series of horizontal lines that show an artificial horizon based on feedback from the IMU. You do not need to connect anything to the ADC inputs on the OSD to make this information appear. All of the data streams in on the serial port.

To make life easier, I have added a variable to ap_2_6_header.h in the ArduPilot source called #define REMZIBI_MODE. Change this to the mode you'd like to use:
REMZIBI_NONE - No Remzibi Output messages
REMZIBI_M_COMMANDS - Used with the standard Remzibi firmware, includes GPGGA, GPRMC and $M commands
REMZIBI_ARDU_FIRMWARE_13 - Used with the Ardu1.3 and older firmware for the OSD
REMZIBI_ARDU_FIRMWARE_14 - Used with the Ardu1.4 and newer firmware for the OSD ($A commands)

See this post for more information on the OSD firmware Ardu 1.3 and older (talks about which variables it looks for).

Please NOTE! There is a big block in the center of the screen where the pitch and roll dashes are shown. If you put any objects in this area they will blink because the firmware is either writing a dash or a blank in all of those spaces.

The area in red is where the dashes are shown

BloomingtonFPV · Apr 25, 2010, 02:42 PM

This is a great idea. I was on the fence about doing this until the prospect of this thread came along. Now I'll definitely do it. Here are some questions that might help people know whether this is for them:

Can this be used to implement a 'return-to-home' function, especially in the case of a lost video and/or radio link (and yes, it can happen at the same time: http://www.rcgroups.com/forums/showt...0#post14835797

Can true airspeed be displayed on the OSD from the ardu shield?

Does this reduce the range of the Tx?

Would it work for a tricopter, especially the IMU part and stablization? I'm thinking of a traditional gyro-stabilized tricopter, not a computer controlled one, although maybe ardupilot would take over from the gyros?

Would it allow for the GPS coordinates to be encoded in one channel of the audio stream?

Does the IMU provide a variometer function?

HappyKillmore · 12:26 AM