Month: April 2020

This fancy title hides the magic of future track calculation and possible collision prediction followed by reasonable warnings. Reasonable in this case should express no crazy alerts while thermalling with twenty other gliders or in situations like following a tow plane on a fifty-meter-long rope. How is it done? Witchcraft!!

We can work with the information available at each moment coming right out of the thin air. The OGN trackers can and eagerly do receive transmissions from other units in reception range. By sorting and ordering these beacons we could (re)construct trajectory of each particular airborne “target” and in theory predict its future behaviour by employing sophisticated mathematical models. A little concern comes with complexity of such methods and the requirement of real-time availability of such results while all computations need to be performed on a fairly limited tracker’s brains. Hence, some simplifications had to be made..

Let’s start from a single point – the most recent beacon received. Such packet of data contains identification of the other airborne vehicle, its speed, altitude, heading, climb/sink rate and angular velocity. From this single point we can iteratively estimate future discrete locations with certain precision. In case of having two (or even more) consecutive locations received from a single transmitter, the accuracy of this method can rise significantly. Between two known states of the other object we can also include speed changes (i.e. acceleration or deceleration), angular velocity and altitude deltas into the calculation. However, the more distant future we look into the more imprecise this prediction will become. This is not a crystal ball, but it works fairly well.

Exactly the same track prediction can be done based on our most recent location(s) and flight directions. After combining all track-points by calculating distances along corresponding (time-wise) pairs while incorporating headings, climb/sink rates and angular velocities we can issue informative warnings to the acting pilot in charge. And that is the theory of this operation.

Now it’s time to put these hypotheses under real-world flight testing! If you don’t hear from me anymore all this was obviously wrong 😉

Manual maintenance could be a lot of hassle especially when one keeps multiple OGN receivers running. You need to update one thing on the first location. Then you decide to do something similar on the second while the third one wants to be kept up to date too. You really don’t want tame differently configured receivers anyway. Later on, when everything is nicely set up and in sync a friend wants to receive a local weather station or something completely else..

Just a few days ago I hit in my podcast listening queue to a CZPodcast‘s (Czech only) an episode about something called balena.io. As I am skipping the tracks in the queue randomly and I’ve already noticed this balena-thingy to be mentioned a couple of times, it became obvious I have to give it a try. Not only by listening that particular episode but also by installing it on my (surprisingly supported) Raspberry Pi of the very first generation!

It all starts with creating an account (eh, another password to remember) on balena.io website. I was pleased those guys support so many devices, even my Pi 1. To install the “balena os” you need to pre-configure an image that you then just download and flash on the SD card. An old two-gig card was just fine and I was running a Balena node in (almost) few steps (well, this tutorial looks lengthy but is is not that bad, really).

Now: what about the app? Before installing the OGN receiver binaries I’ve decided to run a simple script that would send just some messages across the net just to have a starting point for a more complicated setup. The experimental script was really simple:

#!/bin/bash
id=`hostname`

mqHost=$MQ_HOST
mqPort=$MQ_PORT
mqUser=$MQ_USER
mqPassword=$MQ_PASSWORD

i=0
while true
do
    ((i++))
    msg="ahoj '$i' from '$id'"
    echo "Sending msg"
    echo "  $msg"
    mosquitto_pub -h $mqHost -p $mqPort -u $mqUser -P $mqPassword -t testing/pi1 -m "$msg"
    sleep 4
done

Creating a Dockerfile based on the example was a bit trickier. The documentation describes there can be multiple dockerfiles and the order in which they are processed. There is also something called Dockerfile.template which ought to help you with multi-architecture setups and some other matters. And here was the spot I hit a wall. The example Dockerfile.template did not work due to the first line “FROM balenalib/%%BALENA_MACHINE_NAME%%-node:10-stretch-run” – on git push the hook on the server complained something about uppercase letters in this line. Googling it was helpful only to that extent that there shall be another – dockerfile.template (with lowercase D!). Solved by creating a symlink. However, the git hook complained the ‘Dockerfile’ is missing (had to make a copy of Dockerfile.template; yet another symlink didn’ help). And the initial image had to be changed. The resulting Dockerfile/Dockerfile.template/dockerfile.template is then as follows:

#FROM balenalib/%%BALENA_MACHINE_NAME%%-node:10-stretch-run
FROM balenalib/rpi-debian:stretch-run

RUN apt-get update
RUN apt-get install mosquitto-clients -y

RUN mkdir -p /opt/app
WORKDIR /opt/app

COPY testScript.sh .

ENTRYPOINT ["/opt/app/testScript.sh"]

Concequently, by calling git commit & git push the image gets build on the balena cloud server and after seeing blue unicorn you know it got through successfully. In the project dashboard you can observe the docker-image update progress on all your devices (you can have as many as the free quota (10) or your wallet allows).

So far so good. A neat great on the device detail page is you can seamlessly connect straight to the shell and also into a running docker image (or images if there are more of them). But wait – what is that device load? 18? I understand it is only Pi 1 but..!? The ACT LED on the board indicates there is no disk IO (which is a good sign – the card is old, slow and I don’t want it to die by wear too early). It could be caused by the docker image update process. The Pi is connected to the Balena cloud servers through a VPN and the update itself could be a bit demanding. Lets wait for some time for things to settle down..

After an hour the load was still around 12. I guess the 256MB of RAM is just too little. The Compute Module 1 has double of that and it may do the difference. This is a dead end for my Pi 1 in combination with Balena. Our most powerful receiver runs on quad-core Pi 3 is currently down and I will have to climb the hangar roof anyway – will try that ONE very soon!