ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
3

Questions on adapting an algorithm to work with multiple state-space configurations and releasing to the ROS community

asked 2017-03-09 08:59:44 -0500

dotcom gravatar image

updated 2017-03-09 09:02:42 -0500

Hello,

After successful development of an initial version of a multi-robot localization and object tracking algorithm, we have the desire to make it accessible to the ROS community. I have some questions regarding the best approach towards this goal.

Repository of our package: https://github.com/guilhermelawless/pfuclt_omni_dataset

Our algorithm is working currently in ROS indigo and kinetic, but only for a specific configuration of sensors and state-space configuration, as well as the map type (landmark-based). Due to the nature of the method (PF-based), it is not hard to adapt to multiple configurations of these. Here is a list of what we desire or have done:

  • Adapt to multiple 3D and 6D robot state-space configurations
  • Adapt to other motion models for robots and objects/targets
  • Adapt to use other kinds of maps (feature-based, occupancy grids as examples)

All robots should use the same configuration.

While we know that this is not easy to achieve, we would like to put effort into it. Our most important and yet unanswered question is the following, regarding implementation. I see 2 different paths we can take:

  1. Use of agnostic high-level virtual functions for the algorithm, which are then implemented in different classes (one for each robot configuration type, for instance). Developers can then implement their own configuration in this way.
  2. Make one implementation only, that then uses ROS parameters to decide which configurations to use.

1 will require compilation-time evaluation, so in order to provide many available configurations, either the user will have to compile themself, or we would provide many binaries (nodes) that run different configurations.

2 would be one binary only that takes many ROS parameters to decide what to run. This would mean a much bigger (in size) binary file, and perhaps become too confusing to use.

Has anyone developed something on ROS in the same fashion? That can take different robot configurations and observation models? We would be very interested in hearing their thoughts.

What would be the best approach with respect to sharing this implementation with the robotics community?

Thank you for your help.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-03-09 10:38:29 -0500

gvdhoorn gravatar image

updated 2017-03-09 11:25:32 -0500

I don't have a complete answer, but my first idea would be to look at plugins. They would allow you to find a middle-ground between your options 1 & 2, and is a fairly common / accepted ROS design pattern.See wiki/pluginlib for some info.

I'm not entirely sure what "robot configuration type" means, but if it involves executable code, then plugins could allow end-users to configure your 'main' binary with a bunch of plugins that it should load at runtime, with corresponding parameters.


Edit: look at stacks like navigation, nav2d and moveit for some example usages of pluginlib.

edit flag offensive delete link more

Comments

I would say this is worthy of a complete answer. I have been completely unaware of the existance of pluginlib, and it might be exactly what we need.

It all envolves executable code. I suppose there would be overhead in calling the classe's methods, we'll do some tests to check how much. Thank you!

dotcom gravatar image dotcom  ( 2017-03-09 11:08:27 -0500 )edit

(Almost) no overhead. It's basically pointer derefencing, which is negligable.

gvdhoorn gravatar image gvdhoorn  ( 2017-03-09 11:24:39 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2017-03-09 08:59:44 -0500

Seen: 110 times

Last updated: Mar 09 '17