Skip to content

Containers, Totes and Bins: Variety Data

By Noah Loul · Reviewed by Noah Loul · Updated

  1. 01Your data spec
  2. 02Matched to businesses
  3. 03Rights and samples reviewed
  4. 04Licensed delivery
How it works with SourceX: Your data spec → Matched to businesses → Rights and samples reviewed → Licensed delivery.Illustrative

Short answer

A container recognition dataset should cover the variety a robot will meet: tote and bin types, sizes, colors, lid states, liners, wear, labels and fill levels, photographed from working viewpoints. Warehouses and manufacturers often hold such images as a by-product of operations. Images and attributes support detection and identification, not the handling of a tote's weight, flex or contents.

Why containers deserve their own data

In many workplaces the container, not the product, can be the object a worker touches most. Totes ride conveyors, bins sit on shelves, crates stack on pallets, and nested kits travel in trays. A humanoid that cannot tell an open tote from a lidded one, or a tote from the cart that holds it, fails before any grasp begins.

Generic object datasets treat "box" or "bin" as one or two classes. A buyer working on a specific site needs the long tail: the three tote footprints in use, the foldable crates, the dented ones, the ones with a paper label slid into a sleeve. That tail is more likely to appear in operational photos than in public benchmarks, though whether a given archive covers it is a diligence question.

This page covers how to source container images and attributes. For the boundary between recognizing an object and training the manipulation of it, read object recognition data versus manipulation training data, and for the wider cluster see the product and object data hub.

What to look for: the variety axes

Container variety is multidimensional, and a dataset that is large along one axis can be empty along another. Ask which of these axes the supplier can actually populate:

  • Form factor. Stackable totes, nestable totes, collapsible crates, open-front bins, lidded bins, roll cages, pallet boxes, trays and dunnage inserts.
  • Surface condition. Clean, scuffed, stained, cracked, deformed rims, missing lids, residue from earlier contents.
  • State. Empty, partly filled, overfilled, covered with film, stacked, nested, tilted on a conveyor.
  • Identification. Printed labels, barcode stickers, RFID tags, hand-written marks, color-coding conventions, license-plate style IDs.
  • Context. On a shelf, on a conveyor, on a cart, on the floor, held by a person, inside a truck.

A single site usually shows only a slice of these. If a supplier offers many images from one warehouse, expect a narrow range of form factors and a repeated background, which matters when your model must work elsewhere. The same concern drives domain shift across sites in inspection data.

What published work offers as a reference

ARMBench was collected in an Amazon warehouse pick-and-place workcell and comprises images, videos and metadata for more than 235K pick-and-place activities on more than 190K unique objects, with tasks including object segmentation in clutter, object identification and defect detection (Mitash et al., 2023). It is useful here as a capture and labeling reference: it shows what a production workcell can log and how activity-level metadata can sit beside images.

It is only that. The paper's setting is picked objects in a workcell, so it does not tell you how totes, bins or crates are distributed, and it is not a container dataset. Treat any claim that a published benchmark "covers containers" as a question to verify against that benchmark's own documentation.

Illustrative container record

A usable container record pairs an image set with attributes a perception engineer can filter on. The fields below are an illustrative schema with synthetic values, not a standard and not a minimum.

FieldIllustrative valueWhy it matters
container_idctr_00417Links multiple views of one physical container
form_factornestable_toteSeparates classes that look similar
nominal_footprint_mm[600, 400]Supports scale-aware detection; check against a measurement standard
lid_stateopenChanges what is visible and graspable
fill_statepartialDictates appearance and later handling
conditionscuffed_rimReal-world wear is under-represented in clean sets
site_idsite_017Enables held-out-by-site splits

Keep the footprint and weight attributes honest. A nominal catalog dimension is not a measured one, and a "capacity" number says nothing about how a loaded tote flexes in a hand. The standard for nominal product and package measurement attributes is discussed on the product dimensions and weights page.

Where the images live

Existing assets come from a few places. Warehouse operators and third-party logistics providers keep camera captures from induction, sortation and exception handling; manufacturers keep photos from kitting stations and inbound receiving; container pool and packaging suppliers keep catalog imagery. Each source has a different bias. Fixed-camera captures are consistent but narrow. Catalog photos are clean but show no wear. Staff photos of damaged items are diverse but unsystematic.

If you need viewpoints a robot would actually have, such as head-height views of a shelf or top-down views from a gripper camera, existing archives rarely match. That can justify discussing a short commissioned capture designed around your sensors; the trade-offs are in choosing between existing assets, new collection and specialist partners.

What container images cannot support

Container images and attributes do not show how a container behaves when handled. They contain no weight distribution, no rim stiffness, no stacking friction, and no record of how a worker re-grips a sliding tote. Training a humanoid to lift, stack or slide containers needs robot or teleoperation data, or instrumented human capture, with joint states, actions and contact information. Footage of workers moving totes does not substitute for it.

Further limits to plan for:

  • Label drift. Colors and label formats change when a site changes vendors, so a model tuned to one fleet may misread another.
  • Contents leakage. Photos taken through an open tote also show products, packing slips and addresses, which raises business and personal data questions covered in rights for product and container imagery. This is not legal advice.
  • Clutter and occlusion. Containers in stacks and carts are partly hidden; see cluttered scenes for recognition for how that interacts with labeling.
  • Evaluation. Hold out a site or a container fleet for testing, and do not let near-duplicate frames from one conveyor straddle the split.

Acceptance checks you can set

Define these before you receive data, with thresholds that suit your model:

  • Every image links to a container ID and a site ID.
  • Form-factor labels follow a written definition, with a sample of images audited by someone outside the labeling team.
  • Duplicates and near-duplicates are removed or grouped, so one tote seen 200 times does not look like 200 totes.
  • Images with identifiable people, addresses or customer names are flagged. Flagging is not the same as clearance.
  • Attribute coverage is reported per axis, so you can see empty cells rather than an average.

Related reading: packaging variants and SKU appearance for how outer packs differ from the products inside, labels, barcodes and text on packages for reading container IDs, packaging material properties for what the container is made of, and 3PL providers as data suppliers for a common source of tote imagery.

Questions to ask suppliers

  1. Which container form factors, and how many distinct physical fleets, appear in the images?
  2. Were images taken for a purpose such as exception handling, and what does that do to what is shown?
  3. What camera positions, resolutions and lighting conditions are represented, and do they vary by site?
  4. Are condition, lid and fill states labeled, and who assigned them?
  5. Do any images show products, labels, personnel or customer information inside or beside the container?
  6. Can the supplier link several views to one container ID?
  7. Who owns the images, and does any customer or carrier contract restrict their use for model training?
  8. Is there a refresh path when the site changes its container fleet?
  9. Can a held-out site be reserved for evaluation?

Discuss your requirements

If your perception stack needs container and tote imagery, describe the form factors, viewpoints and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources. For the full map of supply routes start at the humanoid training data guide. The catalog entry for images and inspection photos describes the related data type.

Discuss your humanoid training-data requirements with SourceX

Sources

Frequently asked questions

What variety should a container recognition dataset cover for a warehouse robot?

A container recognition dataset should cover the variety a robot will meet, including tote and bin types, sizes, colors, lid states, liners, wear, labels and fill levels, photographed from working viewpoints. Images and attributes support detection and identification, not the handling of a tote's weight, flex or contents.

Why do generic object datasets fall short for site-specific tote and bin recognition?

Generic object datasets treat box or bin as one or two classes, while a site needs the long tail: the three tote footprints in use, foldable crates and dented ones. That tail is more likely to appear in operational photos than in public benchmarks.

Do photos of totes and bins raise rights questions beyond the containers themselves?

Photos taken through an open tote also show products, packing slips and addresses, which raises business and personal data questions. Images with identifiable people, addresses or customer names need to be flagged, and flagging is not the same as clearance.

Describe the data your robots need

Describe the tasks, modalities and permitted uses you need. SourceX reviews the requirement and follows up about potential sources; a request does not guarantee a match.

Discuss your humanoid training-data requirements with SourceX
See if you qualify