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.
In contrast to my earlier posts about the project, this post is less technical and perhaps a bit more “dry” in nature: today talk about the research perspective on the project.
Research questions
When I proposed my project to Idaflieg and DLR, I wrote down three primary questions that I wanted to answer:
Is having continuous feedback of angle of attack perceived to have a positive/negative effect on the safe execution of the flight or no effect at all?
Is the CL-approximation of angle of attack perceived to be helpful? In which maneuvers is it/is it not?
Is the manner in which the device provides feedback perceived to be appropriate?
Optionally: how does this improve over time if we can test multiple days? This didn’t happen.
Notice that these are subjective questions. They deal with the perception of the pilot, not with the facts. This was a deliberate choice. Although one can probably draw more significant conclusions from facts, I figured that measuring these facts would require some sort of A/B testing. Unless we deliberately introduce potentially unsafe situations, I thought it would be likely that the results would be very ambiguous. So, I decided to deal with the pilot’s perception for now…
Method of evaluation
It was pretty quickly obvious that some kind of questionnaire would be what I would use. Thanks to my wife I came across Expectation Confirmation Theory, and found a related paper. This paper dealt with the (future) evaluation of a user interface, which seemed related enough to use it.
A questionnaire was created that reflected the categories in the mentioned paper:
Perceived Usefulness (PU), the user’s perceptions of the expected benefits of using Hobbes.
Perceived Ease of Use (PEoU), the ease and convenience of using Hobbes.
Perceived Performance (PP), how well and clearly Hobbes warns of stalls.
Expectation (E), how Hobbes relates to the user’s expectations.
Confirmation (C), how Hobbes relates to the user’s needs.
Satisfaction (S), whether users are content with Hobbes.
Continuance Intention (CI), whether users would like to fly more with it and recommend it.
Interface Quality (IQ), detailed questions about the device’s audio feedback (interval, tone frequency, volume). Mainly intended for the fourth research question.
All questions are positively phrased and use the Likert scale. In each category at least two questions are asked, where both questions try to measure the same thing but use different words. For example:
“The device works better than expected”, and
“The device fits my expectations”.
This is done in an attempt to find inconsistencies. If the answers to the above two questions are radically different (more than 2 points apart), this might be a sign of inconsistency or misinterpretation of one of the questions. I ignore those answers.
For each category for each flight, I calculate the average Likert score. So I end up with one score for each category, for each flight.
Next to averages I look at the correlation between the various categories, in an effort to find out more about the perception of the system and explain anomalies.
I leave room on the questionnaire to provide additional feedback, and I attempt to talk to pilots after their flight. I received video footage of three flights.
Results
In total 8 evaluated flights took place with Hobbes. Flights were performed by student pilots, experienced cross country pilots and a test pilot. The system was evaluated both in normal flight and inverted flight. Here are the results of each category. The rectangles reflect the range from minimum average value to maximum average value. The black bar reflects the average value.
Average values per category, per flight. Bars reach from minimum average to maximum average. First category is Perceived Usefulness (PU).
The correlations look like this:
Correlation of averages between the different categories.
Three correlations stand out for me. I’ve tried to come up with an explanation for these.
The 0.00 correlation between Perceived Performance and Confirmation.
The 0.28 correlation between Expectations and Confirmation.
The 0.32 correlation between Confirmation and Satisfaction.
This correlation illustrates the relationship between how well and clearly Hobbes warns of stalls versus how Hobbes relates to the user’s needs. This signals that the pilots that evaluated the system feel no need to fly with an AudioAoA system, even though my system works well enough.
This correlation illustrates the relationship between how Hobbes relates to the user’s expectations versus how Hobbes relates to the user’s needs. This signals that although Hobbes works better than expected, it does not completely do what the pilots feel they need.
How Hobbes relates to the user’s needs versus whether users are content with Hobbes. This signals the same thing as number 2: it works, but it doesn’t really do what pilots feel they need.
Remarks and video observations
A few remarks show clear room for improvement, but also the added value of good test pilots that not only do as asked but investigate:
“We tried stalling dynamically, which almost doesn’t get picked up”.
“Sometimes the sound cuts out once you are in full Stall. I tried different calibrations, and a calibration closer to stall-speed worked better than the one close to first mushiness of the controls”.
Other remarks show issues with integration:
“For normal flight it gets a bit annoying as it also beeps in non-critical situations.”
“Sometimes it was hard to concentrate on the device and also the variometer, such that just one got my attention.”
“Sound is the first thing a pilot ignores in high-stress situations. Perhaps an added LED-indication would help.”
Conclusions & personal takeaways
With the above info, I believe we can provide credible answers to the original three research questions:
Is having continuous feedback of angle of attack perceived to have a positive/negative effect on the safe execution of the flight or no effect at all? Yes, Perceived Usefulness is on average 3.6 and never below 3.
Is the CL-approximation of angle of attack perceived to be helpful? In which maneuvers is it/is it not? It is helpful, except for flapped gliders dynamic stalls. It is unclear if dynamic stall behavior is a result of the input data or my arithmetic.
Is the manner in which the device provides feedback perceived to be appropriate? Yes….and no. In general feedback is positive, with a Interface Quality average of almost 4. However, correlations indicate that some things are not satisfactory yet. Pilots indicate that the device is not loud enough. It should also probably not always beep, if we’re to use it as a stall-warning device. Pilot feedback shows that integration with other cockpit audio sources is a complex problem, which was not solved satisfactory.
Recommendations
“Do or die” audio seems more appropriate than always giving feedback, although the gradient up to stall is perceived positively by pilots. Consider limiting feedback to a CL-range close to stall.
Use a pilot-facing speaker and LED to solve volume and readability issues.
Spread the evaluation out over a longer period, with multiple flights per pilot.
Evaluate these kinds of systems over a longer time period, to pilots to get used to the system and acquire more feedback. This might also be an opportunity for tweaking parameters and re-evaluation, as I initially intended.
Outlook
While the experiment as such is finished, there are some things to look out for in the future:
One of the Idaflieg pilots will continue to fly with Hobbes in his H101 Salto aerobatic glider. This allows for more iterations to be tested.
Early tests with a flap-independent algorithm were very promising. This method requires knowledge of the glide polar of the glider, which gives rise to the need to know inverted polars for applicable gliders. These have not yet been determined, but make for exciting test flights.
The experiments clearly show that integration in glider cockpits might have great benefits for flight safety. This opens up a new and exciting area of research.
In January of 2024 I decided to build an audio angle of attack instrument. This page attempts to summarize the most important aspects. This will mainly consist of technical details, for those interested. The full story is here: https://akaflieg.nl/index.php/tag/hobbes/
Inspiration
The inspiration consisted of a couple of things. First was the existing audio of attack meter present in the F4 Phantom:
An impression of the F4 Phantom’s audio angle of attack indication
Another inspiration was a previous job, where we made products with haptic feedback. I drove a car where the navigation system consisted of vibration motors in the driver’s seat. This was very relaxing. I later learnt that haptic feedback is processed in an old part of the brain. This reduces the mental energy required to process it, but also reduces response times. I saw this in patients who learn to walk with an artificial balance organ within 30 minutes of wearing it. Lesson learnt: how you convey information is very important.
Development
For development, I wanted to experiment with eXtreme Manufacturing. Since I had never designed PCBAs or even done anything serious with breadboards, I chose an iterative way of working to learn quickly. I ordered a new PCBA every two weeks from JLCPCB. Those took a week to arrive, making feedback rather quick. I asked coworkers for help when Google wasn’t enough. For PCBA design I used EasyEDA, which already contains footprints of parts that JLCPCB can place.
For CAD, I first used EasyEDA too. Later I switched to OpenSCAD, mainly because of it’s ability to be scripted easily. I eventually implemented Test Driven Development for CAD by checking for collisions between parts.
For the software, I used an existing codebase I had in C++20. Some things that were central to my codebase were:
A templated classencapsulating any SI-unit possible, which automatically handles things like addition and multiplication too. This allowed for the compiler’s type checker to look if things look sane in my physics calculations.
Following the Erlang“let it crash” philosophy, I split my program into communicating processes. Each process can crash (for foreseen or unforeseen reasons) and will be restarted quickly. This makes surviving transient bugs easier, and speeds up development in the face of those. It also makes the code more focused in the “happy path” instead of being littered with error handling.
I heavily used Test Driven Development and CI/CD to increase confidence in the code.
I didn’t optimize anything until needed. Implementations were kept as simple as possible.
Estimating AoA
Very early on in the project, I realised that measuring AoA is hard. Especially if you have never seen the gliders you’re going to measure it on.
Therefore I chose to estimate AoA by estimating C_L. And since I’m only interested in the glider’s approach to C_Lmax, I can even leave out more terms. I was left with: N / IAS^2.
Since I can’t predict C_Lmax, the pilot has to calibrate the system by pressing a PushButton while stalling the glider.
Feedback
For feedback I used a Passive Piezo Buzzer. This generated 80dB of sound at it’s resonant frequency of 2700Hz. I used tiny beeps, inspired by a Geiger Counter, to indicate the approach to stall. I deliberately chose not just to beep at the stall, but to give near-continuous feedback to generate a sense of situational awareness.
An exponential curve to translate the (normalized) C_L value into a beeping frequency was derived, such that:
It beeps at 20Hz at the actual stall.
It beeps at roughly 1Hz at circuit and landing speeds.
It still beeps, but much slower at higher speeds.
Hardware
Following the eXtreme Manufacturing principle “Optimize for change”, I chose the Raspberry Pi Zero 2W as the computing platform for the project. I tuned the Pi down to 0.7 Watt power consumption and optimized for SD-card longevity. I used the Pi’s WiFi to upgrade software easily, by installing a Debian package that was generated by the CI/CD pipeline.
The LXNAV Input PCBA.
Since multiple input sources were available, I split my PCBA into two pieces: one for input and one for output. There existed an LXNAV input PCBA, which received 5V and 3.3V TTL UART. The IGC version received 12V and RS232 signal levels. These two PCBAs could be exchanged within 5 minutes.
The Output PCBA
The output PCBA contained the Buzzer, the (connection for the) PushButton and an RGB-Led to indicate system status.
PCBAs were stacked using long header pins and a set of push-through female headers on top of the PCBAs.
The PushButton was executed as a membrane button on a small 3D-printed adapter bracket. It was secured with a velcrow strap to the flight stick.
Results
It worked pretty well! Here is a demo of a base-to-final turn
After months of learning to design PCBAs, going through numerous iterations, design changes, getting loads of interesting feedback and suggestions, software bugs and bugfixes… I was finally here: I arrived at Stendal.
Armed with a crate full of equipment, spare parts and some fresh clothes I was eager to get started. Let’s get my hardware in as many gliders as possible and start flying!
Neo Theo
The first glider to receive my system was FVA Aachen‘s DG-1001 “NeoTheo”. They had already generously agreed to have my system installed before the event. Great! With the help of one of their members, I installed my device on my second day in Stendal. Their beautiful glider is equipped with an LXNAV S100, which I initially designed my device for. The S100 is able to send both Indicated Airspeed and G-loading at 10Hz over a serial connection and it supplies 5Volts/1Amp for any device connected to it. More than enough for the Raspberry Pi Zero 2W that I use, which only needs 0.2Amps.
My device mounted in FVA’s NeoTheo. The white instrument is in the panel, the PushButton is mounted on the stick.
After installation everything seemed to work on the ground. So I updated the software to the latest version, verified that the device uploaded it’s logs after landing and I went for a CS-STAN technical checkout flight. Together with Kobo, Idaflieg’s current president, I towed to 1250 meters. Kobo had asked if my device would also support inverted flight, since his aerobatic students sometimes manage to stall the DG-1001 during inverted figures. The device does support inverted flight, so an inverted test was to be included too.
First we evaluated the device in normal flight, and below 850 meters altitude we rolled the DG inverted and stalled it. The device worked exactly as intended and signaled the pilot nicely before he would negatively stall the glider.
Kobo simulated a classical error: a student flying an un-coordinated base-to-final turn. These are especially dangerous, because there is very little room for spin-recovery.
Kobo simulates a slow base-to-final turn
The French connection
The day after my arrival, I suddenly saw a familiar face walk towards me: it was Matthieu Scherrer! I bought my last glider, my Ls6b, via him from his gliding club. Matthieu flies an Ls6 too, and performs research on gliders. Matthieu was eager to talk to DLR about the comparison flights, and he was attending the OSTIV Congress in Uvalde in the afternoons.
It turned out that Matthieu was also presenting a paper on estimating Angle of Attack (AoA) from accelerometer data. Off course this was very interesting to me, since I estimate AoA too. My method has a clear problem: I cannot deal with flapped gliders. Matthieu’s method should have a way to solve that issue. Matthieu and I talked a lot about his method, my device, and how the two could be combined. Long story short: I received an A4 paper with formulas to implement and will test those with Condor Soaring.
What about other gliders?
I had brought 5 pieces of my device to Stendal. Before visiting, I knew that my device could be mounted in “Neo Theo” and what hardware was present. About the other gliders, I had to make assumptions. I chose two assumptions, which were more or less false:
Most gliders will have recent LXNAV equipment. An S80 variometer or an LX8000/LX9000 device with PDA port.
The rest will have RJ45 IGC-compatible pinouts.
Both turned out to be wrong. I encountered gliders with older LX9000 devices, which did not feature a PDA port yet. I also encountered gliders with an XCVario, which looks RJ45 IGC-compatible but isn’t (it uses 3.3V UART instead of RS232). An LX7000 device that I encountered needed an RJ12 connector, which the local hardware-store didn’t have.
Even the simulator didn’t work, as the different WiFi clients were not allowed to exchange data. That meant my device couldn’t receive the simulator’s telemetry.
Taking a step back
This was all pretty frustrating. After the initial success of installing the first device, I now failed 4 times in a row. For reasons that were outside of my control in Stendal. With my departure closing, I was afraid that this was going to fail. Six months of work for nothing.
Then I remembered some of the wisdom that I had heard: it’s not reality that’s the problem, it’s how your relate to it. I decided to take a small step back, get out of my daily routine at the airport and have a good lunch in the city center of Stendal.
I then decided that I should put my money on NeoTheo and have as many people fly it as possible. I announced that I would donate to Idaflieg for every evaluated flight that took place on NeoTheo. That worked very well, and the next day four flights with NeoTheo took place, despite windy conditions.
Further evaluation
Two testpilots perform a skidded stall with the system
In total my system has now been evaluated 8 times. It has flown with experienced pilots, inexperienced pilots and even a test-pilot. My device has worked well: I see no bugs or crashes in the logs. The installation of the PushButton also worked well, as there were no accidental presses and it was never close to obstructing any flight controls.
Lessons learnt
Apart from the analysis of the evaluation, I think many lessons can be learnt from my experience. I’ll list a few here…
Optimize for change. This is also the first principle of eXtreme Manufacturing. The fact that I could see my logfiles after the landing of a glider and could build+test a new software-version within 5 minutes was hugely powerful. Several times have I made small improvements to the device, to make the experience a bit smoother. For example: I did not read 5 Volts from the LXNAV S100, but more like 4.6 Volts. That should not be enough for the Pi to run, but it still did. I could make the low-voltage warning go away with a simple change in software and continue testing.
The more generic an interface, the better. I falsely assumed that most of the gliders I would encounter would have either an LXNAV instrument with an RJ45 PDA port (5V + 3.3V TTL UART), or a RJ45 IGC-compatible port (12V + RS232). I was wrong in many ways. I encountered many gliders with either no external port or a (just slightly) incompatible port. This cost me many hours of trying to make things work, without any results. If I would have designed my system with simple screw-terminals instead of a fixed-pinout RJ45 connector, I would have been able to get more gliders to work.
Resilience is all about how you relate to the circumstances, and yourself. When I failed to do 4 installations in a row, I noticed my mood deteriorating pretty quickly. As soon as I stopped beating myself up and started to be kind to myself, the ideas started to flow and better outcomes followed quickly.
Speak up. A lot of days went by where not much happened. I was waiting for people to “discover” my project. It turned out they were busy with projects of their own. Only when I clearly stated that I wanted people to fly with my device, things started to happen. I had to speak up.
integration is crucial. Since I’m not the only instrument in the cockpit, it must co-exist with other instruments. It is vital that the pilot can distinguish between your instrument and all others, and that mental workload remains low. One pilot reported having issues managing their attention between my device and the variometer. Another thought it was difficult to determine if my device was beeping or if FLARM was warning about nearby traffic.
There is synergy between software and physics. Many of the people I spoke to were jealous of the level of software-engineering that has gone into my device. The fault-tolerance attempts that I made were clearly working. On the other hand, I was often very jealous of the amount of physics knowledge that these people have. I can hardly understand the physics behind AoA estimation, let alone improve upon it. The right software engineer and the right physicist can create something far greater and useful than each can on their own.
The value of feedback cannot be overstated. The amount of useful feedback I got from Idaflieg’s pilots was brilliant. No amount of development or thinking can replace this. If I would have had multiple days of testing, I’m sure I could have made tremendous improvements.
Results
I need some time to evaluate the results of the questionaire that the pilots filled in for me. This will feature in a separate post, and will be published at Idaflieg.
In general I think it can be said that the system as such proves valuable. There are some issues to work out, such as the integration with other instruments in the glider cockpit: FLARM, the variometer, the radio. All of these produce sounds too, and we need to be careful about where we direct the attention of the pilot. We also need to take care we do not overwhelm the pilot. In general my device was not loud enough when flying fast (especially in the backseat) and the LED was hard to see. Making it louder might make the integration with other devices more important.
The device appears to detect the approach-to-stall well in most cases. Dynamic stalls appear to be challenging, as the onset is too quick for my device to detect it in time.
Acknownledgements
I would like to thank these people for their invaluable assistance in my project:
Idaflieg and DLR, for allowing me to execute this project.
FVA Aachen, for trusting their glider with my home-built electronics.
My colleagues, for helping me learn PCB design and fixing mis-manufactured PCBs.
Roald, for helping me with 3D printing and mounting a PushButton on the stick.
Kim, for mental support and helping me out with the evaluation form.
The Idaflieg pilots, for their evaluation and suggestions.
There’s no greater thrill than seeing your ideas become reality. Thank you.
Last time – already a month ago – I wrote about uncertainty rearing it’s head, a new output PCBA and the PushButton of my project.Today, about three weeks before I drive to the Sommertreffen with my project, I have almost finished production of a series 5 devices…well almost.
I ordered just one piece too little of an important piece: the extra-long Pi extension headers I use to stack all PCBAs. It’s a bit of a bummer, but something that I will resolve in the next few days.
Software bugs
The stacking mechanism used. The long header pins penetrate the PCB and the small female header.
The past few weeks I’ve been testing the device almost on a daily basis. This has shown some annoying bugs, which I’ve been able to solve.
My software consist of four programs that communicate with each other. Each program has a distinct function. Most of these programs can fail and be restarted very quickly. So quickly that the pilot does not notice anything.
The idea behind this is that bugs can always happen, but that individual parts of the software can fail without the system as a whole failing. For example, if LXNAV sends me malformed input, the process responsible for decoding it will just crash and restart.
That’s all very nice and works great in practice… as long as the code responsible for restarting a failed program works. Off course, this is where I found a bug. Things were not restarting. Even worse, the software responsible for restarting a failed program would lock up itself. This is fixed now.
Series production
Four Raspberry Pi Zero 2W’s waiting for additional PCBAs to be stacked on top. The black enclosure will be used in the Zacher Simulator, to make pilots familiar with the device. The fifth device is running tests.
After my holiday, I started to prepare for a series of 5 units. Because I had already built one unit, this was rather easy: just order 4 more times everything that I had already used.
Today the last parts arrived and it took me about 45 minutes to assemble everything. I believe that this is where eXtreme Manufacturing and especially building fully functional prototypes shines. Because I’ve been involved with 3D printers, hardware suppliers and everything else… I know what works and what doesn’t. Not only have I assembled the device many times before, I also have a gut-feeling about the manufacturing consistency of each supplier and their delivery times.
Where the device has stable interface between parts, I had the choice of using previous iterations of a part if I wanted to save money. In the previous iteration the 3D printing supplier gave me some extra parts that they considered to be bad quality (the color was not perfect), and I was able to re-use those parts.
PushButton
A month ago I was still struggling a little bit with the PushButton and mounting it on the stick. In an effort to get more grip on this situation, I asked DLR for some information on the metal bracket that is used to mount the measuring tape to the flight stick.
The measuring tape and metal bracket that mounts it on the flight stick.
DLR was able to give me accurate measurements and a profile of the metal bracket. Roald, who you might remember from his insights in the PushButton from previous posts, was able to make a 3D model of a flight stick with the metal bracket mounted. He also created a small adapter that allows me to mount the PushButton on a flat surface to the flight stick. Not only did he provide me with this model, he also donated the velcro straps to secure the entire thing!
A mock of the flight stick with bracket and the adapter with the PushButton.
Testing final assembly
The wiring between the main unit and the PushButton. Twisted pair, DuPont cables, flex-PCB.
Despite my efforts, final assembly will still be a bit hard. The majority of the cable will be a twisted pair. The PushButton comes with a female DuPont connector. So I have two options: buy DuPont crimping tools or abuse existing DuPont cables as adapters. I’ve decided to do the latter. This means that I will connect one side of the DuPont cable to the twisted pair cable. I will do so using solder sleeves. While this does work, it’s not pretty and still requires tools: a heatgun.
Some closing thoughts about XM
With the Sommertreffen now approaching, I find myself starting to draw preliminary conclusions about the development and my first real-world experience of eXtreme Manufacturing (XM).
Perhaps the most prominent thought is: the importance of early feedback cannot be overstated. I was completely surprised by the feedback I received at Aero Friedrichshafen. And I cannot count the amount of times that I wished that I had a glider where I could just install and test things with. Early feedback is immensely valuable. I also understand why most Agile coaches say that Agile cannot be done in isolation; in order to receive early feedback you need partners that are willing to evaluate your early work. I’ve tried to evaluate my own work by using a simulator, but it’s just not the same.
Once you have that ability to regularly evaluate, other things like Modularity become very important. If I would have had a glider at my disposal, it would have been a big effort to swap out versions. Anything that takes more than a few minutes easily becomes a mental hurdle. The human mind will always tend to over-estimate it’s own ability to predict the future. So the bigger that hurdle, the more assumptions you are tempted to make and the more re-work you will have to do. Reality tends to be surprising in all kinds of unforeseen ways.
Once you have these things down, you can – in theory – replace things pretty quickly. I can release new software after every flight, but I don’t think I will. Despite my efforts for using Test Driven Design, I have not been able to drive this far enough to be confident about releasing new software to all 5 devices blindly. This is where I would like to improve. Ideally I would like to be able to enable auto-updating on without any worries about software quality.
With my nerves settling down and my devices complete, I’m looking forward to test this thing out in Stendal. I am intensely curious what will work as intended, what unexpected issues will arise and how my device will be regarded by the pilots.I intend to update the device several times during my visit, in order to improve it and get as much feedback on it as possible.
Last time, I wrote about my happy experiences with Test Driven CAD, registration at Idaflieg and some adventures with the PushButton. When I write this, I have only two months left to my visit at the Idaflieg Sommertreffen, which doesn’t feel like a lot…especially if you take into account holidays and work.The good news is, I’m on final glide towards having at least support for the LXNAV S80/S100 variometers working.
Nerves
The doubts that creep up in my mind are all rooted in one thing: the lack of real-life testing. I’m starting to be convinced that this is where this eXtreme Manufacturing (agile) stuff helps a lot: you test early and often. I wish I could have tested more, and sooner. I have successfully tested a lot of software with the usual techniques (Mocking, Faking). That’s not where my doubts are. They are more centered around the stuff I can’t easily test: the entire Linux system I’m dragging along, the manual, etc…
Enclosure updates
In the last version of the enclosure was a hole where the On/Off switch can go through. I just had trouble installing the contents into the enclosure. The fix was very easy: split the enclosure at the location of the switch instead of below it. I thought it would also be nice to have the positions of the switch be visible on the outside, so I added some text indications on the device, as well the text “AOA” to indicate what the device does.
This version of the enclosure is printed with ASA, which is supposedly more resistant to UV radiation and heat. The previous version was printed in PLA by Roald. For crash-worthiness, I verified that the enclosure can handle at least 6kg of weight. Since the device itself weighs almost exactly 100 grams, this is equivalent to 60G. Should be good enough.
Output PCBA
The latest version of the Output PCBA. On the left the screw terminals, IMU center-bottom, current-shunt center-top, LED and Buzzer on the far right.
I’ve revised my Output PCBA quite a bit. With the realization that the PushButton should really be removed, I’ve investigated the method of connecting the PushButton to the stick and to the read-end of my device. Since the PushButton used to be placed at the very front of my device – and the connector is now at the very rear – I have had to change the Output PCBA quite a bit. The PushButton will be connected using old-fashion screw-terminals. I’ve looked at many connectors, only to realize that this solution is by far the most flexible.
The RGBLED is now located at the very front of the device, which should it good visibility to the pilot. The RGB LED will be used to indicate system status to the pilot. When the device detects it might malfunction, the RGB LED will turn red to indicate that the device should be turned off with the On/Off switch.
In the last iteration of the Output PCBA, I switched from an Active Buzzer (which generates a fixed tone at 2700Hz) to a Passive Buzzer (which can generate many tones, but needs a PWM signal to do so). I tried to see if turning the Buzzer on and off using software timers worked well. It more or less does, but sometimes the jitter involved in software timing becomes noticable. Realizing that I have two PWM lines available in the Raspberry Pi Zero 2W, I decided to use both: one for turning the Passive Buzzer on and off, the other one to change the tone. This means that I only need to tell the PWM hardware what to do and it will continue to do so forever. This also should reduce CPU usage a bit, and therefore power consumption.
PushButton
A side view of the measuring tape mount.A front view of the measuring tape and the mount. Tape rolls out towards the camera (instrument panel in flight).
My current plan is to mount a Membrane Button on the measuring tape mounting on the stick. I’m no too sure if the button can nicely follow the curvature of the plate, so I will make a replica and test that. There is a Plan B: handheld pushbuttons.
Idaflieg Sommertreffen
I received the happy news that my project has been accepted for this year’s Idaflieg Sommertreffen! This means that up to 4 aircraft will be fitted with a copy of my Angle of Attack indicator, and the pilots flying those aircraft will provide me with feedback on the device. I’m both very excited and grateful to be accepted, especially since I’m not a member of an Akaflieg and there’s some funding involved. In return I will write an article (both here and in Idaflieg’s winter report), and I’ll present the results of the project in the next Wintertreffen.
Part of the feedback I received was to investigate if my setup falls within the standard changes as defined by CS-STAN. It appears to fall within the description of CS-SC062a: Installation of an awareness function or awareness device. This means I’ll spend some time to look at the recommendations and requirements outlined in this standard change, to make sure my device complies and perhaps revise the manual a bit.
Speaking of a manual… last time there was none. I have started to write one, also in an effort to detect any blind spots. I’ve also started to ask some Akafliegs if I can mount my device in their gliders.
Testing
Since I’ve not yet had my device connected to an LXNAV S80, I’ve asked a friend from my gliding club if I can lend his Glasflugel Libelle with S80 for some testing on the ground. The Libelle is awesome in the sense that you can easily remove the instrument panel from the glider. So I spent some time with my friend’s panel…and everything worked right out of the box! That’s a huge confidence boost!
With the Sommertreffen approaching and approval to execute my project, I’m excited to get everything done. Most things are in place and work consistently. Some things, like the PushButton and the Manual need some attention. I intend to start series production a month in advance, so there’s probably one iteration left. We’re on final glide.
Last time, I wrote about some ground tests I did and the preparations I made for a refactor. In the past two weeks I’ve been able to refactor the project’s enclosure quite a bit, thanks to my preparations in OpenSCAD and my friend Roald, who owns a 3D printer..
First Enclosure
At Aero Friedrichshafen I learnt that the device should really be mounted in the instrument panel, in either a standard 57mm hole or in a standard 80mm hole using an adapter. So, as part of the “Test Driven CAD” efforts I made, I modelled the adapter-plate with screws and made a test make sure my neither the PCBAs nor the enclosure interfere with it.
I was very keen to prove to myself that this “Test Driven” bussiness has the potential for me to get things right the first time. TDD has been a massive improvement in my productivity as a software developer, so I was hoping to get similar improvements in working with CAD. I wasn’t disappointed…
First I added “ears” to the enclosure, such that it can be mounted in a standard 57mm hole. After I spent countless times inserting and removing the Raspberry Pi Zero 2W from the bottom of the enclosure, I decided to add some holes for the ports I use: micro-USB for power, USB-OTG for keyboard/mouse and HDMI for display. I also added a hole in the enclosure through which I can (for now) press the PushButton that’s on the Output PCBA.
Full of confidence I sent Roald a bunch of STL files…and he told me things were not okay. The top and bottom showed overlap and could not be mounted together, and my PCB support pillars on the bottom of the enclosure were too thin to actually print.
I implemented a test to verify that top and bottom do not overlap, and made some changes to get it right. For the PCBA support pillars, my CAD drawings were telling me that there is a conflict between the Raspberry Pi’s pin header and the support pillars (more specifically: the counterbores in the support pillars). I realized that I really don’t need counterbores near the Pi’s pin header, since the stack of PCBAs provides more than enough rigidity due to the pin header stack itself. So I removed the entire set of standoff screws on one side of my PCBA stack and solved the issues with the PCBA support pillars entirely.
I pushed my code to the CI/CD server and collected a set of checked STL files, forwarded it to Roald and waited. The next day at the airfield I received a new version of my enclosure… talk about quick feedback!
The first version of a CAD-designed enclosure that works! HDMI needs some work, but that’s it.
I was very pleasantly surprised by this enclosure. Everything fit inside as planned, I could close the enclosure and mount it to the adapter-plate. Apart from a small miscalculation for the HDMI port, everything worked exactly as intended. Test Driven CAD was a success! I quickly grabbed my laptop and fixed the HDMI issue. To the next version!
Registration at Idaflieg
Around this time it was time to officially submit my project to Idaflieg, so it can be considered for this year’s Sommertreffen in August. I was asked to describe my project, it’s goals, what I’ll do with the results…and potential safety risks. Using some of the experience I’ve recently gained on this topic from my workplace, I saw some potential risks that could drastically increase pilot workload. Not good. It was very clear to see that one solution would answer them all without a doubt: a hardware On/Off switch. Up to now I had always wanted to do everything in software, but it is beginning to dawn on my that you have to account for buggy software.
I finished the Idaflieg form and submitted it, and immediately started to redesign my Input PCBA to contain a hardware On/Off switch. Since the switch should penetrate the enclosure at the front, this also means changing the enclosure (adding a hole at the right place). I found out that my PCBA was too far away from the front of the enclosure to make the switch actually usable by the pilot. So it was time to really test my CAD skills now and reduce margins around the PCBA stack to 0.5mm and make an additional hole for the SD-card to stick out. This was all done in CAD, and I kindly asked Roald to print a new version of the enclosure again.
The second enclosure. The SD-card fits, and HDMI port is now aligned. The new On/Off switch is also visible.
Both the new PCBA and the enclosure arrived at the same day. I put in the Raspberry Pi, and saw that everything fit perfectly. This was a really proud moment! The hole for the On/Off switch was exactly at the right place and the SD-card also aligned perfectly. The only issue was…the switch now prevents me from sliding the entire PCBA stack inside the enclosure. Not totally unexpected, but something that must be fixed in the next iteration.
The PushButton
I was really struggling with the wish of having the PushButton mounted on the stick. Since there is no standard shape or even diameter for sticks in gliders, I found it difficult to come up with something that will work reliably with very little effort or customization. So I started to ask around.
Not only does Roald own a 3D printer, he also possesses the kind of hands-on creativity that I often envy. Things just come to him in a way that I can’t replicate. When I met Roald at the airfield, he showed me this:
Roald shows me his son’s book with music
These booklets are just a few euros, and contain about five of these membrane pushbuttons with flexible PCBs attached to them. I got one of them, and opened it up:
The insides of a different music book.
It contains membrane buttons. They can easily be mounted to anything with a bit of tape or even some Velcro. After a bit of googling I found that there also exists a similar technology called metal dome buttons, and ordered of of those:
Test of a metal dome button. Note the tactile feedback it provides.
I think this might work well, since it can be mounted on the already-present Zacher tape measure mount. It provides tactile feedback as requested, and can easily be installed or removed. The flexible PCB attached to it appears to be strong enough, although the DuPont connection at the end still requires some thoughts.
I am extremely pleased with the amount of progress that I have been able to make in just two weeks. This was accompanied by a feeling of playfulness and flow, which seems a good indicator of being on the right track with eXtreme Manufacturing. Next up is getting the PushButton right, and perhaps starting to write the pilot’s manual.
Last time I wrote about how I got valuable feedback during my visit at Aero Friedrichshafen. As I mentioned, I’m now forced to go back to the drawing board with my enclosure. But not before I gather some more feedback…
Ground tests
Ground tests in one of my club’s DG-1000S gliders.
Unfortunately I was unable to test my hardware in flight, but I was able to spend an entire day with the device connected to one of my club’s DG-1000’s. These are all equipped with an LX8000 and they have the PDA port avaiable for me to connect to. My main objective was finding bugs and more importantly: checking EMC compatibility. I connected everything and found no sings of any EMC issues. During the five hours everything was connected, the radio didn’t turn on, other instruments didn’t behave in an unusual way. No extra noise was audible over the speakers. I consider EMC to be okay for the LXNAV version of my hardware. The other input board, which features a DC-DC Converter (12V to 5V) module, will need a separate test.
I found a few bugs here and there, which were (ironically) all located in parts of the code that I hadn’t covered with Test Driven Development. I can do a better job at separating code that steers hardware from code that’s purely logic. That way I can test more of my code and find these bugs earlier.
After some bugfixes, I could see data flow. The $LXWP0 NMEA sentences from the LX8000 were parsed and the Indicated Airspeed was extracted from it.
My “Tap Detection” algorithm is too sensitive and will be removed. For the final Idaflieg tests I need a physical button anyway, so no use in keeping it around.
Test Driven CAD
A new enclosure arrived during the past few weeks. This enclosure was fundamentally different from previous versions in that I designed it entirely in OpenSCAD. Like with all first tries, this first enclosure was unusable. However, it did reveal important lessons about my CAD process: there are way much details in a CAD model for me to keep track of.
So I started to wonder what “Test Driven Development” in CAD might look like. I want to have an automatic check that tells me if my design satisfies certain constraints. Perhaps the most important constraint is: do the contents of the box actually fit? Another one might be: can I plug in the RJ45 cable? You get the idea…
I solved this by modelling the contents of the enclosure, the PCBs, the standoffs, the nuts and bolts. I then created a scene that is defined as the intersection between the enclosure and the contents. If there is any conflict between the enclosure and it’s intended contents, this intersection will not be empty. When I render this intersection from 3 angles, all 3 images should be empty. To check if the images are actually empty, I wrote a small python script.
I can now make changes in CAD and get feedback on my changes in a matter of seconds. This makes me much more confident that my next iteration of the enclosure will work. It makes me also a lot more confident to refactor the enclosure.
PushButton
A closeup of the control stick of a DG-1001S, with measuring tape and force meter attached to the control stick.
One thing that I’m really struggling with is the PushButton location. I would like to place this at the stick, as one of Idaflieg’s pilots suggested, but it is proving to be difficult. There’s off course also a risk in mounting things to the stick, especially since there’s also a measuring tape mounted to the flight stick during the Zacher flights.
I have planned a session with a friend to try to address this, but anyone who has ideas is more than welcome to suggest them!
With some foundational work done, I’m starting to feel ready for a major refactor of the housing and the pushbutton. I am filling in the forms to officially submit my project for this year’s Idaflieg Sommertreffen, and I’m looking forward to the feedback from Idaflieg’s pilots.
Last time I wrote about iteration 1 of the Output board, which more or less failed. I managed to burn the Red component of the new RGB LED and the new passive buzzer didn’t make any sound. I also introduced the BMI270 IMU, which could serve two functions: as accelerometer for planes equipped with an LX8000/LX9000 computer and a replacement for the pushbutton. I fixed this PCBA and visited Aero Friedrichshafen, where I got very interesting feedback from my friends at Idaflieg.
Fixing my mistakes
Both LED and Passive Buzzer now work.
First, I fixed my mistakes in the PCBA. With the help of a kind colleague, I learnt about the voltage drop across LEDs. The RGB LED now works fine and all components shine equally as bright. Indoors it is visible through the PLA housing, but it might not work in bright sunlight. We’ll see.
The buzzer now works too. I am working on some software errors, but the hardware works. In software, I’m using the timerfd mechanism combined with epoll to turn PWM on and off. Updating the timer does not appear to work, so I’ll probably write a small test program to see what I’m missing. While I use Test Driven Development for most of my code, I find it difficult to test code like this with side-effects.
The enclosure now also works, and I took that opportunity to bring my creation to Aero Friedrichshafen in order to show it and get feedback.
Feedback
The enclosure with PCBAs as I brought it to Aero Friedrichshafen
So I took my new creation to the Aero. I met up with some friends from Idaflieg to proudly show the progress on my project and received some feedback.
The first and most important feedback was: during the flight the pilot should be assumed to be with both hands on the stick. This means I cannot ask them to use a PCB-mounted button or the IMU to mark when the airplane stalls. There should be a button on the stick. I can connect this with long wires and screw-terminals to the PCBA, but this creates new problems. Since I’m now connecting something to a primary flight control, I have to ensure that I do not ever prevent the pilot from using that control. The wires involved cannot restrict movement, and they may not move everywhere during inverted flight. I have to think of a way to connect the button to the stick in a way that does not obstruct the measuring tape that Idaflieg pilots also use during the same flight. This will take some thoughts.
The second piece of feedback was that the box may not be taped to the top of the instrument panel. This was my initial plan, but the pilots clearly stated that this obstructs the view of the pilot and is not safe for inverted flight. Instead, I have to prepare my enclosure for mounting in a standard 57mm hole in the instrument panel. With an adapter I can also mount it in 80mm holes if that works better. This means the enclosure should be larger and should contain either horizontally oriented holes or something that screws can tap into. The experiments with self-tapping are not enough here, I need to have a very secure connection to the instrument panel.
Next steps
Especially for the enclosure it’s back to the drawing board! I decided to abandon creating my enclosures with EasyEDA Pro and started experimenting with OpenSCAD. OpenSCAD is a code-based CAD tool. This requires much more time to create something than for example Fusion360, but it gives me the advantage of including checks with the assert function. This allows me to check that the housing can actually interface with the PCBA stack, something which I had to measure by hand before.
I will have to change the Output PCBA in order to include screw terminals for the – now remote – pushbutton. If the instrument is mounted in the instrument panel, the RGB LED and the buzzer possibly also need to change place. This might involve a large change in some PCBAs, especially if I decide to change the orientation of the PCBA stack.
Before I redesign everything, I want to test one other important aspect: EMC. Since I have something that technically works, I want to fly with the system in order to get more feedback.
With the season well underway, the rain becoming more and more rare, and mountains of inspiration from Aero Friedrichshafen, I’m eager to test my project further and learn more. Let’s get this thing in the air!
Last time I wrote about the next iteration of the Output PCBA. The PCBA features the first I2C IC, the Bosch BMI270. A passive Buzzer instead of an active one, which should allow me to produce different tones if users request that. And finally an RGB LED, which should give me the opportunity to convey errors to the user.
Long story short: this PCBA was kind of a failure. The RGB LED was fried on first try, and the buzzer didn’t produce any sound. I also made some minor mistakes with the BMI270.
Reflection
This was the trigger for some reflection. When I started to design this PCBA, I caught myself thinking: “I am getting the hang of this. Let’s try to make bigger steps, and let’s make progress without asking for help. That’s too slow.”. I felt greedy, rushed.
These feelings are not new to me. Due to my inherent sense of urgency, this is a trap that I’ve stepped into quite a few times already when creating software. Where in more bureaucratic processes, I often have to wait on others, I find myself to be the bottleneck more often in Agile processes. This is not a bad thing, but something I have to learn to deal with. In making software, the thoughts involved are usually something like “This code is so simple that I don’t need to test it, let alone write tests in advance (as TDD prescribes).”. Which is inadvertently followed by the humble lesson that my code doesn’t work and that I’ve attempted to go too fast. I need to take a step back when I feel impatient and come back when I’m calm enough to follow the practices that I know work well.
The overall lesson, in both software and hardware, appears to be: slow down to speed up.
RGB LED
The RGB LED after some tests. The black burn mark is in the red component.
Back to what I screwed up and how I fixed it. The RGB LED had a datasheet…in Chinese. In my rush to complete something, I didn’t translate the datasheet and ended up mistaking the maximum reverse voltage (5 Volt) for the maximum forward voltage (around 2.4 Volt). The values for the maximum forward voltage differ per color, but the Red component has the lowest value. As a result that component burnt out immediately. Not knowing what happened, I tried to measure what was going on and had to conclude that everything worked as intended. Then I noticed the black marking on the LED itself. When I took unused PCBAs out of the box, I got what happened. I looked up the datasheet, translated it and got what happened.
Despite being able to fix this LED, I did conclude that the amount of light coming off the components was not enough for me. The intention is to illuminate the PLA housing from the inside, giving it a glow. This all has to happen in bright sunlight, so it needs to be bright. Power consumption is not my biggest worry here, since I will only turn on the LED in case of errors.
In an attempt to make all three LED components equally as bright (450mcd), I took some time to precisely calculate the needed resistor values for the PCBA. Not because the project requires it, but to show myself I understand this part of the design well.
Passive Buzzer
I expected the passive buzzer to work the first time, since I had already tested a passive buzzer on a breadboard. The setup was slightly different, as I didn’t use an NPN-transistor to toggle it, but I figured that my code worked and I had already used the same transistor for the active single-tone buzzer that I used in previous iterations.
Since my new buzzer was a passive version and thus does not include it’s own oscillator, I figured I wouldn’t need a flyback diode like I ended up needing for the active buzzer (remember the voltage spikes I wrote about earlier).
The buzzer only made small clicking sounds. Measuring what happened, told me that everything up to the NPN-transistor worked as expected, but the voltage levels around the buzzer made no sense and hardly correlated with the ON-OFF switching of the NPN-transistor. I was genuinely puzzled. My kind colleagues gave me some pointers on how they would connect he buzzer. In the end though, I ended up going back to the basics again: the datasheet. I found that I again had mistaken the maximum reverse voltage for the maximum forward voltage. I had picked a 30 Volt buzzer instead of a 5 Volt version.
So I replaced the 30 Volt buzzer with a 5 Volt version, and made sure that the datasheet also includes a application circuit. The circuit included a 1N4148 flyback diode I already used.
IMU – Bosch BMI270
I was genuinely excited about using the BMI270, since it is relatively expensive ($3 per PCBA) but has a good reputation among drone pilots. It is my first I2C device in this project, and thus a nice experiment to see if I understand the I2C bus on the Raspberry Pi enough to talk to it. According to online sources, no pull-up resistors are needed, so wiring was easy.
The BMI270 also has a downside: it is one of the few IMUs that needs to load firmware before actually working. Before loading this firmware, one can identify the device but not much more. The firmware is a whopping 8 KiloBytes large, which is kind of large compared to the 12 bytes that I normally read or write to I2C devices.
I was happy to see the device on the I2C bus immediately, and got to work with the “quick start” procedures in the datasheet. This worked more or less, except for the actual loading of the firmware. I got a very generic “Remote I/O error” from Linux, but a quick search online taught me that you have to send the firmware to the device in 32-byte chunks. That worked just fine, and after increasing some settle times beyond the datasheet values I was able to read accelerometer values.
One thing that I forgot with this device, is to attach the two interrupt lines that it features. These might save me some time and effort, since the device has a built-in step counter. The device might be able to interpret any “taps” as “steps” and thus give me an interrupt if a pilot taps on the device. Since I was already creating a new PCBA, I attached those two lines.
Enclosure
For the enclosure I ordered a third iteration. This was not intended to be production-ready, but instead to find the right diameter for the PCBA supports. In the first iteration, which was printed in SLA, I could have the m2.5 screw self-tap into the material. SLA appears to be somewhat elastic, which I suspect makes this possible.
The second iteration was printed in PLA, which appears to be less elastic. With the same diameter, self-tapping was not possible.
I went down a big rabbit-hole here to see what would be nice. My goal is to keep part-count as low as possible and make assemble simple too. Whenever I can use parts for multiple purposes at once, I would like to.
I decided not to use inserts that you have to melt into your 3d printed part, or tap threads into the 3d printed material. Instead I opted for mounting the PCBAs and securing the two halves of the enclosure with the same screws. This means the enclosure has counterbore holes on both sides, so I can use the m2.5 spacers I already have for both attaching the PCBAs and keeping the enclosure together.
This time I’m taking my time before ordering. I am getting closer to actual testing, so there is really no need to rush things. Slow down in the short term to speed upin the long term.
