Articulated Object Models: Hinges, Sliders and Joint Parameters

The buyer's problem

Rigid-object datasets treat a cabinet as one shape. A robot cannot use it that way. It needs to know that the cabinet has a door on a vertical hinge, a drawer on a slider and a handle on each, and where those axes sit in space.

Workplaces are full of such objects: fire doors, supply cabinets, dispenser levers, valve handwheels, lids, latches, folding carts, equipment panels. Buyers who want a perception or planning system to reason about them need asset data with joints defined, not just meshes. That data comes from two supply routes: manufacturers' own CAD and kinematic assemblies, and annotation of scanned or catalog models by specialists.

This page is about the object model itself. For demonstrations of opening and closing, see equipment controls and interfaces and the demonstrations hub.

What an articulated model contains

The core of a record is a kinematic description:

These fields can be expressed in common robot-description or scene-description formats. Dynamic properties such as friction, damping and spring return are optional additions and are often missing.

What published work shows

SAPIEN is a physics-based simulator built around a large collection of articulated objects for household robotics, with benchmarks for part detection and motion recognition and manipulation tasks approached with heuristics and reinforcement learning (Xiang et al., 2020). It shows what part-based interactive assets enable: you can train perception to find parts and recognize how they move, and you can run manipulation experiments in simulation. It is a research collection of household items, so a buyer should treat workplace coverage as something to source, not assume.

Supply routes

Manufacturer CAD and kinematic models. Equipment makers typically hold assemblies with real joint definitions, because they are needed to design the product. These are accurate but may be proprietary and may need conversion; see manufacturer 3D models and CAD.

Annotation of scanned or catalog models. A static mesh can be split into parts and annotated with axes and limits by trained annotators, sometimes checked against the physical object. Quality depends on the annotator's access to the real mechanism. This route needs a separate annotation step, scoped case by case.

Instrumented capture. Measuring joint ranges on the physical object with a motion capture or fixture gives ground truth, but it is a new collection and costs time per object.

Simulation-ready packages. Some suppliers deliver assets with collision geometry and physics parameters. See simulation-ready object assets for what to check.

What this data can support and what it cannot

It can support:

• Part detection and segmentation training.
• Motion recognition: given an image, predict hinge or slider and the axis.
• Procedural simulation of opening, closing, pulling and sliding.
• Affordance reasoning when combined with affordance and part labels.
• Evaluation scenes in which a system must open each of a list of objects.

It cannot support:

• How people or robots operate the object. Joint parameters say a door can rotate 110 degrees, not where to grasp, how hard to pull or what to do when it sticks. Object models are not manipulation training data. Control training needs robot or teleoperation data. See object recognition vs manipulation data.
• Real-world friction and wear. A modeled hinge opens freely; a real one may bind, spring back or latch.
• Appearance in the workplace. CAD renders do not show dirt, labels or lighting. See synthetic renders vs real images.
• Variation across a model line. Two units of the same SKU can differ in tolerance, age and hardware.

Illustrative joint record

The record is Illustrative. Names and numbers are synthetic and chosen only to show structure.

# Illustrative only - not an available dataset
object_id: obj_cabinet_0031
source: manufacturer_cad_converted
frame: object_base, z_up, meters
links: [body, door_left, handle_left, drawer_1]
joints:
  - name: door_left_hinge
    type: revolute
    parent: body
    child: door_left
    axis: [0, 0, 1]
    origin: [-0.30, 0.25, 0.00]
    limit_deg: [0, 100]    # example values
    verified_on_physical_unit: false
  - name: drawer_1_slide
    type: prismatic
    parent: body
    child: drawer_1
    axis: [0, 1, 0]
    limit_m: [0.0, 0.40]   # example values
    verified_on_physical_unit: true
dynamics: absent

Notice verified_on_physical_unit. It records whether a human checked the joint against a real object, which is the single most useful quality flag on this kind of data.

Acceptance criteria you can set

• Joint correctness. Sample objects and check axes and limits against the physical mechanism or a drawing.
• Part naming consistency. Same part, same label, across objects.
• Frame and unit clarity. Axis directions mean nothing without a stated frame.
• Mesh health. Watertight parts, no interpenetration at limits.
• Coverage. Report counts by object category, including the long tail.
• Dynamics disclosure. State clearly which physical parameters are absent.

Questions to ask suppliers

1. Were joints taken from original CAD kinematics or drawn after the fact by annotators?
2. Which joint parameters were verified on a physical unit?
3. What formats are delivered, and is a converter or schema provided?
4. Are friction, damping and detent data included or absent?
5. How are different SKUs or revisions of the same object distinguished?
6. Who owns the models, and do they carry manufacturer licensing limits?
7. Are the objects workplace types such as fire doors and dispensers, or mostly household items?
8. What annotation guideline and review process was used?

Permissions and provenance

CAD is often trade-secret material and may be covered by supplier agreements. Mesh-derived models from scans of branded products may involve brand and design rights. Ask who authored each model, whether a manufacturer license applies, and what uses (training, simulation, redistribution) are allowed. Simplifying or decimating a model does not by itself settle rights.

Joint models also feed state recognition, such as telling an open drawer from a closed one; see object state recognition. For storage and transport equipment with lids and latches, see containers, totes and bins.

Discuss your requirements

If you need articulated models of specific workplace equipment, describe the object types, joint detail, formats and permitted uses to SourceX. SourceX reviews the requirement, looks for US businesses that may hold suitable models, checks the data and the supplier's licensing permissions, and follows up about potential sources. Annotation of joint parameters would be scoped case by case. A request does not guarantee a match. See the objects hub and the humanoid training data guide for neighboring asset types, and the catalog entry for CAD and engineering files.

Discuss your humanoid training-data requirements with SourceX

Sources

• SAPIEN: A SimulAted Part-based Interactive ENvironment — articulated-object simulator with part detection and motion recognition benchmarks.