Two robotics datasets may expose an action column with the same number of values and still describe different things. One collection may record motor targets, while another describes the intended position of a tool tip. A successful file import only establishes that a reader accepted the records. Before combining the datasets for pretraining, the team needs to establish whether their action meanings can be interpreted together.
Matching array shapes is not a sufficient action-data contract. Database buyers should evaluate how the proposed workflow preserves the meaning needed to prepare training examples, alongside its ability to store and retrieve them.
Describe what each action refers to
Begin with a short, human-readable description of each collection’s action fields. Identify the robot or relevant hardware description, the meaning of the components, and the coordinate or reference convention the data producer reports. An absent description should be treated as a question to resolve, not filled in by copying the convention from a familiar dataset.
Consider a hypothetical merger in which both sources use a column called action. Renaming the columns to the same standard name may simplify loading, but it does not establish that the components correspond. The review should examine the producer’s description and a suitable interpreted example before deciding what a shared training representation would mean.
Distinguish action space from action reference
LeRobot’s action-representation guide distinguishes joint-space actions from end-effector-space actions. It separately distinguishes absolute target positions, relative offsets referenced to the current state at prediction, and sequential delta differences. These are scoped descriptions in that guide, not a claim that every dataset uses the same terminology consistently.
For the proposed merger, record the actual convention used by each source. Do not infer it solely from a field name or a numerical range. Treat a conversion as a separate preparation decision requiring the appropriate source context and specialist validation. This article does not provide a robot-control procedure or recommend deploying converted actions on physical equipment.
Build a meaning map before combining records
The following worksheet is a suggested review aid. Its purpose is to expose unanswered interpretation questions before they become silent assumptions in a combined collection.
| Review item | What the team should establish | Insufficient evidence |
|---|---|---|
| Component identity | What each value describes | Same array length |
| Action space | Which kind of target is represented | A generic action column name |
| Reference convention | What the target or offset refers to | Similar numerical ranges |
| Source context | Which hardware and description apply | A familiar dataset format |
| Preparation decision | How the training input will be interpreted | Import completed without an error |
Keep exceptions visible. Some fields may have a different meaning from the main motion components, and the responsible team should identify how it intends to handle them. A convenient uniform schema should not erase those distinctions merely to make the merged table easier to query.
Preserve the preparation decision
If the team adopts a shared representation, connect the prepared examples to the original release and the transformation decision. This provides an explanation for the derived values without pretending that the original data always had the new meaning. Keep unconverted and prepared material distinguishable in the selection workflow.
For example, a hypothetical experiment might accept one source directly while holding another for further interpretation. The collection tool should be able to represent that choice without rewriting the second source’s metadata as though review were complete. A partially understood dataset may be useful for investigation; that does not make it ready for the same training use as an already interpreted collection.
Put the database comparison in the right place
OceanBase Database can be considered for relational metadata that connects dataset releases, action descriptions, preparation decisions, and selected examples. PostgreSQL or MySQL can also be evaluated for these relationships. Compare implementations on the actual metadata questions and the operating requirements of the project.
The training-data reader and preparation pipeline still have their own responsibilities. Storing action arrays or description references in OceanBase does not itself convert coordinates, establish equivalent hardware behavior, or validate a trained policy. The useful demonstration follows a source example through the recorded interpretation and into the intended training input, with unresolved questions still visible.
Check meaning before reviewing numerical scaling
Action interpretation and numerical normalization answer different questions. The first asks what a value denotes. The second concerns how already understood values are prepared for a model. A team should not assume that applying a numerical transformation makes two incompatible action meanings equivalent.
A bounded acceptance review therefore starts with source interpretation, identifies any proposed conversion, and asks the relevant specialists to validate the prepared examples for the stated experiment. This is a proposed process, not a completed training or safety test. Its value is that the database and collection workflow retain the explanation instead of allowing a successful merge to stand in for an understood dataset.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.