Mark Pitchless | 21 Sep 16:53 2014
Picon

ROS Vagrant base boxes

Hello All,

I'm very pleased to announce a set of vagrant virtual box base boxes, we have been working on at shadow robot, are now available on the cloud for public consumption.

https://vagrantcloud.com/shadowrobot

You need vagrant 1.5+ to use these. On trusty bring up a new ros machine like so:

apt-get install vagrant
mkdir indigovm
cd indigovm
vagrant init shadowrobot/ros-indigo-desktop-trusty64
vagrant up

After a bit a logged in desktop will appear, just open a terminal, roscore and away you go.

Currently we have Hydro and Indigo machines in 32bit and 64bit variants.

These are built using vagrant and ansible as part of our build tools project (more on this next week).
https://github.com/shadow-robot/sr-build-tools/blob/master/vagrant/ros-base/README.md
Feel free to log issues, ideas there or post here.

Collaboration welcome especially creating bases for other providers.

Have fun,
Mark Pitchless
--
www.shadowrobot.com


<div>
<p dir="ltr">Hello All,</p>
<p dir="ltr">I'm very pleased to announce a set of vagrant virtual box base boxes, we have been working on at shadow robot, are now available on the cloud for public consumption.</p>
<p dir="ltr"><a href="https://vagrantcloud.com/shadowrobot">https://vagrantcloud.com/shadowrobot</a></p>
<p dir="ltr">You need vagrant 1.5+ to use these. On trusty bring up a new ros machine like so:</p>
<p dir="ltr">apt-get install vagrant<br>
mkdir indigovm<br>
cd indigovm<br>
vagrant init shadowrobot/ros-indigo-desktop-trusty64<br>
vagrant up</p>
<p dir="ltr">After a bit a logged in desktop will appear, just open a terminal, roscore and away you go.</p>
<p dir="ltr">Currently we have Hydro and Indigo machines in 32bit and 64bit variants.</p>
<p dir="ltr">These are built using vagrant and ansible as part of our build tools project (more on this next week).<br><a href="https://github.com/shadow-robot/sr-build-tools/blob/master/vagrant/ros-base/README.md">https://github.com/shadow-robot/sr-build-tools/blob/master/vagrant/ros-base/README.md</a><br>
Feel free to log issues, ideas there or post here.</p>
<p dir="ltr">Collaboration welcome especially creating bases for other providers.</p>
<p dir="ltr">Have fun,<br>
Mark Pitchless<br>
--<br><a href="http://www.shadowrobot.com">www.shadowrobot.com</a><br><br><br></p>
</div>
Hai Nguyen | 19 Sep 00:02 2014
Picon

Re: [ros-sig-ng-ros] ROS and Web Clients

You are right that it's usually more ideal to have just one web socket connection rather than a connection for each topic. I was accepting it as an unfortunate downside of talking to ROS nodes, but now that you've raised the point, it seems to be more serious of a downside than I thought. Specifically, it'd be difficult to do things like implement access control for each topic, which is particularly vital for being on the web.

After looking into this a little more, however, it looks like whichever DDS system is used, if there is support for some sort of shared memory communication then having a bridge shouldn't be a big performance hit anyway, especially if the marshaling format ends up being JSON.

Since it's all contingent on shared memory access, is OSRF leaning towards a particular implementation of DDS that has this feature?

I do agree with Chad though. It's rather bold to assume that most of the best feedback for ROS 2.0 will be from people that are interested enough to join yet another mailing list, especially since this one is so relevant. From the earliest days, ROS's design has been informed and improved by constant interactions with roboticists. For the benefit of ROS 2.0, I think this process should continue since there is a very real possibility that bad design decisions will result in developers just continuing to use ROS 1.x or even worse, not updating their libraries to support it.

On Tue, Sep 16, 2014 at 5:13 PM, William Woodall <william-GsQoM64suCGGJGYlWa3Ukdi2O/JbrIOy@public.gmane.org> wrote:
On Tue, Sep 16, 2014 at 3:17 PM, Hai Nguyen <haidai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I am not a WebSocket expert but from my understanding, HTTP is used just for the initial handshake so high frequency tf messages should work.

You're right, I was thinking the actual transport was over HTTP, but it is only for the handshaking, I suppose I confused this detail with how REST works.
 
And although I don't have measurements either, the current process where we encode to ROS, send, decode from ROS, encode to JSON, send, and finally decode from JSON is certainly much slower (high latency) and processor intensive than if messages started out as JSON. You also don't strictly need to send JSON at the server end—not that it's that much different from ROS messages—as WebSockets doesn't define a serialization format. For example, you can always send just binary blobs.

As Bob Dean suggested we could make it so that the message is deserialized directly into JSON (we want to support other in memory formats like OpenCV and PCL types as well). This would make the bridge more efficient. But I think the websockets need to still all go over 80 correct? meaning that you need a single point of entry to a remote machine. It seems like a more natural architecture to have one process serve as the gateway to a ROS system for the browser.
 

I agree that having WebSockets in each node, in addition to existing protocols, would be nice but perhaps complex. From what I can see with that linked DDS document, they're just talking about another bridge solution and that is the solution that we have now, which is kind of terrible. Although I didn't expect much since OMG, as you put it, is "slow to adapt to changes and therefore arguably doesn’t always keep up with the latest trends in software engineering." It looks like, for OMG, the web falls into this category of "latest trend in software engineering" that they don't "always keep up with." 

Well the fact that they have been discussing it for over two years even though websockets are only about three years old, and that they have a beta specification out is pretty good for a standards body, IMO. And I have yet to see a technical alternative to the bridge design for communicating with a middleware from a browser.
 

Personally, I feel like maybe having WebSockets be specifiable as a transport, instead of TCP or more exotic protocols, would seem like a good compromise.

Websockets are over TCP, I'm not sure what you mean here. I don't think it is a good idea to have multiple wire protocols for ROS officially. I think in this case having a bridge into another system like websockets is the right thing to do, but I might be convinced otherwise if we come up with a compelling technical solution which involves this.
 

Totally not related, but I've just (re)noticed that rosmaster and the parameter server runs on XMLRPC, which is a whole lot simpler to use and more sophisticated than ROS services (supporting things like exceptions), so why does ROS services need to be there at all? I feel like the master, in ROS 2.0, should hand out plain xmlrpc connections to services when requested by name.

I've seen that XMLRPC is not suitable for high frequency service requests and because it relies on XML it is difficult if not impossible to implement on embedded systems (see rosc's difficulties with XML parsing). Also ROS Services report errors too. In ROS 2.0 we will likely use DDS's RPC system once it becomes available, allowing us to keep one dependency for both pub/sub and services. Since ROS 2.0 will be using DDS, there will be no ROS master, DDS has a distributed discovery system which uses UDP multicast. This is another reason a bridge is technically necessary to communicate with a browser, since the browser cannot discover it's peers in the ROS network without a proxy in the ROS network (the bridge).
 

On Tue, Sep 16, 2014 at 2:38 PM, William Woodall <william-GsQoM64suCGGJGYlWa3Ukdi2O/JbrIOy@public.gmane.org> wrote:
I think the limiting factor here is that browsers only support websockets as a means to communicate with other processes (without browser specific extensions). The overhead of doing socket communication over HTTP leads to the difficulty with high frequency messages like tf. I'll try to address some other things inline.

On Tue, Sep 16, 2014 at 1:01 PM, Hai Nguyen <haidai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I'm not particularly familiar with DDS, but does it work nicely with browsers? either through some sort of translation or better yet, natively?

People have been using DDS with websockets:


There is a DDS-web specification "in progress", the beta of the spec was released in November 2013:


Briefly looking at it, they plan to do what we do, which is to run a native DDS program and have access to data from the browser go through that program to get data using websockets.
 
I'm interested as the current ROS to WebSockets bridge is particularly ugly: the bridge has to subscribe to all the messages that any web client would need to listen to and then rebroadcast them, which introduces additional delays making it horribly painful to use for things like teleop with large messages like images or point clouds.

I'm not convinced the rebroadcast is the core performance issue here, but you could imagine a system where every node has a websocket server, and then the rosbridge node acted as a lookup service for the web browser, allowing it to connect directly to any node. However, I'm not convinced this is a better solution because it adds a lot of complexity. I really think that the over head of converting to JSON and then sending data over HTTP using websockets is the main performance problem, but I could be wrong about that since I don't have any anecdotal evidence to support it. If that is the case though, there is nothing to be done about it, since the only portable way that I know of to communicate with web browsers is through websockets using JSON.
 

From my perspective, interest, especially commercially, in getting ROS to work with the web have only grown over time. There has been push by Bosch and Brown for a while, and then Willow joined in, right before it closed shop, to build a complementary web toolkit [1] for ROS. Savioke, from their job postings, seem to be doing something webby behind the scenes too. And even for hobby/research projects, it's just so much easier to access robots over a browser compared to with Ubuntu/RViz. The fact that you get iOS and Android support, no ROS java [2] needed, almost for free through their browsers is just fantastic (and I suggest trying this if you haven't already).

All of that is true, I don't think there is anything better DDS or ROS could do from a technical perspective though. I'm open to ideas on that front, it might be good to bring up with other robot web tools people.
 

I might have missed it in my superficial lurking, but I haven't seen this issue of communicating with web clients raised with any seriousness yet. It would be a big missed opportunity if ROS 2.0 only supports talking to browsers at the level that it does now. Most projects are moving to the web. These days even my humble ipython runs a full-fledged web server in its default installation. Certainly, in the future, I feel like this will become a much more pressing issue.

This is certainly true, but in my opinion the best way to support this is to have things like a native node.js client for ROS, which should be easy since it is extended using C++. Which gives you access to all the sophisticated web service development tools with a native connection to the ROS nodes.

ipython also using websockets just like rosbridge, there is nothing that I can see that they do fundamentally different from how rosbridge does things.
 

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ros+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.



--

--
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ros-sig-ng-ros/BfvcjD6Rsg0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ros-sig-ng-ros+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.



--

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ros+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ros-sig-ng-ros/BfvcjD6Rsg0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ros-sig-ng-ros+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.



--
<div><div dir="ltr">
<div>You are right that it's usually more ideal to have just one web socket connection rather than a connection for each topic. I was accepting it as an unfortunate downside of talking to ROS nodes, but now that you've raised the point, it seems to be more serious of a downside than I thought. Specifically, it'd be difficult to do things like implement access control for each topic, which is particularly vital for being on the web.</div>
<div><br></div>After looking into this a little more, however, it looks like whichever DDS system is used, if there is support for some sort of shared memory communication then having a bridge shouldn't be a big performance hit anyway, especially if the marshaling format ends up being JSON.<div><br></div>
<div>Since it's all contingent on shared memory access, is OSRF leaning towards a particular implementation of DDS that has this feature?</div>
<div><br></div>
<div>I do agree with Chad though. It's rather bold to assume that most of the best feedback for ROS 2.0 will be from people that are interested enough to join yet another mailing list, especially since this one is so relevant. From the earliest days, ROS's design has been informed and improved by constant interactions with roboticists. For the benefit of ROS 2.0, I think this process should continue since there is a very real possibility that bad design decisions will result in developers just continuing to use ROS 1.x or even worse, not updating their libraries to support it.</div>
<div><br></div>
<div><div><div><div><div class="gmail_extra">
<div class="gmail_quote">On Tue, Sep 16, 2014 at 5:13 PM, William Woodall <span dir="ltr">&lt;<a href="mailto:william <at> osrfoundation.org" target="_blank">william@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<span class="">On Tue, Sep 16, 2014 at 3:17 PM, Hai Nguyen <span dir="ltr">&lt;<a href="mailto:haidai@..." target="_blank">haidai@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div dir="ltr">I am not a WebSocket expert but from my understanding, HTTP is used just for the initial handshake so high frequency tf messages should work.</div></blockquote>
<div><br></div></span><div>You're right, I was thinking the actual transport was over HTTP, but it is only for the handshaking, I suppose I confused this detail with how REST works.</div>
<span class=""><div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr">And although I don't have measurements either, the current process where we encode to ROS, send, decode from ROS, encode to JSON, send, and finally decode from JSON is certainly much slower (high latency) and processor intensive than if messages started out as JSON. You also don't strictly need to send JSON at the server end&mdash;not that it's that much different from ROS messages&mdash;as&nbsp;WebSockets doesn't define a serialization format. For example, you can always send just binary blobs.</div></blockquote>
<div><br></div></span><div>As Bob Dean suggested we could make it so that the message is deserialized directly into JSON (we want to support other in memory formats like OpenCV and PCL types as well). This would make the bridge more efficient. But I think the websockets need to still all go over 80 correct? meaning that you need a single point of entry to a remote machine. It seems like a more natural architecture to have one process serve as the gateway to a ROS system for the browser.</div>
<span class=""><div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div><div>
<div><br></div>
<div>I agree that having WebSockets in each node, in addition to existing protocols, would be nice but perhaps complex. From what I can see with that linked DDS document, they're just talking about another bridge solution and that is the solution that we have now, which is kind of terrible. Although I didn't expect much since OMG, as you put it, is "slow to adapt to changes and therefore arguably doesn&rsquo;t always keep up with the latest trends in software engineering." It looks like, for OMG, the web falls into this category of "latest trend in software engineering" that they don't "always keep up with."&nbsp;</div>
</div></div></div></blockquote>
<div><br></div></span><div>Well the fact that they have been discussing it for over two years even though websockets are only about three years old, and that they have a beta specification out is pretty good for a standards body, IMO. And I have yet to see a technical alternative to the bridge design for communicating with a middleware from a browser.</div>
<span class=""><div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div><div>
<div><br></div>
<div>Personally, I feel like maybe having WebSockets be specifiable as a transport, instead of TCP or more exotic protocols, would seem like a good compromise.</div>
</div></div></div></blockquote>
<div><br></div></span><div>Websockets are over TCP, I'm not sure what you mean here. I don't think it is a good idea to have multiple wire protocols for ROS officially. I think in this case having a bridge into another system like websockets is the right thing to do, but I might be convinced otherwise if we come up with a compelling technical solution which involves this.</div>
<span class=""><div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div><div>
<div><br></div>
<div>Totally not related, but I've just (re)noticed that rosmaster and the parameter server runs on XMLRPC, which is a whole lot simpler to use and more sophisticated than ROS services (supporting things like exceptions), so why does ROS services need to be there at all? I feel like the master, in ROS 2.0, should hand out plain xmlrpc connections to services when requested by name.</div>
</div></div></div></blockquote>
<div><br></div></span><div>I've seen that XMLRPC is not suitable for high frequency service requests and because it relies on XML it is difficult if not impossible to implement on embedded systems (see rosc's difficulties with XML parsing). Also ROS Services report errors too. In ROS 2.0 we will likely use DDS's RPC system once it becomes available, allowing us to keep one dependency for both pub/sub and services. Since ROS 2.0 will be using DDS, there will be no ROS master, DDS has a distributed discovery system which uses UDP multicast. This is another reason a bridge is technically necessary to communicate with a browser, since the browser cannot discover it's peers in the ROS network without a proxy in the ROS network (the bridge).</div>
<div><div class="h5">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div class="gmail_extra">
<br><div class="gmail_quote">
<span>On Tue, Sep 16, 2014 at 2:38 PM, William Woodall <span dir="ltr">&lt;<a href="mailto:william@..." target="_blank">william@...</a>&gt;</span> wrote:<br></span><blockquote class="gmail_quote">
<div><div><div dir="ltr">I think the limiting factor here is that browsers only support websockets as a means to communicate with other processes (without browser specific extensions). The overhead of doing socket communication over HTTP leads to the difficulty with high frequency messages like tf. I'll try to address some other things inline.<div class="gmail_extra">
<br><div class="gmail_quote">
<span>On Tue, Sep 16, 2014 at 1:01 PM, Hai Nguyen <span dir="ltr">&lt;<a href="mailto:haidai@..." target="_blank">haidai@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote"><div dir="ltr"><span>I'm not particularly familiar with DDS, but does it work nicely with browsers? either through some sort of translation or better yet, natively?</span></div></blockquote>
<div><br></div></span><div>People have been using DDS with websockets:</div>
<div><br></div>
<div><a href="http://www.slideshare.net/Angelo.Corsaro/dds-on-the-web-quick-recipes-for-realtime-web-applications" target="_blank">http://www.slideshare.net/Angelo.Corsaro/dds-on-the-web-quick-recipes-for-realtime-web-applications</a></div>
<div><br></div>
<div>There is a DDS-web specification "in progress", the beta of the spec was released in November 2013:</div>
<div><br></div>
<div>
<a href="http://www.omg.org/spec/DDS-WEB/" target="_blank">http://www.omg.org/spec/DDS-WEB/</a><br>
</div>
<div><br></div>
<div>Briefly looking at it, they plan to do what we do, which is to run a native DDS program and have access to data from the browser go through that program to get data using websockets.</div>
<span><div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><span>I'm interested as the current ROS to WebSockets bridge is particularly ugly: the bridge has to subscribe to all the messages that any web client would need to listen to and then rebroadcast them, which introduces additional delays making it horribly painful to use for things like teleop with large messages like images or point clouds.</span></div></blockquote>
<div><br></div></span><div>I'm not convinced the rebroadcast is the core performance issue here, but you could imagine a system where every node has a websocket server, and then the rosbridge node acted as a lookup service for the web browser, allowing it to connect directly to any node. However, I'm not convinced this is a better solution because it adds a lot of complexity. I really think that the over head of converting to JSON and then sending data over HTTP using websockets is the main performance problem, but I could be wrong about that since I don't have any anecdotal evidence to support it. If that is the case though, there is nothing to be done about it, since the only portable way that I know of to communicate with web browsers is through websockets using JSON.</div>
<span><div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div>
<div><br></div>
<div>From my perspective, interest, especially commercially, in getting ROS to work with the web have only grown over time. There has been push by Bosch and Brown for a while, and then Willow joined in, right before it closed shop, to build a complementary web toolkit [1] for ROS. Savioke, from their job postings, seem to be doing something webby behind the scenes too. And even for hobby/research projects, it's just so much easier to access robots over a browser compared to with Ubuntu/RViz. The fact that you get iOS and Android support, no ROS java [2] needed, almost for free through their browsers is just fantastic (and I suggest trying this if you haven't already).</div>
</div></div></blockquote>
<div><br></div></span><div>All of that is true, I don't think there is anything better DDS or ROS could do from a technical perspective though. I'm open to ideas on that front, it might be good to bring up with other robot web tools people.</div>
<span><div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr">
<div><br></div>
<div>I might have missed it in my superficial lurking, but I haven't seen this issue of communicating with web clients raised with any seriousness yet. It would be a big missed opportunity if ROS 2.0 only supports talking to browsers at the level that it does now. Most projects are moving to the web. These days even my humble ipython runs a full-fledged web server in its default installation. Certainly, in the future, I feel like this will become a much more pressing issue.</div>
</div></blockquote>
<div><br></div></span><div>This is certainly true, but in my opinion the best way to support this is to have things like a native node.js client for ROS, which should be easy since it is extended using C++. Which gives you access to all the sophisticated web service development tools with a native connection to the ROS nodes.</div>
<div><br></div>
<div>ipython also using websockets just like rosbridge, there is nothing that I can see that they do fundamentally different from how rosbridge does things.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<span><div dir="ltr">
<div><br></div>
<div>[1]&nbsp;<a href="http://robotwebtools.org/" target="_blank">http://robotwebtools.org</a>
</div>
<div>[2]&nbsp;<a href="https://code.google.com/p/rosjava/" target="_blank">https://code.google.com/p/rosjava/</a>
</div>
</div></span><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:ros-sig-ng-ros+unsubscribe@..." target="_blank">ros-sig-ng-ros+unsubscribe@...</a>.<span><br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br></span></span>
</blockquote>
</div>
<span><br><br clear="all"><div><br></div>-- <br><div dir="ltr">William Woodall<div>ROS Development Team</div>
<div><a href="mailto:william@..." target="_blank">william@...</a></div>
<div><a href="http://wjwwood.io/" target="_blank">http://wjwwood.io/</a></div>
</div>
</span>
</div>
</div></div></div>
<div><div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG NG ROS" group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/ros-sig-ng-ros/BfvcjD6Rsg0/unsubscribe" target="_blank">https://groups.google.com/d/topic/ros-sig-ng-ros/BfvcjD6Rsg0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href="mailto:ros-sig-ng-ros+unsubscribe@..." target="_blank">ros-sig-ng-ros+unsubscribe@...</a>.<span><br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br></span>
</div></div>
</blockquote>
</div>
<span><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Hai Nguyen<div><div><div>
<a href="http://haidai.tumblr.com" target="_blank">http://haidai.tumblr.com</a><br>
</div></div></div>
</div>
</span>
</div>
<div><div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:ros-sig-ng-ros+unsubscribe@..." target="_blank">ros-sig-ng-ros+unsubscribe@...</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</div></div>
</blockquote>
</div></div>
</div>
<div><div class="h5">
<br><br clear="all"><div><br></div>-- <br><div dir="ltr">William Woodall<div>ROS Development Team</div>
<div><a href="mailto:william@..." target="_blank">william@...</a></div>
<div><a href="http://wjwwood.io/" target="_blank">http://wjwwood.io/</a></div>
</div>
</div></div>
</div></div>
<div class=""><div class="h5">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG NG ROS" group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/ros-sig-ng-ros/BfvcjD6Rsg0/unsubscribe" target="_blank">https://groups.google.com/d/topic/ros-sig-ng-ros/BfvcjD6Rsg0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href="mailto:ros-sig-ng-ros+unsubscribe@..." target="_blank">ros-sig-ng-ros+unsubscribe@...</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</div></div>
</blockquote>
</div>
<br><br clear="all"><div><br></div>-- <br><div dir="ltr">Hai Nguyen<div><div><div>
<a href="http://haidai.tumblr.com" target="_blank">http://haidai.tumblr.com</a><br>
</div></div></div>
</div>
</div></div></div></div></div>
</div></div>
Yanzhen Wang | 18 Sep 10:21 2014
Picon

An open source machine learning library (C++)

Hi all,

Machine learning is becoming more and more important in robotics, and robots today are gaining more and more learning abilities. Typical machine learning tools commonly used in robotics community include openCV and Matlab. But they have their own limitations, in either performance or target problem size. We'd like to share an open source ensemble learning library, which we call libEDM, with the community. It is written in C++ and provides functions covering almost all facets of ensemble learning. It can also be used as a toolkit of typical supervised machine learning algorithms, including basic classifiers such as support vector machines (SVM), back-propagation neural networks (BPNN), C4.5 decision trees, naive Bayes, and much more. One of the most important feature of our libEDM is its ability of dealing with extremely large datasets. The largest training set we tested contains 39,859,272 records, each with 75 attributes.

If you want to find more about libEDM or try it out, please go to its GitHub repository:

And we are in the position of ROSifying some parts of the library to make it more usable in the robotics context. Please stay posted. Any feedback will be greatly appreciated.

Best regards,
Yanzhen

<div><div dir="ltr">
<span>Hi all,</span><br><div>
<div><br></div>
<div>Machine learning is becoming more and more important in robotics, and robots today are gaining more and more learning abilities. Typical machine learning tools commonly used in robotics community include openCV and Matlab. But they have their own limitations, in either performance or target problem size. We'd like to share an open source ensemble learning library, which we call libEDM, with the community. It is written in C++ and provides functions covering almost all facets of ensemble learning. It can also be used as a toolkit of typical supervised machine learning algorithms, including basic classifiers such as support vector machines (SVM), back-propagation neural networks (BPNN), C4.5 decision trees, naive Bayes, and much more. One of the most important feature of our libEDM is its ability of dealing with extremely large datasets. The largest training set we tested contains 39,859,272 records, each with 75 attributes.</div>
<div><br></div>
<div>If you want to find more about libEDM or try it out, please go to its GitHub repository:</div>
<div><a href="https://github.com/Qiangli-Zhao/LibEDM" target="_blank">https://github.com/Qiangli-Zhao/LibEDM</a></div>
<div><br></div>
<div>And we are in the position of ROSifying some parts of the library to make it more usable in the robotics context. Please stay posted.&nbsp;<span>Any feedback will be greatly appreciated.</span>
</div>
<div>
<div>
<br><span>Best regards,</span>
<div>Yanzhen</div>
<br class="ecxApple-interchange-newline">
</div>
</div>
</div> 		 	   		  </div></div>
Yanzhen Wang | 18 Sep 03:19 2014
Picon

Debian packages facilitating installation of linux-rt kernel

<!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 12pt; font-family:Calibri } -->
Hi everyone,

A real-time host OS may be needed when one is dealing with real-time guarantees in ROS applications. To make the installation of an rt-patched Linux kernel much easier, we created two Debian packages which do most of the work. They uses the Linux 3.8.13-rt16 RT-PREEMPT patch for 32-bit and 64-bit systems, respectively.

If you would like to give them a try, you can download the packages from the following links:

Place the corresponding package in any directory, and then run the following command and reboot the system.
sudo dpkg -i linux-image-XXXX.deb

Now the real-time kernel will be there.

We would be grateful if you can try them out and any feedback would be greatly appreciated.

Best regards,
Yanzhen

<div><div dir="ltr">

<div dir="ltr">

<div dir="ltr">

&lt;!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--&gt;<div dir="ltr">Hi everyone,<div><br></div>
<div>A real-time host OS may be needed when one is dealing with real-time guarantees in ROS applications. To make the installation of an rt-patched Linux kernel much easier, we created two Debian packages which do most of the work. They uses the Linux 3.8.13-rt16 RT-PREEMPT patch for 32-bit and 64-bit systems, respectively.</div>
<div><br></div>
<div>If you would like to give them a try, you can download the packages from the following links:</div>
<div>32-bit:&nbsp;<a href="http://micros.nudt.edu.cn/ros/attachments/download/6409/linux-image-3.8.13-rt16-i386-v0.0.1.deb" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6409/linux-image-3.8.13-rt16-i386-v0.0.1.deb</a>
</div>
<div>64-bit:&nbsp;<a href="http://micros.nudt.edu.cn/ros/attachments/download/6413/linux-image-3.8.13-rt16_3.8.13-rt16-10.00.Custom_amd64.deb" target="_blank">http://micros.nudt.edu.cn/ros/attachments/download/6413/linux-image-3.8.13-rt16_3.8.13-rt16-10.00.Custom_amd64.deb</a>
</div>
<div><br></div>
<div>Place the corresponding package in any directory, and then run the following command and reboot the system.</div>
<div><span>sudo dpkg -i linux-image-XXXX.deb</span></div>
<div><br></div>
<div>Now the real-time kernel will be there.</div>
<div><br></div>
<div>We would be grateful if you can try them out and any feedback would be greatly appreciated.</div>
<div><div>
<br>Best regards,<div>Yanzhen</div>
<div><br></div>
</div></div>
</div>
</div>
</div>
 		 	   		  </div></div>
Kelsey Hawkins | 17 Sep 14:49 2014
Picon

Combine robot_state_publisher with tf::TransformListener?

I'd bet that 90-100% of transform requests in typical ros systems run through a chain delivered through robot_state_publisher. Wouldn't it make sense to optionally allow tf::TransformListener to parse a URDF and subscribe to /joint_states in addition to /tf? The advantage is that you can do proper interpolation between joint configurations and you vastly reduce the bandwidth of /tf. Plus, you eliminate a processor intensive node which is mostly relaying redundant information easily read from the URDF.

I'm sure this isn't a novel idea, but are there any plans to integrate this behavior into ROS core? Any caveats?

-Kelsey

<div>
<p dir="ltr">I'd bet that 90-100% of transform requests in typical ros systems run through a chain delivered through robot_state_publisher. Wouldn't it make sense to optionally allow tf::TransformListener to parse a URDF and subscribe to /joint_states in addition to /tf? The advantage is that you can do proper interpolation between joint configurations and you vastly reduce the bandwidth of /tf. Plus, you eliminate a processor intensive node which is mostly relaying redundant information easily read from the URDF.</p>
<p dir="ltr">I'm sure this isn't a novel idea, but are there any plans to integrate this behavior into ROS core? Any caveats?</p>
<p dir="ltr">-Kelsey</p>
</div>
supraja reddy | 17 Sep 12:32 2014
Picon

reg: OPW internship

Hello ,

I am interested to work with ROS as a part of OPW internship . Can somebody please help as to how I should proceed . Is there any irc channel regarding this or any person whom I can approach related to this .

Thanks .

Regards,
Myra

<div><div dir="ltr">Hello ,<br><br>I am interested to work with ROS as a part of OPW internship . Can somebody please help as to how I should proceed . Is there any irc channel regarding this or any person whom I can approach related to this . <br><br>Thanks .<br><br>Regards,<br>Myra<br><br>
</div></div>
Bence Magyar | 16 Sep 16:58 2014

Announcing diff_drive_controller in ros_controllers

Hi everyone,

PAL Robotics is pleased to announce the release of the diff_drive_controller that became available in Hydro and Indigo in the first quarter of 2014.

For those who already know it, I'd like to ask you to add your robot(s) to the wiki page with a moderately sized image and name: http://wiki.ros.org/diff_drive_controller#Robots.

For those who are new to it,
For documentation refer to:
http://wiki.ros.org/diff_drive_controller

As the name suggests, this controller moves a differential drive wheel base.
Features:
  • The controller takes geometry_msgs::Twist messages as input.
  • Realtime-safe implementation.

  • Odometry computed and published from open or closed loop
  • Task-space velocity and acceleration limits
  • Automatic stop after command time-out
The controller will soon support skid steer platforms as well.

Cheers,
--

Bence Magyar

Robotics Engineer

bence.magyar-3MzGGok7BHU5ffrT631h+Q@public.gmane.org

www.pal-robotics.com

Pal Robotics, S.L.
c/ Pujades 77-79, 4º4ª
08005 Barcelona
Spain
Tel      +34 93 414 53 47
Fax     +34 93 209 11 09
Skype:  bencemagyar.pal-robotics

Facebook - Twitter - PAL Robotics YouTube Channel

P Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos.

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario.  Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.
<div><div dir="ltr">
<div>
<div>Hi everyone,<br><br>PAL Robotics is pleased to announce the release of the diff_drive_controller that became available in Hydro and Indigo in the first quarter of 2014.<br><br>
</div>
<div>For those who already know it, I'd like to ask you to add your robot(s) to the wiki page with a moderately sized image and name: <a href="http://wiki.ros.org/diff_drive_controller#Robots" target="_blank">http://wiki.ros.org/diff_drive_controller#Robots</a>.<br><br>
</div>
<div>For those who are new to it,<br>For documentation refer to:<br><a href="http://wiki.ros.org/diff_drive_controller" target="_blank">http://wiki.ros.org/diff_drive_controller</a><br><br>
</div>As the name suggests, this controller moves a differential drive wheel base. <br>Features:<br><ul>
<li>The controller takes <a href="http://docs.ros.org/api/geometry_msgs/html/msg/Twist.html" target="_blank">geometry_msgs::Twist</a> messages as input.</li>
<li><p>Realtime-safe implementation. <span></span></p></li>
<li>Odometry computed and published <span></span>from open or closed loop<br>
</li>
<li>Task-space velocity and acceleration limits <span></span>
</li>
<li>Automatic stop after command time-out </li>
</ul>The controller will soon support skid steer platforms as well. <br><br>
</div>
<div>Cheers,<br>
</div>
<div><div><div>-- <br><div dir="ltr">
<p><span><span lang="EN-US">Bence Magyar</span></span></p>
<p><span><span lang="EN-US">Robotics Engineer</span></span></p>
<p><a href="mailto:bence.magyar@..." target="_blank">bence.magyar@...</a></p>
<p><span><a href="http://www.pal-robotics.com/" target="_blank"><span lang="EN-US">www.pal-robotics.com</span></a></span></p>
<p><span>Pal Robotics, S.L.<br>c/ Pujades 77-79, 4&ordm;4&ordf;<br>08005 Barcelona<br>Spain<br>Tel &nbsp; &nbsp; &nbsp;<a value="+34934145347">+34 93 414 53 47</a><br>Fax &nbsp; &nbsp;&nbsp;<a value="+34932091109">+34 93 209 11 09</a><br>Skype:&nbsp;&nbsp;bencemagyar.pal-robotics</span></p>
<p><a href="http://www.facebook.com/palrobotics1" target="_blank">Facebook</a>&nbsp;-&nbsp;<a href="http://twitter.com/#%21/palrobotics" target="_blank">Twitter</a>&nbsp;-&nbsp;<a href="http://www.youtube.com/user/PALRobotics" target="_blank">PAL Robotics YouTube Channel</a><br></p>
<p><span>P</span><span>&nbsp;</span><span>Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos.</span><span></span></p>
<p><span>AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener informaci&oacute;n privilegiada y/o confidencial que est&aacute; dirigida exclusivamente a su destinatario.&nbsp; Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notif&iacute;quelo inmediatamente y remita el mensaje original a la direcci&oacute;n de correo electr&oacute;nico indicada. Cualquier copia, uso o distribuci&oacute;n no autorizados de esta comunicaci&oacute;n queda estrictamente prohibida.</span></p>
<span lang="EN-US">CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.&nbsp; If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.&nbsp; If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.</span><br>
</div>
</div></div></div>
</div></div>
Michael Ferguson | 15 Sep 23:19 2014
Picon

SIG for Buildbot-ROS

After my presentation this past weekend at ROSCON, there has been a lot of interest in BuildBot-ROS. I'd like to announce a new mailing list for discussions about the software, located at: https://groups.google.com/forum/#!forum/buildbot-ros-sig

-Mike Ferguson
<div><div dir="ltr">After my presentation this past weekend at ROSCON, there has been a lot of interest in BuildBot-ROS. I'd like to announce a new mailing list for discussions about the software, located at: <a href="https://groups.google.com/forum/#!forum/buildbot-ros-sig">https://groups.google.com/forum/#!forum/buildbot-ros-sig</a><div><br></div>
<div>-Mike Ferguson</div>
</div></div>
Duy Huynh | 15 Sep 19:19 2014
Picon

qualcomm representative / lightening talk on 2nd day at ros con

hi there,

does anyone have the contact info of the qualcomm representative who presented the qualcomm + ros integration on stage during the lightening talk at ros con?  i found that talk was really interesting, but i couldn't find him afterward at the conference.

please reply to the whole group or privately to me at duy-yuLo52bAwY1l57MIdRCFDg@public.gmane.org

thanks!
duy
<div><div dir="ltr">hi there,<div><br></div>
<div>does anyone have the contact info of the qualcomm representative who presented the qualcomm + ros integration on stage during the lightening talk at ros con? &nbsp;i found that talk was really interesting, but i couldn't find him afterward at the conference.</div>
<div><br></div>
<div>please reply to the whole group or privately to me at <a href="mailto:duy@...">duy@...</a>
</div>
<div><br></div>
<div>thanks!</div>
<div>duy</div>
</div></div>
Yanzhen Wang | 15 Sep 11:27 2014
Picon

Will a ROS package for Bloom filters be useful?

Hi there,

We had implemented several types of Bloom filters in java. A Bloom filter is a space-efficient probabilistic data structure, which is used to test whether an element is a member of a set. It is very useful for applications where the amount of source data is extremely large and conventional hashing techniques become impractical. For more information, please refer to the Wikipedia: http://en.wikipedia.org/wiki/Bloom_filter.

The Bloom filters we implemented include the basic Bloom filter, counting Bloom filter, and dynamic Bloom filter. In a basic Bloom filter, elements can be added but not removed. In the two extensions (counting and dynamic) Bloom filter, element can be removed. Bloom filters are very useful for applications like content synchronization.

We are in the position of wrapping the Bloom filters up as a ROS package, but we think it's better to know whether it is of any interest in the ROS (or more generally, robotics) community in the first place.

Any suggestion will be greatly appreciated.

Best regards,
Yanzhen

<!-- .ExternalClass .ecxhmmessage P { padding:0px; } .ExternalClass body.ecxhmmessage { font-size:12pt; font-family:Calibri; } -->
<div><div dir="ltr">
<div><div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi there,<div><br></div>
<div>We had implemented several types of Bloom filters in java. A Bloom filter is a space-efficient probabilistic data structure, which is used to test whether an element is a member of a set. It is very useful for applications where the amount of source data is extremely large and conventional hashing techniques become impractical. For more information, please refer to the Wikipedia:&nbsp;<a href="http://en.wikipedia.org/wiki/Bloom_filter" target="_blank">http://en.wikipedia.org/wiki/Bloom_filter</a>.</div>
<div><br></div>
<div>The Bloom filters we implemented include the basic Bloom filter, counting Bloom filter, and dynamic Bloom filter. In a basic Bloom filter, elements can be added but not removed. In the two extensions (counting and dynamic) Bloom filter, element can be removed. Bloom filters are very useful for applications like content synchronization.</div>
<div><br></div>
<div>We are in the position of wrapping the Bloom filters up as a ROS package, but we think it's better to know whether it is of any interest in the ROS (or more generally, robotics) community in the first place.</div>
<div><br></div>
<div>Any suggestion will be greatly appreciated.</div>
<div>
<br>Best regards,<div>Yanzhen</div>
<div><br></div>
</div>
</div>
</div>
 		 	   		  </div></div>&lt;!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}

.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}

--&gt;</div></div>
Aaron Sims | 14 Sep 22:40 2014
Picon

The future of ROS 2.0 protocol changes

Dear ROS Teams, Thanks for an informative time at ROSCon 2014. I had to leave about an hour and a half early to catch a flight, and I was left with my head spinning about the the decision to change protocols in ROS 2.0. This is an important decision, and I will share my concerns, as well as my thoughts on a direction I personally would of taken with ROS 2.0, and the protocol directions. This topic seems better fit for a blog, however, an open discussion is important. First let me say the direction of ROS 2.0 makes sense, the complete shift to ROS DDS protocol does not seem wise. There are many good reasons to implement DDS in ROS, however, the way it is implemented can make or break ROS in the future. Many well intended protocol implementations end up at dead ends. Two examples are: HTTP NG (Next Generation) http://www.w3.org/Protocols/HTTP-NG/Activity.html Gnutella 2 http://en.wikipedia.org/wiki/Gnutella2 I'd like to share the approach of the Happy Artist RMDMIA RCSM (Robot Control System Messenger) API. The RCSM implements a plugin architecture that allows multiple robot operating system clients to be registered/accessed, run simultaneously, and inter operate together, or simply to plugin a single client such as the Happy Artist ROS Client for TCPROS/UDPROS. As a ROS user this allows any protocol to plugin, and work from any 3rd party vendor DDS implementation, TCPROS/UDPROS, or any other protocol. In the Happy Artist RMDMIA implementation the RCSM component serves as an interface to the rest of the system so that protocols can change, while code written for autonomous /user control follows the same pattern, allowing interchangeability, and forward/backward compatibility between other aspects of the system. If ROS were to approach 2.0 like this, libraries like MoveIt (an example of a library name (no idea if it is tied to TCPROS/UDPROS protocols in ROS 1.0 implementation), could run on any communication protocol without ever needing to know anything about the protocols it was operating on. This approach needs to be applied to all areas of the system so that a user of any component can interchange their libraries to ROS 2.0 for 100% forward, and backward compatibility. I am personally concerned that researchers may find themselves using ROS alternatives due to the time/money that will be lost while they wait for a viable ROS 2.0 solution. Why would a researcher/developer invest resources into a platform that was going to completely change nullifying their personal investment in that platform? It is evident ROS 2.0 needs support similar to ACID transactions for autonomous robotics that the DDS implementation will support (primarily for people safety, and system stability of commercialized autonomous systems). It is a bad, bad idea to throw the current ROS users under the bus in the interim. The implementation architecture direction for ROS 2.0 I am suggesting alleviates this scenario, and allows ROS to backtrack a little with its users to continue improving ROS 1.0 functionality in TCPROS, and UDPROS. In the interim here are some ROS 1.0 improvements that could greatly improve ROS performance with substantial latency decrease, while increasing data bandwidth:Add support for UDPROS on every ROS supported client, and server with a few minor enhancements. (Some of these suggestions came out of the BOF at ROSCon discussion on latency and performance, and some I have been attempting to subtly hint at with multiple questions on ROS Answers over the last year). UDP Jumbogram support: This is a very simple enhancement. Allow unbounded UDP Datagram sizes, and during protocol handshake (XMLRPC negotiation in UDPROS), and add a flag to the publisher configuration that says allow UDP jumbogram support, or specify the maximum datagram size. ROS currently puts their datagram size limit around 1500 bytes. If the system hardware supports jumbograms, the only change is supporting a configurable maximum datagram size. UDP Multicast support: Adding a header attribute called multicast could allow a topic or service (not aware service is currently supported for UDPROS, but it should be) to configure the associated Publisher to perform a broadcast (A concern of multiple subscribers to a topic causing a major problem with system performance can be alleviated with a feature request by a person in the BOF get together for specifying the numeric limit to subscribers of a particular topic). Note: (Based on my personal UDPROS implementation experience, adding Multicast suppor t would be fairly simple to add into the Happy Artist Java client, so I assume the same might apply on other platforms that have UDPROS support). Maximum Topic Subscribers support: Allow the the system designer to specify the maximum number of subscribers on any given topic. The use case given was a high bandwidth topic that multiple users subscribe to and cause the system to hang. The user wanted to implement a UDPROS topic with Multicast support for a single subscriber. Note: Based on my personal knowledge of the CPP client (somewhat limited), the client uses low level arrays rather than Data Collection Objects, therefore the incremental nature of arrays in CPP code should make this task fairly straight forward to implement. font> If you have any questions or would like to have further discussion, I look forward to discussion.

Sincerely,

Aaron

<div><div>
<div class="">
	
	
	

</div>Dear ROS Teams,

Thanks for an informative time at ROSCon 2014. I had to leave about an hour and a half early to catch a flight, and I was left with my head spinning about the the decision to change protocols in ROS 2.0. This is an important decision, and I will share my concerns, as well as my thoughts on a direction I personally would of taken with ROS 2.0, and the protocol directions. This topic seems better fit for a blog, however, an open discussion is important. 

First let me say the direction of ROS 2.0 makes sense, the complete shift to ROS DDS protocol does not seem wise. There are many good reasons to implement DDS in ROS, however, the way it is implemented can make or break ROS in the future. 

Many well intended protocol implementations end up at dead ends. Two examples are: 
<a href="http://www.w3.org/Protocols/HTTP-NG/Activity.html" class="">HTTP NG (Next Generation)</a> 
<a href="http://www.w3.org/Protocols/HTTP-NG/Activity.html" class="">http://www.w3.org/Protocols/HTTP-NG/Activity.html</a>
<a href="http://en.wikipedia.org/wiki/Gnutella2" class="">Gnutella 2</a>
<a href="http://en.wikipedia.org/wiki/Gnutella2" class="">http://en.wikipedia.org/wiki/Gnutella2</a>

I'd like to share the approach of the Happy Artist RMDMIA RCSM (Robot Control System Messenger) API. The RCSM implements a plugin architecture that allows multiple robot operating system clients to be registered/accessed, run simultaneously, and inter operate together, or simply to plugin a single client such as the Happy Artist ROS Client for TCPROS/UDPROS.  As a ROS user this allows any protocol to plugin, and work from any 3rd party vendor DDS implementation, TCPROS/UDPROS, or any other protocol. In the Happy Artist RMDMIA implementation the RCSM component serves as an interface to the rest of the system so that protocols can change, while code written for autonomous
 /user control follows the same pattern, allowing interchangeability, and forward/backward compatibility between other aspects of the system. If ROS were to approach 2.0
 like this, libraries like MoveIt (an example of a library name (no idea if it is tied to TCPROS/UDPROS protocols in ROS 1.0 implementation), could run on any communication protocol without ever needing to know anything about the protocols it was operating on. This approach needs to be applied to all areas of the system so that a user of any component can interchange their libraries to ROS 2.0 for 100% forward, and backward compatibility.

I am personally concerned that researchers may find themselves using ROS alternatives due to the time/money that will be lost while they wait for a viable ROS 2.0 solution. Why would a researcher/developer invest resources into a platform that was going to completely change nullifying their personal investment in that platform?

It is evident ROS 2.0 needs support similar to ACID transactions for autonomous robotics that the DDS implementation will support (primarily for people safety, and system stability of commercialized autonomous systems).   

It is a bad, bad idea to throw the current ROS users under the bus in the interim. The implementation architecture direction for ROS 2.0 I am suggesting alleviates this scenario, and allows ROS to backtrack a little with its users to continue improving ROS 1.0 functionality in TCPROS, and UDPROS.
In the interim here are some ROS 1.0 improvements that could greatly improve ROS performance with substantial latency decrease, while increasing data bandwidth:Add support for UDPROS on every ROS supported client, and server with a few minor enhancements. (Some of these suggestions came out of the BOF at ROSCon discussion on latency and performance, and some I have been attempting to subtly hint at with multiple questions on ROS Answers over the last year).

UDP Jumbogram support: This is a very simple enhancement. Allow unbounded UDP Datagram sizes, and during protocol handshake (XMLRPC negotiation in UDPROS), and add a flag to the publisher configuration that says allow UDP jumbogram support, or specify the maximum datagram size. ROS currently puts their datagram size limit around 1500 bytes. If the system hardware supports jumbograms, the only change is supporting a configurable maximum datagram size. 

UDP Multicast support: Adding a header attribute called multicast could allow a topic or service (not aware service is currently supported for UDPROS, but it should be) to configure the associated Publisher to perform a broadcast (A concern of multiple subscribers to a topic causing a major problem with system performance can be alleviated with a feature request by a person in the BOF get together for specifying the numeric limit to subscribers of a particular topic).  Note: (Based on my personal UDPROS implementation experience, adding Multicast suppor
 t would be fairly simple to add into the Happy Artist Java client, so I assume the same might apply on other platforms that have UDPROS support). 

Maximum Topic Subscribers support: Allow the the system designer to specify the maximum number of subscribers on any given topic. The use case given was a high bandwidth topic that multiple users subscribe to and cause the system to hang. The user wanted to implement a UDPROS topic with Multicast support for a single subscriber. Note: Based on my personal knowledge of the CPP client (somewhat limited), the client uses low level arrays rather than Data Collection Objects, therefore the incremental nature of arrays in CPP code should make this task fairly straight forward to implement.
 font&gt;

If you have any questions or would like to have further discussion, I look forward to discussion.<br class=""><br class="">Sincerely,<br class=""><br class="">Aaron<div class=""><br class=""></div>
</div></div>

Gmane