Unable to mux with more than one topic

[gseqBE]

I'm on Humble and have the mux package installed via apt.

I have two control topics /cmd_vel_joy_ps4 and /cmd_vel_joy_ui

twist_mux:
  ros__parameters:
    topics:
      joystick_ps4:
        topic   : cmd_vel_joy_ps4
        timeout : 0.5
        priority: 100
      joystick_ui:
        topic   : cmd_vel_joy_ui
        timeout : 0.5
        priority: 90

The mux only works if I have one of the above, but not both. I've confirmed that both work independently.

Any clues as to what I may have missed?

[bmagyar]

Are both the right type?

On Fri, 7 Jul 2023, 23:51 Gerard Sequeira, @.***> wrote:

I'm on Humble and have the mux package installed via apt.

I have two control topics /cmd_vel_joy and /cmd_vel_key

twist_mux: ros__parameters: topics: joystick: topic : cmd_vel_joy timeout : 0.5 priority: 100 keyboard: topic : cmd_vel_key timeout : 0.5 priority: 90

The mux only works if I have one of the above, but not both. I've confirmed that both work independently.

Any clues as to what I may have missed?

— Reply to this email directly, view it on GitHub https://github.com/ros-teleop/twist_mux/issues/46, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA24PYKHUH636DID37NOLQ3XPCHH3ANCNFSM6AAAAAA2CLX35M . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[gseqBE]

Yes, they both are the right type.

I can also echo both topics. I made sure to disconnect the joystick to make sure the UI passes through, for timeout testing.

[gseqBE]

@bmagyar An update: I uninstalled ros2-humble-twisy-mux package, cloned the rolling branch of twist mux. I'm able to get it running with two control topics.

Any reason why the humble package would not work?

[Rick-v-E]

I am experiencing the same problem using humble, both with the apt installed package as the current rolling version from GIT. twist-mux is only working when there is one topic in my config file:

twist_mux:
  ros__parameters:
    topics:
      external:
        topic   : cmd_vel
        timeout : 0.5
        priority: 1
    locks:
      e_stop:
        topic   : e_stop
        timeout : 0.0
        priority: 255

When I add a second topic to the config file, twist-mux does not publish anymore:

twist_mux:
  ros__parameters:
    topics:
      joy:
        topic   : joy_vel
        timeout : 0.5
        priority: 10
      external:
        topic   : cmd_vel
        timeout : 0.5
        priority: 1
    locks:
      e_stop:
        topic   : e_stop
        timeout : 0.0
        priority: 255

From /diagnostics, I get:

header:
  stamp:
    sec: 0
    nanosec: 0
  frame_id: ''
status:
- level: "\0"
  name: 'twist_mux: Twist mux status'
  message: ok
  hardware_id: none
  values:
  - key: velocity topics.external
    value: ' unmasked (listening to cmd_vel @ 0.500000s with priority #1)'
  - key: velocity topics.joy
    value: ' unmasked (listening to joy_vel @ 0.500000s with priority #10)'
  - key: lock locks.e_stop
    value: ' free (listening to e_stop @ 0.000000s with priority #255)'
  - key: current priority
    value: '0'
  - key: loop time in [sec]
    value: '0'
  - key: data age in [sec]
    value: '0'

Last year, the same config file using twist-mux on humble worked fine. However, not a lot has been changed to this package in meantime. Any clue how to fix this?

[Rick-v-E]

@gseqBE, any chance you used it in combination with the new Gazebo? Using it with use_sim_time = true needs a /clock topic from Gazebo otherwise the time will be zero and both topics (in my case cmd_vel and joy_vel) will not expire. Then only the topic with the highest priority will be selected. To get the clock from Gazebo, the gz parameter bridge needs to be running:

ros2 run ros_gz_bridge parameter_bridge /clock@rosgraph_msgs/msg/Clock[ignition.msgs.Clock

This fixed it for me. It would be nice to have some warning for this, but I guess this is true for all nodes that use the clock and sim time.

[gseqBE]

@Rick-v-E We had to find a quick solution for this and the only way to get it to work was to pull the rolling branch as a submodule and compile it. You probably found a fix for it. Also, Gazebo was not running.