If you have experience making maps from aerial photographs, you know it takes effort. 

When I stumbled upon another UAV-related kickstarter, Mapping with Drones, I backed them without giving it another thought. But it wasn’t because I thought they could make mapping easy. You see, I have a problem. I admit it. I’m an addict. Not just with flying robots, but also with kickstarter.  

     With sixty-eight projects backed, I didn’t even watch the video. A quick glance over the text and photos, plus my own experience with tools like PTGui Pro, PhotoScan, AutoPanoGiga, and DroneMapper told me everything I needed to know, that it’s worth risking pizza money for the promise of easier-to-generate aerial maps. Even if that same experience gave me serious doubts about the “ease” with which less-than-ideal photos could be corrected, stitched, and referenced. The guys at Drones Made Easy seem to understand the issues, and aside from attempting to introduce a niche tool to the wider non-UAV public, they seem to focus well on what they are offering: an easy-to-use cloud-based service to generate corrected, stitched, aerial photography and geo-referenced maps. 

     I’ve backed many other UAV-related kickstarters, some of which I might never use with any frequency, including HEXO+ and AirDog. After all, I have purpose-built UAVs, and I’m not into extreme sports. Leading the list as my most wiz-bang, anticipated kickstarter gadget so far is the Glyph. I suspect I will not actually use the Vaavud wind meter, but I tell myself that it will help in my pre-flight checks. I backed Easy Drone, no relation as far as I can tell, to Drones Made Easy, the San Diego team behind Mapping with Drones. Most of my flights involve aerial photography, and they start by risking my gear for a few hundred photos. Back from the field, the arduous phase begins: post-processing the data into something useful. I have a shelf littered with cool kickstarter projects, electronics, gadgets, post cards, tools. But of the near seventy projects I’ve backed so far,  Mapping with Drones is leading contender for “Most Useful”, “Biggest Timesaver” and “Best Value.” But now I’m getting ahead of myself.

     Post-processing. Ground control points, custom perl-scripts to parse out location information from the logs, shifting the time stamp, deleting blurred photos, and some manual processing when it all goes askew. I’ve used other online aerial map making services, I’ve been lost at the keyboard for hours initiating semi-automated workflows, waiting for my modest CPU/GPU to spit out another disappointing map, before I begin again, using smaller groups of images. I’m used to tedious requirements like uploading supporting flight data and needing to using GPS-enabled cameras, so I was skeptical of just how easy these guys could make this service. Still, for only thirty clams, I figured it was worth giving them a helping hand.

     That is, until their CTO Tudor Thomas sent me a friendly “thank you” message, and asked some questions about my early interest in the kickstarter. He seemed pretty confident that his team could make mapping easy. And that bothered me. So I let him have it.

     By “it”, I mean I turned over 850,000 square feet of photos, 80,000 square meters, 20 acres of images. It's far from the largest photo survey I have, but at about 800MB, it fits nicely on a typical dropbox account. It is, however, a very difficult dataset. AutoPanoGiga couldn’t process it. PTGui botched it over and over. PhotoScan and PTGui each required more than six hours of assigning ground control points, loading in photos in small batches, and re-starting the workflow multiple times. Now, don’t get me wrong, these are great tools, the fault is my own. This dataset is challenging. 

Moreover, I’m not processing it on a fifteen thousand dollar workstation, with fancy graphics chips, twelve multicore processors and massive memory.
My lowly workstation is the same computer I lug to the field, with just 16GB RAM, and a few multicore i7 chips. As for the dataset, some sections have less than 50% overlap. The camera was not stabilized, flown in 30 kt/hr gusts, and the survey was long and narrow. 

The lighting conditions were not ideal for the 1/2000 second shutter speed, so about one in five photos is so blurry as to choke up most stitching software.

It’s exactly the sort of data one expects when nothing goes right, but nothing goes horribly wrong… what most of us would call a good day. Tudor, unaware, accepted my challenge, and fed the 177 randomly-named photos, without GPS data, without flight logs, into his still-alpha version server farm. Fully automated workflow? I didn’t think they had a chance. 

     They nailed it.

     Just few hours later, an e-mail was waiting for me in my inbox, with a URL for my finished map. Operated just like maps.google.com or maps.bing.com with grab-to-move, scroll-to-zoom, and a small set of un-obstructive manual zoom controls, my aerial map, far more detailed than anything I was able to export from PTGui (with only 16GB RAM and ordinary graphics processors) is easy to navigate at any zoom level.

With this same dataset, it took me over six hours of manual processing with other software. Each time, in the offline software, the long narrow runs would go slightly off angle, and botch the automated workflows. Tiles from different parts of the survey area would become adjacent, and reality, as I knew it to be on the ground, was re-written into some strange new spider universe. So it was something of a shock to take in the correct shape, zoomed out, realizing that Tudor and his team had no first-hand experience with the land, no plan for how the photos were taken, no mission data, and no idea from whence these photos originated.

     Color me impressed. 

     For a limited time (about 20 days more) they are offering “points” towards map generation at their lowest rates. In fact, if you read the interview carefully, you’ll discover they are even offering additional discounts for DIYDrones backers. Even before I learned that, I was impressed enough that I wanted to share my delight with the output but I wanted more information to share. The proof I had already seen, but that proof lead me to wonder more about the people behind this time saver, this unexpectedly easy map generating experience. I had the opportunity to discuss, via e-mail, Mapping with Drones with San Diego, CA based Tudor Thomas, the CTO of Drones Made Easy.

Arcaven [my alter ego] -  Can you tell me more about your project and about the team?

Tudor: A lot of it can be found at the following links ­

Drones Made Easy Blog   About Drones Made Easy  510 Labs Team Experience

We have software engineers, web applications engineers, electrical engineers, a mechanical engineer and a sales and marketing guy. Between consulting jobs as 510labs, we started work on what would become Maps Made Easy a few months ago. When the need arose to start collecting our own data, we purchased a DJI Phantom 2 with Zenmuse H3­3D gimbal and GoPro Hero 3+ Silver. It certainly was an adjustment from the $500K­-$5 million systems we were used to working with, but for the results we were getting we felt the trade­off was more than worth it. Not to mention the fact that we didn’t need to deal with procuring aircraft time. We knew this was the future of commercial mapping. One day after this realization we secured a DJI dealership and formed relationships with a number of accessory manufacturers. Drones Made Easy was born.

As we grew nearer to being able to release Maps Made Easy, we knew there would be a lot of costs associated with doing it right. Security audits, expanding our computing cluster, rack space, database optimization help and further development were all going to cost money. Most of us had always wanted to do a Kickstarter so we figured we would give it a try to get the word out and raise some of the needed funds required to proceed in the form of pre­paid mapping. Support has been great so far, but the more support we get the sooner additional features will be added.

Arcaven: Can you share more about the features this service will offer? How will the data be made available for export?

Tudor: Initially, we will only be offering output as hosted map tiles (similar to Google Maps) and providing code snippets and iFrame embed codes to allow users to share their output. Through iFrame use, commercial users will be able to share created maps in forums, blogs and on their own sites without restriction. Clever people will be able to turn these tiled maps into other formats. Soon (in the next 2 months) we will be expanding the output types to include GeoTiff/Tiff, OBJ/MTL, Google KMZ (georeferenced only) and 16­bit DEM. Writing conversion tools is a pain and really time consuming so we are trying to provide one type from each category of output. Users can convert it to other formats from there.

Arcaven: Will there be methods to georeference the data?

Tudor: For sure. We will provide a simple web­based interface for associating points in aerial images with a point on a known basemap (Google Maps or Bing) or a method to manually enter more accurate means of ground control point collection. These GCPs are entered at the time of image upload and produce fully georeferenced output. This process keeps users from having to sync GPS files with their images or even dealing with the GPS output track at all. We don’t require GCPs to be entered at all. The output will be almost identical except for the fact that it won’t be georeferenced and will likely have a random rotation. I suspect non­georeferenced stitch jobs will be more than good enough for most people. We plan on adding a simplified geo­alignment workflow where the user will be able to set the rotation and scale of produced stitch so it can be viewed North Up and be used for making measurements.

It was about this time in my discussion with Tudor that he let me in on a secret. Understand, I’ve spend far more money on offline mapping software than I would care to admit to anyone except my credit card company, and that is without the cost of hours of fighting with the software. The map generated by his fully-automated workflow? He estimates it would cost me less than his lowest paid subscription service, with processing budget left over. Less than $9.99. 

Arcaven: Do you have a message for the average drone operator who is concerned about the privacy of their mapping data?

Tudor: Sharing and ease of access to our processed data is our primary concern. We provide users with controls for including their maps in our public gallery and allowing public sharing by means of embedding. Our map tiles are redundantly stored using industry standard cloud storage solutions. All tiles paths are deeply obfuscated behind 512 bits of UUID combinations that make it all but impossible to access the images without prior knowledge of where the image resides. If a user doesn’t want to share their data, the best way for them to access it is by accessing it while logged into our site. The cloud storage for map tiles is publicly accessible, but like every image accessed by social media, it is heavily obfuscated. If a user is extremely concerned about data privacy, I would propose that they download the output data as soon as possible and delete the map. We can work with extreme sensitivities on a case­-by­-case basis.

Arcaven: Do you foresee loosing potential customers due to concerns that the FAA or other government agencies might come looking for rule­-breakers at your site?

Tudor: Maybe. I must say this: we do not condone breaking the rules. Maps Made Easy will work with images taken from drones and other RC aircraft as well as images captured using full­-sized airplanes or helicopters. It is very hard to tell the difference between the two once the imagery is processed. That being said, we don’t control what data is posted to our site for private use. As long as maps are not included in our gallery or shared publicly, access to the data is nearly impossible. The map creator’s username is not shared in our gallery. Also, if a map is not geo-referenced (I realize it is not a real map without a location and scale), there is no way to tell where the images were taken from unless someone recognizes it.

We really doubt the FAA is going to be granted the authority to regulate airspace all the way down to the ground on private property. This is an air rights issue and they go back to the day flight was first conceived. Private property owners will always be able to operate within a certain distance above ground on their private property for legitimate private use. Mapping activities will all be able to be conducted within whatever this ceiling is eventually defined as.

Arcaven: What sorts of features and map editing tools (orientation, 3D rendering, ..., etc) do you foresee in the service, initially and over time?

Tudor: Some of these were answered above, but it is a good list to have them all in one place.

Arcaven: What message do you have for potential backers, and for DIYDrones members?

Tudor: We would love to help people realize what kind of new applications are presented by being able to control when aerial imagery is taken instead of waiting for a Google Maps flyover update. Legitimate use of drones will be a rapidly growing segment of the economy over the next 10 years and DIYDrones users are already at the forefront of it.

In addition to processing that rivals the best available: ease of access, ease of sharing, control of data accessibility, compatibility with GIS systems and management of data over time are the key aspects to what we are trying to provide.

We are doing everything we can to help legitimize the use of drones. Yes, they are fun to play with but they will open up many opportunities for people as useful business tools. Our stretch goal on the Kickstarter campaign is to create a Mapping Marketplace that will pair drone users who like to create maps with property owners who need mapping services. We need a lot of help to reach that goal...

We would like to offer a special incentive to DIYDrones users that back our Kickstarter. For backers that identify themselves as DIYDrones community members after the campaign ends, we will add an additional 25% to whatever their backer reward point total would be.

What makes your service special, and sets it apart from similar services and software?

Tudor: Accessibility and ease. Aerial data is huge and notoriously hard to share. We have seen people take 10s of TB of images and never process any of it because it was disorganized and too unwieldy. We get a lot of requests to offer our software for offline use, but that goes against our goal which is to make stitched aerial imagery easier to share and manage. This is an internet driven world and we are taking aerial mapping off the client machine and putting it in the cloud.

Full Disclosure: I backed the project. That, and this article, is my only association with these guys. No kickbacks. Except they did stitch a map that I'd already spent more than 20 hours stitching with other software. My purpose in sharing is because I was really impressed with their demonstrated ability to save me time in the future.  Back them, and I think they will impress you, too. I may have a problem with my addiction to Kickstarter, but I'm not regretting my decision to back this project.

This isn't a build log. And what's shown here wasn't built as a rover. It is a rover, sure, but it was built as a playground, a collection of dozens of separate experiments, trials, and ideas. I build this a few months ago, and I'm about to tear it apart and rebuild it based on the lessons I learned, but before I do that, I figured I'd share a bit. 

This was a relatively low cost build, for me, but it would not be inexpensive to reconstruct. I had many of these parts already, so I'll provide some details, but it isn't really a good idea to repeat this exactly. Even I would not build it like this a second time. 

The chassis is a Ruckus Monster Truck. I've been very happy with it. If you know about RC trucks, no doubt, you'll have lots to criticize with this bottom-end 1/10 scale vehicle, but it works just fine for autonomous roving on semi-broken ground and natural grass lands. If you have a lot of obsticles over 3.5-4" and you might need to upgrade to a crawler or something in 4WD.

I'm using an APM 2.5, a 3DR 5.8 FPV kit, with OSD, a Futaba R6208SB rx, a 3DR telemetry kit, a GoPro camera, and a previous generation 3DR LEA6 v1.1 GPS. Besides the 3D printed parts, I use a few #6 screws from Home Depot of various lengths, a 6-to-individual-6 pin'ed cable for the rx (because it was handy, I normally make custom cables from a kit of parts I got over at Hansen's Hobbies,) one 3 pin servo cable for power and channel 8 to the rx, and a few zip ties. 

I removed the shell and some of the plates provided to hold bits in place. One nice feature I made use of here is the twist wing connectors. They are supposed to hold a plate in place for the battery, but the velco strap holes are sufficient for that so I repurposed these twisting winged items as the way to hold the 3D printed body to the chassis. 

While you can see screws, these screws are not fixed. They are glued onto the orange 3D body, but they act strictly for alignment for the chassis, as pins. Why use screws? They are cheap and easy to source. A smooth pin would be nicer, but I had screws. 

I left a large space above the battery, allowing the battery to be inserted and removed easily without taking anything apart. The body and chassis fit together like a glove, stay rock solid while driving around, and come apart in seconds, but disconnecting the two servo cables is a bit of a pain. In the future, I might add a socket that causes the servo cables to connect/disconnect just by attacking the body. I suspect the guide pins would pay off even more then.

The 3D work was created in Google Sketchup, sliced on KISSlicer, and printed using Printrun (for Mac) on a PolyPrinter in ABS. PolyPrinter is a large build area (9x9x9") rock solid industrial-grade FMD printer creative iteratively by fellow Makers in the Dallas area based on their frustrations with less-reliable and more well-known printers. 

In the center of the lower plate, I experimented with integrating Tastywheat's Onmimac 3DR APM Anti-Vibration mount. It works just fine, and while it makes a nice looking stand-alone mount, I would not integrate it like this again. It is far easier to re-create the essential bits and not have to fix all the curves and intersections. You'll notice various arches and buttresses underneath. All of these printed perfectly, without any support, on my PolyPrinter, and they really add rigidity to the structure. While not shown, I did also add thicker triangular bands on the underside of the large surfaces, to add rigidity and reduce weight. This structure was printed in one go, with no issues, and it fits like a glove. The heated bed and fully enclosed space of the PolyPrinter, no doubt, are critical to printing large ABS components like this without lifting or warping. 

The protrusion on the front/left of the sketchup screenshot is the bottom of a GoPro mount. There were several experiments around the GoPro in this build. In the upper place, I included a springy tab that retains the GoPro when inserted. 

No tools, no screws, just slide it in from the side.

When it is fully inserted, the GoPro locks into place, but you can still operate all the controls, access all the ports, buttons, and see the all of the indicators. 

It comes out easily, by pushing up on the tab and pulling it out sideways, but will not come loose while driving around, even under hard driving. The back is also open, allowing for GoPro accessories. 

While this arrangement works well, I would not do it like this again, at least not on a rover. The lens gets far too dusty here in Texas, even with light duty. Because the rover is ground-based, weight is not as critical, so for future ground-based builds I will design around the supplied GoPro protective cases. For aerial systems I now use a variation of this arragement, with extra tolerances for a tiny bit of foam on the contact edges. This helps with vibration and gives a tighter fit overall. 

Another minor, but nice, feature of this build, and easier to do in 3D printing than in transitional plate/cut fabrication can be seen for otherwise "hidden" components like the telemetry module. Measuring out where the TX/RX leds would be situated under the top plate, I sunk the plate down over that area so that it is just ~.25mm thick. 

This creates an high quality effect similar to the hidden indicators found on Apple laptops. While I print in bright orange while prototyping and for my aerial components, I expect this effect would look even sharper when printed on black or some other dark color. Here is a shot of the top plate just as the 3DR telemetry radio LEDs light up. When it isn't lit, you just see orange, but it is so thin that when the LEDs light up, they stand out in the original LED colors. 

In future prints, I plan to fit the video and telemetry radios better, such that they do not twist at all when installed, but otherwise I'm very happy with how they work. 

I don't use the power module in this build. The rover chassis is powered on 7.2v 6 cell NiMH battery. To use the power module, I'd probably swap out to one of my in-inventory 3S lipos, but that would lead me to replacing the existing ESC and motor while I'm at it, so I've left it alone for now. 

There are a dozen or so other ideas expressed in this build, but I've hit the limit on embedded/uploaded images in a blog post, so I'll call this the end for now. My dialog is boring enough with the images, I will not subject anyone to my text sans photos. Happy hacking.

I asked my girlfriend what she wants for the holidays. She smiled, saying she wants something sexy, colorful, that comes in a small box, something the perfect size and shape. Naturally, I fired up a 3D editor, warmed up my awesome PolyPrinter and made a …  3DR Pixhawk mass model!

My girl is very smart, and when she figured out what I was up to, she was curious about why I'd make a mass model for her. I admitted that, of course, I have a few Pixhawk autopilots on order, but the printed mass model was something we…. errr… she could use right now. I guess she could see how excited I am about the Pixhawk because she told me I could keep it!

Which is really fortunate, since I suspect that I have the greater need for a mass model of the Pixhawk. I've got a new plane, not yet trimmed,  Given that the new autopilot release is expected very soon, I figured I would go ahead and layout the plane with the Pixhawk in mind. After all, I don't want to risk the real gear on my dodgy piloting skills in an unbalanced plane. I also don't want to complicate PID tuning with balancing and trimming at the same time. Besides using the mass model as an aide to help balance my new plane, I am already using it to help outfit and test other vehicles, including a boat, some of my new multicopter designs (strictly physical layout and balance right now) and for a rover project.

My girlfriend asked how things might unfold if I had correctly figured out what she wanted for the holidays. I reassured her by admitting that if she had really wanted the Pixhawk mass model, I probably would have simply printed another one for me. If you don't already have a 3D printer (and even if you already do) I recommend checking with the guys over at PolyPrinter. They are fellow makers, and regulars with the Dallas Makerspace, where a PolyPrinter has been precisely and quickly laying down plastic (and evolving) almost non-stop for at least long as I've been a member. 

A few minor disclosures:

- This model is based on publicly available specs and art. I don't have a Pixhawk yet, and that is another reason I made the model. When I get my hands on the actual gear, I'll update the mass model because it is still very useful for designing and testing, even when I have the real thing. 

- I'm not affiliated with 3DR, other than as a customer. So this model is not "official." I just like to share.

- I'm not affiliated with PolyPrinter, other than as a customer. I have experience with other 3D printers, and this is simply the happiest-making printer I've ever used. No DIYer or self-respecting prototyped should be without a good 3D printer, and the PolyPrinter is a great printer. 

In the spirit of sharing, I'm posting the Sketchup and STL files for this (draft) Pixhawk mass model. I recommend slicing with wall thickness of 2.5mm, 33.3% infill, circular. This produces a model that is around 40.5g. I printed at the lowest quality, but I think it still came out looking very nice. Please ignore the rough spots in the photo, even at the lowest quality, those are actually from me messing about with a dremel tool, and are not from the printer.

Once the model was printed, I shaved a bit of the plastic off to bring it down to about 39 grams. The spec reports 38 grams, but I'm going to leave it a bit heavy until I can measure it myself, with SD card and extra connectors. The servo, USB, reset, and SD slots are great places to drill out excess plastic to get the weight exactly right. I added a bit of color by hot flowing some crayon to meet the girlfriend's original requirements, and I think it really helps to bring detail for this photo.

I have the best girlfriend. And soon, I'll be swapping out my PX4s for 3DR Pixhawks, and more safely thanks to this model. Here's wishing you get a Pixhawk or two in your stockings this season!

STL Model: PixHawk-MM.stl

Google Sketchup: PixHawk-MM.skp

Slashdot is carrying a story about new research published by the good folks at Carnegie Mellon and Coherent Navigation detailing a series of classes of GPS attacks beyond those previously demonstrated. 

Of particular note to this community, the research details vulnerabilities found in the uBlox 6H GPS receiver. 

The researchers go beyond the typical jamming and spoofing techniques, and also examine weaknesses in GPS messaging and in attacks against the embedded operating systems and applications which communicate with the GPS modules. 

The uBlox 6H does not fair as badly as some of the other modules, and besides spoofing, the only other identified issues is described as "Vulnerable Week #"

"Vulnerable Week Number Date calculations in GPS receivers are done using the Z-count, which consists of a 10 bit Week Number (WN) and 9 bit Time of Week field.

Nothing is ever perfect. Or even as right as we might like. But I've been holding out on you, my friends, focused as I was until lately on moderating, I haven't been taking the final steps to share my code, photos and images of my aircraft, and other files I've been working on, such as this X-Plane model of an ArduPlane based on the Bixler. 

Well, I hung up that moderator hat to focus on contributing in other ways. I wish I could say that gave me the free time to polish this model to the point that it is where I'd like it to be for a general release, but the truth is that I simply added more projects to my plate. I'm not going to let it slide anymore, so this is getting released as it is, and as condemnation and criticism shames me sufficiently, I'll fix it up and release more often. 

The model originally came with a 1.5MB, 20 page "developers" guide that spelled out in painful detail the scaling and specific characteristics of the plane. I haven't updated it, it is even more boring than this post, and it isn't required to get flying, so please allow me to bring your attention to the most important aspects of using this model first. Then I'll add some details for those of you who are interested afterwards (and if you really like to slog through overlong explanations, ask me and I'll send you the documentation, in all its outdated gorry...err ... glory.)

Installing

Simply unzip the model files in your "X-Plane/Aircraft" directory. Make sure you are using X-Plane 9.70 or higher. 

Before You Fly

Assuming you plan to fly Hardware-in-the-Loop, follow the instructions in the manual, but use the following adjustments.

1. Increase the number of flight models per frame. In X-plane, find the menu item for "Operations & Warnings", and increase the flight model per frame to at least 3. 
2. In APM Planner, Simulation, change the throttle gain to "5000."
3. In APM Planner, load the attached Parameter file, then recalibrate your radio and setup your modes according to your preferences.

That is all you really need, but here are some more details for those of you who are interested.

Runways, Grass, and Landing Gear

As you can tell from the video, in keeping with the physical model, there is no landing gear on the plane. A Bixler is typically hand launched, but X-Plane does not include a virtual hand to throw the plane. In reality, there are hidden, invisible skids on this model, to allow the plane to "sit" on the ground properly. Just give the plane full throttle and get it off the ground before it heads for the rough grass, and it should lift off fine. If you get off course, go off the runway, or get turned too severely, it will get "stuck" (as it would in real life.) I've reduced the friction of the "skids" just enough that it will take off from the belly, which is more than it will usually do in real life, but I did not think you'd mind if, on this point, I departed from reality. Most of the time I perform full automatic missions, from take off to landing. If the wind is too strong, or if the mission script is not right, the plane will sometimes go astray and get stuck in the grass. As with after a landing, you simply re-open the plane (or re-open the airport) and you are set for another run. 

A Brief Note on Scale

The X-Plane simulator does a fantastic job approximating flight in fantastic detail, and this model was prepared to leverage quite a few features, including drag of the onboard gear, Reynolds numbers, realistic weight, center of gravity, motor and propeller performance, and at one time (now disabled) I even added battery life into the model. However, with models under 5 lbs / 2.2 Kg, the simulator tends to crash. Well, sometimes the plane crashes and sometimes the entire simulator crashes. There are two things done here to address this issue, and it has been very reliable for myself and for everyone who has so far reported back to me. The first is to increase the flight modes per frame (see above) and the second is to scale the airplane such that it is at least 5 lbs. I have adjusted every aspect of the plane to balance a realistic simulation with this scaling requirement. Thus the plane is scaled at 1.7x (size) and about 3x in terms of weight to maintain the correct relationship between wing area and weight in scaling. Proportional changes to Reynolds, motor power, propeller dimensions were all adjusted in concert in an attempt to be as authentic as possible. If you want the specific numbers you can mine the model or ask me and I'll send you more details. 

Trimmed, Level Flight

I hope the pilots here will forgive me, this is a note for folks with less hands on experience. Planes are designed and trimmed for specific flight speeds. Many planes flown with more throttle will tend to pitch up and climb, and if the forward airspeed is below the designed speed, they will tend to pitch down slightly and lose altitude. Pilots correct this by trimming the plane, and the APM could do this with the P_to_T parameter (which I have not explored, and which I have also not set in my real life Bixler parameter files... nor have I seen any real life parameter files yet that have this set.) 

So it is helpful to know that I designed this plane to fly level at about .480 throttle. If you find it pitches up or down and does not fly exactly level in the simulator, take a peek at your throttle setting. I normally display the throttle data on the screen during flight, and you can do this easily as well. Look at items #25 and #26 in your X-Plane Data Input & Output. The circled items below are essential for HiL, but the items I did not circle are recommended for onscreen feedback.

A Big Thank You

I want to say thank you to a few people who either directly contributed or cannot be left out of any list of thanks related to ArduPlane (and, sadly, I will leave people out, my apologies.) A big thank you to:

Chris Anderson, Doug Weibel, Jose Julio, Jordi Munoz, Jason Short, Andrew Tridgell, Michael Oborne, Paul Mather, Bill Premerlani, and everyone else who shaped ArduPlane and, without whom, this work would neither be possible nor of any value. And a special thanks to Knut Lagies, Didier, Robert Elgin, Yury, David Buzz, Thomas Berndt, Justin Beech, Colin Bouriquet, Michael Brown, George Dimitoglou, Kevin Finisterre, David Jones, Mike, Carlos Moreira, Linux Penzlien, Pavel Skotak, Eric aka Eagle, Dusan Trenic, and Stephen Wong for flying a previous version of this model and providing feedback. 

A Note on Reproducibility and PID Tuning

These PIDs work well for me. However, since each HiL computing environment is different, variations in the resources of the OS, running processes, and especially background tasks such as an Antivirus scan can dramatically affect the latency of control and sensor data to/from the APM. If these PIDs do not work for you, check that you don't have resource hogs tying up your memory or CPU, and please do share your PIDs as you get them dialed in better for your environment. 

Here is a previous video (very cheezy; I was having fun with an iMovie template) announcing the plane, provided for your amusement. 

What about X-Plane 10? Flexible Wings?

Yes, I have produced a variety of different models, including an X-Plane 10 model leveraging the nifty bendy wing features (and in real life, the Bixler's wings flex like crazy.) However, as X-Plane 10 was brand-spanking new at the time, there were issues in using it for HiL that, combined with the additional cost and lack of backward compatibility, caused me to give up this sexy feature and restrict myself to an X-Plane 9 model. You can open and fly this in X-Plane 10, and you can also open and upgrade it to a native X-Plane 10 model using Plane-Maker yourself. If there is enough demand, I'll explore flexible wings and X-Plane 10 again. I have also made 3 channel planes and other variations. If you are really that excited about a variation, please let me know. 

And Now, the Files (attached)

DIYDrones-HiLStar17F-0.3.2.zip

HiLStar-June2012.param

Think you have challenges getting that sonar, airspeed sensor, or magnetometer to produce clean data in the harsh environment on your Skywalker, with ESCs, RF fields, 65mph winds, and multi-G impacts? Well, the guys over at NanoSatisfi are looking for a new level of pain, and have a kickstarter to put the ArduSat into a polar orbit.

Rather than simply launch their payload into space with a load of sensors and some experiments, they are embracing the larger spirit of an open project, and are sandwiching in several arduino-based boards, with the intent to run your experiments. Various options to beam your message down to Earth, take photos or otherwise run your program have been outlined. They have a host of different sensors for your program to I/O block, filter, calculate the median value, and compare to a fluctuating reference voltage.

Normally, I like to provide some details for a blog entry, but for this one, I'm going to let their project speak on its own.

Dvice has a nice story and overview, and the kickstarter page covers the details, and provides ways you can support the project. Here is a sample:

"ArduSat is a miniature cubic satellite, measuring 10 cm along each edge and weighing about 1 kg. Onboard it will have a suite of 25+ sensors, including three cameras, a Geiger counter, spectrometer, magnetometer and more (check out the FAQ below for a full list). The sensors are connected to a bank of user-programmable Arduino processors, which run your application or experiment, gathering data from the space environment."

Here is the video pitch, for your viewing pleasure. 

Personally, if I were these guys, I'd want someone to talk me into joining the DIYDrone's very own Team Prometheus and BLUAS groups.  They can use these teams' methods to trial and test the gear in high altitude balloon launches before I fired this gear into orbit, and avoid some of the potential for public embarrassment and project failure when learning that the GPS was an MT 3329 rather than MT 3339, that the resistors became superconductors at near zero kelvin, the RF field from the telemetry link was generating spurious signals on all the analog sensors, the alternating heat/cold caused the inter-board connectors to swell and contract like an accordion, and the moisture inside the Pan/tilt servos locked up the gears... 

It's space. Where even AVRdude will not help you debug. Err ... scream. I'm thinking there is a good chance that the guys behind this project are already members here. If so, maybe we can give them some constructive questions and ideas. And our support. But if you have to get your Arduino-rant out, go ahead (you know who you are, you lovable rogues.) Just be brief, we've all heard it before, and this project could generate discussions that are actually interesting, possibly even helpful in solving our own sensor, electrical, and environmental challenges. 

Our friends at MaxBotix have updated their offering of ultrasound sonar sensors by adding the new High Resolution LV line. The defining characteristic of this new line of sonars is the 1mm resolution. Yes. 1mm. Well, more correctly, "the HRLV-MaxSonar-EZ Sensors offer calibrated 1 mm accuracy of 0.1% at 1 meter," so at greater distances, the ranging might be off by a millimeter or more. Up to 5 millimeters at 5 meters, if the accuracy were linear. I can live with that. *grin*

The new sensors offer a similar near end range, a minimum of 30cm, and the data sheet describes a 5 meter maximum range. This is slightly shorter than the 6.4 meter maximum range of the LV line or the 7-10 meter range of the XL, but my thinking is beyond 15 feet off the deck, you might not notice if your multicopter switches to using the barometer for alt_hold. Like the other product lines, the specifics of range are most likely subject to the beam pattern. As with the LV line, it is available in a variety of beam patterns off the shelf, and they offer custom solutions for customers who require it. 

This new sensor line offers the same interface as existing sonar products, including analog, serial/TTL, and pulse width, comes in the same form-factor we to which are accustom, but the manufacturer provides details on additional distinguishing characteristics of this new line over the LV line, including:

• Higher resolution output
• Automatic calibration of, noise, humidity, and voltage for consistent, long term, operation.
• Automatical compensate for speed of sound changes due to the effects temperature changes
• Advanced firmware to handle a variety of noise sources
• Simultaneous multiple sensor operation
• Noise filtering is even better than previous MaxSonar products
• Automatic target size compensation

With this level of resolution, I expect there are new technical challenges related to air temperature changes in near-real time, and this suspicion is somewhat supported by two features of this sensor. First, there is it's onboard support for compensation of "self heating" through an onboard temperature sensor. Second, there is support for an external temperature sensor, also available from MaxBotix, which when combined with the onboard temperature sensor, can eliminate a potential "drift of ... up to 3%."

The product page also reports that the HRLV are designed to support simultaneous sensor operation, but it is not clear from the initial information if this is handled through time triggered operation, as with the other sonar lines, or if this sensor discriminates between its pulse and those of other nearby sonar units in some new fashion.

Here are the beam patterns available off the shelf. 

There are a range of other features worth discussing, but let me not distract you from the important questions. Or rather, the important question. With this type of high resolution, I would expect this sonar to come at matching high price. Like the LV and XL lines, different sensors are priced differently, but t The lineup is advertised at MSRP $28.95 - $34.95 for a single sensor, with volume discounts available.

I should mention right now that I have no ties to MaxBotix, except as a fellow customer. I don't get any discounts by bringing this news to you, and at these prices, I don't really need any (but I'd gladly go in on volume purchases if anyone wants to organize some, hint-hint 3DR team.) I was notified by email about the new line in a product announcement email. And that is important to this audience because it also informed me of another useful bit of information. These sonars are begin offered at a 25% discount until 7/15/2012 if you use the discount code en4v en4V [the code is case sensitive.]

A quote included with the product announcement (not attributed):

“1-mm resolution is so stable, that when measuring typical objects at a distance of one meter, the readings do not change by more than 1-mm.”

See the linked data sheet or the product Web page for more information.

DIYDrones member and SUAS News author Gary Mortimer wrote an interesting article about the first flight tests of the Boeing Hydrogen-Powered Phantom Eye UAV. The story has also been syndicated at Slashdot.

The platform will no doubt generate interest outside of military applications because a hydrogen energy storage presumably offers a higher energy storage potential than current battery technologies. I look forward to learning more about why hydrogen energy storage was selected. For those of you who follow discussions about alternative sources and storage methods for transportation, Dr. Richard Muller has a number of excellent, publicly available lectures on the realities of energy density, the (simplified) numbers behind gas, cookie powered propulsion, battery energy density and losses, and why hydrogen isn't necessarily an environmentally friendly alternative to gasoline in his outstanding Physics for Future Presidents lectures. 

While Boeing is principally targeting military applications for this platform, NASA, NOAA, and dozens of other scientific teams will no doubt have similar application requirements. If this makes sense for Boeing's perceived military applications (and I'd personally like to learn more about what design targets were met with this alternative approach) it almost certainly makes sense for atmospheric, weather, disaster assistance, search and rescue, and similar applications. 

Photo Credit: Kevin Peterson/UC Berkeley

Science Magazine published an article suggesting that a project motivated by the recent DARPA push for small, quiet UAVs may be providing support for theories about the origin of flight in animals. 

Besides being an interesting evolutionary and biological theory, it also raises two questions here.

1) Could mini-ArduRover or ArduBoat projects benefit from wings?

2) ArduBird, anyone?

IEEE has published an interesting overview about Google's self-driving cars.

The advances in this field should be of interest to our ArduRover community. The article mentions that Nevada has updated its laws and has become the first US state to allow for these vehicles to legally share the road. No details about the process to "license" the "driver" is mentioned, but I'm certain that interested parties could find out more. 

The article talks about some of the challenges unique to this area of robotics. Specific behavior was coded into their 'autopilot' to communicate intent through action. The example of drivers at a four-way stop is used, where other drivers are not strictly following the rules of the road, and no driver moves, the car will first "announce" its intent to cross the intersection by moving more visibly, just like a human driver in the same situation. This is a domain-specific layer of complexity beyond that required for general robotics, related as it is to interaction with unpredictable agents sharing the robot's space.... such as humans, animals, and moving but "inanimate" objects.

This highlight a possible problem area in the design of our APM projects based primarily on DCM and PID controls. Our APMs have little "understanding" or modeling of the world, but for two-dimensionally-locked robots (well, we usually *hope* our ground and surface vehicles remain locked on the two-dimension plane... it usually means bad things when they leave it...) many which are successful have at least a basic method of modeling the world, its obstacles, and the physics involved. Beyond this, and outside of controlled environments, the robots also need to predict future conditions and the effect of its actions, and refold that information into the ongoing sense and avoid process, comparing and adjusting the whole time.

So where do we go from here, with that knowledge? And is there, perhaps, merit, to adding a "physics sensor", perhaps using a modern graphics chip created for the gaming industry? These are challenges which, perhaps, may take the "ArduSurface" projects in vastly different directions, but I suspect much of that work would subsequently be valuable to their flying counterparts. 

BBC has a nice little video news story about the new computer-controlled passenger transport pods at Heathrow. It includes some nice shots of the video monitoring, computer map, and of the pods in use, and also includes a brief history of this form of transport, and a sound bite by a hopeful business owner about deploying this in smaller cities. 

You can view the full video news story at http://news.bbc.co.uk/2/hi/programmes/click_online/9613795.stm

In what we can only hope are unrelated news stories, Wired Magazine is reporting a virus infestation of Reaper and Predator ground control systems, and sUAS News is reporting the crash of a Reaper UAV in a training accident on friday.

What This is Not About

As an information security professional, dealing with Malware is a topic I can speak about with some authority. Well-meaning techies will, no doubt, raise all the same talking points, "why are we running critical ground control systems on Windows?" "How did this virus get onto classified systems?" "If they were running OSX/Linux/OpenBSD, they would not have this problem!"

Let's address these general statements once so that we can talk about what is important here for commercial and hobbyist UAV operators. Yes, malware creators tend to target Windows more than other platforms, for a number of reasons, and yes, not running Windows for critical (if not all) computer tasks is a common strategy used by many information security professionals and amateurs alike to limit the impact of malware on their daily lives. However, malware is a fact of life in computing systems, and the stuff you know about, or detect on your computer with antivirus software, is childsplay compared the current generation of commercial and military grade goods.

Some Useless Talk

Typical malware discussions deal with personal identifying information theft, credential harvesting, and stealthed online banking wire transfer. They involve that other form of high-tech "drone", the millions of zombie PCs, controlled with a different form of CnC server than we use to cut our quadcopter plates. These are used to knock Websites and networks off line as part of political statements or as part of a poorly-reported, fifteen year history of extortion schemes committed by individuals and highly organized criminal enterprises alike.

I do not want to talk about any of that today. Keeping your financial data and health records private is not of any direct interest to the UAV community. Furthermore, this community is organized around a principle of sharing, with open source code and hardware, so there isn't really any value in deploying malware to "steal" our UAV technologies. Some of you develop and sell commercial products, but you can look out for your business interests like everyone else, by hiring someone like me to take care of it. 

What I would like to reflect upon here is the one area of the traditional security "CIA" model - that is "Confidentiality, Integrity, and Availability" - that most concerns the hobbyist UAV builder/operator, availability. 

Is this Cyber Stuff Really a Problem?

There is no information to suggest that the viruses and key loggers mentioned by Wired Magazine caused a crash of the UAVs in question. The crash on Friday of a Reaper in a training accident did not need to be helped by malware. UAVs crash just fine on their own, or with operator assistance. However, there is ample reason to be concerned. Consider the Telegraph report of the grounding of French Fighter Jets, the ultra-high tech Navy vessel crippled during early sea trials by a virus in the early part of the last decade, and, far more tragic, the 2008 crash of Spanair flight 5022, in which malware played a significant role, that killed 154 people. Make no mistake, this is not a Hollywood script, it is increasingly a very really, very serious business. Even if certain companies (I'm looking at you, Adobe) do not get it.

With thousands of dollars and thousands of hours invested in our UAVs, even if they are not putting lives on the line, we each have a vested interest in keeping our ground control systems fully functional.

No Malicious Intent 

In fact, malware need not even be involved. A month ago, I was using Mission Planner to assist with a backyard flight test when, without warning, Windows "discovered" a new device, and installed a mouse driver ... in place of my FTDI driver. Two hours and twelve attempts to reload the FTDI driver failed before I pulled out my secret weapon, a move I should have used from the start. But I am getting ahead of myself.

The Every Man

So what can an operator do? If patching, removing Adobe products from our computers, using an alternative browser, and running current antivirus is not enough (and it is not, but it is a good start) and if we use Windows because the excellent Mission Planner was written for Windows, how can anyone expect to be certain of a clean, functional ground control system without a professional hacker helping out? 

A Simple Answer

Virtualize. Using technologies like VMWare, Paralleles, and Virtual PC, you can keep a minimal operating system of your choice, Linux, Mac OSX, even Windows, to control the hardware on your laptop. If possible, avoid using it to surf the Web, manage your finances, or watch online videos in flash about Chinese UAV competitions. Maybe you prefer a Mac, but cannot live without Michael Obornes wonderful Mission Planner. Install Parallels and run Windows in a window. Load all the software you need, patch up, fight with the FTDI drives once, and then make a "snapshot". If your virtualized ground control system experiences a failure for any reason, a virus, spyware, or a driver conflict, you can "roll back" in 20-30 seconds to a known-good configuration. 

Here is a tip for advanced users: remap your Mission Planner "logs" directory to a shared directory with your host operating system; keep a copy of the latest MP, FTDI drivers, and perhaps your Arduino code directory in another shared directory.

From time to time, burn a DVD of the latest snapshot of your virtual ground station and keep it with your Parallels (VMware, Virtual PC, etc) install software. When you decide to upgrade your PC hardware, when your five year old son uses his milk to "wash" your keyboard, when that Adobe PDF file demonstrates the classic Odysseus stratagem, when your OS decides FTDI means "Forget This Driver Immediately," or when your beautiful Macbook Air fails to live up to its name after it is propelled off your table at 4 meters a second by a 170lb human dodging the angry blades of an unintentionally attacking quadcopter .. well, you'll be glad you did. 

Even if your computer is completely destroyed while you are visiting your uncle's family in North Dakota, 300 miles from the nearest Best Buy and 2 hours drive from the nearest Internet connection, you can keep on flying ... just borrow cousin Jimmy's MacBook, install Parallels (if he isn't already using it) and you'll be flying again in about ten minutes.

With the Quad 3DR frame availability increasing, I wanted to take a moment to offer a "Build Quick Tip". Skip to the bottom of this post to get to the "quick" part of this tip.

The Backstory

The ArduCopter2 frame uses narrow aluminum arms, and so the design calls for motor mounts. The 3DR frame uses 20mm, 3/4" square tube arms, much larger than those on the other frame, and so it offers a different mounting method. Included in the 3DR frame kit, for each arm, are metal screws and a bag of washers/spacers. The 3DR uses a direct mount method. Each arm has two holes spaced about 1.5 cm apart along the center line of the tube. Screws are placed up through the arm holes and connect directly to the bottom of the motors. Only two of the four motor mounting holes are used, but it is plenty solid, and the X-shaped motor mounting brackets included with most brushless motors are not used at all.

The 3DR frame assembly instructions discusses motor mounting, and I encourage you to read all of the instructions carefully, twice before picking up a single tool. Once you are done reading those instructions, I recommend you take the small bag of spacers and ... put them aside. Do not even open them. 

"But if I do not use the spacers, don't I run the chance of damaging my motors?" you might ask. The truth is, no. You will not run the chance of damaging your motors, you are virtually guaranteed to damage your motors. The screws are simply too long, "engineering variances" aside, for virtually any motor you are likely to be using. The point of my recommendation, however, is that even with the included spacers, you are still running the risk of damaging your motors. So perhaps I should explain myself?

The 3DR frame is my first "kit" built frame. It is my fourth quad, but the first frame I purchased. When yours arrives, it may well have three or four times the spacers/washers that were included in mine. I purchased one of the earliest 3DR frames available from the DIYDrones store, and it included about 20 spacer/washers. I used all the washers and supplemented some small nuts besides, and I still wasn't sure I was getting the spacing right. Ever eager, I "got by" with fewer of the spacers on one of the arms. And you can see the motor from that arm in the picture above. It is a disaster waiting to happen. It functions around 45% throttle, just enough to get the quad off the ground. Then it stops. I discovered this during routine testing, fortunately, and not during a flight test. I am confident that jDrones shipped me a good motor, so what went wrong? The screw was just long enough that, under load, there was some shorting (think, spark gap transmitter!) inside the motor that damaged part of the stator wiring. The motor will spin up and then will short and fail. Backing the screw out will not help, the motor damage is done. Fortunately for me, my last order from jDrones was a batch of sixteen. What can I say, I am an addict. 

The "Quick" Tip

The washers/spacers will be useful, so keep them. For use elsewhere. The problem is that there are just not enough of them, and even if you do have enough of them, it is a pain to count them out (you need at least five per screw, 40 in all, to be safe, and I suspect they are also heavier than this solution.)

Included in your propeller bag (and, if you are using the standard or heavy ArduCopter motors, and the 3DR frame, I really do recommend you use the 10x45 or 12x45 props; unless you know the math better, of course...) are some plastic inserts used, along with the prop adaptor, to fit the propeller to the motor shaft. You can see them in this photo.

At the top of the photo, you will see the full set of  

unadulterated spacers. You get one of these sets with each propeller.

The second set of spacers, in the middle, shows one item missing. That is the plastic insert that is pressed into the center of the propeller.

Notice on the bottom, two additional spacers are missing along the right hand side. Counted collectively, you will have four spacers of just the right size for use in your props themselves. Then, for each prop, you will have two spacer of very slightly different sizes which will work perfectly for our purposes. 

After you have fitted the correct spacer into the propeller, to avoid any mixups, remove these additional spacers, and use them, rather than the included 3DR frame washers, to back the motor screw off so that it cannot damage your motor wiring. Inspect your motors well  (we can now speak of "engineering tolerances.") It is possible that you may still need to use an extra spacer or two (rather than a minimum of five per motor.) I did not need to use any of the 3DR-included spacers when I used the propeller inserts, one insert per motor screw. 

Total (additional) cost: $0.00. Please let me know which country you are from in the comments and I will happily provide conversions for the additional cost into any currency of your choice. ;) This tip is so simple that you might just be annoyed with me for writing such a lengthy blog about it. But, I suspect, not nearly as annoyed as you would be with four secretly unreliable, damaged motors. 

I leave you with a photograph of the final product. I hope that it brings you the same peace of mind and happy motors that I now enjoy.

Research published by the good doctors at LBNL (Lawrence Berkeley National Laboratory) in Advanced Materials into alternative anode materials for Li-Ion batteries suggests that polyfluorene-based conducting polymers (PF) are showing good promise, and might cycle well over time.

Might we soon benefit with 360g 35200 mAh batteries? Six hour ArduPilot and two-and-a-half hour ArduCopter flights? Has anyone successful added a beverage holder to their fatsharks? It may be time to start the prototypes...

From the Berkeley press release: 

"The icing on the anode cake is that the new PF-based anode is not only superior but economical. 'Using commercial silicon particles and without any conductive additive, our composite anode exhibits the best performance so far,' says Gao Liu. 'The whole manufacturing process is low cost and compatible with established manufacturing technologies.'"