Finally worth showing…

First video purely sets some context for the second:

This second is what the post’s about:

So here’s my take on “What was happening”:

The seconds video shows the GPS tracking is essentially working, except for the ‘minor’ fact she completely overran the target landing point, and once again, I ended the flight by encroaching her personal space i.e. the Sweep saw me coming and switched over to an orderly landing.

The problem is, I don’t think the problem’s mine.  Two facts to know before going further: the flight was twenty seconds long and GPS updates happen once per second.  So walking through the various logs from each process involved…

GPS process

GPS process logs

GPS process logs

There’s 18 GPS readings, plus the prerecorded target added to the graph manual by me afterwards.  18 readings is in line with the 20s flight, and the GPS defined distance between take-off and target point is a convincing 2.6m based on what you can see in the video.  What’s wrong is that during the flight, those 18 GPS readings returned only 2 values, shown in blue in the graph; they’re in the correct direction compared to the target which is great, but the distance between them is only about 0.27m.  This then explains everything that was wrong during the flight: because the GPS readings never got to within 1m of the target the flight continued, and because the 2nd point was in the right direction, the flight went in a straight until I got in the way.

Autopilot process

Here’s what the autopilot saw.  All that really matters is there were only 2 distinct GPS reading points, and the autopilot passed those two on to the main motion processing process as distance / direction target:

AP: PHASE CHANGE: RTF
AP: PHASE CHANGE: TAKEOFF
AP: PHASE CHANGE: HOVER
AP: # SATS: ...
AP: PHASE CHANGE: GPS: WHERE AM I?
AP: GPS TRACKING
AP: GPS NEW WAYPOINT
AP: GPS TRACKING UPDATE
AP: PHASE CHANGE: GPS TARGET 3m -151o
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: PHASE CHANGE: GPS TARGET 2m -150o
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: GPS TRACKING UPDATE
AP: PROXIMITY LANDING
AP: PHASE CHANGE: PROXIMITY (0.97m)
AP: LANDING COMPLETE
AP: FINISHED

Motion Process

Motion processing ignores the distance – it just proceeds at a fixed speed in the direction specified.  The flight ends when the GPS process says it is at the target GPS location, so the motion process just keeps moving in the direction defined by autopilot at a fixed speed of 0.3m/s.  The down facing video shows this well.  Note that the -150° yaw specified by the autopilot matches beautifully with the direction flown based on the gyro (where anti/counter clockwise is positive).

Down-facing video

Down-facing video

The flight in reality travelled about 3.7m by the time I got in the way; had she received a GPS point saying she’d overshot, she’d have doubled back, but that never happened.

Why didn’t the GPS receiver not see the movement beyond the first 0.27m?  I’m adamant it ain’t my fault (for a change), and the GPS receiver is the best I’ve found so far when tested passively.  Any ideas anyone?

As a by the by, on the second video, you’ll see both the LiPo (powering the motors) and LiIon (powering the RPi and sensors) now have electronic skiers’ hand / pocket warmers – without these, Hermione struggles to get of the ground, nor read all the sensors now the temperature outside is less than 10°C.

Leave a Reply

Your email address will not be published. Required fields are marked *