Closed dgossow closed 11 years ago
From a configuration perspective, I think this belongs in the sample configuration, since each sample potentially expects the checkerboard in a different position.
I suspect doing that properly will be a real pain to implement, since you'll probably have to pass the pose guesses through the bag file to the estimator.
So this patch is really a huge hack. The more proper way (and what Austin alludes to above with checkerboards in different positions) is really to set a "best sensor", and have the system set the starting guess pose of each checkerboard sample to the value obtained via reprojection of the checkerboard based on a particular sample data. (for instance, on the PR2, you might suggest the tilt laser is the "best sensor" and it will use that to reproject where all poses are.
This of course does lead to a problem: if your best sensor is the arm, well, floating checkerboards are screwed. In this case, perhaps we can rename this parameter to "default_floating_initial_pose" or similar, and then we have implemented the simple version, and can later come back and make the more complex "best sensor" approach happen.
Which actually brings me to another thing: "best sensor" should probably be an array, so that you could say for the PR2 that left_arm then right_arm, and then when left_arm fails for a checkerboard held in the right_arm, you can fall back to right_arm. Yeah, that sounds like quite a bit of code. For now, let's just get "floating" into the name of this parameter and merge it (perhaps also put a comment with reference to this thread of future "TODO: add alternate methods of defining default poses guesses")
Made the requested changes.
fixed the default_floating_initial_pose thing
This will replace the previously used value [0 0 0 0 0 0] as initial pose guess by an (optional) parameter placed in the system.yaml. On dewey, the calibration woudn't converge otherwise.
Not sure about this. Maybe this should go into the 'checkerboards' section.
Example system.yaml: