From dblank at brynmawr.edu Fri Jun 8 08:10:41 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri Jun 8 08:10:46 2007 Subject: [Pyro-users] Dual-Ported Recursive Auto-Associative Memory (RAAM) in Conx Message-ID: <1562.76.98.12.59.1181304641.squirrel@webmail.brynmawr.edu> [Not sure if this made it to the list. -Doug] ---------------------------- Original Message ---------------------------- From: "Alessandro Warth" Date: Thu, June 7, 2007 2:25 pm -------------------------------------------------------------------------- Hello, I saw an example in the Conx tutorial that implements Pollack's Recursive Auto-Associate Memory (http://pyrorobotics.org/?page=PyroRAAMExample), and now I would like to modify it to implement Lonnie Chrisman's Dual-Ported RAAM (http://citeseer.ist.psu.edu/chrisman91learning.html). A Dual-Ported RAAM is basically a network consisting of two RAAMs that _share_ the same hidden layer. They are useful for doing transformations on structured data. Here are a couple of questions: (1) Dual-Ported RAAMs are trained in three steps. First, you train one of the RAAMs to auto-associate on the input. Second, you train the other RAAM to auto-associate on the output. Finally, you train the whole network to associate the hidden-layer representation of the input with the output. Does anyone have any idea whether or not this kind of "partial" training (i.e., training parts of a network, which consists of specifying which units should be treated as inputs and outputs) is possible in Conx, and if so, could you please give me some pointers? (2) I read somewhere in the Conx documentation that the order in which you create layers must be the same order that you are planning on connecting things up. Does this make it impossible for Dual-Ported RAAMs to be implemented using Conx? Thanks in advance for your help! Cheers, Alex -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 From dblank at brynmawr.edu Fri Jun 8 08:31:30 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri Jun 8 08:31:33 2007 Subject: [Pyro-users] Dual-Ported Recursive Auto-Associative Memory (RAAM) in Conx In-Reply-To: <1562.76.98.12.59.1181304641.squirrel@webmail.brynmawr.edu> References: <1562.76.98.12.59.1181304641.squirrel@webmail.brynmawr.edu> Message-ID: <1588.76.98.12.59.1181305890.squirrel@webmail.brynmawr.edu> On Fri, June 8, 2007 8:10 am, Douglas S. Blank said: > [Not sure if this made it to the list. -Doug] > > ---------------------------- Original Message ---------------------------- > From: "Alessandro Warth" > Date: Thu, June 7, 2007 2:25 pm > -------------------------------------------------------------------------- > > Hello, > > I saw an example in the Conx tutorial that implements Pollack's > Recursive Auto-Associate Memory > (http://pyrorobotics.org/?page=PyroRAAMExample), and now I would like to > modify it to implement Lonnie Chrisman's Dual-Ported RAAM > (http://citeseer.ist.psu.edu/chrisman91learning.html). > > A Dual-Ported RAAM is basically a network consisting of two RAAMs that > _share_ the same hidden layer. They are useful for doing > transformations on structured data. > > Here are a couple of questions: > > (1) Dual-Ported RAAMs are trained in three steps. First, you train one of > the RAAMs to auto-associate on the input. Second, you train the other RAAM > to auto-associate on the output. Finally, you train the whole network to > associate the hidden-layer representation of the > input with the output. Does anyone have any idea whether or not this kind > of "partial" training (i.e., training parts of a network, which consists > of specifying which units should be treated as inputs and outputs) is > possible in Conx, and if so, could you please give me some pointers? > > (2) I read somewhere in the Conx documentation that the order in which you > create layers must be the same order that you are planning on > connecting things up. Does this make it impossible for Dual-Ported RAAMs > to be implemented using Conx? > > Thanks in advance for your help! > > Cheers, > Alex Alex, This is possible, as we have found the need to do things like this quite often. There are two possibilities: 1) Define a new class that overrides the Network.step() method. 2) Create two Networks that "share" weights. The first is fairly straightforward, but there are some interactions that you have to handle properly. There is an example in pyrobot/brain/governor.py. (Our governor doesn't really train on the input/output patterns that you give it, but balances the data so you don't train on any one pattern too much. There is a paper about the idea http://cs.brynmawr.edu/~dblank/, very last paper.) The second is a method that we came up with to make complicated multi-step training easier. It works like: net1 = Network() ... net2 = Network() ... net1.shareWeights(net2, [["hidden", "output"]]) where shareWeights takes the other network, and a list of pairs of layer names that define a connection of weights. The governor also has an example of two networks that share weights. Sharing can be very useful when you have SRN or an SRAAM (sequential RAAM) because you don't have to undo the context-copy. The order that you do connect will matter, but if you handle it through one of the above methods, it shouldn't be a problem. If you get stuck, email back to this list. Chances are also good that someone has tried Chrisman's experiment, too, and may have some code or ideas. -Doug From alexwarth at gmail.com Fri Jun 8 13:36:29 2007 From: alexwarth at gmail.com (Alessandro Warth) Date: Fri Jun 8 13:36:34 2007 Subject: [Pyro-users] Dual-Ported Recursive Auto-Associative Memory (RAAM) in Conx In-Reply-To: <1588.76.98.12.59.1181305890.squirrel@webmail.brynmawr.edu> References: <1562.76.98.12.59.1181304641.squirrel@webmail.brynmawr.edu> <1588.76.98.12.59.1181305890.squirrel@webmail.brynmawr.edu> Message-ID: Hi Doug, Thanks so much for your reply. I'm going to try this out over the weekend, and will let you know if I run into any problems. Thanks again, Alex On 6/8/07, Douglas S. Blank wrote: > > On Fri, June 8, 2007 8:10 am, Douglas S. Blank said: > > [Not sure if this made it to the list. -Doug] > > > > ---------------------------- Original Message ---------------------------- > > From: "Alessandro Warth" > > Date: Thu, June 7, 2007 2:25 pm > > -------------------------------------------------------------------------- > > > > Hello, > > > > I saw an example in the Conx tutorial that implements Pollack's > > Recursive Auto-Associate Memory > > (http://pyrorobotics.org/?page=PyroRAAMExample), and now I would like to > > modify it to implement Lonnie Chrisman's Dual-Ported RAAM > > (http://citeseer.ist.psu.edu/chrisman91learning.html). > > > > A Dual-Ported RAAM is basically a network consisting of two RAAMs that > > _share_ the same hidden layer. They are useful for doing > > transformations on structured data. > > > > Here are a couple of questions: > > > > (1) Dual-Ported RAAMs are trained in three steps. First, you train one of > > the RAAMs to auto-associate on the input. Second, you train the other RAAM > > to auto-associate on the output. Finally, you train the whole network to > > associate the hidden-layer representation of the > > input with the output. Does anyone have any idea whether or not this kind > > of "partial" training (i.e., training parts of a network, which consists > > of specifying which units should be treated as inputs and outputs) is > > possible in Conx, and if so, could you please give me some pointers? > > > > (2) I read somewhere in the Conx documentation that the order in which you > > create layers must be the same order that you are planning on > > connecting things up. Does this make it impossible for Dual-Ported RAAMs > > to be implemented using Conx? > > > > Thanks in advance for your help! > > > > Cheers, > > Alex > > Alex, > > This is possible, as we have found the need to do things like this quite > often. There are two possibilities: > > 1) Define a new class that overrides the Network.step() method. > > 2) Create two Networks that "share" weights. > > The first is fairly straightforward, but there are some interactions that > you have to handle properly. There is an example in > pyrobot/brain/governor.py. (Our governor doesn't really train on the > input/output patterns that you give it, but balances the data so you don't > train on any one pattern too much. There is a paper about the idea > http://cs.brynmawr.edu/~dblank/, very last paper.) > > The second is a method that we came up with to make complicated multi-step > training easier. It works like: > > net1 = Network() > ... > net2 = Network() > ... > net1.shareWeights(net2, [["hidden", "output"]]) > > where shareWeights takes the other network, and a list of pairs of layer > names that define a connection of weights. The governor also has an > example of two networks that share weights. Sharing can be very useful > when you have SRN or an SRAAM (sequential RAAM) because you don't have to > undo the context-copy. > > The order that you do connect will matter, but if you handle it through > one of the above methods, it shouldn't be a problem. > > If you get stuck, email back to this list. Chances are also good that > someone has tried Chrisman's experiment, too, and may have some code or > ideas. > > -Doug > > > > _______________________________________________ > Pyro-users mailing list > Pyro-users@pyrorobotics.org > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > From dblank at brynmawr.edu Mon Jun 11 15:36:34 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Mon Jun 11 15:36:40 2007 Subject: [Pyro-users] Re: Pyro bug? In-Reply-To: References: Message-ID: <466DA442.9000302@brynmawr.edu> Grant (and Pyro-users), Thanks for the bug report! You were right, and in fact there were a few issues with that little bit of code. I've updated CVS to include the following in pyrobot/robot/device.py: elif type(item) == types.SliceType: if item.step: step = item.step else: step = 1 if item.start == None: if step > 0: start = 0 else: start = len(self) - 1 else: start = item.start if item.stop == None: if step > 0: stop = len(self) else: stop = -1 elif item.stop > len(self): stop = len(self) else: stop = item.stop if start < 0 and step > 0: start = len(self) + start if stop < 0 and step > 0: stop = len(self) + stop return [self.getSensorValue(p) for p in xrange(start, stop, step)] This allows it to act much more similarly to Python's slice behavior, including: self.robot.sonar[0][:] self.robot.sonar[0][:-1] self.robot.sonar[0][-3:-1] self.robot.sonar[0][::2] Let me know if you see anything wrong with this. Thanks again! -Doug Grant Braught wrote: > Hi Doug, > > We've been working on a summer research project here using Pyro and seem > to have come across a bug. There is an easy work-around so it's not too > big a deal but I thought I'd let you know. It seems that when using > list slices to access a range of sensor values, the value of the sensor > with the maximum index is never included. Here's some sample code that > illustrates the bug: > > === > > from pyrobot.brain import Brain > > class BugBrain(Brain): > > def step(self): > > rrangea = [s.value for s in self.robot.sonar[0]['all']] > rrangeb = [s.value for s in self.robot.sonar[0][0:16]] > > print len(rrangea) # prints 16 > print rrangea # prints all 16 sonar values. > print > print len(rrangeb) # prints 15 > print rrangeb # prints all but the last sonar value. > print > print > > # Create the brain and return it to the Pyrobot program. > def INIT(engine): > return BugBrain('BB', engine) > > === > > It looks like this is caused by some code in the __getItem__ method in > the Device class. > > elif type(item) == types.SliceType: > if item.stop >= len(self): stop = len(self) - 1 > else: stop = item.stop > step = 1 > if item.step: > step = item.step > return [self.getSensorValue(p) for p in xrange(item.start, > stop, step)] > > This seems to cut off the last element when a slice is being used to > access the sensor values. > > === > > Since the range names work we can just use those with no problem. We > actually discovered this using the bumpers where we wanted to get the > rear bumpers ([s.value for s in self.robot.bumpers[0][5:10]) and then > check each one to see if it was triggered. That list turned out to only > have 4 elements in it, causing out of bounds errors when we checked the > [4]th index. > > === > > Thanks again for all your hard work in putting the Pyro stuff together > and maintaining it! It is a great tool! > > Grant > From galk at cs.biu.ac.il Thu Jun 14 03:34:06 2007 From: galk at cs.biu.ac.il (Gal Kaminka) Date: Thu Jun 14 08:13:06 2007 Subject: [Pyro-users] CFP Special Issue on Multi-Robot Coverage, Search, and Exploration (Reminder) In-Reply-To: <200703230928.43127.galk@cs.biu.ac.il> References: <001d01c756bb$b6673a40$0401a8c0@amirshapiro> <200703230928.43127.galk@cs.biu.ac.il> Message-ID: <200706141034.07840.galk@cs.biu.ac.il> (Our apologies if you receive multiple copies of this message.) Please distribute to colleagues and interest parties as appropriate Dear Colleague, This is a reminder of the call for papers, for a special issue of the Annals of Math and Artificial Intelligence journal (AMAI) on Multi-Robot Coverage, Search, and Exploration. (http://www.cs.biu.ac.il/~galk/amai-special/) Please see below for details. The deadline is August 15, 2007. ----------------------------------------------------------------------- Research in multi robot area coverage, search, and exploration has been receiving consistent attention in recent years, due to the increasing number of real-world applications, such as vacuuming, lawn mowing, de-mining, surveillance, search and rescue operations, mapping, planetary exploration, etc. All of these applications require that the area of interest be covered by the robots sensors or end-effectors for various purposes. The use of multiple robots potentially provides redundancy and offers opportunities for increasing efficiency. The problem of multi robot area coverage imposes great challenges to researchers in robotics and AI area. This special issue will explore the new research frontiers that emerge as new applications are identified and new technologies in robots are introduced. The special issue follows in the footsteps of the highly successful 2001 AMAI special issue on coverage. We seek high-quality papers reporting on innovative work on coverage, search, and exploration and related areas of research. Our focus is on algorithmic and analytical approaches. Heuristic approaches should be supported by analysis and empirical evidence. Submissions extending previously published conference papers are acceptable, as long as the extensions are clearly explained. The following potential topics are of interest: o Complete-coverage path planning for a group of robots in known and unknown environments o Multiple robot coordination in area coverage, exploration, and/or search o Issues in trade-off of tasks between teams members; how team members decide who performs which task o Fault-tolerance and robustness in multi robot area coverage o Performance metrics for coverage, exploration, and search o The use of heterogeneous teams (combining different vehicles, end-effectors, and sensors) o Novel applications of coverage, exploration, and search o The effect of the task complexity and of the environment on the design of the cooperative capabilities of multi-robot systems o Communications aspects between the robots during multi robot area coverage o Repeated coverage and patrolling o On-line search for a path, navigation Important Dates --------------- August 15, 2007: Deadline for Paper Submission November 15, 2007: Notification Submission of papers -------------------- Electronic submissions in PDF, postscript, or zipped postscript form are strongly encouraged, and will expedite the review and publication process. Please email the submission to the guest editors (addresses below). The submission message should use the subject "AMAI Submission" All manuscripts should include a title page containing the title of the paper, full names and affiliations, complete postal and electronic addresses, phone and fax numbers, an abstract, and keywords. The contacting author should be clearly identified. Please use latex article class with default values (12pt font, single column, single-line spacing). Guest Editors ------------- Dr. Gal A. Kaminka Computer Science Department Bar Ilan University Ramat Gan 52900, Israel Phone: +972 3 531 7607 Fax: +972 3 736 0498 Email: galk@cs.biu.ac.il Dr. Amir Shapiro Department of Mechanical Engineering Ben Gurion University of the Negev P.O.Box 653 Beer Sheva 84105, Israel Phone: +972 8 647 7165 Fax: +972 8 647 2813 Email: ashapiro@bgu.ac.il -- ----------------------------------------------------------------------- Gal A. Kaminka, Ph.D. http://www.cs.biu.ac.il/~galk Assistant Professor Computer Science Dept. Bar Ilan University Only those who see the invisible can do the impossible "Death is an engineering problem." -- Bart Kosko, "Fuzzy Thinking" "But life is not an engineering task." -- Gal A. Kaminka From angel at chrematisai.com Wed Jun 27 21:41:14 2007 From: angel at chrematisai.com (Angelina Fabbro) Date: Thu Jun 28 14:58:59 2007 Subject: [Pyro-users] Hi there! New Pyro user.. Message-ID: <85b9d2d50706271841l20f71042u6d64060d4e12c789@mail.gmail.com> Hi there! I'm a new user to Pyro and have had no problems plugging away using the live boot disc. I have tried to install on one of my Windows boxes and get as far as loading a robot after I've loaded a stage. For pretty much every robot, I obtain: Attempting to import 'Player6665'... Exception in Tkinter callback Traceback (most recent call last): File "C:\Python24\lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "C:\Python24\libs\pyrobot\gui\TK.py", line 202, in loadRobot gui.loadRobot(self) File "C:\Python24\libs\pyrobot\gui\__init__.py", line 518, in loadRobot self.engine.loadRobot(f) File "C:\Python24\libs\pyrobot\engine\__init__.py", line 174, in loadRobot self.robot = system.loadINIT(file) File "C:\Python24\libs\pyrobot\system\__init__.py", line 86, in loadINIT exec("import " + module + " as userspace") File "", line 1, in ? File "C:\Python24\libs\pyrobot\plugins\robots\Player6665.py", line 1, in ? from pyrobot.robot.player import PlayerRobot File "C:\Python24\libs\pyrobot\robot\player.py", line 13, in ? from os import getuid ImportError: cannot import name getuid As I'm fairly new to programming in Python, and fairly new to Pyro - could someone point out to me what obvious thing I'm missing here? Thanks! ~Angelina Fabbro -- -- President; Computing Science Student Society at Simon Fraser University Member of Association for Advancement of Artificial Intelligence in good standing From dblank at brynmawr.edu Thu Jun 28 15:39:52 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Jun 28 15:40:20 2007 Subject: [Pyro-users] Hi there! New Pyro user.. In-Reply-To: <85b9d2d50706271841l20f71042u6d64060d4e12c789@mail.gmail.com> References: <85b9d2d50706271841l20f71042u6d64060d4e12c789@mail.gmail.com> Message-ID: <4061.216.99.114.114.1183059592.squirrel@webmail.brynmawr.edu> Angelina, Try starting the PyrobotSimulator and use PyrobotRobot60000 under Windows. The other simulator requires some work to get running under Windows. Do you know about our on-line documentation? http://pyrorobotics.org/?page=PyroCurriculum especially near the bottom. -Doug On Wed, June 27, 2007 9:41 pm, Angelina Fabbro said: > Hi there! I'm a new user to Pyro and have had no problems plugging > away using the live boot disc. I have tried to install on one of my > Windows boxes and get as far as loading a robot after I've loaded a > stage. For pretty much every robot, I obtain: > > Attempting to import 'Player6665'... > Exception in Tkinter callback > Traceback (most recent call last): > File "C:\Python24\lib\lib-tk\Tkinter.py", line 1345, in __call__ > return self.func(*args) > File "C:\Python24\libs\pyrobot\gui\TK.py", line 202, in loadRobot > gui.loadRobot(self) > File "C:\Python24\libs\pyrobot\gui\__init__.py", line 518, in loadRobot > self.engine.loadRobot(f) > File "C:\Python24\libs\pyrobot\engine\__init__.py", line 174, in > loadRobot > self.robot = system.loadINIT(file) > File "C:\Python24\libs\pyrobot\system\__init__.py", line 86, in loadINIT > exec("import " + module + " as userspace") > File "", line 1, in ? > File "C:\Python24\libs\pyrobot\plugins\robots\Player6665.py", line 1, in > ? > from pyrobot.robot.player import PlayerRobot > File "C:\Python24\libs\pyrobot\robot\player.py", line 13, in ? > from os import getuid > ImportError: cannot import name getuid > > > As I'm fairly new to programming in Python, and fairly new to Pyro - > could someone point out to me what obvious thing I'm missing here? > > Thanks! > > ~Angelina Fabbro > > -- > -- > President; Computing Science Student Society at Simon Fraser University > Member of Association for Advancement of Artificial Intelligence in > good standing > _______________________________________________ > Pyro-users mailing list > Pyro-users@pyrorobotics.org > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 From angel at chrematisai.com Thu Jun 28 15:54:15 2007 From: angel at chrematisai.com (Angelina Fabbro) Date: Thu Jun 28 15:54:46 2007 Subject: [Pyro-users] Hi there! New Pyro user.. In-Reply-To: <4061.216.99.114.114.1183059592.squirrel@webmail.brynmawr.edu> References: <85b9d2d50706271841l20f71042u6d64060d4e12c789@mail.gmail.com> <4061.216.99.114.114.1183059592.squirrel@webmail.brynmawr.edu> Message-ID: <85b9d2d50706281254i7287088ci97f473d7768067ec@mail.gmail.com> Thank you very much - I will give that a try. I'm actually following along the curriculum some more after I write this. :) On 6/28/07, Douglas S. Blank wrote: > Angelina, > > Try starting the PyrobotSimulator and use PyrobotRobot60000 under Windows. > The other simulator requires some work to get running under Windows. > > Do you know about our on-line documentation? > > http://pyrorobotics.org/?page=PyroCurriculum > > especially near the bottom. > > -Doug > > On Wed, June 27, 2007 9:41 pm, Angelina Fabbro said: > > Hi there! I'm a new user to Pyro and have had no problems plugging > > away using the live boot disc. I have tried to install on one of my > > Windows boxes and get as far as loading a robot after I've loaded a > > stage. For pretty much every robot, I obtain: > > > > Attempting to import 'Player6665'... > > Exception in Tkinter callback > > Traceback (most recent call last): > > File "C:\Python24\lib\lib-tk\Tkinter.py", line 1345, in __call__ > > return self.func(*args) > > File "C:\Python24\libs\pyrobot\gui\TK.py", line 202, in loadRobot > > gui.loadRobot(self) > > File "C:\Python24\libs\pyrobot\gui\__init__.py", line 518, in loadRobot > > self.engine.loadRobot(f) > > File "C:\Python24\libs\pyrobot\engine\__init__.py", line 174, in > > loadRobot > > self.robot = system.loadINIT(file) > > File "C:\Python24\libs\pyrobot\system\__init__.py", line 86, in loadINIT > > exec("import " + module + " as userspace") > > File "", line 1, in ? > > File "C:\Python24\libs\pyrobot\plugins\robots\Player6665.py", line 1, in > > ? > > from pyrobot.robot.player import PlayerRobot > > File "C:\Python24\libs\pyrobot\robot\player.py", line 13, in ? > > from os import getuid > > ImportError: cannot import name getuid > > > > > > As I'm fairly new to programming in Python, and fairly new to Pyro - > > could someone point out to me what obvious thing I'm missing here? > > > > Thanks! > > > > ~Angelina Fabbro > > > > -- > > -- > > President; Computing Science Student Society at Simon Fraser University > > Member of Association for Advancement of Artificial Intelligence in > > good standing > > _______________________________________________ > > Pyro-users mailing list > > Pyro-users@pyrorobotics.org > > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > > > > -- > Douglas S. Blank > Associate Professor, Bryn Mawr College > http://cs.brynmawr.edu/~dblank/ > Office: 610 526 6501 > > -- -- President; Computing Science Student Society at SFU Member of Association for Advancement of Artificial Intelligence in good standing