Blogs

The ardupilot development team is proud to announce the release of version 3.1.0 of APM:Plane. This is a major release with a lot of new features and bug fixes.

The biggest change in this release is the addition of automatic terrain following. Terrain following allows the autopilot to guide the aircraft over varying terrain at a constant height above the ground using an on-board terrain database. Uses include safer RTL, more accurate and easier photo mapping and much easier mission planning in hilly areas.

There have also been a lot of updates to auto takeoff, especially for tail dragger aircraft. It is now much easier to get the steering right for a tail dragger on takeoff.

Another big change is the support of Linux based autopilots, starting with the PXF cape for the BeagleBoneBlack and the Erle robotics autopilot.

Full list of changes in this release

• added terrain following support. See http://plane.ardupilot.com/wiki/common- ... following/
• added support for higher baudrates on telemetry ports, to make it easier to use high rate telemetry to companion boards. Rates of up to 1.5MBit are now supported to companion boards.

• added new takeoff code, including new parameters TKOFF_TDRAG_ELEV, TKOFF_TDRAG_SPD1, TKOFF_ROTATE_SPD, TKOFF_THR_SLEW and TKOFF_THR_MAX. This gives fine grained control of auto takeoff for tail dragger aircraft.
• overhauled glide slope code to fix glide slope handling in many situations. This makes transitions between different altitudes much smoother.
• prevent early waypoint completion for straight ahead waypoints. This makes for more accurate servo release at specific locations, for applications such as dropping water bottles.
• added MAV_CMD_DO_INVERTED_FLIGHT command in missions, to change from normal to inverted flight in AUTO (thanks to Philip Rowse for testing of this feature).
• new Rangefinder code with support for a wider range of rangefinder types including a range of Lidars (thanks to Allyson Kreft)
• added support for FrSky telemetry via SERIAL2_PROTOCOL parameter (thanks to Matthias Badaire)
  added new STAB_PITCH_DOWN parameter to improve low throttle behaviour in FBWA mode, making a stall less likely in FBWA mode (thanks to Jack Pittar for the idea).
• added GLIDE_SLOPE_MIN parameter for better handling of small altitude deviations in AUTO. This makes for more accurate altitude tracking in AUTO.
• added support for Linux based autopilots, initially with the PXF BeagleBoneBlack cape and the Erle robotics board. Support for more boards is expected in future releases. Thanks to Victor, Sid and Anuj for their great work on the Linux port. See http://diydrones.com/profiles/blogs/fir ... t-on-linux for details.
• prevent cross-tracking on some waypoint types, such as when initially entering AUTO or when the user commands a change of target waypoint.
• fixed servo demo on startup (thanks to Klrill-ka)
• added AFS (Advanced Failsafe) support on 32 bit boards by default. See http://plane.ardupilot.com/wiki/advance ... iguration/
• added support for monitoring voltage of a 2nd battery via BATTERY2 MAVLink message
• added airspeed sensor support in HIL
• fixed HIL on APM2. HIL should now work again on all boards.
• added StorageManager library, which expands available FRAM storage on Pixhawk to 16 kByte. This allows for 724 waypoints, 50 rally points and 84 fence points on Pixhawk.
• improved steering on landing, so the plane is actively steered right through the landing.
• improved reporting of magnetometer and barometer errors to the GCS
• added FBWA_TDRAG_CHAN parameter, for easier FBWA takeoffs of tail draggers, and better testing of steering tuning for auto takeoff.
• fixed failsafe pass through with no RC input (thanks to Klrill-ka)
• fixed a bug in automatic flow control detection for serial ports in Pixhawk
• fixed use of FMU servo pins as digital inputs on Pixhawk
• imported latest updates for VRBrain boards (thanks to Emile Castelnuovo and Luca Micheletti)
• updates to the Piksi GPS support (thanks to Niels Joubert)
• improved gyro estimate in DCM (thanks to Jon Challinger)
• improved position projection in DCM in wind (thanks to Przemek Lekston)
• several updates to AP_NavEKF for more robust handling of errors (thanks to Paul Riseborough)
• improved simulation of rangefinders in SITL
• lots of small code cleanups thanks to Daniel Frenzel
• initial support for NavIO board from Mikhail Avkhimenia
• fixed logging of RCOU for up to 12 channels (thanks to Emile Castelnuovo)
• code cleanups from Silvia Nunezrivero
• improved parameter download speed on radio links with no flow control

Many thanks to everyone who contributed to this release, especially our beta testers Marco, Paul, Philip and Iam.

Happy flying!

Our Low Orbit Helium Assisted Navigator (LOHAN) mission Kickstarter campaign got off to a flying start over the weekend, hitting 100+ backers and almost £5k of our £30 target.

Due to circumstances beyond our control, the launch of our Vulture 2 spaceplane has been relocated from Europe to Spaceport America, New Mexico, and we need cash to cover the extra cost.

In return for your support, we're offering top-quality merchandise, with other rewards to follow in the next couple of weeks. It's a tip of the hat to DIYDrones members Andrew Tridgell and Gary Mortimer for opening their wallets, although given Tridge's fantastic support of the mission, the least we can do is send him a few more goodies.

As you can see from the above photo, we're pulling our all the stops in our fundraising drive. Yesterday, apprentice boffin Katarina and the plucky Playmonaut - our aircraft's diminutive pilot - hit the streets in search of extra wonga, armed with hand-crafted sign, LOHAN mug and the obligatory dog on string.

Every little helps, so if you can spare a few bucks to push the envelope of UAV endeavour, get yourself down to Kickstarter.

In this post I discuss the prospects of consumer product delivery by drones and ask: How much are you willing to pay for the service? There is a survey at the end so you we all can see what the trend is.  I'll post the results later.  PS - this is not sponsored by Amazon.

I love the look of the Tesla Model S, but I’d never get one. Somehow, the opportunity to pay $100K to drive only 300 miles before spending 4 to 9 hours recharging does not appeal to me. I also love the idea of Amazon’s drone delivery initiative Prime Air.  But, like the Tesla, the opportunity to pay a lot of money for drone delivery of the latest camera just doesn’t make sense.

Amazon has successfully painted a picture of a future in which its drones push merchandise from its warehouses to nearby consumers in 30 minutes. But to qualify for Prime Air, the order must be less than five pounds, which, according to Bezos, includes 86% of the packages Amazon currently sells. The order must also be small enough to fit in the cargo box that the craft will carry, and the delivery location must be within a 10-mile radius of a participating Amazon order fulfillment center.

What is less than 5 lbs.?  Here’s some examples from some recent online shopping trends research:

• Consumer electronics
• Books
• Clothing

...read more here:  http://droneanalyst.com/2014/08/24/drone-delivery-how-much/

Take the three question survey here: https://www.surveymonkey.com/s/drone-delivery

Falcon taxing for takeoff (photo by Constantin Diehl)

Falcon Unmanned is pleased to have demonstrated Falcon and Falcon Hover at this weekends Rocky Mountain Airshow in Greeley Colorado.  This was the first time in the US that a UAV without a military designation or special airworthiness certificate was able to perform in an outdoor air show demonstration with the FAAs consent.  In the end we were flying under AMA rules as an AMA sanctioned event however I believe that the precedent has been set to open the door for future demonstrations of this type of technology under the COA process.  The actual demonstration included a bungee launch of Falcon, a couple of passes of the spectatros, and recovery.  This was followed by a flight of Falcon Hover along the runway across from the crowd.  During both flights we were broadcasting the video feed from our new stabilized gimbal on the jumbotron.  Following the main demonstrations flights were completed using Falcon Hover in an indoor netted area.  While we were limited flight time this is an important milestone for the industry and showed the general public the positive benefits that unmanned aircraft can provide.

We'd like to thank the Rocky Mountain Airshow staff Jim Cimiluca and Constantin Diehl for their efforts to coordinate this event with the FAA and also Mike Harrington with the AMA for his support for this event.

Chris Miser

Owner

Falcon Unmanned

www.falconunmanned.com

Falcon Hover getting a birds eye view of a P-51 (photo by Constantin Diehl)

Follow different frame and drone configuration : Quad , Hexa , Okto and Plane . The VR Lab Team and member of Virtualrobotix community test all this configuration and send us a very good feedback .

In these three months of work, from the presentation of vr micro brain to the maker fair in san francisco, we have done a lot of work to make the board very reliable and to be able to equip and test different types of drones. For us, a micro drone has the following features: is equipped with a control system structure. has gps reliable and accurate at all hours of the day that allows you to activate the automatic functions browsing the drone. is equipped with a telemetry system that allows integration with a ground station to the ground. E 'equipped with an advanced system of brushless gimbal that allows the perfect stabilization of the camera. Mount a camera system for on-board recording in full HD and allows you to remotely transmit the preview of the recovery.

These are the board developed by VR Lab : VR micro Gimbal , VR Multi Constellation GPS 8  ,VR Micro Brain and plug and play VR micro telemetry board .

This is a video example of our you can add the telemetry module to VR micro brain and test the board with VR Pad Station. Now is possible to connect directly VR micro brain and VR micro Gimbal to VR Pad Station by a usb OTG cable.

Example how is possible to assemble  the boards togheter , the form factor is very small and lightwheight . 

This is an a video example of new VR micro Gimbal in action.

This is a very exclusive video  example of fully autonomous fly using VR Leash experimental kit . You can set the position where put the drone by VR Leash natural reposition system or by PAD / Smartphone user interface available in VR Pad Station Pro.

Some of board use in these drone is already available : 

VR micro Brain : http://www.virtualrobotix.it/index.php/en/shop/autopilot/vrbrainmicro51-detail

VR GPS 8 : http://www.virtualrobotix.it/index.php/en/shop/accessories/gps-ublox-8-detail

VR micro Telemetry option : will be available at begin of september 

VR micro Gimbal Board :  will be available at begin of september 

VR Leash : available for OEM and Pro project.

P.S.

if you have more interesting picture of video of your micro drone base on VR micro boards sene me more details so i can add to page of example configuration that i'm creating in official wiki page.

original blog post : http://www.virtualrobotix.com/profiles/blogs/vr-micro-brain-5-the-micro-drone-invasion-began

Best

Roberto

This new kid on the block was spotted here: http://www.cbs8.com/story/26329653/local-companies-test-drones-in-wind-tunnel?autoStart=true&topVideoCatNo=default&clipId=10495031

Hi DIY Community,

I would like to share this video with some of the things we've done in one year of development of the project flone.

Flone is a platform that makes smartphones able to fly... and much more.

You can select english subtitles for the few spanish sentences in the video.

• Aerial Display System with Floating Pixels
• Aerial Display System with Floating Projection Screens
• Aerial Display System with Marionettes Articulated and Supported by Airborne Devices

http://blogs.marketwatch.com/themargin/2014/08/22/disney-may-use-drones-in-theme-park-entertainment/

It's official.  Guinness World Records validated the flight (see link under Flight 1).

Two flights were achieved to demonstrate that multi-rotor aircraft can stay in the air carrying a payload for a long period of time.  While 20 minute flights were considered long in 2014, these demonstration flights show that 1 hour flights can be the norm.  Imagine the increase in commercial applications when it is common for ships to stay in the air for an hour or more carrying different payloads.  It's just a matter of finding good rotors (Tiger), flight control electronics (3DR), batteries (Panasonic Li-Ion), ESCs, and removing unnecessary weight.  Once industry realizes the importance of performance, we will also see a jump in rotor and ESC net-lift efficiency (lift after it gets itself off the ground first).

Flight 1 – Guinness World Record for Longest Electric RC Multicopter Flight (Duration). Pending Guinness review.

• Ship Name, Rufous
• A hover that stays within view of the stationary video camera
• 1 ½ hrs (97 minutes 23 seconds) on 8/21/2014 @ about 4 meters above open level ground (well above ground effect and without use of thermals or updrafts)
• Hover, while not impressive nor useful, does require more energy than typical flight speeds and as such, a good first test.
• Pixhawk Flight Log (Time, GPS, Altitude, Speed, Volts, Amps): Guinness Flight
• Video of the Guinness record
• Guinness Record Book

• Time Lapse (GoPro) of the Guinness record.

• Ship Secrets

Earth view of the hover breaking the world record.

The officials:  Michael Allen (expert in UAV flight control; Cloud Cap Technology), Brett Faike (UAV extraordinaire; teaches UAV tech at local schools; gave FPV demo after flight), Forrest (pilot in training), and Kirby Neumann-Rae (editor of the Hood River News).

Celebrating surpassing the old record of 80 minutes (ahhh ... hey pilot ... a little less champagne and eyes on the copter ... it's not time to prune the orchard yet!).  Bud, not shown, was taking photos.  Hope you got some champagne Bud!

Co-pilot, Dr Carie Frantz ... yes this amazing looking lass is single, is an unreal outdoor bad-ass, and has a great job in case you were wondering.  Thanks for keeping pops sane Carie.

Posting the final time (for the final application to Guinness, I requested that 4 seconds be taken off because some blades of grass were brushed prior to the ship finally giving up and setting down.  An interesting note on the battery:

o The Li-Ion batteries used are rechargeable (flight was on about the 8th recharge).

o Running Li-Ion batteries down to where the ship drops out of the sky does not hurt them if the ship mass and battery voltage is engineered to invoke that event before voltage runs down too low.

o A few days later, Flight 2 was made using the same battery pack with the ship carrying a camera (see Flight 2 next).

o Li-Ion are low C discharge (not 30 or 20 or 10 ... think about 1 C).  The chemical barrier will break down if amp draw is too high. This causes the ship to loose altitude.  And if there isn't enough altitude for the battery to recover, crash. As an example, using a 4S5P battery pack (about 15000mAh), Rufous hovers and flies at moderate speed at about 8 to 10 amps depending on payload and flight demand and does great even in moderate winds. Rufous has even flown 60 mph (97 kph) on the same Li-Ion battery pack. However, get up to 15+ amps turning a sharp high-speed corner and the battery chemical barrier locks up in about 2 seconds (yes I've had to rebuild a few times before I figured this out).  So caution.  Do the calculations.  Try to design a safe ship that stays in the air at 2x the amp usage at hover. 

Flight 2 – Performance demonstration flight (actual flight versus stationary while carrying a payloads)

• Time aloft                                                                 goal of 1 ½ hr; so far 82.9 minutes
• Distance traveled                                                       goal of 10 km; so far 14.4km (9 miles)
• Elevation gain (cumulative)                                        goal 300 meters; so far 378 m (1242 ft)
• Speed           (max)                                                   goal 18 m/s (40 mph); so far 9 m/s (20 mph)
• Speed           (typical)                                                 so far 2.3 m/s (5 mph)
• Payloads                                                                  GoPro Hero 3+ and 3DR Telemetry Module
• Flight Log  (Time, GPS, Altitude, Speed, Volts, Amps)  Performance Flight
• Video                                                                        coming soon

[note:  will try to beat 90 minutes carrying a camera when I get back from Sri Lanka]

Earth View showing the flight path of the performance demonstration over my orchard.

Photo taken by Brett Faike, a local multi-copter flying legend, of the flight area (man-cave on left and princess palace on right).  He treated the witnesses of the Guinness record to FPV flights afterwards using two sets of goggles so we could "ride" along (keeping the ship within visual range and over my farm, of course).

Flight #2 (with camera and telemetry payloads), Elevation Profile.

Flight #2 (with camera and telemetry payloads), Watt Profile.

Flight #2 (with camera and telemetry payloads), Speed Profile.  The wind speeds were about 2 - 4 m/s from the north..

Flight Team

• Design/Engineering                                 Forrest Frantz
• EE/Flight Engineering                              Jim Frantz
• Test                                                       Marty Frantz
• Pilot                                                       Forrest Frantz
• Copilot                                                   Carie Frantz

Acting Guinness Judges/Timers

• KirbyKeumann-Rea             Hood River News                       Editor
• Michael Allen                     Cloud Cap Technologies             Flight Control Software
• Brett Faike                         Multi-Rotor Extraordinaire           Software Developer

Ship Summary:                                                                                1.65 kg (w/ camera & telemetry)

• Frame                       Quad Carbon tube w/ open front for photography             62 g
• Flight Controller         3DR Pixhawk + 3DR Power Module                               34 g
• Motors                      T-Motor MN3508-29 380KV                                         328 g
• Propellers                  T-Motor Carbon 16 x 5.4                                             116 g
• ESC                          Afro 20A                                                                     31 g
• Batteries                   Rechargeable Panasonic NCR18650B 4S5P                 930 g
• Camera                    GoPRo Hero 3+                                                            76 g
• Telemetry                 3DR Radio V2                                                               19 g
• Wires & Misc           Long wires runs were magnetic wire                                54 g

Design Elements of Note: 

• The electronics platform (EP) was eliminated to save weight (previous EP added 8 grams).  The battery doubled as the EP.  The flight controller (FC) was bonded directly to the battery, which was bonded directly to the frame.  The battery has a strong electro-magnetic field around it.  3DR deals with this issue by putting the sensitive elements, the GPS antenna and Magnometer, separate so it can be placed away from the battery.  In this case the GPS/Compass was bonded to the starboard-fore motor arm away from the battery.  This is a testimony to the excellent design of the FC as it did its job that close to a large battery.  Even though this worked, it is not recommended nor fully tested.
• The ESC have their heat sinks removed.  To ensure cooling, the ESCs were placed directly under the tips of the propellers to get positive prop wash.  The loss in lift is much lower than the loss in weight.  To help protect from shorts, spray the ESC with electrical silicone.
• Wiring in right sized.  The normal EE rule of 3% tolerated loss is put aside.  The rule is replaced by physics of electrical transmission.  A larger wire area cross-section  produces less heat that is measurable in watts.  And a larger wire area cross-section weighs more thus taking more watts to lift it.  Thus watt usage can be calculated for all wire sizes and thus optimized.  Some wire insulation is weak or can break down in sunlight.  Magnetic wire was used where possible.  But multi-wire strands are recommended to prevent wire breakage due to stress aging.
• Li-Ion batteries are about 50% more efficient (watts hours/gram) than LiPo for multi-rotor flight.
• Metal screws/nuts/washers replaced with nylon.  The only exception are the propeller screws which are aluminum.
• Metal screws/nuts/washers and clamps replaced by bonded parts.
• Gussets, screws/nuts/washers, and plates replaced by continuous masts and bonding.
• Metal spacers replaced by short nylon spacers.
• The most efficient propellers and motors were used – Tiger T-Motor.
• Props and motors statically and then dynamically balanced.

Ship Performance:

• Vibration Average Score               0.05 gs.
• Stability Score:                            0.14 degrees.
• Photography                                see test photos

Photo taken from tripod (baseline) with GoPro Hero 3+ at med 7m.

Photo taken from Rufous.  The camera was hard mounted, so now need to work on camera isolation that works.

Test Flight Highlights:  Prior to “Flight 1” the ship crashed three times. 

Crash 1 – Tried saving 2 grams by using Single Ply Carbon Skin Nomex core sandwich panels for motor mounts.  The Nomex core on one motor sheared causing a cascading event where all of the motors sheared.  Picture the ship moving away in an uncontrolled fashion with one motor suddenly floating away and quickly followed by the other three motors as the frame and battery kept flying in a deep descent.

Crash 2 – Really stupid piloting.  I cut power after a landing but forgot to disengage the motors (throttle lower left).  As I bent over the ship, my belly pressed the throttle to full and I got a face full.  Luckily wearing protective goggles and thick clothing.  Sometimes it takes a hard lesson to learn – always disengage the motors and the first thing one does when approaching the ship is to push the red button on the Pixhawk. 

Crash 3 – Had been suspicious of one motor mount bond (didn’t sand all surfaces on all the mounts).  The suspicions came true as one motor left the motor mast and the ship impaled itself into the lawn (photo below) after some high speed runs that loosened the faulty bond.  This crash broke one of the motor masts.  The motors are held on with nylon screws that are sized to shear off without harming the frame.  This works most of the time, but not this time.

Anyone interested in beating this record (the 100 minutes mark is itching to be broken), friend me and I'll gladly pass along what you need to do to satisfy Guinness.  I only ask that we are gentlemen and set records using engineering and piloting skill minimizing the use of ground lift (e.g., please avoid a hover off of a hot tar roof above a heated wall or on a side of a hill/ridge or in ground effect).  We want to show industry what is possible under normal flight conditions.  I also ask that you fully disclose your ship so we can all learn from what you achieved.  Thanks.

If you have any engineering questions, I'll will answer them below.

The forces of bureaucratic darkness have obliged us to relocate the planned launch of the Low Orbit Helium Assisted Navigator (LOHAN) mission to Spaceport America in New Mexico.

You can read the whole epic saga behind the decision right here, but suffice it to say we're heading down to Kickstarter next week to raise cash to cover the extra costs of finally getting the Vulture 2 in the air.

Have a look at the preview here and give us your thoughts. If you're interested in backing our audacious ballocket flight, you can sign up at the top of  preview for en email alert when the campaign kicks off.

We've been hard at work improving our popular NGB filter glass over the summer and the latest design is finally in! This design cuts off higher wavelength NIR light around 770nm. That reduces the amount of light crossing over to the Green and Blue channels which are also sensitive to NIR light, especially at higher wavelengths. The results are better than we could have expected! Check out my full post on Droneyard for more info: 

http://droneyard.com/2014/08/19/latest-vegetation-stress-filters-now-available/

Filters are available now, as are pre-converted and ready for flight SX260s and S100s with CHDK.

There are discounts available for resellers and OEMs, so please contact us before making an order!

And in addition to that, we're now offering the 20.3MP APS-C Samsung NX1100 as a regular option on the E384. The option includes a 20mm pancake lens and a hatch cover system to protect the lens for belly landings. More info on the NX1100 addition, including a sample mosaic, here.

Let me know what you think. We have lots of exciting projects in the pipeline to be announced shortly as well and we can't post everything here, so check out Droneyard.com for the latest!

Engineers at NASA's Langley Research Center in Hampton, Va., are studying the concept with models such as the unmanned aerial system GL-10 Greased Lightning. The GL-10, which has a 10-foot wingspan, recently flew successfully while tethered. Free-flight tests are planned in the fall of 2014.

http://www.nasa.gov/aero/testing-electric-propulsion.html#.U_VgeGNKiEf

I am the Sr. External Pilot on the Aerostar UAS. Here is a link the the article that the local news paper wrote about our program...

Here is the sUAS link.

http://www.suasnews.com/2014/08/30551/nmsu-faa-pursue-sought-after-drone-research/

Here is the local news paper link:

http://www.lcsun-news.com/las_cruces-news/ci_26318186/nmsu-drone-test-center

I'm delighted to announce that the effort to port ArduPilot to Linux reached an important milestone yesterday with the first flight of a fixed wing aircraft on a Linux based autopilot running ArduPilot.

As I mentioned in a previous blog post, we've been working on porting ArduPilot to Linux for a while now. There are lots of reasons for wanting to do this port, not least of which is that it is an interesting challenge!

For the test flight yesterday I used a PXF cape which is an add-on to a BeagleBoneBlack board which was designed by Philip Rowse from 3DRobotics. The PXF cape was designed as a development test platform for Linux based autopilots, and includes a rich array of sensors. It has 3 IMUs (a MPU6000, a MPU9250 and a LSM9DSO), plus two barometers (MS5611 on SPI and I2C), 3 I2C connectors for things like magnetometers and airspeed sensors plus a pile of UARTs, analog ports etc.

All of this sits on top of a BeagleBoneBlack, which is a widely used embedded Linux board with 512M ram, a 1GHz ARM CPU and 2 GByte of EMMC for storage. We're running the Debian Linux distribution on the BeagleBoneBlack, with a 3.8.13-PREEMPT kernel. The BBB also has a two nice co-processors called PRUs (programmable realtime units) which are ideal for timing critical tasks. In the flight yesterday we used one PRU for capturing PPM-SUM input from a R/C receiver, and the other PRU for PWM output to the aircrafts servos.

Summer of code project

The effort to port ArduPilot to Linux got a big boost a few months ago when we teamed up with Victor, Sid and Anuj from the BeaglePilot project as part of a Google Summer of Code project. Victor was sponsored by GSoC, while Sid and Anuj were sponsored as summer students in 3DRobotics. Together they have put a huge amount of effort in over the last few months, which culminated in the flight yesterday. The timing was perfect, as yesterday was also the day that student evaluations were due for the GSoc!

PXF on a SkyWalker

For the flight yesterday I used a 3DR SkyWalker, with the BBB+PXF replacing the usual Pixhawk. Because the port of ArduPilot to Linux used the AP_HAL hardware abstraction layer all of the hardware specific code is abstracted below the flight code, which meant I was able to fly the SkyWalker with exactly the same parameters loaded as I have previously used with the Pixhawk on the same plane.

For this flight we didn't use all of the sensors on the PXF however. Some issues with the build of the initial test boards meant that only the MPU9250 was fully functional, but that was quite sufficient. Future revisions of the PXF will fix up the other two IMUs, allowing us to gain the advantages of multiple IMUs (specifically it gains considerable robustness to accelerometer aliasing).

I also had a digital airspeed sensor (on I2C) and an external GPS/Compass combo to give the full set of sensors needed for good fixed wing flight.

Debugging at the field

As with any experimental hardware you have to expect some issues, and the PXF indeed showed up a problem when I arrived at the flying field. At home I don't get GPS lock due to my metal roof so I hadn't done much testing of the GPS and when I was doing pre-flight ground testing yesterday I found that I frequently lost the GPS. With a bit of work using valgrind and gdb I found the bug, and the GPS started to work correctly. It was an interesting bug in the UART layer in AP_HAL_Linux which also may affect the AP_HAL_PX4 code used on a Pixhawk (although with much more subtle effect), so it was an important fix, and really shows the development benefit of testing on multiple platforms.

After that issue was fixed the SkyWalker was launched, and as expected it flew perfectly, exactly as it would fly with any other ArduPilot based autopilot. There was quite a strong wind (about 15 knots, gusting to 20) which was a challenge for such a small foam plane, but it handled it nicely.

Lots more photos of the first flight are available here. Thanks to Darrell Burkey for braving a cold Canberra morning to come out and take some photos!

Next Steps

Now that we have ArduPilot on PXF flying nicely the next step is a test flight with a multi-copter (I'll probably use an Iris). I'm also looking forward to hearing about first flight reports from other groups working on porting ArduPilot to other Linux based boards, such as the NavIO.

This projects follows in the footsteps of quite a few existing autopilots that run on Linux, both open source and proprietary, including such well known projects as Paparrazi, the AR-Drone and many research autopilots at universities around the world. Having the abiity to run ArduPilot on Linux opens up some interesting possibilities for the ArduPilot project, including things like ROS integration, tightly integrated SLAM and lots of computationally intensive vision algorithms. I'm really looking forward to ArduPilot on Linux being widely available for everyone to try.

All of the code needed to fly ArduPilot on Linux is in the standard ArduPilot git repository.

Thanks

Many thanks to 3DRobotics for sponsoring the development of the PXF cape, and to Victor, Sid and Anuj for their efforts over the last few months! Special thanks to Philip Rowse for designing the board, and for putting up with lots of questions as we worked on the port, and to Craig Elder and Jeff Wurzbach for providing engineering support from the 3DR US offices.

We're obliged to Linus Penzlien (seen above in boffin pipe mode) and Andrew Tridgell for all their hard work last week working on the custom APM:Plane parameters/commands for our Vulture 2 spaceplane.

We were finally able to get the aircraft strapped to the van roof and out for a systems test, and to run the MAV_CMD_NAV_ASCEND_WAIT command, while makes control surfaces "wiggle" every X seconds. This is to prevent the servos freezing up as the Vulture 2 ascends to launch altitude.

The Pixhawk worked fine, and here's a fetching graph of GPS and airspeed sensor speed during our 20 minute test run:

We do, however, have battery issues, and we're certainly going to need more juice. Full details on the test run can be found right here.

Mark Wijnberg Land Surveyors recently completed an aerial survey of a river valley in a remote section of Western Uganda. The area is found on the Eastern slopes of the Rwenzori Mountains, close to the Congolese border. The purpose of the survey was to determine the feasibility of the construction of a hydro-power plant and its environmental and social implications. The survey area dimensions were approximately 7km by 3km and the altitude varied over 350m. Other specifications included orthoimagery, DTM of 0.25m spacing, 0.5m contours, a hydrographic survey of the river profile, installation of various benchmarks and all data represented on an AutoCAD drawing.

The terrain is very mountainous. It seemed to rain nearly every day which made climbing up steep muddy slopes exhausting. The jungle consisted of thick vines and dense vegetation. Much of the site is under cultivation of plantain, coffee and cassava. Many, if not all of the residents, had not encountered a white person before and many of the forest dwellers had never crossed the river to "civilization". There is no electricity, piped water nor sewerage for 100km.

Upon arrival in Uganda, we obtained permissions from the relevant authorities to gain access to the region. Without this permission, we were warned that if caught on this land, we would be assaulted by the army and questions asked only after we were dead! We sought council from local surveyors as to the best method of operation. Our first job was to establish a control coordinate system. As the closest markers giving a global reference system were approximately 2

00km away from the site over very rugged terrain, we decided to post process raw GPS data, collected at 10 second intervals over an 8 hour period. This task was done with a Leica GPS1200 receiver and then uploaded to Trimble RTX post processing option to derive an ITRF2008 coordinate. The results achieved were at 99% confidence level which was suitable for our survey. The coordinate system was also check against OPUS base stations over 3000km away which agreed to within a few centimeters. The orthometric levels were calculated using the EGM2008 geoid model. Once we had determined "where we were in the world", we could begin with the placing of the control benchmarks and measuring them as accurately as

 0.005m in all dimensions. The benchmarks consisted of 25 control points equally spaced over the site. These were time consuming to construct as our client insisted that they be 0.3m x 0.3m x 0.3m concrete blocks with a 0.5m iron bar inserted though the center. This necessitated us to hire local laborers to carry the 100kg of cement, aggregate and iron bars by foot though steep, slippery jungle. These benchmarks were also adopted for GCP for the aerial survey by placing whitewashed stones around the marks in a "T" fashion. A further 80 spot checks were made to check against the final product.

The client also required a survey of the river basin. The river averages 1m deep and flowed fairly fast. Over the 7km length, the total drop was 280m. These points were measured with GPS manually and we not only did a measurement of the channel depth at 15m intervals but we showed the channel sides and banks. This was a job that unfortunately the UAV could not measure as all points were under water. Areas that were densely vegetated we also surveyed manually as we needed to indicate the natural ground level. This required a lot of manual labor to cover this type of terrain. It is estimated that a total of 25km a day was walked with 1km vertically gained.

During the ground survey, a suitable site was searched for to launch and monitor the drone for the aerial survey. A school ground was found to be best suited for launch and landing. It also aligned well with the prevailing winds. It was noted that the winds blew every day from a South Easterly direction. The wind formed in strong gusts of 5 minutes followed by 20 minutes of calm. This is attributed to air rising of the Crater Lakes area rising up towards the Rwenzori Mountains. It was decided to do the survey early in the morning before the winds began. On the day of the flight, cool, calm and overcast conditions were experienced. The overcast conditions were appreciated as this reduced the contrasting effect of having strong sunlight causing shadows from elevated features. The residents of the valley were also asked to refrain from burning to reduce the smoke and haze during the proposed survey dates.

The UAV used is a 1.8m fixed wing, 2014 Skywalker frame with 2.6 APM, RFD900 long range radios, 10ah 4s battery. The camera used is a Canon S100 with an intervalometer script set to record a frame every 3 seconds. This was all kindly supplied by the gentlemen at event38.com. The flight plan was designed to accommodate a 75% sidelap and a 93% frontlap. The reasoning behind such a high sidelap was due to such large changes in elevation in the terrain. This was decided to best cover the location. The high front lap provided redundancy against those images that could not be used due to high rolling, blurring and banking shots. The total flight distance was 56km and the time taken from launch to landing was 1.3 hours. Landing was not as easy as previously thought as a large crowd had gathered shortly after the launch and refused to leave the landing strip upon the return of the UAV from its mission. The landing could best be described as "crowd surfing!"

A total of 1700 images were recorded. A few of these were discarded due to poor quality or non-vertical orientation. Despite the encountered haze, clear images were obtained. A brief overview of the images indicated that extra areas required manual survey to obtain a ground level for the clients final DTM. The images were processed using Agisoft Photoscan and then referenced using the control points previously recorded. These control marks appeared very clearly in the imagery and due to good planning, an even spread of control over the site strengthened the final image block. The maximum residual was found to be 0.03m over a 7km by 3km area. The spot checks manually measured compared very well to those reconstructed by photogrammetric means.

The final processing of the imagery to produce a 0.06m pixel orthophoto and a 0.2m DEM took an Intel i7 processor with 16GB of RAM 11 hours to render. The final image was cut into 500m x 500m blocks to reduce the images size for the client. The DEM was imported to ArcGIS. This allowed us to remove those points manually that did not fall part of the ground level and also those from the river surface. The manually surveyed GPS points were then inserted into the edited DEM and triangulated. This filled the DEM to give and smooth, seamless coverage of the site. Contours were generated to the required interval and checked against the imagery as a backdrop. The other features that formed part of the topographic survey such as dwellings, footpaths, limits of agriculture were digitized from the imagery and exported to CAD format with the contour information. From the measurements taken from the river, cross sections at certain strategic locations could be drawn as well as long sections detailing the fall over distance of the river.

In summary, this project combined both old and new worlds in terms of survey. The Ugandan surveyors that assisted us come from very challenging conditions where electricity is a luxury, and transport is dangerous if not impossible at the best of times. From comparing their typewriters to our laptops, their bicycles to our 4x4 vehicles, from their theodolite to our GPS, the usage of UAV must seem like something out of science fiction movie. The surveyors that we encountered and employed (often very well educated and experienced) were very excited by this new technology and were attracted especially by its seemingly affordability and ease of use. We estimate that this project would have taken us 0.5% of the time it would have taken to manually survey the entire region to the required detail. And even if traditional aerial survey methods were employed, it would push the cost far beyond the reaches of a simple feasibility study. The total time taken to produce the final goods has shocked our client who was expecting the final delivery to take place 3 months from the date of instruction. We managed to finish the project in 29 days. The UAV has again proved itself a very valuable and accurate weapon in the surveyor’s arsenal.

In our RC world, autopilots are typically some kind of software/hardware combination that is physically located on the craft flying/driving/sailing etc.. This has some disadvantages since autopilots are expensive and singular, meaning that they only know them selves and have no interaction capabilities with other autopilots.

As an example, a friend once asked me what it would take to make a drone that could analyse a large field of crops taking samples of soil were the vegetation was less eager to grow. My reply was “Two drones!” - one fixed wing to fly over the field, doing a flir/nir analysis - and one copter type to fly out, land, take samples and return them.

The operation had to be coordinated somehow - so the copter would know were to land etc…

In short - some problems are not solved using one single type of drone, but rather a combination of drones with different capabilities.

In the dungeons of my cellar, pilled with winter clothes, umbrellas, broken china and old lamps, I’ve been working on a universal autopilot system, that has a central computer system that is capable of guiding several drones and coordinate their activities. The main software can be executed on a very small computer ie. a raspberry pi or similar, or a laptop. The drones run a modified version of multiwii 2.2., that sends very compact telemetry data several times each second as well as being able to receive commands from the autopilot on the ground.

The idea is to keep the autopilot on the ground (or on a mother drone), and keep track, issuing flight directions using short and efficient telemetry data between drone and main computer. Several crafts can be controlled by the software at once, making multi drone missions possible and coordinating that drones do not collide.

Each drone uses a XRF (www.ciseco.co.uk) radio module to send back telemetry as well as receive orders on direction, speed, altitude etc… The XRF modules are great, very easy to use and setup and have a range up to 1.8 miles. Most serial transceivers are however usable.  

Each drone uses a multiwii board for stabilisation and serial communication, and a gps module so the central computer knows were the drones are at all times.

The autopilot software (running on the central computer) is controlled by a state machine, meaning that a system is making sure that everything happens in the correct order. For instance, that auto land is only possible after takeoff. Or that takeoff is not possible if the preflight sequence was unsuccessful or GPS lock has not been achieved. The state machine also makes sure that transitions between states are carried out correctly - ie. going from autopilot to manual flight makes the state machine automatically pause the autopilot function and set the craft on a straight path before control is set to manual.

The system is easy to extend for different craft types as well as different hardware.

The guidance part is based on the USAV project described some decades ago (so it seems) here.

Currently I have a simple system working, with one fixed wing, called the UTV-3, based on the Z84 from Zeta Science.

I’ve implemented some simple maneuvers as auto takeoff, auto land and simple waypoint navigation. Simple stuff that I use to test the system with. Once everything is stable, I’ll be implementing the multi drone hub, needed to coordinate the works of several drones. Although I work a lot in my dungeon, I’m also lucky to live close to a field for RC enthusiasts were practical testing can be done. Videos to come.

The two robots communicate their positions, converge to a common docking location and the dock successfully, both indoors and out.

From Robohub:

The video above demonstrates the use of a coordinated control strategy for autonomous docking of a Aeryon Scout UAV onto a skid-steer UGV (Unmanned Ground Vehicle) from Clearpath Robotics. The controller handles the nonlinearities inherent in the motions of the two vehicles, and is stable in the face of multi-second time delays, allowing unreliable wifi communication to be used in the landing. Both indoor and outdoor experiments demonstrate the validity of the approach, and also reveal the major disturbance caused by the ground effect when hovering over the ground vehicle.

For more information, you can read the paper Coordinated landing of a quadrotor on a skid-steered ground vehicle in the presence of time delays (John M. Daly, Yan Ma, Steven L. Waslander, Autonomous Robots – Springer US, July 2014) or ask questions below!

Hey fellow OpenTX users!

I've been procrastinating whilst writing up my thesis, at the end of finishing up a rather long Matlab script I thought wouldn't it be great to be able to use Matlab to generate and save SAPI5 voice packs for my favorite TX, the FrSky Taranis.

Starting off with an Excel spreadsheet containing a list of the text to be read, the directory structure and the file name, this was imported into Matlab 2010 x32 (yep, it is the 32bit version, I have only been able to find a x32 version of the dll required for this script to work, I simply don't have enough time to procrastinate long enough to write my own x64 version). Then set up a few variables and a small looping script to take the text, file name and directory, read out the text in your favourite voice flavour then save the files into a new folder.

The  script is as follows: 

% Set up the initial parameters

clear all;close all;

load('TaranisVoiceData.mat');
Fs   = 32000;
N     = 228;
R     = 2;
Voice = 3;
FileName = 2;
Directory = 1;
Speed = 0; %range goes from -5 to 5
Nbits = 16;

% Extract all words, file paths and file names

for R = 2:N
% the first one is a string
if R == 1
VoiceList{R-1,Voice} = cellstr(textdata(R,Voice)); % use this for cells that contain 'strings'
VoiceList{R-1,FileName} = cellstr(textdata(R,FileName)); 
VoiceList{R-1,Directory} = cellstr(textdata(R,Directory)); 
else
% the next 2 to 110 are numbers
if R >= 2
if R <= 110
VoiceList{R-1,Voice} = num2str(textdata{R,Voice}); % use this for cells that contain numbers
VoiceList{R-1,FileName} = num2str(textdata{R,FileName}); 
VoiceList{R-1,Directory} = num2str(textdata{R,Directory}); 
elseif R > 110
VoiceList{R-1,Voice} = num2str(textdata{R,Voice}); % use this for cells that contain numbers
VoiceList{R-1,FileName} = num2str(textdata{R,FileName}); 
VoiceList{R-1,Directory} = num2str(textdata{R,Directory}); 
end
end 
end
end

%% Now to convert the text into speech and save
Y=1;
for Y=1:N
if Y==227
break
end
VoiceTemp = VoiceList(Y,3);
w = tts(char(VoiceTemp),'VW Kate',Speed,Fs);

currentPath = pwd; % Get the current working directory
[~,~,~] = mkdir(strcat(currentPath,'\SOUNDS'),'EN'); % make a new directory to store the files in ../EN & ../EN/SYSTEM
[~,~,~] = mkdir(strcat(currentPath,'\SOUNDS\EN'),'SYSTEM'); % make a new directory to store the files in ../EN & ../EN/SYSTEM

currentPath = strcat(currentPath,'\',VoiceList{Y,Directory},'\',VoiceList{Y,FileName}); % get the full file path
SaveToHere = currentPath; % store full file path in temp variable
% Save the file
wavwrite(w,Fs,Nbits,currentPath);
Y %counter to monitor progress
end

________________________________________________________

The files are available here:

TaranisVoiceData.mat                     <- The data file which contains the filenames, paths and spoken text

taranis_voiceGen.m                         <- The Matlab file (REQ x32 version of Matlab, I used R2010B) RUN THIS ONE

Taranis%20HQ%20SOUNDS.rar  <- The outputs from the script

tts.m                                                     <- The TTS conversion script (REQUIRED)

Thanks to Siyi Dend who wrote the initial TTS script used in this release.

________________________________________________________

One last thing, to get a list of all the voices that you have available on your computer system just open up Matlab, open the working directory where you have saved the files downloaded from the section above, then in the console type in:

tts('','List'); 

Matlab will print out a list of all available voices on your PC. You can see in the script file I have used the 'VW Kate' SAPI5 voice pack, if you remove the 'VW Kate' and make it like this: 

w = tts(char(VoiceTemp),'',Speed,Fs);

the script will use the default terrible Microsoft Mike or Anna voice, which is rather deplorable, so jump online and Google free SAPI5 voices, there are plenty to be found. See the figure below for an example list.

So with all of that out of the way, I hope that this script may become of use to someone in the community.

Let me know if there are any bugs and I'll try to fix them when I get another opportunity to procrastinate =)

Cheers & happy flying,

L

The sUAS market for surveying applications are dominated by fixed-wing aircraft instead of multicopters. The reason is obvious, the multicopters have very short flight time and can not run long flight plans.

I'm not sure that this will go on for long. There are already many multicopters exceeding the hour and half flight time(only experimental flights without payload). Right now there is technology to stay one hour with a reasonable payload. Part of the "secret" is that the payload represents a small portion of the vehicle weight, which in practice is equivalent to using a larger multicopter.

The advantages of multicopters with respect to planes to do this kind of work where you have to move to an area where, almost certainly, you will not find a meadow of green grass is obviously the launch and recovery. Multirotors no need catapults, nor any parachute and not need landing strip, the roof of a vehicle can serve.

We are working on a very special model, it is a quadrotor with 1280mm diagonal for 27-29 inch propeller and a takeoff weight of about 12Kg. Though not proven, estimate flight time will be about 1 hour with 2 kg of payload.

Printing huge multicopters. All parts of this multicopter but arms and frame plates has been printed in PLA. it have about 112 hours of printing:

Pixhawk. Watch this! Pixhawk size compared to the frame:

(ADDED PICTURES 2-SEP-2014)

Best regards,

Jose Luis Cortes

Quaternium.es