[ octomap_mapping/octomap_server/cfg/OctomapServer.cfg
](https://github.com/OctoMap/octomap_mapping/blob/6e96c831795c664ba554bdff53844657a7916f83/octomap_server/cfg/OctomapServer.cfg#L12)


Name


No one assigned


Cancel  Create saved search


Released


* [ octomap_server ](/questions/scope:all/sort:activity-desc/tags:octomap_server/page:1/)


#  Search code, repositories, users, issues, pull requests...


**Package Links**


##  Stats


* [ octomap_mapping ](/octomap_mapping?distro=hydro)


Follow


###  octomap_server


**[ ndugdale ](/ndugdale) ** commented  Jul 27, 2021


    @ARTICLE{hornung13auro,
      author = {Armin Hornung and Kai M. Wurm and Maren Bennewitz and Cyrill
      Stachniss and Wolfram Burgard},
      title = {{OctoMap}: An Efficient Probabilistic {3D} Mapping Framework Based
      on Octrees},
      journal = {Autonomous Robots},
      year = 2013,
      url = {http://octomap.github.com},
      doi = {10.1007/s10514-012-9321-0},
      note = {Software available at \url{http://octomap.github.com}}
    }


Moravec H, Elfes A (1985) High resolution maps from wide angle
sonar. In: Proc. of the IEEE Int. Conf. on Robotics & Automation
(ICRA), St. Louis, MO, USA, pp 116–121
Muller J, Kohler N, Burgard W (2011) Autonomous miniature blimp ¨
navigation with online motion planning and re-planning. In: Proc. of
the IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)
Newcombe R, Izadi S, Hilliges O, Molyneaux D, Kim D, Davison
A, Kohli P, Shotton J, Hodges S, Fitzgibbon A (2011) KinectFusion: Real-time dense surface mapping and tracking. In: Mixed and
Augmented Reality (ISMAR), 2011 10th IEEE International Symposium on, IEEE, pp 127–136
Nuchter A, Lingemann K, Hertzberg J, Surmann H (2007) 6D ¨
SLAM—3D mapping outdoor environments: Research articles. J
Field Robot 24(8-9):699–722
Oßwald S, Hornung A, Bennewitz M (2012) Improved proposals for
highly accurate localization using range and vision data. In: Proc. of
the IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)
Pathak K, Birk A, Poppinga J, Schwertfeger S (2007) 3D forward sensor modeling and application to occupancy grid based sensor fusion.
In: Proc. of the IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)
Payeur P, Hebert P, Laurendeau D, Gosselin C (1997) Probabilistic octree modeling of a 3-d dynamic environment. In: Proc. of the IEEE
Int. Conf. on Robotics & Automation (ICRA)
Pfaff P, Triebel R, Stachniss C, Lamon P, Burgard W, Siegwart
R (2007) Towards mapping of cities. In: Proc. of the IEEE
Int. Conf. on Robotics & Automation (ICRA), Rome, Italy
Roth-Tabak Y, Jain R (1989) Building an environment model using
depth information. Computer 22(6):85–90
Ryde J, Hu H (2010) 3D mapping with multi-resolution occupied voxel
lists. Autonomous Robots 28(2):169–185
Schnabel R, Klein R (2006) Octree-based point-cloud compression. In:
Symposium on Point-Based Graphics 2006, Eurographics
Shade R, Newman P (2011) Choosing where to go: Complete 3D exploration with stereo. In: Proc. of the IEEE Int. Conf. on Robotics
& Automation (ICRA)
Sibley G, Mei C, Reid I, Newman P (2009) Adaptive relative bundle
adjustment. In: Proc. of Robotics: Science and Systems (RSS)
Smith M, Baldwin I, Churchill W, Paul R, Newman P (2009) The
new college vision and laser data set. International Journal for
Robotics Research (IJRR) 28(5):595–599, DOI http://dx.doi.org/10.
1177/0278364909103911
Stoyanov T, Magnusson M, Andreasson H, Lilienthal AJ (2010) Path
planning in 3d environments using the normal distributions transform. In: Proc. of the IEEE/RSJ Int. Conf. on Intelligent Robots and
Systems (IROS)
Sturm J, Engelhard N, Endres F, Burgard W, Cremers D (2012) A


octomap_server loads a 3D map (as Octree-based OctoMap) and distributes it to
other nodes in a compact binary format. It also allows to incrementally build
3D OctoMaps, and provides map saving in the node octomap_saver.


[ none ](/questions/scope:all/sort:activity-desc/tags:none/page:1/) ×


* Required transform of sensor data into the global map frame if you do scan integration. This information needs to be available from an external SLAM or localization node.


Open


* [ static_map ](/questions/scope:all/sort:activity-desc/tags:static_map/page:1/)


[ ndugdale ](/ndugdale) opened this issue  Jul 27, 2021  · 2 comments


#  Package Summary


You can’t perform that action at this time.


* [ kinetic ](/questions/scope:all/sort:activity-desc/tags:kinetic/page:1/)


  * **[ Code API ](http://docs.ros.org/indigo/api/octomap_server/html) **
  * [ FAQ ](http://answers.ros.org/questions/scope:all/sort:activity-desc/tags:octomap_server/page:1/)
  * [ Changelog ](http://docs.ros.org/en/indigo/changelogs/octomap_server/changelog.html)
  * [ Change List ](/octomap_mapping/ChangeList)
  * [ Reviews ](/octomap_server/Reviews)


BibTeX:


[ How to run Octomap from terminal? ](/question/249290/how-to-run-octomap-
from-terminal/)


* Distance threshold for points (in z direction) to be segmented to the ground plane


  * [ Terms ](https://docs.github.com/site-policy/github-terms/github-terms-of-service)
  * [ Privacy ](https://docs.github.com/site-policy/privacy-policies/github-privacy-statement)
  * [ Security ](/security)
  * [ Status ](https://www.githubstatus.com/)
  * [ Docs ](https://docs.github.com/)
  * [ Contact ](https://support.github.com?tags=dotcom-footer)
  * Manage cookies
  * Do not share my personal information


octomap_server loads a 3D map (as Octree-based OctoMap) and distributes it to
other nodes in a compact binary format. See octomap_saver on how to request or
save a map file. A visualization of the occupied cells is sent as MarkerArray.


Query


* Resolution in meter for the map when starting with an empty map. Otherwise the loaded file's resolution is used.


#  Saved searches


**Package Links**


10
·10−3
Resolution [m]
Time [ms]
Freiburg campus
Freiburg campus, trunc.
FR-079 corridor
FR-079 corridor, trunc.
Fig. 16 Average time to update an octree map by inserting one data
point for the datasets Freiburg campus and FR-079 corridor. The truncated versions insert rays up to a maximum sensor range of 10 m only.
0 1 2 3 4
10
20
30
40
50
Depth cutoff
Time [ms]
Freiburg campus (20 cm)
New College (20 cm)
FR-079 corridor (5 cm)
Fig. 17 Time to traverse all octree leaf nodes in several maps. By limiting the depth of the query (called depth cutoff) a coarser map is traversed.
represents an approximation of the full map, thus we use the
Kullback-Leibler divergence (KLD) summed over the complete map as measure. Since occupancy is a binary random
variable with the discrete states free and occupied, the KLD
of a clamped map Mc from the full map Mf can be computed
by summing over all map nodes n:
KLD(Mf
,Mc) = (10)
∑n

ln
P(n)
Q(n)

P(n) +ln
1−P(n)
1−Q(n)

(1−P(n))


[ ![ROS Answers logo](/m/ros/media/images/logoros.png?v=28) ](/questions/)


** Used by  (4) **


  * **[ Code API ](http://docs.ros.org/en/diamondback/api/octomap_server/html/) **
  * [ FAQ ](http://answers.ros.org/questions/scope:all/sort:activity-desc/tags:octomap_server/page:1/)
  * [ Reviews ](/octomap_server/Reviews)


  * [ Code  ](/OctoMap/octomap_mapping)
  * [ Issues  ](/OctoMap/octomap_mapping/issues)
  * [ Pull requests  ](/OctoMap/octomap_mapping/pulls)
  * [ Actions  ](/OctoMap/octomap_mapping/actions)
  * [ Projects  ](/OctoMap/octomap_mapping/projects)
  * [ Wiki  ](/OctoMap/octomap_mapping/wiki)
  * [ Security  ](/OctoMap/octomap_mapping/security)
  * [ Insights  ](/OctoMap/octomap_mapping/pulse)


10 Armin Hornung et al.
leaf nodes, or leaf nodes in a certain bounding box can be
queried or they can be filtered according to further criteria.
Ray intersection queries, i.e., casting a ray from an origin into a given direction until it hits an occupied volume,
are an important use-case for a 3D map in robotics. This kind
of query is used for visibility checks or to localize with range
sensors. Thus, we provide this functionality in the castRay(·)
method.
5 Evaluation
The approach presented in this paper has been evaluated using several real world datasets as well as simulated ones.
The experiments are designed to verify that the proposed
representation is meeting the requirements formulated in the
introduction. More specifically, we demonstrate that our approach is able to adequately model various types of environments and that it is an updatable and flexible map structure
that can be compactly stored.
For evaluation, we used the current implementation of
OctoMap 1.5.12
. The evaluated datasets are available online3
and can be converted from 3D point clouds into octree maps with the tool graph2tree, which also prints all
necessary statistics.
5.1 Sensor Model for Laser Range Data
OctoMap can be used with any kind of distance sensor, as
long as an inverse sensor model is available. Since our realworld datasets were mostly acquired with laser range finders, we employ a beam-based inverse sensor model which
assumes that endpoints of a measurement correspond to obstacle surfaces and that the line of sight between sensor origin end endpoint does not contain any obstacles. The occupancy probability of all volumes is initialized to the uniform prior of P(n) = 0.5. To efficiently determine the map
cells which need to be updated, a ray-casting operation is
performed that determines voxels along a beam from the
sensor origin to the measured endpoint. For efficiency, we
use a 3D variant of the Bresenham algorithm to approximate
the beam (Amanatides and Woo, 1987). Volumes along the
beam are updated as described in Sect. 3.2 using the following inverse sensor model:
L(n | zt) = (
locc if beam is reflected within volume
lfree if beam traversed volume
(7)
Throughout our experiments, we used log-odds values of
locc = 0.85 and lfree = −0.4, corresponding to probabilities
of 0.7 and 0.4 for occupied and free volumes, respectively.
2 https://github.com/OctoMap/octomap/archive/v1.5.3.tar.gz
3 http://ais.informatik.uni-freiburg.de/projects/datasets/octomap surface sensor
surface
sensor


  * [ Code  ](/OctoMap/octomap_mapping)
  * [ Issues  27  ](/OctoMap/octomap_mapping/issues)
  * [ Pull requests  7  ](/OctoMap/octomap_mapping/pulls)
  * [ Actions  ](/OctoMap/octomap_mapping/actions)
  * [ Projects  0  ](/OctoMap/octomap_mapping/projects)
  * [ Wiki  ](/OctoMap/octomap_mapping/wiki)
  * [ Security  ](/OctoMap/octomap_mapping/security)
  * [ Insights  ](/OctoMap/octomap_mapping/pulse)


I have been trying to use the octomap_server to generate an OctoMap that goes
up to +/- 120 from the map origin. Points outside the +/-100 range are
excluded from the OctoMap, despite setting larger parameter values for
pointcloud_[min|max]_z in the launch file.


For


** Used by  (3) **


[ tags ](/tags/) [ users ](/users/) [ badges ](/badges/)


** Dependencies  (6) **


  * [ arm_navigation_msgs ](/arm_navigation_msgs?distro=electric)
  * [ dynamic_reconfigure ](/dynamic_reconfigure?distro=electric)
  * [ nav_msgs ](/nav_msgs?distro=electric)
  * [ octomap ](/octomap?distro=electric)
  * [ octomap_ros ](/octomap_ros?distro=electric)
  * [ pcl_ros ](/pcl_ros?distro=electric)
  * [ std_msgs ](/std_msgs?distro=electric)
  * [ std_srvs ](/std_srvs?distro=electric)
  * [ visualization_msgs ](/visualization_msgs?distro=electric)


!/usr/bin/env python
PACKAGE = "octomap_server"

from dynamic_reconfigure.parameter_generator_catkin import *

gen = ParameterGenerator()

gen.add("compress_map", bool_t, 0, "Compresses the map losslessly", True)
gen.add("incremental_2D_projection", bool_t, 0, "Incremental 2D projection", False)
gen.add("filter_speckles", bool_t, 0, "Filter speckle nodes (with no neighbors)", False)
gen.add("max_depth", int_t, 0, "Maximum depth when traversing the octree to send out markers. 16: full depth / max. resolution", 16, 1, 16)
gen.add("pointcloud_min_z", double_t, 0, "Minimum height of points to consider for insertion", -100, -100, 100)
gen.add("pointcloud_max_z", double_t, 0, "Maximum height of points to consider for insertion", 100, -100, 100)
gen.add("occupancy_min_z", double_t, 0, "Minimum height of occupied cells to consider in the final map", -100, -100, 100)
gen.add("occupancy_max_z", double_t, 0, "Maximum height of occupied cells to consider in the final map", 100, -100, 100)
gen.add("sensor_model_max_range", double_t, 0, "Sensor maximum range", -1.0, -1.0, 100)
gen.add("sensor_model_min_range", double_t, 0, "Sensor minimum range", -1.0, -1.0, 100)
gen.add("sensor_model_hit", double_t, 0, "Probabilities for hits in the sensor model when dynamically building a map", 0.7, 0.5, 1.0)
gen.add("sensor_model_miss", double_t, 0, "Probabilities for misses in the sensor model when dynamically building a map", 0.4, 0.0, 0.5)
gen.add("sensor_model_min", double_t, 0, "Minimum probability for clamping when dynamically building a map", 0.12, 0.0, 1.0)
gen.add("sensor_model_max", double_t, 0, "Maximum probability for clamping when dynamically building a map", 0.97, 0.0, 1.0)
gen.add("filter_ground", bool_t, 0, "Filter ground plane", False)
gen.add("ground_filter_distance", double_t, 0, "Distance threshold to consider a point as ground", 0.04, 0.001, 1)
gen.add("ground_filter_angle", double_t, 0, "Angular threshold of the detected plane from the horizontal plane to be detected as ground ", 0.15, 0.001, 15)
gen.add("ground_filter_plane_distance", double_t, 0, "Distance threshold from z=0 for a plane to be detected as ground", 0.07, 0.001, 1)

exit(gen.generate(PACKAGE, "octomap_server_node", "OctomapServer"))


I can see that my launch file is correctly accessing the parameters, because
if I instead set the pointcloud_[min|max]_z to have a magnitude less than
-/+100 (e.g. -/+20), these values will be reflected in the terminal with,


Search or jump to...


* Static global frame in which the map will be published. A transform from sensor data to this frame needs to be available when dynamically building maps.


An extension of octomap_server to publish multilayer projected 2D maps, used
by the [ 3d_navigation ](/3d_navigation) stack. Subscriptions and publications
are mostly identical to the octomap_server node.


#  Package Summary


_**[ octomap_mapping ](/octomap_mapping?distro=groovy) ** : octomap_server _


` ~sensor_model/max_range ` ( ` float ` , default: -1 (unlimited))


Multiple Projected Maps from Octomap-Server with different heights


No milestone


  * [ catkin ](/catkin?distro=hydro)
  * [ dynamic_reconfigure ](/dynamic_reconfigure?distro=hydro)
  * [ libpcl-all ](/libpcl-all?distro=hydro)
  * [ libpcl-all-dev ](/libpcl-all-dev?distro=hydro)
  * [ nav_msgs ](/nav_msgs?distro=hydro)
  * [ nodelet ](/nodelet?distro=hydro)
  * [ octomap ](/octomap?distro=hydro)
  * [ octomap_msgs ](/octomap_msgs?distro=hydro)
  * [ octomap_ros ](/octomap_ros?distro=hydro)
  * [ pcl_conversions ](/pcl_conversions?distro=hydro)
  * [ pcl_ros ](/pcl_ros?distro=hydro)
  * [ roscpp ](/roscpp?distro=hydro)
  * [ sensor_msgs ](/sensor_msgs?distro=hydro)
  * [ std_msgs ](/std_msgs?distro=hydro)
  * [ std_srvs ](/std_srvs?distro=hydro)
  * [ visualization_msgs ](/visualization_msgs?distro=hydro)


To see all available qualifiers, see our [ documentation
](https://docs.github.com/search-github/github-code-search/understanding-
github-code-search-syntax) .


Cancel  Submit feedback


** Dependencies  (16) **


Autonomous Robots (2013)
Preprint, final version available at DOI 10.1007/s10514-012-9321-0
OctoMap:
An Efficient Probabilistic 3D Mapping Framework Based on Octrees
Armin Hornung · Kai M. Wurm · Maren Bennewitz ·
Cyrill Stachniss · Wolfram Burgard
Received: 30 April 2012 / Accepted: 31 December 2012
Abstract Three-dimensional models provide a volumetric
representation of space which is important for a variety of
robotic applications including flying robots and robots that
are equipped with manipulators. In this paper, we present an
open-source framework to generate volumetric 3D environment models. Our mapping approach is based on octrees and
uses probabilistic occupancy estimation. It explicitly represents not only occupied space, but also free and unknown
areas. Furthermore, we propose an octree map compression
method that keeps the 3D models compact. Our framework
is available as an open-source C++ library and has already
been successfully applied in several robotics projects. We
present a series of experimental results carried out with real
robots and on publicly available real-world datasets. The results demonstrate that our approach is able to update the
representation efficiently and models the data consistently
while keeping the memory requirement at a minimum.
Keywords 3D · Probabilistic · Mapping · Navigation
1 Introduction
Several robotic applications require a 3D model of the environment. These include airborne, underwater, outdoor, or
extra-terrestrial missions. However, 3D models are also relevant for many domestic scenarios, for example, for mobile
manipulation and also navigation tasks.
This work has been supported by the German Research Foundation
(DFG) under contract number SFB/TR-8 and by the European Commission under grant agreement numbers FP7-248258-First-MM and
FP7-600890-ROVINA.
A. Hornung · K.M. Wurm · M. Bennewitz · C. Stachniss · W. Burgard
Department of Computer Science, University of Freiburg,
Georges-Koehler-Allee 74, 79110 Freiburg, Germany
E-mail: {hornunga,wurm,maren,stachnis,burgard}@informatik.unifreiburg.de
Although 3D mapping is an integral component of many
robotic systems, there exist few readily available, reliable,
and efficient implementations. The lack of such implementations leads to the re-creation of basic software components
and, thus, can be seen as a bottleneck in robotics research.
We therefore believe that the development of an open-source
3D mapping framework will greatly facilitate the development of robotic systems that require a three-dimensional geometric representation of the environment.
Most robotics applications require a probabilistic representation, modeling of free, occupied, and unmapped areas, and additionally efficiency with respect to runtime and


_**[ octomap_mapping ](/octomap_mapping?distro=indigo) ** : octomap_server _


* Resets the complete map


is considered to be occupied when the threshold is reached
and is assumed to be free otherwise, thereby defining two
discrete states. From Eq. (2) it is evident that to change the
state of a voxel we need to integrate as many observations
as have been integrated to define its current state. In other
words, if a voxel was observed free for k times, then it has
to be observed occupied at least k times before it is considered occupied according to the threshold (assuming that
free and occupied measurements are equally likely in the
sensor model). While this property is desirable in static environments, a mobile robot is often faced with temporary or
permanent changes in the environment and the map has to
adapt to these changes quickly. To ensure this adaptability,
Yguel et al. (2007a) proposed a clamping update policy that
defines an upper and lower bound on the occupancy estimate. Instead of using Eq. (2) directly, occupancy estimates
6 Armin Hornung et al.
are updated according to
L(n | z1:t) = (4)
max(min(L(n | z1:t−1) +L(n | zt),lmax),lmin),
where lmin and lmax denote the lower and upper bound on
the log-odds value. Intuitively, this modified update formula
limits the number of updates that are needed to change the
state of a voxel. Applying the clamping update policy in our
approach leads to two advantages: we ensure that the confidence in the map remains bounded and as a consequence the
model can adapt to changes in the environment quickly. Furthermore, we are able to compress neighboring voxels with
pruning (see Sect. 3.4). As we will discuss in Sect. 5.4, this
leads to a considerable reduction in the number of voxels
that have to be maintained. The compression achieved with
clamping is no longer completely lossless in terms of the full
probabilities, since information close to zero and one is lost.
In between the clamping thresholds, however, full probabilities are preserved.
3.3 Multi-Resolution Queries
When measurements are integrated into our map structure,
probabilistic updates are performed only for the leaf nodes
in the octree. But since an octree is a hierarchical data structure, we can make use of the inner nodes in the tree to enable
multi-resolution queries. Observe that we yield a coarser
subdivision of the 3D space when the tree is traversed only
up to a given depth that is not the depth of the leaf nodes.
Each inner node spans the volume that its eight children occupy, so to determine the occupancy probability of an inner
node, we have to aggregate the probabilities of its children.
Several strategies could be pursued to determine the occupancy probability of a node n given its eight sub-volumes ni
(Kraetzschmar et al., 2004). Depending on the application at


* Whether the ground plane should be detected and ignored from scan data when dynamically building a map, using pcl::SACMODEL_PERPENDICULAR_PLANE. This clears everything up to the ground, but will not insert the ground as obstacle in the map. If this is enabled, it can be further configured with the ~ground_filter/... parameters.


* Minimum and maximum height of points to consider for insertion in the callback. Any point outside of this intervall will be discarded before running any insertion or ground plane filtering. You can do a rough filtering based on height with this, but if you enable the ground_filter this interval needs to include the ground plane.


of this section.
Yguel et al. (2007b) presented a 3D map based on
the Haar wavelet data structure. This representation is also
multi-resolution and probabilistic. However, the authors did
not evaluate applications to 3D modeling in-depth. In their
evaluation, unknown areas are not modeled and only a single simulated 3D dataset is used. Whether this map structure
is as memory-efficient as octrees is hard to assess without a
publicly available implementation.
Surface representations such as the 3D Normal Distribution Transform (Magnusson et al., 2007) or Surfels (Habbecke and Kobbelt, 2007) were recently used for
3D path planning (Stoyanov et al., 2010) and object modeling (Weise et al., 2009; Krainin et al., 2011). Similarly, an
accurate real-time 3D SLAM system based on a low-cost
depth camera and GPU processing was proposed by Newcombe et al. (2011) to reconstruct dense surfaces in indoor
scenes. Recently, this work has been extended to work in
larger indoor environments (Whelan et al., 2012). However,
surface representations are unable to distinguish between
free and unknown space, may require large memory particularly outdoors, and are often based on strong assumptions
about the corresponding environment. In mobile manipulation scenarios, for example, being able to differentiate free
from unknown space is essential for safe navigation.
Finally, to the best of our knowledge, no open source implementation of a 3D occupancy mapping framework meeting the requirements outlined in the introduction is freely
available.
3 OctoMap Mapping Framework
The approach proposed in this paper uses a tree-based representation to offer maximum flexibility with regard to the
mapped area and resolution. It performs a probabilistic occupancy estimation to ensure updatability and to cope with
sensor noise. Furthermore, compression methods ensure the
compactness of the resulting models.
3.1 Octrees
An octree is a hierarchical data structure for spatial subdivision in 3D (Meagher, 1982; Wilhelms and Van Gelder,
1992). Each node in an octree represents the space contained
in a cubic volume, usually called a voxel. This volume is
recursively subdivided into eight sub-volumes until a given
minimum voxel size is reached, as illustrated in Fig. 2. The
minimum voxel size determines the resolution of the octree.
Since an octree is a hierarchical data structure, the tree can
be cut at any level to obtain a coarser subdivision if the inner nodes are maintained accordingly. An example of an ocFig. 2 Example of an octree storing free (shaded white) and occupied
(black) cells. The volumetric model is shown on the left and the corresponding tree representation on the right.
Fig. 3 By limiting the depth of a query, multiple resolutions of the
same map can be obtained at any time. Occupied voxels are displayed
in resolutions 0.08 m, 0.64 , and 1.28 m.
tree map queried for occupied voxels at several resolutions
is shown in Fig. 3.


We read every piece of feedback, and take your input very seriously.


octomap_server loads a 3D map (as Octree-based OctoMap) and distributes it to
other nodes in a compact binary format. See octomap_saver on how to request or
save a map file. A visualization of the occupied cells is sent as MarkerArray.


` ~height_map ` ( ` bool ` , default: true)


[ Is there a way to extract the edge with coordinates out of occupancy map in
ROS? ](/question/375526/is-there-a-way-to-extract-the-edge-with-coordinates-
out-of-occupancy-map-in-ros/)


Resources


  * **[ Code API ](http://docs.ros.org/hydro/api/octomap_server/html) **
  * [ FAQ ](http://answers.ros.org/questions/scope:all/sort:activity-desc/tags:octomap_server/page:1/)
  * [ Changelog ](http://docs.ros.org/en/hydro/changelogs/octomap_server/changelog.html)
  * [ Change List ](/octomap_mapping/ChangeList)
  * [ Reviews ](/octomap_server/Reviews)


* **noetic:** _Documentation generated on March 26, 2024 at 10:15 AM_ ( [ doc job ](https://build.ros.org/view/Ndoc/job/Ndoc__octomap_mapping__ubuntu_focal_amd64) ).


#  Page


  * Author: Armin Hornung
  * License: BSD
  * Source: svn [ http://alufr-ros-pkg.googlecode.com/svn/trunk/octomap_stacks/octomap_mapping ](http://alufr-ros-pkg.googlecode.com/svn/trunk/octomap_stacks/octomap_mapping)


Documented


` ~latch ` ( ` bool ` , default: True for a static map, false if no initial
map is given)


` octomap_binary ` ( [ octomap_msgs/GetOctomap
](http://docs.ros.org/en/api/octomap_msgs/html/srv/GetOctomap.html) )


#  Package Summary


  * [ jsk_pcl_ros ](/jsk_pcl_ros?distro=jade)
  * [ jsk_pcl_ros_utils ](/jsk_pcl_ros_utils?distro=jade)
  * [ octomap_mapping ](/octomap_mapping?distro=jade)


Projects


* All occupied voxels as "box" markers for visualization in RViz. Be sure to subscribe to the topic **occupied_cells_vis** in RViz!


` sensor data frame ` → ` /map (static world frame, changeable with parameter
frame_id) `


👍  1  Copolococo reacted with thumbs up emoji


` ~reset ` ( [ std_srvs/Empty
](http://docs.ros.org/en/api/std_srvs/html/srv/Empty.html) )


**Have a question about this project?** Sign up for a free GitHub account to
open an issue and contact its maintainers and the community.


First time here? Check out the FAQ!


** Dependencies  (14) **


General information about OctoMap is available at [ http://octomap.github.com
](http://octomap.github.com) and in the publication [ "OctoMap: An Efficient
Probabilistic 3D Mapping Framework Based on Octrees"
](http://www.informatik.uni-freiburg.de/~hornunga/pub/hornung13auro.pdf) by A.
Hornung, K. M. Wurm, M. Bennewitz, C. Stachniss, and W. Burgard (Autonomous
Robots Journal, 2013).


  * [ jsk_pcl_ros ](/jsk_pcl_ros?distro=indigo)
  * [ jsk_pcl_ros_utils ](/jsk_pcl_ros_utils?distro=indigo)
  * [ octomap_mapping ](/octomap_mapping?distro=indigo)


**Package Links**


* Solutions


that is on top of the floor and several household objects are
in turn represented as submaps on top of the table.
Compared to a single, monolithic map of the environment, our hierarchical approach exhibits a number of advantages: First, each submap is maintained independently and
mapping parameters such as the resolution can be adapted
for each submap. Second, submaps can be manipulated independently. For example, one of the submaps representing
an individual object can be moved while the rest remains
static. Third, hierarchical dependencies of submaps can be
encoded in the hierarchy. For example, all objects on a table
can be associated to this table and if the table is moved then
the objects are moved along with it.
The approach has been evaluated in the context of tabletop manipulation. Objects on a table were mapped at very
fine resolutions while the table and background structures
were mapped at lower resolutions. This approach led to
models that were about an order of magnitude more compact than a single map that represents the complete scene.
4 Implementation Details
4.1 Memory-Efficient Node Implementation
In a straight-forward octree implementation, each node in
the tree stores in addition to the data payload the coordinate of its center location, its voxel size, and pointers to its
children. This, however, can lead to a substantial memory
overhead. Since the node location and its voxel size can be
reconstructed while traversing the octree, we do not explicitly store this information in the nodes to reduce the memory
overhead.
In general, octree nodes need to maintain an ordered list
of their children. This can be directly achieved by using
eight pointers per node. If sparse data are modeled, the memory requirement of those pointers (8×4 byte = 32 byte on a
8 Armin Hornung et al.
32 bit architecture) will lead to a significant memory overhead (Wilhelms and Van Gelder, 1992). We overcome that
by using one child pointer per node that points to an array of
eight pointers (Fig. 7, left). This array is only allocated if the
node indeed has children and is not allocated for leaf nodes.
Thus, any leaf node in the octree only stores the mapping
data itself (e.g., the occupancy probability) and one (null)
pointer. Inner nodes additionally store eight pointers to their
children. In the robotics-related datasets used in our evaluation, 80% – 85% of the octree nodes are leafs. In our experiments, the above-mentioned implementation saves 60% –
65% of memory compared to allocating 8 pointers for each
node.
To store a per-voxel occupancy probability, a single float
value (usually 4 byte) is sufficient to represent the log-odds
value. This results in a node size of 40 byte for inner nodes
and 8 byte for leafs on a 32-bit architecture. Note that most


Repositories


Octree compression
ML Octree compression
Fig. 15 Effect of resolution on memory usage of the Freiburg campus
dataset. Note that a logarithmic scaling is used.
maximum range of 10 m for several resolutions. The average
insert times for one beam are given in Fig. 16.
In our experiments, 3D scans usually consisted of about
90 000 – 250 000 valid measurements. Typically, such a scan
could be integrated into the map in less than a second. This
demonstrates that our current implementation can cope even
with the demanding data of RGBD-cameras that output up
to 300 000 points at fast frame rates, albeit at shorter ranges.
With long measurement beams and large outdoor areas
as in Freiburg campus dataset, a speedup can be obtained by
limiting the map update range. Indoors, however, where only
few sensor beams reach far, there is no noticeable speedup
by limiting the sensor range.
5.5.2 Map Queries
We evaluated the time to traverse all leaf nodes (free or occupied) in an existing map using iterators (see Sect. 4.4.2).
The depth of a query can be limited during run time which
in our data structure is equivalent to a map query in a coarser
map. This allows for more efficient tree traversals in those
cases when a coarser resolution is sufficient.
Figure 17 shows the time to traverse several maps to
their maximum tree depth of 16 corresponding to the full
map resolution (depth cutoff=0). The plot furthermore gives
the times to query all leaf nodes when the query depth is
limited. Each increment in the depth cutoff doubles the edge
length of the smallest voxels and speeds up the traversal by a
factor of about two. It can be seen that map traversals are efficient. Even at full map resolution, the large map of the Freiburg campus containing 1 087 014 occupied and 3 377 882
free leaf nodes can be traversed within 51 ms.
5.6 Clamping parameters
Finally, we analyzed the impact of the clamping thresholds
on map accuracy and compression. Since these thresholds
provide a lower and upper bound for the occupancy probability, information close to P = 0 and P = 1 is lost compared to the full map with no clamping. A clamped map
0.1 0.2 0.4 0.8 1
0
2.5
5
7.5


0
50
100
Scan number
Memory [MB]
FR-079 corridor (5 cm res.)
Full 3D grid
No compression
Octree compression
ML octree compression
20 40 60 80
0
200
400
600
Scan number
Memory [MB]
Freiburg campus (20 cm res.)
Full 3D grid
No compression
Octree compression
ML octree compression
Fig. 14 Memory usage while mapping the two data sets FR-079 corridor and Freiburg campus.
were evaluated on a single core of a standard desktop CPU
(Intel Core i7-2600, 3.4 GHz) for various map data sets.
5.5.1 Map Generation
First, we analyzed the time required to generate maps by
integrating range data. This time depends on the map resolution and the length of the beams that are integrated. We
processed the FR-079 corridor and Freiburg campus datasets
both with the full laser range (up to 50 m) and with a limited
14 Armin Hornung et al.
0.1 0.2 0.4 0.8 1 2
100
101
102
103
Resolution [m]
Memory [MB]
Full 3D grid
No compression


* **electric:** _Documentation generated on March 05, 2013 at 12:07 PM_


#  octomap_server pointcloud_[min|max_z] and occupancy_[min|max]_z parameters
only allow values up to -/+100  #90


* **indigo:** _Documentation generated on June 09, 2019 at 03:09 AM_ ( [ doc job ](http://build.ros.org/view/Idoc/job/Idoc__octomap_mapping__ubuntu_trusty_amd64) ).


current implementation. This enables fast tree traversals by
using computable voxel addresses. However, the depth limit
also poses a limit on the maximum spatial extent of the octree. At a resolution of 1 cm, for example, the map can cover
a maximum of 216 ×0.01m = 655.36m in each dimension.
While this is sufficient for most indoor applications, the implementation can directly be extended to 32 depth levels,
allowing to cover 232 ×0.01m = 42 949 672.96m at a resolution of 1 cm.
4.3 Map File Generation
Many robotic applications require maps to be stored in files.
This includes cases where a map is generated during a setup
phase and is later used by mobile robots for path planning
OctoMap: An Efficient Probabilistic 3D Mapping Framework Based on Octrees 9
and localization. Another scenario is a multi-robot system
where maps are exchanged between robots. In either case,
a compact serialized representation is required to minimize
the consumption of disk space or communication bandwidth.
The most compact files can be generated whenever a
maximum likelihood estimate of the map is sufficient for the
task at hand. In this case the per-node probabilities are discarded. As motivated above, volumes in which no information has been recorded can be of special interest in robotic
systems, for example, during exploration. For this reason,
we explicitly differentiate between free and unknown areas
and encode nodes as either occupied, free, unknown, or as
inner nodes in our map files. Using these labels, octree maps
can be recursively encoded as a compact bit stream. Each
node is represented only by the eight labels of its children.
Beginning at the root node, each child that is not a leaf is
recursively added to the bit stream. Leaf nodes do not have
to be added since they can be reconstructed from their label
during the decoding process. Figure 7 (right) illustrates the
bit-stream encoding. Each row represents one node with the
upper row corresponding to the root node. The last row only
contains leafs so no further nodes are added.
In this maximum likelihood representation, each node
occupies 16 bits of memory, 2 bits per child, resulting in a
compact map file. In our experiments, file sizes never exceeded 15 MB even for large outdoor environments at a fine
resolution (see Sect. 5.4 for details).
There exist applications in which all information in a
map needs to be stored and maintained. This includes cases
in which hard disk space is used as a secondary memory and
maps are temporarily saved to disk until they need to be accessed again. Another use case is the storage of additional
node data such as color or terrain information which would


In its most basic form, octrees can be used to model a
Boolean property. In the context of robotic mapping, this
is usually the occupancy of a volume. If a certain volume
is measured as occupied, the corresponding node in the octree is initialized. Any uninitialized node could be free or
unknown in this Boolean setting. To resolve this ambiguity, we explicitly represent free volumes in the tree. These
are created in the area between the sensor and the measured
end point, e.g., along a ray determined with raycasting. Areas that are not initialized implicitly model unknown space.
An illustration of an octree containing free and occupied
nodes from real laser sensor data can be seen in Fig. 4. Using
Boolean occupancy states or discrete labels allows for compact representations of the octree: If all children of a node
have the same state (occupied or free) they can be pruned.
This leads to a substantial reduction in the number of nodes
that need to be maintained in the tree.
In robotic systems, one typically has to cope with sensor noise and temporarily or permanently changing environments. In such cases, a discrete occupancy label will not
be sufficient. Instead, occupancy has to be modeled probabilistically, for instance by applying occupancy grid mapping (Moravec and Elfes, 1985). However, such a probabilistic model lacks the possibility of lossless compression
by pruning.
The approach presented in this paper offers means of
combining the compactness of octrees that use discrete labels with the updatability and flexibility of probabilistic
modeling as we will discuss in Sect. 3.4.
OctoMap: An Efficient Probabilistic 3D Mapping Framework Based on Octrees 5
Fig. 4 An octree map generated from example data. Left: Point cloud recorded in a corridor with a tilting laser range finder. Center: Octree
generated from the data, showing occupied voxels only. Right: Visualization of the octree showing occupied voxels (dark) and free voxels (white).
The free areas are obtained by clearing the space on a ray from the sensor origin to each end point. Lossless pruning results in leaf nodes of
different sizes, mostly visible in the free areas on the right.
In terms of data access complexity, octrees require an
overhead compared to a fixed-size 3D grid due to the tree
structure. A single, random query on a tree data structure
containing n nodes with a tree depth of d can be performed
with a complexity of O(d) = O(logn). Traversing the complete tree in a depth-first manner requires a complexity of
O(n). Note that, in practice, our octree is limited to a fixed
maximum depth dmax. This results in a random node lookup
complexity of O(dmax) with dmax being constant. Therefore,
for a fixed depth dmax, the overhead compared to a corresponding 3D grid is constant. Note that in all our experiments a maximum depth of 16 was used, which is sufficient
to cover a cube with a vollume of (655.36 m)
3
at 1 cm resolution. The exact timings for this setting are provided in
Sect. 5.5.
3.2 Probabilistic Sensor Fusion
In our approach, sensor readings are integrated using occupancy grid mapping as introduced by Moravec and Elfes
(1985). The probability P(n | z1:t) of a leaf node n to be occupied given the sensor measurements z1:t


    * [ Actions  Automate any workflow  ](/features/actions)
    * [ Packages  Host and manage packages  ](/features/packages)
    * [ Security  Find and fix vulnerabilities  ](/features/security)
    * [ Codespaces  Instant dev environments  ](/features/codespaces)
    * [ Copilot  Write better code with AI  ](/features/copilot)
    * [ Code review  Manage code changes  ](/features/code-review)
    * [ Issues  Plan and track work  ](/features/issues)
    * [ Discussions  Collaborate outside of code  ](/features/discussions)


Development


* **diamondback:** _Only showing information from the released package extracted on Unknown. No API documentation available. Please see[ this page ](http://wiki.ros.org/rosdistro/Tutorials/Indexing%20Your%20ROS%20Repository%20for%20Documentation%20Generation) for information on how to submit your repository to our index. _


#  User


#  Package Summary


` octomap_full ` ( [ octomap_msgs/Octomap
](http://docs.ros.org/en/api/octomap_msgs/html/msg/Octomap.html) )


** Dependencies  (9) **


Continuous Integration


  * **[ Code API ](http://docs.ros.org/jade/api/octomap_server/html) **
  * [ FAQ ](http://answers.ros.org/questions/scope:all/sort:activity-desc/tags:octomap_server/page:1/)
  * [ Changelog ](http://docs.ros.org/en/jade/changelogs/octomap_server/changelog.html)
  * [ Change List ](/octomap_mapping/ChangeList)
  * [ Reviews ](/octomap_server/Reviews)


  * Maintainer status: maintained
  * Maintainer: Armin Hornung <armin AT hornung DOT io>
  * Author: Armin Hornung
  * License: BSD
  * Bug / feature tracker: [ https://github.com/OctoMap/octomap_mapping/issues ](https://github.com/OctoMap/octomap_mapping/issues)
  * Source: git [ https://github.com/OctoMap/octomap_mapping.git ](https://github.com/OctoMap/octomap_mapping) (branch: indigo-devel)


Sorry, something went wrong.


**Package Links**


Toggle navigation


[ Sign in
](/login?return_to=https%3A%2F%2Fgithub.com%2FOctoMap%2Foctomap_mapping%2Fissues%2F90)


  * [ jsk_pcl_ros ](/jsk_pcl_ros?distro=noetic)
  * [ jsk_pcl_ros_utils ](/jsk_pcl_ros_utils?distro=noetic)
  * [ octomap_mapping ](/octomap_mapping?distro=noetic)


` ~resolution ` ( ` float ` , default: 0.05)


* The robot's base frame in which ground plane detection is performed (if enabled)


octomap_server loads a 3D map (as Octree-based OctoMap) and distributes it to
other nodes in a compact binary format. It also allows to incrementally build
3D OctoMaps, and provides map saving in the node octomap_saver.


Documented


A small command line tool to request octomap files from an octomap_server,
similar to [ map_server#map_saver ](/map_server#map_saver) . Just run
"octomap_saver mapfile.bt" to request a compressed binary octomap via service
call and save it to mapfile.bt. Run "octomap_saver -f mapfile.ot" to request a
full probability octomap instead (Requires version 0.5 or later).


    * [ All features ](/features)
    * [ Documentation  ](https://docs.github.com)
    * [ GitHub Skills  ](https://skills.github.com/)
    * [ Blog  ](https://github.blog)


* Incoming 3D point cloud for scan integration. You need to remap this topic to your sensor data and provide a tf transform between the sensor data and the static map frame. The frame_id of the point cloud has to be the sensor frame. Raytracing (clearing of free space) is always done from the origin of this frame at the time of the point cloud.


FR-079 corridor 43.7×18.2×3.3 5 78.88 73.55 41.62 24.72 15.76 0.67
10 10.01 10.87 7.22 5.02 2.70 0.14
Freiburg campus 292×167×28 10 5162.90 1257.57 990.66 504.76 379.70 13.82
20 648.52 187.93 130.24 74.12 49.68 2.00
80 10.58 4.55 4.12 3.09 1.53 0.08
New College (Ep. C) 250×161×33 10 5058.76 607.92 395.42 230.33 148.75 6.40
20 633.64 91.33 50.57 35.95 18.65 0.99
80 10.13 2.34 1.79 1.69 0.63 0.05
freiburg1 360 (RGBD) 7.9×7.3×4.6 2 252.99∗ 159.97∗ 45.52∗ 20.05 21.59∗ 0.52
5 16.19∗ 11.24∗ 4.55∗ 2.52 2.11∗ 0.07
Table 2 Memory consumption of different octree compression types compared to full 3D occupancy maps (called 3D grid) on a 32-bit architecture.
Octree compression in memory is achieved by merging identical children into the parent node (called Pruned). A more efficient but more lossy
compression in memory is achieved by converting each node to its maximum-likelihood value (completely free or occupied) followed by pruning
the complete tree. A maximum-likelihood tree containing only free and occupied nodes can then be serialized to a compact binary file format
(called Lossy file). (∗
): Voxels contain the full color information from the RGBD dataset.
pruning will merge considerable amounts of free space volumes and areas of unknown space don’t use any memory.
Note that a 3D grid of the outdoor data sets with a resolution of 10 cm would not even fit into the addressable main
memory of a 32-bit machine. On the other hand, our map
structure is also able to model fine-graded indoor environments with moderate memory requirements. In very confined spaces, an optimally aligned 3D grid may take less
memory than an uncompressed mapping octree. However,
this effect is diminished as soon as compression techniques
are used.
The evolution of memory consumption over time is
shown in Fig. 14. Memory usage grows when the robot explores new areas (scans 1–22 and 39–44 in FR-079 corridor,
scans 1–50 and 65–81 in Freiburg campus). In the remaining
time, previously mapped areas were revisited where memory usage remained nearly constant or even decreased due
to pruning.
As expected, memory usage increases exponentially
with the tree resolution. This effect can be seen in Fig. 15,
where we used a logarithmic scaling in the plot.
Table 2 gives the file sizes of the serialized binary maximum likelihood map (denoted as “Lossy”) and the full
probabilistic model (“Full”). Note that map files can be
compressed even further by using standard file compression methods. Even maps of the fairly large outdoor datasets
Freiburg campus and New College result in file sizes of less
than 14 MB.
5.5 Runtimes
In the following experiments, we analyzed the time required
to integrate and access data in our framework. All runtimes
10 20 30 40 50 60


Released


#  Provide feedback


####  Required tf Transforms


###  dynamic_reconfigure API


The ROS Wiki is for ROS 1. Are you using ROS 2 ( [ Humble
](http://docs.ros.org/en/humble/) , [ Iron ](http://docs.ros.org/en/iron/) ,
or [ Rolling ](http://docs.ros.org/en/rolling/) )?
[ Check out the ROS 2 Project Documentation ](http://docs.ros.org)
Package specific documentation can be found on [ index.ros.org
](https://index.ros.org)


Password


is estimated according to
P(n | z1:t) = (1)

1+
1−P(n | zt)
P(n | zt)
1−P(n | z1:t−1)
P(n | z1:t−1)
P(n)
1−P(n)
−1
This update formula depends on the current measurement zt
, a prior probability P(n), and the previous estimate
P(n | z1:t−1). The term P(n | zt) denotes the probability of
voxel n to be occupied given the measurement zt
. This value
is specific to the sensor that generated zt
. We provide details on the sensor model used throughout our experiments
in Sect. 5.1.
The common assumption of a uniform prior probability leads to P(n) = 0.5 and by using the log-odds notation,
Eq. (1) can be rewritten as
L(n | z1:t) = L(n | z1:t−1) +L(n | zt), (2)
with
L(n) = log
P(n)
1−P(n)

. (3)
This formulation of the update rule allows for faster updates since multiplications are replaced by additions. In case
of pre-computed sensor models, the logarithms do not have
to be computed during the update step. Note that log-odds
values can be converted into probabilities and vice versa
and we therefore store this value for each voxel instead of
the occupancy probability. It is worth noting that for certain configurations of the sensor model that are symmetric,
i.e., nodes being updated as hits have the same weight as the
ones updated as misses, this probability update has the same
effect as counting hits and misses similar to (Kelly et al.,
2006).
When a 3D map is used for navigation, a threshold on the
occupancy probability P(n | z1:t) is often applied. A voxel


_**[ octomap_mapping ](/octomap_mapping?distro=electric) ** : [ octomap
](/octomap?distro=electric) | [ octomap_ros ](/octomap_ros?distro=electric) |
octomap_server _


_**[ octomap_mapping ](/octomap_mapping?distro=hydro) ** : octomap_server _


#  Package Summary


[ ![@aladin2022](https://avatars.githubusercontent.com/u/98184487?s=80&v=4)
](/aladin2022)


[ ](https://github.com "GitHub") © 2024 GitHub, Inc.


Documented


Line 12 in [ 6e96c83
](/OctoMap/octomap_mapping/commit/6e96c831795c664ba554bdff53844657a7916f83)


  * Author: Armin Hornung
  * License: BSD
  * Source: git [ https://github.com/OctoMap/octomap_mapping.git ](https://github.com/OctoMap/octomap_mapping) (branch: groovy-devel)


* **hydro:** _Documentation generated on August 27, 2015 at 02:14 PM_ ( [ doc job ](http://jenkins.ros.org/job/doc-hydro-octomap_mapping/) ).


  * [ jsk_pcl_ros ](/jsk_pcl_ros?distro=kinetic)
  * [ jsk_pcl_ros_utils ](/jsk_pcl_ros_utils?distro=kinetic)
  * [ octomap_mapping ](/octomap_mapping?distro=kinetic)
  * [ thormang3_navigation... ](/thormang3_navigation?distro=kinetic)


Thanks!

---

The text was updated successfully, but these errors were encountered:


Continuous Integration


Copy link


,
where P(n) is the occupancy probability of node n in Mf
,
and Q(n) in Mc.
The results for a series of occupancy ranges
from [0 : 1] (no clamping, lossless) to [0.4 : 0.6] (strong
clamping, most loss) and different maps can be seen
in Fig. 18. The values for our chosen default threshold [0.12 : 0.97] are shown as thin horizontal lines, dashed
blue for the memory consumption and red for the KLD.
This clamping range was chosen primarily to work best in
the context of laser-based mapping and occasional changes
in the environment, such as people moving through the
scans or doors closing. As can be seen, a stronger compression can be achieved with higher clamping, at the cost of
losing map confidence. In the most degenerated case, one
sensor update can be enough to mark a voxel as completely
OctoMap: An Efficient Probabilistic 3D Mapping Framework Based on Octrees 15
[0:
1]
[0.05:
0.95]
[0.1:
0.9]
[0.15:
0.85]
[0.2:
0.8]
[0.25:
0.75]
[0.3:
0.7]
[0.35:
0.65]
[0.4:
0.6]
0
2
4
6
8
·105


` ~occupancy_[min|max]_z ` ( ` float ` , default: -/+ infinity)


  * [ catkin ](/catkin?distro=kinetic)
  * [ dynamic_reconfigure ](/dynamic_reconfigure?distro=kinetic)
  * [ nav_msgs ](/nav_msgs?distro=kinetic)
  * [ nodelet ](/nodelet?distro=kinetic)
  * [ octomap ](/octomap?distro=kinetic)
  * [ octomap_msgs ](/octomap_msgs?distro=kinetic)
  * [ octomap_ros ](/octomap_ros?distro=kinetic)
  * [ pcl_conversions ](/pcl_conversions?distro=kinetic)
  * [ pcl_ros ](/pcl_ros?distro=kinetic)
  * [ roscpp ](/roscpp?distro=kinetic)
  * [ sensor_msgs ](/sensor_msgs?distro=kinetic)
  * [ std_msgs ](/std_msgs?distro=kinetic)
  * [ std_srvs ](/std_srvs?distro=kinetic)
  * [ visualization_msgs ](/visualization_msgs?distro=kinetic)


The site is read-only. Please transition to use Robotics Stack Exchange


    <launch>
    	<node pkg="octomap_server" type="octomap_server_node" name="octomap_server">
    		<param name="resolution" value="0.1" />
    		<!-- fixed map frame (set to 'map' if SLAM or localization running!) -->
    		<param name="frame_id" type="string" value="/map" />
    		<!-- maximum range to integrate (speedup!) -->
    		<param name="sensor_model/max_range" value="30.0" />
    		<param name="latch" value="false"/>
                     <param name="pointcloud_min_z" value="-200.0"/>
                     <param name="pointcloud_max_z" value="200.0"/>
    		<!-- data source to integrate (PointCloud2) -->
    		<remap from="cloud_in" to="/cloud" />
    	</node>
    	<node pkg="mapping" type="tf_broadcaster.py" name="tf_broadcaster" output="screen"></node>
            <node pkg="mapping" type="nav_publisher.py" name="nav_publisher" output="screen"></node>
    </launch>


and there is no multi-resolution capability. Another potential
problem is that subsequent map updates cannot subdivide
existing volumes, leading to an incorrect model of the environment. Similarly, Douillard et al. (2010) combine a coarse
elevation map for background structures with object voxel
maps at a higher resolution. In contrast to our work, this approach focuses on 3D segmentation of single measurements
and does not integrate several measurements into a model of
the environment.
In robotic mapping, octrees avoid one of the main shortcomings of fixed grid structures: They delay the initialization of map volumes until measurements need to be integrated. In this way, the extent of the mapped environment
does not need to be known beforehand and the map only
contains volumes that have been measured. If inner nodes
of a tree are updated properly, the tree can also be used
as a multi-resolution representation since it can be cut at
any level to obtain a coarser subdivision. The use of octrees
for mapping was originally proposed by Meagher (1982).
Early works mainly focused on modeling a Boolean property such as occupancy (Wilhelms and Van Gelder, 1992).
Payeur et al. (1997) used octrees to adapt occupancy grid
mapping from 2D to 3D and thereby introduced a probabilistic way of modeling occupied and free space. A similar
approach was used by Fournier et al. (2007) and Pathak et al.
(2007). In contrast to the approach presented in this paper,
however, the authors did not explicitly address the issues of
map compression or bounded confidence in the map.
An octree-based 3D map representation was also proposed by Fairfield et al. (2007). Their map structure called
Deferred Reference Counting Octree is designed to allow for efficient map updates, especially in the context
of particle filter SLAM. To achieve map compactness, a
lossy maximum-likelihood compression is performed periodically. Compared to the compression technique used in
our approach, this discards the probability information for
future updates. Furthermore, the problem of overconfident
maps and multi-resolution queries are not addressed.
As a data structure, octrees are applied in a variety of
applications, most notably in the area of computer graphics
for efficient rendering (Botsch et al., 2002; Surmann et al.,
2003; Laine and Karras, 2010) and in the field of photogrammetry to store and address large point clouds (GirardeauMontaut et al., 2005; Elseberg et al., 2011). Another popular
use case is the compression of static point clouds (Schnabel
and Klein, 2006) or point cloud streams (Kammerl et al.,
2012). While our framework is general enough to also store
raw point clouds, its main purpose is to integrate these point
clouds into a memory-efficient, volumetric occupancy map,
since point clouds as environment representation in robotics
4 Armin Hornung et al.
have a number of disadvantages as detailed at the beginning


####  Published Topics


  * **[ Code API ](http://docs.ros.org/en/melodic/api/octomap_server/html) **
  * [ FAQ ](http://answers.ros.org/questions/scope:all/sort:activity-desc/tags:octomap_server/page:1/)
  * [ Changelog ](http://docs.ros.org/en/melodic/changelogs/octomap_server/changelog.html)
  * [ Change List ](/octomap_mapping/ChangeList)
  * [ Reviews ](/octomap_server/Reviews)


Released


updated accordingly. Applying this compression only leads
to a loss of information close to P(n) = 0 and P(n) = 1 while
preserving the probabilities in between. In our experiments,
combining octree pruning and clamping leads to a compression improvement of up to 44%.
In many robotic navigation tasks such as obstacle avoidance or localization, only the maximum likelihood map containing either free or occupied nodes is sufficient. In these
cases, a lossy compression based on the occupancy threshold, as suggested by Fairfield et al. (2007), can be performed. For this compression, all nodes are converted to
their maximum likelihood (clamped) probabilities, followed
by tree pruning. This yields an even greater compression and
less memory requirements.
OctoMap: An Efficient Probabilistic 3D Mapping Framework Based on Octrees 7
Fig. 5 Detail of a volumetric indoor OctoMap containing color information. The complete map covers an area of 7.3 m × 7.9 m × 4.6 m at
2 cm resolution.
3.5 Extensions
3.5.1 Maps with Rich Information
Octree nodes can be extended to store additional data to enrich the map representation. Voxels could, for example, store
terrain information, environmental data such as the temperature, or color information. Each additional voxel property
requires a method that allows several measurements to be
fused. As an example, we extended our mapping framework
to store the average color of each voxel. This creates visualizations for the user and enables a color-based classification
of the environment or appearance-based robot localization
from virtual views (similar to (Einhorn et al., 2011; Mason
et al., 2011)). It can also be used as a starting point to create colored, high-resolution surface meshes (Hoppe et al.,
1992). Figure 5 shows an octree map that was created by
integrating colored point clouds recorded with a hand-held
Microsoft Kinect sensor. The data is available in the sequence called freiburg1 360 of the RGBD-dataset (Sturm
et al., 2012) and was aligned using RGB-D SLAM (Endres
et al., 2012).
3.5.2 Octree Hierarchies
We developed an extension to our mapping approach that exploits hierarchical dependencies in the environment (Wurm
et al., 2011). This extension maintains a collection of
submaps in a tree-structure, where each node represents a
subspace of the environment. The subdivision applied in our
system is based on a user-defined segmentation of the input and on a given spatial relation that expresses the relation
between segments.
Figure 6 gives an illustration of a hierarchy that is based
on the assumption that objects are located on top of supporting planes. In this application, we first estimated supporting
Fig. 6 Hierarchical octree model of a tabletop scene. Background (yellow), table (magenta), and objects (cyan) are represented by individual
octree maps of different resolutions.
planes in the input. Objects on top of these supporting planes
were then segmented in the input data and modeled in individual volumetric submaps. As a result, the table is a submap


Except where otherwise noted, the ROS wiki is licensed under the
[ Creative Commons Attribution 3.0
](http://creativecommons.org/licenses/by/3.0/)


** Used by  (1) **


* Product


** Dependencies  (11) **


By Solution


Botsch M, Wiratanaya A, Kobbelt L (2002) Efficient high quality rendering of point sampled geometry. In: EGRW ’02: Proc. of the 13th
Eurographics workshop on Rendering, pp 53–64
Ciocarlie M, Hsiao K, Jones EG, Chitta S, Rusu RB, Sucan IA (2010)
Towards reliable grasping and manipulation in household environments. In: Intl. Symposium on Experimental Robotics (ISER)
Cole D, Newman P (2006) Using laser range data for 3D SLAM in
outdoor environments. In: Proc. of the IEEE Int. Conf. on Robotics
& Automation (ICRA)
Dornhege C, Kleiner A (2011) A frontier-void-based approach for autonomous exploration in 3D. In: IEEE International Symposium on
Safety, Security and Rescue Robotics (SSRR)
Douillard B, Underwood J, Melkumyan N, Singh S, Vasudevan S,
Brunner C, Quadros A (2010) Hybrid elevation maps: 3D surface
models for segmentation. In: Proc. of the IEEE/RSJ Int. Conf. on
Intelligent Robots and Systems (IROS)
Dryanovski I, Morris W, Xiao J (2010) Multi-volume occupancy grids:
An efficient probabilistic 3D mapping model for micro aerial vehicles. In: Proc. of the IEEE/RSJ Int. Conf. on Intelligent Robots and
Systems (IROS)
Einhorn E, Schroter C, Groß HM (2011) Attention-driven monocu- ¨
lar scene reconstruction for obstacle detection, robot navigation and
map building. Robotics & Autonomous Systems 59(5):296–309
Elseberg J, Borrmann D, Nuchter A (2011) Efficient processing of ¨
large 3d point clouds. In: Proc. of the XXIII Int. Symp. on Information, Communication and Automation Technologies (ICAT ’11)
Endres F, Hess J, Engelhard N, Sturm J, Cremers D, Burgard W (2012)
An evaluation of the RGB-D SLAM system. In: Proc. of the IEEE
Int. Conf. on Robotics & Automation (ICRA)
Fairfield N, Kantor G, Wettergreen D (2007) Real-time SLAM with
octree evidence grids for exploration in underwater tunnels. Journal
of Field Robotics
Fournier J, Ricard B, Laurendeau D (2007) Mapping and exploration
of complex environments using persistent 3D model. In: Computer
and Robot Vision, 2007. Fourth Canadian Conf. on, pp 403–410
Girardeau-Montaut D, Roux M, Marc R, Thibault G (2005) Change
detection on points cloud data acquired with a ground laser scanner.
International Archives of the Photogrammetry, Remote Sensing and
Spatial Information Sciences 36:30–35
Gutmann JS, Fukuchi M, Fujita M (2008) 3D perception and environment map generation for humanoid robot navigation. Int J Rob Res
27(10):1117–1134
Habbecke M, Kobbelt L (2007) A surface-growing approach to multiview stereo reconstruction. In: Proc. of the IEEE Conf. on Computer
Vision and Pattern Recognition (CVPR)
Hadsell R, Bagnell JA, Hebert M (2009) Accurate rough terrain estimation with space-carving kernels. In: Proc. of Robotics: Science
and Systems (RSS)


Labels


** Used by  (3) **


[ Sign up
](/signup?ref_cta=Sign+up&ref_loc=header+logged+out&ref_page=%2F%3Cuser-
name%3E%2F%3Crepo-
name%3E%2Fvoltron%2Fissues_fragments%2Fissue_layout&source=header-
repo&source_repo=OctoMap%2Foctomap_mapping)


Documented


add a comment


octomap_server builds and distributes volumetric 3D occupancy maps as OctoMap
binary stream and in various ROS-compatible formats e.g. for obstacle
avoidance or visualization. The map can be a static OctoMap .bt file (as
command line argument) or can be incrementally built from incoming range data
(as PointCloud2). octomap_server starts with an empty map if no command line
argument is given. In general, octomap_server creates and publishes only on
topics that are subscribed. Since some can be time-consuming to build for
large maps, only subscribe to topics you absolutely need (e.g. in RViz) and
set the "latch" parameter for false when building maps.


No API documentation


  * **[ Code API ](http://docs.ros.org/en/kinetic/api/octomap_server/html) **
  * [ FAQ ](http://answers.ros.org/questions/scope:all/sort:activity-desc/tags:octomap_server/page:1/)
  * [ Changelog ](http://docs.ros.org/en/kinetic/changelogs/octomap_server/changelog.html)
  * [ Change List ](/octomap_mapping/ChangeList)
  * [ Reviews ](/octomap_server/Reviews)


##  Use saved searches to filter your results more quickly


If you look at the config you can see where it is set


* Distance threshold from z=0 for a plane to be detected as ground (4th coefficient of the plane equation from PCL)


  * [ catkin ](/catkin?distro=jade)
  * [ dynamic_reconfigure ](/dynamic_reconfigure?distro=jade)
  * [ nav_msgs ](/nav_msgs?distro=jade)
  * [ nodelet ](/nodelet?distro=jade)
  * [ octomap ](/octomap?distro=jade)
  * [ octomap_msgs ](/octomap_msgs?distro=jade)
  * [ octomap_ros ](/octomap_ros?distro=jade)
  * [ pcl_conversions ](/pcl_conversions?distro=jade)
  * [ pcl_ros ](/pcl_ros?distro=jade)
  * [ roscpp ](/roscpp?distro=jade)
  * [ sensor_msgs ](/sensor_msgs?distro=jade)
  * [ std_msgs ](/std_msgs?distro=jade)
  * [ std_srvs ](/std_srvs?distro=jade)
  * [ visualization_msgs ](/visualization_msgs?distro=jade)


* Downprojected 2D occupancy map from the 3D map. Be sure to remap this topic if you have another 2D map server running. **New / changed in octomap_mapping 0.4.4** : The topic is now ` projected_map ` by default to avoid collisions with static 2D maps


**[ aladin2022 ](/aladin2022) ** commented  Mar 23, 2022


Assignees


  * Maintainer status: maintained
  * Maintainer: Wolfgang Merkt <opensource AT wolfgangmerkt DOT com>
  * Author: Armin Hornung
  * License: BSD
  * Bug / feature tracker: [ https://github.com/OctoMap/octomap_mapping/issues ](https://github.com/OctoMap/octomap_mapping/issues)
  * Source: git [ https://github.com/OctoMap/octomap_mapping.git ](https://github.com/OctoMap/octomap_mapping) (branch: kinetic-devel)


##  Footer


Please cite our paper if you use OctoMap in your research.


Pick a username


Milestone


[ about ](/about/) |  [ faq ](/faq/) |  [ help ](/help/ "help") |  [ privacy
policy ](/privacy/) |  [ terms of service ](/terms/)


**[ laelliott ](/laelliott) ** commented  Jun 16, 2023


  * Update the demos to C++17. ( [ #594 ](https://github.com/ros2/demos/issues/594) )
  * [rolling] Update maintainers - 2022-11-07 ( [ #589 ](https://github.com/ros2/demos/issues/589) )
  * Contributors: Audrow Nash, Chris Lalancette


Every child of LifecycleNodes have a set of callbacks provided. These
callbacks go along with the applied state machine attached to it. These
callbacks are:


CHANGELOG


7. Remove all lines with ` status_  =  ...  ` or ` status::...  `


#  Run the demo


  1. configuring: We initialize our publisher and timer
  2. activate: We activate the publisher and timer in order to enable a publishing
  3. deactivate: We stop the publisher and timer
  4. cleanup: We destroy the publisher and timer


In the case you want to get the current state of the ` lc_talker ` node, you
would call:


####  Additional Links


  * lifecycle_talker
  * lifecycle_listener
  * lifecycle_service_client


##  What\'s happening


    [lc_listener] notify callback: Transition from state unconfigured to configuring
    [lc_listener] notify callback: Transition from state configuring to inactive


The principle is implemented in this demo as the typical talker/listener demo.
However, imaging a real scenario with attached hardware which may have a
rather long booting phase, i.e. a laser or camera. One could image bringing up
the device driver in the configuring state, start and stop only the publishing
of the device\'s data and only in the cleanup/shutdown phase actually shutdown
the device.


_No message files found._


If we have a look at the code, there is one significant change for the
lifecycle talker compared to a regular talker. Our node does not inherit from
the regular ` rclcpp::node::Node ` but from ` rclcpp_lifecycle::LifecycleNode
` .


###  Messages


Alternatively, these three programs can be run together in the same terminal
using the launch file:


####  Authors


The next step would be to execute a state change:


####  Maintainers


    $ ros2 lifecycle set /lc_talker configure
    Transitioning successful


The lifecycle listener on the same time receives a notification as it listens
to every state change notification of the lifecycle talker. In fact, the
listener receives two consecutive notifications. One for changing from the
primary state \"unconfigured\" to \"configuring\". Because the configuring
step was successful within the lifecycle talker, a second notification from
\"configuring\" to \"inactive\".


{
 auto current_command = input_command_.readFromRT();
 for (size_t i = 0; i < command_interfaces_.size(); ++i) {
 if (!std::isnan((*current_command)->data[i])) {
 command_interfaces_[i].set_value((*current_command)->data[i]);
 }
 }
 if (state_publisher_ && state_publisher_->trylock()) {
 state_publisher_->msg_.header.stamp = get_node()->now();
 state_publisher_->msg_.set_point = command_interfaces_[0].get_value();
 state_publisher_->unlockAndPublish();
 }
 return controller_interface::return_type::OK;
}
Implementing a forwarding controller
pluginlib_export_plugin_description_file(controller_interface rrbot_controller.xml)
#include "pluginlib/class_list_macros.hpp"
PLUGINLIB_EXPORT_CLASS(rrbot_controller::RRBotControllerArray, controller_interface::ControllerBase)
<library path="librrbot_controller_array">
 <class name="rrbot_controller/RRBotControllerArray"
 type="rrbot_controller::RRBotControllerArray"
base_class_type="controller_interface::ControllerBase">
 <description>
 RRBotControllerArray ros_control controller.
 </description>
 </class>
</library>
In CMakelists.txt:
In controller.cpp
In rrbot_controller.xml:
Let’s test it all!
ros2 launch rrbot_bringup rrbot_with_rrbot_controller_array.launch.py
ros2 topic pub /rrbot_controller/commands
example_interfaces/msg/Float64MultiArray "data:
- 0.5
- 0.5"
Messages and modifying a controller
std_msgs/MultiArrayLayout layout
 std_msgs/MultiArrayDimension[] dim
 string label


If ` hardware_interface::return_type::ERROR  ` is returned from ` read()  ` or
` write()  ` methods of a hardware_interface class, ` on_error(previous_state)
` method will be called to handle any error that happened.


[ composition ](/p/composition/github-ros2-demos) [ demo_nodes_cpp
](/p/demo_nodes_cpp/github-ros2-demos) [ demo_nodes_cpp_native
](/p/demo_nodes_cpp_native/github-ros2-demos) [ demo_nodes_py
](/p/demo_nodes_py/github-ros2-demos) [ dummy_map_server
](/p/dummy_map_server/github-ros2-demos) [ dummy_robot_bringup
](/p/dummy_robot_bringup/github-ros2-demos) [ dummy_sensors
](/p/dummy_sensors/github-ros2-demos) [ image_tools ](/p/image_tools/github-
ros2-demos) [ intra_process_demo ](/p/intra_process_demo/github-ros2-demos)
lifecycle  [ logging_demo ](/p/logging_demo/github-ros2-demos) [
pendulum_control ](/p/pendulum_control/github-ros2-demos) [ pendulum_msgs
](/p/pendulum_msgs/github-ros2-demos) [ topic_monitor
](/p/topic_monitor/github-ros2-demos)
---|---

github-ros2-demos


[ action_tutorials_cpp ](/p/action_tutorials_cpp/github-ros2-demos) [
action_tutorials_interfaces ](/p/action_tutorials_interfaces/github-
ros2-demos) [ action_tutorials_py ](/p/action_tutorials_py/github-ros2-demos)
[ composition ](/p/composition/github-ros2-demos) [ demo_nodes_cpp
](/p/demo_nodes_cpp/github-ros2-demos) [ demo_nodes_cpp_native
](/p/demo_nodes_cpp_native/github-ros2-demos) [ demo_nodes_py
](/p/demo_nodes_py/github-ros2-demos) [ dummy_map_server
](/p/dummy_map_server/github-ros2-demos) [ dummy_robot_bringup
](/p/dummy_robot_bringup/github-ros2-demos) [ dummy_sensors
](/p/dummy_sensors/github-ros2-demos) [ image_tools ](/p/image_tools/github-
ros2-demos) [ intra_process_demo ](/p/intra_process_demo/github-ros2-demos)
lifecycle  [ logging_demo ](/p/logging_demo/github-ros2-demos) [
pendulum_control ](/p/pendulum_control/github-ros2-demos) [ pendulum_msgs
](/p/pendulum_msgs/github-ros2-demos) [ quality_of_service_demo_cpp
](/p/quality_of_service_demo_cpp/github-ros2-demos) [
quality_of_service_demo_py ](/p/quality_of_service_demo_py/github-ros2-demos)
[ topic_monitor ](/p/topic_monitor/github-ros2-demos)
---|---

github-ros2-demos


Our implementation differentiates between ` Primary States ` and ` Transition
States ` . Primary States are supposed to be steady states in which any node
can do the respected task. On the other hand, Transition States are meant as
temporary intermediate states attached to a transition. The result of these
intermediate states are used to indicate whether a transition between two
primary states is considered successful or not. Thus, any managed node can be
in one of the following states:


###  Services


Primary States (steady states):


  * Update maintainers to Audrow Nash and Michael Jeronimo ( [ #543 ](https://github.com/ros2/demos/issues/543) )
  * Contributors: Audrow Nash


  1. [ Home ](/)
  2. [ Packages ](/packages)
  3. lifecycle


At the same time the lifecycle listener receives a notification as it listens
to every state change notification of the lifecycle talker. In fact, the
listener receives two consecutive notifications. One for changing from the
primary state \"unconfigured\" to \"configuring\", and a second notification
changing the state from \"configuring\" to \"inactive\" (since the configuring
step was successful in the talker).


    $ ros2 service call /lc_talker/get_state lifecycle_msgs/GetState
    requester: making request: lifecycle_msgs.srv.GetState_Request()

    response:
    lifecycle_msgs.srv.GetState_Response(current_state=lifecycle_msgs.msg.State(id=1, label='unconfigured'))


_No plugins found._


###  Wiki Tutorials


It returns a list of all possible transitions this node can execute.


##  0.13.0 (2021-03-25)


#  The demo code


##  What\'s happening


##  0.5.1 (2018-06-28)


    $ ros2 lifecycle list lc_talker
    - configure [1]
      Start: unconfigured
      Goal: configuring
    - shutdown [5]
      Start: unconfigured
      Goal: shuttingdown


###  Package Dependencies


In order to run this demo, we open three terminals and source our ROS 2
environment variables either from the binary distributions or the workspace we
compiled from source.


The above description points to the current state of the development as for
beta1. The future todo list for this topic comprises:


The principle is implemented in this demo as the typical talker/listener demo.
However, imaging a real scenario with attached hardware which may have a
rather long booting phase, i.e. a laser or camera. One could image bringing up
the device driver in the configuring state, start and stop only the publishing
of the device\'s data and only in the cleanup/shutdown phase actually shutdown
the device.


  * Overview
  * 0  Assets
  * 7  Dependencies
  * 0  Tutorials
  * 0  Q & A


The ` lifecycle_talker ` represents a managed node and publishes according to
which state the node is in. We split the tasks of the talker node into
separate pieces and execute them as follows:


###  Services


_No message files found._


        RCLCPP_INFO(get_logger(), "CameraNode configured.");

        return rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn::SUCCESS;
      }

      /* During the activate lifecycle transition, the on_activate function is called,
       * which activates the publisher associated with the node. The publisher_->on_activate()
       * call in this function activates the publisher by notifying its subscribers that the node is
       * ready to publish data.

       * In addition, this code block also includes a log message indicating that the CameraNode
       * has been activated. Finally, a std::this_thread::sleep_for(2s) call is used to introduce a
       * delay of 2 seconds to simulate a time-consuming activation process.

       * The function returns rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn::SUCCESS
       * to indicate that the transition was successful.
       */
      rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn
      on_activate(const rclcpp_lifecycle::State &)
      {
        publisher_->on_activate();

        RCUTILS_LOG_INFO_NAMED(get_name(), "CameraNode activated.");
        std::this_thread::sleep_for(2s);
        return rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn::SUCCESS;
      }
      /* on_deactivate function, which is a callback function called when the node is in the "inactive" state.
       * In this function, the on_deactivate function of the publisher is called to deactivate it.
       * Then, a log message is printed to indicate that the node has been deactivated.

       * The function returns rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn::SUCCESS
       * to indicate that the deactivation process has been completed successfully.
       */
      rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn
      on_deactivate(const rclcpp_lifecycle::State &)
      {
        publisher_->on_deactivate();

        RCUTILS_LOG_INFO_NAMED(get_name(), "CameraNode deactivated.");


At the same time, every lifecycle node has by default 5 different
communication interfaces.


2. If using BaseInterface as base class then you should remove it. Specifically, change:


[ ](https://lunrjs.com/guides/searching.html "Help to Search")


##  0.8.0 (2019-09-26)


##  0.12.1 (2021-03-18)


##  0.7.1 (2019-04-26)


_No plugins found._


In this case we see that currently, the available transitions are ` configure
` and ` shutdown ` . The complete state machine can be viewed with the
following command, which can be helpful for debugging or visualization
purposes:


  * Use default on_activate()/on_deactivate() implemenetation of Node ( [ #552 ](https://github.com/ros2/demos/issues/552) )
  * Contributors: Ivan Santiago Paunovic


Package containing demos for lifecycle implementation


All of the above commands are nothing more than calling the lifecycle node\'s
services. With that being said, we can also call these services directly with
the ros2 command line interface:


##  0.19.0 (2022-01-14)


_No additional links._


#  Changelog for package lifecycle


####  Package Summary


For the rest of the demo, you will see similar output as we deactivate and
activate the lifecycle talker and finally shut it down.


_Not currently indexed._


  * Updated for NodeOptions Node constructor. ( [ #308 ](https://github.com/ros2/demos/issues/308) )
  * Contributors: Michael Carroll


The lifecycle listener receives the same set of notifications as before.
Lifecycle talker changed its state from inactive to active.


For a more verbose explanation on the applied state machine, we refer to the
design page which provides an in-detail explanation about each state and
transition.


* Service ` <node_name>__change_state ` : triggers a transition for the current node.


#  The demo code


##  0.7.1 (2019-04-26)


* Service ` <node_name>__get_available_transitions ` : Same as above, meant to an introspection tool.


  * Mabel Zhang
  * Michael Jeronimo


  * Remove unnecessary dependency on ros2run ( [ #413 ](https://github.com/ros2/demos/issues/413) )
  * Contributors: Michel Hidalgo


###  Package Dependencies


Failed to get question list, you can ticket an issue [ here
](https://github.com/ros-infrastructure/rosindex/issues/new)


##  0.13.0 (2021-03-25)


* Karsten Knese


All of the above commands are nothing else than calling the lifecycle node\'s
services. With that being said, we can also call these services directly with
the ros2 command line interface:


**Tags** |  _No category tags._
---|---
**Version** |  0.20.3
**License** |  Apache License 2.0
**Build type** |  AMENT_CMAKE
**Use** |  RECOMMENDED

###  Repository Summary


    [lc_client] Transition 2 successfully triggered.
    [lc_client] Node lc_talker has current state active.


  * Overview
  * 0  Assets
  * 7  Dependencies
  * 0  Tutorials
  * 0  Q & A


_No additional links._


* Service ` <node_name>__get_state ` : query about the current state of the node.


  * Update the demos to C++17. ( [ #594 ](https://github.com/ros2/demos/issues/594) )
  * [rolling] Update maintainers - 2022-11-07 ( [ #589 ](https://github.com/ros2/demos/issues/589) )
  * Contributors: Audrow Nash, Chris Lalancette


If we have a look at the code, there is one significant change for the
lifecycle talker compared to a regular talker. Our node does not inherit from
the regular ` rclcpp::node::Node ` but from ` rclcpp_lifecycle::LifecycleNode
` .


Have fun!
Use-cases from wilderness - ros2_control + MoveIt2
Use-cases from wilderness
● UR driver: https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver
○ The first open-source driver with ros2_control integration
○ Needs special features:
■ Digital and analog inputs and outputs
■ General robot operation: unlock protective stop, restart safety, break release (TBD)
■ Loading, starting, and stopping programs (TBD)
● Dynamixel: https://github.com/youtalk/dynamixel_control
○ Uses multiple servos
○ Reference implementation for ROBOTIS OpenManipulator-X
Use-cases from wilderness
● ros2_control_demos: https://github.com/ros-controls/ros2_control_demos
○ Tool changing — hardware-lifecycle example (PR #133)
○ “Stacking HW together” — RRBot + FTS Sensor (example 4)
● “My robot has measurement offset”
○ Separate commanded and measured states in visualization (example coming soon)
● Hardware “architectures” and capabilities:
○ https://github.com/ros-controls/roadmap/blob/master/design_drafts/components_architecture_and_urdf_examples.md
References
● ros_control paper in the Journal of Open Source Software
● ros2_control resources
○ https://control.ros.org
○ https://github.com/ros-controls/ros2_control
○ https://github.com/ros-controls/ros2_controllers
○ https://github.com/ros-controls/ros2_control_demos
○ https://github.com/ros-controls/roadmap/blob/master/documentation_resources.md
● Videos/presentations:
○ https://youtu.be/G__yFTWp_M0
○ https://www.youtube.com/watch?v=5OfOPcu8Erw&t=245s
○
References
● ros_control paper in the Journal of Open Source Software
● ros2_control resources
○ https://control.ros.org
○ https://github.com/ros-controls/ros2_control
○ https://github.com/ros-controls/ros2_controllers
○ https://github.com/ros-controls/ros2_control_demos
○ https://github.com/ros-controls/roadmap/blob/master/documentation_resources.md


###  Recent questions tagged ` lifecycle ` at **[ Robotics Stack Exchange
](https://robotics.stackexchange.com/) **


  * unconfigured
  * inactive
  * active
  * shutdown


###  Source Tutorials


No version for distro **hydro** . Known supported distros are highlighted in
the buttons above.


Deps  |  |  Name  |  [ ](/p/lifecycle_msgs#galactic-deps) |  [ 1
](/packages/lifecycle_msgs) |  [ lifecycle_msgs ](/p/lifecycle_msgs#galactic)
---|---|---
[ ](/p/rclcpp_lifecycle#galactic-deps) |  [ 1 ](/packages/rclcpp_lifecycle) |
[ rclcpp_lifecycle ](/p/rclcpp_lifecycle#galactic)
[ ](/p/std_msgs#galactic-deps) |  [ 2 ](/packages/std_msgs) |  [ std_msgs
](/p/std_msgs#galactic)
[ ](/p/ament_cmake#galactic-deps) |  [ 1 ](/packages/ament_cmake) |  [
ament_cmake ](/p/ament_cmake#galactic)
[ ](/p/ament_lint_auto#galactic-deps) |  [ 1 ](/packages/ament_lint_auto) |  [
ament_lint_auto ](/p/ament_lint_auto#galactic)
[ ](/p/ament_lint_common#galactic-deps) |  [ 1 ](/packages/ament_lint_common)
|  [ ament_lint_common ](/p/ament_lint_common#galactic)
[ ](/p/ros_testing#galactic-deps) |  [ 1 ](/packages/ros_testing) |  [
ros_testing ](/p/ros_testing#galactic)

###  System Dependencies


##  0.14.2 (2021-04-26)


[ lifecycle/README.rst
](https://github.com/ros2/demos/tree/humble/lifecycle/README.rst "Open in git
repository")


The lifecycle listener on the same time receives a notification as it listens
to every state change notification of the lifecycle talker. In fact, the
listener receives two consecutive notifications. One for changing from the
primary state \"unconfigured\" to \"configuring\". Because the configuring
step was successful within the lifecycle talker, a second notification from
\"configuring\" to \"inactive\".


###  Wiki Tutorials


##  0.7.4 (2019-05-20)


[ lifecycle/README.rst
](https://github.com/ros2/demos/tree/dashing/lifecycle/README.rst "Open in git
repository")


####  Package Summary


Now let’s write the subscriber node,


    [lc_listener] notify callback: Transition from state unconfigured to configuring
    [lc_listener] notify callback: Transition from state configuring to inactive


* ` CallbackReturn on_error(const rclcpp_lifecycle::State & previous_state) `


##  0.6.0 (2018-12-07)


Name  |  Repo  |  Deps  |  [ desktop ](/p/desktop/github-
ros2-variants#crystal) |  [ github-ros2-variants ](/r/variants/github-
ros2-variants) |  [ ](/p/desktop/github-ros2-variants#crystal-deps)
---|---|---

###  Launch files


In order to trigger a transition, we call the ` change_state ` service


_Not currently indexed._


####  Maintainers


##  0.14.1 (2021-04-19)


##  0.7.5 (2019-05-29)


##  0.30.1 (2023-07-11)


Its commonly used software package for _robotic navigation_ that includes
various components, such as the _map server_ , _costmap generator_ , _local
planner_ , and _global planner_ . These components need to be started and
stopped in a specific order, and their lifecycles need to be coordinated in
order to ensure the proper functioning of the overall navigation system.
Here’s how ROS2 Lifecycle Nodes can be beneficial for managing the Navigation
stack:


#  Run the demo


  * Update asciinema recordings ( [ #360 ](https://github.com/ros2/demos/issues/360) )
  * Use rate instead of thread::sleep to react to Ctrl-C ( [ #348 ](https://github.com/ros2/demos/issues/348) )
  * Contributors: Dirk Thomas, Karsten Knese


    rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn
    on_configure(const rclcpp_lifecycle::State & previous_state)

    rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn
    on_activate(const rclcpp_lifecycle::State & previous_state)

    rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn
    on_deactivate(const rclcpp_lifecycle::State & previous_state)

    rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn
    on_cleanup(const rclcpp_lifecycle::State & previous_state)

    rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn
    on_shutdown(const rclcpp_lifecycle::State & previous_state)


This allows users to get notified of transition events within the network.


_No plugins found._


##  0.10.1 (2020-09-21)


_No additional links._


  * Fix typo ( [ #445 ](https://github.com/ros2/demos/issues/445) )
  * Replace ` ros2 msg ` command in lifecycle README ( [ #446 ](https://github.com/ros2/demos/issues/446) )
  * Contributors: Audrow Nash, Shota Aoki


Package containing demos for lifecycle implementation


Every child of LifecycleNodes have a set of callbacks provided. These
callbacks go along with the applied state machine attached to it. These
callbacks are:


The ` lifecycle_service_client ` application is a fixed order script for demo
purposes only. It explains the use and the API calls made for this lifecycle
implementation, but may be inconvenient to use otherwise. For this reason we
implemented a command line tool which lets you dynamically change states or
various nodes.


##  0.32.1 (2023-12-26)


Alternatively, these three programs can be run together in the same terminal
using the launch file:


This gives room for executing a custom error handling. Only (!) in the case
that this function returns ` CallbackReturn::SUCCESS ` , the state machine
transitions to the state ` unconfigured ` . By default, the ` on_error `
returns ` CallbackReturn::FAILURE ` and the state machine transitions into `
finalized ` .


  * unconfigured
  * inactive
  * active
  * shutdown


##  0.13.0 (2021-03-25)


###  Recent questions tagged ` lifecycle ` at **[ Robotics Stack Exchange
](https://robotics.stackexchange.com/) **


_No launch files found_


  * Updated for NodeOptions Node constructor. ( [ #308 ](https://github.com/ros2/demos/issues/308) )
  * Contributors: Michael Carroll


  * update launch file name format to match documentation ( [ #588 ](https://github.com/ros2/demos/issues/588) )
  * Contributors: Patrick Wspanialy


##  0.7.3 (2019-05-10)


####  Authors


    $ ros2 lifecycle get /lc_talker
    unconfigured [1]


* Publisher ` <node_name>__transition_event ` : publishes in case a transition is happening.


Return either a primary or transition state.


No questions yet, you can ask one [ here
](https://robotics.stackexchange.com/questions/tagged/lifecycle+humble) .


lifecycle_talker lifecycle_listener lifecycle_service_client


Listen


##  0.14.1 (2021-04-19)


  * configuring
  * activating
  * deactivating
  * cleaningup
  * shuttingdown


No version for distro **indigo** . Known supported distros are highlighted in
the buttons above.


  * Converted launch files to the new launch style. ( [ #262 ](https://github.com/ros2/demos/issues/262) )
  * Updated to support remapping arguments to python nodes by passing unused arguments to rclpy from argparse. ( [ #252 ](https://github.com/ros2/demos/issues/252) )
  * Updated to handle change in signature to ` get_service_name ` . ( [ #245 ](https://github.com/ros2/demos/issues/245) )
  * Updated launch files to account for the \"old launch\" getting renamespaced as ` launch ` -> ` launch.legacy ` . ( [ #239 ](https://github.com/ros2/demos/issues/239) )
  * Updated service client demos to handle multiple requests. ( [ #228 ](https://github.com/ros2/demos/issues/228) )
  * Contributors: Geoffrey Biggs, Kevin Allen, Shane Loretz, William Woodall, dhood


Primary States (steady states):


    [lc_talker] on_activate() is called.
    [lc_talker] Lifecycle publisher is active. Publishing: [Lifecycle HelloWorld #11]
    [lc_talker] Lifecycle publisher is active. Publishing: [Lifecycle HelloWorld #12]
    ...


##  lifecycle_talker, lifecycle_listener and lifecycle_service_client


It returns a list of all possible transitions this node can execute.


##  0.6.1 (2018-12-13)


Please note that the index of the published message is already at 11. The
purpose of this demo is to show that even though we call ` publish ` at every
state of the lifecycle talker, the messages are only actually published when
the state in active.


The difference to the transition event before is that our listener now also
receives the actual published data.


* Service ` <node_name>__change_state ` : triggers a transition for the current node.


    #include "rclcpp_lifecycle/lifecycle_node.hpp"
    #include "rclcpp_lifecycle/lifecycle_publisher.hpp"
    #include "rcutils/logging_macros.h"
    #include "sensor_msgs/msg/image.hpp"

    #include "utils.cpp"

    using namespace std::chrono_literals;

    class CameraNode : public rclcpp_lifecycle::LifecycleNode
    {
    public:
      /* The constructor takes in a node_name and a boolean flag for whether to
       * use intra-process communication or not. The captureImage() method is
       * used to capture an image from the camera and process it as necessary.
       * It first checks whether the publisher is active or not and then creates
       * an image message to publish using the publisher. The image message is of
       * type sensor_msgs::msg::Image. The publisher is a lifecycle publisher which
       * means it can be activated or deactivated during runtime using the ROS2 lifecycle interface.
       */
      explicit CameraNode(const std::string & node_name, bool intra_process_comms = false)
      : rclcpp_lifecycle::LifecycleNode(node_name,
          rclcpp::NodeOptions().use_intra_process_comms(intra_process_comms))
      {}

      void publish()
      {
        static size_t count = 0;
        cv::Mat frame_;
        if (!cap_.read(frame_)) {
          // If the camera is disconnected, stop publishing frames.
          RCLCPP_ERROR(get_logger(), "Failed to read frame from camera.");
          return;
        }

        if (!publisher_->is_activated()) {
          RCLCPP_INFO(
            get_logger(), "Lifecycle publisher is currently inactive. Messages are not published.");
        } else {
          RCLCPP_INFO(


If we look at the output of the ` lifecycle_talker ` , we notice that nothing
seems to happen. And this does make sense, since every node starts as `
unconfigured ` . The lifecycle_talker is not configured yet and in our
example, no publishers and timers are created yet. The same behavior can be
seen for the ` lifecycle_listener ` , which is less surprising given that no
publishers are available at this moment. The interesting part starts with the
third terminal. In there we launch our ` lifecycle_service_client ` which is
responsible for changing the states of the ` lifecycle_talker ` .


###  Dependant Packages


Alternatively, these three programs can be run together in the same terminal
using the launch file (as of ROS 2 Bouncy):


##  0.6.2 (2019-01-15)


[ API Docs ](http://docs.ros.org/en/iron/p/lifecycle "View API documentation
on docs.ros.org") [ Browse Code
](https://github.com/ros2/demos/tree/iron/lifecycle "View source code on
repository")


    [lc_client] Transition 1 successfully triggered.
    [lc_client] Node lc_talker has current state inactive.


_No additional authors._


The difference from the earlier transition event is that our listener now also
receives the actual published data.


In order to trigger a transition, we call the ` change_state ` service


[ Write
](/m/signin?operation=register&redirect=https%3A%2F%2Fmedium.com%2Fnew-
story&source=---two_column_layout_nav-----------------------
new_post_topnav-----------)


##  0.17.0 (2021-10-18)


###  Migration from Foxy to newer versions  


###  Wiki Tutorials


ros2 launch lifecycle lifecycle_demo.launch.py


###  Services


####  Additional Links


For the rest of the demo, you will see similar output as we deactivate and
activate the lifecycle talker and finally shut it down.


##  0.7.2 (2019-05-08)


In this post, we will take a closer look at ROS2 Lifecycle Nodes, their
benefits, and how they can be used to manage the lifecycle of different
software components in a robotic system. I will also provide some examples of
how ROS2 Lifecycle Nodes can be implemented. By the end of this post, you will
have a better understanding of ROS2 Lifecycle Nodes and how they can simplify
the management of robotic software components.


  1. configuring: We initialize our publisher and timer
  2. activate: We activate the publisher and timer in order to enable a publishing
  3. deactivate: We stop the publisher and timer
  4. cleanup: We destroy the publisher and timer


##  0.15.0 (2021-05-14)


The ` lifecycle_service_client ` application is a fixed order script for this
demo purpose only. It explains the use and the API calls made for this
lifecycle implementation, but may be inconvenient to use otherwise. For this
reason we implemented a command line tool which lets you dynamically change
states or various nodes.


  * Python lifecycle nodes
  * Lifecycle manager: A global node, handling and dispatching trigger requests for multiple nodes.
  * LifeyclceSubscriber/LifecycleWalltimer/... add more lifecycle controlled entities.


For a more verbose explanation on the applied state machine, we refer to the
design page which provides an in-detail explanation about each state and
transition.


  * changes to avoid deprecated API\'s ( [ #332 ](https://github.com/ros2/demos/issues/332) )
  * Corrected publish calls with shared_ptr signature ( [ #327 ](https://github.com/ros2/demos/issues/327) )
  * Contributors: William Woodall, ivanpauno


#  The demo


CHANGELOG


##  0.20.0 (2022-03-01)


  * Update maintainer list for Foxy ( [ #471 ](https://github.com/ros2/demos/issues/471) )
  * Contributors: Michael Jeronimo


_No additional links._


##  0.23.0 (2022-11-02)


class LifecycleTalker : public rclcpp_lifecycle::LifecycleNode


  * Cleanup the README.rst for the lifecycle demo. ( [ #508 ](https://github.com/ros2/demos/issues/508) )
  * Contributors: Chris Lalancette


      ${OpenCV_LIBRARIES})

    install(TARGETS
      camera_node
      DESTINATION lib/${PROJECT_NAME})

    ament_package()

    # Compile the package
    colcon build --packages-select camera_node

    # Now lets run the camera_node
    source install/setup.zsh

    # list running ros2 topics
    ros2 topic list

    # Output
    /camera_node/transition_event
    /parameter_events
    /rosout

    # listen to messages on the /camera_node/transition_event
    ros2 topic echo /camera_node/transition_event

    # You don't see any logs in the terminal since no transitions
    # have been made yet.


Transition States (intermediate states):


In this case we see that currently, the available transitions are ` configure
` and ` shutdown ` . The complete state machine can be viewed with the
following command, which can be helpful for debugging or visualization
purposes:


In Development


    cmake_minimum_required(VERSION 3.5)
    project(camera_node)

    # Default to C99
    if(NOT CMAKE_C_STANDARD)
      set(CMAKE_C_STANDARD 99)
    endif()

    # Default to C++14
    if(NOT CMAKE_CXX_STANDARD)
      set(CMAKE_CXX_STANDARD 14)
    endif()

    if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
      add_compile_options(-Wall -Wextra -Wpedantic)
    endif()

    # find dependencies
    find_package(ament_cmake REQUIRED)
    find_package(rclcpp_lifecycle REQUIRED)
    find_package(lifecycle_msgs REQUIRED)
    find_package(rclcpp REQUIRED)
    find_package(sensor_msgs REQUIRED)
    find_package(OpenCV REQUIRED COMPONENTS core highgui imgproc videoio)

    include_directories(
      include
      ${sensor_msgs_INCLUDE_DIRS}
      ${lifecycle_msgs_INCLUDE_DIRS}
      ${rclcpp_lifecycle_INCLUDE_DIRS}
      ${rclcpp_INCLUDE_DIRS})

    add_executable(camera_node
      src/camera_node.cpp)
      target_link_libraries(camera_node
      ${rclcpp_lifecycle_LIBRARIES}
      ${lifecycle_msgs_LIBRARIES}
      ${sensor_msgs_LIBRARIES}


  * Add missing required parameter in LifecycleNode launch action ( [ #456 ](https://github.com/ros2/demos/issues/456) )
  * Contributors: Ivan Santiago Paunovic


* Service ` <node_name>__change_state ` : triggers a transition for the current node. This service call takes a transition id. Only in the case, that this transition ID is a valid transition of the current state, the transition is fulfilled. All other cases are getting ignored.


[ lifecycle/README.rst
](https://github.com/ros2/demos/tree/iron/lifecycle/README.rst "Open in git
repository")


The ` lifecycle_service_client ` is a script calling different transitions on
the ` lifecycle_talker ` . This is meant as the external user controlling the
lifecycle of nodes.


##  0.5.0 (2018-06-27)


  * configure
  * activate
  * deactivate
  * cleanup
  * shutdown


    [lc_listener] notify callback: Transition from state unconfigured to configuring
    [lc_listener] notify callback: Transition from state configuring to inactive


##  0.8.0 (2019-09-26)


> Here’s a brief explanation of the ROS 2 packages and messages used in this
> package:
>  ` rclcpp ` : This is a C++ client library for ROS 2 that provides a thin
> C++-style interface for writing ROS 2 nodes. It allows users to create
> publishers and subscribers, services and clients, actions and servers, etc.
>  ` rclcpp_lifecycle ` : This is an extension of ` rclcpp ` that provides an
> implementation of the "lifecycle" concept. A lifecycle node is a special
> type of node that can go through different states, such as "unconfigured",
> "inactive", "active", and "finalized". These states allow for a more
> controlled initialization and shutdown process for nodes.
>  ` rcutils ` : This is a C library that provides some basic, low-level
> functionality that is useful in ROS 2 development. For example, it provides
> a logging API that allows users to log messages with different severity
> levels.
>  ` sensor_msgs ` : This is a ROS 2 package that provides message types for
> commonly used sensors, such as cameras, lidars, and IMUs. In the code
> snippet provided, the ` std_msgs/msg/String ` message type is used, but it
> could be replaced with any message type from the ` sensor_msgs ` package,
> such as ` sensor_msgs/msg/Image ` for a camera node.
>  ` lifecycle_msgs ` : This is a ROS 2 package that provides message types
> for the lifecycle concept. For example, the ` lifecycle_msgs/msg/Transition
> ` message type is used to communicate the success or failure of a lifecycle
> transition from a node to the lifecycle management software.

    cd camera_node && touch src/camera_node.cpp

    // camera_node.cpp
    #include <chrono>
    #include <iostream>
    #include <memory>
    #include <string>
    #include <thread>
    #include <utility>

    #include "lifecycle_msgs/msg/transition.hpp"
    #include "opencv2/highgui/highgui.hpp"
    #include "rclcpp/rclcpp.hpp"
    #include "rclcpp/publisher.hpp"


##  0.7.1 (2019-04-26)