[ros-users] [ros-sig-ng-ros] ROS and Web Clients

Ingo Lütkebohle iluetkeb at gmail.com
Fri Sep 19 07:48:51 UTC 2014


Am 19.09.2014 00:03 schrieb "Hai Nguyen" <haidai at gmail.com>:
>
> You are right that it's usually more ideal to have just one web socket
connection rather than a connection for each topic.

Many Middleware packages can multiplex multiple streams over one TCP
connection. Might be simmering to look for.

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

As someone whose research interests are founded on making teams more
efficient, I can say that talking about the means of communication, while
important, is secondary. The most important thing is the process (yeah, I
know, that's what the architecture astronauts also say, and nobody likes
those, but there is always a process anyway, so better consciously simplify
it).

You don't get large involvement by exposing all people to every messy,
technical discussion. That'll just scare them away, or make them ignore
mails. You *also* don't get it by doing everything behind closed doors, of
course.

Both you and Chad have asked for discussing, essentially, important things
here. However, who's going to make that call?

*I* think there's always a tradeoff here, and that the only way to get
around it is not to discuss more initially, but to release early and often,
and taking release feedback into account.

For that to work, we can look at the Linux kernel approach, e.g. its
commitment to compatibility between releases and Linus's style in general.
We can also look at apache httpd 1.3 to 2.0, for what *not* to do (cf
second system syndrome).

In that vein, it seems that the biggest problem right now is that ROS 2.0
is trying to do very many things at once, instead of staggering them.
That's bound to be difficult, however you go about it.

I don't know the technical reasons for that, but I think it's interesting
that other groups apparently managed to get DDS with ROS 1.0 APIs. Maybe
something can be learned from that.

In any case, ROS has become larger and more complex now, and the core team
actually became smaller. So, what worked the first time around is not
necessarily the way to go now. Some adaptation will likely be necessary.

I for one would certainly be willing to help osrf by joining a special
list. I can't commit to that right now because I'll be starting a new job
soon, but just saying that I wouldn't consider that too large a burden. Of
course, not everybody can or wants do that, that's why I think we need
different forms of involvement.

Cheers,
Ingo

>
> On Tue, Sep 16, 2014 at 5:13 PM, William Woodall <
william at osrfoundation.org> wrote:
>>
>> On Tue, Sep 16, 2014 at 3:17 PM, Hai Nguyen <haidai at gmail.com> 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 at osrfoundation.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 at gmail.com> 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:
>>>>
>>>>
http://www.slideshare.net/Angelo.Corsaro/dds-on-the-web-quick-recipes-for-realtime-web-applications
>>>>
>>>> There is a DDS-web specification "in progress", the beta of the spec
was released in November 2013:
>>>>
>>>> http://www.omg.org/spec/DDS-WEB/
>>>>
>>>> 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.
>>>>
>>>>>
>>>>>
>>>>> [1] http://robotwebtools.org
>>>>> [2] https://code.google.com/p/rosjava/
>>>>>
>>>>> --
>>>>> 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 at googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> William Woodall
>>>> ROS Development Team
>>>> william at osrfoundation.org
>>>> http://wjwwood.io/
>>>>
>>>> --
>>>> 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 at googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> --
>>> Hai Nguyen
>>> http://haidai.tumblr.com
>>>
>>> --
>>> 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 at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> William Woodall
>> ROS Development Team
>> william at osrfoundation.org
>> http://wjwwood.io/
>>
>> --
>> 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 at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Hai Nguyen
> http://haidai.tumblr.com
>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140919/7c75acca/attachment.html>


More information about the ros-users mailing list