Long ago and far away, back when I was doing a lot of real-life soaring, I was heavily involved in the development of the ClearNav flight computer/navigator and I’d like to think I made it better than when I first started working with it. Among other things, I helped develop the thermalling assistant in ClearNav, and also helped port that functionality to XCSoar.
Now, many years late, I am no longer doing real-life soaring, but I’m once again starting to fly in virtual soaring races using the Condor2 soaring simulator. As a part of that, I have been attempting to use the XCSoar flight computer/navigation assistant as an external adjunct to the in-sim Condor flight computer. In particular, Condor2’s flight computer has no capability to support AAT/TAT tasks, so using an external PNA (Personal Navigation Assistant) that does support AAT/TAT tasks makes sense. To facilitate this effort, Condor2 can output GPS NMEA sentences to an external device.
I have nice dual-24″ monitor setup at home, so my initial thought was to run Condor2 on one monitor, and the PC version of XC on the other. This actually works, but with a big ‘gotcha’ – when Condor is running, it captures the mouse and keyboard input, and won’t let it go unless you use ‘ALT-TAB’ to switch to another running program. This means that if you wish make an adjustment in XCSoar, you have to ALT-TAB out of Condor2 and into XCSoar, make whatever adjustments, and then ALT-TAB back to Condor2 – more than a little bit messy. In addition, while ‘away’ from Condor2, it is continuing to fly along without pilot input – maybe OK for a flatland task, but definitely bad for one’s (simulated) health in gnarly terrain.
So, my next idea was to buy a cheap Android device and run XCSoar on it, connected to Condor2 on my PC via Bluetooth. I found a really nice PRITOM M10 10 inch tablet with 2 GB RAM, 32 GB internal storage on Amazon for about $50USD, and figured out how to get NMEA data to it using Bluetooth – nice!
Then I constructed a small AAT/TAT task in Condor2’s default Slovenia scenery, loaded the same task into the M10, and flew it multiple times to see if I could figure out how to best use XCSoar to optimize navigation through both defined areas. This worked really well, but I ran into some problems with the XCSoar software. At least in the Android version, the ‘AAT Time’ and ‘AAT Delta Time’ readouts blanked out several times during the tests, rendering XCSoar pretty much useless for AAT/TAT tasks (see this post for all the gory details).
The above experience led me to think about looking through the source code to see if I could find out why these AAT-related values were going missing. Way back in the day I had done this once before when I ported the ClearNav thermalling assistant algorithm to XCSoar, but that time I didn’t know enough about Github repos and pull requests to do it the right way – I had to throw myself on the mercy of the other developers to make it happen. Since I’m now retired and not flying in real-life anymore, I have a bit more time, so I decided to give it a go.
I started by reading though the XCS Developer Manual, where I found that the primary development platform for XCSoar is Linux, and I haven’t played in Linux-land since my days as IT manager at The Ohio State University ElectroScience Lab a couple of decades ago. Nevertheless, I had an old Dell Precision M6700 15″ ‘desktop replacement’ laptop hanging around doing nothing, so I dug it out and installed Ubuntu 12.4 LTS on it. I chose Ubuntu because it was reportedly easier to use by beginners, and known to install OK on my laptop model. Installation was pretty easy, and using the information in the developer’s manual I was able to clone the Github repo, install the required packages, and actually get the default UNIX version of XCSoar compiled and running on my Ubuntu laptop – yay!
With XCSoar running on my laptop, I decided to try running the same AAT/TAT test task with Condor2 GPS NMEA sentences connected to XCSoar on my Linux laptop using VSPE on my windows box to connect Condor2 to a TCP port, and ‘socat’ on the Linux box to create a bridge between TCP and UDP ports. Then in XCSoar I set ‘Device A’ to point to the UDP port created by socat. Amazingly, this all worked! (See this post for the details). With this setup I ran the test AAT, but the ‘AAT Time’ and ‘AAT Delta Time’ values stayed rock-solid through the entire task – yikes!
This result led me to believe that maybe I could just abandon the Android M10 and just use XCSoar on my Linux box to fly AAT tasks. However, when I actually tried this on a Condor2 race, the Linux box version of XCSoar kept dropping GPS inputs – don’t know why.
So, I decided to see if I could compile XCSoar for Android on the Linux box and ‘side-load’ it onto my M10 Android tablet. If this worked, then I could instrument the code on my Linux box, run it on my M10, and maybe figure out why the AAT Time/AAT Delta Time data was getting corrupted. After all, how hard could it be – I had already cloned the source repo and gotten the UNIX target to compile properly? As it turned out – “Pretty Darned Hard!”
I was stumbling around on the XCSoar developer’s forum, trying to figure out why compiling for Android wasn’t working, when Ronald Niederhagen took pity on me and sent me a direct email with some suggestions. The foremost of those was, ‘Install Debian’ and your life will be easier’. Although I had noticed some references to Debian on some of the development steps, I hadn’t paid much attention to it – after all, all Linux installation are all the same, right? Wrong.
So, I went off into a side project for replacing Ubuntu with Debian on my Dell laptop. Once I got that part accomplished, Ronald sent me the following instructions:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
mkdir 7.42_tst cd 7.42_tst sudo apt-get install git git clone --recursive https://github.com/XCSoar/XCSoar sudo ./XCSoar/ide/provisioning/install-debian-packages.sh sudo apt-get install vorbis-tools cd XCSoar make -j4 ./XCSoar/output/UNIX/bin/xcsoar ./XCSoar/ide/provisioning/install-android-tools.sh make -j4 TARGET=ANDROID ls -l XCSoar/output/ANDROID/bin/*apk |
The first ‘make’ command above ran successfully, and I was able to launch XCSoar on my Linux Debian laptop with no problem. However, the second ‘make’ command to compile XCSoar for Android failed miserably – ouch!
When I reported this result to Ronald, his reply was:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
You are not far from success. You don't seem to have java which this script seems to need. I guess this will do it: sudo apt-get install default-jre Then see if java is there: which java make a directory: mkdir $HOME/opt This is were it installs sdk and ndk if JAVA_HOME is not set. Then run ./XCSoar/ide/provisioning/install-android-tools.sh After that see the result: ls -l $HOME/opt If you see sdk and ndk there then go ahead with make -j4 TARGET=ANDROID |
Ronald’s first sentence — “You are not far from success” was pretty heart-warming. I have done a LOT of programming over a half-century of engineering, and I was well aware how easily projects of this nature can spiral out of control, so ‘hearing’ such encouragement from such an obviously competent source was a life-saver.
Anyway, I ran the command to install the Java jre, confirmed success with the ‘which command, and then re-ran the ‘install-android-tools.sh’ script. This time it completed OK, so then I ran the ‘make -j4 TARGET=ANDROID command. This time it seemed to complete OK, but no corresponding *apk file was generated.
When I reported this to Ronald, he asked me to re-run the compile, but this time redirect both the normal (i.e. stdout) and the error (i.e. stderr) outputs to files and send them to him. OK, so I resurrected (with the help of Google) my 20-year old memories of how to redirect to files in Linux, got the job done, and sent them off to Ronald. In no time at all, Ronald sent back the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
stderr says it can't find javac. Please try which javac Here is what mine says: ronald@debian-rn2:~$ which javac /usr/bin/javac ronald@debian-rn2:~$ ls -l /usr/bin/javac lrwxrwxrwx 1 root root 23 Nov 1 00:39 /usr/bin/javac -> /etc/alternatives/javac ronald@debian-rn2:~$ ls -l /etc/alternatives/javac lrwxrwxrwx 1 root root 44 Nov 1 00:39 /etc/alternatives/javac -> /usr/lib/jvm/java-17-openjdk-amd64/bin/javac ronald@debian-rn2:~$ ls -l /usr/lib/jvm/java-17-openjdk-amd64/bin/javac -rwxr-xr-x 1 root root 14440 Nov 1 00:39 /usr/lib/jvm/java-17-openjdk-amd64/bin/javac ronald@debian-rn2:~$ |
I had no idea what ‘javac’ was (other than a suspicion it was java-related). When I ran the ‘which’ command on my box it came up blank, so obviously Ronald was on the right track. After a couple more back-and-forths, Ronald said:
1 |
try "sudo apt-get install default-jre" |
I ran the install, and FINALLY I was able to get the XCSoar Android version installed:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Ronald, Success!! frank@M6700:~/7.42_tst/XCSoar$ make -j4 TARGET=ANDROID >240128-stdout2 2>240128-stderr2 frank@M6700:~/7.42_tst/XCSoar$ find -type f -name *apk ./output/ANDROID/dbg/build/unsigned.apk ./output/ANDROID/dbg/build/aligned.apk ./output/ANDROID/bin/XCSoar-debug.apk ./output/ANDROID/android/resources.apk Stdout & stderr files attached: Now working on getting APK into my Android tablet! |
With more help from Google, I was finally able to get XCSoar ‘side-loaded’ to the M10. As it turned out, the trick was to copy the *.apk file to my Google Drive site, and then use ‘Drive’ on the M10 to ‘install’ the app. Basically the process is:
- Copy the *.apk file from my Linux laptop to my Google Drive site
- Uninstall XCSoar from the M10 by dragging the icon to the trashcan
- Use ‘Files->Drive’ to access my Google Drive account from the M10
- Double-click on the *.apk file in Google Drive
- Select ‘install’ on the resulting dialog.
Here is a short video showing the process:
So now, Thanks to Ronald Niederhagen, I’m all set for XCSoar development. In the meantime, however, the original reason I wanted to get into XCSoar development (disappearing AAT infobox data) seems to have — disappeared. Not to worry though, as I have lately gotten some other ideas for XCSoar ‘improvements’ 😉
A last thought on this subject from a septuagenarian engineer/programmer, I appreciate how much time and effort Ronald put into helping a noob along. Ronald didn’t know me from Adam, and yet he took the time to help. He didn’t know that I’m a 75-year old broke-down engineer, ex-pilot, (ex – everything, for that matter!), and I don’t know anything about him, either. Heck, Ronald could be a 12-year old kid with acne programming in his parents’ basement wearing pajamas, but in this case he was clearly the teacher and I was clearly the student. It’s pretty cool when the internet and free discourse facilitate this kind of international (and maybe intergenerational) collaboration.
Stay Tuned,
Frank
Pingback: Using VS Code to Debug Linux Makefile Projects | Paynter's Palace
Pingback: Convert Condor Task Briefing Custom Waypoint Description Blocks to XCSoar-compatible .CUP Format ‘Additional Waypoints’ file | Paynter's Palace