Contents
Frozen
Updated 2010-12-20
Variants * base (22/29) * pr2 (29/37) base report [ ] camera_drivers [X] common [X] common_msgs [X] diagnostics [X] documentation [X] driver_common [X] geometry [X] image_common [ ] image_pipeline [X] image_transport_plugins [X] imu_drivers [X] joystick_drivers [X] laser_drivers [X] laser_pipeline [ ] navigation [ ] perception_pcl [X] physics_ode [X] robot_model [X] ros [ ] ros_comm [ ] roslisp_support [X] rx [X] simulator_gazebo [X] simulator_stage [X] slam_gmapping [X] sound_drivers [ ] vision_opencv [X] visualization [X] visualization_common pr2 report [X] pr2_common [X] pr2_controllers [X] pr2_ethercat_drivers [X] pr2_gui [X] pr2_mechanism [X] pr2_power_drivers [X] pr2_robot [ ] pr2_simulator
Meeting Groups
Simulators/Models
ROS
Perception
Base + Eigen-related
Controllers
Apps
Drivers + laser pipeline
Existing Stacks
camera_drivers
move camera_info_manager to image_common stack
camera1394 enhancements
- new wge100 firmware
common
- fill out these capabilities and release as non experimental
- Some sort of action viewer
- Service call like interface to actions
- An observer tool that could allow you to monitor what is going on in the system
navigation
Support PointCloud2
- Full support for passing new maps to the navigation stack that have global frames that change. The costmap had limited support for this in cturtle, but this will be much better.
- Perhaps a roswtf plugin for navigation? Not sure how beneficial this would be... would be interested on feedback for this one.
- Perhaps explore re-writing the navigation plugins using nodelets. (This is going to take some time and may end up in a future turtle release)
- Re-write robot pose ekf with nodelet plugin mechanism.
pr2_controllers
- Move towards generalized, non-PR2-specific framework? (perhaps land in e-turtle)
- Calibration controllers that support both rising/falling edges, versioning on MCB storage and consistent caster calibration.
pr2_navigation
Switch over to use PCL and PointCloud2
- Better ground plane detection
- Perhaps use stereo camera for obstacle data by default. Not sure how perception folks will feel about this as it would most likely keep the head looking at the ground. Is navigation good enough without stereo?
New stacks/packages
Stacks Notes
- image_transport_plugins
- object recognition pipeline:
object_recognition: This will consist of 2D and 3D object recognition
- 2D:
- Binarized Gradient Grid (BiGG designed by Gary and Marius) along with 2D and 3D filtering for false positives
DOT (Stephan Holzer's implementation and improvement of Stephan Hinterstoisser's Dominant Orientation Templates)
Latent-SVM Hierarchical HOG based detector.
Fast LARK (Fast Locally Adaptive Regression Kernel implemented by Hae Jong Seo)
- 2D:
- 3D:
- Segmentation
- 2D:
- select3Dobject (from 2D pose)
- grabCut
- gradient saliency
- from association (BiGG memorizes a segmentation map with each view)
- 3D
- subtract plane
- 2D:
- 6DOF Pose
- Hints from BiGG (memorizes basic pose from each view)
- VPFH directly gives pose
- 3D object fitting
- grasping pipeline:
object_manipulation: this is a robot-independent stack that will eventually make it into ros-pkg. I see the API stabilizing and the functionality maturing for an 0.3 or 0.4 release in Diamondback, then going through the M3 process for an 1.0 release in e-turtle.
pr2_object_manipulation will probably follow a similar path, except that it will stay in PR2-specific distro versions.
tabletop_object_perception is more of a convenience tool to run the manipulation pipeline right now; it is not intended to go beyond 0.2 status. The rest of the manipulation pipeline does not depend on it; only our current applications do.
sql_database: decision was made to change the focus of this stack (see API review). What we need is a library for automatic conversion between ROS messages and a database-friendly format, using existing libraries for lower-level SQL communication. Development on current thread will be limited to bug fixes and minor functionality updates.
vslam (Kurt, Patrick)
- integrate with Freiburg optimizer
topological_navigation, graph_mapping (Bhaskara, Eitan, Kurt)
- Probably bring up to 0.4
- Full topological nav stack with exploration
cv_bridge (Patrick)
- arm_navigation and associated stacks:
arm_navigation: robot independent stack with stable ROS API - no C++ api offered, will mature to 0.4 status.
collision_environment: robot independent stack with C++ API. Current plans include integration of continuous collision checking, so this stack may not stabilize in time for diamondback.
- kinematics - should mature to 0.4 status in diamondback
- motion_planners - ROS API is stable, ompl C++ API should also be much nicer now with Rice's help but will not move to 0.4 until e-turtle
- motion_planning_common - this will not stabilize until e-turtle
- motion_planning_environment - will not stabilize until e-turtle
- motion_planning_visualization - is relatively stable and should move to 0.4 with diamondback
- pr2_kinematics, pr2_kinematics_with_constraints - should move to 0.4 with diamondback
- trajectory_filters - should move to 0.4 with diamondback
- all other stacks are launch file/testing stacks and will not move to 1.0 until all related packages have moved to 1.0
Useful packages that could use homes
foreign_relay: move into topic tools? (Blaise, Brian)
joint_trajectory_replay: where? (Blaise)
New experimental stacks
object_recognition (Marius, Radu, Kurt)
roslisp_common (tf and actionlib)