Blogs

I'm happy to share with you today that this afternoon we had the first flight of a copter using ardupilot running in Linux (the evolution of the work performed this summer through the BeaglePilot project on the ardupilot code). It's particularly a pleasure for me to share these news because it's the result of two years trying to fly a copter running Linux (without a companion computer).

https://www.youtube.com/watch?v=HyHQpS8XwT0&feature=youtu.be

And a second one:

https://www.youtube.com/watch?v=BJud5CaxtqE&list=UUZroM1rZYmQQWCt3DOPcHmA

Setup has been done using 3DR Iris and a lot of tape (the Linux board is actually slightly bigger than the PX4 thereby there was no room inside of the hood for it).

Some remarks:

• The autopilot was running at 100 Hz but we are working on a version that runs at 400 Hz.
• It was using only one of the three IMUs included in the autopilot. Using the three of them might lead to a more stable result.
• We have now the three vehicles working on Linux!
• Take in account that i'm a horrible pilot (working on that while i write code ;) )

Future steps:

• BeaglePilot white paper (WIP)
• More work on the AP_HAL_Linux and the Linux kernel
• Flight tests

Regarding the flight tests, i'd like to point out the fantastic attitude that 3DR has had with us, developers, providing all the hardware needed. Hope this serves as an inspiration for other manufacturers.

This work is the result of the effort of many. Particularly the ardupilot dev team, Siddharth Bharat Purohit, Andrew Tridgell and Philip Rowse. It's been fun to walk this path with all of them and down the road it seems there's more ;).

Special thanks to Hugo Boyer for the recordings.

NOTE: The blog post has been renamed from "APM4.0:First copter flight" to "First copter flight using Linux". Thanks for the users that suggested it.

From IEEE Spectrum:

Airspace above 500 feet is already well regulated by the FAA, but there's a potentially dangerous void that's about to get really crowded between 500 feet and either your skull or the ground, whichever comes first. At NASA's Ames Research Center in Moffett Field, Calif., in the heart of Silicon Valley, NASA engineers and researchers are working on a way to manage that void, and the system they're trying to put in place would help out small autonomous aircraft in a number of ways:

Airspace Restrictions: For manned airplanes, a lot of what air traffic control is all about is telling you where you can't go, as opposed to where you can. Especially around airports, airspace is heavily restricted over a succession of increasing altitudes, and whenever there are special air operations in place (like around air shows or forest fires), special no-fly zones pop up. Autonomous drones (and piloted ones, for that matter) will have to dynamically adapt to, and respect, airspace rules that may change rapidly. And for drones operating close to the ground, restricted airspace would, when possible, also include obvious stuff that you wouldn't want to run into, like buildings.

Flight Corridors: I don't think that we're going to see the sort of drone delivery that Amazon is promising within the next few years, and it sounds like Google doesn't either, with the company suggesting that it might be "a few years but less than a decade" before consumers see any tangible uses from the technology. My guess is that the first time we'll see delivery drones doing anything useful will be dedicated point-to-point service, where the landing areas can be carefully defined and controlled. That solves a huge amount of the problems that we identified with delivery drones, but it still leaves the issues with actually flying around: namely, running into stuff. Having established flight corridors would allow delivery drone operators to carefully define and control flight paths as well, ensuring that there are no obstacles or other aircraft for the drones to smash into.

Operating Areas: NASA suggests that we might start seeing drones for agricultural monitoring and inspections in about a year or so. It would be handy, and safe, to be able to schedule a time and an area where you want a drone to fly around doing work, with some amount of confidence that you wouldn't be bothered.

Again, we want to stress that the eventual adoption of a system like this would be fantastic for small autonomous drones, and it will likely also be necessary for their safe long-term commercial use, including delivery drones as proposed by Google and Amazon. But it's not going to solve every problem that they have, and companies like Amazon and Google have a lot ofmaaaaaybe impossible work to do before they'll be dropping packages off on your doorstep.

Via [ New York Times ]

COMPONENTS

• 1×30 HP vertical shaft gas engineShould equipped with a starter and alternator
• 4×Center Beams ( 2 1/2" x 1 1/2" x 39 3/4")Galvanized Slotted Angle
• 4×Side Beams ( 2 1/2" x 1 1/2" x 29 1/4" )Galvanized Slotted Angle
• 4×Cross Beams ( 2 1/2" x 1 1/2" x 30" )Galvanized Slotted Angle
• 4×End Beams ( 2 1/2" x 1 1/2" x 18" )Galvanized Slotted Angle
• 8×Outer Prop Supports ( 1 1/2" x 1 1/2" x 30 3/4" )Galvanized Slotted Angle
• 4×Inner Prop Supports - Fore ( 1 1/2" x 1 1/2" x 28 1/4" )Galvanized Slotted Angle
• 4×Inner Prop Supports - Aft ( 1 1/2" x 1 1/2" x 32 1/4" )Galvanized Slotted Angle
• 8×Shaft Mounts - ( 2 1/2" x 1 1/2" x 6")Galvanized Slotted Angle
• 4×End Cross Bars ( 1 1/2" x 1/16" x 18" )Galvanized Slotted Bar

See all components

How-to launch an arduplane (XUAV Talon) ?

Introduction:

A XUAV Talon is a relatively heavy airframe (between 2,5 and 3Kg depending on its configuration) to launch. Other EPP/EPO FPV large airframes come in the same weight category. So, how to launch/take-off with such large/heavy UAV planes ?

There are three ways, that I know of, to take-off :

• Hand launching,

 -requires two people : one keeping both hands on his Tx control sticks; the other one throwing the plane in the air.  A two man operation is not always convenient nor possible on the field.

-it is dangerous : the propeller might shred the launcher's hand...

-launch is not systematically succesful as the plane is not systematically thrown correctly (angles, strength)

• Roling the plane on a runway up to take-off speed, 

-requires a runway, long enough & flat. Not really like that in real fields.

-requires wheels on the front, back (or wings) and a steering system : not available on all planes such as the XUAV Talon.

• A catapult launch system

-requires a cheap, reliable, transportable system

-requires enough catapult launch force to handle +3kg planes

The catapult build published hereunder attempts to be a synthesis of lots of ideas and information found on diydrones, rcgroups forum & rc experts youtube videos.

This catapult system is a built intended and tested to launch a XUAV Talon, i.e. a large 2 m wingspan FPV plane (wing extensions) in the 3kg weight category.

This guide first describes the parts and assembly steps; then a result video of (succesful) field tests is shown at the end.

Catapult's parts list & Assembly steps:

The list of parts is shown herebelow:

Cables/ropes setup:

Two types of ropes are required. An elastic rope (a sandow) will provide the force to catapult the plane. A second non elastic nylon rope (or any other strong enough rope) will pull the plane (via a hook fixed on the plane, see further) and will be used to trigger the elastic sandow.

The sandow is shown herebelow:

On one side of the 10 m sandow is a loop that will be fixed on the ground by a (very strong) tent hook. On the other end, the sandow attaches to the nylon rope.

The nylon rope part is shown below:

On one end the nylon rope is attached to the sandow as shown below:

On the other end the nylon rope ends with a loop that will be fixed on the ground with a (very strong) tent hook. This last extremity will be released to trigger the elastic (see further).

At about 3 meters from the sandow-nylon rope junction, a Y is formed : a one meter nylon rope piece and a piece of about 5 meters. The one meter piece ends with a loop that will be attached on the plane's hook. This is the piece that will pull the plane out of the catapult. The other (5m long) piece will act as the trigger (when released from its ground retaining tent hook).

Catapult structure setup:

The catapult body is assembled with PVC tubing. These PVC tubes must be large enough to support the weight of the plane; therefore a suggested minimum diameter of 35 mm.

The longest tube part is about 150 cm; therefore three 2 meters long tubes are enough for the build.

The tubes are glued together, as show on pictures below. Two types of PVC junctions are used : T's and 90 degree angle,

The length of the front and back "legs" of the catapult are chosen so that the launch angle is not too steep and smaller than 45 degrees. The resulting angle with these given dimensions is about 30 degrees max.

The plane, when pulled by the rope, will glide on the two top PVC tubes. The plane wings would get ripped if gliding on the two 90 degree PVC connectors; they must therefore be trimmed, as shown below:

To adjust easily the width of the two left/right catapult rails, a metal bar (of smaller diameter than the inner PVC tube diameter) is inserted horizontally inside/between the two front legs,

XUAV plane setup on the catapult launch system:

The plane left and right wings sit on top of the catapult PVC left/right PVC rails:

The sandow and rope are fixed like this:

This is where the fishing hand scale is used : the sandow must be streched to provide an elastic force of about 5 times the plane's weight. So for a 3kg XUAV Talon, the sandow must be streched to provide 15Kg of force.

To measure this, the sandow extremity is first fixed to a point in the ground with a tent's hook. The other end of the nylon rope assembly is attached to the scale hook; then pulled until 5x the weight is read on the scale. This gives the position where the nylon rope will be released to trigger the sandow (cf video below for a visualization of this explanation).

The 1m nylon rope section (forming a Y junction), attaches to the plane, on the plane's bottom hook. This one meter section must also be kept in a streched state when launching.

The plane's hook must be strongly secured so as not to be ripped off when releasing the sandow brutal force. This cannot be fixed on foam only; it needs plywood or aluminium reinforcements. On the XUAV Talon, the optional plywood landing gear base is used to securely fix an aluminium hook:

The hook must be placed slightly in front of the CG line of the plane. On the XUAV Talon, the CG line is located at about the servo wires position on the wings (see picture).

If the hook is not located right, the plane will not be pulled right and will eventually flip to the sides or upside down.

The results in video

Cheers,

Hugues

I needed an easy way to access data from the PX4Flow sensor using Python, so I wrote this little package, which you can download from github. It runs on Windows, Linux, and OS X in Python 2 and 3. As with the other Python packages I've written, the API is very simple.  I'm hoping that this package will enable students, hobbyists, and others to use the PX4Flow for cool projects on MAVs and other robots.

One thing I could use some help with is the MAVLink parsing.  I looked over pymavlink and was unable to find a class that I could subclass or include to do what I needed, so I wrote my own little parser.  Among other shortcomings, this meant that I was unable to to checksum validation (again, I looked over the checksum code in pymavlink and was unable to figure out how to use it.)  So if anyone wants to modify the code on github, let me know, and I'll add you as a developer. 

Setting up our Ground Control Points (GCPs) to improve the precision of the imagery. In the background, one of the Seven Wonders of the Ancient World: The Temple of Artemis in Ephesus, Turkey.

It isn’t every day that we get to fly drones over one of the Seven Wonders of the Ancient World. Thanks to our intrepid partners and hosts, the Institute of Fine Arts at New York University (NYU) and the Austrian Archaeological Institute, we’ve just returned from an amazing week in Southern Turkey where we flew over ancient theatres and temples dating as far back as the 10th Century BC. We’ll be publishing a longer, more detailed blog post once we’ve had the chance to analyze all the imagery. In the meantime, we’re excited to share a quick overview of the project.

Read more about our Drone Adventures Expedition here! 

(Includes our video interview with archaeologists) 

August 18 – 25, 2014, in the Cévennes and Gévaudan (France). Episode #1 

The episode one on youtube

I am Benoit Pereira da Silva, 42 years old, and I'm a software author and an independent mobile consultant. Since July 2013.i work while walking 3 km/h on a treadmill. I “travel” on average 100 to 120 km per week while doing tasks. After working this way and going more than 5000 km in a year, I decided to walk outside and take on the roads, valleys, mountains, and landscapes that are all around. 

From August 18 – 25, with Nino (my son, who is 13 and a half years old) who has gone along with me on this adventure, we have been walking in the Cévennes and Gévaudan, with a prototype of a mobile desk using self-sufficient energy. We have camped and used the energy produced by the solar cart that I’ll be tugging along.

The episode #1 presents the device :

I have designed, and developed a suspended aluminum desk with a backpack. In addition to various gadgets, this desk has a computer, a phone, a solar "monitoring" system, a battery charger for the drone, and some storage space. 

Below the “shelf," I have a place to attach the drone and its camera when it isn't flying. 

The cart supports two solar panels (1.20 m by 1.10 m) that are likely to produce 200 w at full capacity. In addition, it contains the tent and some small camping equipment, a backup battery, and associated control electronics. 

Resources :

Timeline : http://walkingworking.com/md2014
Via twitter : https://twitter.com/bpereiradasilva
Google + : https://plus.google.com/+BenoitPereir...

Sponsors: 

• Withings designs and develops intelligent devices for health, activity, and well-being: an activity tracker, a watch and connected scales, sleep products, a wireless blood pressure monitor, and applications.http://withings.com
• Escadrone: Images using drones and photogrammetry services. http://escadrone.com

Many folks are going to be horrified at that price, but I look at it as less than autopilots cost back in the day. I think these will fly off the shelf for professional end users. Moores law seems not to apply to unmanned aviation, its too slow.

“Velodyne’s LiDAR Puck has the potential to be truly transformational, an enabling technology for a vast array of price-sensitive applications,” Hall said. “The introductory pricing of $7,999 for this next-generation LiDAR sensor makes choosing the ‘Puck’ a total no brainer for any automation or robotics application requiring timely 3D vision.

There’s no longer any need to go through the hassle of combining several 2D sensors or mount one 2D sensor on a ‘nodding’ platform, now that one 3D sensor can do the job conveniently and at an even lower price point than multiple 2D sensors.”

Full press release

Wolfgang speaking about Velodyne at sUSB Expo 14

Our Vulture 2 spaceplane has been taken apart and reassembled for the last time, principally to allow us to cram in extra batteries for the servos.

We're powering the servos from eight AA Energizer Ultimate Lithiums, via a Castle Creation BEC. This separates the Pixhawk power supply, and the autopilot now runs off its own four pack of the same batteries.

As you can see above, we've also installed the RFD 900u Radio Modem and antenna, so we're good to go for long-range comms.

It just remains for us to fire the whole thing up and check that we now have enough juice to run the servos for the entire mission. We have no doubt we've got it covered.

There are full details on the mods here.

Down at Kickstarter, meanwhile, we're nudging £20,000 of our £30,000 target to launch the Low Orbit Helium Assisted Navigator (LOHAN) mission from Spaceport America. If you fancy chipping in a few bucks to the cause, we've got a range of tempting rewards available for backers.

Congratulations to Giovanni Durso, whose Pixhawk-powered autonomous recharging system is a finalist for The Hackaday Prize

My system attaches to the bottom of current apm systems and allows them to land on a user defined target (example targets provided) and when equipped with the supplementary electronics allows for recharging 

This means that the copter is now capable of performing multiple missions and if combined with a ground vehicle it can be used as an extension of the ground robots capabilities thus creating a multi robot system 

Example applications are 
-surveillance 
multiple copters watching an area 
-environmental surveying 
Can do mapping or remote sensing over a longer period due to recharge 
if with agv it can move around the environment and perform a multitude of missions 
-extending current agv operations 
Aerial mapping / complimentary sensors 
-improved aerial photography 
capable of tracking a target 

DETAILS

The cheap small GPS used on hobby UAVS are only accurate to +-5m and traditional landing systems simply move the copter to a predefined GPS location and slowly lower the craft hoping that there is nothing in the way and that the position is where you started. This is nowhere near accurate enough to allow the copters to dock and thus recharge themselves. Normally a human operator is required to move the copter from the landing site to a place where it can be recharged. This limits mission operation and requires a human operator to be physically present.

Utilizing recent advances in low power high performance computing and computer vision techniques my system will allow the copter to dock, recharge itself and when finished fly off again and continue its mission thus partially compensating for the poor endurance of multirotors.

Todo

- Design testing platform [DONE]

- Build testing platform [DONE]

- Test flightworthyness of platform [DONE]

- Design recharging electronics

- Design vision software for landing [DONE]

- Test integration of vision system with paltform

COMPONENTS

• 1×Hexacopter
• 1×Odroid u3 computer
• 1×Pixhawk autopilot
• 1×Usb webcam

We have been working hard to get Droneshare out of beta, and are pleased to share that we are almost ready to call it V1. We are wrapping up a few things including mission discovery, filtered searches, and making flight uploads easier.

Interesting milestones since our last update:

• Over 15,000 flights uploaded (a combination of public and private flights)
• Upload support is now built into Droidplanner, APM Planner and Mission Planner
• Dataflash (binary or text) logs are now supported (in addition to the original tlogs)
• Andrew Chapman’s LogAnalyzer tool is now integrated for analyzing Dataflash log files looking for common problems
• A “movie” button provides a first person visualization of flights
• Live vehicle tracking & control is now in alpha testing

Here is a sneak peek:

We have received a lot of great input on ways to improve Droneshare, thank you for your feedback! We are excited to focus on the next version. Here are some things we have in mind:

• Better plotting control and better plotting UI
• Airspace warnings
• More polished design ( possibly with better tablet integration )

Before we get started on our next version, we would love to learn more about how and why you use Droneshare, and gather your thoughts on features you would like to see. To keep everyone’s thoughts in an organized fashion, we have created a survey that will help us decide how to move forward based on your needs.

We would also like to take this opportunity to thank Mapbox and Doarama for providing us with awesome open source mapping and and visualizations that make Droneshare better.

Help us make Droneshare even better, ways to help:

• Answering our short survey: https://docs.google.com/forms/d/1nEF3VrLQ0VdEDunWwt-GGvD1cVPWvlUefAy20lGqxUM/viewform

• Using or extending our project source code: https://github.com/diydrones/droneshare

• Found a bug? feel like a feature is missing? help us by creating a ticket: https://github.com/diydrones/droneshare/issues

• Uploading your missions Droneshare: http://www.droneshare.com/

As outlined in this early post by Hai Tran, it has been reported that Australian based UAV manufacturer Cyber Technology found themselves in a spot of bother with the Australian Customs and Border Protection Service when they attempted to export UAVs out of the country on two occasions.

Excerpts from itnews.com.au describe the two incidents:

"The shipment was opened and found to contain two 'CyberQuad' mini Unmanned Aerial Vehicles (UAV), two low light CCD cameras, two hand held UAV controllers, two pairs of video glasses, one power management system with four batteries, two chargers, one mains power supply, two portable video terminals and one rugged Pelican brand transportable case" a spokesman said.

and

Just one month later, a Cyber Technology employee was caught trying to travel overseas with the goods in their baggage

It is obviously no surprise to learn that there are export controls for products relevant to defence applications here in Australia, but it seemed unclear to me where the line is drawn.  What is export controlled and what isn't?  Where is the line between RC Model aircraft, Civilian focused Remotely Piloted Aerial System and Military Hardware?  How does a company or individual interested only in recreational and civilian use of UAVs steer clear of such restrictions?  Is it even possible?

Most of us would be aware of complications faced by US based companies, like 3DR and sparkfun, navigating export restrictions. Export restrictions don't appear to be limited to RTF systems either, with basic and seemingly harmless items like stepper motor controllers which are designed for laughably innocuous things like egg painters apparently affected also.  Yet there appears to be no restriction on things like this, which doesn't seem to make sense?  And what about kickstarter campaigns like the Pocket Drone, Hexo+ and AirDog, and their 5,000-odd backers? How export restrictions will impact on the fulfilment of rewards to backers of these campaigns remains to be seen. Each of these campaigns are international, and it appears that no warnings or disclaimers have been publically issued to backers referring to potential export restrictions. It seems reasonable to assume that there would be a quantity of backers based in countries that may not necessarily be on the unrestricted list (which can be found by clicking on the top left of this page).  The Pocket Drone for example remains yet to ship, but is being assembled in the US. It seems logical that AirDroids would have a plan to ensure fulfilment of all relevant rewards, as refunding dozens, possibly hundreds of backers could cost them heavily - especially when you consider the commission taken by Kickstarter (I wonder whether that gets refunded in the case of a refund in the event that a reward is unfulfillable). Perhaps they plan to fill a container, ship it to Hong Kong and distribute to their backers from there. It seems unlikely, but that would certainly be a laugh if they were forced to do so (but an interesting example of the great lengths a company might be forced to go to create jobs in the US)!

When comparing the above examples of export restricted products in the US with the products offered by Cyper Technology, there are obviously some distinct differences.  Cyper Technology offer 4 different complete aerial systems, each of which are uniquely developed for use in specific applications.

The CyperQuad is a quad copter which is optimised for carrying a range of payload options.  It specifically lists a range of Military uses among it's intended applications - which include Urban Surveillance, Over the hill reconnaissance, communications relay node as well as Mine Detection and target detection.  But it's list of intended use applications also includes recreational uses including aerial photography and FPV.

The CyperEyeII is a medium range endurance (long endurance by our standards) unmanned platform that is designed to carry a payload up to 20kg for up to 10 hours. It's capabilities are quite advanced and it lists both military and civilian uses, but no recreational uses.

Then there is the CyBird and CyberWraith, which are both aimed solely at defence specific applications.

Looking at these systems as a group, and Cyper Technology as a company, no one would argue the relevance of export control. The same can be said about many of the big players like Advanced VTOL Technologies, VTOL Aerospace, Codarra Advanced Systems, Unmanned Systems Australia and Aerosonde. But what about other manufacturers which blur the line like the Flamingo from Silvertone, or those focused squarely on the civilian market like the Scarab series from MuiltiWiiCopter, the GoFour from Aerobot or the original Mini H Quad from Blackout?  Where is the line draw? Or is it all export controlled?  Does this affect all manufacturers and resellers?  And how onerous is the current permit process?

The DSGL (Defence and Strategic Goods List) Categories lists UAVs under Part 2 of the categories list. As identified by Robert Palmer, the definition for what is controlled can be found in section 9A012 on page 246 of the Defence and Strategic Goods List Amendment 2011 (No. 1) - F2013C00051.

9A012 "Unmanned aerial vehicles" ("UAVs"), associated systems, equipment and components, as follows:

a. "UAVs" having any of the following:
                1. An autonomous flight control and navigation capability (e.g., an autopilot with an Inertial Navigation System); or
                2. Capability of controlled-flight out of the direct vision range involving a human operator (e.g., televisual remote control);

b. Associated systems, equipment and components, as follows:
                1. Equipment specially designed for remotely controlling the "UAVs" specified in 9A012.a.;
                2. Systems for navigation, attitude, guidance or control, other than those specified in 7A and specially designed to provide autonomous flight control or navigation capability to "UAVs" specified in 9A012.a.;
                3. Equipment and components, specially designed to convert a manned "aircraft" to a "UAV" specified in 9A012.a.;
                4. Air breathing reciprocating or rotary internal combustion type engines, specially designed or modified to propel "UAVs" at altitudes above 50,000 feet (15,240 metres).

The DSGL also specifically identifies a long list of other items relevant to DIYDroners in the Dual Use Goods section including radio equipment, telemetry and telecontrol equipment, magnetometers, accelerometers, inertial navigation systems, flight control systems and robots. Additional notes stipulate that materials, software and technology related to controlled goods are also controlled.

By these definitions it seems that any APM or FPV equipped aerial system would be affected - including a 400g 230mm mini quad.  The same could be said of an unpowered slope soarer with a 5.8Ghz 25mW video transmitter.  Or a Lego NXT kids toy, any comparable item, or just about any part thereof.

So, could some of us in the DIYDrones community find ourselves in trouble with the law as a result of this law?

As the issues experienced by Cyber Technology with their CyberQuad demonstrate, the definition of export certainly includes travelling with the item.  Like Lachy Goshi, I would love to take one of my smaller aerial systems with me on my next holiday to southeast Asia, but the idea that I might run foul of the Australian Customs Act or Criminal Code on the way out, or on the way into a foreign country (say at Phuket International, for example) is a bit of a worry.  Hai Tran rightfully points out just how unsettling it is to think that, even as end users, we could find ourselves in hot water if we are not careful. This is especially concerning when the maximum penalties are so incredibly high. Like Ben Dellar, I am keen to know more.

It seems that no matter whether you are a developer, a manufacturer, a reseller or simply an operator or end user, or where in the world you are based, it might well be worth taking a closer look at how these laws might affect you in your jurisdiction.

Hello the DIYDrones community!

Thank you very much for your interest in our software. Since last news about support of DJI Phantom 2 our ranks of Beta testers have exploded!

Here we would like to present to you teaser of upcoming version of UgCS 2.0.

To those who have stumbled upon us for the first time we support not just DJI, but numerous other autopilots like: 3DR APM/Pixhawk, ArDrone, PixHawk, Mikrokopter, DJI autopilots, UNAV, Microdrones. You can sign up for beta testing by registering at www.ugcs.com!

Thank you and have a good flights!

Best regards,

UgCS Team

Source: http://www.cybertechuav.com.au/IMG/rubon13.png

http://www.itnews.com.au/News/391585,customs-seizes-80k-worth-of-unauthorised-drones.aspx

Unlike the Civil Aviation definition of UAV v Model Aircraft being Commercial v Hobby use, the Defence and Strategic Goods list (http://www.comlaw.gov.au/Details/F2013C00051/Html/Text#_Toc345675289)  defines a UAV as any unmanned aircraft that has an autopilot OR can fly beyond line of sight. 

Feeling very nervous after reading the article above because you could get into alot of trouble traveling with your Arducopter or Arduplane.

One might think "surely my quad isn't covered under export control" but whilst the CyberQuad looks like quite an impressive aircraft, under the hood, it's an off the shelf flight controller that you can buy from a hobby shop.

Terrorist obviously don't have the brains to buy drone parts from China and assemble it themselves.

David Scaramuzza from ETH writes: "In this video, we show our autonomous quadrotor acting as a flying 3D scanner. At the end of the video, the quadrotor guides a ground robot to grasp an object."

It's a big round of applause today for Billy Bargaliotti, who's wrapped our Vulture 2 spaceplane X-Plane models just as we've topped £18,000 on our Kickstarter campaign to get the aircraft off the ground at Spaceport America.

Billy created four models - two for mission simulations with solid rocket booster, and two "trainer" models for a less hair-raising ride. Here's the Vulture swooping down on the New Mexico spaceport...

...and on final approach:

There's more on Billy and the models here, and you can download them here, with explanatory notes. If you can spare a few bucks on Kickstarter, you'll help us to see how the above views look in reality.

Hi guys, Here is my latest experiment using my QR X350 Pro, SJ4000 and Autodesk ReCap to create a 3D photomesh of a nearby quarry wall. For more info on the mission visit my blog www.theaeroscout.com.au

From Gizmag:

The prospect of delivery drones brings with it a few notable issues. Beyond visions of colliding rotor blades and unsolicited package drops lies another problem: the huge amount of computational power needed to take into account real world uncertainties, such as strong winds, limited battery life and navigational errors, in order to provide a reliable delivery service. This has been the focus of new study from MIT, with a team of researchers devising a new algorithm said to massively reduce the level of computation required, enabling the drone to monitor its "health" in real time.

There was no shortage of skepticism when Amazon announced its plans forPrime Air last year. Ambitious though it may be, research efforts from MIT and others indicate that the world's largest e-tailer is not exactly flying solo in its bid to establish drones as the basis for a viable courier service.

"With something like package delivery, which needs to be done persistently over hours, you need to take into account the health of the system," says Ali-akbar Agha-mohammadi, a postdoc in MIT’s Department of Aeronautics and Astronautics. "Interestingly, in our simulations, we found that, even in harsh environments, out of 100 drones, we only had a few failures."

Agha-mohammadi and his team developed a two-step approach as a way of simplifying the computational processes performed by the drone. The first focused on vehicle-level planning, which involves the drone mapping its path off-line ahead of time. The second part relates to the vehicle's health planning, such as monitoring the condition of propellers, cameras and fuel levels on-the-fly.

In comparison to another technique for planning an autonomous vehicle's course called Markov Decision Process (MDP), the new approach is designed to significantly reduce the enormous amount of navigational outcomes which can arise from various factors, such as strong winds and errors in measurement. The team was able to narrow the number of outcomes down to a few that were most likely by having the drone map out the environment offline prior to departure. This frees up computational energy that can be put toward real-time monitoring.

"Imagine a huge tree of possibilities, and a large chunk of leaves collapses to one leaf, and you end up with maybe 10 leaves instead of a million leaves," Agha-mohammadi says. "Then you can … let this run offline for say, half an hour, and map a large environment, and accurately predict the collision and failure probabilities on different routes."

In testing the new algorithm, the team ran simulations where drones delivered several packages to various addresses. Needing to overcome differing wind conditions and limited fuel, the drones working with the two-part algorithm were better at preserving their health than the regular drones, autonomously re-routing to a refueling station, for example. While this led to a higher number diversions, over time, they delivered as many packages as non-health monitoring drones with far fewer breakdowns or failures.

This new found reliability could be integral to future drone delivery systems Agha-mohammadi claims, with an emphasis on preserving drone health potentially leading to a safer and more dependable service.

"We believe in the near future, in a lab setting, we can show what we’re gaining with this framework by delivering as many packages as we can while preserving health," he says. "Not only the drone, but the package might be important, and if you fail, it could be a big loss."

The team has now fitted electromagnets to drones, enabling them to pick up and drop off packages, with the intention of testing the route-planning approach in actual experiments. The team has also programmed the drones to land on custom-built recharge stations.

Agha-mohammadi will present the approach at the IEEE/RSJ International Conference on Intelligent Robots and Systems, being held in Chicago in September.

The team's research paper can be found here.

Source: MIT

From the Parrot blog:

Few weeks ago, we were talking about this german developer who created a software to control the AR.Drone 2.0 with the Oculus Rift. With our forthcoming Parrot Bebop Drone, FPV flights will become reality and accessible for everyone. 

Parrot Bebop Drone Extended Range, equipped with the powerful remote Parrot Skycontroller you will be able to connect the majority of FPV headsets available on the market: Oculus Rift, Zeiss Cinemizer, Google glass… as long as these glasses have an HDMI output.
Technically, the full HD video stream coming from Parrot Bebop Drone camera is transmitted through Wi-Fi to the Skycontroller which convert the image into a digital format that can be read in real time by the FPV headset.

Be the eye of the drone:

For an even more immersive feeling, the orientation of the fisheye (180 °) camera of the Bebop Drone can be controlled by your head movements through a technology called ‘Headtracking’, only available with Oculus Rift. 

Achieve Icarus’ Dream or your first OBE (Out of Body Experience) with Parrot Bebop Drone ! 

The first tests :

Kyle Tarpley (YouTuber, host the AR.Drone Show) trying for the first time FPV with Bebop Drone

Josh Bixler and Dave Knop from Flitetest flying Bebop Drone with Rift. See their first impression in their preview video test. 

PyQuadSim is a Python program that allows you to fly a simulated quadrotor miniature aerial vehicle (MAV) from a variety of controllers (joystick, R/C transmitter, PS3 controller).

You can modify the source code to add new sensors and other features, as well as configuring the simulated environment for different kinds of missions.

PyQuadSim uses the powerful Virtual Robot Experimentation Platform (V-REP), but does not require programming in Lua or writing a plugin in C++.

I thought some of y'all might find this useful:  http://home.wlu.edu/~levys/software/pyquadsim/

Comments welcome!