<div dir="ltr"><div><div>Brian,<br><br></div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>see you at roscon :-)<br></div><div><br></div><div>cheers,<br></div><div>Ingo<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 29, 2015 at 9:59 PM Brian Gerkey via ros-users <<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 29, 2015 at 10:52 AM, Michael Haberler <<a href="mailto:mail17@mah.priv.at" target="_blank">mail17@mah.priv.at</a>> wrote:<br>
> *) 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.<br>
<br>
I agree completely!  Far too often people think that they need<br>
"real-time" when they don't (and sometimes don't even understand what<br>
it means).<br>
<br>
In any case, support for real-time-safe use of certain APIs is but one<br>
design goal for ROS 2.  And of course it's up to developer of the<br>
system to ensure that all the other requirements are met (real-time<br>
OS, appropriate use of scheduling priority, sufficient CPU for the<br>
workload, etc.).  We simply want to make sure that there's a way to<br>
use our libraries to comfortably modularize your code without<br>
sacrificing the *potential* to meet real-time requirements.  In other<br>
words, if you know how to build a real-time system, we won't get in<br>
your way.  That's a change from ROS (roscpp) today, which very much<br>
does get in your way.<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" rel="noreferrer" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote></div>