Blogs

This caught me out big time. And I thought it might be of help to someone else to post my experience even if it was foolish.

The scenario: I have two AP one with V1 shield, Thermopile sensors. Second one with V2 shield with IMU +V2 I only have one GPS EM406 that I swop around (waiting to get UBlox) for second AP.

The problem: I could not get the throttle to work on the First AP every ting else work fine, after rereading the manual rescan the discussions and blogs for similar problems I found some and try all the options only to end with the same problem –no throttle-. Now I started to swab shields around. I want to add that if I remove the shield the throttle works fine.

The result was and a good lesson not to take short cuts when building. When I soldered the pins of AP1 I have also soldered in Pin 13 so instead of de-soldering pin 13 I have just cut the pin flush to the plastic base. Everything was fine till I used Velcro to strap the AP to the base in the airframe it put enough force on the shield to make pin 13!! . I will not repeat the names I called myself.

The lesson Read the manual on the lines and between the lines and do not take any short cuts it will bite you!!

As part of my slow but sure attempt at entering the competition I have created a simple but effective solution to this part of the rules using a Ray casting algorithm and running this on a Netduino in C# (easy to convert to Arduino).

Here is the code to test if the current location falls within a polygon:

public static bool LocationInsideBoundry(Position point, Position[] boundry)

{

bool insideBoundry = false;

try

{

int j = boundry.Length - 1;

for (int i = 0; i < boundry.Length; i++)

{

if (boundry[i].Longitude < point.Longitude && boundry[j].Longitude >= point.Longitude ||

boundry[j].Longitude < point.Longitude && boundry[i].Longitude >= point.Longitude)

{

if (boundry[i].Latitude +

(point.Longitude - boundry[i].Longitude) / (boundry[j].Longitude - boundry[i].Longitude) * (boundry[j].Latitude - boundry[i].Latitude) < point.Latitude)

{

insideBoundry = !insideBoundry;

}

}

j = i;

}

}

catch (Exception)

{

return false;

}

return insideBoundry;

}

Pretty simple stuff and works a treat.

Here is a simple app in .net that shows if the current location is inside the boundary – drag the map around with the right mouse button add some points and if the location is inside the boundary then the group box background will be green – outside then red.

Hopefully it will be of some use.

Cheers
Justin

Pretty cool outfit with an out there idea

• IMAV 2011 "summer edition" rules

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!

Good news: ArduIMU 1.8 has now been released, which is now built on the same libraries as ArduPilotMega and ArduCopter. [Update: this has now been revised with bug fixes as 1.8.1. See this post for more.] That means that it's got all the latest Ardu* enhancements, including support for the most recent GPS modules (including latest MediaTek firmware), our custom FastSerial communications and magnetometer support. If you've been having trouble with GPS modules not getting lock, please upgrade to this latest version.

You can get the new code here. Note that since it now uses libraries, the installation process is different. Please follow the instructions here. Arduino 0019 or higher required.

If you encounter a bug or other problem, please file an issue here. The developers aren't regularily following comments on blog posts, so the past way to get bugs fixed quickly is through the issue tracker.

Special thanks to Doug Weibel for the port and to the whole APM team for the libraries, which are really paying off now that we're extending them to all the Ardu* projects.

I'm working at the new DIY Drones factory in San Diego today, and I thought I'd share some pictures so you can see where the magic happens! Jordi is the guy standing on the right above. Most conversations are in Spanish, but everyone speaks excellent English, too.

There are currently 8 full-time employees, including Jordi (I'm not an employee, just a co-founder). Here's what some of them do:

Loading ArduIMU firmware and testing the boards with a custom jig.

Here's that jig

The pick-and-place machine

The shipping station

Applying solder paste with a stencil and hand-placing some super-delicate components

Hand-finishing boards and GPS modules that have parts that the pick-and-place machine can't handle.

The original toaster oven we used for reflow! Now still used sometimes (it's outside, so we don't have to vent it). The new automated reflow oven, with a proper conveyor belt, is just waiting to be vented inside.

Lots of room for flying at the baseball field out back!