-
Notifications
You must be signed in to change notification settings - Fork 65
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
[ROS 2] Configurable point cloud publishing. #779
[ROS 2] Configurable point cloud publishing. #779
Conversation
6807459
to
59fd0d1
Compare
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageFormat.h
Outdated
Show resolved
Hide resolved
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageFormat.h
Outdated
Show resolved
Hide resolved
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageFormat.h
Outdated
Show resolved
Hide resolved
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageFormat.cpp
Outdated
Show resolved
Hide resolved
static const Pc2MessageFormat DefaultMessageFormat = { | ||
FieldFormat(FieldFlags::PositionXYZF32), FieldFormat(FieldFlags::Padding32), FieldFormat(FieldFlags::RangeU32), | ||
FieldFormat(FieldFlags::IntensityF32), FieldFormat(FieldFlags::SegmentationData96), |
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.
- Does not seem to work for me - I have an empty message, when I just add LiDAR component.
- Why did you decide for this exact set of fields?
- Should Lidar 2D also have some default message format? Or it does not use this feature (configurable ROS 2 messages) at all?
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.
This seems to be related to an o3de bug where the vector element changes are not registered correctly as prefab changes.
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageFormat.cpp
Outdated
Show resolved
Hide resolved
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageFormat.cpp
Outdated
Show resolved
Hide resolved
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageBuilder.cpp
Outdated
Show resolved
Hide resolved
Gems/ROS2/Code/Source/Lidar/Publishing/PointCloudMessageWriter.h
Outdated
Show resolved
Hide resolved
Note: performance impact testing is mandatory |
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
26e9584
to
8411ca8
Compare
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
As @adamdbrw suggested, here are the benchmarks comparing both the previous version of the raycaster: We can see that the version with configurable publishing takes around 10ms longer. I will analyze and optimize this feature further but I believe that this may be a necessary cost for such a feature. |
Please use |
This pr was a draft at first. As part of the review, new features were requested. I was unable to change it back to a draft and therefore it was not made a draft. |
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
//! @param includeMaxRange Should the raycaster add points at max range for rays that exceeded their range? | ||
virtual void ConfigureMaxRangePointAddition([[maybe_unused]] bool addMaxRangePoints) | ||
{ | ||
AZ_Assert(false, "This Lidar Implementation does not support Max range point addition configuration!"); |
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.
Is this API breaking change is necessary?
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 believe so. Although the new API call that was created in place of this one seems similar, it serves a different purpose.
Gems/ROS2/Code/Include/ROS2/Lidar/PC2PostProcessingBaseComponent.h
Outdated
Show resolved
Hide resolved
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
I understand that we agreed to move this code to a separate Gem, as the proposed functionality would make sense for very specific applications only while bringing the API-breaking changes and huge complications to Lidar component. Could you please confirm? If so, I will close the PR. cc: @pijaro |
@alek-kam-robotec-ai can this optimization be used within the current implementation? |
Yes. |
This optimization is already implemented and was ported alongside other changes this PR made. |
Closing the PR. Please reopen if anything changes. |
What does this PR do?
This PR aims to further improve ROS2 Lidar Component's configurability. It does so by adding message configuration for the ROS2 Lidar component. The message configuration is composed of fields which signify one or more actual PC2 message fields. The presence, order, padding and names of the published fields can now be configured through the ROS2 Lidar Component's editor interface.
Please describe any testing performed.
This feature was tested under various configurations on a simple scene.
List of features: