Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to Properly Implement twist_mux? #12

Open
sradmard opened this issue Jun 1, 2017 · 1 comment
Open

How to Properly Implement twist_mux? #12

sradmard opened this issue Jun 1, 2017 · 1 comment

Comments

@sradmard
Copy link

sradmard commented Jun 1, 2017

Hi there,

I am trying to provide velocity commands to control my robot, but these velocity commands can be generated from different sources. I have keyboard controller, Joystick, voice commands that generates velocity, and navigation package that also creates velocity command. I am publishing each of these velocities on a separate topic and would like to use twist_mux to combine all of them and choose one source at a time depending on the activation order. However, it is not very clear to me how to switch between these sources. I need to switch back and forth between sources, therefore, they all have the same priority. For example, assume I have given my robot a goal location, and the navigation package is publishing velocity into nav_cmd_vel topic, and twist_mux is passing that to cmd_vel to move the robot. Now, I press on the joystick and I want the joystick to take over the velocity control. Which means the twist_mux should pass joy_cmd_vel to cmd_vel instead even though the nav_cmd_vel is still being published on. Later, if I provide another goal location, I want the nav_cmd_vel to be passed to cmd_vel again. I do not know how to activate the switch for twist_mux in my codes so that it is automatically applied when new inputs come in.

I would really appreciate any hint.

@bmagyar
Copy link
Member

bmagyar commented Jun 5, 2017

Hi,

Have you had a look at http://wiki.ros.org/twist_mux ?
On first glance what you described is exactly what we use twist_mux for as is, no need to reimplement anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants