The way I understand it, the joint_state_controller is responsible for two things.
- Publishing joint states
This is correct.
- 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 current state as that's what almost all robots/systems which are ros_control compatible do (ie: have a hardware_interface). If I would be a user of your hardware_interface, I would be really surprised to not see a joint_state_controller in the configuration, but do see JointState messages coming from somewhere. After some time (perhaps reading the readme where this is explained) it would be OK, but I'd certainly have to take a second look.
I may not be representative of the users you target. But you asked.
Originally posted by gvdhoorn with karma: 86574 on 2020-05-04
This answer was ACCEPTED on the original site
Post score: 1
Original comments
Comment by swiz23 on 2020-05-04:
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.
Comment by swiz23 on 2020-05-04:
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!
Comment by gvdhoorn on 2020-05-05:
It'll surely work, as I wrote.
It's not very nice, but that's your decision.
