DRONE DIARY - 1

FLYING CAMERAS FOR DIGITAL HUMANITIES

(Latest entries at the top. For Drone Diary 2, click here.)

A series of tracked flights with the AR.drone 2 testing joystick mode instead of "absolute flight". Several crashes, but the AR is light (and lucky) enough to survive unscathed.

(Click for a X3DOM model)

The QAV 500 v2 partially assembled. All the propellers sent were the same type, a few power cables not ordered, and no radios yet. (This beast weighs 1.9kg, 4 x AR.drone.)

Sun Oct 05 18:32:17 CEST 2014 Test flight and crash

Another test flight that ended with slight damage. Parrot's "absolute control" where piloting is done by tilting the control device (in this case an iPhone), is fine for close proximity flight, but it does not help much for training flight by FPV. The long, final loop (at the lower right) involved flying behind and around a tree. At that distance (the piloting was done from the deck of the house), it was difficult to judge the drone's proximity to the next tree.

For FPV with the AR.drone, use "joystick mode" and watch the console to see where the drone is going. This time the crash bent a propeller shaft. Easy repair.

The model on the right is an embedded interactive X3D file. Click, hold and drag.

Fri Sep 19 10:04:50 CEST 2014 Test flights at 3 archaeological sites

Left: Hunn (Vestfeltet) - Bronze and iron age graves.   Right: Hornes - bronze age petroglyphs (and a newer foundation structure)

Wed Sep 17 10:38:32 CEST 2014 - Flights at Remmen (Østfold University College) 20140325 and 20140917

The model of the campus was created with Sketchup and the tracks imported from the AR.drone's "userbox" file containing its GPS track, converted to GPX and then to altitude-colored KML at the GPS Viz website. The KML files were imported into Sketup Pro 8, saved, and reimported into the Sketchup (2014) model. Finally, VRML output from the Sketchup model was converted to X3DOM with InstantReality's aopt program. (Click the image to open the interactive X3DOM model.)

Mon Sep 15 11:34:17 CEST 2014 - Half sphere panoramas

Two sets of panoramas covering approximately the lower half of a sphere.

The images are generated from pairs retrieved from two Mobius cameras angled at 5° and 45° from the vertical.

The images are generated with 5 sec. timelapse from a continuously rotating drone in an attempt at stable loiter with no GPS assistance.

The drone's landing gear interferes with the horizon limiting the field of view to the lower third of the sphere.

Thu Sep 04 18:32:52 CEST 2014 - Mangled GPS track again - and a cat

Erratic track on 4 (the lower red and orange straight segmant track) satellites which improved with 5 (the upper blue tracks).

Tue Sep 02 181003 CEST 2014 - OK flight

The highest track shows a normal flight again demonstrating the AR.drone's inability to loiter in a fixed position. The lower track shows a normal horizontal flight.

Mon Jun 23 14:41:07 CEST 2014 - Repaired again

AR.drone repaired: Complete disassembly, cross, cards, ribbon cables, motors, bearings, shafts, gears, and propellers. Replaced cross and reassembled the lot. Success on first test. It wobbles about a bit, pretending to fly, then stabilizes. Elevation track is withing reaon, while altitude lost a set of Z-coordinates.

During a careful flight, with what is assumed to be a sufficient number of satellites, hitting the "home" button has it veering off. The erratic track indicates that it probably lost a satellite or two. Control: The AR GPS acquires 5 satellites, while a Garmin handheld gets 9. The chip should be good, but a patch antenna is obviously not enough.

Tue Apr 15 18:52:14 CEST 2014 - Final loiter test

Down into the open field which should give the GPS/FR more satellites for better loiter stability. The first flip should have been a warning, but the central cross arms, gears, shafts, and motor states in the controller program showed no indication of damage or malfunction.

First an initial flip and crash at takeoff, inspection and flight to 5.69m, whereupon the drone flips out of the sky.

flight_20140415_181159: 2014-04-15T16:12:02.024Z; 2014-04-15T16:13:52.804Z; 01:52 min; 4 - 5 sats; 108 trkpts

It is unclear if the crash was caused by a bad gear or broken shaft. The cross arm broke on impact. Either the shaft or gear may have been weakened in an earlier crash.

Tue Apr 15 15:38:06 CEST 2014 - Controlled loiter mode test

Three controlled flights testing loiter mode (hovering in position) with GPS FR (flight recorder.) In each flight, the drone takes off, hovers while the compass is reset. It is then flown vertically to a set elevation between 5 and 10m, where it is allowed to hover for a few minutes, whereupon the HOME button is hit, and when in a stable position, the LANDING button is hit. (The second flight is simply take off, compass reset and landing. The fourth image is an aggregate of all three flights.)

1. flight_20140415_143910: 2014-04-15T12:39:10.000Z; 2014-04-15T12:41:26.471Z; 02:15 min; 6 sats; 133 trkpts
2. flight_20140415_144206: 2014-04-15T12:42:06.000Z; 2014-04-15T12:42:12.647Z; 00:60 min; 7 sats; 8 trkpts
3. flight_20140415_144228: 2014-04-15T12:42:28.000Z; 2014-04-15T12:44:01.320Z; 01:33 min; 7, 6, 8 sats: 91 trkpts

Sat Apr 12 10:36:45 CEST 2014 - two long flights

Tue Apr 8 15:45:56 CEST 2014 - A plan forward

Step 1:

Rebuilding an AR.Drone airframe (cross frame, motors, esc's [electronic speed controllers], gears, and props), to use the PixHawk compatible, PX4IOAR open platform autopilot. Add radio control, GPS, and telemetry transfer/recording of track and state.

Aim: To build skill and experience with a flying lab-bench carrying a single, light weight camera payload and explore loitering capabilities for photogrametry.

This could also be a standard programming platform for teaching.

Step 2:

Build, or complete an RTF, Lumeniere QAV 540G airframe with a PixHawk open platform autopilot, GPS, telemetry recoding/transfer, stabilized and controllable camera gimbal, and FPV streaming.

Experience and results from the PX4IOAR platform can be transferred to the PixHawk autopilot. The airframe is a twin level configration with the upper "clean" frame separated from the lower power frame for vibration damping. There are also a variety of fixing points for added equipment.

An important factor in the QAV540g configuration is the ability of the gimbal mounted camera to rotate 180° vertically, which with the quadcopter's 360° of horizontal rotation would allow for complete, spherical panoramas.

Tue Apr 8 15:20:26 CEST 2014 - Not all drones are nice drones.

The Israel Defence Forces have extensive experience with UAVs for surveillance and are now using tethered drones...

... while a giant art installation in Pakistan is meant to deter "bug splats".

Tue Apr 8 14:48:17 CEST 2014 - "Loiter mode" doesn't work with the AR.Drone

Both of the illustrations of flight tracks above show the unreliability of "loiter mode", i.e. capability to hover in a fixed position which is stable enough to capture overlapping pictures for mosaics or panoramas.

All of the flights contain long attempts at loitering while rotating slowly or incrementally about the vertical axis.

(Both illustrations can be clicked for X3D models of the tracks.)

The AR.Drone has four sensors that appear to be used to track and maintain a position: the low resolution video camera which tries to detect high contrast points beneath the drone; the ultra sound system to maintain elevation; a barometer that tracks elevation; and the GPS.

(The drone only saves a GPS track that can be retrieved from the iOS control unit.)

As loitering is somewhat more stable when performing a continuous rotation, it would seem that no attempt is made to compare sensor intput to correct the position. However, neither the sonar, nor the contrast sensors are reliable when the distance to the ground exceeds 2m.

Loitering reliability deceases significantly when the GPS FR is in use.

Conclusion: While easy to learn and easy to fly, the AR.Drone is too light and underpowered for stable loitering while carrying the necessary paload.

Sat Feb 08 17:26:10 CET 2014 - Hovering in place

Wed Feb 05 21:23:56 CET 2014 - GPS essentials

The flight recorder GPS has 4 satellites or less on which to position. The radius of flight was never more than 5m. Both images are links to X3D interactive models. (See below for displaying in Safari and other WebGL conforming browsers.)

Lesson learnt: Confirm minumum 5 sattelites before takeoff!

In this instance the FR-GPS is receiving 5 satellites or more thus recording a significantly more accurate track of its position. The GPX (horizontal) track is a reasonably correct depiction of the flight track. The base track is the GPX without vertical component. The lower, colored track is "altitude" and the upper track "elevation" data from the userbox file downloaded to the iPhone controller.

Sun Feb 02 12:45:07 CET 2014 - Snow!

Left: Still struggling to maintain constant altitude and position to capture a sufficient number of images for a complete overhead rotational composite.

Above: The AR.drone appears to get confused by snow through its low resolution, downward pointing camera. Click above for an X3D, interactive model of two GPS flight paths over snow. (Enable WebGL in Safari with Preferences > Advanced > Show Develop menu in menu bar, and Enable WebGL from the Develop menu.) Get the Google SketchUP model here or add this network link in Google Earth.

The controller board on motor #1 (below on Fri Jan 24 14:07:42 CET 2014), turned out to be working fine. So the new main board with external antenna has been moved to the spare hull with the working central cross which has received the ball bearings for propeller shafts from the defunct cross. The former drone #3 is now waiting to become a spare drone when a new main board and central cross arrive.

At the left the altitude (orange), speed (yellow), and battery (red), profiles for a 4'55" test flight with the repaired drone #3.

A new FR-GPS is also on order, and when mounted, the photography tests of composite mosaics can start up again.

Sat Jan 25 20:58:53 CET 2014 - Why not to stick with the AR.drone

The AR.drone is a attractive machine for experimenting and testing, but has several flaws as a test bed for "laboratory" work.

• Relatively low, and specifically, variable range because of internal antennas on both the drone and in the controller (iPhone / iPad), resulting in too many uncontrolled flyaways.
• The hull has extensive surface for mounting cameras and trackers, but is not suitable for permanent, vibration free mounting.
• The AR.drone has sufficent power for flight filming with its forward pointing 720p camera, but when higher resolution cameras (specially twin cameras for stereogrametry) are attached, flight time is drastically reduced.
• The AR.drone is not able to maintain stable hovering altitudes for vertical composite mosaic photography.
• The AR.drone's circuitry and cabling interfaces at the surface mount level of its PCBs, complicating any repairs involving manipulation of the circuit boards.
• The drone's build quality is not robust enough to withstand minor crashes, resulting in excessive time spent on repairs.

Alternative drones?

From left to right: A RTF (ready-to-fly) DJI Phantom 2, with a bottom mounted gimbal for steadying a HERO3 camera. A TBS Discovery (RTF or kit), and QAV 540 G (RTF or kit). The DJI Phantom uses a HERO3 camera on its gimbal, so other cameras, such as the Mobius ActionCam has to be bolted on to that. The other surfaces of the drone are not suitable for attachment of ancillary equipment. The TBS and QAV quads are highly adaptable test benches that will accept a variety of radios, controllers, and attachable equipment. The QAV is distinguished by having a lower "dirty" frame that holds the motor arms, and an upper, "clean" deck mounted on (orange) vibration reducing dampers for video and photography equipment. With a multiple choice of navigation controllers, the "test bench" drones can be configured for optimal performance in a chosen flight mode, such as hovering, at the expense of speed and agility.

Fri Jan 24 14:07:42 CET 2014 - More time is spent repairing than flying.

Left: New antenna finally installed on a new main board. The board on the hew drone #3, came with the defective 8-pin interface with the navigation board described below, which resulted in another "PIC Watchdog EMergency" and a dead motor #1. A new main board is on order, and that from a spare drone from another program, received the new antenna. With antenna installed and drone reassembled. the drone was tested in the evening and worked - with all motors spinning up at boot time. The drone took off, hovered, and made a calibration spin indoors.

The next morning (left), drone #3 was taken out, loaded with 2 new Mobius cameras, and promptly reported a "Motor Emergency" (above left) with the status page on the controller software showing the motor #1 is dead. (Above)

Diagnosis (from the AR.drone groups): Bad MOSFET on motor controller board or bad connection the motor wiring in the central cross. So - first exchange motors with the spare. If that doesn't work, exchange the central cross.

More time is spent repairing damaged drones than flying photography experiments.

Both the AR.drone and controller (iPhone/iPad) have internal antennas, with very low range. The advertized 50m range is overly optimistic, resulting in loss of control with drastic consequences. Drone #2 was lost to just such a loss of communications.

That drone had a "wheel antenna" from www.dronemod.com. When the antenna came in the shade of the hull, during it's last flyaway, control was being lost and reception of a command to stop was too late.

For drone #3 a 7dB vertical antenna from ukgadgetsnow.co.uk, was chosen. The installation process includes soldering a UFL female plug on to the main board antenna test point, removing the inductor, and cutting a trace on the underside of the board. The main board and navigaion board have to be removed for the modification. During the disassembly, the soldering points of the 8-pin female interface with the navigation board separated from the main board solder points. Separating the main and navigation boards is a delicate, but necessary operation. Nevertheless, the solder points appear to have been cold, as the same operation, with due attention to that problem was done several times previously.

Thu Jan 23 18:11:03 CET 2014 - Successful stereograms

With the two Mobius ActionCam cameras mounted on a light foam plastic bracket for parallel alignment, successful left-right stereograms now depend only on vibration free hovering.

The lens distance for these tests is 55mm, but with the cameras aligned with the edges of the hull, lens distance would be a natural 70mm.

The position under the hull prevents interference with propeller wash, but necessitates hand launching and landing unless extra long landing gear is used.

It's beginning to look like a somewhat more versatile quadcopter, with longer and more reliable range is needed for this project.

20140119_132159 - Composite mosaic with HERO 3

Snow is a challenging test for software attempting to create a composite mosaic from several images. This composite is assembled from several pictures taken with a HERO 3 pointing down attached to the underside of a hovering AR.drone, and with minimal rotation.

The sentral parts of the image match well, but the edges have several mismatches and ghosting. Both the camera's very wide field of view, and the AR.drone's inability to maintain a fixed altitude while hovering contribute to the anomalies.

In real-world application, the composite would be cropped at the limit of correct matches. Useful composites however, would be made as composite mosaics from pictures gathered along a rough grid over the site, and taken by a camera with a lens of a more "normal" perspective.

For the next test of composite mosaics, reducing the horizontal flight speed to the absolute minimum, and setting a Mobius camera to 1-second shots, is a candidate.

Sun Jan 19 17:09:56 CET 2014 - Notes

• GPS (Flight Recorder) is flakey with horizontal accuracy varying between 5 and 20 meters, and vertical accuracy even worse. The latter is apparently dampened by the sonar height controller.
• The AR.drone is too light to be stable in wind.
• Sonar fools the drone, especially over leafless vegitation such as bushes, resulting in varying elevation during hover when the drone is rotated.
• 3D modelling of flight tracks can be made by converting userbox files from the GPS(FR) to GPX with "darklo's" Ruby script. The script can generate based on altitude or elevation. The GPX can be loaded into Google SketchUP, as can (colored) KML files made from GPX with GPS Visualizer (on line), and KML files from GPX made with GPSBabel. X3D models can be made from VRML files produced by Google SketchUP.
• Mosaics can be made from vertical photographs taken with timelapse (40mm equiv. lens) and processed with Photoshop / Photomerge. Panoramas - spherical or planar are made with GigaPano Pro by combing vertical and angled images taken as timelapse.
• All images for panoramas, mosaics, and stereograms are taken in vertical (portrait) format.
• Imagemagick used to batch modify images. Exiftool is used to inject elevational metadata into pictures for subsequent sorting of image groups from equal heights.
• Flight time loaded with 2 ActionCams, GPS(FR), LED, and GPRS ELT is around 5 minutes.
• Need to test simple dampening material for cameras. (Gel, suspension dampeners, bubble wrap, etc.?)
• DO NOT! a) Fly above 2m with battery below 30% capacity. b) Tempt the 50m range limit. c) Fly above 5m in wind.

01. Bare AR.drone (no battery): 293

02. Unloaded (w/ battery)     : 394

03. HERO HD                   :  99

04. HERO 3 (Black)            :  74

05. Mobius ActionCam (bare)   :  39

06. Mobius (with bracket)     :  49

08. GPS/CF Flight recorder    :  31

09. TK 104 GPS/GSM ELT        :  65

10. Mini A8 GPRS ELT          :  21

11. Wintec 202 GPS            :  57

12. Flashing LED              :   6

    Typical takeoff weight    : 530
    (2, 2x5, 8, 10, 12) 

PANIC! The ribbon cable between the navigation board and the ultrasonic sencor board ripped in a "moderate" crash caused by the drone suddenly moving the opposite way of the iPhone tilt.

The iPhone's accelerometer demanded calibration before every flight yesterday. iPhone problem or drone gyro problem?

(Notice the battery level at 0% in spite of full charge.)

AR.drone 2 carrying two Mobius ActionCam's fastened on each side of the drone with Velcro and manually set to fire "simultaneously" every 2 seconds. The light was low, Velcro is not a very stable or vibration-reducing fastener, the clocks of the cameras drift, and the cameras were not very well aligned. Lens distance in excess os 100mm. This arrangement needs a bracket giving better alignment and 70mm lens distance. How to achieve synchronized shutter relase is being investigated with the firmware programmer.

An alternative arrangement would be two GoPro HERO 3 cameras mounted in a bracket for alignment and synchronized with WIFI control.

Thu Jan 16 17:08:54 CET 2014 - Single HERO 3 (Black) and spherical panoramas

Two interactive, hemispherical panoramas assembled from images taken in our gymnasium with a HERO 3 (Black) as 12Mpx, 2 sec, time lapse images. The camera was taped on to the 45° "chest" of the drone, extended with a small foam plastic console, so as not to shade the sonar apertures. The camera was rotated 90° to cover a widest possible vertical field of view. The images subsequently batch rotated before being processed with GigaPano Pro. The left version was rendered as a sperical projection and the right as a mercator projection.

In spite of GigaPano's excellent ability to automatically find matching points in the images, the drone's vertical and horizontal drift, even in a closed environment is too great to create useable panoramas.

When the new Mobius cameras arrive, new test will be run with two cameras to cover the entire lower hemisphere.

(Click the images for interactive panoramas, and double click the panoramas for full screen display.)

Thu Jan 16 16:36:58 CET 2014 - History

A bit of nostalgia: This short clip shows the AR.drone (its green forward lights reflected in the window), examining the strange object suspended in our livingroom ceiling. From the early fifties up into the 80's, the entry level, handheld aircraft of choice for those willing to take the time to assemble them, were balsa gliders.

A lot of time was spent glueing spars and stretch paper on the wings. Glue, or "dope" varnish was applied in several layers to work up a surface that wouldn't tear on the first landing. Other problems were ballance and warped wood.

The lightest time lapse camera conceivable weighed many times as much as the glider, so an afternoon of flying involved no "post processing" other than occaisional repairs over the kitchen table.

Sun Jan 12 12:58:40 CET 2014 - Why stick with the AR.drone?

After all this frustration, yet another AR.drone is on its way in the post - so why stick with the same machine?

Cost and flexibility:

• While more expensive drones are attractive as ready-to-fly (RTF) machines, user forums complain of problems with "fly-away" for virtually all drones when used in environments that hamper GPS reception.
• Real life applications quite often entail environments with less-than-perfect GPS conditions.
• This project is not meant to be a test bench for kit assembly and attendant tinkering with navigation and video transfer technology.
• The AR.drone is a relatively sophisticated and reasonably affordable RTF drone that can be loaded with enough equipment to experiment with the photographic and photogrametric applications envisioned.

Sat Jan 11 18:21:56 CET 2014 - HERO HD

While waiting for a replacement drone and another set of Mobius cameras, and experiment with GoPro HERO HD.

Panoramas taken from a spare AR.drone carrying a HERO HD camera taking time lapse images every 2 seconds in horizontal format. Notice the empty (black) spot at the nadir. Also duplicated gaps in the 2- and 3- o'clock sector. This works better with vertical format images. (See Thu Jan 02 20:48:46 CET 2014 and Sat Dec 28 17:39:54 CET 2013 below.)

(All the images above are linked to larger pictures, the two tracks at lower left to larger X3D models, and the track at lower right to a Parrot movie. To view the X3D models, enable WebGL as in the Thu Jan 02 21:20:55 CET 2014 entry below.)

The aim of the project is to develop a proof-of-concept for an "affordable" flying camera platform that can be used for photo documentation and photogrametric applications in digital humanities.

On Thursday 20140109, a series of 4 test flights, one attempting a stable hover at around 25m above the house to make a panorama from one viewpoint, while the drone rotates and stops allowing the cameras to capture stable images.

The drone was loaded with its Flight Recorder (FR-GPS), two Mobius ActionCams (one down and one at ca. 45°), a Mini A8 GPRS tracker, and a flashing LED. The drone has an external wheel antenna for better communications, but when the body of the drone puts the controlling device (iPhone) in the signal shade, the link appears to drop out, and position is "held" by the FR-GPS receiver.

The first fly-away of the day took the drone, from the hovering position, into a tree southwest of the house. (Upper left) Ar.drones are quite robust machines, hook-and-loop fasteners held all the loaded equipment and nothing was damaged. After reassembly, a hard reset of the main board, and thorough testing, a short test flight confirmed that the drone was in good shape.

The second flight was a successful panorama hover above the house, testing the drone's ability to maintain stable altitude above a pitched roof, simulating varying terrain. (Left and right in lower row.) The GPX file from the userbox file shows a gap in the GPS signal, while the Parrot flight movie at the right appears to have its track corrected against a probability model.

The third flight brought the second fly-away. While attempting to fly a path circling the house, stopping at intervals to allow the cameras to gather sufficient shots for a 3D model, the FR-GPS took over at the south west and flew a circular course to the east, where the drone ended up in a brich. (Flight track second from left, lower row, and picture second from left top row.) A long ladder was sufficient to bring the drone down.

The final flight, another attempt at "circumnavigating" the subject, ended in catastrophe. At the end of the flight, just before bringing the drone down, the antenna came in the shade of the hull, the FR-GPS took over, and flew the drone toward the forest to the north. Control was regained, the drone tilted backwards to stop, but too late. It flew into the top of a rather high birch and is stuck ca. 18m up. (Last two pictures in top row.)

All the pictures from these flights are on the micro-sd cards in the cameras, and the flight data from the final fly-away is in the /video/boxes/ directory of the drone's motherboard.

• Don't fly with FR-GPS unless the track is needed
• When FR-GPS is used, confirm at least 7 satellite connections
• Don't fly high in anything but windless conditions
• Use a vertical or bottom mounted antenna for high alitiude flights
• Monitor the com link and battery status often
• When the com link appears to become errratic, turn and bring the drone down
• Flight attitude can become erratic at 30% battery load
• Don't consider the emergency button a last resort. It will be too late.
• If the drone gets stuck out of reach, at least attempt to salvage as much data as possible by logging in to the drone's computer before the main battery goes flat, cutting the link.

Various methods of retrieving the drone have been attempted. Cutting down the tree was rejected as it is on Church property. Tying a rope as far up the trunk as possible (ca. 6m), tying the other end to an even larger tree, then shaking the tree by pulling down on at the middle of the rope, just confirmed that the drone is solidly stuck in the upward pointing branches. Shooting a lead sinker with a slingshot to throw a thin line for a subsequent heavier line in order to shake the branches did not work. The sinker never came down as it stooped in the adjacent branches of the birch or close trees.

The evening and night of Thursday it rained continuously and by Friday morning the temperature was well below freezing. The LED was still flashing and the GPRS tracker still answered with the position shown on Thu Jan 02 20:27:04 CET 2014 below. 48 hours later, on Saturday evening (20140111), the Mini A8 is still answering! (Giving a position 125m off.) The LED, however, is much weaker.

The cost of renting a cherry picker is just about the same as the cost of an AR.drone with an FR-GPS, so all that's left is to wait for the wind to blow the thing down and salvage spare parts. After the recent rainfall, it's doubtful if a cherry picker could be set up in a stable posiition on the waterlogged ground anyway. The micro-SD cards, the SIM card in the tracker, and the flash memory of the FR-GPRS should be intact when thoroughly dried out.

All strenuous exercise, which is good for overcoming deep frustration.

Update Sun Jan 12 11:24:22 CET 2014: After a night of light snow and -5°C, the LED is still flashing, but the GPRS tracker no longer answers. It now looks a bit cold and forlorn.

Anomalies in the 2 versions of tracks extracted from the userbox file are mentioned below on Sat Dec 28 17:17:27 CET 2013

The illustration on the left is a screen dump from SketchUp showing three separate tracks. The blue pair to the left are gpx (no vertical component) and kml from a Wintec G-Rays GPS tracker carried on the drone for reference. The two others to the right are the gpx, altitude, and elevation tracks from the AR.drone's userbox file.

The dark red track at origo traces both the elevation and altitude versions of the gpx files converted from the userbox file, but with no vertical component. (This appears to be a bug in the gpx importer plugin for SketchUp.) The lower multicolored track on the vertical (z) axis is the "altitude" version of the userbox file converted to kml with GPS Visualizer (http://www.gpsvisualizer.com). The upper one is the "elevation" output of the userbox file similarly converted. The variation in the vertical component of the userbox tracks might lead one to surmise that "elevation" uses GPS data and that "altitude" uses a barometric sensor - judging by the wide discrepancies in the level of takeoff and landing points.

The older Wintec GPS chip is obviously less accurate than the AR.drone's Flight Recorder GPS.

The illustration on the right is an inline XDOM (x3d) model converted via VRML, which can be explored by holding the mouse button and dragging.

(Is there a way of converting SketchUp models to gpx for importing into qgroundcontrol and flight planning?)

Two panoramas assembled from one Mobius camera pointing 15° the other 60° above the vertical

This assembly was made by sorting the images according to the elevation taken from the userbox track and embedded in each image, in an attempt to use images as close as possible to a single position. The drone has a tendency to drift in very light winds, but it is also speculated (in user groups) that lack of a clear reference point on the ground on which the downward pointing (low resolution) camera can make a fix.

The separate pictures that make up the panoramas were taken on 2 sec timelapse. More images are needed at closer intervals while turning the drone. Some experimentation the "qgroundcontrol" application (a computerbased flight control program that can upload flight plans for autonomous flight), needs to be done to see if that can position and incrementally rotate the drone more precisely.

The drone has a downward pointing ultrasound sensor system, an accelerometer, and a barometric pressure sensor as part of its navigation system. The Flight Recorder unit additionally records GPS elevations. However, the "userbox" data files produce elevational data (through the userbox2gpx conversion script) only when the Flight Recorder is connected. The userbox file contains both absolute and relative elevations. (I have so far only converted absolute.) Often, tracks appear to end at elevations that are wildly different from the takeoff point, also true of the same track files on Parrot's server, but with differing elevational profiles. Horizontal components appear to be consistent and reasonably correct. The anomalies are being discussed with the author of the conversion script.

The paper presented at the IFAC World Congress Milano (Italy) August 28 - September 2, 2011, is limited to flight control systems and does not discuss elevation logging. (The Navigation and Control technology inside the AR.Drone micro UAV, Bristeau, et.al.)

(See Thu Jan 02 20:27:04 CET 2014 update above)

Portable, or "mini" trackers useable with multicopter drones come in at least three distinct forms - GPS, GPRS, and GPS/GPRS. The first simply stores a series of locations based on reception from GPS satellites. The track can then be retrieved from the tracker in various ways, depending on built-in functionality. In the pictures below from 20131122, the drone is shown carrying two such trackers. AR.drone's own proprietory (orange colored) "Flight Recorder". It stores flight video in its flash memory, which can be accessed as a normal USB device. (The flight track, in a proprietory format, is transferred to the iOS/Android control device at the end of the flight, where it can be retrieved. See "20131122 Flight track hacked".) Importantly, the "Flight Recorder" is used by the drone to navigate pre-programmed flight plans, but has also been suspected of guiding runaway drones. In the 20131122 pictures, the drone is also carrying a standalone Wintec WBT 202 GPS tracker, which records its track according to preprogammed parameters, time interval, distance moved, and speed. The stored tracks can be retrieved over a USB or Bluetooth connection.

The second type, GPRS trackers, of which the Mini A8 is one example, base their location on triangulation from the nearest GSM/GPRS mobile phone cell(s). GPRS trackers do not contain GPS receivers and are thus typically lighter than the other types. (The Mini A8 weights 30gm without its SIM card.) GPRS trackers require SIM cards and deliver their location data on reception of an appropriate

command from a telephone, delivering it as a SMS to the requesting phone. The Mini A8 has additional functionality such as passing on anbient sound when called up, limiting access to authorized numbers, etc.. The long/lat coordinates of the delivered location is given at the bottom of the extracted map, but can also be read from the WML-file itself. (Example below.)

Location accuracy based on distance from nearby cell tower(s) is necessarily dependent on the number of towers and signal quality. Low signal strength simply returns a discouraging "Location unclear" message. When a location can be calculated, a message is returned containing a URL at the producer's server which in turn brings up a Google Map extract showing the location. In the illustration above, the indicated location is about 300 meters from the actual location (red dot). In locations with a high density of cell tower antennas, location accuracy can be equal, and even better than many GPS receivers, but in sparsely populated areas, this type of tracker is not very reliable as an emergency location device.

The third type, GPRS/GPS, would be expected to be more suitable as they use a GPS receiver (in some models supplemented with GPRS location) to record the location(s), which is then retrieved in return for requests from a cellphone. The smallest of these trackers weighs 50gm, about the same size as the Mobius ActionCam.

The wheel antenna allows much greater range without losing contact and control. (Mobius ActionCams)

Tracks from 20131217 in SketchUp. (The yellow, green, and blue tracks below ground level are spurious or a bug.)

Ball bearings and standard brass bushing on the left and ball bearing with mounted propeller shaft at right. The bushings on the new cross were already loose and vibrating after a few flights.

Video from the onboard forward camera is now much more stable, with the obvious "shudder" of previous recordings absent. Do additional loads add to stability? Does the long foam plastic boom carrying the forward camera amplify vibrations in the camera when they occur? (Compare to video/20131207_142650.mp4 below.)

8-hour job. Drone disassembled completely to change the central cross, repair crash damages to the 2-o'clock drive, and add a better antenna. The forward boom was glued back together with epoxy and taped. All four drive systems with propellers, moters, and control boards transferred to the new cross. Navigation board and main board removed and some delicate soldering and other modifications performed on the main board in preparation for the new antenna.

Speed, elevation, and battery drain profiles of a 2-minute test flight after the repairs. The drone took off, rose to its hovering position and did a 360° calibration turn. Success!

Wheel antenna mast mounted on the 2-o'clock leg. Another payload reduction!

Almost ready to fly again - still waiting for ball bearings and GSM emergency locator.

Sun Dec 08 12:22:02 CET 2013 - Quadcopters at RoboHub

Sat Dec 07 17:45:13 CET 2013 - SKYJACK! - Hacking nearby drones.

"SkyJack is a drone engineered to autonomously seek out, hack, and wirelessly take over other drones within wifi distance, creating an army of zombie drones under your control. ... Today Amazon announced they're planning to use unmanned drones to deliver some packages to customers within five years. Cool! How fun would it be to take over drones, carrying Amazon packages…or take over any other drones, and make them my little zombie drones."

More here ...

Sat Dec 07 17:19:26 CET 2013

Another disaster!

While waiting for the ball bearings for the propeller shafts, another test flight with two Mobius ActionCams - one down, the other 45° forward - a fatal crash. At about 10m height, the circlip on the 2-o'clock motor appears to have detatched itself from the shaft. The propeller flew off and the drone immediatly fell out of the sky.

The 2-o'clock arm of the central cross broke on impact, and both cameras were torn off their velcro fasteners. Fortunately, we have a spare cross, so there's a major repair job to be done.

Mobius images during and after crash.

Still waiting for ball bearings, an SMS location device, and an antenna to provide more secure communications control with the drone, which will also extend the controlled flight range.

Films here:

• Forward video: 20131207_142650.mp4
• Down timelapse: 20131207_B.mpg
• Down timelapse: 20131207_B.ogg
• 45° timelapse: 20131207_A.mpg
• 45° timelapse: 20131207_A.ogg

Tue Nov 26 18:48:13 CET 2013 Next steps:

• Repair a set of broken gears and bushing
• Find out what happens to the vertical component of GPX coordinates from the Flight Recorder. It appears to be relative, not absolute. For now, they're taken care of by Sketchup importing the reference level from an external database.
• Test autonimous flight with qgroundcontrol
• Figure out a way to trigger the Mobius cameras simultaneously.
• Construct a stable jig for the two Mobius camers for stereo pairs
• Attempt to create synthetic 3D models from photographs using Agisoft Photoscan
• Aim? Cheap Digital Humanities topographic survey and modelling tool for archaeology, etc.

Wed Nov 27 20:58:09 CET 2013

• Worn bushings on the 2-o'clock motor replaced with ones from a spare central cross.
• The drone is flaying again - no serious vibrations!
• Ordered a set of 8 2x5x2mm ball bearings to replace all the bushings.

Tue Nov 26 17:12:10 CET 2013 Gears, propeller shafts, and bushings

The bent shaft above (caused by a crash) has worn its bushing oval (left). The cogs on the gear are also worn down. Result - gear slips off the small gear on the motor shaft (between the three screws), propeller suddenly stops, and the drone crashes. The bushing also has to be changed to prevent vibration.

20131124 Crash!

20131122 Flight track hacked:

(Larger version)

The drone is controlled with the FreeFlight app from an iPhone or iPad. When the Flight Recorder is connected and its GPS running with a sufficient number of satellites, the flight track is dumped into the Freeflight app's Document directory and can be recovered BEFORE the app is allowed to connect to the "AR Academy" (when it uploads the track and deletes it from the control device).

The track can be retrieved from the device with iExplorer and converted to the GPX format with the userbox2gps ruby script. The trace at the left in Sketchup 8 Pro has been converted from GPX with GPSbabel and the ingested with the KML plugin for Sketchup.

20131122 The second drone:

Loaded with a Flight Recorder (GPS and USB memory), a Wintec WBT 202 GPS tracker, both on top. Two Mobius ActionCams (39gr each), one downward pointing on the starboard side the other 45° down on the port side. Below right: a stereo pair taken with the Mobius cameras mounted in parallel.

2013111 It flew away!

2013110 Astounding flying machines

See also The Flying Machine Arena and Dynamic Works

20131108 First flights:

20131107

AR.drone 2 - runs Busy Box Linux

 $ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

BusyBox v1.14.0 () built-in shell (ash)
Enter 'help' for a list of built-in commands.

# help

Built-in commands:
------------------
        . : [ [[ alias bg break cd chdir continue echo eval exec exit
        export false fg hash help jobs kill let local pwd read readonly
        return set shift source test times trap true type ulimit umask
        unalias unset wait

# which vi
/bin/vi
# ls /bin/
US00_check                grep                      pwd
ash                       gunzip                    random_ip
bashproxy                 gzip                      random_mac
board_check               hostname                  repairBoxes
busybox                   init_gpios.sh             repairMicronesie.sh
cat                       ip                        reset_config.sh
check_update.sh           ipcalc                    rm
checkplf                  kill                      rmdir
chgrp                     kk                        sed
chmod                     ln                        sh
chown                     ls                        sleep
cp                        memory_check.sh           stat
cttyhack                  mkdir                     stty
date                      mknod                     sync
dd                        mktemp                    tar
devmem2                   mount                     touch
df                        mount_usb.sh              true
dmesg                     mv                        umount
dsp                       netstat                   umount_usb.sh
dspbridge                 nfs.sh                    uname
echo                      pairing_setup.sh          updateEphemeris.sh
egrep                     parallel-stream.sh        usleep
factory_reset_cb          parrotauthdaemon          vi
false                     pidof                     watch
fgrep                     ping                      wifi_setup.sh
fsck_msdos                program.elf               zcat
gdbserver                 program.elf.respawner.sh
getopt                    ps
# 

Børre Ludvigsen - <b@hiof.no>