I must be crazy throwing my hat in this ring... but here goes.

http://www.happykillmore.com/Software/HK_GCS/HK.zip

Yet another Ground Control Station project has begun. It's little more than a proof of concept. There is absolutely no documentation or error trapping and is not overly functional... but hey, you've got to start somewhere.

My hopes are to create a language file for this so I can get some friends from around the globe to help me translate this into a bunch of languages.

A few things to warn you about right from the start.

1) It's written in VB.NET so it won't run on Linux or Mac natively...so don't ask. If you're looking for something cross-platform, check one of these GCS programs out:

Andrew Matthews GCS http://www.millswoodeng.com.au/fd_gcs.html - Cross-platform - Written in "Processing."

Jaron http://www.diydrones.com/profiles/blogs/uav-playground-12-an-approach - Cross-platform - Written in Java and "Processing."

PixHawk http://pixhawk.ethz.ch/wiki/software/mavlink/ - Cross-platform - Written in QT

AP GCS - Soon to be cross-platform? - Written in Labview

2) More than likely, this program cannot become the "default" GCS program for AP/APM because of #1 and the general concensus among the APM developers that VB.NET is not the right way to go. For that reason I probably won't make this open source... but it's still "freeware."

My next functions I'm planning on adding are Google Earth integration, Live Camera feed (essentially done but I need to optimize and add some error trapping), KML file support and Recorded file playback.

Unzip the files into a folder and run the HK_GCS.exe file. The emulator is in there as well for testing.

Right now, I'm able to parse NMEA, uBlox, MediaTek, SiRF, ArduIMU binary and text and AP commands.

NOTE: This program requires .NET 3.0 and the "Interop Assemblies" in the links below

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043

http://www.microsoft.com/downloads/en/details.aspx?familyid=3c9a983a-ac14-4125-8ba0-d36d67e0f4ad&displaylang=en

Once I get a little further, I'll have an installer so we won't have to worry about this stuff.

Steps to follow to get this thing to work:

1) Download and install the .NET 3.0 Framework

2) Download and install the interop assemblies

3) Download and install the GPS Emulator (this will give you the DX8VB driver) http://www.happykillmore.com/Software/GPSEmulator/Setup/Setup.exe

4) Download the HK.zip file above and unzip into a folder.

5) Run the GPS emulator. If you haven't already installed the com0com feedback ports, click the "Install Ports" button

6) Click options, setup feedback ports and select 2 unused port numbers (I like 254 and 255).

7) Wait for the ports to get added to your system (will take a minute and you'll have to click next)

8) Select one of your newly created ports in the Emulator but don't click connect yet.

9) Open the HK_GCS.exe and select the Serial Data tab. Click Search COM

10) On the emulator Click Protocols and select something. The 2 checkboxes for ArduIMU Binary are good choices.

11) Click Connect and Start on the main screen of the emulator.

You should see the plane moving on Google Maps and should be able to change pitch, roll, etc on the emulator and have it change things on the Instruments tab of the GCS.

Don't worry, it won't be this many steps in the future. Steps 1-5 will be part of a setup.

I posted an update to the ArduIMU. If someone else is working on this, please feel free to email me happy@happykillmore.com.

http://code.google.com/p/ardu-imu/downloads/detail?name=ArduIMU_1_8_1.zip&can=2&q=

Fixes in this post:

1) NMEA protocol now works (typos in update function and missing PMTK in init function)

2) Magnetometer works (typo in setup where it said MAGNETOMETER == 1 where it should have said USE_MAGNETOMETER == 1, AP_Compass must be changed to APM_Compass, Buffer mapping differs from AP2.7 and older code in AP_Compass.cpp)

3) Added blinking lights function to GPS parsing routine (blinks when there is no lock but valid message from GPS unit)

4) Added #define GPS_CONNECTION 0 // 0 for GPS pins, 1 for programming pins (this allows the user to select where the GPS is connected)

Please note that this isn't considered an "official" release and it may well get deleted... I didn't check with anyone before making these changes and posting this :)

Known issues with this version:

1) When selecting BINARY output, GPS light will not blink (#3 above). Simple fix: Add if (GPS.fix >= 1) to a new line 129 of output.pde

2) Removing/disconnecting GPS will not disable GPS lock light.

I would like to make a plea to the GPS protocol developers of ArduPilot and ArduPilot Mega. Please make the blue light mean something.

Since the beginning of the AP project, the blue light has had exactly two states. On = GPS Lock, Off = No GPS Lock. Any other blinking is purely fictional....aside from telling you the AP hasn't crashed or has no power.

Would you please, please, please, please, please make the light toggle on and off every time the AP gets a valid message without GPS lock? We all know it can take 5 minutes sometimes to get lock and if we're sitting there either looking at nothing or looking at a blinking light assuming it's actually talking... we may be wasting our time for GPS lock that is never coming.

It's very simply code and would go a long way towards helping troubleshooting, development and even debugging the code. The blink rate will indicate the Hz / 2 if you're toggling. It will also show you when you're not calling the GPS update routine fast enough. It will give instant feedback to the user and the developer that the AP understands the language being spoken by the GPS (protocol selection and baud rate selection).

There are so many pros and no cons.

Who do I need to beg for this?

Here, I even wrote ALL of the require source code changes. This goes on about line #410 of arduimu.pde and you'll have to add int toggleMode=0; somewhere above.

Download text file: BlinkyNoFix.txt

I'm posting this for the benefit of those who are Googling "How to associate .PDE files with arduino" or "How to associate .PDE files with processing." Please note, the fix is contained in this post...so keep reading!

I don't know how the developers of the Arduino development environment (also called Processing <- The world's worst name for a development environment...makes Googling for help completely impossible) have managed to screw this up for the last 5 versions of their software, but they have....

When you download a new version (ie 0021) from here: http://arduino.cc/en/Main/Software and unzip everything in a folder... your first thought is (or at least mine is) where's the installer? No setup.exe to run? Nope. This was written by people who are not native Windows users and therefore do not follow Windows conventions.

So you click on the only executable in the root folder "Arduino.exe" It opens up just fine... so you think to yourself, "Ok, that was easy enough. Now it's done the file associations and I can open the .PDE file in my project folder." So you double-click your .PDE file...and it opens your old version of Arduino. WTF!?!

Fine, so I'll right click the .PDE and select "Open With..." and choose the "new" Arduino.exe. So you do that...again, it opens the old version.

So now you're getting pissed. So you might open the registry and go to HKEY_CLASSES_ROOT\.pde and find that it calls HKEY_CLASSES_ROOT\Processing.Document in which you drill all the way down and find that same pesky reference to your OLD Arduino folder...so you edit it to read your new folder\Arduio.exe "%1". But AGAIN, it opens the WRONG version of Arduino!?!?!

So now you're really pissed. So you rename your old .executable to arduino.old. So you double-click on the .PDE file AGAIN and are now prompted to select the program. So you browse to your new arduino folder and select arduino.exe. What is now selected is "Java Platform SE Binary" whatever that means...but who cares, as long as it opens with the right version.... but instead... Explorer.exe CRASHES!?!? Ok, now you're about to track down the developers of Arduino and Java and shove their Linux boxes up their.... ok... calm down....their must be a solution.

Here is the SOLUTION: Rename the executable arduino.exe to processing.exe and double-click on it. Then close the window that opened and you can now double-click on your .PDE files. I have no idea why the developers of Arduino/Processing are referencing a non-existant file in their file association call... but you'll notice that the HKEY_CLASSES_ROOT\Processing.Document\Shell\Open|command\{Default} references processing.exe "%1" which hasn't existed in 0018-0021... PLEASE FIX THIS ARDUINO GUYS!

Any time the plane approached or passed 0 degrees the AP would tell my emulator to turn hard left, then hard right, then hard left and sometimes would get stuck in this cycle (not the sine wave I posted yesterday) but a very tight sine wave only varying about 10 to 40 degrees before snapping back hard the other direction.

Finally, I started looking at the NMEA parsing code in the AP source. It turns out, there are 2 atoi() function calls for ground_speed and ground_course in the GPRMC parsing routine. Simply changing atoi to atof completely solves the problem. I assume it's a rounding issue and since the GPS sends one decimal place after the degrees, this decimal place was getting rounded to an integer and then multiplied by 100. I believe this bug has been there since the very beginning when the NMEA parsing routine was first written. I wouldn't have guessed that one decimal point would make such a difference!

I'm having fun today incorporating my changes to the uBlox, NMEA and EM406 code to better manage the blue blinking light as well as the output for Remzibi's OSD in the AP 2.7.1 code. I re-wrote the trajectory function in my Emulator because there was a bit of an offset in my old code. Here's what I'm finding with the new code

Does anyone know what changes I need to make to the gain settings (or something like that) to cut down on this pattern?

Thanks!!!

I'd like to ask any of the math wizards out there if you can write and post an improved "get_bearing" function for the navigation tab of the ArduPilot source.

The more I test the ArduPilot code with my emulator, the more nervous I get. You'll notice in the screenshot of my 43MPH flight around Paris on my emulator, the ArduPilot decided to take a few loops around waypoints and the larger the distance between the waypoints, the greater the error in bearing.

Here's the existing get_bearing function

long get_bearing(struct Location *loc1, struct Location *loc2)
{
long off_x = loc2->lng - loc1->lng;
long off_y = (loc2->lat - loc1->lat) * scaleLongUp;
long bearing = 9000 + atan2(-off_y, off_x) * 5729.57795;
if (bearing < 0) bearing += 36000;
return bearing;
}