Tag: Pathfinder

Posted on

Progress in 2026

With the flying season of 2026 coming to an end, it’s time to look at the past year and to 2027.

Hobbes and the Discus bT

This year the Discus bT flew with Hobbes in it. Besides giving acoustic stall warnings, it has been used as a generic device for logging flights, testing new software and generally improving the software.

The fact that I chose a Raspberry Pi Zero 2W and not a micro-controller turned out to be a key decision here. As soon as the software detects I’ve landed, it tries periodically to upload the measured data over a secure VPN to my server at home. This works very well, and it makes working with the device very pleasant. Since the device has WiFi when I assemble it from the trailer, I can update the device over WiFi before every flying day.

This makes iteration pretty effortless. Every day, I update the device in the morning, fly in the afternoon (sometimes with audio disabled) and upload new data and logs for inspection in the evening. If I find out that things don’t work well, it takes less than 5 minutes to update the software in the glider.

During the season the Discus received its new radio: an Air Avionics AC-1. It works well and I look forward to the Air Avionics transponder. The panel of the Discus is getting more and more empty.

The Discus works very well as a platform for experimentation. I really enjoy how easy it is to work on the panel and how much room it has. A big improvement over my last glider, an Ls6b.

With a more forward center of gravity, the glider is more stable in pitch. Towing on the winch-hook is still something that needs more attention than usual, but thanks to a few years of flying aerobatics I have enough experience with aero-tow to make this happen.

One day I decided not to launch, when there was very turbulent 25km/h wind that was 30 degrees cross. I saw the ASG-29 before me struggle right at the point where I usually need most inputs and decided it would be better not to fly. This is the biggest downside to this Discus bT, but it also gives me room for an extra 18Ah battery. I guess it’s all about compromises…

Flight testing

Just landed after my first measurement flight from FL95 on the Discus 2c DLR. Photo by Ricardo van der Pluijm

After visiting the Idaflieg Sommertreffen this year, I was part of a joint NLR-DLR flight test as an independent contractor. Although the main goal of the test was to convince NLR that a research glider is cheap to operate but can still give you meaningful results, Hobbes was also installed in the Discus 2c DLR during the test.

We performed stalls with airbrakes open and closed in an effort to see how CLmax changes as a function of the airbrake extension. This test showed that what Hobbes does – assuming that stall happens at a fixed CLmax – is too simple. With airbrakes extended I noticed that the indication it gave was too little, so it would be too late in warning the pilot for an actual stall. The good news is that the Discus 2c becomes more stable as you increase airbrake extension. The risk of entering a spin appears to become less with airbrakes extended.

It was a great learning experience to be part of a real flight test, both as ground crew and as pilot.

GPS+RTK experiments

This year has seen a great advancement in AI. In some experiments where I just fed it raw data and let it figure out the rest, it did an unexpected well job. In about 10 minutes it went from raw ASCII data to nice plots without any extra input needed. I only told it what was in the file and what was measured, and it did the rest. It even solved some synchronization issues.

That got me thinking. I’ve owned an ArduSimple simpleRTK2B+heading kit for some years now, and I flew with it in the Ls6 for a few flights. What if I don’t have to make all the hardware nice or have to learn Kalman filters etc? What if I can just fly with the setup, measure the output (UBX-NAV-PVT and UBX-NAV-RELPOSNED) together with the measurements from the backup-IMU that Hobbes contains (a BMI270), and let the AI crunch the numbers?

First flight

Well, the result didn’t disappoint. First of all, it figured out on its own that since the glider has a turbo, there can be engine runs. So when it noticed a dramatic increase in noise on the accelerometers… it figured out it was probably the engine! And it was right. It also noticed that the pitot tube that it gets the data from is in the tail, so I’m not really flying 160km/h with the engine on. That’s just the prop-wash.

Next I went a bit further. I gave it this explanation of how the Borgelt Dynamis system works. No formulas, just the text. And it created the plot shown above. You can clearly see that with the Dynamis method the noise is much less than what the XCVario gets from the TE-probe in the prop-wash. That means that it might be useful to make a nice implementation of this algorithm at some point, so I can have a more reliable and steadier variometer indication during motor runs.

The AI (Claude Opus 5.5) was also able to suggest what I might do to get less noisy readings. It started to suggest that I make the timing of the IMU better and that I average readings and apply one of the built-in filters. On the next flight, things were indeed looking better.

Third flight

By the third flight, the setup had already improved quite a bit. So I decided to see if I might be able to measure the CL-α\alpha curve around the stall of the Discus bT. I have the winglets and stall is very, very gentle with them, so I wondered what that would look like. Since I had purchased a relevant polar curve from Idaflieg, Claude knew what the sink rate should be at different speeds (compensated for the actual weight). The results look pretty plausible, but I might have to repeat this exercise a few times to cancel out air movement.

The landing of the third flight was a little bit harder than usual, and I thought I felt the tail wheel touch first. So I asked Claude to analyze the landing. The image above is what it came up with after a few minutes of number-crunching.

I am very much aware that pretty plots don’t make for verified findings. I do find this fun to play with and I find it helpful that it tells me where I’m leaving accuracy on the table.

Next year I want to place the IMU much closer to the center of gravity, and I want to place the aft GPS antenna more towards the rear. I will also connect the Pulse Per Second signal from the GPS receiver to the Raspberry Pi Zero 2W, so I have a common timebase for both the IMU and the GPS receiver.

Pathfinder

I’ve worked a bit more on the Pathfinder in the recent months, although not as much as I’d like. There is good news though: in 2 dimensions my new algorithm shows the first signs of working and it can easily handle flights of several tens of kilometers. This is already a big step compared to the efforts of previous years.

The next step is to verify that – although I never explicitly tell it to – the search algorithm does reproduce the well-known MacCready rule: “don’t circle in lift weaker than your current cruise setting”. And it should also be able to reproduce the strategies that John Cochrane derived in his paper called Just a little faster please.

Once this is true, I will add the third dimension and look for ways to test the algorithm against either weather predictions or data derived from past flights.

Next year

In order to take the next step in the cockpit of the Discus, aligning it more with the vision laid out in “The avionics revolution hasn’t happened yet”, I will bring the first LCD screen into the cockpit. I bought a sunlight-readable MakerPlane LCD a few years ago. That should fit easily in the existing 80mm hole in the panel. The fact that it has (multi-)touch input enables a whole variety of things that I can then use it for. That will probably trigger a whole lot of software that can be built around it.

The buzzer that’s used by Hobbes will be replaced by a speaker, so I can play all kinds of audio and also handle multiple channels playing audio if I want to.

The GPS+RTK set will be back in a more permanent installation, with proper synchronization to the BMI270 IMU to improve accuracy.

There will be more progress on the Pathfinder, hopefully proof that the approach works, followed by an expansion to three dimensions. If that works, the LCD screen will show route information and I will start testing it in real flights.

Software will be aimed towards implementing a Simplex Architecture: a safety-critical part that has clear boundaries (don’t play more than one warning, warnings have priority over generic information, define clear behavior when no fresh information is produced) and a non-critical part that can change much more freely and much more quickly.

Posted on

Pathfinder 1: Problem Finding

On January the first I announced that this year would be the year of the pathfinder. Since then, I got mentally stuck a bit. Since I had already made an attempt at solving the problem, I found myself slip into the gulleys created by my past efforts. It was very tempting to just continue where I stopped last time, even though I know that my previous approach has important downsides. It makes no sense to solve the wrong problem, so although I was very eager to get started I realized that it was important to identify the right problem first. After going in circles for quite a while, I decided to get help and figure out how to approach this. I stumbled again on Paul MacCready’s approach during the development of the Gossamer Condor. After analysing the competition, he concluded: “The problem is that we don’t understand the problem.”

My previous approach

In 2020 I made a similar attempt. This showed promise, but it lacked important problems.

The most important thing was that it only gives you the most optimal route, with the assumption that all the thermals will still be there when you go to where they were last observed. This is obviously not true, even more so in the evening when thermal activity dies down. A friend suggested that I incorporate the chance that a thermal is not present. This makes a lot of sense, but the algorithm I chose gave me no easy way of incorporating this.

Then I collected statistics without any distinction between lift found during gliding and lift found during circling. This means that if someone circles in lift for a long time, the statistics for that location will be heavily biased towards that lift.

The algorithm also struggled with missing data. Due to the gaps that naturally exist in the coverage of the Open Glider Network, there will be areas where I collect no statistics at all. I had to make assumptions for those locations.

Finding problems

Thermal lift values on the most busy day in 2024: April 11th. It’s nice to see that thermal strengths follow a normal distribution.

The first thing I’m going to do is analyse a lot of gliding days. What is possible with perfect knowledge? How fast could we really fly? How much lift do we really need to stay airborne? How often do predicted thermals still exist when we reach them?

Process

The process I’m using this year is a bit different from last year. Where last year I started to build something straight away, I’m trying to verify my direction a little bit. The reason for this is quite simple: during the presentation of Hobbes in Darmstadt I learnt that tactile feedback would have been much better. I disregarded that quite early (due to safety and complexity concerns), but I do think I could have done a bit more research. Since I know from conversations with a friend who’s an avid cross country pilot that “just the fastest route” might not be sufficient, I am trying to refine the question a bit first.

This is all new and difficult for me. Although I have attended university, I have never had prolonged guidance on “how to do research”. Therefore I’ve always been more of an engineer/tinkerer than a scientist.

Posted on

2025: Year of the pathfinder

One day in 2009, I was lying in the grass near my dorm at the Twente University campus. I saw a DG-300 circle above me, which launched at the nearby airbase. Not long before I had learnt about the work of Alan Kay, who’s team at Xerox PARC invented about half of what we call “Personal Computing” today. Their way of thinking was new and exiting to me. One thought-provoking question that had stuck with me was: “What would be ridiculous not to have in 25 years?”

The dream

Watching the DG-300 circle in a thermal, I thought: “It would be ridiculous not to have a precise prediction of thermals in 25 years”. And so I started thinking….

What would gliding be like if we could prevent out-landings? If we could precisely predict the weather? Predict where thermals will form, when they will form and how fast we can climb in those thermals? This would be a game-changer. No more need for sustainer engines. No more need for late-night retrieves. That sounds pretty great….

Finding an exponential to make it happen

If we could use Moore’s law, this might not actually be that hard to achieve. In 25 years the amount of computing power on board of a glider will be a lot, about 100.000 times that of 2009. We can either use Moore’s Law to make the computers on board faster or to reduce it’s power consumption, or a bit of both. So even if batteries don’t scale exponentially in capacity over time, we can still use Moore’s Law to compute more for the same amount of energy.

Make it feasible

But 25 years is a long time. It probably doesn’t take 25 years to develop a solution. I decided that weather models, such as WRF, would probably be too slow. I decided something based on observations would probably work better than something based on predictions.

In 2009 cellular data wasn’t as ubiquitous as it is in 2025. My conclusion in 2009 was therefore: I should invest my time in Wireless Mesh Networking, so the gliders can communicate with each other without the need for cellular coverage. And that’s what I did: I spent my Master’s Thesis on Wireless Mesh Networking for gliders.

After finishing my thesis, I was not very content with the result. I started working, and the dream of live weather insights faded…. until I had access to the live tracking data from the SkyLines platform. When I looked at the SkyLines data around 2019, I saw that cellular coverage had dramatically improved. I could see that 97% of all GPS positions took less than 1 second to reach the SkyLines server. That means that the glider in question has a working cellular connection!

First try

This lead to my first attempts. First, I used XCSoar’s thermal detection algorithm to locate thermals. A clubmate of me flew with a moving map that showed thermals, and found two where I predicted them. Nice!

Then I started to look at faster cross country flights, and saw that a lot can be either won or lost during the gliding phase. I wrote a program that analyses OGN data and collects statistics of the entire world. I wrote another program that finds the fastest route from A to B given those statistics.

A friend did an 750km attempt in his ASW24, and I followed him live during the attempt. This is what I saw during that day:

A failed 750km attempt in an ASW-24. Lift/sink is shown on the map. The green line is the route home. The bottom graph shows the vertical profile: where to climb, how high to climb and how fast to glide.

Just after rounding the second turn-point I could predict his landing time… and I saw it slip. You can imagine that I was pretty over-the-moon by this result. I could find the most optimal route home in under 2 seconds on a Raspberry Pi 4! This might actually work….

However, later on when I tried to verify my algorithm formally, I unfortunately noticed critical errors in the algorithm and abandoned the project again.

This year

In the past years I didn’t know if what I wanted was feasible. I tried to remove some of the optimizations that violated correctness… but it didn’t work. I needed more than 16GB of memory to calculate a 50km route. It just wasn’t working.

I went back to studying the underlying algorithms, and talked to some friends about my approach and problems. I learnt some valuable things, but by the time I did I was focussing on Hobbes. Now that Hobbes has reached a conclusion, I learnt that prolonged attention can show great results after a few months.

So in 2025 I’m going to focus my attention on making the pathfinder work: make it correct, make it fast.