Short answer
Physical property annotations record what images cannot show: mass, center of mass, friction against named surfaces, fragility class and compliance. Specify each field with a measurement method, a unit, a tolerance and a provenance tag. Without those, planners and simulators cannot tell a measured value from a catalog guess, and a single "weight" column hides which one you received.
The buyer's problem
Grasp planners, simulators and safety checks need numbers that a camera does not provide. A planner that picks a bottle needs its mass and where that mass sits. A controller handling a stacked tray needs to know whether the item can take pressure. Supplier data usually offers nominal weights from product master data and nothing on friction or fragility, so the buyer either measures, commissions measurement, or accepts coarse classes.
This page is a specification you can adapt. It assumes you already know which objects matter; if you are still deciding what to list, start from the object attribute schema and the product dimensions and weights page, which covers the nominal fields.
Why these properties, and how published work uses them
Published grasp work depends on physical parameters even when the data looks purely visual. Dex-Net 2.0 trained a grasp-quality model on 6.7 million synthetic point clouds, grasps and analytic grasp metrics computed from thousands of 3D models, and reports 93% success on eight known adversarial objects over more than 1,000 trials on a physical arm, with 99% precision on 40 novel objects (Mahler et al., 2017). The analytic metrics encode assumptions about contact, and those assumptions are only as good as the object models and parameters behind them.
ACRONYM labeled 17.7 million simulated parallel-jaw grasps over 8,872 objects in 262 categories by running a physics simulator (Eppner et al., 2020). Simulation outcomes inherit whatever mass and friction values the simulator was given, which is why a measured property table has value even for a team that mostly trains in simulation.
Real contact data shows what static properties miss. RH20T provides more than 110,000 contact-rich real-world sequences with visual, force, audio and action data per sequence (Fang et al., 2023). Force traces during handling reveal compliance and slip in ways a lookup table cannot, and a buyer who needs that signal should treat property annotation as a complement to interaction data, not a replacement. See object recognition data versus manipulation training data for the underlying distinction.
Illustrative specification
# Illustrative: synthetic values, adapt every field to your gripper and task
object_record:
object_id: obj_02210
instance_or_class: instance # instance | class_nominal
mass:
value_g: 412.0
method: bench_scale # bench_scale | spec_sheet | estimated
scale_resolution_g: 0.1
state: filled_to_label # empty | filled_to_label | typical_use
center_of_mass_mm_from_base: [0, 0, 78]
friction:
pair_id: pad_silicone_A__surface_B # named contact pair, not a single number
static_mu: 0.62
method: inclined_plane # inclined_plane | pull_test | tribometer
n_trials: 10
condition: dry # dry | wet | oily
fragility:
class: breakable # robust | dentable | crushable | breakable
basis: supplier_statement # handling_test | supplier_statement | visual
max_grip_force_n: null
compliance:
class: semi_rigid # rigid | semi_rigid | flexible | soft
method: coarse_press_test
measured_by: lab_L07
measured_on: 2026-09-01
Every record carries a method and a state. The state matters: a filled container and an empty one are different objects for planning.
Field-level guidance
Mass and center of mass. Specify scale resolution and whether contents are included. Center of mass can be estimated from a balance test, from CAD with uniform density (rough), or from a manufacturer's model. Tag which.
Friction. A coefficient belongs to a contact pair, not an object. If your gripper pads, a suction cup and a bare finger differ, request one value per pair. Ask for dry and contaminated conditions separately, since packaging with condensation or cooking oil behaves differently. Report the method because inclined-plane and pull tests do not give identical numbers.
Fragility. Prefer a small ordered class with definitions over a numeric force unless the supplier ran destructive tests. Examples of definitions you set: "breakable: fails under a drop from a stated height or a stated squeeze". Avoid "fragile" as a free-text label; it varies by supplier.
Compliance. Coarse classes are realistic at purchase scale. Finer stiffness values require instrumented presses and may be worth commissioning for a short list of critical objects. Deformable goods have their own page: deformable product properties.
Hazard-related properties. Flammability, sharpness and chemical hazards are different fields from handling fragility; see hazard properties of objects.
Which properties to buy first
Not every program needs every field. A suction-based picker cares most about mass, center of mass and surface porosity, while a two-finger or multi-finger hand adds friction and compliance. A team handling food service items may rank fragility and contamination state above everything else. Rank the fields by the failure you most need to prevent, specify those with tight tolerances, and accept coarse classes for the rest. Requirements depend on your architecture, embodiment and the object list, and no fixed count of annotated objects is adequate in general.
Pilot before committing
Ask for a pilot of a few dozen objects before a full order. Measure a subset yourself on your bench, compare against the supplier's table, and look at the pattern of differences rather than only the average. Systematic offsets, such as every mass reported with packaging included, point to a method problem that can be fixed in the specification. Random spread points to measurement noise that tolerances must absorb. Use the pilot to refine the state definitions and the friction pair list before a larger run.
Acceptance tests
- Repeat measurement. Re-measure a random sample of objects by an independent operator and compute the spread per field. Set the tolerance by your gripper's margin, not by supplier habit.
- Cross-check against nominal weight. Flag records where measured mass differs from the master-data weight by more than a threshold you choose. Large gaps often mean a different pack size or a data entry error.
- Provenance completeness. Reject records with a value but no method or state.
- Instance coverage. If you need properties per instance (worn items, partly filled containers), confirm the supplier measured instances, not just one reference unit.
- Unit and rounding audit. Look for suspiciously round numbers and unit mix-ups across rows.
Sourcing routes
Existing data comes from manufacturers (specification sheets, packaging engineering files) and testing laboratories (drop, compression and friction reports). These are usually per product class and not designed for learning. Commissioned measurement fits a bounded object list and a stated gripper pairing; the packaging material properties page covers packaging-specific measurements. Both routes need a rights check on the report or table, and on any images attached.
What this data cannot do
Property tables describe objects at rest or under a standard test. They do not tell a policy how an object moves in a gripper, how a stack shifts, or how the properties change with temperature or wear. They also do not replace grasp annotations for products or robot interaction data. Treat them as inputs to planning, simulation and labeling.
Questions to ask suppliers
- For each numeric field, what measurement method and instrument resolution were used?
- Were measurements taken on one reference unit or across several instances per product?
- In what state was the object: empty, filled, new, used?
- Which surfaces and pad materials were used for friction, and under what conditions?
- How is "fragile" or "breakable" defined, and was it tested or asserted?
- Can you share raw test logs, not only summary values?
- Who owns the test reports, and can they be licensed for training and evaluation use?
- How do you handle product revisions, so a property is tied to a pack version?
Discuss your requirements
If you can name the objects, the gripper and the properties that drive your planner, describe the requirement to SourceX. SourceX reviews the request, follows up about potential sources, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. Whether measured data exists or would need new collection is discussed case by case, and a request does not guarantee a match. Start from the humanoid training data guide or the product and object data hub. Related catalog entries include expert annotations and labels.
Explore sourcing and licensing options with SourceX
Sources
- Dex-Net 2.0: Deep Learning to Plan Robust Grasps with Synthetic Point Clouds and Analytic Grasp Metrics — Dex-Net 2.0: grasp planning from synthetic point clouds with analytic grasp metrics; success figures on adversarial and novel objects.
- RH20T: A Comprehensive Robotic Dataset for Learning Diverse Skills in One-Shot — RH20T: real contact-rich sequences with force data alongside vision.
- ACRONYM: A Large-Scale Grasp Dataset Based on Simulation — ACRONYM: grasp outcomes labelled by physics simulation.