From w.richert at gmx.net Thu Jun 2 03:40:40 2005 From: w.richert at gmx.net (Willi Richert) Date: Thu Jun 2 03:40:56 2005 Subject: [Pyro-developers] Maybe threading-related exceptions In-Reply-To: <200505311543.37526.richert@c-lab.de> References: <200505301155.32250.w.richert@gmx.net> <429C65F2.3020901@brynmawr.edu> <200505311543.37526.richert@c-lab.de> Message-ID: <200506020940.40308.w.richert@gmx.net> Hi all, I've asked in the python ML and Danny Yoo suggested: | Hmmm! This actually looks very unusual. You should never see anything | about 'tp_compare' unless you're dealing with a buggy C extension. The pyrobot project contains only plugin-related C-files, as a quick look showed. This looks more and more like a threading issue, as this error never happens with PlayerStage pure client code (without Pyrobot). Just to keep interested people informed. Regards, wr Am Dienstag, 31. Mai 2005 15:43 schrieb Willi Richert: > Am Dienstag, 31. Mai 2005 15:26 schrieb Douglas S. Blank: > > Willi, > > > > Does your computer have more than one CPU? I have seen things like this > > before on a machine with multiple CPUs when running SMP Linux (but only > > with tkinter drawing). > > Nope. Now I have surrounded all "fragile" code blocks with try/except > blocks and return standard values. Works for ~ 1000 seconds. Thereafter the > agents start to do strange things. So I restart everything with the > previously saved Q-Values (Reinforcement Learning). > > BTW, I've also tried to encapsulate some code fragments with thread-locks, > but this didn't seem to help. > > wr > > > -Doug > > > > Willi Richert wrote: > > > Hi, > > > > > > here is another exception that has just occurred and is totally > > > unreasonable to me: > > > > > > NeedBrain.py:245: RuntimeWarning: tp_compare didn't return -1 or -2 for > > > exception return self.markerDistance() < self.STAY_MIN_DIST > > > Exception in thread Thread-4: > > > Traceback (most recent call last): > > > File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap > > > self.run() > > > File "./brain/__init__.py", line 148, in run > > > File "NeedBrain.py", line 415, in step > > > BehaviorBasedBrain.step(self) > > > File > > > "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", > > > line 63, in step self.states[s].run() > > > File > > > "/home/wr/forschung/software/ps/pyrobot/brain/behaviors/__init__.py", > > > line 299, in run self.update() > > > File "NeedBrain.py", line 208, in update > > > if not self.wasNearMarker and self.isNearMarker(): > > > File "NeedBrain.py", line 245, in isNearMarker > > > return self.markerDistance() < self.STAY_MIN_DIST > > > IndexError: tuple assignment index out of range > > > > > > the related code: > > > > > > def markerDistance(self): > > > m_obj = self.get("robot/fiducial/id")(self.marker) > > > if not m_obj: > > > return 1000.0 > > > dist = m_obj.range > > > assert(type(dist), type(float)) > > > return dist > > > > > > def isNearMarker(self): > > > return self.markerDistance() < self.STAY_MIN_DIST > > > > > > Am Montag, 30. Mai 2005 11:55 schrieb Willi Richert: > > >>Hi, > > >> > > >>here is another strange error: > > >> > > >>Exception in thread Thread-2: > > >>Traceback (most recent call last): > > >> File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap > > >> self.run() > > >> File "./brain/__init__.py", line 151, in run > > >>IndexError: tuple assignment index out of range > > >> > > >>Line 151 in brain/__init__.py is > > >> self.couldBeMoving = 1 > > >> > > >>wr > > >>_______________________________________________ > > >>Pyro-developers mailing list > > >>Pyro-developers@emergent.brynmawr.edu > > >>http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers > > > > > > _______________________________________________ > > > Pyro-developers mailing list > > > Pyro-developers@emergent.brynmawr.edu > > > http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers From w.richert at gmx.net Thu Jun 2 09:11:59 2005 From: w.richert at gmx.net (Willi Richert) Date: Thu Jun 2 09:12:11 2005 Subject: [Pyro-developers] Engine.shutdown() does not free Brain Message-ID: <200506021511.59237.w.richert@gmx.net> Hi, I would suggest to add self.freeBrain() to shutdown: def shutdown(self): self.freeBrain() self.freeRobot() Regards, wr From dblank at mainline.brynmawr.edu Thu Jun 2 09:27:20 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Thu Jun 2 09:27:21 2005 Subject: [Pyro-developers] Engine.shutdown() does not free Brain In-Reply-To: <200506021511.59237.w.richert@gmx.net> Message-ID: Willi, I think Engine.freeRobot calls freeBrain (6 lines above shutdown). I hope we can figure out the thread problem. I'll try to make some documentation about what threads are running, and which is responsible for doing what. Do you get this same problem if you don't use the Tkinter GUI? For example: % pyrobot -r Player6665 -s StageSimulator -w everything.cfg -b YourBrain -g tty Pyro> run Does that still give the strange behavior? Thanks, -Doug Willi Richert said: > Hi, > > I would suggest to add self.freeBrain() to shutdown: > > def shutdown(self): > self.freeBrain() > self.freeRobot() > > Regards, > wr > _______________________________________________ > Pyro-developers mailing list > Pyro-developers@emergent.brynmawr.edu > http://emergent.brynmawr.edu/mailman/listinfo/pyro-developers > -- From w.richert at gmx.net Tue Jun 14 03:43:45 2005 From: w.richert at gmx.net (Willi Richert) Date: Tue Jun 14 03:43:51 2005 Subject: [Pyro-developers] Segfault with the RPM FC3 Repository Pyrobot version Message-ID: <200506140943.46644.w.richert@gmx.net> Hi, I just did a clean install as described at http://PyroRobotics.org/pyro/?page=PyroInstallation under 1.1. Every now and then I get now: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1309377616 (LWP 15102)] tupleiter_next (it=0xb7c1d4ec) at Objects/tupleobject.c:797 797 Py_INCREF(item); (gdb) bt #0 tupleiter_next (it=0xb7c1d4ec) at Objects/tupleobject.c:797 #1 0x00ada39f in PyIter_Next (iter=0xb) at Objects/abstract.c:2225 #2 0x00b2d6f0 in eval_frame (f=0x8155f94) at Python/ceval.c:2091 #3 0x00b3197b in eval_frame (f=0x815614c) at Python/ceval.c:3518 #4 0x00b3197b in eval_frame (f=0x815721c) at Python/ceval.c:3518 #5 0x00b3197b in eval_frame (f=0x815849c) at Python/ceval.c:3518 #6 0x00b3209e in PyEval_EvalCodeEx (co=0xb7c560a0, globals=0xb, locals=0x0, args=0xb7c12418, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2663 #7 0x00aede2e in function_call (func=0xb7c52c6c, arg=0xb7c1240c, kw=0x0) at Objects/funcobject.c:504 #8 0x00ada607 in PyObject_Call (func=0xb0b4f1, arg=0x0, kw=0x0) at Objects/abstract.c:1755 #9 0x00ae1d98 in instancemethod_call (func=0xb7c52c6c, arg=0xb7c1240c, kw=0x0) at Objects/classobject.c:2433 #10 0x00ada607 in PyObject_Call (func=0xb0b4f1, arg=0x0, kw=0x0) at Objects/abstract.c:1755 #11 0x00b2fb7f in eval_frame (f=0x814e94c) at Python/ceval.c:3644 #12 0x00b3197b in eval_frame (f=0x811e8b4) at Python/ceval.c:3518 #13 0x00b3197b in eval_frame (f=0x811ea7c) at Python/ceval.c:3518 #14 0x00b3209e in PyEval_EvalCodeEx (co=0xb7f7a260, globals=0xb, locals=0x0, args=0xb7c5ba98, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2663 #15 0x00aede2e in function_call (func=0xb7f8aa04, arg=0xb7c5ba8c, kw=0x0) at Objects/funcobject.c:504 #16 0x00ada607 in PyObject_Call (func=0xb0b4f1, arg=0x0, kw=0x0) at Objects/abstract.c:1755 #17 0x00ae1d98 in instancemethod_call (func=0xb7f8aa04, arg=0xb7c5ba8c, kw=0x0) at Objects/classobject.c:2433 #18 0x00ada607 in PyObject_Call (func=0xb0b4f1, arg=0x0, kw=0x0) at Objects/abstract.c:1755 #19 0x00b2c1b0 in PyEval_CallObjectWithKeywords (func=0x0, arg=0xb7fa202c, kw=0x0) at Python/ceval.c:3346 #20 0x00b54072 in t_bootstrap (boot_raw=0x8135be0) at ./Modules/threadmodule.c:180 #21 0x00baa341 in start_thread () from /lib/tls/libpthread.so.0 #22 0x00a29fee in clone () from /lib/tls/libc.so.6 At the Python mailing list they told me that this is a python third-party problem with high probability. The same happens if I use the current Pyrobot CVS version. My system: Linux 2.6.11-1.27_FC3 #1 Tue May 17 20:27:37 EDT 2005 i686 i686 i386 GNU/Linux Fedora Core 3 Any help? wr From dblank at mainline.brynmawr.edu Tue Jun 14 08:16:10 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Tue Jun 14 08:16:14 2005 Subject: [Pyro-developers] Segfault with the RPM FC3 Repository Pyrobot version In-Reply-To: <200506140943.46644.w.richert@gmx.net> Message-ID: Willi Richert said: > Hi, > > I just did a clean install as described at > http://PyroRobotics.org/pyro/?page=PyroInstallation under 1.1. > > Every now and then I get now: > > Program received signal SIGSEGV, Segmentation fault. [snip] > At the Python mailing list they told me that this is a python third-party > problem with high probability. I have no doubt that it is something in our code (or our build or Player/Stage) as I have never had Python crash, but I think you may have dived down too deep too quickly. What code were you running? Does it involve any of our vision code? (That is the only C/C++/SWIG code, I think) What simulator and versions? Can you provide a simple example of the problem with code so to reproduce it? Does this code work on other computers or other versions of the OS? Does the crash happen if you don't "run" the code, but have Pyrobot open ready to run? What version of SWIG are you using (swig -version)? > The same happens if I use the current Pyrobot CVS version. Are you sure you are running the CVS version? The RPMs install the code in /usr/lib/python2.3/pyrobot/ and can be found even if you have a different version? You can also try this as root: cd /usr/lib/python2.3/pyrobot/ make clean make To see if it is a build issue with the Python code. Of course, it might be an issue with the Player/Stage or other rpm-installed build of ours, but you'll have to let us know what simulator, etc. -Doug > My system: Linux 2.6.11-1.27_FC3 #1 Tue May 17 20:27:37 EDT 2005 i686 i686 > i386 GNU/Linux Fedora Core 3 > > Any help? > wr From abstractius at yahoo.co.uk Thu Jun 23 23:01:10 2005 From: abstractius at yahoo.co.uk (Anastasios Tsiolakidis) Date: Thu Jun 23 23:01:13 2005 Subject: [Pyro-developers] 3d "realistic" physics simulation Message-ID: <20050624030110.11095.qmail@web26403.mail.ukl.yahoo.com> Hello, I have searched the internet for an ambitious simulation environment and have found none. The idea would be to work towards things like a "Simulated AIBO league". A CAD-like file format would be needed to describe a robot's shape as well as 3d behaviours, basically the axes, speeds and ranges of movement (the "effectors"). I am assuming some(all?) CAD programs have provisions for the capture of such dynamic information for their otherwise static designs, but I don't really know and would welcome any relevant information - I will probably ask the question in a CAD forum as well. The purist will probably notice that such virtualisation will be quite difficult and require proper "Virtual Machines" to be constructed in software to simulate proprietary and open sensors, operating systems etc, but I will argue that such VMs can be improved incrementally and will be useful even in very early incarnations. Finally, a physics engine that knows about a few other critical objects as well, such a ball, a net etc will slowly but surely compute the whole thing. Is this of interest to the pyro community? Is this the next step or perhaps the next step after many next steps? Or perhaps is the absence of a roadmap for pyro indicative of the fact that the project has achieved its aims and will not venture that far? All comments welcome! AT ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From dblank at mainline.brynmawr.edu Fri Jun 24 18:45:42 2005 From: dblank at mainline.brynmawr.edu (dblank@mainline.brynmawr.edu) Date: Fri Jun 24 18:45:44 2005 Subject: [Pyro-developers] 3d "realistic" physics simulation In-Reply-To: <20050624030110.11095.qmail@web26403.mail.ukl.yahoo.com> Message-ID: Anastasios, I think many people that have developed and used Pyro would also be interested in such a simulator. However, that goes beyond the current goals of the Pyro project. Many of us are looking toward such a next step though. I am currently looking into developing an AIBO simulator in Gazebo, the 3D Player/Stage simulator. Gazebo combines physics and graphics, with well developed interfaces to robot controllers, and I suggest you have a look. Initially, our AIBO simulator will only simulate some of the dynamics of the robot (for example, leaving out the legs). However, we will focus on the vision, and OPEN-R level compatibility. This is a long term project, and probably won't be ready for general use for a year or two. If there are people interested in developing more sophisticated simulated robots (for example, humanoid, walking, manipulating robots with realistic vision) let me know. Maybe we can coordinate our efforts. -Doug Anastasios Tsiolakidis said: > Hello, > > I have searched the internet for an ambitious > simulation environment and have found none. The idea > would be to work towards things like a "Simulated AIBO > league". A CAD-like file format would be needed to > describe a robot's shape as well as 3d behaviours, > basically the axes, speeds and ranges of movement (the > "effectors"). I am assuming some(all?) CAD programs > have provisions for the capture of such dynamic > information for their otherwise static designs, but I > don't really know and would welcome any relevant > information - I will probably ask the question in a > CAD forum as well. > > The purist will probably notice that such > virtualisation will be quite difficult and require > proper "Virtual Machines" to be constructed in > software to simulate proprietary and open sensors, > operating systems etc, but I will argue that such VMs > can be improved incrementally and will be useful even > in very early incarnations. > > Finally, a physics engine that knows about a few other > critical objects as well, such a ball, a net etc will > slowly but surely compute the whole thing. Is this of > interest to the pyro community? Is this the next step > or perhaps the next step after many next steps? Or > perhaps is the absence of a roadmap for pyro > indicative of the fact that the project has achieved > its aims and will not venture that far? > > All comments welcome! > > AT From dblank at brynmawr.edu Wed Jun 29 00:03:19 2005 From: dblank at brynmawr.edu (dblank@brynmawr.edu) Date: Wed Jun 29 00:03:25 2005 Subject: [Pyro-developers] Pyro CVS version under construction Message-ID: <52528.68.81.116.28.1120017799.squirrel@newwebmail.brynmawr.edu> Pyro users and developers, The Pyro CVS version will be unstable for the next few days as we finalize Pyro4. Under the hood, Pyro is getting a major overhaul to simplify the objects and streamline the processing. The biggest change is the removal of the robot.get(PATH) and robot.set(PATH) methods. For example, you used to have to write: >>> robot.get("robot/x") but that will become: >>> robot.x Other big changes: 1. removal of Aria and Saphira objects. Pioneer robots will be supported via the Player interface. 2. support for the latest player/stage/gazebo 3. more robust processing loop 4. support for UDP with AIBO (more robust AIBO processing) 5. Removal of the engine object (merge it with robot or brain) Once these changes are finalized, look for Pyro 4.10 probably early next week. If you have any wishlist items, please let us know. Thanks! -Doug From dblank at brynmawr.edu Thu Jun 30 12:23:01 2005 From: dblank at brynmawr.edu (dblank@brynmawr.edu) Date: Thu Jun 30 12:23:07 2005 Subject: [Pyro-developers] Pyro version 4.0.4 Message-ID: <34354.68.81.116.28.1120148581.squirrel@newwebmail.brynmawr.edu> Pyro developers, I have completed the major reworking of the robot.get() and robot.set() and have Khepera, Hemisson, Test, and all Player-based robots (Stage, Pioneer, and Gazebo) finished. Also, I have updated all of the plugin/brains/*.py examples, and updated all of the wiki example code to the new format. There are no doubt things that are broken, and somethings that can work better. But, if you want to start using the CVS Pyro and providing feedback, that would be great. I hope to catch all of the issues in the next week or so. Also, you can begin to edit or note problems in the wiki text. This page showed the alternate form, but now is the only way: http://emergent.brynmawr.edu/emergent/PythonicPyroIntro That may help in porting your old code to the new format too. If you have questions, please ask! Thanks, -Doug