[ros-users] Joint controller manager

[YAMOKOSKI, JOHN D. (JSC-ER)[OCEANEERING SPACE SYSTEMS]]

+100

On 01/28/2013 09:04 AM, Adolfo Rodríguez Tsouroukdissian wrote:
- What can you not accomplish (or have had trouble accomplishing) with the tools you or your team have used so far?.

I think we have all created something really similar to your diagram. In fact, I am staring at some code I threw together to map between the indices of vanilla Eigen vectors and names in JointState messages. It was an implementation of the mapping that I _think_ you are planning in your joint_controller_manager, albeit a much simpler version. A concern: Mapping, to me, implies overhead of things like hash tables in order to get data from client interfaces to their proper placement in a full robot description vector. Using callbacks available on event ports and some functors, the conversion could be "registered" at initialization of the client interface --- this might avoid explicit 'lookups'. What were your ideas on this?

- Is it possible to have a controller with multiple interfaces (eg. send position + velocity + effort commands)?.
I'm not addressing ros controller but really this proposal. As a first cut, limiting to one type per controller instantiation might not be a terrible restriction. One of the software constructs I am really impressed by is OMPL's space descriptions ( http://ompl.kavrakilab.org/spaces.html). I'm not saying you'd need to go to this level, but asking a controller to declare its range space with some detail would make integration easier. In the future, it might ease support for controllers that output in something else other than joint space. Things like "sensor_msgs::JointState" is rather ambiguous as to what its controlling without having to introspect the data in the message or see how its being written to in the source's code.

In general, I think this is a great start for a proposal. We are looking at doing something very similar and I would love to see if there is some point of collaboration. But we are under a similar time crunch.. ~6 wks to implementation would be _very_ desirable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130128/5c8c3272/attachment-0004.html>