LAS VEGAS (AP) — Chinese drone maker Ehang Inc. on Wednesday unveiled what it calls the world's first drone capable of carrying a human passenger.

The Guangzhou, China-based company pulled the cloth off the Ehang 184 at the Las Vegas Convention Center during the CES gadget show. In a company video showing it flying, it looks like a small helicopter but with four doubled propellers spinning parallel to the ground like other drones.

The electric-powered drone can be fully charged in two hours, carry up to 220 pounds and fly for 23 minutes at sea level, according to Ehang. The cabin fits one person and a small backpack and even has air conditioning and a reading light. With propellers folded up, it's designed to fit in a single parking spot.

Read more: http://www.dailymail.co.uk/wires/ap/article-3387777/Chinese-drone-maker-unveils-human-carrying-drone.html#ixzz3wVeW1ce9 

I wonder if it uses PixHawk? Comments? 

One of the recently implemented features of UgCS is the Click and Go mode. This makes flying drones with waypoints more intuitive and easier than ever. All you need to do is click on the map, place a point and the drone will automatically fly to it without the need to calculate and upload the route. For DJI drones this works even if the drone is on the ground. Using the Click & Go mode the drone can automatically arm itself, take off and fly to the location specified.

The click and go functionality increases the speed at which the drone can be operated using UgCS route planning software. This can potentially be used not only by hobbyists, but also by security companies, for instance, allowing drones to be deployed quickly and efficiently.

Currently click and go mode works with 3DR Pixhawk, APM as well as DJI Phantom 3 and Inspire 1. Click and go mode will be available for more drones in future releases.

Check out this video of it in action:

Get UgCS here: www.ugcs.com

Safe flights,
UgCS Team

Since posting the BreezySLAM package for Python and other languages, I've received several inquiries about supporting the Lidar unit on the XV-11 vacuuming robot from Neato Robotics.  Although I have an XV-11 and a Python package for it as well, I was reluctant to pull the Lidar unit from it to put on an MAV or other robot.  Now, thanks to GetSureal.com, I was able to get the XV Lidar with a handy Teensy USB adapter built in (which makes clever use of the popular Teensy Board).  So I wrote a little acquisition module for the XV Lidar, and added SLAM support for it in BreezySLAM.  

In the continuing evolution of scalable, multi-UAV control surfaces, here's a few minutes demo of the Guidance Mode UI using the Flying Robot Commander in tandem with Paparazzi UAV. The same framework for building last week's Flight Block UI is used in the creation of the Guidance Mode UI. Instead of using live aircraft, I chose to use the Paparazzi simulation environment for this demonstration. Note that even though each UI is being displayed on different touch devices, they can happily run on a single or many devices, depending on how the user wants to layout their flight control systems. Enjoy and stay tuned for more open-source Flying Robot Commander adventures.

For 2016, 3DR has added an academic Tumblr page to promote all the amazing drone collaborations with schools and universities across the globe. 3DR will also continue with its academic hardware discounts of 20% off retail, including Solo and Solo accessories. The application for discounts can be found here and is currently applicable for non-profit educational institutions in the US, Canada, Australia, and New Zealand (with more countries coming soon).  Feel free to pass on this info to a school near you.

Here's the :Link

The news release said, "CEO Mark Fields said a goal is to set up a system, for example, where a United Nations emergency worker could launch a drone from an F-150 to survey a disaster scene.

“A drone will actually have the coordinates and be able to then land back into the bed of the F-150, even though it’s in another location,” Fields told WWJ Auto Beat Reporter Jeff Gilbert.

The rapidly deployable surveying system ideally would work like this: A response team would drive an F-150 as far as possible into an emergency zone caused by an earthquake or tsunami. Using the Ford SYNC touch screen, the driver could identify a target area and launch a drone through an app. The drone would follow a flight path over the zone, capturing video and creating a map of survivors with associated close-up pictures of each.

Using the driver’s smartphone, the F-150 would establish a real-time link between the drone, the truck and the cloud, so vehicle data can be shared. Data will be relayed to the drone so the driver can continue to a new destination, and the drone will catch up and dock with the truck."

Anybody interested in working on this challenge? 

You can now install the FlightGear Flight Simulator and use it (in view-only mode) to display a 3D simulation of the vehicle and its surroundings.

This provides a much better visualization than 2D maps/HUD alone (as provided by MAVProxy and Mission Planner). In particular it is much easier to see movement that is hard to judge properly in 2D - like pitch and yaw.

SITL outputs FlightGear compatible state information on UDP port 5503. All you need to do is install FlightGear and start it using the batch files provided. When SITL starts, the FlightGear window will sync to your current location.

Currently this feature is only available on the master ardupilot branch. Setup instructions are available here: Windows and Linux (Ubuntu 14.04).

Kudos to Tridge (yet again!) for making this happen!

Looks like a cross between the Parrot Bebop and the Sensefly eBee (also a Parrot subsidiary). Indeed, that's almost exactly what it is. Announced at CES today.

Written by Ryan Beall and Chaz Henderson:

Data/Analysis

The flight data was logged on the micro sd card which was plugged into the front of the Pixhawk autopilot.  The Pixhawk is capable of logging various levels of data, but because the sd card used was 4gb, the default (all data logged) was chosen.  It was also set in the logging settings to only log when the autopilot is ‘armed.’  Only logging when armed helps cut down on useless data. 

The log .bin files can be pulled wirelessly through the ground station or pulled directly off the sd card using a sd card reader.  We used an sd card reader because it is drastically faster.  These files were then converted to .mat files using APM Planner.  These .mat files were then individually loaded into matlab for data shaping and analysis.

Data Shaping:

The Data was shaped using two triggers.  The first trigger was the channel 7 servo command to release from Arcturus.  The second trigger is the spike in acceleration sensed when the aircraft impacts the ground.  

Flight Path Analysis:

The matlab script was also used to illustrate the flight path and basic attitude hold performance.  Some of these example results can be seen below: 

The above is a great illustration of the expected glide performance of this aircraft at its current wing loading.  Above you can see that the mean sink rate is 995 ft/min, which equated to a mean glide ratio of 2.37:1.

Attitude Hold Analysis:

The below is a segment of the roll attitude hold performance during the orbit over the airfield.  The error tracking performance could be greatly improved with more tuning flights.  A comparison to the gains achieved using the auto tuning algorithm (used on this flight) versus the predicted gains from the model derived at the end of this paper will be an interesting follow on study.

It is clear that the roll attitude hold PID loop is working, but it is evident that with large perturbations in roll attitude, that the PIDs are underperforming and has room for tuning/improvement.

Results and Conclusions

The main focus of this study was to ultimately create a flight dynamics models from recorded flight data.  The flight profile analysis above demonstrated that our autonomous flight profile would be adequate for use in estimating this flight model using system identification tools.  As this was a proof of concept and the short amount of time between our range date and deliverable due date, only the roll axis was chosen first for system identification.  A full aircraft model will be developed next quarter.

The roll rate response versus the roll command was analyzed using a SISO matlab method.  The determined model for roll was the following:

The roll rate of this aircraft is "extreme"!  The dual rates and exponential have to be heavily utilized to manually fly this aircraft safely.  This fast response is also manifested in the model above.

The roll command pwm recorded from the flight was put back into the above model and compared to the actual roll rate achieved by the aircraft and can be seen below:

As seen above, the model mapped to reality really well.  There is some noise due to natural unstable air disturbances, but the overall performance of this model is respectable.  More tuning of the PIDs and test flights profiles specifically written for System Identification should help present a more robust model.  We recommend that the follow on study consist of more PID tuning with a more methodical input/output study using frequency sweeps on inputs to help get a more complete model.  It should be noted that this was achieved in three months spread over 6 two-minute flights during a one-day range evolution.  Producing this low fidelity model with this limited amount of time and data was a difficult accomplishment.  But with more time/flights in the following quarter, significant strides on this project are anticipated.

Drop Analysis:

 The following are matlab generated Google earth profiles of the recorded telemetry.  It should be noted that the under side of the wings are blue and the top side of the wings are red in the following illustrations.

Overall this was a successful quick example of how an aircraft can be cheaply prototyped quickly and how one could do a system identification of an airframe with the data provided from log files.  This project will probably evolve into an auto-tuning solution for PIDs of sorts but we will see what the next 3 months produces.

Fly Safe, Fly Fast

-Beall

Research by Ryan Beall and Chaz Henderson:

Background

I took part in a research endeavor to analyze many facets of guided/autonomous parachutes this last 3 months.  There are many technical problems that require solutions for this project to be successful and the following analysis presented below is the culmination of 3 months of research dedicated to airframe system identification and proof of closed loop autonomy.  This project was comprised of two teams working in parallel.  The other team worked on increasing the parachute deployment reliability as well as manual control of a parachute.  Because our team was responsible for solely creating a model from logged flight data and proving low-level autonomy, it was chosen to use a reliable fixed wing airframe instead of the parachutes to more effectively solve the system’s problems without potentially being hindered by airframe reliability.  Proving our methods of analyzing the system on the fixed wing aircraft can easily be modified to the parachute airframe once it comes online.

Equipment

1:  Pixhawk Autopilot

2:  3DR Ublox GPS and magnetometer unit

3:  3DR 900 Mhz wireless telemetry modem suit

4:  350mAh Lithium battery (2 cell)

5:  3 Amp / 5v Battery Eliminator circuit (Hobby King generic)

6:  3 x 5gram servos (Hobby King Generic)

7:  Dollar Tree Foam board (1 sheet per aircraft)

8:  Hot glue gun / hot glue sticks

9:  Custom 3D printed parts for release mechanism (described below)

10: Ultimaker 2 3D printer

11: Laser cutter

Setup

The first part of our project was to design the airframe.  A small wingspan was desired to fit below the Arcturus UAV to ensure minimum interference.  We also didn’t want the high glide ratio of a glider, because we were aiming for flight characteristics similar to that of a parachute.  The design chosen was a delta wing plan-form with a very low aspect ratio.  The flying wing architecture is easier to build, is compact, and uses the least amount of servos for stabilizing flight.  This design did not utilize a motor.  It may be familiar to some of you as a version of the Punjet found at:  

http://flitetest.com/articles/ft-pun-jet-build

The Fuselage was widened to accommodate the Pixhawk and tapered in the back.  The wingspan was also increased by the same thickness added as the fuselage.  The first step in designing the aircraft, was to design the fuselage such that it could carry the autopilot.  The physical dimensions of the Pixhawk autopilot were what dimensioned the fuselage.  Essentially the whole aircraft was designed around the autopilot.  The second design constraint was the release mechanism.  The aircraft had to be able to release itself from the Arcturus UAV with it own servo release mechanism.  The space required to house the release mechanism was a concern.  However, shaping the fuselage around the autopilot gave ample room for the release mechanism as well as the telemetry modem, gps and battery.

The plans illustrated below were generated in Inkscape (open source version of CorelDraw) from the modified flitetest pdf vectors.

These plans were plotted on paper to lay out the electronics and do one last test fit to ensure scaling and servo cutouts were correct.  The Inkscape final plans file was converted to a vector file (generic SVG in Inkscape) in order to be printed on a laser cutter.  The black lines represent a cut that is all the way through the foam board, and the red lines represent a half score cut through the foam board.  The print settings for the laser cutter let you set the laser’s power and speed relative to the color.  Using scrap foam board, test cuts at different power levels and speeds were tested to get the desired performance per the respective color.  The final power/speed settings used for accurate cutting were as follows:

Black: Speed=20%, Power=100%

Red: Speed=20%, Power=55%

It was also found that using the flattest foam board possible ensured the most accurate cuts.  It was also very important to run the auto-focusing procedure for the laser every time cut was performed.

The aircraft was assembled using hot glue and box tape in typical flitetest.com fashion (build video).

The next part of the design process was to design the release mechanism.  The release mechanism comprises to two primary parts:  the base plate designed to spread the launch forces across the bottom of the aircraft and the hook capture device designed to capture the wire.  These two parts were drawn in 3D CAD (Solid Works) and then printed on an Ultimaker 2 3D printer.  These results can be seen below:

The base plate was glued to the bottom of the aircraft and the hook was attached to a pushrod connected to a servo.  The release interface was then tested and the servo was trimmed to minimum and maximum travel positions to prevent binding.

The Pixhawk was configured with the ‘plane’ software and stock PID settings were used for the initial flight.  The elevon settings, correct command orientation, as well as PID attitude feedback were all verified as correct.  The servos were reversed on the ground station until the correct behaviors were observed.  Channel 7 was used for servo pass through to actuate the release hook servo.

The transmitter mode switch was capable of selecting 3 flight modes on the autopilot.  These three flight modes were chosen in a progressive nature to ensure safe flight through the multi-flight test flight process.  For example, the first flight was setup with the following: 1: manual, 2: Auto tune, 3: Fly By Wire A.  This was to ensure that if the attitude PID gains were too high, the flight mode could be selected for manual control.  Return to launch and/or orbit was not selected for any of the 3 modes for the first flight because the underlying attitude controllers needed to be proven.  

On the first flight, it was intended to utilize the auto-tune algorithm for attitude control to further refine the PIDs.  The attitude PIDs recorded from the first short flight were not that much different from the stock PIDs.  The primary influencing gain of focus for these first flights were the proportional gains.  The stock value for these gains was 0.4 ( a fairly conservative value).  The short flight time only enabled the P_roll to increase to 0.43.

The aircraft was tested for release and physical interference with the Arcturus UAV.  The release mechanism successfully released multiple times on the ground and did not interfere with the Arcturus UAV.  All subsequent flights all had 100% successful drops.

 Drop/Flight results to follow in Next post!

Hi,

The project's idea is to use my newly received (thx Santa) Pebble time smartwatch to send commands to a drone from your wrist, via a telemetry (mavlink). Accesorily, the objective is also to play with dronekit (mavlink communcation library) and SITL (APM vehicles/drones simulation tool).

As a summary, Pebble runs an HTTP client app to connect to an ESP8266 WiFi web server, which in turns transmits the received commands to the serial port of mission planner (or any other mavlink compatible ground station), running a dronekit python script to remote control the drone.

The chain of command from the Pebble watch to the drone is the following:

1.Pebble watch <=> 2. ESP8266 WiFi/UART device <=> 3.Dronekit python script <=> 4.Telemetry mavlink radio link <=> 5.Flying Drone

1. Pebble time smartwatch:

From the Pebble app store, the free "Send message" app is used as an HTTP client; The app is used as a kind of REST control, by getting (http GET) a different URI associated to different command. In this project, I decided to code three vehicle mode changes : RTL, LAND, POSHOLD.

2. Web Access Point for the Pebble - ESP8266 module:

This Pebble app needs to connect to a Web server. For that I use an ESP8266 module. As described on Sparkfun : "The ESP8266 WiFi Module is a self contained SOC with integrated TCP/IP protocol stack that can give any microcontroller access to your WiFi network. The ESP8266 is capable of either hosting an application or offloading all Wi-Fi networking functions from another application processor.". It contains a microcontroller which is twice as fast as a basic Arduino board (80 Mhz or 160 Mhz), up to 2MB of flash memory. it exposes a number of GPIO PINs for digital and analog input/ouputs and two  UART ports ! So it is possible to use this device to make a UART-WiFi bridge, which we are using in this project.

Such an ESP8266 module costs between 5 and 15 dollars according to the manufacturer & version. There are more than 12 different versions (ESP-01 is the basic standard module, ESP-02, ..., ESP-12 exposes all GPIO PINs, etc...)

For this project, I used the Sparkfun "Thing" version, which provides an integrated 3.3V regulator, Lipo battery input and a micro USB port.

The module is programmed with the well known Arduino IDE.

I programmed PebbleArducopterControlAP.ino as a web server to run on it, waiting for a Pebble smartwatch connection.

This ESP8266 converts and transmits the Pebble watch received HTTP GET commands to the serial (FTDI USB) port of the computer running a dronekit python script.

3. Dronekit python script:

The ESP8266 module forwards the smartwatch commands to a computer on a serial port (could be a computer board such as RPi or Odroid, etc).

For ease of development & testing, the well known SITL APM simulation software is used to simulate an APM:Copter version 3.3. In the SITL copter simulation, the vehicle's mavlink communicates by default via a TCP link (127.0.0.1:5760)

A quick and simple test script listens on one side on the ESP8266 web server (serial port) and , if it recognizes a programmed command, sends it out to the (SITL simulated) drone via MAvlink on the telemetry link (TCP port).

My source code of this python script here (Vehicle_SIM.py).

4. Mavlink links:

I wanted to run Mission planner in parallel to my dronekit script, to have an easy and familiar visualization of the Pebble command's results on the drone. However in order to run in parallel, on the same drone mavlink link, both the dronekit script and mission planner, you need to run MavProxy to split the mavlink channel on two different UDP ports. Full details on how to use SITL and Mavproxy is given on the dronekit.io site.

5. Flying drone - Results:

See attached video. Had lots of fun to see the magic happen : a press on one of the three Pebble watch buttons triggers a drone mode change (RTL, LAND, POSHOLD in this demo example);

Although the real practical use of such a project is doubtful, I can tell you it is a lot of fun and a good learning experience on different topics : Pebble, ESP8266 modules, Dronekit, SITL !

Cheers,

Hugues

Whether you agree with the FAA’s requirement to register your drone if it weighs more than 0.55 pounds (250 grams) so you can fly it outdoors for fun as a hobby this is now the law as of 12/21/2015.

I would rather ensure my drones are registered rather than face the possibility of a civil penalty up to $27,500. I know I won’t be using them for any criminal activity so I will definitely not face the prospect of fines up to $250,000 and/or imprisonment for up to three years. You can view the full rule here www.faa.gov/news/updates/media/20151213_IFR.pdf

When registering you complete the form with your name, home address, email address, etc. and you will be issued with a unique registration number, you can also use your drone’s serial number when registering. The problem I foresee with using the serial number is if you change drones you have to go through the process of registration once again. If you are issued with the FAA unique registration number it covers any drones you have. You can click HERE to go to the FAA website to register your drone/UAS

Drones/UAS have to be marked with your registration number and this can be done using labels, engraving or using a permanent marker and the number must be readily accessible, readable and legible for visual inspection. You may put the registration number in your battery compartment if you don’t want a visible number on external areas of the drone.

If you would like professionally produced labels for your drone as one way of complying with the FAA regulations then go to Drone Registration Label who can provide them for you.

The PX4 flight stack has an unique architecture: It uses a single codebase and mission logic for all vehicle types.

This allows us to easily support VTOL vehicles of any kind: Tailsitters with just two rotors, Tiltrotors and quad planes [INSTRUCTIONS TO BUILD YOUR OWN HERE]. This has been flying great since summer and our latest release has the full support for all three airframes in it. You can reach the dev team via the mailing list or chat if you're interested to try it.

Tilt rotor:

Tailsitter:

I was a Kickstarter backer of the XPlusOne VTOL aircraft, and I was able to get it for $199 as an early backer.  Now it's sold at the regular price of $1,549 for the version I have, which has no autonomy (it's got a simple MultiWii controller board), or for $2,199 for an autonomous version with Pixhawk. 

I haven't tried the second, more expensive, one, but have now flown the first enough to give a quickie review. 

The promise of VTOL aircraft is that they can take off and land in small space like a copter, but have the duration and lifting power of a plane. Sadly, this is usually more true in theory than in practice. VTOL aircraft like these are often called "sporks" for a reason. As copters they are hard to control, unmaneuverable, and prone to being blown around by the wind due to the sail-like cross-section.  As planes, they tend to be draggy due to the extra props and as a result also struggle with the wind. 

The XPlusOne is no exception. As a copter it tends to be blown about by the wind, as you might expect for something with four (!) wings. But the idea is that you keep it in copter mode just long enough to take off and and land, and do most of your flying in plane mode. Unfortunately, the XPlusOne is even worse at that mode. Since it has no control surfaces, all steering is done with differential thrust of the props, which is sluggish. And since it has no tail surfaces, it has to fly with a very high angle of attack at all but top speed, which means that it's always close to a stall and thus also prone to being affected by wind. 

But the main problem is that, as you can see in the video below, it's almost impossible to see its orientation. With four wings in a symmetrical configuration you just can't tell which side is up, or left from right. Combine that with very poor control authority and you'll be lost within seconds of going into plane mode. 

I just got a few flights in, and only one in plane mode, before this caught up with me. On a windy day, i went to a safe altitude to transition, went into plane mode and I immediately lost orientation. So I switched back into copter mode and the winds at that altitude just blew it away to parts unknown in seconds. I was never able to regain enough control to bring it home. Bye-bye XPlusOne. Had I paid $1,549 I would have been pretty annoyed. 

In short, I think the XPlusOne is unflyable in its base MultiWii configuration. That said, a proper autopilot might have done a much better job than me and the Pixhawk-based version with GPS might have been able to bring it back against the wind in a way that I, from the ground, could not.  But I'm not going to pay $2,200 to find out. 

2015 was a year of remarkable progress in the consumer drone world, and not least here. As is customary, these are some of the highlights of the year on the DIY Drones and APM software development community. 

• APM: Copter 3.3 released after the most exhaustive beta-testing process we've ever done (5,100 comments in the beta testing thread alone!). The biggest change was the move to an Extended Kalman Filter (EKF) for all sensor fusion, which is incredibly powerful in allowing us to bring in integrate new sensors as well as better flight performance. But the list of other features and performance improvements is pretty astounding, but puts this amongst the most powerful drone software stacks in the world.  
• APM: Plane 3.4 brought those same performance features (and a zillion more) to fixed-wing aircraft.
• APM: Rover 2.5 sync'd all that up with a new release for ground rovers, too. 

Overall, the dev team has never been bigger or busier. And the platform is gaining in popularity at an extraordinary rate, and is now the leading open UAV platform in the world, with an estimated 750,000 users based on latest firmware and terrain download data.

DIY Drones grew strongly this year, too (see chart above), with an average of 1,000 new members and 1.3m pageviews per month.  More than 1,400 blog posts were published in 2015, and almost 6,000 discussion group threads with nearly 50,000 comments. 

Meanwhile, our umbrella organization, the Dronecode Project, grew nearly 200% in 2015, with core projects such as APM and PX4 being joined by big companies such as Qualcomm, Intel, Baidu, Box, Parrot, Yuneec and Walkera as well as sister open source software projects such as ROS (Open Source Robotics Foundation) and OpenTx.

In short, it was a big year! I wanted to take this moment to thank all the people who made it happen:

• Randy, Tridge and and the rest of the APM Dev Team, who work tirelessly to invent the future
• Tom and Gary and the rest of the DIY Drones moderators,  who work tirelessly to make this a great place to learn and share
• The members who gave so much of their time, ideas, help and inspiration to make this community thrive

You all rock. It's an inspiration to see what you make here every day. 

-Chris

Qualcomm, a 3DR investor, has released a sneak peek of what it will be showing at CES next week. 3DR will be also displaying in the Qualcomm booth. Draw your own conclusions ;-)

From the Verge: "We believe that, with this chip, we can cut the price of the average 4K camera drone from $1,200 down to $300 or $400," Qualcomm's Raj Talluri told The Verge in October. "And we think we can extend the battery life from 20 minutes to 45 to 60 minutes. That will open them up to a much broader audience and a whole new range of applications."

Being a product of the 1960's and a fan of science fiction films/series like Star Trek, Lost in Space, 2001: Space Odyssey, Space 1999, Silent Running, the idea of having a control surface full of multi-colored buttons seemed a natural approach for managing flying aircraft. Last week, I decided to design a web based UI that scratched that 1960's sci-fi itch, so to speak. I call it the Flying Robot Commander, with a wink and a nod to Johnny Sokko. The goal was to make a flexible web based UI that allowed for easy development of virtual control surfaces with nice big, colored buttons, sliders, etc... that easily integrate with Paparazzi UAV. Since it's delivered via a web browser, it works on any device that runs a browser(i,e. touch screens, touch devices, traditional laptops/desktops). Here's the a video of the first ever live test of the FRC(flying robot commander). Unfortunately, the rainy weather kept the first demo limited to simple arming/disarming of motors. The weather folks promise that we will be getting a few rainless days soon, so stay tuned for a follow-up video with multiple aircraft in the air under the tutelage the Flying Robot Commander. Giant robot, launch! ~HooperFly

As always, this post is mirrored on my personal blog with a little nicer formatting at ddmckinnon.com.

Ever since I moved to Berkeley and started at 3DR, I dreamed of developing an app that ran on-board Solo that would let me see who was chillin’ on my roof deck 2,200 feet from the 3DR world HQ in Berkeley. I dreamed of, as my day was wrapping up, sending Solo to snap a picture of my roof deck, post it online, and tell me if I should head home to grill on my roof with my neighbors. After the wonderful week-long hackathon we had at 3DR in December, I finally realized that dream.

And, it wasn’t that hard. While the documentation still leaves a little bit to be desired, DroneKit Python is amazingly accessible. I have a modest background in academic computing, but little to no experience with modern software engineering. After a few days of effort, which could be shortened to a few hours for those of you reading this guide, I was able to programmatically coerce Solo into some really rich behaviors driven by the on-board computer. I have enormous confidence that anyone in the DIY Drones community, after reading this guide, could do the same.

First, some basics. Solo is unique with its programmable Linux computer on board. While other platforms, including Solo, ship with a mobile SDK, mobile development is significantly more challenging (stay tuned for my guide to 3DR Services/DroneKit Android…). The computer on board Solo ships with Python, a very simple programming language, preinstalled. This makes it very easy for rote novices like me to write software that controls Solo.

OK, how do you actually do this? Follow the steps below and frequently refer to both dev.3dr.com and python.dronekit.io. The former is the Solo development guide. It describes specifically how to get your code running on Solo and how you, as a new Solo developer, can use all of the tools 3DR has built to make your job easy. The latter is the DroneKit Python documentation. It more generally describes what you can do with DroneKit Python and how to get DroneKit running on non-Solo vehicles.

Note: This guide is written for the Mac user. I’m sure there are equivalent Windows commands for many of these steps, but it will be up to the reader to track them down.

Step 1: Install Python

If you don’t have Python installed on your computer, it likely makes the most sense to install using Homebrew, a package manager for OS X that makes sure all of your packages are linked properly. Installation is straightforward and full instructions can be found at brew.sh, but essentially you just need to run

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

from any directory in your terminal.

After Homebrew is installed, run

brew install python

from any directory in your terminal. Full instructions are at http://docs.python-guide.org/en/latest/starting/install/osx/ if you have any trouble.

Note: Brew installing this version of Python is critical to your success with DroneKit. I spent a couple hours removing multiple old Python installs and relinking tools on my dad’s computer while installing DroneKit. I would highly recommend removing any old install of Python and restarting with the Homebrew tap.

Step 2: Install DroneKit Python and SITL

DroneKit Python is the actual software that will interpret your easy-to-write commands and translate them into ones and zeros that are readable by Solo. SITL, or software in the loop, is a simulated vehicle that runs inside your computer. SITL represents the only safe way to test your code (software bugs become a lot more problematic when you’re programming the behavior of a real, physical object). I’m sure everyone on DIY Drones has heard of SITL at one time or another, but until very recently (today!) it was fairly difficult to set up.

Note: Please ignore other documentation floating around the internet regarding installing SITL on a virtual machine and follow these instructions.

Both DroneKit Python and SITL are installed using the pip command. Pip is an install command built into Python, which you just installed using Homebrew, that brings amazing software to your from the command line.

From any directory, run

pip install dronekit

to install DroneKit. Remember that, because pip is a Python command, there is no reason to specific which DroneKit we are installing.

Next, also from any directory, run

pip install dronekit-sitl

to install SITL.

Step 3: Run SITL

This step is fairly opaque in most of the documentation online, but it actually quite straightforward. SITL is a virtual computer running on your computer. Try it. Run

dronekit-sitl copter

from any directory. You will see the command return something like

Started model quad at -35.363261,149.165230,584,353 at speed 1.0

bind port 5760 for 0

Starting sketch 'ArduCopter'

Serial port 0 on TCP port 5760

Starting SITL input

Waiting for connection ....

Running this is equivalent to turning on IRIS or Solo in your front yard and without connecting to a GCS. Your simulated vehicle is sitting inside your computer at a model airport in Australia, which I imagine is Tridge’s local airfield, sending out a TCP signal from port 5760 waiting for a GCS to connect. If you decide you’d prefer that your simulated vehicle take off in Berkeley, rather than Australia, run

dronekit-sitl copter --home=37.873894,-122.302141,584,353

See what happened? Other SITL options can be accessed by running

dronekit-sitl --help

or

dronekit-sitl copter --help

You’ll notice that you can simulate a plane or a rover and change various simulated vehicle settings.

Step 4: Connect SITL to arbitrary ground control stations

DroneKit Python contains a connect command, but to actually see how your simulated copter responds to your code, you will need to connect a GCS. This is done through MAVProxy, which as best as I can tell is both a text based GCS and a way to plumb mavlink messages from SITL or a real copter to other GCSs.

Unfortunately, installing MAVProxy is not as straightforward as the rest of this guide. The best instructions are at http://dronecode.github.io/MAVProxy/html/getting_started/download_and_installation.html#mac, but to keep this guide linear I will reproduce them. Run

brew tap homebrew/science

brew install wxmac wxpython opencv

from any directory in the terminal. The first command taps a repository that is not normally indexed in Homebrew. The second command installs wxMac, which is total mystery to me, wxPython, which is also a mystery to me, and OpenCV, which is an amazing open source computer vision project from which, I believe, sprang Pix4D and Agisoft.

Next, run

sudo pip uninstall python-dateutil

sudo pip install numpy pyparsing

sudo pip install MAVProxy

The sudo part means that you are running the command as an administrator on your computer and the pip command is our old friend from before.

Now MAVProxy should be installed and you are ready to start playing with your virtual copter. Start up SITL, if you closed the terminal window, by running

dronekit-sitl copter --home=37.873894,-122.302141,584,353

Then open a new terminal window and run

mavproxy.py --master=tcp:127.0.0.1:5760 --out=udpout:10.1.49.130:14550 --out=udpout:127.0.0.1:14550 --out=udpout:127.0.0.1:14549

Notice that your SITL window has now bound to the MAVProxy master. This is because we’ve pointed MAVProxy to listen to MAVLink messages over TCP at local IP address (127.0.0.1, although 0.0.0.0 will work as well) using port 5760, all of which was specified when you initially booted up SITL. The three --out items give me three sockets to which I can connect GCSs.

You can now use MAVProxy to control your virtual vehicle (or your real vehicle if you choose to do so, to connect MAVProxy to a real vehicle connect your computer to Solo’s WiFi and replace tcp:127.0.0.1:5760 with udpin:0.0.0.0:14550). Try typing

mode guided

arm throttle

takeoff 10

into the terminal window running MAVProxy. You’ll notice your virtual vehicle will switch modes, arm itself, and takeoff. However, as interesting as it is to control a virtual vehicle from the command line, we are here to write software to control Solo’s behavior and need a visual way to monitor your virtual Solo’s behavior.

This is where the sockets come in. The first refers to my tablet running Tower, which I can use to both monitor and control my instance of SITL. The 3DR network assigned IP address 10.1.49.130 to my Android tablet, which I determined by navigating to the advanced WiFi settings menu, and Tower is set up to listen for a vehicle on port 14550. Now, when I connect my tablet to the same WiFi network on which I am running SITL, I can see my virtual copter parked near the Berkeley office and can control it just like a real copter. To connect your Android tablet running Tower, you should replace my IP address with your own.

The second will be used for running the DroneKit Python examples. We need a socket free for DroneKit’s connect command to bind to.

The third is an extra for Tower-Web, a nice web app that let’s you track the status of your real or virtual vehicle. This is nice because it lets you debug your DroneKit Python applications without an Android tablet handy, but this step is totally optional and redundant if you plan on using your tablet running Tower to visualize your virtual Solo’s behavior. To install Tower-Web, simply run

sudo -H pip install -UI git+https://github.com/dronekit/tower-web.git

from the terminal. Once the installation completes, run

tower tcp:127.0.0.1:14549

and you will bind the Tower-Web backend to your instance of SITL. Point your favorite web browser to http://localhost:24403/ and you should see your virtual vehicle flying around on your screen.

To quickly review, you now should have a virtual vehicle running on your computer that you can control using MAVProxy running in the terminal, Tower running on your Android device, or Tower-Web (sort of) in your web browser. Whew!

Step 5: Run the DroneKit Python example apps

Great! Now you’ve made it this far and are ready to start having some real fun. Let’s run the examples.

The easiest way to get the examples is using Git, which is a great and widespread tool for sharing and code on the internet. If you don’t have Git installed on your computer, we can return to our favorite program Homebrew and run

brew install git

from the terminal. Once Git is installed, navigate to the directory where you’d like the examples to be stored and run

git clone http://github.com/dronekit/dronekit-python.git

The DroneKit Python examples will download into the folder from which you ran this command. Navigate to the Vehicle State example by typing

cd dronekit-python/examples/vehicle_state/

and run

python vehicle_state.py --connect 127.0.0.1:14550

Note that we now have used all three of the sockets generated by MAVProxy (if you’d like to prove this to yourself, try connecting to 14550 with both DroneKit and Tower-Web) and the Vehicle State application will run. I’ll leave it to the DroneKit Python documentation to explain exactly what this program does, but needless to say you’ve run your first application on your virtual drone and are well on your way to writing your own.

I’d recommend running the rest of the examples, reading the documentation, and getting a rough sense of what they do. By the end of this, you should have a pretty good idea of what kinds of functionality is built into DroneKit Python and how you might write an application to control your real drone.

Step 6: Run the DroneKit Python example apps on Solo

SITL is fun and all, but we don’t read posts on DIY Drones to learn about controlling virtual vehicles. We want to control the real thing. Let’s try running some of these examples on Solo.

Simple Go To is a great one to start with. All of the locations are in Australia, so, if you don’t live with Tridge, open up simple_goto.py with a text editor (I like Sublime Text) and edit the lattituide, longitrude, and alitude in points one and two (LocationGlobalRelative(your lat, your lon, your alt). Next, test your changes in SITL and make sure you simulated Solo is behaving as you anticipated.

Once you are satisfied with your code, bring Solo out to your airfield, connect your computer to Solo’s WiFi network, and spin up MAVProxy to plumb the whole system together. For the lazy, the terminal command is

mavproxy.py --master=udpin:0.0.0.0:14550 --out=udpout:10.1.49.130:14550 --out=udpout:127.0.0.1:14550 --out=udpout:127.0.0.1:14549

You now can run

python simple_goto.py --connect 127.0.0.1:14550

from the Simple Go To’s directory and Solo will execute the Python commands and perform the mission. Pretty cool!

However, the observant reader might catch that in this case the code is actually running on your computer, not the computer on board Solo. To move the code and all of its dependencies on to Solo, we have to return to the Solo Development Guide and take advantage of some neat tools that the engineers at 3DR have written.

First, let’s install the Solo command line interface using pip

pip install -UI git+https://github.com/3drobotics/solo-cli

This CLI lets you run a number of useful commands from the terminal. For example, if you’d like to connect your computer to both the internet and Solo over WiFi, which is very useful for development, run

solo wifi --name=network name --password=network password

To run your example code on Solo, run

solo script pack

from the directory containing simple_goto.py. This command will prepare a package containing your Python application and all of its dependencies on your computer. To install and run (note that this is a single step) this package on Solo, connect to Solo’s WiFi network and run

solo script run simple_goto.py

Solo will takeoff and execute its mission based solely on the code you loaded onto its companion computer. You can verify that this by turning off your controller and seeing Solo execute its mission without an external signal in the loop.

Step 7: Controlling the camera and gimbal

Now that you’ve run the examples both in SITL and on Solo and spent some time understanding the various DroneKit Python functions, you are essentially ready to program your own Python-based GCS. It’s that easy!

However, one of the most amazing pieces of Solo is the fully controllable gimbal and camera. Simple camera functions haven’t quite made it into DroneKit Python and we at 3DR are still working to integrate all of the Solo-specific MAVLink messages into our SDK, but, because it’s close to Christmas and generosity is in the air, I will post some shortcuts here.

Both the gimbal and GoPro are controlled by MAVLink messages and DroneKit Python is backwards compatible with PyMAVLink, a great way to send arbitrary MAVLink messages to Solo. The general format of a MAVLink message sent through PyMAVLink is somewhat complicated. An example of a yaw message is below.

msg = vehicle.message_factory.command_long_encode(

        0, 0,     # target system, target component

       mavutil.mavlink.MAV_CMD_CONDITION_YAW, #command

      0, #confirmation

        90,     # param 1, yaw in degrees

        45,           # param 2, yaw speed deg/s

        1,           # param 3, direction -1 ccw, 1 cw

        0, # param 4, relative offset 1, absolute angle 0

        0, 0, 0)     # param 5 ~ 7 not used

I am no PyMAVLink expert, but, as we can see in both the comments and the MAVLink documentation for the yaw command, we use the vehicle.message_factory.command_long_encode function to pass an 11 argument message to some component. The first two arguments serve as the address of the message--0 and 0 refer to Pixhawk, which is doing the yawing. The third argument refers to what MAVLink message you’d like to send. Feel free to experiment with different messages. The fourth does nothing and the fifth through eleventh refer to the up to seven commands that can be passed through any MAVLink message. For this particular yaw command, only four are used--the amount of yaw requested, the yaw speed, the direction, and whether yaw should be absolute or relative to the position of the copter before the yaw was initialized. Now you’ve had the opportunity to look under the hood at DroneKit.

We will use a similar strategy to control the camera and the gimbal with one caveat--mavlink-solo-master is still private. We at 3DR are working hard to clean everything up for public consumption so these commands will work on board Solo, but not on your computer or in SITL.

To switch GoPro from video to photo mode, try the command below.

msg = vehicle.message_factory.gopro_set_request_encode(MAVLINK_GIMBAL_SYSTEM_ID, MAVLINK_GIMBAL_COMPONENT_ID, mavutil.mavlink.GOPRO_COMMAND_CAPTURE_MODE, (1, 0, 0, 0))

vehicle.send_mavlink(msg)

vehicle.flush()

Notice we are now using the gopro_set_request_encode variable rather than the command_long_encode, but the general format is the same. Here the system and component IDs, which were 0 and 0 for Pixhawk, are declared as variables rather than numbers. You can either include MAVLINK_GIMBAL_SYSTEM_ID = 1 and

MAVLINK_GIMBAL_COMPONENT_ID = 154 as constants in the start of your code, or just substitute these numbers for the text. Notice the MAVLink message is GOPRO_COMMAND_CAPTURE mode, which is not found on the list of Arducopter MAVLink messages. This is because it is found in the in the still private mavlink-solo-master and documentation has not yet been written. That said, I can tell you right now that switching the first bit in the message from a 1 to a 0 will switch the camera from photo to video mode. Cool!

To take a picture, I used the code below.

def take_a_pic():

   msg = vehicle.message_factory.gopro_set_request_encode(MAVLINK_GIMBAL_SYSTEM_ID, MAVLINK_GIMBAL_COMPONENT_ID, mavutil.mavlink.GOPRO_COMMAND_SHUTTER, (1, 0, 0, 0))

vehicle.send_mavlink(msg)

vehicle.flush()

Notice that this time I wrote a definition, so each time I want to take a picture in my code I can simply write take_a_pic().

To control gimbal, I wrote an eponymous definition, nadir_point.

def nadir_point():

   vehicle.flush()

   msg = vehicle.message_factory.mount_configure_encode(

           0, 1,    # target system, target component

           mavutil.mavlink.MAV_MOUNT_MODE_MAVLINK_TARGETING,  #mount_mode

           1,  # stabilize roll

           1,  # stabilize pitch

           1,  # stabilize yaw

           )

   vehicle.send_mavlink(msg)

   vehicle.flush()

   msg = vehicle.message_factory.mount_control_encode(

           0, 1,    # target system, target component

           -90*100, # pitch is in centidegrees

           0.0, # roll

           0, # yaw is in centidegrees

           0 # save position

           )

   print "mavlink message is:", msg

   vehicle.send_mavlink(msg)

   vehicle.flush()

This time it takes two MAVLink messages to get the job done, but it still does the trick. Now whenever I’d like to point the gimbal toward nadir, I simply call nadir_point(). If I wanted to be even more clever, I would write a function called point(XX) whose argument appeared in place of -90 in the pitch field so the function could be used to point the gimbal wherever I wanted.

You should now have all of the tools in your toolbox to write your own WHOZCHILLIN app.

Step 8: WHOZ CHILLIN

You can download my WHOZ CHILLIN code here. You can see that the user gets several different CHILL options. Go ahead and replace my GPS locations with your own and  give it a rip. Note that the CHILLIN app turns off the R/C failsafes. Test your code in SITL extensively before you even consider doing this.

Step 9: Future directions

But wait, you say. I promised that WHOZ CHILLIN would let me open a web browser and see an image of who was chillin’ on my roof. The code here just takes a picture that GoPro saves to the SD card that I have to pull out to take a look at. This is way too painful of a workflow to really be CHILLIN. You are right, but this is enough for now.

Instructions for grabbing stills from the video feed, setting up a Python server, and posting the result online will be contained in the next installment of Idiot’s Guide to DK-Python and soon you will be able to complete your journey to WHOZ CHILLIN.

I'll leave you with this picture of WHOZ CHILLIN at the basketball courts near 3DR.

"Drone Buzzes President Barack Obama's Motorcade in Hawaii"

Link here

Some guy, who received a drone for Christmas happens to be flying when Obama drives by, and the media goes WILD. But they ignore the hundreds of cars on the same highway that are a much higher risk to the president. It's going to be a big uphill struggle to get the society to overcome their fear of drones when the media panics like this. 

Imagine what the FAA would do if this toy had crashed into the presidents motorcade? 

I've been looking for a better way to protect my Iris+. Amazon recently had a daily deal on Pelican cases. When I saw the Pelican 1650 for only $150, I couldn't pass it up. 

I like the 1650 because I am able to fit everything in it, even though it is a little large. In my case I have:

• Iris+ with propellers on
• Iris+ controller with lanyard
• 2 batteries 
• LiPo bag (for charging
• Telemetry radio
• Long legs 
• Spare Props
• Iris+ tool kit
• USB cables (for telemetry)
• LiPo charger
• LiPo charger power cable

I'm pretty happy with how this turned out.