The primary goal of the students' project was to build most of the instrumentation for a real instrument panel. I provided the API and some of the instruments as examples. Here we see (from top left) the airspeed indicator, attitude indicator (or artificial horizon), altimeter, clock (with timing capability), GPS, then on the next row the turn coordinator, directional gyro, vertical speed indicator, tachometer, then on the third row the automatic direction finder, VOR instrument, ILS (localizer, glideslope) instrument, distance measuring equipment and marker-beacon indicator, and finally on the bottom right the VOR, ADF, and ILS receivers. All of these are separate, resizable instruments rendered by a scalable-vector-graphics engine I designed in Java.

I told the students if they didn't take these tasks seriously, they'd be doing the horizontal situation indicator (HSI), which is a great instrument to have, but it's a little complex to build.

My philosopy to teaching software engineering is to make students work in depth with a subject they know nothing about, or perhaps they think they do, but really don't. This interdisciplinary approach forces them to learn the subject to some degree in order to apply their own skills to solve problems within it. Not only do they learn more about CS, but they also learn about something else, and most importantly, they learn how to learn, which is a skill that will carry them through their careers and lives.

A secondary aspect is to show how computer science plays a core role in the work of practically every other technical field. I got to show the students what combining computer science, electrical engineering, mechanical engineering, and aviation looks like. Most real-world systems incorporate the first three.

multimechatronics.com

The students were given working solutions to many of their tasks so they could learn how the systems really worked. Here is the testbed for the automatic direction finder (ADF). The left panel is a GPS display, which they didn't need to make. The top row indicates the actual location of the UAV in latitude, longitude, and altitude (above ground level), as well as its heading. The next row is the latitude and longitude of the cursor, as well as the bearing and distance to it from the UAV. The +/- buttons are for zoom, and TOP alternates between the north-up and track-up modes.

On the right are two variants of the ADF: top is a fixed card, and bottom is a moveable card. For both, the needle points to a non-directional beacon (NDB). Below them is the ADF receiver that tunes into the NDBs on the chart (which aren't shown).

The VOR (very-high-frequency omnidirectional range, which nobody ever says) is another point-to-point navigation system, like the ADF, but it provides course information in the form of a vertical needle that deflects left or right of the desired course in the center. Below that is the distance measuring equipment (DME), which indicates the distance to the VOR station. (The lights are addressed below with the ILS.) At the bottom is the navcomm receiver for selecting the active and standby stations.

The localizer and glideslope instrument displays horizontal and vertical navigation information from an instrument landing system (ILS). It behaves similarly to the VOR (in fact, they are derived from the same code), but it allows the aircraft to fly down a corridor to the runway for landing. The marker-beacon lights (blue, orange, white) on the DME correspond to fixed distances from the runway.

The architecture for the ADF system looks like this. The students had to build it with my API.

Here's the DME.

And then the VOR.