Open ahendrix opened 11 years ago
[watts] This has happened on a texas robot. We've confirmed this on ta113.
We checked the launch files, and verified that our input was correct.
The caster calibration controller needs to be fixed.
[wim] To know which of the two flags you hit, you need to know 2 things:
The problem described in this ticket seems caused by assuming the caster moves in one direction, but a user is pushing it in the other direction.
[wim] Fixed in trunk.
wim@prl1:~/boxturtle_wg_all/stacks/pr2_controllers/pr2_calibration_controllers$ svn ci -m "check if calibration happens on correct flag. ticket 3841. check applies to joint and caster calibration controllers" Sending include/pr2_calibration_controllers/caster_calibration_controller.h Sending include/pr2_calibration_controllers/joint_calibration_controller.h Sending src/caster_calibration_controller.cpp Sending src/joint_calibration_controller.cpp Transmitting file data .... Committed revision r36024.
[dking] This change adds a ros::Duration(1.0).sleep() which kills the realtime loop every time this scenario is hit. The proper way to add a delay to the update function would be to add another state to state machine.
I tried to "help" the casters on PRM calibrate with the motors halted. I spun one the wrong way and it calibrated backwards. Since we're now using upper and lower limits in the calibration flag position, we should not trip the calibration controller until we cross the correct flag.
pr2_calibration_controllers/src/caster_calibration_controller.cpp {{{ bool switchstate = actuator->state.calibrationreading & 1; if (switchstate != original_switchstate) { }}}
This should check whether we trip the rising or falling edge, and only trigger in that case.
trac data: