Physics

Simulating real world physics

One of the great advantages of Unity is the very well-functioning physics simulation. It is based on the NVIDIA PhysX engine, which has been extended with the Unity API.

The Unity engine is able to simulate very large systems with many meshes and moving objects. This is combined with a very realistic and good real-time rendering. The approach of realvirtual.io is based on a combination of physical and kinematic motion capabilities. In some cases it is advantageous to use physical movements, in other cases it is recommended to use purely kinematic movements. The strength of Unity and realvirtual.io is that we can combine both worlds to get very realistic, powerful, but also stable and accurate models.

If you need very high quality physics simulation with multi contact simulation and high accurate dynamics, you can also use AGX Dynamics for Unity, which is supported by realvirtual.io

Physical and kinematic movements

Free physical movements of movable units

In automation systems, freely movable objects are very often required. We call this kind of objects in realvirtual.io MU (movable unit). MUs are goods on a conveyor belt or objects on a workpiece carrier, in general the products moving in a Digital Twin of a production system. Physical movements means that these MUs move due to physical collisions, forces and gravity. Just like in the real world. This allows for very realistic behavior and takes into account all collisions between MUs and the environment without having to program any special motion or behavior logic. In Unity, everything simulated via the Unity Physics Engine must hava a RigidBody component attached to.

In realvirtual.io, Sources (see the Source section) create MUs. After a MU is created, the physical properties look like this:

As you can see Use Gravity is enabled and the Is Kinematic property is turned off.

Is Kinematic turned off (false) means, that the object is freely moving based on collisions and physical forces.

Stability of TransportSurfaces

Normal transport on conveyor systems is modelled by TransportSurfaces. If your transport system is very complex and you have a lot of colliders you should consider the following things:

  • use the simples colliders possible (best is box collider)

  • put the colliders on the standard layers (see #colission-matrix)

  • You can limit the freedom of the RigidBodies with a setting on the TransportSurface:

Kinematic movements

For parts that do not move freely physically like MUs are defined as kinematic parts.

This applies, for example, to the motion of the machines themselves. For example, motor-driven axes, such as those found in robots and machines, are all represented with kinematic motion. Kinematic means that the position of the drive and the kinematic chain for multiple axes is precisely defined by their geometric parent - children relationship, excluding any application of force.

Forces and the possibility that the kinematic chain may break are not considered in purely kinematic simulations. The engine calculates the exact current position of a part based on the different drive positions. We call this the kinematic motions.

Trying to represent e.g. a robot via PhysX joints (i.e. not kinematic) is often problematic, because the PhysX physics solver has a kind of "spring effect" in the axes themselves so that exact positioning is not possible. Therefore we use kinematic movements for this purpose.

Kinematic movements are realized based on the GameObject hierarchy. This means that when a parent object moves, the child object also moves. This is Unity's default behavior for non-physical objects. These objects must still have a RigidBody to allow accurate position and sensor collision detection, but the Use Gravity property must be turned off and the IsKinematic property turned on.

IsKinematic turned on (true) means, that the GameObject moves based on the parent child relation and the local transform positions. There is no spring effect in the joints and there are no forces calculated.

This is how a moving arm of a robot looks like:

If you attach a Drive to a hierarchy level, realvirtual.io automatically adds a RigidBody and handles property settings for Kinematic movements.

Articulation Body

With Unity 2020.1 the physics was upgraded to PhysX4.0. Unity introduced the new concept of articulation: a set of bodies organized in a logical tree, where a parent-child relation expresses the idea of mutually constrained motion. There is always a single root body, and there can be no loops. The transform hierarchy is used to express articulations. The amount of degrees of freedom in a given parent-child relationship depends on the actual joint type used. For more information please check https://docs.unity3d.com/2020.3/Documentation/ScriptReference/ArticulationBody.html

To use Articulation Bodies is just an option. We still recommend to use standard realvirtual.io Kinematic definitions based on drives and transforms.

If you would like to use Articulation Bodies you must attach the realvirtual.io Drive to the Articulation Body. The Drive position will now be transformed to the Articulation Body.

The Drive direction needs to be set to "virtual" because the Direction of the Joint (and the connected drive) will be defined by the Articulation Body.

You can check an example on realvirtual.io Community Github https://github.com/game4automation/game4automation-Community/tree/main/in2sight/Robots/ABB/IRB7600-400-255

Collision Matrix

To deliver fast collision detection, realvirtual.io uses an individual collision matrix. This matrix is automatically generated when you select Tools > realvirtual > Apply standard settings.

realvirtual.io is using the following special collision layers:

Layer (until 2021)Layer (2022 and above)Description

g4a SensorMU

rvMUSensor

Layer for the collision body of moving units () that should interact with sensors such as light barriers. Due to the limitations with the Mesh Collider this collision body should be a Box Collider.

g4a TransportMU

rvMUTransport

Layer for the transport collision body of an. This can be a mesh collider to provide realistic collisions.

g4a Sensor

rvSensor

Layer for detection areas such as light beams and so on. Usually this should be a box collider.

g4a Transport

rvTransport

Layer for the collision body of transport surfaces or for placing objects onto a plate.

g4a MU

rvMU

Layer for MUs where one box collider is sufficient for transport collisions and sensor detections.

g4a Snapping

rvSnapping

Only used in Simulation Library - Layer for snapping detection

g4a CollisionDynamic

rvSimDynamic

Only used in Simulation Library - Layer for moving Transportables on path system

g4a CollissionSatic

rvSimStatic

Only used in Simulation Library - Layer for detecting Transportables on path system, used by Workstations

g4a Postprocessiong

deleted

not used - for future usage

g4a Lamps

deleted

not used - for future usage

g4a Debug

deleted

not used - for future usage

Physic solver settings

Physics settings are described in detail on the Unity webpage but we would like give you some hints based on our experience.

First of all you should only change something in the Physics settings, if you are not happy with stability and performance. Usually the standard settings work quite well.

Physics Step Time

Unity is calculating physics in a fixed steptime. This is when the FixedUpdate methods are getting called. You can change the time steps by selecting Edit > Project Settings > Time:

The standard setting is 20ms. You can decrease it e.g. to 5ms. This will increase physical calculation quality but also increase your processor load. If your processor load is getting to high you well see that screen update rates are getting low (e.g. 60ms and less).

Solver Iterations

Another possibility to generate better physics simulation is to increase the solver iterations. You can increase solver iterations to generate better quality but this will increase also your load. Typically, it’s used to reduce the jitter resulting from joints or contacts.

Physics Solver

Another setting which usually generates better physics is to change the solver type from standard (Projected Gauss Seidel) to Temporal Gauss Seidel.

It usually helps when you experience some erratic behavior during simulation with the default solver. We recommend to use this setting.

For more information check the Unity documentation:

© 2022 in2Sight 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