The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
At the moment ros_control is mostly concerned with providing a efficient and re-usable way to setup a (relatively simple) controller architecture that is able to interface with a ROS node graph. Most (if not all) default controllers operate at the joint-space level, and the package can be said 'to live' at the (or at least very near to) the Controller layer (in a 3T architecture, just an example).
It would make more sense to me to make something like initialisation a higher-level behaviour, perhaps part of a larger overall statemachine (again, just an example, there are others) that encodes the Executive part of your architecture. At start-up, your application then always passes through the initialisation (sub)states first, before accepting any other requests for execution of behaviours. That initialisation phase would then interact with ros_control to switch controllers to the appropriate types at the appropriate times, search for the limit switches and setup your encoders properly.
| | 2 | No.2 Revision |
At the moment ros_control is mostly concerned with providing a an efficient and re-usable way to setup a (relatively simple) controller architecture that is able to interface with a ROS node graph. Most (if not all) default controllers operate at the joint-space level, and the package can be said 'to live' at the (or at least very near to) the Controller Controller layer (in a 3T architecture, just an example).
It would make more sense to me to make something like initialisation a higher-level behaviour, perhaps part of a larger overall statemachine (again, just an example, there are others) that encodes the Executive part of your architecture. At start-up, your application then always passes through the initialisation (sub)states first, before accepting any other requests for execution of behaviours. That initialisation phase would then interact with ros_control to switch controllers to the appropriate types at the appropriate times, search for the limit switches and setup your encoders properly.
| | 3 | No.3 Revision |
tl;dr: no, there is no support for limit switches in ros_control, but I'd argue that it is also not something that should be there (as something like initialisation of a robot to me seems like a higher-level behaviour).
At the moment ros_control is mostly concerned with providing an efficient and re-usable way to setup a (relatively simple) controller architecture that is able to interface with a ROS node graph. Most (if not all) default controllers operate at the joint-space level, and the package can be said 'to live' at the (or at least very near to) Controller layer (in a 3T architecture, just an example).
It would make more sense to me to make something like initialisation a higher-level behaviour, perhaps part of a larger overall statemachine (again, just an example, there are others) that encodes the Executive part of your architecture. At start-up, your application then always passes through the initialisation (sub)states first, before accepting any other requests for execution of behaviours. That initialisation phase would then interact with ros_control to switch controllers to the appropriate types at the appropriate times, search for the limit switches and setup your encoders properly.
ros_control (and more specifically, the hardware_interface part of it) could perhaps be used to implement an interface to your limit switch hardware, similar to the joint_state_controller (which isn't a controller at all, it's a sensor interface, publishing JointState msgs). Whether that is something that makes sense depends on preference and how you've setup the rest of your system.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
