Common Mistakes
Did you remember to upload new intrinsics to the camera eeprom by running write_pr2_cam_intrinsics.sh?
Does your robot.xml point to the new URDF you just generated?
Does /etc/ros/distro point to where you expect it to?
Did you reset the calibration offsets on the MCBs by setting the L,B,R breakers Disabled?
The tutorials ask me to delete /etc/ros/plugs/calibration.yaml, I but can't find it. What should I do?
- The plugs calibration is a secondary-order calibration used for the plugging-in demos. If you haven't run the plugging in demos, then it is likely that no one has ever generated this file on your PR2.
The robot was calibrated using the boxturtle distro, but now I am trying to run latest and the calibration appears to be off. Are there known issues with this?
- There are currently no known issues when calibrating with one distro and running with another. However, we cannot guarantee that this will always be the case. If calibration seems in be off in a newer distro, verify that the calibration looks reasonable with the distro that was used to calibrate the robot.
I finished calibrating my PR2, and one arm seems reasonable calibrated, whereas the other arm is way off. What did I do wrong?
- When holding the checkerboard in the gripper, it is imperative that its grip of the checkerboard doesn't change. If the checkerboard bumps into anything or if the run-stop is pressed, the data capture step must be restarted. Sometimes, even the impact from the arm bumping into something can cause the checkerboard to move, even though nothing ever touched the checkerboard.
What can I do to ensure that I get the best calibration that I can?
Verify Stereocam Calibration:
Do stereocamera epipolar checks using both the large and small checkerboards. It is very possible for the stereocameras to be well calibrated far away, but not as good close up. The small 5x4 checkerboard can be used with cameracheck.py to verify the epipolar error very close (.75m) to the narrow stereocam. Ideally, this error will be less than .3 pixels.
Ensure a low load average on c1
The data capture step processes streaming data from almost every sensor on the robot, and thus is very cpu intensive. If the load average on C1 becomes large (greater than 15), the calibration can potentially start dropping laser lines from the tilting laser, and produce poor calibration results. You can check load average on c1 using the top command.
If you do notice an extremely high load average, you should stop the data capture app and restart both machines. The computers can be shutdown using the pr2-shutdown command, and turned on again with a paperclip.
It's not entirely unreasonable to restart both computers just prior to starting capture_data.launch, simply to make sure that the computer doesn't become unstable halfway through capturing data.
Redo calibration with pr2_calibration >=0.4.3
- There was a small bug with specifying the size of the small 5x4 checkerboard that came with the PR2. This was fixed in pr2_calibration 0.4.3. Rerunning the calibration with this release or greater may provide slightly better results.
All the calibration tutorials mention a 7x6 checkerboard. However, our checkerboard appears to be 8x7. Why?
- The opencv checkerboard convention counts internal corners. See diagram below:
Troubleshooting/cb_7x6.png "cb_7x6.png")
- The opencv checkerboard convention counts internal corners. See diagram below:
It looks like all of the requested cameras see the checkerboard, but I'm still not capturing a sample
- Each camera's processing pipeline is looking at the sequence of camera images, and verifying that none of the pixels are moving by more than a specified tolerance. This data is then used to create intervals on which each sensor is considered settled. These intervals are then intersected across all sensors to find an interval across which all of the sensors have settled. Most likely, due to glare or other lighting issues, one of the pixels is jumping around, preventing the settled interval from ever becoming very long.
You can view the settled interval using the following tool:rosrun joint_states_settler view_interval interval:=[INTERVAL_TOPIC]
Where [INTERVAL_TOPIC] can be the interval topic for any camera or chain sensor:
/wide_stereo/left/settled_interval
/wide_stereo/right/settled_interval
/narrow_stereo/left/settled_interval
/narrow_stereo/right/settled_interval
/narrow_stereo/left/settled_interval
/left_arm_chain/settled_interval
/right_arm_chain/settled_interval
/head_chain/settled_interval
[INTERVAL_TOPIC] can also be set to the intersection of all the sensors' intervals:
/request_interval
If the tilt scanner is also active, then all the sensors must be settled during the tilt scanner's observation of checkerboard. If the checkerboard is moved during this time (resulting in request_interval re-zeroing), then the sample will be discarded and the tilt scanner will try again.
- Each camera's processing pipeline is looking at the sequence of camera images, and verifying that none of the pixels are moving by more than a specified tolerance. This data is then used to create intervals on which each sensor is considered settled. These intervals are then intersected across all sensors to find an interval across which all of the sensors have settled. Most likely, due to glare or other lighting issues, one of the pixels is jumping around, preventing the settled interval from ever becoming very long.
Reporting Errors
If you encounter a problem that isn't addressed on this page, please file a ticket