ObstacleDetection instances, attributes and Adaptive CruiseControl

[tguild]

Adaptive cruise control distance setting typically seen on the dashboard user interface as increments (eg 1-5) that may be either vehicle lengths or an incremental variable that also factors in vehicle speed for safe following distance. If the latter a setting of 1 may be 10 meters at 30km/h but 30 at 90 km/h. In that case it would be more important to note the user preferred an adaptive buffer of 1 that has no fixed length but fluctuates with speed. We ask the OEM and suppliers on the VSS call to give clarity to conventions in production wrt adaptive cruise control.

In adding instances to ObstacleDetected, we want to be able to support multiple leaf nodes as multiple obstacles can be detected concurrently. Here too we want input from OEM and suppliers on the multitude of obstacle detecting sensors in mainstream vehicles. We realize more advanced autonomous vehicles will have far more lidar/camera/other sensors detecting and tracking obstacles. Degrees with zero being directly in front would provide more flexibility but trying to keep it simple. We want to avoid Center in both Y and X axis and based on feedback will likely go with "Middle" or "-" for Y.

instances:
- ["Front", "-", "Rear"]
- ["Left", "Center", "Right"]

We also want ObjectType such as wildlife, pedestrian, bicycle, vehicle, etc but again hope someone in the community can direct us to an effort like Sensoris that should be leveraged instead of defining ourselves.

[erikbosch]

MoM:

• Please review
• Ted: For adaptive cruise control you typically have some settings.
• Ted: Setting in meters proposed for now, or would a symblic setting in "steps" (1-2-3-...) be better for OEM needs?
• Ted: Instance concept proposed (front left, front center, and so on) , does it fit OEM needs?
• Stefan: we are not aware of any existing baseline
• Richard: Some vehicles have car-lengths, likely OEM specific. Cars with automatic parking has more sensors so will likely differ vehicle to vehicle.
• Erik: For wipers we have both symbolic steps (e.g. to control frequency when use automatic mode) and absolute (Hz)
• Daniel: ASAM has an extensive model for similar things. https://www.asam.net/fileadmin/News/Brochures/ASAM_SIM-Guide_Online.pdf

[erikbosch]

Changing to draft for now. @tguild - feel free to switch back to "ready for review" when all discussions in other COVESA groups have finished, i.e. it has reached a stable state for final review

[tguild]

Hej @erikbosch I took a look at the wiper example and only see frequency in cycles per minute, not an alternative with a stepped setting (eg slow, medium and fast - potentially represented as integer 1, 2, 3).

[erikbosch]

Hej @erikbosch I took a look at the wiper example and only see frequency in cycles per minute, not an alternative with a stepped setting (eg slow, medium and fast - potentially represented as integer 1, 2, 3).

In https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/Body/Body.vspec we have two levels of wiper functionality. We have Windshield.Wiping.Mode and Windshield.Wiping.Intensity that represents a quite typical user interface where you have one handle to select wiping mode and then a wheel to fine-tune the intensity in interval/rain-mode.

The Windshield.Wiping.System is then for the more fine grained low level control, like actual frequency expressed in cycles per minute and similar.

Windshield.Wiping.Mode:
  datatype: string
  type: actuator
  allowed: ['OFF', 'SLOW', 'MEDIUM', 'FAST', 'INTERVAL', 'RAIN_SENSOR']
  description: Wiper mode requested by user/driver.
               INTERVAL indicates intermittent wiping, with fixed time interval between each wipe.
               RAIN_SENSOR indicates intermittent wiping based on rain intensity.

Windshield.Wiping.Intensity:
  datatype: uint8
  type: actuator
  description: Relative intensity/sensitivity for interval and rain sensor mode as requested by user/driver.
               Has no significance if Windshield.Wiping.Mode is OFF/SLOW/MEDIUM/FAST
               0 - wipers inactive.
               1 - minimum intensity (lowest frequency/sensitivity, longest interval).
               2/3/4/... - higher intensity (higher frequency/sensitivity, shorter interval).
               Maximum value supported is vehicle specific.

Windshield.Wiping.System:
  type: branch
  description: Signals to control behavior of wipers in detail.
               By default VSS expects only one instance.
  comment:     These signals are typically not directly available to the user/driver of the vehicle.
               The overlay in overlays/extensions/dual_wiper_systems.vspec can be used to modify this branch
               to support two instances; Primary and Secondary.

#include WiperSystem.vspec Windshield.Wiping.System

[tguild]

Thanks @erikbosch I was looking at WiperSystem.vspec which has Frequency instead of Body.vspec.

I do not see any mechanism in YAML that suggests an either or situation. It seems both are defined and the underlying vehicle can support either or both Frequency or Mode (optionally plus Intensity for vehicles equipped with rain sensor).

[erikbosch]

Duplicate name?

[erikbosch]

MOM:

• Please review, merge decision next week

[erikbosch]

DCO check is missing, a sign off is needed, see https://covesa.global/about-covesa/#contribute-code.

Instructions on how to rebase and add signoff at https://github.com/COVESA/vehicle_signal_specification/pull/780/checks?check_run_id=33207647757

[erikbosch]

Typo Intverval

[erikbosch]

MoM:

• OK to merge when review comments from Erik is addressed

[erikbosch]

@tguild - some minor things remaining like correcting AdaptiveIntvervalSet. Do you think you have time to update it so we can get it ready for merge.

[erikbosch]

Merged by #793