Ros API

CmdVelMux Nodelet

Subscribed Topics

• Multiplexer input topic. There can be an arbitrary number of input topics described on the configuration file.

Published Topics

• Multiplexed output. Incoming velocity commands from the active source are republished on this topic. The topic name is specified on the configuration file.

• The active input at each moment, or idle if nobody is commanding the robot. Latched topic

Parameters

• Configuration file path. Mandatory. This parameter can be dynamically reconfigured; if so, the cmd_vel_mux will be reloaded with the new configuration. This makes simple to run it on the robot's bootstrap configuration, allowing apps to reconfigure it according to their particular needs.

Configuration

We configure the Command Velocity Multiplexer with a YAML file. We reproduce here the example file that comes with the sources:

subscribers:
  - name:        "Default input"
    topic:       "input/default"
    timeout:     0.1
    priority:    0
    short_desc:  "The default cmd_vel, controllers unaware that we are multiplexing cmd_vel should come here"
  - name:        "Navigation stack"
    topic:       "input/navigation"
    timeout:     0.5
    priority:    1
    short_desc:  "Navigation stack controller"

    ...

  - name:        "Web application"
    topic:       "input/webapp"
    timeout:     0.3
    priority:    8
  - name:        "Keyboard operation"
    topic:       "input/keyop"
    timeout:     0.1
    priority:    7
publisher:       "output/cmd_vel"

As you can see, for every input we must specify 4 parameters:

• name: Source name
• topic: The topic that provides cmd_vel messages
• timeout: Time in seconds without incoming messages to consider this topic inactive
• priority: Priority: an UNIQUE unsigned integer from 0 (lowest) to MAX_INT
• short_desc: Short description (optional)

The last line gives the name for the output topic.

Hints

• Take a look at the first subscriber; if remapped to cmd_vel, it warranties that a robot running cmd_vel_mux will expose the standard ROS interface for velocity commands, but as it has the lowest priority, it will get masked by any other input.
• To use cmd_vel_mux successfully, incoming cmd_vel must behave properly:
  • Do not spam with zero-velocity messages when the controller is not active
  • Send messages continuously while the controller is active. The frequency is irrelevant for cmd_vel_mux; they will be resent as they come.

• Take a look to the Kobuki's Control System Tutorial to learn how cmd_vel_mux works together with other components to build up a safe and flexible control system.

Report a Bug

Use github to report bugs or request features.