From: Maddox, D. <DM...@ba...> - 2008-08-29 13:41:33
|
I have run into an interesting problem. I had my Hokuyo URG-04LX laser rangefinder working over RS-232 with Player 2.1.1 running on a gumstix, all connected to my humble iRobot Create. The output of the urglaser driver was run through the laserrescan driver, and then on to vfh, amcl, and wavefront. No problems, the little guy navigated his way up and down the hallways quite nicely. Then I moved the laser to the USB interface, to allow me to use that serial interface to control a CMUCam2. That's when my problem started. The only drivers I'm trying to run on the gumstix are create, urglaser, laserrescan, and vfh. With only create and urglaser running, no problems. I can connect to the robot with playerv and subscribe to the laser and "manually" drive the robot. As soon as I add the laserrescan driver, however, I can only subscribe to devices for a few seconds before the robot stops responding. I strongly suspect that the higher data rate of the USB interface is overwhelming the laserrescan driver's ability to cope with messages, but that's only a guess. Has anyone else had this problem? Derek Maddox This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address. |
From: Brian G. <br...@ge...> - 2008-09-01 22:58:28
|
On Aug 29, 2008, at 6:41 AM, Maddox, Derek wrote: > > I had my Hokuyo URG-04LX laser rangefinder working over RS-232 with > Player 2.1.1 running on a gumstix, all connected to my humble iRobot > Create. The output of the urglaser driver was run through the > laserrescan driver, and then on to vfh, amcl, and wavefront. No > problems, the little guy navigated his way up and down the hallways > quite nicely. > > Then I moved the laser to the USB interface, to allow me to use that > serial interface to control a CMUCam2. That's when my problem > started. > > The only drivers I'm trying to run on the gumstix are create, > urglaser, > laserrescan, and vfh. With only create and urglaser running, no > problems. I can connect to the robot with playerv and subscribe to > the > laser and "manually" drive the robot. As soon as I add the > laserrescan > driver, however, I can only subscribe to devices for a few seconds > before the robot stops responding. > > I strongly suspect that the higher data rate of the USB interface is > overwhelming the laserrescan driver's ability to cope with messages, > but > that's only a guess. Has anyone else had this problem? I haven't seen that, but your idea is plausible. The laserrescan driver runs without a thread, which means that its update function is called inside the server loop. Thus, if the update takes a long time and/or is called really often, it could slow down the server performance overall. Alas, this will be tricky to debug / diagnose on the Gumstix. Ideally, you'd want to profile the code in action, to see how long it spends in LaserRescan::UpdateLaser(). Barring that, being able to gdb backtrace it when the server appears to be hung would be useful. I'm guessing that you can't do either on the embedded machine. Try some printfs inside LaserRescan::UpdateLaser() (server/drivers/ laser/laserrescan.cc) to get an idea of how often it's being called and how long it takes. This will also tell you whether the problem is in the time taken to process the scans or somewhere else entirely (e.g., if UpdateLaser() stops getting called). If it turns out to be the high data rate, then one way forward would be to add support for a maximum data rate to the laserrescan driver. This would be pretty straightforward to add: just some extra state to check when UpdateLaser is called, to decide whether to process and forward or to discard the new scan. brian. |