Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007591CDD ASN.1 (TS 102 894-2)New Featurepublic08-01-2017 19:1613-07-2018 09:44
Reporterbuburuzan 
Assigned Tolinla 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product VersionTS 102 894-2 V1.2.1 
Target VersionFixed in Version 
Summary0007591: Change DE_CurvatureValues Unit from “1 over 30000 meters” to “1 to accomodate more relevant values.
DescriptionThe new proposed Method provides a constant accuracy over the full range of values (0-30000).

CR form as ITSWG1(16)001001 (https://docbox.etsi.org/ITS/ITSWG1/05-CONTRIBUTIONS/2016//ITSWG1(16)001001_New_Curvature_representation.docx [^]) and motivation as ITSWG1(16)001002 (https://docbox.etsi.org/ITS/ITSWG1/05-CONTRIBUTIONS/2016//ITSWG1(16)001002_Motivation_CR_-_New_Curvature_representation.pptx [^]).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0014490)
linla (manager)
10-01-2017 15:53

 please approve in ITS WG1#38
(0014503)
linla (manager)
18-01-2017 10:14

 optionally, Value is Interger of [1/radiis x 10000]
(0014539)
buburuzan (developer)
23-03-2017 12:21

 The proposal doesn't improve accuracy by much when Value=1/Radius*10000:
Radius Value
1 10000
10 1000
100 100
200 50
1000 10
So all the values between 1000 and 10000 wil be "wasted" on radii smaller as 10, radii which a vehicle will never have...
(0014540)
Dieter Smely (reporter)
23-03-2017 14:01

 A motorcycle can have a curve radius of around 3 m, and a bicycle even less.

Originally the proposal was to use not the radius, but the curvature.
When it comes to the requirement to increase the accuracy between a radius of 10 m and 1000 m, than this works fine, since you have 900 steps in between the radius 10 m and 100 m, which are the most common curvatures, while you have only 90 steps, when looking at the radius. That is an accuracy increase by factor 10.
When you are not interested in radii smaller than 10 m just limit the value to 10 bits - resulting in a maximum curvature of 1023/m equal a radius of 9,7 m.
When you use the same 10 bits for the radius, you have almost the same curvature / radius range, but with much less accuracy in the interesting region (see above).
(0014550)
buburuzan (developer)
06-04-2017 15:34

 Agreed in WG1#39 with the changes:
- Value=1/Radius*10000
- reduce the number of bits to 10 for holding the value
(0014713)
Alexandre Berge (administrator)
27-06-2017 08:46

 Previous comments mention limiting the value to 10 bits, and in the note description the max value is indicated to be 1023 (which is 2^10 - 1). However, to my understanding, CurvatureValue is a _signed_ value, so if we want the value range to be (-1023..1023), the encoding needs to be performed on 11 bits (otherwise, keeping 10bits, it would be (-511..511).

(0..1023) will be encoded on 10 bits,

but

(-1023..1023) requires 11 bits.

In addition, the current implementation features a ‘unavailable(30001)’ value, should we keep something similar ?

Assuming 11 bits (“useable” value of 10bits + 1 bit for sign) and ‘unavaialble’ value, the change would be:
CurvatureValue ::= INTEGER {unavailable(1023)} (-1024..1023)
(0014714)
Alexandre Berge (administrator)
27-06-2017 09:12

 Final decision: CurvatureValue ::= INTEGER {unavailable(1023)} (0..1023)
(0014721)
linla (manager)
27-06-2017 15:35

 approved in WG1 40 meeting
(0014831)
buburuzan (developer)
10-10-2017 09:20

 We discussed and agreed at the WG1#41 meeting to keept the number of bits to 14 in order not to break the backwards compatibility. The new callculation method will be kept (so only the reduction ob bits number is reverted).
@Alex: please review this change an if it is OK implement it.
(0015111)
linla (manager)
22-06-2018 08:58

 in WG1#43 meeting, the issue was rediscussed from RC, the conclusion is to keep 10bit definition as recorded in WG1#43 meeting report.
(0015114)
buburuzan (developer)
24-06-2018 19:08

 I am not so sure that is the resolution, we only agreed to change the callculation method, the number of bits and the signage information is not 100% clear to me, yet. Before closing it, the following two issues still need to be clarified:
1. How many bits we use for the curvature value
2. how do we handle the signage information vor that value
(0015116)
linla (manager)
26-06-2018 09:48

 CurvatureValue ::= INTEGER {straight(0),unavailable(1023)} (-1023..1023) CurvatureValue ::= INTEGER {straight(0), reciprocalOf1MeterRadiusToRight(-30000), reciprocalOf1MeterRadiusToLeft(30000), unavailable(30001)} (-30000..30001)

It describes the inverse of a detected vehicle turning curve radius scaled with 30 000A curvature detected by a vehicle represents the curvature of the actual vehicle trajectory. Positive values indicate a turning curve to the left hand side of the driver. It corresponds to the vehicle coordinate system as defined in ISO 8855 [2]. The value shall be set to 0 when the vehicle is moving straight. When the information is not available, the DE shall be set to 30 001with the the following information:
Value=1/Radius*10000
wherein radius is the vehicle turning curve radius..

Positive values indicate a turning curve to the left hand side of the driver. It corresponds to the vehicle coordinate system as defined in ISO 8855 [2]. The value shall be set to 0 when the vehicle is moving straight. The value shall be set to 1023, if the information is not available.

The DE is used in Curvature DF as defined in clause A.107.

Approved in WG1#44
(0015117)
linla (manager)
26-06-2018 09:49

 Please check and implement the ASN.1 according to the WG1#44 decision (signed value included)
(0015121)
linla (manager)
13-07-2018 09:44

 Please check and implement the ASN.1 according to the WG1#44 decision (signed value included)

- Issue History
Date Modified Username Field Change
08-01-2017 19:16 buburuzan New Issue
10-01-2017 15:53 linla Note Added: 0014490
18-01-2017 10:14 linla Note Added: 0014503
02-02-2017 10:22 Sebastian Muellers Assigned To => buburuzan
02-02-2017 10:22 Sebastian Muellers Status new => assigned
23-03-2017 12:21 buburuzan Note Added: 0014539
23-03-2017 14:01 Dieter Smely Note Added: 0014540
06-04-2017 15:34 buburuzan Note Added: 0014550
06-04-2017 15:34 buburuzan Status assigned => resolved
06-04-2017 15:34 buburuzan Resolution open => fixed
27-06-2017 08:46 Alexandre Berge Note Added: 0014713
27-06-2017 09:12 Alexandre Berge Note Added: 0014714
27-06-2017 15:35 linla Note Added: 0014721
10-10-2017 09:20 buburuzan Assigned To buburuzan => Alexandre Berge
10-10-2017 09:20 buburuzan Note Added: 0014831
10-10-2017 09:20 buburuzan Status resolved => feedback
10-10-2017 09:20 buburuzan Resolution fixed => reopened
22-06-2018 08:58 linla Note Added: 0015111
24-06-2018 19:08 buburuzan Note Added: 0015114
24-06-2018 19:08 buburuzan Status feedback => assigned
24-06-2018 19:08 buburuzan Assigned To Alexandre Berge => linla
24-06-2018 19:08 buburuzan Status assigned => new
26-06-2018 09:48 linla Note Added: 0015116
26-06-2018 09:48 linla Status new => resolved
26-06-2018 09:48 linla Resolution reopened => fixed
26-06-2018 09:49 linla Note Added: 0015117
26-06-2018 09:49 linla Status resolved => assigned
13-07-2018 09:44 linla Note Added: 0015121
13-07-2018 09:44 linla Status assigned => resolved

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker