Refactor/simple sensor simulator/noise

[yamacir-kit]

Description

Abstract

Refactored the function to add noise to messages published by DetectionSensor in simple_sensor_simulator.

Background

DetectionSensor currently provides a simple noise application. The feature can be configured in the items listed in LINK whose names begin with detectedObject.

However, since this feature is only a simple noise application, a more practical noise model will be designed by Autoware's planner development team. The classes DefaultNoiseApplicator and CustomNoiseApplicator have been prepared as a testing ground for the planner development team to test and validate the model.

Details

The two refactorings we have done this time are as follows:

Delete DefaultNoiseApplicator and CustomNoiseApplicator and replace them with closure

These two classes were provided for ease and simplicity of test implementation.
In reality, however, these classes served neither purpose. As evidenced by the fact that DefaultNoiseApplicator's class members are raw references, this class is effectively no different than a closure that reference-captures the required object.
Although the member function DetectionSensor<>::update has the disadvantage of being larger in definition, I thought it would be more beneficial to reduce the total amount of code, so I removed those classes and replaced them with closures that do the equivalent work.

Change the argument type of the noise application function

Previously, the noise application function (CustomNoiseApplicator::operator ()) was passed the DetectedObjects type, which is the message type that will eventually be published.
However, each object stored in the DetectedObjects type does not have an identifier that can be used to identify the individual object, which makes it difficult to implement a specific noise model.
Therefore, the data type given to the noise application function was changed to traffic_simulator_msgs::EntityStatus, which holds the name of each entity.

References

None.

Destructive Changes

None.

Known Limitations

None.

[github-actions]

Checklist for reviewers ☑️

All references to "You" in the following text refer to the code reviewer.

• Is this pull request written in a way that is easy to read from a third-party perspective?
• Is there sufficient information (background, purpose, specification, algorithm description, list of disruptive changes, and migration guide) in the description of this pull request?
• If this pull request contains a destructive change, does this pull request contain the migration guide?
• Labels of this pull request are valid?
• All unit tests/integration tests are included in this pull request? If you think adding test cases is unnecessary, please describe why and cross out this line.
• The documentation for this pull request is enough? If you think adding documents for this pull request is unnecessary, please describe why and cross out this line.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud