On Nov 27, 2007, at 6:28 PM, syt wrote:
> Does anyone know how to reduce the running time of SetOdometry()
> When running this function on the simulation, the time it spends is
> around 0.01 seconds and 0.04 seconds, which is good. However, if this
> function is run to set a real robot odometry, it normally spends
> around 0.2
> seconds. Maybe this partly depends on the speed of the CPU but I do
> think a powerful computer will improve this too much.
> Thus, does anyone know how to improve this when set odometry to a real
> robot? Or is there an alternative way to do so, which can limit the
> spent on setting the odometry within 0.1 second?
> By the way, the purpose to do so is if the EKF sample period is 0.1
> when the update step is finished, the odometry has to be updated to
> corrected the location of the robot immediately.
The PLAYER_POSITION2D_REQ_SET_ODOM request (which is issued by the
Position2d::SetOdometry method) requires a closed-loop interaction
with the driver that controls the robot. This interaction can be
delayed by waiting for the driver to finish its current communication
cycle with the robot. Many robots (e.g., the Pioneers) operate at
10-20Hz. Add a little client-server overhead, and I'm not surprised
that the call takes 0.2 seconds.
If you cannot tolerate this delay, then I would suggest that you not
use SetOdometry. Instead, let the robot's odometry accumulate as
normal, and maintain the appropriate coordinate transform in your