Show EOL distros: 

yujin_ocs: yocs_cmd_vel_mux | yocs_controllers | yocs_diff_drive_pose_controller | yocs_math_toolkit | yocs_velocity_smoother | yocs_virtual_sensor | yocs_waypoints_navi

Package Summary

A multiplexer for command velocity inputs. Arbitrates incoming cmd_vel messages from several topics, allowing one topic at a time to command the robot, based on priorities. It also deallocates current allowed topic if no messages are received after a configured timeout. All topics, together with their priority and timeout are configured through a YAML file, that can be reload at runtime.

yujin_ocs: yocs_cmd_vel_mux | yocs_controllers | yocs_diff_drive_pose_controller | yocs_joyop | yocs_keyop | yocs_math_toolkit | yocs_rapps | yocs_safety_controller | yocs_velocity_smoother | yocs_virtual_sensor | yocs_waypoints_navi

Package Summary

A multiplexer for command velocity inputs. Arbitrates incoming cmd_vel messages from several topics, allowing one topic at a time to command the robot, based on priorities. It also deallocates current allowed topic if no messages are received after a configured timeout. All topics, together with their priority and timeout are configured through a YAML file, that can be reload at runtime.

yujin_ocs: yocs_cmd_vel_mux | yocs_controllers | yocs_diff_drive_pose_controller | yocs_joyop | yocs_keyop | yocs_math_toolkit | yocs_rapps | yocs_safety_controller | yocs_velocity_smoother | yocs_virtual_sensor | yocs_waypoints_navi

Package Summary

A multiplexer for command velocity inputs. Arbitrates incoming cmd_vel messages from several topics, allowing one topic at a time to command the robot, based on priorities. It also deallocates current allowed topic if no messages are received after a configured timeout. All topics, together with their priority and timeout are configured through a YAML file, that can be reload at runtime.

New in groovy

Ros API

CmdVelMux Nodelet

The command velocity multiplexer nodelet is intended to run together with the kobuki_node to arbitrate access to robot by multiple controllers.

Subscribed Topics

~input/cmd_vel (geometry_msgs/Twist)
  • Multiplexer input topic. There can be an arbitrary number of input topics described on the configuration file.

Published Topics

~output/cmd_vel (geometry_msgs/Twist)
  • Multiplexed output. Incoming velocity commands from the active source are republished on this topic. The topic name is specified on the configuration file.
~active (std_msgs/String)
  • The active input at each moment, or idle if nobody is commanding the robot. Latched topic

Parameters

~yaml_cfg_file (string)
  • 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.

Ros API

CmdVelMux Nodelet

The command velocity multiplexer nodelet is intended to run together with the kobuki_node to arbitrate access to robot by multiple controllers.

Subscribed Topics

~input/cmd_vel (geometry_msgs/Twist)
  • Multiplexer input topic. There can be an arbitrary number of input topics described on the configuration file.

Published Topics

~output/cmd_vel (geometry_msgs/Twist)
  • Multiplexed output. Incoming velocity commands from the active source are republished on this topic. The topic name is specified on the configuration file.
~active (std_msgs/String)
  • The active input at each moment, or idle if nobody is commanding the robot. Latched topic

Parameters

~yaml_cfg_file (string)
  • 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.

Ros API

CmdVelMux Nodelet

The command velocity multiplexer nodelet is intended to run together with the kobuki_node to arbitrate access to robot by multiple controllers. It will however work equally as well for any other mobile ros base.

Subscribed Topics

~input/cmd_vel (geometry_msgs/Twist)
  • Multiplexer input topic. There can be an arbitrary number of input topics described on the configuration file.

Published Topics

~output/cmd_vel (geometry_msgs/Twist)
  • Multiplexed output. Incoming velocity commands from the active source are republished on this topic. The topic name is specified on the configuration file.
~active (std_msgs/String)
  • The active input at each moment, or idle if nobody is commanding the robot. Latched topic

Parameters

~yaml_cfg_file (string)
  • 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.

Wiki: yocs_cmd_vel_mux (last edited 2018-01-09 09:00:34 by GvdHoorn)