Originally Posted by rshep

Happy - re Step5 and "This step is also going to require a couple 'custom' wiring harnesses.... which is always fun." ... since purchasing the Hansen crimper and a variety of connector parts I have been eager to make new and different "custom cables" that fit my own setup requirements.
Besides it will give me something to do while awaiting delivery of the DIY Drones order ...

Yeah, I've got the same crimper. It took me about 10 minutes to make the 4 cables I needed. Before having the crimper that project would have taken me hours and the results would not have been good....

I'm pretty excited about step 5. I spent about 4 hours today getting the GPGGA and GPRMC outputs working. My testing has been with the uBlox because that's working so well right now. That's good news for users who aren't using the NMEA GPS (Sirf and uBlox). However, it has to go through the ArduPilot to make it work.

The GPS emulator still needs the ArduPilot Binary protocol added (which I already understand so it shouldn't take long). Right now I'm adding the mode and waypoint display messages to the output stream to the OSD. I also need to add a "debug" type message so you can see sensor data as well. I think step 5 is shaping up to be the longest step. I also need to make naother custom harness for the ArduShield on step 5. The pinouts are not the same when adding the shield for the GPS and D8 pins.

I'm also going to spend a bit of time working on the feedback loop for the emulator so you can run missions using the ArduPilot binary and see it move on Google Maps. I might be able to post most of Step #5 tonight or tomorrow.

So let's see, on my To-Do:
1) NMEA GPS optimization
2) Add ArduPilot binary to emulator
3) Add mission feedback for use with emulator
4) Add debug messages for output to OSD
5) Test Step #5 with ArduShield
6) Add Artifical Horizon to OSD config tool
7) Make all of this compatible with ArduMega (when it gets here)

A few questions about the various gps systems:

1) Will the UBLOX gps work with the remzibi OSD?
2) I have an original (orange) and a newer (purple) gps from remzibi. Is there a difference in firmware, and if so can these be upgraded?
3) How well does the remzibi gps work with ardupilot? Is the ubox worth it?

Edit: Note: the part listed below is not the same as the one used on the sparkfun site. It is actually this one:
http://search.digikey.com/scripts/Dk...ame=MPX10DP-ND
but it actually may be more robust than the 8 pin version.

I've found the sources for pressure sensors that might replace this

http://store.diydrones.com/product_p/br-0004-02.htm

at Newark.com. Here are the stock numbers. I'm not sure you save much over the $22 at sparkfun, and it would be good to support them whenever possible, but if you are making several it might make sense (and who has only one plane...)

2 07F9931 MPX5100DP EA 0001 1 0 11.350 11.35
Pressure Sensors IC; Pressure Measure Type: Differential; Operating

10 52K8713 CRCW0603750RFKEA TC 00001 10 0 0.024 0.24
RES THICK FILM 750OHM 100mW 1%; Resistance:750ohm; Resistance
10 46WX064 CC0603KRX7R9BB10 TC 0001 10 0 0.014 0.14
CAP CERAMIC 0.01UF 50V X7R 0603; Dielectric Characteristic:X7R;
10 64K2861 C0603C334Z4VACTU TC 00001 10 0 0.045 0.45
CAP CERAMIC 0.33UF 16V Y5V 0603; Dielectric Characteristic:Y5V; Capacitance:0.33µF;

Originally Posted by BloomingtonFPV

A few questions about the various gps systems:

1) Will the UBLOX gps work with the remzibi OSD?
2) I have an original (orange) and a newer (purple) gps from remzibi. Is there a difference in firmware, and if so can these be upgraded?
3) How well does the remzibi gps work with ardupilot? Is the ubox worth it?

1) No, not directly. Through the ArduPilot, yes it will.
2) The firmware might be different, but more than likely, it's only the factory settings that are different. No, the mfg does not give us the ability to update the firmware or to change the factory settings (not sure why).
3) Right now, as I'm testing, not well. But I'm not sure why. The uBlox requires about 5 messages to get all the data ArduPilot needs. NAV-POSLLH, NAV-STATUS, NAV-SOL and NAV-VELNED. So even if the message is smaller, there are 4 that are required. Only GPGGA and GPRMC are needed from the NMEA GPS and therefore only 2 checksums to calculate instead of 4.

So this is a good opportunity for me to do the math!! The uBlox specs show a message length for just the payload. So for example, if it shows a length of "20" then that's really 2 (Header) + 2 (ID) + 20 (Payload) + 2 (Checksum) = 26

uBlox Message - Length
NAV-POSLLH - 26
NAV-STATUS - 22
NAV-SOL - 58
NAV-VELNED - 42
Total: 148 characters

NMEA Message - Length
GPGGA - 65
GPRMC - 68
Total: 133 characters

So the idea that the uBlox messages being binary are somehow faster is a myth. Every cycle the uBlox has to send 15 more characters than the NMEA does. So what does that mean? As far as I'm concerned, it's the speed with which you can parse the data that's the problem. With uBlox, every piece of data is in a fixed position in the data stream. With NMEA, you have to look for commas.

By my math, at 5Hz sending the GPGGA and GPRMC messages only at 38.400 baud, that's 19.4% of the available bandwidth. So I believe it all boils down to the string parsing ability of the Arduino.

Here's my real concern with the ArduPilot parsing. If I set the NMEA GPS to 4Hz (250 ms delay) then it should be sending 4 messages per second. If I connect to the GPS using Hyperterm then sure enough, every 250ms (exactly) I get a message for GPGGA and GPRMC. So over a 20 second window, the GPS has sent 80 messages.

Below are two screenshots. The first with uBlox (4Hz) and the second NMEA (4Hz). The ArduIMU parses 44 to 79 uBlox messages in a 20 second window. With NMEA it parses between 0 (this is a REAL problem!) and 40 messages in a 20 second window.

More often than not, the NMEA is in the mid to low-20's for a 20 second window. So what's happening to all those other 55 messages?


uBlox connected (4Hz) - 38400


NMEA connected (4Hz) - 38400

You'll notice the cycle time is the same for uBlox and NMEA. About 20ms.

Well, problem solved (in the ArduIMU code anhow)...

Check out the screenshots below. 100% of the messages are coming through now for both the uBlox and NMEA. The probem was the switch (cycleCount) function in the Arduimu tab was only checking the GPS once every 6 cycles. I changed it to check every cycle and now it works great!

So unless there's an accuracy issue with Remzibi's inexpensive NMEA GPS, there's no benefit (speed wise) to uBlox.


uBlox connected (4Hz) - 38400


NMEA connected (5Hz!!!!) - 38400

...

Nicely done! Did you just save everyone who already has a Remzibi OSD about $110? Now if we can make the air pressure sensor ourselves for about $15, then all we have to buy is Ardupilot and the IMU.

In thinking about calibrating the air pressure sensor, I think I'm going to input the raw voltage into ADC3 with standard low-pass filtering and display the raw ADC value with a gain of 1 and an offset of zero. I'll then go out on a fairly calm day and fly lazy circles at various speeds. I can then take off various values that the GPS gives me for speed from the video, along with the pressure value from the same video frame. I'll just fit a line to the scatterplot and that will give me the gain and offset.

This assumes the pressure sensor is linear. We may need quadratic terms...

In the end it may not matter. Ardu probably just needs a minimum value in order to make sure it isn't stalling, and whether the function is linear or quadratic is irrelevant for a minimum.

It might be too soon to tell. The ArduPilot code reads an analog value from the sensor. I assume you can hard code the calibrated values once you figure out what they need to be. It would be nice to eliminate the need for the sheild....

O.K.
Got started yesterday and after some problems "seeing" the FTDI cable (downloaded new drivers) have managed to struggle through to Page 1 and the edits to the code on ap_2_6_header.h and ArduPilot_2_6.
Changed both accordingly saved and tried a verify on my Laptop and a Desktop.

Error Compiling

C:...........................tmp\/ap_2_6_header.h:1: error: stray'\357' in program

C:...........................tmp\/ap_2_6_header.h:1: error: stray'\273' in program

C:...........................tmp\/ap_2_6_header.h:1: error: stray'\277' in program

What am I doing wrong, obviously something fundamental.

Also couldn't work out which is the Arduino.exe executable in the C:\Projects\ArduPilot\arduino-0018 folder.

Sorry to be asking for advice so soon. Hope you can help.

Thanks.

Step 1 is to get Windows to stop hiding extensions for known file types.

In XP, open "My Computer"
Click Tools, Folder OPtions (At the top)
Then click the View Tab
Uncheck "Hide Extensions for known file types." <-This is probably the dumbest setting in the history of Windows.
Click Ok.

Does it say what line numbers have these errors?

Thanks for the "Hide Extensions for known file types" tip, thats working.

Line numbers? Can't find any. The full error message reads:


C:\DOCUME~1\J5OB3~1.DAV\LOCALS~1\TEMP\build5093030 159698342995.tmp\/ap_2_6_header.h:1: error: stray '\XXX' in program


Where XXX = 357, = 273, and = 277.

Hope this helps.
Thanks.
Jon

Well, the problem is in ap_2_6_header.h but I don't know why you'd be having trouble and I didn't with the same source.

http://cboard.cprogramming.com/linux...gram-mean.html

Try the one attached.

Replaced the .h file and tried to compile but got even more errors. I have been playing around with other Arduino sketches, maybe if I remove all traces of this other software and start again from scratch?
Tomorow, my head is hurting for now.
Thanks for your help with this.
Jon.

When you open the program, does it say Arduino 0018 at the very top?