[concert_service_manager] concert_service_manager should accept service parameters via msg when enabling a message

[piyushk]

I'm porting our scenario (multi-robot human guidance) to the concert framework for the first demo. Our code was pretty modular, and should be relatively easy to port. I intend to get one of the services to spawn and kill 2 other services as necessary, the only catch being that it needs to spawn one of those 2 services with a particular parameter set.

I intend to submit a PR where a user can optionally point to a different parameter file in the Enable Service request (than the one supplied with the original service specification).

I'm going to continue porting code over, and implement this change when I get to it. Please let me know if there is a better way to get this functionality.

[stonier]

We did some work along these lines earlier. If memory recalls you could configure the service in the creation of a solution with an overriding parameter file. When you enable the service it will use that one instead of it's original. I'll check this after a meeting this morning and get back to you.

[stonier]

Babbler concert does this - it takes the original chatter service and overrides a few things:

• babbler.concert
• concert launcher
• loaded services - this lists the services that get started with babbler concert, variables and the location of any overrides.
• parameter overrides

[piyushk]

I don't think this is directly applicable to my use case. One of my services cycles through enabling and disabling other services, depending on whether a user is interacting with it or not. Every time the second service is enabled by the first service, the second service needs to be provided with parameters containing that new user's credentials. A static parameter override won't cut it.

I have a workaround for this right now, since all my services are communicating with one another anyway. I just set the necessary parameters for the service that is going to be spawned, and then spawn that service without setting those parameters. I'm not sure if this is the best way of handling parameters, but it works quite well.

[stonier]

Ah, I see. That workaround should work. However it does raise a good point for discussion that we've had quite a few times here. We've designed this first iteration of these service blocks to be independent of each other, i.e. they shouldn't be aware of each other at all. Since they are in the same ros workspace though, they can of course secretly communicate with each other across pre-arranged parameters or topics that aren't reflected in any solution configuration as you are working around with here. This is not especially good though since it introduces a hidden dependency that is not reflected in the infrastructure anywhere (i.e. black magic).

From another angle, you could say the services are not completely independent. You get indirect communications, e.g. across a shared map, or in a shared world canvas style database.

I'm not sure I want to move to the idea of having interacting, dependent services. It's a bit of a pandora's box, but it's probably possible (c.f. linux init.d services which can put down dependencies on other services).

For now, if I find myself actually wanting services to interact, I tend to bring that back to a single service and modularise inside the service.

[stonier]

@jack-oquin do you have any particular thoughts on this?

[piyushk]

My non-concert solution uses a roslaunch python wrapper to launch that second service. I could use the same logic and pull in that second service as a module of the first service, and avoid this black magic. I'll still be spawning a gazebo service as necessary. There is a bit of black magic communication happening between the first service and gazebo, but I can get easily get rid of that black magic.

Would you prefer that I do something like that? I'm primarily writing this code for the upcoming demo, and would prefer to stick to something that follows the current concert structure.

[stonier]

Priority is upcoming demo....we certainly don't have time to remodel services before the demo and it would be good to think/talk this out a bit before ping ponging on any work.

[piyushk]

Ok. My code is pretty modular, so it takes a few lines of code to switch one an internal launch to a service launch. In any case, I'll figure out the fastest way for getting the demo up and running (with instructions).