-
Notifications
You must be signed in to change notification settings - Fork 64
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
Constructors with parameters in ROS2SensorComponents #433
Conversation
Signed-off-by: Jan Hanca <[email protected]>
Signed-off-by: Jan Hanca <[email protected]>
Signed-off-by: Jan Hanca <[email protected]>
Signed-off-by: Jan Hanca <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice changes! How was this PR tested?
It was tested manually to ensure that all options are still available in Editor and with some unit tests (not pushed) to test the constructors. The unit tests were based on this code: RobotecAI#10 and can be found in closed #429 for |
Test code would be great! |
Tests were added, but I am not sure if we want to keep them. |
|
||
namespace ROS2 | ||
{ | ||
void ImuSensorConfiguration::Reflect(AZ::ReflectContext* context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not like that change. There are designs, projects, and Gems that use that component and this changes reflection.
namespace ROS2 | ||
{ | ||
//! A structure capturing configuration of a lidar sensor (to be used with ROS2LidarSensorComponent). | ||
class LidarSensorConfiguration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It breaks all lidars in other gems and other projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change from code point of view looks nice, but it will break all prefabs using touched components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhanca-robotecai the default view in Editor is simple to address can be fixed through an attribute (expand). |
Change management is an inherent part of the software engineering process. The sooner we are able to battle-test our approach to component migration the better. Version converters might be possibly used to change existing data in an unbreakable way, and developed idioms shall be kept as unit tests for further reference |
Signed-off-by: Jan Hanca <[email protected]>
Signed-off-by: Jan Hanca <[email protected]>
Signed-off-by: Jan Hanca <[email protected]>
631e98e
to
990f32c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Does anything else need to be changed with prefabs? I see changes for ROSBot but not Proteus.
Based on the internal conversation it was decided to break the backward compatibility and fix the design issue. If decided otherwise, the sample implementation of the version converter (for one of the sensors) can be found here: jhanca-robotecai#1 The Editor's view was set to the same as before using the attributes: Additionally, as the backward compatibility is broken, the parameter Finally, the prefab with Slamtec sensor was fixed (the configuration of 3D lidar sensor was requested for 2D lidar sensor), before: |
The changes in:
|
The demos need to be adjusted to development anyway, we should skip adjustments for this PR alone |
There is no configuration stored in Proteus' prefab.
It is quite easy to miss the change, as de-serialization simply ignores the unknown fields without notifying the user about problems. Therefore I would strongly recommend doing it as fast as possible. E.g. |
@michalpelka take a look please |
ROS2GNSSSensorComponent
,ROS2ImuSensorComponent
,ROS2LidarSensorComponent
, andROS2Lidar2DSensorComponent
to separate structsThe goal of this PR is to simplify the implementation of methods for creating sensors (it will be used in RobotImporter).