PR #1224 introduced checks for `collate_landmarks` and `collate_fixed_frame` in the `CollatedTrajectoryBuilder`. However, it falsely checks for `collate_landmarks` in the `AddSensorData(FixedFramePoseData)` function. This PR fixes that.
Consolidating pbstream tools into a single tool
* adds two subcommands for now (info and migrate)
* removes commandline flags for filenames in favor of commandline args
* updates documentation for migration tool
* [GenericPoseGraph] Add rotation 3d constraint.
* [GenericPoseGraph] Add serialization tests for constraints.
* Remove files from other branch
* Updated include paths.
Added new constructor for `RotationalScanMatcher` and exposed `RotateHistogram`.
This PR prepares for PR #1277 where the constructor
`RotationalScanMatcher(const std::vector<std::pair<Eigen::VectorXf, float>>& histograms_at_angles)`
will be removed and only the new constructor
`RotationalScanMatcher(const Eigen::VectorXf& histogram)`
will remain. The unit tests will be updated to use the new constructor in #1277.
Submap::ToProto now returns the proto.
This PR makes the interfaces for serialization more consistent: In `mapping_state_serialization.cc` all `ToProto` methods return the proto except Submap::ToProto.
* [GenericPoseGraph] Added relative pose cost 3d.
* Added another case to the test.
* Removed ceres function from cost function.
* Ran clang-format.
* Minor renaming.
When serializing `TrajectoryNode`, the declared proto is currently re-used. This can lead to unexpected behavior, in particular when the serialization of the proto is performed in an external function.
This PR also relates PR #1277 where exactly that problem occurred in the SerializeSubmaps.
Introduce separate mutex for PoseGraph3D work queue access.
This reduces lock contention, see issue #1250.
In particular higher frequency call to AddWorkItem
don't need to take the main mutex from the froground
thread anymore.
This PR introduces two metrics to measure performance of local slam: real time ratio, and cpu real time ratio. The latter is introduced to measure the headroom.
Real time ratio tells us how fast local slam processes the incoming sensor data. When SLAM is falling behind, this is below 100%. In the steady state it is 100% (The real time ratio is above 100% only when slam is 'catching up'.). So this does not tell us how much faster than real time slam processes the data. For this purpose the cpu real time ratio is introduced. It measures how much cpu time slam used, compared to the real time passed to collect the sensor data. Thus it can be more than 100% if slam is faster than real time. For example, a cpu real time ratio of 200% means that slam could process the data twice as fast as it comes in.
Three durations are measured:
- sensor_duration: the physical time it took to collect the sensor data.
- wall_time_duration: the time it took to process that data
- thread_cpu_duration: CPU time it took to process that data.
And the metrics then are:
real time ratio = sensor_duration / wall_time_duration
cpu real time ratio = sensor_duration / thread_cpu_duration
Martin Schwörer
Wolfgang Hess
Alexander Belyaev
Arno Fleck
Michael Grupp
Sebastian Klose
Martin Bokeloh
Susanne Pielawa
gaschler
Juraj Oršulić
danielsievers
Christoph Schütte
Steve Wolter