Help us with this petition for security on anti-collision systems

Very interesting view, Andy!
But, can a Flarm cpu do this? My doubts come from the fact that the
calculation engine in my flight software takes about 25ms every second on a
400mhz ARM cpu. For flight path estimation, some of those calculations would
be necessary too. A very conservative estimation would be 20% of 25ms,
needed by flarm too. So let's say 5ms, but on 8mhz (50 times slower). That
means 250ms.
The available time slot is 1000ms but it cannot be used entirely, because
the data must be transmitted and received within the timeslot itself.
So using the same thumb rule, I would say 250ms out of 750ms are used for
calc, leaving 500ms for the rest.
The "rest" being dealing with the gps, receiving data from the radio,
processing data and compare for each data the collisions. outputting NMEA to
serial port if needed, recording the flight, managing the leds etc.
And we must consider that the ATmel 128 cpu has no floating point, no math,
and even a sin() and cos() function are made from scratch in C language by
the cross compiler.
This is why, although "thumb ruled", I cannot thing that a cone like yours
is in use, but something much more simpler.
Because there is no time to do things like you say, I believe.
What do you think?

"Andy Blackburn" wrote in message
...

I don't know exactly how the Flarm guys do their math to project a flight
path, but I think of it as a cone with it's point at the glider and it's
wide end 15 seconds ahead of the glider. The cone can be straight or curved
and the cone's centerline defines the overall curvature, which can be
defined by a number of factors, but for simplicity's sake lets say that it
is a circle based on the last three datapoints (it could be any kind of
mathematical curve). If the glider is flying straight, the circle has an
infinite radius (a straight line). If the glider is thermaling the circle
has a radius of a few hundred feet.

Now imagine the pilot of the glider has decided that instead of thermalling
to the left he wants to thermal to the right because he thinks the core is
not at the center of the left hand turn but rather at the center of the new
right hand turn he wants to establish.. He puts the stick over to the right
and the glider starts to roll. The bank shallows, passes through wings level
and eventually settles in a steady right hand turn. From start to finish it
takes around 10 seconds. What happens to the projection of his future flight
path? As his circle widens the projection widens until it is straight out in
front of him and then starts curving to the right until it is a cone curved
to the right in a circular arc with a radius of several hundred feet
(whatever his turn radius is.

It is true that because no instrument can read the pilot's mind you cannot
predict that the point 15 second ahead of the glider will flip from being on
a left hand circular arc to a right hand circular arc, but that projected
point and any given moment is the BEST ESTIMATE of where the glider is
headed and as the wide end of the cone arcs through straight ahead the edge
of the cone will intersect any paths on that new circle. It won't be a 15
second warning, more like 7-10 seconds depending on how much the cone
widens. There is no algorithm or system that will read the mind of the pilot
before he even knows his mind, but the Flarm approach certain warns you of a
glider heading your way as soon as it is in fact heading your way - that's
what we want it to do.

You can be more conservative and set the warning to alert for any glider
that is close enough to hit you based on the maximum possible closure rate -
assuming both pilots turn aggressively to go exactly head to head. This
would require a warning for any glider within a mile to a mile and a half
(assuming 300 knot closure rate). Also assume the other glider is in a 25
knot thermal or 25 knots of sink and you are in the opposite to take a worst
case scenario. Anyone plus or minus about 1200 feet and within a mile to a
mile and a half distance should generate a warning. That is the warning
volume to be 99.9999% sure that no matter what you do or the other pilot
does you will be warned at least 15 seconds from possible impact. Oh, except
if the higher glider has speed brakes out, then you need more like a +/-
2500 foot warning height band.

Without some assumption on projected path, collision warning turns into a
traffic alert system if you want 100% certain that no matter what either
pilot does you will be warned at least 15 seconds ahead of time. Getting
continuous warnings on dozens of glider all the time defeat the purpose I'd
like to see served in a collision warning system - that it only warns you
when a collision is a real possibility, not a 0.0001% chance that I would
get warned about a few seconds later anyway if the worst case circumstances
in terms of pilot maneuvering actually came to pass.

If that's what this has been about, it is kind of silly and academic. You
should only give warning on things that are pretty likely to happen - or
like the boy who cried wolf, people will stop listening to you.

9B

On Sun, 31 May 2015 16:18:10 +0200, pcool wrote:

Very interesting view, Andy!
But, can a Flarm cpu do this? My doubts come from the fact that the
calculation engine in my flight software takes about 25ms every second
on a 400mhz ARM cpu. For flight path estimation, some of those
calculations would be necessary too. A very conservative estimation
would be 20% of 25ms, needed by flarm too. So let's say 5ms, but on 8mhz
(50 times slower). That means 250ms.
The available time slot is 1000ms but it cannot be used entirely,
because the data must be transmitted and received within the timeslot
itself.
So using the same thumb rule, I would say 250ms out of 750ms are used
for calc, leaving 500ms for the rest.
The "rest" being dealing with the gps, receiving data from the radio,
processing data and compare for each data the collisions. outputting
NMEA to serial port if needed, recording the flight, managing the leds
etc.
And we must consider that the ATmel 128 cpu has no floating point, no
math, and even a sin() and cos() function are made from scratch in C
language by the cross compiler.
This is why, although "thumb ruled", I cannot thing that a cone like
yours is in use, but something much more simpler.
Because there is no time to do things like you say, I believe.
What do you think?

"Andy Blackburn" wrote in message
...

I don't know exactly how the Flarm guys do their math to project a
flight path, but I think of it as a cone with it's point at the glider
and it's wide end 15 seconds ahead of the glider. The cone can be
straight or curved and the cone's centerline defines the overall
curvature, which can be defined by a number of factors, but for
simplicity's sake lets say that it is a circle based on the last three
datapoints (it could be any kind of mathematical curve). If the glider
is flying straight, the circle has an infinite radius (a straight line).
If the glider is thermaling the circle has a radius of a few hundred
feet.

Now imagine the pilot of the glider has decided that instead of
thermalling to the left he wants to thermal to the right because he
thinks the core is not at the center of the left hand turn but rather at
the center of the new right hand turn he wants to establish.. He puts
the stick over to the right and the glider starts to roll. The bank
shallows, passes through wings level and eventually settles in a steady
right hand turn. From start to finish it takes around 10 seconds. What
happens to the projection of his future flight path? As his circle
widens the projection widens until it is straight out in front of him
and then starts curving to the right until it is a cone curved to the
right in a circular arc with a radius of several hundred feet (whatever
his turn radius is.

It is true that because no instrument can read the pilot's mind you
cannot predict that the point 15 second ahead of the glider will flip
from being on a left hand circular arc to a right hand circular arc, but
that projected point and any given moment is the BEST ESTIMATE of where
the glider is headed and as the wide end of the cone arcs through
straight ahead the edge of the cone will intersect any paths on that new
circle. It won't be a 15 second warning, more like 7-10 seconds
depending on how much the cone widens. There is no algorithm or system
that will read the mind of the pilot before he even knows his mind, but
the Flarm approach certain warns you of a glider heading your way as
soon as it is in fact heading your way - that's what we want it to do.

You can be more conservative and set the warning to alert for any glider
that is close enough to hit you based on the maximum possible closure
rate -
assuming both pilots turn aggressively to go exactly head to head. This
would require a warning for any glider within a mile to a mile and a
half (assuming 300 knot closure rate). Also assume the other glider is
in a 25 knot thermal or 25 knots of sink and you are in the opposite to
take a worst case scenario. Anyone plus or minus about 1200 feet and
within a mile to a mile and a half distance should generate a warning.
That is the warning volume to be 99.9999% sure that no matter what you
do or the other pilot does you will be warned at least 15 seconds from
possible impact. Oh, except if the higher glider has speed brakes out,
then you need more like a +/- 2500 foot warning height band.

Without some assumption on projected path, collision warning turns into
a traffic alert system if you want 100% certain that no matter what
either pilot does you will be warned at least 15 seconds ahead of time.
Getting continuous warnings on dozens of glider all the time defeat the
purpose I'd like to see served in a collision warning system - that it
only warns you when a collision is a real possibility, not a 0.0001%
chance that I would get warned about a few seconds later anyway if the
worst case circumstances in terms of pilot maneuvering actually came to
pass.

If that's what this has been about, it is kind of silly and academic.
You should only give warning on things that are pretty likely to happen
- or like the boy who cried wolf, people will stop listening to you.

I see what you're getting at, but I know what I've done using a Parallax
BS2 STAMP that was running a 'compiled', i.e. probably P-coded, integer
BASIC to do some simple time-critical calculations while driving an RC
servo and scanning a pair of switches.

I also remember just what we managed to get a smallish mainframe to do
back in the early 70s with its 1.5 uS (666 Khz) cycle time.

I don't know the Atmel at all, but if it can use interrupts for i/o
handling rather than dimly waiting for each byte to dribble in from its
serial ports then the position might look a bit better than you seem to
think it is.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

I bet you could do a good enough job without a lot of trig. You need position, velocity vector and some measure of curvature. You could probably do the horizontal and vertical parts separately. The cone part is just relaxing the distance that constitutes a collision conflict progressively with each increase in projection time/distance.

Of course the proof is in how FLARM behaves so they are doing something like what I described.

How the calculations fit in processing time available is a question for the likes of Dave Nadler who understand these issues intimately.

9B

On Sunday, May 31, 2015 at 7:32:20 PM UTC+2, Andy Blackburn wrote:
I bet you could do a good enough job without a lot of trig. You need position, velocity vector and some measure of curvature. You could probably do the horizontal and vertical parts separately. The cone part is just relaxing the distance that constitutes a collision conflict progressively with each increase in projection time/distance.

Of course the proof is in how FLARM behaves so they are doing something like what I described.

How the calculations fit in processing time available is a question for the likes of Dave Nadler who understand these issues intimately.

9B

On the 'Classic' platform, we do a lot of the calculations in (our) fixed-point integers, plus use lookup tables and other tricks. A bit harder to code and test, but *very* fast on the AVR processor.

Urs
FLARM