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 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
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.
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!
Testing final assembly
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.