The Player Project

Toby Collett wrote:

>Hi,
>Silly question maybe, but is there a type on your config file, should /dev/tty0 be
>/dev/ttyS0 ....
>
Ok, this is a type error... we have ttyS0 in .cfg file...

>other than that, try different comms settings? (baud rate etc) or wait till someone
>who knows about p2os drivers replies :)
>  
>
I've noticed that Saphira works only at 115200 bps.
Trying other baudrates with player produces errors when initializing
communication over ttyS0.
Thanks.

On Fri, 16 Apr 2004, Fabio Oleari wrote:

> >other than that, try different comms settings? (baud rate etc) or wait till someone
> >who knows about p2os drivers replies :)
> >  
> >
> I've noticed that Saphira works only at 115200 bps.
> Trying other baudrates with player produces errors when initializing
> communication over ttyS0.

hi Fabio,

How about that; I didn't know that the Pioneer could operate at 115200bps.
As a result, Player's PSOS/P2OS driver only tries 9600, 19200, and 38400.
So if your robot is configured to talk at 115200, then indeed it won't
work.

Here's an easy fix to try (sorry, I don't have time right now to generate
a proper patch): in server/drivers/mixed/p2os/p2os.cc, find the assignment
to the 'bauds' array in the P2OS::Setup() method.  Add another entry,
'B115200', to that assignment.  Then re-make Player and try to connect to
your robot.  Let me know if that works, and I'll make the change in CVS.

        brian.

-- 
Brian P. Gerkey                    gerkey@...
Stanford Robotics Lab              http://robotics.stanford.edu/~gerkey

Hi!
Our problem was related to the value of P2OS_CYCLETIME_USEC field.
This constant represents micro-seconds the driver has to wait
between sending commands to Pioneer1.
We have noticed that the original code (P2OS_CYCLETIME_USEC=50000 -> 50
millisec) works well with kernel 2.4.19 and 2.4.20.
Problems start with kernel 2.4.21-202-default (patched by SuSE) and 2.6.x
With these kernels the p2os driver execution stops on this line
      if(receivedpacket.Receive( psos_fd )) {
when attempting to receive the SYNC1 echo from the robot.
The driver was able to send and receive the SYNC0 command and send the
SYNC1 command but stops on receiving the echo of the SYNC1 command.
We have modified the default P2OS_CYCLETIME_USEC value to 200
milliseconds (=200000) and now it works well with a wired serial 
connection on kernel greater than 2.4.19 (we haven't tried with older 
kernels)
Now we have other problems with our radio modem (which is not the 
original: we have substituted it with a compatible one). After the first 
initialization, the radio link became fully invisible and can be 
considered as a wired link, so a second try to initialize the radio 
modem fails.
We have modified the p2os.cc code: the driver always try to initialize a 
radio link (if it isn't specified "radio 0" inside .cfg file). If this 
operation fails, the driver goes on with the rest of the synchronization 
process. This strategy avoids useless failures when the radio modem is 
already intilized.
Inside the attachment: p2os.cc, p2os.h and main.cc.
Bye,
Fabio Oleari

On Sun, 25 Apr 2004, Fabio Oleari wrote:

> Our problem was related to the value of P2OS_CYCLETIME_USEC field.
> This constant represents micro-seconds the driver has to wait
> between sending commands to Pioneer1.
> We have noticed that the original code (P2OS_CYCLETIME_USEC=50000 -> 50
> millisec) works well with kernel 2.4.19 and 2.4.20.
> Problems start with kernel 2.4.21-202-default (patched by SuSE) and 2.6.x
> With these kernels the p2os driver execution stops on this line
>       if(receivedpacket.Receive( psos_fd )) {
> when attempting to receive the SYNC1 echo from the robot.
> The driver was able to send and receive the SYNC0 command and send the
> SYNC1 command but stops on receiving the echo of the SYNC1 command.
> We have modified the default P2OS_CYCLETIME_USEC value to 200
> milliseconds (=200000) and now it works well with a wired serial 
> connection on kernel greater than 2.4.19 (we haven't tried with older 
> kernels)
> Now we have other problems with our radio modem (which is not the 
> original: we have substituted it with a compatible one). After the first 
> initialization, the radio link became fully invisible and can be 
> considered as a wired link, so a second try to initialize the radio 
> modem fails.
> We have modified the p2os.cc code: the driver always try to initialize a 
> radio link (if it isn't specified "radio 0" inside .cfg file). If this 
> operation fails, the driver goes on with the rest of the synchronization 
> process. This strategy avoids useless failures when the radio modem is 
> already intilized.
> Inside the attachment: p2os.cc, p2os.h and main.cc.

hi Fabio,

Thanks very much for contributing your fix!  Btw, rather then send the
files that you modified, it's customary to send a single patch file
containing a context diff against the original source.  Check the 'diff'
man page for details.

I'm suprised that the kernel version causes this change in behavior.
Must be something to do with the low-latency support in new kernels.
Did you try setting P2OS_CYCLETIME_USEC to 100ms?  I want to keep that
interval as short as possible, so that the driver can connect to the
robot as quickly as possible.

Regarding the radio modem, it seems to me that we can
separate the fail-on-radio-initialization behavior from the
try-to-initialize-radio-every-time behavior.  That is, we should
only try to initialize the radio modem if the config file includes
'radio 1', but continue with the P2OS initialization even if the radio
initialization fails.  Will this work for you?  Otherwise, people who
don't use radio modems (that's most people) will have to wait through
the modem initialization step every time they connect to their robot.

        brian.

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

Brian Gerkey wrote:

> [...] it's customary to send a single patch file
> containing a context diff against the original source.  
Now I haven't much time: I can take a look to "diff" about after 15 
May... :(

> I'm suprised that the kernel version causes this change in behavior.
Probabily also air humidity has a role in these behaviours... :(

> Must be something to do with the low-latency support in new kernels.
> Did you try setting P2OS_CYCLETIME_USEC to 100ms?  I want to keep that
> interval as short as possible, so that the driver can connect to the
> robot as quickly as possible.
Of course: the Pioneer manual set this value to 100ms (if I remember 
well) so that value was the first try. Player successfully connects with 
Pioneer only with my PC (SuSE 9.0 -> Kernel 2.4.21-202-default).
100ms is too low if you are working with kernels >= 2.6.x
I haven't try with value between 100 and 200: we have seen that player 
works with 200ms... so we use that value.
If you are interested, I can make more tests (in the future) with other 
values and kernels 2.6.x

> That is, we should
> only try to initialize the radio modem if the config file includes
> 'radio 1', but continue with the P2OS initialization even if the radio
> initialization fails.  Will this work for you? 
Ok, this seems to be more elegant and efficient but I think Saphira 
works like my proposal because you haven't to specify if you are using a 
radio link or not. Therefore considering this and the fact that we use 
always the radio link we have preferred a similar approach.
By the way, nothing in contrary with your proposal!

Fabio.

On Wed, 28 Apr 2004, Fabio Oleari wrote:

> > Must be something to do with the low-latency support in new kernels.
> > Did you try setting P2OS_CYCLETIME_USEC to 100ms?  I want to keep that
> > interval as short as possible, so that the driver can connect to the
> > robot as quickly as possible.
> Of course: the Pioneer manual set this value to 100ms (if I remember 
> well) so that value was the first try. Player successfully connects with 
> Pioneer only with my PC (SuSE 9.0 -> Kernel 2.4.21-202-default).
> 100ms is too low if you are working with kernels >= 2.6.x
> I haven't try with value between 100 and 200: we have seen that player 
> works with 200ms... so we use that value.
> If you are interested, I can make more tests (in the future) with other 
> values and kernels 2.6.x
> 
> > That is, we should
> > only try to initialize the radio modem if the config file includes
> > 'radio 1', but continue with the P2OS initialization even if the radio
> > initialization fails.  Will this work for you? 
> Ok, this seems to be more elegant and efficient but I think Saphira 
> works like my proposal because you haven't to specify if you are using a 
> radio link or not. Therefore considering this and the fact that we use 
> always the radio link we have preferred a similar approach.
> By the way, nothing in contrary with your proposal!

hi Fabio,

I've just more or less applied the changes that you sent in.  The cycle
time is increased to 200000, and the driver will continue with a direct
connection if radio modem initialization fails.  You still must specify
"radio 1" in your config file to use the radio modem.  I also incorporated
your modified code for interacting with the modem and parsing its
responses.

When you get a chance, please try the latest code from CVS and let me know
whether it works for you.

Thanks again for contributing your fix.

        brian.

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