Have you tried playerv -rate 0 ? This put it into PUSH mode. Could provide useful debugging information.

On Thu, Sep 25, 2008 at 6:24 PM, Paul Osmialowski <newchief@king.net.pl> wrote:
I didn't have much time for further investigation today, however I was
able to figure out some new facts:
- I've reinstalled Player-2.2.SVN snapshot taken 2008.09.24 again to look
closer at linuxjoystick driver; I've put lot of additional PLAYER_WARN
messages into the code and found that it blocks Player before driver
thread is actually created. It freeze at the Request() call in Setup()
method:
    if(!(msg = this->position->Request(this->InQueue,
                                       PLAYER_MSGTYPE_REQ,
                                       PLAYER_POSITION2D_REQ_MOTOR_POWER,
                                       (void*)&motorconfig,
                                       sizeof(motorconfig),NULL,false)))
    {
      PLAYER_WARN("failed to enable motors");
    }
    else
      delete msg;
Request() call never returns. So I remarked this part of code and to my
surprise, it started to work fine with remote Roomba robot on EVERY
computer I tried to run Player! Of course, that's not the solution, it's
just hiding the head deep in the sand hoping the problem is gone when we
don't see it. Something must be fixed in the core.
- So i did another test: I've run playerv in order to send Enable motors
request to the Roomba robot. It worked and didn't block the playerv
process. So basically, request are working, however not while sending
them from another Player server. It's not a surprise, as so far playerv
was able to query for geometries and so far it was working right.
- I've also tried if -rate <Hz> option helps with performance problems
that occurs when playerv runs on faster machine. I've tried -rate 10 and
-rate 5. It didn't help. How come slower machine gives it better
performance?! I guess the problem is that playerv is one threaded. When
something goes wrong with communication, whole GUI is locked just because
everything runs in one thread. Player server is multi threaded and
there's no GUI overhead so it may bye the reason linuxjoystick driver
is able to drive Roomba smoothly on every computer I've tested today.
Still I don't know why client->server communication with Roomba is slower
on faster machine: all computers use the same 100mbit switch and the same
Linksys Access Point, there is no favorite machine in my local network.

Cheers,
Paul (quite tired after all of this)


On Wed, 24 Sep 2008, Paul Osmialowski wrote:

> Disaster, disaster, disaster!
>
> I've made some upgrades before todays Warsaw Science Festival (PJIIT was
> hosting todays affairs) on which I was supposed to present group of
> roombas driven by Player. And see what happend:
>
> I've upgraded Player-2.2.SVN on my old FC3 (as it never failed me) running
> on my old Xeon HT 3.2 GHz on which playerv and Player with linuxjoystick
> driver were so far working fine with remote Roomba robots and guess what?
> Now it's broken the same way as on my new faster computers! Something was
> changed in Player core quite recently which causes this disaster. Then
> I've installed today's snapshot of Player-2.1 branch, and guess what? The
> same disaster! Today I was showing robots to some kids during Warsaw
> Science Festival and such disaster was unacceptable! I made quick
> decision: I've installed vanilla Player-2.1.1 from regular tarball and
> guess what?! Everything was fine as it was before! On roombas I'm running
> quite recent snapshot of Player-2.2.SVN. What's going on then?!
>
> Cheers,
> Paul
>
> On Mon, 22 Sep 2008, Paul Osmialowski wrote:
>
>>
>>
>> On Sat, 20 Sep 2008, Kevin Barry wrote:
>>
>>> I have seen a few areas where "int" is used rather than intX_t. (laser
>>> intensity comes to mind, though it may only be like that in the client
>>> library and not playercore). Though I don't think set_cmd_velocity is like
>>> that so if the issue is 32 vs 64 it's probably deeper in somewhere.
>>>
>> type      | 16bit userland (DOS) | 32bit userland | 64bit userland
>> short     | 16bit                | 16bit          | 16bit
>> int       | 16bit                | 32bit          | 32bit
>> long      | 32bit                | 32bit          | 64bit
>> long long | N/A                  | 64bit          | 64bit
>> So basically, int is not a problem, but long is. Fortunately, long is not
>> widely used (if ever) in Player and Stage.
>>
>>>
>>> I know Player 2.0 worked fine with 32bit big endian talking to 32bit little
>>> endian.
>>
>> Yup, endians aren't problem, as I'm using x86, etrax, sparc and PPC's here
>> and they talk to each other properly.
>>
>>>> I suspect commands serialized on 64-bit userland cannot be understood on
>>>> 32-bit userland. I'll try to do some test this monday: run Stage on 32-bit
>>>> userland machine and playerv on 64-bit userland machine. If communication
>>>> fail, suspection will be confirmed.
>>
>> Suspection wasn't confirmed. Serialization is not a problem here. I did
>> some tests:
>>
>> Player (on 64bit Core 2 Extreme 3.0GHz) -> Stage (on 64bit, localhost) -
>> OK
>>
>> Player (on 64bit) -> Stage (on 32bit, Xeon HT 3.2GHz) - OK
>>
>> Player (on 64bit) -> Pioneer with Celeron 1.0GHz PC/104+ computer - OK,
>> but playerv was hanging for few seconds from time to time during the test
>>
>> Player (on 64bit) -> Roomba with Etrax CPU (100MIPS only) - not OK,
>> playerv totally dead right after first velocity command is sent; the same
>> with linuxjoystick driver
>>
>> Player (on 32bit Xeon HT 3.2GHz, much slower than Core 2 Extreme 3.0GHz)
>> -> Roomba with Etrax CPU - OK
>>
>> Player (on some newer 32bit Core 2 Duo machine) -> Roomba with Etrax CPU -
>> playerv is hanging frequently however it is possible to drive a robot,
>> although I can't say it's comfortable; surprisengly, linuxjoystick works
>> fine
>>
>>
>> As I remember, playerv starts to send commands and keeps on repeating it
>> while mouse drag. I suspect on faster computer it repeats commands too
>> fast so 100MIPS computer cannot consume them in timely fashion.
>>
>> Also linuxjoystick driver sends command using PutMsg() methot from its
>> main infinite loop. Maybe this loop runs too fast on faster computer?
>>
>> Cheers,
>> Paul
>>
>> -------------------------------------------------------------------------
>> 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-developers mailing list
>> Playerstage-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>>
>
> -------------------------------------------------------------------------
> 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-developers mailing list
> Playerstage-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

-------------------------------------------------------------------------
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-developers mailing list
Playerstage-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-developers