From: Douglas S. B. <db...@br...> - 2004-07-25 08:37:50
|
Player users/developers, I'm just now trying out player as a server on our vintage Pioneer2ATs (Redhat 6.0), circa 2000. I've updated the p2os, so it is up-to-date, and compiled Player-src-1.5 from tarball (I had to disable linuxwifi and khepera, and edit the makefile to remove the examples to get it to compile, FYI). Both p2os_position and p2os_sonar seem to work fine. But, when I put in ptz:0 (driver "sonyevid30") The player server dies a painful death with: Player got a SIGSEGV! (that ain't good) This occurs with playerjoy and our own Python client. I searched through the archives, but didn't see anything. Has sonyevid30 changed any after 1.5? Maybe I have the wrong serial port? How would I know? Any hints much appreciated, -Doug -- Douglas S. Blank, Assistant Professor db...@br..., (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu |
From: Brian G. <ge...@ai...> - 2004-07-25 16:57:16
|
On Sun, 25 Jul 2004, Douglas S. Blank wrote: > I'm just now trying out player as a server on our vintage Pioneer2ATs > (Redhat 6.0), circa 2000. I've updated the p2os, so it is up-to-date, > and compiled Player-src-1.5 from tarball (I had to disable linuxwifi and > khepera, and edit the makefile to remove the examples to get it to > compile, FYI). hi Doug, I just noticed the compilation problems you mention, and I'd like to fix them, if possible, with your help. I'm not surprised that linuxwifi doesn't build. The configuration check verifies the presence of <linux/wireless.h>, but that file and the API it defines may change between major kernel versions (RH 6.0 uses a 2.2 kernel, and we're probably relying on the 2.4 API). I'm not sure what we can do about this one, maybe explicitly check the running kernel version... Could you tell what the problem was in the khepera driver build? How about the examples? Which ones fail, and can you see why? brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Douglas S. B. <db...@br...> - 2004-07-25 18:40:44
|
Brian Gerkey wrote: > On Sun, 25 Jul 2004, Douglas S. Blank wrote: > >>I'm just now trying out player as a server on our vintage Pioneer2ATs >>(Redhat 6.0), circa 2000. I've updated the p2os, so it is up-to-date, >>and compiled Player-src-1.5 from tarball (I had to disable linuxwifi and >>khepera, and edit the makefile to remove the examples to get it to >>compile, FYI). > > hi Doug, > I just noticed the compilation problems you mention, and I'd like to fix > them, if possible, with your help. Good idea, because I think that the sonyevid30 not working may be more serious than I thought. First some details on it, then some more details on compiling issues. So, the big problem is that when I attach onto the player server and try to start the sonyevid30, it crashes. I attached onto the player server with GDB and saw this when I connect: // ------------------------------------------------------ (gdb) c Continuing. [New Thread 10659] [New Thread 10418] [New Thread 10660] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 10660] Program received signal SIGSEGV, Segmentation fault. 0x805b0b3 in P2OS::Main (this=0x80c4770) at p2os.cc:1409 1409 sizeof(sound_cmd)); Current language: auto; currently c++ (gdb) bt #0 0x805b0b3 in P2OS::Main (this=0x80c4770) at p2os.cc:1409 #1 0x804dc8a in CDevice::DummyMain (devicep=0x80c4770) at device.cc:440 #2 0x401a3ce9 in pthread_start_thread (arg=0xbf7ffe7c) at manager.c:204 (gdb) l 1404 // now reset command to 0 1405 player_sound_cmd_t sound_cmd; 1406 sound_cmd.index = 0; 1407 // TODO: who should really be the client here? 1408 soundp->PutCommand(this,(unsigned char*)(&sound_cmd), 1409 sizeof(sound_cmd)); 1410 soundindex = 0; 1411 } 1412 // ------------------------------------------------------ So I went to that section of code, enabled a printf statement there, and commented out the call to PutCommand(). The code then runs without crashing, but results in output like: // ------------------------------------------------------ PTZ connection initializing (/dev/ttyS2)...SonyEVID30::Setup():tcflush():: Input/output error Playing sound: 65535 Playing sound: 65535 Playing sound: 65535 Playing sound: 65535 Playing sound: 65535 ... // ------------------------------------------------------ Why is it trying to play a sound everytime through that loop? Is that the right tty port? > I'm not surprised that linuxwifi doesn't build. The configuration check > verifies the presence of <linux/wireless.h>, but that file and the API > it defines may change between major kernel versions (RH 6.0 uses a 2.2 > kernel, and we're probably relying on the 2.4 API). I'm not sure what > we can do about this one, maybe explicitly check the running kernel > version... > > Could you tell what the problem was in the khepera driver build? I'll rerun configure, and get details on the above when I get a bit more time. > How about the examples? Which ones fail, and can you see why? When the examples are in the list of things to compile, it bombs on: // ------------------------------------------------------ ... g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../server -I../../server -I../../client_libs/c -I../../client_libs/c++ -g -O2 -c manualGrip.cc manualGrip.cc: In function `int main(int, char **)': manualGrip.cc:113: undeclared variable `string' (first use here) manualGrip.cc:113: parse error before `;' manualGrip.cc:114: `str' undeclared (first use this function) manualGrip.cc:114: (Each undeclared identifier is reported only once manualGrip.cc:114: for each function it appears in.) manualGrip.cc:116: confused by earlier errors, bailing out make[3]: *** [manualGrip.o] Error 1 // ------------------------------------------------------ I think that is a line using "std::". Thanks for any help in getting the ptz working! -Doug > brian. > -- Douglas S. Blank, Assistant Professor db...@br..., (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu |
From: Brian G. <ge...@ai...> - 2004-07-25 19:40:29
|
On Sun, 25 Jul 2004, Douglas S. Blank wrote: > So, the big problem is that when I attach onto the player server and try > to start the sonyevid30, it crashes. I attached onto the player server > with GDB and saw this when I connect: > > // ------------------------------------------------------ > (gdb) c > Continuing. > [New Thread 10659] > [New Thread 10418] > [New Thread 10660] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 10660] > > Program received signal SIGSEGV, Segmentation fault. > 0x805b0b3 in P2OS::Main (this=0x80c4770) at p2os.cc:1409 > 1409 sizeof(sound_cmd)); > Current language: auto; currently c++ > (gdb) bt > #0 0x805b0b3 in P2OS::Main (this=0x80c4770) at p2os.cc:1409 > #1 0x804dc8a in CDevice::DummyMain (devicep=0x80c4770) at device.cc:440 > #2 0x401a3ce9 in pthread_start_thread (arg=0xbf7ffe7c) at manager.c:204 > (gdb) l > 1404 // now reset command to 0 > 1405 player_sound_cmd_t sound_cmd; > 1406 sound_cmd.index = 0; > 1407 // TODO: who should really be the client here? > 1408 soundp->PutCommand(this,(unsigned char*)(&sound_cmd), > 1409 sizeof(sound_cmd)); > 1410 soundindex = 0; > 1411 } > 1412 > // ------------------------------------------------------ I found a bug in the p2os driver dealing with initialization of the sound support, and I've attached a patch that should fix it. It may be that using p2os and sonyevid30 is a lucky combination that exposes this bug, or it may be that there's yet another problem. If this patch doesn't stop player crashing, I'd highly recommend running it through valgrind (you'll likely have to build valgrind from source on that old machine). It's far more informative than gdb, and can really shorten the debug cycle on problems like this. > When the examples are in the list of things to compile, it bombs on: > > // ------------------------------------------------------ > ... > g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../server -I../../server > -I../../client_libs/c -I../../client_libs/c++ -g -O2 -c manualGrip.cc > manualGrip.cc: In function `int main(int, char **)': > manualGrip.cc:113: undeclared variable `string' (first use here) > manualGrip.cc:113: parse error before `;' > manualGrip.cc:114: `str' undeclared (first use this function) > manualGrip.cc:114: (Each undeclared identifier is reported only once > manualGrip.cc:114: for each function it appears in.) > manualGrip.cc:116: confused by earlier errors, bailing out > make[3]: *** [manualGrip.o] Error 1 > // ------------------------------------------------------ That's this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=996044&group_id=42445&atid=433164 The fix is to #include <string>, rather than <string.h>. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Brian G. <ge...@ai...> - 2004-07-25 19:44:55
|
On Sun, 25 Jul 2004, Brian Gerkey wrote: > I found a bug in the p2os driver dealing with initialization of the > sound support, and I've attached a patch that should fix it. Ok, this time I'll actually provide the patch. brian. Index: server/drivers/mixed/p2os/p2os.cc =================================================================== RCS file: /cvsroot/playerstage/code/player/server/drivers/mixed/p2os/p2os.cc,v retrieving revision 1.24 diff -c -r1.24 p2os.cc *** server/drivers/mixed/p2os/p2os.cc 13 Jul 2004 19:55:08 -0000 1.24 --- server/drivers/mixed/p2os/p2os.cc 25 Jul 2004 19:32:45 -0000 *************** *** 130,135 **** --- 130,137 ---- ((player_p2os_cmd_t*)device_command)->gripper.cmd = GRIPstore; ((player_p2os_cmd_t*)device_command)->gripper.arg = 0x00; + ((player_p2os_cmd_t*)device_command)->sound.index = 0; + p2os_subscriptions = 0; pthread_mutex_init(&p2os_accessMutex,NULL); *************** *** 1230,1236 **** /* check for sound play command */ newsoundplay = false; ! if (command.sound.index) { newsoundplay = true; soundindex = ntohs(command.sound.index); } --- 1232,1238 ---- /* check for sound play command */ newsoundplay = false; ! if (soundp && command.sound.index) { newsoundplay = true; soundindex = ntohs(command.sound.index); } |
From: Douglas S. B. <db...@br...> - 2004-07-25 20:33:09
|
Great; thanks Brian! The patch fixed the sound initialization issue with the p2os on the old Pioneers, and the <string.h> => <string> fixed the examples so that they compile. Now, everything runs, but I still get this error when attempting to start the PTZ: PTZ connection initializing (/dev/ttyS2)...SonyEVID30::Setup():tcflush():: Input/output error Oh wait, I now see in the user manual: "The sonyevid30 operates over a direct serial link, not through the P2OS microcontroller's AUX port, as is the normal configuration for ActivMedia robots. You may have to make or buy a cable to connect your camera to a normal serial port." Sorry, just looks like I need to get a couple of cables. Is there a place that sells those, or are they easy to make? -Doug -- Douglas S. Blank, Assistant Professor db...@br..., (610)526-6501 Bryn Mawr College, Computer Science Program 101 North Merion Ave, Park Science Bld. Bryn Mawr, PA 19010 dangermouse.brynmawr.edu |
From: Brian G. <ge...@ai...> - 2004-07-25 20:53:47
|
On Sun, 25 Jul 2004, Douglas S. Blank wrote: > Great; thanks Brian! The patch fixed the sound initialization issue with > the p2os on the old Pioneers, and the <string.h> => <string> fixed the > examples so that they compile. Now, everything runs, but I still get > this error when attempting to start the PTZ: > > PTZ connection initializing > (/dev/ttyS2)...SonyEVID30::Setup():tcflush():: Input/output error > > Oh wait, I now see in the user manual: > > "The sonyevid30 operates over a direct serial link, not through the P2OS > microcontroller's AUX port, as is the normal configuration for > ActivMedia robots. You may have to make or buy a cable to connect your > camera to a normal serial port." Yep, controlling the camera through the P2OS board saves you a serial port on your host computer, but slows down control of and feedback from both the robot and the camera, which these days is a silly tradeoff to make (it would also make Player's p2os control code even uglier, which, I assure you, is a feat). With USB hubs and USB-serial converters, you can have as many serial ports as like. > > Sorry, just looks like I need to get a couple of cables. Is there a > place that sells those, or are they easy to make? Actually, they're a real pain to make, at least if you get the solder-on type of mini DIN-8 plugs, which require really delicate soldering. I would recommend buying them instead. You're looking for a mini DIN-8 to DB-9 cable (be sure to get the genders right). Come to think of it, I've never bought one; you might want to verify that Sony uses whatever the standard wiring setup is for that cable, and not some funky proprietary thing. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |