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
>
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
(text/plain)