This is similar to cartographer-project/cartographer#1780, but
- we add a pull request template (there was none before)
- we refer to cartographer_ros CONTRIBUTING.md
- we give different instructions to execute cartographer_ros tests
Signed-off-by: Wolfgang Hess <whess@lyft.com>
This makes much more sense than 1.0.0, which is counter-intuitive.
If someone is building from source they usually do it to build the
latest bleeding-edge version.
Signed-off-by: Michael Grupp <grupp@magazino.eu>
I was running through these docs and having [trouble](https://github.com/googlecartographer/point_cloud_viewer/issues/389)
with map visualization via `point_cloud_viewer`.
Notably, color is required for plys ingested by `point_cloud_viewer` (in contrast to Meshlab).
This PR adds a note to make this clear.
Signed-off-by: Erik Reed <ereed.uw@gmail.com>
If the output of cartographer should be used as an input to an additional sensor fusion method,
using the published TF transform is inconvenient or in our specific use case even harmful
because we don't want to add the raw cartographer output to our TF tree.
With this change it becomes optional to broadcast to /tf.
Morever there is an option to publish the tracked frame pose as a PoseStamped message.
We add two new optional parameters:
- `publish_to_tf` if false no tf transform is broadcasted
- `publish_tracked_pose` If set `true` a PoseStamped representing the position of the
tracked pose w.r.t. map frame is published.
If default launchers and settings are used this PR causes no change in the behavior.
Fixes broken links, code blocks and other things that
`sphinx-build docs/source docs/out -E` complained about.
Signed-off-by: Michael Grupp <grupp@magazino.eu>
This uses the more modern issue template mechanism of GitHub.
Users will be able to choose one of these after clicking "add issue".
---
The template for tuning is reworded to reflect that tuning issues are
not guaranteed to be handled by maintainers.
Signed-off-by: Michael Grupp <grupp@magazino.eu>
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
Bo Chen
Daisuke Sato
Christian Clauss
iotboy
Mitchell Allain
jeongmyunglee
Linh Nguyen
Jonathan Huber
Michael Grupp
Mohamed Ahmed
Wolfgang Hess
stribor14
zhenzhenxiang
Erik Reed
Geonhee
Tully Foote
mgladkova
Ashwath Narayan Murali
fprott