Author Archives: paynterf

Hearing Aid AGC Testing

Posted 11 March 2023,

I have been wearing hearing aids for quite some time, compliments of a lifetime around airplanes, long before hearing protection became a thing. I recently got a set of Jabra ‘Enhance 200’ aids via direct order, and I like them very much, EXCEPT I have noticed that my perceived hearing acuity seems to vary quite distinctly over a period of a minute or two. I first noticed this when I would turn on a water tap while washing dishes or preparing to take a shower. I would turn on the tap, and then 20-30 sec later, the perceived sound of the water coming out of the tap would increase significantly – even though the water flow rate had not changed. Later, in a social setting (bridge club), I will experience significantly lower and higher perceived speech volumes – very frustrating! I hypothesized that the aids employ an AGC (Automatic Gain Control) of some sort that is getting triggered by an initial loud noise which reduces the gain (and my perceived noise/speech level), and then 10-50sec later the gain would go back up again.

Just recently though, another thought popped into my head – what if the perceived volume changes aren’t due to some property of the hearing aids, but instead are a physiological feature of my current hearing/understanding processes? Hmm, I know I have some issues with my Eustachian tubes blocking and unblocking, and I also know that on occasion the volume changes are correlated with a ‘blocked Eustachian tube’ feeling, so this isn’t a completely crazy hypothesis.

So, how to distinguish ‘meat space’ audio response from hearing aid responses? I decided I could set up an experiment where I could expose one or both of my hearing aids to a volume ‘step function’ and monitor the output for AGC-like responses (an initial rapid drop in output, followed by an eventual return to normal). Something like the following block diagram:

The idea is that the Teensy would produce an audio output in the human audible range that can be controlled for amplitude and duration. The audio would be presented to the hearing aid, and the amplified output of the hearing aid would then be captured with an external microphone connected back to the Teensy. A plot of captured amplitude vs time, with a ‘step function’ input should indicate if the hearing aid is employing an AGC-like response function.

After some fumbling around and searching through the posts on the Teensy forum, I ran across this post describing how to create a simple 440Hz sinewave output from the DAC pin. The original poster was having problems, but after Paul Stoffregen added the ‘magic sauce’ (adding the ‘AudioMemory(10);’) line, everything worked fine. When I copy/pasted the posters code and added the line, I got the nice 440Hz waveform shown below – yay!!

The next step is to hook the DAC output to a small speaker, so I can drive the hearing aid. When I tried hooking a speaker directly to the DAC output, it clipped badly – oops! Fortunately, I remembered that long ago I had purchased a ‘prop shield’ for the Teensy LC/3.1/3.2 controllers, and this contains a 2W audio amp whose input connects directly to the DAC output – nice! So I dug around and found the part, soldered on headers, and plugged it on top of the Teensy.

15 March 2024 Update:

So, yesterday Space X launched IFT3 (Integrated Flight Test #3), consisting of ‘Super-Heavy Booster 10’ and ‘Ship 28’. The combination was the largest, most powerful rocket ever launched, by a fair margin. The upper stage (Starship 28) flew from Boca Chica Texas to the Indian Ocean near Australia in about 49 minutes – wow! At that point, the upper stage was the largest object ever launched into space in all history – Wow Again!

OK, back to reality. I managed to get the prop shield working – after the usual number of false-starts and errors. One ‘gotcha’ was that I hadn’t realized the 2W audio amp was a Class-C type, which means it switches on and off at a very high frequency (100KHz or so) – way above human hearing range, and the audio AM modulates that signal. When it is connected to a speaker or other audio transducer, it acts like a low-pass filter and all that comes out is the audio; this is a really neat trick, but it means that the audio amp output signal is basically impossible to look at directly with a scope – oops. So, I got a pair of MEMS microphone breakout boards from Sparkfun and used the microphone to turn the speaker audio back into an electrical signal that I could view with the scope. Here’s the setup:

Teensy ‘propshield’ mounted on Teensy 3.2. Note Sparkfun MEMS microphone suspended over speaker

This worked great, and I was able to verify that the speaker audio output was a reasonable replica of what the T3.2 DAC was putting out.

The next step was to feed the MEMS mic output back into a Teensy 3.2 analog input so I could measure the signal amplitude (A4 in the above block diagram). Then I would modify the Teensy program to deliver a 1-2 sec ‘pulse’ of high amplitude audio to the hearing aid, followed by a constant low-amplitude signal. The measured amplitude of the hearing aid output (as received by the MEMS mic) would be monitored to see if the hearing aid exhibited AGC-like behavior.

However, as I started setting this up, I realized I would have to solder yet another flying lead to the top of the prop shield, as the Teensy 3.2 pins were no longer accessible directly. So I decided to fix this problem by adding female headers to the top side of the prop shield to allow access to all Teensy pins. The result is shown in the ‘before/after’ photos below:

19 March 2024 Update:

I soon discovered that my plan for routing the MEMS mic back to a Teensy analog input and just averaging the results over time wasn’t going to work, as a glance at the MEMS output to the Teensy (shown below) would make quite obvious:

MEMS output with 1000Hz sinewave input to speaker. Average value is 3.3V/2

The average value for this signal is just the DC offset, which will always be the same. The only thing that varies is the amplitude – not the average value – oops!

OK, so the obvious work-around to this problem would be to put a half-wave or full-wave rectifier circuit between the MEMS output and the Teensy so the analog input could measure the half- or full-wave amplitude instead of the average. But, I really didn’t want to add any more circuitry, and besides I have this entire 72MHz computer at my beck and call – surely I can get it to emulate a half- or full-wave rectifier?

So, after the usual number of screwups, I got this working reasonably well – at least enough for a ‘proof-of-concept. The basic idea is to take analog input readings as fast as possible, and use the resulting values to compute the average value (in A/D units – not voltage), and then take the absolute value of the difference between each measurement and the average value – this essentially implements a full wave rectifier circuit in software.

The following data and Excel plot shows the results for the waveform shown above:

Idx:	Usec	Meas	Amp
0	1617384	183	329.18
1	1617480	2	510.18
2	1617580	1	511.18
3	1617680	1	511.18
4	1617780	3	509.18
5	1617880	810	297.82
6	1617980	1023	510.82
7	1618080	1023	510.82
8	1618180	1023	510.82
9	1618280	1023	510.82
10	1618380	214	298.18
11	1618480	2	510.18
12	1618580	1	511.18
13	1618680	1	511.18
14	1618780	2	510.18
15	1618880	810	297.82
16	1618980	1023	510.82
17	1619080	1023	510.82
18	1619180	1023	510.82
19	1619280	1023	510.82
20	1619380	210	302.18
21	1619480	1	511.18
22	1619580	1	511.18
23	1619680	2	510.18
24	1619780	2	510.18
25	1619880	811	298.82
26	1619980	1023	510.82
27	1620080	1023	510.82
28	1620180	1023	510.82
29	1620280	1023	510.82
30	1620380	218	294.18
31	1620480	2	510.18
32	1620580	1	511.18
33	1620680	2	510.18
34	1620780	2	510.18
35	1620880	822	309.82
36	1620980	1023	510.82
37	1621080	1023	510.82
38	1621180	1023	510.82
39	1621280	1023	510.82
40	1621380	221	291.18
41	1621480	2	510.18
42	1621580	1	511.18
43	1621680	1	511.18
44	1621780	2	510.18
45	1621880	818	305.82
46	1621980	1023	510.82
47	1622080	1023	510.82
48	1622180	1023	510.82
49	1622280	1023	510.82

Idx: Usec Meas Amp

0 1617384 183 329.18

1 1617480 2 510.18

2 1617580 1 511.18

3 1617680 1 511.18

4 1617780 3 509.18

5 1617880 810 297.82

6 1617980 1023 510.82

7 1618080 1023 510.82

8 1618180 1023 510.82

9 1618280 1023 510.82

10 1618380 214 298.18

11 1618480 2 510.18

12 1618580 1 511.18

13 1618680 1 511.18

14 1618780 2 510.18

15 1618880 810 297.82

16 1618980 1023 510.82

17 1619080 1023 510.82

18 1619180 1023 510.82

19 1619280 1023 510.82

20 1619380 210 302.18

21 1619480 1 511.18

22 1619580 1 511.18

23 1619680 2 510.18

24 1619780 2 510.18

25 1619880 811 298.82

26 1619980 1023 510.82

27 1620080 1023 510.82

28 1620180 1023 510.82

29 1620280 1023 510.82

30 1620380 218 294.18

31 1620480 2 510.18

32 1620580 1 511.18

33 1620680 2 510.18

34 1620780 2 510.18

35 1620880 822 309.82

36 1620980 1023 510.82

37 1621080 1023 510.82

38 1621180 1023 510.82

39 1621280 1023 510.82

40 1621380 221 291.18

41 1621480 2 510.18

42 1621580 1 511.18

43 1621680 1 511.18

44 1621780 2 510.18

45 1621880 818 305.82

46 1621980 1023 510.82

47 1622080 1023 510.82

48 1622180 1023 510.82

49 1622280 1023 510.82

The above data was collected by sampling the input at about 20KHz (50 Usec). As can be seen from the above, the average value is a constant 511.64 (out of a zero to 1023 scale), and the actual measured values varied from about 264 to about 755. Here are Excel plots of both the measured input and the calculated amplitude:

So it looks like this idea will work. For the intended application (determining if my hearing aids exhibit AGC-like behavior, I can perform a running average of the full-wave rectified signal using something like a 0.1 Sec interval (2000 samples). That should accurately capture the onset and release of the 1-sec HIGH tone, and have plenty of resolution to capture any AGC-like sensitivity increase over a longer time – say 30 Sec or so.

Here’s the code that produced the above outputs:

/*
    Name:       MicSigAmplitudeMeas.ino
    Created:	3/18/2024 6:35:27 PM
    Author:     FRANKNEWXPS15\Frank
*/
#include "elapsedMillis.h"
#include <Audio.h>



#define MEAS_ARRAY_SIZE 50
#define AD_IN_PIN A9
#define MICROSEC_BETWEEN_ADMEAS 100
#define MIC_INPUT_PIN A9 //pin 23
#define AUDIO_OUT_HIGH 0.02

uint16_t meas_array[MEAS_ARRAY_SIZE];
uint32_t microsec_array[MEAS_ARRAY_SIZE];

AudioSynthWaveformSine   sine;
AudioAmplifier           amp;
AudioOutputAnalog        dac;
AudioConnection          patchCord1(sine, amp);
AudioConnection          patchCord2(amp, dac);


elapsedMicros gl_MicrosecBetweenADMeas;
uint16_t gl_array_idx = 0;


void setup()
{
  Serial.begin(115200);
  Serial.printf("Hello World\n");

  pinMode(MIC_INPUT_PIN, INPUT);
  //analogReadRes(12);

  AudioMemory(20);
  dac.analogReference(EXTERNAL);
  delay(50);
  pinMode(5, OUTPUT); //high power DAC output
  digitalWrite(5, HIGH);
  delay(10);


  amp.gain(1.0);

  sine.frequency(1000.0);
  sine.amplitude(AUDIO_OUT_HIGH);//Should be enough to fully clip
  sine.phase(0.0);

  delay(1000);

  gl_MicrosecBetweenADMeas = 0;
  gl_array_idx = 0;

  //init all the arrays
  for (size_t i = 0; i < MEAS_ARRAY_SIZE; i++)
  {
    //amp_meas_array[i] = 0;
    meas_array[i] = 0;
    microsec_array[i] = 0;
    //avg_meas_array[i] = 0;
  }

  while (gl_array_idx < MEAS_ARRAY_SIZE)
  {
    if (gl_MicrosecBetweenADMeas >= MICROSEC_BETWEEN_ADMEAS)
    {
      gl_MicrosecBetweenADMeas -= MICROSEC_BETWEEN_ADMEAS;
      uint16_t micVal = analogRead(MIC_INPUT_PIN);
      UpdateArrays(micros(), micVal);
      gl_array_idx++;
    }
  }

  //print out results
  float avg = GetAvgMeas();
  Serial.printf("Idx:\tUsec\tMeas\tAmp\n");
  for (size_t i = 0; i < MEAS_ARRAY_SIZE; i++)
  {
    float amp = abs(meas_array[i] - avg);
    Serial.printf("%d\t%lu\t\%d\t%2.2f\n", i, microsec_array[i], meas_array[i], amp);
  }
}

void loop()
{
}

//void UpdateArrays(uint32_t usec, uint16_t measval, float aval, float avg)
void UpdateArrays(uint32_t usec, uint16_t measval)
{
  microsec_array[gl_array_idx] = usec;
  meas_array[gl_array_idx] = measval;
}

float GetAvgMeas()
{
  float avg = 0;
  float tot = 0;
  for (size_t i = 0; i < MEAS_ARRAY_SIZE; i++)
  {
    tot += meas_array[i];
  }
  avg = tot / MEAS_ARRAY_SIZE;
  Serial.printf("tot = %2.2f, avg = %2.2f\n", tot, avg);

  return avg;
}

100

101

102

103

104

105

106

107

108

109

110

111

Name: MicSigAmplitudeMeas.ino

Created: 3/18/2024 6:35:27 PM

Author: FRANKNEWXPS15\Frank

#include "elapsedMillis.h"

#include <Audio.h>

#define MEAS_ARRAY_SIZE 50

#define AD_IN_PIN A9

#define MICROSEC_BETWEEN_ADMEAS 100

#define MIC_INPUT_PIN A9 //pin 23

#define AUDIO_OUT_HIGH 0.02

uint16_t meas_array[MEAS_ARRAY_SIZE];

uint32_t microsec_array[MEAS_ARRAY_SIZE];

AudioSynthWaveformSine sine;

AudioAmplifier amp;

AudioOutputAnalog dac;

AudioConnection patchCord1(sine, amp);

AudioConnection patchCord2(amp, dac);

elapsedMicros gl_MicrosecBetweenADMeas;

uint16_t gl_array_idx = 0;

void setup()

{

Serial.begin(115200);

Serial.printf("Hello World\n");

pinMode(MIC_INPUT_PIN, INPUT);

//analogReadRes(12);

AudioMemory(20);

dac.analogReference(EXTERNAL);

delay(50);

pinMode(5, OUTPUT); //high power DAC output

digitalWrite(5, HIGH);

delay(10);

amp.gain(1.0);

sine.frequency(1000.0);

sine.amplitude(AUDIO_OUT_HIGH);//Should be enough to fully clip

sine.phase(0.0);

delay(1000);

gl_MicrosecBetweenADMeas = 0;

gl_array_idx = 0;

//init all the arrays

for (size_t i = 0; i < MEAS_ARRAY_SIZE; i++)

{

//amp_meas_array[i] = 0;

meas_array[i] = 0;

microsec_array[i] = 0;

//avg_meas_array[i] = 0;

}

while (gl_array_idx < MEAS_ARRAY_SIZE)

{

if (gl_MicrosecBetweenADMeas >= MICROSEC_BETWEEN_ADMEAS)

{

gl_MicrosecBetweenADMeas -= MICROSEC_BETWEEN_ADMEAS;

uint16_t micVal = analogRead(MIC_INPUT_PIN);

UpdateArrays(micros(), micVal);

gl_array_idx++;

}

//print out results

float avg = GetAvgMeas();

Serial.printf("Idx:\tUsec\tMeas\tAmp\n");

for (size_t i = 0; i < MEAS_ARRAY_SIZE; i++)

{

float amp = abs(meas_array[i] - avg);

Serial.printf("%d\t%lu\t\%d\t%2.2f\n", i, microsec_array[i], meas_array[i], amp);

}

void loop()

{

}

//void UpdateArrays(uint32_t usec, uint16_t measval, float aval, float avg)

void UpdateArrays(uint32_t usec, uint16_t measval)

{

microsec_array[gl_array_idx] = usec;

meas_array[gl_array_idx] = measval;

}

float GetAvgMeas()

{

float avg = 0;

float tot = 0;

for (size_t i = 0; i < MEAS_ARRAY_SIZE; i++)

{

tot += meas_array[i];

}

avg = tot / MEAS_ARRAY_SIZE;

Serial.printf("tot = %2.2f, avg = %2.2f\n", tot, avg);

return avg;

}

I made another run with the A/D resolution set to 12 bits to see if it made any appreciable difference. As can be seen in the following Excel plot – it didn’t:

Here’s another plot showing the microphone output, but this time with the DAC sinewave output amplitude reduced to the point where the microphone output isn’t large enough to clip.

In the reduced sinewave amplitude plot above, the ‘Meas’ plot is still centered about the halfway mark in the 12-bit range of values, while the average value of the ‘Amp’ plot has been reduced from about 1800 to about 200.

So, now that I know that the DAC-Speaker-Microphone-ADC loop works, I need to extend it to record amplitude values over an extended period – at least 30 sec, and more like a minute or more.

I modified my control program to create a 1-second ‘burst’ of a HIGH amplitude sinewave, followed by an infinitely long period of a LOW amplitude sinewave. The HIGH amplitude was chosen to fully clip the microphone output, and the LOW amplitude was chosen to be well above the noise floor, but still very small compared to the HIGH amplitude signal. Here are O’scope photos of both the HIGH & LOW signals:

Here is the output from the program (the LOW amplitude output was manually terminated after a few seconds):

1617: Starting 1-second burst at AUDIO_OUT_HIGH amplitude
Msec	D_Msec	AvgAmp
1622	1622	2045.9
1823	201	1421.2
2024	201	1453.2
2225	201	1495.7
2426	201	1136.4
2626: Finished 1-second burst at AUDIO_OUT_HIGH amplitude
Msec	D_Msec	AvgAmp
2627	1	927.6
2828	201	104.2
3029	201	115.7
3230	201	94.1
3431	201	102.5
3632	201	104.7
3833	201	104.4
4034	201	115.4
4235	201	104.9
4436	201	116.7
4637	201	113.6
4838	201	102.1
5039	201	107.0
5240	201	161.6
5441	201	153.3
5642	201	167.4
5843	201	171.8
6044	201	170.8
6245	201	186.8
6446	201	179.4
6647	201	202.0
6848	201	204.8
7049	201	204.0
7250	201	191.0
7451	201	212.0
7652	201	209.0
7853	201	190.2
8055	202	180.9
8256	201	169.2
8457	201	168.0
8658	201	180.9
8859	201	147.6
9060	201	145.1
9261	201	152.9
9462	201	156.6
9663	201	119.8
9864	201	122.5

1617: Starting 1-second burst at AUDIO_OUT_HIGH amplitude

Msec D_Msec AvgAmp

1622 1622 2045.9

1823 201 1421.2

2024 201 1453.2

2225 201 1495.7

2426 201 1136.4

2626: Finished 1-second burst at AUDIO_OUT_HIGH amplitude

Msec D_Msec AvgAmp

2627 1 927.6

2828 201 104.2

3029 201 115.7

3230 201 94.1

3431 201 102.5

3632 201 104.7

3833 201 104.4

4034 201 115.4

4235 201 104.9

4436 201 116.7

4637 201 113.6

4838 201 102.1

5039 201 107.0

5240 201 161.6

5441 201 153.3

5642 201 167.4

5843 201 171.8

6044 201 170.8

6245 201 186.8

6446 201 179.4

6647 201 202.0

6848 201 204.8

7049 201 204.0

7250 201 191.0

7451 201 212.0

7652 201 209.0

7853 201 190.2

8055 202 180.9

8256 201 169.2

8457 201 168.0

8658 201 180.9

8859 201 147.6

9060 201 145.1

9261 201 152.9

9462 201 156.6

9663 201 119.8

9864 201 122.5

31 March 2024 Update:

After getting all of the above working, I then installed one of my Jabra ‘Enhance 200’ aides in between the speaker and the microphone, as shown in the photos below:

With the aid installed, I got the following microphone output using my ‘burst + long-term low level audio’ setup.

Even though the Jabra aid did NOT exhibit anything like the AGC behavior I expected, there *was* a sort of cyclical response with the Jabra aid that wasn’t there without the aid in the middle. This cyclical behavior repeats about once every five seconds and *could* be some sort of AGC-like behavior – just not the one I was expecting.

Stay tuned,

Frank

Convert Condor Task Briefing Custom Waypoint Description Blocks to XCSoar-compatible .CUP Format ‘Additional Waypoints’ file

Leave a reply

Posted 23 March 2024

After a multi-year hiatus, I recently started flying contests again in the Condor Soaring Simulator. As sort of a side project, I have also been working with the XCSoar glider navigation program, to see if I could use XCSoar to help navigate AAT/TAT tasks in Condor (Condor doesn’t support AAT/TAT tasks natively with the in-sim PDA).

After using XCSoar for a while, I became frustrated with XCSoar’s inability to define ‘custom’ turnpoints based on LAT/LON coordinates, which are used quite frequently in Condor contest tasks. After a long-fought and ultimately unsuccessful battle with XCSoar’s source code to see if I could modify the program to facilitate this, I admitted defeat and decided to try another way to skin this cat. XCSoar will accept an ‘Additional Waypoints’ file, so I decided to see if I could create a program to convert the ‘new TP’ blocks in the Condor ‘Task Briefing’ description to XCSoar-compatile .CUP file waypoint lines, which could then be loaded into XCSoar for selection as task waypoints.

Here is the .CUP file format defintion page from the SeeYou (naviter) program website:

The above description is NOT very easy to read. It is full of errors, so some imagination is required to make sense of it. The ‘hardpoints’ in the description are as follows:

Latitude strings are exactly 9 characters long. Longitude strings are exactly 10 characters long.
In latitude strings, the decimal point is exactly the 5th character (Char4) . In longitude strings, the decimal point is exactly the 6th character (Char5).
Both latitude and longitude strings apparently must be zero-padded as necessary to make the string character counts work out. For instance, in the longitude example the ‘degree’ value of ‘014’ must be exactly three characters.

Example Run:

Here’s a recent task briefing from Condor-Club:

As can be seen in the above screengrab, TP2-TP2 are all ‘custom’ turnpoints defined only by Lat/Lon coordinates. Manually adding these to a .CUP formatted file for use in XCSoar would be essentially impossible, given that the turnpoint coordinates only become visible 15 minutes before server start.

To start the process, the turnpoint blocks from the above briefing were copy/pasted one at a time into a text document (I use NotePad++), as follows (note that I manually changed the name of the last turnpoint from ‘Finish’ to TP 6, as my Python script currently only looks for ‘Start’ and ‘TP’ starting strings)

TP 2 (955 m.)
Heading: 93° for 65.1 km,
Coords: 49.8.359N / 20.14.201E
Classic turnpoint,
min. height: 0 m., max.: 10,000 m.
angle: 360°, radius: 1,000 m.

TP 3 (781 m.)
Heading: 158° for 32.7 km,
Coords: 48.51.629N / 20.22.768E
Classic turnpoint,
min. height: 0 m., max.: 10,000 m.
angle: 360°, radius: 1,000 m.

TP 4 (617 m.)
Heading: 268° for 99.2 km,
Coords: 48.49.454N / 19.1.724E
Classic turnpoint,
min. height: 0 m., max.: 10,000 m.
angle: 360°, radius: 1,000 m.

TP 5 (394 m.)
Heading: 138° for 24.1 km,
Coords: 48.39.956N / 19.15.148E
Classic turnpoint,
min. height: 0 m., max.: 10,000 m.
angle: 360°, radius: 1,000 m.

TP 6 (204 m.)
Heading: 106° for 84.8 km,
Coords: 48.31.81N / 20.22.800E
Classic turnpoint,
min. height: 0 m., max.: 10,000 m.
angle: 180°, radius: 1,500 m.

TP 2 (955 m.)

Heading: 93° for 65.1 km,

Coords: 49.8.359N / 20.14.201E

Classic turnpoint,

min. height: 0 m., max.: 10,000 m.

angle: 360°, radius: 1,000 m.

TP 3 (781 m.)

Heading: 158° for 32.7 km,

Coords: 48.51.629N / 20.22.768E

Classic turnpoint,

min. height: 0 m., max.: 10,000 m.

angle: 360°, radius: 1,000 m.

TP 4 (617 m.)

Heading: 268° for 99.2 km,

Coords: 48.49.454N / 19.1.724E

Classic turnpoint,

min. height: 0 m., max.: 10,000 m.

angle: 360°, radius: 1,000 m.

TP 5 (394 m.)

Heading: 138° for 24.1 km,

Coords: 48.39.956N / 19.15.148E

Classic turnpoint,

min. height: 0 m., max.: 10,000 m.

angle: 360°, radius: 1,000 m.

TP 6 (204 m.)

Heading: 106° for 84.8 km,

Coords: 48.31.81N / 20.22.800E

Classic turnpoint,

min. height: 0 m., max.: 10,000 m.

angle: 180°, radius: 1,500 m.

My CondorTPX_to_CupWP.py Python script opens a ‘FileOpen’ dialog where the input file (in this case ‘NewTPs_IN.txt’) can be selected by the user, and a ‘FileSave’ dialog where the output file (in this case ‘NewTPS_OUT.CUP’) can be selected, and then parses through the blocks in the input file, converting them to equivalent .CUP-formatted lines compatible with XCSoar. Here is the console printout from the ‘verbose’ (-v) version of the script:

File containing custom Condor task turnpoints = C:/Users/Frank/Desktop/NewTPS_IN.txt
File to which XCSoar-compatible turnpoint lines will be written = C:/Users/Frank/Desktop/NewTPS_OUT.txt
list contains 34 items
0: TP 2 (955 m.)

1: Heading: 93° for 65.1 km,

2: Coords: 49.8.359N / 20.14.201E

3: Classic turnpoint,

4: min. height: 0 m., max.: 10,000 m.

5: angle: 360°, radius: 1,000 m.

6:

7: TP 3 (781 m.)

8: Heading: 158° for 32.7 km,

9: Coords: 48.51.629N / 20.22.768E

10: Classic turnpoint,

11: min. height: 0 m., max.: 10,000 m.

12: angle: 360°, radius: 1,000 m.

13:

14: TP 4 (617 m.)

15: Heading: 268° for 99.2 km,

16: Coords: 48.49.454N / 19.1.724E

17: Classic turnpoint,

18: min. height: 0 m., max.: 10,000 m.

19: angle: 360°, radius: 1,000 m.

20:

21: TP 5 (394 m.)

22: Heading: 138° for 24.1 km,

23: Coords: 48.39.956N / 19.15.148E

24: Classic turnpoint,

25: min. height: 0 m., max.: 10,000 m.

26: angle: 360°, radius: 1,000 m.

27:

28: TP 6 (204 m.)

29: Heading: 106° for 84.8 km,

30: Coords: 48.31.81N / 20.22.800E

31: Classic turnpoint,

32: min. height: 0 m., max.: 10,000 m.

33: angle: 180°, radius: 1,500 m.


Start Processing Lines

0: TP 2 (955 m.)

In ConstructCUPString(tpname = NewTP 2, inlist_idx = 0)
['Coords:', '49.8.359N', '/', '20.14.201E']
Constructing Latitude...

latitude string = 49.8.359N
latitude lat_deg str = 49
latitude lat_deg = 49
after adjustment, latitude deg str = 49
lat_deg_dot_idx = 2, min_dot_idx = 4
latitude minplusdec str = 8.359N
latitude NorS str = N
latitude min dot idx = 1
latitude min val str = 8
latitude min dec val str = 359
after 'len < 2' adjustment, latitude min str = 08
after 'len < 2' adjustment, latitude min dec str = 359
latitude min = 8
latitude min str = 08
latitude .CUP str = 4908.359N

Constructing Longitude...

longitude string = 20.14.201E
longitude lon_deg str = 20
longitude lon_deg = 20
after 'len < 3' adjustment, longitude deg str = 020
lon_deg_dot_idx = 2, min_dot_idx = 5
longitude minplusdec str = 14.201E
longitude EorW str = E
longitude min dot idx = 2
longitude min val str = 14
longitude min dec val str = 201
after 'len < 2' adjustment, longitude min str = 14
after 'len < 3' adjustment, longitude min dec str = 201
longitude .CUP str = 02014.201E

Extracting Turnpoint Style:
stylestr = Classic

numstr =  2
back in main pgm: cupstr = NewTP 2, NewTP 2, ,4908.359N, 02014.201E, ,Classic, , , ,,  x = 4
5: angle: 360°, radius: 1,000 m.

numstr =
back in main pgm: cupstr = ,  x = 5
6:

numstr =
back in main pgm: cupstr = ,  x = 6
7: TP 3 (781 m.)

In ConstructCUPString(tpname = NewTP 3, inlist_idx = 7)
['Coords:', '48.51.629N', '/', '20.22.768E']
Constructing Latitude...

latitude string = 48.51.629N
latitude lat_deg str = 48
latitude lat_deg = 48
after adjustment, latitude deg str = 48
lat_deg_dot_idx = 2, min_dot_idx = 5
latitude minplusdec str = 51.629N
latitude NorS str = N
latitude min dot idx = 2
latitude min val str = 51
latitude min dec val str = 629
after 'len < 2' adjustment, latitude min str = 51
after 'len < 2' adjustment, latitude min dec str = 629
latitude min = 51
latitude min str = 51
latitude .CUP str = 4851.629N

Constructing Longitude...

longitude string = 20.22.768E
longitude lon_deg str = 20
longitude lon_deg = 20
after 'len < 3' adjustment, longitude deg str = 020
lon_deg_dot_idx = 2, min_dot_idx = 5
longitude minplusdec str = 22.768E
longitude EorW str = E
longitude min dot idx = 2
longitude min val str = 22
longitude min dec val str = 768
after 'len < 2' adjustment, longitude min str = 22
after 'len < 3' adjustment, longitude min dec str = 768
longitude .CUP str = 02022.768E

Extracting Turnpoint Style:
stylestr = Classic

numstr =  3
back in main pgm: cupstr = NewTP 3, NewTP 3, ,4851.629N, 02022.768E, ,Classic, , , ,,  x = 11
12: angle: 360°, radius: 1,000 m.

numstr =
back in main pgm: cupstr = ,  x = 12
13:

numstr =
back in main pgm: cupstr = ,  x = 13
14: TP 4 (617 m.)

In ConstructCUPString(tpname = NewTP 4, inlist_idx = 14)
['Coords:', '48.49.454N', '/', '19.1.724E']
Constructing Latitude...

latitude string = 48.49.454N
latitude lat_deg str = 48
latitude lat_deg = 48
after adjustment, latitude deg str = 48
lat_deg_dot_idx = 2, min_dot_idx = 5
latitude minplusdec str = 49.454N
latitude NorS str = N
latitude min dot idx = 2
latitude min val str = 49
latitude min dec val str = 454
after 'len < 2' adjustment, latitude min str = 49
after 'len < 2' adjustment, latitude min dec str = 454
latitude min = 49
latitude min str = 49
latitude .CUP str = 4849.454N

Constructing Longitude...

longitude string = 19.1.724E
longitude lon_deg str = 19
longitude lon_deg = 19
after 'len < 3' adjustment, longitude deg str = 019
lon_deg_dot_idx = 2, min_dot_idx = 4
longitude minplusdec str = 1.724E
longitude EorW str = E
longitude min dot idx = 1
longitude min val str = 1
longitude min dec val str = 724
after 'len < 2' adjustment, longitude min str = 01
after 'len < 3' adjustment, longitude min dec str = 724
longitude .CUP str = 01901.724E

Extracting Turnpoint Style:
stylestr = Classic

numstr =  4
back in main pgm: cupstr = NewTP 4, NewTP 4, ,4849.454N, 01901.724E, ,Classic, , , ,,  x = 18
19: angle: 360°, radius: 1,000 m.

numstr =
back in main pgm: cupstr = ,  x = 19
20:

numstr =
back in main pgm: cupstr = ,  x = 20
21: TP 5 (394 m.)

In ConstructCUPString(tpname = NewTP 5, inlist_idx = 21)
['Coords:', '48.39.956N', '/', '19.15.148E']
Constructing Latitude...

latitude string = 48.39.956N
latitude lat_deg str = 48
latitude lat_deg = 48
after adjustment, latitude deg str = 48
lat_deg_dot_idx = 2, min_dot_idx = 5
latitude minplusdec str = 39.956N
latitude NorS str = N
latitude min dot idx = 2
latitude min val str = 39
latitude min dec val str = 956
after 'len < 2' adjustment, latitude min str = 39
after 'len < 2' adjustment, latitude min dec str = 956
latitude min = 39
latitude min str = 39
latitude .CUP str = 4839.956N

Constructing Longitude...

longitude string = 19.15.148E
longitude lon_deg str = 19
longitude lon_deg = 19
after 'len < 3' adjustment, longitude deg str = 019
lon_deg_dot_idx = 2, min_dot_idx = 5
longitude minplusdec str = 15.148E
longitude EorW str = E
longitude min dot idx = 2
longitude min val str = 15
longitude min dec val str = 148
after 'len < 2' adjustment, longitude min str = 15
after 'len < 3' adjustment, longitude min dec str = 148
longitude .CUP str = 01915.148E

Extracting Turnpoint Style:
stylestr = Classic

numstr =  5
back in main pgm: cupstr = NewTP 5, NewTP 5, ,4839.956N, 01915.148E, ,Classic, , , ,,  x = 25
26: angle: 360°, radius: 1,000 m.

numstr =
back in main pgm: cupstr = ,  x = 26
27:

numstr =
back in main pgm: cupstr = ,  x = 27
28: TP 6 (204 m.)

In ConstructCUPString(tpname = NewTP 6, inlist_idx = 28)
['Coords:', '48.31.81N', '/', '20.22.800E']
Constructing Latitude...

latitude string = 48.31.81N
latitude lat_deg str = 48
latitude lat_deg = 48
after adjustment, latitude deg str = 48
lat_deg_dot_idx = 2, min_dot_idx = 5
latitude minplusdec str = 31.81N
latitude NorS str = N
latitude min dot idx = 2
latitude min val str = 31
latitude min dec val str = 81
after 'len < 2' adjustment, latitude min str = 31
after 'len < 2' adjustment, latitude min dec str = 810
latitude min = 31
latitude min str = 31
latitude .CUP str = 4831.810N

Constructing Longitude...

longitude string = 20.22.800E
longitude lon_deg str = 20
longitude lon_deg = 20
after 'len < 3' adjustment, longitude deg str = 020
lon_deg_dot_idx = 2, min_dot_idx = 5
longitude minplusdec str = 22.800E
longitude EorW str = E
longitude min dot idx = 2
longitude min val str = 22
longitude min dec val str = 800
after 'len < 2' adjustment, longitude min str = 22
after 'len < 3' adjustment, longitude min dec str = 800
longitude .CUP str = 02022.800E

Extracting Turnpoint Style:
stylestr = Classic

numstr =  6
back in main pgm: cupstr = NewTP 6, NewTP 6, ,4831.810N, 02022.800E, ,Classic, , , ,,  x = 32
33: angle: 180°, radius: 1,500 m.

numstr =
back in main pgm: cupstr = ,  x = 33
all 34 infile lines processed

Contents of output file C:/Users/Frank/Desktop/NewTPS_OUT.txt
name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc

NewTP 2, NewTP 2, ,4908.359N, 02014.201E, ,Classic, , , ,

NewTP 3, NewTP 3, ,4851.629N, 02022.768E, ,Classic, , , ,

NewTP 4, NewTP 4, ,4849.454N, 01901.724E, ,Classic, , , ,

NewTP 5, NewTP 5, ,4839.956N, 01915.148E, ,Classic, , , ,

NewTP 6, NewTP 6, ,4831.810N, 02022.800E, ,Classic, , , ,

Press any key to continue . . .

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

File containing custom Condor task turnpoints = C:/Users/Frank/Desktop/NewTPS_IN.txt

File to which XCSoar-compatible turnpoint lines will be written = C:/Users/Frank/Desktop/NewTPS_OUT.txt

list contains 34 items

0: TP 2 (955 m.)

1: Heading: 93° for 65.1 km,

2: Coords: 49.8.359N / 20.14.201E

3: Classic turnpoint,

4: min. height: 0 m., max.: 10,000 m.

5: angle: 360°, radius: 1,000 m.

7: TP 3 (781 m.)

8: Heading: 158° for 32.7 km,

9: Coords: 48.51.629N / 20.22.768E

10: Classic turnpoint,

11: min. height: 0 m., max.: 10,000 m.

12: angle: 360°, radius: 1,000 m.

13:

14: TP 4 (617 m.)

15: Heading: 268° for 99.2 km,

16: Coords: 48.49.454N / 19.1.724E

17: Classic turnpoint,

18: min. height: 0 m., max.: 10,000 m.

19: angle: 360°, radius: 1,000 m.

20:

21: TP 5 (394 m.)

22: Heading: 138° for 24.1 km,

23: Coords: 48.39.956N / 19.15.148E

24: Classic turnpoint,

25: min. height: 0 m., max.: 10,000 m.

26: angle: 360°, radius: 1,000 m.

27:

28: TP 6 (204 m.)

29: Heading: 106° for 84.8 km,

30: Coords: 48.31.81N / 20.22.800E

31: Classic turnpoint,

32: min. height: 0 m., max.: 10,000 m.

33: angle: 180°, radius: 1,500 m.

Start Processing Lines

0: TP 2 (955 m.)

In ConstructCUPString(tpname = NewTP 2, inlist_idx = 0)

['Coords:', '49.8.359N', '/', '20.14.201E']

Constructing Latitude...

latitude string = 49.8.359N

latitude lat_deg str = 49

latitude lat_deg = 49

after adjustment, latitude deg str = 49

lat_deg_dot_idx = 2, min_dot_idx = 4

latitude minplusdec str = 8.359N

latitude NorS str = N

latitude min dot idx = 1

latitude min val str = 8

latitude min dec val str = 359

after 'len < 2' adjustment, latitude min str = 08

after 'len < 2' adjustment, latitude min dec str = 359

latitude min = 8

latitude min str = 08

latitude .CUP str = 4908.359N

Constructing Longitude...

longitude string = 20.14.201E

longitude lon_deg str = 20

longitude lon_deg = 20

after 'len < 3' adjustment, longitude deg str = 020

lon_deg_dot_idx = 2, min_dot_idx = 5

longitude minplusdec str = 14.201E

longitude EorW str = E

longitude min dot idx = 2

longitude min val str = 14

longitude min dec val str = 201

after 'len < 2' adjustment, longitude min str = 14

after 'len < 3' adjustment, longitude min dec str = 201

longitude .CUP str = 02014.201E

Extracting Turnpoint Style:

stylestr = Classic

numstr = 2

back in main pgm: cupstr = NewTP 2, NewTP 2, ,4908.359N, 02014.201E, ,Classic, , , ,, x = 4

5: angle: 360°, radius: 1,000 m.

numstr =

back in main pgm: cupstr = , x = 5

numstr =

back in main pgm: cupstr = , x = 6

7: TP 3 (781 m.)

In ConstructCUPString(tpname = NewTP 3, inlist_idx = 7)

['Coords:', '48.51.629N', '/', '20.22.768E']

Constructing Latitude...

latitude string = 48.51.629N

latitude lat_deg str = 48

latitude lat_deg = 48

after adjustment, latitude deg str = 48

lat_deg_dot_idx = 2, min_dot_idx = 5

latitude minplusdec str = 51.629N

latitude NorS str = N

latitude min dot idx = 2

latitude min val str = 51

latitude min dec val str = 629

after 'len < 2' adjustment, latitude min str = 51

after 'len < 2' adjustment, latitude min dec str = 629

latitude min = 51

latitude min str = 51

latitude .CUP str = 4851.629N

Constructing Longitude...

longitude string = 20.22.768E

longitude lon_deg str = 20

longitude lon_deg = 20

after 'len < 3' adjustment, longitude deg str = 020

lon_deg_dot_idx = 2, min_dot_idx = 5

longitude minplusdec str = 22.768E

longitude EorW str = E

longitude min dot idx = 2

longitude min val str = 22

longitude min dec val str = 768

after 'len < 2' adjustment, longitude min str = 22

after 'len < 3' adjustment, longitude min dec str = 768

longitude .CUP str = 02022.768E

Extracting Turnpoint Style:

stylestr = Classic

numstr = 3

back in main pgm: cupstr = NewTP 3, NewTP 3, ,4851.629N, 02022.768E, ,Classic, , , ,, x = 11

12: angle: 360°, radius: 1,000 m.

numstr =

back in main pgm: cupstr = , x = 12

13:

numstr =

back in main pgm: cupstr = , x = 13

14: TP 4 (617 m.)

In ConstructCUPString(tpname = NewTP 4, inlist_idx = 14)

['Coords:', '48.49.454N', '/', '19.1.724E']

Constructing Latitude...

latitude string = 48.49.454N

latitude lat_deg str = 48

latitude lat_deg = 48

after adjustment, latitude deg str = 48

lat_deg_dot_idx = 2, min_dot_idx = 5

latitude minplusdec str = 49.454N

latitude NorS str = N

latitude min dot idx = 2

latitude min val str = 49

latitude min dec val str = 454

after 'len < 2' adjustment, latitude min str = 49

after 'len < 2' adjustment, latitude min dec str = 454

latitude min = 49

latitude min str = 49

latitude .CUP str = 4849.454N

Constructing Longitude...

longitude string = 19.1.724E

longitude lon_deg str = 19

longitude lon_deg = 19

after 'len < 3' adjustment, longitude deg str = 019

lon_deg_dot_idx = 2, min_dot_idx = 4

longitude minplusdec str = 1.724E

longitude EorW str = E

longitude min dot idx = 1

longitude min val str = 1

longitude min dec val str = 724

after 'len < 2' adjustment, longitude min str = 01

after 'len < 3' adjustment, longitude min dec str = 724

longitude .CUP str = 01901.724E

Extracting Turnpoint Style:

stylestr = Classic

numstr = 4

back in main pgm: cupstr = NewTP 4, NewTP 4, ,4849.454N, 01901.724E, ,Classic, , , ,, x = 18

19: angle: 360°, radius: 1,000 m.

numstr =

back in main pgm: cupstr = , x = 19

20:

numstr =

back in main pgm: cupstr = , x = 20

21: TP 5 (394 m.)

In ConstructCUPString(tpname = NewTP 5, inlist_idx = 21)

['Coords:', '48.39.956N', '/', '19.15.148E']

Constructing Latitude...

latitude string = 48.39.956N

latitude lat_deg str = 48

latitude lat_deg = 48

after adjustment, latitude deg str = 48

lat_deg_dot_idx = 2, min_dot_idx = 5

latitude minplusdec str = 39.956N

latitude NorS str = N

latitude min dot idx = 2

latitude min val str = 39

latitude min dec val str = 956

after 'len < 2' adjustment, latitude min str = 39

after 'len < 2' adjustment, latitude min dec str = 956

latitude min = 39

latitude min str = 39

latitude .CUP str = 4839.956N

Constructing Longitude...

longitude string = 19.15.148E

longitude lon_deg str = 19

longitude lon_deg = 19

after 'len < 3' adjustment, longitude deg str = 019

lon_deg_dot_idx = 2, min_dot_idx = 5

longitude minplusdec str = 15.148E

longitude EorW str = E

longitude min dot idx = 2

longitude min val str = 15

longitude min dec val str = 148

after 'len < 2' adjustment, longitude min str = 15

after 'len < 3' adjustment, longitude min dec str = 148

longitude .CUP str = 01915.148E

Extracting Turnpoint Style:

stylestr = Classic

numstr = 5

back in main pgm: cupstr = NewTP 5, NewTP 5, ,4839.956N, 01915.148E, ,Classic, , , ,, x = 25

26: angle: 360°, radius: 1,000 m.

numstr =

back in main pgm: cupstr = , x = 26

27:

numstr =

back in main pgm: cupstr = , x = 27

28: TP 6 (204 m.)

In ConstructCUPString(tpname = NewTP 6, inlist_idx = 28)

['Coords:', '48.31.81N', '/', '20.22.800E']

Constructing Latitude...

latitude string = 48.31.81N

latitude lat_deg str = 48

latitude lat_deg = 48

after adjustment, latitude deg str = 48

lat_deg_dot_idx = 2, min_dot_idx = 5

latitude minplusdec str = 31.81N

latitude NorS str = N

latitude min dot idx = 2

latitude min val str = 31

latitude min dec val str = 81

after 'len < 2' adjustment, latitude min str = 31

after 'len < 2' adjustment, latitude min dec str = 810

latitude min = 31

latitude min str = 31

latitude .CUP str = 4831.810N

Constructing Longitude...

longitude string = 20.22.800E

longitude lon_deg str = 20

longitude lon_deg = 20

after 'len < 3' adjustment, longitude deg str = 020

lon_deg_dot_idx = 2, min_dot_idx = 5

longitude minplusdec str = 22.800E

longitude EorW str = E

longitude min dot idx = 2

longitude min val str = 22

longitude min dec val str = 800

after 'len < 2' adjustment, longitude min str = 22

after 'len < 3' adjustment, longitude min dec str = 800

longitude .CUP str = 02022.800E

Extracting Turnpoint Style:

stylestr = Classic

numstr = 6

back in main pgm: cupstr = NewTP 6, NewTP 6, ,4831.810N, 02022.800E, ,Classic, , , ,, x = 32

33: angle: 180°, radius: 1,500 m.

numstr =

back in main pgm: cupstr = , x = 33

all 34 infile lines processed

Contents of output file C:/Users/Frank/Desktop/NewTPS_OUT.txt

name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc

NewTP 2, NewTP 2, ,4908.359N, 02014.201E, ,Classic, , , ,

NewTP 3, NewTP 3, ,4851.629N, 02022.768E, ,Classic, , , ,

NewTP 4, NewTP 4, ,4849.454N, 01901.724E, ,Classic, , , ,

NewTP 5, NewTP 5, ,4839.956N, 01915.148E, ,Classic, , , ,

NewTP 6, NewTP 6, ,4831.810N, 02022.800E, ,Classic, , , ,

Press any key to continue . . .

At the very end of the above printout, the newly-written contents of the output file are read back out again as a verification that the conversion was successful. Here is the actual contents of the ‘NewTPS_OUT.CUP’ file:

name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc
NewTP 2, NewTP 2, ,4908.359N, 02014.201E, ,Classic, , , ,
NewTP 3, NewTP 3, ,4851.629N, 02022.768E, ,Classic, , , ,
NewTP 4, NewTP 4, ,4849.454N, 01901.724E, ,Classic, , , ,
NewTP 5, NewTP 5, ,4839.956N, 01915.148E, ,Classic, , , ,
NewTP 6, NewTP 6, ,4831.810N, 02022.800E, ,Classic, , , ,

name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc

NewTP 2, NewTP 2, ,4908.359N, 02014.201E, ,Classic, , , ,

NewTP 3, NewTP 3, ,4851.629N, 02022.768E, ,Classic, , , ,

NewTP 4, NewTP 4, ,4849.454N, 01901.724E, ,Classic, , , ,

NewTP 5, NewTP 5, ,4839.956N, 01915.148E, ,Classic, , , ,

NewTP 6, NewTP 6, ,4831.810N, 02022.800E, ,Classic, , , ,

This file now has to be transferred to the directory used by XCSoar for waypoints, and then selected in XCSoar (Config->System->Site Files) to load as the ‘More Waypoints’ selection. After this, all the above turnpoints will be available for task construction. Here’s a photo of my Android tablet with the above task turnpoints loaded:

XCSoar task map, using converted task briefing turnpoint blocks

Same task as above, from Condor-Club briefing

It is clear from the above images that the Condor-Club ‘custom’ task turnpoints have been converted properly from text blocks to SeeYou .CUP format waypoint strings, so now I can use XCSoar to navigate Condor tasks with ‘custom’ turnpoints – Yay!

Here’s the Python script I created to do the conversion:

# This Python file uses the following encoding: utf-8
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("-v", "--verbose", help="increase output verbosity",
                    action="store_true")
args = parser.parse_args()

# Purpose:  Convert Condor task 'New TP' turnpoints (copy/pasted from Condor task description
# to a text file) to CUP-formatted strings and write them to a user-selected file to be used
# in XCSoar

# CUP file format:
# name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc
#"Cruseilles",Cruseill,,4601.100N,00606.400E,716.0m,1,,,,
#"Marignane",,,4325.998N,00512.846E,4m,5,317,2500,0,

#Condor Task 'New Waypoint' format:
# TP 2 (7,362 ft)
# Heading: 144° for 46.8 NM,
# Coords: 45.23.99N / 6.45.300E
# Classic turnpoint,
# min. height: 0 ft, max.: 32,808 ft
# angle: 360°, radius: 3,281 ft

#Plan:
#   Step1: Get text file containing Condor 'newTP' blocks copy/pasted from task description
#   Step2: Get 'outfile' filename to write .CUP lines to. Create if necessary. 
#           If aleady existing, ask user if we can overwrite. 'No' causes program to exit
#   Step3: Read lines until finding a line starting with 'TP' or 'Start'
#   Step4: Parse 'Coords' line to get coordinate Lat/Lon strings
#   Step5: Construct .CUP formatted line & write to outfile

#   Step1: Get text file containing Condor 'newTP' blocks copy/pasted from task description
import tkinter as tk
from tkinter.filedialog import askopenfilename, asksaveasfilename
root = tk.Tk() ; root.withdraw()


# PURPOSE: constructs a .CUP-formatted string from the (six?) lines waypoint
# block in the typical Condor-club task briefing.
# For example:
# ----------------------------------------------------------------------
# Start (2,434 ft)
# Heading: 115° for 3.9 NM,
# Coords: 46.31.377N / 6.42.372E
# Classic turnpoint,
# min. height: 0 ft, max.: 6,234 ft
# angle: 180°, radius: 13,123 ft
# ----------------------------------------------------------------------
# The CUP waypoint format is:
# name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc
# but we are only going to fill the name, code, lat, lon and style fields
#Inputs:
#   TPName = string containing the name to be used in the .CUP string
#   x = integer denoting index into the turnpoint block string list acquired from the input file
#Outputs
#   returns a string and the INDEX TO THE NEXT LINE in the list of strings from the input file
#Plan:
#   Step1: assign 'TPname' to 'name' and 'code'
#   Step2: skip the 'Heading' line
#   Step3: extract the lat/lon strings from the 'Coords' line and convert them to .CUP format
#   Step4: extract the style string from the next line
#   Step5: concatenate the above, with appropriate ',' entries for blank entries

def ConstructCUPString(tpname, inlist, inlist_idx):
    if args.verbose:
        print(f"In ConstructCUPString(tpname = {tpname}, inlist_idx = {inlist_idx})")
        
#Step1: assign 'TPname' to 'name' and 'code'
    namestr = tpname
    codestr = tpname
    
#Step2: skip the 'Heading' line
    inlist_idx += 2
#Step3: extract the lat/lon strings from the 'Coords' line and convert them to .CUP format
    
#  From SeeYou site: Latitude is a field of length 9, where char0-1 are degrees, Char2-3 are minutes, Char4 decimal point,
# char5-7 are decimal minutes and char8 is either N or S. The ellipsoid used is WGS-1984
# Example: SeeYou 5107.830N is equal to 51° 07.830' N    print(f"inlist[{inlist_idx}] = {inlist[inlist_idx]}")
    coordstrlist = inlist[inlist_idx].split()
    
    if args.verbose:
        print(coordstrlist)
        print("Constructing Latitude...\n")
    
    #latitude deg
    latstr = coordstrlist[1]
    
    if args.verbose:
        print(f"latitude string = {latstr}")
        
    lat_deg_dot_idx = latstr.find('.')
    lat_deg_val_str = latstr[0:lat_deg_dot_idx]
    lat_deg_val = int(lat_deg_val_str)
    if args.verbose:
        print(f"latitude lat_deg str = {lat_deg_val_str}")
        print(f"latitude lat_deg = {lat_deg_val}")
    
    #if necessary, add leading zero(s) to lat_deg value
    if len(lat_deg_val_str) < 2:
        if len(lat_deg_val_str) < 1:
            lat_deg_val_str = '0'+ lat_deg_val_str
        lat_deg_val_str = '0'+ lat_deg_val_str
    if args.verbose:
        print(f"after adjustment, latitude deg str = {lat_deg_val_str}")
    
    #latitude min
    min_dot_idx = latstr.find('.',lat_deg_dot_idx +1 )
    if args.verbose:
        print(f"lat_deg_dot_idx = {lat_deg_dot_idx}, min_dot_idx = {min_dot_idx}")
        
    minplusdec_str = latstr[lat_deg_dot_idx +1:] #still has 'N/S' appended
    lat_NorS_str = minplusdec_str[len(minplusdec_str)-1]
    minplusdec_str = minplusdec_str[0:len(minplusdec_str)]
    if args.verbose:
        print(f"latitude minplusdec str = {minplusdec_str}")
        print(f"latitude NorS str = {lat_NorS_str}")
        
    lat_min_dot_idx = minplusdec_str.find('.')
    if args.verbose:
        print(f"latitude min dot idx = {lat_min_dot_idx}")
        
    lat_min_val_str = minplusdec_str[0:lat_min_dot_idx]
    if args.verbose:
        print(f"latitude min val str = {lat_min_val_str}")
        
    lat_min_dec_val_str = minplusdec_str[lat_min_dot_idx + 1: len(minplusdec_str)-1]
    if args.verbose:
        print(f"latitude min dec val str = {lat_min_dec_val_str}")
    lat_min_dec_val = int(lat_min_dec_val_str)
    lat_min_val = int(lat_min_val_str)
    
    #if necessary, add leading zero(s) to minutes value
    if len(lat_min_val_str) < 2:
        if len(lat_min_val_str):
            lat_min_val_str = '0'+ lat_min_val_str
    if args.verbose:
        print(f"after 'len < 2' adjustment, latitude min str = {lat_min_val_str}")
        
    
    #if necessary, add trailing zero(s) to minutes decimal value
    if len(lat_min_dec_val_str) < 3:
        if len(lat_min_dec_val_str) < 2:
            lat_min_dec_val_str = lat_min_dec_val_str + '0'
        lat_min_dec_val_str = lat_min_dec_val_str + '0'
    if args.verbose:
        print(f"after 'len < 2' adjustment, latitude min dec str = {lat_min_dec_val_str}")
        print(f"latitude min = {lat_min_val}")
        print(f"latitude min str = {lat_min_val_str}")
        
    #now construct SeeYou equivalent
    
    cuplatstr = lat_deg_val_str + lat_min_val_str + '.' + lat_min_dec_val_str + lat_NorS_str
    if args.verbose:
        print(f"latitude .CUP str = {cuplatstr}")
        print("\nConstructing Longitude...\n")
    
    lonstr = coordstrlist[3]
    if args.verbose:
        print(f"longitude string = {lonstr}")
 
    lon_deg_dot_idx = lonstr.find('.')
    lon_deg_val_str = lonstr[0:lon_deg_dot_idx]
    lon_deg_val = int(lon_deg_val_str)
    if args.verbose:
        print(f"longitude lon_deg str = {lon_deg_val_str}")
        print(f"longitude lon_deg = {lon_deg_val}")
    
    #if necessary, add leading zero(s) to lon_deg value
    if len(lon_deg_val_str) < 3:
        if len(lon_deg_val_str) < 2:
            lon_deg_val_str = '0'+ lon_deg_val_str
        lon_deg_val_str = '0'+ lon_deg_val_str
    if args.verbose:
        print(f"after 'len < 3' adjustment, longitude deg str = {lon_deg_val_str}")
    
    #longitude min
    min_dot_idx = lonstr.find('.',lon_deg_dot_idx +1 )
    if args.verbose:
        print(f"lon_deg_dot_idx = {lon_deg_dot_idx}, min_dot_idx = {min_dot_idx}")
    
    minplusdec_str = lonstr[lon_deg_dot_idx +1:] #still has 'E/W' appended
    lon_EorW_str = minplusdec_str[len(minplusdec_str)-1]
    minplusdec_str = minplusdec_str[0:len(minplusdec_str)]
    if args.verbose:
        print(f"longitude minplusdec str = {minplusdec_str}")
        print(f"longitude EorW str = {lon_EorW_str}")
        
    lon_min_dot_idx = minplusdec_str.find('.')
    lon_min_val_str = minplusdec_str[0:lon_min_dot_idx]
    lon_min_dec_val_str = minplusdec_str[lon_min_dot_idx + 1: len(minplusdec_str)-1]
    if args.verbose:
        print(f"longitude min dot idx = {lon_min_dot_idx}")
        print(f"longitude min val str = {lon_min_val_str}")
        print(f"longitude min dec val str = {lon_min_dec_val_str}")
    
    
    #if necessary, add leading zero(s) to minutes value
    if len(lon_min_val_str) < 2:
        if len(lon_min_val_str):
            lon_min_val_str = '0'+ lon_min_val_str
    if args.verbose:
        print(f"after 'len < 2' adjustment, longitude min str = {lon_min_val_str}")
        
    
    #if necessary, add trailing zero(s) to minutes decimal value
    if len(lon_min_dec_val_str) < 3:
        if len(lon_min_dec_val_str) < 2:
            lon_min_dec_val_str = lon_min_dec_val_str + '0'
        lon_min_dec_val_str = lon_min_dec_val_str + '0'
    if args.verbose:
       print(f"after 'len < 3' adjustment, longitude min dec str = {lon_min_dec_val_str}")
        
    #now construct SeeYou equivalent
    cuplonstr = lon_deg_val_str + lon_min_val_str + '.' + lon_min_dec_val_str + lon_EorW_str
    if args.verbose:
        print(f"longitude .CUP str = {cuplonstr}")

#Step4: extract the style string from the next line
    if args.verbose:
        print(f"\nExtracting Turnpoint Style: ")    
        
    inlist_idx += 1
    stylestrlist = inlist[inlist_idx].split()
    stylestr = stylestrlist[0]    
    if args.verbose:
        print(f"stylestr = {stylestr}\n")
    
#Step5: concatenate the above, with appropriate ',' entries for blank entries
# name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc
    cupStr = namestr + ", " + codestr + ", ," + cuplatstr + ", " + cuplonstr + ", ," + stylestr + ", , , ,"
    inlist_idx += 1

    return cupStr, inlist_idx
#------------------------------------------------------------------------------------------------------    
#----------------------------------------Main Program------------------------------------------------    
#------------------------------------------------------------------------------------------------------    
infile = askopenfilename(parent=root)
    
print(f"File containing custom Condor task turnpoints = {infile}")

#   Step2: Get 'outfile' filename to write .CUP lines to. Create if necessary. 
#           If aleady existing, ask user if we can overwrite. 'No' causes program to exit
outfilename = asksaveasfilename(parent = root)

print(f"File to which XCSoar-compatible turnpoint lines will be written = {outfilename}")
ofile = open(outfilename,'w')
ofile.write(f"name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc\n")

#   Step3: Read 'infile' lines until finding a line starting with 'TP' or 'Start'
f=open(infile, encoding="utf-8")#"utf-8" encoding param needed so deg symbol displays OK
inlist = f.readlines()
f.close()


TPname = ''

#Print out entire list
if args.verbose:
    print("list contains " + str(len(inlist)) + " items")
    for x in range(len(inlist)):
        instr = inlist[x]
        print(str(x) + ": " + instr)
    
    if args.verbose:
        print("\nStart Processing Lines\n")

# for x in range(len(inlist)):
x = 0        
while x < len(inlist):
    instr = inlist[x]
    
    if args.verbose:
        print(str(x) + ": " + instr)
    
    outstr = '' #03/23/2024 needed to avoid error in verbose print block
    numstr = '' #03/23/2024 needed to avoid error in verbose print block
    if 'Start' in instr:
        TPname = 'NewStart'+ str(x)
        outstr, x = ConstructCUPString(TPname, inlist, x)
        ofile.write(outstr + "\n") #Write .CUP formatted line & write to outfile
    # if args.verbose:
        # print(f"back in main pgm: cupstr = {outstr},  x = {x}")
        
    elif 'TP' in instr:
        #TP number separated by a space
        numstr = instr[2:4]
        TPname = 'NewTP'+ numstr
        outstr, x = ConstructCUPString(TPname, inlist, x)
        ofile.write(outstr + "\n") #Write .CUP formatted line & write to outfile
        
    if args.verbose:
        print(f"numstr = {numstr}")
        print(f"back in main pgm: cupstr = {outstr},  x = {x}")
        
    x = x + 1
        
print(f"all {x} infile lines processed")
        
ofile.close()

#now print out ofile contents
# if args.verbose:
print(f"\nContents of output file {outfilename}")
outfile = open(outfilename, 'r')

for line in outfile:
    print(line)

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

# This Python file uses the following encoding: utf-8

import argparse

parser = argparse.ArgumentParser()

parser.add_argument("-v", "--verbose", help="increase output verbosity",

action="store_true")

args = parser.parse_args()

# Purpose: Convert Condor task 'New TP' turnpoints (copy/pasted from Condor task description

# to a text file) to CUP-formatted strings and write them to a user-selected file to be used

# in XCSoar

# CUP file format:

# name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc

#"Cruseilles",Cruseill,,4601.100N,00606.400E,716.0m,1,,,,

#"Marignane",,,4325.998N,00512.846E,4m,5,317,2500,0,

#Condor Task 'New Waypoint' format:

# TP 2 (7,362 ft)

# Heading: 144° for 46.8 NM,

# Coords: 45.23.99N / 6.45.300E

# Classic turnpoint,

# min. height: 0 ft, max.: 32,808 ft

# angle: 360°, radius: 3,281 ft

#Plan:

# Step1: Get text file containing Condor 'newTP' blocks copy/pasted from task description

# Step2: Get 'outfile' filename to write .CUP lines to. Create if necessary.

# If aleady existing, ask user if we can overwrite. 'No' causes program to exit

# Step3: Read lines until finding a line starting with 'TP' or 'Start'

# Step4: Parse 'Coords' line to get coordinate Lat/Lon strings

# Step5: Construct .CUP formatted line & write to outfile

# Step1: Get text file containing Condor 'newTP' blocks copy/pasted from task description

import tkinter as tk

from tkinter.filedialog import askopenfilename, asksaveasfilename

root = tk.Tk() ; root.withdraw()

# PURPOSE: constructs a .CUP-formatted string from the (six?) lines waypoint

# block in the typical Condor-club task briefing.

# For example:

# ----------------------------------------------------------------------

# Start (2,434 ft)

# Heading: 115° for 3.9 NM,

# Coords: 46.31.377N / 6.42.372E

# Classic turnpoint,

# min. height: 0 ft, max.: 6,234 ft

# angle: 180°, radius: 13,123 ft

# ----------------------------------------------------------------------

# The CUP waypoint format is:

# name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc

# but we are only going to fill the name, code, lat, lon and style fields

#Inputs:

# TPName = string containing the name to be used in the .CUP string

# x = integer denoting index into the turnpoint block string list acquired from the input file

#Outputs

# returns a string and the INDEX TO THE NEXT LINE in the list of strings from the input file

#Plan:

# Step1: assign 'TPname' to 'name' and 'code'

# Step2: skip the 'Heading' line

# Step3: extract the lat/lon strings from the 'Coords' line and convert them to .CUP format

# Step4: extract the style string from the next line

# Step5: concatenate the above, with appropriate ',' entries for blank entries

def ConstructCUPString(tpname, inlist, inlist_idx):

if args.verbose:

print(f"In ConstructCUPString(tpname = {tpname}, inlist_idx = {inlist_idx})")

#Step1: assign 'TPname' to 'name' and 'code'

namestr = tpname

codestr = tpname

#Step2: skip the 'Heading' line

inlist_idx += 2

#Step3: extract the lat/lon strings from the 'Coords' line and convert them to .CUP format

# From SeeYou site: Latitude is a field of length 9, where char0-1 are degrees, Char2-3 are minutes, Char4 decimal point,

# char5-7 are decimal minutes and char8 is either N or S. The ellipsoid used is WGS-1984

# Example: SeeYou 5107.830N is equal to 51° 07.830' N print(f"inlist[{inlist_idx}] = {inlist[inlist_idx]}")

coordstrlist = inlist[inlist_idx].split()

if args.verbose:

print(coordstrlist)

print("Constructing Latitude...\n")

#latitude deg

latstr = coordstrlist[1]

if args.verbose:

print(f"latitude string = {latstr}")

lat_deg_dot_idx = latstr.find('.')

lat_deg_val_str = latstr[0:lat_deg_dot_idx]

lat_deg_val = int(lat_deg_val_str)

if args.verbose:

print(f"latitude lat_deg str = {lat_deg_val_str}")

print(f"latitude lat_deg = {lat_deg_val}")

#if necessary, add leading zero(s) to lat_deg value

if len(lat_deg_val_str) < 2:

if len(lat_deg_val_str) < 1:

lat_deg_val_str = '0'+ lat_deg_val_str

if args.verbose:

print(f"after adjustment, latitude deg str = {lat_deg_val_str}")

#latitude min

min_dot_idx = latstr.find('.',lat_deg_dot_idx +1 )

if args.verbose:

print(f"lat_deg_dot_idx = {lat_deg_dot_idx}, min_dot_idx = {min_dot_idx}")

minplusdec_str = latstr[lat_deg_dot_idx +1:] #still has 'N/S' appended

lat_NorS_str = minplusdec_str[len(minplusdec_str)-1]

minplusdec_str = minplusdec_str[0:len(minplusdec_str)]

if args.verbose:

print(f"latitude minplusdec str = {minplusdec_str}")

print(f"latitude NorS str = {lat_NorS_str}")

lat_min_dot_idx = minplusdec_str.find('.')

if args.verbose:

print(f"latitude min dot idx = {lat_min_dot_idx}")

lat_min_val_str = minplusdec_str[0:lat_min_dot_idx]

if args.verbose:

print(f"latitude min val str = {lat_min_val_str}")

lat_min_dec_val_str = minplusdec_str[lat_min_dot_idx + 1: len(minplusdec_str)-1]

if args.verbose:

print(f"latitude min dec val str = {lat_min_dec_val_str}")

lat_min_dec_val = int(lat_min_dec_val_str)

lat_min_val = int(lat_min_val_str)

#if necessary, add leading zero(s) to minutes value

if len(lat_min_val_str) < 2:

if len(lat_min_val_str):

lat_min_val_str = '0'+ lat_min_val_str

if args.verbose:

print(f"after 'len < 2' adjustment, latitude min str = {lat_min_val_str}")

#if necessary, add trailing zero(s) to minutes decimal value

if len(lat_min_dec_val_str) < 3:

if len(lat_min_dec_val_str) < 2:

lat_min_dec_val_str = lat_min_dec_val_str + '0'

if args.verbose:

print(f"after 'len < 2' adjustment, latitude min dec str = {lat_min_dec_val_str}")

print(f"latitude min = {lat_min_val}")

print(f"latitude min str = {lat_min_val_str}")

#now construct SeeYou equivalent

cuplatstr = lat_deg_val_str + lat_min_val_str + '.' + lat_min_dec_val_str + lat_NorS_str

if args.verbose:

print(f"latitude .CUP str = {cuplatstr}")

print("\nConstructing Longitude...\n")

lonstr = coordstrlist[3]

if args.verbose:

print(f"longitude string = {lonstr}")

lon_deg_dot_idx = lonstr.find('.')

lon_deg_val_str = lonstr[0:lon_deg_dot_idx]

lon_deg_val = int(lon_deg_val_str)

if args.verbose:

print(f"longitude lon_deg str = {lon_deg_val_str}")

print(f"longitude lon_deg = {lon_deg_val}")

#if necessary, add leading zero(s) to lon_deg value

if len(lon_deg_val_str) < 3:

if len(lon_deg_val_str) < 2:

lon_deg_val_str = '0'+ lon_deg_val_str

if args.verbose:

print(f"after 'len < 3' adjustment, longitude deg str = {lon_deg_val_str}")

#longitude min

min_dot_idx = lonstr.find('.',lon_deg_dot_idx +1 )

if args.verbose:

print(f"lon_deg_dot_idx = {lon_deg_dot_idx}, min_dot_idx = {min_dot_idx}")

minplusdec_str = lonstr[lon_deg_dot_idx +1:] #still has 'E/W' appended

lon_EorW_str = minplusdec_str[len(minplusdec_str)-1]

minplusdec_str = minplusdec_str[0:len(minplusdec_str)]

if args.verbose:

print(f"longitude minplusdec str = {minplusdec_str}")

print(f"longitude EorW str = {lon_EorW_str}")

lon_min_dot_idx = minplusdec_str.find('.')

lon_min_val_str = minplusdec_str[0:lon_min_dot_idx]

lon_min_dec_val_str = minplusdec_str[lon_min_dot_idx + 1: len(minplusdec_str)-1]

if args.verbose:

print(f"longitude min dot idx = {lon_min_dot_idx}")

print(f"longitude min val str = {lon_min_val_str}")

print(f"longitude min dec val str = {lon_min_dec_val_str}")

#if necessary, add leading zero(s) to minutes value

if len(lon_min_val_str) < 2:

if len(lon_min_val_str):

lon_min_val_str = '0'+ lon_min_val_str

if args.verbose:

print(f"after 'len < 2' adjustment, longitude min str = {lon_min_val_str}")

#if necessary, add trailing zero(s) to minutes decimal value

if len(lon_min_dec_val_str) < 3:

if len(lon_min_dec_val_str) < 2:

lon_min_dec_val_str = lon_min_dec_val_str + '0'

if args.verbose:

print(f"after 'len < 3' adjustment, longitude min dec str = {lon_min_dec_val_str}")

#now construct SeeYou equivalent

cuplonstr = lon_deg_val_str + lon_min_val_str + '.' + lon_min_dec_val_str + lon_EorW_str

if args.verbose:

print(f"longitude .CUP str = {cuplonstr}")

#Step4: extract the style string from the next line

if args.verbose:

print(f"\nExtracting Turnpoint Style: ")

inlist_idx += 1

stylestrlist = inlist[inlist_idx].split()

stylestr = stylestrlist[0]

if args.verbose:

print(f"stylestr = {stylestr}\n")

#Step5: concatenate the above, with appropriate ',' entries for blank entries

# name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc

cupStr = namestr + ", " + codestr + ", ," + cuplatstr + ", " + cuplonstr + ", ," + stylestr + ", , , ,"

inlist_idx += 1

return cupStr, inlist_idx

#------------------------------------------------------------------------------------------------------

#----------------------------------------Main Program------------------------------------------------

#------------------------------------------------------------------------------------------------------

infile = askopenfilename(parent=root)

print(f"File containing custom Condor task turnpoints = {infile}")

# Step2: Get 'outfile' filename to write .CUP lines to. Create if necessary.

# If aleady existing, ask user if we can overwrite. 'No' causes program to exit

outfilename = asksaveasfilename(parent = root)

print(f"File to which XCSoar-compatible turnpoint lines will be written = {outfilename}")

ofile = open(outfilename,'w')

ofile.write(f"name,code,country,lat,lon,elev,style,rwdir,rwlen,freq,desc\n")

# Step3: Read 'infile' lines until finding a line starting with 'TP' or 'Start'

f=open(infile, encoding="utf-8")#"utf-8" encoding param needed so deg symbol displays OK

inlist = f.readlines()

f.close()

TPname = ''

#Print out entire list

if args.verbose:

print("list contains " + str(len(inlist)) + " items")

for x in range(len(inlist)):

instr = inlist[x]

print(str(x) + ": " + instr)

if args.verbose:

print("\nStart Processing Lines\n")

# for x in range(len(inlist)):

x = 0

while x < len(inlist):

instr = inlist[x]

if args.verbose:

print(str(x) + ": " + instr)

outstr = '' #03/23/2024 needed to avoid error in verbose print block

numstr = '' #03/23/2024 needed to avoid error in verbose print block

if 'Start' in instr:

TPname = 'NewStart'+ str(x)

outstr, x = ConstructCUPString(TPname, inlist, x)

ofile.write(outstr + "\n") #Write .CUP formatted line & write to outfile

# if args.verbose:

# print(f"back in main pgm: cupstr = {outstr}, x = {x}")

elif 'TP' in instr:

#TP number separated by a space

numstr = instr[2:4]

TPname = 'NewTP'+ numstr

outstr, x = ConstructCUPString(TPname, inlist, x)

ofile.write(outstr + "\n") #Write .CUP formatted line & write to outfile

if args.verbose:

print(f"numstr = {numstr}")

print(f"back in main pgm: cupstr = {outstr}, x = {x}")

x = x + 1

print(f"all {x} infile lines processed")

ofile.close()

#now print out ofile contents

# if args.verbose:

print(f"\nContents of output file {outfilename}")

outfile = open(outfilename, 'r')

for line in outfile:

print(line)

Enjoy!

Frank

Bridgemate II Keypad Membrane Replacement

Leave a reply

Posted 22 February 2024

COBA, the Central Ohio Bridge Association, owns a number of Bridgemate II table pads, and lately we have been hearing a number of complaints about having to press buttons harder than normal to get the expected response. After some research, one of our members discovered that we could purchase replacement membranes from Bridgemate for $15 each, so we decided to undertake a membrane replacement program.

Opening up a Bridgemate II

The keyboard cover/upper-half can be removed by disengaging a number of flexible plastic tabs, as shown in the following page from the Bridgemate site:

While this wasn’t quite as trivial as the above description, it wasn’t really all that hard. Most of the difficulty was in trying NOT to break things during the opening process on the first unit. Once that was accomplished (thankfully without breaking anything), I’m sure the rest will go much easier. Here are some photos showing the disassembled Bridgemate II

Visual inspection of this first unit showed everything to be very clean – basically indistinguishable from a brand-new unit. In particular, the key membrane seemed to completely intact, and could be easily manipulated between the ‘pressed’ and the ‘unpressed’ states with just fingertip pressure.

Stay tuned,

Frank

Using VS Code to Debug Linux Makefile Projects

Leave a reply

Posted 20 February 2024,

I recently got re-interesting in soaring (glider racing) after a number of years away. As part of this new journey, I became interested in contributing to the development of the XCSoar glider racing navigation software. I had contributed to this program some years ago in a very minor way, and thought maybe now that I’m retired and have plenty of time to waste (NOT!!), I could maybe contribute in a more meaningful way.

In any case, XCSoar development is done in Linux (Specifically in Debian Linux, but that’s another story), so I started thinking about creating a development environment on a Debian Linux box. I had an old Dell Precision M6700 ‘desktop replacement’ laptop that I hadn’t turned on for years, so I dug it out, installed Linux (Ubuntu first, then Debian), and with the help of Ronald Niederhagen (see this post), I was able to clone the XCSoar repo from Github and built both the Linux and Android versions.

However, I still needed to find a way to ‘break into’ the code, and to do that I was going to need a way of running the program under debug control. I have done this sort of thing for decades on the Windows world, but not so much in Linux, so I was sort of starting from scratch. After a LOT of research, I found that Microsoft had a free Linux IDE called VS Code – sort of a lightweight version of Visual Studio aimed at the Linux and IOS world.

So, I installed VS Code on my Linux box and started the ‘lets learn yet another coding IDE’ dance, again starting with a lot of Google searches, running tutorials, etc etc. After creating some basic ‘hello world’ programs using VS code, I started thinking about how to use VS Code on the XCSoar project, comprised of thousands of source files and a Makefile almost three hundred lines long. I knew just enough about Makefiles to type ‘make’ or ‘make all’, so there was a steep learning curve ahead to use VSCode for debugging.

After yet another round of Google searches and forum posts, I found a relevant tutorial on the ‘HackerNoon’ website. the HackerNoon tutorial seems to be aimed at Windows users (Linux doesn’t use extensions to denote executable files), but I was able to work my way through and translate as appropriate. I suggest you open the HackerNoon tutorial in one window, and this ‘translation’ in another.

Original:

I will be using the following tools:

VSCode

Git Bash (using MinGW-w64)

g++ (part of the GNU Compiler Collection (GCC))

GNU Make

I will be using the following tools:

VSCode

Git Bash (using MinGW-w64)

g++ (part of the GNU Compiler Collection (GCC))

GNU Make

Translation for Linux:

I will be using the following tools:

VSCode

Bash 

g++ (part of the GNU Compiler Collection (GCC))

Make

I will be using the following tools:

VSCode

Bash

g++ (part of the GNU Compiler Collection (GCC))

Make

Download & Install VS Code: See this link. Everything else should already be available as part of any modern Linux distro (I’m using Debian 12 – ‘bookworm’).

main.cpp: (same as original – no translation required)

#include <iostream>
#include <vector>
#include <string>

int main() {
    std::vector<std::string> testStrings {"this", "is", "just", "a", "test"};

    for(auto testString : testStrings) {
        std::cout << testString << std::endl;
    }
}

#include <iostream>

#include <vector>

#include <string>

int main() {

std::vector<std::string> testStrings {"this", "is", "just", "a", "test"};

for(auto testString : testStrings) {

std::cout << testString << std::endl;

}

Makefile (Original):

CC="/c/MinGW/bin/g++.exe"

main.exe: main.cpp
	${CC} -g main.cpp

CC="/c/MinGW/bin/g++.exe"

main.exe: main.cpp

${CC} -g main.cpp

Makefile (Translation for Linux):

OUT_FILE = "mymain"

main: mymain.cpp
	g++ -g -o $(OUT_FILE) mymain.cpp

OUT_FILE = "mymain"

main: mymain.cpp

g++ -g -o $(OUT_FILE) mymain.cpp

Run the ‘main.exe’ make target, then run the executable to make sure everything works (Original):

$ /c/MinGW/bin/mingw32-make.exe main.exe
$ ./main.exe

1 2	$ /c/MinGW/bin/mingw32-make.exe main.exe $ ./main.exe

Translation for Linux:

I placed ‘mymain.cpp’ and ‘Makefile’ in my home directory tree as shown below:

frank@M6700:~/projects$ ls /home/frank/projects/Hacknoon/
Makefile  mymain.cpp
frank@M6700:~/projects$

frank@M6700:~/projects$ ls /home/frank/projects/Hacknoon/

Makefile mymain.cpp

frank@M6700:~/projects$

so to test the Makefile and the executable, I did the following:

frank@M6700:~/projects$ cd /home/frank/projects/Hacknoon/
frank@M6700:~/projects/Hacknoon$ make
g++ -g -o "mymain" mymain.cpp
frank@M6700:~/projects/Hacknoon$ ./mymain
this
is
just
a
test
frank@M6700:~/projects/Hacknoon$

frank@M6700:~/projects$ cd /home/frank/projects/Hacknoon/

frank@M6700:~/projects/Hacknoon$ make

g++ -g -o "mymain" mymain.cpp

frank@M6700:~/projects/Hacknoon$ ./mymain

this

just

test

frank@M6700:~/projects/Hacknoon$

This test confirms that the source code compiles correctly, that the Makefile is correct, and the output from the compiled program is as expected – yay!

Setting up VSCode debugger:

At this point the HackerNoon tutorial and my experience parted ways. I could get the ‘Run and Debug’ side panel open, and I could open ‘mymain.cpp’ in the VSCode editor window, but I couldn’t find anything that suggested it could “create a launch.json file”. I tried to send a comment to the author, but comments weren’t enabled for some reason (and yes, I did register and log in). I suspect that the disparity between the HackerNoon example and my VSCode reality is due to changes in VSCode after the HackerNoon tutorial was created. Which is why I absolutely hate posts like this that aren’t dated in any way shape or form. Because of this, it is impossible to determine if changes like I encountered are due to mistakes on the part of the author, or just changes in the underlying software being demonstrated.

So, I was left to randomly click on things until, by some miracle, the ‘launch.json’ file was created and appeared in the VSCode edit window. Later I went back and tried to re-create the miracle and I sort of figured it out; with the ‘mymain.cpp’ file open in the editor, click on the ‘gear’ icon (upper right as shown in the screenshot below):

And select ‘(gdb) Launch’ from the menu items presented. This will create a ‘launch.json’ file and open it in the editor, as shown below:

At this point we can reconnect to the ‘HackerNoon’ tutorial and copy/paste the launch.json contents from the tutorial to the newly-created launch.json file in VSCode, as shown below

launch.json after copy/pasting example code from HackerNoon site

Here’s the ‘launch.json’ file from HackerNoon:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/main.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set Disassembly Flavor to Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "run the makefile"
        }
    ]
}

{

"version": "0.2.0",

"configurations": [

{

"name": "(gdb) Launch",

"type": "cppdbg",

"request": "launch",

"program": "${workspaceFolder}/main.exe",

"args": [],

"stopAtEntry": false,

"cwd": "${fileDirname}",

"environment": [],

"externalConsole": false,

"MIMode": "gdb",

"miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",

"setupCommands": [

{

"description": "Enable pretty-printing for gdb",

"text": "-enable-pretty-printing",

"ignoreFailures": true

{

"description": "Set Disassembly Flavor to Intel",

"text": "-gdb-set disassembly-flavor intel",

"ignoreFailures": true

}

"preLaunchTask": "run the makefile"

}

]

}

And here’s the same file, after translating it for Linux instead of Windows:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/mymain",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "./gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set Disassembly Flavor to Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "run the makefile"
        }
    ]
}

{

"version": "0.2.0",

"configurations": [

{

"name": "(gdb) Launch",

"type": "cppdbg",

"request": "launch",

"program": "${workspaceFolder}/mymain",

"args": [],

"stopAtEntry": false,

"cwd": "${fileDirname}",

"environment": [],

"externalConsole": false,

"MIMode": "gdb",

"miDebuggerPath": "./gdb",

"setupCommands": [

{

"description": "Enable pretty-printing for gdb",

"text": "-enable-pretty-printing",

"ignoreFailures": true

{

"description": "Set Disassembly Flavor to Intel",

"text": "-gdb-set disassembly-flavor intel",

"ignoreFailures": true

}

"preLaunchTask": "run the makefile"

}

]

}

The next step is to create a ‘tasks.json’ file using the ‘New File’ (ALT-Ctrl-N) in VSCode. This brings up a dialog forcing the user to specify the folder into which the new file will be placed, which seemed a bit strange for me, but what do I know. Put the new file in the same (hidden) .vscode folder as the companion ‘launch.json’. In my setup this was layed out as shown below:

frank@M6700:~/projects/Hacknoon$ ls -alFR
.:
total 152
drwxr-xr-x 3 frank frank   4096 Feb 21 11:33 ./
drwxr-xr-x 7 frank frank   4096 Feb 21 12:19 ../
-rw-r--r-- 1 frank frank    116 Feb 20 18:44 Makefile
-rwxr-xr-x 1 frank frank 134680 Feb 21 11:33 mymain*
-rw-r--r-- 1 frank frank    243 Feb 19 11:19 mymain.cpp
drwxr-xr-x 2 frank frank   4096 Feb 19 19:43 .vscode/

./.vscode:
total 16
drwxr-xr-x 2 frank frank 4096 Feb 19 19:43 ./
drwxr-xr-x 3 frank frank 4096 Feb 21 11:33 ../
-rw-r--r-- 1 frank frank  970 Feb 21 16:37 launch.json
-rw-r--r-- 1 frank frank  383 Feb 20 19:16 tasks.json

frank@M6700:~/projects/Hacknoon$ ls -alFR

total 152

drwxr-xr-x 3 frank frank 4096 Feb 21 11:33 ./

drwxr-xr-x 7 frank frank 4096 Feb 21 12:19 ../

-rw-r--r-- 1 frank frank 116 Feb 20 18:44 Makefile

-rwxr-xr-x 1 frank frank 134680 Feb 21 11:33 mymain*

-rw-r--r-- 1 frank frank 243 Feb 19 11:19 mymain.cpp

drwxr-xr-x 2 frank frank 4096 Feb 19 19:43 .vscode/

./.vscode:

total 16

drwxr-xr-x 2 frank frank 4096 Feb 19 19:43 ./

drwxr-xr-x 3 frank frank 4096 Feb 21 11:33 ../

-rw-r--r-- 1 frank frank 970 Feb 21 16:37 launch.json

-rw-r--r-- 1 frank frank 383 Feb 20 19:16 tasks.json

Here’s the original ‘tasks.json’:

{
    "tasks": [
        {
            "type": "shell",
            "label": "run the makefile",
            "command": "/c/MinGW/bin/mingw32-make.exe",
            "args": ["main.exe"],
            "problemMatcher": [],
        }
    ],
    "version": "2.0.0"
}

{

"tasks": [

{

"type": "shell",

"label": "run the makefile",

"command": "/c/MinGW/bin/mingw32-make.exe",

"args": ["main.exe"],

"problemMatcher": [],

}

"version": "2.0.0"

}

And here’s the same file after translation for Linux:

{
    "tasks": [
        {
            "type": "shell",
            "label": "run the makefile",
            "command": "make",
            "args": ["mymain"],
            "problemMatcher": [],
        }
    ],
    "version": "2.0.0"
}

{

"tasks": [

{

"type": "shell",

"label": "run the makefile",

"command": "make",

"args": ["mymain"],

"problemMatcher": [],

}

"version": "2.0.0"

}

The above three files (mymain.cpp, launch.json and tasks.json) form a complete set (a ‘configuration?) that enables VSCode to compile and then run – under debug control – a .cpp file. Here’s a short video showing two complete compile/run cycles:

Video showing VSCode compiling/running/debugging using a Linux Makefile

At this point is is clear that the combination of VSCode, in conjunction with appropriately constructed ‘Makefile’, ‘launch.json’ and ‘tasks.json’ files is capable of debugging a Linux-base C++ program. This means that – at least in theory – I should be able to aim VSCode at the humungous Makefile associated with the equally humungous XCSoar program and step through the source code under debug control – yeeehah!

23 February 2024 Update:

Well, the theory (about being able to run XCSoar under debug control) has now been validated. I was able to run XCSoar using the following launch & tasks.json file contents

Launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/output/UNIX/bin/xcsoar",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set Disassembly Flavor to Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "run the makefile"
        }
    ]
}

{

"version": "0.2.0",

"configurations": [

{

"name": "(gdb) Launch",

"type": "cppdbg",

"request": "launch",

"program": "${workspaceFolder}/output/UNIX/bin/xcsoar",

"args": [],

"stopAtEntry": false,

"cwd": "${fileDirname}",

"environment": [],

"externalConsole": false,

"MIMode": "gdb",

"miDebuggerPath": "gdb",

"setupCommands": [

{

"description": "Enable pretty-printing for gdb",

"text": "-enable-pretty-printing",

"ignoreFailures": true

{

"description": "Set Disassembly Flavor to Intel",

"text": "-gdb-set disassembly-flavor intel",

"ignoreFailures": true

}

"preLaunchTask": "run the makefile"

}

]

}

Tasks.json:

{
    "tasks": [
       {
            "type": "shell",
            "label": "run the makefile",
            "command": "make",
            "args": [],
            "problemMatcher": [],
        },
    ],
    "version": "2.0.0"
}

{

"tasks": [

{

"type": "shell",

"label": "run the makefile",

"command": "make",

"args": [],

"problemMatcher": [],

"version": "2.0.0"

}

And here is a short video showing the action:

So now I’m set; I can run XCSoar under debug control, and I should be able to poke around and hopefully make some changes (or at least understand some of the magic tricks). On thing I’ve already found is that (depending on where the breakpoints are) XCSoar can grab the mouse focus (not the keyboad, thankfully), so even though the mouse cursor can move around the screen outside the XCSoar window, all mouse clicks go to XCSoar. Fortunately I found that keyboard inputs still go to VSCode, so I can still (with some difficulty) get around OK.

Trying my Hand at XCSoar Program Development

1 Reply

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:

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

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:

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

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:

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:~$

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:

try "sudo apt-get install default-jre"

1	try "sudo apt-get install default-jre"

I ran the install, and FINALLY I was able to get the XCSoar Android version installed:

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!

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:

Installing a fresh Android version of XCSoar on my Android M10 tablet

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

XCSoar Soaring Computer AAT Task Study, Part III

Leave a reply

Posted 29 January 2024

This post is the third installment of my continuing attempt to learn how to use the XCSoar soaring flight computer to successfully navigate AAT/TAT tasks. Although I am using the Condor2 soaring flight simulator for this purpose, the results should be perfectly applicable to real-life AAT/TAT task navigation as well.

The experimental setup for this and previous test flights is an Android M10 tablet connected via Bluetooth to my Win10 PC running Condor2. I created a small task in the default Slovenia scenery as shown below:

And I loaded this same scenery and task into XCSoar, and started flying the task

I am using the latest version of XCSoar, compiled from source code on my Linux box and then ‘side-loaded’ to the M10 Android tablet, as shown below

In response to some comments regarding an earlier test run, this time I made sure I had the proper glide polar selected for the plane (ASW-28-15) to be flown in Condor. Here’s the polar plot in Condor:

And here is the tabular information for the ASW28-15 polar in XCSoar

Another issue from the last run was that I had not selected a MC value for the flight, just accepting the default value of 1.0. There was some concern that using this value caused XCSoar to use a very low achieved speed value for task completion calculations. For this run, I selected an initial MC value of 5.0 (although I changed it a couple of times during the task in an attempt to determine the effect of the user-selected MC value on task parameters).

The next photo shows the situation just after starting the task.

In my last run I noticed the time display was way off – like 7hrs off. So this time I added both ‘local’ and ‘UTC’ info blocks to the bottom of the cruise info set. As can be seen in the above image, the start took place at 12:03 UTC, and the local time is shown as 8:03(pm?). This is clearly wrong. I believe XCSoar is mis-interpreting the time information imbedded in the NMEA stream (or Condor2 isn’t properly converting the time in the NMEA stream from local to UTC). I looked at a representative NMEA ‘GPGGA’ string from Condor2, and it appears Condor is the culprit; I see ‘$gpgga,120235,…’, where the ‘120235’ value is supposed to be UTC, but is clearly local time – oops!

The AAT Time and AAT dt values look reasonable here, although I am suspicious that the dt value is so close to zero. What speed and distance values are being used to produce this result? If the ‘AAT Dtgt’ value (50.4) is used for the distance, and the ‘AATVtgt’ value (60.5mph) is used for speed, the result is 49.98 min, which is very close to the displayed ‘AATdt’ of 3min 48 sec. I checked this again about 3 min into the flight, and this time AATdtgt = 54.6, AATVtgt = 65.5mph ==> 50.01min ETE ==> AATdt of 5.01 min vs the displayed AAT delta of 4.75min.

After about 5 min, I figured out how to bring the Status page up, as shown below:

There are a lot of different values here, but I don’t understand most of them.

Assigned task time and Estimated task time – those are understandable and reasonable
Remaining time. I think this is strictly the ‘AAT Time’ value, counting down min by min
Task distance: probably the same as AATDtgt – the distance around the target points as currently placed.
Remaining distance: No clue
Speed estimated: No clue
Speed average: Probably just what it says – distance-made-good/time-since-start
MacCready: Self explanatory
AAT range: Shown as -19% here, so I believe that means both remaining targets are slightly in front of their respective centers.
Speed remaining: No clue. Maybe the distance remaining (AATdtgt?) divided by the time remaining? 49.5mi / 65mph ==>45.6min, so this is probably correct
Achieved MacCready, Achieved speed, Cruise efficiency: No clue

Shortly after this I launched the ‘Target Show’ utility, and stepped through the targets, as shown in the screenshots below:

The values shown in the above pages for KURJIV & JAVROJEV seem reasonable, but I’m not sure where the ‘V rem’ value comes from.

Also, I note that the ‘Delta T’ value isn’t color-coded like it is for the ‘AAT delta time’ InfoBox. I think this is a mistake; if you color-code it in one place, you should color-code it in all places

The next two screenshots show the situation about midway through the KURJIV area

I still don’t understand much of the data shown on the ‘Status’ page, and now I note that the ‘Remaining time’ value on the Status page is not the same as the ‘AAT time’ value on the map display. The difference between these two times is (38-33’23 = 4’37) is close to the sum of the ‘AAT time’ and ‘AAT delta time’ values.

I turned in the KURJIV area shortly after passing the KURJIV center point. When I did, I somehow managed to disable all the InfoBox displays – yikes!

Fortunately I managed to get them back in fairly short order by clicking on the ‘Page Show Info’ box, changing it from ‘Auto’ to ‘Hide’ (I must have inadvertently changed this feature from ‘Auto’ to ‘Hide’ earlier. Here’s a short video clip showing the mis-fingering and the re-fingering:

Note that the original ‘mis-fingering’ was me trying to bring up the ‘Status’ page with an ‘S’ gesture on the screen, and somehow got the ‘Hide the InfoBoxes’ option instead -yikes!

At some point between the KURJIV & JAVORJEV areas, I manually changed the MC value from 5 to 1 to see if that impacted the navigation and ETA calculations. AFAICT, it did absolutely nothing. Later I changed it from 1.0 to 9.2kts, and still couldn’t see any difference in the calculation.

Just as I entered the second (JAVROJEV) area, I changed to the ‘Target’ display in the JAVROJEVA area, as shown below:

Just before entering JAVROJEV area. Note that the ‘optimize’ feature is enabled

With ‘optimization’ enabled, XCSoar has adjusted the target point so as to result in a slightly overtime (4min 56 sec) arrival. Next, I manually moved the target point to the very end of the area. This also automatically disabled the ‘optimization’ feature. Within a second or two, the Delta T value changed from 4min 56sec to 12min 3sec, as expected. Then I moved the target to near the start of the area, and Delta T changed to -4min 23sec, as shown in the next two screenshots.

JAVROJEV target moved to back of area, resulting in a projected 12min 9sec over time arrival

JAVROJEV target moved to front of area, resulting in a projected -4min 23sec undertime arrival

I left the target at the front of the area, to see how XCSoar behaved in non-optimization mode. The next screenshot shows the situation just as the glider crosses through the ellipse connected to the manually placed target.

Glider just crossing early-arrival target ellipse

Note that Delta T is now -5min 5sec instead of -4min 23sec, and Vach is now 76.8mph instead of 76.5mph, consistent with the slightly earlier arrival time.

Next I flew on into the JAVROJEV area, still in non-optimized mode. As the glider went past the target ellipse, the Delta T value kept changing in a way consistent with the increased distance and (slightly) increased speed. It appears as if XCSoar is actually moving the calculation target along with the glider, even though the displayed target point isn’t moving. Sort of a ‘shadow’ optimization mode?

In the next screenshot, the glider is just at the point of turning toward home.

At this point the manually placed target is toward the front of the area, but now XCSoar is showing a +6min 14sec overtime arrival, which should be enough of a margin to avoid an early arrival due to a faster-than-expected final glide

The next screenshot shows the situation just after clicking on the ‘arm turn’ box.

Just after turning for home in JAVROJEV area. Note target no longer visible

The target marker and ellipse which was at the front of the area has now disappeared, and the ETA/ETD calculations now show a 3m 59sec overtime arrival down from 6min 17sec just a few seconds earlier. There is no way the glider or pilot could have caused this 3min 18sec change, so clearly there is something that isn’t quite consistent in XCSoasr’s before and after turn calculations.

At this point, the flight is essentially over. As the next screenshot shows, the flight ended with a slightly (1min 14sec) overtime arrival, as hoped for.

Flight Summary:

This test flight was much more successful than earlier ones, and I now have a reasonable expectation of being able to navigate/manage an AAT/TAT task in Condor without getting myself completely turned inside out. There are still some issues, though:

The ‘Time UTC’ and ‘Time loc.’ readouts are completely screwed up, but it’s not XCSoar’s fault. Condor2’s GPS NMEA sentences insert local times into the UTC field, a really bad NoNo. Since Condor knows where it is in whatever task scenery is being used, it must convert local times to UTC times internally, and put the UTC time into the NMEA stream.
It is still not clear to me what speed(s) XCSoar uses for arrival time calculations, I think it is using some form of ‘speed made good’ or ‘average speed to date’.
I don’t think the MacCready value (or it’s corresponding projected speed) is used at all. At one point I changed the MacCready value from 5.0 to 1.0, then to 9.2, and then back to 5.0 and didn’t notice any significant change in the arrival time calculations.
XCSoar has a few minor GUI issues. The ‘delta time readout on the status page doesn’t utilize the same (or any) color code as the ‘AAT delta time’ readout on the main navigation page.
When the pilot flies past the target and target ellipse, the target should start moving with the glider. AFAICT, the calculations do that already – it’s just the graphical element that isn’t tracking.
At one point I lost all my info boxes, and had no idea how it had happened or how to get them back again. As it turned out, the culprit was my attempt to bring up the ‘Status’ page with an ‘S’ gesture. Not only did XCSoar not recognize my feeble attempt, but it obviously did recognize it as some sort of ‘hide the infoboxes’ gesture – yikes! This seems to be a classic case of symbol interference – literally.

I have included a link to the full video of this flight below, in case someone else would like to reference it for their own research, or to buttress/rebut a claim or opinion from me.

https://drive.google.com/file/d/1CB6CgySUK0nWtdiMIg3LYffm3i57z7wQ/view?usp=sharing

Connect Condor on PC to XCSoar on Linux

Leave a reply

Posted 17 January 2024

I recently re-started flying Condor Soaring Simulator after a long absence, and renewed an old interest in using the open-source XCSoar navigation software for external TAT/AAT planning and navigation. XCSoar runs on PC’s, Android phones/tablets, and Linux and is widely used in RL (real-life) and Condor soaring.

I started out by running XCSoar 7.42 on a cheap Android M10 tablet, connected via Bluetooth to Condor running on my Windows 10 PC. Then I created a small AAT task in the default Slovenia scenery and ran a series of test flights to see how XCSoar did. I documented my results in this post and this one.

As a result of my study, I identified some bugs and other issues on the XCSoar forum, and found out that the XCSoar software is actually written in C++ on Linux, and then cross-compiled for the various supported platforms. I’ve done a fair bit of work in C++ and in Linux, so this got me thinking that maybe I could resurrect my old Linux skills and play around with the XCSoar source code a bit. So I dug out my old moth-balled Dell Precision M6700 laptop, loaded up Ubuntu 24.0 LTS, cloned the XCSoar repo, compiled it on my Linux box, and voila! I was in business!

Well, not quite. In order to use Condor on my Windows PC as the test bed for XCSoar software mods, I had to somehow connect Condor’s NMEA output to the NMEA input to the XCSoar program running on my Linux box. This turned out to be non-trivial and involved a lot of web searching, tearing of hair (what little I have left), and gnashing of teeth, but in the words of my Nebraska cousins “We gotter done!”

This post, then is a way of capturing the surprisingly easy (once you know the magic) process of connecting the NMEA output from Condor running on my Win 10 PC to the NMEA input of XCSoar running on my Linux box.

As it turned out, I had already solved (sort of) the first half of the problem, getting NMEA data from Condor out of my Win 10 PC. When I first (re)started playing with XCSoar, I found some posts describing how to connect Condor NMEA ouput to XCSoar running on the same PC, using a nice utility called ‘Virtual Serial Ports Emulator’ (VSPE), and this actually worked very well – except for one tiny little problem; in order to make any adjustments in XCSoar, I had to ALT-TAB out of Condor over to XCSoar, and that meant ‘flying blind’ (literally) while working with XCSoar – not a good thing. I solved this problem by instead route Condor NMEA output to a Bluetooth virtual serial port connected to an Android M10 tablet.

The procedure for connecting Condor on my Win 10 PC to XCSoar running on a Linux box is:

Connect Condor NMEA output to a TCP port on the Win 10 Box
Use ‘socat’ on the Linux box to connect the Win 10 TCP port to XCSoar

Connect Condor NMEA output to a TCP port on the Win 10 Box:

This connection is composed of two legs, both using VSPE; the first one defines a virtual serial port to which Condor NMEA output can be directed. The second one creates a connection between the virtual serial port defined in the first step to a Win 10 TCP port. The screenshot below shows both these legs.

Any unused COM port number may be defined here. Once this is done, connect Condor NMEA output to this port by going to Setup->Options in Condor, checking the ‘Output NMEA’ box, and then selecting the port number defined above, as shown below:

Use ‘socat’ on the Linux box to connect the Win 10 TCP port to XCSoar:

When I first started this adventure, I found references to the Linux ‘socat’ command while Googling for things like “Connect Linux Box to Win 10 PC”. Then I started reading about ‘socat’ in particular, and although I could understand that ‘socat’ connected two ‘things’ (where a ‘thing’ could be a serial port, a TCP port a UDP port, a website, etc), it wasn’t easy to figure out how to use it for my application. Finally I ran across this tutorial, which guided me through a series of example socat applications.

After playing with the examples for a while, I realized I should be able to use the ‘STDIO’ socat example to connect the already existing TCP port on my Win 10 box to STDIO in a Linux console terminal and watch NMEA data flow through. So I fired up Condor on my PC and selected ‘Free Flight’. In the ‘NOTAM’ tab, I selected the ‘Airborne’ start option (I believe this is the default), and then selected ‘Start Flight’. Condor outputs NMEA sentences even when the glider is suspended in mid-air, waiting to start flying, so this is a convenient way to test connections. Then on my Linux box I opened a terminal window and typed in the command shown at the top of the following image:

Linux ‘socat’ command to connect Condor NMEA output to terminal window

When I executed the command, I started getting NMEA sentences from Condor – yay!!

Now that I verified that I can connect to a Linux terminal window from Condor running on my Win10 PC, the remaining piece is to change the destination from a terminal window to XCSoar’s GPS data input and then configure XCSoar to accept GPS data from that port. To do this I executed the following ‘socat’ command on a terminal window in Linux:

frank@frank-Precision-M6700:~$ socat UDP:localhost:4353 TCP4:192.168.1.161:5555

1	frank@frank-Precision-M6700:~$ socat UDP:localhost:4353 TCP4:192.168.1.161:5555

This establishes a connection between a randomly selected UDP port on the Linux box and a TCP port on my PC. The PC TCP port number is the one selected above connecting COM9 to a TCP port, and the UDP port on my Linux box was just a random unused port number.

Then I launched XCSoar on my Linux box and navigated to Config–>Devices, as shown in the following screenshot. Device A is defined as UDP port 4353, the port number selected above.

XCSoar ‘Devices’ page showing connection to Linux UDP port 4353

This establishes the end-to-end connection between Condor running on my Win10 PC to XCSoar running on my Linux box. With this established, XCSoar shows ‘GPS fix’ as the status for Device A, and the main screen shows the glider’s location in the selected scenery, as shown below:

Stay Tuned,

Frank

XCSoar Soaring Computer AAT Task Study, Part II

2 Replies

Posted 14 January 2024

This is the second installment in my study of the XCSoar cross-country race navigation software with respect to its use in AAT/TAT tasks in Condor2. In my last post, I created a small AAT task in Condor and flew it with XCSoar on a Android M10 tablet, connected to my Condor PC via bluetooth. In this installment, I fly the same task, but this time I video’d the entire task and then afterwards picked out screenshots to highlight points of interest during the task.

This next shot illustrates a problem I had right at the start. I used my finger to swipe down (hoping to zoom in or out), but instead it froze the XCSoar app. Had to reboot the M10 tablet and go through some other gyrations to get going again. I sure would hate to have this happen just before task opening on a AAT race in Condor.

XCSoar crashed after the ‘swipe down’ gesture

After getting XCSoar back up and reconnected to Condor, I got going with the task again. Here’s a screenshot showing the situation just before exiting the start cylinder

Just before task start. All the data values look OK

Now just after the start

Just after exiting the start cylinder, with the ‘Task Start’ popup visible

Comments:

The ‘AAT Time’ value has decreased by 4 sec, which seems OK
‘AAT delta time’ seems a bit odd, as it shows I’m going to arrive early by about 1 minute
The AAT Dmax/Dmin and AAT Vmax/Vmin values look consistent. IOW, to consume 45 min covering the min distance of 24.9mi, I need an average speed of 29.9mph (24.9mi / 29.9mph = 0.833hr –> 50min), and for the max dist of 92.9mi I need 111mph (92.9mi/111mph = 0.833hr — 50min). This gives me fair bit of confidence that I have the necessary data to optimize the task.

Just before entering the first turn circle

Comments:

All the numbers still look reasonable here. The ‘AAT Time’ has gone down by about 3.5min, and the arrival is still shown as 1:09min (according the documentation, BLUE indicates arrival will be over by at least 5 minutes).

Now, just after entering the first turn circle,

Comments:

It was nice to see the ‘In sector, arm advance when ready’ popup show, but I wasn’t entirely sure what it meant.
It was also very nice to see that the ‘target’ started following the glider symbol, meaning that I didn’t have to move it manually – yay!
I noted that the ‘AAT Dmin’ value changed from 24.9 to 27.4mi, so that sounds right.

Next, I brought up the Task Status page (after a LOT of fumbling), and got this:

Comments:

I was amazed by how little information on this page was useful. The only values that I found believable were the ‘Assigned Task Time’, the ‘Speed Average’, and ‘Achieved speed’ values.
The ‘Estimated task’ value of 2:47 and the ‘Remaining time’ value of 2:40 makes no sense. Where did they come from?

At about the halfway point something happened (or I did something stupid – AGAIN) and my ‘AAT time and ‘AAT delta time’ values – the very most critical information required for successfully completing an AAT – disappeared, only to return again when I made the the turn toward JAVORJEV. At the time I didn’t notice until well after the fact, so having the entire flight on video really paid dividends – yay! Here’s a short (~ 35 sec) video showing the point at which they disappeared.

watch as the ‘AAT Time’ and ‘AAT delta time’ values disappear, starting at about 22sec

Comments:

The two values that disappeared are the whole reason for using an external navigation device to fly AATs in Condor. After they disappeared, I was basically winging it from then on.
It is possible that the data disappearance is related in some way to the buttons I was pressing around the same time. The first screen tap happens at 13.35sec into the video clip and the ‘AAT delta time’ value starts going GAGA about 10sec later.

In the next screenshot I’m about 3/4 of the way through the first turn, and thinking about turning around. Since I lost my ‘AAT Time’ & ‘AAT delta time’ readouts I’m flying blind on timing:

Comments:

The only information I have to work with are the Dmin/max and Vmin/max values, and some notion of my average speed. I think it’s around 80-90mph, and as long as it is less than 111mph I’m OK to turn at this point.

The next shot shows the ‘Show Target’ page for this turnpoint

Comments:

This page shows a value for ‘V ach’ of 70.8mph, which is almost identical to the value shown for ‘AAT Vmin. Assuming I believe this number, and assuming that value will continue to increase because I’ll be ridge running the rest of the task, I should be OK turning here.
I have no idea what the ‘ETE’ and ‘Delta T’ values mean on this page – they don’t look consistent with the ‘AAT Vmin/max’ and ‘AAT Dmin/max numbers on the main navigation page. I don’t think there’s any way I can make it back 26 minutes and 39 seconds early, even if my glider suddenly acquire orbital velocity.

The next shot shows the same page, but for the JAVORJEV turn circle, just as I’m getting ready to turn in the KURJIV circle

Comments:

Apparently, moving the target position in the KURJIV circle also moves the corresponding one in the JAVORJEV circle – I didn’t expect that. I wonder what happens in a 3, 4, or 5 turn circle AAT – do ALL the targets move in unison?
What does the ‘Optimized’ checkbox do?

The next shot shows the situation just as I made the turn for JAVORJEV. Again I didn’t notice this at the time, but my ‘AAT Time’ and ‘AAT delta time’ datablocks returned from the dead. Here’s a short (20sec) video showing the action. Just from the video, it looks like tapping on the ‘Arm turn’ button also resurrected the AAT info boxes.

However, my joy over getting my AAT datablocks back was short-lived. A short time after making the turn, the datablock info disappeared again – for good. This time there were no button pushes to blame. The following short video shows the action

AAT datablock info disappears for the second- and final – time

The next shot shows me just before exiting the first circle on the way to JAVORJEV

Comments:

The AAT datablocks are still missing
The Target in the JAVORJEV circle is now toward the near side of the circle, so is there some optimization going on in the background?

The next shows my attempt to manually move the JAVORJEV target.

Comments:

The ETE & Delta T values look reasonable, and the implication is that I should be able to use up all the time by moving all the way to the back of the JAVORJEV circle
However, when I manually move the target to the front of the circle, there is almost NO change in the ETE/Dt values, and the small change that shows is in the wrong direction. Moving the target forward like this should make me way earlier, but the numbers show that I’ll be almost 1 minute LATER than I was before. how can this be?

As shown in the next video, I decided to try the ‘Optimized button to see what it did. This radically changed the target location, and the ETE/Dt values. After a few iterations, it looked like the Optimize function was indeed working properly.

Comments:

It takes a while for the optimization to converge. At first, the values for ETE & Dt are WAY off, and then they oscillate back and forth several times before stabilizing on believable numbers.

The last video covers the finish (or NOT-finish, in this case)

Comments:

At the start of this clip, XCSoar is in ‘Final Glide’ mode, but switches back to ‘Cruise’ just before entering the finish circle.
I was expecting a ‘Task Finished’ notification when I crossed into the circle, but didn’t get one. In fact, AFACT, XCSoar never finished this task at all. I’m sure this was an operator error on my part, but I don’t know what I screwed up – bummer!

XCSoar Soaring Computer AAT Task Study, Part I

1 Reply

Posted 14 January 2024

Among the many ‘EXs’ I claim, one of them is ‘EX-glider racing pilot’, and another is ‘EX author of “Cross-Country Soaring with Condor”, a fairly popular book in the soaring community that explains how to use the Condor Soaring Simulator to learn real-life (RL) cross-country (XC) soaring. Now that I don’t fly RL contests any more, I have decided to start flying XC races again in Condor.

Many Condor racing pilots also fly gliders in RL, and use Condor to help them with XC strategies and tactics, and how to best take advantage of the many XC navigation and racing support computer programs available, and Condor supports this by making GPS location data available to users. One of the most popular programs for this purpose is XCSoar (https://xcsoar.org/). In RL XC racing, one of the most popular task types is the Assigned Area Task (AAT) or Turn Area Task (TAT), where the pilot is free to decide where to turn to the next leg of the task, as long as he is within the bounds of an assigned area. Unfortunately, the Condor soaring simulator’s internal navigation computer doesn’t support this type of task, so the pilot must either just guess where to turn, or use some type of external navigation support.

This post is intended to describe my efforts to use XCSoar for Condor racing, and in particular how to use it for AAT/TAT optimization. To do this, I set up a small AAT task in the default Slovenia scenery, as shown in the screenshots below:

Here’s a screenshot of the task in XCSoar:

And the same task in Condor2

After starting the flight, I would pause Condor2 at progressive points along the task and take a photo of the XCSoar app running on an Android tablet, with the idea that after the task was over, I could go back and make some sense of what XCSoar was telling me throughout the flight (Note that due to the loss of GPS data when Condor2 is paused, the green track line jumps way off screen each time, so you have to ignore the impossibly straight part of the ‘breadcrumb trail’).

The following shot was taken just before exiting the start circle at KAMEN

For some reason, XCSoar thinks that almost 3 minutes have elapsed since I started the task, even though I’m still inside the start cylinder and I haven’t gotten any start notifications

OK, it may be that XCSoar started me when I crossed the circle diameter perpendicular to the task line. I note that even though the task diagram shows a cylinder with radius of 2mi, is it possible that XCSoar is still triggering on the default start point type (Start Line, 1.8mi wide)?

The next shot (above) shows the situation just after exiting the start cylinder. Although not shown, I did get a ‘Start’ notification at this point. Note that the ‘AAT Time’ readout jumped backwards from 42:04 in the previous photo to 44:56 in this one. The 44:56 number should be the correct one, as I have just exited from the start cylinder.

Note that the ‘AAT delta time’ value doesn’t make any sense to me. It’s supposed to show ‘Difference between the estimated task time and the AAT minimum time, and if it is colored blue it is supposed to mean that I could turn right there and be assured that I would arrive home so as to be more than 5 minutes over time. But that can’t possibly be true, as I haven’t even gotten into the first turn area yet – WTF?

The above shot shows the situation just after turning around in the first turn area. I really wasn’t getting any good information from the data fields I had displayed – just nothing made any sense, so I guessed the turn point based on the AAT time value, which I took to be the AAT time remaining starting from 45:00 minutes and a wild-assed guess about my achieved speed (I guessed I was doing about 1.5 miles/min). With this guess, and thinking that the remaining distance was between 41.5 and 64.2 miles (assuming I interpreted these values correctly). The ‘AAT delta time’ readout still seems to be nonsense – or maybe it is really true at this point?

The above photo shows the situation after exiting the first turn area and proceeding towards the JAVORJEV turn area. The ‘AAT Time’ value seems like it is behaving rationally, but look at the ‘AAT dT’ value – if true, it should mean I’m going to arrive over 45 minutes LATE, which makes no sense at all. The ‘AAT Dmax’ value is sort of meaningful, and I take it to mean that I have at most 64.2 miles remaining and 27:19 minutes to cover the distance, or right around 120mph. If I believe the ‘AAT Dmin’ number, then that works out to about 90mph if I just touch the last area. The ‘AATDtgt’ now makes sense as well, as the ‘target’ is right on the near edge of the last area, making the ‘Dmin’ and ‘Dtgt’ equal.

The above photo shows the situation about 4 minutes later, just before entering the JAVOR circle. The value of the last three datablocks haven’t changed, which makes sense, but now the ‘AAT dT’ value has changed dramatically again, this time to something a little more reasonable. Now *I think* it is showing me arriving 4:32 early, but that would mean it should be colored RED, and it clearly isn’t – WTF again!

At this point I thought to look at the task Status page, and discovered that this page seemed to think I was going to arrive 4 minutes over time, not under, so now I’m really lost. The help in XCSoar says that the ‘AAT delta time’ data block value will be colored BLUE if the expected arrival time for a turn at the present point will be at least 5 minutes OVER time, and RED if it is going to be UNDER time. However, the actual color of this datablock value is BLACK, and based on the data on the Status page, it looks like BLUE means UNDER time and BLACK means over time.

Also, I saw on this page that my earlier estimate of around 90mph was pretty close to the mark. Armed with this information, and the knowledge that the rest of the task was going to be even faster, I might want to go further into the area than just the minimum.

The above shot is from (I think) the ‘Show Target’ page for the JAVORJEV turn area, after I moved the target from the near edge to well past the center of the area. I expected this page to tell me what the effect of moving the target would have on the total task time, but AFAICT, the only real values are the 49% distance offset value and the Vach value of 93.1mph – the ETE of 2h 52min and the Vrem of 16.4mph are clearly garbage.

The above shot shows the situation about a quarter of the way into the JAVORJEV circle. The ‘AAT time’ value continues to be believable, but now the ‘AAT dT’ value shows me arriving (early?/late?). After seeing the data from the Status page, I was inclined at this point to think that the BLUE coloring meant ‘early’. The AAT Dmax value is unchanged as it should be, but now the AAT Dmin and AAT Dtgt values have both increased. I *think* the AAT Dmin value now shows the total task distance assuming I turn immediately, and the AAT Dtgt value shows it for continuing to the target and then turning. The AAT Time value shows I have about 21 minutes remaining, so I would have to fly well above VNE to arrive just on time If I go to the target, and something like 150 if I were to turn immediately.

The above figure shows the ‘Status’ page on the way back from JAVORJEV to LESCE-BLED. It has the ‘Assigned task time’ correct, but the ‘Estimated Task Time’ and ‘Remaining time’ are clearly not real. The Task distance and remaining distance values look OK though.

The above shot shows the situation as I’m coming out of the JAVORJEV area heading home. The ‘AAT Time’ looks correct, but the ‘AAT dT’ value looks crazy again. Could it be that the value is actually correct, but now showing arrival 49.11 seconds early? Man, that’s a pretty subtle thing to have to figure out while flying close to the ground at Vne! If this is correct, then the number should really be formatted as ‘0:49.11’ instead

The above shot shows the situation just after exiting the JAVROJEV area, and now the datablocks have changed to final glide. Now it looks like I’m going to arrive about 4 minutes early (I’m assuming this is based on my current Vgnd of 115Kt) – bummer!

The last shot before entering the finish circle. Not quite sure how, but I managed to lose some time on the way back, arriving at 44:03 – a little less than 1 minute early. I deliberately left the display scale alone during the approach to the finish cylinder, as I wanted to see if the ‘AutoZoom’ feature would work. It didn’t, but I’m not sure who’s to blame – me or XCSoar. More investigation needs to be done.

Conclusions:

I set up my datablocks for cruise, climb, and FG based mostly on a video I found of a pilot flying an AAT task – I really didn’t have any idea what all the values would really show me. In retrospect, I’m going to have to spend some more time going through the available datablocks and see if another mix makes more sense.
There were some seriously erroneous numbers showing up in some of the datablocks, especially the ‘AAT dTime’ one. It occurs to me that this might have been due to the way I was pausing the flight and then taking a photo of the XCSoar screen. It might be that the values got screwed up when the GPS signal went away. I’ll have to redo this flight without pauses (maybe video the entire flight and then just grab frames, or maybe set up my phone on a tripod so I can just press one button?)
The XCSoar documentation doesn’t match reality in some places, especially with respect to the ‘AAT dTime’ datablock colors. The documentation says RED for early, BLUE for late, nothing about BLACK.

If nothing else, this flight and the subsequent analysis gave me a lot better understanding of XCSoar’s capabilities with respect to AAT task support. I’m a long way from being comfortable with trusting it to feed me good information in real time, but I’m a lot closer than I was before 😊

Stay tuned,

Frank

WallE3 Doesn’t Like Reflective Surfaces

Leave a reply

Posted 08 December 2023

WallE3 went with us last month when we travelled to St. Louis for Thanksgiving with family, and I showed off his autonomous wall following skills. WallE3 actually did great for quite a while – that is until he found himself staring at the side of a floor-mounted wine cooler (wine ‘safe’?). As can be seen in the following short video, WallE3 fell in love with the cooler, and showed his love by repeatedly head-butting it – oops!

After looking at the telemetry data for the run, I saw that WallE3 was measuring much larger front distances – like several hundred centimeters – when it was only a few centimeters from the object. It appears he was backing up to a defined front distance in response to a ‘WALL_OFFSET_DISTANCE_AHEAD’ anomaly, but somehow convinced himself that instead of 20cm from the wall, he was actually more like 100cm away. Of course, since he wanted to be at 30cm (the desired wall offset distance), he drove forward to lessen the distance, thereby bonking into the wall. Then, when he hit the wall, the front LIDAR line of sight geometry changed enough to produce a true measurement of just a few centimeters, which then sent WallE3 running backwards to open up the distance. Lather, rinse, repeat. Here’s an Excel plot of a representative (but not exact – I somehow lost the actual telemetry data for this run).

Representative reflective surface ‘headbutt’ telemetry

As can be seen from the above the measured distance oscillates between the maximum measurable distance of 1000cm to nearly zero. Here’s a photo of the experimental setup that produced the above data.

The ‘reflective surface’ is a piece of glossy black translucent plastic, oriented at an angle to reflect WallE3’s LIDAR beam upward to the ceiling and then the reflected signal from the ceiling back to WallE3.

I’ve been thinking about this issue ever since first seeing it in St. Louis, but hadn’t come up with any firm ideas about how to solve it. I tinkered with the idea of generating two running averages of the front distance when in the ‘MoveToDesiredFrontDistCm()’ function, with the two averages separated in time by some amount. When approaching a normal non-reflective surface, the two averages would closely track each other, but when approaching a reflective surface that produced the above dramatic distance shifts, then the two averages would be dramatically different around the transitions. This could then be detected, and something done to recover. Then last night while falling asleep, I wondered whether or not the STMicro VL53LXX infra-red LIDAR sensors would have the same problem – hmm, maybe not! If that were the case, then I could probably run one in parallel with the Garmin LIDAR unit, and use it instead of the Garmin for all ‘MoveToDesiredFront/RearDistCm()’ calls.

I tried this experiment using the currently installed rear distance sensors by calling ‘MoveToDesiredRearDistCm()’ with the same reflective surface setup as before, as shown in the following photo:

‘MoveToDesiredRearDistCm()’ setup with reflective surface

Here’s an excel plot of the rear distance run:

MoveToRearDistCm() with 30cm target and reflective surface

As can be seen in the above plot, the rear distance run was completely normal, so the VL53LXX infra-red LIDAR sensors don’t have the same problem – at least not with this translucent glossy plastic material.

10 December 2023 Update:

I got to thinking that maybe the reason the rear distance sensor worked so well with the shiny black material is that it could be IR transparent, meaning that while the front sensor (an LED LIDAR system) would see a ‘mirror’, the rear sensor would just see the toolbox. So, I jumped up on Amazon and got a cheap mirror square so I could answer that question. Here is a short video and Excel plot showing a ‘MoveToDesiredFrontDistCm()’ run with the new mirror square.

As can be seen from the video, WallE was perfectly happy to drive right through the mirror, but I had visions of mirror pieces all over the bench, the floor, and me, so I manually prevented that from happening. Here’s an Excel plot showing the same run:

MoveToFrontDist(cm) approaching tilted mirror

As the Excel plot shows, the robot did OK for the first 20 measurements (about 1sec) but immediately thereafter started a steady 200cm, and it stayed that way until I stopped it at about 2sec

Then I tried the same experiment, but this time utilizing the STMicro VL53LXX IR LIDAR sensor on the rear of the robot, as shown in the following short video:

As the video shows, the IR LIDAR behaved pretty much the same as the LED LIDAR (no real surprise, as they are both LIDAR technology, but still a bummer!

Here’s the Excel plot for this run:

As the Excel plot shows, the distance decreased monotonically for the first 30 points (about 1.5sec) but then shot up to 200 due to the mirror. I believe the lower distances after about point 40 (2sec) were due to me interfering with the IR beam.

So, unfortunately my theory about the rear IR sensor doing better with the shiny black plastic ‘mirror’ because it appeared transparent at that wavelength seems to be bolstered, so I now think that using the VL53LXX sensor instead of the Garmin LIDAR LED sensor for ‘MoveToFrontDistCm()’ operations is NOT going to work. Back to the drawing board :(.

23 December 2023 Update:

I’ve been thinking about this problem for a while now, and have not come up with a good answer; WallE3’s perception of the world around it depends entirely on LIDAR-type distance sensors, so if those sensors produce ‘false’ distance reports due to mirror or mirror-ish surfaces, WallE3 has no way to know the ‘true’ distance – bummer!

So, what I decided to do is to simply detect the symptoms of the ‘mirrored surface’ situation, halt the robot and yell for help. The detection algorithm uses the knowledge that when the robot is moving forward toward a ‘normal’ object, the front distance should decrease monotonically with time. Similarly when the robot is moving backwards toward a ‘normal’ object, the rear distance should decrease monotonically with time. Conversely, when approaching a ‘mirror-like’ object, the measured distance tends to be unstable, with distance increasing instead of decreasing.

The detection algorithm calculates a three-point average each time through the action loop, and compares the result to the last time through the loop. If the new average is greater than the old average, a ‘mirrored surface detection’ is declared and the robot calls ‘YellForHelp()’ which stops the motors and emits an audible Morse code ‘SOS’.

Here’s the full code for ‘DoOneMoveToFrontDistCm()’ function that actually moves the robot and checks for ‘mirrored surface’ error conditions

bool DoOneMoveToFrontDistCm(uint16_t offsetCm, float Kp, float Ki, float Kd)
{
  float lastError = 0;
  float lastInput = 0;
  float lastIval = 0;
  float lastDerror = 0;

  uint16_t oldAvgDist = GetAvgFrontDistCm(); //added 12/19/23

  MsecSinceLastDistUpdate = 0; //01/08/22 not using ISR anymore
  MsecSinceLastFrontDistUpdate = 0; //added 10/02/22 to slow front LIDAR update rate

  gl_LastAnomalyCode = ANOMALY_NONE;

  //12/23/23 display ten distances from front dist array before start
  gl_pSerPort->printf("In DoOneMoveToFrontDistCm() at top, displaying 10 front dist entries\n\n");

  gl_pSerPort->printf("idx\tFrontD[idx]\n");
  for (int i = 9; i >= 0; i--)
  {
    gl_pSerPort->printf("%d\t%d\n", FRONT_DIST_ARRAY_SIZE - 1 - i, aFrontDistCM[FRONT_DIST_ARRAY_SIZE-1-i]);
  }
  gl_pSerPort->printf("\n");

  gl_pSerPort->printf("Msec\tFrontD\tTgtD\toldAvgD\tnewAvgD\tErr\tIval\tOutput\tspeed\tFrontVar\tRearVar\n");

  while (abs(gl_FrontCm - offsetCm) > 1 && gl_LastAnomalyCode != ANOMALY_STUCK_AHEAD
    && gl_LastAnomalyCode != ANOMALY_STUCK_BEHIND)
  {
    CheckForUserInput();

    if (MsecSinceLastDistUpdate >= MSEC_PER_DIST_UPDATE)
    {
      MsecSinceLastDistUpdate -= MSEC_PER_DIST_UPDATE;

      UpdateAllEnvironmentParameters(); //10/01/23 this can change anomaly code

      uint16_t newAvgDist = GetAvgFrontDistCm(); //avg of last three front dist readings
      
      OffsetDistOutput = PIDCalcs((double)gl_FrontCm, (float)offsetCm, lastError,
        lastInput, lastIval, lastDerror, Kp, Ki, Kd);

      int16_t speed = (int16_t)OffsetDistOutput;

      //PIDCalcs out can be negative, must handle both signs
      if (speed >= 0)
      {
        speed = (speed > MOTOR_SPEED_QTR) ? MOTOR_SPEED_QTR : speed;
      }
      else //speed < 0
      {
        speed = (speed < -MOTOR_SPEED_QTR) ? -MOTOR_SPEED_QTR : speed;
      }

      gl_pSerPort->printf("%lu\t%d\t%d\t%d\t%d\t%2.1f\t%2.1f\t%2.1f\t%d\t%2.0f\t%2.0f\n",
        millis(), gl_FrontCm, offsetCm, oldAvgDist, newAvgDist, lastError, lastIval, OffsetDistOutput, speed, gl_Frontvar, gl_Rearvar);

      RunBothMotorsBidirectional(-speed, -speed);
      delay(100);

      //11/17/23 added to zero out lastIval anytime Kp*Err > max speed (MOTOR_SPEED_QTR here)
      //if (abs(gl_FrontCm - offsetCm)*OffsetDistKp > MOTOR_SPEED_QTR)
      if (abs(gl_FrontCm - offsetCm) * Kp > MOTOR_SPEED_QTR)
      {
        lastIval = 0;
      }


      //12/19/23 rev to return false if the average distance starts going the wrong way
      //         (i.e. going up if the robot is moving forward, or down if the robot
      //         is moving backwards)
	//12/24/23 Just '>' wasn't enough to prevent false positives, so Added '*1.1' factor
      if ((AreBothMotorsForward() && newAvgDist > oldAvgDist * 1.1) || (AreBothMotorsReversed() && newAvgDist * 1.1 < oldAvgDist)
       && abs(speed) > MOTOR_SPEED_MIN)
      {
        gl_pSerPort->printf("\nIn DoOneMoveToFrontDistCm() in 'mirrored sfc' detection block, displaying 10 front dist entries\n\n");

        //12/23/23 display last 10 distances from front dist array
        gl_pSerPort->printf("idx\tFrontD[idx]\n");
        for (int i = 9; i >= 0; i--)
        {
          gl_pSerPort->printf("%d\t%d\n", FRONT_DIST_ARRAY_SIZE - 1 - i, aFrontDistCM[FRONT_DIST_ARRAY_SIZE - 1 - i]);
        }
        gl_pSerPort->printf("\n");

        return false;
      }

      oldAvgDist = newAvgDist;
    }
  }

  return true;
}

bool DoOneMoveToFrontDistCm(uint16_t offsetCm, float Kp, float Ki, float Kd)

{

float lastError = 0;

float lastInput = 0;

float lastIval = 0;

float lastDerror = 0;

uint16_t oldAvgDist = GetAvgFrontDistCm(); //added 12/19/23

MsecSinceLastDistUpdate = 0; //01/08/22 not using ISR anymore

MsecSinceLastFrontDistUpdate = 0; //added 10/02/22 to slow front LIDAR update rate

gl_LastAnomalyCode = ANOMALY_NONE;

//12/23/23 display ten distances from front dist array before start

gl_pSerPort->printf("In DoOneMoveToFrontDistCm() at top, displaying 10 front dist entries\n\n");

gl_pSerPort->printf("idx\tFrontD[idx]\n");

for (int i = 9; i >= 0; i--)

{

gl_pSerPort->printf("%d\t%d\n", FRONT_DIST_ARRAY_SIZE - 1 - i, aFrontDistCM[FRONT_DIST_ARRAY_SIZE-1-i]);

}

gl_pSerPort->printf("\n");

gl_pSerPort->printf("Msec\tFrontD\tTgtD\toldAvgD\tnewAvgD\tErr\tIval\tOutput\tspeed\tFrontVar\tRearVar\n");

while (abs(gl_FrontCm - offsetCm) > 1 && gl_LastAnomalyCode != ANOMALY_STUCK_AHEAD

&& gl_LastAnomalyCode != ANOMALY_STUCK_BEHIND)

{

CheckForUserInput();

if (MsecSinceLastDistUpdate >= MSEC_PER_DIST_UPDATE)

{

MsecSinceLastDistUpdate -= MSEC_PER_DIST_UPDATE;

UpdateAllEnvironmentParameters(); //10/01/23 this can change anomaly code

uint16_t newAvgDist = GetAvgFrontDistCm(); //avg of last three front dist readings

OffsetDistOutput = PIDCalcs((double)gl_FrontCm, (float)offsetCm, lastError,

lastInput, lastIval, lastDerror, Kp, Ki, Kd);

int16_t speed = (int16_t)OffsetDistOutput;

//PIDCalcs out can be negative, must handle both signs

if (speed >= 0)

{

speed = (speed > MOTOR_SPEED_QTR) ? MOTOR_SPEED_QTR : speed;

}

else //speed < 0

{

speed = (speed < -MOTOR_SPEED_QTR) ? -MOTOR_SPEED_QTR : speed;

}

gl_pSerPort->printf("%lu\t%d\t%d\t%d\t%d\t%2.1f\t%2.1f\t%2.1f\t%d\t%2.0f\t%2.0f\n",

millis(), gl_FrontCm, offsetCm, oldAvgDist, newAvgDist, lastError, lastIval, OffsetDistOutput, speed, gl_Frontvar, gl_Rearvar);

RunBothMotorsBidirectional(-speed, -speed);

delay(100);

//11/17/23 added to zero out lastIval anytime Kp*Err > max speed (MOTOR_SPEED_QTR here)

//if (abs(gl_FrontCm - offsetCm)*OffsetDistKp > MOTOR_SPEED_QTR)

if (abs(gl_FrontCm - offsetCm) * Kp > MOTOR_SPEED_QTR)

{

lastIval = 0;

}

//12/19/23 rev to return false if the average distance starts going the wrong way

// (i.e. going up if the robot is moving forward, or down if the robot

// is moving backwards)

//12/24/23 Just '>' wasn't enough to prevent false positives, so Added '*1.1' factor

if ((AreBothMotorsForward() && newAvgDist > oldAvgDist * 1.1) || (AreBothMotorsReversed() && newAvgDist * 1.1 < oldAvgDist)

&& abs(speed) > MOTOR_SPEED_MIN)

{

gl_pSerPort->printf("\nIn DoOneMoveToFrontDistCm() in 'mirrored sfc' detection block, displaying 10 front dist entries\n\n");

//12/23/23 display last 10 distances from front dist array

gl_pSerPort->printf("idx\tFrontD[idx]\n");

for (int i = 9; i >= 0; i--)

{

gl_pSerPort->printf("%d\t%d\n", FRONT_DIST_ARRAY_SIZE - 1 - i, aFrontDistCM[FRONT_DIST_ARRAY_SIZE - 1 - i]);

}

gl_pSerPort->printf("\n");

return false;

}

oldAvgDist = newAvgDist;

}

return true;

}

02 January 2024 Update:

I wasn’t really happy with my previous attempt at ‘mirrored surface’ detection as it seemed pretty to produce false positives. After thinking about the problem some more, I thought I might be able to use a distance variance calculation as a more robust detection method. The idea is that a normal monotonic increase or decrease in distance measurements would have a pretty low variance, while a distance reversal would generate a much larger value.

So, I ran some simulations in Excel using a 5-point running variance calculation, and the results were encouraging. Then, with the help of my lovely lab assistant, I set up an experiment in my office sandbox to see if I could capture a representative mirrored surface ‘screwup’, as shown below:

And here is an Excel plot showing the results (both the distance and 5-pt variance vertical scales have been truncated to show the smaller scale variations)

Front Distance and 5-pt Variance (truncated vertical scales for better visibility)

As can be see in the video and the Excel plot, the robot undergoes a number of distinct front/back oscillations, but then eventually settles down. It is clear from the plot that the 5-pt variance calculation is a good indicator of a ‘mirrored surface’ condition. Just looking at the plot, it appears that a variance threshold of 40-60 should provide for robust detection without much of a risk of false positives.

One other note about this experiment. To get multiple oscillations as shown in the video and plot, the mirrored surface had to be slanted slightly up toward the ceiling. If the surface was oriented vertically like a normal wall, the robot would often miss the first distance and hit the wall, but then would typically back off to the correct distance. I think this indicates that in the vertical configuration, there is enough backscatter from the floor and/or the robot itself to get a reasonable (if not entirely accurate) LIDAR distance measurement.

07 January 2024 Update:

After playing around some more with this issue, I think the above 5pt variance calculation for ‘mirrored surface’ detection will work, so I revised my current well-tested ‘CalcBruteFrontDistArrayVariance()’ function to take a integer argument denoting the number of elements to use, starting at the end (most recent data) and working backwards.

Then I ran another test in my lab, but this time on a non-mirrored surface, to verify that the 5pt variance calc would still work properly and to settle on a good threshold for ‘mirror’ detection. The Excel plot below shows the results of a run where the robot moved backwards (still using the front LIDAR sensor) to 90cm from the wall.

Running 5-point variance of front distances

As can be seen, the variance starts out in the 10 to 20 range during the initial ‘coarse’ distance movement, but then drops into the 0 to 5 range during the second ‘fine tuning’ movement. Comparing this to the previous ‘mirrored surface’ plot leads me to believe that a threshold of 40 would almost certainly (eventually) detect a ‘mirrored surface’ condition.

24 January 2024 Update:

I added the ‘CalcFrontNPointVar(uint16_t N)’ function to the robot code so I could obtain the front variance using just the last N front distances instead of the entire 100 point array. This turned out to work very well for detecting the ‘Mirrored Surface’ anomaly condition. Then I added ‘ANOMALY_MIRRORED_SFC’ to the list of anomaly codes, and added a ‘case’ block in ‘HandleAnomalousConditions()’ to deal with this condition. The handler function is:

  case ANOMALY_MIRRORED_SFC: //01/21/24 added
    gl_LastAnomalyCode = ANOMALY_NONE; //rev 09/30/23 to clear anomaly flag
    gl_pSerPort->printf("ANOMALY_MIRRORED_SFC case detected with tracking case %s\n", WallTrackStrArray[trackcase]);
    gl_pSerPort->printf("In ANOMALY_MIRRORED_SFC case just before call to RunToDaylightV2() with last anomaly code = %s\n", AnomalyStrArray[gl_LastAnomalyCode]);
    gl_CurTrackingCase = RunToDaylightV2(); //added 10/2/23
    gl_pSerPort->printf("In ANOMALY_MIRRORED_SFC case: RunToDaylightV2 returned = %s\n", WallTrackStrArray[gl_CurTrackingCase]);
    break;

case ANOMALY_MIRRORED_SFC: //01/21/24 added

gl_LastAnomalyCode = ANOMALY_NONE; //rev 09/30/23 to clear anomaly flag

gl_pSerPort->printf("ANOMALY_MIRRORED_SFC case detected with tracking case %s\n", WallTrackStrArray[trackcase]);

gl_pSerPort->printf("In ANOMALY_MIRRORED_SFC case just before call to RunToDaylightV2() with last anomaly code = %s\n", AnomalyStrArray[gl_LastAnomalyCode]);

gl_CurTrackingCase = RunToDaylightV2(); //added 10/2/23

gl_pSerPort->printf("In ANOMALY_MIRRORED_SFC case: RunToDaylightV2 returned = %s\n", WallTrackStrArray[gl_CurTrackingCase]);

break;

At the moment, all it does is call the ‘RunToDaylightV2()’ function, which does a 360º search for the best direction in which to move next. Here’s the telemetry and a short video showing the action.

DoOneMoveToFrontDistCm() returned false with gl_LastAnomalyCode == ANOMALY_MIRRORED_SFC
MoveToDesiredFrontDistCm returning false
	FrontBackMotionTest(): MoveToDesiredFrontDistCm() failed with anomaly code = MIRRORED_SURFACE - Quitting!
In HandleAnomalousConditions(NEITHER) with last anomaly code = MIRRORED_SURFACE
ANOMALY_MIRRORED_SFC case detected with tracking case NEITHER
In ANOMALY_MIRRORED_SFC case just before call to RunToDaylightV2() with last anomaly code = NONE
In RunToDaylightV2()

Idx	Hdg	FrontD	LeftD	RightD	LSteer	RSteer	Avail
0	62.6	380	82.0	246.7	0.7	-1.0	0
1	75.9	526	95.4	318.2	0.2	0.5	1
2	86.4	142	101.3	294.9	0.3	-0.6	0
3	97.9	181	107.4	241.4	0.3	0.1	0
4	109.2	168	89.7	242.8	0.7	-0.7	0
5	119.3	143	102.2	209.9	1.0	1.0	0
6	129.3	123	179.5	162.2	0.1	0.3	0
7	139.8	379	170.0	149.3	0.2	-0.2	0
8	150.4	443	149.5	171.7	0.0	-0.1	0
9	160.8	390	126.1	103.9	0.2	0.7	0
10	170.9	315	143.8	88.6	0.0	-0.1	1
11	-178.9	340	148.7	168.4	-0.1	1.0	0
12	-169.2	227	170.1	86.5	0.2	0.5	1
13	-158.0	249	160.3	94.0	1.0	-1.0	0
14	-148.8	192	130.1	112.6	1.0	0.7	0
15	-138.8	147	127.7	83.6	1.0	0.7	0
16	-128.4	147	189.4	85.8	0.5	-0.4	1
17	-118.2	108	312.0	97.3	1.0	0.2	1
18	-108.6	84	204.5	97.5	1.0	-0.1	1
19	-98.4	137	293.3	101.8	-0.1	-0.1	0
20	-88.5	182	307.3	109.3	-0.6	-0.2	0
21	-78.9	75	242.9	102.3	-0.3	0.6	0
22	-67.9	116	238.6	90.6	1.0	-1.0	0
23	-57.1	79	178.8	167.9	1.0	-0.3	0
24	-47.3	61	151.2	177.9	0.3	0.2	0
25	-37.7	95	152.4	166.7	-0.4	0.2	0
26	-28.2	95	164.2	144.0	-0.3	0.9	0
27	-18.5	98	100.3	147.4	-0.1	-1.0	0
28	-8.6	101	89.1	148.9	0.5	-0.0	0
29	1.1	101	174.3	149.4	-1.0	-0.3	0
30	11.5	69	85.2	172.5	-0.3	-0.2	1
31	21.3	69	87.2	183.7	0.7	1.0	0
32	31.1	182	112.1	138.9	-0.3	0.1	0
33	40.5	170	76.6	137.6	0.7	-1.0	0
34	50.2	162	80.0	248.1	0.4	-1.0	1
35	61.6	362	94.8	352.2	0.1	-0.6	1
In RunToDaylightV2()
RunToDaylightV2(): After REV sort, arrays are

Idx	Hdg	FrontD	LeftD	RightD	LSteer	RSteer	Avail
0	75.9	526	95.4	318.2	0.2	0.5	1
1	150.4	443	149.5	171.7	0.0	-0.1	0
2	160.8	390	126.1	103.9	0.2	0.7	0
3	62.6	380	82.0	246.7	0.7	-1.0	0
4	139.8	379	170.0	149.3	0.2	-0.2	0
5	61.6	362	94.8	352.2	0.1	-0.6	1
6	-178.9	340	148.7	168.4	-0.1	1.0	0
7	170.9	315	143.8	88.6	0.0	-0.1	1
8	-158.0	249	160.3	94.0	1.0	-1.0	0
9	-169.2	227	170.1	86.5	0.2	0.5	1
10	-148.8	192	130.1	112.6	1.0	0.7	0
11	31.1	182	112.1	138.9	-0.3	0.1	0
12	-88.5	182	307.3	109.3	-0.6	-0.2	0
13	97.9	181	107.4	241.4	0.3	0.1	0
14	40.5	170	76.6	137.6	0.7	-1.0	0
15	109.2	168	89.7	242.8	0.7	-0.7	0
16	50.2	162	80.0	248.1	0.4	-1.0	1
17	-128.4	147	189.4	85.8	0.5	-0.4	1
18	-138.8	147	127.7	83.6	1.0	0.7	0
19	119.3	143	102.2	209.9	1.0	1.0	0
20	86.4	142	101.3	294.9	0.3	-0.6	0
21	-98.4	137	293.3	101.8	-0.1	-0.1	0
22	129.3	123	179.5	162.2	0.1	0.3	0
23	-67.9	116	238.6	90.6	1.0	-1.0	0
24	-118.2	108	312.0	97.3	1.0	0.2	1
25	-8.6	101	89.1	148.9	0.5	-0.0	0
26	1.1	101	174.3	149.4	-1.0	-0.3	0
27	-18.5	98	100.3	147.4	-0.1	-1.0	0
28	-37.7	95	152.4	166.7	-0.4	0.2	0
29	-28.2	95	164.2	144.0	-0.3	0.9	0
30	-108.6	84	204.5	97.5	1.0	-0.1	1
31	-57.1	79	178.8	167.9	1.0	-0.3	0
32	-78.9	75	242.9	102.3	-0.3	0.6	0
33	21.3	69	87.2	183.7	0.7	1.0	0
34	11.5	69	85.2	172.5	-0.3	-0.2	1
35	-47.3	61	151.2	177.9	0.3	0.2	0
FrontD	Hdg	LeftD	LSteer	RightD	RSteer
at index = 0, FrontD = 526, bWallTrackAvailable = 1
Trackable Wall found at index = 0
FrontD	Hdg	LeftD	LSteer	RightD	RSteer
526	75.9	95.4	0.2	318.2	0.5
Turning to heading = 75.9
Just after turning to 75.9
FrontD	Hdg	LeftD	LSteer	RightD	RSteer
526	75.9	95.4	0.2	318.2	0.5
In RunToDaylightV2() with trackable wall on left side: trkdir = LEFT
RunToDaylightV2() returning LEFT
In ANOMALY_MIRRORED_SFC case: RunToDaylightV2 returned = LEFT

DoOneMoveToFrontDistCm() returned false with gl_LastAnomalyCode == ANOMALY_MIRRORED_SFC

MoveToDesiredFrontDistCm returning false

FrontBackMotionTest(): MoveToDesiredFrontDistCm() failed with anomaly code = MIRRORED_SURFACE - Quitting!

In HandleAnomalousConditions(NEITHER) with last anomaly code = MIRRORED_SURFACE

ANOMALY_MIRRORED_SFC case detected with tracking case NEITHER

In ANOMALY_MIRRORED_SFC case just before call to RunToDaylightV2() with last anomaly code = NONE

In RunToDaylightV2()

Idx Hdg FrontD LeftD RightD LSteer RSteer Avail

0 62.6 380 82.0 246.7 0.7 -1.0 0

1 75.9 526 95.4 318.2 0.2 0.5 1

2 86.4 142 101.3 294.9 0.3 -0.6 0

3 97.9 181 107.4 241.4 0.3 0.1 0

4 109.2 168 89.7 242.8 0.7 -0.7 0

5 119.3 143 102.2 209.9 1.0 1.0 0

6 129.3 123 179.5 162.2 0.1 0.3 0

7 139.8 379 170.0 149.3 0.2 -0.2 0

8 150.4 443 149.5 171.7 0.0 -0.1 0

9 160.8 390 126.1 103.9 0.2 0.7 0

10 170.9 315 143.8 88.6 0.0 -0.1 1

11 -178.9 340 148.7 168.4 -0.1 1.0 0

12 -169.2 227 170.1 86.5 0.2 0.5 1

13 -158.0 249 160.3 94.0 1.0 -1.0 0

14 -148.8 192 130.1 112.6 1.0 0.7 0

15 -138.8 147 127.7 83.6 1.0 0.7 0

16 -128.4 147 189.4 85.8 0.5 -0.4 1

17 -118.2 108 312.0 97.3 1.0 0.2 1

18 -108.6 84 204.5 97.5 1.0 -0.1 1

19 -98.4 137 293.3 101.8 -0.1 -0.1 0

20 -88.5 182 307.3 109.3 -0.6 -0.2 0

21 -78.9 75 242.9 102.3 -0.3 0.6 0

22 -67.9 116 238.6 90.6 1.0 -1.0 0

23 -57.1 79 178.8 167.9 1.0 -0.3 0

24 -47.3 61 151.2 177.9 0.3 0.2 0

25 -37.7 95 152.4 166.7 -0.4 0.2 0

26 -28.2 95 164.2 144.0 -0.3 0.9 0

27 -18.5 98 100.3 147.4 -0.1 -1.0 0

28 -8.6 101 89.1 148.9 0.5 -0.0 0

29 1.1 101 174.3 149.4 -1.0 -0.3 0

30 11.5 69 85.2 172.5 -0.3 -0.2 1

31 21.3 69 87.2 183.7 0.7 1.0 0

32 31.1 182 112.1 138.9 -0.3 0.1 0

33 40.5 170 76.6 137.6 0.7 -1.0 0

34 50.2 162 80.0 248.1 0.4 -1.0 1

35 61.6 362 94.8 352.2 0.1 -0.6 1

In RunToDaylightV2()

RunToDaylightV2(): After REV sort, arrays are

Idx Hdg FrontD LeftD RightD LSteer RSteer Avail

0 75.9 526 95.4 318.2 0.2 0.5 1

1 150.4 443 149.5 171.7 0.0 -0.1 0

2 160.8 390 126.1 103.9 0.2 0.7 0

3 62.6 380 82.0 246.7 0.7 -1.0 0

4 139.8 379 170.0 149.3 0.2 -0.2 0

5 61.6 362 94.8 352.2 0.1 -0.6 1

6 -178.9 340 148.7 168.4 -0.1 1.0 0

7 170.9 315 143.8 88.6 0.0 -0.1 1

8 -158.0 249 160.3 94.0 1.0 -1.0 0

9 -169.2 227 170.1 86.5 0.2 0.5 1

10 -148.8 192 130.1 112.6 1.0 0.7 0

11 31.1 182 112.1 138.9 -0.3 0.1 0

12 -88.5 182 307.3 109.3 -0.6 -0.2 0

13 97.9 181 107.4 241.4 0.3 0.1 0

14 40.5 170 76.6 137.6 0.7 -1.0 0

15 109.2 168 89.7 242.8 0.7 -0.7 0

16 50.2 162 80.0 248.1 0.4 -1.0 1

17 -128.4 147 189.4 85.8 0.5 -0.4 1

18 -138.8 147 127.7 83.6 1.0 0.7 0

19 119.3 143 102.2 209.9 1.0 1.0 0

20 86.4 142 101.3 294.9 0.3 -0.6 0

21 -98.4 137 293.3 101.8 -0.1 -0.1 0

22 129.3 123 179.5 162.2 0.1 0.3 0

23 -67.9 116 238.6 90.6 1.0 -1.0 0

24 -118.2 108 312.0 97.3 1.0 0.2 1

25 -8.6 101 89.1 148.9 0.5 -0.0 0

26 1.1 101 174.3 149.4 -1.0 -0.3 0

27 -18.5 98 100.3 147.4 -0.1 -1.0 0

28 -37.7 95 152.4 166.7 -0.4 0.2 0

29 -28.2 95 164.2 144.0 -0.3 0.9 0

30 -108.6 84 204.5 97.5 1.0 -0.1 1

31 -57.1 79 178.8 167.9 1.0 -0.3 0

32 -78.9 75 242.9 102.3 -0.3 0.6 0

33 21.3 69 87.2 183.7 0.7 1.0 0

34 11.5 69 85.2 172.5 -0.3 -0.2 1

35 -47.3 61 151.2 177.9 0.3 0.2 0

FrontD Hdg LeftD LSteer RightD RSteer

at index = 0, FrontD = 526, bWallTrackAvailable = 1

Trackable Wall found at index = 0

FrontD Hdg LeftD LSteer RightD RSteer

526 75.9 95.4 0.2 318.2 0.5

Turning to heading = 75.9

Just after turning to 75.9

FrontD Hdg LeftD LSteer RightD RSteer

526 75.9 95.4 0.2 318.2 0.5

In RunToDaylightV2() with trackable wall on left side: trkdir = LEFT

RunToDaylightV2() returning LEFT

In ANOMALY_MIRRORED_SFC case: RunToDaylightV2 returned = LEFT

This experiment led to one of those “Well, DUH!! moments, as the robot’s preferred ‘RunToDaylight()’ heading was right back at the mirrored surface!

After recovering from my ‘face-palm’ moment, I realized I needed to modify the ‘RunToDaylight() function to take heading-start & heading-end parameters to exclude the mirrored surface sector from the ‘RunToDaylight()’ search for an appropriate recovery heading.

28 January 2024 Update:

I modified ‘RunToDaylightV2()’ to take two float parameters denoting the start and ending headings for the search. In the normal non-mirrored surface case, ‘RunToDaylightV2()’ is called with no arguments. The no-argument overload simply calls ‘RunToDaylightV2(startHdg, endHdg)’ with startHdg = endHdg. In the mirrored surface case, the two-parameter version of ‘RunToDaylightV2()’ is called from the ‘ANOMALY_MIRRORED_SFC’ case block of ‘HandleAnomalousConditions()’

Here’s a short video and the telemetry from a test run toward a mirrored surface.

MTFD: at start, tgt = 30cm, curr_dist = 518, PID = 1.00, 0.10, 0.10
In DoOneMoveToFrontDistCm() at top, displaying 10 front dist entries

Msec	FrontD	5ptVar
abs(gl_FrontCm - offsetCm) * Kp = 497.0 -- Zeroing lastIval!
227898	527	186.8
Warning!  Mirrored surface detected in DoOneMoveToFrontDistCm()! Setting anomaly code to ANOMALY_MIRRORED_SFC
idx	FrontD
0	99	527
1	98	527
2	97	504
3	96	504
4	95	538
DoOneMoveToFrontDistCm() returned false with gl_LastAnomalyCode == ANOMALY_MIRRORED_SFC
MoveToDesiredFrontDistCm returning false
	FrontBackMotionTest(): MoveToDesiredFrontDistCm() failed with anomaly code = MIRRORED_SURFACE - Quitting!
In HandleAnomalousConditions(NEITHER) with last anomaly code = MIRRORED_SURFACE
ANOMALY_MIRRORED_SFC case detected with tracking case NEITHER
In ANOMALY_MIRRORED_SFC with IMUHdgValDeg = -0.3
In ANOMALY_MIRRORED_SFC with startdeg = 19.7,  enddeg = -20.3
In RunToDaylightV2(19.7, -20.3)

GetHdgDiff(1, 19.7, -20.3)
GetHdgDiff - Else block: starthdg = 19.7, endhdg = -20.3
GetHdgDiff - Else block: CCW_hdg_diff = 40.0, CW_hdg_diff = 320.0
GetHdgDiff: hdg_diff = 320.0
RunToDaylightV2: spindeg 8.0
RunToDaylightV2: turning 320.0deg CW from 19.7 to -20.3
turning to startHdg 19.7
Idx	Hdg	FrontD	LeftD	RightD	LSteer	RSteer	Avail
0	16.1	162	109.2	283.6	0.1	1.0	0
1	24.6	171	110.7	292.3	0.1	0.3	0
2	34.9	208	115.9	309.9	0.2	0.7	0
3	44.7	195	127.8	264.0	0.3	0.5	0
4	54.3	226	123.2	200.4	0.6	1.0	0
5	65.1	192	198.4	150.5	0.6	0.4	0
6	73.3	159	205.1	136.7	0.1	0.2	0
7	82.9	410	196.8	122.4	-0.1	-0.3	0
8	93.8	607	165.8	54.0	0.1	0.9	0
9	101.8	313	149.6	50.3	0.2	-0.1	1
10	112.6	279	171.9	64.2	-0.1	-1.0	0
11	122.1	331	182.5	87.0	-0.0	-1.0	0
12	132.9	202	202.6	150.5	0.6	1.0	0
13	141.1	199	199.4	72.9	1.0	0.2	1
14	149.1	151	205.0	72.9	1.0	-0.8	0
15	158.3	119	178.5	104.8	1.0	-0.9	0
16	167.7	104	175.2	104.9	1.0	0.8	0
17	176.6	127	205.8	84.2	1.0	-0.3	1
18	-175.5	46	270.5	93.6	0.1	-1.0	0
19	-166.1	69	289.7	108.2	-1.0	-0.1	0
20	-158.2	72	302.1	110.8	-1.0	-0.1	0
21	-150.3	118	297.2	115.7	-1.0	-0.3	0
22	-141.0	165	285.9	127.1	1.0	-0.5	0
23	-131.8	67	193.4	134.6	1.0	-0.4	0
24	-122.6	66	160.3	139.1	1.0	-1.0	0
25	-113.3	108	137.1	204.3	0.7	0.1	0
26	-104.4	102	120.0	205.7	0.3	-0.3	0
27	-95.2	68	118.4	195.8	-0.9	0.6	0
28	-86.1	96	50.9	163.2	-0.6	1.0	0
29	-77.2	104	47.9	172.6	0.1	-0.1	1
30	-68.0	110	57.8	178.1	1.0	0.1	0
31	-58.8	120	80.4	194.0	1.0	0.2	0
32	-49.1	123	147.1	208.7	-0.2	-0.1	0
33	-39.2	103	72.1	214.0	-0.1	0.0	1
34	-29.5	184	69.7	205.2	0.2	0.8	1
35	-21.1	205	101.0	176.7	0.0	0.9	0
RunToDaylightV2(): After REV sort, arrays are

Idx	Hdg	FrontD	LeftD	RightD	LSteer	RSteer	Avail
0	93.8	607	165.8	54.0	0.1	0.9	0
1	82.9	410	196.8	122.4	-0.1	-0.3	0
2	122.1	331	182.5	87.0	-0.0	-1.0	0
3	101.8	313	149.6	50.3	0.2	-0.1	1
4	112.6	279	171.9	64.2	-0.1	-1.0	0
5	54.3	226	123.2	200.4	0.6	1.0	0
6	34.9	208	115.9	309.9	0.2	0.7	0
7	-21.1	205	101.0	176.7	0.0	0.9	0
8	132.9	202	202.6	150.5	0.6	1.0	0
9	141.1	199	199.4	72.9	1.0	0.2	1
10	44.7	195	127.8	264.0	0.3	0.5	0
11	65.1	192	198.4	150.5	0.6	0.4	0
12	-29.5	184	69.7	205.2	0.2	0.8	1
13	24.6	171	110.7	292.3	0.1	0.3	0
14	-141.0	165	285.9	127.1	1.0	-0.5	0
15	16.1	162	109.2	283.6	0.1	1.0	0
16	73.3	159	205.1	136.7	0.1	0.2	0
17	149.1	151	205.0	72.9	1.0	-0.8	0
18	176.6	127	205.8	84.2	1.0	-0.3	1
19	-49.1	123	147.1	208.7	-0.2	-0.1	0
20	-58.8	120	80.4	194.0	1.0	0.2	0
21	158.3	119	178.5	104.8	1.0	-0.9	0
22	-150.3	118	297.2	115.7	-1.0	-0.3	0
23	-68.0	110	57.8	178.1	1.0	0.1	0
24	-113.3	108	137.1	204.3	0.7	0.1	0
25	167.7	104	175.2	104.9	1.0	0.8	0
26	-77.2	104	47.9	172.6	0.1	-0.1	1
27	-39.2	103	72.1	214.0	-0.1	0.0	1
28	-104.4	102	120.0	205.7	0.3	-0.3	0
29	-86.1	96	50.9	163.2	-0.6	1.0	0
30	-158.2	72	302.1	110.8	-1.0	-0.1	0
31	-166.1	69	289.7	108.2	-1.0	-0.1	0
32	-95.2	68	118.4	195.8	-0.9	0.6	0
33	-131.8	67	193.4	134.6	1.0	-0.4	0
34	-122.6	66	160.3	139.1	1.0	-1.0	0
35	-175.5	46	270.5	93.6	0.1	-1.0	0
FrontD	Hdg	LeftD	LSteer	RightD	RSteer
at index = 0, FrontD = 607, bWallTrackAvailable = 0
at index = 1, FrontD = 410, bWallTrackAvailable = 0
at index = 2, FrontD = 331, bWallTrackAvailable = 0
at index = 3, FrontD = 313, bWallTrackAvailable = 1
Trackable Wall found at index = 3
FrontD	Hdg	LeftD	LSteer	RightD	RSteer
313	101.8	149.6	0.2	50.3	-0.1
Turning to heading = 101.8
Just after turning to 101.8
FrontD	Hdg	LeftD	LSteer	RightD	RSteer
313	101.8	149.6	0.2	50.3	-0.1
In RunToDaylightV2() with trackable wall on right side: trkdir = RIGHT
RunToDaylightV2() returning RIGHT
In ANOMALY_MIRRORED_SFC case: RunToDaylightV2 returned = RIGHT

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

MTFD: at start, tgt = 30cm, curr_dist = 518, PID = 1.00, 0.10, 0.10

In DoOneMoveToFrontDistCm() at top, displaying 10 front dist entries

Msec FrontD 5ptVar

abs(gl_FrontCm - offsetCm) * Kp = 497.0 -- Zeroing lastIval!

227898 527 186.8

Warning! Mirrored surface detected in DoOneMoveToFrontDistCm()! Setting anomaly code to ANOMALY_MIRRORED_SFC

idx FrontD

0 99 527

1 98 527

2 97 504

3 96 504

4 95 538

DoOneMoveToFrontDistCm() returned false with gl_LastAnomalyCode == ANOMALY_MIRRORED_SFC

MoveToDesiredFrontDistCm returning false

FrontBackMotionTest(): MoveToDesiredFrontDistCm() failed with anomaly code = MIRRORED_SURFACE - Quitting!

In HandleAnomalousConditions(NEITHER) with last anomaly code = MIRRORED_SURFACE

ANOMALY_MIRRORED_SFC case detected with tracking case NEITHER

In ANOMALY_MIRRORED_SFC with IMUHdgValDeg = -0.3

In ANOMALY_MIRRORED_SFC with startdeg = 19.7, enddeg = -20.3

In RunToDaylightV2(19.7, -20.3)

GetHdgDiff(1, 19.7, -20.3)

GetHdgDiff - Else block: starthdg = 19.7, endhdg = -20.3

GetHdgDiff - Else block: CCW_hdg_diff = 40.0, CW_hdg_diff = 320.0

GetHdgDiff: hdg_diff = 320.0

RunToDaylightV2: spindeg 8.0

RunToDaylightV2: turning 320.0deg CW from 19.7 to -20.3

turning to startHdg 19.7

Idx Hdg FrontD LeftD RightD LSteer RSteer Avail

0 16.1 162 109.2 283.6 0.1 1.0 0

1 24.6 171 110.7 292.3 0.1 0.3 0

2 34.9 208 115.9 309.9 0.2 0.7 0

3 44.7 195 127.8 264.0 0.3 0.5 0

4 54.3 226 123.2 200.4 0.6 1.0 0

5 65.1 192 198.4 150.5 0.6 0.4 0

6 73.3 159 205.1 136.7 0.1 0.2 0

7 82.9 410 196.8 122.4 -0.1 -0.3 0

8 93.8 607 165.8 54.0 0.1 0.9 0

9 101.8 313 149.6 50.3 0.2 -0.1 1

10 112.6 279 171.9 64.2 -0.1 -1.0 0

11 122.1 331 182.5 87.0 -0.0 -1.0 0

12 132.9 202 202.6 150.5 0.6 1.0 0

13 141.1 199 199.4 72.9 1.0 0.2 1

14 149.1 151 205.0 72.9 1.0 -0.8 0

15 158.3 119 178.5 104.8 1.0 -0.9 0

16 167.7 104 175.2 104.9 1.0 0.8 0

17 176.6 127 205.8 84.2 1.0 -0.3 1

18 -175.5 46 270.5 93.6 0.1 -1.0 0

19 -166.1 69 289.7 108.2 -1.0 -0.1 0

20 -158.2 72 302.1 110.8 -1.0 -0.1 0

21 -150.3 118 297.2 115.7 -1.0 -0.3 0

22 -141.0 165 285.9 127.1 1.0 -0.5 0

23 -131.8 67 193.4 134.6 1.0 -0.4 0

24 -122.6 66 160.3 139.1 1.0 -1.0 0

25 -113.3 108 137.1 204.3 0.7 0.1 0

26 -104.4 102 120.0 205.7 0.3 -0.3 0

27 -95.2 68 118.4 195.8 -0.9 0.6 0

28 -86.1 96 50.9 163.2 -0.6 1.0 0

29 -77.2 104 47.9 172.6 0.1 -0.1 1

30 -68.0 110 57.8 178.1 1.0 0.1 0

31 -58.8 120 80.4 194.0 1.0 0.2 0

32 -49.1 123 147.1 208.7 -0.2 -0.1 0

33 -39.2 103 72.1 214.0 -0.1 0.0 1

34 -29.5 184 69.7 205.2 0.2 0.8 1

35 -21.1 205 101.0 176.7 0.0 0.9 0

RunToDaylightV2(): After REV sort, arrays are

Idx Hdg FrontD LeftD RightD LSteer RSteer Avail

0 93.8 607 165.8 54.0 0.1 0.9 0

1 82.9 410 196.8 122.4 -0.1 -0.3 0

2 122.1 331 182.5 87.0 -0.0 -1.0 0

3 101.8 313 149.6 50.3 0.2 -0.1 1

4 112.6 279 171.9 64.2 -0.1 -1.0 0

5 54.3 226 123.2 200.4 0.6 1.0 0

6 34.9 208 115.9 309.9 0.2 0.7 0

7 -21.1 205 101.0 176.7 0.0 0.9 0

8 132.9 202 202.6 150.5 0.6 1.0 0

9 141.1 199 199.4 72.9 1.0 0.2 1

10 44.7 195 127.8 264.0 0.3 0.5 0

11 65.1 192 198.4 150.5 0.6 0.4 0

12 -29.5 184 69.7 205.2 0.2 0.8 1

13 24.6 171 110.7 292.3 0.1 0.3 0

14 -141.0 165 285.9 127.1 1.0 -0.5 0

15 16.1 162 109.2 283.6 0.1 1.0 0

16 73.3 159 205.1 136.7 0.1 0.2 0

17 149.1 151 205.0 72.9 1.0 -0.8 0

18 176.6 127 205.8 84.2 1.0 -0.3 1

19 -49.1 123 147.1 208.7 -0.2 -0.1 0

20 -58.8 120 80.4 194.0 1.0 0.2 0

21 158.3 119 178.5 104.8 1.0 -0.9 0

22 -150.3 118 297.2 115.7 -1.0 -0.3 0

23 -68.0 110 57.8 178.1 1.0 0.1 0

24 -113.3 108 137.1 204.3 0.7 0.1 0

25 167.7 104 175.2 104.9 1.0 0.8 0

26 -77.2 104 47.9 172.6 0.1 -0.1 1

27 -39.2 103 72.1 214.0 -0.1 0.0 1

28 -104.4 102 120.0 205.7 0.3 -0.3 0

29 -86.1 96 50.9 163.2 -0.6 1.0 0

30 -158.2 72 302.1 110.8 -1.0 -0.1 0

31 -166.1 69 289.7 108.2 -1.0 -0.1 0

32 -95.2 68 118.4 195.8 -0.9 0.6 0

33 -131.8 67 193.4 134.6 1.0 -0.4 0

34 -122.6 66 160.3 139.1 1.0 -1.0 0

35 -175.5 46 270.5 93.6 0.1 -1.0 0

FrontD Hdg LeftD LSteer RightD RSteer

at index = 0, FrontD = 607, bWallTrackAvailable = 0

at index = 1, FrontD = 410, bWallTrackAvailable = 0

at index = 2, FrontD = 331, bWallTrackAvailable = 0

at index = 3, FrontD = 313, bWallTrackAvailable = 1

Trackable Wall found at index = 3

FrontD Hdg LeftD LSteer RightD RSteer

313 101.8 149.6 0.2 50.3 -0.1

Turning to heading = 101.8

Just after turning to 101.8

FrontD Hdg LeftD LSteer RightD RSteer

313 101.8 149.6 0.2 50.3 -0.1

In RunToDaylightV2() with trackable wall on right side: trkdir = RIGHT

RunToDaylightV2() returning RIGHT

In ANOMALY_MIRRORED_SFC case: RunToDaylightV2 returned = RIGHT

Stay tuned!

Frank