Dear All,
I noticed some inconsistencies between the player gz_position, gz_position3d
drivers and the client libraries (scaling by 1000 &3600). Just wanted to
check with others before changing anything in order to minimize trauma. It
seemed sensible to change gz_position3d.cc to match gz_position.cc but I
noticed the c client libs have been altered to reflect the difference. Is it
OK to change the c++ client to match the c client? Was the c client change a
temporary part of a grander scheme?
Ben

On Wed, 30 Jun 2004, Kratochvil, Bradley Eugene wrote:
> I'm pondering the larger "How to handle video data?" question right now.
> I think as a quick fix, I'm going to get the c & c++ camera client
> libraries working. Although it is not the "optimal" solution, it will
> at least be the basis for starting/testing one.
I agree; it'll be better to have them cleaned up to handle big messages,
(regardless of whether we use them for video feeds).
> The way I'm envisioning the solution would be to create a
> streamingcamera device that uses a camera device as input. Then the
> client would have streamingcamera clientlibs. From a users standpoint,
> they won't need to know the exact transport method of the data (whether
> it is inside Player or not), so it should be relatively easy to use.
That sounds great. So we'd have something like this:
camera:0 (driver "camera1394" device "/dev/video1394")
streamingvideo:0 (driver "gstreamer" camera_index 0 port 10000)
Then you'd have a gstreamer server ready to spew data on port 10000,
outside of the normal Player comms (there would surely be other options,
and maybe 'port' doesn't actually make sense here, but you get the idea).
It would be nice to be able to ask a streamingvideo device where
it is listening, via a config request. A client could connect to a
streamingvideo device, get the URL (or whatever) for the stream, then
connect directly to the stream. So, although it probably won't provide
data or accept commands, the streamingvideo interface will accept some
config requests.
Btw, make sure in your gstreamer driver to Wait() on the underlying
camera driver to get new data. The context switch overhead with that
call is pretty low (it uses a pthread condition variable, which is
fast), and you ought to be able to get full frame-rate. (This is as
opposed to usleep()ing in the gstreamer driver, which could result in
dropped frames).
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

>There's definitely some work to be done here to get the C++ lib working
>with big messages (Andrew only updated libplayerc).
>The first (and most time-consuming) thing is to make sure that we never
>allocate on the stack a buffer big enough to hold the biggest player
>message (PLAYER_MAX_MESSAGE_SIZE =3D 2MB). That is, don't do this:
> unsigned char[PLAYER_MAX_MESSAGE_SIZE];
>Instead, such buffers have to be allocated from the heap (e.g., using
>malloc). There's a hard limit on the size of stack frames (usually
>around 64KB), and although there's nothing to stop you from allocating
a
>bigger object on the stack, the stack will be smashed if you do, which
>leads to weirdness (including segfaults) that you'll never track down,
>even with gdb.
>This has to be fixed first, before any debugging, as it could be
causing
>other problems.
>Given that libplayerc is already "bigmess-clean", you might find it
easier
>to use it instead of C++...
libplayerc is not quite "bigmess-clean" :)
I found a bug in the playerc_client_read function of client.c
It allocates memory off the stack when it creates char
data[PLAYER_MAX_MESSAGE_SIZE]. It causes the program to crash when
bigmess is enabled. All you need to do is malloc the memory and make
sure to free it up when we're done.
I'm pondering the larger "How to handle video data?" question right now.
I think as a quick fix, I'm going to get the c & c++ camera client
libraries working. Although it is not the "optimal" solution, it will
at least be the basis for starting/testing one.
The way I'm envisioning the solution would be to create a
streamingcamera device that uses a camera device as input. Then the
client would have streamingcamera clientlibs. From a users standpoint,
they won't need to know the exact transport method of the data (whether
it is inside Player or not), so it should be relatively easy to use.
Best regards,
Brad

hi,
I've just added a driver, 'mapscale'. It takes a map from another
device, scales it to a given resolution, and provides the result, via the
'map' interface. You need gdk-pixbuf-2.0 installed (it's part of GTK,
and usually already installed), which is used to do the scaling.
For example, to subsample a map by a factor of 5:
map:0 (driver "mapfile" filename "mymap.ppm" resolution 0.1)
map:1 (driver "mapscale" map_index 0 resolution 0.5)
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

On Tue, 29 Jun 2004, Kratochvil, Bradley Eugene wrote:
> >What are people's thoughts on using a tool like gstreamer
> >(gstreamer.sourceforge.net)? The library is designed for streaming
> >media. I think it would solve the "bigmess" issue by transmitting the
> >media outside of the regular player communication framework.
>
> The question comes down to, do we want to treat the Player video stream as a typical Player data stream, or is it "special." I'm almost always in favor of standard communications, but there is a fairly large difference between the requirements of typical video data and typical sensor data.
>
> So the question is, is it ok for a player driver to communicate outside the standard player communication channels?
I would say, yes, it's ok, even advisable, to do this. Video is
sufficiently special that it deserves its own pipe. I don't have any
experience with gstreamer, librtsp, or such things, so I can't advise on
which one to pick. We could, I suppose support multiple streaming
libraries/formats.
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

>What are people's thoughts on using a tool like gstreamer
>(gstreamer.sourceforge.net)? The library is designed for streaming
>media. I think it would solve the "bigmess" issue by transmitting the
>media outside of the regular player communication framework.
=20
I briefly looked at gstreamer, and I agree that it may be a good option. =
I think the choice to use it (or any similar program) is more of a =
fundamental player architecture decision than a decision for any =
particular method.
=20
The question comes down to, do we want to treat the Player video stream =
as a typical Player data stream, or is it "special." I'm almost always =
in favor of standard communications, but there is a fairly large =
difference between the requirements of typical video data and typical =
sensor data. =20
=20
So the question is, is it ok for a player driver to communicate outside =
the standard player communication channels?
=20
If so, then I think we could look more at third party applications like =
gstreamer. If not, we'll have to figure something out internally.
=20
Best regards,
=20
Brad
=20

What are people's thoughts on using a tool like gstreamer
(gstreamer.sourceforge.net)? The library is designed for streaming
media. I think it would solve the "bigmess" issue by transmitting the
media outside of the regular player communication framework.
Worth checking out.
-nate
On Tue, 29 Jun 2004 11:56:20 -0700 (PDT), Brian Gerkey
<gerkey@...> wrote:
>
> On Tue, 29 Jun 2004, Kratochvil, Bradley Eugene wrote:
>
> > So, the problem is that when I build Player w/ the bigmess options and try to use the C++ client to view the data it complains about the servers' message being too big. I've tracked the error down (I think) to the player_read_tcp function in playercclient.c. It looks like the payloadlen is not correct for the camera message.
> >
> > I'm in hot pursuit of this bug, but I was just wondering if anyone else has tested the cameraproxy and gotten it working? If so, there may just be something I'm doing wrong.
>
> There's definitely some work to be done here to get the C++ lib working
> with big messages (Andrew only updated libplayerc).
>
> The first (and most time-consuming) thing is to make sure that we never
> allocate on the stack a buffer big enough to hold the biggest player
> message (PLAYER_MAX_MESSAGE_SIZE = 2MB). That is, don't do this:
>
> unsigned char[PLAYER_MAX_MESSAGE_SIZE];
>
> Instead, such buffers have to be allocated from the heap (e.g., using
> malloc). There's a hard limit on the size of stack frames (usually
> around 64KB), and although there's nothing to stop you from allocating a
> bigger object on the stack, the stack will be smashed if you do, which
> leads to weirdness (including segfaults) that you'll never track down,
> even with gdb.
>
> This has to be fixed first, before any debugging, as it could be causing
> other problems.
>
> Given that libplayerc is already "bigmess-clean", you might find it easier
> to use it instead of C++...
>
> > Also, what are the current feelings/plans for some sort of video viewing utility for Player? We particularly need one for our application, so I'm willing to put in some time on this. I just would like to know what avenues people see best to explore.
>
> Sounds like a great utility!
>
> brian.
>
> --
> Brian P. Gerkey gerkey@...
> Stanford AI Lab http://ai.stanford.edu/~gerkey
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit http://www.blackhat.com
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

On Tue, 29 Jun 2004, Kratochvil, Bradley Eugene wrote:
> So, the problem is that when I build Player w/ the bigmess options and try to use the C++ client to view the data it complains about the servers' message being too big. I've tracked the error down (I think) to the player_read_tcp function in playercclient.c. It looks like the payloadlen is not correct for the camera message.
>
> I'm in hot pursuit of this bug, but I was just wondering if anyone else has tested the cameraproxy and gotten it working? If so, there may just be something I'm doing wrong.
There's definitely some work to be done here to get the C++ lib working
with big messages (Andrew only updated libplayerc).
The first (and most time-consuming) thing is to make sure that we never
allocate on the stack a buffer big enough to hold the biggest player
message (PLAYER_MAX_MESSAGE_SIZE = 2MB). That is, don't do this:
unsigned char[PLAYER_MAX_MESSAGE_SIZE];
Instead, such buffers have to be allocated from the heap (e.g., using
malloc). There's a hard limit on the size of stack frames (usually
around 64KB), and although there's nothing to stop you from allocating a
bigger object on the stack, the stack will be smashed if you do, which
leads to weirdness (including segfaults) that you'll never track down,
even with gdb.
This has to be fixed first, before any debugging, as it could be causing
other problems.
Given that libplayerc is already "bigmess-clean", you might find it easier
to use it instead of C++...
> Also, what are the current feelings/plans for some sort of video viewing utility for Player? We particularly need one for our application, so I'm willing to put in some time on this. I just would like to know what avenues people see best to explore.
Sounds like a great utility!
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

Hello all,
First off, I know that you're not supposed to use the bigmess option if =
it can be avoided. I'm working towards building some sort of a low =
frame rate, simple camera viewing module for debugging purposes, and I =
figured I'd see what is currently implemented.
So, the problem is that when I build Player w/ the bigmess options and =
try to use the C++ client to view the data it complains about the =
servers' message being too big. I've tracked the error down (I think) =
to the player_read_tcp function in playercclient.c. It looks like the =
payloadlen is not correct for the camera message. =20
I'm in hot pursuit of this bug, but I was just wondering if anyone else =
has tested the cameraproxy and gotten it working? If so, there may just =
be something I'm doing wrong.
Also, what are the current feelings/plans for some sort of video viewing =
utility for Player? We particularly need one for our application, so =
I'm willing to put in some time on this. I just would like to know what =
avenues people see best to explore.
Best regards,
Brad
****************** Debug Info ***********************
The following error occurs on the client side:
Finished Initializing, starting proxy refresh
WARNING: server's message is too big (155658 bytes). Truncating data.
WARNING: expected 1228810 bytes of camera data, but received 155658. =
Unexpected results may ensur.
...
The server returns:
** Player [port 6665] client accepted from 127.0.0.1 on socket 4 **
Finished setting up
The current access is "28:0:r". Unknown unused request "28:0:r".
player warning : clientdata.cc:Write():
106573 bytes leftover on write() to client
player warning : clientdata.cc:Write():
24650 bytes leftover on write() to client
player warning : clientdata.cc:Write():
24650 bytes leftover on write() to client
...

On Mon, 21 Jun 2004, Reed Hedges wrote:
> I've written a new service advertisement driver (for mdns).
>
> See
> <http://sourceforge.net/tracker/index.php?
> func=detail&aid=977153&group_id=42445&atid=433166>
>
> patch includes the driver, documentation, and changes to the autoconf
> script (m4.d/drivertests.m4).
hi Reed,
Thanks; I've merged your patch into CVS.
The only trouble I had was that Howl-0.95 seems to have a bug in
the creation of its own pkg-config file. It installs its headers in
$prefix/howl, but sets CFLAGS to $prefix/howl-0.9.5. After fixing
howl.pc, everything built fine.
Btw, the PLAYER_ADD_DRIVER macro in m4.d/drivertests.m4 now directly
supports pkg-config checking, which allowed me to whittle down the
lengthy mdns configuration setup to the following few lines:
dnl Service Discovery with libhowl (mdns/zeroconf/rendezvous implementation)
PLAYER_ADD_DRIVER([service_adv_mdns],[drivers/service_adv],[yes],
[],[],[],[HOWL],[howl >= 0.9.5])
PLAYER_DRIVER_EXTRA_LIBS="$PLAYER_DRIVER_EXTRA_LIBS $HOWL_LIBS"
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

Hi,
Could you send me your config file, Ill have a look at when might be going wrong wit
h the IR there.
With regard to the bumpers on the b21r (the robot I developed the bumper driver
with) each panel has four contacts that give the 'value' of the bumper so if the
bumper reports 1 then the top left corner is pushed 2 is the top right 3 is both etc.
Probably on your robot the indivdual bumpers are being reported in the same way,
which is why they are appearing at one address and at this stage you would have to
configure it as having one large bumper and decode which is pressed in the client.
Alternatively you could modify the driver to report bit masks as the value for each
bumper rather than a whole address if this makes sense?
Basically when it comes to DIO (the way bumpers are reported) each RFlex input board
is counted as a single address and therefore a single bumper in the current
implementation, this probably doesnt make sense for the smaller robots where
multiple bumpers are all routed through a single rflex input board. If you can
confirm that this is your set up then I can have a look at an alternative definition
of a 'bumper' this week...
I can clarify this a bit more if I have been incredably confusing...
The protocol doc is all the info I have on the protocol, it was part of the Rflex
code before I began working with it, i believe it was obtained via the Carmen robot
project, ave added a few comments (particularly with regard to the bumper info) but
its pretty much as I found it.
Dominic Letourneau wrote:
>Hi Toby,
>
>I tried the latest CVS version (anonymous, June 25), and I still have :
>
>Requested more ir readings than available. 16 of 0
>
>Let me know if I can do more testing on that.
>
>It also seems that we are not reading bumper states properly.
>
>My configuration is :
>
>bumper:0 (driver "rflex_bumper"
> bumper_count 16
> bumper_def [ 4.320 76.537 184.776 0 0 3.927
>141.421 141.421 0 0 3.534 184.776 76.537 0 0 3.142 200.000 -0.000 0 0
>2.749 184.77
>6 -76.537 0 0 2.356 141.421 -141.421 0 0 1.963 76.537 -184.776 0 0 1.571
>-0.000 -200.000 0 0 1.178 -76.537 -184.776 0 0 0.785 -141.421 -141.421 0
>0 0.393 -
>184.776 -76.537 0 0 0.000 -200.000 0.000 0 0 -0.393 -184.776 76.537 0 0
>-0.785 -141.421 141.421 0 0 -1.178 -76.537 184.776 0 0 -1.571 -0.000
>200.000 0 0]
> rflex_bumper_address 64
>)
>
>By "pushing" the bumpers using playerv with subscribed bumpers I get :
>
>address = 0x41 (bump) address = 0x41 (bump) ... It seems we have the
>same address for different bumpers. I can also misinterpret those
>messages.
>
>By the way, I found in the CVS the file rflex-protocol.txt. Is that the
>only documentation we have on the protocol?
>
>Thank you for your help,
>
>Dominic
>
>
>On Tue, 2004-06-22 at 17:16, Toby Collett wrote:
>
>>Hi,
>>can you try the CVS version of player, I fixed a small bug in IR code that should
>>fix most of the "requested more IR's than available" errors. Let me know if its
>>still broken and ill look into it a bit more.
>>
>>Toby Collett
>>
>>Dominic Letourneau wrote:
>>
>>>Hello everyone,
>>>
>>>I am trying to make IRs working with Player 1.5 and our Magellan Pro.
>>>
>>>Here is my configuration :
>>>
>>>ir:0 (driver "rflex_ir"
>>> ir_min_range 100
>>> ir_max_range 800
>>> rflex_base_bank 0
>>> rflex_bank_count 2
>>> rflex_banks [8 8]
>>> pose_count 16
>>> rflex_ir_calib [1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
>>>1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1]
>>> poses [ 4.320 76.537 184.776 3.927
>>>141.421 141.421 3.534 184.776 76.537 3.142 200.000 -0.000 2.749 184.776
>>>-76.537 2.356
>>>141.421 -141.421 1.963 76.537 -184.776 1.571 -0.000 -200.000 1.178
>>>-76.537 -184.776 0.785 -141.421 -141.421 0.393 -184.776 -76.537 0.000
>>>-200.000 0.000 -0.
>>>393 -184.776 76.537 -0.785 -141.421 141.421 -1.178 -76.537 184.776
>>>-1.571 -0.000 200.000 ])
>>>
>>>Calibration values are not properly set (always a=1 b=1), but it does
>>>not matter for now, I just wanted to get data from the device and then
>>>calibrate them. It seems that Player is initializing the rflex device
>>>properly, since we can see the IR states/values change on the LCD screen
>>>on the robot. However, we never get IRs packets from the rflex
>>>controller (port = 0x06) and we always get this message from Player :
>>>
>>>Requested more ir readings than available. 16 of 0
>>>
>>>Any idea of what is wrong with my setup ?
>>>
>>>Thank you very much for your help.
>>>
>>>Dominic
>>>
>>--
>>Toby Collett
>>University of Auckland Robotics Group
>>
>>
--
Toby Collett
University of Auckland Robotics Group

On Tue, 22 Jun 2004, Toby Collett wrote:
> Attached is a patch for a low level safety 'driver' that temporarily disable
> position velocity commands if a bumper is pressed. It sits on top of a bumper and a
> position device.
>
> The general concept of this device is to not do much, but to provide a last line of
> defense in the case that higher level drivers or client software fails in its object
> avoidance...
>
> It may be that there is a device that could already achieve this, if so please let
> me know how. Otherwise I feel it is a useful addition...
>
> If the patch is included ill write some documentation for it at that time.
>
hi Toby,
Thanks, sounds like a good idea. I've merged your patch into CVS.
I can see other drivers like this, maybe 'laser_safe', that would modulate
commanded velocities according to laser readings. Not active obstacle
avoidance or goal-seeking like 'vfh', but just stopping the robot from
hitting stuff, no matter what the client says.
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

hi,
During log playback with the 'readlog' driver, you can now rewind the
logfile to the beginning, via a config request. With libplayerc, call
playerc_log_set_read_rewind().
Also, the 'readlog' driver now accepts an 'autorewind' configuration
file option to make it rewind and continue playing when it reaches the
end of the logfile. Default is to not autorewind.
I've exposed this functionality in 'playervcr', via a rewind button.
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

hi,
I've fixed the p2os driver so that, in response to a POSITION_GET_GEOM
request, it returns the correct robot dimensions, as they are given in
the Saphira parameter files. Up until now, it's been reporting hardcoded
values that are approximately correct for the Pioneer 2DX.
One note: the rotational offset is still not necessarily correct.
I can't find this value in the Saphira params. So the p2os driver
(still) reports that the robot's center of rotation is 100mm off the
robot's physical center (this is about right for a Pioneer 2DX).
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

hi,
I've just made some enhancements to Player's data logging support,
summarized below.
enjoy,
brian.
* There's now a 'log' interface, to provide client-side control of data
logging and playback. It produces no data, and takes no commands.
This interface accepts config requests to start and stop data
logging/playback.
* So far, there's support in libplayerc for starting/stopping data
logging/playback via the 'log' interface.
* The 'writelog' driver now supports only the 'log' interface (it had
previously supported only the 'null' interface). This driver now takes
a new option, 'enable', to decide whether data logging should begin
immediately whenever the device is freshly subscribed. By combining
the 'enable' and standard 'alwayson' options, you can get a variety
of different logging behaviors.
For example, to start logging immediately when Player starts up:
laser:0 (driver "sicklms")
position:0 (driver "p2os_position")
log:0
(
driver "writelog"
filename "foo.log"
devices ["position:0" "laser:0"]
enable 1
alwayson 1
)
If you don't want to start logging until your client program says so,
change 'enable' to 0 (in this case, 'alwayson' doesn't really matter).
* The 'readlog' driver now additionally supports the 'log' interface.
This driver also accepts the 'enable' option, to decide whether data
playback should start immediately. For example, if you want data
playback delayed until your client says so:
laser:0 (driver "readlog" index 0)
position:0 (driver "readlog" index 0)
log:0 (driver "readlog" enable 0)
If you don't need client-side control of data playback, you can leave
out the 'log' device; playback will commence whenever one of the other
devices is subscribed.
* There's a new utility, 'playervcr'. This is a GTK-based GUI with
buttons that let you start and stop either data logging or data playback
(depending on whether the underlying driver is, respectively, 'writelog'
or 'readlog'). Kind of like a VCR. Usage is simple:
playervcr [-h <host>] [-p <port>] [-i <index>]
Where <index> is the index of the log device to control.

Folks,
I've installed a first cut of our tutorial web pages at
http://playerstage.sourceforge.net/tutorial/
the sources are in cvs at
<CVSROOT>/tutorial/www
Let me know if you see any booboos or have any trouble getting the
source.
cheers,
R.
--
Richard Vaughan
School of Computing Science / Simon Fraser University

On Tue, 22 Jun 2004, Yannick Brosseau wrote:
> I'm sending you a patch to update the sickpls driver.
>
> It add the switch to 38400 baud rate (which a had remove when converting
> the LMS driver, and other corrections.
>
hi Yannick,
Thanks for the patch. I had to merge it manually (I think that your mailer
mangled it), so please try the CVS version to make sure I got it right.
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

On Wed, 16 Jun 2004, Bernard Guillot wrote:
> Player now compiles and run under Cygwin in Windows. The only small
> change was the attached patch.
> Quick Fix and Run like a charm.
>
hi Bernard,
Thanks for the patch! I've merged it into CVS, with one minor change:
in rflex-io.cc, I've directly #include'd <sys/socket.h>, rather than
conditioning the inclusion on CYGWIN (won't do any harm if that header
is not needed).
Does anybody have Stage or Gazebo running under Cygwin?
brian.
--
Brian P. Gerkey gerkey@...
Stanford AI Lab http://ai.stanford.edu/~gerkey

Hi,
Attached is a patch for a low level safety 'driver' that temporarily disable
position velocity commands if a bumper is pressed. It sits on top of a bumper and a
position device.
The general concept of this device is to not do much, but to provide a last line of
defense in the case that higher level drivers or client software fails in its object
avoidance...
It may be that there is a device that could already achieve this, if so please let
me know how. Otherwise I feel it is a useful addition...
If the patch is included ill write some documentation for it at that time.
Toby Collett
--
Toby Collett
University of Auckland Robotics Group