Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ObstacleDetection instances, attributes and Adaptive CruiseControl #780

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

tguild
Copy link

@tguild tguild commented Oct 4, 2024

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.

description: Distance in meters to detected object

ObstacleDetection.TimeGap:
datatype: int32
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has negative number a meaning, or would uint32 suffice?
Has this one and Distance only significance if ObstacleDetection.IsWarning is True, or what values should be used if there is no obstacle?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsigned is fine but wanted decimal instead of rounding to full integer.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If no meaning - shall we use uint32, i.e. up to 65 seconds?

@@ -113,6 +124,9 @@ LaneDepartureDetection.IsError:
#
ObstacleDetection:
type: branch
instances:
- ["Front", "Rear"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the instances also for the existing signals like IsEnabled, IsWarning and so on? If not we could split to two branches, one called ObstacleDetection (without instances) and one called Obstacles (with instances)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each ObstacleDetection sensor could throw a separate warning, be disabled independently etc,

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previous conversation before considering instances approach

#770

@erikbosch
Copy link
Collaborator

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 erikbosch marked this pull request as draft November 7, 2024 10:45
@erikbosch erikbosch added the Status:Rework Committer must refactor or address comments label Nov 7, 2024
@erikbosch
Copy link
Collaborator

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
Copy link
Author

tguild commented Nov 12, 2024

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
Copy link
Collaborator

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
Copy link
Author

tguild commented Nov 12, 2024

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).

Adding alternative to distance in meters
trailing whitespace
more extraneous whitespace
unit: m
description: Distance in meters to keep from lead vehicle

CruiseControl.AdaptiveDistanceSet:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicate name?

@erikbosch erikbosch marked this pull request as ready for review November 19, 2024 15:08
@erikbosch
Copy link
Collaborator

MOM:

  • Please review, merge decision next week

unique node name
@erikbosch
Copy link
Collaborator

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

unit: m
description: Distance in meters to keep from lead vehicle

CruiseControl.AdaptiveIntvervalSet:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo Intverval

datatype: float
type: sensor
unit: m
description: Distance in meters to detected object
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can never be negative, or?

And distance is distance from the specified "zone". I.e. an object just in front of the front number plate may be reported with distance==0.01 meter by Front.Center, but with distance==0.80 meter by Front.Right?

@erikbosch
Copy link
Collaborator

MoM:

  • OK to merge when review comments from Erik is addressed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status:Rework Committer must refactor or address comments
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants