For the complete documentation index, see llms.txt. This page is also available as Markdown.

Motion and Kinematic

Motion axes are modeled by connecting Drives to GameObjects. The Drive will move the GameObject, including its sub-components, along a defined rotational or linear axis. The Drive is a base component with some generic Drive behavior but it does not expose a Signal interfaces to a PLC. For this a Drive Behavior script is added in addition to the Drive script for the GameObject. The Drive Behavior includes special behaviors (such as pneumatic cylinders or position controlled drives) including any signals supporting the special behavior.

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.

Choosing a Motion Approach

realvirtual offers several complementary ways to move geometry. Pick the one that matches how your mechanism is built:

  • Drive + 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 for PLC signals and special behaviors (pneumatic cylinders, position control).

  • Kinematic Joints (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 — 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 — 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).

The rest of this page focuses on the standard Drive.

This Youtube tutorial shows how to define Drives

Tutorial Adding Drives

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 moving GameObjects. The Drive 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)

© 2025 realvirtual GmbH 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.

Last updated