Blogs

Lorenz Meir of the Pixhawk team had a good email discussion with the APM dev team on airspeed math, and was kind enough to write it up in a very helpful primer.

Check out the whole thing here, which walks through the math and measurement techniques.

His tips at the end apply to sensor measurements of all sorts:

• Get as much ADC resolution as possible, in the best case 10-100 times or more than your needed accuracy
• Sample at a much higher frequency and take the average/median (e.g. sample 10 times in a row, take the average/median, return this filtered value). This technique is called oversampling and if the sampling repetitions occur at a much higher frequency than the sampling interval, it should not delay the signal (no phase shift).
• Do a plot over a sensor range to figure out if your sensor is linear, if not, fit a quadratic/cubic function and linearize
• Do a static calibration if necessary
• Compensate for temperature changes if the sensor is sensitive to it
• Do not over-fit or over filter and just correct as much error as you need to make your application work. Too many projects and people get entangled in their own complexity and failures and crashes are the result of too high complexity and too few testing"

I noticed that my Garmin never says my location accuracy is better than 10 feet. I suspect that's a hard stop--no matter how good it is, nothing better than 10 feet will be reported. I decided to check this by plotting the coordinates given from the Garmin device in Google Maps, then Google Earth, and discovered that if any inaccuracy exists, it's within these two programs. In each case, the program showed my location a good 40-50' from where I actually was. On the other hand, plotting those same coordinates within Bing Maps showed the location within 6' of where the Garmin actually was located. The beta version of MapQuest allows you to enter cooridinates, and it was better than Google, but not quite as good as Bing.

I realize that both the Garmin and the map program being used have inaccuracies that will be additive, but I am very surprised at the Google results. I'm curious if anyone here who has plotted their flight paths within Google Earth has seen similar inaccuracies. Your plane could be shown either flying underground or taking off and landing from a virtual airstrip in the sky.

Thanks,
Paul

Work has been progressing slowly, but should speed up in two weeks when I will have more time and be back to my equipment and machining facilities. I have a new version of the board coming that should facilitate better proccessing.

It is quite large right now as it is designed to fit on top of the XC-1A dev kit, but the final board will be able to fit into a footprint as little as 1.5"x1" (small size is a key goal here) with a 6 or even 8 layer board to accomodate the proccesor (144 BGA). I am thinking of adding a backup comm system based on a cellular module, which would also be added to the board (64 BGA).

A test stand for the helicopter is in the works. The stand will allow the helicopter to move freely in all directions with boundary limits to prevent crashing. The movement range will be 0-3 feet in the Z axis, and ~150 degrees in the x and y direction. It will add a little bit of weight, but should not matter much with a .30 size helicopter. Motion should not be constrained as it will use PTFE/oil impregnated bronze bearings. CAD files to come later.

This site is just a few days old, but might be worth checking out if you're looking to work in the UAV industry. Seems like a pretty good start so far.

Powered by a 48 Mhz Atmel AT91SAM7X512 Free tools, all open source code and hardware .NET Micro Framework Event-based programming, multi-threading, line-by-line debugging, and breakpoints.

http://www.netduino.com/

Amazing price I think for only $34.95...mine is coming this Friday...new toys. This will bring a lot of high level programmers into the embedded world, I believe. What would you do with it?

1. High Density routing for swarms of uavs - and manned planes.
   
2. Real-time deconfliction - immediate reaction to changes
3. Infinite scalability - with only local communication.
4. Deconfliction over non-airport hot spots like traffic, crime and accident scenes, borders, ships or oil rigs, ad hoc disaster and military sites.
5. Mixed types and sizes of aircraft with unique separation requirements, power, speed etc...
   
6. Deconflicts airplanes on the ground as well as in the air.
7. Listen and avoid potential (small devices without transmitters).
8. Can be used for ground vehicle, boats, or subs (provided they have localization).
   

The PixHawk team in Switzerland, which has been doing great work with quadcopters and ground stations (we're evaluating their GCS for the APM), is planning to release their IMU and autopilot commercially. Before they do so, they'd like some community feedback on what you'd like to use it for and which features you'd like.

Vote here!

Pictured is the mostly completed ground station, and some of the vehicle-side stuff.

The ground station consists of an Arduino mega, an SFE joystick shield, a Nokia 6100 LCD, and a cheap 4800 baud wireless serial modem, which is hidden behind the LCD. I plan on replacing the serial modem with an Xbee pro soon, but the TX/RX pair was only $10 total, so I figured it'd work for inital debugging and testing.

The plane components here are another arduino, with the wireless RX, elevator and rudder servos, and a 4DS TTL-level camera.

Everything works well, except for the camera. Hooked directly to the mega at 57600 baud and lowest RAW resolution, I averaged about 0.5 fps to the screen. I don't even what to think about what it would be like over a 4800baud connection, let alone an Xbee a hundred feet in the air. My question thus is - what would a good NTSC-output camera be, and what would be a good transmitter and receiver unit for that camera? The Xbee I plan on getting is 2.4ghz, so I would need something that would not interfere with that. Thanks!

Stumbled onto this...

http://www.xsens.com/en/general/mti-g

I hope you like it! ;)

PS.:The location of XBee on the illustrations will be tested soon by Jani. We need to know if it will cause interferences on the magnetometer.

on his Sunday CNN Show, Fareed Zakaria recommended this book and said it was relevant to the modern discussion of Ideas as Property (Patents). I should very much like to hear the perspective of DIY thinkers on the relative merits of Idea ownership, Idea sharing, and how they might reform the current Patent system. Is it still a tool for social mobility - and impetus for the Industrial revolution - as it was for Watts and his Steam engine - or has it been captured by static institutions in a way that precludes growth - especially from new entrants? Has the narrative of a man, a plan, a steam engine - become overwhelmed by patent sweatshops at MS and HP patenting the obvious and mundane, as a means of pulling up the ladder?

Congrats to Bill Premerlani and the rest of the UAVDevBoard team for a great writeup on the Sparkfun front page!

Here's how it starts:

"The UAV Development Platform has been available on SparkFun's website for almost four years now. In that time, much progress has been made. A group of UAV pilots from across the globe have assembled and put their heads together to develop an extremely powerful control platform for RC airplanes and RC helicopters."

...and then it goes on to talk about the acrobatic potential of the platform and to hint of new hardware in the pipeline.

And for an animated view of the above mission (if you have Google Earth installed), click here.

Now that the DIY Drones community is more than 20,000 people, we're getting a lot of requests to participate in our various projects. That's terrific and we absolutely love and depend on the work of volunteers here. It's also a fun and rewarding experience for the dev team members: they get to help determine the path of these projects along with inventing new ones, see their contributions used by thousands of people, work with other awesome talents and get all the free hardware they need, along with prototypes of new products.

But it's often hard to figure out exactly what jobs are right for which people, and how to add people to existing teams without causing disruption and slowing everything down with training and communications (the "Mythical Man Month" problem).

We currently have more than 40 core developers working on ArduPlane, ArduCopter, ArduRover, various ground stations and hardware spin offs, along with several dozen other contributors. That's nearly fully staffed, and requires nearly full time coordination of the various mailing lists, code repositories, wikis, Google Docs planning documents and weekly Skype dev chats. But we do want to have a path by which new contributors can join, in a way that slots them in best both for their own interests and skills and the projects' needs. This ensures that we're constantly refreshing the dev teams with new ideas and energy, and taking the load off core developers as the projects expand and life occasionally intrudes.

The best way to participate is to do something cool on your own and share it here. All of our code bases and hardware design files are open. If you see an opportunity to improve something, just do it, post it and then tell the community about what you've done. If it's good, people will use it, help improve it, and we'll get a sense of what you can do. That makes it much easier for us to figure out what your skills are and where you'd fit in best.

Here's a list of project you can get started on now.

So bottom line: see something you think you can improve? Just do it. If it's cool, your reputation here will grow and you'll be much in demand. It's as simple as that.

[photo at top taken by me of the Arduino team, which operates similarly]