docking timeout on top of the station
Closed this issue · 10 comments
This has happened to us more than once, and then when we call topo nav again, it starts trying to use move_base, which of course doesn't work, and the system enters a deadlock pretty much.
@gestom, could you make sure the robot backtracks when the docking action server timesout?
How come that the recovery behaviour does not solve that problem ?
For some reason move_base doesnt fail, it just published low speeds.
We just saw this again. The robot tried to dock twice then gave up whilst on the station but not charging (and therefore not at the ChargingPoint node). The recovery behaviour isn't really designed to get the robot off the station (although it will eventually), so please could the robot undock before giving up?
[ INFO] [1463175566.927052323]: Charging service is waiting for charger signal
[ INFO] [1463175595.601613311]: Position of the robot relative to the charging station is -0.023 -0.015 0.003, i.e. 27.532135 mm from the desired position, but no charging signal received.
[ INFO] [1463175595.632971381]: Charging service is undocking to try again
[ INFO] [1463175596.338835572]: Charging service is realizing to be too slow
[ INFO] [1463175596.343315842]: unsubscribing from camera topics
[INFO] [WallTime: 1463175596.358413] State machine transitioning 'NAVIGATION':'planner_failure'-->'RECOVER_NAVIGATION'
[INFO] [WallTime: 1463175596.359828] State machine starting in initial state 'SLEEP_AND_RETRY' with userdata:
['goal', 'n_fails']
[ INFO] [1463175596.800770969]: Map width x height: 804 x 705
[ INFO] [1463175596.998962306]: Map width x height: 80 x 80
[INFO] [WallTime: 1463175602.206458] State machine terminating 'SLEEP_AND_RETRY':'try_nav':'recovered_without_help'
[INFO] [WallTime: 1463175602.207701] State machine terminating 'RECOVER_NAVIGATION':'recovered_without_help':'recovered_without_help'
[INFO] [WallTime: 1463175602.208428] Concurrent state 'NAV_SM' returned outcome 'recovered_without_help' on termination.
[INFO] [WallTime: 1463175602.210667] Concurrent state 'magnetic_strip' returned outcome 'preempted' on termination.
[INFO] [WallTime: 1463175602.221300] Concurrent state 'service_pause_nav' returned outcome 'preempted' on termination.
[INFO] [WallTime: 1463175602.224989] Concurrent state 'stuck_on_carpet' returned outcome 'preempted' on termination.
[INFO] [WallTime: 1463175602.227921] Concurrent state 'bumper' returned outcome 'preempted' on termination.
[INFO] [WallTime: 1463175602.230376] Concurrent state 'pad_pause_nav' returned outcome 'preempted' on termination.
[INFO] [WallTime: 1463175602.231713] Concurrent Outcomes: {'stuck_on_carpet': 'preempted', 'magnetic_strip': 'preempted', 'service_pause_nav': 'preempted', 'bumper': 'preempted', 'pad_pause_nav': 'preempted', 'NAV_SM': 'recovered_without_help'}
[INFO] [WallTime: 1463175602.232327] State machine terminating 'MONITORED_NAV':'recovered_without_help':'recovered_without_help'
[INFO] [WallTime: 1463175602.232827] ABORTED
[INFO] [WallTime: 1463175602.598835] setting parameters back
[INFO] [WallTime: 1463175602.599578] Fatal fail on Friday, May 13 2016, at 22:40:02 hours (126/54)
[INFO] [WallTime: 1463175602.666705] Navigating Case 1 -> res: 1
[INFO] [WallTime: 1463175602.667348] Navigating next try: 4
@gestom told me he's on it.
this seems to be happening in the deployment, @gestom can you make sure the robot always backtracks before docking stops?
This really is a show-stopper for us.
I am currently testing the fixed version on Linda. However, do you have any rosbags that show how it actually happens ? Does Betty's station differ from the other ones ?
Is it?
Yes, that pull request makes the robot move backwards when the robot didn't dock before timeout, the current problems with the docking (and everything else using the head camera) are related to the camera framerate.