search

osrf / capabilities

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

Make roslauncher for providers with dependencies optional #33

Closed bit-pirate closed 10 years ago

bit-pirate commented 10 years ago

For implementing multiple caps made available by just one node/launcher (see #22 ), it might be need to implement many stubs (providers with empty launchers). This doesn't play nicely with the capability server's rules to consider a capability shut down, when the launcher shuts down.

For now, I implemented a simple node, which does nothing to keep the launcher alive.

Could we make the launcher optional, if the provider depends on another interface? The state of that provider would then be determined by the state of its dependency.

wjwwood commented 10 years ago

Do these not do what you want?

https://github.com/osrf/capabilities/commit/0c5a259e86f9527195bb0fc43bf7b5255afc716c https://github.com/osrf/capabilities/commit/b157ae237223cfb0a7fbf9c867d5fe8273d19c30

wjwwood commented 10 years ago

bump, I think these commits address your needs, can you confirm and close if that is true?

bit-pirate commented 10 years ago

Confirmed. Thanks!

bit-pirate commented 10 years ago

Just noticed the warning and wonder, if it is needed.

[WARN] [WallTime: 1383741783.578927] Provider 'kobuki_capabilities/kobuki_led1' does not have a launch file, running a placeholder.

This will often be an intended situation, in which I wouldn't want this being a warning. Switch to info or debug?

wjwwood commented 10 years ago

Adjusted in 79a7a79

bit-pirate commented 10 years ago

Thanks!