Ask Your Question
0

Controller Spawner stuck while loading

asked 2018-03-01 09:35:44 -0600

callum91 gravatar image

updated 2018-03-02 03:53:01 -0600

Hi everyone,

I am working on a robotics project based in ROS where we started with out simulation in Gazebo and built all our algorithms around the simulation while waiting for our actual robot to arrive.

Now that the actual robot has arrived we are moving away from the gazebo model in order to implement on the real robot. We have been using ros_control in order to control all of the motors on the robot (velocity controlled motors). What I have been working on most recently is converting the gazebo_ros control package so that the code we have currently written will all work with the real robot. I have managed to write up the hardware interface so that all the joints are being correctly identified and read in from the urdf files and robot state publisher is able to receive and publish the joint states being published.

The controller manager is also being instantiated from within my newly written node to run all of the controllers. The issue I am currently having is that when launching all of the nodes the controller spawner is recognising the controller manager as it is finding the various services required but gets stuck trying to load the controller.

The terminal output just shows:

Loading controller: joint_back_left_wheel_controller

When we launch the gazebo simulated version the spawner does not get stuck at this stage and is able to launch all 6 of the controllers that have been setup in a .yaml configuration file.

Does anyone know what could be the issue here? Or if theres anything I can check that will be helpful to debugging this issue.

Thanks for you help in advance.

*EDIT 1*

The above issue was solved by gvdhoorn's suggestion below of creating the multi-threaded spinner. However now it is getting locked after loading all the controllers where it prints:

Controller Spawner: Loaded Controllers:

and then lists the loaded controllers.

When I shut down the node the following is printed out.

  Traceback (most recent call last):
  File "/opt/ros/kinetic/lib/controller_manager/spawner", line 207, in <module>
    if __name__ == '__main__': main()
  File "/opt/ros/kinetic/lib/controller_manager/spawner", line 199, in main
    resp = switch_controller(loaded, [], 2)
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 435, in __call__
    return self.call(*args, **kwds)
  File "/opt/ros/kinetic/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 523, in call
    raise rospy.exceptions.ROSInterruptException("node shutdown interrupted service call")
rospy.exceptions.ROSInterruptException: node shutdown interrupted service call

Does anyone know how I might go about solving this? thanks

edit retag flag offensive close merge delete

Comments

One thing to check is whether you are using a multi-threaded spinner in your hw iface node. It's not required, but I've seen things deadlock before. An AsyncSpinner(1) fi may be problematic.

gvdhoorn gravatar imagegvdhoorn ( 2018-03-01 10:18:17 -0600 )edit

Hi gvdhoorn, Thanks for your quick reply! That has fixed where it was deadlocked before and I am able to load all the controllers in. However now it appears to be deadlocked again I have edited above with the new issue.

callum91 gravatar imagecallum91 ( 2018-03-02 03:33:37 -0600 )edit

I'm not sure. This could be any nr of things. What could help is comparing your hw iface (node) implementation with known working ones. Only you can do that unfortunately.

Another approach might be to make your hw iface node as simple as possible, see if it works. Then start re-adding ..

gvdhoorn gravatar imagegvdhoorn ( 2018-03-02 05:10:56 -0600 )edit

.. functionality and see where things break.

If you prefer a more structured approach: use gdb, attach to your node and set breakpoints where required. Then see what it is doing when it "gets stuck".

gvdhoorn gravatar imagegvdhoorn ( 2018-03-02 05:12:20 -0600 )edit

I found this thread here https://answers.ros.org/question/1193... which appears to be solving a similar problem to what I am having but I am struggling to get the implementation correct. Do you know of a simple hw if I could compare too? ...

callum91 gravatar imagecallum91 ( 2018-03-02 07:38:51 -0600 )edit

As I tried testing the ros control boilerplate from here https://github.com/davetcoleman/ros_c... but it appears to be having the same issue locking on the switch control command.

callum91 gravatar imagecallum91 ( 2018-03-02 07:39:46 -0600 )edit

I would say Dave Coleman's ros_control boilerplate is quite ok. Perhaps you can compare with that.

I must say that a simple hw iface implementation should work fine with a simple AsyncSpinner(0) or AsyncSpinner(2). Are you doing anything special or have strange requirements?

gvdhoorn gravatar imagegvdhoorn ( 2018-03-02 07:44:20 -0600 )edit

You did not mention that it blocks on switching controllers. That is new info.

gvdhoorn gravatar imagegvdhoorn ( 2018-03-02 07:45:29 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-03-02 10:29:46 -0600

callum91 gravatar image

I believe I have managed to fix this issue. The problem came because I was instantiating the hardware interface through another class rather than in the main function and I believe this was causing issues with the controller manager services having access.

To fix this I simplified the initialisation of the hardware interface to one class and followed this example of a working HW interface ( https://github.com/cyborg-x1/ros_cont... ) mainly the src/mybot.cpp file which showed how to setup the queue and asyncspinner as described here correctly ( https://answers.ros.org/question/1193... )

I am now able to load all the joint interfaces, limits through reading the urdf transmissions the same way in which gazebo achieves this and am able to load and load and start the controllers successfully.

Thanks to all the other people in the other threads who have described similar issues and gvdhoorn for your help. Callum

edit flag offensive delete link more

Comments

1

It's unclear to me why the separate callback queue is needed, but if it works for you, then that's ok.

I'll accept your answer for you.

gvdhoorn gravatar imagegvdhoorn ( 2018-03-02 11:10:40 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-03-01 09:35:44 -0600

Seen: 811 times

Last updated: Mar 02 '18