This should solve #1506.
- Use osrf/ros-<distro>-desktop as base image for CI
The basic ROS base image requires rosdep to install packages with many
dependencies, e.g. rviz. Using the desktop base image should speed up CI
because it has a good overlap with what we need and only little extra stuff.
- Remove apt list only after installing everything.
- Don't build protobuf 3 from source on Ubuntu 18 & 20.
It should come with rosdep. Only on Ubuntu 16 we need to build manually
because it ships with Protobuf 2.
- No need to build Ceres from source on Ubuntu 18 & 20.
The versions are greater or equal to 1.13, which is the one specified in
the source build script. The apt packages should work just fine.
The cartographer library is built from source in all cases, which is good to
ensure that we always test compatibility with the latest version of it.
- it has been used only at Google for a quality pipeline
- the worker.py is Python 2 and closely tied to Google Cloud, so I don't
believe there is much to be reused by someone else nowadays and not
worth the effort to port to Python 3.
Signed-off-by: Michael Grupp <grupp@magazino.eu>
cartographer-project/cartographer#1711 removed
building Abseil from the Cartographer library.
We follow here the same approach as in
cartographer CI.
An alternative approach which is now possible is
adding an Abseil package for catkin and depending
on that.
Signed-off-by: Wolfgang Hess <whess@lyft.com>
* 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.
Wolfgang Hess
Michael Grupp
Geonhee
Bo Chen
Tully Foote
mgladkova
Ashwath Narayan Murali
fprott
Sebastian Klose
Esteve Fernandez
Juraj Oršulić
Matthias Loebach
Florent Revest
Alexander Belyaev
Alireza
Mikael Arguedas