Ask Your Question
0

joint_state_controller in ros_control

asked 2020-05-04 14:00:26 -0500

swiz23 gravatar image

Hi,

I'm currently using ROS Kinetic on Ubuntu 16.04, and am in the process of implementing ros_control on my robot. My question is as follows:

  • My custom robot driver node currently publishes joint states and subscribes to a 'joint command' topic. I'd like to build my ros_control package (specfically the hardware_interface node) such that it is completely independent of my driver node. To achieve this, the 'write' function in the ros_control loop would just publish to the 'joint command' topic, while the 'read' function would just pull joint states from the robot drivers' joint_states topic. The issue I am having though is how to correctly implement the joint_state_controller in my hardware_interface node. The way I understand it, the joint_state_controller is responsible for two things.

    1) Publishing joint states

    2) passing the current joint states to the ros controllers

Obviously though, I don't need the joint_state_controller to publish joint states since my driver node is already doing that. However, I still need the joint_state_controller to pass the current states to the ros controllers. So my question is - is there a way I can prevent the joint_state_controller from publishing joint_states? I assume I could just set the publish_rate parameter in the YAML file to 0, but that seems a bit hacky...

Thanks!

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2020-05-04 15:10:30 -0500

gvdhoorn gravatar image

updated 2020-05-04 15:51:57 -0500

The way I understand it, the joint_state_controller is responsible for two things.

1) Publishing joint states

This is correct.

2) passing the current joint states to the ros controllers

This is incorrect.

The joint_state_controller only publishes current state, it does not do anything with other controllers or pass anything on to them (and it's also not an actual controller, but you probably had already figured that out).

With this in mind I don't believe the rest of your questions need an answer.

I would comment on this though:

To achieve this, the 'write' function in the ros_control loop would just publish to the 'joint command' topic, while the 'read' function would just pull joint states from the robot drivers' joint_states topic

If you really want to use ROS topics for in- and output of your hardware_interface, then I would recommend to not use the default joint_states name for that particular topic. It's only going to confuse people, and you will run into problems with the joint_state_controllerpublishing to /joint_states which your hardware_interface then reads.


Edit:

Would it be possible (and would this be frowned upon from a design perspective) to just do ros_control without the joint_state_controller - relying just on the joint_states published from my robot's driver node?

well, it's software, so you can do whatever you want.

I don't understand what you mean by:

relying just on the joint_states published from my robot's driver node?

who is relying on this? External consumers of JointState messages? Or your hardware_interface?

I see what you're saying about renaming the joint_states topic from my driver node to something else - but I feel it would be redundant and inefficient to have two joint_states topics with the exact same information.

Thing is: you're trying to make an adapter or façade which makes your driver/node compatible with an established abstraction (ie: ros_control). It's perfectly possible to use ROS topics for everything (although I personally wouldn't do it), but you will run into situations where it may be somewhat 'ugly'. That's often the case when adding a compatibility layer to existing code.

In the end, I believe it will depend somewhat on how much you value symmetry and the principle-of-least-surprise.

Symmetry would be improved if you'd use ros_control controllers to both accept new commands and publish current state (ie: use joint_state_controller to publish current state and use whatever controller from ros_controllers (or a custom one) to accept new commands). That's symmetrical as the ROS API of your control system would at that point all "live" at the same level of abstraction.

Having some "random node" (not really random, but from an architectural perspective it sort-of is) publish JointStates which I am to take as being one half of the interface to a particular robot/system seems "off" to me. But that's not really a technical issue, more of a design one.

Least-surprise is maintained if you'd use joint_state_controller to publish ... (more)

edit flag offensive delete link more

Comments

Would it be possible (and would this be frowned upon from a design perspective) to just do ros_control without the joint_state_controller - relying just on the joint_states published from my robot's driver node?

I see what you're saying about renaming the joint_states topic from my driver node to something else - but I feel it would be redundant and inefficient to have two joint_states topics with the exact same information.

swiz23 gravatar image swiz23  ( 2020-05-04 15:19:06 -0500 )edit

I'm a bit new to ROS Answers, so I'm not sure if I should be editing my question or posting down here. But you said...

I don't understand what you mean by: relying just on the joint_states published from my robot's driver node? who is relying on this? External consumers of JointState messages? Or your hardware_interface?

The answer is both. In any event, I tested my code without using the joint_state_controller but with my driver's published joint_states topic, and everything appears to be functioning properly. Regarding my initial question - I originally thought that the hardware_interface::JointStateHandle object (present in my hardware interface node) was directly dependent on there being a joint_state_controller. Now I realize that's not the case.

Anyhow, thanks for your feedback! I appreciate it!

swiz23 gravatar image swiz23  ( 2020-05-04 17:19:01 -0500 )edit

It'll surely work, as I wrote.

It's not very nice, but that's your decision.

gvdhoorn gravatar image gvdhoorn  ( 2020-05-05 02:47:32 -0500 )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: 2020-05-04 14:00:26 -0500

Seen: 50 times

Last updated: May 04