Revision history [back]

I feel this is a reasonable question since I had a similar question at first.

I leave the thorough, theoretical answer to @DimitriProsser's. Instead I would response this way; citing your example, move_base doesn't even want to specify how you input costmap, but instead it leaves up how you want to achieve to you. So in your concrete class where you're responsible to implement initialize (and some others), you input costmap however you want (using topic or service or whatsoever).

I feel this is a reasonable question since I had a similar question at first.

I leave the thorough, theoretical answer to @DimitriProsser's. Instead I would response respond this way; citing your example, move_base doesn't even want to specify how you input costmap, but instead it leaves up to you how you want to achieve to you. the task. So in your concrete class where you're responsible to implement initialize (and some others), other required functions), you input costmap however you want (using topic or service or whatsoever).

I had a similar question at first.

I leave the thorough, theoretical answer to @DimitriProsser's. Instead I would respond @DimitriProsser's and instead this way; citing your example, is just my opinion. (As far as I've seen though) many API of ROS stacks provide data types (by msg system) they require, but don't really restrict procedure. move_base doesn't even want to specify how you input costmap, but instead it leaves up to you how you want is the one exception where the common procedure/logic to achieve the task. So in your concrete class where you're responsible necessary task is already figured out and also implemented as a framework by using pluginlib.

This deviates the topic but this seems to implement me similar when web application framework (initializestruts (and some other required functions), you input costmap however you want (using topic etc.) appeared. They tend to call those common procedure as "business process" or service something. I assume sooner or whatsoever).later (or even now) this kind of "procedure framework" will increase in ROS too (I'm still new to robotics so correct/inform me please)?

I had a similar question at first.

I leave the thorough, theoretical answer to @DimitriProsser's and instead this is just my opinion. (As far as I've seen though) many API of ROS stacks provide data types (by msg system) they require, but don't really restrict procedure. move_base is the one exception where the common procedure/logic to achieve the necessary task is already figured out and also implemented as a framework by using pluginlib.

This Btw this deviates the topic but this seems to me similar when web application framework (struts etc.) appeared. They appeared, when there was very flexible ways to build web application but less framework so developers had to write their own logic every time. People in web development tend to call those common procedure as "business process" or something. I assume sooner or later (or even now) this kind of "procedure framework" will increase in ROS too (I'm still new to robotics relatively, so correct/inform me please)?