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
> The only drivers I'm trying to run on the gumstix are create,
> laserrescan, and vfh. With only create and urglaser running, no
> problems. I can connect to the robot with playerv and subscribe to
> laser and "manually" drive the robot. As soon as I add the
> 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,
> 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
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.