Hello everyone,
Today's question is about communication. What is the best way to handle IO
in Orocos? By IO I mean communication from and towards a non-Orocos
environment (hence not port communication).
There used to be an IO component in OCL, which has been removed. There
exists a typekit for Orocos which is called Yarp.
Now the question is both about the technical side and the architecture side:
- Is Yarp a good choice? Are there alternatives worth mentionning? Is it
also available for communication that does not use Orocos ports? How easy
is it to implement?
- What is the best way to handle IO in Orocos? Since basically I have
position, velocity, and current commands travelling everywhere, it could be
interesting to plug it anywhere. Moreover, I want to be able to command
several devices (I have several control cards with 1 IP address each). I
figured I should use some sort of driver, and have the interfaces from my
robot available through services gathered in one Orocos IO Component. I
still have trouble working out the specifics about how to connect those
services elegantly to the other Orocos components, I could need a hand.
Thanks in advance
Flavian
UDP/TCP and IO component
On 07/10/2013 09:09 AM, Flavian Hautbois wrote:
> Hello everyone,
>
> Today's question is about communication. What is the best
"best".. Please don't use that word :)
> way to handle
> IO in Orocos? By IO I mean communication from and towards a non-Orocos
> environment (hence not port communication).
> There used to be an IO component in OCL, which has been removed. There
> exists a typekit for Orocos which is called Yarp.
What are your needs vis-a-vis 1) Data rate 2) Size of packets 3)
(de)serialization on the the 'other side' [this can be a big deal, esp.
if the 'other side' is something like a small
micro-controller/dSpace/Simulink, xPC Target etc. Depending on your
needs you can try different options. In no particular order, this is
what I've tried at some point or another
1.
http://www.orocos.org/wiki/rtt/examples-and-tutorials/simple-tcp-client-...
2. Use a UDP client/server component. The component is periodic and in
each updateHook() in reads its data ports and asynchronously sends the
data to a remote server. In another thread of the component (created
during startHook()), you can asynchronously receive from a remote
server. I have used the boost asio libraries for this and it works very
well, together with a configuration file for the ip-addresses and port
numbers; just make sure your data packet size < UDP datagram size :)
3. Recently, we have moved away from client-server approaches in favor
of publish-subscribe mechanisms. For example, in one on-going project we
use ZeroMQ to publish a stream data from a ZMQStreamer component. The
advantage of this approach is that once you setup the orocos publisher
component, you can subscribe to the stream from different computers
running different software. In our case one machine has a subscriber
dumping data to a mongodb, another machine subscribes and provides a
Human-Machine Interface display etc. The thing to be aware of with ZMQ
(or similar transports) is that they don't do the (de)serialization for
you. We have found it convenient to use the binaray BSON protocol for
this, in conjunction with ZMQ. It provides maximum flexibility in the
sense that the computers/subscribers can run different operating systems
and programming languages suitable for the task. We have also written
C++ S function blocks for Simulink, to subscribe to the data stream in a
running model. But you need to evaluate the performance penalty (if any).
4. Another approach is to use DDS. This has it's own (de)serialization
mechanisms so you don't have to worry about that. It also has a lot of
QoS mechanisms, and at least one DDS implementation (RTI) runs under
Xenomai. OpenSplice DDS has some kind of GPL (or maybe LGPL) license.
Beware though, that none of these mechanisms are transparent..unlike the
YARP transport. This means you need to build a dedicated orocos
component for the i/o.
Hope this helps,
Sagar
> Now the question is both about the technical side and the architecture side:
> - Is Yarp a good choice? Are there alternatives worth mentionning?
> Is it also available for communication that does not use Orocos ports?
> How easy is it to implement?
> - What is the best way to handle IO in Orocos? Since basically I
> have position, velocity, and current commands travelling everywhere, it
> could be interesting to plug it anywhere. Moreover, I want to be able to
> command several devices (I have several control cards with 1 IP address
> each). I figured I should use some sort of driver, and have the
> interfaces from my robot available through services gathered in one
> Orocos IO Component. I still have trouble working out the specifics
> about how to connect those services elegantly to the other Orocos
> components, I could need a hand.
>
> Thanks in advance
>
> Flavian
>
>
UDP/TCP and IO component
On Wed, 10 Jul 2013, Flavian Hautbois wrote:
> Hello everyone,
>
> Today's question is about communication. What is the best way to handle IO
> in Orocos?
Not...!
Orocos has been designed not to do communication with the "outside world";
you should select one of the many communication middlewares out there,
wrap an RTT component around it, and let that one interact with the other
RTT components via ports.
> By IO I mean communication from and towards a non-Orocos
> environment (hence not port communication).
> There used to be an IO component in OCL, which has been removed. There
> exists a typekit for Orocos which is called Yarp.
>
> Now the question is both about the technical side and the architecture side:
> - Is Yarp a good choice? Are there alternatives worth mentionning? Is it
> also available for communication that does not use Orocos ports? How easy
> is it to implement?
My one-line experience summary: _all_ non-robotics communication
middlewares are better than those that have been developed by roboticists.
> - What is the best way to handle IO in Orocos? Since basically I have
> position, velocity, and current commands travelling everywhere, it could be
> interesting to plug it anywhere. Moreover, I want to be able to command
> several devices (I have several control cards with 1 IP address each). I
> figured I should use some sort of driver, and have the interfaces from my
> robot available through services gathered in one Orocos IO Component. I
> still have trouble working out the specifics about how to connect those
> services elegantly to the other Orocos components, I could need a hand.
>
> Thanks in advance
>
> Flavian
Herman
UDP/TCP and IO component
>From my experience, don't fall in the pitfall of putting everything in
Orocos. The drivers/libs that are developped to handle the hardware should
be able to work out of Orocos (or any framework) aka in a simple main test
program. The simple reason for this is that Orocos is just the glue code,
your valuable code should stay framework independent.
Orocos comes when interfacing your "high level" software onto the hardware
or different independent parts of your code. At this point you should
already have a defined interface in your lib/driver
(input/output/commands...) and the mapping will be straightforward in
Orocos concepts.
I'll let people with more experience with this hardware implementation
problem to give further details.
2013/7/10 Flavian Hautbois <f [dot] hautbois [..] ...>
> Hello everyone,
>
> Today's question is about communication. What is the best way to handle IO
> in Orocos? By IO I mean communication from and towards a non-Orocos
> environment (hence not port communication).
> There used to be an IO component in OCL, which has been removed. There
> exists a typekit for Orocos which is called Yarp.
>
> Now the question is both about the technical side and the architecture
> side:
> - Is Yarp a good choice? Are there alternatives worth mentionning? Is
> it also available for communication that does not use Orocos ports? How
> easy is it to implement?
> - What is the best way to handle IO in Orocos? Since basically I have
> position, velocity, and current commands travelling everywhere, it could be
> interesting to plug it anywhere. Moreover, I want to be able to command
> several devices (I have several control cards with 1 IP address each). I
> figured I should use some sort of driver, and have the interfaces from my
> robot available through services gathered in one Orocos IO Component. I
> still have trouble working out the specifics about how to connect those
> services elegantly to the other Orocos components, I could need a hand.
>
> Thanks in advance
>
> Flavian
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
UDP/TCP and IO component
That's true. Yarp also exists as a standalone so I should be fine for that.
The drivers for my robots, though, will be developped separately from
Orocos. I still need a nice way to embed them though...
2013/7/10 Willy Lambert <lambert [dot] willy [..] ...>
> From my experience, don't fall in the pitfall of putting everything in
> Orocos. The drivers/libs that are developped to handle the hardware should
> be able to work out of Orocos (or any framework) aka in a simple main test
> program. The simple reason for this is that Orocos is just the glue code,
> your valuable code should stay framework independent.
>
> Orocos comes when interfacing your "high level" software onto the hardware
> or different independent parts of your code. At this point you should
> already have a defined interface in your lib/driver
> (input/output/commands...) and the mapping will be straightforward in
> Orocos concepts.
>
> I'll let people with more experience with this hardware implementation
> problem to give further details.
>
>
> 2013/7/10 Flavian Hautbois <f [dot] hautbois [..] ...>
>
>> Hello everyone,
>>
>> Today's question is about communication. What is the best way to handle
>> IO in Orocos? By IO I mean communication from and towards a non-Orocos
>> environment (hence not port communication).
>> There used to be an IO component in OCL, which has been removed. There
>> exists a typekit for Orocos which is called Yarp.
>>
>> Now the question is both about the technical side and the architecture
>> side:
>> - Is Yarp a good choice? Are there alternatives worth mentionning? Is
>> it also available for communication that does not use Orocos ports? How
>> easy is it to implement?
>> - What is the best way to handle IO in Orocos? Since basically I have
>> position, velocity, and current commands travelling everywhere, it could be
>> interesting to plug it anywhere. Moreover, I want to be able to command
>> several devices (I have several control cards with 1 IP address each). I
>> figured I should use some sort of driver, and have the interfaces from my
>> robot available through services gathered in one Orocos IO Component. I
>> still have trouble working out the specifics about how to connect those
>> services elegantly to the other Orocos components, I could need a hand.
>>
>> Thanks in advance
>>
>> Flavian
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>
UDP/TCP and IO component
On Jul 10, 2013, at 04:04 , Flavian Hautbois <f [dot] hautbois [..] ...> wrote:
> That's true. Yarp also exists as a standalone so I should be fine for that. The drivers for my robots, though, will be developped separately from Orocos. I still need a nice way to embed them though...
>
>
> 2013/7/10 Willy Lambert <lambert [dot] willy [..] ...>
> From my experience, don't fall in the pitfall of putting everything in Orocos. The drivers/libs that are developped to handle the hardware should be able to work out of Orocos (or any framework) aka in a simple main test program. The simple reason for this is that Orocos is just the glue code, your valuable code should stay framework independent.
>
> Orocos comes when interfacing your "high level" software onto the hardware or different independent parts of your code. At this point you should already have a defined interface in your lib/driver (input/output/commands...) and the mapping will be straightforward in Orocos concepts.
>
> I'll let people with more experience with this hardware implementation problem to give further details.
>
>
> 2013/7/10 Flavian Hautbois <f [dot] hautbois [..] ...>
> Hello everyone,
>
> Today's question is about communication. What is the best way to handle IO in Orocos? By IO I mean communication from and towards a non-Orocos environment (hence not port communication).
> There used to be an IO component in OCL, which has been removed. There exists a typekit for Orocos which is called Yarp.
>
> Now the question is both about the technical side and the architecture side:
> - Is Yarp a good choice? Are there alternatives worth mentionning? Is it also available for communication that does not use Orocos ports? How easy is it to implement?
> - What is the best way to handle IO in Orocos? Since basically I have position, velocity, and current commands travelling everywhere, it could be interesting to plug it anywhere. Moreover, I want to be able to command several devices (I have several control cards with 1 IP address each). I figured I should use some sort of driver, and have the interfaces from my robot available through services gathered in one Orocos IO Component. I still have trouble working out the specifics about how to connect those services elegantly to the other Orocos components, I could need a hand.
>
> Thanks in advance
>
> Flavian
It really depends on what you need to do. We have numerous devices in our robot systems that all have different Orocos component(s) supporting them. For some, say cameras or PCI-based access to a robot, we simply use one Orocos component that coordinates behaviour and talks to the device directly. For others, say with socket interfaces, we use separate command, telemetry, and control components, and then use file descriptor activities and signal pipes to decouple the three, so that stalls or dropouts in the network don't affect the overall system coordination.
Community - we still need to do better at putting examples design patterns like these up. I don't know whether Rock has any - they seem to be about the best documented so far?
S
UDP/TCP and IO component
On 07/10/2013 12:52 PM, S Roderick wrote:
> On Jul 10, 2013, at 04:04 , Flavian Hautbois <f [dot] hautbois [..] ...
> <mailto:f [dot] hautbois [..] ...>> wrote:
>
>> That's true. Yarp also exists as a standalone so I should be fine for
>> that. The drivers for my robots, though, will be developped
>> separately from Orocos. I still need a nice way to embed them though...
>>
>>
>> 2013/7/10 Willy Lambert <lambert [dot] willy [..] ...
>> <mailto:lambert [dot] willy [..] ...>>
>>
>> From my experience, don't fall in the pitfall of putting
>> everything in Orocos. The drivers/libs that are developped to
>> handle the hardware should be able to work out of Orocos (or any
>> framework) aka in a simple main test program. The simple reason
>> for this is that Orocos is just the glue code, your valuable code
>> should stay framework independent.
>>
>> Orocos comes when interfacing your "high level" software onto the
>> hardware or different independent parts of your code. At this
>> point you should already have a defined interface in your
>> lib/driver (input/output/commands...) and the mapping will be
>> straightforward in Orocos concepts.
>>
>> I'll let people with more experience with this hardware
>> implementation problem to give further details.
>>
>>
>> 2013/7/10 Flavian Hautbois <f [dot] hautbois [..] ...
>> <mailto:f [dot] hautbois [..] ...>>
>>
>> Hello everyone,
>>
>> Today's question is about communication. What is the best way
>> to handle IO in Orocos? By IO I mean communication from and
>> towards a non-Orocos environment (hence not port communication).
>> There used to be an IO component in OCL, which has been
>> removed. There exists a typekit for Orocos which is called Yarp.
>>
>> Now the question is both about the technical side and the
>> architecture side:
>> - Is Yarp a good choice? Are there alternatives worth
>> mentionning? Is it also available for communication that does
>> not use Orocos ports? How easy is it to implement?
>> - What is the best way to handle IO in Orocos? Since
>> basically I have position, velocity, and current commands
>> travelling everywhere, it could be interesting to plug it
>> anywhere. Moreover, I want to be able to command several
>> devices (I have several control cards with 1 IP address
>> each). I figured I should use some sort of driver, and have
>> the interfaces from my robot available through services
>> gathered in one Orocos IO Component. I still have trouble
>> working out the specifics about how to connect those services
>> elegantly to the other Orocos components, I could need a hand.
>>
>> Thanks in advance
>>
>> Flavian
>>
>
> It really depends on what you need to do. We have numerous devices in
> our robot systems that all have different Orocos component(s)
> supporting them. For some, say cameras or PCI-based access to a robot,
> we simply use one Orocos component that coordinates behaviour and
> talks to the device directly. For others, say with socket interfaces,
> we use separate command, telemetry, and control components, and then
> use file descriptor activities and signal pipes to decouple the three,
> so that stalls or dropouts in the network don't affect the overall
> system coordination.
>
> Community - we still need to do better at putting examples design
> patterns like these up. I don't know whether Rock has any - they seem
> to be about the best documented so far?
In general, we are getting there.
For the particular "raw I/O" discussion,
http://rock-robotics.org/stable/documentation/device_drivers/
<http://rock-robotics.org/stable/documentation/device_drivers/writing_driver.html>
UDP/TCP and IO component
A Dimecres, 10 de juliol de 2013, Flavian Hautbois va escriure:
> That's true. Yarp also exists as a standalone so I should be fine for that.
> The drivers for my robots, though, will be developped separately from
> Orocos. I still need a nice way to embed them though...
>
Hi,
first of all, please Willy and Flavian, stop of top posting.
Second, the question exposed by Flavian is something that all of us had
suffered. And, in specific to Flavian AFAIK if that he must communicate with a
hardware (Haptic) that _only_ offers a TCP/UDP interface to connect. The Kuka
LWR offers the same and I would like to have others devices with the same
interface, non privately dark boxes without a clear interface.
It's a typical case that you have a device that offers a network
communications (in theory with some kind of "constant" rate) and you want to
create some kind of application to "control" that device, or build some
complex application around it.
I think that if you can trust that you device offers a deterministic signal
(an interrupt, a digital, or whatever) you can think to use a component that
react to that at the interval that the component do. But, the protocol,
interface to that component should done by your self and use whatever you feel
comfortable IMHO. In the case of a device with a primitive protocol, I think
that simpler is better, so build a component that communicate with the device
and from there use ports or whatever the framework provides.
Another approach, that could be elegant is that you develop a layer to
encapsulate the functionality offered by the device in a library and your
orocos component use that library to access to the device. This approach could
have some problem because you should manage the thread to wait the receive
function and maybe could be problematic to merge it in a multi-threaded
application with multiples components.
But, after all, my final conclusion and maybe some "guru" of the list correct
me is that there's no clear methodology or fundamental theory in the
implementation of a robotic problem and all of us more or less implement
solutions with some common sense to try to solve the problem.
Just my opinion,
Best regards,
Leo
>
> 2013/7/10 Willy Lambert <lambert [dot] willy [..] ...>
>
> > From my experience, don't fall in the pitfall of putting everything in
> > Orocos. The drivers/libs that are developped to handle the hardware should
> > be able to work out of Orocos (or any framework) aka in a simple main test
> > program. The simple reason for this is that Orocos is just the glue code,
> > your valuable code should stay framework independent.
> >
> > Orocos comes when interfacing your "high level" software onto the hardware
> > or different independent parts of your code. At this point you should
> > already have a defined interface in your lib/driver
> > (input/output/commands...) and the mapping will be straightforward in
> > Orocos concepts.
> >
> > I'll let people with more experience with this hardware implementation
> > problem to give further details.
> >
> >
> > 2013/7/10 Flavian Hautbois <f [dot] hautbois [..] ...>
> >
> >> Hello everyone,
> >>
> >> Today's question is about communication. What is the best way to handle
> >> IO in Orocos? By IO I mean communication from and towards a non-Orocos
> >> environment (hence not port communication).
> >> There used to be an IO component in OCL, which has been removed. There
> >> exists a typekit for Orocos which is called Yarp.
> >>
> >> Now the question is both about the technical side and the architecture
> >> side:
> >> - Is Yarp a good choice? Are there alternatives worth mentionning? Is
> >> it also available for communication that does not use Orocos ports? How
> >> easy is it to implement?
> >> - What is the best way to handle IO in Orocos? Since basically I have
> >> position, velocity, and current commands travelling everywhere, it could
be
> >> interesting to plug it anywhere. Moreover, I want to be able to command
> >> several devices (I have several control cards with 1 IP address each). I
> >> figured I should use some sort of driver, and have the interfaces from my
> >> robot available through services gathered in one Orocos IO Component. I
> >> still have trouble working out the specifics about how to connect those
> >> services elegantly to the other Orocos components, I could need a hand.
> >>
> >> Thanks in advance
> >>
> >> Flavian
> >>
> >> --
> >> Orocos-Users mailing list
> >> Orocos-Users [..] ...
> >> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >>
> >>
> >
>
>
UDP/TCP and IO component
Hello,
Just to share a bit of my experience... In our project we have a
microcontroller equipped with Ethernet controller. I can freely say that
MCU runs in hard realtime. The main computer communicates with that MCU via
TCP-IP. An OROCOS component is dedicated for that comm. I implemented the
polling principle, client-server arch. This is not optimal, since TCP-IP
introduces a lot of overhead, but for our comm. setting it works fine (fs =
500 Hz). FYI, I am time-stamping entry, and exit from that component
(TimeService::Instance()->getTicks()) and jitter is quite low (< 100 us).
>From the coding point of view, I don't think that it is a big deal to
establish TCP-IP/UDP based comm with a device -- this does not relates to
"parsing" the device's protocol.
BTW, In the same setup we use EtherCAT based EBOX device, fs = 1kHz, and we
do not have problems.
Best,
Milan
On Wed, Jul 10, 2013 at 11:09 AM, Leopold Palomo-Avellaneda <
leopold [dot] palomo [..] ...> wrote:
> A Dimecres, 10 de juliol de 2013, Flavian Hautbois va escriure:
> > That's true. Yarp also exists as a standalone so I should be fine for
> that.
> > The drivers for my robots, though, will be developped separately from
> > Orocos. I still need a nice way to embed them though...
> >
>
> Hi,
>
> first of all, please Willy and Flavian, stop of top posting.
>
> Second, the question exposed by Flavian is something that all of us had
> suffered. And, in specific to Flavian AFAIK if that he must communicate
> with a
> hardware (Haptic) that _only_ offers a TCP/UDP interface to connect. The
> Kuka
> LWR offers the same and I would like to have others devices with the same
> interface, non privately dark boxes without a clear interface.
>
> It's a typical case that you have a device that offers a network
> communications (in theory with some kind of "constant" rate) and you want
> to
> create some kind of application to "control" that device, or build some
> complex application around it.
>
> I think that if you can trust that you device offers a deterministic signal
> (an interrupt, a digital, or whatever) you can think to use a component
> that
> react to that at the interval that the component do. But, the protocol,
> interface to that component should done by your self and use whatever you
> feel
> comfortable IMHO. In the case of a device with a primitive protocol, I
> think
> that simpler is better, so build a component that communicate with the
> device
> and from there use ports or whatever the framework provides.
>
> Another approach, that could be elegant is that you develop a layer to
> encapsulate the functionality offered by the device in a library and your
> orocos component use that library to access to the device. This approach
> could
> have some problem because you should manage the thread to wait the receive
> function and maybe could be problematic to merge it in a multi-threaded
> application with multiples components.
>
> But, after all, my final conclusion and maybe some "guru" of the list
> correct
> me is that there's no clear methodology or fundamental theory in the
> implementation of a robotic problem and all of us more or less implement
> solutions with some common sense to try to solve the problem.
>
> Just my opinion,
>
> Best regards,
>
> Leo
>
>
> >
> > 2013/7/10 Willy Lambert <lambert [dot] willy [..] ...>
> >
> > > From my experience, don't fall in the pitfall of putting everything in
> > > Orocos. The drivers/libs that are developped to handle the hardware
> should
> > > be able to work out of Orocos (or any framework) aka in a simple main
> test
> > > program. The simple reason for this is that Orocos is just the glue
> code,
> > > your valuable code should stay framework independent.
> > >
> > > Orocos comes when interfacing your "high level" software onto the
> hardware
> > > or different independent parts of your code. At this point you should
> > > already have a defined interface in your lib/driver
> > > (input/output/commands...) and the mapping will be straightforward in
> > > Orocos concepts.
> > >
> > > I'll let people with more experience with this hardware implementation
> > > problem to give further details.
> > >
> > >
> > > 2013/7/10 Flavian Hautbois <f [dot] hautbois [..] ...>
> > >
> > >> Hello everyone,
> > >>
> > >> Today's question is about communication. What is the best way to
> handle
> > >> IO in Orocos? By IO I mean communication from and towards a non-Orocos
> > >> environment (hence not port communication).
> > >> There used to be an IO component in OCL, which has been removed. There
> > >> exists a typekit for Orocos which is called Yarp.
> > >>
> > >> Now the question is both about the technical side and the architecture
> > >> side:
> > >> - Is Yarp a good choice? Are there alternatives worth
> mentionning? Is
> > >> it also available for communication that does not use Orocos ports?
> How
> > >> easy is it to implement?
> > >> - What is the best way to handle IO in Orocos? Since basically I
> have
> > >> position, velocity, and current commands travelling everywhere, it
> could
> be
> > >> interesting to plug it anywhere. Moreover, I want to be able to
> command
> > >> several devices (I have several control cards with 1 IP address
> each). I
> > >> figured I should use some sort of driver, and have the interfaces
> from my
> > >> robot available through services gathered in one Orocos IO Component.
> I
> > >> still have trouble working out the specifics about how to connect
> those
> > >> services elegantly to the other Orocos components, I could need a
> hand.
> > >>
> > >> Thanks in advance
> > >>
> > >> Flavian
> > >>
> > >> --
> > >> Orocos-Users mailing list
> > >> Orocos-Users [..] ...
> > >> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> > >>
> > >>
> > >
> >
> >
> > --
> > F. Hautbois
> >
>
>
> --
> --
> Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...>
> Institut d'Organització i Control de Sistemes Industrials -IOC-
> Universitat Politècnica de Catalunya -UPC-
>
> Institute of Industrial and Control Engineering
> Technical University of Catalonia
> Avda. Diagonal 647, pl. 11
> 08028 BARCELONA (Spain)
>
> Tel. +34-934017163
> Fax. +34-934016605
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
UDP/TCP and IO component
On Wed, 10 Jul 2013, Leopold Palomo-Avellaneda wrote:
> A Dimecres, 10 de juliol de 2013, Flavian Hautbois va escriure:
>> That's true. Yarp also exists as a standalone so I should be fine for that.
>> The drivers for my robots, though, will be developped separately from
>> Orocos. I still need a nice way to embed them though...
>>
>
> Hi,
>
> first of all, please Willy and Flavian, stop of top posting.
>
> Second, the question exposed by Flavian is something that all of us had
> suffered. And, in specific to Flavian AFAIK if that he must communicate with a
> hardware (Haptic) that _only_ offers a TCP/UDP interface to connect. The Kuka
> LWR offers the same and I would like to have others devices with the same
> interface, non privately dark boxes without a clear interface.
>
> It's a typical case that you have a device that offers a network
> communications (in theory with some kind of "constant" rate) and you want to
> create some kind of application to "control" that device, or build some
> complex application around it.
>
> I think that if you can trust that you device offers a deterministic signal
> (an interrupt, a digital, or whatever) you can think to use a component that
> react to that at the interval that the component do. But, the protocol,
> interface to that component should done by your self and use whatever you feel
> comfortable IMHO. In the case of a device with a primitive protocol, I think
> that simpler is better, so build a component that communicate with the device
> and from there use ports or whatever the framework provides.
>
> Another approach, that could be elegant is that you develop a layer to
> encapsulate the functionality offered by the device in a library and your
> orocos component use that library to access to the device. This approach could
> have some problem because you should manage the thread to wait the receive
> function and maybe could be problematic to merge it in a multi-threaded
> application with multiples components.
>
> But, after all, my final conclusion and maybe some "guru" of the list correct
> me is that there's no clear methodology or fundamental theory in the
> implementation of a robotic problem and all of us more or less implement
> solutions with some common sense to try to solve the problem.
Agreed... The bad news is that the "best practices" that come out now and
then of some groups that have a lot of good common sense are seldom
"consolidated" and reused by others... :-(
> Just my opinion,
My reaction above is not an opinion anymore, but a highly corroborated
factual statement... Unfortunately.
> Best regards,
>
> Leo
Herman