0
$\begingroup$

Rosanswers logo

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


Originally posted by callum91 on ROS Answers with karma: 46 on 2018-03-01

Post score: 0


Original comments

Comment by gvdhoorn on 2018-03-01:
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.

Comment by callum91 on 2018-03-02:
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.

Comment by gvdhoorn on 2018-03-02:
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 ..

Comment by gvdhoorn on 2018-03-02:
.. 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".

Comment by callum91 on 2018-03-02:
I found this thread here https://answers.ros.org/question/119316/using-controller-manager-and-getting-it-to-work/ 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? ...

Comment by callum91 on 2018-03-02:
As I tried testing the ros control boilerplate from here https://github.com/davetcoleman/ros_control_boilerplate/blob/kinetic-devel/src/sim_hw_main.cpp#L61 but it appears to be having the same issue locking on the switch control command.

Comment by gvdhoorn on 2018-03-02:
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?

Comment by gvdhoorn on 2018-03-02:
You did not mention that it blocks on switching controllers. That is new info.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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_control_test) mainly the src/mybot.cpp file which showed how to setup the queue and asyncspinner as described here correctly (https://answers.ros.org/question/119316/using-controller-manager-and-getting-it-to-work/)

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


Originally posted by callum91 with karma: 46 on 2018-03-02

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by gvdhoorn on 2018-03-02:
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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.