From matthew2.studley at uwe.ac.uk Fri Feb 1 07:01:08 2008 From: matthew2.studley at uwe.ac.uk (Matthew Studley) Date: Fri Feb 1 07:02:06 2008 Subject: [Pyro-users] pyrobot simulator : 'invisible objects' Message-ID: <1201867268.6964.9.camel@titanium.clocksoft.dom> Hi I'm only just starting to get acquainted with pyrobot. I want to draw items in the simulator that are not visible to the existing robot sensors. Could you point me at the appropriate part of the API please? regards Matt -- ================================== Dr Matthew Studley Lecturer : Robotics Bristol Robotics Laboratory Room 3Q75 University of the West of England Coldharbour Lane Bristol BS16 1QY +44 (0)117 968 2671 From dblank at brynmawr.edu Fri Feb 1 10:21:21 2008 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri Feb 1 10:21:28 2008 Subject: [Pyro-users] pyrobot simulator : 'invisible objects' In-Reply-To: <1201867268.6964.9.camel@titanium.clocksoft.dom> References: <1201867268.6964.9.camel@titanium.clocksoft.dom> Message-ID: <35531.71.59.123.159.1201879281.squirrel@webmail.brynmawr.edu> On Fri, February 1, 2008 7:01 am, Matthew Studley said: > Hi > > I'm only just starting to get acquainted with pyrobot. > > I want to draw items in the simulator that are not visible to the > existing robot sensors. Could you point me at the appropriate part of > the API please? Matt, If you want to add invisible objects to the Python-based simulator that comes with pyro, then take a look at pyrobot/simulators/pysim.py If you just want to add decorative things in the world, then you could create a list of items that get drawn and scaled, but don't interact with sensors. Someone could refactor the pysim program into objects that have properties (like "visible"). Currently, items are kept in a list of line segments for speed reasons. -Doug > regards > > Matt > > > -- > ================================== > Dr Matthew Studley > Lecturer : Robotics > Bristol Robotics Laboratory > > Room 3Q75 > University of the West of England > Coldharbour Lane > Bristol BS16 1QY > > +44 (0)117 968 2671 > _______________________________________________ > Pyro-users mailing list > Pyro-users@pyrorobotics.org > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 From mightor at gmail.com Thu Feb 7 15:47:04 2008 From: mightor at gmail.com (Xander Soldaat) Date: Thu Feb 7 15:47:13 2008 Subject: [Pyro-users] Circular room Message-ID: <36fd1e2b0802071247ub0bd1d8nec7be855cf2e48f9@mail.gmail.com> Hi there, I'm using the 2D TkSimulator together with a Pioneer robot for my virtual robot project. I am trying to create a circular room, rather than the standard box shaped one. I tried using just sim.drawOval(0,0, 4,4), but that doesn't seem to work the same as a bounding box. I have also tried using drawOval() after calling addBox() with the same dimensions. The canvas does show a perfect circle that fits exactly inside the box, but it totally ignores the circle. My question is how do I create a circular bounding area with the same properties as the sim.addBox() function? Thanks, Xander -- | mail: mailto:mightor@gmail.com | | What the world needs is more geniuses | with humility, there are so few of us left. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emergent.brynmawr.edu/pipermail/pyro-users/attachments/20080207/04343278/attachment.htm From dblank at brynmawr.edu Fri Feb 8 15:33:57 2008 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri Feb 8 15:34:07 2008 Subject: [Pyro-users] Circular room In-Reply-To: <36fd1e2b0802071247ub0bd1d8nec7be855cf2e48f9@mail.gmail.com> References: <36fd1e2b0802071247ub0bd1d8nec7be855cf2e48f9@mail.gmail.com> Message-ID: <47ACBCB5.4030305@brynmawr.edu> Xander Soldaat wrote: > Hi there, > > I'm using the 2D TkSimulator together with a Pioneer robot for my > virtual robot project. I am trying to create a circular room, rather > than the standard box shaped one. I tried using just sim.drawOval(0,0, > 4,4), but that doesn't seem to work the same as a bounding box. I have > also tried using drawOval() after calling addBox() with the same > dimensions. The canvas does show a perfect circle that fits exactly > inside the box, but it totally ignores the circle. > > My question is how do I create a circular bounding area with the same > properties as the sim.addBox() function? Xander, You're right that there are two lists in the Python simulator: wall segments (sim.world) and other decorations that are drawn but don't interact with the sensors (sim.shapes). If you want to draw a round room (or any other shape) you need to construct the walls out of segments (eg, straight lines). Here is a world that draws a robot in a round room using geometry to rotate the segments, and offset them to a center of (2, 2): from pyrobot.simulators.pysim import * import math def INIT(): # (width, height), (offset x, offset y), scale: sim = TkSimulator((357,486), (38,397), 57.838547) # x1, y1, x2, y2 in meters: x, y = 2, 2 # center of circle length = 1.0 # length of segment parts = 20 # number of sides, larger = more circular ds = (math.pi * 2)/parts for i in range(0, 360, 360/parts): d = i * math.pi/180 x1, y1 = x + math.cos(d) * length, y + math.sin(d) * length x2, y2 = x + math.cos(d + ds) * length, y + math.sin(d + ds) * length sim.addWall(x1, y1, x2, y2) # port, name, x, y, th, bounding Xs, bounding Ys, color # (optional TK color name): sim.addRobot(60000, TkPioneer("RedPioneer", 2.0, 2.0, 6.28, ((.225, .225, -.225, -.225), (.175, -.175, -.175, .175)), "red")) # add some sensors: sim.robots[0].addDevice(Pioneer16Sonars()) return sim Hope that helps, -Doug > Thanks, > Xander > > -- > | mail: mailto:mightor@gmail.com > | > | What the world needs is more geniuses > | with humility, there are so few of us left. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pyro-users mailing list > Pyro-users@pyrorobotics.org > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users From mightor at gmail.com Sun Feb 10 03:14:30 2008 From: mightor at gmail.com (Xander Soldaat) Date: Sun Feb 10 03:14:39 2008 Subject: [Pyro-users] Circular room In-Reply-To: <47ACBCB5.4030305@brynmawr.edu> References: <36fd1e2b0802071247ub0bd1d8nec7be855cf2e48f9@mail.gmail.com> <47ACBCB5.4030305@brynmawr.edu> Message-ID: <36fd1e2b0802100014w5bb18c61h32195daafa3b05ea@mail.gmail.com> Douglas, Thanks a lot for this solution, it looks very circular indeed! The only thing left for me to do is adjust the scale somewhat and I'll be sorted. It never occurred to me to use a mathematical approach like this. Thanks again! Xander On Feb 8, 2008 9:33 PM, Douglas S. Blank wrote: > Xander Soldaat wrote: > > Hi there, > > > > I'm using the 2D TkSimulator together with a Pioneer robot for my > > virtual robot project. I am trying to create a circular room, rather > > than the standard box shaped one. I tried using just sim.drawOval(0,0, > > 4,4), but that doesn't seem to work the same as a bounding box. I have > > also tried using drawOval() after calling addBox() with the same > > dimensions. The canvas does show a perfect circle that fits exactly > > inside the box, but it totally ignores the circle. > > > > My question is how do I create a circular bounding area with the same > > properties as the sim.addBox() function? > > Xander, > > You're right that there are two lists in the Python simulator: wall > segments (sim.world) and other decorations that are drawn but don't > interact with the sensors (sim.shapes). > > If you want to draw a round room (or any other shape) you need to > construct the walls out of segments (eg, straight lines). Here is a > world that draws a robot in a round room using geometry to rotate the > segments, and offset them to a center of (2, 2): > > from pyrobot.simulators.pysim import * > import math > def INIT(): > # (width, height), (offset x, offset y), scale: > sim = TkSimulator((357,486), (38,397), 57.838547) > # x1, y1, x2, y2 in meters: > x, y = 2, 2 # center of circle > length = 1.0 # length of segment > parts = 20 # number of sides, larger = more circular > ds = (math.pi * 2)/parts > for i in range(0, 360, 360/parts): > d = i * math.pi/180 > x1, y1 = x + math.cos(d) * length, y + math.sin(d) * length > x2, y2 = x + math.cos(d + ds) * length, y + math.sin(d + ds) * > length > sim.addWall(x1, y1, x2, y2) > > # port, name, x, y, th, bounding Xs, bounding Ys, color > # (optional TK color name): > sim.addRobot(60000, TkPioneer("RedPioneer", > 2.0, 2.0, 6.28, > ((.225, .225, -.225, -.225), > (.175, -.175, -.175, .175)), > "red")) > # add some sensors: > sim.robots[0].addDevice(Pioneer16Sonars()) > return sim > > Hope that helps, > > -Doug > > > Thanks, > > Xander > > > > -- > > | mail: mailto:mightor@gmail.com > > | > > | What the world needs is more geniuses > > | with humility, there are so few of us left. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Pyro-users mailing list > > Pyro-users@pyrorobotics.org > > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > > -- | mail: mailto:mightor@gmail.com | | What the world needs is more geniuses | with humility, there are so few of us left. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emergent.brynmawr.edu/pipermail/pyro-users/attachments/20080210/6da36f34/attachment.htm From swaffoj at allegheny.edu Mon Feb 11 22:05:41 2008 From: swaffoj at allegheny.edu (John Mark Swafford) Date: Mon Feb 11 22:05:53 2008 Subject: [Pyro-users] Inconsistent Results Message-ID: <47B10D05.8080207@allegheny.edu> Dear All, I have been running a series of experiments where I am calling pyrobot from within another python program. I am working with grammatical evolution (an evolutionary algorithm that evolves executable code from a grammar). When the code I am evolving is executed from within another python program, it should solve a maze and return a fitness. According to my results, the code I am generating does not solve the maze and does not have a good fitness. My problem lies in that when I use the same generated code in the pyrobot GUI, it does in fact solve the maze and should return a high fitness. I copied my fitness function, just the robot's geographical distance from the end of the maze divided by the total distance between the starting point and the finish, so that it is the same in both the python executed code and the GUI executed code. Can anyone suggest a reason as to why this is happening? Kind Regards, John Mark S. From dblank at brynmawr.edu Mon Feb 11 22:34:59 2008 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Mon Feb 11 22:35:06 2008 Subject: [Pyro-users] Inconsistent Results In-Reply-To: <47B10D05.8080207@allegheny.edu> References: <47B10D05.8080207@allegheny.edu> Message-ID: <50927.71.59.123.159.1202787299.squirrel@webmail.brynmawr.edu> On Mon, February 11, 2008 10:05 pm, John Mark Swafford said: > Dear All, > > I have been running a series of experiments where I am calling > pyrobot from within another python program. I am working with > grammatical evolution (an evolutionary algorithm that evolves executable > code from a grammar). When the code I am evolving is executed from > within another python program, it should solve a maze and return a > fitness. According to my results, the code I am generating does not > solve the maze and does not have a good fitness. My problem lies in that > when I use the same generated code in the pyrobot GUI, it does in fact > solve the maze and should return a high fitness. I copied my fitness > function, just the robot's geographical distance from the end of the > maze divided by the total distance between the starting point and the > finish, so that it is the same in both the python executed code and the > GUI executed code. Can anyone suggest a reason as to why this is > happening? Differences in timing could result from things like socket communication and other "real" sources of randomness. There are generally two options: 1) try to evolve code that is resistant to such timing differences and is robust to transference to slightly different contexts. You could try to accomplish this by adding randomness. 2) make your code run exactly the same when testing and evolving, ie get rid of any source of "real" randomness (don't use sockets). If you test exactly in the same manner as you evolve, you should be fine. To diagnose this further, I'd have to see how you are evolving and testing. -Doug > Kind Regards, > John Mark S. > > _______________________________________________ > Pyro-users mailing list > Pyro-users@pyrorobotics.org > http://emergent.brynmawr.edu/mailman/listinfo/pyro-users > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501