Open BenjaminBeichler opened 10 years ago
These were the reasons why I proposed an OBU coordinate system and to allocate all track elements on a position as seen by the OBU. Please check, if the OBU coordinate system as specified in chapter 4.1 of https://github.com/openETCS/SRS-Analysis/blob/master/System%20Analysis/WorkingRepository/Group4/SUBSET_26_3-6/DetermineTrainLocationProcedures.docx?raw=true covers your needs.
That seems to fit really good. Is this part of SRS Subset 26? I haven't read such parts. Sorry for not reading this document. While reading the parts of 3.12 there is no such coordinate system mentioned, but a logical consequence for all described algorithms.
If I understand right, the Parts of Gradient-Profile, all static speed restrictions (if they have positional dependencies), track conditions and other track information will work with this OBU coordinate system, isn't it ?
The OBU coordinate system is not part of the spec, but a design decision only. We are free to cleverly choose any method that fits to the needs and works correctly.
Uwe, I’ve derived the equations for the distances from the LRBG. The reason is that inaccuracies between your absolute reference and the “original reference balise group” will be in the equations for train position and in the equations for locations. This have to be arranged in a way that the inaccuracies in the one are compensated in the other (while the inaccuracies in rear of the ORBG are irrelevant). You may derive those equations, but it’s introducing extra complexity.
The most optimal choice would be using the trains front end as reference. But as that one is moving it would lead to high calculation efforts. Therefore using the LRBG as the reference is an optimized choice. Still it’s useful to store the absolute detection locations (or even better: detection time).
Regards, Jan
From: Uwe Steinke [mailto:notifications@github.com] Sent: maandag 10 maart 2014 11:23 To: openETCS/SRS-Analysis Subject: Re: [SRS-Analysis] Modelling Proposal&Question: Global Absolute Position (#15)
The OBU coordinate system is not part of the spec, but a design decision only. We are free to cleverly choose any method that fits to the needs and works correctly.
— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/15#issuecomment-37168589.
Lloyd’s Register is a trading name of Lloyd’s Register Group Limited and its subsidiaries. For further details please see http://www.lr.org/entities © Lloyd's Register Group Limited 2012
Lloyd's Register Group Limited, its affiliates and subsidiaries and their respective officers, employees or agents are, individually and collectively, referred to in this clause as 'Lloyd's Register'. Lloyd's Register assumes no responsibility and shall not be liable to any person for any loss, damage or expense caused by reliance on the information or advice in this document or howsoever provided, unless that person has signed a contract with the relevant Lloyd's Register entity for the provision of this information or advice and in that case any responsibility or liability is exclusively on the terms and conditions set out in that contract.
But this means, after every LRBG, all Data-Structures with positions needs to be updated with the new reference point, for the calculation which needs the actual position of the train. All other calculation uses positional data from balises or RBC, which should have constant accuracy, isn't it?
Another thing is the resolution of this one dimensional coordinates. Currently I use floating point (namely C-double) variables in meters. Of course also fixed point are imaginable, since the accuracy is limited to 10s centimeters (I'm not really sure ...), but then also the inaccuracies of fixed point calculations needs to be considered.
If you don’t update the data structure for the BG’s, you have to update all data structures containing locations (MA, TSR’s, gradients, speed profiles, announced BG’s,…….)
From: Benjamin Beichler [mailto:notifications@github.com] Sent: maandag 10 maart 2014 12:50 To: openETCS/SRS-Analysis Cc: Welvaarts, Jan Subject: Re: [SRS-Analysis] Modelling Proposal&Question: Global Absolute Position (#15)
But this means, after every LRBG, all Data-Structures with positions needs to be updated with the new reference point, for the calculation which needs the actual position of the train. All other calculation uses positional data from balises or RBC, which should have constant accuracy, isn't it?
Another thing is the resolution of this one dimensional coordinates. Currently I use floating point (namely C-double) variables in meters. Of course also fixed point are imaginable, since the accuracy is limited to 10s centimeters (I'm not really sure ...), but then also the inaccuracies of fixed point calculations needs to be considered.
— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/15#issuecomment-37174341.
Lloyd’s Register is a trading name of Lloyd’s Register Group Limited and its subsidiaries. For further details please see http://www.lr.org/entities © Lloyd's Register Group Limited 2012
Lloyd's Register Group Limited, its affiliates and subsidiaries and their respective officers, employees or agents are, individually and collectively, referred to in this clause as 'Lloyd's Register'. Lloyd's Register assumes no responsibility and shall not be liable to any person for any loss, damage or expense caused by reliance on the information or advice in this document or howsoever provided, unless that person has signed a contract with the relevant Lloyd's Register entity for the provision of this information or advice and in that case any responsibility or liability is exclusively on the terms and conditions set out in that contract.
In Preparation to the Modelling Workshop, I want to propose some Issue about the positional Data in other parts of the OBU. In the SystemC Model I make the design decision, that there exist something like a global position, which have the same reference point over a greater distance.
As I right understand all data of balises and radio are referenced to balise groups. This make things much more complicated and I suppose a calculated (imaginary) absolute 1D Position simplifies many things. In my opinion this proposal is also SRS-compliant, because the positional attributes are mostly not described in detail.
This refers to #8 #9 and especially I think @UweSteinkeFromSiemens is proposed for managing this task.