Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved undocking #16

Open
jacobperron opened this issue Apr 1, 2016 · 5 comments
Open

Improved undocking #16

jacobperron opened this issue Apr 1, 2016 · 5 comments

Comments

@jacobperron
Copy link
Member

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 jacobperron added this to the 2.0.0 milestone Apr 1, 2016
@gijsvesch
Copy link

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

@jacobperron
Copy link
Member Author

jacobperron commented Dec 13, 2016

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.

@betaupsx86
Copy link

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.

@jacobperron
Copy link
Member Author

@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.

@betaupsx86
Copy link

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.

eborghi10 referenced this issue in eborghi10/create_autonomy Mar 16, 2019
* Docker container: first commit

* Fix Error in Dockerfile

* Start testing vcstool

* Add Github dependencies using vcstool

* Edit building instructions

* Delete

* Clean up package.xml in ca_move_base

* Delete unnecessary kobuki_msgs dependency

* Edit Docker instructions

* Fix Dockerfile

* Docker container: first commit

* Delete kobuki_msgs dependency

* Fix Dockerfile

* Add EOL

* Edit README
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants