[RFC 96] EBus and ROS2 support for sensor configurations

[arturkamieniecki]

What does this PR do?

This PR enables runtime modification of sensor configuration using EBuses and ROS2 messages.
It add a new toggle to all sensors. If it is enabled, the sensor will create two topics. Get configuration and set configuration. Each of these components will use JSON to communicate.

How was this PR tested?

By modifying the configuration of the components.

[Copilot]

Pull Request Overview

This PR adds runtime sensor configuration support via EBuses and introduces new configuration structures across multiple sensor components. Key changes include:

• Introduction of configuration structs and Bus overrides for GNSS, Contact, and Camera sensor components.
• Refactoring of ROS2SensorComponentBase to support a configuration template parameter.
• Updates to include paths and adjustments to Lidar sensor configuration with mutable model lists.

Reviewed Changes

Copilot reviewed 43 out of 43 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
Gems/ROS2Sensors/Code/Source/Imu/ImuSensorConfiguration.cpp	Updated include path to use ROS2Sensors module.
Gems/ROS2Sensors/Code/Source/GNSS/ROS2GNSSSensorComponent.{h,cpp}	Added configuration struct and overrides for GNSS sensor.
Gems/ROS2Sensors/Code/Source/ContactSensor/ROS2ContactSensorComponent.{h,cpp}	Introduced configuration struct and interface for the Contact sensor.
Gems/ROS2Sensors/Code/Source/Camera/ROS2CameraSensorComponent{.h,.cpp}	Refactored sensor activation and configuration handling; added dedicated configuration method.
Gems/ROS2Sensors/Code/Include/ROS2Sensors/Sensor/ROS2SensorComponentBase.h	Updated base component to be templated with a configuration type and integrated ConfigurationBus support.
Gems/ROS2Sensors/Code/Include/ROS2Sensors/Lidar/LidarSensorConfiguration.h	Modified include paths and changed m_availableModels from const to mutable.
Gems/ROS2Sensors/Code/Include/ROS2Sensors/Configuration/ConfigurationBus.h	Added a new configuration Bus interface.

[michalpelka]

I think reusing std_msgs/string is not acceptable approach.
I support some internal API for adjusting sensors but ROS 2 messages should be used for sensors' data.

[jhanca-robotecai]

I reused some code from this PR and did it differently: #914

I created separate sensor configuration buses for each sensor type, i.e.:

• CameraConfigurationRequestBus
• ImuConfigurationRequestBus
• LidarConfigurationRequestBus
• WheelOdometryConfigurationRequestBus

ContactSensor, GNSS, and Odometry do not have any configuration. An advantage of this approach is a clear separation of the buses. Instead of having SensorConfigurationBus and ConfigurationBus, which are quite difficult to understand, each sensor would have a SensorConfigurationBus to configure basic parameters (available in every sensor) and a dedicated bus for parameters specific to that sensor.

Additionally, it simplifies the integration with ScriptCanvas/Lua if needed and is more O3DE way. Buses have calls to configure the whole sensor at once or to configure single parameters. This solution is much more flexible, as it allows the use of the same pipeline (getting the whole configuration via JSON, using O3DE serialization, and setting the configuration) or to easily create services for changing one parameter only. Finally, it does not require creating fake empty configuration structures just to ensure each sensor can override setters/getters (we have 4 sensors that can be configured and 3 that cannot).

[nick-l-o3de]

Do we want to close this and use 914, or are both required?

[jhanca-robotecai]

Do we want to close this and use 914, or are both required?

This one will be closed in favor of #914 if accepted. I will take care of that after the other one is merged, thanks!

[jhanca-robotecai]

Closing this PR in favor of #914