Finally found the fecking wobbles

I ‘think’ there are two factors: the colder temperature reduced the power of the LiPo; this then made the system a little less able to react to distance errors, causing it to rotate more to correct horizontal distance drift, and this in turn exposed a long term bug that completely failed to compensate for horizontal distance changes due to changes in pitch / roll angles (the code was there, but had a crass bug).

The cool LiPo has been fixed with a walkers / skiers pocket-warmer strapped firmly on top, keeping it lovely and cosy.

The crass video horizontal tracking error has been fix also.  As a result, GitHub has been updated, and naively once more I can continue working on the GPS tracking.

You scratch my back…

I’ll scratch yours:
Best Raspberry Pi Projects
They contacted me a week or two ago with a pre-written article for my approval; I’m never one to refuse free advertising, so having checked and every-so-slightly amended it, I sent them the OK for publication. Yesterday, the above arrived in my e-mail as a link to their free marketing (my words, not theirs).  There are a lot of other cool projects other than mine, so there may be something that tickles your fancy.  Make of it what you will.

P.S. I have visited their site: no nasty viruses encountered.

Indian Summer

It’s the 26th September, and the regular English “Indian Summer” has arrived: clear blue skies, no wind, and 18.2°C in the shade, 22.2°C in the sun.  Time to do some more testing on GPS to see it’s viability to use it as part of auto-pilot control i.e. flight plans defined by a series of GPS waypoints.

Measured by me, a tape-measure and a magnetic compass, the flight was about 13m long heading almost exactly (magnetic) west.  Here’s the raw data I got from GPS with a few bytes zeroed out so you can’t track me down!

latitude, longitude, altitude, satellites, epx, epy
51.000968, -1.000573, 85.323000, 9, 22.995000, 58.705000
51.000765, -1.000710, 81.490000, 9, 22.995000, 58.705000
51.000803, -1.000683, 81.943000, 9, 22.995000, 58.705000
51.000803, -1.000683, 81.943000, 6, 22.995000, 58.705000
51.000816, -1.000683, 82.107000, 6, 22.995000, 58.705000
51.000823, -1.000683, 81.487000, 6, 22.995000, 58.705000
51.000841, -1.000684, 82.436000, 9, 22.995000, 58.705000
51.000854, -1.000684, 82.601000, 9, 22.995000, 58.705000
51.000860, -1.000684, 83.385000, 9, 22.995000, 58.705000
51.000872, -1.000685, 83.549000, 9, 22.995000, 58.705000
51.000878, -1.000685, 84.334000, 9, 22.995000, 58.705000
51.000883, -1.000685, 85.118000, 9, 22.995000, 58.705000
51.000890, -1.000700, 84.518000, 9, 22.995000, 58.705000
51.000896, -1.000700, 85.303000, 9, 22.995000, 58.705000
51.000901, -1.000700, 86.087000, 9, 22.995000, 58.705000
51.000901, -1.000700, 86.087000, 9, 22.995000, 58.705000
51.000907, -1.000700, 86.871000, 9, 22.995000, 58.705000
51.000907, -1.000714, 86.892000, 9, 22.995000, 58.705000
51.000907, -1.000714, 86.892000, 9, 22.995000, 58.705000
51.000919, -1.000715, 87.056000, 9, 22.995000, 58.705000
51.000919, -1.000715, 87.056000, 9, 22.995000, 58.705000
51.000919, -1.000715, 87.056000, 9, 22.995000, 58.705000
51.000919, -1.000729, 87.076000, 9, 22.995000, 58.705000
51.000925, -1.000729, 87.861000, 9, 22.995000, 58.705000
51.000925, -1.000729, 87.861000, 9, 22.995000, 58.705000
51.000925, -1.000729, 87.861000, 9, 22.995000, 58.705000
51.000919, -1.000744, 87.096000, 9, 22.995000, 58.705000
51.000919, -1.000744, 87.096000, 9, 22.995000, 58.705000
51.000919, -1.000744, 87.096000, 9, 22.995000, 58.705000
51.000913, -1.000744, 86.312000, 9, 22.995000, 58.705000
51.000913, -1.000758, 86.332000, 9, 22.995000, 58.705000

It’s a 33 seconds flight, and there a 31 GPS samples.  There’s 9 satellites throughout barring a couple of samples.  Ignoring the first two samples, this data suggests latitude changes by (51.000917 – 51.000803)° or +12.23 meters (north) once converted to radians and multiplied by the average radius of the earth of 6,371,000 meters.  Longitude isn’t quite as simple to calculate as you need to know the latitude to work out the longitude distance; just trust me to say it’s -5.17 meters (west).  Alternatively, here’s the graph:

GPS drive flight tracking

GPS drive flight tracking

And if you haven’t spotted it, there’s a problem:  GPS says the flight was 13.5m* long at -22° or roughly NNW.  The distance is right, but the direction is out by 68° according to the magnetic compass’s direction of west  I checked with my iPhone compass and it agrees. I can’t explain this; it’s worked fine in the past, and to the best of my knowledge, satellites round here haven’t been shifted.  More digging required…

*Just out of interest, the ground video tracking measured the flight length as 8 meters – I really do need to fix the arbitrary scaling I’m using.

10°C and all’s fine

I think the problem with stability was a combination of Hermione’s new long legs’ weight distribution, combined with (perhaps) cold LiPo power.  Putting her back to the body layout above, combined with running the LiPo over a 33Ω resistor (0.5A at 4s cells ≈ 16V = 8W when she’s not plugged in) and normal behaviour has resumed.  Due to some diagnostics tweaks, the code is updated on GitHub.

Hibernation

It’s Autumn, and that means the MPU-9250 is running outside of its ideal temperature zone.  Every year, what flies beautifully during the summer deteriorates once the temperature falls firmly into the teens.  That’s what’s happened yesterday with ambient @ 15°C.  What was a rock solid hover two days ago has become unstable.  Previous years, I’ve been able to move indoors with one of my smaller models, but that’s not an option this year.  Hermione is simply too big to fly in the house and she needs to be this big to incorporate all the sensors and RPi 3B.  Additionally, GPS is virtually inaccessible indoors.

To make things worse, all summer Hermione has been running an IMU which is outside of the spec accuracy range: it reads gravity as 0.88g – her accuracy should be 3% not 12%.  She just about got away with it during the summer temperatures, but not now down in the teens.

Net?  I’ve a new MPU-9250 on the way which will meet their spec; this should help somewhat, but at the same time, I think it’s fair to say that like the hedgehogs and squirrels round here, Hermione will be going into GPS hibernation, and only waking occassionally to test the sweep mapping of the indoors with very limited lateral flight movement.

As I result, I have updated the latest code onto GitHub.

What the GP(S) saw

Hermione did two 2m straight line flights today, and both landed about 3.1m away measured manually with a tape-measure.  The stats from both flights showed Hermione thought she’d flow just the 2m:

2m from video POV

2m from video POV

So there’s a scale of 1.55 x real distance = down-facing-video distance that needs fixing.  The scale formula I used to convert the video macroblocks to meters was an informed guess, and it may just be missing a π/2.

The 2m square flight plan I flew and plotted the other day is actually a 1.8m square (0.3m/s for 6s) when I checked the flight plan earlier.  After applying the video tracking error scale of 1.55, this is the comparison of the rescaled flight plan against what GPS saw.

GPS vs. virtual reality

GPS vs. virtual reality

The square is about 3.95m diagonally, and the errors between this and the GPS plot seem to be ≈±0.75m.  Horizontally readings are about 1m apart whereas vertically, it’s more like 0.75m – not sure yet whether that’s how it works out due to our latitude, or if there’s a bug in my GPS processing.

What’s this all mean? First, I need to add a factor of 1.55 to the video, and second, GPS directed flights could be made to work after all if

  1. obstacles surrounding Hermione are at least a meter away, probably two
  2. destinations are several meters away, best guess is 5 meters or more.
  3. sweep gets turning back on!

OK, that’s better

Same 2m square flight, 10 satellites detected throughout, square direction is roughly SE → NE → NW → SW:

GPS square tracking

GPS square tracking

If you ignore any horizontal and vertical lines, what’s left are diagonals pointing SE, NE, NW and SW matching reality.  So net, the real directional / locations are there, but so’s a variable inaccuracy of a few meters.  That means that GPS tracking should be possible, but the flight target distance needs to be longer (i.e. a 10m square in order to fly the square based on it’s 4 GPS waypoint corners)  and there needs to be some softening in the changes in GPS locations before they are passed to the motion processor as the direction to fly.

Just in passing, the compass / magnetometer showed takeoff at 160° which is a lot more SSE or S than the GPS SE – there’s clearly more work I need to do on compass calibrations as there’s only a degree or so here between true and magnetic north.

Compare and Contrast…

the 2m squared flight tracked with fused IMU, LiDAR and Video…

Fusion tracking

Fusion tracking

against GPS:

GPS tracking

GPS tracking

The vertical axis for fusion is the height in meters; for the GPS, it’s the number of satellites. This is complete garbage; a standard chart shows more clearly what’s happening:

2D GPS track

2D GPS track

The difference between the 1st and 2nd GPS has an error of roughly -27 by -11 meters after which, every following dot seems to be a combination of the square tracking combined with some sort of settling which slowly removes the error initial -27 by -11 error.  It’s time I did more investigation into how to handle a GPS warm-boot.

Back to basics

I’m back from “Hell on Earth” (a.k.a. Disneyland Paris).  I’m still hunting for a decent GPS receiver that provides anything like the reception level of my DJI Mavic.  It’s a bright sunny day outside, and the Mavic GPS can see a stable 10+ satellites; the minimum level it will use GPS flight tracking seems to be about 9 satellites.  In comparison, Hermione seated in the same position can only see between 4 and (occasionally) 8 satellites depending on which of the 5 GPS recorders I have.  This may explain why my 2m square flight GPS tracking was so poor.

I have one more arriving in the next week or so upon which I have high hopes.

Until that arrives, my focus is on fine tuning the existing code.  Primarily, this is the vertical velocity PID gains; during a flight, the maximum value from the Z axis accelerometer is ±4g – the maximum configured – whereas the average is just over 2g.  Because it’s hitting the maximum, that means the integrated velocity is less that it should be, meaning Hermione continues to climb when the motion processing thinks she’s hovering.


Sod’s law struck again: just after first posting this, the new GPS receiver arrived and it was no better than the others.  The best of the bunch is the GlobalSat SiRF Start IV which has reached 11 satellites on a good day.

I also did some quick testing on the acceleration and it’s reporting a 5.91g ascent peak and -4.58g descent peak.  Tweaking the PID to reduce P gain and increase I gain just made it sluggish, but the peaks remained > ±4g.  For the moment, I’ve just updated the code to us ±8g range.  Another possible source could be noise from the props’ minor damage.  I’ll just tolerate this for now while I’m playing with the GPS tracking.

SLAM dunk

Once last brain dump before next week’s torture in Disneyland Paris: no, not crashing into inanimate objects; quite the opposite: Simultaneous Location And Mapping i.e. how to map obstacles’ location in space, attempting to avoid them initially through random choice of change in direction, mapping both the object location and the trial-and-error avoidance and in doing so, feeding backing into future less-randomized, more-informed direction changes i.e. a.i.

My plan here, as always, ignores everything described about standard SLAM processes elsewhere and does it my way based upon the tools and restrictions I have:

  • SLAM processing is carried out by the autopilot process.
  • GPS feeds it at 1Hz as per now.
  • Sweep feeds it every time a near obstacle is spotted within a few meters – perhaps 5?
  • The map is 0.5m x 0.5m resolution python dictionary indexed by integer units of 1,1 (i.e. twice the distance GPS measurement) into whose value is a score (resolution low due to GPS accuracy and Hermione’s physical size of 1m tip to tip)
  • GPS takeoff location = 0,0 on the map
  • During the flight, each GPS position is stored in the map location dictionary with a score of +100 points marking out successfully explored locations
  • Sweep object detection are also added to the dictionary, up to a limited distance of say 5m (to limit feed from Sweep process and ignore blockages too far away to matter).  These have a score of say -1 points due to multiple scans per second, and low res conversion of cm to 0.5m
  • Together these high and low points define clear areas passed through and identified obstructions respectively, with unexplored areas having zero value points in the dictionary.
  • Height and yaw are fixed throughout the flight to local Sweep and GPS orientation in sync.
  • The direction to travel within the map is the highest scoring next area not yet visited as defined by the map.

The above code and processing is very similar to the existing code processing the down facing video macro-blocks to guess the most likely direction moved; as such, it shouldn’t be too hard to prototype.  Initially the map is just dumped to file for viewing the plausibility of this method in an Excel 3D spreadsheet.


P.S. For the record, despite autonomous GPS testing being very limited, because the file-based flight plan works as well or better than the previous version, I’ve unloaded the latest code to GitHub.