Write up recent design discussions

[tfoote]

From the whiteboard and discussions

[wjwwood]

https://github.com/robotics-in-concert/rocon_planning/blob/master/capabilities.rst

@dirk-thomas and @tfoote, can you review what's there as I go along?

[stonier]

Some comments:

Rapps and Current Use Case : at the moment, our use of rapp is for any application which is managed by the robot (rocon) application manager. It would be the robot app manager's role to do the inferencing based on the rapp's requirements to decide whether this rapp is launchable or not yet. This would involve the rapp manager reading the rapp's specification wrt capability requirements, checking which capability providers are around (via a capability server?) and then deciding if that is runnable or not. The second part of the app manager's role would be in launching the rapp and also triggering whatever capabilities need to be launched.

Generalising : I don't see any reason why someone might not build another implementation to make use of capabilities. The question would be to determine if and what we might generalise immediately. Right now, the rapp manager design is such that only one rapp executes at a time, which means the idea of shared capabilities would not be needed. However, implementing the concept of sharing for capabilities could not only be useful in other contexts, but it might open up possibilities leading towards parallel rapp execution.

Who Handles Remapping?

I think in the described workflow, the suggestion is for rapps to tell the capability how to remap itself. We had a use case in mind working in the opposite direction - the capability provider informs the rapp where stuff is located and the rapp (or more specifically, the rapp manager) reorganises the rapp when it starts. This has the advantage in being able to design a capability layer on top of an existing robot (possibly one which boots into a pre-configured state) rather than designing the capability enabled robot from the ground up.

I think also if you lean towards shared capabilities, then the rapp can no longer dictate remappings, but it could certainly re-organise itself.

Capabilities can depend on other Capabilities??

I think your capability providers depending on capabilities as illustrated is indirectly doing this, no?

Only one instance of a particular Capability can be activated at one time

You mention this in the capabilities definition and worry about topic collisions. Perhaps thinking about capability providers which supply separate remap configurations (as I described above) can guarantee no topic collisions. Also, would two camera capabilities be unusual? Or should it be recommended if there are multiple capabilities to provide, then these should be classified semantically?

Semantic Capabilities

I like these, provides some very clear structure.

Capability Providers

I like these too - very clearly separates a capability specification from a capability provision.

[bit-pirate]

:+1: to shared capabilities for the future (not of high priority now) :+1: to rapps being remapped by the app/capability manager on start-up according to the information given by the capabilities (or their providers) :+1: to capabilities may depend on other capabilities

My comments:

Rapps/Capabilities

• I am missing the mentioning and explanation of the fact that capabilities enable the portability of rapps - in my eyes one of the biggest benefits of the capabilities concept. The mentioning of robot-agnostic hints the portability idea, but I'd like to highlight it (more).

Capabilities

• Only interface descriptions or does a capability include the software providing it?

Semantic Capabilities

• Wouldn't mentioned remappings, since that can already be done with/by normal capabilities
• Why may semantic capabilities not extend the parent capability?
• Maybe we should make use of both semantic tags and hierarchies with the later allowing extensions
• We might draw a line like this:
  • semantic capability: capability with a specific non-standard parametrisation (e.g. smooth navigation) and no extensions
  • inherited capability: provides all what its parent does (hence it can be used for the same purpose and in the same way) plus extensions which offer more or different functionalities
  • e.g. holonomic navigation: Plans paths for differential drives when used as navigation or allows sideways movements when used as holonomic navigation.
  • e.g. _self-collision free armnavigation: When used as _armnavigation plans paths which may lead to collision with itself and the environment. When used as _self-collision free armnavigation outputs collision free paths.

Capability Providers

• New name necessary? Why not just "software"? This goes back to the question, if capabilities are only interface descriptions.
• One provider may provide multiple capabilities, but only one can be used at a time.
  • e.g. both FrontCamera and Camera : The rapps can choose what they want, e.g. rapp doesn't care about details, it just takes Camera. If it does, it specifies the FrontCamera requirement.
• Exclusions: Maybe we not only need the required parameter for caps, but also "conflicts-with" to manage interfering requirements, e.g. OpenNI nodes/launchers.

[wjwwood]

First, we had a meeting yesterday to talk about your feedback Daniel, and I have been working on writing up the responses and capturing them in the design doc, but I will just try summarize some of the stuff we talked about here too.

Generalising : I don't see any reason why someone might not build another implementation to make use of capabilities. The question would be to determine if and what we might generalise immediately. Right now, the rapp manager design is such that only one rapp executes at a time, which means the idea of shared capabilities would not be needed. However, implementing the concept of sharing for capabilities could not only be useful in other contexts, but it might open up possibilities leading towards parallel rapp execution.

We believe that sharing Capabilities might occur in a single Rapp execution, for example:

  R
 /  \
N    P
 \  /
  K

Where R is the Rapp, N is Navigation, the P is people tracking, and K is the Kinect. This might be a contrived example, but we think that something similar will come up at some point.

Who Handles Remapping?

I think in the described workflow, the suggestion is for rapps to tell the capability how to remap itself. We had a use case in mind working in the opposite direction - the capability provider informs the rapp where stuff is located and the rapp (or more specifically, the rapp manager) reorganises the rapp when it starts. This has the advantage in being able to design a capability layer on top of an existing robot (possibly one which boots into a pre-configured state) rather than designing the capability enabled robot from the ground up.

I think also if you lean towards shared capabilities, then the rapp can no longer dictate remappings, but it could certainly re-organise itself.

Here we basically agree that it makes sense for the Rapps to reconfigure themselves rather than the Capability Interface, but we also think that Capability Providers still need to be able to remap a Capability Interface. I summarized that here:

https://github.com/robotics-in-concert/rocon_planning/blob/master/capabilities.rst#requiring-should-not-allow-remapping

Capabilities can depend on other Capabilities??

I think your capability providers depending on capabilities as illustrated is indirectly doing this, no?

The idea here is that a single Capability Interface might have different dependencies based on the implementation of the provider. Brian gave the example of Mapping as a Capability, which one provider might need a LaserObservation and one might be a static map server. By restricting the dependency on other Capabilities to Capability Providers, it simplifies the definition of the Interfaces. We believe that all cases can be modeled using Capability Provider depends on Capabilities relationships. There might be a need for a Capability extending another Capability, but we couldn't come up with a good example of how that would be used and provide significant benefit over having separate Capabilities.

Only one instance of a particular Capability can be activated at one time

You mention this in the capabilities definition and worry about topic collisions. Perhaps thinking about capability providers which supply separate remap configurations (as I described above) can guarantee no topic collisions. Also, would two camera capabilities be unusual? Or should it be recommended if there are multiple capabilities to provide, then these should be classified semantically?

Preventing topic collisions is, in our opinion, the responsibility of the robot developer (for Capabilities), but the robot developer really can't ensure this if Rapps can setup multiple copies of Capabilities with remapping. You could "ensure" this by using a global namespace to namespace everything rather remapping part of the interface (but not other topics hidden by the interface). There are cases where this is not what you want to do, e.g. you might want to remap everything but /cmd_vel for two instances of the same Capability.

[stonier]

Most of this looks good.

Sharing capabilities - :+1: I notice you guys are thinking about algorithmic capabilities now, not just hardware capabilities?

Remapping : reorganising rapps and cpability providers remapping a capability interface - :+1:

Capability dependencies and restrictions on capability providers: :+1:

Topic Collisions: I agree, topic collisions for capabilities should be the province of the robot developer. If the rapps only re-organise themselves (rather than provide remapping rules for capabilities) then I can't see any real issues with things like multiple capabilities if you work on the assumption that the robot developer is god - i.e. has setup capability providers correctly.

Some other points:

Capabilities Extensions: introduces some implementation complexity, but might ease work, eliminate redundancy, worthwhile?

Capability Providers: what do you foresee actually being the guts of this component? Marcus is asking about having a single capability provider handle multiple capabilities.

[wjwwood]

http://imgur.com/7O0vdjH