[Pyro-users] Re: Pyro High-Level Conceptual Model

[Douglas S. Blank]

Bill,

Good questions! I'm CCing the pyro-users mailing list, too, as these are
questions others, no doubt, have.

Bill Manaris <manaris at cs.cofc.edu> said:

> Hi Doug,
> 
> I hope all is well.  I have started using Pyro in my Intro to AI class
> using Russell and Norvig.  So far it's going good.  There is a natural
> connection between intelligent agents and Pyro.

Good to hear it. If anyone has links to web resources that they would be
willing to share, that would be very useful. This list would be a good place
to post them.
 
> One of my students asked me a question yesterday after class.
> He was having difficulty understanding how the various Pyro
> components interacted with each other -- a high level conceptual
> model related to data flow.

This is something that we know that we need more documentation, so we
appreciate the specific questions. You can find the place where we have
started to document the overall Pyro design at:

http://pyrorobotics.org/pyro/?page=PyroModuleObjectOverview

Your questions suggest another line of information that should be on that
page, too.

> 1) Stage is the 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?)

The simulators are purely passive in the sense that nothing that happens there
causes any code to run in Pyro. 

> 2) Player is a server -- 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?

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 order is:

1. Start a simulator or server on a real robot
2. Start a robot client
3. Load a brain
4. run

> 3) 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?  

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:

self.robot.get("devices/laser0/all/value")

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.

> 4) Where do robot devices reside?  

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).
 
> What happens when you add a physical robot?  Does that replace Stage?

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.

> Perhaps calling Player a server in the context of Pyro might be confusing.

Well, yes. It provides both the client and server programs. Maybe we should
call the Player server somthing else, or maybe rename Player6666 to
PlayerClient6666?

> Perhaps this is already explained somewhere.  If so, please let me know.

I'll add this set of questions to the FAQ, and we'll try to work into the page
mentioned above.

> Perhaps the Pyro user interface could be improved to better communicate
> the underlying conceptual model.  If you agree with this, I could assign it 
> as a project in my graduate HCI class in the Spring.  
> It would be a great project.

I think that you can see we tried to make the UI match the steps outlined
above (server, client, brain, run). But, I think having students think about
how they would do it would be a great project. Tkinter makes it pretty easy to
create interfaces. There is also wxPython, which is a bit snappier than Tkinter.

> Any help you can provide to help me form a more cohesive conceptual
> model of the high-level desing/interaction between components will
> be most appreciated.

Thanks, Bill, for a great set of questions! Hope this helps,

-Doug

> Thanks,
> 
> Bill
> 
> --
> Bill Manaris, Ph.D.
> Computer Science Department
> College of Charleston
> 66 George Street, Charleston, S.C. 29424, USA
> Voice: (843)953-8159, Fax: (843)953-8154
> Web:  www.cs.cofc.edu/~manaris
> 

-- 
Douglas S. Blank,       Assistant Professor         
dblank at brynmawr.edu,          (610)526-6501
Bryn Mawr College,  Computer Science Program
101 North Merion Ave,  Park Science Building
Bryn Mawr, PA 19010 dangermouse.brynmawr.edu