ROS / Player Integration
This page is intended to capture tips and techniques for integrating Player and ROS. For the most part, the intent is to use Player drivers within a ROS system.
Example and patterns
There are several packages that use Player driver code:
- hokuyo: code was extracted from the Player 'urglaser' driver
- 3dmgx2_driver: code was extracted from the Player 'microstrain3dmg' driver
- erratic_player: uses the Player 'erratic' driver directly, by bringing up a dummy Player server in-process
- wavefront: code was extracted from the Player 'wavefront' driver
- amcl: code was extracted from the Player 'amcl' driver
The last two are probably of less interest because they're algorithms rather than hardware drivers, but you get the idea.
The work involved in adapting a Player driver to ROS depends largely on how the driver is structured. Patterns seen so far:
- If the driver is a standalone library with thin Player bindings (e.g., urglaser), then it's just a matter of writing new ROS bindings to the library.
- If the driver is a standalone library but with a non-trivial state machine implemented as part of the Player bindings (e.g., amcl), then that state machine will have to be reconstituted in the ROS bindings.
- If the driver is a tangled mess of functionality and Player interactions (e.g., erratic), then the best course of action may be to create a Player server in-process, instantiate the driver, and interact with it by passing messages through Player's Device API. For the most part, you're just translating between ROS messages and Player messages.
Option (3) is the least elegant, but is also pretty easy, and can be a good way to get started. erratic_player is an example of this kind of reuse.
