On Mon, Jan 28, 2013 at 7:23 PM, YAMOKOSKI, JOHN D. (JSC-ER)[OCEANEERING
SPACE SYSTEMS] <john.d.yamokoski@nasa.gov> wrote:

>  +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?
>

John,

All lookups and maps are cached, and are computed when a controller is
loaded. When running the controller, mapping from one vector to another is
O(1), like so:

controller_pos[i] = robot_pos[lookup[i]];

where lookup is a std::vector.

Higher-level streams on ROS topics might be subject to data with varying
size and order, especially when there are multiple writers where each sends
partial knowledge chunks. In this case lookups are needed at every update,
but this is fortunately not the case in the controller manager.

When a client is loaded, it specifies which joints and interfaces it
requires, including the ordering. This is something that does not change
during the lifetime of the controller, unless it is stopped, unloaded, and
re-loaded with a different configuration.

- 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.
>

Sometimes you are constrained by your hardware vendor, and sometimes you
want to do just that; back to the fancy example: It makes sense to expose
both an effort and a stiffness interface for a variable-stiffness joint, as
these are two 'independent' control parameters.


> 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.
>

Great!. I did not fully understand the above statement, are you currently
working on this?. I can share the repository where I'll be working on --I'm
just setting it up-- but it'll take some weeks before something usable
starts to show up.

Cheers,

Adolfo.

>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>