From gsakkis at rutgers.edu Tue Feb 1 11:10:48 2005 From: gsakkis at rutgers.edu (George Sakkis) Date: Tue Feb 1 11:06:55 2005 Subject: [Pyro-developers] Installation on cygwin Message-ID: <013201c50878$9a6b05d0$ad03a8c0@charisteas> Greetings everyone, I just downloaded Pyro and I'm looking forward to start using it, and potentially contributing to it as part of my master's thesis. So far I have failed to install it out-of-the-box just by following the instructions on http://emergent.brynmawr.edu/pyro/?page=PyroInstallation; I guess the main reason is that I'm trying to build it on cygwin but apparently the makefiles are intended for Linux (or maybe just RedHat). Next thing I tried was the standard distutils 'python setup.py build' but the current setup.py is obviously outdated; for one thing, a bunch of directories mentioned there do not exist in the latest tarball. I'm wondering if anyone has a setup.py that works for the current version (3.4.3) before I start fiddling with it myself. George From dblank at brynmawr.edu Wed Feb 2 11:46:18 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Wed Feb 2 11:42:30 2005 Subject: [Pyro-developers] Installation on cygwin In-Reply-To: <013201c50878$9a6b05d0$ad03a8c0@charisteas> References: <013201c50878$9a6b05d0$ad03a8c0@charisteas> Message-ID: <420103DA.1030109@brynmawr.edu> George, Welcome aboard! First, Pyro has run under Windows (natively) with some minor changes. But those changes haven't been incorporated into the main version yet. (Little things like paths need to be made cross-platform). The only reason you would want to go as far as running it under cygwin would be to try to get all of the functionality of the the third-party simulators and tools (such as Player/Stage, and Khepera simulator). But that is unlikely to be very satisfying, and would work much better under Linux. You can run the main Pyro Python code under Windows to connect onto robots, such as the Aibo, or Player running on a Pioneer3, for example. But you may not have a real robot. The ideal solution would be to have a cross-platform simulator which you could connect Pyro onto. The Robocup simulator should work. There are also some pure-Python symbolic simulators that come with Pyro for playing games like chess, checkers, etc. Those should work under Windows, I think, but I haven't tried them yet. Some parts (like the vision subsystem) are written in C++ and rely on shared memory. I have no idea if that will work under Windows. In general, a Mac OS X port should work better and more easily. Finally, the setup.py is just a stub that someone contributed to help us get that method of installation working. So, the makefile is the only method that I know that works currently. In short, if you don't have a robot, running Pyro under Linux or Mac OS X will be a lot more fun and productive. But you will be able to do somethings under Windows. Let us know if you have any questions, and we welcome contributions! -Doug George Sakkis wrote: > Greetings everyone, > > I just downloaded Pyro and I'm looking forward to start using it, and potentially contributing to it > as part of my master's thesis. So far I have failed to install it out-of-the-box just by following > the instructions on http://emergent.brynmawr.edu/pyro/?page=PyroInstallation; I guess the main > reason is that I'm trying to build it on cygwin but apparently the makefiles are intended for Linux > (or maybe just RedHat). Next thing I tried was the standard distutils 'python setup.py build' but > the current setup.py is obviously outdated; for one thing, a bunch of directories mentioned there do > not exist in the latest tarball. I'm wondering if anyone has a setup.py that works for the current > version (3.4.3) before I start fiddling with it myself. > > George > > _______________________________________________ > Pyro-developers mailing list > Pyro-developers@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers > > -- Douglas S. Blank, Assistant Professor dblank@brynmawr.edu, (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From gsakkis at rutgers.edu Wed Feb 2 18:30:47 2005 From: gsakkis at rutgers.edu (George Sakkis) Date: Wed Feb 2 18:26:42 2005 Subject: [Pyro-developers] Installation on cygwin References: <013201c50878$9a6b05d0$ad03a8c0@charisteas> <420103DA.1030109@brynmawr.edu> Message-ID: <001e01c5097f$3aaf49f0$e302a8c0@charisteas> Doug, thanks for the reply. I'm using cygwin as a compromise between developing on a *nix environment and having XP for OS (I'm still hesitant to make the full shift to Linux; also a dual boot system seems more trouble than it's worth it). In any case, I believe that distutils is the way to go in the long run anyway, so I've already started tweaking setup.py and fixing the problems I come across (e.g. name clashes between some C functions under pyro and Cygwin functions/macros). If I get to build it on my system and on a linux box without makefiles, I can make available the patches. George > George, > > Welcome aboard! > > First, Pyro has run under Windows (natively) with some minor changes. > But those changes haven't been incorporated into the main version yet. > (Little things like paths need to be made cross-platform). > > The only reason you would want to go as far as running it under cygwin > would be to try to get all of the functionality of the the third-party > simulators and tools (such as Player/Stage, and Khepera simulator). But > that is unlikely to be very satisfying, and would work much better under > Linux. > > You can run the main Pyro Python code under Windows to connect onto > robots, such as the Aibo, or Player running on a Pioneer3, for example. > But you may not have a real robot. > > The ideal solution would be to have a cross-platform simulator which you > could connect Pyro onto. The Robocup simulator should work. There are > also some pure-Python symbolic simulators that come with Pyro for > playing games like chess, checkers, etc. Those should work under > Windows, I think, but I haven't tried them yet. > > Some parts (like the vision subsystem) are written in C++ and rely on > shared memory. I have no idea if that will work under Windows. > > In general, a Mac OS X port should work better and more easily. > > Finally, the setup.py is just a stub that someone contributed to help us > get that method of installation working. So, the makefile is the only > method that I know that works currently. > > In short, if you don't have a robot, running Pyro under Linux or Mac OS > X will be a lot more fun and productive. But you will be able to do > somethings under Windows. > > Let us know if you have any questions, and we welcome contributions! > > -Doug > > George Sakkis wrote: > > Greetings everyone, > > > > I just downloaded Pyro and I'm looking forward to start using it, and potentially contributing to it > > as part of my master's thesis. So far I have failed to install it out-of-the-box just by following > > the instructions on http://emergent.brynmawr.edu/pyro/?page=PyroInstallation; I guess the main > > reason is that I'm trying to build it on cygwin but apparently the makefiles are intended for Linux > > (or maybe just RedHat). Next thing I tried was the standard distutils 'python setup.py build' but > > the current setup.py is obviously outdated; for one thing, a bunch of directories mentioned there do > > not exist in the latest tarball. I'm wondering if anyone has a setup.py that works for the current > > version (3.4.3) before I start fiddling with it myself. > > > > George > > > > _______________________________________________ > > Pyro-developers mailing list > > Pyro-developers@emergent.brynmawr.edu > > http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers > > > > > > > -- > Douglas S. Blank, Assistant Professor > dblank@brynmawr.edu, (610)526-6501 > Bryn Mawr College, Computer Science Program > 101 North Merion Ave, Park Science Bld. > Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From josh at burnettsonline.org Tue Feb 15 04:23:57 2005 From: josh at burnettsonline.org (Josh Burnett) Date: Tue Feb 15 04:19:12 2005 Subject: [Pyro-developers] success with Khepera 'bots on OSX? Message-ID: <62bd7dca3d7ed0a02f877ea582adedc7@burnettsonline.org> Hi all, Pyro newbie here. I'm looking to use Pyro with the Khepera II robots in my OSX box. I'm working through the process of building Pyro for my machine, and most of the problems I get seem to be with the Khepera module - it compiles if I don't select the Khepera option. Has anyone had any success with this? Any pointers? All comments are appreciated, Josh Josh Burnett jburnett@bu.edu From dblank at brynmawr.edu Tue Feb 15 09:21:36 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Tue Feb 15 09:16:43 2005 Subject: [Pyro-developers] success with Khepera 'bots on OSX? In-Reply-To: <62bd7dca3d7ed0a02f877ea582adedc7@burnettsonline.org> References: <62bd7dca3d7ed0a02f877ea582adedc7@burnettsonline.org> Message-ID: <42120570.2000805@brynmawr.edu> Josh, The Khepera simulator is a very old open source X11 project that we hacked to get it to work via a shared memory model with Pyro. This was a hack on Linux to get us going. Even if you did get it working on OSX now, it would hardly be worth it (the simulator has other issues). Yet, it is still the only simulator we have for the Khepera, so it does have some uses. Our plan was to develop a better Khepera simulation under Player/Stage, which should run on OSX (we currently support the older Player/Stage, not the latest versions yet). However, Player/Stage doesn't have a light-source model, so tasks like "go to the light" can't be done. I think it would be fairly easy to add light sources to Player/Stage (or even Gazebo) if you wanted to try that, and then have a very nice simulation of the Khepera. We hope to get the main Python Pyro code properly cross-platform this Spring. If you have patches to help toward that, they would be very welcomed! -Doug Josh Burnett wrote: > Hi all, Pyro newbie here. > > I'm looking to use Pyro with the Khepera II robots in my OSX box. I'm > working through the process of building Pyro for my machine, and most of > the problems I get seem to be with the Khepera module - it compiles if I > don't select the Khepera option. > > Has anyone had any success with this? Any pointers? > > All comments are appreciated, > > Josh > > Josh Burnett > jburnett@bu.edu > > _______________________________________________ > 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 Thu Feb 17 13:06:15 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Feb 17 13:01:11 2005 Subject: [Pyro-developers] Pyro's mind/body unification; workshop; suggestions Message-ID: <4214DD17.6060208@brynmawr.edu> As we prepare for the final year of the three-year NSF grant, "Beyond Legos: Building the Next Generation Robotics Laboratory" we are making the last major conecptual reorganizations in Pyro. This is also the last year for the Summer Pyro Workshop. If interested in coming to it, please see http://cs.brynmawr.edu/BeyondLegos/Workshops/2005.html Toward this end we have just committed a few changes to Pyro 3.6.0 and to the on-line Pyro documentation. These changes will hopefully make the API a little clearer and easier to explain and use. The first of these is a bit of unification between Pyro's idea of mind and body. Pyro has the objects Brain and Robot, and these two object were the main objects that people interacted with when writing controllers. However, the API was a little clunky when one interacted with these. For example, to find out where the robot thinks it is, you write: >>> self.robot.get("robot/x") "self" is the brain, inside of which is where you write all of your code. But then the brain had to reference the robot, which then had to make the "robot/x" request. This was an interface that evolved from the first idea of controlling robots from Python. In the beginning, we weren't sure how many Brains a user might create at a time, and weren't sure how many Robots each brain might control. Now we know that most users use 1 brain to control 1 robot, and so it makes sense to make less distinction between the Brain and Robot. In the latest version of Pyro, you can now control many robot-centric commands without having to refer to the robot twice. The above command becomes: >>> self.get("robot/x") This is now true for move(), startDevice(), removeDevice() and all of the common things that you would do to the robot. The old method is still valid, but you can use the shorter version, too. Also, this doesn't prevent a single Brain from controlling more than one robot (you can see the RobocupTeam examples to see how you might want to organize that), but it does have good default behavior. (The Pyro RobocupTeam example breaks the Robocup Soccer rules BTW. But it is a easy interface for exploring team-based robotics issues, like soccer.) If you have run into any bits of Pyro that you found confusing, or you have an idea for making something more clear, please let us know. We hope to have Pyro 4.0 finished in the next few weeks. It will include: * support for Aibo (first draft currently included) * support for the latest Player/Stage/Gazebo * Gazebo simulated camera * ER1 support * Web-based version * expression watcher (first draft currently included) * Python code will be cross-platform compatible * Updated Live Pyro CD * Better comments in code * Updated documentation (later this spring) * User's manual (later this spring) Thanks for any feedback! -Doug -- Douglas S. Blank, Assistant Professor dblank@brynmawr.edu, (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From gsakkis at eden.rutgers.edu Thu Feb 17 15:45:03 2005 From: gsakkis at eden.rutgers.edu (gsakkis@eden.rutgers.edu) Date: Thu Feb 17 15:39:54 2005 Subject: [Pyro-developers] Re: [Pyro-users] Pyro's mind/body unification; workshop; suggestions In-Reply-To: <4214DD17.6060208@brynmawr.edu> References: <4214DD17.6060208@brynmawr.edu> Message-ID: <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> > As we prepare for the final year of the three-year NSF grant, "Beyond > Legos: Building the Next Generation Robotics Laboratory" we are making > the last major conecptual reorganizations in Pyro. This is also the last > year for the Summer Pyro Workshop. If interested in coming to it, please > see http://cs.brynmawr.edu/BeyondLegos/Workshops/2005.html > > Toward this end we have just committed a few changes to Pyro 3.6.0 and > to the on-line Pyro documentation. These changes will hopefully make the > API a little clearer and easier to explain and use. > > The first of these is a bit of unification between Pyro's idea of mind > and body. Pyro has the objects Brain and Robot, and these two object > were the main objects that people interacted with when writing > controllers. However, the API was a little clunky when one interacted > with these. For example, to find out where the robot thinks it is, you > write: > > >>> self.robot.get("robot/x") > > "self" is the brain, inside of which is where you write all of your > code. But then the brain had to reference the robot, which then had to > make the "robot/x" request. > > This was an interface that evolved from the first idea of controlling > robots from Python. In the beginning, we weren't sure how many Brains a > user might create at a time, and weren't sure how many Robots each brain > might control. Now we know that most users use 1 brain to control 1 > robot, and so it makes sense to make less distinction between the Brain > and Robot. > > In the latest version of Pyro, you can now control many robot-centric > commands without having to refer to the robot twice. The above command > becomes: > > >>> self.get("robot/x") > > This is now true for move(), startDevice(), removeDevice() and all of > the common things that you would do to the robot. The old method is > still valid, but you can use the shorter version, too. > > Also, this doesn't prevent a single Brain from controlling more than one > robot (you can see the RobocupTeam examples to see how you might want to > organize that), but it does have good default behavior. (The Pyro > RobocupTeam example breaks the Robocup Soccer rules BTW. But it is a > easy interface for exploring team-based robotics issues, like soccer.) > > If you have run into any bits of Pyro that you found confusing, or you > have an idea for making something more clear, please let us know. We > hope to have Pyro 4.0 finished in the next few weeks. It will include: > > * support for Aibo (first draft currently included) > * support for the latest Player/Stage/Gazebo > * Gazebo simulated camera > * ER1 support > * Web-based version > * expression watcher (first draft currently included) > * Python code will be cross-platform compatible > * Updated Live Pyro CD > * Better comments in code > * Updated documentation (later this spring) > * User's manual (later this spring) > > Thanks for any feedback! > > -Doug That's all very good news, and I'm looking forward to Pyro 4.0 ! I've been poking into Pyro's internals over the last few days, and to be honest, I was discouraged by the complicated design and (at a less extent) by the not-so-pythonic style. If I could pick one thing I wished it was different, this would be the get/set device API, with devices being specified as Unix-like paths. Instead I found the ipyro wrapper more natural, though this can be improved further. Here's a rough idea of my preferred API ('<<<' is used for the existing expression, '>>>' for the proposed one): <<< robot.get('/robot/range/count') >>> len(robot.rangeSensors) <<< robot.get('/robot/range/0/value') >>> robot.rangeSensors[0].distance() <<< robot.set('/robot/range/units', 'CM') <<< robot.get('/robot/range/0/value') >>> robot.rangeSensors[0].distance(unit='cm') <<< robot.get('/robot/range/all/value') >>> [sensor.distance() for sensor in robot.rangeSensors] <<< robot.get("/robot/range/all/th") >>> [sensor.angle() for sensor in robot.rangeSensors] <<< robot.get("/robot/range/all/thr") >>> [sensor.angle(inRadians=True) for sensor in robot.rangeSensors] <<< # returns a dict for each sensor <<< robot.get("/robot/range/all/value,th") >>> # returns a tuple for each sensor >>> [(sensor.distance(), sensor.angle()) for sensor in robot.rangeSensors] <<< robot.get('/robot/range/2/x,y') # returns dict {'y': y, 'x': x} >>> robot.rangeSensors[2].position() # returns tuple (x,y) <<< robot.get('/robot/range/front/value') >>> [sensor.distance() for sensor in robot.rangeSensors['front']] <<< robot.get('/robot/range/1:5/value') >>> [sensor.distance() for sensor in robot.rangeSensors[1:5]] # finding out the direction of the nearest obstacle around <<< from pyro.brain import select, avg <<< select(min, "value", self.get("/robot/range/all/pos,thr,value"))["thr"] >>> min([(sensor.distance(), sensor.angle()) >>> for sensor in robot.rangeSensors])[1] On a side note, I have a setup.py that builds (a subset of) Pyro on cygwin, but I think it should be cross-platform with no or few minor modifications. Currently it doesn't cover extensions modules with dependencies that are not available on cygwin or I didn't need to build (camera/bt848, camera/V4L, robot/driver/saphira, simulators/khepera, tools/cluster), but these should be relatively easy to be accomodated as well. Best, George From dblank at brynmawr.edu Thu Feb 17 16:39:53 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Feb 17 16:35:09 2005 Subject: [Pyro-developers] Re: [Pyro-users] Pyro's mind/body unification; workshop; suggestions In-Reply-To: <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> References: <4214DD17.6060208@brynmawr.edu> <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> Message-ID: <42150F29.5050600@brynmawr.edu> gsakkis@eden.rutgers.edu wrote: > That's all very good news, and I'm looking forward to Pyro 4.0 ! I've been poking > into Pyro's internals over the last few days, and to be honest, I was discouraged > by the complicated design and (at a less extent) by the not-so-pythonic style. If > I could pick one thing I wished it was different, this would be the get/set > device API, with devices being specified as Unix-like paths. Instead I found the > ipyro wrapper more natural, though this can be improved further. Here's a rough > idea of my preferred API ('<<<' is used for the existing expression, '>>>' for > the proposed one): George, This is something that we have been wrestling with, and I very much like your interface. I think that with a couple of additional methods we can do it very much like your suggestion. What we were trying to accomplish with our unPythonic get() and set() was a controlled view what was accessible. For instance, if you say: dir(robot) You see lots of methods and properties that we wanted to hide from the novice's view. By implementing our own get/set we could give just the robot-specific methods and properties. (The get/set code got out-of-control and is the ugliest bits I ever saw. I can say that, as, I am afraid to admit it, I wrote it.) Currently, Pyro can access the range sensor, for example, with: robot.range but that returns the Device object. I will add __len__, __getitem__, etc. to those to make it work like you suggest. I don't know of a way to make those listable though (so that ipyro would work) with dir() and other Python tools. If you have other suggestions, please let us know. > On a side note, I have a setup.py that builds (a subset of) Pyro on cygwin, but I > think it should be cross-platform with no or few minor modifications. Currently > it doesn't cover extensions modules with dependencies that are not available on > cygwin or I didn't need to build (camera/bt848, camera/V4L, robot/driver/saphira, > simulators/khepera, tools/cluster), but these should be relatively easy to be > accomodated as well. Please send your additions, and I will add them to the standard install. Thanks! -Doug > Best, > George > -- Douglas S. Blank, Assistant Professor dblank@brynmawr.edu, (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From gsakkis at eden.rutgers.edu Thu Feb 17 18:25:39 2005 From: gsakkis at eden.rutgers.edu (gsakkis@eden.rutgers.edu) Date: Thu Feb 17 18:20:30 2005 Subject: [Pyro-developers] Re: [Pyro-users] Pyro's mind/body unification; workshop; suggestions In-Reply-To: <42150F29.5050600@brynmawr.edu> References: <4214DD17.6060208@brynmawr.edu> <63751.68.197.31.58.1108673103.squirrel@webmail.eden.rutgers.edu> <42150F29.5050600@brynmawr.edu> Message-ID: <62126.68.197.31.58.1108682739.squirrel@webmail.eden.rutgers.edu> > George, > > This is something that we have been wrestling with, and I very much like > your interface. I think that with a couple of additional methods we can > do it very much like your suggestion. I also think it's doable, without even breaking backwards compatibility if this is necessary; get() and set() can remain and work without change (probably annotated as deprecated). > What we were trying to accomplish with our unPythonic get() and set() > was a controlled view what was accessible. For instance, if you say: > > dir(robot) > > You see lots of methods and properties that we wanted to hide from the > novice's view. By implementing our own get/set we could give just the > robot-specific methods and properties. (The get/set code got > out-of-control and is the ugliest bits I ever saw. I can say that, as, I > am afraid to admit it, I wrote it.) > > Currently, Pyro can access the range sensor, for example, with: > > robot.range > > but that returns the Device object. I will add __len__, __getitem__, > etc. to those to make it work like you suggest. I don't know of a way to > make those listable though (so that ipyro would work) with dir() and > other Python tools. dir() is a handy introspection function intended to be used interactively, mainly for debugging or just out of curiosity, but certainly not for documentation, especially for the novice (running e.g. dir(1) will scare off for good the unsuspecting python newbie). I can't think any better workaround than good __doc__umentation that describes the interface; this is easily accessed in IPython by prepending (or appending) '?' to any object (e.g. 'pyro.robot.Robot ?') > If you have other suggestions, please let us know. > > > On a side note, I have a setup.py that builds (a subset of) Pyro on cygwin, but I > > think it should be cross-platform with no or few minor modifications. Currently > > it doesn't cover extensions modules with dependencies that are not available on > > cygwin or I didn't need to build (camera/bt848, camera/V4L, robot/driver/saphira, > > simulators/khepera, tools/cluster), but these should be relatively easy to be > > accomodated as well. > > Please send your additions, and I will add them to the standard install. I will try to think of any undocumented changes I made, add some comments, and I'll send them over in the next few days. > Thanks! > > -Doug Regards, George From dblank at brynmawr.edu Thu Feb 17 22:40:38 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu Feb 17 22:35:31 2005 Subject: [Pyro-developers] This is great! Message-ID: Thanks again, George, for the insightful proposal. For me, the part that I had been missing was the idea to make sensor[i] an object. Although this might be quite a burden for the system when dealing with lasers (with 361 readings, or more) it does work, and it is quite elegant. After just a few lines of code, here is the new Pythonic Pyro range sensor interface: >>> len(robot.range) >>> robot.range[0].distance() >>> robot.range[0].distance(unit='cm') >>> [sensor.distance() for sensor in robot.range] >>> [sensor.angle() for sensor in robot.range] >>> [sensor.angle(unit='radians') for sensor in robot.range] >>> [(sensor.distance(), sensor.angle()) for sensor in robot.range] >>> robot.range[2].position() >>> [sensor.distance() for sensor in robot.range['front']] >>> [sensor.distance() for sensor in robot.range[1:5]] >>> min([(sensor.distance(), sensor.angle()) for sensor in robot.range])[1] >>> [sensor.position() for sensor in robot.range['front']] >>> [sensor.hit() for sensor in robot.range['front']] >>> [sensor.hit() for sensor in robot.range['front-left']] >>> robot.range[2].hit() I only slighty altered George's proposed interface, making angle() also take the keyword "unit" (radians or degrees). position() returns a tuple (x,y,z) (sensors can be in different planes). hit() returns the (x,y,z) of the object that is being detected. You can access robot.sonar, robot.laser, robot.light and robot.ir this way. This code doesn't affect the old get()/set() at all and I will be glad someday to delete that code. We'll leave it in for now, though. I have implemented the above for the Player/Stage robots. I'll now go through and add it throughout to the other robot types. Other sensor types I'll probably leave in the get() format for now (unless anyone has a similar proposal). Thanks! -Doug -- Douglas S. Blank, Assistant Professor dblank@brynmawr.edu, (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Building Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From dblank at brynmawr.edu Sun Feb 20 11:27:04 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Sun Feb 20 11:21:46 2005 Subject: [Pyro-developers] CVS moving to Pyro4 Message-ID: Pyro Developers working from CVS: Pyro version 3.6.1 is the last version for the Pyro3 series. From here on out, the CVS HEAD will be in the Pyro4 series. That means, don't do a "cvs update" in your installed Pyro code unless you are ready to move to Pyro4. The main difference in Pyro4 from Pyro3 is that it will support the lastest versions of Player/Stage/Gazebo (PSG). PSG has gone through a complete reorganization, and some amazing things are now possible that weren't before. Unfortunately, most everything has changed including world files, config files, methods of starting up programs, protocols, etc. Although the Pyro4 -> PSG interface won't be ready for days, you can check out the installation notes at: http://emergent.brynmawr.edu/emergent/Pyro4Installation You can get the last versions of Pyro3 and the newest versions of Pyro4 (when available) at: http://emergent.brynmawr.edu/~dblank/pyro/tars/ Currently Pyro4 is based on PSG out of their CVS, so things will be in flux for the next month or so. Finally, why would we go to all this trouble to bring Pyro up-to-date with the new PSG? PSG offers: - access to a wide range or robots - the new Stage offers unlimited-sized worlds, dynamic creation/deletion of objects, programmability (move non-robot objects in the world), flexible screen capture (every N seconds, for example), nice screen images for use in reports - the new Gazebo offers simulated cameras of OpenGL data (which means that we can do some very realistic simulations using the standard Pyro tools), dual-camera support (for exploring stereo vision) ~Doug -- Douglas S. Blank, Assistant Professor dblank@brynmawr.edu, (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Building Bryn Mawr, PA 19010 dangermouse.brynmawr.edu From danbmil at andrew.cmu.edu Thu Feb 24 18:43:43 2005 From: danbmil at andrew.cmu.edu (Daniel B Miller) Date: Sun Feb 27 23:02:37 2005 Subject: [Pyro-developers] Adding a platform to Pyro, and more Message-ID: <2713.209.172.121.194.1109288623.squirrel@209.172.121.194> Hi all-- Recently I have become involved in planning our future development of the RoboCamp West program (http://west.cmu.edu/specialPrograms/index.htm). As a long-time Pythonista, I was very excited to find Pyro, and am hoping to convince the powers that be to use it as the basis for our curriculum. The one hitch is that our program is based on our own MAX platform. MAX is a 4-wheel, all-terrain steerable robot, resembling a typical RC truck (think Sandstorm at 1/16 scale). Anyway, my primary questions are as follows: 1) Is there any documentation on adding platforms to Pyro? Is this sort of thing anticipated and encouraged? Or, would it be seen as pulling away from the main thrust of the program? 2) Assuming we go ahead and try to do this, what sorts of challenges should we anticipate? My main concern is that MAX is most definitely _not_ a typical differential-drive type of research robot. It steers like a car, has a suspension, and is capable of very dynamic behavior. The drawbacks are: no turning in place, and bad odometry (squishy wheels). It has lots of brainpower -- a servopod controller, plus a 1ghz+ pentium PC running Linux. Any thoughts on this would be greatly appreciated. Best regards, -- Dan Miller Faculty Research Associate Carnegie Mellon West From dblank at brynmawr.edu Sun Feb 27 23:19:06 2005 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Sun Feb 27 23:13:19 2005 Subject: [Pyro-developers] Adding a platform to Pyro, and more In-Reply-To: <2713.209.172.121.194.1109288623.squirrel@209.172.121.194> References: <2713.209.172.121.194.1109288623.squirrel@209.172.121.194> Message-ID: <42229BBA.2020505@brynmawr.edu> Dan, I think that the best approach would be to use a standard interface, and then access that from Python. Luckily, there is an interface that many people are organizing around: the Player/Stage interface. Take a look at: http://playerstage.sourceforge.net/ If you build an interface using their standard devices, then Pyro can access it as a normal Player-based robot. That will also allow many other tools to work with your robot. PlayerStage has some robots that are similar to what you have described. The protocol can be written in whatever language you want, but they have many tools in C and C++. But, once the interface is done, then you can work in Python. This is the direction we are headed: we hope to move all of our low-level interfaces to Player/Stage, and focus on the control from Python (and other high-level languages). Let us know how that goes, -Doug Daniel B Miller wrote: > Hi all-- > > Recently I have become involved in planning our future development of the RoboCamp West program (http://west.cmu.edu/specialPrograms/index.htm). > > As a long-time Pythonista, I was very excited to find Pyro, and am hoping to convince the powers that be to use it as the basis for our curriculum. The one hitch is that our program is based on our own MAX platform. MAX is a 4-wheel, all-terrain steerable robot, resembling a typical RC truck (think Sandstorm at 1/16 scale). > > Anyway, my primary questions are as follows: > > 1) Is there any documentation on adding platforms to Pyro? Is this sort of thing anticipated and encouraged? Or, would it be seen as pulling away from the main thrust of the program? > > 2) Assuming we go ahead and try to do this, what sorts of challenges should we anticipate? My main concern is that MAX is most definitely _not_ a typical differential-drive type of research robot. It steers like a car, has a suspension, and is capable of very dynamic behavior. The drawbacks are: no turning in place, and bad odometry (squishy wheels). It has lots of brainpower -- a servopod controller, plus a 1ghz+ pentium PC running Linux. > > Any thoughts on this would be greatly appreciated. > > Best regards, > -- 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