      <plugin
        filename="ignition-gazebo-thruster-system"
        name="ignition::gazebo::systems::Thruster">
        <namespace>tethys</namespace>
        <joint_name>propeller_joint</joint_name>
        <thrust_coefficient>0.004422</thrust_coefficient>
        <fluid_density>1000</fluid_density>
        <propeller_diameter>0.2</propeller_diameter>
      </plugin>


Name  |  Name  |


Name


<?xml version="1.0" ?>
<!--
  Ignition Gazebo apply joint force system demo


Toggle navigation


  * README
  * GPL-2.0 license


The following SDF snippet shows an example usage:


            <cylinder>
              <radius>0.08</radius>
              <length>0.3</length>
            </cylinder>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
        </visual>
        <visual name="vis_cylinder">
          <pose>0 0 0.5 0 0 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.9</length>
            </cylinder>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
        </visual>
        <collision name="col_lower_joint">
          <pose>0 0 0 0 1.5708 0</pose>
          <geometry>
            <cylinder>
              <radius>0.08</radius>
              <length>0.3</length>
            </cylinder>
          </geometry>
        </collision>
        <collision name="col_cylinder">
          <pose>0 0 0.5 0 0 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.9</length>


[ HBPNeurorobotics ](/HBPNeurorobotics) /  **[ gazebo_dvs_plugin
](/HBPNeurorobotics/gazebo_dvs_plugin) ** Public


##  Languages


* [ Pricing ](/pricing)


![](group__GazeboRosCamera.png)
---

##  Classes

---
class  |  [ gazebo::GazeboRosCamera ](classgazebo_1_1GazeboRosCamera.html)
|  [ GazeboRosCamera ](classgazebo_1_1GazeboRosCamera.html "GazeboRosCamera
Controller.") Controller. [ More...
](classgazebo_1_1GazeboRosCamera.html#_details)

* * *


  * [ C++  89.8%  ](/HBPNeurorobotics/gazebo_dvs_plugin/search?l=c%2B%2B)
  * [ CMake  10.2%  ](/HBPNeurorobotics/gazebo_dvs_plugin/search?l=cmake)


      <model:physical name="camera_model">
        <body:empty name="camera_body_name">
          <sensor:camera name="camera_sensor">
            <controller:gazebo_ros_camera name="controller-name" plugin="libgazebo_ros_camera.so">
                <alwaysOn>true</alwaysOn>
                <updateRate>15.0</updateRate>
                <imageTopicName>camera_name/image_raw</imageTopicName>
                <cameraInfoTopicName>camera_name/camera_info</cameraInfoTopicName>
                <frameName>camera_body_name</frameName>
            </controller:gazebo_ros_camera>
          </sensor:camera>
        </body:empty>
      </model:phyiscal>


[ Activity  ](/HBPNeurorobotics/gazebo_dvs_plugin/activity)


First, make sure the DVS datatypes are available in your installation. For
this, clone the [ RPG DVS ROS ](https://github.com/uzh-rpg/rpg_dvs_ros)
package into your catkin workspace.


#  DVS Gazebo Plugin


    * [ 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)


Explore


1. Move the rudder:


[ LICENSE ](/HBPNeurorobotics/gazebo_dvs_plugin/blob/master/LICENSE "LICENSE")


[ Sign in
](/login?return_to=https%3A%2F%2Fgithub.com%2FHBPNeurorobotics%2Fgazebo_dvs_plugin)


[ **16** forks ](/HBPNeurorobotics/gazebo_dvs_plugin/forks)


[ ](/HBPNeurorobotics/gazebo_dvs_plugin/branches) [
](/HBPNeurorobotics/gazebo_dvs_plugin/tags)


GPL-2.0 license


This plugin can be used as a drop-in replacement for normal Gazebo camera
plugins. Both, the DVS plugin and the [ CameraPlugin
](https://bitbucket.org/osrf/gazebo/src/666bf30ad9a3c042955b55f79cf1a5416a70d83d/plugins/CameraPlugin.cc)
use the Gazebo [ CameraSensor
](https://bitbucket.org/osrf/gazebo/src/666bf30ad9a3c042955b55f79cf1a5416a70d83d/gazebo/sensors/CameraSensor.cc)
internally.


Search


[ CMakeLists.txt
](/HBPNeurorobotics/gazebo_dvs_plugin/blob/master/CMakeLists.txt
"CMakeLists.txt")


#  Provide feedback


* Solutions


    * [ Learning Pathways  ](https://resources.github.com/learn/pathways/)
    * [ White papers, Ebooks, Webinars  ](https://resources.github.com/)
    * [ Customer Stories ](/customer-stories)
    * [ Partners  ](https://partner.github.com/)


    @INPROCEEDINGS{7862386,
    author={J. Kaiser and J. C. V. Tieck and C. Hubschneider and P. Wolf and M. Weber and M. Hoff and A. Friedrich and K. Wojtasik and A. Roennau and R. Kohlhaas and R. Dillmann and J. M. Zöllner},
    booktitle={2016 IEEE International Conference on Simulation, Modeling, and Programming for Autonomous Robots (SIMPAR)},
    title={Towards a framework for end-to-end control of a simulated vehicle with spiking neural networks},
    year={2016},
    pages={127-134},
    keywords={automobiles;cameras;complex networks;feedforward neural nets;learning (artificial intelligence);mobile robots;DVS;camera images;complex networks;deep learning architectures;end-to-end simulated vehicle control;hand-crafted feature detectors;neural self-driving vehicle applications;neurorobotics applications;rate-based neural networks;silicon retina;spiking neural networks;steering wheel decoder;vehicle end-to-end for lane following behavior;Biological neural networks;Brain modeling;Cameras;Robot sensing systems;Voltage control},
    doi={10.1109/SIMPAR.2016.7862386},
    month={Dec},}


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


[ 29  stars ](/HBPNeurorobotics/gazebo_dvs_plugin/stargazers) [ 16  forks
](/HBPNeurorobotics/gazebo_dvs_plugin/forks) [ Branches
](/HBPNeurorobotics/gazebo_dvs_plugin/branches) [ Tags
](/HBPNeurorobotics/gazebo_dvs_plugin/tags) [ Activity
](/HBPNeurorobotics/gazebo_dvs_plugin/activity)


{{ message }}


[ Notifications ](/login?return_to=%2FHBPNeurorobotics%2Fgazebo_dvs_plugin)


  * [ Code  ](/HBPNeurorobotics/gazebo_dvs_plugin)
  * [ Issues  ](/HBPNeurorobotics/gazebo_dvs_plugin/issues)
  * [ Pull requests  ](/HBPNeurorobotics/gazebo_dvs_plugin/pulls)
  * [ Actions  ](/HBPNeurorobotics/gazebo_dvs_plugin/actions)
  * [ Projects  ](/HBPNeurorobotics/gazebo_dvs_plugin/projects)
  * [ Security  ](/HBPNeurorobotics/gazebo_dvs_plugin/security)
  * [ Insights  ](/HBPNeurorobotics/gazebo_dvs_plugin/pulse)


Try sending commands:


##  Detailed Description


[ include/  gazebo_dvs_plugin
](/HBPNeurorobotics/gazebo_dvs_plugin/tree/master/include/gazebo_dvs_plugin
"This path skips through empty directories")


  This will stop applying the force. The joint may continue to rotate for some time before coming to a stop
    ign topic -t "/model/joint_force_example/joint/j1/cmd_force" -m ignition.msgs.Double  -p "data: 0.0"
-->
<sdf version="1.6">
  <world name="apply_joint_force">
    <plugin
      filename="ignition-gazebo-physics-system"
      name="gz::sim::systems::Physics">
    </plugin>
    <plugin
      filename="ignition-gazebo-scene-broadcaster-system"
      name="gz::sim::systems::SceneBroadcaster">
    </plugin>


##  Use saved searches to filter your results more quickly


[ **10** watching ](/HBPNeurorobotics/gazebo_dvs_plugin/watchers)


      <!-- Vertical fin -->
      <plugin
        filename="ignition-gazebo-lift-drag-system"
        name="ignition::gazebo::systems::LiftDrag">
        <air_density>1000</air_density>
        <cla>4.13</cla>
        <cla_stall>-1.1</cla_stall>
        <cda>0.2</cda>
        <cda_stall>0.03</cda_stall>
        <alpha_stall>0.17</alpha_stall>
        <a0>0</a0>
        <area>0.0244</area>
        <upward>0 1 0</upward>
        <forward>1 0 0</forward>
        <link_name>vertical_fins</link_name>
        <cp>0 0 0</cp>
      </plugin>


Readme


      <joint name="j1" type="revolute">
        <pose>0 0 -0.5 0 0 0</pose>
        <parent>base_link</parent>
        <child>rotor</child>
        <axis>
          <xyz>0 0 1</xyz>
          <dynamics>
            <damping>0.0001</damping>
          </dynamics>
        </axis>
      </joint>
      <plugin
        filename="ignition-gazebo-apply-joint-force-system"
        name="gz::sim::systems::ApplyJointForce">
        <joint_name>j1</joint_name>
      </plugin>
    </model>
  </world>
</sdf>


<?xml version="1.0" ?>
<!--
  Ignition Gazebo pose publisher plugin demo
  Try listening to topic:
    ign topic -e -t "/model/double_pendulum_with_base/pose"
-->
<sdf version="1.6">
  <world name="pose_publisher">
    <physics name="1ms" type="ignored">
      <max_step_size>0.001</max_step_size>
      <real_time_factor>1.0</real_time_factor>
    </physics>
    <plugin
      filename="ignition-gazebo-physics-system"
      name="gz::sim::systems::Physics">
    </plugin>
    <plugin
      filename="ignition-gazebo-user-commands-system"
      name="gz::sim::systems::UserCommands">
    </plugin>
    <plugin
      filename="ignition-gazebo-scene-broadcaster-system"
      name="gz::sim::systems::SceneBroadcaster">
    </plugin>
    <light type="directional" name="sun">
      <cast_shadows>true</cast_shadows>
      <pose>0 0 10 0 0 0</pose>
      <diffuse>1 1 1 1</diffuse>
      <specular>0.5 0.5 0.5 1</specular>
      <attenuation>
        <range>1000</range>
        <constant>0.9</constant>
        <linear>0.01</linear>
        <quadratic>0.001</quadratic>
      </attenuation>
      <direction>-0.5 0.1 -0.9</direction>
    </light>
    <model name="ground_plane">
      <static>true</static>
      <link name="link">


      <!-- Joint controllers -->
      <plugin
        filename="ignition-gazebo-joint-position-controller-system"
        name="ignition::gazebo::systems::JointPositionController">
        <joint_name>horizontal_fins_joint</joint_name>
        <p_gain>0.1</p_gain>
      </plugin>


###  Resources


This package provides a DVS simulation implemented as Gazebo plugin.


No packages published


    * [ Enterprise ](/enterprise)
    * [ Teams ](/team)
    * [ Startups ](/enterprise/startups)
    * [ Education  ](https://education.github.com)


* [ The ReadME Project  GitHub community articles  ](/readme)


[ Custom properties  ](/HBPNeurorobotics/gazebo_dvs_plugin/custom-properties)


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


        <visual name="vis_upper_joint">
          <pose>-0.05 0 0 0 1.5708 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.3</length>
            </cylinder>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
        </visual>
        <visual name="vis_lower_joint">
          <pose>0 0 1.0 0 1.5708 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.2</length>
            </cylinder>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
        </visual>
        <visual name="vis_cylinder">
          <pose>0 0 0.5 0 0 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.9</length>
            </cylinder>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>


      <pose>0 0 0.005 0 0 0</pose>
      <link name="base_link">
        <pose>0.0 0.0 0.0 0 0 0</pose>
        <inertial>
          <inertia>
            <ixx>2.501</ixx>
            <ixy>0</ixy>
            <ixz>0</ixz>
            <iyy>2.501</iyy>
            <iyz>0</iyz>
            <izz>5</izz>
          </inertia>
          <mass>120.0</mass>
        </inertial>
        <visual name="base_visual">
          <pose>0.0 0.0 0.0 0 0 0</pose>
          <geometry>
            <box>
              <size>0.5 0.5 0.01</size>
            </box>
          </geometry>
          <material>
            <ambient>1.0 0.0 0.0 1</ambient>
            <diffuse>1.0 0.0 0.0 1</diffuse>
            <specular>1.0 0.0 0.0 1</specular>
          </material>
        </visual>
        <collision name="base_collision">
          <pose>0.0 0.0 0.0 0 0 0</pose>
          <geometry>
            <box>
              <size>0.5 0.5 0.01</size>
            </box>
          </geometry>
        </collision>
      </link>
      <link name="rotor">
        <pose>0.0 0.0 1.0 0.0 0 0</pose>
        <inertial>
          <pose>0.0 0.0 0.0 0 0 0</pose>


Last commit message


##  [ Contributors  3
](/HBPNeurorobotics/gazebo_dvs_plugin/graphs/contributors)


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


      ign topic -t /model/tethys/joint/propeller_joint/cmd_thrust
      -m ignition.msgs.Double -p 'data: -31'


    <sensor name='camera' type='camera'>
        <camera name='__default__'>
            <horizontal_fov>1.8</horizontal_fov>
            <image>
                <width>128</width>
                <height>128</height>
            </image>
            <clip>
                <near>0.1</near>
                <far>100</far>
            </clip>
        </camera>
        <always_on>1</always_on>
        <update_rate>60</update_rate>
        <visualize>0</visualize>
        <plugin name='camera_controller' filename='libgazebo_dvs_plugin.so'>
            <cameraName>camera_front</cameraName>
            <robotNamespace>AADC_AudiTT</robotNamespace>
            <eventThreshold>10</eventThreshold>
            <cameraInfoTopicName>camera_info</cameraInfoTopicName>
            <!-- <eventsTopicName>events</eventsTopicName> -->
        </plugin>
    </sensor>


Cancel  Create saved search


Skip to content


2. Propel the vehicle:


[ LICENSE ](/HBPNeurorobotics/gazebo_dvs_plugin/blob/master/LICENSE "LICENSE")


[ ](/HBPNeurorobotics/gazebo_dvs_plugin/commits/master/)

###


    * [ CI/CD & Automation ](/solutions/ci-cd/)
    * [ DevOps ](/solutions/devops/)
    * [ DevSecOps  ](https://resources.github.com/devops/fundamentals/devsecops/)


[ Star  ](/login?return_to=%2FHBPNeurorobotics%2Fgazebo_dvs_plugin)


      ign topic -t /model/tethys/joint/vertical_fins_joint/0/cmd_pos \
         -m ignition.msgs.Double -p 'data: -0.17'


The parameters ` robotNamespace ` , ` cameraName ` and ` eventsTopicName `
(default: "events") result in ` "$robotNamespace/$cameraName/$eventsTopicName"
` as the identifier of the provided events topic. In this case, events will be
accessible from ` "/AADC_AudiTT/camera_front/events" ` .


For


You can’t perform that action at this time.


[ Search syntax tips ](https://docs.github.com/search-github/github-code-
search/understanding-github-code-search-syntax)


  Example showing various marine plugins working together for an
  Autonomous Underwater Vehicle (AUV).


###  Stars


#  Saved searches


    <light type="directional" name="sun">
      <cast_shadows>true</cast_shadows>
      <pose>0 0 10 0 0 0</pose>
      <diffuse>0.8 0.8 0.8 1</diffuse>
      <specular>0.2 0.2 0.2 1</specular>
      <attenuation>
        <range>1000</range>
        <constant>0.9</constant>
        <linear>0.01</linear>
        <quadratic>0.001</quadratic>
      </attenuation>
      <direction>-0.5 0.1 -0.9</direction>
    </light>
    <model name="ground_plane">
      <static>true</static>
      <link name="link">
        <collision name="collision">
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
        </collision>
        <visual name="visual">
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
        </visual>
      </link>
    </model>
    <model name="joint_force_example">


#  HBPNeurorobotics/gazebo_dvs_plugin


[ Branches  ](/HBPNeurorobotics/gazebo_dvs_plugin/branches) [ Tags
](/HBPNeurorobotics/gazebo_dvs_plugin/tags)


  </world>
</sdf>


[ package.xml ](/HBPNeurorobotics/gazebo_dvs_plugin/blob/master/package.xml
"package.xml")


    <physics name="1ms" type="ode">
      <max_step_size>0.001</max_step_size>
      <real_time_factor>1.0</real_time_factor>
    </physics>
    <plugin
      filename="ignition-gazebo-physics-system"
      name="ignition::gazebo::systems::Physics">
    </plugin>
    <plugin
      filename="ignition-gazebo-user-commands-system"
      name="ignition::gazebo::systems::UserCommands">
    </plugin>
    <plugin
      filename="ignition-gazebo-scene-broadcaster-system"
      name="ignition::gazebo::systems::SceneBroadcaster">
    </plugin>
    <plugin
      filename="ignition-gazebo-buoyancy-system"
      name="ignition::gazebo::systems::Buoyancy">
      <uniform_fluid_density>1000</uniform_fluid_density>
    </plugin>


This commit does not belong to any branch on this repository, and may belong
to a fork outside of the repository.


##  Footer


  * [ Notifications ](/login?return_to=%2FHBPNeurorobotics%2Fgazebo_dvs_plugin)
  * [ Fork  16  ](/login?return_to=%2FHBPNeurorobotics%2Fgazebo_dvs_plugin)
  * [ Star  29  ](/login?return_to=%2FHBPNeurorobotics%2Fgazebo_dvs_plugin)


The sensor parameter ` update_rate ` has only limited effect in Gazebo. The
real rate is determined by the rendering pipeline and can be way lower than
the specified rate. Still, this implementation yields a higher event frequency
than similar Python-based implementations as a standalone node.


  * [ 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


        <collision name="collision">
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
        </collision>
        <visual name="visual">
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
        </visual>
      </link>
    </model>
    <model name="double_pendulum_with_base">
      <link name="base">
        <inertial>
          <mass>100</mass>
        </inertial>
        <visual name="vis_plate_on_ground">
          <pose>0 0 0.01 0 0 0</pose>
          <geometry>
            <cylinder>
              <radius>0.8</radius>
              <length>0.02</length>
            </cylinder>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>


      <!-- Horizontal fin -->
      <plugin
        filename="ignition-gazebo-lift-drag-system"
        name="ignition::gazebo::systems::LiftDrag">
        <air_density>1000</air_density>
        <cla>4.13</cla>
        <cla_stall>-1.1</cla_stall>
        <cda>0.2</cda>
        <cda_stall>0.03</cda_stall>
        <alpha_stall>0.17</alpha_stall>
        <a0>0</a0>
        <area>0.0244</area>
        <upward>0 0 1</upward>
        <forward>1 0 0</forward>
        <link_name>horizontal_fins</link_name>
        <cp>0 0 0</cp>
      </plugin>


[ src ](/HBPNeurorobotics/gazebo_dvs_plugin/tree/master/src "src")


##  Folders and files


|

View all files

##  Repository files navigation


###  Forks


##  History


Ros Camera Plugin Controller.


[ 15 Commits  ](/HBPNeurorobotics/gazebo_dvs_plugin/commits/master/)


Clear


      <!-- hydrodynamics plugin-->
      <plugin
        filename="ignition-gazebo-hydrodynamics-system"
        name="ignition::gazebo::systems::Hydrodynamics">
        <link_name>base_link</link_name>
        <xDotU>-4.876161</xDotU>
        <yDotV>-126.324739</yDotV>
        <zDotW>-126.324739</zDotW>
        <kDotP>0</kDotP>
        <mDotQ>-33.46</mDotQ>
        <nDotR>-33.46</nDotR>
        <xUabsU>-6.2282</xUabsU>
        <xU>0</xU>
        <yVabsV>-601.27</yVabsV>
        <yV>0</yV>
        <zWabsW>-601.27</zWabsW>
        <zW>0</zW>
        <kPabsP>-0.1916</kPabsP>
        <kP>0</kP>
        <mQabsQ>-632.698957</mQabsQ>
        <mQ>0</mQ>
        <nRabsR>-632.698957</nRabsR>
        <nR>0</nR>
      </plugin>


[ README.md ](/HBPNeurorobotics/gazebo_dvs_plugin/blob/master/README.md
"README.md")


Then, clone this package into your workspace and rebuild.


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


Cancel  Submit feedback


* Product


###  Footer navigation


##  [ Packages  0
](/orgs/HBPNeurorobotics/packages?repo_name=gazebo_dvs_plugin)


[ All ](javascript:void\(0\)) [ Classes ](javascript:void\(0\)) [ Namespaces
](javascript:void\(0\)) [ Files ](javascript:void\(0\)) [ Functions
](javascript:void\(0\)) [ Variables ](javascript:void\(0\)) [ Typedefs
](javascript:void\(0\)) [ Enumerator ](javascript:void\(0\)) [ Friends
](javascript:void\(0\)) [ Defines ](javascript:void\(0\))


Collaboration diagram for Ros Camera Plugin XML Reference and Example:


By Solution


The following plugins are used:


          </material>
        </visual>
        <collision name="col_upper_joint">
          <pose>-0.05 0 0 0 1.5708 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.3</length>
            </cylinder>
          </geometry>
        </collision>
        <collision name="col_lower_joint">
          <pose>0 0 1.0 0 1.5708 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.2</length>
            </cylinder>
          </geometry>
        </collision>
        <collision name="col_cylinder">
          <pose>0 0 0.5 0 0 0</pose>
          <geometry>
            <cylinder>
              <radius>0.1</radius>
              <length>0.9</length>
            </cylinder>
          </geometry>
        </collision>
      </link>
      <!-- lower link, length 1, IC ~-120 degrees more -->
      <link name="lower_link">
        <pose>0.25 1.0 2.1 -2 0 0</pose>
        <self_collide>0</self_collide>
        <inertial>
          <pose>0 0 0.5 0 0 0</pose>
        </inertial>
        <visual name="vis_lower_joint">
          <pose>0 0 0 0 1.5708 0</pose>
          <geometry>


[ include/  gazebo_dvs_plugin
](/HBPNeurorobotics/gazebo_dvs_plugin/tree/master/include/gazebo_dvs_plugin
"This path skips through empty directories")


[ gazebo_plugins ](http://ros.org/wiki/gazebo_plugins)
Author(s): Sachin Chitta, Stu Glaser, John Hsu  autogenerated on Fri Jan 11
10:09:30 2013


##  About


Last commit date

---|---|---|---

##  Latest commit


          <inertia>
            <ixx>0.032</ixx>
            <ixy>0</ixy>
            <ixz>0</ixz>
            <iyy>0.032</iyy>
            <iyz>0</iyz>
            <izz>0.00012</izz>
          </inertia>
          <mass>0.6</mass>
        </inertial>
        <visual name="visual">
          <geometry>
            <box>
              <size>0.25 0.25 0.05</size>
            </box>
          </geometry>
          <material>
            <ambient>0.0 0.0 1.0 1</ambient>
            <diffuse>0.0 0.0 1.0 1</diffuse>
            <specular>0.0 0.0 1.0 1</specular>
          </material>
        </visual>
        <collision name="collision">
          <geometry>
            <box>
              <size>0.25 0.25 0.05</size>
            </box>
          </geometry>
        </collision>
      </link>


Ros Camera Plugin Controller.  More...


You signed in with another tab or window. [ Reload ]() to refresh your
session.  You signed out in another tab or window. [ Reload ]() to refresh
your session.  You switched accounts on another tab or window. [ Reload ]() to
refresh your session.  Dismiss alert


Additional navigation options


          </material>
        </visual>
        <visual name="vis_pole">
          <pose>-0.275 0 1.1 0 0 0</pose>
          <geometry>
            <box>
              <size>0.2 0.2 2.2</size>
            </box>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
        </visual>
        <collision name="col_plate_on_ground">
          <pose>0 0 0.01 0 0 0</pose>
          <geometry>
            <cylinder>
              <radius>0.8</radius>
              <length>0.02</length>
            </cylinder>
          </geometry>
        </collision>
        <collision name="col_pole">
          <pose>-0.275 0 1.1 0 0 0</pose>
          <geometry>
            <box>
              <size>0.2 0.2 2.2</size>
            </box>
          </geometry>
        </collision>
      </link>
      <!-- upper link, length 1, IC -90 degrees -->
      <link name="upper_link">
        <pose>0 0 2.1 -1.5708 0 0</pose>
        <self_collide>0</self_collide>
        <inertial>
          <pose>0 0 0.5 0 0 0</pose>
        </inertial>


[ Report repository ](/contact/report-
content?content_url=https%3A%2F%2Fgithub.com%2FHBPNeurorobotics%2Fgazebo_dvs_plugin&report=HBPNeurorobotics+%28user%29)


##  [ Releases ](/HBPNeurorobotics/gazebo_dvs_plugin/releases)


-->
<sdf version="1.6">
  <world name="buoyant_tethys">
    <scene>
      <!-- For turquoise ambient -->
      <ambient>0.0 1.0 1.0</ambient>
      <background>0.0 0.7 0.8</background>
    </scene>


[ GPL-2.0 license ](/HBPNeurorobotics/gazebo_dvs_plugin/blob/master/LICENSE)


#  Acknowledgement


Search or jump to...


###  License


#  Ros Camera Plugin XML Reference and Example
[ [ Gazebo ROS Dynamic Plugins ](group__gazebo__dynamic__plugins.html) ]


  * [ Main Page  ](index.html)
  * [ Related Pages  ](pages.html)
  * [ Modules  ](modules.html)
  * [ Namespaces  ](namespaces.html)
  * [ Classes  ](annotated.html)
  * [ Files  ](files.html)
  * ![](search/search.png) [ ![](search/close.png) ](javascript:searchBox.CloseResultsWindow\(\))


[ **29** stars ](/HBPNeurorobotics/gazebo_dvs_plugin/stargazers)


Example commands for the vehicle to move in a circle:


The parameter ` eventThreshold ` specifies the pixel-wise threshold which has
to be exceeded for a event to be emitted for this pixel.


Include my email address so I can be contacted


[ CMakeLists.txt
](/HBPNeurorobotics/gazebo_dvs_plugin/blob/master/CMakeLists.txt
"CMakeLists.txt")


    <include>
      <pose>0 0 1 0 0 1.57</pose>
      <uri>https://fuel.ignitionrobotics.org/1.0/accurrent/models/MBARI%20Tethys%20LRAUV</uri>


master


<!-- Lift and drag -->


</include>


Resources


No releases published


    <light type="directional" name="sun">
      <cast_shadows>true</cast_shadows>
      <pose>0 0 10 0 0 0</pose>
      <diffuse>1 1 1 1</diffuse>
      <specular>0.5 0.5 0.5 1</specular>
      <attenuation>
        <range>1000</range>
        <constant>0.9</constant>
        <linear>0.01</linear>
        <quadratic>0.001</quadratic>
      </attenuation>
      <direction>-0.5 0.1 -0.9</direction>
    </light>


This package provides a DVS simulation implemented as Gazebo plugin.


##  Install


Code


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


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


###  Watchers


            </cylinder>
          </geometry>
        </collision>
      </link>
      <!-- pin joint for upper link, at origin of upper link -->
      <joint name="upper_joint" type="revolute">
        <parent>base</parent>
        <child>upper_link</child>
        <axis>
          <xyz>1.0 0 0</xyz>
        </axis>
      </joint>
      <!-- pin joint for lower link, at origin of child link -->
      <joint name="lower_joint" type="revolute">
        <parent>upper_link</parent>
        <child>lower_link</child>
        <axis>
          <xyz>1.0 0 0</xyz>
        </axis>
      </joint>
      <plugin
        filename="ignition-gazebo-pose-publisher-system"
        name="gz::sim::systems::PosePublisher">
        <publish_link_pose>true</publish_link_pose>
        <publish_collision_pose>false</publish_collision_pose>
        <publish_visual_pose>false</publish_visual_pose>
        <publish_nested_model_pose>false</publish_nested_model_pose>
      </plugin>
    </model>
  </world>
</sdf>


Example Usage:


This is somewhere that the launch system in ROS 2 can hopefully improve on
what ` roslaunch ` from ROS 1 had to offer, and it can do so by providing not
only these common reactions to processes exiting, but also by providing more
granular information about the process exit (and other events), and by letting
the user specify arbitrary responses to these type of events.


Skip to content


  Goals  

The repository has two other goals:

  1. Implements the example configuration described in the ` ros-controls/roadmap  ` repository file [ components_architecture_and_urdf_examples ](https://github.com/ros-controls/roadmap/blob/master/design_drafts/components_architecture_and_urdf_examples.md) .

  2. The repository is a validation environment for ` ros2_control  ` concepts, which can only be tested during run-time (e.g., execution of controllers by the controller manager, communication between robot hardware and controllers).


That covers most of the features and design goals of ` roslaunch ` from ROS 1,
but in the next subsection we’ll discuss what is different for the launch
system in ROS 2 due to changes in ROS 2 and how it might improve on the launch
system from ROS 1.


          * Parallel vs Sequential Loading of Nodes
          * Registration of Composable Nodes
    * Event Subsystem
      * Categories of Events by Source
        * Launch System Events
        * Operating System Events
        * ROS Specific Events
      * Reporting and Handling of Events
        * Information Provided by Events
        * Event Handlers
        * Handling of Events
          * Event Filters
        * Sending Events
    * System Description
      * Launch Descriptions
        * Actions
          * Including Another Launch Description
          * Launch System Configuration
          * Execute a Process
          * Event Handlers
          * Emitting Events
        * Groups
        * Substitutions
      * Mapping to Programming Languages and Markup Languages
    * Execution and Verification of the System Description
    * Testing
    * Requirements
    * Reference Implementation Proposal
    * Alternatives
    * References


##  Testing


Advantages:


A container process must offer all of the following services.


In ROS 2, there are only one kind of parameters and they work differently. In
general they work more like “dynamic reconfigure parameters” from ROS 1, in
that they are node specific (no truly global parameters) and they are managed
by the node (the node can refuse changes and parameters can only be read and
changed while the node is running). More details can be found in the
parameters design document  2  .


[ ros2_control_demos-not-released.rolling.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos-not-
released.rolling.repos "ros2_control_demos-not-released.rolling.repos")


This applies to “plain” ROS nodes, but there is more that the launch system
can use in Managed ROS Nodes, which is described in the next section.


For example, there might be the ` on_event ` event handler signature, which
then returns a given set of actions or groups the user provides. This
signature might be useful to after ten seconds start a node or include another
launch file, and in XML it might look like this:


This fundamental difference in how parameters work will affect both the
architecture of the launch system in ROS 2 and how users specify parameters
for nodes via the launch system.


#####  Container Process API


[ ros2_control_demos-not-released.galactic.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos-not-
released.galactic.repos "ros2_control_demos-not-released.galactic.repos")


Like many other event systems, the events should be capable of not only
notifying that an event has occurred, but it should be able to communicate
data associated with the event.


[ ](/ros-controls/ros2_control_demos/branches) [ ](/ros-
controls/ros2_control_demos/tags)


Query


[ **16** watching ](/ros-controls/ros2_control_demos/watchers)


One of the objectives of the launch system in ROS 2 is to emulate the features
of the launch system in ROS 1, but due to architectural changes in ROS 2, some
of the features, goals, and terminology need to change.


  * after a period of time, signal ` SIGTERM `
  * after a period of time, signal ` SIGKILL `
  * nothing


This allows for more complex actions which might include, but not be limited
to:


Cancel  Create saved search


TODO: This will outline what we have and what we need to build and how it
should be separated.


[ Dockerfile ](/ros-controls/ros2_control_demos/tree/humble/Dockerfile
"Dockerfile")


The example shows how to implement robot hardware with separate communication
to each actuator.


[ README.md ](/ros-controls/ros2_control_demos/blob/humble/README.md
"README.md")


####  Groups


The lowest level of event handlers is the function which takes an event and
returns a launch description. For example, a user defined event handler might
look like this in Python:


Regardless of how the user uses the launch system to interact with these
items, they should be exposed by the launch system, which is the only entity
which can interact with them directly.


#####  Emitting Events


  * “Package name + executable name” rather than “executable name + PATH” (i.e. ` ros2 run ` equivalent)
  * ROS specific environment variables (e.g. ` ROS_DOMAIN_ID ` , ` RMW_IMPLEMENTATION ` , console output formatting, etc…)
  * ROS specific command line arguments
    * Varies for single Node processes and multi Node processes
    * Change node name or namespace
    * Remap topics, services, actions, parameters, etc…
    * Initialize parameter values


[ CONTRIBUTING.md ](/ros-
controls/ros2_control_demos/blob/humble/CONTRIBUTING.md "CONTRIBUTING.md")


ROS specific events would most likely occur in processes that launch is
executing, but using ROS topics and/or services launch could observe these
events and generate equivalent events within the launch event system. For
example, if a process being run by launch contains a node with a life cycle,
launch could observe any life cycle state transitions the node makes and
create an event each time one of those transitions occur. Using this a user
could, for example, wait for a node to reach the “active” state and only then
start another process.


######  Command Line Arguments


Building yet again on previous entities, the “Managed ROS Nodes” inherits all
of the execution, runtime, and termination characteristics from normal ROS
nodes and therefore  operating system processes  .


hardware
Restructuring for example_1 (#234)
last year
test
Add pytest for example1 description (#342) (#419)
4 months ago
CMakeLists.txt
Add pytest for example1 description (#342) (#419)
4 months ago
README.md
Add readmes in every example folder (#262)
last year
package.xml
Add pytest for example1 description (#342) (#419)
4 months ago
ros2_control_demo_example_1.xml
Restructuring for example_1 (#234)
last year
README.md
ros2_control_demo_example_1
RRBot - or ''Revolute-Revolute Manipulator Robot'' - a simple position controlled robot with one hardware interface. This example also demonstrates the switching between different controllers.


[ ros2_control_demos.humble.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos.humble.repos
"ros2_control_demos.humble.repos")


By default, events are passed to all event handlers and there is no way for an
event handler to “accept” an event to prevent it from being delivered to other
events.


{{ message }}


* docking_server


The repository is structured into ` example_XY ` folders that fully contained
packages with names ` ros2_control_demos_example_XY ` .


  * Requires write access to the file system
  * Requires parsing a config file
  * Cannot tell from the outside if a container process supports this interface
  * Cannot tell if and when nodes are loaded or unloaded


The following output must be seen in the Meili Agent’s terminal. This
indicates that the connection between the robot and Meili FMS’s dashboard has
been established successfully , using WebSocket.


If a container process is asked to load a node with a full node name matching
an existing node, then it must reject the request. This is to avoid conflicts
in features that assume node name uniqueness, like parameters.


####  Actions


#  ros2_control Demos


Toggle navigation  [ ROS 2 Design ](/)


[ example_1 ](/ros-controls/ros2_control_demos/tree/humble/example_1
"example_1")


    <!-- This is a made up example of a markup, consider it pseudo code... -->
    <!-- Also this could be made even simpler by just having a tag which lets -->
    <!-- you specify the extra actions directly, rather than emitting an event and -->
    <!-- handling it, but this demonstrates the custom event handler signature -->

    <emit_event after="10" type="my_custom_timer_event" />

    <on_event event_type="my_custom_timer_event">
      <!-- actions to be included when this event occurs -->
      <include file="$(package-share my_package)/something.launch.xml" />
      <node pkg="my_package" executable="my_exec" />
      <group namespace="my_ns">
        <node pkg="my_package" executable="my_exec" />
      </group>
    </on_event>


3. [ http://design.ros2.org/articles/node_lifecycle.html ](http://design.ros2.org/articles/node_lifecycle.html) ↩  ↩  2  ↩  3  ↩  4


1. [ http://design.ros2.org/articles/static_remapping.html#remapping-rule-syntax ](http://design.ros2.org/articles/static_remapping.html#remapping-rule-syntax) ↩  ↩  2  ↩  3


2. Semi-binary builds - against released core ROS packages (main and testing), but the immediate dependencies are pulled from source. Shows that local build with dependencies is possible and if fails there we can expect that after the next package sync we will not be able to build.


Also leveraging Managed Nodes when possible, the launch system in ROS 2 could
export, aggregate and export, or react to lifecycle events of nodes. For
example, it might be possible to say that a node, rather than a process, is
“required” such that the launch system shutdowns if that node’s state ends up
in the “Finalized” state, which would be similar to a process exiting with the
“required=true” setting for ` roslaunch ` from ROS 1.


ROS 2 Distro  |  Branch  |  Build status  |  Documentation
---|---|---|---
**Rolling** |  [ ` master ` ](https://github.com/ros-
controls/ros2_control_demos/tree/rolling) |  [ ![Rolling Binary
Build](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/rolling-binary-
build.yml/badge.svg?branch=master) ](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/rolling-binary-
build.yml?branch=master)
[ ![Rolling Semi-Binary Build](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/rolling-semi-binary-
build.yml/badge.svg?branch=master) ](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/rolling-semi-binary-
build.yml?branch=master)
|  [ Documentation ](https://control.ros.org/master/index.html)
[ API Reference ](https://control.ros.org/master/doc/api/index.html)
**Humble** |  [ ` humble ` ](https://github.com/ros-
controls/ros2_control_demos/tree/humble) |  [ ![Humble Binary
Build](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/humble-binary-
build.yml/badge.svg?branch=humble) ](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/humble-binary-
build.yml?branch=humble)
[ ![Humble Semi-Binary Build](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/humble-semi-binary-
build.yml/badge.svg?branch=humble) ](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/humble-semi-binary-
build.yml?branch=humble)
|  [ Documentation ](https://control.ros.org/humble/index.html)
[ API Reference ](https://control.ros.org/humble/doc/api/index.html)
**Galactic** |  [ ` galactic ` ](https://github.com/ros-
controls/ros2_control_demos/tree/galactic) |  [ ![Galactic Binary
Build](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/galactic-binary-
build.yml/badge.svg?branch=galactic) ](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/galactic-binary-
build.yml?branch=galactic)
[ ![Galactic Semi-Binary Build](https://github.com/ros-
controls/ros2_control_demos/actions/workflows/galactic-semi-binary-
build.yml/badge.svg?branch=galactic) ](https://github.com/ros-


[ 330  stars ](/ros-controls/ros2_control_demos/stargazers) [ 165  forks
](/ros-controls/ros2_control_demos/forks) [ Branches  ](/ros-
controls/ros2_control_demos/branches) [ Tags  ](/ros-
controls/ros2_control_demos/tags) [ Activity  ](/ros-
controls/ros2_control_demos/activity)


[ example_7 ](/ros-controls/ros2_control_demos/tree/humble/example_7
"example_7")


The rationale for the previous rule is that if someone attempts to ` SIGTERM `
the launch system, they probably did so out of impatience after sending `
SIGINT ` to the launch system, and therefore the launch system should attempt
to exit quickly. Exiting quickly will hopefully avoid encouraging a user to `
SIGKILL ` the launch system, which might cause the subprocesses to be
improperly shutdown and perhaps even become zombie processes.


Another option for a container process API is to pass configuration in via
STDIN.


TODO: Restructure notes on this and put them here.


#####  Event Filters


Also, since there can be multiple nodes per process, shutting down a node no
longer always means sending a unix signal to a single process. Other
mechanisms might need to be used to have more granular shutdown control in
multi-node processes.


The most basic version of these entities, and the foundation for the other
entities, are  operating system processes  .


If the  operating system process  terminates, and therefore returns a return
code, the launch system will report this event and it can be handled in a user
defined way. Termination covers expected termination (e.g. return from `
main() ` or use ` exit() ` ) and unexpected termination (e.g. the abort trap
or a segmentation fault or bus error).


[ **330** stars ](/ros-controls/ros2_control_demos/stargazers)


If you want to have rather step by step manual how to do things with `
ros2_control ` checkout the [ ros-control/roscon2022_workshop
](https://github.com/ros-controls/roscon2022_workshop) repository.


Find the documentation in doc/userdoc.rst or on control.ros.org.


When an event handler finishes, it is able to return a launch description
which is implicitly given to the include action at the location of the event
handler’s registration. This allows an event handler to cause any action upon
completion, e.g. include another launch description, unregister an event
handler, emit another event, run a process, start the termination of a process
by emitting an event, etc…


_RRBot_ with GPIO interfaces.


In this subsection, and the following subsections of the “Calling Conventions”
section, the different possible combinations of nodes and processes is
explained. In each case they “inherit” any behaviors from either the “ROS
nodes” or the “Managed ROS nodes” subsections above, but in these subsections
the “how” of communicating ROS specific options is described in more detail.


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


humble


* No waiting for an API to become available


A kind of in-between entity is an  operating system process  which uses shell
evaluation to expand a relative executable name to an absolute path using the
PATH environment variable.


##  Event Subsystem


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


For ROS nodes that have a lifecycle, a.k.a. Managed ROS Nodes  3  , each node
will have additional runtime state, which the launch system could access and
either utilize directly, pass through to the event system, or aggregate before
passing it through the event system.


The launch system in ROS 1 only really ever was supported on Linux and other
Unix-like operating systems like BSD and macOS. These machines all have SSH,
which is the mechanism which is specifically called out to be used when
launching processes on remote machines. It also played a role in defining what
you specified and how when configuring ` roslaunch ` from ROS 1 to be able to
launch processes on remote machines.


#  Running in ROS2 Foxy or Humble  #


Actions may also yield more actions and groups rather than perform an actual
task. For example, an action to “run a node” may end up resulting in
“executing two process” or in “executing a process and registering an event
handler”. These kind of actions could be thought of a launch description
generators or macros, since they effectively generate the same contents as a
launch description, but look like an action to the user.


[ Notifications ](/login?return_to=%2Fros-controls%2Fros2_control_demos)


[ .github ](/ros-controls/ros2_control_demos/tree/humble/.github ".github")


[ example_10 ](/ros-controls/ros2_control_demos/tree/humble/example_10
"example_10")


##  Content


###  Forks


###  Process with a Single Node


#####  Event Handlers


The latter two steps can be skipped, or the time until escalation can be
adjusted, on a per process basis.


So the biggest impact of a single node process is that the configuration, in
terms of command line arguments and environment variables, can be simplified.


[ example_6 ](/ros-controls/ros2_control_demos/tree/humble/example_6
"example_6")


[ example_4 ](/ros-controls/ros2_control_demos/tree/humble/example_4
"example_4")


[ Dockerfile ](/ros-controls/ros2_control_demos/tree/humble/Dockerfile
"Dockerfile")


  Demos  

This [ GitHub Repository ](https://github.com/ros-controls/ros2_control_demos)
provides templates for the development of ` ros2_control  ` -enabled robots
and simple simulations to demonstrate and prove ` ros2_control  ` concepts.

If you want to have a rather step by step manual how to do things with `
ros2_control  ` checkout [ ros-control/roscon2022_workshop
](https://github.com/ros-controls/roscon2022_workshop) repository.


* Open Source


Further more the wiki goes on to say ( [
https://wiki.ros.org/roslaunch/Architecture
](https://wiki.ros.org/roslaunch/Architecture) ):


A simple example of an event with extra data might be a “process exited”
event, which would include enough information to identify which process it was
as well as the return code of the process.


[ .gitignore ](/ros-controls/ros2_control_demos/blob/humble/.gitignore
".gitignore")


###  Managed ROS Nodes


    * [ Topics ](/topics)
    * [ Trending ](/trending)
    * [ Collections ](/collections)


Additional navigation options


[ ros2_control_demos.galactic.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos.galactic.repos
"ros2_control_demos.galactic.repos")


  * [ Code  ](/ros-controls/ros2_control_demos/tree/humble)
  * [ Issues  19  ](/ros-controls/ros2_control_demos/issues)
  * [ Pull requests  4  ](/ros-controls/ros2_control_demos/pulls)
  * [ Actions  ](/ros-controls/ros2_control_demos/actions)
  * [ Projects  0  ](/ros-controls/ros2_control_demos/projects)
  * [ Security  ](/ros-controls/ros2_control_demos/security)
  * [ Insights  ](/ros-controls/ros2_control_demos/pulse)


Dynamically loading a node means spawning it in a container process that does
not know about the node until it is asked to load it. A container process is a
stand alone executable that loads and executes nodes within itself.


  * ` stdin ` pipe
  * signals ( ` SIGINT ` , ` SIGTERM ` , ` SIGUSR1 ` , etc…)


There are two actions associated with event handlers, registering one and
unregistering one. How event types and event handlers are represented and
tracked depends on the implementation of the launch system. However, as an
example, a “launch file” written in Python might represent event’s as classes
which inherit from a base class. If instead the “launch file” is written in
XML, event types might be expressed as a string, with launch system events
using a “well-known name” and with user definable events being represented
with unique strings as well. Similarly, the Python based “launch file” might
use instances of objects to represent registered event handlers, therefore you
might need that object to perform the unregister action. And in the XML based
“launch file” the user might be required to give a unique name to all
registered event handlers, so that they can unregistered with the same name
later.


Include my email address so I can be contacted


[ example_14 ](/ros-controls/ros2_control_demos/tree/humble/example_14
"example_14")


Also, these constraints don’t have to be related to ROS specific events like
lifecycle state changes. For example, a user might express that a plain
process should be launched (in this case executed as a subprocess) after
another process has been running for ten seconds. The launch system in ROS 2,
could either choose to let the user define a predicate which satisfied that
constraint, or it could provide a generic constraint like: “launch N seconds
after another process”.


From the description of ` roslaunch ` from the wiki ( [
https://wiki.ros.org/roslaunch ](https://wiki.ros.org/roslaunch) ):


##  Reference Implementation Proposal


For


However, to remove boilerplate code or to avoid programming in markup
descriptions, common event handler patterns can be encapsulated in different
event handler signatures.


In a process with multiple nodes, things are much the same as with a process
with a single node, but the configuration, again in terms of command line
arguments and environment variables, need to be more specific in order to
discriminate between the various nodes being instantiated in the process. The
remapping design document  1  goes into detail on how you can selectively
configure multiple nodes using command line arguments, so check there for up-
to-date details.


Skip to content
ros-controls
/
ros2_control_demos


The most basic events are related solely to things that happen within the
launch system itself. This can be as simple as a timed event, either a
specific amount of time has passed, or a specific time of day has passed, or
an “idle” event which might be used to implement a “call later” type of
callback.


[ example_3 ](/ros-controls/ros2_control_demos/tree/humble/example_3
"example_3")


© Open Source Robotics Foundation, Inc.


##  Execution and Verification of the System Description


#####  Including Another Launch Description


Except where otherwise noted, these design documents are licensed under [
Creative Commons Attribution 3.0
](http://creativecommons.org/licenses/by/3.0/) .


Parameter  |  Default Value  |  CLI Command
---|---|---
publish_frequency  |  1 (Hz)  |  ros2 launch meili_agent meili_agent.launch.py
publish_frequency:=1
topic_streaming_mode  |  FILTERING  |  ros2 launch meili_agent
meili_agent.launch.py topic_streaming_mode:=FILTERING
battery_present  |  False  |  ros2 launch meili_agent meili_agent.launch.py
battery_present:=False
path_planning  |  False  |  ros2 launch meili_agent meili_agent.launch.py
path_planning:=False
traffic_control  |  False  |  ros2 launch meili_agent meili_agent.launch.py
traffic_control:=False
offline  |  False  |  ros2 launch meili_agent meili_agent.launch.py
offline:=False
lipo_cells  |  0  |  ros2 launch meili_agent meili_agent.launch.py
lipo_cells:=4

  * Parameters


##  Languages


[ View Source ](https://github.com/ros2/design/blob/gh-
pages/articles/150_roslaunch.md) [ Edit in Github
](https://github.com/ros2/design/edit/gh-pages/articles/150_roslaunch.md)


    * True: Battery will be streamed
    * False: Default value → Battery will not be streamed
  4. **path_planning** . When allocating tasks with multiple points, the user can choose to use a route calculated by Meili FMS’s path planner.


6. [ https://doc.qt.io/archives/qt-4.8/eventsandfilters.html#event-filters ](https://doc.qt.io/archives/qt-4.8/eventsandfilters.html#event-filters) ↩


The launch system can be considered in parts, separated by concern. The coarse
breakdown is like so:


[ ros2_control_demos.foxy.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos.foxy.repos
"ros2_control_demos.foxy.repos")


Another basic action would be to execute a subprocess, with arguments and
emitted events, as described in the calling conventions section under “
operating system process  ”.


**NOTE** : There are three build stages checking current and future
compatibility of the package.


> roslaunch also contains a variety of tools to help you write your .launch
> files as portably as possible. You can use the ` <env> ` tag to specify
> environment variables that need to be set for a particular machine or node.
> The $(find pkg) syntax let you specify file paths relative to a ROS package,
> instead of specifying their location on a particular machine. You can also
> use the $(env ENVIRONMENT_VARIABLE) syntax within include tags to load in
> .launch files based on environment variables (e.g. MACHINE_NAME).


During runtime, a Managed ROS node emits events anytime the state of the node
changes. This is at least emitted on a topic, but could also be captured,
aggregated, and/or communicated in other ways too. These state changes could
be consumed by either the launch system itself or by the user, either of which
could react to these changes.


  * composition of systems into systems of systems to manage complexity
  * use include semantic to reuse fragments rather than writing each from scratch
  * use groups to apply settings (e.g. remappings) to collections of nodes/processes/included launch files
    * also use groups with namespaces to form hierarchies
  * portability through abstraction of operating system concepts, e.g. environment variables
  * utilities to locate files on the filesystem in a relocatable and portable way, e.g. ` $(find <package_name>) `


Hopefully this is another case on which the launch system for ROS 2 can
improve, at least for nodes with a lifecycle, a.k.a. Managed Nodes  3  . For
Managed Nodes, it would not be possible to apply constraints on when something
is launched, rather than how it is in ` roslaunch ` from ROS 1, where things
are run in a non-deterministic order.


[ Please Login to View Pull Requests
](https://github.com/login/oauth/authorize?client_id=efa6dd8eae9106381720)


##  Footer


[ Report repository ](/contact/report-
content?content_url=https%3A%2F%2Fgithub.com%2Fros-
controls%2Fros2_control_demos&report=ros-controls+%28user%29)


You can’t perform that action at this time.


In ROS 1, there could only ever be one node per process and so the goals of `
roslaunch ` from ROS 1 reflect that by using “ROS nodes” and “processes”
almost interchangeably.


  * include a launch description from a file with a certain markup type
  * set an environment variable
  * run a single-node process
  * run a multi-node process
  * run a node container
  * run a node proxy to load into a node container
  * run a process on a remote computer
  * declare launch description arguments
    * exposed as either:
      * command line arguments for top-level launch descriptions
      * or additional arguments to the “include another launch description” action
    * stored in “launch system configuration”
  * various OS actions, e.g. touch a file, read a file, write to a file, etc…


* Example 8: [ "Using transmissions" ](/ros-controls/ros2_control_demos/blob/humble/example_8)


  * [ 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


####  Remote Operating System Processes


The interface for this Service was added in ROS 2 Dashing:


####  Runtime


One option for a container processes API is to pass a configuration file with
nodes to load via the command line.


The launch system will initiate this process when an event (built-in or user
generated) initiates shutdown, e.g. when a process with the equivalent of the
` require=true ` exit handler terminates, or when the launch system itself
receives the ` SIGINT ` signal.


[ .pre-commit-config.yaml ](/ros-controls/ros2_control_demos/blob/humble/.pre-
commit-config.yaml ".pre-commit-config.yaml")


[ example_6 ](/ros-controls/ros2_control_demos/tree/humble/example_6
"example_6")


Clear


###  Reporting and Handling of Events


###  License


Search


This API could also have very low latency to launch nodes. However, there also
is no way to get feedback about the success or failure of loaded nodes. STDOUT
cannot be used because a composable node logging messages to STDOUT is assumed
to be very common and would conflict. Since STDIN is always available, it
would be possible to unload a node via this API.


[ LICENSE ](/ros-controls/ros2_control_demos/blob/humble/LICENSE "LICENSE")


[ example_1 ](/ros-controls/ros2_control_demos/tree/humble/example_1
"example_1")


###  Watchers


####  Process Related Events and Responses


Pull Requests


###  Operating System Processes


Example 13: “Multi-robot example (tba.)”

Example 14: “Modular robots with actuators not providing states and with
additional sensors”


>   1. aliased ` <machine> ` s: you can separate machine definitions and node
> definitions into separate .launch files and use aliases to define which
> machines get used at runtime. This allows you to reuse the same node
> definitions for multiple robots. For example, instead of saying that a
> laser_assembler runs on ‘foo.willowgarage.com’, you can say that it runs on
> the ‘tilt-laser’ machine. The machine definitions then take care of which
> host is the ‘tilt-laser’ machine.
>


[ Sign in ](/login?return_to=https%3A%2F%2Fgithub.com%2Fros-
controls%2Fros2_control_demos%2Ftree%2Fhumble)


* Example 6: [ "Modular robots with separate communication to each actuator" ](/ros-controls/ros2_control_demos/blob/humble/example_6)


[ Please Login to View Pull Requests
](https://github.com/login/oauth/authorize?client_id=efa6dd8eae9106381720)


Whether described via static file or programmatically, once the system is
described it has to be executed, and this section will cover all of that. Most
of this is already covered in the “calling conventions” section, but this
section will also cover some more details about execution, and then add on to
that verification (starting another discussion about what the launch system
should and should not do itself). Verification is runtime assertion that
mirrors the static analysis that can be done off-line.


###  Similarities with ROS 1


#  ROS 2 Launch System


  Build from source  

  * Download all repositories

        mkdir -p ~/ros2_ws/src
    cd ~/ros2_ws/src
    git clone https://github.com/ros-controls/ros2_control_demos
    cd ~/ros2_ws/
    vcs import src < src/ros2_control_demos/ros2_control_demos.$ROS_DISTRO.repos
    rosdep update --rosdistro=$ROS_DISTRO
    sudo apt-get update

  * Install dependencies:

        rosdep install --from-paths src --ignore-src -r -y

  * Build everything, e.g. with:

        . /opt/ros/${ROS_DISTRO}/setup.sh
    colcon build --symlink-install

  * Do not forget to source ` setup.bash  ` from the ` install  ` folder!


    source /opt/ros/humble/setup.bash
    cd ~/ros2_ws
    source install/setup.bash
    ros2 launch meili_agent meili_agent.launch.py


A simple example of an event without extra data might be an event for “call
later”, where it doesn’t matter who initiated the “call later” or how long it
has been since that occurred (though it could include that if it wished), and
so this events existence is sufficient to notify waiting actions to proceed.


Often when these kind of “dynamic” features are discussed the question of “why
is roslaunch (from ROS 1) a static description and not a script”? The direct
answer is that “it doesn’t have to be”, but the API for doing it
programmatically is not very well documented or easy to use.


##  Build status


###  ROS Nodes


##  Getting Started


* Example 5: [ "Industrial robots with externally connected sensor" ](/ros-controls/ros2_control_demos/blob/humble/example_5)


[ .clang-format ](/ros-controls/ros2_control_demos/blob/humble/.clang-format
".clang-format")


Last commit message


You signed in with another tab or window. [ Reload ]() to refresh your
session.  You signed out in another tab or window. [ Reload ]() to refresh
your session.  You switched accounts on another tab or window. [ Reload ]() to
refresh your session.  Dismiss alert


Each of these actions would be able to generate one or more other actions.
This can be used to run one or more processes with a single action statement,
or to simply provide some “syntactic sugar” For example, a “run a single-node
process” action might take ROS specific configurations, then expand them to
generic configurations for one of the basic actions like the “execute a
process” action.


[ **165** forks ](/ros-controls/ros2_control_demos/forks)


When launching the Meili Agent, there are few parameters that you can
configure:


With this information the launch system can execute any arbitrary  operating
system process  on the local machine.


In each of these cases, the ROS specific constructs can be expressed with the
existing mechanisms described by the “Execution” subsection for “Operating
System Processes”, i.e. the ROS specific constructs can be expanded into
either command line arguments or environment variables. Therefore the launch
system is able to take ROS specific declarations, e.g. “remap ‘image’ to
‘left/image’”, and convert them implicitly into terms that a normal  operating
system process  can consume like environment variables or command line
arguments, e.g. adding ` image:=left/image ` to the command line arguments.
However, what a given ROS specific declaration is converted into depends on
how the nodes are used within the process, but later sections will go into
details about that.


The services are hidden to avoid colliding with user created services. `
load_node ` will be called by the launch system when a composable node is to
be dynamically loaded, and ` unload_node ` destroys a composable node. `
list_nodes ` is not called by launch system, and is only provided for
introspection.


##  Context


[ example_14 ](/ros-controls/ros2_control_demos/tree/humble/example_14
"example_14")


and possibly other things, all of which it will share in common with `
roslaunch ` from ROS 1.


[ Star  ](/login?return_to=%2Fros-controls%2Fros2_control_demos)


Terminal 2:

    source /opt/ros/${ROS_DISTRO}/setup.bash
    cd ~/ros2_ws
    rviz2 -d src/ros2_control_demos/example_1/description/rviz/rrbot.rviz

Now, you can see the robot moving by changing the values of the joints by
moving the sliders around in the ` joint_state_publisher_gui  ` .


  * ` ~/_container/load_node `
  * ` ~/_container/unload_node `
  * ` ~/_container/list_nodes `


####  Information Provided by Events


[ example_2 ](/ros-controls/ros2_control_demos/tree/humble/example_2
"example_2")


TODO: Restructure notes on this and put them here.


During runtime a “plain” ROS node doesn’t expose anything new beyond what an
operating system process  does. It does have ROS topics, services, parameters,
etc. but none that are standardized in a way that’s useful for the launch
system at this time.


2. [ http://design.ros2.org/articles/ros_parameters.html ](http://design.ros2.org/articles/ros_parameters.html) ↩  ↩  2


You will see a similar **output** :


* Example 1: [ _RRBot_ ](/ros-controls/ros2_control_demos/blob/humble/example_1)


In addition, the launch system may interact with, or allow the user to
interact with, an  operating system process  ’s:


  * name of the executable (just the name, relative path, or absolute path)
  * environment variables ( ` PATH ` , ` LD_LIBRARY_PATH ` , ` DL_PRELOAD ` , etc…)
  * command line arguments
  * working directory (directory from which to execute the process)
  * launch prefix (used to inject things like ` gdb ` , ` valgrind ` , etc…)


* Example 13: "Multi-robot example (tba.)"


  * ROS 2 Launch System
    * Context
      * Description of ` roslaunch ` from ROS 1
      * Differences in ROS 2
        * Relationship Between Nodes and Processes
        * Launching Nodes (Processes) Remotely and Portability
        * Parameters
        * Process Related Events and Responses
        * Deterministic Startup
        * Node Related Events and Responses
        * Static Description and Programmatic API
        * Locating Files
      * Similarities with ROS 1
    * Separation of Concern
    * Calling Conventions
      * Operating System Processes
        * Execution
        * Runtime
        * Termination
        * Shell Evaluation
        * Remote Operating System Processes
      * ROS Nodes
        * Execution
        * Runtime
        * Termination
      * Managed ROS Nodes
        * Execution
        * Runtime
        * Termination
      * Process with a Single Node
      * Process with Multiple Nodes
        * Dynamically loading Nodes
          * Container Process API
            * API using Command Line Configuration File
            * API using STDIN
            * API using ROS Services or Topics
          * Proposed Container process API
            * Command Line Arguments
            * ROS Services
            * Exit Code


[ ros2_control_demos-not-released.galactic.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos-not-
released.galactic.repos "ros2_control_demos-not-released.galactic.repos")


Other events will be specific to any process that is executed by the launch
system, like when a process is started or when a process exits. You could also
imagine events which get fired when ` stdout ` or ` stderr ` data is received
from the process by the launch system, assuming it captures that information.


During runtime, the launch system may monitor all  operating system process
’s:


Go to file


[ example_3 ](/ros-controls/ros2_control_demos/tree/humble/example_3
"example_3")


.gitignore
.pre-commit-config.yaml
CONTRIBUTING.md
LICENSE
README.md
ros2_control_demos-not-released.foxy.repos
ros2_control_demos-not-released.galactic.repos
ros2_control_demos-not-released.humble.repos
ros2_control_demos-not-released.rolling.repos
ros2_control_demos.foxy.repos
ros2_control_demos.galactic.repos
ros2_control_demos.humble.repos
ros2_control_demos.rolling.repos
Breadcrumbsros2_control_demos
/example_1/
Directory actionsAdd file
More options
Latest commit
christophfroehlichsaikishorfmauch
Update all demos using the description from topic rather than the par…
11d699b
 ·
last month
History
This branch is 76 commits ahead of, 94 commits behind master.
Breadcrumbsros2_control_demos
/example_1/
Folders and files
Name	Last commit message	Last commit date
parent directory
..
bringup
Update all demos using the description from topic rather than the par…
last month
description
Extract robot description into global package (again) (#339) (#346)
8 months ago
doc
Update docker instructions (#351) (#365)
7 months ago


When running the Meili Agent, two ROS nodes are launched:


Type / to search


Historically, ROS 1’s ` roslaunch ` allowed a few common exit handling cases:


####  Parameters


  * convert common ROS concepts like remapping and changing the namespace into appropriate command line arguments and configurations for nodes so the user doesn’t have to do so
  * manage complexity through composition of simpler systems (launch files)
  * allow including of other launch files
  * use groups to apply settings to collections of nodes and processes
  * provide operating system portability where possible


##  Use saved searches to filter your results more quickly


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


build-status) .

Otherwise, install [ ROS 2 rolling on your computer
](https://docs.ros.org/en/rolling/Installation.html) .

Note

` ros2_control  ` and ` ros2_controllers  ` packages are released and can be
installed using a package manager. We provide officially released and
maintained debian packages, which can easily be installed via aptitude.
However, there might be cases in which not-yet released demos or features are
only available through a source build in your own workspace.


_RRBot_ with an integrated sensor.


For example, the environment variables which are set when running an
operating system process  would be taken from the launch system configuration,
and therefore can be modified with an action. Then any “execute a process”
actions which come after it will be affected by the configuration change.


The API will not include setting environment variables per loaded node. Many
languages have APIs to get environment variables, and there is no way to
isolate them within a process.


[ README.md ](/ros-controls/ros2_control_demos/blob/humble/README.md
"README.md")


TODO:


_RRBot_ with an externally connected sensor.


Demonstrates how to switch between simulation and hardware.


This repository aims at providing examples to illustrate ros2_control and
ros2_controllers


  * No waiting for an API to become available
  * Works with read-only file systems


The following options for an API are being considered.


Last commit date

---|---|---|---

##  Latest commit


1. load_node


  * ` stdout ` pipe
  * ` stderr ` pipe


[ ros2_control_demos-not-released.humble.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos-not-
released.humble.repos "ros2_control_demos-not-released.humble.repos")


[ Sign in ](/login?return_to=https%3A%2F%2Fgithub.com%2Fros-
controls%2Fros2_control_demos%2Ftree%2Fhumble)


##  Alternatives


##  [ ![](/logo.jpg) Meili Robots  ](https://meilirobots.com)


#####  Proposed Container process API


[ ros-controls ](/ros-controls) /  **[ ros2_control_demos ](/ros-
controls/ros2_control_demos) ** Public


* [ The ReadME Project  GitHub community articles  ](/readme)


##  System Description


The first is a single process with a single ROS node within it. This was
likely the most commonly used type of entity launched in ROS 1, as you could
only have one node per process in ROS 1. In ROS 2, this will likely be less
common because you can have one to many nodes per process, but will may still
be used quite a bit in the form of quickly developed scripts and drivers or
GUI tools which might require control over the main thread.


[ CONTRIBUTING.md ](/ros-
controls/ros2_control_demos/blob/humble/CONTRIBUTING.md "CONTRIBUTING.md")


The packages have following structure of subfolders:


A container process must assign the node a unique id when it is loaded. The id
of a loaded node instance never changes. Two nodes in the same container
process must never have the same id, and there should be a significant time
delay before an id is reused.


  * Calling Conventions for Processes and Various Styles of Nodes
  * Reporting System for Events
  * System Description and Static Analysis
  * Execution and Verification of the System Description
  * Testing


    * [ Learning Pathways  ](https://resources.github.com/learn/pathways/)
    * [ White papers, Ebooks, Webinars  ](https://resources.github.com/)
    * [ Customer Stories ](/customer-stories)
    * [ Partners  ](https://partner.github.com/)


When your robot is successfully operating with the **navigation nodes** , you
can run the following command and start the Meili Agent.


In order to do this, the launch system in ROS 2 will need to model the
dependencies between processes and/or nodes where they exist, and the
constraints on those dependencies. For example, a user might express that an
image processing node has a dependency on a camera driver node with the
constraint that it should not be launched (what ever the action to do that
might be, e.g. run a process or something else) until the camera driver node
reaches the “Active” state. These constraints can be arbitrarily defined by
the user or common constraints could be modeled directly by the launch system.


  * [ C++  45.5%  ](/ros-controls/ros2_control_demos/search?l=c%2B%2B)
  * [ Python  41.3%  ](/ros-controls/ros2_control_demos/search?l=python)
  * [ CMake  6.5%  ](/ros-controls/ros2_control_demos/search?l=cmake)
  * [ C  6.5%  ](/ros-controls/ros2_control_demos/search?l=c)
  * Other  0.2%


  Examples  

  * [ Example 1: RRBot ](../example_1/doc/userdoc.html)
  * [ Example 2: DiffBot ](../example_2/doc/userdoc.html)
  * [ Example 3: RRBot with multiple interfaces ](../example_3/doc/userdoc.html)
  * [ Example 4: Industrial robot with integrated sensor ](../example_4/doc/userdoc.html)
  * [ Example 5: Industrial robots with externally connected sensor ](../example_5/doc/userdoc.html)
  * [ Example 6: Modular robots with separate communication to each actuator ](../example_6/doc/userdoc.html)
  * [ Example 7: Full tutorial with a 6DOF robot ](../example_7/doc/userdoc.html)
  * [ Example 8: Using transmissions ](../example_8/doc/userdoc.html)
  * [ Example 9: Gazebo ](../example_9/doc/userdoc.html)
  * [ Example 10: Industrial robot with GPIO interfaces ](../example_10/doc/userdoc.html)
  * [ Example 11: CarlikeBot ](../example_11/doc/userdoc.html)
  * [ Example 12: Controller chaining ](../example_12/doc/userdoc.html)
  * [ Example 14: Modular robots with actuators not providing states ](../example_14/doc/userdoc.html)

[ Previous ](../../ros2_controllers/range_sensor_broadcaster/doc/userdoc.html
"Range Sensor Broadcaster") [ Next  ](../example_1/doc/userdoc.html "Example
1: RRBot")

* * *

© Copyright 2024, ros2_control Development Team.

Built with [ Sphinx ](https://www.sphinx-doc.org/) using a [ theme
](https://github.com/readthedocs/sphinx_rtd_theme) provided by [ Read the Docs
](https://readthedocs.org) .

Other Versions  v: master

Releases

     [ Iron (latest) ](../../../../iron/doc/ros2_control_demos/doc/index.html)

     [ Humble ](../../../../humble/doc/ros2_control_demos/doc/index.html)

     [ Galactic (EOL) ](../../../../galactic/doc/ros2_control_demos/doc/index.html)

     [ Foxy (EOL) ](../../../../foxy/doc/ros2_control_demos/doc/index.html)


[ ros2_control_demos-not-released.foxy.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos-not-
released.foxy.repos "ros2_control_demos-not-released.foxy.repos")


###  Topics


This repository aims at providing examples to illustrate ros2_control and
ros2_controllers


The launch system must be able tell the container process what arguments to
give to a dynamically loaded node. This includes command line arguments and
client library specific options (e.g. ` rclcpp ` has ` use_intra_process_comms
` ). Since the launch system cannot know about all custom containers, the API
must include a way to pass unknown arguments (e.g. by passing key-value
pairs).


[ ros2_control_demos.rolling.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos.rolling.repos
"ros2_control_demos.rolling.repos")


  * Must wait for the service API to become available
  * Cannot stop dynamically loaded nodes from creating the same services


    [agent_node-1] [INFO] [1711034259.807871522] [agent_node]: [ROSAgentNode] Meili Agent is ready for receiving tasks
    [agent_node-1] [INFO] [1711034259.811494685] [agent_node]: [ROSAgent] Mode for topic streaming is FILTERING
    [agent_node-1] [INFO] [1711034259.959250611] [agent_node]: [OfflineAgent] Internet Connected
    [agent_node-1] [INFO] [1711034260.248296171] [agent_node]: [ROSHandler] WS open


[ ros2_control_demos.galactic.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos.galactic.repos
"ros2_control_demos.galactic.repos")


    * FILTERING: streams topics in a determined frequency.
    * REAL_TIME: streams topics in real-time.
  3. **battery_present** . Indicates if battery values are available and if the user wants to stream it to the cloud. Values can be:


In ROS 1, there was a global parameter server which stored all parameters and
nodes would get and set all parameters through this server. The server was
tightly integrated into ` roslaunch ` from ROS 1, and was also used by the
other kind of parameters from ROS 1, which were called “dynamic reconfigure
parameters”.


#####  Launch System Configuration


[ ](/ros-controls/ros2_control_demos/commits/humble/)

###


[ ros2_control_demo_description ](/ros-
controls/ros2_control_demos/tree/humble/ros2_control_demo_description
"ros2_control_demo_description")


###  License


###  Description of ` roslaunch ` from ROS 1


  * send ` SIGINT `
  * after a short period of time, send ` SIGTERM `
  * after an additional short period of time, send ` SIGKILL `


For example, the user could express something like “when node ‘A’ enters the `
Active ` state, launch nodes ‘B’ and ‘C’” or “if node ‘A’ exits with a return
code or enters the ` Finalized ` state, shutdown everything”.


####  Launch System Events


###  Stars


For ROS2 Foxy:


Repositories


* Example 2: [ _DiffBot_ ](/ros-controls/ros2_control_demos/blob/humble/example_2)


  Local installation  

If you have ROS 2 installed already, choose the right version of this
documentation and branch of the ` ros2_control_demos  ` repository matching
you ROS 2 distribution, see [ this table ](https://github.com/ros-
controls/ros2_control_demos


Without getting into implementation details (e.g. libraries and class
hierarchies), this subsection will try to express what information should be
contained within events, and how they can be accessed and what the behavior of
the event system is with respect to delivery.


[ Branches  ](/ros-controls/ros2_control_demos/branches) [ Tags  ](/ros-
controls/ros2_control_demos/tags)


A container process must accept command line arguments including log level,
remapping, and parameters. These command line arguments must not be applied to
dynamically launched nodes. The launch system will pass these arguments to a
container process in the same way it would pass them to a node. If a remap
rule would apply to a launch service, the launch system should try to use the
remapped service name instead.


######  API using ROS Services or Topics


There can (and probably will) still be a “global parameter server” in ROS 2,
but it will simply be implemented as a node which accepts all changes and
could be run along with the launch system automatically or could be invoked
explicitly by the user (a la ` roscore ` from ROS 1), but it should not be
required for basic functionality.


The launch system may choose to either capture these pipes, for logging or
suppressing output to the console, or it can connect the pipes to an existing
` pty ` , like the terminal’s ` stdout ` and/or ` stderr ` pipes or a null
pipe (e.g. ` /dev/null ` ).


> roslaunch does not guarantee any particular order to the startup of nodes –
> although this is a frequently requested feature, it is not one that has any
> particular meaning in the ROS architecture as there is no way to tell when a
> node is initialized.


[ Login disabled for now ]()


TODO: Reformat requirements list, possibly combine/reconcile with “separation
of concerns section” (consider dropping in favor of renaming to something that
implies requirements as well)


Advantages:


    # This is a made up example of an API, consider it pseudo code...

    launch_description = LaunchDescription(...)
    # ...

    def my_process_exit_logger_callback(event: ProcessExitedEvent) -> LaunchDescription:
        print(f"process with pid '{event.pid}' exited with return code '{event.return_code}'")

    launch_description.register_event_handler(
        ProcessExitedEvent, my_process_exit_logger_callback, name='my_process_exit_logger')


Cancel  Submit feedback


[ ros2_control_demos.rolling.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos.rolling.repos
"ros2_control_demos.rolling.repos")


Even for the ROS 1 feature called ‘nodelet’ (where you could emulate having
more than one node per process), the conceptual mapping from node or nodelet
to process was preserved by proxy processes. For example, you would run a
“NodeletManager” and then run a process for each nodelet you wanted to run in
that manager. This allowed nodelet’s which exited to be detected by `
roslaunch ` from ROS 1, as well as allowing them to respond to signals that it
sent to the proxy process.


[ example_5 ](/ros-controls/ros2_control_demos/tree/humble/example_5
"example_5")


####  Handling of Events


> **Note** The name of the workspace may vary depending on your previously
> configured workspace.


  * [ Code  ](/ros-controls/ros2_control_demos/tree/humble)
  * [ Issues  ](/ros-controls/ros2_control_demos/issues)
  * [ Pull requests  ](/ros-controls/ros2_control_demos/pulls)
  * [ Actions  ](/ros-controls/ros2_control_demos/actions)
  * [ Projects  ](/ros-controls/ros2_control_demos/projects)
  * [ Security  ](/ros-controls/ros2_control_demos/security)
  * [ Insights  ](/ros-controls/ros2_control_demos/pulse)


![Menu](/svg/menu.svg) **Running in ROS2 Foxy or Humble** ![Table of
Contents](/svg/toc.svg)


####  Sending Events


3. Source build - also core ROS packages are build from source. It shows potential issues in the mid future.


###  Launch Descriptions


  Quick Hints  

These are some quick hints, especially for those coming from a ROS1 control
background:

>   * There are now three categories of hardware components: _Sensor_ ,
> _Actuator_ , and _System_ . _Sensor_ is for individual sensors; _Actuator_
> is for individual actuators; _System_ is for any combination of multiple
> sensors/actuators. You could think of a Sensor as read-only. All components
> are used as plugins and therefore exported using ` PLUGINLIB_EXPORT_CLASS  `
> macro.
>
>   * _ros(1)_control_ only allowed three hardware interface types: position,
> velocity, and effort. _ros2_control_ allows you to create any interface type
> by defining a custom string. For example, you might define a `
> position_in_degrees  ` or a ` temperature  ` interface. The most common
> (position, velocity, acceleration, effort) are already defined as constants
> in hardware_interface/types/hardware_interface_type_values.hpp.
>
>   * Joint names in <ros2_control> tags in the URDF must be compatible with
> the controller’s configuration.
>
>   * In ros2_control, all parameters for the driver are specified in the
> URDF. The ros2_control framework uses the ** <ros2_control> ** tag in the
> URDF.
>
>   * Joint names in <ros2_control> tags in the URDF must be compatible with
> the controller’s configuration.
>
>


[ ros2_control_demo_description ](/ros-
controls/ros2_control_demos/tree/humble/ros2_control_demo_description
"ros2_control_demo_description")


> roslaunch is a tool for easily launching multiple ROS nodes locally and
> remotely via SSH, as well as setting parameters on the Parameter Server. It
> includes options to automatically respawn processes that have already died.
> roslaunch takes in one or more XML configuration files (with the .launch
> extension) that specify the parameters to set and nodes to launch, as well
> as the machines that they should be run on.


Uses repos file: ` src/$NAME$/$NAME$-not-released.<ros-distro>.repos `


####  Operating System Events


  * preprocessing with an XML preprocessor, like ` xacro ` or some other general purpose templating system
  * more sophisticated expressions as XML tags in the ` roslaunch ` from ROS 1 syntax, e.g. ` $(eval expression) ` (added in ROS Kinetic) or the ` if=$(arg ...) ` and ` unless=$(arg ...) ` attributes


In order for the launch system to execute a described system, it needs to
understand how it can achieve the description. The phrase “calling
conventions” is an existing phrase in Computer Science  4  , but this section
is not talking specifically about the compiler defined calling convention,
through it is appropriating the term to describe a similar relationship. In
this case, the phrase “calling conventions” is meant to describe the
“interface” or “contract” the launch system has with anything it is executing
and monitoring. This contract covers initial execution, activity during
runtime, signal handling and behavior of the launch system, and shutdown.


[ example_4 ](/ros-controls/ros2_control_demos/tree/humble/example_4
"example_4")


[ Apache-2.0 license ](/ros-controls/ros2_control_demos/blob/master/LICENSE)


[ ros2_control_demos ](/ros-
controls/ros2_control_demos/tree/humble/ros2_control_demos
"ros2_control_demos")


Advantages:


Name


  * No config file parsing
  * Works with read-only file systems
  * Can indicate if a node was successfully loaded
  * Can create API to trigger launch events
  * Can tell if a container process supports this interface


TODO:


[ example_8 ](/ros-controls/ros2_control_demos/tree/humble/example_8
"example_8")


Another basic action that the launch system should support is the ability to
emit events and if necessary declare new kinds of events before emitting them.


First, this section will describe in a programming language, or text markup,
agnostic way what can be expressed in the system description and how it maps
to the calling conventions and event handling described in previous sections,
as well as how it maps to launch system specific behaviors. After that, it
will suggest how this agnostic system description can be applied to Python and
XML, but also how it might be able to be extended to support other languages
and markups.


  * equivalent to substitutions in ROS 1, see: https://wiki.ros.org/roslaunch/XML#substitution_args
  * they’ve already been implemented in the reference implementation, they should at least be summarized as built here


#####  Parallel vs Sequential Loading of Nodes


  * [ CONCEPTS ](/docs/concepts/)
    * [ About Meili Robots ](/docs/concepts/about-meilirobots/)
    * [ Terminology ](/docs/concepts/terminology/)
  * [ GET STARTED ](/docs/get-started/)
    * [ Account Setup ](/docs/get-started/account-setup/)
    * [ Adding Vehicles to Your Fleet ](/docs/get-started/add-vehicles/)
      * [ Adding Vehicle’s Battery ](/docs/get-started/add-vehicles/vehicle-battery/)
      * [ Creating a Fleet Setup ](/docs/get-started/add-vehicles/ros-setup/)
      * [ Adding Vehicle’s Topics ](/docs/get-started/add-vehicles/vehicle-topics/)
    * [ Deleting Vehicles from Your Fleet ](/docs/get-started/delete-vehicles/)
    * [ On-Robot Agent ](/docs/get-started/on-robot-agent/)
      * [ Installing Meili Agent ](/docs/get-started/on-robot-agent/installation/)
        * [ Melodic ](/docs/get-started/on-robot-agent/installation/melodic/)
        * [ Noetic ](/docs/get-started/on-robot-agent/installation/noetic/)
        * [ Foxy ](/docs/get-started/on-robot-agent/installation/foxy/)
        * [ Humble ](/docs/get-started/on-robot-agent/installation/humble/)
        * [ Meili CLI ](/docs/get-started/on-robot-agent/installation/meili-cli/)
      * [ Running Meili Agent ](/docs/get-started/on-robot-agent/running/)
        * [ Running in ROS Melodic or Noetic ](/docs/get-started/on-robot-agent/running/ros/)
        * [ Running in ROS2 Foxy or Humble ](/docs/get-started/on-robot-agent/running/ros-2/)
  * [ TUTORIALS ](/docs/tutorials/)
    * [ Dashboard ](/docs/tutorials/dashboard/)
    * [ Vehicles ](/docs/tutorials/vehicles/)
    * [ Missions ](/docs/tutorials/missions/)
    * [ Analytics ](/docs/tutorials/analytics/)
    * [ Maps ](/docs/tutorials/maps/)
      * [ Uploading a Map ](/docs/tutorials/maps/maps-upload/)
      * [ Path and station editor ](/docs/tutorials/maps/maps-editing/)
      * [ Map editor ](/docs/tutorials/maps/maps-editor/)
      * [ Format description ](/docs/tutorials/maps/maps-format-description/)
    * [ Site settings parameters ](/docs/tutorials/site-settings/)
    * [ Actions ](/docs/tutorials/actions/)
      * [ Mission presets ](/docs/tutorials/actions/mission-presets/)
      * [ Mission schedules ](/docs/tutorials/actions/mission-schedules/)
      * [ Action definitions ](/docs/tutorials/actions/action-definitions/)
      * [ Action presets ](/docs/tutorials/actions/action-presets/)
    * [ VDA5050 ](/docs/tutorials/vda5050/)
      * [ Connection ](/docs/tutorials/vda5050/connection/)
      * [ Messages ](/docs/tutorials/vda5050/messages/)
      * [ Setting up a robot with VDA5050 ](/docs/tutorials/vda5050/setting-up/)
      * [ Topics ](/docs/tutorials/vda5050/topics/)


  * ` require=true ` : if this process exits (any reason) shutdown everything else, as it’s “required”
  * ` respawn=true ` : if this process exits (any reason) restart it with the same settings as startup
    * ` respawn_delay=N ` : if restarting it, delay a number of seconds between attempts


[ example_11 ](/ros-controls/ros2_control_demos/tree/humble/example_11
"example_11")


2. **topic_streaming_mode** . There are two different modes that exist:


    * [ CI/CD & Automation ](/solutions/ci-cd/)
    * [ DevOps ](/solutions/devops/)
    * [ DevSecOps  ](https://resources.github.com/devops/fundamentals/devsecops/)


In addition to the “Execution” subsection of the “Operating System Processes”
section, processes with ROS Nodes in them may need to consider additional
elements, like:


* [ GitHub Sponsors  Fund open source developers  ](/sponsors)


[ ](https://github.com/)


[ ros2_control_demos-not-released.rolling.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos-not-
released.rolling.repos "ros2_control_demos-not-released.rolling.repos")


###  Resources


* Example 10: [ "Industrial robot with GPIO interfaces" ](/ros-controls/ros2_control_demos/blob/humble/example_10)


####  Execution


####  Event Handlers


[ ![Logo](../../../_static/logo_ros-controls.png) ](../../../index.html)

  * [ Getting Started ](../../getting_started/getting_started.html)
  * [ ros2_control ](../../ros2_control/doc/index.html)
  * [ ros2_controllers ](../../ros2_controllers/doc/controllers_index.html)
  * Demos
    * What you can find in this repository
    * Goals
    * Examples Overview
    * Installation
      * Local installation
        * Build from debian packages
        * Build from source
      * Using Docker
        * To view the robot
        * To run the ros2_control demos
    * Quick Hints
    * Examples
      * [ Example 1: RRBot ](../example_1/doc/userdoc.html)
      * [ Example 2: DiffBot ](../example_2/doc/userdoc.html)
      * [ Example 3: RRBot with multiple interfaces ](../example_3/doc/userdoc.html)
      * [ Example 4: Industrial robot with integrated sensor ](../example_4/doc/userdoc.html)
      * [ Example 5: Industrial robots with externally connected sensor ](../example_5/doc/userdoc.html)
      * [ Example 6: Modular robots with separate communication to each actuator ](../example_6/doc/userdoc.html)
      * [ Example 7: Full tutorial with a 6DOF robot ](../example_7/doc/userdoc.html)
      * [ Example 8: Using transmissions ](../example_8/doc/userdoc.html)
      * [ Example 9: Gazebo ](../example_9/doc/userdoc.html)
      * [ Example 10: Industrial robot with GPIO interfaces ](../example_10/doc/userdoc.html)
      * [ Example 11: CarlikeBot ](../example_11/doc/userdoc.html)
      * [ Example 12: Controller chaining ](../example_12/doc/userdoc.html)
      * [ Example 14: Modular robots with actuators not providing states ](../example_14/doc/userdoc.html)
  * [ Command Line Interface ](../../ros2_control/ros2controlcli/doc/userdoc.html)
  * [ Simulator Integrations ](../../simulators/simulators.html)
  * [ Migration Guides ](../../migration/migration.html)
  * [ API Documentation ](../../api/api.html)
  * [ Supported Robots ](../../supported_robots/supported_robots.html)
  * [ Resources ](../../resources/resources.html)
  * [ Contributing ](../../contributing/contributing.html)
  * [ Project Ideas for GSoC 2024 ](../../project_ideas.html)
  * [ Acknowledgements ](../../acknowledgements/acknowledgements.html)


* Solutions


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


The interface for this Service was added in ROS 2 Dashing:


Disadvantages:


Search or jump to...


* Parameters


####  Termination


[ doc ](/ros-controls/ros2_control_demos/tree/humble/doc "doc")


There are pro’s and con’s to both scripted launch files as well as static,
declarative launch files, but that will be covered in its own section later in
this article. But even if the preference is for a static launch file format
like is common in ROS 1, it’s a goal of the launch system in ROS 2 to have a
more accessible public API which is used to execute that static launch file,
so a programmatic approach will always be an option.


Events can be handled by registering an event handler with the launch system.
The only required form of event handler is one that is a function, registered
locally with the launch system.


The system description is a declarative set of actions and reactions that
describe what the user wants to launch in a format that the launch system can
interpret.


  * ` bringup ` \- stores launch files and runtime configurations for demo robots.
  * ` description ` \- stores URDF (and XACRO) description files, rviz configurations and meshes for the example robots.
  * ` hardware ` \- stores implementations of example hardware components (interfaces).
  * ` controllers ` (optional) - stores implementation of example controllers.


######  ROS Services


  * Explain in general how the features described in the previous sections would map to a programming language and/or markup language and any considerations therein.
  * How it would map to Python (likely implementation)
  * How it would map to XML (likely first markup language)


* agent_node


Managed ROS Nodes do not add any additional inputs or specific configurations
at execution time on top of what “plain” ROS nodes add, at least not at this
time. In the future this might change, so reference the design doc  3  or
future documentation on the subject.


###  Differences in ROS 2


####  Node Related Events and Responses


However, it should also be possible to control which configurations are
inherited by an included launch description and also to “scope” an included
launch description so that it cannot affect the configuration above it.


This feature could be used by users to filter a launch system event and then
dispatch it to other user defined event handlers, or to create new or modified
events based on existing events.


[ ros2_control_demos-not-released.foxy.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos-not-
released.foxy.repos "ros2_control_demos-not-released.foxy.repos")


Last Modified: 2019-09


Follow the steps provided in the [ documentation
](https://control.ros.org/humble/doc/ros2_control_demos/doc/index.html#installation)
to install ros2_control_demos.


[ ros2_control_demos.humble.repos ](/ros-
controls/ros2_control_demos/blob/humble/ros2_control_demos.humble.repos
"ros2_control_demos.humble.repos")


When capturing the output pipes of a process, the launch system could report
this data in a way that the user may process them in real-time or could pass
the data through user defined filters, generating a user-handled event when
the filter matches.


* [ Contribute ](/contribute.html)


This article describes the launch system for ROS 2, and as the successor to
the launch system in ROS 1 it makes sense to summarize the features and roles
of ` roslaunch ` from ROS 1 and compare them to the goals of the launch system
for ROS 2.


[ example_5 ](/ros-controls/ros2_control_demos/tree/humble/example_5
"example_5")


The launch description can also contain event handlers. An event handler is
essentially a function which takes an event as input and returns a launch
description to be included at the location of the event handler registration.
The event handler will be executed asynchronously when the associated event is
emitted.


####  Launching Nodes (Processes) Remotely and Portability


######  Exit Code


Unlike the Qt event system, an event filter is simply like any other event
handler, and will not prevent other event handlers from receiving the event.
Instead, each event filter will have its own list of event handlers, each of
which can accept or reject an event, allowing or denying further processing of
the event within the event filter, respectively.


>   1. ` <group> ` s: you can group together a collection of nodes to give
> them the same name remappings.
>


_RRBot_ with an exposed transmission interface.


A special case of  operating system processes  , shell evaluation would simply
be passing shell script code as an argument to the default system shell. This
is a problematic thing to support because it is hard/messy to make it portable
to all operating systems.


    * True: The Meili Agent will periodically check the wifi connectivity.
    * False: Default value. Wifi connection will not be checked periodically.
  7. **lipo_cells** : Indicates whether the battery is a LiPo battery or not. If >0 the battery is a LiPo battery.