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.

The avionics revolution hasn’t happened yet

In 2024 I tested Hobbes, an acoustic angle of attack indicator. The feedback from that was quite clear: this shows promise, but the integration needs work. Not only was my instrument’s acoustic feedback similar to that of FLARM, causing some pilots to question which instrument they heard. Some pilots even complained that they even got a headache of hearing both my instrument and the variometer at the same time, and having to divide their attention between both devices.

This got me thinking about the state of avionics in gliders. Since I started gliding in 2003, I’ve seen avionics make their way into glider cockpits. However, we’re doing it wrong… let me tell you why.

What a glider cockpit looks like

A modern glider cockpit is a collection of various instruments, which each do their own thing, combined in an instrument panel. Most manufacturers make a particular type of instrument. The interface to the pilot is – with the exception of moving map displays – a round gauge facing the pilot.

There are a lot of small instruments in a modern glider. Here is a list of what you are likely to see:

  • A speedometer, altimeter, variometer
  • A moving map display
  • A VHF radio, transponder
  • A traffic awareness device (FLARM)

Optionally, we might also see:

  • Flap indicators, gear warning and canopy warning instruments
  • Live wind indicators, tracking instruments
  • Electronic water dump instruments, water dump instruments
  • Battery conditioning instruments, solar charge controllers
  • Canopy flashers

Electronics, Pneumatics and GNSS

Since each electronic system is separate, most manufacturers tell you to use a separate fuse for each instrument. Since we don’t want the fuses in the primary field of view of the pilot – ideally we spend no time interacting with them during flight – each instrument has a separate wire going to the fuse and a central ground point. As the number of instruments increases, the wiring becomes more and more complex… until you end up with something like this:

The messy cockpit of an ASH26E

Most glider pilots know that – over time – the wiring behind the panel becomes a big mess. There’s usually little point in trying to understand what’s happening, so when you buy a second-hand glider some people just remove it all and start from scratch.

With the pneumatics the same happens as with the electronics, but less dramatic. With more instruments attached to a single pressure source the risk of interactions grows, as does the risk of leaking connections.

Most instruments want their own specific GNSS antenna and GNSS receiver. Thus, the panel (cover) becomes more and more crowded with GNSS antennae over time. When you remove the panel cover, it’s easy to pull on the cables, compromising the quality of the connection to the connectors.

Attention management

When multiple instruments are designed by different parties, they do not take into account each others’ presence in the cockpit. The result might be that the pilot is faced with multiple conflicting warnings, or might fly with multiple instruments that are (too) similar in their way of warning the pilot. This puts the burden on the pilot in the worst situation possible: when there is a complex emergency.

Integration

Most of the electronic instruments use a proprietary protocol (usually over RS232: more wires) if they talk to other devices. That means that integration between various types of equipment is difficult and labor-intensive. Not only do instruments not talk to each other. As a result of this they also have their own – incomplete – picture of the current situation. For example, when a glider flies backwards over the ground in a strong wave GPS-based instruments work in reverse. Again the burden is laid on the pilot, who is forced to keep a mental model of each instrument in their head.

What we need

The White Flight Control Room at NASA Houston

In order to break free from what we consider to be “normal”, what we’re simply used to from prolonged exposure, we might ask ourselves: “What would be ridiculous not to have in glider cockpits in 25 years?”. This is my take…

It would be absolutely ridiculous not to have cockpits that direct our attention primarily outward. It would be ridiculous if we would not have systems that primarily manage themselves. It would be ridiculous if we would fly around with systems that we have to adapt to instead of systems that communicate towards us in the way that’s most intuitive to us. And it would be ridiculous if our systems didn’t allow us to cooperate seamlessly when flying cross-country.

A glider cockpit should be a miniaturized version of a control room. We should be able to answer questions like:

  • Where are we?
  • What is our current situation?
  • What just happened?
  • What’s about to happen?
  • What can we do?

And we should have to perform as little mental effort as possible to do so. It would be absolutely ridiculous if the burden of the increasing complexity in our cockpits was put on the pilot. Our systems should demand as little attention as possible, and we as pilots should look inside the cockpit only briefly in order to update our situational awareness with information we cannot see out the window and that cannot be conveyed in other ways (acoustically, tactile, …).

Our cockpit systems should manage themselves and recover from non-critical errors or be adaptive enough to gracefully degrade in their performance.

This means that an instrument is the wrong abstraction altogether. Each instrument maintains its own partial model of the world and asserts it independently — the pilot is the only place those models ever meet. We’ve digitized that arrangement without questioning it; electronic instruments are still just pneumatic instruments with screens.

The right abstraction is the flight situation — one coherent model of what is happening, maintained by the system rather than assembled by the pilot. Sensors become inputs to that model, not endpoints in their own right. Alerts become coordinated expressions of a single reasoning process, not independent voices competing for the same limited attention. The FLARM knows what the AoA sensor knows. The variometer knows the battery state. When these things matter together — and they often do — the system can say so, once, clearly. The pilot’s job becomes reading a situation, not integrating six partial pictures of one.

How we get there

In order to learn what the future should exactly look like, we need to live in that future. That means that we need to build glider cockpits in which we can experience what it is to fly in the gliders of the future. We need to perform many experiments in order to test how the science of human-machine interaction applies in to the glider cockpit.

That means we need to build prototypes and test them, so we can see for ourselves if they bring us closer to a future where gliding is safer, more accessible and cross-country flying is the norm.

This is all the reason behind some of the decisions that I took over the last years. In project Hobbes I chose not to use a micro-controller and create a single-purpose device. I chose to use a Raspberry Pi Zero 2W, a massively overpowered device for the task, so I can change the device and run experiments without being even slightly bothered about performance. The device updates over the air, such that changes can be made quickly. The device is so overpowered, that I can perform most tasks in software. This allows a great deal of flexibility and keeps the hardware also very simple.

For my current glider this means that I’m working to get the instrument panel as empty as possible, and develop a control system (for the non-certified parts of the glider) that allows rapid experimentation. After all, there are a lot of questions left unanswered about what a glider pilot actually needs and how we can best interact with the pilot during flight. The system is designed in a highly modular way and will be (like Hobbes was) very overpowered for what it needs to do.

Conclusion

The pilots who flew with Hobbes weren’t wrong to complain. They were experiencing the logical consequence of a design tradition that never questioned its own assumptions. Every instrument added to a cockpit adds another voice asserting its own partial picture of the world — and the pilot pays the price. The way forward isn’t to add better instruments. It’s to build a cockpit that thinks. That’s what I’m doing.

Next Generation

Since I’ve not posted anything for… a long time now, I thought it was time for some updates. A lot has happened, and I think it’s time to talk about that.

New glider

In the past few years I started slowly looking for a glider to experiment with. The Hobbes project left me with a desire for more avionics experimentation. One of my personal conclusions of the project was that making something to build into a glider in just a day limits the options too much. Things like haptic feedback – which I knew was more optimal for Hobbes than acoustic feedback – was out of the question because of this.

In true “Test Driven Development” fashion, I had decided that I should make a large checklist of requirements for this next glider. I had bought my last glider, an Ls6b, based on my feelings alone. Don’t get me wrong, I still long for the incredible handling that the Ls6 had… but it wasn’t practical for me. At least not for the type of experimentation that I had in mind.

So I made a checklist with some requirements:

  • The instrument panel of the glider should be easily accessible.
  • The wings of the glider should be light enough to assemble it on any flyable day.
  • The glider should have a tail-wheel, which saves my back during assembly and is nice during crosswind take-off.
  • There should be ample space for batteries, baggage and equipment.
  • The glider should fly easily enough to let people who just got their license fly on it and still have enough headspace to do something else.
  • The glider should have a glass fuselage, so that I don’t struggle with adding antennas.
  • The glider should have multiple sets of static ports, such that I can separate experimental equipment from mandatory equipment.
  • The manufacturer should be supportive of experimentation with the aircraft, so I can ask for support if needed.
  • The glider should perform well in weak weather, as this increases the chances I will assemble it and fly it.
  • If at all possible the glider should have an engine, so I can make mistakes during testing and not land in a field.

Discus bT

In the end I settled on the Discus bT as a type. I flew the Discus bT of one of my friends about two years ago and tested some of the handling using the Idaflieg Zacherprotocol. I was pleasantly surprised by the handling. There is not much adverse yaw and the glider is overall easy to fly. The wings of the Discus bT are pretty light and it assembles easily.

During my visit of Aero Friedrichshafen in 2024 I had a nice chat with Tilo of Schempp-Hirth, and he was very supportive about my ideas for experimentation. That was a great pick-me-up and made me focus on the Discus bT more.

This particular Discus bT has a glassfiber fuselage (it also comes in a lighter all-carbon fuselage), which makes installing antennas easy. It contains three sets of static ports and two pitot tubes! This is ideal, because it allows me to put the experimental equipment on one set of pressure ports while critical instruments like the airspeed indicator, altimeter and transponder can be attached to another set. I can modify the experimental stuff as much as I want without affecting the critical instruments.

In the Discus bT the panel is very well accessible and since cables are not routed via the very front of the glider it is easier to add new cables. There is room next to the wheel for two standard 9aH batteries, and there is a mount for a 20aH battery for the engine right below the instrument panel.

This particular Discus bT contains no nose hook. Although that makes aero-tows a bit harder – especially with an aft center of gravity – it means that there is room for an extra 20aH battery in the nose. This means that I can also separate the power for any critical avionics, such as radio and transponder, from any experimental equipment.

Handling & Performance

I’ve flown some small cross-country flights in the glider and I enjoy both the handling and the performance of the glider. With the winglets it’s very docile around the stall and it carries its weight (400kg take-off weight) pretty well. On weak days I cannot out-climb my clubs Discus 2cT, but the glider can glide a long way with reasonable speed.

Next steps

The Discus already has a pretty spacious panel, but I intend to clean it up a little bit. The separate radio and transponder that are present right now will be replaced by an Air Com, Air Control Display and Air Transponder. You can’t get any more compact than 3 instruments in one 57mm hole.

The center of the panel will feature a modular system such that experimental avionics can be quickly swapped out. These will have their own power source and will only use the pressure ports that are not connected to anything critical. A swap should only involve a Weight & Balance + Inventory list update. I’m currently figuring out what kind of regulations apply to the instrument panel of the glider and how I can ensure the safety of the glider with this modular system.

The glider will be fitted with an GPS-RTK set, which should give me a reliable heading and pitch indication.

Project

The first project for this glider will be the Pathfinder. The engine in the Discus bT allows me to experiment with potential algorithms without risking many outlandings. The modular instrument panel should allow me to experiment with ways of indicating the best strategy to the pilot.