
Home
FAQ
Player
Stage
Gazebo
Contrib
Documentation
Publications
Contributors
Users

passthrough
[Drivers]

The 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

The 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

The 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 and bug. 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:


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 "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"
)

A client connecting to orac will see four devices: two position devices and two laser devices. Both robots can now be controlled through a single connection to orac.

Example: Shifting computation

Computationally expensive drivers (such as amcl) can be shifted off the robot and onto a workstation. The basic method is a straight-forward variant of the example given above.

Imagine that we have a robot named bee. On bee, run the Player server with this configuration file:
```
driver
(
  name "p2os"
  provides ["odometry::position:0"]
)
driver
(
  name "sicklms200"
  provides ["laser:0"]
)
```
The robot is assumed to be a Pioneer with a SICK laser range-finder.

Now imagine that we have a workstation named orac. On this workstation, start another instance of Player with the following configuration file:
```
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"]
  ....
)
```
(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 position, laser and localize devices, but all of the heavy computation will be done on the workstation.

Example: Using the amcl driver with Stage 1.3.x

Some newer drivers, such as the amcl and vfh driver, are not supported natively in Stage. For these drivers users must employ a second Player server configured to use the passthrough driver. The basic procedure is as follows.

Start Stage with a world file something like this:
```
...
position (port 6665 laser ())
...
```
Stage will create one robot (position device) with a laser, and will start a Player server that listens on port 6665.

Start another Player server using the command


  player -p 7000 amcl.cfg

where the configuration file amcl.cfg looks like this (see the documentation for the amcl driver for a detailed description of the additional setings for that driver):


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"]
)

The second Player server will start up and listen on port 7000; clients connecting to this server will see a robot with position, laser, and localize devices.

Authors

Brian Gerkey, Andrew Howard

Generated on Tue May 3 14:16:12 2005 for Player by

1.3.6

passthrough [Drivers]

passthrough
[Drivers]