mas_domestic_robotics
mas_domestic_robotics copied to clipboard
b-it-bots
Robot-independent ROS packages for domestic applications
## Short description As some of our other actions, the `move_base` action doesn't have recovery behaviours at the moment, such that failures in the action often cause failures in subsequent...
## Problem description Related to https://github.com/b-it-bots/mas_domestic_robotics/issues/219 Our current object placing strategy, which is implemented in the [`place` action](https://github.com/b-it-bots/mas_domestic_robotics/tree/devel/mdr_planning/mdr_actions/mdr_manipulation_actions/mdr_place_action), is "blind" in the sense that the robot just moves to the...
Our existing pickup action treats all objects equally, i.e. we don't have runtime selection of object-specific grasping strategies. The [pickup action client](https://github.com/b-it-bots/mas_domestic_robotics/blob/devel/mdr_planning/mdr_actions/mdr_manipulation_actions/mdr_pickup_action/ros/scripts/pickup_client) should thus be modified so that an appropriate...
Related to https://github.com/b-it-bots/mas_domestic_robotics/issues/217 If a pickup failure is detected by the grasp verification module, the action should go into a recovery mode. The simplest form of recovery would be resetting...
Since navigation goals can be considered encyclopedic information that is currently stored in YAML files (e.g. [here](https://github.com/b-it-bots/mas_domestic_robotics/blob/kinetic/mdr_environments/brsu-c069/navigation_goals.yaml)), it makes sense to consider storing the information in the ontology instead in...
- load topological map from configuration files - see https://github.com/b-it-bots/topological_map/issues/1 - define an ontology for our lab - see https://github.com/b-it-bots/mas_knowledge_base/issues/6 - define a topology for our lab - see https://github.com/b-it-bots/topological_map/issues/6
As discussed in #145, we need further discussion in how to handle `mdr_find_people`. > Yeah but `mdr_detect_person` can be extended to have 3D processing, instead of creating a new package....
Right now since the dependency to `mcr_arm_cartesian_control` means, that we need to clone all of `mas_common_robotics`. Refactoring this would make the migration easier and would shorten the build times in...
Right now `mdr_follow_person` depends on `mcr_follow_person` and `mcr_algorithms. That means that we need to clone all of `mas_common_robotics`. Refactoring this would make the migration easier and to shorten the build...