• Robot Motion
  • CFG Files
  • WORLD Files
















Robot Program: laserobstacleavoid
Configuration file: simple.cfg
Robot Program: randomwalk
Configuration file: everything.cfg
Robot Program: sonarobstacleavoid
Configuration file: everything.cfg

Randomwalk

Player is a server running on a robot providing access to hardware and sensors to remote programs. main() initializes values proxy pointers such as the LaserProxy and SonarProxy pointers. A try / catch block is executed for error handling. The catch block handles possible errors and terminates the program if necessary. The real work is done in the try block which is partitioned in the following programming steps.

1. Establish connection
...is accomplished with PlayerClient robot(gHostname,gPort). PlayerClient establishes a connection to the Player server on the local machine by constructing a client object usually called robot with a host and and a port number
2.Subscribe device(s)
...is accomplished by proxies such as Position2dProxy pp(&robot,gIndex and ore SonarProxy(&robot, gIndex). The object, robot, is used to as an argument to the constructor proxies for controlling mobile robot movement in the dimension space.
3. Read Sensory Data
... initializes proxies to NULL and then creates the necessary proxies such as, SonarProxy. Once established proxy objects, provide a continuous stream of buffered readings to the robots' control program. The Player client continuously updates and processes the reading by the robots' device proxy objects.
4. Processing
... the Read method is called within an infinite read-think-act loop which passes program control to function to process proxy readings. Some proxies like the robot's sonar, provide access to its reading by an array. The proxy reading are followed by condition statement to determine whether or not an obstacle is in the robot's path. The proxies settings are adjusted to indicate how close an obstacle has be to the robot to be considered an obstacle. Once a obstacle is detected code is written to evade the obstacle by adjusting wheel speed and turn radii.
5.Send motor command
Obstacle in robots path: The previous step calculated wheel speed and turn radii parameters to avoid obstacles. These parameters are passed to wheel proxies such as Position2dProxy to move the wheels in a manner to avoid obstacles. After the the avoidance parameters are set the program is at the bottom of Processing (or the infinite read-think-act) loop and repeats. Obstacles not in robot's path: The previous step calculated wheel speed and turn radii parameters to when there is not an obstacle to avoid. The parameters used when there are no obstacles to avoid are usually different from the parameter calculated to avoid obstacles. These parameters passed to wheel proxies maintain the robot on a straight path and at a higher speed.
Summary
These five steps summarize the basic flow of robot control and have been used to describe the program randomwalk.cc which, attempts to avoid obstacles by setting parameter: speed to 0 and yawing either -40 or 40 degrees. When an obstacle is not in the robot path, the robot moves forward at speed .200 and yaws randomly between -20 and 20 degree every 3 seconds. Laserobstacleavoid and sonarobstacleavoid work similarly.




The configuration files instantiates the drivers needed to control the robot and tells the drivers how to access the hardware. The *.cfg files map physical devices to Player devices. The file is composed of one or more driver sections, each of which instantiates and configures a single driver. What follows is a list of keywords and an inline comments / documentation which will help in understanding how everything.cfg works

plugin: The name of a shared library (plugin) that contains the driver. Loaded before attempting to instantiate the driver.
provides: The device address(es) through which the driver can be accessed. This option is mandatory.
requires: The device address(es) to which the driver will subscribe.
alwayson: If 1, then the driver will be setup when the player server starts, without waiting for any client connection.
model: the name of a Stage position model that will be controlled by the interface. Stage will search down the tree of models starting at the named model to find a previously-unassigned device of the right type.
worldfile: the filename of a Stage worldfile. Player will attempt to load the worldfile and attach interfaces to Stage models specified by the "model" keyword.




For Player to work in simulation mode Stage requires two configuration files: Stage .world file and the previously mentioned Player .cfg file. The .world file defines the simulated world, it tells Stage about sensors and actuators to be simulated, as well as background image to load, etc. Stage documentation is incomplete. Finding information on the keywords is tedious.

interval_sim: the length of each simulation update cycle in milliseconds.
interval_real: the amount of real-world (wall-clock) time the simulator will attempt to spend on each simulation cycle.
resolution: The resolution (in meters) of the underlying bitmap model. Larger values speed up raytracing at the expense of fidelity in collision detection and sensing.
Include: file which contains the definition of a particular type of robot or map or floorplan
size[x,y]: size of the window in pixels