From w.richert at gmx.net  Fri May  6 06:41:15 2005
From: w.richert at gmx.net (Willi Richert)
Date: Fri May  6 06:30:03 2005
Subject: [Pyro-developers] Blob problems with CVS version and stage plugin
Message-ID: <200505061241.15420.w.richert@gmx.net>

Hi,

I have the most recent CVS versions of PS and pyro. When I try to run 
http://pyrorobotics.org/pyro/?page=ExampleChase I get 

Pyro Version 4.0.0: Ready...
Running...
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
    self.run()
  File "./brain/__init__.py", line 147, in run
  File "NeedBrain.py", line 15, in step
    self.seekColor('red')
  File "NeedBrain.py", line 23, in seekColor
    result = self.getLargestBlob(color)
  File "NeedBrain.py", line 85, in getLargestBlob
    allBlobs = self.getBlobs(color)
  File "NeedBrain.py", line 58, in getBlobs
    data = self.get('robot/blobfinder/data')
  File "./brain/__init__.py", line 64, in get
  File "./robot/__init__.py", line 310, in get
  File "./robot/__init__.py", line 257, in _get
  File "./robot/device.py", line 302, in _get
  File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 38, in preGet
    self.devData["data"] = self.getDeviceData()
  File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 55, in getDeviceData
    return self.getPose()  #self.handle.scan[0]
  File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 58, in getPose
    x, y, th = self.handle.px, self.handle.py, self.handle.pa
  File "/home/wr/forschung/software/ps/lib/python2.3/site-packages/playerc.py", line 369, in <lambda>
    __getattr__ = lambda self, name: _swig_getattr(self, playerc_blobfinder, name)
  File "/home/wr/forschung/software/ps/lib/python2.3/site-packages/playerc.py", line 21, in _swig_getattr
    raise AttributeError,name
AttributeError: px

The code in robot/player.py
    def getDeviceData(self, pos = 0):
        return self.getPose()  #self.handle.scan[0]
    def getPose(self):
        """ Move the device. x, y are in meters """
        x, y, th = self.handle.px, self.handle.py, self.handle.pa
        return x, y, th / PIOVER180

tries to directly access the blobfinder's data. However that is only accessible over the list handle.blobs, as one can find out in pyro with
self.robot.device["blobfinder0"].handle.blobs

Since I'm not that familiar with Pyro, I want to ask whether this can be fixed in the CVS since I'm dependend on the blobs.
Or is there some other means in Pyro/Stage to be used as a marker?

Thanks,
wr
From dblank at mainline.brynmawr.edu  Fri May  6 07:59:53 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Fri May  6 07:48:35 2005
Subject: [Pyro-developers] Blob problems with CVS version and stage plugin
In-Reply-To: <200505061241.15420.w.richert@gmx.net>
Message-ID: <twig.1115380793.77619@cs.brynmawr.edu>

Willi,

It looks like this webpage example needs to be updated to use the new
blobfinder interface. In fact, we should probably make this use the blob
filters that sit on top of a camera interface, rather than use the specific
details of the low-level blobfinder device, that was only specific to Stage
(and only to a particular version). This will allow the webpage code to work
with real robots too.

I'll see if I can update that soon.

-Doug

Willi Richert <w.richert@gmx.net> said:

> Hi,
> 
> I have the most recent CVS versions of PS and pyro. When I try to run 
> http://pyrorobotics.org/pyro/?page=ExampleChase I get 
> 
> Pyro Version 4.0.0: Ready...
> Running...
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
>     self.run()
>   File "./brain/__init__.py", line 147, in run
>   File "NeedBrain.py", line 15, in step
>     self.seekColor('red')
>   File "NeedBrain.py", line 23, in seekColor
>     result = self.getLargestBlob(color)
>   File "NeedBrain.py", line 85, in getLargestBlob
>     allBlobs = self.getBlobs(color)
>   File "NeedBrain.py", line 58, in getBlobs
>     data = self.get('robot/blobfinder/data')
>   File "./brain/__init__.py", line 64, in get
>   File "./robot/__init__.py", line 310, in get
>   File "./robot/__init__.py", line 257, in _get
>   File "./robot/device.py", line 302, in _get
>   File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 38, in preGet
>     self.devData["data"] = self.getDeviceData()
>   File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 55, in
getDeviceData
>     return self.getPose()  #self.handle.scan[0]
>   File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 58, in
getPose
>     x, y, th = self.handle.px, self.handle.py, self.handle.pa
>   File
"/home/wr/forschung/software/ps/lib/python2.3/site-packages/playerc.py", line
369, in <lambda>
>     __getattr__ = lambda self, name: _swig_getattr(self, playerc_blobfinder,
name)
>   File
"/home/wr/forschung/software/ps/lib/python2.3/site-packages/playerc.py", line
21, in _swig_getattr
>     raise AttributeError,name
> AttributeError: px
> 
> The code in robot/player.py
>     def getDeviceData(self, pos = 0):
>         return self.getPose()  #self.handle.scan[0]
>     def getPose(self):
>         """ Move the device. x, y are in meters """
>         x, y, th = self.handle.px, self.handle.py, self.handle.pa
>         return x, y, th / PIOVER180
> 
> tries to directly access the blobfinder's data. However that is only
accessible over the list handle.blobs, as one can find out in pyro with
> self.robot.device["blobfinder0"].handle.blobs
> 
> Since I'm not that familiar with Pyro, I want to ask whether this can be
fixed in the CVS since I'm dependend on the blobs.
> Or is there some other means in Pyro/Stage to be used as a marker?
> 
> Thanks,
> wr
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 



-- 



From w.richert at gmx.net  Sat May  7 17:34:52 2005
From: w.richert at gmx.net (Willi Richert)
Date: Sat May  7 16:35:04 2005
Subject: [Pyro-developers] Proper fiducial support in player.py for Stage
	fiducials
Message-ID: <200505072334.53013.w.richert@gmx.net>

Hi,

this diff made my fiducials work together with the Stage CVS version:

Index: player.py
===================================================================
RCS file: /cvs/pyro/robot/player.py,v
retrieving revision 1.64
diff -r1.64 player.py
55a56
>
84a86,94
> class PlayerFiducialDevice(PlayerDevice):
>     def __init__(self, client):
>         PlayerDevice.__init__(self, client, "fiducial",
>                               mode=playerc.PLAYERC_READ_MODE)
>
>     def getDeviceData(self):
>         fs = self.handle.fiducials
>         return fs
>
624a635,636
>         elif item == "fiducial":
>             return {"fiducial": PlayerFiducialDevice(self.client)}



Regards,
wr
From dblank at mainline.brynmawr.edu  Sat May  7 16:53:55 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Sat May  7 16:53:55 2005
Subject: [Pyro-developers] Proper fiducial support in player.py for Stage
	fiducials
In-Reply-To: <200505072334.53013.w.richert@gmx.net>
Message-ID: <twig.1115499235.77347@cs.brynmawr.edu>

Willi,

Thanks; your fiducial patch is now in the CVS version of Pyro. Also, do you
have a sample controller to show how you have used it? Just a short example
would be helpful.

Thanks again!

-Doug



From w.richert at gmx.net  Mon May  9 03:27:26 2005
From: w.richert at gmx.net (Willi Richert)
Date: Mon May  9 02:27:32 2005
Subject: [Pyro-developers] Proper fiducial support in player.py for Stage
	fiducials
In-Reply-To: <twig.1115499235.77347@cs.brynmawr.edu>
References: <twig.1115499235.77347@cs.brynmawr.edu>
Message-ID: <200505090927.26888.w.richert@gmx.net>

Am Samstag, 7. Mai 2005 22:53 schrieb dblank@mainline.brynmawr.edu:
> Willi,
>
> Thanks; your fiducial patch is now in the CVS version of Pyro. Also, do you
> have a sample controller to show how you have used it? Just a short example
> would be helpful.
>
> Thanks again!
>
> -Doug

Here it is. I will try to give bearing, id, orient, pos, range, rot, this, 
thisown, upos and urot as parameters accessible like e.g.  
self.get("robot/fiducial/pos").  That will, of course, break this particular 
example.

============================== NeedBrain.py ====================
from pyro.brain import Brain

class FindBlobs(Brain):
    def setup(self):
        self.startDevice('fiducial')
    
    def destroy(self):
        self.removeDevice('fiducial')
    
    def step(self):
        fids = self.get("robot/fiducial/data")
        if fids>0:
            f=fids[0]
            # bearing, id, orient, pos, range, rot, this, thisown, upos, urot                
            print f.id, f.orient, f.pos, f.range
        
def INIT(engine):
   return FindBlobs('FindBlobs', engine)
==============================================================

Have fun,
wr
From w.richert at gmx.net  Tue May 10 07:08:09 2005
From: w.richert at gmx.net (Willi Richert)
Date: Tue May 10 07:08:25 2005
Subject: [Pyro-developers] Moving "stack" variable from FSMBrain to Brain
Message-ID: <200505101308.09323.w.richert@gmx.net>

Hi all,

currently it's not possible to use push/pop in the states of a 
BehaviorBasedBrain. This is because the needed Brain variable "stack" is only 
initalized in FSMBrain. Since FSMBrain and BehaviorBasedBrain are all 
descendents of Brain, wouldn't it make more sense to declare
self.stack = []
in Brain? There are no other changes needed.

Thanks,
wr
From dblank at brynmawr.edu  Tue May 10 10:07:01 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Tue May 10 10:06:52 2005
Subject: [Pyro-developers] Moving "stack" variable from FSMBrain to Brain
In-Reply-To: <200505101308.09323.w.richert@gmx.net>
References: <200505101308.09323.w.richert@gmx.net>
Message-ID: <4280C005.4080609@brynmawr.edu>

Willi,

Good catch! The change is now in CVS. (If we ever get T-shirts that say 
"Pyro Maniac" on them, we'd send you one. We'd also send one to Jim, 
Zach, Stefanie, Robert, George, and others for their contributions. We 
may have to make some T-shirts!)

It sounds like you are doing some interesting things with Pyro that we 
hadn't thought of before. Maybe sometime you could give us a 
show-and-tell? In fact, I added a place on the wiki where anyone can 
briefly describe their project, and provide a link:

http://emergent.brynmawr.edu/emergent/PyroUsers

Thanks!

-Doug

Willi Richert wrote:
> Hi all,
> 
> currently it's not possible to use push/pop in the states of a 
> BehaviorBasedBrain. This is because the needed Brain variable "stack" is only 
> initalized in FSMBrain. Since FSMBrain and BehaviorBasedBrain are all 
> descendents of Brain, wouldn't it make more sense to declare
> self.stack = []
> in Brain? There are no other changes needed.
> 
> Thanks,
> wr
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 
> 


-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From w.richert at gmx.net  Tue May 10 10:36:21 2005
From: w.richert at gmx.net (Willi Richert)
Date: Tue May 10 10:36:15 2005
Subject: [Pyro-developers] Moving "stack" variable from FSMBrain to Brain
In-Reply-To: <4280C005.4080609@brynmawr.edu>
References: <200505101308.09323.w.richert@gmx.net>
	<4280C005.4080609@brynmawr.edu>
Message-ID: <200505101636.21518.w.richert@gmx.net>

Hi,

as you assume correctly that I'm a Reinforcement Learning Agent, I've attached 
some other diffs for ./brain/behaviors that mainly move the State.goto() 
functionality a little bit to the Brain System. It's actually a simple hack 
that makes my purposes possible. 

What do you think about fully moving that whole goto() stuff from the State's 
domain into the Brain class? E.g. if I want to use reinforcement learning on 
top of a BehaviorBasedBrain, I need some means to switch centrally between 
the actual possible states. With the current CVS version, where only States 
can trigger a goto, it is not possible.

Some other topics on my wish list:
1) convenient and working non-gui Pyro mode, where you can e.g. run dozens of 
agents in a Stage world (the suggested "-g tty" option does not work for me)
2) more transparent directory structure in self.get("robot/..."). I've 
extended it by my own to get, e.g. only a list of fiducial IDs, but since 
child directories aren't easily supported I have to do 
self.get("robot/fiducial/idlist")()
to actually invoke the function behind idlist (see player.py_diff attachment).

Have fun,
wr

Am Dienstag, 10. Mai 2005 16:07 schrieb Douglas S. Blank:
> Willi,
>
> Good catch! The change is now in CVS. (If we ever get T-shirts that say
> "Pyro Maniac" on them, we'd send you one. We'd also send one to Jim,
> Zach, Stefanie, Robert, George, and others for their contributions. We
> may have to make some T-shirts!)
>
> It sounds like you are doing some interesting things with Pyro that we
> hadn't thought of before. Maybe sometime you could give us a
> show-and-tell? In fact, I added a place on the wiki where anyone can
> briefly describe their project, and provide a link:
-------------- next part --------------
Index: __init__.py
===================================================================
RCS file: /cvs/pyro/brain/behaviors/__init__.py,v
retrieving revision 1.24
diff -r1.24 __init__.py
22a23
>       self.activeState = None
28a30
>       self.goto(name)
31a34
>       self.activeState = None
46a50,51
>    def goto(self, name):
>       self.activeState = self.states[name]
-------------- next part --------------
Index: fsm.py
===================================================================
RCS file: /cvs/pyro/brain/behaviors/fsm.py,v
retrieving revision 1.13
diff -r1.13 fsm.py
72a73
>       self.brain.goto(state)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: player.py_diff
Type: text/x-java
Size: 1430 bytes
Desc: not available
Url : http://emergent.brynmawr.edu/pipermail/pyro-developers/attachments/20050510/291f1759/player.bin
From dblank at brynmawr.edu  Tue May 10 20:17:23 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Tue May 10 20:17:10 2005
Subject: [Pyro-developers] Moving "stack" variable from FSMBrain to Brain
In-Reply-To: <200505101636.21518.w.richert@gmx.net>
References: <200505101308.09323.w.richert@gmx.net>	<4280C005.4080609@brynmawr.edu>
	<200505101636.21518.w.richert@gmx.net>
Message-ID: <42814F13.4000908@brynmawr.edu>

Willi Richert wrote:
> Hi,
> 
> as you assume correctly that I'm a Reinforcement Learning Agent, I've attached 
> some other diffs for ./brain/behaviors that mainly move the State.goto() 
> functionality a little bit to the Brain System. It's actually a simple hack 
> that makes my purposes possible. 

Done. Thanks!

> What do you think about fully moving that whole goto() stuff from the State's 
> domain into the Brain class? E.g. if I want to use reinforcement learning on 
> top of a BehaviorBasedBrain, I need some means to switch centrally between 
> the actual possible states. With the current CVS version, where only States 
> can trigger a goto, it is not possible.

I'm not sure how you would use this? Can you give a simple example?

You would still want to push/pop from states, too, yes? Or would you 
just call self.brain.push() and self.brain.pop() from a state?

> Some other topics on my wish list:
> 1) convenient and working non-gui Pyro mode, where you can e.g. run dozens of 
> agents in a Stage world (the suggested "-g tty" option does not work for me)

This should be very easy to construct. All that is needed is a thread to 
call the update() and step(). I'll look into that, if you don't come up 
with a bit of code first...

> 2) more transparent directory structure in self.get("robot/..."). I've 
> extended it by my own to get, e.g. only a list of fiducial IDs, but since 
> child directories aren't easily supported I have to do 
> self.get("robot/fiducial/idlist")()
> to actually invoke the function behind idlist (see player.py_diff attachment).

Yes, the path structure code got ugly. You can use the alternative 
pythonic interface:

self.robot.fiducial.property
self.devices.fiducial0.property

-Doug

> Have fun,
> wr
> 
> Am Dienstag, 10. Mai 2005 16:07 schrieb Douglas S. Blank:
> 
>>Willi,
>>
>>Good catch! The change is now in CVS. (If we ever get T-shirts that say
>>"Pyro Maniac" on them, we'd send you one. We'd also send one to Jim,
>>Zach, Stefanie, Robert, George, and others for their contributions. We
>>may have to make some T-shirts!)
>>
>>It sounds like you are doing some interesting things with Pyro that we
>>hadn't thought of before. Maybe sometime you could give us a
>>show-and-tell? In fact, I added a place on the wiki where anyone can
>>briefly describe their project, and provide a link:
>>
>>
>>------------------------------------------------------------------------
>>
>>Index: __init__.py
>>===================================================================
>>RCS file: /cvs/pyro/brain/behaviors/__init__.py,v
>>retrieving revision 1.24
>>diff -r1.24 __init__.py
>>22a23
>>
>>>      self.activeState = None
>>
>>28a30
>>
>>>      self.goto(name)
>>
>>31a34
>>
>>>      self.activeState = None
>>
>>46a50,51
>>
>>>   def goto(self, name):
>>>      self.activeState = self.states[name]
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>Index: fsm.py
>>>===================================================================
>>>RCS file: /cvs/pyro/brain/behaviors/fsm.py,v
>>>retrieving revision 1.13
>>>diff -r1.13 fsm.py
>>>72a73
>>>
>>>>      self.brain.goto(state)
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>Index: player.py
>>>>===================================================================
>>>>RCS file: /cvs/pyro/robot/player.py,v
>>>>retrieving revision 1.65
>>>>diff -r1.65 player.py
>>>>55a56
>>>>
>>>>>    
>>>>
>>>>84a86,109
>>>>
>>>>>class PlayerFiducialDevice(PlayerDevice):
>>>>>    def __init__(self, client):
>>>>>        PlayerDevice.__init__(self, client, "fiducial", mode=playerc.PLAYERC_READ_MODE)
>>>>>
>>>>>        self.devData["count"] = len(self)
>>>>>        self.devData["id"] = self.getFiducialsById
>>>>>        self.devData["idlist"] = self.getFiducialIDs
>>>>>
>>>>>    def getFiducialsById(self, id):
>>>>>        for f in self.handle.fiducials:
>>>>>            if f.id==id:
>>>>>                return f
>>>>>        return
>>>>>
>>>>>    def getFiducialIDs(self):
>>>>>        return [f.id for f in self.handle.fiducials]
>>>>>
>>>>>    def getDeviceData(self):
>>>>>        fs = self.handle.fiducials
>>>>>        return fs
>>>>>
>>>>>    def __len__(self):
>>>>>        return len(self.handle.fiducials)
>>>>>
>>>>
>>>>244,251d268
>>>>< class PlayerFiducialDevice(PlayerDevice):
>>>><     def __init__(self, client):
>>>><         PlayerDevice.__init__(self, client, "fiducial", mode=playerc.PLAYERC_READ_MODE)
>>>>< 
>>>><     def getDeviceData(self):
>>>><         fs = self.handle.fiducials
>>>><         return fs
>>>>< 
>>>>622a640,643
>>>>
>>>>>##         if item == "ptz":
>>>>>##             return {"ptz": PlayerPTZDevice(self.client, "ptz")}
>>>>>##         elif item == "gripper":
>>>>>##             return {"gripper": PlayerGripperDevice(self.client, "gripper")}
>>>>>
>>>>>
>>>>>------------------------------------------------------------------------
>>>>>
>>>>>_______________________________________________
>>>>>Pyro-developers mailing list
>>>>>Pyro-developers@emergent.brynmawr.edu
>>>>>http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers


-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From w.richert at gmx.net  Thu May 12 05:05:08 2005
From: w.richert at gmx.net (Willi Richert)
Date: Thu May 12 05:04:57 2005
Subject: [Pyro-developers] messy environment loading code in Engine
Message-ID: <200505121105.08565.w.richert@gmx.net>

Hi,

while trying to understand, why the multi brain example page at 
http://pyrorobotics.org/pyro/?page=ExampleMultipleBrains does not specify a 
stage config file, I've stumbled across the Engine.loadSimulator() code. At 
the beginning the line "options = string.split(file)" assumes that the file 
argument contains space separated options (here then I would assume that I 
can specify "-c room.cfg", e.g. But then, simulatorName consumes the whole 
file argument after the last "/", which would also contain those options and 
render the subsequent test (if simulatorName[-6:] == "Server") useless.

   def loadSimulator(self, file, worldfile):
      import string
      print "Engine.loadSimulator(%s, %s)"%(file, worldfile)
      options = string.split(file)
      guiflag = ''
      simulatorName = file.split('/')[-1]
      pyroPID = os.getpid()
      if simulatorName[-6:] == "Server":
         configDirName = simulatorName[:-6]
	...
         elif system.file_exists(os.getenv('PYRO') + \
                                 '/plugins/simulators/' + options[0]):
          ...
      else:
         # Ends with "Simulator"
         simDirName = simulatorName[:-9]
         if system.file_exists(worldfile):

Do I assume correctly that nobody ever has tried to run this version with 
multiple brains without gui? Would it be difficult to get it running?

Regards,
wr
From w.richert at gmx.net  Thu May 12 05:46:47 2005
From: w.richert at gmx.net (Willi Richert)
Date: Thu May 12 05:46:32 2005
Subject: [Pyro-developers] Configuration() not defined in Engine
Message-ID: <200505121146.48033.w.richert@gmx.net>

Hi,

Configuration is initialised and set properly to share.config in the 
pyro/bin/pyro startup file. We should consider cases in which Engines are 
initialised without having run the normal pyro file as it is done in 
http://pyrorobotics.org/pyro/?page=ExampleMultipleBrains

Regards,
wr
From dblank at mainline.brynmawr.edu  Thu May 12 09:12:07 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Thu May 12 09:11:44 2005
Subject: [Pyro-developers] Configuration() not defined in Engine
In-Reply-To: <200505121146.48033.w.richert@gmx.net>
Message-ID: <twig.1115903527.18226@cs.brynmawr.edu>

Willi,

We have done evolutionary experiments before using Pyro. Here
is an example that uses Python as the GUI (it does use Pyro
to start Stage, but that is in another process). You can also
just start Stage or Gazebo directly.


# 1. Start Stage, Gazebo, or Real robots
#    (maybe without gui) inside or outside 
#    of Pyro:

# export PYTHONPATH=/home/dblank
# export LD_LIBRARY_PATH=/usr/local/lib
# export PYRO=/home/dblank/pyro
# ~/pyro/bin/pyro -s StageSimulator -w playpen2.cfg &

# 2. Connect Pyro to the robots

from pyro.engine import Engine
from pyro.robot.player import PlayerRobot
import time

g = PlayerRobot('Green', 6665)
ge = Engine()
ge.setRobot(g)

b = PlayerRobot('Blue', 6667)
be = Engine()
be.setRobot(b)

# 3. Load their brains by filename (or create their
#    brain objects right here):

be.loadBrain('Avoid')
ge.loadBrain('Avoid')

# 4.Run the brains in their own threads:

be.pleaseRun()
ge.pleaseRun()

# 5. Stop them whenever you want (based on time, or
#    something they do):

time.sleep(10)

be.pleaseStop()
ge.pleaseStop()

------ 

Hope that helps,

-Doug

Willi Richert <w.richert@gmx.net> said:

> Hi,
> 
> Configuration is initialised and set properly to share.config in the 
> pyro/bin/pyro startup file. We should consider cases in which Engines are 
> initialised without having run the normal pyro file as it is done in 
> http://pyrorobotics.org/pyro/?page=ExampleMultipleBrains
> 
> Regards,
> wr
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 



-- 



From dblank at mainline.brynmawr.edu  Thu May 12 09:16:19 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Thu May 12 09:15:57 2005
Subject: [Pyro-developers] messy environment loading code in Engine
In-Reply-To: <200505121105.08565.w.richert@gmx.net>
Message-ID: <twig.1115903779.57644@cs.brynmawr.edu>

Willi,

We have run multiple brains with this version (Pyro4), but it may be that that
page is not up-to-date. I'll take a look. I think that your assumptions below
are not correct (e.g., Pyro already has the command options parsed long before
you get to loadSimulator).

There are some bad assumptions in the code that are based on file/path
separators (so that this doesn't work on Windows yet), but we're working on that.

-Doug

Willi Richert <w.richert@gmx.net> said:

> Hi,
> 
> while trying to understand, why the multi brain example page at 
> http://pyrorobotics.org/pyro/?page=ExampleMultipleBrains does not specify a 
> stage config file, I've stumbled across the Engine.loadSimulator() code. At 
> the beginning the line "options = string.split(file)" assumes that the file 
> argument contains space separated options (here then I would assume that I 
> can specify "-c room.cfg", e.g. But then, simulatorName consumes the whole 
> file argument after the last "/", which would also contain those options and 
> render the subsequent test (if simulatorName[-6:] == "Server") useless.
> 
>    def loadSimulator(self, file, worldfile):
>       import string
>       print "Engine.loadSimulator(%s, %s)"%(file, worldfile)
>       options = string.split(file)
>       guiflag = ''
>       simulatorName = file.split('/')[-1]
>       pyroPID = os.getpid()
>       if simulatorName[-6:] == "Server":
>          configDirName = simulatorName[:-6]
> 	...
>          elif system.file_exists(os.getenv('PYRO') + \
>                                  '/plugins/simulators/' + options[0]):
>           ...
>       else:
>          # Ends with "Simulator"
>          simDirName = simulatorName[:-9]
>          if system.file_exists(worldfile):
> 
> Do I assume correctly that nobody ever has tried to run this version with 
> multiple brains without gui? Would it be difficult to get it running?
> 
> Regards,
> wr
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 



-- 



From w.richert at gmx.net  Thu May 12 09:35:08 2005
From: w.richert at gmx.net (Willi Richert)
Date: Thu May 12 09:34:52 2005
Subject: [Pyro-developers] messy environment loading code in Engine
In-Reply-To: <twig.1115903779.57644@cs.brynmawr.edu>
References: <twig.1115903779.57644@cs.brynmawr.edu>
Message-ID: <200505121535.09205.w.richert@gmx.net>

Am Donnerstag, 12. Mai 2005 15:16 schrieb dblank@mainline.brynmawr.edu:
> Willi,
>
> We have run multiple brains with this version (Pyro4), but it may be that
> that page is not up-to-date. I'll take a look. I think that your
> assumptions below are not correct (e.g., Pyro already has the command
> options parsed long before you get to loadSimulator).

1) Indeed, now I've got it working! The main problem was to find out that by 
worldfile you mean configfile in the Engine() parameters.

2) Do you know a way to run stage without GUI? Now I have ~7 Steps/second. I 
need far more to get meaningful results in short time.

3) Another bug: If you turn of profile counting than you get an error, because 
we should introduce 'profileTotalTime' before using it in Brain.
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
    self.run()
  File "/home/wr/forschung/software/ps/pyro/brain/__init__.py", line 155, in 
run
    self.profileTotalTime += time.time() - self.lastRun
  File "/home/wr/forschung/software/ps/pyro/brain/__init__.py", line 98, in 
__getattr__
    raise AttributeError, ("'<type %s>' object has no attribute '%s'" % 
(self.__class__.__name__, attr))
AttributeError: '<type NeedBrain>' object has no attribute 'profileTotalTime'

4) BTW, despite of the bugs which are in the CVS version, Pyro is by far the 
most convenient and intuitive robotic simulation toolkit I've used so far! 
Good work, Pyro folks!

Have fun,
wr
From dblank at mainline.brynmawr.edu  Thu May 12 10:40:20 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Thu May 12 10:39:58 2005
Subject: [Pyro-developers] messy environment loading code in Engine
In-Reply-To: <200505121535.09205.w.richert@gmx.net>
References: <twig.1115903779.57644@cs.brynmawr.edu>,
	<twig.1115903779.57644@cs.brynmawr.edu>
Message-ID: <twig.1115908820.8039@cs.brynmawr.edu>

Willi Richert <w.richert@gmx.net> said:

> Am Donnerstag, 12. Mai 2005 15:16 schrieb dblank@mainline.brynmawr.edu:
> > Willi,
> >
> > We have run multiple brains with this version (Pyro4), but it may be that
> > that page is not up-to-date. I'll take a look. I think that your
> > assumptions below are not correct (e.g., Pyro already has the command
> > options parsed long before you get to loadSimulator).
> 
> 1) Indeed, now I've got it working! The main problem was to find out that by 
> worldfile you mean configfile in the Engine() parameters.

Good to hear. We made "world" and "config" synonymous because some simulators
call their files "worlds" and some call them "configs". Now, some simulators
(Stage) have both! In any event, you can the -w, --world, -c, or --config
flags interchangebly.
 
> 2) Do you know a way to run stage without GUI? Now I have ~7 Steps/second. I 
> need far more to get meaningful results in short time.

There was at one time a -g flag on Stage that ran it without the GUI. Now,
there claims to be a -u flag that sets the Hz of the simulator. I haven't been
able to get that to work, and the non-GUI Stage seems to not be there any
more. I see that you have a question over at Platy/Stage so maybe they can help.
 
> 3) Another bug: If you turn of profile counting than you get an error, because 
> we should introduce 'profileTotalTime' before using it in Brain.

Ok, I'll take a look at that.

> 4) BTW, despite of the bugs which are in the CVS version, Pyro is by far the 
> most convenient and intuitive robotic simulation toolkit I've used so far! 
> Good work, Pyro folks!

Thanks, Willi. Both for your kind words, and for your help in fixing these issues.

-Doug, on behalf of all the Pyro Maniacs

> 
> Have fun,
> wr

-- 



From dblank at mainline.brynmawr.edu  Thu May 12 14:29:56 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Thu May 12 14:29:33 2005
Subject: [Pyro-developers] Timing issues in Pyro
In-Reply-To: <twig.1115908820.8039@cs.brynmawr.edu>
References: <twig.1115903779.57644@cs.brynmawr.edu>,
	<twig.1115903779.57644@cs.brynmawr.edu>,
	<200505121535.09205.w.richert@gmx.net>
Message-ID: <twig.1115922596.93512@cs.brynmawr.edu>

Willi's recent questions on how to run Pyro as fast as possible lead me to
poke around the details in Pyro, and especially when using Stage.

There are three different timings, and they all may interact in different ways:

1. First, there is the rate of stepping in Pyro. This is currently no faster
than 10 steps a second, and can be slower depending on your brain's step code,
and other devices like cameras which run in that same thread. There is a pause
in Pyro, to make it run this slow, but you can change that pause time with:

brain.pauseTime = WAIT

where WAIT is a time in seconds. The default is 0.1 which causes 1/10 of a
second pause between step() calls. You can set this to 0.0 if you wish, but
read on. I have tried brains running with pauseTime set to 0.05, which gives
about 85 brain steps a second. You can see the brain steps/second by setting:

brain.profilePerformance = 1

We should get the device updates out of the main thread, but there are some
locking/unlocking issues we will have to figure out. Possible device delays
currently are only an issue with the Pyro camera classes. If this is a
problem, there is the Phission camera project which is under development. It
runs in a separate process, and has a pipeline model. However, it can't be
intergrated with Python quite so closely and requires locking/unlocking to use
(maybe not for beginners).

2. Second, there is the speed that the Python code talks to the robot. Using
player, this is determined by the rate that Player processes and pushes data.
You can change this rate with player's -u flag. Some other Pyro robot
interfaces will just operate as fast as possible (for example, the Khepera
simulator). If Player's rate is slower than Pyro's rate, then commands can
build up on the socket. The player command looks like:

player -u 850 worldfile.cfg

3. Third, there is yet another timing: real time. If you make the first two
changes, you can get 85 commands / second. That can be quite handy if you need
fine-time control, and if your network can handle the bandwidth. However, if
your goal is to make simulated experiments go faster, this two changes haven't
done that yet. To change the rate that time is simulated in the simulator, you
can add 

interval_sim 100  # milliseconds per update step
interval_real 100 # real-time milliseconds per update step 

in the Stage world file. Keep one of the values fixed, and change the other.
As Richard Vaughan in the Player-Stage mailing list says:

"To make Stage run faster than real time, leave interval_sim at some positive
value, say 100 ms. Then set interval_real to be less than 100. A value of 0
should do it."

Richard continues with related information:

"Player is clocked from Stage, so Player perceives Stage's simulation time.
However, there are some serious problems with using Player/Stage in this way,
due to the interactions of Player, your client, and the OS network stack. When
Stage runs very fast you will probably find that the network stack starts to
send data in larger chunks, which means that your control loop is becoming
delayed. A common symptom is that your nice robot controller starts bumping
into walls or oscillating side to side. There's no fix for this, as it's a
consequence of using network sockets to talk to Player. In the future, we'll
have an alternative transport mechanism that doesn't have this problem. For
now, I can't really recommend dropping interval interval_real much below
interval_sim, unless you are very careful indeed."

So, to make simulations go faster than real time, you will want to do all of
these, with the network bandwidth being the limiting factor. However, when
Player/Stage has a new method, we will explore that option from Pyro.

-Doug


From w.richert at gmx.net  Sun May 15 12:09:43 2005
From: w.richert at gmx.net (Willi Richert)
Date: Sun May 15 12:09:11 2005
Subject: [Pyro-developers] Re: [Pyro-users] Communication between agents
In-Reply-To: <twig.1116083455.95741@cs.brynmawr.edu>
References: <twig.1116083455.95741@cs.brynmawr.edu>
Message-ID: <200505151809.43306.w.richert@gmx.net>

Hi,

up to now I couldn't see my simulation device because I had no port specified 
for it in my configuration file. Now, it works.

But, if I want to check for every agent at every time step to which other 
agents it can talk to, it would be a waste of CPU. Wouldn't it be much more 
reasonable to have the possibility to have in parallel to the subscribed 
agents some kind of observer mechanism, where one can hook into certain 
functions that are invoked at every step? This would be useful for other 
"environment maintenance" tasks also. So far, every environment activity must 
be implemented as a brain derivative, if I've understood the concept right. 
Maybe there is already some Brain-like class in Pyro, without a visible 
representation, by which one can check certain environment conditions and 
invoke environmental handling code that is not special to a special agent?

Thanks,
wr

Am Samstag, 14. Mai 2005 17:10 schrieb dblank@mainline.brynmawr.edu:
> Willi,
>
> No, there isn't a way to know for certain where a robot really is (and for
> good reason---we want to make these interfaces as much like a real robot
> interface as we can).
>
> However, in Pyro, a Player robot will always check port 7000 to see if
> there is a simulation interface there. If there is (and there is for all of
> the worlds that come with Pyro + Stage) it will automatically load it. The
> Player simulation interface is the new replacement for the old "truth"
> interface (except that Gazebo currently uses the old truth not simulation).
>
> This is sometimes called a "hand of god" interface, because you know where
> things truly are, and can reach into the simulation and move things. The
> simulation interface provides a way for any Pyro robot to move (and soon
> create) objects in the simulation. It works like:
>
> robot.simulation.setPose("objectname", x, y, th)
>
> where "objectname" is a string name of the Stage object (found in the world
> file, or moving your mouse over the object).
>
> This is very useful for reseting (or randomizing) a world for a new
> experiment.
>
> Hope that helps,
>
> -Doug
>
> Willi Richert <w.richert@gmx.net> said:
> > Hi,
> >
> > yesterday I've asked a question about inter-robot communication in Pyro
> > with StageStimulator. I've tried my first steps to implement a
> > Communicator with the following properties:
> > 1. Agents are registered at the Communicator
> > 2. At each step Communicator.exchange() is invoked which handles the
> > exchange of information between a pair of two agents that are within a
> > specified communication range.
> >
> > The problem is: If I traverse the list of registered agents I can access
> > each individuals positions (self.get("robot/x,y")). Of course, this is
> > not the real position, but the position the agent thinks it is. But, the
> > determination, whether two agents are nearby should be based on "hard
> > facts", not on the robot's opinion. I could of course use the agent's
> > self.get("robot/fiducial")...range to get another agent within reach
> > which would be a little more accurate, but this does not give me the
> > robot's brain object, but only positional data. I would need some method
> > to map positional data to the agent's object.
> >
> > Any hint on that? Is that possible without using Player's Truth device?
> >
> > Thanks,
> > wr
> > _______________________________________________
> > Pyro-users mailing list
> > Pyro-users@emergent.brynmawr.edu
> > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users
From dblank at brynmawr.edu  Sun May 15 13:11:14 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Sun May 15 13:10:37 2005
Subject: [Pyro-developers] Re: [Pyro-users] Communication between agents
In-Reply-To: <200505151809.43306.w.richert@gmx.net>
References: <twig.1116083455.95741@cs.brynmawr.edu>
	<200505151809.43306.w.richert@gmx.net>
Message-ID: <428782B2.1090008@brynmawr.edu>

Willi,

Some comments/questions below.

Willi Richert wrote:
> Hi,
> 
> up to now I couldn't see my simulation device because I had no port specified 
> for it in my configuration file. Now, it works.

An aside: it appears that if you don't explicitily give a port to the 
simulation interface, it will default to 6665. So, you could explicitly 
request to create a simulation device in Pyro to port 6665. We just 
decided to make the default be 7000 in Pyro, so that it is clear that it 
doesn't have anything to do with any particular robot.

> But, if I want to check for every agent at every time step to which other 
> agents it can talk to, it would be a waste of CPU. Wouldn't it be much more 
> reasonable to have the possibility to have in parallel to the subscribed 
> agents some kind of observer mechanism, where one can hook into certain 
> functions that are invoked at every step? This would be useful for other 
> "environment maintenance" tasks also. So far, every environment activity must 
> be implemented as a brain derivative, if I've understood the concept right. 
> Maybe there is already some Brain-like class in Pyro, without a visible 
> representation, by which one can check certain environment conditions and 
> invoke environmental handling code that is not special to a special agent?

I'm not quite sure what you have in mind, but I can mention some ways 
that you could implement an observer.

You might consider making a "brain" that doesn't actually connect to any 
robot, but does connect to the simulation device. You can easily do this 
with the Player robot by selecting port 7000.

This will run in its own thread, and you can monitor all of the robots. 
In the step() method, you can put any code that you want, and it would 
get run as often as that brain runs (see previous messages about 
changing the frequency of the brain step() calls).

Another method might be to create a montitor device that all robots 
would run. But this sounds like what you don't need. This would have all 
of the robots invoking some code every step.

Let us know if that first option won't work for some reason.

-Doug

> Thanks,
> wr
> 
> Am Samstag, 14. Mai 2005 17:10 schrieb dblank@mainline.brynmawr.edu:
> 
>>Willi,
>>
>>No, there isn't a way to know for certain where a robot really is (and for
>>good reason---we want to make these interfaces as much like a real robot
>>interface as we can).
>>
>>However, in Pyro, a Player robot will always check port 7000 to see if
>>there is a simulation interface there. If there is (and there is for all of
>>the worlds that come with Pyro + Stage) it will automatically load it. The
>>Player simulation interface is the new replacement for the old "truth"
>>interface (except that Gazebo currently uses the old truth not simulation).
>>
>>This is sometimes called a "hand of god" interface, because you know where
>>things truly are, and can reach into the simulation and move things. The
>>simulation interface provides a way for any Pyro robot to move (and soon
>>create) objects in the simulation. It works like:
>>
>>robot.simulation.setPose("objectname", x, y, th)
>>
>>where "objectname" is a string name of the Stage object (found in the world
>>file, or moving your mouse over the object).
>>
>>This is very useful for reseting (or randomizing) a world for a new
>>experiment.
>>
>>Hope that helps,
>>
>>-Doug
>>
>>Willi Richert <w.richert@gmx.net> said:
>>
>>>Hi,
>>>
>>>yesterday I've asked a question about inter-robot communication in Pyro
>>>with StageStimulator. I've tried my first steps to implement a
>>>Communicator with the following properties:
>>>1. Agents are registered at the Communicator
>>>2. At each step Communicator.exchange() is invoked which handles the
>>>exchange of information between a pair of two agents that are within a
>>>specified communication range.
>>>
>>>The problem is: If I traverse the list of registered agents I can access
>>>each individuals positions (self.get("robot/x,y")). Of course, this is
>>>not the real position, but the position the agent thinks it is. But, the
>>>determination, whether two agents are nearby should be based on "hard
>>>facts", not on the robot's opinion. I could of course use the agent's
>>>self.get("robot/fiducial")...range to get another agent within reach
>>>which would be a little more accurate, but this does not give me the
>>>robot's brain object, but only positional data. I would need some method
>>>to map positional data to the agent's object.
>>>
>>>Any hint on that? Is that possible without using Player's Truth device?
>>>
>>>Thanks,
>>>wr
>>>_______________________________________________
>>>Pyro-users mailing list
>>>Pyro-users@emergent.brynmawr.edu
>>>http://emergent.brynmawr.edu/mailman/listinfo/pyro-users
> 
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 
> 


-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From w.richert at gmx.net  Tue May 17 10:37:04 2005
From: w.richert at gmx.net (Willi Richert)
Date: Tue May 17 10:43:54 2005
Subject: [Pyro-developers] Timing issues in Pyro, Part II
Message-ID: <200505171637.04674.w.richert@gmx.net>

Hi,

I refer to Doug's previous post "[Pyro-developers] Timing issues in Pyro".

You said that you get 85 updates/s with pauseTime=0.05

I delved again into my timing issues, because I get lots of 
"warning : XXX bytes leftover on write() to client" if I simulate two brains. 
With only one I get no warnings and ~ 10 updates/s (Pentium(R) M processor 
1600MHz) .

Does this mean that my code is thinking too much between the update()s? I have 
no chance to make it faster.

- 
wr

PS: There is a post on that at the playerstage ML 
(http://sourceforge.net/mailarchive/forum.php?forum_id=8201&style=flat&viewday=15&viewmonth=200403) 
which did not help me very much.
From w.richert at gmx.net  Wed May 18 10:12:08 2005
From: w.richert at gmx.net (Willi Richert)
Date: Wed May 18 10:12:25 2005
Subject: [Pyro-developers] Timing issues in Pyro, Part II
In-Reply-To: <200505171637.04674.w.richert@gmx.net>
References: <200505171637.04674.w.richert@gmx.net>
Message-ID: <200505181612.11363.w.richert@gmx.net>

I forgot to mention that my CPU is not even 100% used.
With 4 robots I have to set pauseTime to 0.4. And even then the warning is 
being displayed after some time.

Does this mean that Pyro is not reading fast enough Player's data or that my 
robots do not manage to write their motor commands efficiently back to 
Player?

In your mail you mentioned Player's -u option. Where could I specify it using 
Pyro?

Thanks,
wr

Am Dienstag, 17. Mai 2005 16:37 schrieb Willi Richert:
> Hi,
>
> I refer to Doug's previous post "[Pyro-developers] Timing issues in Pyro".
>
> You said that you get 85 updates/s with pauseTime=0.05
>
> I delved again into my timing issues, because I get lots of
> "warning : XXX bytes leftover on write() to client" if I simulate two
> brains. With only one I get no warnings and ~ 10 updates/s (Pentium(R) M
> processor 1600MHz) .
>
> Does this mean that my code is thinking too much between the update()s? I
> have no chance to make it faster.
>
> -
> wr
>
> PS: There is a post on that at the playerstage ML
> (http://sourceforge.net/mailarchive/forum.php?forum_id=8201&style=flat&view
>day=15&viewmonth=200403) which did not help me very much.
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
From w.richert at gmx.net  Sat May 21 08:50:23 2005
From: w.richert at gmx.net (Willi Richert)
Date: Sat May 21 08:50:35 2005
Subject: [Pyro-developers] Strange errors related to client code loading
	(system/__init__)
Message-ID: <200505211450.23756.w.richert@gmx.net>

Hi,

Recently, I got strange errors if when inheriting from 
pyro.brain.behaviors.fsm.State in more than 2 hierarchy levels. This error 
only occurs with more than one robot:

Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
    self.run()
  File "/home/wr/forschung/software/ps/pyro/brain/__init__.py", line 154, in 
run
    self.step()
  File "NeedBrain.py", line 425, in step
    BehaviorBasedBrain.step(self)
  File "/home/wr/forschung/software/ps/pyro/brain/behaviors/__init__.py", line 
67, in step
    self.states[s].run()
  File "/home/wr/forschung/software/ps/pyro/brain/behaviors/fsm.py", line 125, 
in run
    self.update()
  File "NeedBrain.py", line 256, in update
    MarkerAction.update(self)
TypeError: unbound method update() must be called with MarkerAction 
instance as first argument (got ApproachMarker10Action instance instead)

I have the following dependence tree: State -> MarkerAction -> 
ApproachMarkerAction -> ApproachMarker10Action 

I've found several ways to workaround the exception, but still I don't know, 
why it happens. 

1. Move all members from MarkerAction to ApproachMarker and remove 
MarkerAction from the hierarchy.
2. In pyro/system/__init__.py in the client code loading section

    exec("import " + module + " as userspace")
    reload(userspace)

uncomment out the reload line. At the #python IRC channel they suggested a 
better way (though I don't know why):
userspace = __import__(module)
3. Instead of MarkerAction.update(self) use 
MarkerAction.__bases__[0].__dict__["update"](self)


As it seems the error has something to do with the fact that the robot client 
code (the Brain) is loaded as a module and the reload() seems to do some 
strange things if more than one robot is loaded.

Any further clarifying on the situation?

wr
From dblank at brynmawr.edu  Sat May 21 09:53:40 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Sat May 21 09:53:46 2005
Subject: [Pyro-developers] Strange errors related to client code loading
	(system/__init__)
In-Reply-To: <200505211450.23756.w.richert@gmx.net>
References: <200505211450.23756.w.richert@gmx.net>
Message-ID: <428F3D64.5000102@brynmawr.edu>

Willi,

I don't think I'd be able to understand what's wrong without specific 
code. You have identified the tricky bit of code that Pyro uses to 
load/reload the brain, and that was arrived at through trial and error. 
If there is a better method of implementing the functionality, we 
certainly would do it. (The code was designed to force a reloading of file.)

Do any of your classes share global variables? Anything that happens 
only once when loading your classes? Does your code work if the load 
code in pyro/system/__init__.py is changed to:

    userspace = __import__(module)
    reload(userspace)

If so, we'll change it.

-Doug

Willi Richert wrote:
> Hi,
> 
> Recently, I got strange errors if when inheriting from 
> pyro.brain.behaviors.fsm.State in more than 2 hierarchy levels. This error 
> only occurs with more than one robot:
> 
> Exception in thread Thread-2:
> Traceback (most recent call last):
>   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
>     self.run()
>   File "/home/wr/forschung/software/ps/pyro/brain/__init__.py", line 154, in 
> run
>     self.step()
>   File "NeedBrain.py", line 425, in step
>     BehaviorBasedBrain.step(self)
>   File "/home/wr/forschung/software/ps/pyro/brain/behaviors/__init__.py", line 
> 67, in step
>     self.states[s].run()
>   File "/home/wr/forschung/software/ps/pyro/brain/behaviors/fsm.py", line 125, 
> in run
>     self.update()
>   File "NeedBrain.py", line 256, in update
>     MarkerAction.update(self)
> TypeError: unbound method update() must be called with MarkerAction 
> instance as first argument (got ApproachMarker10Action instance instead)
> 
> I have the following dependence tree: State -> MarkerAction -> 
> ApproachMarkerAction -> ApproachMarker10Action 
> 
> I've found several ways to workaround the exception, but still I don't know, 
> why it happens. 
> 
> 1. Move all members from MarkerAction to ApproachMarker and remove 
> MarkerAction from the hierarchy.
> 2. In pyro/system/__init__.py in the client code loading section
> 
>     exec("import " + module + " as userspace")
>     reload(userspace)
> 
> uncomment out the reload line. At the #python IRC channel they suggested a 
> better way (though I don't know why):
> userspace = __import__(module)
> 3. Instead of MarkerAction.update(self) use 
> MarkerAction.__bases__[0].__dict__["update"](self)
> 
> 
> As it seems the error has something to do with the fact that the robot client 
> code (the Brain) is loaded as a module and the reload() seems to do some 
> strange things if more than one robot is loaded.
> 
> Any further clarifying on the situation?
> 
> wr
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 
> 


-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From dblank at brynmawr.edu  Sat May 21 11:05:04 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Sat May 21 11:05:07 2005
Subject: [Pyro-developers] Pyro4 LiveCD beta
Message-ID: <428F4E20.6010201@brynmawr.edu>

Pyro users/developers,

There is now a beta version of the Pyro4 Live CD at:

http://PyroRobotics.org/?page=PyroLiveCD

It is a full install of the current version of Pyro4 out of CVS now 
using Knoppix 3.8.1 (the latest Knoppix version). The disk also comes 
with all of the latest Player/Stage/Gazebo installed. The CD doesn't 
currently have the Robocup soccer server, or a start-up Pyro HTML page. 
But will shortly.

Also, Gazebo probably won't work, unless Knoppix correctly identifies 
your graphics card. In addition, your graphics card will need to support 
the advanced GLX commands that Gazebo requires. (If you try this, let us 
know if it works.)

The Pyro4 LiveCD will certainly run these simulators:

  - Stage   (2D simulator)
  - Khepera (old 2D of the Khepera)
  - Symbolic (for AI symbolic worlds and games)

Knoppix 3.8.1 is very nice in that it uses a new filesystem (unionfs) 
that can simulate a read/write disk (even though it is really just a 
read-only disk). This makes it very easy to pretend like you have an 
installed version of Linux. There are also easy ways to save these 
changes, and also an easy way to turn the CD into an installed version 
of Debian Linux.

Instructions and downloadable versions of Pyro4 will be available this 
week. Holly Yanco and I will be giving a Pyro Tutorial at AAAI this 
summer in Pittsburgh, PA. Find out more at:

http://www.aaai.org/Conferences/National/2005/tutorials05.html

-Doug

-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From dblank at brynmawr.edu  Sun May 22 17:25:32 2005
From: dblank at brynmawr.edu (dblank@brynmawr.edu)
Date: Sun May 22 17:25:34 2005
Subject: [Pyro-developers] Pyro becomes Pyrobot
Message-ID: <35417.68.81.116.28.1116797132.squirrel@newwebmail.brynmawr.edu>

Pyro users/developers,

Because of a longstanding naming conflict with another open source Python
project, we are changing the main Python package name used for importing
in Python code.

Pyro, Python Remote Objects has been around for many years, even longer
than Pyro, Python Robotics. In addition, some users use both the robotics
and remote object systems. This was problematic, as both projects used the
name "pyro" to import code.

We thought for quite a bit as to resolve this to make everyone happy, and
to make it not too painful. We settled on the name "pyrobot". You can
think of it as short for "PYthon ROBOTics", or "Pyro Bot", or, you can
think of it of "Py, Robot" a play on Asimov's "I, Robot".

This name change effect the CVS repository, and the way that you import
code. You now should write:

import pyrobot.modulename
from pyrobot.modulename import *

Also, you will start the main program with "pyrobot" and "ipyrobot" (we
may have a link to "pyro" in the interim). We won't change the project
name, so you can still refer to the project as Pyro.

This change is now in CVS, and will appear on the next Pyrobot versions
and LiveCD (version 4.0.1 and above).

-Doug


From bturner1 at gmail.com  Wed May 25 14:31:36 2005
From: bturner1 at gmail.com (Ben Turner)
Date: Wed May 25 14:31:39 2005
Subject: [Pyro-developers] goto methods in FSM brains
Message-ID: <b5479c9605052511319fd3003@mail.gmail.com>

I'm running Pyrobot 4.0.1 and tyring to use the FSMSquare brain on a
Player robot in the 'everything' world of the Stage simulator. When I
hit Run, the robot works ok until the brain tries to switch out of its
first state and into its second. Then I get the followning error:

Exception in thread Thread-1:Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 442, in __bootstrap
    self.run()
  File "./brain/__init__.py", line 148, in run
  File "./brain/behaviors/fsm.py", line 39, in step
  File "./brain/behaviors/fsm.py", line 123, in run
  File "./plugins/brains/FSMSquare.py", line 47, in update
  File "./brain/behaviors/fsm.py", line 73, in goto
  File "./brain/__init__.py", line 97, in __getattr__
AttributeError: '<type FSMBrain>' object has no attribute 'goto'

The same thing happens when I use FSMPushPop, and when I run
AiboFindball or AiboSoccer on the AIBO. Should these brains have goto
methods? If so what should happen in these methods?

--
Ben Turner
Swarthmore College 2006
bturner1@swarthmore.edu
bturner1@gmail.com

From ethan.jucovy at gmail.com  Wed May 25 14:45:30 2005
From: ethan.jucovy at gmail.com (Ethan Jucovy)
Date: Wed May 25 14:45:34 2005
Subject: [Pyro-developers] Subsumption.py
Message-ID: <a508aad3050525114564be5890@mail.gmail.com>

The Subsumption.py sample brain in the repository doesn't work because
the Behavior class it defines doesn't have a get() method.  It's a
one-line fix.  (I think the class name should also be changed to
SubsumptionBehavior since behaviors.py already defines a class
Behavior.)

class Behavior:
    def __init__(self):
        self.translate = 0
        self.rotate = 0
        self.flag = 0
[etc]
----

class SubsumptionBehavior:
    def __init__(self):
        self.translate = 0
        self.rotate = 0
        self.flag = 0

    def get(self, *args):
         return self.robot.get(*args)
[etc]
----

Or alternatively 

class SubsumptionBehavior:
    def __init__(self):
        self.translate = 0
        self.rotate = 0
        self.flag = 0

    def setRobot(self, robot):
        self.robot = robot
        self.get = self.robot.get
----

I suppose the former is better in terms of clarity/object-orientation
but the latter should be slightly faster unless python knows to inline
the get function.

From ethan.jucovy at gmail.com  Wed May 25 15:08:53 2005
From: ethan.jucovy at gmail.com (Ethan Jucovy)
Date: Wed May 25 15:08:55 2005
Subject: [Pyro-developers] "bytes leftover on write() to client"
Message-ID: <a508aad305052512085dacb21c@mail.gmail.com>

Ben and I are getting this warning while running the stage simulator
on the "everything" world:

"warning: x bytes leftover on write() to client"

where x is varying anywhere from 1 to ~900 bytes.  I got it while
running Subsumption.py and he got it with BBWander.py after it was
running for about 5 or 6 minutes, and the warning seems to repeat
every time step with different numbers of bytes.  After a little while
longer the simulator display stops refreshing unless the mouse is held
down over it.  Is this a memory leak somewhere?

-Ethan

From dblank at brynmawr.edu  Thu May 26 11:49:32 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Thu May 26 11:49:39 2005
Subject: [Pyro-developers] "bytes leftover on write() to client"
In-Reply-To: <a508aad305052512085dacb21c@mail.gmail.com>
References: <a508aad305052512085dacb21c@mail.gmail.com>
Message-ID: <4295F00C.5090602@brynmawr.edu>

Ethan Jucovy wrote:
> Ben and I are getting this warning while running the stage simulator
> on the "everything" world:
> 
> "warning: x bytes leftover on write() to client"

Ethan,

This warning means, I think, that the communication between Pyro and 
Player is not keeping up. I tried the same brain in that world, and it 
has been running for about 30 minutes without any problems.

It may be that your computer is just not keeping up, and falling further 
and further behind. What is your processor speed and memory size? What 
is the load? Are others on the machine?

There are some things you can do even if your computer is too slow for 
the defaults. The first is to slow down Players updates. I think by 
default it sends 10 updates a second. The place to look for this would 
be where Pyro starts the communication with Player:

pyrobot/robot/player.py

I think that you can set the frequency of the updates. It will problem 
be a call to the robot.client object of a Player robot. Check the 
Player/Stage/Gazebo docs. For example, see:

http://playerstage.sourceforge.net/doc/Player-current/player-html/

I doubt that it is a memory leak. Let us know what you find.

-Doug

> where x is varying anywhere from 1 to ~900 bytes.  I got it while
> running Subsumption.py and he got it with BBWander.py after it was
> running for about 5 or 6 minutes, and the warning seems to repeat
> every time step with different numbers of bytes.  After a little while
> longer the simulator display stops refreshing unless the mouse is held
> down over it.  Is this a memory leak somewhere?
> 
> -Ethan
> 
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 
> 


-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From dblank at brynmawr.edu  Thu May 26 12:00:33 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Thu May 26 12:00:36 2005
Subject: [Pyro-developers] Subsumption.py
In-Reply-To: <a508aad3050525114564be5890@mail.gmail.com>
References: <a508aad3050525114564be5890@mail.gmail.com>
Message-ID: <4295F2A1.8010003@brynmawr.edu>

Ethan, it is now fixed in CVS, and thanks for fixing it in the wiki. -Doug

Ethan Jucovy wrote:
> The Subsumption.py sample brain in the repository doesn't work because
> the Behavior class it defines doesn't have a get() method.  It's a
> one-line fix.  (I think the class name should also be changed to
> SubsumptionBehavior since behaviors.py already defines a class
> Behavior.)

-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From dblank at brynmawr.edu  Thu May 26 13:20:37 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Thu May 26 13:20:41 2005
Subject: [Pyro-developers] goto methods in FSM brains
In-Reply-To: <b5479c9605052511319fd3003@mail.gmail.com>
References: <b5479c9605052511319fd3003@mail.gmail.com>
Message-ID: <42960565.70009@brynmawr.edu>

Ben,

Yes, that code was a little mixed up. I've straightened it up a bit, by 
putting all of the States, Behaviors, and brains that use those in one file:

pyrobot/brains/behaviors/__init__.py

which means that you can get all of those classes with:

from pyrobot.brains.behaviors import *

I just deleted fsm.py. I am getting a bit strange behavior with those 
BehaviorBasedBrains that have a lot of states. I wonder if there isn't a 
better way to implement some of that...

In any event, CVS has the changes in Pyro 4.0.2.

-Doug

Ben Turner wrote:
> I'm running Pyrobot 4.0.1 and tyring to use the FSMSquare brain on a
> Player robot in the 'everything' world of the Stage simulator. When I
> hit Run, the robot works ok until the brain tries to switch out of its
> first state and into its second. Then I get the followning error:
> 
> Exception in thread Thread-1:Traceback (most recent call last):
>   File "/usr/lib/python2.3/threading.py", line 442, in __bootstrap
>     self.run()
>   File "./brain/__init__.py", line 148, in run
>   File "./brain/behaviors/fsm.py", line 39, in step
>   File "./brain/behaviors/fsm.py", line 123, in run
>   File "./plugins/brains/FSMSquare.py", line 47, in update
>   File "./brain/behaviors/fsm.py", line 73, in goto
>   File "./brain/__init__.py", line 97, in __getattr__
> AttributeError: '<type FSMBrain>' object has no attribute 'goto'
> 
> The same thing happens when I use FSMPushPop, and when I run
> AiboFindball or AiboSoccer on the AIBO. Should these brains have goto
> methods? If so what should happen in these methods?
> 
> --
> Ben Turner
> Swarthmore College 2006
> bturner1@swarthmore.edu
> bturner1@gmail.com
> 
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 
> 


-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From ethan.jucovy at gmail.com  Fri May 27 15:12:10 2005
From: ethan.jucovy at gmail.com (Ethan Jucovy)
Date: Fri May 27 15:12:13 2005
Subject: [Pyro-developers] "no module named version,
	cannot import name Brain"
Message-ID: <a508aad30505271212788b5630@mail.gmail.com>

With the latest code from the CVS, I'm getting the following errors
when I try to import behaviors:

Python 2.3.5 (#2, Feb  9 2005, 00:38:15) 
>>> from pyrobot.brain.behaviors import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 4, in ?
    #
  File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 8, in ?
    #
  File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 3, in ?
    # $Id: //modules/pil/PIL/__init__.py#2 $
ImportError: No module named version
>>> from pyrobot.brain.behaviors import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/ejucovy1/summerWork/pyrobot/brain/behaviors/__init__.py",
line 6, in ?
    from pyrobot.brain import Brain
ImportError: cannot import name Brain
>>> from pyrobot.brain.behaviors import *
>>> from pyrobot.brain.behaviors import *
>>>

From w.richert at gmx.net  Fri May 27 15:25:20 2005
From: w.richert at gmx.net (Willi Richert)
Date: Fri May 27 15:25:35 2005
Subject: [Pyro-developers] "no module named version,
	cannot import name Brain"
In-Reply-To: <a508aad30505271212788b5630@mail.gmail.com>
References: <a508aad30505271212788b5630@mail.gmail.com>
Message-ID: <200505272125.20812.w.richert@gmx.net>

Did you do 
python configure.py 
at first?

- wr
Am Freitag, 27. Mai 2005 21:12 schrieb Ethan Jucovy:
> With the latest code from the CVS, I'm getting the following errors
> when I try to import behaviors:
>
> Python 2.3.5 (#2, Feb  9 2005, 00:38:15)
>
> >>> from pyrobot.brain.behaviors import *
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 4, in ?
>     #
>   File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 8, in ?
>     #
>   File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 3, in ?
>     # $Id: //modules/pil/PIL/__init__.py#2 $
> ImportError: No module named version
>
> >>> from pyrobot.brain.behaviors import *
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/home/ejucovy1/summerWork/pyrobot/brain/behaviors/__init__.py",
> line 6, in ?
>     from pyrobot.brain import Brain
> ImportError: cannot import name Brain
>
> >>> from pyrobot.brain.behaviors import *
> >>> from pyrobot.brain.behaviors import *
>
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
From dblank at mainline.brynmawr.edu  Fri May 27 16:00:57 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Fri May 27 16:00:59 2005
Subject: [Pyro-developers] "no module named version,
	cannot import name Brain"
In-Reply-To: <200505272125.20812.w.richert@gmx.net>
References: <a508aad30505271212788b5630@mail.gmail.com>,
	<a508aad30505271212788b5630@mail.gmail.com>
Message-ID: <twig.1117224057.3629@cs.brynmawr.edu>

I was hoping that we can go to a Python-based distutils "setup.py" install,
but I find it much harder to use than a make file, and have about given up on
the idea.

In any event, the current method is still "make" which will call "python
configure.py" if there is no Makefile.cfg. To reconfigure Pyro, just run
"python configure.py" or "make config" again, or just edit Makefile.cfg.

After you run make (which will build all of the C/C++ projects needed) you can
then run pyrobot/bin/pyrobot. You might find that pyro finds a different
installed version other than one in your home directory. If you do, you can
list your home directory version first in PYTHONPATH:

export PYTHONPATH=/home/yourid:$PYTHONPATH

(if pyrobot is installed in your root directory). You can also set PYROBOT env
variable to somewhere else, to switch between installed versions.

You might be interested in setting a PYTHONSTARTUP env variable. For more
information see:

http://pyrorobotics.org/pyro/?page=PyroInstallation
http://pyrorobotics.org/pyro/?page=PyroSetUp

-Doug

Willi Richert <w.richert@gmx.net> said:

> Did you do 
> python configure.py 
> at first?
> 
> - wr
> Am Freitag, 27. Mai 2005 21:12 schrieb Ethan Jucovy:
> > With the latest code from the CVS, I'm getting the following errors
> > when I try to import behaviors:
> >
> > Python 2.3.5 (#2, Feb  9 2005, 00:38:15)
> >
> > >>> from pyrobot.brain.behaviors import *
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 4, in ?
> >     #
> >   File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 8, in ?
> >     #
> >   File "/usr/lib/python2.3/site-packages/PIL/__init__.py", line 3, in ?
> >     # $Id: //modules/pil/PIL/__init__.py#2 $
> > ImportError: No module named version
> >
> > >>> from pyrobot.brain.behaviors import *
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "/home/ejucovy1/summerWork/pyrobot/brain/behaviors/__init__.py",
> > line 6, in ?
> >     from pyrobot.brain import Brain
> > ImportError: cannot import name Brain
> >
> > >>> from pyrobot.brain.behaviors import *
> > >>> from pyrobot.brain.behaviors import *
> >
> > _______________________________________________
> > Pyro-developers mailing list
> > Pyro-developers@emergent.brynmawr.edu
> > http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 



-- 



From w.richert at gmx.net  Sat May 28 04:23:00 2005
From: w.richert at gmx.net (Willi Richert)
Date: Sat May 28 04:23:20 2005
Subject: [Pyro-developers] small bugfix in State
Message-ID: <200505281023.01295.w.richert@gmx.net>

Hi,

the State class has a little bug, if I understand it right:

   def pop(self):
      if len(self.brain.states) > 0:
         returnState = self.brain.stack.pop()
         self.goto(returnState)
      else:
         raise AttributeError, "pop without a push in state '%s'" % self.name


I think the proper check would be
    if len(self.brain.stack) > 0:


Have fun,
wr
From dblank at mainline.brynmawr.edu  Sat May 28 11:07:40 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Sat May 28 11:07:42 2005
Subject: [Pyro-developers] small bugfix in State
In-Reply-To: <200505281023.01295.w.richert@gmx.net>
Message-ID: <twig.1117292860.51279@cs.brynmawr.edu>

Yep, good eyes. Fixed in CVS. Thanks! -Doug

Willi Richert <w.richert@gmx.net> said:

> Hi,
> 
> the State class has a little bug, if I understand it right:
> 
>    def pop(self):
>       if len(self.brain.states) > 0:
>          returnState = self.brain.stack.pop()
>          self.goto(returnState)
>       else:
>          raise AttributeError, "pop without a push in state '%s'" % self.name
> 
> 
> I think the proper check would be
>     if len(self.brain.stack) > 0:
> 
> 
> Have fun,
> wr

-- 



From w.richert at gmx.net  Sat May 28 12:52:16 2005
From: w.richert at gmx.net (Willi Richert)
Date: Sat May 28 12:52:33 2005
Subject: [Pyro-developers] Seldom but strange Fuzzy-related error
Message-ID: <200505281852.16980.w.richert@gmx.net>

Hi,

after approx 1500 timesteps I got a really strange error:
Exception: tuple assignment index out of range
<Fuzzy instance value = 0.5 min = 1.5 max = 3> <C playerc_fiducial_item_t instance at _68261008_p_playerc_fiException in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
    self.run()
  File "./brain/__init__.py", line 148, in run
  File "NeedBrain.py", line 454, in step
    BehaviorBasedBrain.step(self)
  File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", line 63, in step
    self.states[s].run()
  File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", line 292, in run
    b.update() # fires IF rules
  File "NeedBrain.py", line 94, in update
    self.IF(1, 'translate', trans)
UnboundLocalError: local variable 'trans' referenced before assignment

ducial_item_t>

It happened in the line "trans, rot = self.fuTrans >> m_obj.range, m_obj.bearing" at the following class:

class MoveToMarkerBehavior(Behavior):
    def __init__(self, marker, status = 0, effects = {}, name = ''):
        Behavior.__init__(self, status, effects, name)
        self.marker = marker
        self.fuTrans = Fuzzy(1.5, 3)

    def update(self):
        m_obj = self.get("robot/fiducial/id")(self.marker)
        
        if not m_obj:
            l, r = min(self.get('robot/range/front-left/value')), min(self.get('robot/range/front-right/value'))
            if not self.searchDir:
                if l>r:
                    self.searchDir = 1
                else:
                    self.searchDir = -1

            trans, rot = 0.4, self.searchDir*math.pi/4

        else:
            try:
                self.searchDir = None
                trans, rot = self.fuTrans >> m_obj.range, m_obj.bearing
            except Exception, e:
                print "Exception:",str(e)
                print self.fuTrans, m_obj
            
        self.IF(1, 'translate', trans)
        self.IF(1, 'rotate', rot)
        
    def onActivate(self):
        self.searchDir = None
    

I remember that I already had a strange Fuzzy related problem, so I encapsulated it with the try/except block.
This error occurs very seldom. Any hint why it is occurring? My code? Pyro? 
Any suggestions/improvements to the mentioned code are welcome.

Thanks,
wr
From dblank at mainline.brynmawr.edu  Sat May 28 13:49:37 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Sat May 28 13:49:40 2005
Subject: [Pyro-developers] Seldom but strange Fuzzy-related error
In-Reply-To: <200505281852.16980.w.richert@gmx.net>
Message-ID: <twig.1117302577.97032@cs.brynmawr.edu>

Thant looks suspiciously like a thread issue, but I don't know why it would
happen here. I'll try to look later, if you don't find a solution. -Doug

Willi Richert <w.richert@gmx.net> said:

> Hi,
> 
> after approx 1500 timesteps I got a really strange error:
> Exception: tuple assignment index out of range
> <Fuzzy instance value = 0.5 min = 1.5 max = 3> <C playerc_fiducial_item_t
instance at _68261008_p_playerc_fiException in thread Thread-2:
> Traceback (most recent call last):
>   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
>     self.run()
>   File "./brain/__init__.py", line 148, in run
>   File "NeedBrain.py", line 454, in step
>     BehaviorBasedBrain.step(self)
>   File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py",
line 63, in step
>     self.states[s].run()
>   File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py",
line 292, in run
>     b.update() # fires IF rules
>   File "NeedBrain.py", line 94, in update
>     self.IF(1, 'translate', trans)
> UnboundLocalError: local variable 'trans' referenced before assignment
> 
> ducial_item_t>
> 
> It happened in the line "trans, rot = self.fuTrans >> m_obj.range,
m_obj.bearing" at the following class:
> 
> class MoveToMarkerBehavior(Behavior):
>     def __init__(self, marker, status = 0, effects = {}, name = ''):
>         Behavior.__init__(self, status, effects, name)
>         self.marker = marker
>         self.fuTrans = Fuzzy(1.5, 3)
> 
>     def update(self):
>         m_obj = self.get("robot/fiducial/id")(self.marker)
>         
>         if not m_obj:
>             l, r = min(self.get('robot/range/front-left/value')),
min(self.get('robot/range/front-right/value'))
>             if not self.searchDir:
>                 if l>r:
>                     self.searchDir = 1
>                 else:
>                     self.searchDir = -1
> 
>             trans, rot = 0.4, self.searchDir*math.pi/4
> 
>         else:
>             try:
>                 self.searchDir = None
>                 trans, rot = self.fuTrans >> m_obj.range, m_obj.bearing
>             except Exception, e:
>                 print "Exception:",str(e)
>                 print self.fuTrans, m_obj
>             
>         self.IF(1, 'translate', trans)
>         self.IF(1, 'rotate', rot)
>         
>     def onActivate(self):
>         self.searchDir = None
>     
> 
> I remember that I already had a strange Fuzzy related problem, so I
encapsulated it with the try/except block.
> This error occurs very seldom. Any hint why it is occurring? My code? Pyro? 
> Any suggestions/improvements to the mentioned code are welcome.
> 
> Thanks,
> wr
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 



-- 



From ethan.jucovy at gmail.com  Sun May 29 02:40:33 2005
From: ethan.jucovy at gmail.com (Ethan Jucovy)
Date: Sun May 29 02:40:35 2005
Subject: [Pyro-developers] Fuzzy class
Message-ID: <a508aad305052823402642cb71@mail.gmail.com>

Pyro's Fuzzy class seems sort of limited and confusing to me, so I'm
in the process of writing a new Fuzzy class which I hope will be more
extendable and more intuitive.  If you use Pyro's Fuzzy class, please
let me know what you think of this proposed change: whether it's worth
doing at all, what I'm doing wrong, what I should add / do differently
/ etc.  I haven't done much with this yet, but here's an outline of
how my new class works:

Basically this Fuzzy class contains a membership function and a
dictionary of parameters to be used by the membership function.  The
function itself can be set to anything you like.  Unlike Pyro's
current Fuzzy class this class does not store a value; to fuzzify a
variable you would call the instance of the class with the variable to
fuzzify as a parameter.

I've written a few 'common' functions for convenience--rising and
falling functions (like the current << and >> graphs) and triangular
and trapezoidal ones.  I could also add other functions very easily
(smooth ones, for instance?).  Fuzzys with these membership functions
can be created by calling a constructor function and supplying the
relevant parameters.  So

>>> f = RisingFuzzy(0,20)
>>> x = 10
>>> print f(x)
0.5
>>> f = TriangleFuzzy(0,10,20)
>>> print f(x)
1.0
>>> print f
< Fuzzy instance with parameters {'a':0, 'b':10, 'c':20} and
membership function Triangle >

To create a custom Fuzzy you would supply the membership function and
the parameter names and values when you create the Fuzzy.

>>> def aFunction(x,p):
>>>  if p['flag'] == False:
>>>    return 1.0 - x
>>>  else:
>>>     return x * p['multiplier']

>>> f = Fuzzy({'flag':True, 'multiplier':0.5}, aFunction)
>>> print f(0.8)
0.4

I'm trying to figure out if there's a more convenient/prettier way to
handle parameters, and I'm thinking of wrapping the Fuzzy constructor
in a function for consistency, but that's the basic gist of it.  It
would probably be fairly easy to make Pyro's current syntax work with
this new class, too.

-Ethan

From ethan.jucovy at gmail.com  Sun May 29 03:10:28 2005
From: ethan.jucovy at gmail.com (Ethan Jucovy)
Date: Sun May 29 03:10:30 2005
Subject: [Pyro-developers] Re: Seldom but strange Fuzzy-related error
Message-ID: <a508aad3050529001055425635@mail.gmail.com>

Hi there,

I don't know if this is the cause of the problem, but "Fuzzy >> value"
returns a Fuzzy, not a float.  To get a floating-point value out of
that expression you need to cast the resulting Fuzzy to a float.  It's
possible that when the rule kicks in and m_obj is true Pyro is trying
to assign the Fuzzy to the robot's translation without casting it, and
it's getting upset about that.  So try changing the offending line to

trans, rot = float(self.fuTrans >> m_obj.range), m_obj.bearing

Does that help?

-Ethan

From dblank at mainline.brynmawr.edu  Sun May 29 10:17:22 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Sun May 29 10:17:24 2005
Subject: [Pyro-developers] Re: Seldom but strange Fuzzy-related error
In-Reply-To: <a508aad3050529001055425635@mail.gmail.com>
Message-ID: <twig.1117376242.87214@cs.brynmawr.edu>

I was thinking that it was realted to this, and I bet I know why. What Willi
had was correct, and Ethan has correctly pointed to the root cause of the
problem. The key issue, I think, is that an object is being created here, and
returned. But the object isn't turned into a float until it gets to another
thread. At least this is what I'm guessing.

Threads with Python (and Tkinter) can be tricky: many things work that really
shouldn't... at least most of the time.

-Doug

Ethan Jucovy <ethan.jucovy@gmail.com> said:

> Hi there,
> 
> I don't know if this is the cause of the problem, but "Fuzzy >> value"
> returns a Fuzzy, not a float.  To get a floating-point value out of
> that expression you need to cast the resulting Fuzzy to a float.  It's
> possible that when the rule kicks in and m_obj is true Pyro is trying
> to assign the Fuzzy to the robot's translation without casting it, and
> it's getting upset about that.  So try changing the offending line to
> 
> trans, rot = float(self.fuTrans >> m_obj.range), m_obj.bearing
> 
> Does that help?
> 
> -Ethan
> 
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 



-- 



From dblank at mainline.brynmawr.edu  Sun May 29 10:49:05 2005
From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu)
Date: Sun May 29 10:49:06 2005
Subject: [Pyro-developers] Fuzzy class
In-Reply-To: <a508aad305052823402642cb71@mail.gmail.com>
Message-ID: <twig.1117378145.51398@cs.brynmawr.edu>

Some things you might look into:

When you pass arguments by keyword to a function or method, they are put into
a dictionary. You can grab that dictionary with 2 stars:

def function(**keywords):
   print keywords

You can also pass them along:

def function(**keywords):
   return otherFunc(**keywords)

That way you can write:

function(multiplier=.2, val1 = 3)

Also, your suggestion of a function taking a function and returning a function
reminds me of the "decorator" idea in Python:

def decorator(f):
   def newF(a, b)
       return f(a, b) + 1
   return newF

@decorator
def plain(a, b):
   return a * b

But that only works in Python 2.4, and I'm not sure if it helps what you are
attempting to do. Good luck!

-Doug

Ethan Jucovy <ethan.jucovy@gmail.com> said:

> Pyro's Fuzzy class seems sort of limited and confusing to me, so I'm
> in the process of writing a new Fuzzy class which I hope will be more
> extendable and more intuitive.  If you use Pyro's Fuzzy class, please
> let me know what you think of this proposed change: whether it's worth
> doing at all, what I'm doing wrong, what I should add / do differently
> / etc.  I haven't done much with this yet, but here's an outline of
> how my new class works:
> 
> Basically this Fuzzy class contains a membership function and a
> dictionary of parameters to be used by the membership function.  The
> function itself can be set to anything you like.  Unlike Pyro's
> current Fuzzy class this class does not store a value; to fuzzify a
> variable you would call the instance of the class with the variable to
> fuzzify as a parameter.
> 
> I've written a few 'common' functions for convenience--rising and
> falling functions (like the current << and >> graphs) and triangular
> and trapezoidal ones.  I could also add other functions very easily
> (smooth ones, for instance?).  Fuzzys with these membership functions
> can be created by calling a constructor function and supplying the
> relevant parameters.  So
> 
> >>> f = RisingFuzzy(0,20)
> >>> x = 10
> >>> print f(x)
> 0.5
> >>> f = TriangleFuzzy(0,10,20)
> >>> print f(x)
> 1.0
> >>> print f
> < Fuzzy instance with parameters {'a':0, 'b':10, 'c':20} and
> membership function Triangle >
> 
> To create a custom Fuzzy you would supply the membership function and
> the parameter names and values when you create the Fuzzy.
> 
> >>> def aFunction(x,p):
> >>>  if p['flag'] == False:
> >>>    return 1.0 - x
> >>>  else:
> >>>     return x * p['multiplier']
> 
> >>> f = Fuzzy({'flag':True, 'multiplier':0.5}, aFunction)
> >>> print f(0.8)
> 0.4
> 
> I'm trying to figure out if there's a more convenient/prettier way to
> handle parameters, and I'm thinking of wrapping the Fuzzy constructor
> in a function for consistency, but that's the basic gist of it.  It
> would probably be fairly easy to make Pyro's current syntax work with
> this new class, too.
> 
> -Ethan
> 
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 



-- 



From w.richert at gmx.net  Sun May 29 11:00:35 2005
From: w.richert at gmx.net (Willi Richert)
Date: Sun May 29 12:33:50 2005
Subject: [Pyro-developers] Re: Seldom but strange Fuzzy-related error
In-Reply-To: <twig.1117376242.87214@cs.brynmawr.edu>
References: <twig.1117376242.87214@cs.brynmawr.edu>
Message-ID: <200505291700.35881.w.richert@gmx.net>

Hmm,


Am Sonntag, 29. Mai 2005 16:17 schrieb dblank@mainline.brynmawr.edu:
> I was thinking that it was realted to this, and I bet I know why. What
> Willi had was correct, and Ethan has correctly pointed to the root cause of
> the problem. The key issue, I think, is that an object is being created
> here, and returned. But the object isn't turned into a float until it gets
> to another thread. At least this is what I'm guessing.

But then, the update() should have been interrupted somehow. It is called 
within the Brain-Thread
From w.richert at gmx.net  Sun May 29 13:09:49 2005
From: w.richert at gmx.net (Willi Richert)
Date: Sun May 29 13:10:06 2005
Subject: [Pyro-developers] Re: Seldom but strange Fuzzy-related error
In-Reply-To: <200505291700.35881.w.richert@gmx.net>
References: <twig.1117376242.87214@cs.brynmawr.edu>
	<200505291700.35881.w.richert@gmx.net>
Message-ID: <200505291909.49765.w.richert@gmx.net>

Sorry, somehow my mailer sent the mail too early ...

The situation is the following: I have three robots running in parallel, 
everyone within it's own thread. Doug said: "But the object isn't turned into 
a float until it gets to another thread." But the IF() call does just this 
and it is following directly the Fuzzy invocation:
   def IF(self, fvalue, controller, amount = 1.0, name = ''):
      if name == '':
         name = "Rule%d" % (len(self.rules) + 1)
      self.rules.append([float(fvalue), controller, float(amount), name])

So I do not see where another thread would interrupt this control flow. 
Somehow, the three Brains must be tinkering with each others data somehow - I 
don't see where this is possible. 

And the real error is not the UnboundLocalError in the IF()-call, but the line
	trans, rot = self.fuTrans >> m_obj.range, m_obj.bearing
I will run additional test. Will take some time to trigger the error again.

Anyway, thank you very much for your help.
wr
From w.richert at gmx.net  Mon May 30 05:55:32 2005
From: w.richert at gmx.net (Willi Richert)
Date: Mon May 30 05:55:57 2005
Subject: [Pyro-developers] Maybe threading-related exceptions
Message-ID: <200505301155.32250.w.richert@gmx.net>

Hi,

here is another strange error:

Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
    self.run()
  File "./brain/__init__.py", line 151, in run
IndexError: tuple assignment index out of range

Line 151 in brain/__init__.py is
            self.couldBeMoving = 1

wr
From w.richert at gmx.net  Mon May 30 08:21:01 2005
From: w.richert at gmx.net (Willi Richert)
Date: Mon May 30 08:21:16 2005
Subject: [Pyro-developers] Maybe threading-related exceptions
In-Reply-To: <200505301155.32250.w.richert@gmx.net>
References: <200505301155.32250.w.richert@gmx.net>
Message-ID: <200505301421.01647.w.richert@gmx.net>

Hi,

here is another exception that has just occurred and is totally unreasonable to me:

NeedBrain.py:245: RuntimeWarning: tp_compare didn't return -1 or -2 for exception
  return self.markerDistance() < self.STAY_MIN_DIST
Exception in thread Thread-4:
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
    self.run()
  File "./brain/__init__.py", line 148, in run
  File "NeedBrain.py", line 415, in step
    BehaviorBasedBrain.step(self)
  File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", line 63, in step
    self.states[s].run()
  File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", line 299, in run
    self.update()
  File "NeedBrain.py", line 208, in update
    if not self.wasNearMarker and self.isNearMarker():
  File "NeedBrain.py", line 245, in isNearMarker
    return self.markerDistance() < self.STAY_MIN_DIST
IndexError: tuple assignment index out of range

the related code:

    def markerDistance(self):
        m_obj = self.get("robot/fiducial/id")(self.marker)
        if not m_obj:
            return 1000.0
        dist = m_obj.range
        assert(type(dist), type(float))
        return dist

    def isNearMarker(self):
        return self.markerDistance() < self.STAY_MIN_DIST


Am Montag, 30. Mai 2005 11:55 schrieb Willi Richert:
> Hi,
>
> here is another strange error:
>
> Exception in thread Thread-2:
> Traceback (most recent call last):
>   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
>     self.run()
>   File "./brain/__init__.py", line 151, in run
> IndexError: tuple assignment index out of range
>
> Line 151 in brain/__init__.py is
>             self.couldBeMoving = 1
>
> wr
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
From dblank at brynmawr.edu  Tue May 31 09:26:10 2005
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Tue May 31 09:26:16 2005
Subject: [Pyro-developers] Maybe threading-related exceptions
In-Reply-To: <200505301421.01647.w.richert@gmx.net>
References: <200505301155.32250.w.richert@gmx.net>
	<200505301421.01647.w.richert@gmx.net>
Message-ID: <429C65F2.3020901@brynmawr.edu>

Willi,

Does your computer have more than one CPU? I have seen things like this 
before on a machine with multiple CPUs when running SMP Linux (but only 
with tkinter drawing).

-Doug

Willi Richert wrote:
> Hi,
> 
> here is another exception that has just occurred and is totally unreasonable to me:
> 
> NeedBrain.py:245: RuntimeWarning: tp_compare didn't return -1 or -2 for exception
>   return self.markerDistance() < self.STAY_MIN_DIST
> Exception in thread Thread-4:
> Traceback (most recent call last):
>   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
>     self.run()
>   File "./brain/__init__.py", line 148, in run
>   File "NeedBrain.py", line 415, in step
>     BehaviorBasedBrain.step(self)
>   File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", line 63, in step
>     self.states[s].run()
>   File "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", line 299, in run
>     self.update()
>   File "NeedBrain.py", line 208, in update
>     if not self.wasNearMarker and self.isNearMarker():
>   File "NeedBrain.py", line 245, in isNearMarker
>     return self.markerDistance() < self.STAY_MIN_DIST
> IndexError: tuple assignment index out of range
> 
> the related code:
> 
>     def markerDistance(self):
>         m_obj = self.get("robot/fiducial/id")(self.marker)
>         if not m_obj:
>             return 1000.0
>         dist = m_obj.range
>         assert(type(dist), type(float))
>         return dist
> 
>     def isNearMarker(self):
>         return self.markerDistance() < self.STAY_MIN_DIST
> 
> 
> Am Montag, 30. Mai 2005 11:55 schrieb Willi Richert:
> 
>>Hi,
>>
>>here is another strange error:
>>
>>Exception in thread Thread-2:
>>Traceback (most recent call last):
>>  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
>>    self.run()
>>  File "./brain/__init__.py", line 151, in run
>>IndexError: tuple assignment index out of range
>>
>>Line 151 in brain/__init__.py is
>>            self.couldBeMoving = 1
>>
>>wr
>>_______________________________________________
>>Pyro-developers mailing list
>>Pyro-developers@emergent.brynmawr.edu
>>http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 
> _______________________________________________
> Pyro-developers mailing list
> Pyro-developers@emergent.brynmawr.edu
> http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> 
> 


-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu
From richert at c-lab.de  Tue May 31 09:43:36 2005
From: richert at c-lab.de (Willi Richert)
Date: Tue May 31 09:58:57 2005
Subject: [Pyro-developers] Maybe threading-related exceptions
In-Reply-To: <429C65F2.3020901@brynmawr.edu>
References: <200505301155.32250.w.richert@gmx.net>
	<200505301421.01647.w.richert@gmx.net>
	<429C65F2.3020901@brynmawr.edu>
Message-ID: <200505311543.37526.richert@c-lab.de>

Am Dienstag, 31. Mai 2005 15:26 schrieb Douglas S. Blank:
> Willi,
>
> Does your computer have more than one CPU? I have seen things like this
> before on a machine with multiple CPUs when running SMP Linux (but only
> with tkinter drawing).

Nope. Now I have surrounded all "fragile" code blocks with try/except blocks 
and return standard values. Works for ~ 1000 seconds. Thereafter the agents 
start to do strange things. So I restart everything with the previously saved 
Q-Values (Reinforcement Learning).

BTW, I've also tried to encapsulate some code fragments with thread-locks, but 
this didn't seem to help.

wr

>
> -Doug
>
> Willi Richert wrote:
> > Hi,
> >
> > here is another exception that has just occurred and is totally
> > unreasonable to me:
> >
> > NeedBrain.py:245: RuntimeWarning: tp_compare didn't return -1 or -2 for
> > exception return self.markerDistance() < self.STAY_MIN_DIST
> > Exception in thread Thread-4:
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
> >     self.run()
> >   File "./brain/__init__.py", line 148, in run
> >   File "NeedBrain.py", line 415, in step
> >     BehaviorBasedBrain.step(self)
> >   File
> > "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py",
> > line 63, in step self.states[s].run()
> >   File
> > "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py",
> > line 299, in run self.update()
> >   File "NeedBrain.py", line 208, in update
> >     if not self.wasNearMarker and self.isNearMarker():
> >   File "NeedBrain.py", line 245, in isNearMarker
> >     return self.markerDistance() < self.STAY_MIN_DIST
> > IndexError: tuple assignment index out of range
> >
> > the related code:
> >
> >     def markerDistance(self):
> >         m_obj = self.get("robot/fiducial/id")(self.marker)
> >         if not m_obj:
> >             return 1000.0
> >         dist = m_obj.range
> >         assert(type(dist), type(float))
> >         return dist
> >
> >     def isNearMarker(self):
> >         return self.markerDistance() < self.STAY_MIN_DIST
> >
> > Am Montag, 30. Mai 2005 11:55 schrieb Willi Richert:
> >>Hi,
> >>
> >>here is another strange error:
> >>
> >>Exception in thread Thread-2:
> >>Traceback (most recent call last):
> >>  File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
> >>    self.run()
> >>  File "./brain/__init__.py", line 151, in run
> >>IndexError: tuple assignment index out of range
> >>
> >>Line 151 in brain/__init__.py is
> >>            self.couldBeMoving = 1
> >>
> >>wr
> >>_______________________________________________
> >>Pyro-developers mailing list
> >>Pyro-developers@emergent.brynmawr.edu
> >>http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers
> >
> > _______________________________________________
> > Pyro-developers mailing list
> > Pyro-developers@emergent.brynmawr.edu
> > http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers

-- 
Dipl.-Inform. Willi Richert
 C-LAB - Cooperative Computing & Communication Laboratory
 der Universit?t Paderborn und Siemens

FU.323
 F?rstenallee 11
 D-33102 Paderborn
 Tel: +49 52 51 60 - 61 20
 Fax: +49 52 51 60 - 60 65
 E-Mail: richert@c-lab.de
 Internet: http://www.c-lab.de