-
Notifications
You must be signed in to change notification settings - Fork 607
Feature: Creation of an Intensity Map #783
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
base: humble
Are you sure you want to change the base?
Conversation
|
@asoriano1 can you give us some metrics or examples of this in use for how much it improves localization and/or better addresses some situations that it previously didn't do well at? |
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.
Some preliminary notes
src/intensity_map_saver.cpp
Outdated
| #include <cstdlib> | ||
| #include "rclcpp/rclcpp.hpp" | ||
|
|
||
| namespace intensity_map_saver { |
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 there any difference here between this and the map saver? If not, this can be removed and we can just have 2x instances of the map_saver. One for the occ grid and another for the intensity map.
I think actually we should have them both run in the map_saver in 1 instance that way the maps are synchronized
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.
There is no difference between intensity_map_saver and map_saver but map_saver have not parametrize the name of the map, only the name of the topic. This means that if we use two instances of map_saver for different topics, we need to ensure that the output file names are different to avoid overwriting. When the service is called without specifying a map name, this is not an issue: two files are created (e.g., map.pgm and map_2.pgm).
However, if a file name is provided via the service, both savers would try to use the same name, which could lead to one overwriting the other. We could solve this by automatically adding a suffix based on the topic name (the only param we have), but then the final file name would no longer exactly match what the user specified in the service call.
Other option is to add a new parameter (e.g. bool) to MapSaver to specify if is_intensity or not. I'm not sure which approach is the least problematic.
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 think adding an argument for which to save could make sense, but I think the best is to save both in 1 instance of the map saver node. That way both are saved close to simultaneously. Then, we can just append _intensity (or whatever) to the service call for the intensity one.
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.
Done with 1 instance of the map saver node at 44a9829.
The service still receives just the "map_name" and it will save occupancy map as "map_name" and intensity map as "map_name_intensity".
b68f08f to
8d22542
Compare
…arameter. MEAN strategy is applied by default
…ED_MEAN fusion strategy
|
I jsut also noticed this is open against Humble. That's OK, but we will need one on |
| * @param gridIndex index | ||
| * @param intensity intensity value (p.e. 0 a 255) | ||
| */ | ||
| inline void SetIntensity(kt_int32s gridIndex, kt_int8u intensity) |
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 ... don't actually sett this or the GetIntensity function used anywhere. Should it be?
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.
Removed. The method and the file. Now all is managed by karto lib
src/slam_mapper.cpp
Outdated
| /*****************************************************************************/ | ||
| { | ||
| // Create the occupancy grid from scans | ||
| karto::OccupancyGrid * occ_grid = karto::OccupancyGrid::CreateFromScans( |
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 is very, very inefficient to call twice (once in just getOccupancyGrid above). Remove this function and get the intensity grid in the same getOccupancyGrid function.
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.
solved at 1c8bb3a.
Now everything is processed at Karto lib.
src/slam_mapper.cpp
Outdated
| // For each scan update the intensity grid | ||
| const auto & scans = mapper_->GetAllProcessedScans(); | ||
| for (auto scan : scans) { | ||
| slam_toolbox::updateIntensityGridFromScan(scan, occ_grid, *intensity_grid, min_intensity_threshold_, |
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.
Can the occ grid creation process not be combined with the intensity grid creation process? Doing this separately after iterating through all the data is very inefficient
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.
solved at 1c8bb3a.
Now everything is processed at Karto lib.
…ccupancyGrid class
…_intensity_counter parameter for intensity values storage
… and publishes them
…:msg::OccupancyGrid
…ginal map_saver updated to save occupancy and intensity maps
…ensure the range of the intensity values
…ring the intensity in a cell. Options are: mean, max, latest
|
@asoriano1 let me know if / when you're ready for another review! |
…ant prints removed
Basic Info
Description of contribution in a few bullet points
Description of documentation updates required from your changes
Future work that may be required in bullet points