I also vote my support.

I've read Brook's book (iconic but very outdated) and I don't see how using DDS contributes to the second system effect. I would think using an existing middleware is much more economical then a DIY middleware. Getting QoS for free ain't a bad thing.

Assuming the licensing is right. I'm not a lawyer, so I have no idea.

On Tue, Sep 29, 2015 at 4:14 PM Ingo Lütkebohle <ros-users@lists.ros.org> wrote:
Brian,

just as a quick, private note of support for OSRF's current course: I think you're absolutely on the right path with DDS and RTPS, despite also having reservations about some of the underlying tech, but nothing major.

Regarding the patents on DDS, maybe Bosch can have some lawyers look at that. No promises, but I think that might be something we (meaning Arne und me) could sell management.

Moreover, maybe the guy Bosch is going to fund could also look at easing the migration path from ROS1 to ROS2. That is something which would be dear to me, and where I think we can help a lot of people.

see you at roscon :-)

cheers,
Ingo


On Tue, Sep 29, 2015 at 9:59 PM Brian Gerkey via ros-users <ros-users@lists.ros.org> wrote:
On Tue, Sep 29, 2015 at 10:52 AM, Michael Haberler <mail17@mah.priv.at> wrote:
> *) it is my experience from the the precursor of the machinekit project, and I hear the same story from commercial users of realtime stacks: time and again way too much code is done in hard realtime environments - usually for a lack of understanding of the actual requirements, "playing it safe" and erring on the costly side, and sometimes it comes down to very human factors like job security.

I agree completely!  Far too often people think that they need
"real-time" when they don't (and sometimes don't even understand what
it means).

In any case, support for real-time-safe use of certain APIs is but one
design goal for ROS 2.  And of course it's up to developer of the
system to ensure that all the other requirements are met (real-time
OS, appropriate use of scheduling priority, sufficient CPU for the
workload, etc.).  We simply want to make sure that there's a way to
use our libraries to comfortably modularize your code without
sacrificing the *potential* to meet real-time requirements.  In other
words, if you know how to build a real-time system, we won't get in
your way.  That's a change from ROS (roscpp) today, which very much
does get in your way.
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users