Orocos port to QNX

Dear Orocos developers,

I am happy to announce an initial (but quite reasonable) port of the Orocos
to the QNX real-time OS, http://www.qnx.com/ has been comleted.
i have just pushed it to my GitHub repository,
http://github.com/ptroja/orocos-rtt-qnx
- see branches rtt-1.0-svn-patches-qnx and rtt-2.0-mainline-qnx.

While QNX is propertiary system, so you can find it a bit against the
open-source philosophy,
I think that this port can be at least *interesting*. Actually most of the
QNX source code is now
open - legal fans can take a look at this site:
http://www.qnx.com/news/pr_2471_1.html

The exact build procedure is a bit tricky - you need to install a
cross-development headers
and libraries from my http://github.com/ptroja/qnx-cross/downloads.

The current status is as follows:
* all RTT compiles cleanly, both for 1.x and 2.x branches,
* most of the tests programs fail (but not most of the test cases!) - which
I guess is not so bad,
* OCL needs some hand-help to compile, but the basic set of components
(helloworld, deployer,
timer, taskbrowser and reporter) seems to work properly.

During the port I have discovered some minor STL issues, like missing
headers or std::
namespace prefixes (QNX C++ compiler is more restrictive about this). I
think those can
be safely applied to trunk (I could only check, that gnulinux target is
happy with those fixes).
Other changes are QNX specific, but they do not pollute Orocos source tree
at all.

The the final question is... Are there any interest in the community in
sharing and improving this port?
I think there is no point to have just another dead-port to maintain in the
source tree (I think there
was such a story of RTEMS port some time ago...). I think, that QNX is very
interesting platform
for Orocos, but there must be also interest of users to make it live and
work :-)

Best regards,

Orocos port to QNX

On Saturday 15 May 2010 19:48:31 Piotr Trojanek wrote:
> Dear Orocos developers,
>
> I am happy to announce an initial (but quite reasonable) port of the Orocos
> to the QNX real-time OS, http://www.qnx.com/ has been comleted.
> i have just pushed it to my GitHub repository,
> http://github.com/ptroja/orocos-rtt-qnx
> - see branches rtt-1.0-svn-patches-qnx and rtt-2.0-mainline-qnx.

Hi Piotr,

Thanks for doing this effort, the more rtos'es the merrier :-) I looked at your
patches and they look clean. I think that all ports belong on the rtt
mainline, and yours seems ready for merging. You are right that there is a
currently dead port (ecos) in the repository. Maybe we should tag that
directory with a file 'UNMAINTAINED'. Nevertheless, ecos is not dead, and I
like to keep it in there in case someone wants to pick it up again, or needs a
port towards an RTOS that is similar to ecos. I have the same feeling for the
QNX port, as long as one user is runnnig Orocos on top of QNX, it *certainly*
belongs in the mainline. when that last user drops it, we get in the 'ecos'
case.

I'll pull it in later this week if that's fine for you...

Peter

Orocos port to QNX

On Sat, 15 May 2010, Piotr Trojanek wrote:

> I am happy to announce an initial (but quite reasonable) port of the Orocos
> to the QNX real-time OS, http://www.qnx.com/ has been comleted.

Great! Probably it deserves a mention on the Orocos.org home page...

> i have just pushed it to my GitHub repository, http://github.com/ptroja/orocos-rtt-qnx
> - see branches rtt-1.0-svn-patches-qnx and rtt-2.0-mainline-qnx.
>
> While QNX is propertiary system, so you can find it a bit against the open-source
> philosophy,

It's not more "strange" than the efforts to make RTT run on Windows or MAC OS X :-)

> I think that this port can be at least *interesting*.
> Actually most of the QNX source code is now
> open - legal fans can take a look at this site: http://www.qnx.com/news/pr_2471_1.html
>
> The exact build procedure is a bit tricky - you need to install a cross-development
> headers
> and libraries from my http://github.com/ptroja/qnx-cross/downloads.
>
> The current status is as follows:
> * all RTT compiles cleanly, both for 1.x and 2.x branches,
> * most of the tests programs fail (but not most of the test cases!) - which I guess is
> not so bad,
> * OCL needs some hand-help to compile, but the basic set of components (helloworld,
> deployer,
> timer, taskbrowser and reporter) seems to work properly.
>
> During the port I have discovered some minor STL issues, like missing headers or std::
> namespace prefixes (QNX C++ compiler is more restrictive about this). I think those can
> be safely applied to trunk (I could only check, that gnulinux target is happy with those
> fixes).
> Other changes are QNX specific, but they do not pollute Orocos source tree at all.
>
> The the final question is... Are there any interest in the community in sharing and
> improving this port?
> I think there is no point to have just another dead-port to maintain in the source tree
> (I think there
> was such a story of RTEMS port some time ago...). I think, that QNX is very interesting
> platform
> for Orocos, but there must be also interest of users to make it live and work  :-)

There is of course the other "final" question: what are the pros and cons
of supporting QNX? Or other "less popular" OSs?

I mean this as a serious question, to which I would welcome motivated
arguments, since making Orocos platform-independent was an _objective_
since day one...

Phrasing the question a bit differently: what is realtime Linux missing wrt
QNX, RTEMS, VxWorks...? There is at least one thing I can come up with:
certification! But there are probably other arguments, or am I wrong...?

For example, Piotr, what is your lab's motivation to go for QNX instead of Linux?
Legacy? Support? Features?

> Best regards,
>
> --
> Piotr Trojanek

Herman

> Robot Control and Recognition Systems Team,
> Institute of Control & Computation Engineering,
> Warsaw University of Technology

Orocos port to QNX

We are now using Orocos/RTT as part of a development project here at Disney. While we are developing in Linux, platform independence is certainly a selling point to have Orocos be accepted by the larger Disney community.

Without discussing the pros/cons of QNX, I will say it does tend to be one of the leading contenders in any discussion of commercial RTOS. It seems to me that a maintained port to QNX would certainly lend credibility (and testing) to the stated goal of platform independence.

-Akhil

Akhil J. Madhani, PhD
Technical Staff - Director
Walt Disney Imagineering R&D
1401 Flower St.
Glendale, CA 91201
Office: (818) 553-6839
Cell: (818) 641-4481
akhil [dot] j [dot] madhani [..] ...

This electronic message transmission contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please immediately notify the sender at (818) 553-6839 and delete this e-mail message from your computer.  Be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited.  Thank you.
-----Original Message-----
From: orocos-dev-bounces [..] ... [mailto:orocos-dev-bounces [..] ...] On Behalf Of Herman Bruyninckx
Sent: Sunday, May 16, 2010 11:34 PM
To: Piotr Trojanek
Cc: orocos-dev [..] ...
Subject: Re: [Orocos-Dev] Orocos port to QNX

On Sat, 15 May 2010, Piotr Trojanek wrote:

> I am happy to announce an initial (but quite reasonable) port of the Orocos
> to the QNX real-time OS, http://www.qnx.com/ has been comleted.

Great! Probably it deserves a mention on the Orocos.org home page...

> i have just pushed it to my GitHub repository, http://github.com/ptroja/orocos-rtt-qnx
> - see branches rtt-1.0-svn-patches-qnx and rtt-2.0-mainline-qnx.
>
> While QNX is propertiary system, so you can find it a bit against the open-source
> philosophy,

It's not more "strange" than the efforts to make RTT run on Windows or MAC OS X :-)

> I think that this port can be at least *interesting*.
> Actually most of the QNX source code is now
> open - legal fans can take a look at this site: http://www.qnx.com/news/pr_2471_1.html
>
> The exact build procedure is a bit tricky - you need to install a cross-development
> headers
> and libraries from my http://github.com/ptroja/qnx-cross/downloads.
>
> The current status is as follows:
> * all RTT compiles cleanly, both for 1.x and 2.x branches,
> * most of the tests programs fail (but not most of the test cases!) - which I guess is
> not so bad,
> * OCL needs some hand-help to compile, but the basic set of components (helloworld,
> deployer,
> timer, taskbrowser and reporter) seems to work properly.
>
> During the port I have discovered some minor STL issues, like missing headers or std::
> namespace prefixes (QNX C++ compiler is more restrictive about this). I think those can
> be safely applied to trunk (I could only check, that gnulinux target is happy with those
> fixes).
> Other changes are QNX specific, but they do not pollute Orocos source tree at all.
>
> The the final question is... Are there any interest in the community in sharing and
> improving this port?
> I think there is no point to have just another dead-port to maintain in the source tree
> (I think there
> was such a story of RTEMS port some time ago...). I think, that QNX is very interesting
> platform
> for Orocos, but there must be also interest of users to make it live and work  :-)

There is of course the other "final" question: what are the pros and cons
of supporting QNX? Or other "less popular" OSs?

I mean this as a serious question, to which I would welcome motivated
arguments, since making Orocos platform-independent was an _objective_
since day one...

Phrasing the question a bit differently: what is realtime Linux missing wrt
QNX, RTEMS, VxWorks...? There is at least one thing I can come up with:
certification! But there are probably other arguments, or am I wrong...?

For example, Piotr, what is your lab's motivation to go for QNX instead of Linux?
Legacy? Support? Features?

> Best regards,
>
> --
> Piotr Trojanek

Herman

> Robot Control and Recognition Systems Team,
> Institute of Control & Computation Engineering,
> Warsaw University of Technology

Orocos port to QNX

Dear Herman and Akhil,

thank you for your interest and response!

I think, that until somebody actually start to use Orocos@QNX the main (but
really good!) goal
is just testing platform independence... As I have mentioned - I have
already caught some minor
issues related to STL conformance with QNX's compiler, which is definitely
more restrictive
about this. (I have separated those fixes into individual commits, so they
can be easily picked
with Git).

QNX is the most POSIX-compatible system I know and does it since a long time
ago...
In fact - the only fixes required to port gnulinux files to QNX were about
Linux non-conformance to POSIX!

The reason that my lab is using QNX is in fact a bit about legacy. We have
started to play
with QNX4 several years ago. At that time there was no RT competition at
all. QNX allows
for RT between processes running in protected memory model - this has
strongly influenced
our software and now it is structured into processes instead of "components"
(i.e. shared libraries,
which execute inside one address space). QNX also allows for handing
interrupts in userspace
without any tricks, which is much more than most of the opensource like
RTAI/RTEMS can do...

The community support nor development tools for QNX are not as great as for
userspace gnulinux
port, but please do not forget, that CDT (C/C++ Development Tools) for
Eclipse is from QNX! There
also exist many other QNX tools specialized for RT development.

The bad side (and the reason why we are looking at the open-source
alternative) is device drivers
and third party software support, which is much behind Linux. There are
application, where RT is
not really required, but we want to use our software - i.e. a mobile
robotics. In such a application
please forget about QNX. You will have to spent most of your time looking
for supported WiFi and
framegrabber just to realize, that you still have to make OpenCV and QT
running at QNX...

I think the real pros of Orocos@QNX would be to run distributed components
in RT. This is possible
with QNX proprietary network protocol, QNET. OK, I doubt to what extend
there can be RT over Ethernet,
but QNX claims it is RT and certainly it is with more "RT" networks, i.e.
Profibus. The question however
is about Orocos and it's bindings to Corba. It is not easy to build working
ACE+TAO or OmniORB package,
and even then - I think they will not use QNET transport. If it would be
possible to distribute Orocos
just with Send/Receive/Reply concept - then we are home.

Piotr

On Mon, May 17, 2010 at 17:28, Madhani, Akhil J
<Akhil [dot] J [dot] Madhani [..] ...>wrote:

> We are now using Orocos/RTT as part of a development project here at
> Disney. While we are developing in Linux, platform independence is
> certainly a selling point to have Orocos be accepted by the larger Disney
> community.
>
> Without discussing the pros/cons of QNX, I will say it does tend to be one
> of the leading contenders in any discussion of commercial RTOS. It seems to
> me that a maintained port to QNX would certainly lend credibility (and
> testing) to the stated goal of platform independence.
>
> -Akhil
>
>
>
>
>
>
> Akhil J. Madhani, PhD
> Technical Staff - Director
> Walt Disney Imagineering R&D
> 1401 Flower St.
> Glendale, CA 91201
> Office: (818) 553-6839
> Cell: (818) 641-4481
> akhil [dot] j [dot] madhani [..] ...
>
>
> This electronic message transmission contains information which may be
> confidential or privileged. The information is intended to be for the use of
> the individual or entity named above. If you are not the intended recipient,
> please immediately notify the sender at (818) 553-6839 and delete this
> e-mail message from your computer. Be aware that any disclosure, copying,
> distribution or use of the contents of this information is prohibited.
> Thank you.
> -----Original Message-----
> From: orocos-dev-bounces [..] ... [mailto:
> orocos-dev-bounces [..] ...] On Behalf Of Herman Bruyninckx
> Sent: Sunday, May 16, 2010 11:34 PM
> To: Piotr Trojanek
> Cc: orocos-dev [..] ...
> Subject: Re: [Orocos-Dev] Orocos port to QNX
>
> On Sat, 15 May 2010, Piotr Trojanek wrote:
>
> > I am happy to announce an initial (but quite reasonable) port of the
> Orocos
> > to the QNX real-time OS, http://www.qnx.com/ has been comleted.
>
> Great! Probably it deserves a mention on the Orocos.org home page...
>
> > i have just pushed it to my GitHub repository,
> http://github.com/ptroja/orocos-rtt-qnx
> > - see branches rtt-1.0-svn-patches-qnx and rtt-2.0-mainline-qnx.
> >
> > While QNX is propertiary system, so you can find it a bit against the
> open-source
> > philosophy,
>
> It's not more "strange" than the efforts to make RTT run on Windows or MAC
> OS X :-)
>
> > I think that this port can be at least *interesting*.
> > Actually most of the QNX source code is now
> > open - legal fans can take a look at this site:
> http://www.qnx.com/news/pr_2471_1.html
> >
> > The exact build procedure is a bit tricky - you need to install a
> cross-development
> > headers
> > and libraries from my http://github.com/ptroja/qnx-cross/downloads.
> >
> > The current status is as follows:
> > * all RTT compiles cleanly, both for 1.x and 2.x branches,
> > * most of the tests programs fail (but not most of the test cases!) -
> which I guess is
> > not so bad,
> > * OCL needs some hand-help to compile, but the basic set of components
> (helloworld,
> > deployer,
> > timer, taskbrowser and reporter) seems to work properly.
> >
> > During the port I have discovered some minor STL issues, like missing
> headers or std::
> > namespace prefixes (QNX C++ compiler is more restrictive about this). I
> think those can
> > be safely applied to trunk (I could only check, that gnulinux target is
> happy with those
> > fixes).
> > Other changes are QNX specific, but they do not pollute Orocos source
> tree at all.
> >
> > The the final question is... Are there any interest in the community in
> sharing and
> > improving this port?
> > I think there is no point to have just another dead-port to maintain in
> the source tree
> > (I think there
> > was such a story of RTEMS port some time ago...). I think, that QNX is
> very interesting
> > platform
> > for Orocos, but there must be also interest of users to make it live and
> work :-)
>
> There is of course the other "final" question: what are the pros and cons
> of supporting QNX? Or other "less popular" OSs?
>
> I mean this as a serious question, to which I would welcome motivated
> arguments, since making Orocos platform-independent was an _objective_
> since day one...
>
> Phrasing the question a bit differently: what is realtime Linux missing wrt
> QNX, RTEMS, VxWorks...? There is at least one thing I can come up with:
> certification! But there are probably other arguments, or am I wrong...?
>
> For example, Piotr, what is your lab's motivation to go for QNX instead of
> Linux?
> Legacy? Support? Features?
>
> > Best regards,
> >
> > --
> > Piotr Trojanek
>
> Herman
>
> > Robot Control and Recognition Systems Team,
> > Institute of Control & Computation Engineering,
> > Warsaw University of Technology
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Orocos port to QNX

ptroja wrote:
Dear Herman and Akhil,

[ clip]
I think the real pros of Orocos@QNX would be to run distributed components
in RT. This is possible with QNX proprietary network protocol, QNET. OK, I doubt to what extend
there can be RT over Ethernet, but QNX claims it is RT

QNET has nothing to do with real-time communication.

Quote:

and certainly it is with more "RT" networks, i.e. Profibus.

PROFIBUS allows a bus cycle of 100us e.g. with a jitter of 5us ... can you do this with QNET ??
No, no ... PROFIBUS provides much more predictable real-time than QNET!

Regards

Armin Steinhoff

http://www.steinhoff-automation.com

Re: Orocos port to QNX

ptroja wrote:
Dear Herman and Akhil,

[ clip] I think the real pros of Orocos@QNX would be to run distributed components in RT. This is possible with QNX proprietary network protocol, QNET. OK, I doubt to what extend there can be RT over Ethernet, but QNX claims it is RT

QNET has nothing to do with real-time communication.

Quote:
 and certainly it is with more "RT" networks, i.e. Profibus.

PROFIBUS allows a bus cycle of 100us e.g. with a jitter of 5us ... can you do this with QNET ?? No, no ... PROFIBUS provides much more predictable real-time than QNET!

Regards

Armin Steinhoff

http://www.steinhoff-automation.com

Orocos port to QNX

Dear Armin,

I think I am missing something... QNET is layer for a distributed
inter-process messaging.
It does his job at a kernel level (in opposition to any TCP/IP based
protocol, i.e. real-time CORBA).
As a QNX rule - a server task priority is changed to the client's priority
when the request arrives.
No matter if the request arrive from local or remote client. So this allows
for managing priorities
of distributed tasks.

>From the other hand we know, that Ethernet introduces somehow unacceptable
jitter - so we
do not want to use Ethernet as a QNET's transport. But it is still possible
to use Profibus
or even a bare RS232 as a transport layer for QNET with help of devn-fd.so
driver:
http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/d/devn-fd.so...

My conclusion is, that combining QNET messaging with real-time data link
layer you can
get transparent, distributed messaging without loosing any of the real-time
capabilities you
have on local QNX machine.

Regards,

On Wed, Jun 9, 2010 at 16:05, <a-steinhoff [..] ...> wrote:

>

ptroja wrote:
Dear Herman and Akhil,
>
> [ clip]
> I think the real pros of Orocos@QNX would be to run distributed components
> in RT. This is possible with QNX proprietary network protocol, QNET. OK, I
> doubt to what extend
> there can be RT over Ethernet, but QNX claims it is RT
>

>
> QNET has nothing to do with real-time communication.
>
>
Quote:

> and certainly it is with more "RT" networks, i.e. Profibus.
>

>
> PROFIBUS allows a bus cycle of 100us e.g. with a jitter of 5us ... can you
> do this with QNET ??
> No, no ... PROFIBUS provides much more predictable real-time than QNET!
>
> Regards
>
> Armin Steinhoff
>
> http://www.steinhoff-automation.com
>
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Orocos port to QNX

On Tuesday 18 May 2010 00:17:07 Piotr Trojanek wrote:
...
>
> I think the real pros of Orocos@QNX would be to run distributed components
> in RT. This is possible
> with QNX proprietary network protocol, QNET. OK, I doubt to what extend
> there can be RT over Ethernet,
> but QNX claims it is RT and certainly it is with more "RT" networks, i.e.
> Profibus. The question however
> is about Orocos and it's bindings to Corba. It is not easy to build working
> ACE+TAO or OmniORB package,
> and even then - I think they will not use QNET transport. If it would be
> possible to distribute Orocos
> just with Send/Receive/Reply concept - then we are home.

We've been working on this on the 2.0 mainline. Look at the transports/mqueue
dir, which implements a *dataflow* transport between components. The transport
is configured using the RTT::ConnPolicy object, in which a user can specify how
a connection must be setup. mqueue for example uses the name_id to coordinate
the connection to mqueue file descriptors between processes. name_id can
contain any string format. There is no such equivalent for calling
methods/operations or reading/writing properties.

Corba is still best for 'coordinative' actions, ie, starting/stopping
components etc. If your embedded process just starts producing data from the
moment it is executed, you can probably get away with the data flow transport
way of working only. The upcomming ros transport for ros topics will also work
similar to how mqueue works today.

I know this is a very minimal description and that documentation is not up to
date yet. Working on it...

Peter

Orocos port to QNX

2010/5/19 Peter Soetens <peter [..] ...>

> On Tuesday 18 May 2010 00:17:07 Piotr Trojanek wrote:
> We've been working on this on the 2.0 mainline. Look at the
> transports/mqueue
> dir, which implements a *dataflow* transport between components. The
> transport
> is configured using the RTT::ConnPolicy object, in which a user can specify
> how
> a connection must be setup. mqueue for example uses the name_id to
> coordinate
> the connection to mqueue file descriptors between processes. name_id can
> contain any string format. There is no such equivalent for calling
> methods/operations or reading/writing properties.
>

The extremely neat feature of QNX is support for a distributed POSIX message
queues.
In QNX they are simply available as "/net/HOSTNAME/dev/mqueue/QUEUE_NAME".

As I understand - this makes DataPorts (at least conceptually) ready for
RT-distributing
components. Regarding data marshaling - I guess, that those distributed
message queues
allow for communication between cross-endian hardware, since QNX message
passing
is aware of it. So this is just issue of portable realtime
boost::serialization, but I have already
code for that, based on XDR format.

It still does not solve the methods/operations however...

Orocos port to QNX

On Tue, 18 May 2010, Piotr Trojanek wrote:

[...]
> I think the real pros of Orocos@QNX would be to run distributed
> components in RT. This is possible with QNX proprietary network protocol,
> QNET. OK, I doubt to what extend there can be RT over Ethernet, but QNX
> claims it is RT and certainly it is with more "RT" networks, i.e.
> Profibus. The question however is about Orocos and it's bindings to
> Corba. It is not easy to build working ACE+TAO or OmniORB package, and
> even then - I think they will not use QNET transport. If it would be
> possible to distribute Orocos just with Send/Receive/Reply concept - then
> we are home.

RTT _is_ already at this conceptual Send/Receive/Reply level! The CORBA
stuff is _optional_ and not at all needed.

Herman