App Platform Proposal

• Proposers: Daniel Stonier, Jihoon Lee

• Deadline: xxx 2013

We'll call a live meeting if there is sufficient need for it, otherwise conclusions from the dialogue below will do.

Make sure to subscribe if you would like email-notification of updates to this page.

Outline

Most of what we are planning will probably be familiar to people who got comfortable with the turtlebot and pr2 app platform design. The pairing of apps between robot and android is a really convenient way to connect and retask your robot. We'd like to advance the concept and also extend it to handle multi-robot frameworks.

So here we will outline a clear set of ideas relevant to the app platform. Just to get the ball rolling, a more detailed sketch illustrating how we might design for pairing and concert modes, and a bit on capabilities.

Target

Land it on Turtlebot for Hydro.

Definitions

So we're all on the same page:

• Rapp : a robot/rocon app (not to confuse with smart phone apps).

• Gateway : the object connecting local and remote ros systems.

• Connection : any ros pub/sub/service/action_client/action_server

• Advertising : offering to publicly share a connection with other ros systems

• Flipping : directing a single connection to a remote ros system.

• Platform Tuple : a string expressing the platform that is running (e.g. linux.ros.turtlebot)

Use Cases

• Retaskable Robot : such a robot would be connected to a repository of robot apps that can be automatically installed/upgraded (along with all the robot software) and relaunched simply by picking up a tablet, connecting to the robot and choosing from among a list of available tasks (applications). This would target both developers and users. Also the convenience of its use has already been stamped with approval from both groups on turtlebot and the pr2.

• Human-Robot Pairing : a tablet and a robot working in unison are far more interesting, versatile and usable than a standalone robot with the occasional hard link back to a computer. Configuration and diagnostics are much simpler and human assisted tasking opens up more possibilities than autonomous tasking.

• Intelligent Building : connect robots, pc's, devices, humans (tablets) and the cloud together. In this scenario, the appable concept can also apply with usefulness to non-robot entities by providing a structured public interface for autonomously connecting and retasking the robot, device or tablet. If there is such structure, then a centralised solution can start co-ordinating these entities in useful ways.

• Robot with Apps : encourage software development by non-robotics and non-control developers by providing a simplified interface at the app level for writing robotic software.

Design

Goals

• Platform_G00 : flexible and practical solution for robots, pc's, and devices
• Platform_G01 : don't expose the internal ros master (security)

• Platform_G02 : don't expose all internal topics (security & simplification)

• Platform_G03 : a workflow for convenient robot control from a tablet (1-1).
• Platform_G04 : a workflow for convenient robot control from a multi-robot-device solution.

• Platform_G05 : remotely manage and automate software & dependency installation/upgrades

• Platform_G06 : robust & configurable external connections.

• Rapp_G00 : rapps and user interfaces to rapps should be easy for humans to understand/utilise
• Rapp_G01 : provide launchers and configuration for a particular 'task'.
• Rapp_G02 : specify public/private interfaces for the launched environments.
• Rapp_G03 : specify underlying dependencies in a simple and portable way.
• Rapp_G04 : allow multiple implementations of a single rapp specification.

With regards to G04, a single rapp might be to pick up a cup, but that may be provided by several different implementation, e.g. pr2 and justin implementations may be wildly different, but still represented by the same rapp.

Implementation Decisions

• Platform_D00a : provide an implementation in python that would suit 95% of robots (customise embedded or cross platform versions later).
• Platform_D00b : platform tuples to classify what rapps it can support.

• Platform_D01-02 : use the gateway model for multimaster connections.

• Platform_D03-04: merge 1-1 and multi-robot control mechanisms as much as possible (design sketch).

• Platform_D03 : 1-1 control via pairing mode.

• Platform_D04 : multi-robot control via concert mode.

• Platform_D05a : automate sw installation/upgrade checks when starting a rapp.
• Platform_D05b : advertise install/uninstall handles for rapps only.
• Platform_D05c : manage android app installation side from the robot side automatically in paired mode (~turtlebot).
• Platform_D05d : abstracted rapp repository that utilises packaging infrastructure suitable for the particular platform (e.g. apt-get in ubuntu, app markets in iphone/android), start with ubuntu apt-get and bloom.
• Platform_D05e : provide an option for pre-installed local and installable remote rap repositories, with a flag to disable the remote rap repositories if a fixed platform is preferred.
• Platform_D06 : pending next gen ros comms design.
• Rapp_D00a : some simplified metadata for humans (e.g. icons)

• Rapp_D00b : call them rapps (robot/rocon apps) so as not to confuse with android apps.

• Rapp_D01 : keep them as metapackages only (i.e. no code)?

• Rapp_D03 : use capability rule mappings as really roughly introduced here

• Rapp_D04a : federated rapp repositories, i.e. single rapp meta-repository & multiple (varied) package repositories

• Rapp_D04b : aim for binary package repositories native to the underlying system.

Comments/Issues

Rapps as Metapackages

Could potentially be simpler if we just define rapps as metapackages only. i.e. they don't include any code, just launch and public interface rules [Daniel].

Optimising

[Daniel] I feel the best target to aim for is one which satisfies most use cases easily. Optimal versions of the app manager can be written later for other platforms. There are areas here where it might be optimised, e.g. pairing mode's private robot master doesn't really need a gateway - direct master sync'ing is probably enough. But we introduce more complexity into the app manager then and I don't think the bang is worth the buck (at least not initially and especially before next gen comms).

• [Piyush] Agreed about the complexity bit. I am slight confused about this point though. As far as I understand from the design docs, each robot has a private master and a public master - are you talking about the sync between these 2 masters?

  • [Daniel] yes, you could just do direct registrations. You wouldn't need discovery like we do with the redis server, nor gateways to firewall connections, but that means the syncing for paired mode and concert mode would be totally different. Easier just to keep them the same, especially if we have to upgrade the way communications work in the near future.

Web App Manager

I haven't made any mention yet to managing web apps or running a web app manager. We could introduce that early into the design here. Or we could postpone that to the next iteration.

• Web bridge(or bridge of rosbridge) implementation is needed to handle web apps. We may discuss after this. Would it be necessary in near future? [Jihoon]

• Also, Would Web App be similar to Android apps? If app_platform is to handle rapps, Web App can be discussed in other place. [Jihoon]

• I am hoping we can slip it in to this design quite easily. For 1-1 pairing, a web app version of the master chooser could connect to the public master and utilise the start/stop app handles similarly. Only instead of sending the name of an app to install back to the web app user, they get a url to the app (served by the robot?). A web concert client (concert mode) will need a bit more thought and a totally different implementation, but I think we can ensure that it follows the same/similar specifications [Daniel].

Rapp installation management

• [ Jihoon ] One of our goal is that Rapp manager can install/remove Rapps upon the request from concert master. Desirably Android apps as well. Should we include this feature?

  • [Daniel] Yes, added

• [Piyush] Is the Rapp installation procedure only allowed to install system dependencies? Any thoughts on handling test/unpublished code in a rapp workspace?

  • [Daniel] We actually did this previously by having the application package paths in a source workspace and flagging it as a pre-installed rapp. I'd probably be keen on having this functionality still there. Does that fit your use case that you have in mind?

    • [Piyush] Yes. I think this should be more than sufficient. I think we'll have a common sandbox repository that people can commit too and I'll write a few scripts to sync up all the robots to the updated code.