Short answer
Product dimension and weight data gives a humanoid's planners the size and mass of each item before it is seen up close: whether it fits a hand or needs two, whether it is within payload, how to pack and place it. Brands publish nominal values through product master data; retailers and 3PLs often hold measured values. Expect errors, mixed packaging levels and no center of mass, so spot-measure before relying on them.
Why planners want numbers before perception
A humanoid can estimate an object's size from depth images, but only once it is close, unoccluded and well lit. Mass it cannot see at all. When the robot is told to fetch a case of detergent or restock a shelf, its task and motion planners make decisions earlier: one hand or two, which approach, how fast to move, where the item will fit. Listed dimensions and weights let those decisions start from a prior instead of a guess, and let the robot notice when what it lifts does not match what it expected.
This is physical-understanding data in the product and object data cluster: it describes objects at rest, not how they behave in a hand.
Where the numbers enter planning
| Planning decision | Attribute used | How listed values can mislead |
|---|---|---|
| One hand, two hands or a tool | Largest dimension, weight | Values often describe the package, not the item inside |
| Grasp width feasibility | Smallest dimension across a graspable face | A bounding box overstates irregular or tapered shapes |
| Payload and joint torque margins | Weight, ideally center of mass | Gross and net weight get swapped; center of mass is almost never listed |
| Speed and acceleration limits | Weight, fragility flags | Fragility is rarely a structured field |
| Placement, packing and stacking | Dimensions, orientation, stackability | Axis conventions differ between suppliers |
| Simulation | Mass, plus a mesh | A single mass implies uniform density, which liquids and kits violate |
| Recognition priors | Size | Two sizes of the same product often share identical artwork |
The last row is easy to miss. A 500 ml and a 1 L bottle of the same product can look the same in a crop; known size at a known distance separates them. Grocery shelves are full of such pairs, as the page on grocery and retail product recognition explains.
Nominal, measured and estimated values
Every value in a delivery should say which of three kinds it is.
Nominal values are what the brand declares. The GS1 Package and Product Measurement Standard defines nominal measurement attributes for retail and non-retail products from consumer unit to pallet, and GDSN lets trading partners share this master data through GS1-certified data pools (GS1, 2026). Nominal values follow agreed rules, but they describe the design, not any particular unit.
Measured values come from dimensioning and weighing systems at receiving docks, distribution centers and parcel hubs. They catch errors in nominal data and record real variation, but they are taken on whatever unit passed the scanner, sometimes damaged or mislabeled. Warehouse dimensioning records are covered on dimensioning and weighing records.
Estimated values are copied from supplier feeds, typed in by hand or inferred from similar items. Category structure can help fill gaps: GS1's Global Product Classification groups products into bricks of similar form and material that share category attributes (GS1). An inferred value should stay flagged as inferred so a planner can widen its margins.
Packaging levels cause most errors
Products move as eaches, inner packs, cases and pallets, and a single SKU record can hold measurements for several levels. A humanoid restocking shelves handles eaches and cases; one unloading trucks handles cases and sometimes mixed pallets. Case and pallet identifiers live in a separate key system: the SSCC identifies a logistic unit such as a case, pallet or parcel (GS1). Require the packaging level on every value, and check that a case weight is not sitting in an each field.
What published object datasets record
Research object sets treat physical properties as first-class data. The YCB set spans everyday objects that vary in size, weight, texture and rigidity, and is distributed with physical properties, scans and geometric models for benchmarking (Calli et al., 2015). Catalog-derived sets are thinner: ABO carries up to 18 metadata attributes per listing (Collins et al., 2021), and how many of those are measurements varies by product.
Simulated grasp data shows why mass quality matters downstream. ACRONYM labels its grasp outcomes by physics simulation (Eppner et al., 2020); any simulated outcome is only as good as the mass, friction and geometry assigned to the object model.
Supplier types
| Supplier | What they typically hold | Strength | Watch for |
|---|---|---|---|
| Brands and manufacturers | Nominal dimensions and weights per packaging level; spec sheets | Authoritative design values | Values not updated after pack changes |
| Retailers and e-commerce operators | Data-pool values plus their own item-setup data | Broad assortment | Hand-entered fields; mixed units |
| 3PLs and distribution centers | Measured cube and weight scans | Real units, real variation | Rights over client SKUs; scan errors |
| Industrial and B2B distributors | Shipping dimensions for parts and supplies | Back-of-house items retailers lack | Shipping box, not item, dimensions |
When a 3PL's records describe its clients' products, the client may need to agree before licensing; see client-owned inventory rights.
Illustrative package contents
# Illustrative only — synthetic SKUs and values, not an available dataset
package: dims_weights_supplier_R11_v0
scope: 6,500 SKUs, household and grocery, US assortment
per_value_fields: [value, unit, packaging_level, source, measured_at, method]
example_record:
gtin: "00000000000017"
each: {length_mm: 72, width_mm: 72, height_mm: 248, gross_weight_g: 1134,
source: nominal_data_pool, packaging_change: 2025-11}
each_measured: {length_mm: 74, width_mm: 73, height_mm: 249, gross_weight_g: 1121,
source: dc_dimensioner_04, n_scans: 6, measured_at: 2026-03-02}
case: {units: 8, length_mm: 300, width_mm: 152, height_mm: 255, gross_weight_g: 9420,
source: nominal_data_pool}
flags: {liquid: true, center_of_mass: not_available, orientation_sensitive: true}
excluded: friction, stiffness, center of mass (not held by the supplier)
rights: training, simulation-asset creation and internal evaluation; no redistribution
The each_measured block is what makes this extract valuable for planning: it shows the nominal value is close for this SKU and records how many scans back it.
What this data cannot support
- Shape. Three numbers describe a box. Bottles, bags and tools need meshes or depth data; see physical property annotations for the properties images do not show.
- Mass distribution. Center of mass and inertia are almost never held, and they shift as liquids slosh or kits are unpacked.
- Contact behavior. Friction, stiffness, crush strength and slip need measurement or interaction data.
- State changes. A half-used container weighs less than its listing.
- Manipulation. No dimensions table records how an item moves when grasped; that comes from demonstrations and robot data.
Quality and acceptance criteria
- Units and axes. One unit system and a documented axis convention per packaging level.
- Packaging level. Present on every value; no case values in each fields.
- Plausibility. Weight divided by volume falls within a density range you set per category; outliers are listed.
- Spot measurement. A random sample measured physically agrees with the listed values within your tolerance.
- Completeness. Fill rates reported per field and packaging level for your target SKUs, not as an average.
- Provenance. Every value carries nominal, measured or estimated status and a date.
- Currency. Packaging change dates are present, so stale values can be found.
A wider audit method is on product master data quality audit, and the field-level structure for combining these values with other attributes is on object attribute schema.
Questions to ask suppliers
- Which values come from data pools, which from your own measurement, and which were typed in?
- Which packaging levels are populated for each SKU?
- What dimensioning or weighing equipment do you use, and how often is it calibrated?
- How do you record the axis convention for length, width and height?
- When packaging changes, are dimensions and weights updated, and is the change dated?
- Do you keep repeated scans per SKU, or only the latest value?
- For SKUs you hold for clients, may their product data be licensed?
- Can you deliver catalog images alongside, keyed to the same identifiers?
That last item connects this purchase to product catalog data for robot perception.
Discuss your requirements
List the SKU scope, packaging levels and fields your planners need, and the tolerance you expect. Send the requirement to SourceX: it looks for US businesses that hold suitable product data, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. SourceX reviews each request and follows up about potential sources; a request does not guarantee a match. See also the humanoid training data guide, the page on licensing product catalogs and descriptions and the catalog entry for supply chain and logistics records.
Discuss your humanoid training-data requirements with SourceX
Sources
- GS1 Package and Product Measurement Standard (formerly GDSN Package Measurement Rules) — nominal measurement attributes and master-data sharing.
- Serial Shipping Container Code (SSCC) — identifiers for cases, pallets and parcels.
- GS1 Global Product Classification (GPC) — category bricks for products of similar form and material.
- Benchmarking in Manipulation Research: The YCB Object and Model Set and Benchmarking Protocols — object sets distributed with physical properties.
- ABO: Dataset and Benchmarks for Real-World 3D Object Understanding — metadata attributes in catalog-derived data.
- ACRONYM: A Large-Scale Grasp Dataset Based on Simulation — grasp outcomes labeled by physics simulation.