* [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
When preparing constraints make holding of the PoseGraph3D
mutex fine-grained to address lock contention from issue #1250.
That includes not holding the mutex when acquring the constraint
builder mutex.
Take PoseGraph3D mutex inside instead of outside work item
This refactors the code but does not alter behavior except
that the shared mutex is separately taken for work_queue_ access,
released, and then re-acquired inside each work item.
As a consequence AddWorkItem() also needs to EXCLUDE() the lock and
acquire it internally, because for the case where we run the task
in the foreground we cannot hold the lock and recursively acquire it again
inside the task being run.
This prepares for making locking more fine-grained, see issue #1250.
Adds value conversion tables to perform lazy computations of lookup tables for mapping from a uint16 value to a float in [`lower_bound`, `upper_bound`].
Owners of the value conversion tables are `SubmapController`, `PoseGraph2D`, `ActiveSubmaps` and `ProbabilityGridPointsProcessor`. For concurrency reasons, having only a single owner is not possible.
Follow up PR in `cartographer_ros` is prepared.
The first submap is now created with first call to `ActiveSubmaps:InsertRangeData`.
Originally the first submap was created at the origin. Creating the first submap with the first range data insertion allows to align the first submap with the gravity estimate of the first scan. This change makes the interface of ActiveSubmaps most consistent, as `ActiveSubmaps::submaps()` will return the correct active submaps after insertion.
The change affects the result of cartographer. The results were verified and provide the same quality as current master.
Unwrap the logic to dispatch optimization and the deferred
logic to create the work queue (when kicked off in foreground)
to happen in AddWorkItem() and HandleWorkQueue().
The work items will instead return whether they need optimization
to be dispatched or not.
This adds a .clang-format file, so that git clang-format uses
Google style without the need to remember the commandline flag.
Moreover, this ensures correct formatting if the Cartographer
code is in a subtree of a repo.
[PR 946](https://github.com/googlecartographer/cartographer/pull/946) introduced metrics in local trajectory builder. The accumulation duration was measured from accumulation_start to accumulation_stop.
This PR changes this to measure the entire time elapsed between two accumulations (i.e. from accumulation_stop to the next accumulation_stop).
Mostly the two measurements result in roughly the same, with the new way measuring slightly larger durations, as expected. But occasionally the measurements differ significantly. This is probably due to a lock contention somewhere outside of what was measured previously. Since we are interested in real time metrics, we need to track the entire time passed.
Extracted the ScanMatch method in the LocalTrajectoryBuilder3D.
This is a short refactoring. With that change, the code of LocalTrajectoryBuilder3D resembles LocalTrajectoryBuilder2D more. (see LocalTrajectoryBuilder2D::ScanMatch)
Removed redundant adaptive voxel fitering in trajectory builder 2d.
Adaptive voxel filtering of the lidar point cloud was performed in InsertIntoSubmap and ScanMatch. Both methods are called from AddAccumulatedRangeData. Now, adaptive voxel filtering is done only once in AddAccumulatedRangeData and the filtered point cloud is then forwarded to InsertIntoSubmap and ScanMatch.
Fixed unintentional casting of high_resolution_max_range from double to int, to float
In SubmapsOptions3D the parameter "high_resolution_max_range" is defined as double. In the code it gets casted to int when calling Submap3D::InsertRangeData and to float when calling FilterRangeDataByMaxRange.
Michael Grupp
Martin Bokeloh
Alexander Belyaev
gaschler
Martin Schwörer
Christoph Schütte
Steve Wolter
danielsievers
Juraj Oršulić
Susanne Pielawa
Kevin Daun
Wolfgang Hess
Arno Fleck