Blogs

This post first appeared in sUAS News 'The Market'

---

We just released a new report titled “The Truth about Drones in Construction and Infrastructure Inspection.” The report is the second in series of studies sponsored by BZ Media (creator of InterDrone Expo) that looks objectively at each major commercial market for drones and drone technology.

In this report we show how drones have been used successfully in construction and infrastructure asset management as aerial image and data capture devices thus far, review competitive and traditional approaches using incumbent technology, discuss the opportunities and challenges posed by the technology itself, outline the lessons learned, and discuss what’s next for drones in this industry. Here is an excerpt:

“Unlike The Truth about Drones in Precision Agriculture, where satellite and manned aircraft image services have been available to growers at low costs for years, construction and inspection professionals have had historically few options.  Up until now, the process for construction planning and documenting was mostly manual and done from the ground — and hiring helicopters or aircraft to take aerial images was either too costly or logistically impossible due to airspace restrictions.  The simple truth is small drones — in particular multirotors — can fly lower and closer than traditional aircraft and capture more useful detailed information.

In the inspection world, unmanned aircraft have a distinct cost and safety advantage over using people on ropes, ladders, scaffolding, and bucket trucks.  For example, a rope-access inspection at a wind farm can involve two or three workers who need at least half a day to get the job done in order to produce a series of photos for a report.  This can cost $1,200-$1,500 every 12-18 months – in addition to the costs incurred from shutting off the turbines for at least half a day (see details here).

There are many other examples of the benefit of drones vs. traditional approaches. This article points out that the Minnesota Department of Transportation (MDOT) recently completed a study on the benefits of using drones to inspect roads and bridges. MDOT estimated that a standard bridge deck inspection costs $4,600, takes eight hours, a crew of four people and heavy equipment. The same inspection with a drone takes just two people and two hours, at a significantly lower cost.”

The report goes on to summarize the proof-of-concept projects for drones done by hundreds of firms across the globe – not just for construction but also for civil infrastructure and asset management purposes.  We explore the major project types according to a commonly used building lifecycle framework of design, construction, operation, and demolition.

You can get a copy of the free report here

If you have questions about what’s in the report or would like to comment on it after reading it please comment below.

Thanks

Colin

Andrew recommended that I look at pixfalcon as a smaller pixhawk for some of my RC planes, so I got one for a bixler 2 build (he did recommend pixracer too, but that one has 6 PWM outputs instead of 8).

Here's my blog post on a bixler2 rebuild with a pixfalcon and Brotronics PowerTowerRX with backup lipo and buzzer:

http://marc.merlins.org/perso/rc/post_2016-07-11_Bixler2-conversion-to-Pixfalcon-with-Micro-HKPilot-Telemetry-Radio-_-OSD-and-Brotronics-PowerTowerRX.html

I have mixed feelings about the pixfalcon: It looks like good hardware in a small form factor, and I can live with the few limitations like missing I/O ports, but the choice of yet another set of incompatible plugs is just silly, not even using the same ordering for the 3 wires in I2C is beyond silly, and not providing ground and VCC on 7 of the 8 servo cables, is not a good idea if you expect people to use it in planes.

Sadly, those shortcomings combined (not counting some other ones detailed in the blog post, like wires so thin for the analog video on the OSD board that no enough current could reach my camera), make this board quite a pain in the rear to use to be honest (I spent probably 2 days finding and working all those issues, most were unnecessary and none of which are an issue with a real pixhawk). Then, if you add that the board does not get powered from the servo rail and seems to only rely on power from the power module which itself has a cheap and inaccurate current sensor, it's not all rosy.
Virtually all these problems are easily fixable, so I'm hopeful a pixfalcon v2 would fix this, but for my next plane build, I'll likely buy a different small pixhawk clone, that said the pixracer probably won't be an improvement there as far as cables are concerned, so are there others I could/should look at?

Power module:

Combined OSD + short range telemetry radio due to lack of external antenna (also it may be responsible for some OSD code freezes in flight):

Google Cardboard your Drone!

This is a new Android App for running a Heads Up Display on a SmartPhone using Google Cardboard glasses to hold the smart phone.

I have posted a free version on dropbox at https://www.dropbox.com/s/iysadmr511nvwlr/QtGstreamerGoogleCardboard.apk?dl=0

Your phone will need to have side-loading enabled to install the app. Please google on how to side-load an app.

This app will overlay the HUD on a video stream using GStreamer in two distinct panes for viewing in the Google Cardboard viewer.   The app supports both a single and dual video stream, and depending on the processing power of you phone, it' possible to have a stereo view using multiple cameras. 

The App will automatically listen for a MAV-Link data stream on UDP port 14550, the default UDP port for MAV-Link for the HUD telemetry items. To support both the video and telemetry, you will need to supply both data streams to the phone, or for a simple WiFi camera without telemetry, you can connect directly to the camera for live video.

Scenario #1: Simple connection to WiFi Camera

In the App video setup menu, (top-left toolbar) supply this string for the GStreamer pipeline:

souphttpsrc location=http://10.0.0.1:60152/liveview.JPG?%211234%21http%2dget%3a%2a%3aimage%2fjpeg%3a%2a%21%21%21%21%21 ! jpegdec

This string is for the Sony QX10. For other cameras, you will need to know how to connect and get the live stream using a standard GStreamer pipeline. I would suggest experimenting with GStreamer on a PC first to discover the correct string, then use it in the Android app. 

For a Kodak PixPro SL10 camera, I found this string to work:

souphttpsrc location=http://172.16.0.254:9176 ! multipartdemux ! jpegdec

In the UI configuration menu (top-left toolbar) select, "Split Image" to get the same image on both viewing panes. This is for a single camera configuration.

Scenario #2: Companion PC (Raspberry PI) with camera and PixHawk/APM Telemetry

There is a blog post currently running about using the Raspberry PI as a Companion Pi 2/3/Zero, so I will not give details here on how to setup the PI to get telemetry via the PixHawk/APM telemetry port, please refer to those pages for instructions.

If you have a Raspberry Pi with a camera, you can use this setup:

On the PI:

raspivid  -t 0 -w 1280 -h 720 -fps 40 -b 4000000 -o - | gst-launch-1.0 -v fdsrc ! h264parse config-interval=1 ! rtph264pay ! udpsink host= $1 port=9000

The "$1" argument is the IP address of your SmartPhone.   This command is for 720p, but you should consider the resolution of the device and adjust accordingly.  It makes no sense to send a 720p video to a phone with a 800x600 display.

In the Android App, configure the gstreamer pipeline with this string:

udpsrc port=9000  ! application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse ! queue ! avdec_h264

For telemetry, I suggest using MAVProxy on the Raspberry Pi, and send the UDP stream to the phone's IP address and UDP port 14550.  The Raspberry PI should be acting as a WiFi access point, and the phone configured with a static ip address.

If you want to display data on a ground station PC and the App at the same time, you can use MavProxy to split the UDP stream, and then connect to your UAV using Mission Planner. 

Here is a sample command that I use to split the data stream with MavProxy on the Raspberry Pi.

mavproxy --master=/dev/ttyAMA0 --baudrate=115200 --out=192.168.1.1:14550 --out=192.168.0.3:14550

In this case, the phone is at IP address 192.168.0.3 (static IP address) and Mission Planner is running on a PC at 192.168.1.1.  Check your phone's documentation on how to setup a static IP for WiFi.  It's usually in the 'Advanced' section of the settings in your phone.  You will also need to configure your Raspberry PI to have a static IP address for it's WiFi access point. The actual MAVProxy settings will depend on how you setup your PixHawk/APM, so choose the correct baud rate you have configured in the flight controller.

Another thing to consider is the processing power of your device. If you see a lot of pixelation, your device is too slow, so you will need to change the resolution of the transmission and/or the bitrate. Some smartphones are just too slow to display the video at full resolution. I have tested 720p on my Google Nexus 6 and it works fine, but on a cheap tablet PC, I had to slow it down and switch to 800x600.  

In part two of this blog, I will explain how to setup the dual video stream and more advanced configurations for high-power/long range FPV using an antenna tracker and the Ubiquity Nano/Rocket M5 ground station access points.

Happy Flying!

Observer VTOL Hybrid UAS from Vertech Imaging on Vimeo.

[Updated the PCB/SCH with the latest version:

- added a diode for the LEDs to drop the voltage from 5V to lower so the input (3v3) is lower than 0.7 VCC

- fixed some parallel traces on the top and bottom of the board

- broken out i2c on another pin header]

I started working on a custom FC board for silkopter and soon I will receive the first PCBs.

It's meant to be used as a Raspberry PI HAT and all the software (silkopter) runs on raspbian.

The board is 2 layout and can be printed (I hope, still didn't receive them yet) using DirtyPCB for ~30e for 10 boards. It was developed with the free version of eagle (hence the 2 layer limitation) in the past week.

Eagle schematic and PCB layout are on github 

My goal with this board is to have solid, long range RF integrated into the board, add sensor redundancy and experiment with SMD as a side quest.

Sensors:

- Dual MPU9250 9-axis IMU, one on SPI and one on I2C. They will both perform @1Khz

- Dual MS5611 barometer, one on SPI and the other on I2C @100Hz for both

- ADS1115 16bit ADC for current/voltage sensing

- Input for a serial GPS like any ublox (3.3V signal)

- Input for a serial sonar like MaxSonar. Works both with UART and RS232 signals (normal or inverted, 3.3V both)

RF:

- Either a RF4463F30 board (-126dBm sensitivity, 1000kbps, 30dBm power)

- Or a RFM22B board (-126dBm sensitivity, 256kbps, ~20dBm power)

Outputs:

- 6 PWM. I plan 4 motors and 2 for gimbal

- 3 RGB leds (NeoPixels or WS2812b)

A skilled developer could adapt Arducopter to support this board in 1-2 weeks. The trickier part would be the RC part to make it use the RF board instead of a classic RC receiver.

I'm also developing a custom RC system with a Raspberry PI, a touchscreen for FPV digital video (800x480 resolution, 2000kbps), a 3 axis gimbal for yaw/pitch/roll and a motorized slider for thrust control.

I'm working now on the component selection and schematic.

The build log is  here.

Feedback is welcome, it's my second PCB ever and my first one with SMD and especially a QFN package.

As we are so happy about our national football team, Drotek will offer a 5% discount on our entire store for people who sign up at euro.drotek.co before kick-off (Sunday 9 pm, French time). 

If France wins it will become a 10% discount!

People who sign up can also choose to prognosticate on the score, those who get it right will get an additional reward! 

Cheer for France with us !!!

Go to : euro.drotek.co

Discount code will be sent at the end of the match

This is a single lens spherical vision camera capable of streaming 360 x 240 degrees Field of View (FOV) video. It is optimized for drones and robotics due to its small size and weight.

The viewer can visualize the live or recorded stream as either a 3D georegistered video bubble placed on the map or enter the sphere for a more immersive experience. Additional viewing modes are: “Virtual pan-tilt”, “target lock-on” and “video draping” where the video Region of Interest (ROI) is rectified in real time. The VR-Eye cam software is also compatible with Android based VR headsets i.e. Gear-VR or other generic VR headsets that work with Android Smartphones i.e. Google cardboard. An iOS version is on the works.

The VR-Eye cam software can combine the spherical video with the MAVlink stream and offer a unique “geo-registered” view where the video sphere is placed on its exact location and orientation on the map.

The video below is a screen recording of a real-time stream as received by the ground station. The immersive video can be viewed live using the VR-Eye cam software or VR headsets and simultaneously recorded. The recorded video can be reproduced for post mission analysis where the viewer can select and monitor the camera surroundings from any desired camera angle combined with geolocation information.

For more information about the VR-Eye cam click here

The VR-Eye cam is expected to be in production early September 2016

As the first half of 2016 screams into the rear view mirror, sUAS News brings you sUAS Guide Issue 2. Lots of happenings in the last few weeks including the FAA finalizing the Part 107 ‘small UAS Rule’, which we will see come into effect in August this year. A great step forward to foster the growth of more commercial small UAS businesses in the USA.

Issue 2 – July 2016 https://joom.ag/ZcpQ

In this edition we bring you insights on Part 107 from experienced folks in the industry, as well as the same on the business and technologies side of things. Thank you to all those who contributed to this issue!

We hope you enjoy reading the material as much as we did. Don’t forget to subscribe to sUAS Guide to get notified when new issues are published. If you have any questions, feel free to email Tiaan :- tiaan@suasnews.com

Dronestagram, the first social network dedicated to aerial photography has just announced the winners of the 3rd International Drone Photography Contest organized in partnership with National Geographic.

More than thousands of pictures were submitted across three categories:
Nature/Wildlife, Sports/Adventure & Travel and it's been a very hard mission for the jury to make a selection.
The competition was judged on creativity, photographic quality and respect of the theme by a panel of experts including Deputy Director of Photography at National Geographic Patrick Witty as well as Emanuela Ascoli, Photo Editor of National Geographic France and 
Eric Dupin & Guillaume Jarret, co-founders of Dronestagram. 

Who are the winners of this edition? Find out a preview here below!

1st Prize Winner – Category Sports Adventure: Moab Rock climbing by maxseigal

1st Prize Winner – Category Nature Wildlife: Kalbyris forest, Denmark by mbernholdt

Here's a primer on custom geofencing with Solo, which has never been easier. It has just been released in the new 3DR Solo app for iOS and will be coming to Android soon: (Correction: all the other features in the latest Solo iOS app, such as rewind, are coming to Android in the next month or so, but we do not have an Android ETA for geofencing yet. Sorry for the confusion on that -- I read the internal roadmap too fast and missed that)

On your map view, you can enable or disable geofencing. When it’s on, you will have four points (like dropped pins) that you use to make a virtual quadrilateral flight cage around your drone. Solo uses GPS to set and obey this boundary. You can move your four points to change the shape, size and location of your quadrilateral at any time in flight, blocking off any objects or areas you choose. This also means that if you want to fly in another area, simply move your pins on your screen and you’ll create a new safe zone — or you can turn the geofence off altogether.

Why this is important:

• It works.

• Safe: Because it’s a hard fence, it really does keep your drone away from objects, even power lines.

• Customizable: If you don’t want that hard fence there, you can move it to where you want it, or easily disable or enable it.

• Engaging: Perhaps the most important advantage. Instead of stopping you from thinking about the environment around you, like hardware sensors would do, geofencing keeps pilots engaged and aware. This level of interaction with your drone and with your environment is critical for any truly holistic approach to drone safety, as opposed to blindly trusting an imperfect technology.

It's customary and traditional that we celebrate the addition of every 1,000 new members here and share the traffic stats. This time it's 79,000!

Despite the site being on-and-off down for nearly a week over the past two month as you can see on the right side of the traffic graph above  (the fault of Ning, our hosting provider -- you can see the sorry story of their tech issues here), we still had more than a million page views this month.  

We've known we were going to have to eventually going to shift off Ning, but it looks like the time is now. I'm been evaluating Jamroom, which has a special service to migrate Ning networks, and so far it looks good. Anybody have experience with Jamroom and would like to help with the migration?

The deal lasts only for 48 hours - do not miss the offer!

If you are upgrading your fleet to Linux-based autopilots or would like to install RTK navigation or do precision mapping - we have deals right for you!

Reach is capable of up to 14Hz centimeter-level accurate navigation, has plenty of of space for logging RINEX and supports NTRIP corrections natively.

With Navio2 you can run ArduPilot and your own applications alongside it directly on Raspberry Pi which makes it a perfect platform for drone hackers and for educational purposes.

Everything is in stock and ready for worldwide shipping by air mail or DHL express.

To get the discount go to our shop and use coupon code “reach4th” during checkout to save 71USD on Reach RTK kit or “navio4th” to save 30USD on Navio2 autopilot.

Lately we have been experimenting a lot with drones equipped with RTK GNSS receivers.

In our setup we used North Surveying RTKite receivers together with Pixhawk flight controllers.

This is a short video with fully automatic flight of 2 drones using RTK GPS. Initial distance between drones was 2 meters, vertical separation 2 meters:

We also conducted a lot of flights to test real-life precision of RTK-equipped drones.

Our test scenario was pretty simple - in take-off in automatic mode, horizontal movement of 10 meters, return to home and land.

We have compiled a table of measurements which can be found below.

It is pretty clear that in RTK Lock mode drones have very high precision. The precision can be even better – we didn’t tune PIDs and the wind was quite high, so the drones had a little drift just before touchdown.

With the RTK base station switched off, drones had precision similar to usual GNSS receivers, perhaps a little bit better because RTKite is  L1/L2 receiver.

A word of caution for everyone eager to use RTK receiver as the main one connected to the autopilot and used for navigation, not only for geotagging - we found that in situations when RTK receivers loose RTK lock, the autopilot can suddenly get very different coordinates. This may cause the autopilot can send the drone in an unpredictable direction. This is especially dangerous when flying at low altitudes.   

We are currently working on this issue together with North Surveying support to assure smooth transitions between different RTK receiver modes.

For any inquiries regarding the RTK system, feel free to drop us a PM or e-mail us at ugcs@ugcs.com

More information on our ground station software UgCS can be found at www.ugcs.com

Good luck and safe flights,
UgCS Team

When it's time for a drone to fly itself home, we for years settled for a a straight line back, "as the crow flies". That's obviously inadequate, since there could easily be a tree or large building in the way. So 3DR improved that with Solo, with the "Rewind" feature, which finds the shortest path back through the known-good area that the drone has already flown through. 

Now that same technology is coming to the open source PX4 flight code. A preview is shown above. Smart.

From BAE, the ultimate DIY Drone:

Ahead of this years' Farnborough International Airshow, engineers and scientists at BAE Systems and the University of Glasgow have outlined their current thinking about military aircraft and how they might be designed and manufactured in the future.

Native support for the uAvionix PingX ADS-B receiver is now available in beta of the 3.4 code for Copter, Plane and Helicopter.  Below is the procedure for loading the firmware on your Pixhawk/APM autopilot to visualize ADS-B compliant aircraft in your operational vicinity.

• Verify that you are running the latest version of Mission Planner
• Open Mission Planner and click “Install Firmware” from the “Initial Setup” window
• Use the Hot Key command “Ctrl Q” to access Beta/Trunk firmware (V3.4dev) and click load
• Once the firmware update is complete, power cycle the autopilot
• Verify a successful update by viewing “Flight Data–Message” window located in the bottom left corner of Mission Planner
• Set ADSB_ENABLE to “1” in the Mission Planner parameters list
• The default plug-in on the Pixhawk autopilot for pingRX remains TELEM2

Just for the next day -- get it while you can!

Comes with the latest 2.4 software with such features as Smart Rewind RTL, Panos, and Ziplines (on iOS now, and Android catching up to latest features next month)

.

The version without gimbal is a great and cheap open source development platform. We use dozens of them for swarming (instructions coming soon) 

This video shows a test flight of the HackflightSim quadcopter flight simulator, with a new feature: a simulated "companion board" (Raspberry Pi, BeagleBone, ODROID) running machine vision code written in Python with the OpenCV library. This software allows rapid prototyping of machine-vision algorithms before deploying and testing them on an actual vehicle. In this simple demonstration, we are running a threshold-based detector for blue components in the image: non-blue pixels appear as black in the detector, and blue pixels appear as white. Clicking the Play button on the simulator starts the simulation and then launches a Python script that reads successive images from a simulated belly camera on the vehicle. By grabbing the image bytes directly from the V-REP simulator using a C++ plugin (rather than the slower vision sensor built into V-REP), we get an on-the-fly resizable camera image and realistic update rates of 35-40 frames per second. The C++ firmware flying the simulated vehicle is the same as what we run on our actual quadcopters, and the Python code running the machine vision algorithm can likewise be deployed on an actual companion board with no modification.