Proposer: E. Gil Jones
Present at review:
- List reviewers
I made this an API review as that seems like the most general category. The purpose of this review is to discuss the way forward for the pr2_teleop_general package. This package was originally pr2_teleop_booth - designed for robot demos - but has proved pretty useful, and I'd like to see released for a general audience. It currently lives in pr2_apps_trunk - if you'd like to check out you can use this overlay text:
- svn: uri: https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_apps/trunk local-name: stacks/pr2_apps
There's also a description page at: http://www.ros.org/wiki/pr2_teleop_general
Note that I also wrote a pretty full-featured keyboard implementation that I've already used pretty extensively in simulation.
More than an API review this is really a review of what this package should do, what it should be called, and where it should live. I'd like feedback on a number of issues that I detail below.
Should this be merged with/gradually replace pr2_teleop?
One issue Wim raised in keeping this pr2_teleop_general and having it live alongside pr2_teleop is that it essentially already provides a superset of the functionality of pr2_teleop. One path of integration is to actually check this code into the pr2_teleop package, make sure that it provides a proper subset of the functionality, and deprecate the existing pr2_teleop code. But given the widespread use of pr2_teleop I want to be very careful about moving forward.
Design for interoperability
The existence of the mux in pr2_teleop associated with navigation already attests that getting teleop programs to interact with running launch files. This is functionality I don't currently have in pr2_teleop_general, though you can already disable all arm behavior easily, for instance. This leads to several questions:
- What is the full set of functionality these nodes should implement to support application-specific launch file creation?
- Should the mux system be extended in lieu of a full resource management system?
- Do programs need to enable or disable specific buttons or change what buttons do?
Fidelity in naming
A final issue I'd like to discuss is naming. Should everything that seeks to teleop the pr2 live in pr2_teleop? Another possibility is to make a pr2_teleop stack with a pr2_teleop_common stack for shared code, and particular implementations for methods of control based on interface - pr2_teleop_joystick, pr2_teleop_keyboard, potentially pr2_teleop_phantom or pr2_teleop_cockpit. The pr2_teleop monikor seems a bit problematic in that when folks implement new/different/better methods for teleop control. This just seems a reasonable juncture to think about that a little bit.
Question / concerns / comments
Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.
I think we should for dturtle. The existing pr2_teleop system should be deprecated. In order to make things easier, we may want to change the direction of the head tilt commands to make it easier for pr2_teleop users to convert.
We could rename the existing code to "pr2_teleop_simple.launch", in case we have concerns about interoperability.
We should add a mux and make sure it works with the nav system.
I don't think we should support allowing different programs to change what buttons do. We could provide a supported ROS API, for example publishing on 'my_arm_controller/position' for a particular button. Once we have a stable API, the user can change out the type of controller, etc.
pr2_teleop is fine with me. More complicated teleop systems can be easily named to distinguish themselves from pr2_teleop, like pr2_cockpit and teleop_3d.
pr2_teleop_common or teleop_common might be better so that core infrastructure can be create and placed there so that people can build off of it
We should look at making some base "modules" or nodelets that are parameterized( buttons, controllers, etc) so people can import/run them to construct custom teleop nodes/packages, this will help with copied code everywhere.
- What is the consensus on the above issues?
- What changes need to be made?
- What should the release process look like?
Package status change mark change manifest)
Add run button
Add navigation mux
Release soon against cturtle as pr2_teleop_booth
Consider drop-in replacement for dturtle
Eitan needs to deal with his dependencies
Add some compelling stuff to roadmap
Send out an email to pr2 users on release
Migrate existing wg users to it to work out bugs