Hi,
I'm interested in possibly using Orocos on QNX 6.5 and was wondering if anyone could give me any comments on how difficult that's likely to be or what problems I might encounter. I found ptroja's post "Orocos port to QNX" from 2010-05-15, and from the discussion in there it sounds as though some of those edits were pulled into the code for the gnulinux target.
So does anyone know if the gnulinux target works more or less unmodified on QNX? Or if there are any dependencies that are likely to be problematic? (Does CORBA work on QNX?) I don't have access to a QNX platform just yet so I haven't had a chance to try it.
Any insight would be appreciated.
Thanks,
Nick D'Amore
Orocos on QNX?
On Monday 07 February 2011 22:17:34 ndamore [..] ... wrote:
> Hi,
>
> I'm interested in possibly using Orocos on QNX 6.5 and was wondering if
> anyone could give me any comments on how difficult that's likely to be or
> what problems I might encounter. I found ptroja's post "Orocos port to
> QNX" from 2010-05-15, and from the discussion in there it sounds as though
> some of those edits were pulled into the code for the gnulinux target.
>
> So does anyone know if the gnulinux target works more or less unmodified on
> QNX? Or if there are any dependencies that are likely to be problematic?
> (Does CORBA work on QNX?) I don't have access to a QNX platform just yet
> so I haven't had a chance to try it.
>
> Any insight would be appreciated.
Hi Nick,
The QNX port was not merged because there was not a 'push' for it from its
maintainer (Piotr Trojanek) to include it in upstream. If more people start
using Orocos on QNX, it would be best to merge it in the mainline such that
they can share each other's improvements.
If you know some git, you could even try to merge his changes yourself with
the latest version of RTT. I certainly welcome ports to these platforms.
Since TAO is reported to work on QNX, Orocos should be able to use it as well.
I also vaguely recall that Piotr was working on other, more efficient transports
for the QNX platform as well.
Peter
Orocos on QNX?
Hi Nick,
I did not made a 'push' of my work, because we have discussed on the mailing
list,
that Orocos does not need another unsupported OS port. Actually I have done
this
work as a proof of concept rather than to run some real-world application.
I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
The job of getting Orocos to work with QNX is not hard. Probably my trivial
patches
solves (almost) all the issues. You will have more troubles with getting
dependencies
to work (Boost, Eigen, etc.). You can use my binary packages to speed up
this part.
The most problematic will be Corba. ACE+TAO states, that they do support
QNX,
but I had a lot of troubles while building it some time ago. PolyORB seemed
to compile
fine. There was some runtime exception while shutting-down PolyORB test
applications,
but I think were working fine until shutdown :-)
I believe, that making use of native QNX Send/Receive/Reply is the better
way to go,
when someone thinks seriously about distributed real-time Orocos controller
on QNX.
I guess that the concept of 'transport' in Orocos 2.x.x is easier to follow
this idea.
If you have any questions please fell free to contact me directly or post to
the mailing list.
Piotr,
On Thu, Feb 10, 2011 at 10:56, Peter Soetens <peter [..] ...>wrote:
> On Monday 07 February 2011 22:17:34 ndamore [..] ... wrote:
> > Hi,
> >
> > I'm interested in possibly using Orocos on QNX 6.5 and was wondering if
> > anyone could give me any comments on how difficult that's likely to be or
> > what problems I might encounter. I found ptroja's post "Orocos port to
> > QNX" from 2010-05-15, and from the discussion in there it sounds as
> though
> > some of those edits were pulled into the code for the gnulinux target.
> >
> > So does anyone know if the gnulinux target works more or less unmodified
> on
> > QNX? Or if there are any dependencies that are likely to be problematic?
> > (Does CORBA work on QNX?) I don't have access to a QNX platform just yet
> > so I haven't had a chance to try it.
> >
> > Any insight would be appreciated.
>
> Hi Nick,
>
> The QNX port was not merged because there was not a 'push' for it from its
> maintainer (Piotr Trojanek) to include it in upstream. If more people start
> using Orocos on QNX, it would be best to merge it in the mainline such that
> they can share each other's improvements.
>
> If you know some git, you could even try to merge his changes yourself with
> the latest version of RTT. I certainly welcome ports to these platforms.
>
> Since TAO is reported to work on QNX, Orocos should be able to use it as
> well.
> I also vaguely recall that Piotr was working on other, more efficient
> transports
> for the QNX platform as well.
>
> Peter
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Orocos on QNX?
Oh, need to correct this old post...
I was meaning problems with compiling omniORB on QNX - not PolyORB.
There are definitely too many ORB-s out there :-)
PolyORB is an Ada software. I am currently trying to build it and this work
is not too far
from being completed. Thanks to Felipe for spotting this mistake!
Piotr
On Thu, Feb 17, 2011 at 14:13, Piotr Trojanek <piotr [dot] trojanek [..] ...>wrote:
> Hi Nick,
>
> I did not made a 'push' of my work, because we have discussed on the
> mailing list,
> that Orocos does not need another unsupported OS port. Actually I have done
> this
> work as a proof of concept rather than to run some real-world application.
>
> I also have not played with Orocos Toolchain and did not focus on
> RTT-2.x.x.
>
> The job of getting Orocos to work with QNX is not hard. Probably my trivial
> patches
> solves (almost) all the issues. You will have more troubles with getting
> dependencies
> to work (Boost, Eigen, etc.). You can use my binary packages to speed up
> this part.
>
> The most problematic will be Corba. ACE+TAO states, that they do support
> QNX,
> but I had a lot of troubles while building it some time ago. PolyORB seemed
> to compile
> fine. There was some runtime exception while shutting-down PolyORB test
> applications,
> but I think were working fine until shutdown :-)
>
> I believe, that making use of native QNX Send/Receive/Reply is the better
> way to go,
> when someone thinks seriously about distributed real-time Orocos controller
> on QNX.
> I guess that the concept of 'transport' in Orocos 2.x.x is easier to follow
> this idea.
>
> If you have any questions please fell free to contact me directly or post
> to the mailing list.
>
> Piotr,
>
>
> On Thu, Feb 10, 2011 at 10:56, Peter Soetens <peter [..] ...>wrote:
>
>> On Monday 07 February 2011 22:17:34 ndamore [..] ... wrote:
>> > Hi,
>> >
>> > I'm interested in possibly using Orocos on QNX 6.5 and was wondering if
>> > anyone could give me any comments on how difficult that's likely to be
>> or
>> > what problems I might encounter. I found ptroja's post "Orocos port to
>> > QNX" from 2010-05-15, and from the discussion in there it sounds as
>> though
>> > some of those edits were pulled into the code for the gnulinux target.
>> >
>> > So does anyone know if the gnulinux target works more or less unmodified
>> on
>> > QNX? Or if there are any dependencies that are likely to be
>> problematic?
>> > (Does CORBA work on QNX?) I don't have access to a QNX platform just
>> yet
>> > so I haven't had a chance to try it.
>> >
>> > Any insight would be appreciated.
>>
>> Hi Nick,
>>
>> The QNX port was not merged because there was not a 'push' for it from its
>> maintainer (Piotr Trojanek) to include it in upstream. If more people
>> start
>> using Orocos on QNX, it would be best to merge it in the mainline such
>> that
>> they can share each other's improvements.
>>
>> If you know some git, you could even try to merge his changes yourself
>> with
>> the latest version of RTT. I certainly welcome ports to these platforms.
>>
>> Since TAO is reported to work on QNX, Orocos should be able to use it as
>> well.
>> I also vaguely recall that Piotr was working on other, more efficient
>> transports
>> for the QNX platform as well.
>>
>> Peter
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>
>
>
> --
> Piotr Trojanek
>
Orocos on QNX?
On Thu, 17 Feb 2011, Piotr Trojanek wrote:
> Hi Nick,
>
> I did not made a 'push' of my work, because we have discussed on the mailing list,
> that Orocos does not need another unsupported OS port. Actually I have done this
> work as a proof of concept rather than to run some real-world application.
>
> I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
>
> The job of getting Orocos to work with QNX is not hard. Probably my trivial patches
> solves (almost) all the issues. You will have more troubles with getting dependencies
> to work (Boost, Eigen, etc.). You can use my binary packages to speed up this part.
>
> The most problematic will be Corba. ACE+TAO states, that they do support QNX,
And I hope they never will! :-)
CORBA has not been able to prove that it is 'incontournable' in the domain
of middlewares, so I think we should try to get rid of it as completely as
possible. Just too many differences in implementations of a too large
standard. Lots of very good ideas though...
> but I had a lot of troubles while building it some time ago. PolyORB
> seemed to compile fine. There was some runtime exception while
> shutting-down PolyORB test applications, but I think were working fine
> until shutdown :-)
>
> I believe, that making use of native QNX Send/Receive/Reply is the better
> way to go, when someone thinks seriously about distributed real-time
> Orocos controller on QNX.
I absolutely agree.
> I guess that the concept of 'transport' in Orocos 2.x.x is easier to
> follow this idea.
>
> If you have any questions please fell free to contact me directly or post to the mailing list.
>
> Piotr,
Herman
>peter [..] ...>> wrote:
> On Thu, Feb 10, 2011 at 10:56, Peter Soetens <peter [..] ...
> On Monday 07 February 2011 22:17:34 ndamore [..] ...<mailto:ndamore [..] ...> wrote:
>> Hi,
>>
>> I'm interested in possibly using Orocos on QNX 6.5 and was wondering if
>> anyone could give me any comments on how difficult that's likely to be or
>> what problems I might encounter. I found ptroja's post "Orocos port to
>> QNX" from 2010-05-15, and from the discussion in there it sounds as though
>> some of those edits were pulled into the code for the gnulinux target.
>>
>> So does anyone know if the gnulinux target works more or less unmodified on
>> QNX? Or if there are any dependencies that are likely to be problematic?
>> (Does CORBA work on QNX?) I don't have access to a QNX platform just yet
>> so I haven't had a chance to try it.
>>
>> Any insight would be appreciated.
>
> Hi Nick,
>
> The QNX port was not merged because there was not a 'push' for it from its
> maintainer (Piotr Trojanek) to include it in upstream. If more people start
> using Orocos on QNX, it would be best to merge it in the mainline such that
> they can share each other's improvements.
>
> If you know some git, you could even try to merge his changes yourself with
> the latest version of RTT. I certainly welcome ports to these platforms.
>
> Since TAO is reported to work on QNX, Orocos should be able to use it as well.
> I also vaguely recall that Piotr was working on other, more efficient transports
> for the QNX platform as well.
>
> Peter
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
> --
> Piotr Trojanek
>
Orocos on QNX?
On Feb 17, 2011, at 11:38 , Herman Bruyninckx wrote:
> On Thu, 17 Feb 2011, Piotr Trojanek wrote:
>
>> Hi Nick,
>>
>> I did not made a 'push' of my work, because we have discussed on the mailing list,
>> that Orocos does not need another unsupported OS port. Actually I have done this
>> work as a proof of concept rather than to run some real-world application.
>>
>> I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
>>
>> The job of getting Orocos to work with QNX is not hard. Probably my trivial patches
>> solves (almost) all the issues. You will have more troubles with getting dependencies
>> to work (Boost, Eigen, etc.). You can use my binary packages to speed up this part.
>>
>> The most problematic will be Corba. ACE+TAO states, that they do support QNX,
>
> And I hope they never will! :-)
>
> CORBA has not been able to prove that it is 'incontournable' in the domain
> of middlewares, so I think we should try to get rid of it as completely as
> possible. Just too many differences in implementations of a too large
> standard. Lots of very good ideas though...
I completely disagree. Again Herman, you are making huge statements that have enormous impact to the community as a whole. CORBA is a reliable working solution for many of us. Removing it from Orocos makes it less attractive a solution, leading to less people choosing to use it. And That Hurts Everyone Of Us In The Orocos Community.
It isn't broken, so please don't go fixing it!!!
S
CORBA and Orocos (Was: Orocos on QNX?)
On Fri, 18 Feb 2011, S Roderick wrote:
> On Feb 17, 2011, at 11:38 , Herman Bruyninckx wrote:
>
>> On Thu, 17 Feb 2011, Piotr Trojanek wrote:
>>
>>> Hi Nick,
>>>
>>> I did not made a 'push' of my work, because we have discussed on the mailing list,
>>> that Orocos does not need another unsupported OS port. Actually I have done this
>>> work as a proof of concept rather than to run some real-world application.
>>>
>>> I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
>>>
>>> The job of getting Orocos to work with QNX is not hard. Probably my trivial patches
>>> solves (almost) all the issues. You will have more troubles with getting dependencies
>>> to work (Boost, Eigen, etc.). You can use my binary packages to speed up this part.
>>>
>>> The most problematic will be Corba. ACE+TAO states, that they do support QNX,
>>
>> And I hope they never will! :-)
>>
>> CORBA has not been able to prove that it is 'incontournable' in the domain
>> of middlewares, so I think we should try to get rid of it as completely as
>> possible. Just too many differences in implementations of a too large
>> standard. Lots of very good ideas though...
>
> I completely disagree. Again Herman, you are making huge statements that
> have enormous impact to the community as a whole. CORBA is a reliable
> working solution for many of us. Removing it from Orocos makes it less
> attractive a solution, leading to less people choosing to use it. And
> That Hurts Everyone Of Us In The Orocos Community.
Again, you are grossly re-interpreting my statements :-) I have said
thousands of time that (i) CORBA should be _just one_ of the Communication
middlewares available, (ii) it does not deserve to be so prominently
visible in Orocos, (iii) interoperability with _all_ middlewares is a
major design focus of Orocos. Hence, if you rely on CORBA, you will be
served as well as before the suggested "removal", since "removal" means to
put decent (no, perfect!) _bridges_ into RTT, and a decent documentation,
examples, code, ... in a "CORBA tools" sub-project or so.
> It isn't broken, so please don't go fixing it!!!
This is the most huge "legacy" statement of them all :-) I understand what
you mean, and I am all for keeping the good interoperability between Orocos
and CORBA, but not, I repeat, not, with CORBA being such a (preceptionally)
"preferential middleware partner" as it is now. That's all against the
principle of separation of concern.
And, BTW, I know _many_ more potential users that are really scared away by
seeing the name "CORBA" coming up in build parameters, documentation,
messagea etc, as proven by the tons of emails on orocos-users about people
having serious problems with thinking they have to build CORBA before they
can use Orocos. Our major "interoperability customers" now, by the way, is
the ROS community, that Ruben is being serving rather well lately, and
CORBA is definitely loosing ground, rapidly. In this context, do you know
of newly convinced CORBA users? I would be very happy to learn about that.
Let this be an invitation to such CORBA users on this mailing list to
speak up, and support Stephen :-)
Anyway, sincere thanks for bringing up the "legacy voice" in this thread;
it's needed! But I must play the "5C" separation of concerns voice here,
because that's where the long-term future of Orocos lies, as a niche
project that is just the best there is in that niche and can play well with
the other guys, without discriminating any of them :-) CORBA will be one of
the other guys, ROS too, and hopefully many more, so that the perception to
the outside world will, naturally, become less CORBA-centric.
> S
Herman
CORBA and Orocos (Was: Orocos on QNX?)
On Fri, Feb 18, 2011 at 7:49 AM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Fri, 18 Feb 2011, S Roderick wrote:
>
>> On Feb 17, 2011, at 11:38 , Herman Bruyninckx wrote:
>>
>>> On Thu, 17 Feb 2011, Piotr Trojanek wrote:
>>>
>>>> Hi Nick,
>>>>
>>>> I did not made a 'push' of my work, because we have discussed on the mailing list,
>>>> that Orocos does not need another unsupported OS port. Actually I have done this
>>>> work as a proof of concept rather than to run some real-world application.
>>>>
>>>> I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
>>>>
>>>> The job of getting Orocos to work with QNX is not hard. Probably my trivial patches
>>>> solves (almost) all the issues. You will have more troubles with getting dependencies
>>>> to work (Boost, Eigen, etc.). You can use my binary packages to speed up this part.
>>>>
>>>> The most problematic will be Corba. ACE+TAO states, that they do support QNX,
>>>
>>> And I hope they never will! :-)
>>>
>>> CORBA has not been able to prove that it is 'incontournable' in the domain
>>> of middlewares, so I think we should try to get rid of it as completely as
>>> possible. Just too many differences in implementations of a too large
>>> standard. Lots of very good ideas though...
>>
>> I completely disagree. Again Herman, you are making huge statements that
>> have enormous impact to the community as a whole. CORBA is a reliable
>> working solution for many of us. Removing it from Orocos makes it less
>> attractive a solution, leading to less people choosing to use it. And
>> That Hurts Everyone Of Us In The Orocos Community.
>
> Again, you are grossly re-interpreting my statements :-) I have said
> thousands of time that (i) CORBA should be _just one_ of the Communication
> middlewares available, (ii) it does not deserve to be so prominently
> visible in Orocos, (iii) interoperability with _all_ middlewares is a
> major design focus of Orocos. Hence, if you rely on CORBA, you will be
> served as well as before the suggested "removal", since "removal" means to
> put decent (no, perfect!) _bridges_ into RTT, and a decent documentation,
> examples, code, ... in a "CORBA tools" sub-project or so.
>
>> It isn't broken, so please don't go fixing it!!!
>
> This is the most huge "legacy" statement of them all :-) I understand what
> you mean, and I am all for keeping the good interoperability between Orocos
> and CORBA, but not, I repeat, not, with CORBA being such a (preceptionally)
> "preferential middleware partner" as it is now. That's all against the
> principle of separation of concern.
>
> And, BTW, I know _many_ more potential users that are really scared away by
> seeing the name "CORBA" coming up in build parameters, documentation,
> messagea etc, as proven by the tons of emails on orocos-users about people
> having serious problems with thinking they have to build CORBA before they
> can use Orocos. Our major "interoperability customers" now, by the way, is
> the ROS community, that Ruben is being serving rather well lately, and
> CORBA is definitely loosing ground, rapidly. In this context, do you know
> of newly convinced CORBA users? I would be very happy to learn about that.
> Let this be an invitation to such CORBA users on this mailing list to
> speak up, and support Stephen :-)
>
> Anyway, sincere thanks for bringing up the "legacy voice" in this thread;
> it's needed! But I must play the "5C" separation of concerns voice here,
> because that's where the long-term future of Orocos lies, as a niche
> project that is just the best there is in that niche and can play well with
> the other guys, without discriminating any of them :-) CORBA will be one of
> the other guys, ROS too, and hopefully many more, so that the perception to
> the outside world will, naturally, become less CORBA-centric.
>
My vision is that CORBA stays as-is, but I wouldn't mind organizing
all transports in a separate package tree (as Herman proposes)
to clearly state to new users that CORBA is opt-in. Such a migration would
cost us some time we can hardly afford, so It's not a high priority do
do that right-now.
We should be more careful nowadays with how we profile ourselves,
about which problems we solve and how. The how is very important
to 'engineers' and the poor CORBA implementations that are around
did not give it a good reputation. The ros-runs-out-of-the-box solution is
how it should be, and that's something we should learn from as a
community and offer the same experience to all of us that need
real-time, supervision, and a flexible and interoperable robotics framework.
It should be Joy, not Pain.
>> S
>
> Herman
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
CORBA and Orocos (Was: Orocos on QNX?)
On Fri, 18 Feb 2011, Peter Soetens wrote:
> On Fri, Feb 18, 2011 at 7:49 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Fri, 18 Feb 2011, S Roderick wrote:
>>
>>> On Feb 17, 2011, at 11:38 , Herman Bruyninckx wrote:
>>>
>>>> On Thu, 17 Feb 2011, Piotr Trojanek wrote:
>>>>
>>>>> Hi Nick,
>>>>>
>>>>> I did not made a 'push' of my work, because we have discussed on the mailing list,
>>>>> that Orocos does not need another unsupported OS port. Actually I have done this
>>>>> work as a proof of concept rather than to run some real-world application.
>>>>>
>>>>> I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
>>>>>
>>>>> The job of getting Orocos to work with QNX is not hard. Probably my trivial patches
>>>>> solves (almost) all the issues. You will have more troubles with getting dependencies
>>>>> to work (Boost, Eigen, etc.). You can use my binary packages to speed up this part.
>>>>>
>>>>> The most problematic will be Corba. ACE+TAO states, that they do support QNX,
>>>>
>>>> And I hope they never will! :-)
>>>>
>>>> CORBA has not been able to prove that it is 'incontournable' in the domain
>>>> of middlewares, so I think we should try to get rid of it as completely as
>>>> possible. Just too many differences in implementations of a too large
>>>> standard. Lots of very good ideas though...
>>>
>>> I completely disagree. Again Herman, you are making huge statements that
>>> have enormous impact to the community as a whole. CORBA is a reliable
>>> working solution for many of us. Removing it from Orocos makes it less
>>> attractive a solution, leading to less people choosing to use it. And
>>> That Hurts Everyone Of Us In The Orocos Community.
>>
>> Again, you are grossly re-interpreting my statements :-) I have said
>> thousands of time that (i) CORBA should be _just one_ of the Communication
>> middlewares available, (ii) it does not deserve to be so prominently
>> visible in Orocos, (iii) interoperability with _all_ middlewares is a
>> major design focus of Orocos. Hence, if you rely on CORBA, you will be
>> served as well as before the suggested "removal", since "removal" means to
>> put decent (no, perfect!) _bridges_ into RTT, and a decent documentation,
>> examples, code, ... in a "CORBA tools" sub-project or so.
>>
>>> It isn't broken, so please don't go fixing it!!!
>>
>> This is the most huge "legacy" statement of them all :-) I understand what
>> you mean, and I am all for keeping the good interoperability between Orocos
>> and CORBA, but not, I repeat, not, with CORBA being such a (preceptionally)
>> "preferential middleware partner" as it is now. That's all against the
>> principle of separation of concern.
>>
>> And, BTW, I know _many_ more potential users that are really scared away by
>> seeing the name "CORBA" coming up in build parameters, documentation,
>> messagea etc, as proven by the tons of emails on orocos-users about people
>> having serious problems with thinking they have to build CORBA before they
>> can use Orocos. Our major "interoperability customers" now, by the way, is
>> the ROS community, that Ruben is being serving rather well lately, and
>> CORBA is definitely loosing ground, rapidly. In this context, do you know
>> of newly convinced CORBA users? I would be very happy to learn about that.
>> Let this be an invitation to such CORBA users on this mailing list to
>> speak up, and support Stephen :-)
>>
>> Anyway, sincere thanks for bringing up the "legacy voice" in this thread;
>> it's needed! But I must play the "5C" separation of concerns voice here,
>> because that's where the long-term future of Orocos lies, as a niche
>> project that is just the best there is in that niche and can play well with
>> the other guys, without discriminating any of them :-) CORBA will be one of
>> the other guys, ROS too, and hopefully many more, so that the perception to
>> the outside world will, naturally, become less CORBA-centric.
>
> My vision is that CORBA stays as-is, but I wouldn't mind organizing
> all transports in a separate package tree (as Herman proposes)
> to clearly state to new users that CORBA is opt-in. Such a migration would
> cost us some time we can hardly afford, so It's not a high priority do
> do that right-now.
I agree. (With both of your statements: (i) all Communication integration
is opt-in, (ii) not the highest priority.)
> We should be more careful nowadays with how we profile ourselves,
> about which problems we solve and how. The how is very important
> to 'engineers' and the poor CORBA implementations that are around
> did not give it a good reputation. The ros-runs-out-of-the-box solution is
> how it should be, and that's something we should learn from as a
> community and offer the same experience to all of us that need
> real-time, supervision, and a flexible and interoperable robotics framework.
>
> It should be Joy, not Pain.
>
>>> S
>>
>> Herman
>
> Peter
Herman
CORBA and Orocos (Was: Orocos on QNX?)
On Feb 19, 2011, at 04:38 , Herman Bruyninckx wrote:
> On Fri, 18 Feb 2011, Peter Soetens wrote:
>
>> On Fri, Feb 18, 2011 at 7:49 AM, Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...> wrote:
>>> On Fri, 18 Feb 2011, S Roderick wrote:
>>>
>>>> On Feb 17, 2011, at 11:38 , Herman Bruyninckx wrote:
>>>>
>>>>> On Thu, 17 Feb 2011, Piotr Trojanek wrote:
>>>>>
>>>>>> Hi Nick,
>>>>>>
>>>>>> I did not made a 'push' of my work, because we have discussed on the mailing list,
>>>>>> that Orocos does not need another unsupported OS port. Actually I have done this
>>>>>> work as a proof of concept rather than to run some real-world application.
>>>>>>
>>>>>> I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
>>>>>>
>>>>>> The job of getting Orocos to work with QNX is not hard. Probably my trivial patches
>>>>>> solves (almost) all the issues. You will have more troubles with getting dependencies
>>>>>> to work (Boost, Eigen, etc.). You can use my binary packages to speed up this part.
>>>>>>
>>>>>> The most problematic will be Corba. ACE+TAO states, that they do support QNX,
>>>>>
>>>>> And I hope they never will! :-)
>>>>>
>>>>> CORBA has not been able to prove that it is 'incontournable' in the domain
>>>>> of middlewares, so I think we should try to get rid of it as completely as
>>>>> possible. Just too many differences in implementations of a too large
>>>>> standard. Lots of very good ideas though...
>>>>
>>>> I completely disagree. Again Herman, you are making huge statements that
>>>> have enormous impact to the community as a whole. CORBA is a reliable
>>>> working solution for many of us. Removing it from Orocos makes it less
>>>> attractive a solution, leading to less people choosing to use it. And
>>>> That Hurts Everyone Of Us In The Orocos Community.
>>>
>>> Again, you are grossly re-interpreting my statements :-) I have said
>>> thousands of time that (i) CORBA should be _just one_ of the Communication
>>> middlewares available, (ii) it does not deserve to be so prominently
>>> visible in Orocos, (iii) interoperability with _all_ middlewares is a
>>> major design focus of Orocos. Hence, if you rely on CORBA, you will be
>>> served as well as before the suggested "removal", since "removal" means to
>>> put decent (no, perfect!) _bridges_ into RTT, and a decent documentation,
>>> examples, code, ... in a "CORBA tools" sub-project or so.
>>>
>>>> It isn't broken, so please don't go fixing it!!!
>>>
>>> This is the most huge "legacy" statement of them all :-) I understand what
>>> you mean, and I am all for keeping the good interoperability between Orocos
>>> and CORBA, but not, I repeat, not, with CORBA being such a (preceptionally)
>>> "preferential middleware partner" as it is now. That's all against the
>>> principle of separation of concern.
>>>
>>> And, BTW, I know _many_ more potential users that are really scared away by
>>> seeing the name "CORBA" coming up in build parameters, documentation,
>>> messagea etc, as proven by the tons of emails on orocos-users about people
>>> having serious problems with thinking they have to build CORBA before they
>>> can use Orocos. Our major "interoperability customers" now, by the way, is
>>> the ROS community, that Ruben is being serving rather well lately, and
>>> CORBA is definitely loosing ground, rapidly. In this context, do you know
>>> of newly convinced CORBA users? I would be very happy to learn about that.
>>> Let this be an invitation to such CORBA users on this mailing list to
>>> speak up, and support Stephen :-)
>>>
>>> Anyway, sincere thanks for bringing up the "legacy voice" in this thread;
>>> it's needed! But I must play the "5C" separation of concerns voice here,
>>> because that's where the long-term future of Orocos lies, as a niche
>>> project that is just the best there is in that niche and can play well with
>>> the other guys, without discriminating any of them :-) CORBA will be one of
>>> the other guys, ROS too, and hopefully many more, so that the perception to
>>> the outside world will, naturally, become less CORBA-centric.
>>
>> My vision is that CORBA stays as-is, but I wouldn't mind organizing
>> all transports in a separate package tree (as Herman proposes)
>> to clearly state to new users that CORBA is opt-in. Such a migration would
>> cost us some time we can hardly afford, so It's not a high priority do
>> do that right-now.
>
> I agree. (With both of your statements: (i) all Communication integration
> is opt-in, (ii) not the highest priority.)
Glad to hear that that misunderstanding has been sorted out.
>> We should be more careful nowadays with how we profile ourselves,
>> about which problems we solve and how. The how is very important
>> to 'engineers' and the poor CORBA implementations that are around
>> did not give it a good reputation. The ros-runs-out-of-the-box solution is
>> how it should be, and that's something we should learn from as a
>> community and offer the same experience to all of us that need
>> real-time, supervision, and a flexible and interoperable robotics framework.
>>
>> It should be Joy, not Pain.
Agreed
S
CORBA and Orocos (Was: Orocos on QNX?)
On Mon, 21 Feb 2011, Stephen Roderick wrote:
> On Feb 19, 2011, at 04:38 , Herman Bruyninckx wrote:
>
>> On Fri, 18 Feb 2011, Peter Soetens wrote:
>>
>>> On Fri, Feb 18, 2011 at 7:49 AM, Herman Bruyninckx
>>> <Herman [dot] Bruyninckx [..] ...> wrote:
>>>> On Fri, 18 Feb 2011, S Roderick wrote:
>>>>
>>>>> On Feb 17, 2011, at 11:38 , Herman Bruyninckx wrote:
>>>>>
>>>>>> On Thu, 17 Feb 2011, Piotr Trojanek wrote:
>>>>>>
>>>>>>> Hi Nick,
>>>>>>>
>>>>>>> I did not made a 'push' of my work, because we have discussed on the mailing list,
>>>>>>> that Orocos does not need another unsupported OS port. Actually I have done this
>>>>>>> work as a proof of concept rather than to run some real-world application.
>>>>>>>
>>>>>>> I also have not played with Orocos Toolchain and did not focus on RTT-2.x.x.
>>>>>>>
>>>>>>> The job of getting Orocos to work with QNX is not hard. Probably my trivial patches
>>>>>>> solves (almost) all the issues. You will have more troubles with getting dependencies
>>>>>>> to work (Boost, Eigen, etc.). You can use my binary packages to speed up this part.
>>>>>>>
>>>>>>> The most problematic will be Corba. ACE+TAO states, that they do support QNX,
>>>>>>
>>>>>> And I hope they never will! :-)
>>>>>>
>>>>>> CORBA has not been able to prove that it is 'incontournable' in the domain
>>>>>> of middlewares, so I think we should try to get rid of it as completely as
>>>>>> possible. Just too many differences in implementations of a too large
>>>>>> standard. Lots of very good ideas though...
>>>>>
>>>>> I completely disagree. Again Herman, you are making huge statements that
>>>>> have enormous impact to the community as a whole. CORBA is a reliable
>>>>> working solution for many of us. Removing it from Orocos makes it less
>>>>> attractive a solution, leading to less people choosing to use it. And
>>>>> That Hurts Everyone Of Us In The Orocos Community.
>>>>
>>>> Again, you are grossly re-interpreting my statements :-) I have said
>>>> thousands of time that (i) CORBA should be _just one_ of the Communication
>>>> middlewares available, (ii) it does not deserve to be so prominently
>>>> visible in Orocos, (iii) interoperability with _all_ middlewares is a
>>>> major design focus of Orocos. Hence, if you rely on CORBA, you will be
>>>> served as well as before the suggested "removal", since "removal" means to
>>>> put decent (no, perfect!) _bridges_ into RTT, and a decent documentation,
>>>> examples, code, ... in a "CORBA tools" sub-project or so.
>>>>
>>>>> It isn't broken, so please don't go fixing it!!!
>>>>
>>>> This is the most huge "legacy" statement of them all :-) I understand what
>>>> you mean, and I am all for keeping the good interoperability between Orocos
>>>> and CORBA, but not, I repeat, not, with CORBA being such a (preceptionally)
>>>> "preferential middleware partner" as it is now. That's all against the
>>>> principle of separation of concern.
>>>>
>>>> And, BTW, I know _many_ more potential users that are really scared away by
>>>> seeing the name "CORBA" coming up in build parameters, documentation,
>>>> messagea etc, as proven by the tons of emails on orocos-users about people
>>>> having serious problems with thinking they have to build CORBA before they
>>>> can use Orocos. Our major "interoperability customers" now, by the way, is
>>>> the ROS community, that Ruben is being serving rather well lately, and
>>>> CORBA is definitely loosing ground, rapidly. In this context, do you know
>>>> of newly convinced CORBA users? I would be very happy to learn about that.
>>>> Let this be an invitation to such CORBA users on this mailing list to
>>>> speak up, and support Stephen :-)
>>>>
>>>> Anyway, sincere thanks for bringing up the "legacy voice" in this thread;
>>>> it's needed! But I must play the "5C" separation of concerns voice here,
>>>> because that's where the long-term future of Orocos lies, as a niche
>>>> project that is just the best there is in that niche and can play well with
>>>> the other guys, without discriminating any of them :-) CORBA will be one of
>>>> the other guys, ROS too, and hopefully many more, so that the perception to
>>>> the outside world will, naturally, become less CORBA-centric.
>>>
>>> My vision is that CORBA stays as-is, but I wouldn't mind organizing
>>> all transports in a separate package tree (as Herman proposes)
>>> to clearly state to new users that CORBA is opt-in. Such a migration would
>>> cost us some time we can hardly afford, so It's not a high priority do
>>> do that right-now.
>>
>> I agree. (With both of your statements: (i) all Communication integration
>> is opt-in, (ii) not the highest priority.)
>
> Glad to hear that that misunderstanding has been sorted out.
It's _good_ to have this kind of "hey, do we still think along the same
lines?!?!" kind of threads! :-) It's the signature of a living project!
>>> We should be more careful nowadays with how we profile ourselves,
>>> about which problems we solve and how. The how is very important
>>> to 'engineers' and the poor CORBA implementations that are around
>>> did not give it a good reputation. The ros-runs-out-of-the-box solution is
>>> how it should be, and that's something we should learn from as a
>>> community and offer the same experience to all of us that need
>>> real-time, supervision, and a flexible and interoperable robotics framework.
>>>
>>> It should be Joy, not Pain.
>
> Agreed
> S
Herman