passthrough (deprecated)
[Drivers]
- Deprecated:
- This driver is probably no longer needed, since a driver can now require a remote driver directly in the configuration file.
passthrough
driver acts as a client to another Player server; it returns data generated by the remote server to client programs, and send commands from the client programs to the remote server. In this way, one Player server can pretend to have devices that are actually located at some other location in the network (i.e., owned by some other Player server). Thus, the passthrough
driver makes possible three important capabilities:- Data from multiple robots can be aggregated in a single Player server; client programs can then talk to more than one robot through a single connection.
- Computationally intensive drivers can be moved off the robot and onto a workstation. Client programs connect to the workstation rather that the robot, but are otherwise unchanged.
- When working with Stage 1.3.x, you can use sophisticated drivers, like amcl and vfh by instantiating them in a second copy of Player, and passing through data and commands for the simulated devices. See the below for some examples of the
passthrough
driver in action.
- Compile-time dependencies
- none
- Provides
- The
passthrough
driver will support any of Player's interfaces, and can connect to any Player device.
- Requires
- none
- Configuration requests
- This driver will pass on any configuration requests.
- Configuration file options
passthrough
driver needs the full address of the remote device which is a tuple host:port:interface:index. The interface is determined with the normal "provides" syntax. Specify the remaining parts in the configuration file:
- remote_host (string)
- Default: "localhost"
- Hostname of the remote device
- remote_port (integer)
- Default: the port being used by this instance of Player
- TCP port of the remote device
- remote_index (integer)
- Default: the index of the passthrough device
- Index of the remote device
- access (string)
- Default: "a"
- The access to be acquired ("r", "w", or "a")
- Example: Controlling multiple robots through a single connection
passthrough
driver can be used to aggregate devices from multiple robots into a single server. The following example illustrates the general method for doing this.
- Imagine that we have two laser-equipped Pioneer robots named
bee
andbug
. On each robot, start a Player server with the following configuration file:driver ( name "p2os" provides ["odometry::position:0"] ) driver ( name "sicklms200" provides ["laser:0"] )
- Now imagine that we have a workstation named
orac
. On this workstation, start another instance of Player with the following configuration file:A client connecting todriver ( name "passthrough" provides ["position:0"] remote_host "bee" remote_port 6665 remote_index 0 access "a" ) driver ( name "passthrough" provides ["laser:0"] remote_host "bee" remote_port 6665 remote_index 0 access "r" ) driver ( name "passthrough" provides ["position:1"] remote_host "bug" remote_port 6665 remote_index 0 access "a" ) driver ( name "passthrough" provides ["laser:1"] remote_host "bug" remote_port 6665 remote_index 0 access "r" )
orac
will see four devices: two position2d devices and two laser devices. Both robots can now be controlled through a single connection toorac
.
- Example: Shifting computation
- Imagine that we have a robot named
bee
. Onbee
, run the Player server with this configuration file:The robot is assumed to be a Pioneer with a SICK laser range-finder.driver ( name "p2os" provides ["odometry::position:0"] ) driver ( name "sicklms200" provides ["laser:0"] )
- Now imagine that we have a workstation named
orac
. On this workstation, start another instance of Player with the following configuration file:(See the documentation for the amcl driver for a detailed description of the additional setings for that driver.) Clients connecting to this server will see a robot with position2d, laser and localize devices, but all of the heavy computation will be done on the workstation.driver ( name "passthrough" provides ["position:0"] remote_host "bee" remote_port 6665 remote_index 0 access "a" ) driver ( name "passthrough" provides ["laser:0"] remote_host "bee" remote_port 6665 remote_index 0 access "r" ) driver ( name "amcl" provides ["localize:0"] requires ["position:0" "laser:0"] .... )
- Example: Using the amcl driver with Stage 1.3.x
passthrough
driver. The basic procedure is as follows.
- Start Stage with a world file something like this: Stage will create one robot (position device) with a laser, and will start a Player server that listens on port 6665.
... position (port 6665 laser ()) ...
- Start another Player server using the command where the configuration file
player -p 7000 amcl.cfg
amcl.cfg
looks like this (see the documentation for the amcl driver for a detailed description of the additional setings for that driver):The second Player server will start up and listen on port 7000; clients connecting to this server will see a robot with position2d, laser, and localize devices.driver ( name "passthrough" provides ["position:0"] remote_host "localhost" remote_port 6665 remote_index 0 access "a" ) driver ( name "passthrough" provides ["laser:0"] remote_host "localhost" remote_port 6665 remote_index 0 access "r" ) driver ( name "mapfile" provides ["map:0"] filename "cave.pnm" resolution 0.03 negate 1 ) driver ( name "amcl" provides ["localize:0"] requires ["odometry::position:0" "laser:0" "laser::map:0"] )
- Author:
- Brian Gerkey, Andrew Howard