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 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 >> 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 >