search

osrf / capabilities

Implements the concept of capabilities as part of the robots-in-concert system.
Other
8 stars 26 forks source link

Thoughts on the Specifications #1

Closed stonier closed 10 years ago

stonier commented 11 years ago

Remappings for non-public interfaces

Looking at the nav stack provider specifically here. It defines a remapping for the scan interface. Is that a remapping for itself or for the LaserObservation dependency?. In the former case, since that is a non-public interface, couldn't/shouldn't that be covered by the provider's launch file? In the latter case, wouldn't the LaserObservation provider (hokuyo_base) handle it?

Interfaces

Is there a reason you classify like this instead of explicitly pub, sub, service? I'm not opposed to it, just curious. I should make sure to adopt a similar approach to defining interfaces through other components like the gateways and rapps.

Will this be accommodate or simpler to break it down to topics?

By dynamic_reconfigure or as a todo idea?

Just trying to imagine what this would look like. Questions, e.g. would it be re-using the launch file provided by a regular camera provider?

stonier commented 11 years ago

Launching Capabilities with Apps via the App Manager Workflow - will follow up in a separate issue later today.

bit-pirate commented 10 years ago

I guess, it's time to follow-up on this.

I see there is already a stub in the docs: http://docs.ros.org/hydro/api/capabilities/html/capabilities.specs.html Where should we develop those specs? ROS wiki? RSTs?

What about creating a separate package for the capability specs, such as std_capabilities or std_caps, in this repo?

My suggestion for the first specs we implement:

@wjwwood @mikeferguson any others you can think of?

mikeferguson commented 10 years ago

Arm stuff is still quite undefined, and so I think we should avoid that for now. One other thing I could think of is a pointable sensor head (for instance, a wrapper around control_msgs/PointHead -- along with what sensors get pointed by it). Not entirely sure what this one would look like.

wjwwood commented 10 years ago

I have the beginnings of std_interfaces, but I am open to suggestions on the name.

I am currently focusing on these capability interfaces/providers for the turtlebot2:

I am trying to keep the rgdb_fake_laser_sensor and freenect_rgdb_sensor providers turtlebot agnostic, but I might have to wrap them in turtlebot specific providers to handle things like nodelet manager names (this might not be an issue, still exploring it).

Again, these are just preliminary, all of the names are up for debate.

wjwwood commented 10 years ago

@mikeferguson I will try to look into the pointed head stuff, but realistically it could be a few weeks before I branch outside of the interfaces and providers I have listed above.

wjwwood commented 10 years ago

@bit-pirate This http://docs.ros.org/hydro/api/capabilities/html/capabilities.specs.html is for the spec parsing API, not a list of specs that will be provided. Sorry for the confusion. I don't intend to ship any interfaces or providers with the capabilities package.

I think the development of those specs should go into packages which will hold them and discussion can happen on github or in the ros wiki.

wjwwood commented 10 years ago

I'll update this repo when I get it in a good state:

https://github.com/osrf/std_interfaces

We can easily more the organization later (github does nice redirects now).

mikeferguson commented 10 years ago

@wjwwood Once you get a few examples in there, I can certainly help to define some others, and also test out the Turtlebot ones on that other robot...

bit-pirate commented 10 years ago

For the name I'm fine with std_capabilities. I only added the abbreviation, since we already use it for messages and services.

Once the specs are up, I'll look into setting up TB1 and TB2 providers for DifferentialMobileBase and Navigation2D and also real and fake providers for LaserSensor.

The laser sensor can be used as a good example for multiple providers.

wjwwood commented 10 years ago

FYI, Here is the start of a set of standard interfaces:

https://github.com/osrf/std_capabilities/tree/initial_specs/interfaces

This is by no means a complete list of things which should be there, nor are the ones there even close to done, but I have been using these as my base line for testing and putting together demos. They are in the initial_specs branch because I would like to do a more formal review (via pull request) of each spec before placing it, even initially, into the master branch.

wjwwood commented 10 years ago

I have been working on some preliminary turtlebot2 capabilities and providers here:

https://github.com/osrf/turtlebot2_capabilities

Again, by no means complete or correct, but merely what I've been using as a proof of concept.

wjwwood commented 10 years ago

Now that we have repositories setup for discussion of standard interfaces and examples of usage in the turtlebot2_capabilities repo, I am going to close this issue. We should move the discussion to the correct repository's issue tracker and open new issues here when we have actionable items with respect to the specifications.