create_robot icon indicating copy to clipboard operation
create_robot copied to clipboard

Improved undocking

Open jacobperron opened this issue 9 years ago • 5 comments

Currently, publishing to the undock topic simply switches control of the robot back to the user (after the robot has entered the docking demo). It would be nice if, on top of this, the robot also backs up slowly for a short distance. Similar to how the built-in cleaning behaviours work when starting on a docking station. Unfortunately, iRobot has not exposed this undocking behaviour, so we have to roll our own.

jacobperron avatar Apr 01 '16 23:04 jacobperron

Could you not write a simple program which just drives backward and then turns for 180 degrees?

gijsvesch avatar Dec 13 '16 15:12 gijsvesch

Could you not write a simple program which just drives backward and then turns for 180 degrees?

Yes. I was debating whether or not it should be a routine inside ca_driver, but I think it is better to only expose the underlying interface provided by the Create/Roomba platforms. Perhaps, an undocking routine could be implemented in a separate node as an optional feature in ca_tools or a new package ca_behaviours.

jacobperron avatar Dec 13 '16 20:12 jacobperron

I would go for having them separate. I think the whole Docking/Undocking process should be done via an Action Server. You could preempt your requests and also cover all the specific cases (ex: if ordered to undock while already docked/charging - backup and rotate, if ordered to undock while still searching for the charger - stop and return control to user, etc ). This of course if you don't mind the overhead and added code complexity.

betaupsx86 avatar Jan 22 '17 06:01 betaupsx86

@betaupsx86 Thanks for the input. I like the idea of an action server for docking. If we want to follow the OI Spec more exactly there could be an action server for each of the possible "demos" that the base provides (ie. clean, spot, max, dock). Unfortunately there does not seem to be a notion of "done" for the actions I mentioned coming from the base. It may be simpler to leave the /dock interface as is and have the Set Mode feature for regaining control of the robot. For example, changing the mode to FULL via a message (or service call) to /set_mode will naturally preempt a docking procedure. We can add complexity in a separate package with an undocking behaviour.

jacobperron avatar Jan 23 '17 18:01 jacobperron

For docking at least we could query the charging state of the robot. If the base gets to the charger and starts charging then the action is complete.

betaupsx86 avatar Jan 24 '17 02:01 betaupsx86