feat: introducing SensorModule to provide access to environmental events

[kschrab]

Description

• Provides new interfaces to provide vehicle applications with sensor modules.
  • The BasicSensorModule is a single-value based sensor model which can be used to detect icy or rainy areas (e.g., via getOs().getBasicSensorModule().getStrengthOf(SensorType.ICE). This replaces the method getOs().getStateOfEnvironmentSensor(SensorType.ICE) in the general OperatingSystem. The data for this sensor module is produced by the EnvironmentAmbassador.
  • The LidarSensorModule provides access to the previously added PointCloud structure which is produced by vehicle simulators such as PHABMACS or Carla.
  • For now, only VehicleUnits are able to use the new sensor modules.
• Adjusted all apps (e.g., WeatherWarningApp).

Issue(s) related to this PR

• Resolves internal issue 889

Affected parts of the online documentation

Changes in the documentation required?

Yes, documentation and Barnim tutorials must be adjusted to use getBasicSensorModule instead now.

Definition of Done

Prerequisites

• You have read CONTRIBUTING.md carefully.
• You have signed the Contributor License Agreement.
• Your GitHub user id is linked with your Eclipse Account.

Required

• The title of this merge request follows the scheme type(scope): description (in the style of Conventional Commits)
• You have assigned a suitable label to this pull request (e.g., enhancement, or bugfix)
• origin/main has been merged into your Fork.
• Coding guidelines have been followed (see CONTRIBUTING.md).
• All checks on GitHub pass.
• All tests on Jenkins pass.

Requested (can be enforced by maintainers)

• New functionality is covered by unit tests or integration tests. Code coverage must not decrease.
• If a bug has been fixed, a new unit test has been written (beforehand) to prove misbehavior
• There are no new SpotBugs warnings.

Special notes to reviewer

[hoelger]

had a very brief read and came up with following things:

• getEnvironmentSensor(): environment here gets a very special naming meaning "coming from environment simulator". also lidar data is from the environment... right? not sure how confusing this is in the future >> getSimpleSensor()
• getEnvironmentSensor(): singular "Sensor" may be confusing, because environment has multiple sensor types...
• getOs().getSensorModule().getEnvironmentSensor().enable() : this enable was happening on the module itself (looking at adhoc / cell), so after getModule(), now it's one layer deeper. I find this confusing and for my taste this should be unified.
• same thing different perspective: with "sensible" you give access to both environment + lidar. so why would you enable() those separately?
• discussed: have getLidarSensorModule() and getSimpleSensorModule() as two different modules
• why DefaultSensorModule and not SensorModule (cmp AdhocModule / CellModule) (I don't fully understand why you want to split this very little functionality into the interface SensorModule, this only makes sense if you can reuse it, like for the Sensor<T>). I would merge Default + SensorModule

[hoelger]

Why do we remove this handy option to add callbacks? :)

[kschrab]

I removed that at least for this basic sensor, as I noticed it was not implemented correctly and doing it right would require more effort. The callback was only triggered when the vehicle entered the event area, but not when it left it or when the event time has reached its end. We can later offer this method, but right now it would not work as expected and would be out of scope of this re-design.

[hoelger]

I don't understand why the module now goes into VehicleUnit. So implementing it here was wrong in the first place?

[kschrab]

Yes, as long as we only support vehicles with the proposed sensor modules, it's sufficient to initialize the implementation in the VehicleUnit only. We can discuss if we already want RSUs or TrafficLights to be able be Sensible, but again, this more sounds like a feature than a re-design.