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
|