This is an introduction to the key abstractions used in the Pyro Robotics system. This module provides an exploration of the objects and their attributes, properties, and methods. When completed, the reader should be able to discuss the design of robotics controllers.

Overview of Pyro Objects

Pyro is written using object oriented programming (OOP) in Python. There are four main classes in Pyro: robot, brain, gui, and engine. This module will explore these objects and how they interact to form the core of Pyro.

pyrobot.robot

In order to do anything in Pyro, you will need a Pyro robot instance. All robot types are extensions of pyrobot.robot. The following table shows the names of robots and their corresponding simulator or hardware.

Pyro Robot Name	Pyro Simulator Name	Robot Hardware
PyrobotRobot60000	PyrobotSimulator	Pioneer family
Player6665, Player6666	StageSimulator, GazeboSimulator	Pioneer family, ER1, Khepera, B21R, etc.
Khepera, Hemisson	N/A	Khepera 1 and 2, Hemisson
KheperaSimulated	KheperaSimulator	N/A
Robocup, RobocupTeamA, RobocupTeamB	RobocupSimulator	N/A
IntelliBrain-Bot	N/A	IntelliBrain-Bot
Roomba	N/A	Roomba

Player also includes support for the Segway human transport, among others. There is also an API for controlling Fred Martin's Handyboard via a serial tether from Pyro. Researchers are also working on ports to Mac OS X and Windows.

Each simulator is actually a different process, and each one has its own method of talking to Pyro. For example, the simulator for the Pyrobot robots uses ports, while KheperaSimulated uses shared memory.

It is generally a requirement to start up any simulator before attempting to load the corresponding Pyro robot instance. On the other hand, you should stop Pyro before stopping a simulator. Consider a simulator to be the server, and Pyro the client. A server will stop when Pyro is stopped.

Robot objects are responsible for the details of interfacing with the simulators and real hardware. All robots are defined in the pyrobot/robot/ directory. For example, the following files have the details of connecting onto the symbolic Pyrobot simulator, Player, and Khepera robots, respectively:

pyrobot/robot/symbolic.py
pyrobot/robot/player.py
pyrobot/robot/khepera.py

For some robots, this involves many details. You may find that some of the lowest-level details are in a lower-level directory of pyrobot/robot/. But all robots get their core definition from:

pyrobot/robot/__init__.py

Robot instances are passive objects: they only do things when a brain or gui object tells them to. They command the motors of real and simulated robots, but only as directed by a brain.

pyrobot.brain

Each robot has exactly one brain. All brains are extensions of:

pyrobot/brain/__init__.py

Brains are themselves extensions of threads. Thus, brains are capable of running on their own, in their own process. Sometimes a brain may have multiple behaviors, but they all run in a single thread.

Brains may operate continuously, but they do so one step at a time. Most brain threads call their step() methods about 10 times per second. But you can implement your own brain that steps many thousands of times a second.

If you have loops (for or while loops, for example) in your step function, you may experience erratic behavior, either in the robot or in the gui. Remember that step() is already in a loop, and runs many times a second.

pyrobot.gui

Each brain/robot pair has an associated graphical user interface, or gui. The basic gui is defined in:

pyrobot/gui/__init__.py

The gui is responsible for drawing things, if necessary. There are two main gui's, and they must be indicated on the command line:

pyrobot -g tty     # A basic TTY console non-gui
pyrobot -g tk      # A Tk-based graphical interface

The tty gui is a bare interface to provide interaction and control over a slow connection, such as wireless. The tk gui will ask the robot (and its devices) for data so that it can render visual representations. Note that the tty GUI does not update devices' displays. If you run with the tty gui and wish to have graphical windows (for example, on a camera) then you will need an camera.updateWindow() call in your brain.

pyrobot.engine

Finally, the engine is the last main object. The engine is designed as a container for the brain/robot/gui trio (and some other overhead objects). The engine is the place where the above objects can find each other. You can find the engine definition in:

pyrobot/engine/__init__.py

You can ignore engines, as they are not seen unless you want to write raw Python code to control multiple robots.

Up: PyroModulesContents