As I mentioned in my previous post, I was planning to enable my landing prediction code for my next flight. This code is based on some work that Steve Randall did a few years ago, but using a slightly different technique as I was using a Pi and therefore had plenty of RAM available for storing wind data (Steve used a PIC). I wrote the code as the first stage in having a HAB guide itself to a predetermined landing spot, and knew that it worked pretty well using stored data from one of Steve’s flights, but hadn’t got round to trying it for real.
The way my code works is this:
- During ascent, it splits the vertical range into 100 metres sections, into which it stores the latitude and longitude deltas as degrees per second.
- Every few seconds, it runs a prediction of the landing position based on the current position, the data in that array, and an estimated descent profile that uses a simple atmospheric model (from Steve) plus default values for payload weight and parachute effectiveness.
- During descent, the parachute effectiveness is measured, and the actual figure is used in the above calculation in (2).
So, basically, for each vertical 100m band, the software calculates the estimated time to fall through that band, and applies that to the latitude/longitude deltas measured during ascent. It then sums all the resulting deltas for descent to 100m (typical landing altitude), adds them to the current position, and emits the result in the telemetry as the predicted landing position.
Although the habhub online map does its own landing prediction, an onboard prediction has some advantages:
- It has more descent data to work with, so can more accurately profile the parachute performance
- It is using more recent wind data, measured during ascent
- Ground chase crews can see the landing prediction without having internet access
There are disadvantages too. Because it uses wind data from the ascent, if the wind has changed (due to the landing being in a different area, or because the wind is changing with time) then those factors will introduce errors.
Also, I have a suspicion that the live map consistently overestimates the horizontal distance travelled by a descending flight. This can be seen by watching its landing prediction which, as the flight descends, will move back towards the actual flight position.
So I was keen to see how well the onboard prediction fairs against the habhub prediction. Steve Randall was also interested in this, and was kind enough to record the descent on his screen. He has sped up and annotated the video which you can see here:
From that you can see that:
- Until close to landing, it’s a lot more accurate than the habhub prediction (for this flight – might not be the case generally!)
- The noise in the estimated landing position is mainly along the large part of the descent track.
Here’s a screenshot from the map, edited to show the movement of the landing position during descent:
Steve produced a chart showing the parachute effectiveness ( relative coefficient of drag – which is what the code is trying to measure) with altitude:
Noise at low altitudes is less important, as it’s being applied to a short remaining distance to fall, but the noise higher – between say 5000 and 15,000m – is more important.
For my next flight, I’ll apply some filtering to hopefully make the prediction more consistently accurate. I have all the GPS data from this flight and I can run that back into the tracker code to test how well it would have worked on that last flight.