search

robotics-in-concert / concert_services

Official services supported by rocon.
0 stars 5 forks source link

Making gazebo as concert software #47

Closed jihoonl closed 9 years ago

jihoonl commented 9 years ago

@stonier, @piyushk Just thought about making gazebo_service as concert software. Since concert software is designed to provide modules which affect across concert, I think it would be more make sense to convert gazebo_service as gazebo_robot_spawner in concert software. So any service contacts gazebo robot spawner software to summon a simulated robot to use for their service.

How do you guys think about this? Would there be benefits to keep it as concert service?

piyushk commented 9 years ago

@jihoonl It looks like I'm behind on my concert terminology again. What do you exactly mean by concert software, i.e. "concert software is designed to provide modules which affect across concert"?

jihoonl commented 9 years ago

Hi @piyushk,

The definition of concert service is more like a programmed workflow that provides “experience” to users with allocated resources, interactions, and state machine(or workflow). And there is a constraint that services are independent to each others. So service instance can be developed with any framework(BPEL, Orc, ROS, or any).

Since services are not talking each other, concert software is introduced to utilise sharable components among services. For example, assumes there is a concert with robot delivery service, autonomous security service, and robot guide service. map_server which provides a building map would be useful for all three services. So here is where software comes in. Each services will request software farm a map provider software serves building map, then software farm spawns one map provider and returns the spawned software’s namespace to the requester(e.g - service).

The software farm implementation is in rocon_concert repository and concert_software_farm. And check out concert_service_indoor_2d_map_prep service as example.

Since gazebo is more than a service with meaning above, I think it would be nicer to make gazebo as software. It was workflow in my head.

untitled drawing

Hm.. actually never mind. My thinking is going back and forth whether it should be service or software. Gazebo Service is to simulate robots and environments for testing. It is not for supporting other service to run.

Well.. keeping it as concert_service seems fine. How do you think this?

stonier commented 9 years ago

A service shouldnt request gazebo or request gazebo to spawn a robot. That makes the service gazebo dependent. Ideally the same service should work with gazebo robots and also with real robots.

piyushk commented 9 years ago

I don't feel qualified enough to give comments on this thread at the moment. Please continue the discussion and take a decision as necessary.

While I've been writing independent services using the framework, I always end up writing one service that ties everything together by being aware of other services (which violates the framework design). I suspect that service needs to be written as "concert software". I'm going to be extremely busy over the summer, but as time permits I will try to switch to the correct design. I might have some input then.

jihoonl commented 9 years ago

Hm.. ok closing this for now.