* Fix build status on front page.
Changes "googlecartographer" to "cartographer-project"
for references to CI and GitHub.
Following cartographer-project/cartographer#1693.
Signed-off-by: Wolfgang Hess <whess@lyft.com>
* Remove Indigo and Lunar Dockerfiles.
* Simplify start_trajectory.
* Ran clang-format.
* Make corrections based on the review
* Make corrections based on review #2, remove obsolete functions
* Remove unnecessary local variables
This `/trajectory_query` service allows to look up trajectory segments
from the pose graph.
This can be useful if one wants to get optimized trajectory data from
the current SLAM run and listening to live TF data would be too noisy.
For example, to stitch buffered point cloud data from a depth sensor
based on a recent localization trajectory segment of a robot.
Before, the pose graph trajectory nodes were not available except for
the trajectory marker topic (only positions, no orientation; inefficient)
or after serialization (which is not practical in live operation).
This allows to serialize the state also when no bagfile is given, e.g.
when the offline node is used to run an optimization and/or trimming
configuration on a pbstream. Or simply when one wants to use a custom
name directly. This doesn't break compatibility with the previous CLI.
I have added a few lines to the doc to alert users to remove ros abseil-cpp and also to change the rosinstall file if they wish to checkout a different version of cartographer. As discussed in #1208
Some service handlers need to check if a trajectory is in a valid
state for the requested operation. If it's not, they return an error
response.
`Node::CheckTrajectoryState` allows to avoid code duplication in such
situations.
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
The metrics registry is used as a raw pointer reference in map builder
and must outlive it.
Since C++ destroys in reverse declaration order, we have to put the
registry declaration before the map builder bridge.
Fixes#1234.
* Don't run final optimization in visualize_pbstream.launch
Replaces the offline node with the normal node.
The problem is that the offline node immediately runs a final
optimization with `visualize_pbstream.lua`, which is most likely not the
configuration that was used to generate the pbstream. This can lead to
effects like distortions in the map e.g. due to different weights, even
though the actual saved state is fine.
* Drop all /echoes or /imu messages.
* Use -start_trajectory_with_default_topics=false
* Consider waiting trajectories with a sensor bridge as active.
Fixes a corner case where trajectories that didn't start SLAMing yet
couldn't be finished, e.g. due to waiting for sensor data. They don't
appear in the trajectory states list of the pose graph yet but already
have a trajectory builder.
https://github.com/googlecartographer/cartographer/issues/1367
This fixes#1050. Tested standalone compilation and with the debian fakeroot tool. I had to build with a custom Protobuf3 instance though, so another build-check on a regular setup would be appreciated.
Before this change all *.cc files would be included. If subprojects
were run individually with the Debian package generator. This resulted in an
inclusion of temporarily checked out *.cc from the abseil include. This
change fixes the import behaviour and enables the creation of a valid
package.
This restructures the doc as a tutorial leading newcomers to becoming experimented users.
It adds pages on:
- how to get started with Cartographer on a new .bag
- how Cartographer works and can be tuned step-by-step
- how to use "extra" features of Cartographer
- how to contribute to Cartographer
It also provides some cosmethic changes with: new titles, non-indented code blocks, various illustrations, reworked paragraphs for clarity...
With two 20 Hz lidars and a 200 Hz IMU, the progress reports were outputted every 500 seconds, which is really too sparse to be useful. Decrease this by a factor of 10.
Fixes strange behavior with empty leftover entries in the trajectory list of the RViz plugin.
By using an `std::map` instead of an `std::vector` for the trajectories we can
easily erase trajectories which do not appear in the submap list anymore.
As @ojura reported and explained in #940, there is a critical issue with the new changes introduced in the mentioned PR, which significantly slows down the offline node.
- The reason of this problem was that In order to count the number of processed messages the `std::distance` function was used which is computationally expensive(O(n)).
- Instead, the former `log_counter_` and now `message_counter_` class variable which was used to print a message every X seconds is also employed to count the number of the processed (and also skipped) messages.
We have already a cloned source space in the base image, which can be
buggy according to: https://github.com/vcstools/wstool/issues/77
This should unblock Travis and fix local builds.
Set the visibility in he constructor, otherwise the setting won't have
an effect on newly created submap slices unless it's toggled again.
Somehow this got lost in #1012, sorry for that.
Wolfgang Hess
Bo Chen
Michael Grupp
Tully Foote
mgladkova
Ashwath Narayan Murali
fprott
Sebastian Klose
Esteve Fernandez
Juraj Oršulić
Matthias Loebach
Florent Revest
Alexander Belyaev
Alireza
Mikael Arguedas
Christoph Schütte