From gsakkis at rutgers.edu Tue Feb 1 11:10:48 2005 From: gsakkis at rutgers.edu (George Sakkis) Date: Tue Feb 1 11:06:55 2005 Subject: [Pyro-users] Installation on cygwin Message-ID: <013201c50878$9a6b05d0$ad03a8c0@charisteas> Greetings everyone, I just downloaded Pyro and I'm looking forward to start using it, and potentially contributing to it as part of my master's thesis. So far I have failed to install it out-of-the-box just by following the instructions on http://emergent.brynmawr.edu/pyro/?page=PyroInstallation; I guess the main reason is that I'm trying to build it on cygwin but apparently the makefiles are intended for Linux (or maybe just RedHat). Next thing I tried was the standard distutils 'python setup.py build' but the current setup.py is obviously outdated; for one thing, a bunch of directories mentioned there do not exist in the latest tarball. I'm wondering if anyone has a setup.py that works for the current version (3.4.3) before I start fiddling with it myself. George From dblank at brynmawr.edu Wed Feb 2 11:46:18 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Wed Feb 2 11:42:31 2005 Subject: [Pyro-users] Re: [Pyro-developers] Installation on cygwin In-Reply-To: <013201c50878$9a6b05d0$ad03a8c0@charisteas> References: <013201c50878$9a6b05d0$ad03a8c0@charisteas> Message-ID: <420103DA.1030109@brynmawr.edu> George, Welcome aboard! First, Pyro has run under Windows (natively) with some minor changes. But those changes haven't been incorporated into the main version yet. (Little things like paths need to be made cross-platform). The only reason you would want to go as far as running it under cygwin would be to try to get all of the functionality of the the third-party simulators and tools (such as Player/Stage, and Khepera simulator). But that is unlikely to be very satisfying, and would work much better under Linux. You can run the main Pyro Python code under Windows to connect onto robots, such as the Aibo, or Player running on a Pioneer3, for example. But you may not have a real robot. The ideal solution would be to have a cross-platform simulator which you could connect Pyro onto. The Robocup simulator should work. There are also some pure-Python symbolic simulators that come with Pyro for playing games like chess, checkers, etc. Those should work under Windows, I think, but I haven't tried them yet. Some parts (like the vision subsystem) are written in C++ and rely on shared memory. I have no idea if that will work under Windows. In general, a Mac OS X port should work better and more easily. Finally, the setup.py is just a stub that someone contributed to help us get that method of installation working. So, the makefile is the only method that I know that works currently. In short, if you don't have a robot, running Pyro under Linux or Mac OS X will be a lot more fun and productive. But you will be able to do somethings under Windows. Let us know if you have any questions, and we welcome contributions! -Doug George Sakkis wrote: > Greetings everyone, > > I just downloaded Pyro and I'm looking forward to start using it, and potentially contributing to it > as part of my master's thesis. So far I have failed to install it out-of-the-box just by following > the instructions on http://emergent.brynmawr.edu/pyro/?page=PyroInstallation; I guess the main > reason is that I'm trying to build it on cygwin but apparently the makefiles are intended for Linux > (or maybe just RedHat). Next thing I tried was the standard distutils 'python setup.py build' but > the current setup.py is obviously outdated; for one thing, a bunch of directories mentioned there do > not exist in the latest tarball. I'm wondering if anyone has a setup.py that works for the current > version (3.4.3) before I start fiddling with it myself. > > George > > _______________________________________________ > 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 gsakkis at rutgers.edu Wed Feb 2 18:30:47 2005 From: gsakkis at rutgers.edu (George Sakkis) Date: Wed Feb 2 18:26:42 2005 Subject: [Pyro-users] Re: [Pyro-developers] Installation on cygwin References: <013201c50878$9a6b05d0$ad03a8c0@charisteas> <420103DA.1030109@brynmawr.edu> Message-ID: <001e01c5097f$3aaf49f0$e302a8c0@charisteas> Doug, thanks for the reply. I'm using cygwin as a compromise between developing on a *nix environment and having XP for OS (I'm still hesitant to make the full shift to Linux; also a dual boot system seems more trouble than it's worth it). In any case, I believe that distutils is the way to go in the long run anyway, so I've already started tweaking setup.py and fixing the problems I come across (e.g. name clashes between some C functions under pyro and Cygwin functions/macros). If I get to build it on my system and on a linux box without makefiles, I can make available the patches. George > George, > > Welcome aboard! > > First, Pyro has run under Windows (natively) with some minor changes. > But those changes haven't been incorporated into the main version yet. > (Little things like paths need to be made cross-platform). > > The only reason you would want to go as far as running it under cygwin > would be to try to get all of the functionality of the the third-party > simulators and tools (such as Player/Stage, and Khepera simulator). But > that is unlikely to be very satisfying, and would work much better under > Linux. > > You can run the main Pyro Python code under Windows to connect onto > robots, such as the Aibo, or Player running on a Pioneer3, for example. > But you may not have a real robot. > > The ideal solution would be to have a cross-platform simulator which you > could connect Pyro onto. The Robocup simulator should work. There are > also some pure-Python symbolic simulators that come with Pyro for > playing games like chess, checkers, etc. Those should work under > Windows, I think, but I haven't tried them yet. > > Some parts (like the vision subsystem) are written in C++ and rely on > shared memory. I have no idea if that will work under Windows. > > In general, a Mac OS X port should work better and more easily. > > Finally, the setup.py is just a stub that someone contributed to help us > get that method of installation working. So, the makefile is the only > method that I know that works currently. > > In short, if you don't have a robot, running Pyro under Linux or Mac OS > X will be a lot more fun and productive. But you will be able to do > somethings under Windows. > > Let us know if you have any questions, and we welcome contributions! > > -Doug > > George Sakkis wrote: > > Greetings everyone, > > > > I just downloaded Pyro and I'm looking forward to start using it, and potentially contributing to it > > as part of my master's thesis. So far I have failed to install it out-of-the-box just by following > > the instructions on http://emergent.brynmawr.edu/pyro/?page=PyroInstallation; I guess the main > > reason is that I'm trying to build it on cygwin but apparently the makefiles are intended for Linux > > (or maybe just RedHat). Next thing I tried was the standard distutils 'python setup.py build' but > > the current setup.py is obviously outdated; for one thing, a bunch of directories mentioned there do > > not exist in the latest tarball. I'm wondering if anyone has a setup.py that works for the current > > version (3.4.3) before I start fiddling with it myself. > > > > George > > > > _______________________________________________ > > 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 stefan at sels.com Sat Feb 5 10:01:48 2005 From: stefan at sels.com (Stefan Sels) Date: Sat Feb 5 09:57:42 2005 Subject: [Pyro-users] Re: Pyro for Aibo In-Reply-To: <4198F6C4.7040401@cs.brynmawr.edu> References: Message-ID: <20050205150148.GA27306@sels.com> Hallo, i think about installing pyro on my Aibo ERS-7 : >Required hardware: > > * Aibo ERS-7 (which comes with wireless) > * Wireless access point > * Pink Memstick (64MB will do) I only got an 32 MB memory stick (with my mind2 software) and I only found 16 MB sticks to buy at Sony. Do I really need 64 MB ? Do 64 MB Sticks exist? ( Open-R FAQ says that there are only 16 MB) or can you modify an regular memory stick to contain open-r ? Any hints for buying such sticks (in Europe?) would be great... Regards, Stefan From dblank at brynmawr.edu Sat Feb 5 10:12:21 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Sat Feb 5 10:08:14 2005 Subject: [Pyro-users] Re: Pyro for Aibo In-Reply-To: <20050205150148.GA27306@sels.com> References: <20050205150148.GA27306@sels.com> Message-ID: <4204E255.2050903@brynmawr.edu> Stefan, That's an error. 16mb should do, and I think that you don't need the pink ones, but I haven't tried the non-pink ones yet. We have made some progress in the last week in getting Pyro working with the Aibo. Note that you don't put Pyro *on* the Aibo, but run Pyro on a PC and TekkotsuMon on the Aibo. Also, it looks like we will have some patches for the Tekkotsu folks, so if anyone wants to try the Aibo + Pyro interface out, post a note here, and I'll have make some up-to-date documents on the Pyro wiki. -Doug Stefan Sels wrote: > Hallo, > > i think about installing pyro on my Aibo ERS-7 : > > >>Required hardware: >> >> * Aibo ERS-7 (which comes with wireless) >> * Wireless access point >> * Pink Memstick (64MB will do) > > > I only got an 32 MB memory stick (with my mind2 software) and I only found 16 MB sticks to buy at Sony. > Do I really need 64 MB ? > Do 64 MB Sticks exist? ( Open-R FAQ says that there are only 16 MB) > or can you modify an regular memory stick to contain open-r ? > > Any hints for buying such sticks (in Europe?) would be great... > > Regards, > Stefan > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > -- 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 stefan at sels.com Sat Feb 5 10:49:50 2005 From: stefan at sels.com (Stefan Sels) Date: Sat Feb 5 10:45:42 2005 Subject: [Pyro-users] Re: Pyro for Aibo In-Reply-To: <4204E255.2050903@brynmawr.edu> References: <20050205150148.GA27306@sels.com> <4204E255.2050903@brynmawr.edu> Message-ID: <20050205154949.GC27306@sels.com> On Sat, Feb 05, 2005 at 10:12:21AM -0500, Douglas S. Blank wrote: > Stefan, Hi Douglas, > That's an error. 16mb should do, and I think that you don't need the > pink ones, but I haven't tried the non-pink ones yet. I ordered a pink one from Sony. I will try to use a "normal" one as well if I got it (shipping next week). > We have made some progress in the last week in getting Pyro working with > the Aibo. Note that you don't put Pyro *on* the Aibo, but run Pyro on a > PC and TekkotsuMon on the Aibo. Ok. I thought Pyro would be installed on the stick as well. I had a look on the Tekkotsu Homepage. Is there a special reason why version 2.1 is required? > Also, it looks like we will have some patches for the Tekkotsu folks, so > if anyone wants to try the Aibo + Pyro interface out, post a note here, > and I'll have make some up-to-date documents on the Pyro wiki. I would like to. > -Doug Regards, Stefan From gsakkis at rutgers.edu Sat Feb 5 17:32:33 2005 From: gsakkis at rutgers.edu (George Sakkis) Date: Sat Feb 5 17:28:12 2005 Subject: [Pyro-users] Re: Pyro for Aibo References: <20050205150148.GA27306@sels.com> <4204E255.2050903@brynmawr.edu> <20050205154949.GC27306@sels.com> Message-ID: <005e01c50bd2$96328c60$ad03a8c0@charisteas> I plan to work on ERS-7 too; a short guide/tutorial on how to put Open-R, Tekkotsu and Pyro together would definitely be helpful. Best, George > > Also, it looks like we will have some patches for the Tekkotsu folks, so > > if anyone wants to try the Aibo + Pyro interface out, post a note here, > > and I'll have make some up-to-date documents on the Pyro wiki. > > I would like to. > > > -Doug > > Regards, > Stefan From galk at cs.biu.ac.il Sun Feb 6 00:50:48 2005 From: galk at cs.biu.ac.il (Gal Kaminka) Date: Sun Feb 6 00:49:26 2005 Subject: [Pyro-users] Re: Pyro for Aibo In-Reply-To: <4204E255.2050903@brynmawr.edu> References: <20050205150148.GA27306@sels.com> <20 050205150148.GA27306@sels.com> Message-ID: <5.1.0.14.2.20050206074807.036f2010@mailhost.cs.biu.ac.il> Doug, We regularly use AIBOs in the lab for research, as well as other robots. We've been lurking on the pyro mailing list. May I ask why you use the TekkotsuMon object on the Tekkotsu rather than a specialized (smaller) object that will simply pass-through the results of vision and sensor processing to pyro? Gal At 10:12 AM 2/5/2005 -0500, Douglas S. Blank wrote: >Stefan, > >That's an error. 16mb should do, and I think that you don't need the pink >ones, but I haven't tried the non-pink ones yet. > >We have made some progress in the last week in getting Pyro working with >the Aibo. Note that you don't put Pyro *on* the Aibo, but run Pyro on a PC >and TekkotsuMon on the Aibo. > >Also, it looks like we will have some patches for the Tekkotsu folks, so >if anyone wants to try the Aibo + Pyro interface out, post a note here, >and I'll have make some up-to-date documents on the Pyro wiki. > >-Doug > >Stefan Sels wrote: >>Hallo, >>i think about installing pyro on my Aibo ERS-7 : >> >>>Required hardware: >>> >>> * Aibo ERS-7 (which comes with wireless) >>> * Wireless access point >>> * Pink Memstick (64MB will do) >> >>I only got an 32 MB memory stick (with my mind2 software) and I only >>found 16 MB sticks to buy at Sony. >>Do I really need 64 MB ? >>Do 64 MB Sticks exist? ( Open-R FAQ says that there are only 16 MB) >>or can you modify an regular memory stick to contain open-r ? >>Any hints for buying such sticks (in Europe?) would be great... >>Regards, >> Stefan >>_______________________________________________ >>Pyro-users mailing list >>Pyro-users@emergent.brynmawr.edu >>http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > >-- >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 >_______________________________________________ >Pyro-users mailing list >Pyro-users@emergent.brynmawr.edu >http://emergent.brynmawr.edu/mailman/listinfo/pyro-users From dblank at brynmawr.edu Sun Feb 6 11:49:52 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Sun Feb 6 11:49:14 2005 Subject: [Pyro-users] Re: Pyro for Aibo In-Reply-To: <5.1.0.14.2.20050206074807.036f2010@mailhost.cs.biu.ac.il> References: <20050205150148.GA27306@sels.com> <20 050205150148.GA27306@sels.com> <5.1.0.14.2.20050206074807.036f2010@mailhost.cs.biu.ac.il> Message-ID: <42064AB0.9030404@brynmawr.edu> Gal, Do you have suggestions for something else to use instead of TekkotsuMon? We were using it because it seemed to do most of what we were looking for, and it was being actively maintained. But if there are other options we would like to know about them. We didn't really consider writing our own because we hadn't developed code on the Aibo before, and we weren't sure we wanted to take on more code to maintain. (On the other hand, the AIBO seems like a wonderful platform and I think we are moving to support it for the forseeable future.) Thanks for any leads, -Doug Gal Kaminka wrote: > Doug, > > We regularly use AIBOs in the lab for research, as well as other robots. > We've been lurking on the pyro mailing list. > > May I ask why you use the TekkotsuMon object on the Tekkotsu rather than > a specialized (smaller) object that will simply pass-through the results of > vision and sensor processing to pyro? > > Gal > > > At 10:12 AM 2/5/2005 -0500, Douglas S. Blank wrote: > >> Stefan, >> >> That's an error. 16mb should do, and I think that you don't need the >> pink ones, but I haven't tried the non-pink ones yet. >> >> We have made some progress in the last week in getting Pyro working >> with the Aibo. Note that you don't put Pyro *on* the Aibo, but run >> Pyro on a PC and TekkotsuMon on the Aibo. >> >> Also, it looks like we will have some patches for the Tekkotsu folks, >> so if anyone wants to try the Aibo + Pyro interface out, post a note >> here, and I'll have make some up-to-date documents on the Pyro wiki. >> >> -Doug >> >> Stefan Sels wrote: >> >>> Hallo, >>> i think about installing pyro on my Aibo ERS-7 : >>> >>>> Required hardware: >>>> >>>> * Aibo ERS-7 (which comes with wireless) >>>> * Wireless access point >>>> * Pink Memstick (64MB will do) >>> >>> >>> I only got an 32 MB memory stick (with my mind2 software) and I only >>> found 16 MB sticks to buy at Sony. >>> Do I really need 64 MB ? >>> Do 64 MB Sticks exist? ( Open-R FAQ says that there are only 16 MB) >>> or can you modify an regular memory stick to contain open-r ? >>> Any hints for buying such sticks (in Europe?) would be great... >>> Regards, >>> Stefan >>> _______________________________________________ >>> Pyro-users mailing list >>> Pyro-users@emergent.brynmawr.edu >>> http://emergent.brynmawr.edu/mailman/listinfo/pyro-users >> >> >> >> -- >> 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 >> _______________________________________________ >> Pyro-users mailing list >> Pyro-users@emergent.brynmawr.edu >> http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > > -- 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 ronin at udc.es Mon Feb 7 13:30:50 2005 From: ronin at udc.es (=?iso-8859-1?q?Jos=E9_Antonio_Becerra_Permuy?=) Date: Mon Feb 7 13:26:23 2005 Subject: [Pyro-users] Problem with SOM module Message-ID: <200502071930.51106.ronin@udc.es> Hi! I just started to play with Pyro. I followed the instructions in "SOM: Step-by-Step Example" and I found a problem at the beginning: Pyro Version 3.5.0: Ready... >>> from pyro.brain import psom Ok >>> from pyro.brain.psom import vis Ok >>> mysom = vis.VisPsom(3, 4, dim=5) Exception exceptions.AttributeError: "VisPsom instance has no attribute 'params'" in > ignored ERROR: exceptions.TypeError unsubscriptable object exceptions.TypeError: unsubscriptable object in command line Exception exceptions.AttributeError: "VisPsom instance has no attribute 'params'" in > ignored Python is 2.4. Is the SOM module working in this version? Regards. From bob.roos at gmail.com Tue Feb 8 09:21:27 2005 From: bob.roos at gmail.com (Bob Roos) Date: Tue Feb 8 09:17:16 2005 Subject: [Pyro-users] Question about Hemisson Message-ID: I just learned that between now and Feb 15 I have an opportunity to apply for approx. $2000 in support from my school. We have no robotics facilities at all here. For this amount of money I can't really consider things much more expensive than Hemissons or Mindstorms, and the Pyro connection is a strong motivation for going with Hemisson. We use Linux. >From the Hemisson page (at http://www.cyberbotics.com/products/robots/hemisson.html) I see that there are two versions, standard and deluxe. Given that we are starting from scratch, I'm tempted by the deluxe (plus that apparently is the only one configured to work with Linux), but of course it's twice as expensive. All my robotics experinence has been via Pyro simulation (and a little bit of Lego Mindstorms tinkering). I'm not looking to outfit an entire lab here, just looking for enough robots to be able to do some student research projects and special topics at this point; more equipment would presumably be requested in a grant proposal somewhere down the road. Comments or suggestions? (E.g., is it possible to start from scratch with the "standard" Hemissons, or is it a good buy to get the deluxe, which has BotStudio software, 2-yr warranty, etc., for the extra money?) My current idea (I'm still looking at other options) is to apply for funds for three Hemisson deluxe (although I haven't yet looked into educational discounts -- how much have others of you paid for Hemissons?). Your comments are much appreciated! Bob Roos Allegheny College From dblank at brynmawr.edu Tue Feb 8 09:56:17 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Tue Feb 8 09:51:59 2005 Subject: [Pyro-users] Problem with SOM module In-Reply-To: <200502071930.51106.ronin@udc.es> References: <200502071930.51106.ronin@udc.es> Message-ID: <4208D311.5080901@brynmawr.edu> Jos?, Your code snippet worked for me. I suspect that something didn't build correctly. What version of SWIG are you using? I might be too old, or maybe it is too new and they have changed something. There is a SWIG 1.3.17 at http://emergent.brynmawr.edu/~dblank/pyro/tars/ Also, by your example, it looks like you are running from inside Pyro. This example is really meant to run from the Python command. Maybe that is what is causing the problem. -Doug Jos? Antonio Becerra Permuy wrote: > Hi! > I just started to play with Pyro. I followed the instructions in "SOM: > Step-by-Step Example" and I found a problem at the beginning: > > Pyro Version 3.5.0: Ready... > >>>> from pyro.brain import psom > > Ok > >>>> from pyro.brain.psom import vis > > Ok > >>>> mysom = vis.VisPsom(3, 4, dim=5) > > Exception exceptions.AttributeError: "VisPsom instance has no attribute > 'params'" in instance at 0xb790afac>> ignored > ERROR: exceptions.TypeError unsubscriptable object > exceptions.TypeError: unsubscriptable object in command line > Exception exceptions.AttributeError: "VisPsom instance has no attribute > 'params'" in instance at 0xb78eb0cc>> ignored > > Python is 2.4. > Is the SOM module working in this version? > Regards. > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > -- 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 gsakkis at rutgers.edu Tue Feb 8 11:01:18 2005 From: gsakkis at rutgers.edu (George Sakkis) Date: Tue Feb 8 10:56:58 2005 Subject: [Pyro-users] Pyro-Tekkotsu relationship ? Message-ID: <012901c50df7$6cf6bd40$ad03a8c0@charisteas> I'm going to work on a Sony Aibo and I've started reading the documentation of both Tekkotsu (http://www-2.cs.cmu.edu/~tekkotsu/) and Pyro, but I'm not sure yet how do they relate to one another. Although Tekkotsu is a huge improvement compared to the messy underlying Open-R API, my first impression based on the "SampleBehavior" and "SampleMC" tutorial examples are that it is still cumbersome for high-level robot programming (I guess working almost exclusively on python for the last year or so makes everything else seem ugly ;-). I would be very happy if I could avoid digging into Tekkotsu altogether and focus on Pyro only, so I was wondering: is Pyro just a python wrapper of Tekkotsu (or a subset of it) ? Or they are complementary ? Or they address different needs/levels of abstraction ? Thanks in advance for any insight. George From kim.wheeler at roadnarrowsrobotics.com Tue Feb 8 11:11:59 2005 From: kim.wheeler at roadnarrowsrobotics.com (Kim Wheeler) Date: Tue Feb 8 11:08:13 2005 Subject: [Pyro-users] Question about Hemisson In-Reply-To: References: Message-ID: <4208E4CF.5050706@roadnarrowsrobotics.com> Hi Bob: I'm with RoadNarrowsRobotics and we are the local US distributers for Hemissons. I was at the Pyro workshop this last summer. RoadNarrows is very interested in supporting Hemisson with Pyro since it is open-source. If you are going to use Pyro and not Bot-Studio/Webots, there is no big need to buy Hemisson Deluxe. You can always change your mind later and get these tools added on. Also, you can buy your own rechargeable batteries and charger, they are standard 9 volt. The robot and its internal processor/configuration are identical. Webots/BotStudio should work on both linux and Windows. It would be better to buy some of the extensions like the blue tooth radio module than buy the deluxe, if you are using Pyro. Give me a call or email and I'll can help get a quote for you the educational discounts. - Kim By the way www.cyberbotics.com are the makers of the Webots simulation software and what comes with the Hemisson Delux is a limited version that works with Hemissons. www.k-team.com are the manufacturers of the Hemisson, more info on the Hemisson can be found from www.hemisson.com and our local US site, www.roadnarrowsrobotics.com . -- Kim Wheeler RoadNarrows LLC 1151 Eagle Dr. #140 Loveland, CO 80537 U.S.A. Tel: 970.593.0370 Fax: 970.461.9969 Website: www.roadnarrowsrobotics.com Bob Roos wrote: >I just learned that between now and Feb 15 I have an opportunity to >apply for approx. $2000 in support from my school. We have no robotics >facilities at all here. For this amount of money I can't really >consider things much more expensive than Hemissons or Mindstorms, and >the Pyro connection is a strong motivation for going with Hemisson. We >use Linux. > >>From the Hemisson page (at >http://www.cyberbotics.com/products/robots/hemisson.html) I see that >there are two versions, standard and deluxe. Given that we are >starting from scratch, I'm tempted by the deluxe (plus that apparently >is the only one configured to work with Linux), but of course it's >twice as expensive. > >All my robotics experinence has been via Pyro simulation (and a little >bit of Lego Mindstorms tinkering). I'm not looking to outfit an entire >lab here, just looking for enough robots to be able to do some student >research projects and special topics at this point; more equipment >would presumably be requested in a grant proposal somewhere down the >road. > >Comments or suggestions? (E.g., is it possible to start from scratch >with the "standard" Hemissons, or is it a good buy to get the deluxe, >which has BotStudio software, 2-yr warranty, etc., for the extra >money?) My current idea (I'm still looking at other options) is to >apply for funds for three Hemisson deluxe (although I haven't yet >looked into educational discounts -- how much have others of you paid >for Hemissons?). > >Your comments are much appreciated! > >Bob Roos >Allegheny College >_______________________________________________ >Pyro-users mailing list >Pyro-users@emergent.brynmawr.edu >http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > > > From ronin at udc.es Tue Feb 8 13:20:43 2005 From: ronin at udc.es (=?iso-8859-1?q?Jos=E9_Antonio_Becerra_Permuy?=) Date: Tue Feb 8 13:16:08 2005 Subject: [Pyro-users] Problem with SOM module In-Reply-To: <4208D311.5080901@brynmawr.edu> References: <200502071930.51106.ronin@udc.es> <4208D311.5080901@brynmawr.edu> Message-ID: <200502081920.43492.ronin@udc.es> El Martes, 8 de Febrero de 2005 15:56, Douglas S. Blank escribi?: > Your code snippet worked for me. I suspect that something didn't build > correctly. What version of SWIG are you using? I might be too old, or 1.3.24 > maybe it is too new and they have changed something. There is a SWIG > 1.3.17 at http://emergent.brynmawr.edu/~dblank/pyro/tars/ > > Also, by your example, it looks like you are running from inside Pyro. > This example is really meant to run from the Python command. Maybe that > is what is causing the problem. No, If I run it from python I get the same problem. Using pdb I found the error was in the first line of _ptrset function in brain/psom/__init__.py: def _ptrset(myarr, item, i): """ Given an array, an item, and an index, this function inserts the item into the array at position indexed by i. NOTE: Users should not ever use this function. """ if myarr[-5:] == 'float': csom.floatarray_setitem(myarr, i, item) elif myarr[-5:] == 'short': csom.shortarray_setitem(myarr, i, item) elif myarr[-3:] == 'int': csom.intarray_setitem(myarr, i, item) elif myarr[-4:] == 'char': csom.charstararray_setitem(myarr, i, item) # array of character pointers else: raise TypeError, myarr (Pdb) n TypeError: 'unsubscriptable object' > /usr/local/pyro/brain/psom/__init__.py(70)_ptrset() -> if myarr[-5:] == 'float': It seems an SWIG problem like you said. I can use an older version of SWIG, but I think that Pyro should work with latest version... Unfortunately, I'm a newbie regarding Pyro, Python and SWIG :-( Regards. From dblank at brynmawr.edu Tue Feb 8 15:15:14 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Tue Feb 8 15:10:52 2005 Subject: [Pyro-users] Pyro-Tekkotsu relationship ? In-Reply-To: <012901c50df7$6cf6bd40$ad03a8c0@charisteas> References: <012901c50df7$6cf6bd40$ad03a8c0@charisteas> Message-ID: <42091DD2.6040809@brynmawr.edu> George, Pyro only uses a small part of Tekkotsu, basically their debugger. Tekkotsu is a very interesting system for programming the Aibo through events. But we don't use that. Pyro just uses the Tekkotsu Monitor. The Montior is a series of servers that run on the Aibo such that any program can connect onto them and read sensor data, images, and control movements. We have made a Python interface to connect onto the servers running on the Aibo, and put a Pyro interface on that. The Pyro code will still run on a PC and connects to the dogs via wireless. The main project of Tekkotsu offers a unique programming environment. If I were going to land an Aibo on the moon, I'd probably use Tekkotsu to control it. But for doing interactive teaching, and high-level scripting and experiments in the lab, I'd use Pyro. To give you an idea of the environments: In Tekkotsu, if you want to change a line of code, you must recompile everything that depends on the code (it is C++ code) using the provided cross-compiler. Then the code is copied to the dog over ftp, the dog shuts down, and starts back up. The whole process (compile + transfer + reboot) lasts at least a minute on our machines. In Pyro, you simply press the "reload brain" button and nearly instantly you are running the new code. Others on this list might have other suggestions on environments for the Aibo. For those of you ready to start running Pyro with Aibo, I'll try to get our patches to the Tekkotsu group this week. -Doug George Sakkis wrote: > I'm going to work on a Sony Aibo and I've started reading the documentation of both Tekkotsu > (http://www-2.cs.cmu.edu/~tekkotsu/) and Pyro, but I'm not sure yet how do they relate to one > another. Although Tekkotsu is a huge improvement compared to the messy underlying Open-R API, my > first impression based on the "SampleBehavior" and "SampleMC" tutorial examples are that it is still > cumbersome for high-level robot programming (I guess working almost exclusively on python for the > last year or so makes everything else seem ugly ;-). I would be very happy if I could avoid digging > into Tekkotsu altogether and focus on Pyro only, so I was wondering: is Pyro just a python wrapper > of Tekkotsu (or a subset of it) ? Or they are complementary ? Or they address different needs/levels > of abstraction ? Thanks in advance for any insight. > > George > > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > -- 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 Tue Feb 8 15:18:01 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Tue Feb 8 15:13:39 2005 Subject: [Pyro-users] Problem with SOM module In-Reply-To: <200502081920.43492.ronin@udc.es> References: <200502071930.51106.ronin@udc.es> <4208D311.5080901@brynmawr.edu> <200502081920.43492.ronin@udc.es> Message-ID: <42091E79.4030104@brynmawr.edu> I was afraid of that. The code that you identified was a hack that we came up with to get the last major update of SWIG working with the som code. Looks like we'll have to revisit that again. If you solve it before we do, please send us a patch. -Doug Jos? Antonio Becerra Permuy wrote: > Using pdb I found the error was in the first line of _ptrset function in > brain/psom/__init__.py: > > def _ptrset(myarr, item, i): > """ > Given an array, an item, and an index, this function inserts the item > into the array at position indexed by i. > NOTE: Users should not ever use this function. > """ > if myarr[-5:] == 'float': > csom.floatarray_setitem(myarr, i, item) > elif myarr[-5:] == 'short': > csom.shortarray_setitem(myarr, i, item) > elif myarr[-3:] == 'int': > csom.intarray_setitem(myarr, i, item) > elif myarr[-4:] == 'char': > csom.charstararray_setitem(myarr, i, item) # array of character > pointers > else: > raise TypeError, myarr > > (Pdb) n > TypeError: 'unsubscriptable object' > >>/usr/local/pyro/brain/psom/__init__.py(70)_ptrset() > > -> if myarr[-5:] == 'float': > > It seems an SWIG problem like you said. I can use an older version of SWIG, > but I think that Pyro should work with latest version... Unfortunately, I'm a > newbie regarding Pyro, Python and SWIG :-( > Regards. > > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > -- 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 Feb 10 10:20:02 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Feb 10 10:15:39 2005 Subject: [Pyro-users] Re: Reading from the keyboard in Pyro In-Reply-To: <20050210043347.35401.qmail@web53306.mail.yahoo.com> Message-ID: Munjal Desai said: > I wanted to control the Pioneer Robots using the > keyboard through pyro, but I am unable to read from > the keyboard. Munjal, I'm going to respond to this in the pyro-users mailing list. Please post follow-ups there. You can join it at: http://emergent.brynmawr.edu/mailman/listinfo/pyro-users You can get responses from stdin, but you have to type in the console window not the Pyro window, and that may block all activity in that thread until you type somthing (there is a timeout() method I think on stdin). But here is another idea though: You might want to make something like the Joystick control. If you select "Joystick" under "Robot" from the main menu, you can control any robot by clicking in the circle. Take a look at that code in pyro/tools/joystick.py You'll notice that that program doesn't actually make a robot move, and has an extra layer of indirection. To actually make a robot move, you have to connect it to a robot. If you look in pyro/gui/TK.py you'll see: class JoystickDriver(Joystick): def __init__(self, robot): self.robot = robot Joystick.__init__(self) def move(self, translate, rotate): self.robot.move(translate, rotate) The reason we did that is that this same class can now be used for, say, a user-controlled wheelchair. For example, a user may try to control the chair to head into a wall, but in the JoyStickDriver class you can balance the user's desires with some protection, a way of implementing varying levels of autonomy. Ok, back to your problem. You can do the same kinds of things with the keyboard. Because the GUI does much more than just be a gui (it takes care of additional threads running, for example) you will probably still want to use it (there are other less-gui guis in Pyro, like using "-g tty" on start up). I think I would look at Tkinter to see how to bind a keystoke to a command, and do something similar to joystick.py above. Let us know if that works, -Doug > > I tried the following in the command line and in the > program. > > import sys > c = sys.stdin.read(1) > > and pyro just freezes. > > Is there some way of reading the keystrokes from pyro. > > I would highly appreciate your help in this matter. > > Thank You > > Munjal > > > > > > > > > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - Get yours free! > http://my.yahoo.com > > -- Douglas S. Blank, Assistant Professor dblank@brynmawr.edu, (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Building Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From dave.bc at gmail.com Tue Feb 15 23:56:42 2005 From: dave.bc at gmail.com (David Cameron) Date: Tue Feb 15 23:51:47 2005 Subject: [Pyro-users] install on Windows with MinGW? (X11 include files?) Message-ID: <9d7797b4050215205677551b3d@mail.gmail.com> After a bit of commenting in the configure.py script (somebody imported Posix directly...), I've gotten very close to installing Pyro on my WinXP system using MinGW. But then I got to 4. Where is the X11 include directory? Which is a good question. Is there an X11 for Windows that would include (oh dear) include files? Would Cygwin have the required files bundled with it? I must admit I'm pretty ignorant about Cygwin. I'm going to break out the debian discs, but I wanted to recommend pyro to a project team I'm working with, so any help would still be greatly appreciated! Dave From dblank at brynmawr.edu Wed Feb 16 16:58:46 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Wed Feb 16 16:53:58 2005 Subject: [Pyro-users] install on Windows with MinGW? (X11 include files?) In-Reply-To: <9d7797b4050215205677551b3d@mail.gmail.com> References: <9d7797b4050215205677551b3d@mail.gmail.com> Message-ID: <4213C216.8060503@brynmawr.edu> Dave, None of us core Pyro users have any Windows+Pyro experience, so you may be on your own on that issue. If you make progress, let us know and we would be glad to pass along anything that you find. You can also recommend our Live Pyro CD; just boot and start running Pyro under Knoppix. -Doug David Cameron wrote: > After a bit of commenting in the configure.py script (somebody > imported Posix directly...), I've gotten very close to installing Pyro > on my WinXP system using MinGW. > > But then I got to > 4. Where is the X11 include directory? > > Which is a good question. Is there an X11 for Windows that would > include (oh dear) include files? Would Cygwin have the required files > bundled with it? I must admit I'm pretty ignorant about Cygwin. > > I'm going to break out the debian discs, but I wanted to recommend > pyro to a project team I'm working with, so any help would still be > greatly appreciated! > > Dave > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > -- 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 mainline.brynmawr.edu Wed Feb 16 17:04:07 2005 From: dblank at mainline.brynmawr.edu (Douglas S. Blank) Date: Wed Feb 16 16:59:04 2005 Subject: [Pyro-users] Re: Mac and Windows Version Status In-Reply-To: <200502161405.j1GE5TKt021623@dangermouse.brynmawr.edu> References: <200502161405.j1GE5TKt021623@dangermouse.brynmawr.edu> Message-ID: <4213C357.6010301@cs.brynmawr.edu> > Hello, > > I found the Pyro site through a search engine. I saw from a note that > Windows and OS X versions were due soon though I don?t know from when. > Is there any finer resolution on timing? We should have the main Python code cross-platform in the next week. Exactly what simulators that will run on those two platforms remains to be seen, however. You can start by exploring Player/Stage and Gazebo. Also Robocup Soccer Server is reportedly cross-platform. You can subscribe to the pyro-users mailing list for follow-ups. -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 Thu Feb 17 13:06:15 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Feb 17 13:01:11 2005 Subject: [Pyro-users] Pyro's mind/body unification; workshop; suggestions Message-ID: <4214DD17.6060208@brynmawr.edu> As we prepare for the final year of the three-year NSF grant, "Beyond Legos: Building the Next Generation Robotics Laboratory" we are making the last major conecptual reorganizations in Pyro. This is also the last year for the Summer Pyro Workshop. If interested in coming to it, please see http://cs.brynmawr.edu/BeyondLegos/Workshops/2005.html Toward this end we have just committed a few changes to Pyro 3.6.0 and to the on-line Pyro documentation. These changes will hopefully make the API a little clearer and easier to explain and use. The first of these is a bit of unification between Pyro's idea of mind and body. Pyro has the objects Brain and Robot, and these two object were the main objects that people interacted with when writing controllers. However, the API was a little clunky when one interacted with these. For example, to find out where the robot thinks it is, you write: >>> self.robot.get("robot/x") "self" is the brain, inside of which is where you write all of your code. But then the brain had to reference the robot, which then had to make the "robot/x" request. This was an interface that evolved from the first idea of controlling robots from Python. In the beginning, we weren't sure how many Brains a user might create at a time, and weren't sure how many Robots each brain might control. Now we know that most users use 1 brain to control 1 robot, and so it makes sense to make less distinction between the Brain and Robot. In the latest version of Pyro, you can now control many robot-centric commands without having to refer to the robot twice. The above command becomes: >>> self.get("robot/x") This is now true for move(), startDevice(), removeDevice() and all of the common things that you would do to the robot. The old method is still valid, but you can use the shorter version, too. Also, this doesn't prevent a single Brain from controlling more than one robot (you can see the RobocupTeam examples to see how you might want to organize that), but it does have good default behavior. (The Pyro RobocupTeam example breaks the Robocup Soccer rules BTW. But it is a easy interface for exploring team-based robotics issues, like soccer.) If you have run into any bits of Pyro that you found confusing, or you have an idea for making something more clear, please let us know. We hope to have Pyro 4.0 finished in the next few weeks. It will include: * support for Aibo (first draft currently included) * support for the latest Player/Stage/Gazebo * Gazebo simulated camera * ER1 support * Web-based version * expression watcher (first draft currently included) * Python code will be cross-platform compatible * Updated Live Pyro CD * Better comments in code * Updated documentation (later this spring) * User's manual (later this spring) Thanks for any feedback! -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 gsakkis at eden.rutgers.edu Thu Feb 17 15:45:03 2005 From: gsakkis at eden.rutgers.edu (gsakkis@eden.rutgers.edu) Date: Thu Feb 17 15:39:55 2005 Subject: [Pyro-users] Pyro's mind/body unification; workshop; suggestions In-Reply-To: <4214DD17.6060208@brynmawr.edu> References: <4214DD17.6060208@brynmawr.edu> Message-ID: <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> > As we prepare for the final year of the three-year NSF grant, "Beyond > Legos: Building the Next Generation Robotics Laboratory" we are making > the last major conecptual reorganizations in Pyro. This is also the last > year for the Summer Pyro Workshop. If interested in coming to it, please > see http://cs.brynmawr.edu/BeyondLegos/Workshops/2005.html > > Toward this end we have just committed a few changes to Pyro 3.6.0 and > to the on-line Pyro documentation. These changes will hopefully make the > API a little clearer and easier to explain and use. > > The first of these is a bit of unification between Pyro's idea of mind > and body. Pyro has the objects Brain and Robot, and these two object > were the main objects that people interacted with when writing > controllers. However, the API was a little clunky when one interacted > with these. For example, to find out where the robot thinks it is, you > write: > > >>> self.robot.get("robot/x") > > "self" is the brain, inside of which is where you write all of your > code. But then the brain had to reference the robot, which then had to > make the "robot/x" request. > > This was an interface that evolved from the first idea of controlling > robots from Python. In the beginning, we weren't sure how many Brains a > user might create at a time, and weren't sure how many Robots each brain > might control. Now we know that most users use 1 brain to control 1 > robot, and so it makes sense to make less distinction between the Brain > and Robot. > > In the latest version of Pyro, you can now control many robot-centric > commands without having to refer to the robot twice. The above command > becomes: > > >>> self.get("robot/x") > > This is now true for move(), startDevice(), removeDevice() and all of > the common things that you would do to the robot. The old method is > still valid, but you can use the shorter version, too. > > Also, this doesn't prevent a single Brain from controlling more than one > robot (you can see the RobocupTeam examples to see how you might want to > organize that), but it does have good default behavior. (The Pyro > RobocupTeam example breaks the Robocup Soccer rules BTW. But it is a > easy interface for exploring team-based robotics issues, like soccer.) > > If you have run into any bits of Pyro that you found confusing, or you > have an idea for making something more clear, please let us know. We > hope to have Pyro 4.0 finished in the next few weeks. It will include: > > * support for Aibo (first draft currently included) > * support for the latest Player/Stage/Gazebo > * Gazebo simulated camera > * ER1 support > * Web-based version > * expression watcher (first draft currently included) > * Python code will be cross-platform compatible > * Updated Live Pyro CD > * Better comments in code > * Updated documentation (later this spring) > * User's manual (later this spring) > > Thanks for any feedback! > > -Doug That's all very good news, and I'm looking forward to Pyro 4.0 ! I've been poking into Pyro's internals over the last few days, and to be honest, I was discouraged by the complicated design and (at a less extent) by the not-so-pythonic style. If I could pick one thing I wished it was different, this would be the get/set device API, with devices being specified as Unix-like paths. Instead I found the ipyro wrapper more natural, though this can be improved further. Here's a rough idea of my preferred API ('<<<' is used for the existing expression, '>>>' for the proposed one): <<< robot.get('/robot/range/count') >>> len(robot.rangeSensors) <<< robot.get('/robot/range/0/value') >>> robot.rangeSensors[0].distance() <<< robot.set('/robot/range/units', 'CM') <<< robot.get('/robot/range/0/value') >>> robot.rangeSensors[0].distance(unit='cm') <<< robot.get('/robot/range/all/value') >>> [sensor.distance() for sensor in robot.rangeSensors] <<< robot.get("/robot/range/all/th") >>> [sensor.angle() for sensor in robot.rangeSensors] <<< robot.get("/robot/range/all/thr") >>> [sensor.angle(inRadians=True) for sensor in robot.rangeSensors] <<< # returns a dict for each sensor <<< robot.get("/robot/range/all/value,th") >>> # returns a tuple for each sensor >>> [(sensor.distance(), sensor.angle()) for sensor in robot.rangeSensors] <<< robot.get('/robot/range/2/x,y') # returns dict {'y': y, 'x': x} >>> robot.rangeSensors[2].position() # returns tuple (x,y) <<< robot.get('/robot/range/front/value') >>> [sensor.distance() for sensor in robot.rangeSensors['front']] <<< robot.get('/robot/range/1:5/value') >>> [sensor.distance() for sensor in robot.rangeSensors[1:5]] # finding out the direction of the nearest obstacle around <<< from pyro.brain import select, avg <<< select(min, "value", self.get("/robot/range/all/pos,thr,value"))["thr"] >>> min([(sensor.distance(), sensor.angle()) >>> for sensor in robot.rangeSensors])[1] On a side note, I have a setup.py that builds (a subset of) Pyro on cygwin, but I think it should be cross-platform with no or few minor modifications. Currently it doesn't cover extensions modules with dependencies that are not available on cygwin or I didn't need to build (camera/bt848, camera/V4L, robot/driver/saphira, simulators/khepera, tools/cluster), but these should be relatively easy to be accomodated as well. Best, George From dblank at brynmawr.edu Thu Feb 17 16:39:53 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Feb 17 16:35:10 2005 Subject: [Pyro-users] Pyro's mind/body unification; workshop; suggestions In-Reply-To: <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> References: <4214DD17.6060208@brynmawr.edu> <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> Message-ID: <42150F29.5050600@brynmawr.edu> gsakkis@eden.rutgers.edu wrote: > That's all very good news, and I'm looking forward to Pyro 4.0 ! I've been poking > into Pyro's internals over the last few days, and to be honest, I was discouraged > by the complicated design and (at a less extent) by the not-so-pythonic style. If > I could pick one thing I wished it was different, this would be the get/set > device API, with devices being specified as Unix-like paths. Instead I found the > ipyro wrapper more natural, though this can be improved further. Here's a rough > idea of my preferred API ('<<<' is used for the existing expression, '>>>' for > the proposed one): George, This is something that we have been wrestling with, and I very much like your interface. I think that with a couple of additional methods we can do it very much like your suggestion. What we were trying to accomplish with our unPythonic get() and set() was a controlled view what was accessible. For instance, if you say: dir(robot) You see lots of methods and properties that we wanted to hide from the novice's view. By implementing our own get/set we could give just the robot-specific methods and properties. (The get/set code got out-of-control and is the ugliest bits I ever saw. I can say that, as, I am afraid to admit it, I wrote it.) Currently, Pyro can access the range sensor, for example, with: robot.range but that returns the Device object. I will add __len__, __getitem__, etc. to those to make it work like you suggest. I don't know of a way to make those listable though (so that ipyro would work) with dir() and other Python tools. If you have other suggestions, please let us know. > On a side note, I have a setup.py that builds (a subset of) Pyro on cygwin, but I > think it should be cross-platform with no or few minor modifications. Currently > it doesn't cover extensions modules with dependencies that are not available on > cygwin or I didn't need to build (camera/bt848, camera/V4L, robot/driver/saphira, > simulators/khepera, tools/cluster), but these should be relatively easy to be > accomodated as well. Please send your additions, and I will add them to the standard install. Thanks! -Doug > Best, > George > -- 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 gsakkis at eden.rutgers.edu Thu Feb 17 18:25:39 2005 From: gsakkis at eden.rutgers.edu (gsakkis@eden.rutgers.edu) Date: Thu Feb 17 18:20:30 2005 Subject: [Pyro-users] Pyro's mind/body unification; workshop; suggestions In-Reply-To: <42150F29.5050600@brynmawr.edu> References: <4214DD17.6060208@brynmawr.edu> <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> <42150F29.5050600@brynmawr.edu> Message-ID: <62126.68.197.31.58.1108682739.squirrel@webmail.eden.rutgers.edu> > George, > > This is something that we have been wrestling with, and I very much like > your interface. I think that with a couple of additional methods we can > do it very much like your suggestion. I also think it's doable, without even breaking backwards compatibility if this is necessary; get() and set() can remain and work without change (probably annotated as deprecated). > What we were trying to accomplish with our unPythonic get() and set() > was a controlled view what was accessible. For instance, if you say: > > dir(robot) > > You see lots of methods and properties that we wanted to hide from the > novice's view. By implementing our own get/set we could give just the > robot-specific methods and properties. (The get/set code got > out-of-control and is the ugliest bits I ever saw. I can say that, as, I > am afraid to admit it, I wrote it.) > > Currently, Pyro can access the range sensor, for example, with: > > robot.range > > but that returns the Device object. I will add __len__, __getitem__, > etc. to those to make it work like you suggest. I don't know of a way to > make those listable though (so that ipyro would work) with dir() and > other Python tools. dir() is a handy introspection function intended to be used interactively, mainly for debugging or just out of curiosity, but certainly not for documentation, especially for the novice (running e.g. dir(1) will scare off for good the unsuspecting python newbie). I can't think any better workaround than good __doc__umentation that describes the interface; this is easily accessed in IPython by prepending (or appending) '?' to any object (e.g. 'pyro.robot.Robot ?') > If you have other suggestions, please let us know. > > > On a side note, I have a setup.py that builds (a subset of) Pyro on cygwin, but I > > think it should be cross-platform with no or few minor modifications. Currently > > it doesn't cover extensions modules with dependencies that are not available on > > cygwin or I didn't need to build (camera/bt848, camera/V4L, robot/driver/saphira, > > simulators/khepera, tools/cluster), but these should be relatively easy to be > > accomodated as well. > > Please send your additions, and I will add them to the standard install. I will try to think of any undocumented changes I made, add some comments, and I'll send them over in the next few days. > Thanks! > > -Doug Regards, George