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.
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|
|Player6665, Player6666||StageSimulator, GazeboSimulator||Pioneer family, ER1, Khepera, B21R, etc.|
|Khepera, Hemisson||N/A||Khepera 1 and 2, Hemisson|
|Robocup, RobocupTeamA, RobocupTeamB||RobocupSimulator||N/A|
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:
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.
Each robot has exactly one brain. All brains are extensions of:
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.
Each brain/robot pair has an associated graphical user interface, or gui. The basic gui is defined in:
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.
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:
You can ignore engines, as they are not seen unless you want to write raw Python code to control multiple robots.