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
Multiple controller_manager spawn calls freeze a controller manager #265
Comments
Your snippet clearly launches 2 controller managers so that's where the problem is. Take a look at this example where the
Dave's boilerplate functionalities allow a quick setup by using the controller manager + spawner at the same time but if you need to launch things in a modular way I'd recommend looking at any of the PAL robots for inspiration. |
I think the problem is that both use the same node name You can spawn multiple controllers at once, too:
(just realized that is this is the default for the boilerplate template)
The |
I have tested it myself, and I get the same bevahior, looks like a bug. |
The controller_manager script is just an interface to an already running controller_manager (confusing name). It's fairly similar to the spawner script, which also causes the issue if two are started. @ipa-mdl Yes, I still see the problem with different node names. Conceptually, I think multiple spawn nodes should be able to run together (I was using it to start some controllers using |
Yes that should work! |
Yeah, sorry for rushing to conclusion, my eyes skipped the fact that it was the python script. This is actually not that hard to test. |
Any update on this? |
Same behavior on Ubuntu 16.04, ROS kinetic. I think this is a regression bug. And I find that after combined the |
TL;DR: This is no bug in the I went through the code of the The service handlers in We could improve the situation a little bit by resolving the deadlock with a timed lock (so it will recover after some time), but the boilerplate controller loop will freeze for a certain time. |
I have proposed a fix: PickNikRobotics/ros_control_boilerplate#20 |
I think I'm facing a similar problem without Terminal 1:
Terminal 2:
Terminal 3: control node started previously (the same if it is started after)
However, if I use The control node calls I don't know whether it is correct to add these waits or not, but I've added them in the past to be sure that everything was started correctly. Now that I need to add several spawners they seem to mess up. Indeed, if I remove both calls everything start correctly even with the It seems a deadlock problem but it is difficult to figure out exactly where. Any thoughts? Is it the right behavior? |
@alextoind, which version of It is possible that PickNikRobotics/ros_control_boilerplate#20 solves your problems? That PR has been very recently merged, so the fix is not yet available in the released packages. |
Alessandro, please add the usual info too: op system, ROS distro, package
version
On Apr 27, 2018 10:29, "Alessandro Tondo" <notifications@github.com> wrote:
I think I'm facing a similar problem without ros_control_boilerplate
installed: if I launch several rosrun controller_manager controller_manager
spaw ... commands almost simultaneously, they stuck while spawning
controllers, e.g.
*Terminal 1:*
rosrun controller_manager controller_manager spawn
d1_joint_state_controller d1_c1 d1_c2
Loaded d1_joint_state_controller
*Terminal 2:*
rosrun controller_manager controller_manager spawn
d2_joint_state_controller d2_c1 d2_c2
Loaded d2_joint_state_controller
Loaded d2_c1
Loaded d2_c2
*Terminal 3:* control node started previously (the same if it is started
after)
...
[ INFO] [1524818643.691951727]: Is waiting for [controller_manager] to
startup...
[ INFO] [1524818643.693721761]: [controller_manager] is ready!
[ INFO] [1524818643.697370788]: Is waiting for controller
[d1_joint_state_controller] to startup...
[ INFO] [1524818643.840676782]: Controller [d1_joint_state_controller]
is loaded!
[ INFO] [1524818643.840705571]: Is waiting for controller [d1_c1] to startup...
However, if I use load ... commands in the exactly same manner, it works as
expected (apart form the needs to start controllers later). And of course
it works if I spawn all the controllers in one shot.
The control node calls controller_manager.getControllerByName(c_name) and
action_client.waitForServer() respectively to wait for controllers and
action server startup (I'm using default joint trajectory controllers at
the moment).
I don't know whether it is correct to add these waits or not, but I've
added them in the past to be sure that everything was started correctly.
Now that I need to add several spawners they seem to mess up. Indeed, if I
remove both calls everything start correctly even with the spawn ...
commands.
It seems a deadlock problem but it is difficult to figure out exactly where.
Any thoughts? Is it the right behavior?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#265 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADXH4S7-xpPKjHKy2c2pc7NAVQaE9nkUks5tsuT3gaJpZM4ML4IW>
.
|
@miguelprada as said at the beginning I have no @bmagyar I'm sorry about that, here you are:
Thank you very much |
Is it based on something like |
Oops I read your post too fast and thought it was a with instead of a without 🤦♂️ In any case, the problem might be the same one that was fixed in PickNikRobotics/ros_control_boilerplate#20, as @ipa-mdl seems to suggest when asking whether your control node is based on |
@ipa-mdl these are my first-level dependencies, but I don't think there is nothing like
And I'm quite sure there aren't deadlocks in my code: it just initializes things up and relies on ROS Action Clients. However I do run the update loop of my control node through a ROS Timer. Is that the problem?
@miguelprada I had already read that post, but since I use an AsyncSpinner initialized with just one thread (and Actions are initialized with With my setup I should have only one thread accessing those resources. Isn't it? Thank you very much for your time |
Not the same problem, but the same effect. Since you are running an |
Thank you @ipa-mdl! And what about a dedicated Callback Queue and AsyncSpinner pair to handle the An improved doc as suggested in #330 would be great for people like me! |
This should work. But I don't see any benefit, especially if the main ends with |
Just to be sure I had got it correctly ;) Thank you very much! |
Using https://github.com/davetcoleman/ros_control_boilerplate/tree/0.4.0/rrbot_control as an example, replace the
ros_control_controller_manager
node in https://github.com/davetcoleman/ros_control_boilerplate/blob/0.4.0/rrbot_control/launch/rrbot_hardware.launch#L21 with:Build and run
roslaunch rrbot_control rrbot_hardware.launch
and the controller manager stops responding, either to service calls (ie,/rrbot/controller_manager/list_controllers
) or Ctrl-C (if run outside roslaunch). The same thing happens if using spawner instead of controller_manager. I haven't tested it on a controller manager running outside of ros_control_boilerplate.If it's intended that only one spawn call is allowed, I didn't see it in the documentation.
The text was updated successfully, but these errors were encountered: