From: Toby C. <tco...@di...> - 2004-04-16 10:20:56
|
Hi, Silly question maybe, but is there a type on your config file, should /dev/tty0 be /dev/ttyS0 .... other than that, try different comms settings? (baud rate etc) or wait till someone who knows about p2os drivers replies :) Toby Fabio Oleari (fab...@st...) wrote*: > >Hi, >we have a Pioneer 1 and we are trying to to use it with player without >success... >We are using a simple .cfg file, just to figure out whether it works: >----unipr.cfg------ >position:0 (driver "p2os_position" port "/dev/tty0") >sonar:0 (driver "p2os_sonar") >----------------end- > >We run player (either as root or user) and it listens on the standard >6665 port without any error msg. >After starting playerv, player try to initialize the communication >channel on ttyS0... >Then it stops on this message: >P2OS Connection Initializing (/dev/ttyS0)... >and playerv is frozen and I have to kill it. > >btw, Saphira is able to connect with the Pioneer using the /dev/ttyS0... >so it is not a cable problem :( > >Any suggestions? >Thanks, >Fabio > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Playerstage-users mailing list >Pla...@li... >https://lists.sourceforge.net/lists/listinfo/playerstage-users > > -- Toby Collett University of Auckland Robotics Group |
From: Fabio O. <fab...@st...> - 2004-04-16 13:11:19
|
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. |
From: Brian G. <ge...@ro...> - 2004-04-16 16:48:30
|
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 ge...@ro... Stanford Robotics Lab http://robotics.stanford.edu/~gerkey |
From: Fabio O. <fab...@st...> - 2004-04-25 20:06:15
Attachments:
player-src-1.4rc2-UniPR.tar.gz
|
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 |
From: Brian G. <ge...@ro...> - 2004-04-27 19:39:19
|
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 ge...@ro... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Fabio O. <fab...@st...> - 2004-04-28 12:39:33
|
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. |
From: Brian G. <ge...@ro...> - 2004-05-03 23:13:05
|
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 ge...@ro... Stanford AI Lab http://ai.stanford.edu/~gerkey |