June 9, 2010 at 6:33 am #123
I’m writing here because it’s the third time that I have experienced the problem that I’m going to describe. I want to share it to understand whether is a my problem or there’s something to improve in FS. </p>
<p>What I’m talking about is the track analysis of pilots that land out but leave GPS switched on while coming back to take off. It this situation it seems that FS doesn’t understand that pilot has landed and analyze all points in the track, even the ones after the landing point. </p>
<p>I’m the scorekeeper of a regional championship and in the last task I had a pilot whom landed out 2 km away from the ES turnpoint but left the GPS switched on until he entered by car in the ES turnpoint. When I scored the task, that pilot was scored as GOAL because in the automatic track analysis FS didn’t understand that he had landed. </p>
<p>I can’t attach files in this forum, but if you need I can send it to you via email. </p>
<p>I think that it should be implemented an automatic analysis that suggests the score keeper where the pilot probably landed. A possible criterion should be when in the tracks are found more that 15 or 20 seconds with speed over ground equal to 0 km/h at the same altitude. </p>
<p>Does other score keeper had the same problem?</p>
</p>June 10, 2010 at 1:36 pm #489
We had the same problem at last Austrian Championship in Hanggliding.
The pilot landed short before ES (was not identical with goal, so no witnesses there)
During moving his glider out of the landing meadow for derigging he entered ES-cylinder and therefore got, according to GAP 2002, speed points with 20% penalty scored.
There were more than 10 tracklog points with speed lower than 5 km/h until he reached ES, while speed of the trackpoints before landing was 50 down to 35 km/h.
We found this only incidentally.
Until then we relied on the tracklog speed filter, which was on.
Does the filter only work before start?
How does it work?
It is hard to define a reliable criterion for landing in a GPS-track.
Several seconds with low ground speed in same hight can also mean that one soars on one spot. On the other hand touch and go will hardly be detected, if the pilot is a good sprinter.
So in this case the sudden speed drop would be a better indicator.
(how did CompeGPS handle this? – there it worked, as far as I experienced it)
Cheaters (intentionally or not) will only be found if you check the tracklogs carefully at landings. (There are cases reported where a pilot prevented thermalling when running circles on the ground an then drove to goal by car, always taking care to keep proper speed 😉 )
At least it would be helpful to be able to select points of the track and declare them as landing point (context menue, right mouse click..)
AndiNovember 21, 2011 at 1:57 pm #1116
Hello, I did not believe it WAS NECESSARY to Comment on this issue.
I trust the honesty of the drivers, Many of Them ….. friends Now I can not trust.
Now, After a classification with 100 pilots, Where Attempting to pilot a flight to fraud, walk 250 meters to mark ESS … I need to urgently Solve this defect ..
I prefer to cancel HAVING Several pilot landed false alarms, Before confirming a track from a driver Who has Walked.
100 tracks, you imagine checking point to point, competition in 7 days?
Sorry my bad english….
En la ultima competicion, detecte un piloto caminando 250 metros para validar ESS, algo muy dificil de detectar si no verifica punto x punto un track.. Creo que el FS deberia informar con una alarma las posibles zonas de aterrizaje.
velocidad menor a 10 km/h durante 30 segundos, sin variacion de altura mayor a 3 metros..
luego el encargado de clasificaciones podria validar el punto de aterrizaje real si fuera necesario.
Pero necesitamos que el software nos informe de algun modo estas areas con posibles aterrizaje…November 21, 2011 at 8:49 pm #1117
Rafael I agree with you: it’s better to have many false alarm than don’t find the only one “walking pilot”. I wrote this post bacause I know that sometime this can happend and it’s not fast to find those pilot during a 7 day competition…May 14, 2012 at 1:07 pm #1349
Hello, I am scorer of the Brazilian championship, as well as others. I always check the beginning and end of the track, eliminating these repetitions possible pilot landed or stopped and then moving around.
In the final stage of the Brazilian, a pilot landed 200 meters from the goal line in a small mountain, and kept running to try to reach the nearest goal, but witnesses and more analysis of track, he was warned.
Constantly we have this kind of action from the pilot, but when the scorer always warned that the competitor, with several witnesses that he did wrong, not immediately switch off the GPS, they start to get smarter and stop to deceive.
Some GPS do not do this kind of record.
The Option of alarm analysis of track already be of great value, because there does not need to check one-to-one.
Another tournament that had 150 pilots worked in three days to review, give gave much time work and analysis.
Scorer Brazilian Cup
firstname.lastname@example.orgNovember 11, 2012 at 2:47 pm #1389
The way “walking pilot” detection works currently in FS: If the average speed over the last five track points drops below 3.6 km/h, it is assumed that the pilot has stopped flying, and track evaluation ends there. All of you who have seen problems with walking pilots not being detected, could you please send me the track log and if possible also the corresponding FSDB file?
Chairman of CIVL’s Software Working GroupJanuary 16, 2013 at 4:28 pm #2434
I’d like to resurrect this thread, since it has become an issue again in some competitions. Let’s figure out what’s going on, and how to design a good solution.
Rafa Lopez sent me the track of the “flight” he mentions above. Here is what I found:
The pilot landed at 20:41:46 (all times UTC)
Less than a minute later, at 20:42:42, he started running towards the ESS cylinder, which was at that time 270m away.
He reached the cylinder at 20:45:01, turned around, walked a couple more steps until 20:45:26, then turned off the GPS.
So in total he ran 270m in 2:19, giving him an average speed of 1.94 m/s or 6.99 km/h.
Between landing and entering ESS, he spent 3:15 on the ground, covered 270m, giving him an average speed of 1.23 m/s or 4.42 km/h
So far the facts. Now why did FS not detect that? Simply because the offending pilot was “too fast”:
FS uses a sliding 4-minutes-window across the track, and calculates the average speed for each window. Once this speed drops below 1 m/s (3.6 km/h), the assumption is that the pilot has landed and the remainder of the track is no longer considered.
During the last 4 minutes of the track we’re looking at here, the average speed was 1.90 m/s (6.84 km/h). So no landing is detected, the entire track is used for scoring.
From the comments in the code I can see that originally, the intention was to make the threshold at 1.5 m/s or 5.4 km/h. For some reason this was later changed to 1 m/s (3.6 km/h) – probably because some slow-flying paragliders were wrongly considered landed.
We could fine-tune this by increasing the threshold, and decreasing the window-size, to say 3 minutes and 1.25 m/s, but there is always a risk of false positives, slow-flying pilots who are considered landed.
Does anybody have an idea how else to do the landing-detection? Include altitude in the mix? Again the danger is that a soaring pilot, pinned to a cliff, may be wrongly considered as landed.
On a slightly bigger scale, I feel that the score keeper must be given the option to overrule a detected landing and tell FS to use the rest of the track as well. That will require some bigger changes, but should make the whole process easier.
Rafa’s scenario can be avoided by not giving 80% of time and arrival points to pilots who make ESS but not goal. In FAI Category 1 Paragliding comps, as well as the PWC, you always must reach goal to get any time (and arrival) points. Somebody running 270m to cross the goal line would certainly be more obvious than doing the same for a 2km ESS.
Looking forward to your input
JoergJanuary 17, 2013 at 12:44 am #2435
“On a slightly bigger scale, I feel that the score keeper must be given the option to overrule a detected landing and tell FS to use the rest of the track as well. That will require some bigger changes, but should make the whole process easier.”
This is already possible, just put the distance flown manually and take the entire track.
Alarm only landed on the task screen when the speed is less than 3km for 1 or 2 minutes
Another option is to put in FS Flight tracks with color and an alarm that possible landing points. The scorekeeper will decide whether or not to validate the flight.
But it is first necessary to review 80 or more tracks x each task.January 21, 2013 at 2:32 am #2743
I’ve just finished scoring the Corryong Cup 2013. The last time I scored this competition, I followed the previous scorers and used SeeYou. Now, with my experience with FS, I used FS to score the comp. For the most part, FS was up to the task, however we found a couple of glitches. Both seem to be related to this issue.
1) Spot the Walking ( or driving ) pilot. – “Task 3 (2)” pilot Adam Jones – id 189
I found at least one tracklog where the track which was downloaded with GPS Dump was had the correct furthest point along the track and the correct landing place marked in “FS Flight” however, the distance flown which was given to the pilot in FS was much more. Upon further analysing the track in Google Earth, I could see that after landing, the pilot had not turned off their GPS, and were then retrieved by their driver and driven further along the task to retrieve a team mate who flew further. It appears that the distance that FS awarded them was to the furthest point along their track AFTER their landing. It seems that FS Flight is correctly calculating the distance, but that FS is not.
I have since discovered that the current version of FS – 1.3.4 – exhibits the behaviour I described above, but that when I load the .fsdb up in my development environment with the current version of the source code, it correctly identifies the landing.
As I couldn’t get FS to score the track to his actual furthers point along the track, I estimated his distance and manually scored him. The measure distance between two lat/lon tools in FS Flight is useful for this, but only to a limited extent. I can see no way in FS to accurately work out how far along the task route any particular point is. The track point for Adam happens to be very close to the course line, so it was good enough to use, but other similar issues occurred where the track was not close to the course line. At the top of the left panel in FS Flight is a row containing data related to where the mouse currently sits over the visual representation of the tracklog. This contains the track point data. It would be nice to also show the Lat/Lon for the point ALONG the course line perpendicular to the track selected point. It would be handy to visually show this as well by extending a dotted line from the trackpoint to the course line which would intersect the course line at right angles. If we also include the distance along the course to that point, the user would be able to very easily identify the correct distance to manually score the pilot when FS for one reason or another does not do so. – Even better would be the ability to right click on a track point and be given the option to “Score the pilot to THIS point along the course.”
2) I’ve also noticed that on some tracklogs, FS incorrectly assumes a landing when no such landing has occurred. As FS Flight only shows the track up to the point in which FS Flight calculates the landing place, and does not show points AFTER that landing place, the scorer needs to open the tracklog in another application ( Google Earth or SeeYou for example ) to be able to calculate the distance and times to manually score the pilot. To help the scorer manually score a pilots track, it would be nice to have an option in FS Flight to show the entire track, even including points before a detected launch, and after a detected landing, and even outside the task time window. With these track points shown, and with the measurement tools suggested above, I don’t think that a scorer will need to use anything other than FS to manually score a track which for some reason was not correctly scored by FS.
You must be logged in to reply to this topic.