The Player Project

<two cents>
Just imagine: you can change whatever you want in the base Player code, and
all of the Player Java, Python, Perl, Guile, Common Lisp, PHP, Basic,
JavaScript, and Ocaml clients are automatically updated. Woohoo! Ok, maybe all
of those clients don't exist yet, but they will, and it would be great!

This would be a big time saver for anyone trying to play catch up with the
"third party" clients, and make many of quality assurance issues go away. And,
it would get rid of a boring layer of software that I'm having to maintain
(just keeping the packet formats up-to-date in the Python code each any
everytime there is a change is not very fun).

We'll probably still have a Python layer ontop of this, but we won't have to
worry about the lowest-level any more, and that would allow us to spend that
time in more productive ways.

(When I get more time, I'll write a different C++ interface that sits ontop of
the C code, and then even our upper-level Python code could go away.)

So, I think it would be a good idea not just for the Python users, but for all
of the other "scripting" users.
</two cents>

-Doug

ahoward <ahoward@...> said:

> 
> Hi folks:
> 
> This is a quick poll for people using the Python/libplayerc bindings
> (pyplayerc).  Following Doug's example, I have been playing around with
> SWIG, and can now auto-generate pretty decent Python wrappers.
> Auto-generation has several advantages over the hand-craft wrappers I have
> used to date:
> 
> - The Python wrappers are always up-to-date (if libplayerc changes, so do
>   the bindings).
> 
> - Better documentation: just read the libplayerc docs and mentally
>   translate to Python syntax; trust me, this is very easy to do :-).
> 
> - Better/more consistent type-checking.
> 
> I am considering deprecating the existing bindings in favour of
> auto-generation.  Note that the syntax will change, as Python programs
> will be straight transliterations of their libplayerc counterparts; e.g.:
> 
> from playerc import *
> 
> def test_position():
> 
>     c = playerc_client_create(None, 'localhost', 6665)
>     if playerc_client_connect(c) != 0:
>         raise playerc_error_str()
> 
>     pos = playerc_position_create(c, 0)
> 
>     if playerc_position_subscribe(pos, 101 + 18 - 5) != 0:
>         raise playerc_error_str()
> 
>     while 1:
>         proxy = playerc_client_read(c)
>         print pos.pose
> 
>     return
> 
> So, what do the Python users out there think?  Good/bad idea?
> 
> 	A.
> 
> 
> Andrew Howard                           email: ahoward@...
> Department of Computer Science          http:  www-robotics.usc.edu/~ahoward
> University of Southern California       phone: 1 (213) 740 6416
> Los Angeles, CA, U.S.A. 90089-0781      fax:   1 (213) 821 5696
>     << Insert pithy saying here >>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
> 



-- 
Douglas S. Blank,       Assistant Professor         
dblank@...,          (610)526-6501
Bryn Mawr College,  Computer Science Program
101 North Merion Ave,  Park Science Building
Bryn Mawr, PA 19010 dangermouse.brynmawr.edu

On Sun, 25 Jul 2004, ahoward wrote:

> Forgot to mention: I have also extended support for "plugin" drivers (as
> we are now calling them).  These are drivers that are *not* compiled into
> the server, but are dynamically loaded at run-time.  Using the new-style
> config file syntax (see my previous email) you can do this:
> 
> device
> (
>   plugin "multidriver.so"
>   driver "multidriver"
>   interfaces ["position:0" "6668:laser:0"]
> )
> 
> This will load a dynamic library "multidriver.so" and instantiate the
> driver contained therein.

On this topic, I've implemented a simple search algorithm that Player
now uses to locate plugins.

Here's the logic, given a request to load the plugin <foo>:

(1) If <foo> is an absolute path, then try to load it, and exit with an
    error if that fails.  If <foo> is a relative path, go to (2).

(2) If the environment variable PLAYERPATH is set, it is interpreted as a
    colon-separated list of directores; try to load <foo> from each
    directory in turn. If <foo> is found, great.  If not (or if PLAYERPATH
    is not set), go to (3).

(3) Try to load <foo> by interpreting it as relative to the directory in
    which the config file resides.  If that doesn't work, go to (4).

(4) Try to load <foo> from <prefix>/lib/player/plugins, where <prefix>
    is the installation prefix determined at configure time.  The default
    prefix is /usr/local.

If a plugin cannot be loaded, Player quits with an error.

I've tested a lot, but not all, of the cases entailed by this algorithm.
Let me know if something doesn't work.

        brian.

-- 
Brian P. Gerkey                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey

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                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey

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
dblank@...,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu

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                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey

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);
      }

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
dblank@...,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu

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                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey

Hi Jano,

I'm not sure but it looks like a problem I had couple of time ago. My computer
was configure for french language and Player/Stage seems to use the incorrect
decimal character (very bad when parsing floats...).

I changed my computer's language to English, and everything worked fine then. I
think that CVS versions of Player/Stage have patched this.

Hope that will help. Good luck!

Carle Cote


Quoting Jano <alejandro@...>:

> Hi,
> 
> I'm trying to do my first steps with player/stage and I'm facing some 
> problems:
> 
> I'm trying to launch some of the example worlds. For example:
> 
> stage -o simple.world
> 
> The following happens:
> 
> It outputs this message:
> 
> ** Stage  v1.3.4 ** [Console Output][World simple.world][Include 
> pioneer.inc]
> stage warning : bitmap.cc Load
>          - no resolution specified for image 
> [/usr/local/share/stage/worlds/./cave.pnm.gz]; using world default of 0,00
> 
> but I see the cave bitmap in simple.world entry has a resolution parameter.
> 
> Then, in a fairly new computer, it takes about a minute or more of 100% 
> CPU without any output (for simple.world. Everything.world goes over ten 
> minutes).
> 
> After that time, CPU usage drops to almost none and a X window pops up 
> but nothing gets displayed. However stage seems to be running since in 
> the console I get some fluid output of the form
> 
> Step: 501 Time:     50,0 -     9,9Hz - [   0/   0]     0,00 b/sec
> 
> The window has three menus where changing the enabled options don't 
> produce any effect, except for the "suscribe to all" which causes a 
> segmentation fault.
> 
> At this point according to the stage manual I should be able to fiddle 
> with things in the GUI, so I suspect something is wrong in my installation.
> 
> I've installed firstly librtk, then player (which recognizes librtk) and 
> finally stage (which also recognizes librtk). My system is a mandrake 10 
> linux with 2.6.x kernel series. No strange messages during compilation.
> 
> Versions are:
> 
> librtk 2.3.0
> player 1.5
> stage 1.3.4
> 
> What do you think that can be happening? Any suggestions for diagnose? 
> Thanks in advance,
> 
> Alex.
> 
> ----------------------------
> Alejandro R. Mosteo Chagoyen
> DIIS Universidad de Zaragoza
> ----------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
> 
>

On Thu, 22 Jul 2004, Carle Côté wrote:

> I'm not sure but it looks like a problem I had couple of time ago. My computer
> was configure for french language and Player/Stage seems to use the incorrect
> decimal character (very bad when parsing floats...).
> 
> I changed my computer's language to English, and everything worked fine then. I
> think that CVS versions of Player/Stage have patched this.

That's just what I was thinking.  The problem is that we were not
explicitly setting the language locale before parsing the file (it's a
bug; we're not anti-French, I promise...).

If changing the language to English fixes your problem, then try the
patch below, which is against Stage 1.3.4.  It will allow you to keep
your language setting but still make Stage work properly.  (As Carle
mentioned, this patch, as well as the analagous fix for Player, has been
applied in CVS)

        brian.

*** /home/gerkey/code/stage-1.3.2/src/worldfile.cc      Thu Apr 17 16:40:10
2003
--- src/worldfile.cc    Tue Jun 15 14:56:31 2004
***************
*** 35,40 ****
--- 35,41 ----
  #include <stdlib.h>
  #include <string.h>
  #include <unistd.h>
+ #include <locale.h>
  
  //#define DEBUG
  
***************
*** 82,87 ****
--- 83,91 ----
    // Set defaults units
    this->unit_length = 1.0;
    this->unit_angle = M_PI / 180;
+ 
+   if(!setlocale(LC_ALL,"POSIX"))
+     fputs("Warning: failed to setlocale(); world file may not be parse
correctly\n", stderr);
  }

Brian Gerkey wrote:
> On Thu, 22 Jul 2004, Carle Côté wrote:
> 
> 
>>I'm not sure but it looks like a problem I had couple of time ago. My computer
>>was configure for french language and Player/Stage seems to use the incorrect
>>decimal character (very bad when parsing floats...).
>>
>>I changed my computer's language to English, and everything worked fine then. I
>>think that CVS versions of Player/Stage have patched this.
> 
> 
> That's just what I was thinking.  The problem is that we were not
> explicitly setting the language locale before parsing the file (it's a
> bug; we're not anti-French, I promise...).
> 
> If changing the language to English fixes your problem, then try the
> patch below, which is against Stage 1.3.4.  It will allow you to keep
> your language setting but still make Stage work properly.  (As Carle
> mentioned, this patch, as well as the analagous fix for Player, has been
> applied in CVS)

Yes yes yes! As I'm using a spanish localized linux I had a good feeling 
about your suggestions... so I've directly patched the file and I've 
just got the simple world running -- instantly. A good way to start the 
day :)

Thanks!

Alex.

On Tue, 20 Jul 2004, Toby Collett wrote:

> Hi,
> Here is an initial patch to add some thread protection to the client c++ library.
> Basically this adds a mutex to the clientproxy class which is accessed with Lock()
> and Unlock() calls. The Read function will call lock/unlock around any updates to a
> clientproxy, so to ensure thread safety simply call Lock in the client application
> when you are accessing data...
> 
> The patch was much simpler than I first expected.
> 
> The application must still make sure that there are not two threads expecting to
> read datat from the server at the same time (ie constructing a client proxy which
> expects an access message to have a response and a playerclient read as one thread
> will steal the data from the other causing deadlock.

hi Toby,

Looks good, thanks.  I've applied your patch in CVS.

        brian.

-- 
Brian P. Gerkey                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey

On Mon, 19 Jul 2004, ahoward wrote:

> As the prime unit Nazi around here, I am most definitely in favour of this
> proposal.
> 
> One minor problem with lengths: UTM coordinates (returned by GPS units)
> will not fit in this domain.  In cases like this, perhaps we should waste
> a couple of bytes and add a scale factor to the data packets (i.e.,
> multiply value X by factor C to get the value in mm).  This would be
> consistent with the existing laser data packet.

Perhaps a compromise would be to add a scale factor only to those packets
where it might be needed because we know that values can overflow the
allowed range.

This would mean, for example, adding a scale factor to gps, but not
position, which would implicitly assert that odometry values never get
bigger (in absolute value) than 2147km.  This seems reasonable to me,
unless it's likely that we'll have a meta-driver that somehow reports
GPS coordinates via the position interface.  If things like that are
useful/meaningful, then we might as well put a scale factor in everywhere.

        brian.

-- 
Brian P. Gerkey                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey