[ros-users] Web introspection tools

[Jenkins, Odest Chadwicke]

I believe the web introspection thread highlights the tradeoffs of
usability and interoperability with performance and efficiency, as
discussed previously wrt usability:

  http://lists.ros.org/pipermail/ros-users/2014-February/068247.html

William, you are correct about native apps if the use case is restricted to
a root-access machines running a specific OS an a LAN, connecting to a LAN
over VPN, or similar specifically-optimized configuration.  Recent history
shows that such system and network optimizations in ROS have come at a cost
in terms of ease of use, modification, build, and deployment.

Using customized messaging over a non-HTTP transport will surely yield
significant performance benefits.  However, this will come at the cost on
the front-end with respect to usability, accessibility beyond a LAN, and
interoperability across different development frameworks, etc.  While I
agree JavaScript and HTML5 has a lot of great frameworks coming up, it is
important to acknowledge the ways such frameworks restrict extensibility
and interoperability, especially the potential for breaking code built on
these frameworks over time.

I believe William's message acknowledges this tradeoff.  It is just good to
clarify the relative strengths and weaknesses of different design choices
with a broader range of use cases in mind.
___
Chad


> ------------------------------
>
> Message: 5
> Date: Wed, 25 Jun 2014 13:27:28 -0700
> From: William Woodall <william at osrfoundation.org>
> To: User discussions <ros-users at lists.ros.org>
> Cc: User discussions <ros-users at code.ros.org>
> Subject: Re: [ros-users] Web introspection tools
> Message-ID:
>         <CAFe2DWid9H+zWwou+YTBy9ABBxOzVf7ckG3=
> kWrJ1fZ3noTEBQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I haven't tried to implement anything, but my guess is that at least for
> rviz, there are several places where a native app would out perform the web
> version considerably. For example, transforming data between frames before
> visualizing would likely be very intensive in javascript. You could push
> most if not all of this into the server side which could be C++, but then
> you run into the fact that websockets actually introduce considerable
> overhead to communication when compared with ROS topics. This makes it a
> bottleneck, for example the robotwebtools have things like the tf
> republisher which takes /tf data and does some tricks to reduce the number
> of messages sent. I believe this was developed because the websockets
> couldn't keep up with /tf. I don't think the JSON data is the only reason
> for increased bandwidth usage, but also the fact that it must go over http
> requests.
>
> I'm sure about the custom shaders being available or needed, but I imagine
> that the lack of them would make rendering things like pointclouds much
> less efficient.
>
> For other tools like rqt_graph, rqt_topic, and other things I think the web
> based tools make a lot of sense. You can work around access to local files
> using the server for files on the target machine and you can access files
> local to the browser's machine using html5 and javascript in some cases.
> There are some awesome up and coming javascript libraries for data
> visualization like d3js.org, which we have done some experimenting with
> here at OSRF.
>
> --
>
>
> On Wed, Jun 25, 2014 at 1:05 PM, Vincent Rabaud <vincent.rabaud at gmail.com>
> wrote:
>
> > At ROS Kong, some rQt on the web was demoed as well as a Gazebo web
> > visualizer.
> >
> > I am no expert in web programing but what prevents us from moving rQt and
> > RViz to the web/javascript ? The obvious advantages would be
> cross-platform
> > support, optimizations independent of the underlying libraries, easier
> code
> > to debug, no compilation. Plus, there are already great tools like
> > robotwebtools and rosbridge.
> >
> > Here are a few reasons I was told that could prevent that move; are those
> > really valid ? Are there better reasons ?
> > - hard to access local files (html is not aware of local files)
> > - no customizable shaders in WebGL (is that the case ? do we need those
> ?)
> > - slow JSON parsing libraries (aren't those optimized in recent browsers
> ?)
> > - heavy bandwidth usage (how about binary JSON ?)
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at lists.ros.org
> > http://lists.ros.org/mailman/listinfo/ros-users
> >
> >
>
>
> --
> William Woodall
> ROS Development Team
> william at osrfoundation.org
> http://wjwwood.io/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ros.org/pipermail/ros-users/attachments/20140625/b1b518c9/attachment-0002.html
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140630/1289e93c/attachment.html>