In the lead-up to this year's Autonomous Vehicle Competition, Sparkfun just posted the stats for last year's AVC:

Last year we asked participants to give us a list of the major parts they used in their vehicle (SparkFun or otherwise) and 31 participants responded. And similar to the whole field, about two thirds participated in the ground competition and one third aerial.

The controller most often used in ground vehicles was an ArduPilot (ArduPilot Mega 2.5) (30%). The ArduPilot is an assembled PCB with an accelerometer, gyroscope, magnetic sensor, pressure sensor, GPS connector and current sensor. [Using the ArduRover code]

For aerial platforms, the controller most often used was the Ardupilot (ArduPilot Mega 2.5) (4 out of 5, or 80%). [Using the ArduCopter and ArduPlane code]

This year 3DR is going be debuting a new ready-to-roll ArduRover at the AVC, which is designed to dominate again ;-). Sparkfun is now giving away five of these (Developer Edition) free to AVC entrants! See the details at the bottom of the post here.

This is an update on my earlier mishap.... (NOTE - For those who do not wish to subject themselves to a double helping of my long winded posts... basically, I built a really nice APM powered quad from a non working IdeaFly IFLY4 back in march, which I then promptly lost control (and possession) of.

Anyway, one Saturday evening, about a month after my drone went missing, I received a house call from the local constabulary.

Knock, knock, knock. "Police!"

"S^&t... Really?" I thought and said out loud.  Half out of surprise and half expecting it to be a mate playing silly buggers.

Upon opening the front door I was greeted by a pair of plain clothed detectives from the Local Area Command of the New South Wales Police Force.  They politely introduced themselves, promptly verified that I was indeed the individual who had reported a lost drone approximately a month earlier, then asked whether they could quiz me on the frequencies employed by my craft - sighting the issue of radio interference in the area.  A little shocked, I complied and happily started rattling on about the FPV, DATA and RC links on my little craft.

I got about as far as explaining the frequencies and power outputs before they stopped me, revealing they had no interest in the frequencies I was using and that they were simply having a lend of me.  "we simply came to return your drone, it is sitting in the boot of our squad car" they said. I followed them out to the street where they popped the boot and presented the prodigal drone.

Much to my delight (and, if I'm honest, surprise), the craft was itself completely unblemished.  No parts were damaged, missing or even out of place - including the rather loosely secured camera.  Not even the antennas were bent, or out of place.  Well, there was one thing that had been fiddled with.  My makeshift camera mount integrated an anti-vibrant solution consisting of a layer of moongel sandwiched between two pieces of black painted balsa wood which is wrapped in cling-wrap.  It appears that the police have inspected this, probably due to it's suspect appearance.

When I asked about how it came to be in their possession they had little to say, other than the fact that it was handed in to police by what is obviously a rather understanding neighbour.  They found me thanks to the fact that I filed an incident report (even though the footage on the camera would have sufficed).

Further discussion revealed the detectives were fans of the technology and keen to know more.  We chatted for a bit and I gave them a bit of a look at some of my others projects before they headed back to work.

After seeing the detectives off I went over my wayward craft with a fine toothed comb.  The only damage (other than a bit of dog slobber on the lens) was to the battery itself (an $8 Turnigy 3S 20/30C 2200mAh) which was no longer functional having been left to fully discharge beyond a serviceable level.

Next, I downloaded the media from the Mobius, which was programmed to take stills a 1/4 second intervals at the time it went missing.  The retrieved imagery clearly records the path taken by the craft between me and where it ended up. It traveled in a southerly direction for about 300m before drifting west about 30m and landing in the middle of a nearby neighbours backyard. Below is a photo taken at the moment I lost control.  Note the red circle in the bottom left hand corner of the image which shows me fruitlessly reaching my transmitter into the air.

Log shows it was in Auto Tune mode, as I had expected, which was the result of a programming failure on my behalf.  Thankfully, this episode was the result of human error and can be easily avoided in future with just a little more care. Loss of control was actually caused by me breaking the failsafe process I had set previously (RTF was on channel 8 high, which was set as failsafe in both APM and RC Receiver) - leading the craft to enter Auto Tuning mode, rather than entering RTL mode when RC link with craft was compromised.  As a result, the craft continued to fly away from it's takeoff point, until which time it hit the perimeter failsafe.

Feeling compelled to do something for the individual(s) responsible for reuniting me with my most treasured of toys, I decided to pay my neighbour the complement of a friendly visit.  To show my deep appreciation, I came armed with a rare drop of a particularly drinkable substance.

Sadly, I didn't get to speak to the bloke that found and returned my drone, I think I spoke to his grown son. While appreciative of the gesture, he made it clear that wine wasn't his poison. Frustrated by the failure of my assumption, I ripped out my wallet which unfortunately only contained a pair of $20s.  He graciously accepted the cash, I shook his hand and thanked him profusely before heading home.

I have put about 30 charges through it since getting it back, but this whole situation has 'gentled me down some'. I am now far less flippant towards flying and setup and I always test my failsafe prior to initial arming for ever flight.  Nor do I fly without droidplanner anymore.

Needless to say, I consider myself to be very lucky.

Hi Paul,

I don't know if you know me. I'm a lead developer for the ardupilot project. You know, the project that you just accused of not being open source in an interview on http://thecrashcast.com/. I write about half the code for the project, so maybe you've heard of me.

If you've been following my work for the last 4 years on ardupilot then you would know that I'm generally a pretty mild mannered person. I try to keep my posts polite and helpful, to generally raise the tone of diydrones and open source projects in general.

Well, you better don your asbestos suit now, because I also have a rarely seen darker side. Just occasionally someone does something that pisses me off so much that I get really really annoyed. Your recent actions have done that, so here comes a flaming.

Some background

A real flaming doesn't generally come with a background introduction, but hey, I still have a mild side too (despite the fact that I am seething with anger at you right now), so why not.

I'm a long time open source developer. I started contributing to open source in the late 80s. There is a good chance that when you read this letter the bits are getting to you via computers running open source code that I've contributed to. On the wall behind me is a Free Software Foundation award for the advancement of free software. I teach a masters course on how to build and contribute to open source projects. I'm not an open source newbie. Perhaps you should have checked before making outlandish claims about ardupilot, a project that I've put my heart and sole into for so long?

I've been working on ardupilot for 3 and a half years now. In that time I've contributed over 5000 patches to the project. Given your amazing statements on the crashcast podcast and on your website about you being a defender of open source I expected to see your name in the contribution list. Strangely enough, it's not there. Did you use a pseudonym in all the contributions you have made or did you just accuse a project that you have no association with of not being open source?

How Open Source Works

As I describe in my course, open source is different for different people. Me, I'm a free software radical. I like everything I do to be FOSS (free and open source software). If I can't do something with FOSS then I see if I can write a FOSS tool to do it, then distribute it to the world. As a result I've started about 30 FOSS projects over the years and contributed to dozens more. I'm such a radical that many people in the FOSS world (including Linus Torvalds) have accused me of being too radical, and pushing the "free software or death" line too hard.

One of the big misunderstandings about open source is the insane and self-serving idea you have been pushing that the ardupilot project is somehow required, because of open source principles that you somehow fail to explain, to provide your company with binaries of our software that work on your board. That is utter and complete drivel and rubbish. You're wrapping yourself up in the open source flag while not even having the faintest idea of how open source works.

Open source project leaders can choose which hardware they support. As a lead developer of the ardupilot project I have chosen to try to make the code work on as many boards as possible. So in fact the firmware.diydrones.com site (which I maintain) does provide firmware that will probably work on your RTFHawk boards. I've also worked with people who want to port ardupilot to completely new hardware platforms. Did you notice I merged in support for Flymaple boards a few months back? Did you notice I merged in support for the VRBrain too? Did you notice the work I've been doing on porting ardupilot to the BeagleBone?

I'm guessing you didn't notice any of that or you wouldn't be making such grandiose and idiotic claims about ardupilot not being an open project.

So here's the deal. Open source project leaders get to choose what code they accept, what code they write and how the projects get managed. Really basic stuff really. I have chosen to make ardupilot widely portable and flexible, but I didn't have to. It would still be open source if I wrote the code to only work on one brand of board.

Michael Oborne is the project leader of the MissionPlanner project. He has done an awesome job building up MissionPlanner from scratch, and making it a GCS that people love to use. As the project leader for MissionPlanner he gets to set the policy. If he wants it to only load firmware to only blue boards with pink edging that have butterflies embossed on the PCB then that would be his right. I might give him some odd looks if he did that, but I'd defend his right to do it.

Because MissionPlanner is an open source project you can make it do something different if you like. If you don't like what it does then why not try something really radical like talking to him (you _did_ talk to him before accusing him of heinous crimes against the open source world? right? yes?). Hey, you could even send him a patch! Now there is a radical idea. If that fails then you could fork MissionPlanner and make it do what you want it to do. That is the fundamental succinct definition of open source after all - the right to fork. You have that right, even if perhaps you don't deserve it after all you've said in recent days.

Why do we work closely with 3DR?

If I were to believe the crap you said on that podcast then it would seem that I'm held hostage by 3DRobotics. Help, I'm an open source developer being supported by a hardware company that uses my software. Oh no!! Help me get out!!

The fact is the ardupilot developers work closely with 3DRobotics because it benefits the project. Think about that. We choose to work with them because working with them advances the aim of producing the most awesome free software autopilot that we can.

I regularly get asked by Craig Elder from 3DRobotics if there is anything he can send me to help me with my work on ardupilot. If I say "well, I fried my last Pixhawk while testing the power handling to its limits" then he pops a couple of new ones in a fedex pouch and sends it down to me in Australia. It's great!

They even pay me! I get 100% copyright on all the work I do, I get complete discretion on what code I put in and I get paid to do it. Yep, open source developers can get paid!

In fact, most large open source projects have lots of paid developers. Ever heard of the Linux kernel? Last I heard about 80% of the code is written by people who work for hardware companies that benefit from the project. This is normal. I've been paid to develop open source software by numerous companies for 20 years.

The main difference with 3DRobotics is that they are one of very few companies who have been enlightened enough to pay the ardupilot core developers. In the case of Linux there are hundreds of companies that have understood open source enough to pay the core developers. Chris Anderson from 3DRobotics saw that pitching in money to pay the people who have been working on ardupilot for so long is a good thing both for the ardupilot project and for 3DRobotics, so he did it. Now you throw that back at him and try to use it to accuse him and 3DRobotics of being some evil company perverting open source. What sort of insane logic does that stem from?

I looked in my letter box today and I didn't see any hardware from you. I bet if I talk to all the other ardupilot devs they would tell me you didn't send any hardware to them either. I haven't seen any code from you. Yet you get up on your high horse and try to claim that we owe you something? Please just crawl back into the hole you came from.

That OTP thing

The thing you have built your edifice of open source outrage on is the way that MissionPlanner checks the OTP area of Pixhawk boards and doesn't load firmware unless they match a particular public key. I have stated publicly that I don't like that behaviour. I have also made it clear that it is Michael's decision as project leader for MissionPlanner.
I have been working with other developers to try to come up with a better solution. That is how things are done in the open source world. Contributors to projects tell the project leader if they don't like something the project does and the project leader takes their ideas into consideration. Ultimately the project leader (Michael in this case) gets to choose.

So we agree?

You might think that because I also don't like the current OTP mechanism that we are in agreement. We are not. I wouldn't be flaming you in such a long winded fashion if I agreed with you.

You are taking advantage of the OTP behaviour for your own ends, and those ends have absolutely nothing to do with protecting open source.

Let's have a quick look at your actual behaviour with regards to open source and your RTFHawk project. Given your rabid defence of open source I presume you've read the license of the projects you are criticising so loudly? It's the GNU GPLv3. I happened to be on a committee that helped develop that license, so maybe you don't know it quite as well as I do. Here is a refresher. When you distribute binaries that are built from source code that is under the GPLv3 you need to (among other things) do the following:

• make the recipients of the binaries aware of their rights under the GPL. Have a look at firmware.diydrones.com for how we do that
• offer the source code to anyone who asks for it (which is why making them aware of this is so important)

So, let's see. On your website you have a binary copy of MissionPlanner modified to upload firmware to your board. Do you tell people who go there that it's GPLv3 software? Do you link to the source code? Do you offer the patches you've done? Nope, nope and nope.

What is more, you are wrapping yourself in an open source flag and trying to use that flag to sell your clone boards. You do this by criticising 3DRobtotics, a company that has done more for open source autopilots than any other company I know of. You are doing this as a company that has, as far as I am aware, done absolutely zero to benefit the ardupilot project or MissionPlanner that you are criticising.

So what now?

First off, go read up on open source. Read some of ESRs essays. Read the FSF site.

Then go away. One of the things a open source project can do is ignore people who really piss them off. You have really pissed me off. I would not accept a patch from you in future, even if you ever could be bothered to get off your ass and make a real contribution.

I will accept patches from other hardware vendors, and I look forward to working with other hardware vendors who make boards that run ardupilot, just like I have done ever since I got involved in this project. I love working with any hardware vendors who make great autopilots and who want to work with the project. I will do it regardless of whether they contribute money or hardware, because I love to see the platform grow. I won't however work with you because you have decided to start off the relationship between your company and the ardupilot project by insulting it and using those insults to further your own aims. So congratulations, you are the first company that I have banned from working with the ardupilot project, or at least working with me on it. Maybe you'd like to put that on your website?

Time to get some sleep.

Here's a pretty good news report about drones from a TV station in the Twin Cities.  It covers a variety of drone uses and discusses the UND program.  It also covers some political issues in Minnesota.

North Dakota opens nation's first drone test site [KARE11]

Researchers at Rice University in Houston, Texas, have developed a nanoporous material that has the energy density (the amount of energy stored per unit mass) of an electrochemical battery and the power density (the maximum amount of power that can be supplied per unit mass) of a supercapacitor. It's important to note that the energy storage device enabled by the material is not claimed to be either of these types of energy storage devices.

The research community has wearied of claims that some new nanomaterial enables a “supercapacitor," when in fact the energy storage device is not a supercapacitor at all, but a battery. However, in this case, the Rice University researchers, led by James Tour, who is known for having increased the storage capacity of lithium-ion (Li-ion) batteries with graphene, don’t make any claims that the device they created is a supercapacitor. Instead it is described as an electrochemical capacitor with nanoporous nickel-fluoride electrodes layered around a solid electrolyte that is flexible and relatively easy to scale up for manufacturing.

The issue of appropriate nomenclature aside, the reported performance figures for this energy storage material are very attractive. In the Journal of the American Chemical Society ("Flexible Three-Dimensional Nanoporous Metal-Based Energy Devices"),  the researchers report energy density of 384 watt-hours per kilogram (Wh/kg), and power density of 112 kilowatts per kilogram (kW/kg).

To give some context to these numbers, a typical energy density for a Li-ion battery is 200Wh/kg, whereas commercially available supercapacitors store around 5- to 25 Wh/kg and research prototype supercapacitors have made claims of anywhere from 85 to 164 Wh/kg. In terms of power density, the numbers for the new nanoporous material is in line with those of supercapacitors, which range from 10 to 100 kW/kg—far higher than the 0.005 to 0.4kW/kg that batteries can deliver.

“The numbers are exceedingly high in the power that it can deliver, and it’s a very simple method to make high-powered systems,” Tour said in a press release. “We’re already talking with companies interested in commercializing this.”

To make the battery-supercapacitor hybrid, the Rice team deposited a nickel layer on a backing material. They then etched the nickel layer to create pores five nanometers in diameter. The result is high surface area for storing ions. After removing the backing, the nickel-based electrode material is wrapped around a solid electrolyte of potassium hyrodroxide in polyvinyl alcohol. In testing, the researchers found that there was no degradation of the pore structure after 10 000 charge-discharge cycles, or any significant degradation of the electrode-electrolyte interface.

“Compared with a lithium-ion device, the structure is quite simple and safe,” said Yang Yang, lead author of the paper, in the press release. “It behaves like a battery but the structure is that of a supercapacitor. If we use it as a supercapacitor, we can charge quickly at a high current rate and discharge it in a very short time. But for other applications, we find we can set it up to charge more slowly and to discharge slowly like a battery.”

With the device’s flexibility and high charge-up rate, it’s possible to imagine this storage device powering flexible mobile devices. However, charging rates for the battery/supercapacitor will be limited by the typical 200-amp 240V single-phase residential service, which is only capable of providing (absent any other load) only 48 kW.

http://spectrum.ieee.org/nanoclast/semiconductors/materials/nanoporous-material-combines-the-best-of-battery-and-supercapacitor-capabilities

Here's the blurb:

diydrones moderator Mark Harrison (me!) will be appearing on the popular CrashCast podcast today, Wednesday April 30, at 8:00pm Central time.

A 30 year veteran of the Open Source Software (OSS) world (he release his first open source program in 1982), he will be talking about his experiences with RC OSS such as OpenTX/er9x and Ardupilot Mega. In addition he'll be presenting his views about the interesting challenges being faced in the relatively new Open Source Hardware (OSH) world, such as cloning and developer support.

You can listen to the live stream, download the podcast, and access the show notes here:

http://thecrashcast.com

I had originally planned pure tech (summary: open source RC = Great) but topically I'll be touching on the recent diydrones thread regarding the pixhawk clones and how this site handles potentially controversial topics .(summary: with grace and style).

So give it a listen, and check back Thursday morning to see if I'm still a moderator here!

I thought I would share my recent experience getting back into UAV/RC. HI got started in this a few years back as a uni project where I wrote a FBW / Stabilization program on a PICAXE PIC chip using the ArduIMU as a sensor package. 

More recently I have started again with a Bixler 2 and Pixhawk where I have been learning the world of APM (and re-learning my rusty RC skills). It was certainly a learning experience - my first ever auto flight flew away out of sight due to reversed rudder settings. Lucky for me the APM eventually managed to turn the plane around and it calmly flew back to home after a few very tense minutes packing up and go searching for the aircraft in the suburbs.

Over the Easter break I took a trip down to Albany in Western Australia and obtained some HD videos around the beaches there which I've attached below:

First Camera Equipped APM Flight on my Bixler 2 - Snapshot is looking over Bald Head.... next stop Antarctica.

Telemetry Range Tests around whaling station - This includes a crash due to stalling at the end of flight. First time with dual 2.2AH batteries and I underestimated the effect of the extra weight on stall speed.

Flying Over Goode Beach - A nice tour of the Goode Beach area in Albany. This video includes an overlay of the MP HUD from the telemetry data on the flight.

Unfortunately on my last flight (not shown as camera was lost) I encountered a major problem in the air which I suspect was motor/ESC failure. The resulting stall and crash from high altitude destroyed the aircraft but fortunately hit the ground only about 100m from me and I was able to recover all of the electronics except the camera. A new Bixler is on my kitchen table at home under construction and I hope it lasts longer and I can learn the lessons for both build and flying.

(Standard safety note - you will notice that we are launching/landing in a small carpark and using the nearby road at times. This is an extremely quiet rural road and I had a spotter who could see up and down the road to ensure we didn't get in the way or get hit by traffic)

Undergraduates of Loughborough University have to do a Group Design Project as part of their final year Aeronautical MEng degree. This year, with the help of Simon Howroyd a PhD student at the University, one of the groups were challenged to design and develop a UAV capable of searching for a person, in a Search and Rescue (SAR) mission. The team known as "Overwatch" have heavily modified a Skywalker X8 and used APM2.6 to create a stable camera platform capable of flying search missions.

The project goes beyond the typical hobbyist modelling approach and features heavy theoretical design and analysis including Computational Fluid Dynamics to assess the aerodynamics, backed up by wind tunnel testing. They have also done structural modelling to ensure a stiff structure in unforgiving weather conditions such as storms in mountainous areas which are hard to reach by rescuers en foot.

It is relatively short project, only spanning around 7 months, with all the undergraduates having no prior knowledge of UAVs or RC aircraft, so the learning curve has been steep! Factor this alongside working with unusual materials in this field such as Styrofoam and expanded polyolefin (EPO) and you have a great project to vastly improve the employability of the students in industry after graduation.

May 2014 sees the project come to a conclusion with a presentation and report due. Of particular interest the output of the system is a GPS location and photo of the person to be rescued. This is achieved by utilising a standard search pattern and onboard image processing of camera frames where Matlab code (recompiled as C code and uploaded onto a BeagleBone) makes decisions as to the probability of the subject being found in each frame.

We look forward to any comments you may have and we will post a complete report at the end of the project in a month or so.

UPDATE 11JUN14:  We made the ITV Central, and ITV Yorkshire 6'o'clock news here in the UK!

Pictures:

Find more photos like this on DIY Drones

Videos:

Down facing camera - flight 1

Front facing camera - flight 2

Rear facing camera - flight 3 (with stall & spin)

45deg down facing camera - flight 4

Undergraduate Team:

James Baines - Systems hardware, image processing & prototype development
Sufal Basnyt - Image processing
Oliver Boldero - Prototype manufacture, materials & CAD
Alex Cook - Aerodynamics
Stephen Clarkson - Portability & prototype manufacture
Iain Forbes Brown - Aerodynamics & wind tunnel
Chris Hughes - Comms & swarm logic
Mudasser Iqbal - Prototype manufacture, structural design & catapult
Jitinder Johal - CONOPS, detection, FMECA
Phillip Loughlin - Systems hardware, powertrain & prototype development
Oliver Meager - Aerodynamics & CFD
Thomas Offord - Sense & Avoid
James Whitehead - Comms & swarm logic

Project Directing Staff:

Dr Gary Page - Senior CFD lecturer
Dr Chris Harvey - Structures lecturer
Dr Paul Cunningham - Materials & structures lecturer
Simon Howroyd - Pilot & UAV technical support, PhD researcher

This is actually pretty cool. The Cheerson CX-20 Phantom clone ($330 at Banggood) uses an APM clone flight controller, running ArduCopter 3.1. Found on RC Groups here. 

We've been dropping hints about the forthcoming Linux-based versions of APM/Pixhawk. Here's another glimpse of the future, using the forthcoming Pixhawk Fire "cape" (like an Arduino shield) for Beaglebone Black.  Victor Mayoral Vilches explains the BeaglePilot project, which is a Linux-based autopilot for flying robots. It was a project selected by BeagleBoard at the Google Summer of Code 2014.

BeaglePilot project aims to create the first Linux-based autopilot for flying robots using the BeagleBone and the BeagleBone Black as the “hardware blueprint”. For this purpose the project will focus on integrating ArduPilot (most popular autopilot) in the BeagleBone (Black). The main tasks performed will be userspace drivers development, the Robot Operative System Integration (ROS), web IDE exploration and security assessment. The BeagleBone cape “PixHawk Fire Cape” and the robot “Erle” will be used.

After a year of darkness, with a lot of crashes and deceptions, we manage to build our lightweight frame and get our manufacturer licence from the DGAC.

In France, europe will probably apply the same rules, the uav with batteries and dslr, has to be less than 4kg alltogether to be authorized in town. Our goal was to get 1 kg payload with 15 min and a full control of the dslr. Our overpowered quad is 2580g with paraglide, and has an autonomy of 12 to 15min with 2*4S2100mah (418g). The gimbal can carry 1kg payload and all canon dslr are driven by dslrcontroller from the ground.

We had a 6 months disscussion with the dgac to prove them the safety of the apm firmware.

Done, DGAC accepted the first manufacturer with something that is not DJI or MK.

Thanks a lot to everyone who helped us.

Nicolas hebert

escadrone.com

On Sunday I spent the morning self-consciously traipsing around my brother's neighborhood with an apparently wierd collection of hand-held electronics and foam in the form or my APM, battery and a Hextronic 3DR knock-off 915MHz telemetry radio and Skyfun fin. We left a laptop on the top floor of the house running APM Planner with the base station radio connected directly to the USB port and using a standard "duck" monopole antenna.

The mobile unit used my experimental lightweight directly-soldered dipole and the contraption was powered by a standard Futaba NiCad receiever pack as pictured above.  The aim of the new antenna design was to reduce mass and configure it so that it could be embedded entirely within the vertical stabilizer of the Skyfun.

Unfortunately, I don't have a functioning GPS at the moment, so I located our position relative to the base station by memory and adding a series of coded yaw and roll gyrations of the APM to help identify the approximate location by post-processing the tlog file and correlating with Google Earth measurements. The time-domain plot of the RSSI results looks like this:

What is immediately obvious is the elevated noise floor at the base station. I guess it could be laptop power supply related or some other component, but I think it begs some experimentation with USB cable extensions and remote antennae. I'd also like to make a dipole up to see if I can improve the efficiency.

From the post-processed position data (approximated by the ruler function in Google Earth) I have plotted an RSSI profile with radius. Note that we were not line-of-sight for a lot of the meanderings due to the geography and surrounding suburbia. There is also a huge steel girder railway bridge that we passed under during the process, which appears to have had some effect. The transmission dropout in the first graph appears to be due to terrain masking entirely.

During the log file post-processing in Excel, I concocted an error rate calculation to compare the data with RSSI. What you see here is probably of little absolute merit, but it does indicate a dramatic increase in the error rate as the RSSI value falls much below 100. The time-domain plot would seem by eyeball to indicate successful transmission with an even lower RSSI.

Since I had also wanted to see if my new-fangled antenna had made a difference, or at least no difference, I plotted RSSI against remRSSI to see if there was any bias. The answer is, if you squint a little, perhaps to a small degree. The base station appears to recieve a higher signal at range than the mobile station. Whether this amounts to improved signal transmission from the mobile station, it's hard for my RF ignorance to determine, but I will clutch at this straw for some feelings of feeble accomplishment.

So, it seems likely that the system as it stands will yield a reasonably line-of-sight data link to circa 500m. If I can improve the base station noise floor, this may be able to be significantly improved. I was actually hoping to reach the 1000m mark, but this looks like requiring more development and experimentation.

All of this is (for completeness) with the radios configured using mission planner with the frequency band from 918-928MHz, 30 channels, 20mW power. For some reason, this is the maximum power available on the selection menu when connected. There might be a firmware update to try.

I wanted to share my experience with openFoam. 

I am using openFoam as part of the free linux distribution CAElinux. CAElinux makes it a snap to get a copy of openFoam up and running. CAElinux also comes with a plethora of open source CAE packages. After going through many of the available tutorials, I can now import my own geometries and run a case. I still have much to learn as openFoam is extremely powerful and flexible. The interface is mostly through setup files so it is not very intuitive or point and click. 

the first step is to produce a computational mesh. this is a screenshot of gmsh an open source meshing program for mesh generation. it is very tricky adjusting the mesh densities. set things a little too fine and you can end up with millions of entities and take days to complete. set it too low and your computations will not be as accurate. I can successfully generate all the meshes required but still working on getting from gmsh to openFoam. 

After the mesh is generated( I used snappyhexmesh for the photo at the top) you must configure the dictionaries and folders in your case file ( I modded the motorBike tutorial case folder). After this is all set up and the code in the dictionary files makes sense, a quick "./Allrun' in the terminal to execute the run script. After a while the case will be done running and you can enter "paraFoam' to open up paraview with your newly created simulation data. paraview has a nice GUI interface and does not take long to produce some nice pictures of the 3D pressure and velocity fields of the airflow around the model. 

I still have much to learn before I can start making highly accurate performance predictions with openFoam, but I know I will get there. it is great to have access to such a powerful and open CFD package

This smartphone-sized pocket battery is being marketed for emergency starting of cars with flattery-battery-syndrome, but if the manufacturers specs are believable it would make a fantastic power pack for quads etc.  More than twice the energy density of typical hobby-grade LiPos (typically <600kJ/kg) and with a good punch of the current to boot! (50C, allegedly!)

At only $99.99 ($69.99 for pre-sale purchase - see website) it's not bad value compared to the lower energy-density Panasonic NCR18650B cells.

FWIW

As published by The Guardian (link to the full story is here):

"A German wildlife rescue project is deploying small aerial drones to find young deer hiding in tall grass and protect them from being shredded by combine harvesters cutting hay in spring.

According to project spokesman Rolf Stockum, the pilot scheme has shown great promise in spotting the young animals. About 100,000 of them fall victim in Germany every year to the large agricultural machines, he said on Friday."

Hi there, my name is Ben Boughton and I am a grain producer from NSW in Australia. I have recently been awarded a Nuffield Scholarship to research the potential of UAVs/UGVs in the grains industry (Sponser: GRDC). I have a website - agmapsonline.com where I have been documenting some of my initial research. I have some information about Nuffield and my research project below.

This year I plan to travel locally & globally to continue my studies and am looking for people to visit. I am very interested in the Open Source community UAV scene and believe it has a lot to offer the ag industry.

The people I would like to meet with is anyone that is using UAVs to improve their grain production. I am particularly interested in those competent in producing georeferenced aerial imagery including NDVI over large areas (100Ha+) and willing to share processes.

Much of what I learn will be made available through Nuffield as a report which is presented upon completion.

If you like to be a part please contact me by email ben@agmapsonline.com

Thanks for your time,

Ben Boughton

As a side note - I have just received my PixHawk and plan to put it in my fresh Finwing Penguin when I get a chance. I am very excited by the potential of this little unit especially when we see people combining it with the Piksi RTK GPS.

A summary of my Nuffield Scholarship:

2014 Nuffield Scholar Ben Boughton

I am an Australian farmer based in northern NSW on a family farm. We grow wheat, barley, and chickpeas in the winter and sorghum in the summer. Our land area is 2200ha and annual rainfall is 600mm.

About Nuffield Australia:

Nuffield Australia awards Scholarships each year to farmers in Australia. The objective is to increase practical farming knowledge and management skills and techniques generally. These scholarships give Australian citizens the opportunity to study farming practices in New Zealand, Europe, Asia and the Americas and those countries best suited to the Scholar. They will also promote a closer understanding between farmers in the countries visited.

Upon returning to Australia it is expected that Scholars will be able to actively spread the knowledge and understanding they have gained among their fellow farmers and others.

Read more at Nuffield Australia Website: http://nuffield.com.au/about-nuffield-australia/

Research Project: Potential of unmanned aerial/ground vehicles in the grains industry

I believe there are several components that make up the agricultural UAV Solution:
aUAV Solution = platform + GPS + autopilot & communication + sensor + data processing & integration + legal & operation

As part of my Nuffield studies I want to look at farmers/agronomists/specialist businesses integrating these components to make better decisions on grain farms and thus increase their triple bottom line (economic, environmental & social).  I want to try and cover solutions over different price points spanning from professional integrated solutions (e.g. AgEagle, Precision Hawk), to the budget (yet almost complete) such as Event38 to anyone that has had success in a fully DIY setup (e.g. 3D Robotics components). Ideally I’d like to see UAVs operating, collecting data, data processed and then the data put to work in an existing grain growing system or at least understand the potential for this process.

In addition, I would like to meet people focusing on individual components, particularly the sensor and software development integration into existing precision agriculture systems, as this has been identified as a great challenge.

Ground vehicles are not a direct focus, but small autonomous ground vehicles used to collect data or undertake light duties such as camera spraying will be considered as well.

Upon returning to Australia I will be presenting my findings to the Nuffield organisation and a report will be made available on the Nuffield website. I also hope to in the future use UAV technology on my home farm.

Read more about my farming background and Nuffield project at http://agmapsonline.com

Andrew Tridgell (Tridge), one of the lead APM/Pixhawk developers, gave a speech in January on the process of porting the code to Linux, which is now well underway (more details soon).  This is a great overview of the approach the dev team took on this and what it enables. 

Not sure how much stereoscopic effect you can get from the air. 

We did the same last year with Oculus Rift from a plane (see below), and it just looked like regular FPV.

This is a really interesting lecture on the challenges and progress towards truly autonomous rotorcraft, which Scherer defines as aircraft that do not follow pre-programmed missions but instead dynamically change their paths depending on obstacle and objectives determined in flight. 

This is the path that the APM/Pixhawk project is on, too, and the introduction of "rally points" in current version of the code is the beginnings of the dynamic waypoint control that is the foundation of this. Right now we do some dynamic mission planning, such as geofencing, terrain following and autolanding patterns. But with the generation of code enabled by the more powerful Pixhawk platform, this will extend to something closer to what Scherer defines as true autonomy, with the ability to automatically adjust missions in flight to avoid obstacles, follow targets and adjust mapping paths in response to changing image acquisition needs (obscured shots or changed lighting).

With the help of several members of this community, I could make the prototype in the torpedo design work and I did a lot of measuring and mapping with it.

It went very well, so I decided to build an improved version of the sonar boat which you can see in the picture above.

But first I will share some impressions of my first boat. In the following picture you can see me with my "torpedo design" boat.

In the video below you can see the performance of the boat.

The ArduPilot worked very well and the speed, size and the operation range were satisfying. But the propulsion nozzle turned out to be very sensitive to sea plants. And in windy conditions with waves and in curves, it was rolling quite a lot. I measured a big lake with it as you can see in the Google Earth picture on the bottom of this page, but I decided to build a more stable boat.

So now I tell you about the Making of the improved boat:

The new boat should be able to carry more batteries, be more stable in the water, be faster and not be too much bigger. So I decided to build a small trimaran. I started to plan it with DELFTship which is for free and easy to use.

I also used NX to plan the space I needed in the hull as you can see in the pictures below:

The next step was the making of the positive mold. I could use the laser cutter of the Fablab in Aachen (https://hci.rwth-aachen.de/fablab) to cut the sections that were exported from DELFTship out of 3mm MDF.

At home I glued everything together with hot glue and filled it with Styrodur that I cut before:

After a lot of grinding and filling, it looked like this:

After some more grinding and painting, I made a negative mold with plaster bandages to keep the costs low and painted it with 2K paint. After waxing the mold I could start with the glass fiber:

I used the following product and which worked very well:

http://shop1.r-g.de/art/100110

The resin has a curing time of 40 min which makes it very easy to use. The result looked like this:

After equipping the hull it was ready for the water:

In the following video you can see the making of the boat step by step:

Before letting the boat into the lakes I wanted to be able to find it after its work under any circumstance so I included an XBee 900 pro for a GPS-data link. Also I wanted to be able to manipulate the track of the boat by a joystick with the XBee, so I printed a case for a small remote control to include the XBee, a thumbstick, a small Arduino and other switches.

I am now able to switch between the XBee-controll and the ArduPilot with a multiplexer on board.

After that final step, I was ready for the next lakes.

After improving the ArduPilot parameters the trimaran performed very well. I could switch the boat on, put it into the water and have breakfast at home, before picking it up after several hours and it was always there. If the wind had blown it away, I could track it via the XBee and with the Earth Bridge, I could watch its position live on Google Earth.

In this Video you can see the performance of the boat in different conditions:

The following pictures will give you some impressions of the measuring:

In this last picture, you can see the work i have done so far with the boats and in the area, there will be many more lakes for measuring.

If you have questions or suggestions just comment and I try to answer quick.