Dear All,
I find this project extremely interesting and am considering whether to employ it for our project.
Our front ends will definitely be GUI's executing on Windows platform - i.e. not OROCOS components.
Our equipment controllers will be embedded processors in control cubicles, probably using Linux with some sort of real-time extensions - lets say built with OROCOS components.
Ethernet shall be the medium for comms between GUI and controller.
Real-time ethernet to be the medium for comms between controllers.
This seems to be a very standard set-up to me. After looking through the documentation, I haven't well understood how you would manage the connection between the non-OROCOS GUI's and the OROCOS controllers.
Any info would be appreciated.
Thanks,
David
Windows GUI Orocos Application
On Thursday 11 September 2008 16:37:46 david [dot] hamilton [..] ...
wrote:
> Dear All,
>
> I find this project extremely interesting and am considering whether to
> employ it for our project.
>
> Our front ends will definitely be GUI's executing on Windows platform -
> i.e. not OROCOS components. Our equipment controllers will be embedded
> processors in control cubicles, probably using Linux with some sort of
> real-time extensions - lets say built with OROCOS components. Ethernet
> shall be the medium for comms between GUI and controller. Real-time
> ethernet to be the medium for comms between controllers.
>
> This seems to be a very standard set-up to me. After looking through the
> documentation, I haven't well understood how you would manage the
> connection between the non-OROCOS GUI's and the OROCOS controllers.
>
> Any info would be appreciated.
I have used the CORBA extension for the components to get access to components
in python (which can also be used in windows). This is also the way we use to
connect to components in the KTaskbrowser, which is a very general QT-based
gui for orocos components.
Ruben
Windows GUI Orocos Application
On Thursday 11 September 2008 16:37:46 david [dot] hamilton [..] ...
wrote:
> Dear All,
>
> I find this project extremely interesting and am considering whether to
> employ it for our project.
>
> Our front ends will definitely be GUI's executing on Windows platform -
> i.e. not OROCOS components. Our equipment controllers will be embedded
> processors in control cubicles, probably using Linux with some sort of
> real-time extensions - lets say built with OROCOS components. Ethernet
> shall be the medium for comms between GUI and controller. Real-time
> ethernet to be the medium for comms between controllers.
>
> This seems to be a very standard set-up to me. After looking through the
> documentation, I haven't well understood how you would manage the
> connection between the non-OROCOS GUI's and the OROCOS controllers.
The only option that the RTT provides for remote, cross-platform access is the
CORBA layer. It makes the component interfaces available, but not as
easy/straight forward as in pure C++. This is mainly because of the mediocre
CORBA bindings for C++, but also because the interface was initially designed
to allow Orocos<->Orocos communication and not User<->Orocos communication.
Other languages such as Java or Python are easier to use with the CORBA
layer.
I know of some users who dropped CORBA and which have written their own
application-specific TCP/IP protocol to interface with their Orocos
application to work around this issue. For rapid prototyping, the CORBA
interface still wins of course.
We don't yet support real-time networked communication for data flow. This is
a hot topic for some of our users, but will not yet be there for the next two
releases at least.
Peter
Windows GUI Orocos Application
Hi Peter,
Thanks for the info.
My current concern is to try to create a standard approach for the controllers that will need to be developed for our project. The OROCOS system looks to me to have the right combination of structure and flexibility.
I had noticed that one of your applications was "Motion control over realtime ethernet" so I thought you supported real-time network communication. In any case, our view is long-term, so I imagine this issue will be resolved along the way.
Regarding the GUI interface, do the users you speak of make their TCP/IP developments available to others? I would like to have an initial understanding of what was involved. I don't have a clear understanding of the OROCOS component public interfaces and I don't know CORBA at all. My feeling is that we too will develop a specific TCP/IP comms layer.
Regards,
David
Windows GUI Orocos Application
On Mon, 15 Sep 2008, david [dot] hamilton [..] ... wrote:
> My current concern is to try to create a standard approach for the
> controllers that will need to be developed for our project. The OROCOS system
> looks to me to have the right combination of structure and flexibility.
>
> I had noticed that one of your applications was "Motion control over realtime
> ethernet" so I thought you supported real-time network communication. In any
> case, our view is long-term, so I imagine this issue will be resolved along
> the way.
We have indeed used a 6D camera system in a control loop via RT-net
realtime ethernet. But there are so many of those realtime ethernet
protocols available... :-( Anyway, it's Orocos' policy not to mix
communication middleware and protocols with the development of
realtime-safe infrastructure. In other words, the selection and
implementation of such middleware is (to be) done outside of Orocos. For
historical reasons, Orocos does have the option to use CORBA, but this is
not a dependency. It can serve as an example for other middleware
interfaces, of course, and these could be added to the codebase in case
somebody contributes mature code :-)
> Regarding the GUI interface, do the users you speak of make their TCP/IP
> developments available to others? I would like to have an initial
> understanding of what was involved. I don't have a clear understanding of the
> OROCOS component public interfaces and I don't know CORBA at all. My feeling
> is that we too will develop a specific TCP/IP comms layer.
"Yet another one" :-)
Some students have used TCP/IP to connect Blender to a robot running. I think Ruben can point you to
Orocos:
the interfacing code involved in this project...
Please, feel free to elaborate more on this topic, since it is indeed a
topic that many people are interested in (and most go their own TCP/IP
way, which could be easy in the short term but is a maintenance nightmare
in the long term....).
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Windows GUI Orocos Application
On Mon, 15 Sep 2008, david [dot] hamilton [..] ... wrote:
Some students have used TCP/IP to connect Blender to a robot running. I think Ruben can point you to the interfacing code involved in this project...
Orocos:
Please, feel free to elaborate more on this topic, since it is indeed a topic that many people are interested in (and most go their own TCP/IP way, which could be easy in the short term but is a maintenance nightmare in the long term....).
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Presumably they created a Component proxy on the GUI end and a Component server at the application end with a TCP/IP connection between the two.
This software would be a worthy addition to the OROCOS site, especially if the TCP/IP link is robust.
Windows GUI Orocos Application
On Monday 15 September 2008 16:35:17 david [dot] hamilton [..] ...
wrote:
>
On Mon, 15 Sep 2008,
> david [dot] hamilton [..] ... wrote:
>
> Some students have used TCP/IP to connect Blender to a robot running
> Orocos: . I think Ruben can point you to the interfacing code involved in
> this project...
>
> Please, feel free to elaborate more on this topic, since it is indeed a
> topic that many people are interested in (and most go their own TCP/IP way,
> which could be easy in the short term but is a maintenance nightmare in the
> long term....).
>
> Herman
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
>
>
> Presumably they created a Component proxy on the GUI end and a Component
> server at the application end with a TCP/IP connection between the two.
It was a lot more simple, since they only wanted to send over data in one
direction it was just a socket on the server-side (non-OROCOS) where data in a
specific format was send into and a socket on the client-side (OROCOS-
component) that read the data from the socket and put it in the right form on
one of it's DataPorts.
> This software would be a worthy addition to the OROCOS site, especially if
> the TCP/IP link is robust.
We already have a Component which can report data over a tcp/ip link
(streaming). This is a general component which is available in the OCL
library:
I also have build an application-specific component to listen on a port for
specific commands. It triggers events to which other components in the
application react on to execute the desired command.
It uses the same tcp-socket related classes as the reporting component uses
and parses the messages it receives.
Ruben
Windows GUI Orocos Application
On Mon, 15 Sep 2008, david hamilton wrote:
>
On Mon, 15 Sep 2008, david hamilton
> wrote:
>
> Some students have used TCP/IP to connect Blender to a robot running
> Orocos: . I think Ruben can point you to the interfacing code involved in
> this project...
>
> Please, feel free to elaborate more on this topic, since it is indeed a topic
> that many people are interested in (and most go their own TCP/IP way, which
> could be easy in the short term but is a maintenance nightmare in the long
> term....).
>
> Herman
>
>
> Presumably they created a Component proxy on the GUI end and a Component
> server at the application end with a TCP/IP connection between the two.
>
> This software would be a worthy addition to the OROCOS site, especially if
> the TCP/IP link is robust.
It isn't :-) Since, it too, was a "Yet Another Quick Hack because doing it
professionally is too difficult and not necessary"... In other words, the
"component proxy" was not worth being called this way.
Anyway, we _are_ interested in adding such a thing to the Orocos site, but
nobody currently has time to clean up the biggest mess and document it
properly...
Herman
PS If you don't want your plain email address to show up in our public
mailing list archives, you should configure your email setup to also use a
name instead of just an email address...
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm