The first week of December my gliding club held a gliding competition at Springfield. I was asked to help with the flight recording. I was interested in learning what happens during a competition and it would give me access to a lot of instructors and glider time, so I agreed.
Canterbury gliding club currently uses a python desktop (wxGTK) application to record all the flight times for billing and maintenance purposes. When recording flights, you collect the details of the flight (glider, pilot, instructor, launch method, etc). Then when the launch begins you click a button that records the time, and similarly when the tow plane and gliders land you click another button to record the landing times. The program determines the cost and at the end of each day (when closed) it generates a number of reports and emails them to interested people. The system is pretty easy to explain to other people and works perfectly almost all of the time.
I’ve been thinking about replacing it with something web-based. Primarily because the current system is very reliant on the 1 laptop it runs on, which is getting old and doesn’t last very long when not plugged in. Ideally, something that has the same flow and looks familiar enough that people changing over won’t require any additional support. The current system stores everything in XML files, one per session unless the session is restarted (after a crash or accidental close) in which case it starts a new XML file that includes all the entries from the previous file. This seems sane, except the reporting tools that can be run later don’t handle this at all and show/count the same flight multiple times.
The reason I want to make a web-based system is so I can be more helpful on the gliding field. Gliders have 2 or 3 wheels, but they are all along the center-line. This means they need someone to hold the wing up when they are launching. The current system means that the person recording the flights cant do this, or needs to record the time and then adjust the flight later. If it was web-based, they could use their phone/tablet to record the launch time more accurately.
So I wrote a Django app that could handle the flight recording functionality. Actually, I wrote one that could do everything up to calculating the flight cost, but I decided that I was stuck and it wasn’t going to be easy to add the features we needed. So I started again having learned from my choices and made some different decisions. By the time I was asked to be the flight recorder I had something that could record flights but not much else.
I thought about how I could make use of what I had and if that would improve my flight recording ability or not. It would need some work to get something that could hand over the parts it didn’t implement too the existing program. I figured if I could get it running I would give it a go, the worst that could happen would be someone telling me to stop using it.
I determined the MVP was something that could export the session data. Then I could copy that file to the existing laptop/program and run the reports from the existing program. This would leave the current laptop as the authoritative source of flight data, and my system as just an alternative interface for flight recording. I didn’t know which pilots I was getting, so I also made an importer that could import all the existing pilot records (which also captured most of the possible gliders).
As I developed all the features I tested them as much as possible how they would be used. This helped me remove the obvious bugs (doesn’t accept certain options, expects form fields that aren’t present, etc). Also, I made some interface improvements because of this (even with 4 pilots, searchable select boxes are nicer). The pilot importer was pretty easy once I found a plugin that could read XML. The exporter required a bit more work, not because writing XML is overly hard, but because the existing system uses some slight different notation for some fields and isn’t tolerant of files it didn’t produce.
In the week before the competition, I was pretty happy that I had something I could use. So I spent some time setting up some network equipment and a server that I could easily transport and set up on the field. OpenWRT on a carambola2 to provide DHCP, DNS, and access to the internet via the existing link. A Bullet M2 HP to provide WiFi across the entire field. I used a CubieTruck as the server.
When I got to field I set up all the hardware, verified that I could connect from my laptop and got to work. First I got the latest version of pilots list and attempted to import it. The first bug, I used a hardcoded path and my dev environment has a different path that on the CubieTruck. A second issue, importing the pilot data took a long time, multiple minutes. Turns out the CubieTruck I/O performance is a lot worse than the Intel Atom D525 dev environment I was using at home. After importing the pilot data, I was able to successfully use it. I had to make some additions to the database because we had additional tow planes and pilots from other clubs. So far so good.
Now for the part, I really wasn’t sure about, actual flight recording. I was pretty certain everything should work. As long as I could get all the pre-flight data I needed I figured that flight recording should go okay. I know most of our club pilots and which glider they fly, so that solved most of my problems. The person doing the competition scoring was sitting next to me and knew who the other pilots/gliders were. So with all the flights loaded, I got a bit scared, what if something goes wrong? I already had a pen/paper because I had made a map of tow planes to pilots because I would have to update this flight data right before launch. So I figured everything that I click gets recorded and I can always get it later when I’m less stressed. Anything that I wasn’t able to enter I could write down. I almost started the existing system, but I needed my laptop and the existing system just to keep up with the launch rate, dual recording launches wasn’t going to happen. Plus, I had tested it and no drop-dead issues had been seen.
Launching was successful. All the gliders got airborne, and they all showed up in my currently airborne list. Landing the tow planes was mostly successful, except they were landing far away and if I missed the radio calls it’s a bit hard to tell the difference between 3 aircraft of the same model. So far I hadn’t left the existing computer, so other than having 2 flights open at once the benefit was marginal. Later when the gliders were landing, I was able to stand outside with a radio and listen to them and watch them land. I could load the flight on my phone and land it without having to go back to the desk. This was especially helpful when they started landing behind where I was sitting and they could fully stop before they appeared behind the hanger.
Exporting the session data and importing it into the existing system worked well. I put a marker in the session notes to make it obvious that something different happened in case there were any errors. Something asked me about it a few days in, but this was the only thing they noticed.
Would I do it again? All the days I was there I used my new system. So I would definitely do this again (and I have been back with some more changes and tried those too). I had done enough testing to know that everything I was going to need was going to work. So I was hoping that I didn’t forget to implement or test something critical. The biggest problem I had was my test server being different from my dev server. Mostly the performance different hurt a lot, but also the full path being different was enough to cause a bug.