The nut behind the wheel…

and a flat battery, but the concept was proven:

Once the stable hover at one meter has attained, the RC takes over: look for the yaw, the forward lateral movement, the height gain, and the awfully unstable landing due to the battery running too low.

As a first live trial it’s brilliant; next step: charge the batteries, and get the human trained to use the RC better!

Obstruction avoidance test 2 – PASSED!!!!!

After a minor tweak to the handling resolution of the Scanse Sweep data, all works brilliantly.

This is a five metre forwards flight, with the flight paused and later resumed once the obstacle has been avoided.  Note that ‘H’ tracks the obstruction at about one meter away.  Hence she flies a quarter circle around the circular cardboard tube, before continuing the forward flight when the obstruction is behind her.

The code is updated on GitHub as a result.

Obstruction Avoidance Overview

Here’s what ‘H’ does detecting an obstacles within one meter:

Now it’s time to get her to move around the obstacle and continue to her destination.  All sensors are installed and working; this is pure code in the autopilot process*.

Here’s the general idea for how the code should work for full maze exploration:

  • Takeoff, then…
    • hover
    • record current GPS location in map dictionary, including previous location (i.e index “here I am” : content “here I came from” in units of meters held in a python dictionary
    • do Sweep 360° scan for obstacles
    • find next direction based on the current map contents either…
      • unexplored unobstructed direction (beyond 2m) biased towards the target GPS point (e.g. the centre of the maze)
      • previously visited location marking the current location in the map dictionary as blocked to avoid further return visits
    • head off on the new direction until
      • obstacle found in the new direction
      • unexplored direction (i.e not in the map so far) found
    • repeat

And in fact, this same set of rules are required for just avoiding obstacles, which is good, as I doubt I’ll ever be able to find / build a suitably sized maze, and if I did, the LiPo will run out long before the centre of the maze is reached.

* The fact it’s pure code means it’s going to be quiet on the blogging front apart from GPS tracking videos when the weather warms up.  I’m also considering building a new version of Hermione from the spares I have in stock, provisionally called “Penelope”.  She’s there for shows only; I can then use Hermione purely for testing new features without worrying about breaking her prior to an event.


What’s left?

  • Refine the u-blox NEO-M8T to use the “pedestian” model algorithm which is more accurate than the current “portable” model used.
  • Test the yaw code I’ve been working on in the background so ‘H’ always points in the way she’s going.
  • Stop swearing at Microsoft for the Spectre and Meltdown updates they installed this morning which has crippled my PC just loading web pages!

Sixty seconds sanity check

A 60 seconds hover in preparations for my next GPS tracking flight on Wednesday when the sun will be out:

Weather conditions are poor today: light contrast is low due to thick clouds and the temperature is about 3°C.  The code is using the butterworth filter to extract gravity from the accelerometer, and the hover height is set higher at 1.5m to avoid the longer grass in the field next door on Wednesday: takeoff at 50cm/s for 3 seconds to get away from the ground quickly; descent is at 0.25cm/s for 6 seconds for a gentle landing.  The aim here is to move the down-facing LiDAR into a zone where it’ll be more accurate / stable vertically, while checking the down-facing video still provides accurate horizontal stability at this higher height, lower contrast lawn surface.

The check has passed well, boding well for Wednesdays GPS field flight!

Worth a Betta Bitta Butter

I suspect the low temperature increasingly unstable GPS tracking flights are partly due to the LiPo power (fixed with the hand / pocket digital warmers), and partly the accelerometer drift over time / temperature.  The problem with the latter is that gravity is recorded at the start of the flight and hence is fixed, meaning that accelerometer drift during the flight results in velocity and distance drift as the integration of (accelerometer – gravity) grows .  This is currently overcome by having second sources of velocity and distance (down-facing LiDAR + video) fused with the drifting IMU integrated (accelerometer – gravity) values.  The instability sets in over time as the IMU velocity and distance values drift increasingly over time but the LiDAR and video values don’t.  Ultimately these sources increasingly diverge and the instability ensues.

I remembered using a Butterworth IIR filter to extract gravity from the accelerometer dynamically 3 years ago to account for the accelerometer drift in cold temperatures, but it either failed or I got distracted by a better solution.

Yesterday, I tried again, but this time with a little better understanding: I now have a way to prime the filter without taking many seconds to do so.

Here’s the result: a stable hover without drift despite the LiDAR / video disabled – only the IMU status is in use:

Once the windy weather’s gone next week, I’ll be heading out into the next-door field again to fly with more GPS-waypoint intermediate targets, and this time, hopefully I’ll be able to complete the flight without the increasingly instability seen so far.

Here we go round the Mulberry bush.

Yesterday it was a cold and frosty morning, but more critically, sunny with only a light breeze:

28/12/2017 BBC weather forecast

Thursday’s weather

So I managed to squeeze in another test flight, where the plan was to fly ‘H’ between 3 GPS wayspoint frisbee-markers from a takeoff in between all three.  As you can see, reality deviated significantly from the plan.

I’d made a minor change to the code such that the maximum horizontal speed was 1 m/s reducing proportionally as ‘H’ got less than 5 meters from the target e.g at 3m from the target, the speed is set to 0.66cm/s.  That worked well approaching the first red frisbee-marker after takeoff.  However the next phase, although heading in the right direction between red and orange frisbee-markers, was very unstable and ultimately overshot the orange frisbee-marker, so I killed the flight.  Here’s what the flight controller saw:

GPS TARGET 6m -69o
GPS TARGET 6m -69o
GPS TARGET 5m -70o
GPS TARGET 4m -71o
GPS TARGET 4m -73o
GPS TARGET 3m -75o
GPS TARGET 2m -78o
GPS TARGET 2m -82o
GPS TARGET 1m -86o
GPS TARGET 1m -90o
GPS TARGET 2m -117o
Flight time 20.242111

The green text is from takeoff to the red frisbee-marker.  The yellow section shows a good heading towards the second frisbee-marker.  It started at the right speed of 1m/s while more than 5m away, but the red lines show velocity increasing to 2, 2 and 4 m/s as H got closer to the orange frisbee-marker.  On the plus side, she knew she’d overshot the target and had been told to double back at the point I killed the flight -check the angles at the end of the red lines.

Time to go bug hunting – it’s hopefully just a stupid crass typo on my part.  Luckily, the kids go back to school on Tuesday, and the weather forecast so far is looking good that morning:

Tuesday's weather forecast

Tuesday’s weather forecast

I hope by Tuesday I’ll also have worked out how to get better video quality from the Mavic!

P.S. No crass bug found, so my second best guestimation is that the LiPo cooled to below optimal performance temperature; this has the same effect as seen, and I had set the heater elements on the lowest level. The plan for the next flight is identical to before, but with the heaters on high and with full logging enabled in case this also fails and I need to diagnose in detail the source of the problem from the lateral velocity targets.

Perfect, nearly!

With a minor tweak to the u-blox NEO-M8T GPS receiver configuration, ‘H’ headed off in the right direction, making subtle changes of direction as she got closer to the pre-recorded GPS target point, and when within one meter, hovered briefly before landing. Only down side was the LiPo was at under 40% by then (it started at 48%), and that seems to be the point there’s not enough power for a stable descent, hence the very chaotic landing.

This is probably the last test for 2017 due both to the weather forecast and the chaos of Christmas.  See you all in the New Year – have a great holiday break!

P.S. The latest code has been updated on GitHub.