On 01/17/2011 01:18 PM, Herman Bruyninckx wrote:
> I guess you can reuse the component architecture that is being used in
> some
> OCL applications for 6DOF velocity controlled robots: they have an
> interface that is generic to all robots of the same kind, and internally
> they hide the hardware-dependent software, such as the drivers to the IO.
> In other words, there is not that much deep architecture work to be done.
Great, I'll check the current code and try to make the same...
> A good advise: don't try to put every single piece of code in its own
> RTT component, since Orocos has been designed for "coarse grained"
> component based systems. For example, it makes a lot of sense to keep
> all the control loops, that run at the same frequency and are using
> the same
> hardware IO, within the same component.
Ok, thanks for the advice and the fast reply!
> I wish you a lot of success with your endeavour!
Thanks a lot! I wish too...
In case of good results I'll share the code.

Fabrizio

On Jan 17, 2011, at 07:18 , Herman Bruyninckx wrote:

> On Mon, 17 Jan 2011, Fabrizio wrote:
>
>> Hi all,
>> This is my first post so I greet everybody...
>
> Welcome! :-)
>
>> I'm a developer of Altair, University of Verona
>> (http://metropolis.sci.univr.it).
>
> Give my regards to Paolo! :-)
>
>> I'm going to put a Stabuli Puma 260 and a Puma 560, both controlled a
>> Galil 1880 board, into Orocos.
>> We control that Galil with dmclnxlib and with a kernel module modified
>> by us.
>>
>> I don't know what's the best way to do this work and respect the
>> architecture of Orocos so if you have suggestions
>> I'll be glad...
>
> I guess you can reuse the component architecture that is being used in some
> OCL applications for 6DOF velocity controlled robots: they have an
> interface that is generic to all robots of the same kind, and internally
> they hide the hardware-dependent software, such as the drivers to the IO.
> In other words, there is not that much deep architecture work to be done.

Agreed. Wrap access to the dmclnxlib library into a component (most likely just one component) controlling the robot, and then use other controller/coordinator components to make the robot move.

> A good advise: don't try to put every single piece of code in its own
> RTT component, since Orocos has been designed for "coarse grained"
> component based systems. For example, it makes a lot of sense to keep
> all the control loops, that run at the same frequency and are using the same
> hardware IO, within the same component.

While Herman has a good point, there is a wide spectrum on the ML regarding number of components in a system, and how fine-grained such components are. There are a number of users with 10-20 components in a system, but there are also a number of us operating with 40+ components per system. The problem with the higher numbers isn't RTT, it's the scalability of the deployment tooling (the OCL deployer or similar tools).
S