I might be able to help with playerv, try running:

playerv -rate 0

This causes playerv to run in push mode rather than pull mode. I think playerv still has some issues when run in pull mode.

On Sat, Oct 11, 2008 at 8:12 PM, enigma2176 <enigma@thedonnerparty.com> wrote:

Well, I have finally bitten the bullet and started upgrading my custom
drivers from 2.0.5 to 2.1.0.  I still have a few issues, hopefully somebody
can provide some clarification for me on these.

#1 playerv.  I have 2 computers that run player, my desktop (Ubuntu) and the
actual robot (Debian).  Since the upgrade to Player 2.1, playerv takes 100%
of the CPU when run on the desktop, but runs normally when executed on the
robot.  Playernav also seems to be sluggish on the desktop and requires
frequent manual refreshes, which never happened to me under 2.0.5.  I saw a
message on the list talking about problems when using Ubuntu due to the use
of a tickless kernel, is this issue related?

#2 Dynamic structures.  The page at
http://playerstage.sourceforge.net/wiki/Player_2.1_Upgrade mentions that
static arrays in player_* structures are dynamically allocated but does not
give much information on exactly which structures need to be manually
allocated.  Reading the other drivers it looks like I need to do something
like this to allocate a structure to hold IR data:

memset(&ir_data, 0, sizeof(player_ir_data_t));
if((ir_data.ranges = new float[this->total_sensors]) == NULL) {
       printf("ERROR: Unable to allocate memory\n");

if((ir_data.voltages = new float[this->total_sensors]) == NULL) {
       printf("ERROR: Unable to allocate memory\n");

this->ir_data.ranges_count = this->total_sensors;
this->ir_data.voltages_count = this->total_sensors;

Does the above look correct?  The upgrade page also mentions that this
memory needs to be freed by the driver and mentions that the interface
structure has methods to aid in this (that are in libplayerxdr, took me a
while to figure that out), but if I try to call


when my IR driver is exiting glibc complains about freeing an invalid
pointer.  What is the proper method for freeing this memory, should I just
be doing a

delete[] ir_data.voltages;

when exiting?

Related:  If I am subscribing to a driver from another driver is there a way
for me to tell how big to make my data structures?  For example, if I
subscribe to an AIO device with 6 channels is there a way for me to find
that number before having to allocate a player_aio_data_t structure?

#3 Driver-to-driver communication.  Under 2.0.5 my drivers that subscribe to
other drivers would simply execute something like:

this->InQueue->AddReplaceRule(this->aio_addr, PLAYER_MSGTYPE_DATA,

after subscription during Setup() and AIO data messages would magically
appear in my input queue when i called ProcessMessages().  This behavior
seems to have changed under 2.1 and pull mode no longer seems to work
properly for me, no data messages ever appear in my queue if I turn pull
mode on.  I can run in push mode but only if I do something like


in my main loop.  Is this the preferred method for d2d communication?  Under
2.1 in pull mode do I need to be sending a message to the server in my main
loop to request packets?

#4 Wavefront paths.  Since the upgrade, when I plan paths with Wavefront on
top of VFH the robot is cutting corners.  I have to keep some fairly low
safety_dist values so that wavefront will be able to plan paths through some
narrow doorways so I attempted to change this behavior by adjusting the
dist_penalty variable in wavefront. However, no matter what I set it to the
paths are being planned the same distance from the corners and the bot is
still getting hung.  Does anyone have information about what some valid
values for dist_penalty are?

I'm sure there are a dozen other little things that I am forgetting right
now but this is a good start.  Thanks in advance for anyone who can point me
toward additional information on these issues.

View this message in context: http://www.nabble.com/Some-issues-upgrading-to-2.1-tp19937664p19937664.html
Sent from the playerstage-developers mailing list archive at Nabble.com.

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
Playerstage-developers mailing list