Post your questions and answers here.
Q1: Stage is a simulator -- it is purely passive, right? Or does it initiate action when, say, the robot hits a wall? (If so, is this done through a Player call-back?)
A1: The simulators are purely passive in the sense that nothing that happens there causes any code to run in Pyro. Currently, Pyro doesn't have a mode that would allow it to operate through events connected to call-backs. However, you could extend pyro.brain by changing the update() method to do so. Right now, all state information is gathered from the robot by polling the robot about 10 times a second.
Q2: Player is a server, right -- it initiates action. It receives information from Stage simulated sensors. It is "extended" through a brain assigned by the end-user through the Pyro interface. Or is the brain "inside" Pyro, and the latter is sending commands to Player?
A2: I usually descibe the simulators as being the server. Player is a client in that it connects onto Stage, which must already be running. Pyro wraps the Player client into what we call a "robot" interface. So, the correct starting order is:
Start a simulator or server on a real robot
Start a robot client
Load a brain
Run the brain
Likewise, to shutdown Pyro, you should:
Stop the brain
Which causes the simulator/server to close
Don't close the server/simulator first!
Q3: Pyro is a collection of classes. Is it a wrapper around the Player component? Does it communicate directly with Stage? Or only through Player? What happens when the Pyro user gets robot attributes, e.g., sensor values, via the Pyro command line?
A3: Pyro starts the server (whether it is a simulator or a server that runs on the real hardware). The server does not reside "inside" pyro, but pyro will close it down when Pyro stops.
Pyro wraps Player (and other robot clients) in Python code, and handles the communication between Python and whatever server is running (Stage, some other simulator, or hardware server).
When Pyro gets sensor values, it really is just accessing data that it has already queried from the robot. About 10 times a second, Pyro is asking the Stage server (through the client Player) about the robot's "state" (sensor readings). When you have in your brain:
[s.value for s in self.robot.laser["all"]]
you are really getting that data from the last update, which happens right before the step() method is called in the brain. When you issue that from the command line, you are getting it from the last update.
It does NOT send that query to the server. Movement commands, at least in the direct control methodology, do send the commands to the robot.
Also, see http://pyrorobotics.org/pyrobot/?page=PyroModuleObjectOverview for more details on the overall Pyro design.
Q4: Where do robot devices reside?
A4: The idea of a Pyro "device" is an abstraction. The actual code may be Python code, or it might actually be inside Player, or some other client. The "device" is an abstraction that hides the details so you don't need to know. Each robot implements the communication with a device differently. Some devices have their own communication (like laser and cameras). Some devices have their data mixed in with the communication with the robot (like sonar and some pan-tilt-zoom units).
Q5: What happens when you add a physical robot? Does that replace Stage?
A5: Yes, exactly. A physical robot is a server. Some robots (like the Pioneer and Khepera) already have a server running on them, just waiting for a client. Some real robots need to have a little server started, like the Player-based real robots. In this case, Player also provides the server, which is why there is a PlayerServer in the Server directory and picklist.
Q6: Perhaps calling Player a server in the context of Pyro might be confusing.
A6: Well, yes. It provides both the client and server programs. Maybe we should call Player6666 PlayerClient6666?
Q7: Sometimes when I press the "Reload" button, error messages are not reported that do appear when you use "Load". What's happening?
A7: If you try to "Load" a file that has errors, it won't load. Pressing "Reload" doesn't do anything because no file was ever loaded to begin with. The solution is to open the troubled file, fix the errors, and then "Load" it again. Note that you won't be able to simply click on "Edit", because it never loaded. Try clicking on "Edit", then loading the file in the editor.
Q8: How can i install and use Pyro on Windows, is there a distribution for windows?
A8: Pyro may in fact work with operating systems other than Unix and Linux, but we wouldn't know as we do all of our work in these environments. Of course, Python, TCL, and OpenGL will run under a large number of operating systems, but there may be some assumptions that we have made that require Linux. Our suggestion is to make your system dual-bootable. For more information, see, for example, Red Hat Linux.
$$$NEW!$$$: You can now make a Pyro Live CD from which you can boot a computer running Windows, and run a full version of Pyro, and all of its support software and simulators. See PyroLiveCD for more information and to download the 584 MB CD image.
Q9: What versions of Linux does Pyro run under?
A9: We have tested extensively under RedHat 7.x, 8.x, and 9.x; Fedora Core 2; and Knoppix (which is based on Debian) but it should work fairly well under most Unixes.
Q10: Can I load all of the things I need at the command line?
A10: Yes. Try this:
% pyro -s AriaSimulator -r Aria -b BBWander -d FakeCamera
Note, though, that if you have your own file called BBWander.py and it isn't in the current directory (the one that you started Pyro in) then the system will look in its own directories and may find a BBWander.py there. It's a good idea to work in the same directory that you have your programs.
Q11: The SOM initialization without a dataset sometimes creates values that are outside the range of rmin and rmax. Also, seeding with a dataset sometimes creates values that are way off. Are both of these behaviors normal, or is something wrong?
A11: No, nothing is wrong. The SOM works that way.
Q12: Is there any way to control multiple AIBO robots with a single Python brain?
A12: Yes, but that requires a little bit more infrastraucture that you'll have to handle yourself. Almost all of Pyro is just Python code, so you can do most anything that you can think of. The main Pyro gui is designed to run one robot via one brain. But, you can do variations on that. For example, you don't even need a single brain.
One problem with running two robots with one brain is that the gui only automatically updates one robot. But you could add code like:
class MultiBrain(Brain): def setup(self): self.otherRobot = AiboRobot("127.0.0.1") def step(self): self.otherRobot.update() self.otherRobot.move(1, -1)
but that could get confusing. You might also try having one brain for each robot, but have them communicate through, say, sockets.
Q13: Is it possible to control multiple robots (of any type) without using Player/Stage?
A13: Player/Stage is only needed for those robots that only have a Player interface. There are many robots that do not rely on P/S, including Aibo, Hemisson, Khepera, and the Pyrobot Simulated robots. A Player/Stage robot is just another type of robot.