Physics
Simulating real world physics
Last updated
Simulating real world physics
Last updated
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
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.
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:
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.
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
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:
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
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.
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).
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.
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.
