[Documentation] [TitleIndex] [WordIndex

The household_objects SQL database

This page documents the household_objects SQL database. It refers strictly to the database itself, as a SQL entity. For documentation of its ROS wrapper and usage inside of ROS, see the household_objects_database package.



One of the guiding principles for building this database was to enable other researchers to replicate our physical experiments, and build on our results. The database was constructed using physical objects that are generally available from major retailers (while this current release is biased towards U.S.-based retailers, we hope that a future release can include international ones as well). The objects were divided into three categories: for the first two categories, all objects were obtained from a single retailer (IKEA and Target, respectively), while the third category contained a set of household objects commonly available in most retail stores. Most objects were chosen to be naturally graspable using a single hand (e.g. glasses, bowls, cans, etc.); a few were chosen as use cases for two-hand manipulation problems (e.g. power drills).

For each object, we acquired a 3D model of its surface (as a triangular mesh). To the best of our knowledge, no off-the-shelf tool exists that can be used to acquire such models for a large set of objects in a cost- and time-effective way. To perform the task, we used two different methods, each with its own advantages and limitations:

In the current release of the database, one of the goals was that each database entry should correspond to a real, physical world objects. However, that is not always necessary. In general, by scaling a given 3D model, it is often possible to obtain a different model eliciting different grasps (since grasping is inherently scaled-dependent). To allow for this possibility in the future, all grasps in the database are computed on scaled_models, which are scaled versions of the original models. The current release only contains scaled models with a scale of 1.0, so there is a one-to-one relationship between original and scaled models.

The 3D geometry of each object is explicitly stored in the database. However, we have also allowed for the possibility of using external data files to hold data (such as the geometry in different formats, thumbnails, etc). The database allows for the possibility of storing an arbitrary number of links to files for each object. Obviously, in order to use this feature, you would need the relevant files as well as the database itself.


For each object in the database, we used the GraspIt! simulator to compute a large number of grasp points for the PR2 gripper. We note that, in our current release, the definition of a good grasp is specific to this gripper, requiring both finger pads to be aligned with the surface of the object and further rewarding postures where the palm of the gripper is close to the object as well. We hope that future releases will also include grasp information for some of the robotic hands most commonly used in the research community.


These are the details of the database schema, organized by table, in roughly descending order of importance. All table fields are prefaced by the name of the table, except for those that act as foreign keys.



mesh (holds the 3D object surface models)


file_path (stores paths to miscellaneous files that can be associated with objects)

model_set (used for defining subsets of objects to be used for particular experiments when you do not want to use all the objects in the database). The database comes with two such sets defined: REDUCED_EXPERIMENT_SET (containing 16 models) and DEBUG_EXPERIMENT_SET (containing 4 models)

variable (used for storing misc. variables). This is also used to store the MODEL_ROOT variable, used to define a base path that all paths in the file_path table are relative to.

2019-08-17 12:46