Blogs

Hi this is Iñigo, one the of the engineers behind Erle-Robotics. I would like to share with you that we have integrated ubleds in our Erle-Brain.

Thanks to this, users can easily identify autopilot's state. We have differentiate few ones:

- Blinking blue to signal that autopilot is initializing.

- Blinking red to indicate that autopilot is disarmed.

- When autopilot is armed with GPS signal, the status LEDs turns into blue color.

- Finally, when autopilot is armed without GPS signal, the status leds, switches between blue and green colors.

Check our yesterdays flight:

https://www.youtube.com/watch?x-yt-ts=1421782837&x-yt-cl=84359240&feature=player_embedded&v=GHeZ_jrA8lg

For more info, check the post in our website.

Cheers!

How a simple, DIY-inspired design helped create the worlds most dangerous flying corps.

    When World War 1 came to an end in 1918, the victorious allies took care to heavily restrict the military development of powered flight in the Treaty of Versailles.  It wasn't long however, until the land of the Red Baron discovered a loophole wherein the treaty overlooked the use of unpowered flight as a military training tool. The resulting training regime used a brilliantly simple design called a Schulgleiter(English: School glider) and arguably produced the finest airmen in all of WWII (at least when evaluating individual skills alone...). 

     For a regime better known for engineering achievements like the ME-262 (the world's first jet fighter),  than for inspired design practices as those that produced Russia's T-34 Tank or Britain's plywood Mosquito Bomber, the Schulgleiter is truly extraordinary.  Officially designated the DFS-SG-38 Schulgleiter, the craft had a simple stick for steering, foot pedals for flaps and little else.

  The gliders would be launched by a giant bungee chord on a mountain known as the Wasserkuppe where gentle slopes and perfect tailwinds make it the heart of German aviation to this very day.  The following image shows a Schulgleiter in mid-launch position, and the 1940 vintage training video shows how the process worked.

  With such ideal flight conditions, the SchulGleiter was far from the only aircraft developed at the Wasserkuppe, nor was it the only advance in unpowered flight at the time.  The Horten Brothers are best known for developing the Ho-229. A jet-powered, Flying Wing with characteristics so far ahead of its time, that Northrop Grumman, designers of the B2 Stealth bomber, famously constructed a replica for the purposes of testing its stealth characteristics.

  While the Ho-229 has attracted a sizable following of aircraft modelers and enthusiasts, less attention has focused on the fact that such a high-tech marvel is almost entirely derived from seemingly low-tech glider designs.  Going back as far as the First World War, the Horten's had been developing the flying wing concept as a glider.  Such designs might appear familiar to readers of DIYDrones, though some might warrant further research.

   Of the unpowered-wings, the best known is perhaps the Horton H.IV whose extremely broad, thin wingspan was a breakthrough in tailless aircraft design.

 I am highly interested to learn if other contributors to the DIYDRONES community have tested similar airfoil/wingspan designs or are aware of detailed blueprints for Horten wings or other prewar German glider designs.  

  Furthermore, I would like to examine where present work on DIYDrones might apply to simple manned craft like the SchulGleiter.

AFAIK the Wasserkuppe is still a popular location for Gliders and RC aircraft and currently houses the German Sailplane Museum.  Please feel free to comment if you have flown at this location or are interested in the subject in general.

*This is the first post of what I hope to be a series of blog posts, tutorials and curricular guides under the hashtag #makinghistory.  MH entries will examine historical antecedents to contemporary practices in the DIY, Open Source, Maker and Civic Hacking movements.

Erle Robotics, Canonical and the Open Source Robotics Foundation (OSRF) have partnered to bring an "app store" for drones that will use the Robot Operative System (ROS) as its core framework for robotic application development.

We are inspired to support entrepreneurs and inventors focused on life-changing projects. From scientific breakthroughs by autonomous robotic explorers to everyday miracles like home safety and energy efficiency, our world is being transformed by smart machines that can see, hear, move, communicate and sense in unprecedented ways.

Mark Shuttleworth, Founder of Ubuntu and Canonical

 

Ubuntu Core enables our new app store for open robots. That creates a market for innovation and competition in smart robotics, with apps and updates delivered straight from developers to a new class of open, intelligent robots powered by open platforms and open protocols

Brian Gerkey, CEO of the Open Source Robotics Foundation

Through our Linux autopilot Erle-brain that runs APM, we are happy to introduce Erle-Copter as the first Ubuntu Core powered drone. A Linux copter that will support the new Snappy Ubuntu Core which will keep our drones secure and upgraded automatically. 

We are delighted to reveal the Erle-Copter as the world's first Ubuntu Core powered drone that will stay secure automatically and can be upgraded with additional capabilities from the app store. An open platform attracts innovators and experts to collaborate and compete, we are excited to lead the way with open drones for education, research and invention.

Victor Mayoral Vilches, CTO of Erle Robotics

Everyone agrees that developing robotic applications is a difficult task. Brian (CEO of the OSRF) introduced ROS as the LAMP stack for Robotics.

In a few years ROS has changed the robotics field. It has unified Universities and industries around the world, enhanced collaboration, sharing of algorithms and reuse of code. A task that traditionally could take months can be developed within days using ROS. We are true believers of this framework and its possibilities for the future of robotics thereby adopting it as an SDK for an "app store" seems the right choice for us.

We welcome this opportunity to bring a new wave of Linux experts to the drone landscape and keep working to make reliable, Linux-based autopilots.

Last summer, with the help of the DIY Drones community, Agribotix set out to discover how drones could be used to help growers make better decisions. Some of you followed the journey through our blog posts, and we are grateful for all the discussion and discourse our results generated. By the end of the summer, we had the pleasure of working with dozens of growers across many states and several countries who leveraged Agribotix drones or image processing on different types of crops.

Over the course of our first full year in operation, we found that many growers are looking for a simple, cloud-based solution to process their images into actionable intelligence. We wanted the participants at DIY Drones to be one of the first to know that Agribotix has opened up our drone data processing system -- Bring Your Own Drone™ (BYOD) -- to anyone flying drones for agriculture.

The service takes images from virtually any drone, stitches them and returns a single view of a field.  If you send us near-IR pictures, we will also return the results with a false-color NDVI image as well as a shapefile that can be imported into virtually any farm management system and used as an aid to precision fertilizer application.

If you are using a 3D Robotics flight controller, you can download our Field Extractor software, which will automate the process of selecting the images for each flight, geotagging them and uploading. 

We have tried to make the process as risk-free as possible; we process your results, return a thumbnail, and you only pay if you like what you see. You can sign up and begin processing immediately.  Use the Discount Code DIYFREEFIELD and your first field will be processed at no cost.

If you are flying drones for agriculture, we hope you will give our service a try and let us know what you think.

Today we again sucessfully flew Arducopter with ADS-B transmitter. Flight was detected on Flightradar24.com along with other aircraft.

Our Arducopter has formal and legal ICAO registration and probably is first in its class in the world to get formal ICAO ID.

We used microADS-B reciever and our UgCS software to monitor the mission. In paralel also used Sagetech Reciever (screenshot)

Please see whole mission in our video

Thanks,

UgCS Team

Dear Amelia,

I noticed this article on The Epoch Time and was concerned by what I saw. Please note - I am an experienced drone enthusiast and the statements quoted in your article do not reflect the typical user experience as I understand it.

Having built and flown a number of different flying robots I am well aware that machines which are designed, built and operated correctly rarely make mistakes without some human interference. In fact, I would say that 99% of issues are the direct result of poor setup, poor maintenance and/or incorrect or uninformed operation.

Drone groups and organisations are also not normally inclined to publicly discuss or highlight the fallibility of our cherished hobby or blame our tools for potentially dangerous failures experienced in the air, so you can imagine it is highly unusual to be reading direct quotes to that effect from prominent members of our community in your publication.

Investigating further, I discovered that Steve Cohen is not actually the main organiser of the New York Drone User Group. Steve Cohen is listed as the co-organiser with another person named Timothy Reuter. The association between these two people can be seen on the left hand panel towards the top of this page. Timothy Reuter is also the founder of the Drone User Group Network as well as a new startup company known as AirDroids. AirDroid launched a kickstarter campaign early last year with a product called the Pocket Drone.

Here is an excerpt from a presentation given by Timothy Reuter on the Pocket Drone back when launching his crowdfunding campaign early last year - "There wasn't anything (out there) that was fully featured, and yet affordable, and everything required you to take a separate case along with you that was big and bulky. There weren't any drones that were convenient. Now, we've been working on these problems for the last year and we're excited to announce the launch of our first product, the pocket drone. It's powerful enough to carry a go pro into the air, but folds up small enough to take with you just about anywhere you go. It works with everything you needs out of the box like an off the shelf product but has all the advanced featured you'd expect from an advanced open-source kit. and here it is flying, the pocket drone, your personal flying robot. It has all the little features done right, which add up to a significant advance in commercially available drones."

One year on and the Pocket Drone is now currently shipping to enthusiastic backers who have been waiting to receive their reward from AirDroids. Sadly, the Pocket Drone has fallen well short of the claims used to attract backers to the campaign and the majority of users appear to have experienced serious issues trying to operate the product so far. Just read a few of the comments here. Or some of the user uploads like this one or this one. Backer experiences with the Pocket Drone have been so negative that one has publicly admitted to a bout of depression caused by the situation. Another has also openly admitted to weeping over the outcome. Others speak of fraud, credit card charge backs and refunds. But most people are just very unhappy.

It is clear that the Pocket Drone does not deliver on earlier claims and with so many unhappy backers it would seem logical that the AirDroids team may be in damage control - possibly fearful of hundreds of returned items arriving back at their distribution point, a class action being formed by the 1000+ unhappy backers involved, or potentially even being the subject of a legal claim in relation to potential injury or property damage.

Frankly, I would not be surprised if the article on your website was a story given to the media so to negatively redefine the consumer drone experience to better align with the abysmal situation Pocket Drone backers currently find themselves in.

Looking at people's comments it appears to be a long list of serious problems that set the Pocket Drone apart from other consumer drone alternatives - including poor construction, shortcomings in setup and tuning, the absence of safety failsafes, a poorly placed antenna that gets cut off by the tail rotor, landing gear which all but guarantees lost parts and a crash upon landing, as well as no technical flight instruction or guide for new flyers to show them how to use the features used to market the product.

Please consider how the follow quotes from Steve Cohen come across in light of the above outlined issues:

"The technology is difficult to control even for the most experienced flyers."

"Little things frequently go wrong. Even though Cohen is a seasoned drone maker, his antenna came loose while he was flying."

“I've made every mistake two or three times,” Cohen said. “You've got to make the mistakes, that’s key.”

"But that incident wasn't as heartbreaking as when his QAV400 - a more expensive and advanced drone that he spent more time customizing—fell into the Prospect Park lake."

“The thing about having drones is, you have to try not to get too attached.”

“The technology is not reliable yet”

To me, parallels (right down to the specifics of an antenna falling off) between the negative comments made by financial backers of Timothy Reuter's company and the negative comments made by his organisation's members in the media are simply too simular to ignore.

Thank you for your time spent reading my email,

The Kenya Civil Aviation Authority finally broke the silence about the use of UAVs in the Kenyan airspace. This was probably provoked a couple of drone articles and incidences that have been published recently. Just recently, a writer for a local daily wrote this article about drones in Kenya flying into strong legal winds.

If you are visiting Kenya, you better leave your drone home at the moment. There was also this guy who was recently fined about 500 Dollars for flying his drone in a national park in Kenya.

On the bright side, they at least left some open window for us to try and seek approval from the Ministry of Defence. I hope things work out well.

This is my fourth article about Andruav. In the past few articles I talked about:

1- What is Andruav then I focused on the telemetry features in Andruav.

2- Andruav as a3G unlimited Range Telemetry and made demo on Multiwii.

3- Andruav as APM Telemetry 

Now lets get back to Andruav itself. As mentioned before Andruav is an interconnected system, it aims to connect multiple GCS & Drones together so that they can communicate and exchange information.

The first line of code of Andruav was written in Sep 2014, so it is relatively new, however there has been alot of progress since then. Now let us discuss the interconnectivity demo in the video:

Video Scenario:

The video shows how multiple drones and GCS can be interconnected using Andruav.

In the video we have:
        1- two Andruav mobiles that are mounted on two different drones.
        2- two Andruav mobiles that are GCS mobiles.

        GCS mobiles can be in two different places, states, countries ...etc. and they both can be very far from Drones.

Scenario #1:

   An Andruav-GCS connects to Drone 1 and display IMU data from it. then Drone 2 is selected and GCS mobile start display IMU data from Drone 2.

Scenario #2:

  Both GCS mobiles are connected to the same Drone. and they both display IMU data from a single drone.
Please note: both mobiles can take remote images from the drone, the preview will be sent only to the GCS that requested the image.

A Hi-Res image with GPS info will be stored and linked to KML file in the drone mobile.

Scenario #3:

   Each GCS is connected to a drone. i.e. GCS1 is connected to Drone1 and GCS2 is connected to Drone2.

Things to be notice:

       1- All drones are connected to all GCS all the time, it is the IMU data that is being redirected only.
       

       2- All drones and GCS can be tracked simultaneously on Google MAP of any GCS.
       

       3- A drone can be connected to a GCS as IMU data, while telemetry data is being sent to the other GCS.

Current version 1.0.30 can automatically distinguish between Multiwii protocol & MAVlink and optimize telemetry communication for each one.

As part of the roadmap, comming versions should be able to parse & inject packets and provide standard means of communication between different drones regardless of board type.

SmartAP Autopilot now has its own Configurator, this is a desktop application which helps to configure SmartAP board easily and prepare the vehicle for the first flight just in 10 minutes! The design is very clean and intuitive, while the capabilities are very flexible. Check out the video tutorial on system configuration above.

The major specifications are:   

• Intuitive interface
• Works via USB or Telemetry
• Battery status display
• Supports 10 types of airframes
• Radio type selection (PWM or SBUS)
• Easy IMU calibration
• Fast parameters tuning
• Advanced parameters list access
• Command line interface
• Real time plot
• Firmware update (coming soon)

This is the initial version and more interesting things are yet to come.

SmartAP Ground Control Station for mission planning, flight control and post-flight analysis is in development and will be released soon. 

SmartAP Autopilot is the next generation flight control system for multirotor Unmanned Aerial Vehicles capable of fully autonomous flight. It has a powerful microcontroller STM32F4 from STMicroelectronics, 9-axis Inertial Measurement Unit and the latest GPS receiver from UBlox integrated onboard. SmartAP supports any type of multirotor UAV with outstanding navigation and control precision. Unlike our competitors SmartAP was developed using the latest electronic components available at the moment, which allowed us to achieve such amazing results. 

More information: http://sky-drones.com/

This is a preview of the upcoming high fidelity simulation capabilities and native ROS / Linux port of the PX4 flight stack. It includes simulated cameras, inertial sensors, flight physics and even sensors like laser rangefinders. The same software running during software in the loop simulation can also be executed on a Linux computer for live flight, and leverages the ROS middleware, logging, replay, data streaming and 3D visualization infrastructure.

• PX4 ROS Code
• Gazebo core simulation plugin by ASL, ETH Zurich
• Mailing list for more information and contact

This is a tryout prototype of a multirotor testing device. Someone else built it for me actually who normally works with doors and heavier stuff, so it got bulky in the end and the rings gain too much momentum to be anything comparable to a multirotor this size. All connection points are regular bearings: inner ring is roll, second ring is pitch and third ring is yaw. The outer ring is support and should be mounted upright.

This is not shockingly new, the dragonfly indiegogo project used a tether for their testing, as seen in this video:

http://vimeo.com/105405677

This model is intended to be used for testing controller boards with motors that you'd typically put on miniquads and 5x3 props. So thrust is a bit tougher. Some improvements that need to be made are swapping the alu material for carbon and ideally making the rings round with the edge facing the direction of travel (not flat as seen here) to reduce wind drag. A slightly better method of mounting the rings is for the inner ring to rotate around the Z axis. In the current construction method, if the vehicle has some angle in either pitch or roll, the yawing forces are reduced. Such an inner rotating ring is a lot more complex to construct, so that's probably not going to happen.

Such a device offers the following benefits:

• It avoids damage if the firmware isn't fully tested
• You can test the controller in any weather condition
• It's less likely to hurt yourself (holding the model to see how it behaves, etc)
• If yaw is not used, you can hook it all up to a power supply to reduce battery dependencies and you can debug the controller without having to hold or constrain the model.
• Can be used for training.

In the next prototype I intend to use a square outer support and mount this on a flexible base with 5 pressure sensors at each quadrant and one below. The generated pressure is the force the quad generates in that direction, which through a script can be translated in acceleration and eventually velocity. The acceleration and speed data with attitude can then be sent to a flight simulator to be able to test the behavior of the controller in a simulated environment and the GPS+air pressure data needs to be overridden in the controller through telemetry. The idea is to reduce the complexity of a HITL simulation, so you don't need to simulate the complex action of the props anymore and you can use a very simple UFO aircraft to test the navigation code and performance.

I can share design files with people who want to collaborate on this.

I was curious how well LIDAR-Lite, which is just a laser range finder out of the box, would work as a full sweeping LIDAR unit, so I set up this demo unit. The unit updates at 100Hz, so to detect a 10cm object (like a telephone pole) within a 5m arc at 10m distance (with 2x oversampling), I calculate that you need to sweep 30 degrees back and forth each second. (5m = 10m*sin (30)).

That's totally within the speed of a regular servo, so I threw together this test. It just uses APM as an Arduino, sends the LIDAR-Lite and servo position data over serial and reads and graphs the data with a Processing sketch on the laptop.  The Arduino code and Processing sketch are here: LIDAR%20sweep.zip. 

BTW, the LIDAR-Lite sensor is already fully supported by the APM code as a range finder (for altitude hold with copters and/or autolanding assist with planes). You can read more about using it here. 

The code for object avoidance using LIDAR-Lite is already written (thanks to Robert Lefebvre), and this would just add a sweeping component. Here's a video of it working in static mode, on a 2-axis stabilized gimbal:

Some observations:

• It works! I can spot telephone poles with no problem
• That said, the effective range of the LIDAR-Lite unit in this application is just 10m. I'm not using a low-pass filter on the cable, which is normally recommended, and I'm just taking one data point at each position, so I think that can be improved with a smarter sampling strategy.
• In practice, this would be better implemented by moving a mirror, not the entire LIDAR unit, to avoid shaking and other off-axis movement that can get in the way of sampling
• Laser range finders are SO MUCH BETTER than sonar. 

U.S. Sen. Chuck Schumer called on the federal government Friday to release what he dubs "much-needed rules" for the use of unmanned drones in light of two recent instances of drones encroaching into Westchester County Airport airspace.

Full article here Senator Demands Federal Action 

An example of the new geo-spatial products and virtual surveying and planning tools which we can bring to the farmer's kitchen table today - safely, harmlessly and economically, over and over again. All thanks to small UAVs - the new personal mapping systems. Thanks to the tremendous contributions from the DIY Drone community, small enterprises can now offer new cost saving solutions to virtually every sector of the economy. Mapping and modeling activities can now migrate to the long part of the "long tail". Let's hope they prosper there in peace.

https://www.youtube.com/watch?v=963OypmuAoc

Ardupilot developer Andrew Tridgell has presented 'Flying with Linux' at LinuxConf 2015 in Auckland, New Zealand.  During his presentation Tridge connected to the running autopilot software of a plane being flown in Canberra Australia by CanberraUAV chief pilot Jack Pittar and Grant Morphett. A Skype connection to Grant's phone was used to display the flight to the audience in New Zealand.

Running Ardupilot on Linux enables other cpu intensive processes such as image recognition software to be run on the same platform as the auto pilot. To demonstrate how capable the system was of multitasking, a new linux kernel was being compiled while ardupilot was also being run to fly the plane. Compiling software typically places a very high load on a system but ardupilot ran normally flying the plane three times around a circuit. The plane even did a successful auto landing despite high winds.

Flight telemetry streamed live to the presentation while Tridge explained how the system was configured and the work that the CanberraUAV team had done since his last presentation a year ago. This work included winning the prestigious Outback Search and Rescue Challenge held in Queensland Australia last year.

Hi all,

I posted here a while back about my Quad frame and thought it would be a good idea to post a quick update.....

For those that missed the first post this is a Quadcopter frame in the Spider style but the difference being that the bottom plate has a Dirty/clean setup ( The FC, Gimball and battery are on the clean section) , this means that the effects of vibrations are greatly reduced.

I have decided to make the Explorer4 Quadcopter Open source, I have been getting lots of great sugestions but dont have the time to impliment and test them all.

I have put links on the website to Github where you can download the drawing files and cut one for yourself. There is also alot of Info that I have added over the past few months, Including a build guide with videos and a parts list with links.

www.explorer4-quadcopter.com

This post is intended to illustrate the steps into making a less-than-a-buck battery voltage measurer to monitor the life of your UAV battery. It has been used successfully on a generic autopilot board (running MegaPirateNG), but it should also work on original ArduPilot or other boards.
On the hardware side you need a simple voltage divider and optionally a capacitance-type filter (100nF):


"Wait! What's going on?"  You wouldn't want to send your raw battery power directly to the board, unless of course you wanted to see it flaming up. This voltage divider sends a ~2.2V (when battery is fully charged at ~12.6V) voltage to your controller board. This value is then multiplied by a scaling factor to get the original battery voltage level to be displayed on your GCS.

Connect GND to a ground pin on your board and insert the the socket into the AD0-Ax slot.
Measure your battery voltage with a multimeter (you'll need this value in a second). Now cable the battery to the newly made circuit and the latter to the system.
Connect your board to your computer via USB and start MissionPlanner.

You can follow these visual steplines on the wiki while reading the following.
Click on the Initial Setup tab and under the Optional Hardware slot on the left select Battery Monitor.
Select the following:
-Battery Monitor: 3 Battery Voltage
-Sensor: 1
-APM Version: <your version here>
Type the battery's voltage value in the Measured Battery Voltage entry and press enter. The following entry (named Battery Voltage (Calced)) will monitor your battery voltage. This info is also visible on the bottom left corner of the HUD in the Flight Data screen, and you can also set battery failsafe..how cool is that!

Very interesting post from Nathan Wambold on LinkedIn:

I watched this documentary today on the history of and new potential uses of "drone" technology. In of itself, it's an interesting and good documentary. But, one thing in particular I found very interesting is a statement made in the video about (military) UAV pilots and how the FAA had conducted a study proving that traditionally trained airplane pilots are NOT as good at piloting these crafts as those who have never been trained to fly a real airplane (find this comment @ 23 mins. into the video).

Now, there's still no comparison in piloting a military grade RPA or UAV to today's commercial products. Methodology and equipment are completely different. But, if the FAA conducted a study proving it's better to NOT be a traditionally trained airplane pilot when piloting a UAV, then why is the FAA currently in process of trying to mandate a commercial pilot's license to fly today's UAV copters and planes?

Congrats to the X PlusOne team on the conclusion of their successful Kickstarter campaign, having raised nearly three times their goal!  The Pixhawk-based autonomy add-on package is the one I'm getting.