Blogs

Antennas are a critical part of any drone system -- whether for RF remote control or for telemetry & control. The cloverleaf antenna is a popular option owing to its reasonable gain pattern in the lateral directions and because of its circular polarization.  But it's always important to evaluate your antennas to make sure their performance is inline with specifications -- sometimes a simple little change in the antenna geometry can have massive ramifications.

A buddy of mine is an antenna engineer who has worked at Google and Apple on some of their iconic devices. He recently acquired some of the 3D Robotics cloverleaf antennas and performed an analysis. Some of the specs are a little off -- there’s no way a cloverleaf design achieves 18dBi gain (as mentioned in their specs); it’s more like 2dBi.  But the gain is still pretty respectable for a cloverleaf design; the radiation pattern is nice and isotropic (on the lateral plane); and the polarization is reasonably circular (axial ratio of 3.8dB means its a bit more elliptical, but good enough).

All too often, antennas seem like a “black box” to those of us who specialize in electronics, computer science, or mechanics.... so I was really excited when my buddy posted an approachable theoretical explanation behind the cloverleaf antenna (as well as others) over on his Antenna Theory website.

New video from Flyability showing a pretty unique use of their drone. Exploring the deep cracks within the Zermatt Glacier in Switzerland.

Some of the key features of FlytOS are:

1. Built on ROS: easily plug-in any of the advanced ROS modules for vision, swarm, SLAM, etc.

2. Rich APIs for Navigation, vehicle-setup, calibration, etc.

3. Onboard APIs for ROS, C++, Python.

4. RESTful and Websocket APIs for Web/Mobile.

5. Support for Pixhawk (PX4 flight stack), with linux companion computer.

6. Trigger onboard apps from remote mobile/web UI.

7. Easy custom-data plumbing between onboard apps and remote web/mobile UI.

8. 3D Software Simulator for testing apps, without access to drone hardware.

FlytOS will soon be available to the drone developers community. Support for APM and other popular autopilots/drones is also being added to FlytOS. Learn more about FlytOS, here.

You can start building/testing your drone-apps right away with FlytSim, a 3D software simulator, based on Pixhawk SITL (no autopilot or drone hardware required). Several interesting sample onboard (CPP, Python), and web/mobile apps are now available on github, to try out with FlytSim. Checkout the FlytSim Demo, below (Youtube link):

If you would like to use an optimized/tightly-integrated linux flight-computer, please join the beta program for FlytPOD here: http://flytbase.com

Documentation and sample apps for FlytSim and FlytOS can be found here: http://docs.flytbase.com

FlytSim is available for download here: http://flytbase.com/flytos/#flytsim

Here is the latest iteration if Silkopter in simulator action. Progress has been slow especially on the hardware side. Getting sensors working at 1Khz and realtime 720p video streamed at 30FPS on the raspberry pi 1 was a bit of a challenge that ended up with a spectacular crash (no video though). 

I had so much fun playing around with DroneKit Python over the last month or so, that I thought I would try my hand at DroneKit Android. Specifically, I was interested in building a customized version of Tower. As always, this blog post is cross posted on my blog with a little nicer formatting here.

The DIY Drones community is probably well aware of Tower’s expansive capabilities as a mobile ground control station, specifically with regards the built in autonomous mapping and scanning modes. Some tens of thousands of users are currently leveraging Tower to control their Pixhawk-powered drones, many of these for small business or large enterprise. However, these commercial users are stuck with a multitool when all they need is a knife. Tower has so many features and functions that it can be quite overwhelming for first time users to create even simple survey. Furthermore, it is fairly easy for even advanced users to make simple mistakes like accidentally pushing the drone into ACRO using the drop down menu up top.

For my first DroneKit Android project, I set out to create an Agribotix branded GCS for Solo AGCO Edition. This isn’t any kind of official AGCO product, but just a fun project I thought would help me learn about DK-Android.

Key features I wanted to explore in DroneKit Android were how to:

• Change styling, colors, and logos

• Remove unnecessary flight modes

• Fix camera settings

• Remove hobby oriented settings

• Force a UDP connection

While this project is obviously mostly an exercise in deletion, it served as a great introduction to what functions are available in DroneKit Android, how code is split between Tower and 3DR Services, and how a basic Android app is structured. Prior to this undertaking, I had never touched a line of Java or Kotlin or worked with an Android app, so I will assume the reader hails from a similar background.

I hope this guide inspires/enables some of you to create your own custom versions of Tower! My example apk is available here and my my source code is here.

Step 1: Get ready

If you aren’t already familiar with SITL, DroneKit, git, and the various developer tools I’ll mention here, head over to my Idiot’s Guide to DK-Python: A Journey to WHOZ CHILLIN and give it a quick read. You will be using many of the tools and concepts discussed previously to debug and test your custom version of Tower.

Note: DK-Python is fairly simple and well documented. DK-Android is not. If you are interested in an easier journey to a custom GCS, it may make sense to work in Python.

Next, download Android Studio. Google has built an incredible Integrated Development Environment (IDE) for building Android apps and you will be using it to do all of your work on Tower.

The Tower source code comes next. Because Tower is open source, all of its source code can be downloaded from the DroidPlanner GitHub account. Run

git clone https://github.com/DroidPlanner/Tower.git

from the terminal in the directory where you’d like to work on your version of Tower. Git will automatically download all of the files you will need.

Next open Tower in Android Studio. Alternatively you can use the VCS ⇒ Checkout from Version Control ⇒ GitHub flow to automatically import Tower into Android Studio.

Android Studio will then attempt to build the Gradle, which must succeed before you can do anything. If you just installed Android Studio, it will fail because you will need to install both the latest Android SDK and BuildTools. Wait for the Gradle build to fail and follow Android Studio’s instructions to get both of these items installed.

Finally, it’s possible to test your app on either a simulated device or a real one. On my computer, the simulated device runs very slowly, so I prefer to debug using a real tablet. To do this, you must plug your tablet into your computer’s USB and set it to developer mode. Briefly, find the Android Build Number section in settings and tap it seven times. After the seventh tap, you will see Developer Mode enabled and you will be able to run your code on the connected tablet.

Step 2: Build Tower

Now that you’re ready to roll, try building Tower yourself. First, click Run ‘Android’ under the Run menu. Assuming you’ve followed all the instructions in Step 1 successfully, Android Studio should compile the Tower source code and spin up a copy of Tower on your connected device. Cool! Now you never need to download compiled .apks of open source projects. You can just compile them yourself.

Go ahead and start up an instance of SITL and connect your compiled version of Tower, which should be called Tower debug on your tablet. You should be able to control your virtual copter just like the you can using the production version of Tower available in the app store.

Running your program is great for quickly testing your changes, but you will need to compile your own .apk for distribution. Try clicking Build APK under the Build menu, building your own version of Tower, and installing it on an Android device. Easy!

Step 3: Android app basics

I am definitely not the most qualified person to write this section and likely will have some errors in my assumptions, but I think my basic understanding is generally sound. If any of the Android wizards out here have improvements or corrections, I would love to roll them in. However, having spent some time bumbling through Tower’s structure without any background in Android applications, I hope I can provide a more accessible view into how to start digging in.

When you open Tower in Android Studio, you’ll notice two high level menus: Android and Gradle Scripts. Android is where most of the meat lives, but some of the files found within Gradle Scripts are responsible for very high level functions like the app name.

Within Android, you’ll see manifests, java, and res. manifests dictates what types of devices are compatible with our app. When you open the xml file within manifests, you’ll notice most of the file is concerned with various hardware configurations. For this project, we don’t care about hardware, but you might imagine that for your custom version of Tower, you might want to restrict users to connecting over Bluetooth and thus would like to throw up an error if a user tried to run your app on a tablet that did not have Bluetooth capability.

The java folder contains, not surprisingly, all of the java files that provide the structure of the app. However, in an Android application, the java files in many cases only serve as a general framework into which content is populated from the xml files found in the res folder. This will become abundantly clear as we walk through the tutorial, but Tower is a delicate dance between the java files in the java folder and the xml files in the res folder.

Take a minute to scan through the java and res folders with Tower open by your side and see what you recognize. I certainly was pretty amazed by how much I was able to understand by just generally scanning the code while poking through Tower. If there is a specific feature you are interested in, try Find in Path, Shift+Command+F on a Mac, and you generally can see where in the code base a specific feature resides. 

Step 4: Let’s try some easy stuff

So you think Tower is a boring name? Me, too. Within Android Studio, open the Gradle Scripts/build.gradle (Module Android) file. Head down to lines 140, 148, and 154. You’ll notice that you can replace Tower with a name of your choosing. I used Agribotix for my example, but let your creative juices flow.

Don’t like the Tower logo? Replace the ic_launcher.png logos found in res/drawable/ic_launcher with your own. The different files are for different resolution icons that are displayed on different size devices. If you want to be really fancy, you can use an online tool like this one to automatically generate all of these files from a vector image.

Want to establish some branding within the app? The sidebar seems like a good place to start. Head to res/layout/nav_header_main.xml. You’ll see something like the image below. The screen is split between Android Studio’s best guess as to how nav_header_main.xml will appear on an device and the actual .xml file. If you CMD + click on some of the elements, you can see how they are linked to the rest of the code. Try it and see. After playing around for a few minutes, it should be fairly obvious what’s going on inside this .xml file.

Now, let’s get to your custom branding. You can either do things the hard way or the easy way. The hard way is scan through the text and identify which lines of code likely correspond to which design element. Here, is is fairly obvious that android:text= specifies what the text in the header will say, but that’s not always to case. However, Android Studio is pretty amazing. You can simply click on the item of interest, say the text, and Android Studio will highlight what code is responsible for that element. Go ahead and change the background color, logo, and text to match your branding.

Great, now you should understand the basics of how Tower, and Android apps in general for that matter, is structured from a design perspective. I just identified a few specific touch points here, but with some pretty straightforward digging, you should now be able to completely own the style and design of Tower.

After you’ve tinkered to your heart’s content, go ahead and Run ‘Android’ or build an APK and see how it looks.

Step 5: Let’s dive a little deeper

Now that you own the design, let’s start to own the functionality. One of my biggest issues with Tower, especially when showing it off to a commercial user interested in mapping, is the 15 flight modes available from the telemetry bar. It is far too easy for a user interested in autonomous flight to accidentally kick the copter into ACRO mode and cause a crash. Let’s fix that.

This is the first time where we will be working at the intersection of Tower and 3DR Services. You’ll notice that if you navigate res/layout/fragment_action_bar_telem.xml, you’ll find the design responsible for this feature. However, what you will not find is the ability to add or remove menu items using a simple .xml file. Rather, you will see a reference to android:id="@+id/bar_flight_mode" when you click on the flight mode piece of the telemetry bar. If you search your app for that string, you will find a java file called ActionBarTelemFragment.java.

If you stare at this file for long enough, you will realize that the menu of options in the telemetry drop down is populated by FlightModeAdapter.

If you CMD + click on FlightModeAdapter, Android Studio will take you to a file called FlightModeAdapter.kt, which is written in a language called Kotlin, which is similar to Java. It may be worthwhile to stop at this point and download the Kotlin plugin for Android Studio to make your code look a little more beautiful. Inside FlightModeAdapter.kt, you will see that there is another layer to the onion.

Tower is pulling the flightModes from a variable called VehicleMode. CMD + click on VehicleMode and you’ll notice that Android Studio takes you to the locked VehicleMode.java. This file is locked because it is not actually part of Tower, but rather 3DR Services, which provides many of the functions called by Tower and DroneKit-Android apps. While you certainly could modify that file and compile a new version of 3DR Services, it is easier to step out a layer and try to address all of our changes from the Tower level.

To do this, reopen FlightModeAdapter.kt and put on your Java hat. flightModes is simply an array populated by 3DR Service’s VehicleMode variable. To remove elements from the array, we use the Java remove command. For example, to remove ACRO from your version of Tower, include  

flightModes.remove(VehicleMode.COPTER_ACRO)

underneath flightModes. For my app, I removed every flight mode aside from RTL, Auto, and Guided.

Great. Now build your app and make sure everything still works.

Step 6: Like Solo? Let’s make Tower connect automatically over WiFi (UDP).

Solo AGCO Edition users obviously are only interested in flying Solo. Bluetooth, USB, and TCP connections are painful for the uninitiated to understand and totally unnecessary. To force a UDP connection, open java/DroidPlannerApp.java. You can see that this file handles all kinds of connectivity-related functionality.

Around line 300, you’ll see

final int connectionType = dpPrefs.getConnectionParameterType();

If you look at the code carefully, you’ll see that we can cheat and short circuit the whole connection type selection process by just hard coding in a UDP connection. You’ll notice that the connectionType variable in an integer. If you do a little CMD + click digging, you’ll learn that that integer is 0 for USB, 1 for UDP, 2 for TCP, and 3 for Bluetooth. To force a UDP connection, we can just go behind all of the logic and menus and replace

dpPrefs.getConnectionParameterType()

with

1

Easy.

This cheat will not remove any of the UI, but no matter what connection type you specific, Tower will look for a vehicle over UDP. Which brings us to...

Step 7: Remove unnecessary menus

Now that we’ve hardcoded a UDP connection, we should remove all of the connectivity menus. And, while we’re at it, let’s get rid of everything else we find distracting. Personally, I don’t like the Flight History or Checklist top level menus and think the user is exposed to way too many settings.

Go ahead and open up res/menu/navigation_drawer_items.xml to clean up the navigation drawer and res/xml/preferences.xml to get rid of the preferences you don’t like.

You may find that with some of the xml items that you remove, you may have to find the associated Java reference and comment it out as well. This should be fairly straightforward to work through, but feel free to look to the Agribotix app for specific examples.

In this general vein, I also removed Dronie, Follow, and Land from the top level menus and everything aside from Spline Survey from the Editor screen, because the Solo AGCO Edition owners are essentially only interested in building maps. You can see how I did this by looking at what I commented out in java/org.droidplanner.android/fragments/control/CopterFlightControlFragment.java and /res/layout/fragment_editor_tools.xml

Step 8: Simplify the Editor screen for the optimal survey

Solo AGCO Edition customers use the editor screen to do only one thing: spline survey. They also user only one camera, GoPro, and should never have to play with sidelap or overlap. The mapping workflow can be dramatically simplified by hardcoding all of these values in, which is possible in java/org.droidplanner.android/proxy/mission/item/fragments/MissionSurveyFragment.java.

I started to get a little sloppy here (you’ll notice that I didn’t change the camera UI, although the camera is hardcoded to GoPro in the backend), but I hardcoded the camera to Hero 4 Black, the sidelap to 70%, and the overlap to 85%.

Step 9: Profit?

Whew! That was a lot of work, but in the end we created a custom version of Tower that is built to address specific user needs and reinforce a platform partner’s branding. Tower is a very extensible base for a huge variety of custom mobile GCSs, so I hope this guide makes modification a little more accessible for all of the 3DR platform partners out there doing great things with Pixhawk.

Hey DIY Drones here is a video highlighting my work over the last year.  I've decided to try and start a company automating tractors.  This is the first video highlighting my work.  

I'll be showing it an agricultural trade show that starts tomorrow, but wanted to post it here first as this is where I got my start.  If you have seen some of the earlier videos I posted this one has quite a few new shots I was saving so you will get a great overall picture of how it works in the field.  If you aren't familiar with it I am essentially using a pixhawk in the tractor and some custom GCS software in the combine.  Here is a link to the thread I started, http://diydrones.com/group/ardurover-user-group/forum/topics/apm-rover-in-tractor-setup and if you want to keep up most of the changes and code are now on github https://github.com/mattdreimer/AutonomousGrainCart ; I am extremely grateful for this community and the open source hardware and software. I am getting the chance to present at this trade show (Ag Days https://www.agdays.com/) the focus of the talk will be inspiring other people to try this with a heavy emphasis on why open source is awesome!

The UgCS team has accomplished what we believe is a first – integrating a Mode S/ADS-B out transponder with a small drone, enabling radar visibility throughout the drone’s flight.  A BeagleBone Black computer with CAN bus shield was used to integrate a Sagetech XPS-TR, the world’s smallest transponder, with the A2’s flight controller.  The flight controller continuously sent the drone’s location and commands through the CAN bus shield to the BeagleBone, which passed that information to the Sagetech transponder.  The transponder was powered by the 6S onboard battery, which also powered the drone itself.  The BeagleBone was powered by a separate 2S battery, but with a converter the same 6S battery could have been used for all 3 devices.

With an antenna located about 3m below the drone, the mission was a complete success, with the drone appearing and remaining visible on the website www.flightradar24.com throughout the flight.

Video footage of the flight can be found here: 

UgCS 2.8 will feature a communications interface with the Sagetech ADS-B transponder, enabling configuration of ICAO ID, Flight ID and Squawk Code parameters through the UgCS system.

For more information visit www.ugcs.com, www.sph-engineering.com, and www.sagetechcorp.com.

For inquiries please contact us: ugcs@ugcs.com.

Safe flights,

UgCS Team

At Erle Robotics we believe that Gazebo is the key tool for the future development of robotics.In order to help our community and users to simplify the process of algorithm with flying robots We’ve decided to put together a series about how to simulate Erle-Copter with ROS/Gazebo. Here are the first four episodes:

Episode 1: How to launch the simulator once the environment is set up

Episode 2: Testing ArduCopter flight modes

Episode 3: Automatic take off and land using ROS

Episode 4: Overriding the radio control using MAVROS

In addition to this we have created documentation where we explain how to go through the whole process.  We also recommend having a look to the series of videos that explain how to get started with the Robot Operating System (ROS).

“Start discovering the world of robotics with Erle Robotics.”

Many thanks to Alex Buyval for creating the initial Arducopter simulation on Gazebo. Also many thanks to Aurélien Roy and Maxime Lafleur to continue his work.

To DIY Drones (DIYD) Members and website visitors:  I am planning to terminate hosting of dronespeak.com, to focus on applying drone systems to address urgent problems with our environment.

New to DIYD? Excited to make your own drone system? You may want to copy pages from dronespeak.com for your personal use. Over 6000 Blog Posts (News Reports) and other items have been curated since January 2013 by using a managed vocabulary, a collection of DIY UAS topics, and methods other than bots. Read what DIYD members have said about announced UASs, UAVs, UAV sensing systems, and topics such as Sense and avoid, Crash, flyaway and recovery, New to making a UAV or drone system?, Traveling with a civilian or commercial drone system, and Aerial mapping.

I expect the future will include many do-it-yourselfers who want to make their own system, along with many more who would rather buy a complete package that is optimized for one or more applications/purposes. There will continue to be many viewpoints and opinions about the increasing numbers of drones and unmanned vehicles, by any definition, and for any purpose.

My thanks to Doug Starwalt and others for their support over the last three years. I am moving on to focus on problems where drones have potential to help, such as my crowdfunding effort to monitor declining kelp habitats.

Unless my plans change (maybe there is an offer that is hard to refuse?), I will retain the domain name and US Registered Trademark. DIYD members may contact me (the ‘John Githens’ near Seattle) through the DIYD email system. It’s been an interesting journey. Best wishes to you all for 2016 and beyond.

The SF40 controller board

In systems that need precise timing and accurate waveform generation it is sometime necessary to separate out the time-critical elements from the non-realtime processing. Even though interrupts and realtime operating systems can improve the timing response of a processor system, microprocessors are fundamentally sequential execution devices which makes it very difficult for them to transition rapidly between different time critical operations without introducing unpredictable delays. Also, unexpected software excursions to service rarely used routines can leave time sensitive peripherals hanging.

As an example of a time critical system, the SF40 LiDAR has to synchronize the precisely timed data stream from the laser with the position of the motor. At the same time, alarm updates and requests for navigation information from the flight controller introduce asynchronous demands on the processor.

The SF40 includes a three phase brushless DC motor to drive the laser sensor. This motor needs three, pulse-width-modulated (PWM) signals to synthesize the 120 degree phase shifted sine waves needed to produce the right magnetic field patterns in the motor. Whilst hardware PWM generators are now common on most microprocessors, they require software intervention to change their pulse width values and things start to get busy if you want to produce continuous, high resolution, smooth rotation in the motor. Adding in active control of the motor speed (5:1 control) and torque (100:1 control) and compensating for changes in battery voltage (6.5V to 30V) makes driving the motor even more complicated.

The SF40 separates out the non-realtime microprocessor functions from the real-time signal generation needed to drive the motor. It does this by combining FPGA fabric with an ARM Cortex-M3 microprocessor subsystem (MSS) in a SmartFusion chip from MicroSemi.

The MSS has numerous hardware resources that unload the processor from actions like buffering communications with the flight controller whilst simultaneously allowing interrupt driven communications with the laser.

The microprocessor subsystem

The MSS has a clock conditioning circuit (CCC) with a number of different clock signals that can be configured to give the best PWM frequency, processor clock speed and in this case there is also a clock to drive a servo.

The clock conditioning circuit

The MSS also has an analog co-processor engine (ACE) that continually monitors currents and voltages around the system as well as filters and rescales them. The ACE runs autonomously so the processor only needs to ask for the results whenever it needs them.

The control panel for the analog computing engine

The MSS is connected to the FPGA fabric through direct port pins and an APB (advanced peripheral bus). The functional components within the FPGA fabric are made up using standard library parts and custom VHDL modules.

Top level architecture of the SF40

One of the key items in the architectural diagram is a two port RAM embedded in the FPGA fabric that allows the processor to create and store the high resolution, three phase waveforms needed by the motor. The RAM is initialized by the processor and thereafter the motor driver module in the FPGA fabric reads the waveforms as fast or as slowly as necessary to drive the motor at different speeds. Using the RAM in this way allows for on-the-fly changes in modulation depth which lets the SF40 maintain constant torque at different motor speeds and power supply voltages. 

VHDL code for generating precise PWM waveforms

By combining the hardware controls in the FPGA fabric with software running in the MSS, the SF40 is able to have the best of both worlds in terms of precise timing and waveform generation along with lots of asynchronous processing capacity. IMHO, this type of architecture should be used more often whenever reliable interaction is needed between high performance processing platforms and the real world :).

The video below (enable audio!) shows a detailed overview of the new Pixracer flight controller.

It is the 4th generation of the Pixhawk flight controller family (make: FMUv4) and like the first generations designed by the Pixhawk Open Hardware team in collaboration with an international dev team. It supports the PX4 and APM flight stacks. If you like to try PX4 on it, follow the user guide.

Introduction

Pipeline – this is defined as a “special form of transport used to transport liquids (i.e. liquids and gases), or liquid mixtures with solid particles”. The issue of thermographic pipeline inspection applies to long-distance piping systems supplying variable media with a temperature different from the temperature of the surrounding atmosphere. By using thermographic systems, it is possible to determine and localize defects to pipeline insulation and leaks of the transferred media. In some cases, leaks can even be determined and localized in underground pipelines.

The reliability of the piping can suffer through poor design, improperly selected material or a defective construction of the whole transport system or from unexpected conditions when in the operation. This text deals with external piping systems that are permanently affected by atmospheric influences and are threatened by unpermitted interventions (mechanical damage due to lack of knowledge, accidents or intentional actions). The damage can be reflected as weakening of the cladding on the external insulation and leaks of heating energy, as well as breaks in the piping and the loss of the transported medium. At the same time, there is the risk of the wear on the thickness of the piping through internal corrosion (during the transport of aggressive liquids) or mechanical stressing (in the case of the transport of non-homogeneous materials with solid particles).

Aviation inspection of pipelines

To resolve the problem of inspecting long-distance pipelines, an elegant and simple solution is available at first sight. Application of UAV with a camera that can fly above the whole length of the pipeline while recording and displaying the monitored scene in real time.

The operator controlling the drone from a safe place has an immediate overview of the condition of the pipeline and if identifying a defect, can focus in detail and personally check the area. However, a traditional camera for the visible spectrum discovers only a fraction of the defects, or records only areas with visible damage or leaks.

A traditional camera does not detect defects to internal heat insulation and the escapes of media below the surface of ground. With the timely discovery of areas where the insulation is thinner or where the cladding on the tube is damaged, major accidents can be prevented that would result in economic losses and a threat to the health and lives of the public. A thermal camera can detect such defects and record the thermal radiation of objects. On the basis of the difference to the surface of the pipeline and the experience of the operator, hidden defects can be found.

The company Workswell developed the Workswell AIRvision system, which combines two camera systems - a visible spectrum camera (for inspection of visible defects found by thermal camera) and a thermal camera for detecting the problems mentioned above. The servicing software enables to remotely switch camera regimes, to record radiometric videos or to make static images in both the visible and infra-red spectrum. The operator sees the objects under the drone in real time or can analyse records and identify damaged areas.

Moreover, Workswell AIRvision, unlike similar systems, enables to manually set the range of temperatures, e.g. in the interval of 15 °C to 25 °C. Even this range of temperatures can be changed during the flight. Without the need to land, the system actual situation can be set for the system and to easily achieve the required thermal sensitivity setting, which is required for the localization of minor moisture defects or the most precise localization of large defects. Traditional photo documentation is required to localise a defect, therefore, the Workswell AIRvision video camera is of sufficient quality to produce a traditional photo. Moreover, the system can be fitted with a GPS sensor for storing information about the position of the drone when creating a record.

The system can measure temperature at the central point, as well as in the local minimum and maximum. Minimum and maximum are localized using a blue (minimum) and red (maximum) cross. This function can also be used to navigate drones because the system automatically shows where the largest potential problem is located.

Produced records are fully radiometric, including videos. After termination of the flight, the records can be evaluated using the Workswell CorePlayer software to produce a measurement report on measurement with the exact localization of the problems. For this reason, a photo is available of all produced thermal images (thermogram).

Individual photos from the radiometric video can be taken and used as separate thermal images (thermograms) to analyse a problem.

More informations about drone thermal imaging system Workswell AIRvision including datasheet and drawings.

PX4 has been flying Tailsitters, Tiltrotors and Quad Planes since last summer (instructions here), but we didn't get around to add support to our 3D Gazebo based simulator until now. As its standard-compliant MAVLink its easy to reuse and we've made it part of Dronecode.

The video shows a physically simulated transition of a Quad plane with Gazebo and QGroundControl side by side.

Just $67 and available now:

The PX4LITE is the next step in FC hardware with its powerful ST micro 32bit ARM Cortex core and massive I/O support. The PX4LITE is one of the most advanced autopilot systems available with support for almost any type of vehicle from a moon rover or a multirotor aircraft. Designed by the PX4 open-hardware project, it is supported by a number of development communities making this one of the most flexible and reliable platforms for vehicle control.

This Flight Controller has been changed from the original with the addition of an IMU which houses the safety switch, buzzer port, USB port and indicator light. This allows the IMU to be placed in a more convenient part of the platform for access to these components. Also removed from the original are non-common interface components.

Overall this is an excellent flight controller for your larger multi-rotors.

Features:
• Advanced 32bit ARM CortexM4 high performance processor, can run NuttX RTOS real time operating system
• 8 PWM/servo output
• Support auto and manual mode
• Micro SD card records flight data
• Removal of non-common components SPKT/DSM, CAN, AUX OUT ports
• Independent IMU Inertia control unit, built-in damping structure, can effectively reduce the vibration of copter
• External extend module integrate RGB LED indicators, Safety switch, Beep buzzer and USB module, greatly reduce installation space
• All interface (includes GPS/Telem/Power) are compatible with APM2.5/2.6/2/8

Specs:
Main control dimension: 63x44x17mm
Main control weight: 40g
External extend module dimension: 33.5x22.5x10mm
External extend module weight: 10g

Processor:
32bit 2mb flash STM32F427Cortex M4
Frequency: 168MHz, 256K Ram
32bit STM32F103 backup assistant processor

Sensor:
LGD20 3-Axis 16bit gyroscope
LSM303D 3-Axis 14bit accelerator/ magnetometer
MPU6000 6-Axis accelerator/ magnetometer
MS5611 barometer

Interface:
Futaba SBUS input & output
PPM signal input
PWM signal input
I2C interface x 2
Telem interface x 2
Power module interface
GPS interface

Included:
1 x PXLITE flight controller
1 x IMU module
1 x Connect cable
1 x buzzer

*PX4/Pixhawk is an independent, open-source, open-hardware project aiming at providing a high-end autopilot to the academic, hobby and industrial communities (BSD licensed)

*The reference to APM refers to the ArduPilot project, a family of open source autopilots based on the Arduino open source computing platform, developed by 3DR and the open source community. It consists of a choice of ArduPilot Mega (APM) electronics and a range of free software versions for different vehicles and is governed by an open source creative commons license. 

*Note: This is not an original Arduino brand product.

Hi all,

this is a short follow-up on my previous tests (I, II) with u-blox different u-blox M8 GPS modules.
This time I'll report about a survey campaign of several days with different copters and GPS. After processing the data I was surprised about the positional accuracy so I decided to share some numbers.

We used two copters running AC 3.3. One with an M8N and the other with an M8T GPS. The survey was conducted over a period of 4 days.

Six orthomosaics were overlapping:

Dataset   Day time
A         3   10:40
B         1   11:20
C         4   12:00
D         4   10:20
E         4   11:00
F         1   10:00

The orthomosaics were generated using direct georeferencing, i.e. without any RTK processing or ground control points. Hence, the final accuracy, or to be more precise the spatial offset between the maps, is a function of the accuracy of a single GPS and the image processing pipeline.

Since the flights were conducted over 4 days with different GPS and copter setups, the positional offset shows the overall GPS accuracy that can be achieved with M8 GPSs. The processing chain was the same for all datasets. However, there is for sure some influence as well. [I'll provide more details about image processing in my next blog post.]

Flight altitude was 50-60 m. Images were taken using a Canon S110. The size of the survey locations ranges form 5 to 25 ha (12-60 acre). The length of the entire area covered by the orthomosaics (from A to F) is 2.7 km (1.7 miles).

The maximum spatial offset between the orthomosaics is 1.2 m (3.9 ft). The average is 0.87 m (2.9 ft).

Overlay   Offset
A vs B    0.8 m / 2.6 ft
A vs C    0.6 m / 2.0 ft
B vs C    1.2 m / 3.9 ft
B vs D    0.4 m / 1.3 ft
D vs E    1.1 m / 3.6 ft
E vs F    1.1 m / 3.6 ft

Based on my previous tests I expected a much lower accuracy of about 2-4m maximum spatial offset. But it seems that both, the M8 GPS as well as the image processing pipeline, are pretty accurate and stable.

My next tests will be on RTK post-processing as well as the (promised) bench comparison between different M8 versions and antennas.

Best regards,
Thorsten

In a show of global technical solidarity, on June 25th, 2016 at 1700 hours  00 seconds UTC(GMT for some of us old folks), the world's "Global Synchronized Autonomy" event will occur. What is Global Synchronized Autonomy? Well, it's about using all of our highly synchronized devices and global networks to initiate a bit of local autonomy. You may have heard the saying "think global, act local"? That's exactly what this project is about. The idea is to "trigger" autonomous systems at the very second specified, globally, where autonomous systems includes flying robots, rovers, boats, planes, and, yes, humans. From a first order perspective, it's an opportunity to bring together the autonomous machinery community and let folks come up with creative/novel autonomous systems to trigger and enjoy in their communities. On a global level, we share in our ability to connect and collaborate in an uplifting manner. The loverobot.org site is the current place holder for the landing page and will evolve as we approach the date. Stay tuned for information, code, videos as well as practice countdown days going forward. Save the date and start thinking about how to participate. Giving rise to the Unoccupied Collective ~HooperFly (Art by Tim Bonvallet)

1BitSquared has just launched their German online store. This is the first dedicated Paparazzi UAV hardware supplier in Europe.

Paparazzi UAV (Unmanned Aerial Vehicle) is an open-source drone hardware and software project encompassing autopilot systems and ground station software for multicopters/multirotors, fixed-wing, helicopters and hybrid aircraft that was founded in 2003. Paparazzi UAV was designed with autonomous flight as the primary focus and manual flying as the secondary. From the beginning it was designed with portability in mind and the ability to control multiple aircraft within the same system. Paparazzi features a dynamic flight plan system that is defined by mission states and using way points as “variables”. This makes it easy to create very complex fully automated missions without the operators intervention. For more project information, see here.

With a store in Europe they can provide faster delivery times of Paparazzi UAV hardware for all the European users and developers. Now you can purchase Lisa/M(X), Lisa/S, Elle0 autopilots and accessories for Paparazzi UAV within Europe without having to pick up your order at your customs office. We hope this will make the entry into Paparazzi and working with the system easier, knowing that you can get new parts and hardware faster from a local supplier.

Check out the 1BitSquared DE store, if you have any questions or suggestions let us know in the Paparazzi UAV Gitter channel, esden is always there to answer your questions regarding the 1BitSquared products and online store. You can also reach 1BitSquared through their contact form, and the 1BitSquared Gitter Discuss channel.

Big news from Dronecode, where Qualcomm, whose Snapdragon Flight board was the hit of CES, has moved up to become a Platinum member. Also another 27 companies have joined.

SAN FRANCISCO – January 12, 2016 – Dronecode, the nonprofit organization developing a common, shared open source platform for Unmanned Aerial Vehicles (UAVs), today announced major milestones that include investments from 27 new member organizations and the formation of technical working groups to advance the Dronecode open source platform for UAVs.

With investments from more than 50 member organizations, Dronecode has nearly tripled membership since its formation. One of the founding members, Qualcomm Technologies, Inc., a subsidiary of Qualcomm Incorporated, has increased its investment to the platinum level as it introduces new products for the UAV ecosystem. Qualcomm Technologies, Inc. recently launched Qualcomm® Snapdragon Flight™, a highly integrated 58x40mm board targeted specifically for consumer drones and robotics applications. Snapdragon Flight is based on a Qualcomm® Snapdragon™ 801 processor, along with Dronecode PX4 open source UAV software and robust connectivity, bringing cutting-edge mobile technologies to create a new class of consumer drones.

The highest growth rate for drones or UAVs is commercial opportunities across applications in areas such as agriculture, energy, utilities, mining, construction and more (BI Intelligence’s “Drone Market Forecast 2015”). By uniting the industry around a neutral, open source platform, the Dronecode Project aims to help the drone industry overcome software and hardware barriers to accelerate drone adoption for these critical applications.

The newest Dronecode members include silver members Aerotenna LLC, AirMap, Airphrame, Altitude Angel, AutoModality, BirdsEyeView Aerobotics, CUAV, Droidika, Dig.y.Sol, DroneDeploy, DroneWorks Inc., Emlid, EnRoute, Falcon Unmanned, Hex Technologies Limited, Incite Focus, Inspectools, Matternet, ProfiCNC, Sentera, Skedans, Yin Yan Tech US Inc. and Zubax. New sponsored members include Humanitarian UAV network, OpenTX Project, Stanford University Aerospace Design Lab and UAVCAN.

The Dronecode Project is also forming three technical working groups to ensure better standardization and interoperability in the areas of camera and gimbal controls; airspace management; and hardware/software interfaces. Details include:

• MAVlink Camera Working Group: aims to assist camera manufacturers implementing the MAVlink protocol in cameras. The group will also work with developers and manufacturers to expand the Dronecode platform so that it can support additional cameras and functions.
• Airspace Working Group: formed to establish common data types, units and formats that all airspace providers can transmit and receive. The working group will also lead the discussion on best practices for how to ensure separation between aircraft(s) and establish agreement on common response behavior.
• Hardware Working Group: the mandate of the hardware working group is to establish mechanical and electrical standards for interfaces to the autopilot and the peripherals. This will create a more formal interface between hardware and software development and unite efforts between Dronecode members and the open source developer community working to advance UAVs.

“From increasing member investments to a growing, vibrant developer community, the Dronecode Project’s first year has been extremely exciting,” said Chris Anderson, Dronecode Board of Directors chairman. “By bringing efforts together to establish a common platform and utilizing open source best practices, we're able to build the foundation for a new era of drone applications that extend from the camera to the cloud. The Dronecode "full-stack" platform approach, combined with the hardware and software innovations of its members, will bring about a new generation of drones that are autonomous, aware of their environments, and continuously connected -- an airborne Internet of Things."

The Dronecode Project is a Linux Foundation Collaborative Project. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found atwww.linuxfoundation.org.

 

About Dronecode Project

Dronecode Foundation is a nonprofit organization working on a common, shared open source platform for Unmanned Aerial Vehicles (UAVs). Dronecode brings together existing and future open source UAV software projects, including the APM UAV software platform originally developed by 3DRobotics. More than 1,200 developers are working on Dronecode’s six projects focused on maximizing adoption of the project's cost-effective, reliable and technologically advanced UAV software. A Linux Foundation Collaborative Project, Dronecode is an independently funded software project that harnesses the power of collaborative development to fuel innovation across industries and ecosystems. https://www.dronecode.org

From Stitchkingdom:

Back in summer of 2014, Stitch Kingdom broke news that Walt Disney Parks and Resorts was working on an intricate system using controlled drones to supplement its nighttime entertainment, proposing to: use drones to control massive marionettes (such as an exampled Jack Skellington) and/or use drones to carry screens that could act as what they dubbed ‘flixels,’ or ‘floating pixels.’

In late October of 2015, Disney decided to move ahead with these plans by filing an exemption from the FAA under section 333 which governs the commercial use of drones. The application was published on December 31 and has not yet been answered by the FAA.

The exemption request defines the original plans further by noting that ‘Flixels’ refers specifically to Disney’s proprietary unmanned aircraft vehicle (UAV) system. The payload is defined a a show element which is a ‘physical structure or “special effects mechanism” weighing no more than five pounds that is securely attached to each multicopter [a four, six or eight blade drone, manufactured by 3DR] with eighteen pound tensile strength nylon cable ties.’ Further in the document, the application notes that the payloads may be larger than the drones themselves and are ‘typically an inanimate object’ and that drones will fly for approximately five minutes at a time in subnetworks of five multicopters each and will go no higher than 150 feet above ground level at a maximum speed of 6 knots per hour. Flight paths will ‘largely take place over water elements and restricted areas.’ As much of the document refers to Disney’s safety controls, Disney says the system will include geofencing that will prevent the UAVs from leaving their controlled airspace which will already be a minimum of 100 feet away from guest viewing.

According to the application, ‘Flixels are to accompany entertainment at the Walt DisneyWorld and Disneyland Resorts, including during each resort’s nightly Fireworks Spectaculars. Deployed from a monitored platform designated as the launch/land area in restricted access areas of each resort, Flixels will be “magically” incorporated into Disney story elements that engage and inspire children and their families. Once the show segment concludes, Flixels will return to the launching/landing area.’