This is to make it possible to use the proto definitions
from Python where the directory structure otherwise
prevents them from being imported in the usual way.
Signed-off-by: Wolfgang Hess <whess@lyft.com>
Adds a new field intensities to TimedPointCloudData.
RangeDataCollator now also takes intensities into account.
AddRangeData now takes a point cloud by value instead of
const reference as we would later make a copy of it anyway.
Signed-off-by: Wolfgang Hess <whess@lyft.com>
Adds a new structure IntensityHybridGrid, similar to HybridGrid
but which stores intensities instead of probabilities.
InterpolatedGrid is adapted to handle both types of HybridGrids.
Signed-off-by: Wolfgang Hess <whess@lyft.com>
It's essentially leading to buffering all submaps twice, which
is a high (~2x) peak in memory consumption during deserialization.
Don't convert anymore since this affects _all_ pbstreams and not only
the (probably few) old pbstreams that require the conversion.
Signed-off-by: Michael Grupp <grupp@magazino.eu>
This integrates the imu based extrapolator implementation, adds lua configuration and conversions from lua to proto. Note that the parameters of the imu based extrapolator are not tuned yet and the default is still the constant-velocity extrapolator.
Signed-off-by: mschworer <mschworer@lyft.com>
This makes use of the ExtrapolationResult returned by the pose extrapolator. ExtrapolationResult contains poses corresponding to the timestamps of range data measurements to be used for motion compensation. When using the PoseExtrapolator implementation there is no functional difference. This PR prepares the integration of ImuBasedPoseExtrapolator, which requires using ExtrapolationResult returned by ExtrapolatePosesWithGravity to run efficiently.
Signed-off-by: mschworer <mschworer@lyft.com>
This integrates the extrapolator interface into the 3D trajectory builder. The construction is now done within the interface and local trajectory builder 3D just makes use of the interface. No functional changes.
Signed-off-by: mschworer <mschworer@lyft.com>
This adds an alternative implementation for pose extrapolation which uses imu integration as well as past local SLAM results (and odometry data) to predict a pose. This allows to perform motion compensation and initialize scan matching afterwards.
Using imu data for pose extrapolation and motion compensation is more accurate, because it does not make a constant velocity assumption like the PoseExtrapolator implementation. Next steps are the integration into local trajectory builder as well as tuning the parameters for existing datasets.
This PR is quite large but was already reviewed in smaller chunks internally and combines contributions from @danielsievers, @wohe and @schwoere.
Signed-off-by: mschworer <mschworer@lyft.com>
This adds an interface around the extrapolator without further integration into any call sides.
Currently there is only a constant-velocity extrapolator implementation. The next step is to add an extrapolator implementation which integrates imu measurements for pose extrapolation.
Signed-off-by: mschworer <mschworer@lyft.com>
This fixes local constraint search in frozen maps built from multiple trajectories.
Local constraint search from a localization trajectory to a set of frozen trajectories
(i.e. the map) is done only among trajectories that are transitively connected in the
same connected component. If we set an initial pose, we create such a connection
to one frozen trajectory, but we were so far not able to do a local constraint search
w.r.t. to other frozen trajectories because they're not connected among each other.
Any constraints between them are not loaded (because they’re frozen).
This PR adds the possibility to use the TolerantLoss function for INS in pose graph optimization. This is currently switched off, and so there's not functional change.
The ceres TolerantLoss function (see [description](http://ceres-solver.org/nnls_modeling.html), and [implementation](https://github.com/ceres-solver/ceres-solver/blob/master/internal/ceres/loss_function.cc)) has the following property
- for large values of x it approaches a quadratic loss ("null loss") with the specified weight (fixed_frame_pose_translation_weight)
- for small values of x it approaches a quadratic loss with a smaller weight
- there's a crossover at some value x_c. The function is convex everywhere.
This fixes the bug that has been faced during localization with an initial pose and a trimmed map (OverlappingSubmapsTrimmer2D has been used). A small test is added that reproduces the problem (an infinite loop) where a trimmed trajectory (MapById instance) is used.
Apparently the format bot uses a bleeding edge clang-format that uses
the new Google style and reformats a bunch of files in every PR. This is
an empty commit to trigger this in a separate commit.
See 62e3198c4f
This commit add support of specifying the option to collate data by
trajectory introduced in #828 in the lua configuration files.
The value is set to false as when a boolean option is not specified it
is initialized to false.
Adds a metric family that monitors:
- the number of submaps in frozen trajectories
- the number of submaps in active trajectories
- the number of deleted/trimmed submaps
In the current implementation, as soon as one trajectory is frozen it is not possible to use new landmarks anymore.
In this PR a suggest a change, that allows introducing new landmarks also in the presence of a frozen trajectory. This is done with the following steps:
- Store set of frozen landmarks
- Landmarks that are loaded from a pbstream, with the flag ` load_frozen_state=true` are inserted into the set of frozen landmarks via `setLandmarkPose` function
- frozen landmarks are set constant in the optimization problem
- new landmarks can be introduced and will be optimized in the optimization problem
Motivated by and closes#1470
- use `pose_queue_duration_` instead of hardcoded "0.001"
(cartographer_ros sets this to 0.001, probably that's why this
wasn't noticed)
- queue_delta is in seconds, log message said milliseconds
Previously, two config values were spelled "bandwith".
The assumption is that these values are not used in other
repositories so the rename is harmless.
This PR makes libcartographer build on Windows (including tests). Abseil was bumped to avoid a MSVC compiler bug.
I have observed two tests failing:
`MapBuilderTestByGridType/MapBuilderTestByGridType.GlobalSlam2D/1` and `MapBuilderTestByGridType/MapBuilderTestByGridType.LocalizationOnFrozenTrajectory2D/1`.
Since the constraint builder metrics are ever-increasing, it makes sense
to add gauges that monitor the current counts of constraints in the pose
graph. The main advantages are that they also take trimming into account
and distinguish constraints within or across trajectories.
Wolfgang Hess
Michael Grupp
Martin Schwörer
Jihoon Lee
Susanne Pielawa
Phil
Mariia Gladkova
jie
damienrg
Kevin Daun
Jonathan Huber
Alex Millane
Andre Gaschler
Juraj Oršulić
Alexander Belyaev
Christoph Schütte