> For the complete documentation index, see [llms.txt](https://doc.realvirtual.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.realvirtual.io/components-and-scripts/motion.md). # Motion and Kinematic Motion axes are modeled by connecting [Drives](/components-and-scripts/motion/drive.md) to GameObjects. The [Drive](/components-and-scripts/motion/drive.md) will move the GameObject, including its sub-components, along a defined rotational or linear axis. The [Drive](/components-and-scripts/motion/drive.md) is a base component with some generic [Drive](/components-and-scripts/motion/drive.md) behavior but it does not expose a Signal interfaces to a PLC. For this a [Drive Behavior](/components-and-scripts/motion/drive-behavior.md) script is added in addition to the [Drive](/components-and-scripts/motion/drive.md) script for the GameObject. The [Drive Behavior](/components-and-scripts/motion/drive-behavior.md) includes special behaviors (such as pneumatic cylinders or position controlled drives) including any signals supporting the special behavior. {% hint style="info" %} The standard units for drive positions in all realvirtual.io components are millimeters for linear drives and degrees for rotational drives. The standard units for speeds are millimeters per second and degrees per second. In Unity, each millimeter is represented as one Unity unit (which means what you see in the Transform component in Unity is in meters). You can adjust the scale in **realvirtualController**, but this is generally not recommended. {% endhint %} ## Choosing a Motion Approach realvirtual offers several complementary ways to move geometry. Pick the one that matches how your mechanism is built: * [**Drive**](/components-and-scripts/motion/drive.md) **+ hierarchy** — the standard, and the right choice for the vast majority of axes. A Drive moves a GameObject and all its children along one linear or rotational axis. Chain Drives through the Transform hierarchy to build serial kinematics (a stacked XYZ gantry, a conveyor, a simple robot wrist). Add a [Drive Behavior](/components-and-scripts/motion/drive-behavior.md) for PLC signals and special behaviors (pneumatic cylinders, position control). * [**Kinematic Joints**](/components-and-scripts/motion/kinematic-joints.md) ***(Professional)*** — a position-based constraint solver for **closed kinematic chains** that a parent/child hierarchy cannot express, because one link has to satisfy more than one constraint at once. Use it for Delta robots, four-bar linkages, scissor lifts and parallel grippers. Drives still drive the active joints; the solver positions every passive link each FixedUpdate, without physics, jitter or drift. Its `KinematicTarget` companion adds inverse (Cartesian-target) control to the same mechanism. Runs in a native, multi-threaded solver that scales to hundreds of mechanisms. * [**Joint**](/components-and-scripts/motion/joint.md) — a PhysX-based joint. Physics joints are force-driven and iterative, so they tend to **jitter, sag and drift**: a closed loop never settles perfectly, springs and dampers have to be tuned, and the same input can give slightly different results from run to run. Use PhysX joints only when you genuinely want dynamic behaviour (falling parts, collisions, compliance) — not when you need an exact, repeatable mechanism pose. * [**Kinematic**](/components-and-scripts/motion/kinematic.md) — a CAD import helper that groups parts and corrects pivots; despite the similar name it is unrelated to Kinematic Joints. * **Robot IK *****(Professional)*** — dedicated inverse kinematics for standard serial 6-axis and collaborative robots, with path planning and blending (see [Robot Inverse Kinematics](/components-and-scripts/robot-inverse-kinematics.md)). {% hint style="success" %} **Accuracy over physics for mechanisms.** For any mechanism where the pose has to be *correct* — a Delta robot picking to an exact point, a linkage indexing to a fixed stop, a gripper closing to a precise width — prefer [**Kinematic Joints**](/components-and-scripts/motion/kinematic-joints.md) over PhysX joints. The constraint solver satisfies the geometry exactly every FixedUpdate with no jitter, no drift and fully deterministic, repeatable results, while a physics joint only ever approximates the constraint and needs tuning to stay stable. In realvirtual, physics is mainly used for the **parts (MUs) themselves** — parts falling, colliding, singulating and accumulating on [transport surfaces](/components-and-scripts/motion/transportsurface.md), in chutes and in bins — where the dynamic, force-driven behaviour is exactly what you want. Use physics for the material flow; use Drives and Kinematic Joints for the machine's own moving structure. {% endhint %} The rest of this page focuses on the standard [Drive](/components-and-scripts/motion/drive.md). This Youtube tutorial shows how to define [Drives](/components-and-scripts/motion/drive.md) {% embed url="" %} Tutorial Adding Drives {% endembed %} > We supply seveal standard Behavior models, but due to the large variety of automation devices and functionality, it is most likely you will need to add your own behavior models. The next image gives a good overview of [Drives](/components-and-scripts/motion/drive.md) moving GameObjects. The [Drive](/components-and-scripts/motion/drive.md) is contolled by a special Drive Behavior which is connected to one or more Signals. The Signals are then connected to a PLC (using an [Automation Interface](https://game4automation.com/documentation/current/interface.html))
© 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.realvirtual.io/components-and-scripts/motion.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.