search

openETCS / modeling

WP3 Top Level Project: to cover all tasks related with modeling
32 stars 42 forks source link

TrackAtlas update: GradientProfile now correctly composed from several packets #708

Open JakobGartner opened 9 years ago

JakobGartner commented 9 years ago

The Gradient Profile has now the following features (*) means "new feature":

Packet 21 converted to Gradient Profile format from TrackAtlasTypes Absolute Position AND relative position to LRBG are now calculated in parallel () The GradientProfile is built up from several consecutive packets () A flag "available" is maintained while profile is valid/ onboard () The profile is always internally maintained from the location of the previous LRBG() The profile is always transmitted referencing the current LRBG location (*)

The function is now relying on Calculate Train Position data for the balise locations. @UweSteinkeFromSiemens : is the choice of using "nominal" position for LRBG and prvLRBG position the good one?

T12z commented 9 years ago

What is the scale of (new) Track Atlas Gradient? Like in the packets itself, promille or like in obu-types-comment tenths of promille (aka 1/10000)? I'd be happy without additional upscale.

---- Jakob Gärtner schrieb ----

The Gradient Profile has now the following features (*) means "new feature":

Packet 21 converted to Gradient Profile format from TrackAtlasTypes Absolute Position AND relative position to LRBG are now calculated in parallel () The GradientProfile is built up from several consecutive packets () A flag "available" is maintained while profile is valid/ onboard () The profile is always internally maintained from the location of the previous LRBG() The profile is always transmitted referencing the current LRBG location (*)

The function is now relying on Calculate Train Position data for the balise locations. @UweSteinkeFromSiemens : is the choice of using "nominal" position for LRBG and prvLRBG position the good one?

— Reply to this email directly or view it on GitHub.

UweSteinkeFromSiemens commented 9 years ago

To answer your question: is the choice of using "nominal" position for LRBG and prvLRBG position the good one?

The calculations with uncertainties is easy with the functions provided by the BasicLocationFunctions_Pkg lib. I strongly recommend to use these functions, since they enforce the unification of all calculations of distances, locations, positions and odometry data.

JakobGartner commented 9 years ago

The gradient value is in 0/00 as in the SRS

The distances are in cm.

If you want other scale just say so

On 02 Sep 2015, at 08:32, Thorsten Schulz notifications@github.com wrote:

What is the scale of (new) Track Atlas Gradient? Like in the packets itself, promille or like in obu-types-comment tenths of promille (aka 1/10000)? I'd be happy without additional upscale.

---- Jakob Gärtner schrieb ----

The Gradient Profile has now the following features (*) means "new feature":

Packet 21 converted to Gradient Profile format from TrackAtlasTypes Absolute Position AND relative position to LRBG are now calculated in parallel () The GradientProfile is built up from several consecutive packets () A flag "available" is maintained while profile is valid/ onboard () The profile is always internally maintained from the location of the previous LRBG() The profile is always transmitted referencing the current LRBG location (*)

The function is now relying on Calculate Train Position data for the balise locations. @UweSteinkeFromSiemens : is the choice of using "nominal" position for LRBG and prvLRBG position the good one?

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/708#issuecomment-136950393.

JakobGartner commented 9 years ago

I don’t do monitoring in the Track Atlas, I only reference the nominal target distances to the BGs. For me this means that when I use the values for position of LRBG and prvLRBG that I receive from CalculateTrainPosition I entirely live in the nominal world.

Right?

On 02 Sep 2015, at 10:13, Uwe Steinke notifications@github.com wrote:

To answer your question: is the choice of using "nominal" position for LRBG and prvLRBG position the good one?

The current train position as well as the location of LRBG and prvLRBG are afflicted by uncertainties. The uncertainty is expressed by the window between min and max of Obu_BasicTypes_Pkg::LocWithInAcc_T. The nominal location is an arbitrary value between min and max and the worst choice in any case.

The uncertainties apply also to the profile data, so that all profiles must take them into account and provide their locations with uncertainties too.

When the profile/track data are to be used by subsequent components (speed and distance monitoring, ... ), those typically have to calculate the min or max distance between the current train position and a profile datum (beginning speed restriction, ...). If min or max is appropriate, depends on what is safe.

The calculations with uncertainties is easy with the functions provided by the BasicLocationFunctions_Pkg lib. I strongly recommend to use these functions, since they enforce the unification of all calculations of distances, locations, positions and odometry data.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/708#issuecomment-136972018.

UweSteinkeFromSiemens commented 9 years ago

No. What is the nominal world suitable for?

Living in the nominal world is equivalent to ignoring completely

JakobGartner commented 9 years ago

ok. Thanks. I see that I must check whether the frontmost or backlist LRBG location is the relevant for me.

For the moment I will put all to “frontmost” , I will work this out when I add the train length compensation

On 02 Sep 2015, at 11:13, Uwe Steinke notifications@github.com wrote:

No. What is the nominal world suitable for?

Living in the nominal world is equivalent to ignoring completely

the mounting inaccuracies of balises on the track the odometry inaccuracies of the odometry on board the detection inaccuracies of the balises by the BTM the train positioning as one of the most central OBU functions — Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/708#issuecomment-136989389.

JakobGartner commented 9 years ago

my main question is this, if I formulate it in a different way:

we are talking about effectively moving all targets according to “safety considerations”.

when now the supervision function does again the same considerations, we may have a double compensation.

Did you sort these questions out in CalculateTrainPosition?

e.g. the estimates for the (LR)BGs and the estimates for the Train Position itself are totally decoupled, are they?

On 02 Sep 2015, at 11:13, Uwe Steinke notifications@github.com wrote:

No. What is the nominal world suitable for?

Living in the nominal world is equivalent to ignoring completely

the mounting inaccuracies of balises on the track the odometry inaccuracies of the odometry on board the detection inaccuracies of the balises by the BTM the train positioning as one of the most central OBU functions — Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/708#issuecomment-136989389.

UweSteinkeFromSiemens commented 9 years ago

The track atlas should provide all profile locations with uncertainties.

It is the task of the subsequent component consuming the profile data to decide, if min or max is the safe value, depending on the current scenario and state.

Example:

JakobGartner commented 9 years ago

OK, as the subsequent component is not using the data that way, this will be integrated after the Friday demo deadline

On 02 Sep 2015, at 11:30, Uwe Steinke notifications@github.com wrote:

The track atlas should provide all profile locations with uncertainties.

It is the task of the subsequent component consuming the profile data to decide, if min or max is the safe value, depending on the current scenario and state.

Example:

for a decreasing speed limit, the minimum distance is safe. for an increasing speed limit, the maximum distance is safe. — Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/708#issuecomment-136997296.

UweSteinkeFromSiemens commented 9 years ago

Instead of compensation I propose to simply calculate.

calculateTrainPosition provides the current train position as a min / max range of Obu_BasicTypes_Pkg::LocWithInAcc_T. The same applies to the LRBG location. If you want to know the distance between LRBG and the current train position, BasicLocationFunctions_Pkg::sub_2_distances will compute the distance as a min / max range as well.

All calculations can be performed in the same way.

A remark to profile distances received from packets:

they are defined as without inaccuracies (min = max = 0). But since train position and BG locations are uncertainties afflicted, all distances between train and a profile destination ahead will have uncertainties too.

So, it might be possible

JakobGartner commented 9 years ago

On 02 Sep 2015, at 11:52, Uwe Steinke notifications@github.com wrote:

Instead of compensation I propose to simply calculate.

calculateTrainPosition provides the current train position as a min / max range of Obu_BasicTypes_Pkg::LocWithInAcc_T. The same applies to the LRBG location. If you want to know the distance between LRBG and the current train position, BasicLocationFunctions_Pkg::sub_2_distances will compute the distance as a min / max range as well.

All calculations can be performed in the same way.

A remark to profile distances received from packets:

they are defined as without inaccuracies (min = max = 0). But since train position and BG locations are uncertainties afflicted, all distances between train and a profile destination ahead will have uncertainties too.

So, it might be possible

to set up the track atlas without uncertainties based on the nominal data given by the packets and then simply induce the uncertainties when calculating the true distance between a profile destination and the train position or between the LRBG and a profile destination in a second step.

OK the latter was what I had understood, so all seems fine.

Jakob

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/708#issuecomment-137006486.

T12z commented 9 years ago

As for gradient profiles, I have no specification to use uncertainties. But I would not be necessary anyways. Gradients are well overestimated, as always the whole train is taken for minimum gradient. This should well compensate for odometry errors, as train length is normally more than odo uncertaincy.

Concerning the MRSP, these migrate to brake targets, but as of 3.13.8.1.1, these are made of location and speed, nothing said about uncertainties

T12z commented 9 years ago

The gradient value is in 0/00 as in the SRS

If it is 1:1 with SRS that is perfectly fine with me, just as I mentioned in #685 , usage and documentation diverged. I hope DMI is using it the right way.

UweSteinkeFromSiemens commented 9 years ago

The uncertainties are induced by physics as specified in Subset 026, 3.6.4, and apply to all location based data in general. It of course comprises profiles as well, even though the profile distances extracted from packets are given without uncertainties.

For safety reasons, it has to guaranteed, that the train under no circumstances violates the profiles received. This must not be based on assumptions, but proved.