From stefie10 at alum.mit.edu Thu Apr 7 16:29:19 2005 From: stefie10 at alum.mit.edu (Stefanie Tellex) Date: Thu Apr 7 16:20:26 2005 Subject: [Pyro-developers] pyro with player/gazebo Message-ID: <1112905759.16699.7.camel@mearas.media.mit.edu> Hello, I was playing around with pyro on player/gazebo using a pioneer 2 with a laser range sensor. I had some trouble getting the BBWander brain to work. The attached patch fixes the problems I was having, although probably not correctly. First, state1.setup was getting called twice in BBWander.py, and it didn't like that, so I added an initialization flag so it ignores the second call. Second, BBWander was accessing the "thr" component of the range scanner, which does not appear to exist. I added an implementation for "th" and "thr" in player.py. It now drives around and avoid walls, although the robot's motion is pretty jerky. Is there a way to make it drive more smoothly? The patch is against CVS pyro, and I'm using player 1.6.2 (not CVS). Thanks, Stefanie -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 1125 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-developers/attachments/20050407/1105050a/patch.bin From dblank at brynmawr.edu Thu Apr 7 21:54:56 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Apr 7 21:46:03 2005 Subject: [Pyro-developers] pyro with player/gazebo In-Reply-To: <1112905759.16699.7.camel@mearas.media.mit.edu> References: <1112905759.16699.7.camel@mearas.media.mit.edu> Message-ID: <4255E470.5060709@brynmawr.edu> Stefanie, Thanks! The code for the laser angle (theta) in radians (thr) was indeed missing. The setup problem was actually caused by a reorg in the Finite State Machine code pyro/brain/behavior/fsm.py. We had thought about collapsing onActivate() with setup() but I'm retracting those changes so that they will be distinct again. (Anyone have a better name than onActivate?) Both of these fixes are now in CVS. The jittering was an artifact of the fact that you can (apparently) only set translate and rotate velocities at the same time in Player. The interface hadn't yet been written in Pyro that allows only one to be set at a time. That has been fixed in CVS as well. BBWander now behaves as it should. I've tested it with laser and sonar. To test with sonar, you will need to add the following lines to /usr/share/player/config/gazebo.cfg: driver ( name "gz_sonar" provides ["sonar:0"] gz_id "robot1" ) Also, most brains use the general "range" name to refer to the default distance sensor (sonar, if you have one; laser after that, if you have one). To dynamically switch the default range sensor on the fly, do this: robot.devDataFunc = robot.sonar or robot.devDataFunc = robot.laser (I'd like to do away with the robot.devData and robot.devDataFunc. Originally they were there so that sensor names would conflict with properties of robot. Now, we refer to robot.laser anyway (through the magic of __getattr__) so we should abandon the overly complicated devData. That would allow ipython to work out of the box too.) Thanks again! -Doug Stefanie Tellex wrote: > Hello, > > I was playing around with pyro on player/gazebo using a pioneer 2 with a > laser range sensor. I had some trouble getting the BBWander brain to > work. The attached patch fixes the problems I was having, although > probably not correctly. > > First, state1.setup was getting called twice in BBWander.py, and it > didn't like that, so I added an initialization flag so it ignores the > second call. > > Second, BBWander was accessing the "thr" component of the range scanner, > which does not appear to exist. I added an implementation for "th" and > "thr" in player.py. > > It now drives around and avoid walls, although the robot's motion is > pretty jerky. Is there a way to make it drive more smoothly? > > The patch is against CVS pyro, and I'm using player 1.6.2 (not CVS). > > Thanks, > > Stefanie > > > ------------------------------------------------------------------------ > > Index: plugins/brains/BBWander.py > =================================================================== > RCS file: /cvs/pyro/plugins/brains/BBWander.py,v > retrieving revision 1.29 > diff -r1.29 BBWander.py > 44a45,48 > >> def __init__(self): >> State.__init__(self) >> self.initialized = False >> > > 46a51,52 > >> if (self.initialized): >> return > > 48a55 > >> self.initialized = True > > 50,51c57,58 > < if min(self.get("/robot/range/front-all/value")) < 1: > < self.goto("TurnAround") > --- > >> pass >> > > Index: robot/player.py > =================================================================== > RCS file: /cvs/pyro/robot/player.py,v > retrieving revision 1.60 > diff -r1.60 player.py > 214c214,216 > < self.subDataFunc['th'] = lambda pos: self.client.laser[0][0][0] + (self.client.laser[0][0][2] * pos) # in degrees > --- > >># self.subDataFunc['th'] = lambda pos: self.client.laser[0][0][0] + (self.client.laser[0][0][2] * pos) # in degrees >> self.subDataFunc['th'] = lambda pos: pos >> self.subDataFunc['thr'] = lambda pos: pos * math.pi / 180.0 >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Pyro-developers mailing list >>Pyro-developers@emergent.brynmawr.edu >>http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers -- Douglas S. Blank, Assistant Professor dblank@brynmawr.edu, (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From dblank at brynmawr.edu Fri Apr 8 10:42:58 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri Apr 8 10:34:01 2005 Subject: [Pyro-developers] pyro with player/gazebo In-Reply-To: <4255E470.5060709@brynmawr.edu> References: <1112905759.16699.7.camel@mearas.media.mit.edu> <4255E470.5060709@brynmawr.edu> Message-ID: <42569872.5040207@brynmawr.edu> A couple of corrections: > robot.devDataFunc = robot.sonar > > or > > robot.devDataFunc = robot.laser Should be: robot.devDataFunc["range"] = robot.sonar or robot.devDataFunc["range"] = robot.laser Also: > (I'd like to do away with the robot.devData and robot.devDataFunc. > Originally they were there so that sensor names would conflict with > properties of robot. Now, we refer to robot.laser anyway (through the > magic of __getattr__) so we should abandon the overly complicated > devData. That would allow ipython to work out of the box too.) Should be: (I'd like to do away with the robot.devData and robot.devDataFunc. Originally they were there so that sensor names would NOT conflict with properties of robot. Now, we refer to robot.laser anyway (through the magic of __getattr__) so we should abandon the overly complicated devData. That would allow ipython to work out of the box too.) -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 stefie10 at alum.mit.edu Sun Apr 10 12:50:24 2005 From: stefie10 at alum.mit.edu (Stefanie Tellex) Date: Sun Apr 10 12:41:14 2005 Subject: [Pyro-developers] opening extra devices with player Message-ID: <1113151824.1204.19.camel@mearas.media.mit.edu> Hello, Thanks for your help on my earlier question. I needed to open an additional position device via the player interface to use the player lodo driver. The attached patch adds a method to the PlayerRobot class that opens additional devices. I've only tested it on two position devices so far but it seems to work. I also tried to fix a bug, although I'm not sure I fixed it correctly. When I called robot.get("devices/position1/data"), I got an attribute error about "scan". There was no stack trace, so I modified gui/__init__.py to see one. Then, I traced the error to robot/player.py in getDeviceData (line 55). I don't know what it is supposed to return, but I changed it to return getPose, since that works for position. Since PlayerDevice isn't specific to position, I'm not sure that is the right thing. It did get rid of the exception, and it's now clear how to read data from the position interfaces. Hope this is useful. Stefanie -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 2219 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-developers/attachments/20050410/2b06471d/patch.bin From stefie10 at alum.mit.edu Sun Apr 10 14:40:33 2005 From: stefie10 at alum.mit.edu (Stefanie Tellex) Date: Sun Apr 10 14:31:23 2005 Subject: [Pyro-developers] map module Message-ID: <1113158433.2199.4.camel@mearas.media.mit.edu> Hello, I ran into the Tkinter "main thread is not in main loop" problem described here: http://mail.python.org/pipermail/tkinter-discuss/2005-February/000312.html while trying to use the map building module. I got around it by adding a "redraw" method to the brain and putting the redraw callbacks there instead of in the step method. I have attached the fixed map.py for possible inclusion on the web site. (The original code is on this page: http://emergent.brynmawr.edu/pyro/?page=PyroModuleMapping). Hope this helps. Stefanie From dblank at mainline.brynmawr.edu Sun Apr 10 17:45:11 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Sun Apr 10 17:39:20 2005 Subject: [Pyro-developers] opening extra devices with player In-Reply-To: <1113151824.1204.19.camel@mearas.media.mit.edu> Message-ID: Thanks, Stephanie. I have applied your patch to the CVS version of Pyro. I was wondering how to handle Player/Stage's index, and I like your solution (ie, the user will handle it). I think your solution with the base PlayerDevice is fine. And thank you for fixing the bug in the gui not being able to report the error--- that always bothered me, and I wasn't sure what the fix was. -Doug Stefanie Tellex said: > Hello, > > Thanks for your help on my earlier question. > > I needed to open an additional position device via the player interface > to use the player lodo driver. The attached patch adds a method to the > PlayerRobot class that opens additional devices. I've only tested it on > two position devices so far but it seems to work. > > I also tried to fix a bug, although I'm not sure I fixed it correctly. > When I called robot.get("devices/position1/data"), I got an attribute > error about "scan". There was no stack trace, so I modified > gui/__init__.py to see one. > > Then, I traced the error to robot/player.py in getDeviceData (line 55). > I don't know what it is supposed to return, but I changed it to return > getPose, since that works for position. Since PlayerDevice isn't > specific to position, I'm not sure that is the right thing. It did get > rid of the exception, and it's now clear how to read data from the > position interfaces. > > Hope this is useful. > > Stefanie > -- From stefie10 at alum.mit.edu Fri Apr 15 16:10:49 2005 From: stefie10 at alum.mit.edu (Stefanie Tellex) Date: Fri Apr 15 16:01:13 2005 Subject: [Pyro-developers] rotating the map Message-ID: <1113595849.31369.1.camel@mearas.media.mit.edu> Hi, I reworked the lps redraw method so that the map is oriented vertically instead of horizontally. That makes a lot more sense to me because then it aligns with the camara image in Gazebo - you can see that the occupancy grid is right much more easily. I've attached a patch for this. It just unilaterally changes the orientation. It could easily be changed to an option, if people care. Stefanie -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 820 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-developers/attachments/20050415/26b4ee31/patch.bin From stefie10 at alum.mit.edu Fri Apr 15 16:43:03 2005 From: stefie10 at alum.mit.edu (Stefanie Tellex) Date: Fri Apr 15 16:39:06 2005 Subject: [Pyro-developers] rotating the map In-Reply-To: <1113595849.31369.1.camel@mearas.media.mit.edu> References: <1113595849.31369.1.camel@mearas.media.mit.edu> Message-ID: <1113597783.31959.1.camel@mearas.media.mit.edu> Hi, I forgot to rotate the robot. Here's an updated patch with a rotated robot. (This patch supersedes the last one.) Stefanie On Fri, 2005-04-15 at 16:10, Stefanie Tellex wrote: > Hi, > > I reworked the lps redraw method so that the map is oriented vertically > instead of horizontally. That makes a lot more sense to me because then > it aligns with the camara image in Gazebo - you can see that the > occupancy grid is right much more easily. > > I've attached a patch for this. It just unilaterally changes the > orientation. It could easily be changed to an option, if people care. > > Stefanie > > ______________________________________________________________________ > _______________________________________________ > Pyro-developers mailing list > Pyro-developers@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 1234 bytes Desc: not available Url : http://emergent.brynmawr.edu/pipermail/pyro-developers/attachments/20050415/8911517f/patch.bin From chil0060 at umn.edu Tue Apr 26 00:05:32 2005 From: chil0060 at umn.edu (John Chilton) Date: Tue Apr 26 08:57:19 2005 Subject: [Pyro-developers] Pyro/AIBO/Tekkotsu 1.4 Issue Message-ID: <426DBE0C.90009@umn.edu> I was having issues connecting to an AIBO with the latest version of Pyro and Tekkotsu. I posted about this, and someone suggested that maybe Tekkotsu started using UDP for its camera data and Pyro wasn't configured for this. This turned out to be the case. The post included the following two suggestions for fixing the problem. ----------------- 1. Change Tekkotsu so that it will use TCP. Edit tekkotsu/project/ms/config/tekkotsu.cfg so: rawcam_transport=tcp rle_transport=tcp and run make update from the tekkotsu directory. or you might try: 2. Change Pyro so that it uses UDP on the camera socket. You can do that by changing pyro/plugins/devices/AiboCamera.py to return: return {"camera": AiboCamera(robot, visionSystem = VisionSystem(), tcp = 0)} ------------- I tried suggestion 1 and it worked fine, then I undid the change and tried suggestion 2. It did not work. Just thought I would let you know. Thanks everyone for the great software. -John Chilton