I agree that IR calibration should be a driver side issue but I am not sure about not having some sort of calibration methods exposed from the IR sensor interface. The reason is to allow robots that have odometry to help the IR drivers do a self calibration. Imagine setting the robot down in front of a wall and kicking off an autocalibration client that moves the robot so that each of the sensors fire at the wall from a series of ranges. This actual range data (as read from odometry) is passed down to the driver which creates a persistant lookup table of actual vs read values. The IR sensor pose information would be used to make sure the robot aligns the IR sensor under test to be firing directly into the wall.
In order to do this autocalibration excercise in this manner, some sort of calibration methods would need to be exposed from the IR sensor interface. If the calibration methods are not exposed, you could maintain the calibration data in the application, but that is ineffective as you would need to code each of your applications to handle the calibration data. Alternately the autocalibrate client could save the calibration data to a file and have the driver use the file, but that seems like a clumsy approach.
Is this sufficient reason to expose calibration methods? I dunno, but I do know that it has got to be a lot less painful than calibrating sensors manually.
From: Brian Gerkey <firstname.lastname@example.org>
Sent: Monday, March 27, 2006 12:20 PM
Subject: Re: [Playerstage-users] regarding defining IR sensors
On Mar 23, 2006, at 3:45 PM, Toby Collett wrote:
> Calibration is a driver side issue and should not affect the
> interface that is exposed. As for the really cheap ones they should
> probably have a different interface altogether to reflect that, or
> only return two different range values, 0 and their max?
That's a good point.
> my original thought was to create a new ranger interface and
> virtual drivers to convert sonar, ir and maybe laser into it and we
> could update drivers as needed to expose it directly...then we dont
> loose any compatability.
Sounds reasonable. I've opened a feature request on this issue at
SF.net so we don't forget.
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
Playerstage-users mailing list