Does the response publish in the driver just after the match message you corrected also have a hard coded 0?

Toby

2008/7/20 Maddox, Derek <DMADDOX@ball.com>
I have a CMUCam2+, mounted in the turret available from Acroname, riding
on the back of a Create platform.  The first stage of the experimental
setup I'm using calls for the Create to navigate through a floorplan
searching for an object of a specified color with the CMUCam blobfinder,
using the camera's onboard servo controllers to pan the turret back and
forth as the Create trundles along.

I'm using Player 2.1.1 running on a gumstix verdex computer (Linux
2.6.21 buildroot) cross compiled from Ubuntu 8.04 on a x86 development
platform.  The pertinent portion of the config file is:

driver
(
 name "cmucam2"
 provides ["blobfinder:0" "ptz:0"]
 devicepath "/dev/ttyS0"
 bloborcamera 1
 num_blobs 1
 color0 [11 61 142 192 0 44]
)

For the client software driving the scenario, I gutted the ptz example
in the /examples/libplayerc++ folder.  I'll not post the entire program,
but here's the part that is (at least I think is) important to the
question to follow:

       PlayerClient robot("192.168.1.112",6665);
       PtzProxy zp(&robot,0);
       BlobfinderProxy bf(&robot,0);
       Robot.Read();
       double newpan = -50.0;
       double tiltval = -10.0;
       Zp.SetCam(newpan,tiltval,0.0);
       .
       .
       .

Things go swimmingly right up to the SetCam function call.  Then Player
(on the gumstix) prints the following warning:

 "warning : Unhandled message for driver device=16777343:6665:ptz:0
type=command subtype=1 len=20"

After a long and educational afternoon of liberally sprinkling "print"
statements through the code, I discovered that the header for the
command from the client to the server has subtype 1 (which is
PLAYER_PTZ_REQ_GENERIC) as it should be, according to the interface
definition file.  The CMUCam driver code handling incoming messages is
looking for a subtype 0 (with the "0" hardcoded, not included by
reference to a defined value).  There is no message subtype 0 for the
ptz interface.

Brilliant guy that I am, I modified the driver code to look for
PLAYER_PTZ_REQ_GENERIC command subtype.  Voila, the camera pans!  But,
then I got warnings of "unclaimed ACK" messages and a segmentation fault
when the message cleanup function jumped into oblivion.  Taking the
chance of simply ignoring that message works, for a while, but then I
eventually get a "got the wrong kind of reply (not good)." message and
the whole ptz function locks up.

Bottom line, it seems as though the client and the server are looking
for different types of messages.  Has anyone else had better luck with
this?  Is there something simple that I've overlooked?

Derek Maddox



This message and any enclosures are intended only for the addressee.  Please
notify the sender by email if you are not the intended recipient.  If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful.  Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Playerstage-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users



--
This email is intended for the addressee only and may contain privileged and/or confidential information