Skip to content
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

Conversation

alek-kam-robotec-ai
Copy link
Contributor

@alek-kam-robotec-ai alek-kam-robotec-ai commented Oct 29, 2024

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:

  • Added a new ROS2 Lidar Component field which allows for configurable PC2 message format,
    • this feature introduced new fields (some fields are not currently supported and are filled with default values)
  • Improved Lidar performance
  • Added support for ray Ring IDs
  • Removes raycaster - side publishing

@alek-kam-robotec-ai alek-kam-robotec-ai force-pushed the feature/configurable-pc-message/alkam branch from 6807459 to 59fd0d1 Compare October 29, 2024 15:31
@alek-kam-robotec-ai alek-kam-robotec-ai marked this pull request as ready for review October 29, 2024 15:31
@alek-kam-robotec-ai alek-kam-robotec-ai requested review from a team as code owners October 29, 2024 15:31
@byrcolin byrcolin added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Oct 29, 2024
@jhanca-robotecai jhanca-robotecai added sig/simulation Categorizes an issue or PR as relevant to SIG Simulation and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Oct 30, 2024
Comment on lines +143 to +145
static const Pc2MessageFormat DefaultMessageFormat = {
FieldFormat(FieldFlags::PositionXYZF32), FieldFormat(FieldFlags::Padding32), FieldFormat(FieldFlags::RangeU32),
FieldFormat(FieldFlags::IntensityF32), FieldFormat(FieldFlags::SegmentationData96),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Does not seem to work for me - I have an empty message, when I just add LiDAR component.
  2. Why did you decide for this exact set of fields?
  3. Should Lidar 2D also have some default message format? Or it does not use this feature (configurable ROS 2 messages) at all?

Copy link
Contributor Author

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.

@adamdbrw
Copy link
Contributor

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]>
@alek-kam-robotec-ai alek-kam-robotec-ai force-pushed the feature/configurable-pc-message/alkam branch from 26e9584 to 8411ca8 Compare November 4, 2024 09:19
@alek-kam-robotec-ai
Copy link
Contributor Author

alek-kam-robotec-ai commented Nov 21, 2024

As @adamdbrw suggested, here are the benchmarks comparing both the previous version of the raycaster:
Note: The second histogram is incorrect (for the correct comparison, see newer comments)
before
as well as the one from this pr:
after
I've measured the times using the AZStd::chrono::high_resolution_clock. The lidar was configured to have 1024 x 1024 ray pattern (1048576 rays) and used the RGL implementation. In both cases compact was enabled (non hits were not processed).

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.

@jhanca-robotecai
Copy link
Contributor

This feature was tested under various configurations on a simple scene. Please note that this is a draft pull request and is not yet ready for review.

Please use Draft option of github instead of text message to make it more clear.

@alek-kam-robotec-ai
Copy link
Contributor Author

This feature was tested under various configurations on a simple scene. Please note that this is a draft pull request and is not yet ready for review.

Please use Draft option of github instead of text message to make it more clear.

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]>
@alek-kam-robotec-ai
Copy link
Contributor Author

alek-kam-robotec-ai commented Nov 21, 2024

After a bit of digging I've realized that I've used the wrong data for the histogram of frequency tick elapsed time (You can see it on the histogram as well, there would be no sufficient time to publish the message - publishing takes ~6ms and was not changed by this pr). I've also found a new optimization which further improved performance by about ~4ms (for 1mln rays).
Performance prior to configurable publishing (development branch):
before
and after introducing it (including the new performance optimization):
after

Signed-off-by: Aleksander Kamiński <[email protected]>
Signed-off-by: Aleksander Kamiński <[email protected]>
pijaro pushed a commit to RobotecAI/o3de-extras that referenced this pull request Nov 25, 2024
pijaro pushed a commit to RobotecAI/o3de-extras that referenced this pull request Nov 25, 2024
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!");
Copy link
Contributor

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?

Copy link
Contributor Author

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.

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]>
@jhanca-robotecai
Copy link
Contributor

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

@jhanca-robotecai
Copy link
Contributor

I've also found a new optimization which further improved performance by about ~4ms (for 1mln rays).

@alek-kam-robotec-ai can this optimization be used within the current implementation?

@alek-kam-robotec-ai
Copy link
Contributor Author

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

Yes.

@alek-kam-robotec-ai
Copy link
Contributor Author

I've also found a new optimization which further improved performance by about ~4ms (for 1mln rays).

@alek-kam-robotec-ai can this optimization be used within the current implementation?

This optimization is already implemented and was ported alongside other changes this PR made.

@jhanca-robotecai
Copy link
Contributor

Closing the PR. Please reopen if anything changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/simulation Categorizes an issue or PR as relevant to SIG Simulation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants