An object is uniquely defined by a type and a database in ObjectId.msg:
################################################## OBJECT ID #########################################################
# Contains information about the type of a found object. Those two sets of parameters together uniquely define an
# object
# The key of the found object: the unique identifier in the given db
string key
# The db parameters stored as a JSON/compressed YAML string. An object id does not make sense without the corresponding
# database. E.g., in object_recognition, it can look like: "{'type':'CouchDB', 'root':'http://localhost'}"
# There is no conventional format for those parameters and it's nice to keep that flexibility.
# The object_recognition_core as a generic DB type that can read those fields
# Current examples:
# For CouchDB:
# type: 'CouchDB'
# root: 'http://localhost:5984'
# collection: 'object_recognition'
# For SQL household database:
# type: 'SqlHousehold'
# host: 'wgs36'
# port: 5432
# user: 'willow'
# password: 'willow'
# name: 'household_objects'
# module: 'tabletop'
string db
More information is also stored by ORK in the database. This information can be retrieved in ObjectInformation.msg:
############################################## VISUALIZATION INFO ######################################################
################### THIS INFO SHOULD BE OBTAINED INDEPENDENTLY FROM THE CORE, LIKE IN AN RVIZ PLUGIN ###################
# The human readable name of the object
string name
# The full mesh of the object: this can be useful for display purposes, augmented reality ... but it can be big
# Make sure the type is MESH
shape_msgs/Mesh ground_truth_mesh
# Sometimes, you only have a cloud in the DB
# Make sure the type is POINTS
sensor_msgs/PointCloud2 ground_truth_point_cloud
When the objects are recognized, an array of recognized objects is published in RecognizedObjectArray.msg:
##################################################### HEADER ###########################################################
Header header
# This message type describes a potential scene configuration: a set of objects that can explain the scene
object_recognition_msgs/RecognizedObject[] objects
##################################################### SEARCH ###########################################################
# The co-occurrence matrix between the recognized objects
float32[] cooccurrence
which contains several RecognizedObject.msg:
##################################################### HEADER ###########################################################
# The header frame corresponds to the pose frame, NOT the point_cloud frame.
Header header
################################################## OBJECT INFO #########################################################
# Contains information about the type and the position of a found object
# Some of those fields might not be filled because the used techniques do not fill them or because the user does not
# request them
# The type of the found object
object_recognition_msgs/ObjectType type
#confidence: how sure you are it is that object and not another one.
# It is between 0 and 1 and the closer to one it is the better
float32 confidence
################################################ OBJECT CLUSTERS #######################################################
# Sometimes you can extract the 3d points that belong to the object, in the frames of the original sensors
# (it is an array as you might have several sensors)
sensor_msgs/PointCloud2[] point_clouds
# Sometimes, you can only provide a bounding box/shape, even in 3d
# This is in the pose frame
shape_msgs/Mesh bounding_mesh
# Sometimes, you only have 2d input so you can't really give a pose, you just get a contour, or a box
# The last point will be linked to the first one automatically
geometry_msgs/Point[] bounding_contours
#################################################### POSE INFO #########################################################
# This is the result that everybody expects : the pose in some frame given with the input. The units are radian/meters
# as usual
geometry_msgs/PoseWithCovarianceStamped pose
There is that object that is pretty useful to recognize and it’s called a table. When found with the Tabletop Detector it publishes those two messages:
# Informs that a planar table has been detected at a given location
Header header
# The pose gives you the transform that take you to the coordinate system
# of the table, with the origin somewhere in the table plane and the
# z axis normal to the plane
geometry_msgs/Pose pose
# There is no guarantee that the table does NOT extend further than the
# convex hull; this is just as far as we've observed it.
# The origin of the table coordinate system is inside the convex hull
# Set of points forming the convex hull of the table
geometry_msgs/Point[] convex_hull
Header header
# Just an array of tables
object_recognition_msgs/Table[] tables