Web Interfaces

SIG Coordinator: Sarah Osentoski

Topics: rosbridge, rosjs, wviz, heaphy, remote labs

Members:

• Brandon Alexander
• Sonia Chernova
• Matei Ciocarlie
• Christopher Crick
• Kaijen Hsiao
• Trevor Jay
• Chad Jenkins
• Nate Koenig
• Jihoon Lee
• Jonathan Mace
• Sarah Osentoski
• Bener Suay
• Russell Toris
• Hai Nguyen
• Phil Grice

Mailing List:

Description of and status of current projects

Description of current work packages and efforts

• New rosjs api: Brandon contacted us and was excited about the potential of the current web stuff but had suggestions about improving the API. A current draft of the API can be found at https://github.com/rosjs/rosjs. It can be tested and comments and improvements are most welcome. The goal is to eventually have the rosjs organization on GitHub be the place where the common web modules go.

• More modular components: One criticism of the current implementation is that the current monolithic remote_lab package has grown unwieldy. The web functionality should be separated into smaller components which users can mix and match depending on their project needs. For example, a user could install a separate transform frame Javascript module, or one that supports the Javascript Actionlib. These will also be hosted on the new rosjs GitHub organization.

• Hardening/Improving rosbridge: Up until very recently rosbridge was basically maintained and supported fully by Trevor as a side project from his normal contracting work. There have been efforts to improve some of the functionality of rosbridge including creating a test suite to help prevent some of the regression bugs that were getting introduced during new feature adds. Additionally we've been trying to work on getting rosbridge to send data more effectively.
• Fixing the install process of the current remote_lab stack: Currently even if you install through the debs you don't really have working web visualization. Our goal by the end of summer (that is almost fully achieved at this point) is to fix the install so that you just need to launch a file and open a web browser and will see web data.
• Getting a dynamic interface/module working for people to play with: Currently to add or change topics that are visualized people need to actually edit the .html code. However this isn't really necessary, Bener has been working on making a widget that will add and remove topics from the visualization scene. While he is doing this he has also been adding data types, such as laser scans etc and trying to improve the data visualizations where possible.
• Create necessary "server side" infrastructure to better handlelarge or special topics as needed: Possibilities include handling point clouds more effectively, maps, robot models/urdfs.

Description of new proposed framework

New proposed framework for Javascript Tools

The proposed framework is meant to be a modular set of ROS web components. The goal is for developers to only have to include the modules they need for their project. Each JavaScript module should be flexible and focused and adhere to JavaScript best practics. Modules include:

• ros.js - The new ros.js exposes topics, services, and params to the web app. It is meant to be a light-weight core for robot web apps. The new ros.js strives to to be friendly for web developers to understand and use.
• actionlib
• tf
• WVIZ
• Point clouds
• Video

While some of these components have existed previously in various repositories, as we port them to be more modular and standalone, the modules will reside under the GitHub organization https://github.com/rosjs.

Proposed new features

Deadlines

Hackathon Planning

Date: August 13-17th Location: Willow Garage

Potential Topics:

• Scavenger Hunt - You could have multiple types of robots looking for things throughout the environment and users helping them through webpages. There could be lots of different types of webpages including one people could check on to see the location of found objects and the status of the each robot or something like that?
• Hide-And-Go-Seek - You have one teleoperated seeker and the rest of the teleoperated robots have a couple minutes to hide. Then the seeker looks for the hiding robots. When a robot is found, it's re-enabled and can help find the remaining robots.