App Platform proposal - use cases

[Michael Gratton]

Hi,

I haven't seen any use cases for the app manager put forward, and it
might be useful discussing them to clarify what features and
requirements really are necessary for an App Manager v2.

Two quickly come to mind:

1. Anne is a roboticist working on a custom robot(s) at [home|work] and
wants to provide a way to both easily control its standard features
(i.e. teleop), but also provide a way to control its unique, custom
features (i.e. the onboard espresso machine). She has full control of
the hardware and software platform, and can install/upgrade software
packages as needed.

2. FooRobots Corp is mass producing a line of robots with identical
configuration and hardware capabilities that are being marketed at
people who are not roboticists. Customers can peer under the hood, but
that voids their warranty. It wants:
(a) To develop custom apps that allow customers to control the robot's
standard features and ship them on all robots by default via a standard,
immutable software image.
(b) To encourage third party developers to develop additional, custom
apps for its robots and provide a way for these to be easily installed
from its own app store.

There's probably a bunch of others. Anyone?

From these two perspectives, we can look at the goals and implementation
decisions at
<http://ros.org/wiki/rocon_app_platform/Reviews/App%20Platform%20Proposal>
to see if they make sense. So:

- Platform_G00 to Platform_G04 and Platform_G06 seem fine in the context
of both use cases.
- Platform_G05 makes sense only for use case (2b) and only for the
deployment part. The dependency installation/upgrade part is in direct
conflict with (2a). A useful analogue here is phone apps - nearly all
developers work with only what the standard platform provides, without
being able to modify the system to e.g. install a system-wide 3rd party
library.

- Rapp_G00 is important in the context of both use cases, but mostly for
(2a).
- Rapp_G01 seems unnecessary in the context of Rapp_G00 for (1) and for
(2) is probably redundant.
- Rapp_G02 seems fine for both.
- Rapp_G03 is unnecessary for both (1) and (2)
- Rapp_G04 seems to have been truncated in editing.

- Platform_D05(a,b,c,d) is unnecessary for both (1) and (2).
- The others seem fine.

- Rapp_D03 and Rapp_D04 both seem to be unnecessary for (1) and (2).
- The others seem fine.

A few things see, missing:

- Similar to Platform_D00a, provide some default rapps for common
functionality (i.e. teleop) for the case of (1)
- Ensure that in developing rapps that provide a UI, that they can
follow the best practices and usability guidelines for the UI's platform
(i.e. no lowest common denominator approach to UI - probably making
Rapp_D00a redundant, also install, launch and use phone apps in the same
way as any other phone app, etc). This is useful for (1) but necessary
for (2).
- Provide a way for end users to operate rapp UI's without knowing
anything about ROS - necessary for (2)
- Provide hooks into app manager, but not necessarily a default
implementation, of a way to install new apps at run time. Runtime
installation is unnecessary for (1) and (2a), and (2b) will likely
entail a custom implementation anyway.

//Mike

--
Michael Gratton <mic...@quuxo.com>
Quuxo Software <http://quuxo.com/>

[Daniel Stonier]

On 22 March 2013 10:19, Michael Gratton <mic...@quuxo.com> wrote:

Hi,

I haven't seen any use cases for the app manager put forward, and it
might be useful discussing them to clarify what features and
requirements really are necessary for an App Manager v2.

Very good point - putting our use cases to paper slipped past me. I added a couple of our primary use case interests to the wiki.

 

Two quickly come to mind:

1. Anne is a roboticist working on a custom robot(s) at [home|work] and
wants to provide a way to both easily control its standard features
(i.e. teleop), but also provide a way to control its unique, custom
features (i.e. the onboard espresso machine). She has full control of
the hardware and software platform, and can install/upgrade software
packages as needed.

This one isn't such a big use case for us. Roboticists can generally tap into their robot at will anyway, so the extra layers don't really help them much, except for convenience. That is actually something we shouldn't ignore though. I remember Brian mentioning that once they had the tablet-robot pairing setup for pr2 at willow, many of the developers just dropped ssh'ing into the robots for simple tasks like teleop'ing th robot. The convenience of just picking up a tablet was really valuable.

We're trying to move away from thinking about robots and researchers to working out what is needed to successfully sell robotics though, so this use case has a lower priority for us.

 

2. FooRobots Corp is mass producing a line of robots with identical
configuration and hardware capabilities that are being marketed at
people who are not roboticists. Customers can peer under the hood, but
that voids their warranty. It wants:
(a) To develop custom apps that allow customers to control the robot's
standard features and ship them on all robots by default via a standard,
immutable software image.
(b) To encourage third party developers to develop additional, custom
apps for its robots and provide a way for these to be easily installed
from its own app store.

There's probably a bunch of others. Anyone?

We actually build robots of the 2a) and 2b) variety. Actually 2a) is still equally important to us and we already have some options in the current app manager (which we'll keep) to facilitate that. 

 

From these two perspectives, we can look at the goals and implementation
decisions at
<http://ros.org/wiki/rocon_app_platform/Reviews/App%20Platform%20Proposal>
to see if they make sense. So:

- Platform_G00 to Platform_G04 and Platform_G06 seem fine in the context
of both use cases.
- Platform_G05 makes sense only for use case (2b) and only for the
deployment part. The dependency installation/upgrade part is in direct
conflict with (2a). A useful analogue here is phone apps - nearly all
developers work with only what the standard platform provides, without
being able to modify the system to e.g. install a system-wide 3rd party
library.

- Rapp_G00 is important in the context of both use cases, but mostly for
(2a).
- Rapp_G01 seems unnecessary in the context of Rapp_G00 for (1) and for
(2) is probably redundant.
- Rapp_G02 seems fine for both.
- Rapp_G03 is unnecessary for both (1) and (2)

Simplifying the underlying dependencies is more of a technical goal. There are some limitations with the current way of doing things (see Fergs' email) and we'd also like to start getting software people more involved with robotics, so this may help.

 

- Rapp_G04 seems to have been truncated in editing.

Indeed, expounded on that some.

 

- Platform_D05(a,b,c,d) is unnecessary for both (1) and (2).
- The others seem fine.

- Rapp_D03 and Rapp_D04 both seem to be unnecessary for (1) and (2).
- The others seem fine.

A few things see, missing:

- Similar to Platform_D00a, provide some default rapps for common
functionality (i.e. teleop) for the case of (1) 

Already thinking about that, but didn't have that in the review, +1

 

- Ensure that in developing rapps that provide a UI, that they can
follow the best practices and usability guidelines for the UI's platform
(i.e. no lowest common denominator approach to UI - probably making
Rapp_D00a redundant, also install, launch and use phone apps in the same
way as any other phone app, etc). This is useful for (1) but necessary
for (2).

Not sure that we're really thinking about UI's for the robot apps a great deal. Definitely for UI's on the android end though. 

With regards to running phones just like any other apps, we're currently using and will probably continue to use something that is slightly different to a regular smart phone scenario. Rather than having to remember which app to start to connect from tablet to the robot, we use a general purpose robot connector application, which queries the robot for the library of rapps that the robot can run. These rapps define what will end up running on both the robot and the tablet. 

- Provide a way for end users to operate rapp UI's without knowing
anything about ROS - necessary for (2)

+1

 

- Provide hooks into app manager, but not necessarily a default
implementation, of a way to install new apps at run time. Runtime
installation is unnecessary for (1) and (2a), and (2b) will likely
entail a custom implementation anyway.

//Mike

Thanks for the input Mike.

Daniel.

 

--
Michael Gratton <mic...@quuxo.com>
Quuxo Software <http://quuxo.com/>

--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin R&D: http://rnd.yujinrobot.com/