From w.richert at gmx.net Mon May 2 15:39:42 2005 From: w.richert at gmx.net (Willi Richert) Date: Mon May 2 09:28:20 2005 Subject: [Pyro-users] pyro compilation errors Message-ID: <200505021539.42478.w.richert@gmx.net> Hi, my version is 3.6.1. However, in setup.py I get: setup(name = "pythonrobotics", version = "2.2.3", ... I fully obeyed http://emergent.brynmawr.edu/pyro/?page=PyroInstallation. A clean make gives: ... ... make[1]: Leaving directory `/home/wr/forschung/software/ps-cvs/pyro/brain/psom/csom_src/som_pak-dev' (cd ./tools/cluster && make) make[1]: Entering directory `/home/wr/forschung/software/ps-cvs/pyro/tools/cluster' cc -O -DFLOAT=double -c -o alloc.o alloc.c In file included from alloc.c:38: alloc.h:32: Fehler: in Konflikt stehende Typen f?r ?malloc? (it's german => Error: types for "malloc" are conflicting) alloc.h:32: Fehler: in Konflikt stehende Typen f?r ?malloc? alloc.h:33: Fehler: in Konflikt stehende Typen f?r ?calloc? alloc.h:33: Fehler: in Konflikt stehende Typen f?r ?calloc? make[1]: *** [alloc.o] Fehler 1 make[1]: Leaving directory `/home/wr/forschung/software/ps-cvs/pyro/tools/cluster' make: *** [tools/cluster] Fehler 2 =========== My Makefile.cfg ============= # Pyro - Python Robotics Config Script # What version of Python do you want to build Pyro for? # Leave empty if your python binary is just "python" PYTHON_VERSION= # Where exactly is python? PYTHON_BIN=/usr/bin/python2 # Where is this version of Python's include files? PYTHON_INCLUDE=-I/usr/include/python2.3 # Where are X11 files (such as X11 include directory)? X11_DIR = /usr/X11R6 # What subdirs to include in the make process? CONFIGDIRS = vision/cvision camera/fake camera/blob camera/aibo camera/robocup brain/psom brain/psom/csom_src/som_pak-dev tools/cluster simulators/khepera ==================================== Thanks for any help, wr From dblank at mainline.brynmawr.edu Mon May 2 10:01:59 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Mon May 2 09:50:59 2005 Subject: [Pyro-users] pyro compilation errors In-Reply-To: <200505021539.42478.w.richert@gmx.net> Message-ID: Willi Richert said: > Hi, > > my version is 3.6.1. However, in setup.py I get: > setup(name = "pythonrobotics", > version = "2.2.3", ... Willi, The setup.py in the root directory of Pyro is a work in progress. The plan is that it will be used in Pyro4, which is why it isn't mentioned in the installation docs yet, and, in fact, doesn't quite work yet. The following error is a result of the changing GCC compiler tools. This has been fixed in the upcoming Pyro4. You can apply the fix yourself, or move to Pyro4 (out of CVS). See: http://pyrorobotics.org/pyro/?page=Pyro4Installation The fix can be found here: http://bubo.brynmawr.edu/cgi-bin/viewcvs.cgi/pyro/tools/cluster/alloc.h.diff?r1=1.1&r2=1.2 -Doug > I fully obeyed http://emergent.brynmawr.edu/pyro/?page=PyroInstallation. A > clean make gives: > ... > ... > make[1]: Leaving directory > `/home/wr/forschung/software/ps-cvs/pyro/brain/psom/csom_src/som_pak-dev' > (cd ./tools/cluster && make) > make[1]: Entering directory > `/home/wr/forschung/software/ps-cvs/pyro/tools/cluster' > cc -O -DFLOAT=double -c -o alloc.o alloc.c > In file included from alloc.c:38: > alloc.h:32: Fehler: in Konflikt stehende Typen für »malloc« > (it's german => Error: types for "malloc" are conflicting) > alloc.h:32: Fehler: in Konflikt stehende Typen für »malloc« > alloc.h:33: Fehler: in Konflikt stehende Typen für »calloc« > alloc.h:33: Fehler: in Konflikt stehende Typen für »calloc« > make[1]: *** [alloc.o] Fehler 1 > make[1]: Leaving directory > `/home/wr/forschung/software/ps-cvs/pyro/tools/cluster' > make: *** [tools/cluster] Fehler 2 > > > =========== My Makefile.cfg ============= > > # Pyro - Python Robotics Config Script > > # What version of Python do you want to build Pyro for? > # Leave empty if your python binary is just "python" > PYTHON_VERSION= > > # Where exactly is python? > PYTHON_BIN=/usr/bin/python2 > > # Where is this version of Python's include files? > PYTHON_INCLUDE=-I/usr/include/python2.3 > > # Where are X11 files (such as X11 include directory)? > X11_DIR = /usr/X11R6 > > # What subdirs to include in the make process? > CONFIGDIRS = vision/cvision camera/fake camera/blob camera/aibo > camera/robocup brain/psom brain/psom/csom_src/som_pak-dev tools/cluster > simulators/khepera > ==================================== > > Thanks for any help, > wr > > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > -- From w.richert at gmx.net Fri May 6 06:06:47 2005 From: w.richert at gmx.net (Willi Richert) Date: Fri May 6 05:55:49 2005 Subject: [Pyro-users] change in stage cvs -> change in pyro's stage cfg file Message-ID: <200505061206.48012.w.richert@gmx.net> Hi, since some naming convention in the recent stage cvs has changed from libstage to libstageplugin you have to do the same in your cfg file, else you get the following error: ============================== invoking player_driver_init()...failed error : failed to resolve player_driver_init: /home/wr/forschung/software/ps-cvs/lib/libstage.so.1: undefined symbol: player_driver_init error : failed to load plugin: libstage ============================== Regards, wr From dblank at mainline.brynmawr.edu Fri May 6 08:04:15 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Fri May 6 07:52:57 2005 Subject: [Pyro-users] change in stage cvs -> change in pyro's stage cfg file In-Reply-To: <200505061206.48012.w.richert@gmx.net> Message-ID: Thanks! Just one of the problems with basing our code on someone else's CVS code. It looks like Player/Stage/Gazebo is going to have some big changes in CVS soon. But it also looks they are about to have a release that is useable. As soon as that happens, one can use the release, and we don't have to rely on the moving target CVS. -Doug Willi Richert said: > Hi, > > since some naming convention in the recent stage cvs has changed from libstage > to libstageplugin you have to do the same in your cfg file, else you get the > following error: > ============================== > invoking player_driver_init()...failed > error : failed to resolve > player_driver_init: /home/wr/forschung/software/ps-cvs/lib/libstage.so.1: > undefined symbol: player_driver_init > error : failed to load plugin: libstage > ============================== > > Regards, > wr > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > -- From dblank at brynmawr.edu Fri May 6 12:12:16 2005 From: dblank at brynmawr.edu (dblank@brynmawr.edu) Date: Fri May 6 12:00:55 2005 Subject: [Pyro-users] RE: Pyro 4 Install Questions? Message-ID: <32807.68.81.116.28.1115395936.squirrel@newwebmail.brynmawr.edu> Hi Matt, I'm replying to this through the pyro-users mailing list. Please check there followups. You can find more info on the mailing list at: http://emergent.brynmawr.edu/mailman/listinfo/pyro-users Comments below: > I've been working on trying to get Pyro 3 > and now Pyro 4 installed. The Installation is so far so good... > > However on step 2.7 Opencv, I keep coming up with errors whenever I do a > Make. I have the latest version of opencv from the cvs repository. > I've installed all the OpenCV requirements as stated in the INSTALL > file.... > [snip] > I'm running a standard/vanilla FC3 2.6.11 Kernel, on a P4 AOpen White > box. No real answers, but some hints: Working out of anyone's CVS is risky. Although we try to keep ours working at all times, that isn't always possible. So, I would try to find a stable version of OpenCV (a version that has a release number). Also, be aware that they may change their interface. Pay attention to what versions we mention in the install manual, and fall back to that version if you need to. On the other hand, OpenCV isn't critical to getting going. OpenCV is a package that Player/Stage can use, but is not required. In fact, Player/Stage is very good about not requiring much, if anything at all! But, some features won't be available. It would be nice to know what features you will lose by not having a particular project or library installed, but we don't have such a list yet. I'm not sure what won't work without OpenCV, but I suspect it isn't critical. Of course, you can always come back and install it later, and then re-configure the packages that depend on it. (OpenCV is a Computer Vision library. I don't know what might take advantage of it in Player/Stage. We could probably use in on our own vision code, though, so maybe some day it will be critical.) So, I would just skip it (and any other packages that give you trouble) for now. Hope that helps, -Doug From levmar at gmail.com Mon May 9 22:17:52 2005 From: levmar at gmail.com (Mark Leverentz) Date: Mon May 9 22:17:52 2005 Subject: [Pyro-users] Phission Interface Message-ID: <387d2ad205050919174f17c71@mail.gmail.com> Hello, I have been working with Pyro's vision tools; however, I've been struggling trying to get the phission piece to work. I've got phission installed on my system, and I can get it mostly working. However, the one thing that seems to provide all the pieces that I'm currently missing is the "phissioncamera" class. Is this class, mentioned in a few examples on the Pyro/Phission page, a Pyro 4 item? I can't seem to find it in Pyro 3.6 or in CVS anywhere. It also doesn't seem to be included in the Phission package. What I'm really looking for is a way to provide a phission Capture class that will wrap a pyro Camera, so that I can get my AIBO's camera into the phission pipeline. Mark Leverentz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emergent.brynmawr.edu/pipermail/pyro-users/attachments/20050509/57fc5164/attachment.htm From thomas.hauser at usu.edu Mon May 9 22:57:01 2005 From: thomas.hauser at usu.edu (Thomas Hauser) Date: Mon May 9 22:57:01 2005 Subject: [Pyro-users] Neural network unknown input? Message-ID: <200505092057.01679.thomas.hauser@usu.edu> Hi, I have a question regarding the neural networks in Phyro. How do I use the NN with unknown input? My approach is n.setLearning(0) ninput = [0.15,0.15] noutput = [0., 0.] n.step(input=ninput, output=noutput) print n['output'].activation Is that the correct approach? Regards Thomas -- Thomas Hauser Assistant Professor Mechanical & Aerospace Engineering Utah State University Phone: (435) 797-2834, FAX: (435) 797 2417, E-mail: thauser@engineering.usu.edu URL: http://www.mae.usu.edu/faculty/thauser From holly at cs.uml.edu Mon May 9 23:15:43 2005 From: holly at cs.uml.edu (Holly Yanco) Date: Mon May 9 23:15:33 2005 Subject: [Pyro-users] Phission Interface In-Reply-To: <387d2ad205050919174f17c71@mail.gmail.com> (message from Mark Leverentz on Mon, 9 May 2005 21:17:52 -0500) Message-ID: <200505100315.j4A3FhZl193885@venus.cs.uml.edu> Attached is the phissioncamera.py file. Holly #----------- # phissioncamera class # by Andrew Chanler # June 2004 # # This is a class intended to allow people to play with # phission without having to learn all the phission # setup and pipeline stuff. # #----------- #----------------------------------------------------------------------------- # Import all of phission import sys sys.path.append("../../"); from phission.brains import PhissionUtil from phission import * #----------------------------------------------------------------------------- class phissioncamera(PhissionUtil): def setup(self, capturechannel, capturewidth = 320, captureheight = 240): PhissionUtil.__init__(self) self.display = SDLDisplay() self.phission_AddDisplay(self.display) self.capture = V4LCapture() self.phission_AddCapture(self.capture) self.capture.set(capturewidth, captureheight) self.capture.setChannel(capturechannel) #---------------------------------------------------------- # Initialize the filters self.blob = blob_Filter() self.blob_data = phBlobData() self.blob_color = phColorRGB24_new(0, 0, 0) self.blob_tol = phColorRGB24_new(0, 0, 0) self.blob.addColor(self.blob_color, self.blob_tol) self.blob.setOutcolor(phColorRGB24_new(255,0,0)) self.blob.setColorBlobs(1) self.blob.setDrawRects(1) self.empty = empty_Filter() self.gauss = gaussian3x3_Filter() self.sub = subtract_Filter(2,1) self.addfilter = add_Filter(3,1) self.hsv = convert_Filter(phImageHSV24) self.hist = histogram_Filter() self.hist_data = phHistogramData() self.canny = cv_canny_Filter() self.sobel = sobel_Filter() self.median = medianNxN_Filter(5) #----------------------------------------------------------- # Put the filters into the pipeline self.pipeline = phPipeline() self.phission_AddPipeline(self.pipeline) self.pipeline.add(self.empty.phFilterPtr()) # Capture -> phPipeline -> Display self.pipeline.setLiveSourceInput(self.capture.getLiveSourceOutput()) self.display.setLiveSourceInput(self.pipeline.getLiveSourceOutput()) self.phission_Startup() def destroy(self): "Destroy phission to release the capture device." return self.phission_Shutdown() def play(self): "Resume play after pausing phission." return self.phission_Startup() def pause(self): "Pause phission." return self.phission_Halt() def no_Filter(self): "Do not run any filters." self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.empty.phFilterPtr()) self.pipeline.startPipeline() def motion_Filter(self): self.pipeline.stopPipeline() self.pipeline.empty() self.__set_blobcolor(phColorRGB24_new(255,255,255),phColorRGB24_new(200,200,200)) self.pipeline.add(self.sub.phFilterPtr()) self.pipeline.add(self.addfilter.phFilterPtr()) self.pipeline.add(self.blob.phFilterPtr()) self.pipeline.startPipeline() def canny_Filter(self): self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.canny.phFilterPtr()) self.pipeline.startPipeline() def sobel_Filter(self): self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.sobel.phFilterPtr()) self.pipeline.startPipeline() def gaussianBlur_Filter(self): self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.startPipeline() def medianBlur_Filter(self): self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.median.phFilterPtr()) self.pipeline.startPipeline() def ColorTrackHSV_Filter(self, color, tol): self.pipeline.stopPipeline() self.pipeline.empty() thecolor = phColorHSV24_new( color[0], color[1], color[2]) self.__set_blobcolor(thecolor, phColorHSV24_new(tol[0],tol[1],tol[2])) self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.hsv.phFilterPtr()) self.pipeline.add(self.blob.phFilterPtr()) self.pipeline.startPipeline() def ColorTrackRGB_Filter(self, color, tol): self.pipeline.stopPipeline() self.pipeline.empty() thecolor = phColorRGB24_new( color[0], color[1], color[2] ) self.__set_blobcolor(thecolor,phColorRGB24_new( tol[0], tol[1], tol[2])) self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.blob.phFilterPtr()) self.pipeline.startPipeline() def SpotColorTrackHSV_Filter(self, x, y, size, tol): self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.hsv.phFilterPtr()) thecolor = self.__hist_onetime(x, y, size) self.__set_blobcolor(thecolor, phColorHSV24_new(tol[0],tol[1],tol[2])) self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.hsv.phFilterPtr()) self.pipeline.add(self.blob.phFilterPtr()) self.pipeline.startPipeline() def SpotColorTrackRGB_Filter(self, x, y, size, tol): self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.gauss.phFilterPtr()) thecolor = self.__hist_onetime(x, y, size) self.__set_blobcolor(thecolor,phColorRGB24_new( tol[0], tol[1], tol[2])) self.pipeline.stopPipeline() self.pipeline.empty() self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.blob.phFilterPtr()) self.pipeline.startPipeline() def histogramRGB_Filter(self, x, y, size): self.pipeline.stopPipeline() self.pipeline.empty() if(x - size < 0): x = size if(y - size < 0): y = size if(x + size > self.capture.getWidth() - 1): x = self.capture.getWidth() - size if(y + size > self.capture.getHeight() - 1): y = self.capture.getHeight() - size self.hist.set( x - size, y - size, x + size, y + size, 8, 1, phColorRGB24_new(255,0,255)) self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.hist.phFilterPtr()) self.pipeline.startPipeline() def histogramHSV_Filter(self, x, y, size): self.pipeline.stopPipeline() self.pipeline.empty() if(x - size < 0): x = size if(y - size < 0): y = size if(x + size > self.capture.getWidth() - 1): x = self.capture.getWidth() - size if(y + size > self.capture.getHeight() - 1): y = self.capture.getHeight() - size self.hist.set( x - size, y - size, x + size, y + size, 8, 1, phColorRGB24_new(255,0,255)) self.pipeline.add(self.gauss.phFilterPtr()) self.pipeline.add(self.hsv.phFilterPtr()) self.pipeline.add(self.hist.phFilterPtr()) self.pipeline.startPipeline() def getHistData(self): self.hist.getHistogramData(self.hist_data) temp = self.hist_data.getColor() # note: refering to temp.rgb24.r is the same as saying temp.hsv24.v and so on return (temp.rgb24.r, temp.rgb24.g, temp.rgb24.b) def getMaxBlob(self): self.blob.getBlobData(self.blob_data) return self.blob_data.getBlob(0) def getMaxBlob_cx(self): self.blob.getBlobData(self.blob_data) return self.blob_data.getBlob(0).cx def getMaxBlob_cy(self): self.blob.getBlobData(self.blob_data) return self.blob_data.getBlob(0).cy def getMaxBlob_mass(self): self.blob.getBlobData(self.blob_data) return self.blob_data.getBlob(0).mass def __set_blobcolor(self, newcolor, newtol): self.blob.removeColor(self.blob_color, self.blob_tol) self.blob_color = newcolor self.blob_tol = newtol self.blob_tol.type = self.blob_color.type self.blob.addColor(self.blob_color, self.blob_tol) def __hist_onetime(self, x, y, size): #assumes pipeline is already stopped and preliminary filters are already loaded if(x - size < 0): x = size if(y - size < 0): y = size if(x + size > self.capture.getWidth() - 1): x = self.capture.getWidth() - size if(y + size > self.capture.getHeight() - 1): y = self.capture.getHeight() - size self.hist.set( x - size, y - size, x + size, y + size, 8, 1, phColorRGB24_new(255,0,255)) self.pipeline.add(self.hist.phFilterPtr()) self.pipeline.runFilters() while(self.pipeline.isPipelineActive()): pass self.hist.getHistogramData(self.hist_data) return self.hist_data.getColor() From dblank at mainline.brynmawr.edu Tue May 10 00:16:33 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Tue May 10 00:16:21 2005 Subject: [Pyro-users] Neural network unknown input? In-Reply-To: <200505092057.01679.thomas.hauser@usu.edu> Message-ID: Thomas, Yes, your method would work fine. I assume that you don't want to train the network on these unknown values (how could you?), but just see what the outputs would be given some input. Notice that you must give step() the targets for the output layers, otherwise it will complain. So, you rightly did, and set learning off. A new method (thanks to suggestions by Jim Marshall) is to use the propagate() method, but this code is still in the CVS of conx.py (ready for Pyro4). It works like: >>> n.propagate(input=[0.15, 0.15]) [0.47829221171672637, 0.49863408402387427, 0.49847281125176623] That is, it works just like step, but doesn't require targets, and doesn't change any weights. It also returns the output layer activations (if there is just one output layer), or returns a dictionary (if there is more than one output layer). -Doug Thomas Hauser said: > Hi, > > I have a question regarding the neural networks in Phyro. > How do I use the NN with unknown input? > My approach is > > n.setLearning(0) > ninput = [0.15,0.15] > noutput = [0., 0.] > n.step(input=ninput, output=noutput) > print n['output'].activation > > Is that the correct approach? > > Regards > > Thomas > > -- > Thomas Hauser > Assistant Professor > Mechanical & Aerospace Engineering > Utah State University > Phone: (435) 797-2834, FAX: (435) 797 2417, E-mail: > thauser@engineering.usu.edu > URL: http://www.mae.usu.edu/faculty/thauser > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > -- From dblank at brynmawr.edu Tue May 10 10:13:47 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Tue May 10 10:13:38 2005 Subject: [Pyro-users] Phission Interface In-Reply-To: <387d2ad205050919174f17c71@mail.gmail.com> References: <387d2ad205050919174f17c71@mail.gmail.com> Message-ID: <4280C19B.8020104@brynmawr.edu> Mark, If you succeed in getting the AIBO camera (or more generally, the Pyro camera framework) into the Phission pipeline, that would be a very useful bit of code. If you get that, please donate it back to Pyro. You would earn your place next to all those others that deserve our fictitious Pyro Maniac T-shirts :) -Doug Mark Leverentz wrote: > Hello, > I have been working with Pyro's vision tools; however, I've been > struggling trying to get the phission piece to work. I've got phission > installed on my system, and I can get it mostly working. However, the > one thing that seems to provide all the pieces that I'm currently > missing is the "phissioncamera" class. Is this class, mentioned in a > few examples on the Pyro/Phission page, a Pyro 4 item? I can't seem to > find it in Pyro 3.6 or in CVS anywhere. It also doesn't seem to be > included in the Phission package. What I'm really looking for is a way > to provide a phission Capture class that will wrap a pyro Camera, so > that I can get my AIBO's camera into the phission pipeline. > > Mark Leverentz > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 pthoren at cs.uml.edu Tue May 10 13:36:17 2005 From: pthoren at cs.uml.edu (Philip D.S. Thoren) Date: Tue May 10 14:48:47 2005 Subject: [levmar@gmail.com: [Pyro-users] Phission Interface] In-Reply-To: <200505100316.j4A3GG4D193886@venus.cs.uml.edu> References: <200505100316.j4A3GG4D193886@venus.cs.uml.edu> Message-ID: <4280F111.9010907@cs.uml.edu> Hi Mark, phissioncamera.py was made obsolete by the new phSimpleVision class. The phissioncamera.py source won't work with the current CVS of Phission because of necessary changes to support phSimpleVision. The phissioncamera.py source was not part of Phission originally but rather a Python class to tie the Phission components together into a single easier to use object. phSimpleVision uses the ideas that Andrew Chanler (coder of phissioncamera.py) and Dr. Holly Yanco had in mind for a simpler vision class that uses Phission. The Wiki documentation needs to be updated to use phSimpleVision; The current documentation for Phission is at ( very rough ~100pgs ): http://cvs.sourceforge.net/viewcvs.py/*checkout*/phission/phission/docs/PhissionDocumentation.pdf There is a section that explains phSimpleVision and points to a couple examples contained in the "phission/examples/pyro" directory. I've looked at what the Aibo camera code in Pyro supplies and it looks like you have a char *, a width, a height and a format (RGB) to set into a phImage object. Since you have this, you should be able to get the image data into the Phission system. If you need any help with Phission, let me know and I'll do the best I can to help out. ~ Philip Thoren (Make sure any Phission emails get sent to me; I'm not currently subscribed to the pyro-users list; waiting for confirmation) >Hello, >I have been working with Pyro's vision tools; however, I've been >struggling trying to get the phission piece to work. I've got >phission installed on my system, and I can get it mostly working. >However, the one thing that seems to provide all the pieces that I'm >currently missing is the "phissioncamera" class. Is this class, >mentioned in a few examples on the Pyro/Phission page, a Pyro 4 >item? I can't seem to find it in Pyro 3.6 or in CVS >anywhere. It also doesn't seem to be included in the Phission >package. What I'm really looking for is a way to provide a >phission Capture class that will wrap a pyro Camera, so that I can get >my AIBO's camera into the phission pipeline. > >Mark Leverentz > > From dblank at mainline.brynmawr.edu Tue May 10 15:49:36 2005 From: dblank at mainline.brynmawr.edu (Douglas S. Blank) Date: Tue May 10 15:49:38 2005 Subject: [Pyro-users] Re: pyro for er1 robot In-Reply-To: <004f01c55573$282fd2f0$1e02000a@TODDSCOMPUTER> References: <004f01c55573$282fd2f0$1e02000a@TODDSCOMPUTER> Message-ID: <42811050.8030702@cs.brynmawr.edu> Todd, I'm responding to this through the pyro-users mailing list. You can join it here: http://emergent.brynmawr.edu/mailman/listinfo/pyro-users Look there for follow-ups. Now, to your question: Todd Leveck wrote: > Hi... I am interested in using Pyro for the Er1 robot. Is Er1 supported > now or in the near future? Thanks The ER1 is supported in Pyro exactly as much as it is supported under the Player/Stage project. That is, Pyro relies on the player interface to work with the ER1. I inquired recently about the ER1 on the player/stage users list, but didn't receive an answer. David Feil-Seifer was the person working on the interface, and he had movement working last I saw. The ER1 is listed as a project that you can enable/disable in player, so maybe the support is complete and done, I just don't know. If anyone knows more, please let us know. -Doug > Todd -- 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 Wed May 11 09:07:16 2005 From: w.richert at gmx.net (Willi Richert) Date: Wed May 11 09:07:07 2005 Subject: [Pyro-users] Pyro in batch mode Message-ID: <200505111507.17391.w.richert@gmx.net> Hi, has anyone already used pyro in batch mode (no gui, super fast). What about self.get("robot/timestep")? Do I have to consider some side effects compared to GUI mode? Regards, wr From dblank at brynmawr.edu Thu May 12 00:03:01 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu May 12 00:02:43 2005 Subject: [Pyro-users] Pyro in batch mode In-Reply-To: <200505111507.17391.w.richert@gmx.net> References: <200505111507.17391.w.richert@gmx.net> Message-ID: <4282D575.70302@brynmawr.edu> Willi, You can try setting brain.pauseTime from 0.1 (10 updates a second, max) to a smaller number, including zero. That should make the brain run top speed. There may be some side-effects, like, say, that the brain may run a few times before the sensors get updated again. Also, some of the devices (cameras for example) also get updated in that same loop. You may spend a fair amount of time waiting on the camera (if so, you might want to try the phission camera system, which runs in its own process, and has a pipeline). I don't think that there is a robot.timestep, but there is a robot.timestamp, but that just reflects the time of the last step call. (There is a brain.profilePerformance that you can set to 1; I think it was designed to find the max speed for running). Finally, a side comment: when we first built Pyro, we got 10,000 updates a second with an empty brain, on a fairly old machine. So, there should be some speed-ups available. -Doug Willi Richert wrote: > Hi, > > has anyone already used pyro in batch mode (no gui, super fast). What about > self.get("robot/timestep")? Do I have to consider some side effects compared > to GUI mode? > > Regards, > wr > _______________________________________________ > 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 w.richert at gmx.net Fri May 13 09:56:52 2005 From: w.richert at gmx.net (Willi Richert) Date: Fri May 13 09:56:38 2005 Subject: [Pyro-users] Using mcom with Pyro/Stage Message-ID: <200505131556.52172.w.richert@gmx.net> Hi, I need some means to communicate between the robots in my Stage simulation. There is a device dedicated to this: "mcom". If I specify it in my world file like ================================================ driver( name "stage" provides ["6665:position:0" "6665:laser:0" "6665:fiducial:0" "6665:mcom:0"] model "p0" ) ================================================ I get: mapping 6665.26.0 => err: error: stage driver doesn't support interface type 26 Are there alternatives or would I have to implement the communication by myself? Thanks, wr From dblank at brynmawr.edu Fri May 13 11:08:22 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri May 13 11:08:01 2005 Subject: [Pyro-users] Using mcom with Pyro/Stage In-Reply-To: <200505131556.52172.w.richert@gmx.net> References: <200505131556.52172.w.richert@gmx.net> Message-ID: <4284C2E6.3030706@brynmawr.edu> Willi, There was a "comm" interface in the old Player/Stage, and Pyro supported that somewhat (see pyro/robot/player.py PlayerCommDevice). I have heard that Player/Stage has a communication implementation ready for the next big version, player 1.7. But that doesn't really help now. It wouldn't take too much to implement a simple, fixed-size messaging system in either player, or in Python. The issues would largely be the same. I looked into using something like Jabber (an instant messaging interface) which has Python wrappers. It would work, but has a pretty high overhead, both in infrastructure and time delay (on the order of many seconds). As a bonus, though, humans could jump in, watch the conversations (for debugging), and even participate in the messaging. The Jabber approach does suggest a method that could be easily done in Python: instead of a peer-to-peer messaging system, write a server to send and receive the messages. First, Pyro could start a simple message server (like you might do with CORBA). A robot could "login" to the server, and send most any type of Python objects (through the Python pickle interface) to other robots. A message device would poll the server for messages, and put them in a queue. Sending a message would require a "to" field (you could actually using email for this!). I think you could hack something up using a Python server very quickly. For hints on this method, take a look at: pyro/plugins/simulators/SymbolicSimulator # loads a Symbolic World pyro/robot/symbolic.py # model for "device" pyro/plugins/worlds/Symbolic/*.py # model for "server" I can help with this late next week, or if you start such a client/server system, I can help finish it. It would be useful for Pyro. -Doug Willi Richert wrote: > Hi, > > I need some means to communicate between the robots in my Stage simulation. > There is a device dedicated to this: "mcom". If I specify it in my world file > like > ================================================ > driver( > name "stage" > provides ["6665:position:0" "6665:laser:0" "6665:fiducial:0" "6665:mcom:0"] > model "p0" > ) > ================================================ > I get: > > mapping 6665.26.0 => err: error: stage driver doesn't support interface > type 26 > > > Are there alternatives or would I have to implement the communication by > myself? > > Thanks, > wr > _______________________________________________ > 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 w.richert at gmx.net Fri May 13 14:42:32 2005 From: w.richert at gmx.net (Willi Richert) Date: Fri May 13 14:42:15 2005 Subject: [Pyro-users] Using mcom with Pyro/Stage In-Reply-To: <4284C2E6.3030706@brynmawr.edu> References: <200505131556.52172.w.richert@gmx.net> <4284C2E6.3030706@brynmawr.edu> Message-ID: <200505132042.32158.w.richert@gmx.net> Doug, I've started to implement my own little Communicator, since I've found out how to start several engines/brains in one process. After instantiating the Engine, I invoke my own brain Communicator setter, with which every Brain can direct messages to another brain. Of course this is not the most portable way (I won't be able to talk from Pyro brains to Java Player clients), but for my research it suffices. Thank you for your fast and detailed reply, wr PS: Of course, having a Pyro brain talking via Jabber to a human account is really spacy. The next time, maybe my pyro brain asks you questions on this mailing list ... you never know ;-) Am Freitag, 13. Mai 2005 17:08 schrieben Sie: > Willi, > > There was a "comm" interface in the old Player/Stage, and Pyro supported > that somewhat (see pyro/robot/player.py PlayerCommDevice). I have heard > that Player/Stage has a communication implementation ready for the next > big version, player 1.7. But that doesn't really help now. > > It wouldn't take too much to implement a simple, fixed-size messaging > system in either player, or in Python. The issues would largely be the > same. > > I looked into using something like Jabber (an instant messaging > interface) which has Python wrappers. It would work, but has a pretty > high overhead, both in infrastructure and time delay (on the order of > many seconds). As a bonus, though, humans could jump in, watch the > conversations (for debugging), and even participate in the messaging. > > The Jabber approach does suggest a method that could be easily done in > Python: instead of a peer-to-peer messaging system, write a server to > send and receive the messages. First, Pyro could start a simple message > server (like you might do with CORBA). A robot could "login" to the > server, and send most any type of Python objects (through the Python > pickle interface) to other robots. A message device would poll the > server for messages, and put them in a queue. Sending a message would > require a "to" field (you could actually using email for this!). I think > you could hack something up using a Python server very quickly. > > For hints on this method, take a look at: > > pyro/plugins/simulators/SymbolicSimulator # loads a Symbolic World > pyro/robot/symbolic.py # model for "device" > pyro/plugins/worlds/Symbolic/*.py # model for "server" > > I can help with this late next week, or if you start such a > client/server system, I can help finish it. It would be useful for Pyro. > > -Doug > > Willi Richert wrote: > > Hi, > > > > I need some means to communicate between the robots in my Stage > > simulation. There is a device dedicated to this: "mcom". If I specify it > > in my world file like > > ================================================ > > driver( > > name "stage" > > provides ["6665:position:0" "6665:laser:0" "6665:fiducial:0" > > "6665:mcom:0"] model "p0" > > ) > > ================================================ > > I get: > > > > mapping 6665.26.0 => err: error: stage driver doesn't support > > interface type 26 > > > > > > Are there alternatives or would I have to implement the communication by > > myself? > > > > Thanks, > > wr > > _______________________________________________ > > Pyro-users mailing list > > Pyro-users@emergent.brynmawr.edu > > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users From w.richert at gmx.net Sat May 14 07:06:46 2005 From: w.richert at gmx.net (Willi Richert) Date: Sat May 14 07:06:27 2005 Subject: [Pyro-users] Communication between agents Message-ID: <200505141306.46543.w.richert@gmx.net> 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 From dblank at mainline.brynmawr.edu Sat May 14 11:10:55 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Sat May 14 11:10:24 2005 Subject: [Pyro-users] Communication between agents In-Reply-To: <200505141306.46543.w.richert@gmx.net> Message-ID: 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 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 w.richert at gmx.net Tue May 17 08:08:21 2005 From: w.richert at gmx.net (Willi Richert) Date: Tue May 17 10:55:09 2005 Subject: [Pyro-users] Pyro in batch mode In-Reply-To: <4282D575.70302@brynmawr.edu> References: <200505111507.17391.w.richert@gmx.net> <4282D575.70302@brynmawr.edu> Message-ID: <200505171408.21605.w.richert@gmx.net> Hi, I have the following Python script which runs several robots in parallel together with my MonitorBrain that has some environmental management stuff to do: ==================================================== from pyro.engine import Engine import time brain = "NeedBrain" simulator = "StageSimulator" worldfile = "config/room.cfg" # Create the engines: engConfs = [("p0", "Player6665", brain, simulator, [], {}, worldfile, []), ("p1", "Player6666", brain, simulator, [], {}, worldfile, []), ("p2", "Player6667", brain, simulator, [], {}, worldfile, []), ("p3", "Player6668", brain, simulator, [], {}, worldfile, []) ] engines = [] monEng = Engine("Player7000", "MonitorBrain" , simulator, [], {}, worldfile, []) engines.append(monEng) monitor = monEng.brain for ec in engConfs: eng = Engine(*ec[1:]) engines.append(eng) monitor.register(ec[0], eng.brain) time.sleep(3) for e in engines: e.pleaseRun() runningTime = 60*60 print "run for %i seconds"%runningTime # Let them run for awhile: time.sleep(runningTime) ========================================================= However, if I start my brains using this script I get a totally different behavior than if I start a single brain using pyro GUI. E.g. after some seconds I get messages like "warning : 968 bytes leftover on write() to client" all the time. Furthermore, the robots behave, as if I had set the world's interval_real to low (e.g. 0). Both, interval_real and interval_sim are set to 100. I've also tried different values for Brain.pauseTime, but the behavior is always the same. The robots behave, if they get too little and too late sensor information. Any hints? -wr Am Donnerstag, 12. Mai 2005 06:03 schrieb Douglas S. Blank: > Willi, > > You can try setting brain.pauseTime from 0.1 (10 updates a second, max) > to a smaller number, including zero. That should make the brain run top > speed. There may be some side-effects, like, say, that the brain may run > a few times before the sensors get updated again. Also, some of the > devices (cameras for example) also get updated in that same loop. You > may spend a fair amount of time waiting on the camera (if so, you might > want to try the phission camera system, which runs in its own process, > and has a pipeline). > > I don't think that there is a robot.timestep, but there is a > robot.timestamp, but that just reflects the time of the last step call. > (There is a brain.profilePerformance that you can set to 1; I think it > was designed to find the max speed for running). > > Finally, a side comment: when we first built Pyro, we got 10,000 updates > a second with an empty brain, on a fairly old machine. So, there should > be some speed-ups available. > > -Doug > > Willi Richert wrote: > > Hi, > > > > has anyone already used pyro in batch mode (no gui, super fast). What > > about self.get("robot/timestep")? Do I have to consider some side effects > > compared to GUI mode? > > > > Regards, > > wr > > _______________________________________________ > > Pyro-users mailing list > > Pyro-users@emergent.brynmawr.edu > > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users 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-users] Re: [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 mac at cs.hmc.edu Fri May 20 16:46:30 2005 From: mac at cs.hmc.edu (Mac Mason) Date: Fri May 20 16:46:33 2005 Subject: [Pyro-users] Documentation on implementing a Robot class? Message-ID: <20050520204630.GB14081@turing.cs.hmc.edu> I'm looking for some documentation on implementing subclasses of Robot. In particular, I've got a homegrown simulator, and am writing a Pyro Simulator and Robot to talk to it. At the moment, the simulator works just fine, and the robot class implements move() and rotate() and translate() and all that. What I'm really very lost on is sensors; the simulator I'm using simulates a laser range finder, and that information is easy to get to. On the other hand, my reading of source and googling around hasn't helped me figure out how Pyro's abstraction works. Could somebody point me to some documentation on what functions I need to implement, what variables need setting, and what sort of format Pyro expects for ouput? Thanks! --Mac -- Julian "Mac" Mason mac@cs.hmc.edu Computer Science '06 (310)-882-8068 Harvey Mudd College -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-users/attachments/20050520/463bbc2f/attachment.bin From dblank at brynmawr.edu Fri May 20 17:50:30 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri May 20 17:50:46 2005 Subject: [Pyro-users] Documentation on implementing a Robot class? In-Reply-To: <20050520204630.GB14081@turing.cs.hmc.edu> References: <20050520204630.GB14081@turing.cs.hmc.edu> Message-ID: <428E5BA6.90606@brynmawr.edu> Mac, Good question, and one that probably hasn't been asked or answered before. This is an interface that has been evolving in an ad hoc manner since the beginning of Pyro 5 years ago or so. In the beginning, there was no standard method, and every type of robot did it a different way. Then, we developed the idea of a "device" and most robots now have moved to support this abstraction. Some robots talk to their sensors directly, and others have to communicate through another port or socket. In any event, the "device" is the way to go now. You can take a look at a sample device at pyro/plugins/devices/Test.py. That shows the basic idea. Then you need a way to get data from the sensor to the robot. The easiest way would be to store the values in the device.devData dictionary by its name in the update method: class TestDevice(Device): def __init__(self, sensor): self.sensor = sensor ... def update(self): """ Device update method """ self.devData["readingA"] = self.sensor.getReading() Here you notice that we need a handle on the sensor object, which you can pass in to the device as you construct it. For examples of that, see pyro/robot/player.py. After that, you can get the reading with: >>> robot.startDevice("TestDevice") >>> robot.testDevice.readingA The devData business is a bit complicated, and I think we will probably remove that. It has a bunch of connections to things like setables and getables that you will see in other robot implementations. Let us know if you have other questions. There isn't a lot of docs on this, but by asking questions you can help us know where we need more info. Thanks! -Doug Mac Mason wrote: > I'm looking for some documentation on implementing subclasses of Robot. > In particular, I've got a homegrown simulator, and am writing a Pyro > Simulator and Robot to talk to it. At the moment, the simulator works > just fine, and the robot class implements move() and rotate() and > translate() and all that. > > What I'm really very lost on is sensors; the simulator I'm using > simulates a laser range finder, and that information is easy to get to. > On the other hand, my reading of source and googling around hasn't > helped me figure out how Pyro's abstraction works. > > Could somebody point me to some documentation on what functions I need > to implement, what variables need setting, and what sort of format Pyro > expects for ouput? > > Thanks! > > --Mac > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 mac at cs.hmc.edu Sat May 21 00:44:19 2005 From: mac at cs.hmc.edu (Mac Mason) Date: Sat May 21 00:44:22 2005 Subject: [Pyro-users] Documentation on implementing a Robot class? In-Reply-To: <428E5BA6.90606@brynmawr.edu> References: <20050520204630.GB14081@turing.cs.hmc.edu> <428E5BA6.90606@brynmawr.edu> Message-ID: <20050521044418.GA16010@turing.cs.hmc.edu> On Fri, May 20, 2005 at 05:50:30PM -0400, Douglas S. Blank wrote: > You can take a look at a sample device at pyro/plugins/devices/Test.py. > That shows the basic idea. Then you need a way to get data from the > sensor to the robot. The easiest way would be to store the values in the > device.devData dictionary by its name in the update method: > > class TestDevice(Device): > def __init__(self, sensor): > self.sensor = sensor > ... > def update(self): > """ Device update method """ > self.devData["readingA"] = self.sensor.getReading() > So Devices have the devData dictionary? That makes sense. > Here you notice that we need a handle on the sensor object, which you > can pass in to the device as you construct it. For examples of that, see > pyro/robot/player.py. So, I need to define a Sensor class as well? It looks like all it needs to do (in this case) is provide a getReading() function, which talks to my simulator (sockets, in this case) and gives back the value. So far, so good. > After that, you can get the reading with: > > >>> robot.startDevice("TestDevice") > >>> robot.testDevice.readingA > How do I teach the robot that it has this device? Is there a list of devices somewhere that I need to add it to? Thanks! --Mac -- Julian "Mac" Mason mac@cs.hmc.edu Computer Science '06 (310)-882-8068 Harvey Mudd College -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-users/attachments/20050520/a27b4c9a/attachment.bin From dblank at brynmawr.edu Sat May 21 10:06:04 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Sat May 21 10:06:10 2005 Subject: [Pyro-users] Documentation on implementing a Robot class? In-Reply-To: <20050521044418.GA16010@turing.cs.hmc.edu> References: <20050520204630.GB14081@turing.cs.hmc.edu> <428E5BA6.90606@brynmawr.edu> <20050521044418.GA16010@turing.cs.hmc.edu> Message-ID: <428F404C.6080704@brynmawr.edu> Mac, Some comments below: Mac Mason wrote: > On Fri, May 20, 2005 at 05:50:30PM -0400, Douglas S. Blank wrote: >> >>class TestDevice(Device): >> def __init__(self, sensor): >> self.sensor = sensor >> ... >> def update(self): >> """ Device update method """ >> self.devData["readingA"] = self.sensor.getReading() >> > > > So Devices have the devData dictionary? That makes sense. Yes, exactly. You can put anything in there (lists, strings, numbers), and it will be available through the get() methods path-like syntax: robot.get("robot/sensor/value") or through the Python syntax: robot.sensor.value You can also overload __len__, add a groups dictionary (for named ranges), and some other handy functions. >>Here you notice that we need a handle on the sensor object, which you >>can pass in to the device as you construct it. For examples of that, see >>pyro/robot/player.py. > > So, I need to define a Sensor class as well? No, just a method that you can call in update(). In the above example, you could pass your robot object in to the device constructor, and then it would call the getReading from the robot. > It looks like all it needs to do (in this case) is provide a > getReading() function, which talks to my simulator (sockets, in this > case) and gives back the value. So far, so good. Right. >>After that, you can get the reading with: >> >>>>>robot.startDevice("TestDevice") >>>>>robot.testDevice.readingA >> > How do I teach the robot that it has this device? Is there a list of > devices somewhere that I need to add it to? There are a couple of things to add here, and I suggest you look at pyro/robot/player.py. Search for "Sonar" and "sonar" in that file and you will find: 1. The class PlayerSonarDevice. That shows some nice bits that are built into the Device class. Also, check out the SensorValue class. That allows things like: [(x.distance, x.angle) for x in robot.sensor.frontSensors] 2. Look in the PlayerRobot constructor to see the PlayerSonarDevice being loaded. 3. Check out the builtinDevices dictionary and startDeviceBuiltin method. Good luck, and let us know if you hit any snags; we will take this dialog and make a section in the Pyro Users Manual on how to do this, for future generations :) -Doug > Thanks! > > --Mac -- 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:08 2005 Subject: [Pyro-users] 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:35 2005 Subject: [Pyro-users] 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 w.richert at gmx.net Mon May 23 13:19:33 2005 From: w.richert at gmx.net (Willi Richert) Date: Mon May 23 13:19:44 2005 Subject: [Pyro-users] getPose Message-ID: <200505231919.33156.w.richert@gmx.net> Hi, sometimes I get suddenly strange values via the simulation interface. I have given every fiducial in my setting a name "x" line, with x denoting the fiducial's name, which I can access with x,y,th = self.robot.simulation.getPose("x") If I use setPose() on a robot I get sometimes for the subsequent getPose() errors like PlayerSimulationDevice: thr= 2.28156055572e-305 Exception in thread Thread-1: 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 477, in step BehaviorBasedBrain.step(self) File "/home/wr/forschung/software/ps/pyro/brain/behaviors/__init__.py", line 64, in step self.states[s].run() File "/home/wr/forschung/software/ps/pyro/brain/behaviors/fsm.py", line 116, in run b.update() # fires IF rules File "NeedBrain.py", line 152, in update x,y,th = self.robot.simulation.getPose(self.robot.robName) File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 85, in getPose raise "simulation.getPose() failed, result=",result simulation.getPose() failed, result=: -1 Sometimes I get no error, but the angle is set to -2147483648.0. Is that a PlayerStage error? I use some workaround code to free a stalled robot quickly, so I use setPose() to move it away, because I want to concentrate on other points in my simulation. Is using setPose()/getPose() not allowed for client code? Any hint appreciated, wr From dblank at brynmawr.edu Mon May 23 14:29:31 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Mon May 23 14:29:35 2005 Subject: [Pyro-users] getPose In-Reply-To: <200505231919.33156.w.richert@gmx.net> References: <200505231919.33156.w.richert@gmx.net> Message-ID: <4292210B.40003@brynmawr.edu> Willi, Simulation getPose and setPose is *supposed* to work from the client code. Could it be that you are getting/setting too fast, and the -1 really is some error code that says it isn't ready yet? Try wrapping the problem code in a try-except block and see if the value changes. That is, maybe it is a very large number for a short while, but then becomes the correct value. Can you tell if the problem occurs on the get or the set? -Doug Willi Richert wrote: > Hi, > > sometimes I get suddenly strange values via the simulation interface. I have > given every fiducial in my setting a > name "x" > line, with x denoting the fiducial's name, which I can access with > x,y,th = self.robot.simulation.getPose("x") > > If I use setPose() on a robot I get sometimes for the subsequent getPose() > errors like > > PlayerSimulationDevice: thr= 2.28156055572e-305 > Exception in thread Thread-1: > 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 477, in step > BehaviorBasedBrain.step(self) > File "/home/wr/forschung/software/ps/pyro/brain/behaviors/__init__.py", line > 64, in step > self.states[s].run() > File "/home/wr/forschung/software/ps/pyro/brain/behaviors/fsm.py", line 116, > in run > b.update() # fires IF rules > File "NeedBrain.py", line 152, in update > x,y,th = self.robot.simulation.getPose(self.robot.robName) > File "/home/wr/forschung/software/ps/pyro/robot/player.py", line 85, in > getPose > raise "simulation.getPose() failed, result=",result > simulation.getPose() failed, result=: -1 > > Sometimes I get no error, but the angle is set to -2147483648.0. > > Is that a PlayerStage error? I use some workaround code to free a stalled > robot quickly, so I use setPose() to move it away, because I want to > concentrate on other points in my simulation. Is using setPose()/getPose() > not allowed for client code? > > Any hint appreciated, > wr > _______________________________________________ > 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 w.richert at gmx.net Tue May 24 07:18:16 2005 From: w.richert at gmx.net (Willi Richert) Date: Tue May 24 07:18:30 2005 Subject: [Pyro-users] getPose In-Reply-To: <4292210B.40003@brynmawr.edu> References: <200505231919.33156.w.richert@gmx.net> <4292210B.40003@brynmawr.edu> Message-ID: <200505241318.16592.w.richert@gmx.net> Am Montag, 23. Mai 2005 20:29 schrieb Douglas S. Blank: > Willi, > > Simulation getPose and setPose is *supposed* to work from the client > code. Could it be that you are getting/setting too fast, and the -1 > really is some error code that says it isn't ready yet? > > Try wrapping the problem code in a try-except block and see if the value > changes. That is, maybe it is a very large number for a short while, but > then becomes the correct value. > > Can you tell if the problem occurs on the get or the set? I don't know if I understand what you mean. self.get("robot/simulation/data/") won't work, because PlayerSimulationDevice.getPose(self, name) expects the name to get the pose, whereas the base class PlayerDevice does not. I suggest to change preGet(self, kw) to preGet(self, *kw) so that varying arguments can be passed over to the specific Device. Then, I can specify the robot, of which I want the simulation pose. Just in case that's what you mean, I've attached the both files as tarbz2 since I cannot access the CVS today. It's just for clarifying - the code is quick and dirty. Regards, wr -------------- next part -------------- A non-text attachment was scrubbed... Name: player_device_simulation.tar.bz2 Type: application/x-tbz Size: 8651 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-users/attachments/20050524/c4557695/player_device_simulation.tar.bin From dblank at brynmawr.edu Tue May 24 09:24:43 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Tue May 24 09:24:51 2005 Subject: [Pyro-users] getPose In-Reply-To: <200505241318.16592.w.richert@gmx.net> References: <200505231919.33156.w.richert@gmx.net> <4292210B.40003@brynmawr.edu> <200505241318.16592.w.richert@gmx.net> Message-ID: <42932B1B.9000509@brynmawr.edu> Willi Richert wrote: > Am Montag, 23. Mai 2005 20:29 schrieb Douglas S. Blank: > >>Willi, >> >>Simulation getPose and setPose is *supposed* to work from the client >>code. Could it be that you are getting/setting too fast, and the -1 >>really is some error code that says it isn't ready yet? >> >>Try wrapping the problem code in a try-except block and see if the value >>changes. That is, maybe it is a very large number for a short while, but >>then becomes the correct value. >> >>Can you tell if the problem occurs on the get or the set? > > > I don't know if I understand what you mean. self.get("robot/simulation/data/") > won't work, because PlayerSimulationDevice.getPose(self, name) expects the > name to get the pose, whereas the base class PlayerDevice does not. > I suggest to change preGet(self, kw) to preGet(self, *kw) so that varying > arguments can be passed over to the specific Device. Then, I can specify the > robot, of which I want the simulation pose. Just in case that's what you > mean, I've attached the both files as tarbz2 since I cannot access the CVS > today. It's just for clarifying - the code is quick and dirty. I was asking if robot.simulation.getPose(x, y, t) or robot.simulation.setPose("name", x, y, t) caused the -1 problem. I see that you are using the robot.get(PATH) syntax, and that it didn't work for the simulation device, and we can fix that. Now two questions: 1. Does setting the pose or getting the pose cause the problem where you either get a -1, or some weird value? 2. Does the code you sent fix that problem, or is it just a fix for the robot.get(PATH) argument error? -Doug > Regards, > wr -- 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 11:38:47 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu May 26 11:38:52 2005 Subject: [Pyro-users] Re: Pyro Question In-Reply-To: <2f23434f4e1c7c130d6bdb6739344421@bowdoin.edu> References: <2f23434f4e1c7c130d6bdb6739344421@bowdoin.edu> Message-ID: <4295ED87.4050804@brynmawr.edu> Steve and Oliver, Hi!, I'm responding to this on the pyro-users mailing list. If you haven't joined yet, go here: http://emergent.brynmawr.edu/mailman/listinfo/pyro-users http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers Comments below. Stephen M. Majercik wrote: > Hi Doug -- > > Oliver Radwan, a student who's working with me this summer is trying to > get Pyro installed on a Mac. He's close, but not quite there -- > apparently some issues with TKinter. Do I remember correctly that > you've been able to get Pyro running on a Mac? If so, is there someone > Oliver could talk to about this? There's two parts to this: the Python part, and the extra bits. Python should run very easily. I think most people use fink to get Python and Tkinter. There are still a couple of places where we need to make our code be portable to Mac and Windows. Places like paths will be an issue for a couple more weeks. But, our intention is to have the core Python portion running on all major platforms in the next month. Once this is done, you would be able to run the Symbolic simulators (AI-based games) but no other simulators. You would be able to connect onto another computer or robot. The harder part are the extra bits, like vision, and the simulators. But, I just saw on the Player/Stage/Gazebo mailing list this week where someone had all of their tools running under the Mac. If this is true, then the simulations should work with Pyro. I'm not so certain about using our vision code on the Mac or Windows. See http://sourceforge.net/mailarchive/forum.php?thread_id=7275215&forum_id=8201 and other message in that forum. If others have info, please add. (If anyone is looking for a project, it would be nice to have a simple Python-based 2D simulation that used the Player/Stage interfaces. That would allow for a Python-only installation! Mac and Windows users could do some things right out-of-the-box. See the Symbolic simulator code for ideas.) -Doug > Thanks! > Steve > -- 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 29 11:18:20 2005 From: dblank at brynmawr.edu (dblank@brynmawr.edu) Date: Sun May 29 11:18:22 2005 Subject: [Pyro-users] New Pyro4 RPMs for Fedora Core 3 Message-ID: <52411.68.81.116.28.1117379900.squirrel@newwebmail.brynmawr.edu> Pyro users, If you have wrestled with attempting to install all of the extra programs that Pyro can use (like the Player/Stage/Gazebo programs, and their dependencies) you might like to know that we now have some RPMs ready for testing. This would allow you to install everything that you need for Pyro4 by doing this: rpm -ihv *.rpm Currently, we have RPMs for Fedore Core 3, which may work for other Linux systems running kernel 2.6 and gcc 3.4. If you would like packages for Debian, or some other format, please let us know. You can get these RPMs at: http://PyroRobotics.org/rpms/fc3 After you install those, you will need to get and make Pyro4: cvs -d :pserver:anonymous@bubo.brynmawr.edu:/cvs co -P pyrobot cd pyrobot make We're still working on Pyro4's installation, but we thought you might find these RPMs handy. If you find any issues, please let us know. Those interested in building packages for other systems should let me know, and I'll coordinate with you. -Doug From skk137 at psu.edu Mon May 30 18:54:11 2005 From: skk137 at psu.edu (Steve Keppeler) Date: Mon May 30 18:54:14 2005 Subject: [Pyro-users] Enabling Tkinter in Python2.4 Message-ID: <200505302254.j4UMsB220551@webmail13.cac.psu.edu> So basically I am trying to enable the Tkinter module. I read a couple guides online and they all said to edit the Python makefile to enable the module but when I do that and try to remake python the following happens: _______________________________________________________________ ./python: error while loading shared libraries: libtk8.3.so: cannot open shared object file: No such file or directory make: *** [sharedmods] Error 127 _____________________________________________________________ I did install libtk and libtcl just fine. Here is what Modules/Setup looks like: _______________________________________________________________ # *** Always uncomment this (leave the leading underscore in!): _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ # *** Uncomment and edit to reflect where your Tcl/Tk libraries are: -L/usr/local/lib \ # *** Uncomment and edit to reflect where your Tcl/Tk headers are: -I/usr/local/include \ # *** Uncomment and edit to reflect where your X11 header files are: -I/usr/X11R6/include \ # *** Or uncomment this for Solaris: # -I/usr/openwin/include \ # *** Uncomment and edit for Tix extension only: # -DWITH_TIX -ltix8.1.8.2 \ # *** Uncomment and edit for BLT extension only: # -DWITH_BLT -I/usr/local/blt/blt8.0-unoff/include -lBLT8.0 \ # *** Uncomment and edit for PIL (TkImaging) extension only: # (See [url]http://www.pythonware.com/products/pil/[/url] for more info) # -DWITH_PIL -I../Extensions/Imaging/libImaging tkImaging.c \ # *** Uncomment and edit for TOGL extension only: # -DWITH_TOGL togl.c \ # *** Uncomment and edit to reflect your Tcl/Tk versions: -ltk8.3 -ltcl8.3 \ # *** Uncomment and edit to reflect where your X11 libraries are: -L/usr/X11R6/lib \ # *** Or uncomment this for Solaris: # -L/usr/openwin/lib \ # *** Uncomment these for TOGL extension only: # -lGL -lGLU -lXext -lXmu \ # *** Uncomment for AIX: # -lld \ # *** Always uncomment this; X11 libraries to link with: -lX11 _____________________________________________________________ And yes, the .so files are in the /usr/local/lib directory: _____________________________________________________________ [root@localhost lib]# cd /usr/local/lib;ls libtcl8.3.so libtclstub8.4.a libtkstub8.3.a tcl8.3 tk8.3 libtcl8.4.so libtk8.3.so libtkstub8.4.a tcl8.4 tk8.4 libtclstub8.3.a libtk8.4.so python2.4 tclConfig.sh tkConfig.sh __________________________________________________________________ The locations of the headers and libraries are right as far as I know, I am missing something glaringly obvious here or do I need to do something else? From dblank at mainline.brynmawr.edu Mon May 30 20:44:20 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Mon May 30 20:44:22 2005 Subject: [Pyro-users] Enabling Tkinter in Python2.4 In-Reply-To: <200505302254.j4UMsB220551@webmail13.cac.psu.edu> Message-ID: Steve, On most Unix/Linux systems, Python and Tkinter come already installed, or very easy to install. For example, you can often install Python and Tkinter from rpms or deb packages. If you are trying to build from sources, you can usually just: configure make install as root for each. Usually, you don't have to edit anything. Unfortunately, this is beyond the scope of this list. -Doug Steve Keppeler said: > So basically I am trying to enable the Tkinter module. I read a couple guides > online and they all said to edit the Python makefile to enable the module but > when I do that and try to remake python the following happens: > _______________________________________________________________ > ./python: error while loading shared libraries: libtk8.3.so: cannot open shared > object file: No such file or directory > make: *** [sharedmods] Error 127 > _____________________________________________________________ > > I did install libtk and libtcl just fine. Here is what Modules/Setup looks > like: > _______________________________________________________________ > # *** Always uncomment this (leave the leading underscore in!): > _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ > # *** Uncomment and edit to reflect where your Tcl/Tk libraries are: > -L/usr/local/lib \ > # *** Uncomment and edit to reflect where your Tcl/Tk headers are: > -I/usr/local/include \ > # *** Uncomment and edit to reflect where your X11 header files are: > -I/usr/X11R6/include \ > # *** Or uncomment this for Solaris: > # -I/usr/openwin/include \ > # *** Uncomment and edit for Tix extension only: > # -DWITH_TIX -ltix8.1.8.2 \ > # *** Uncomment and edit for BLT extension only: > # -DWITH_BLT -I/usr/local/blt/blt8.0-unoff/include -lBLT8.0 \ > # *** Uncomment and edit for PIL (TkImaging) extension only: > # (See [url]http://www.pythonware.com/products/pil/[/url] for more info) > # -DWITH_PIL -I../Extensions/Imaging/libImaging tkImaging.c \ > # *** Uncomment and edit for TOGL extension only: > # -DWITH_TOGL togl.c \ > # *** Uncomment and edit to reflect your Tcl/Tk versions: > -ltk8.3 -ltcl8.3 \ > # *** Uncomment and edit to reflect where your X11 libraries are: > -L/usr/X11R6/lib \ > # *** Or uncomment this for Solaris: > # -L/usr/openwin/lib \ > # *** Uncomment these for TOGL extension only: > # -lGL -lGLU -lXext -lXmu \ > # *** Uncomment for AIX: > # -lld \ > # *** Always uncomment this; X11 libraries to link with: > -lX11 > _____________________________________________________________ > > And yes, the .so files are in the /usr/local/lib directory: > _____________________________________________________________ > [root@localhost lib]# cd /usr/local/lib;ls > libtcl8.3.so libtclstub8.4.a libtkstub8.3.a tcl8.3 tk8.3 > libtcl8.4.so libtk8.3.so libtkstub8.4.a tcl8.4 tk8.4 > libtclstub8.3.a libtk8.4.so python2.4 tclConfig.sh tkConfig.sh > __________________________________________________________________ > > The locations of the headers and libraries are right as far as I know, I am > missing something glaringly obvious here or do I need to do something else? > > _______________________________________________ > Pyro-users mailing list > Pyro-users@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > -- From mac at cs.hmc.edu Tue May 31 15:06:01 2005 From: mac at cs.hmc.edu (Mac Mason) Date: Tue May 31 15:06:10 2005 Subject: [Pyro-users] Documentation on implementing a Robot class? In-Reply-To: <428F404C.6080704@brynmawr.edu> References: <20050520204630.GB14081@turing.cs.hmc.edu> <428E5BA6.90606@brynmawr.edu> <20050521044418.GA16010@turing.cs.hmc.edu> <428F404C.6080704@brynmawr.edu> Message-ID: <20050531190555.GA5608@turing.cs.hmc.edu> On Sat, May 21, 2005 at 10:06:04AM -0400, Douglas S. Blank wrote: > After that, you can get the reading with: > > >>>robot.startDevice("TestDevice") > >>>robot.testDevice.readingA > I feel like I'm getting close, but this still doesn't quite work. I've got a TestDevice class: class TestDevice(Device): def __init__(self, robot): Device.__init__(self, "TestDevice") self.robot = robot def update(self): self.devData["TestDeviceReading"] = self.robot.getReading() getReading() handles all the talking to my simulator and whatnot. In addition, my Robot's __init__ contains the following two lines: self.devData["builtinDevices"] = ["TestDevice"] self.startDevice("TestDevice") And the Robot has the following function: def startDeviceBuiltin(self, item): if item == "TestDevice": return {"TestDevice" : TestDevice(self)} else: # Complain... So, the robot starts up fine, and the startDevice() call runs just fine (and a TestDevice gets constructed, according to print statements added to its __init__) But I'm still unclear on how to actually get information through the device interface; I can't figure out where the TestDevice got stored, so I can't poke it to figure out what it has learned... Thanks! --Mac -- Julian "Mac" Mason mac@cs.hmc.edu Computer Science '06 (310)-882-8068 Harvey Mudd College -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-users/attachments/20050531/714dc1e0/attachment.bin From dblank at mainline.brynmawr.edu Tue May 31 23:06:52 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Tue May 31 23:06:55 2005 Subject: [Pyro-users] Documentation on implementing a Robot class? In-Reply-To: <20050531190555.GA5608@turing.cs.hmc.edu> References: <20050520204630.GB14081@turing.cs.hmc.edu> <428E5BA6.90606@brynmawr.edu> <20050521044418.GA16010@turing.cs.hmc.edu> <428F404C.6080704@brynmawr.edu>, <428F404C.6080704@brynmawr.edu> Message-ID: Mac Mason said: > On Sat, May 21, 2005 at 10:06:04AM -0400, Douglas S. Blank wrote: > > After that, you can get the reading with: > >=20 > > >>>robot.startDevice("TestDevice") > > >>>robot.testDevice.readingA > >=20 > > I feel like I'm getting close, but this still doesn't quite work. > > I've got a TestDevice class: > > class TestDevice(Device): > def __init__(self, robot): > Device.__init__(self, "TestDevice") > self.robot =3D robot > > def update(self): > self.devData["TestDeviceReading"] =3D self.robot.getReading() > > getReading() handles all the talking to my simulator and whatnot. > > In addition, my Robot's __init__ contains the following two lines: > > self.devData["builtinDevices"] =3D ["TestDevice"] > self.startDevice("TestDevice") > > And the Robot has the following function: > > def startDeviceBuiltin(self, item): > if item =3D=3D "TestDevice": > return {"TestDevice" : TestDevice(self)} > else: > # Complain... > > So, the robot starts up fine, and the startDevice() call runs just fine > (and a TestDevice gets constructed, according to print statements added > to its __init__) > > But I'm still unclear on how to actually get information through the > device interface; I can't figure out where the TestDevice got stored, so > I can't poke it to figure out what it has learned... Mac, You should be able to refer to it a couple of ways. If you want the object, use: robot.TestDevice or robot.get("robot/TestDevice") That will return an object that you can then tack on the method or property name: robot.TestDevice.TestDeviceReading or robot.get("robot/TestDevice/TestDeviceReading") There is some magic in the robot and device code to make the above work. In retrospect, we should have just made the TestDeviceReading a property of the object and TestDevice a property of robot, but we had an idea that got out of control. Maybe in Pyro4 we can get rid of the devData dictionary business both in the robot and in the device... An aside: your examples breaks a couple of conventions in Pyro. Usually, the name returned in the startDeviceBuiltin is an general interface (like "camera", "position", "gripper", etc.) It is hoped not to have too many of these, and that any new ones will be generic and reuseable. Also, they are all lowercase names. We generally save upper case names for classes. Hope that helps, -Doug > > Thanks! > > --Mac > > --=20 > Julian "Mac" Mason mac@cs.hmc.edu > Computer Science '06 (310)-882-8068 > Harvey Mudd College > > --PEIAKu/WMn1b1Hv9 > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (SunOS) > > iD8DBQFCnLWT1AphoTGXiN0RAsnQAJsFTLuLpjSyNmdS4sKkNvJxwHS4igCcDlsH > RN4695xuFgrOtVgM+EhcBsQ= > =vYCe > -----END PGP SIGNATURE----- > > --PEIAKu/WMn1b1Hv9-- > --