One of the big advantages of Unity is the very fast Physics simulation. It is based on the NVIDIA Physics engine extended with the Unity API. The Unity engine is capable of simulating very large systems with a many meshes and moving objects. This is combined with a very realistic and good real time rendering.
The Game4Automation approach relies on a combination of physical and kinematic movement capabilities. In some cases it is an advantage to use physical movements and in other cases it is recommended to use purekinematic movements.
There are simulation systems on the market, that are using only one of these two principles. The strength of Unity and Game4Automation is, that we can combine both worlds for achieving very realistic, high performing, stable and accurate models.
Very often in automation systems you need free moving objects. We call these objects in Game4Automation anMU, i.e. a movable unit. MUs can represent goods on a conveyor or items on a feeding tray, generally the products moving around in a factory scene. Physical movements means , that these MUs move around based on physical collision, forces and gravity. As in the real word. This allows for very realistic behavior and takes into account all collision between MUs and the environment, and without the need for programming any special motion or behaviour logic. In Unity everything that is simulated via the Physics-Engine needs a Rigid-Body attached.
As you can see Use Gravity is enabled and the Is Kinematic property is turned off.
For parts that do not move freely like MUs, kinematic parts are defined to represent the motion for factory machinery and equipment. For example motor driven axes as found in a robot and automatic machinery are all represented with kinematic motion. Kinematic means that the position of the drive and the kinematic chain for several axes is defined exactly through their geometrical relationship and Newtonian maths excluding any force effects. Forces and the possibility that the kinematic chain can break is not considered for these simulation and virtual commissioning scenarios. The engine calculates the exact current position of a part based on the various drive positions. We call this the kinematic movements.
Even though Unity supports the definition of kinematic chains based on Rigid-Bodies with physics joints, we don’t advise using them. Kinematic on Rigid-Bodies are not accurate enough for exactly defined movements found in production machinery.
Kinematic movements are realized based on the Gameobject hierarchy. This means that, if we move a parent object also the child object moves. This is the standard Unity behavior for non physical objects. These objects should still be equipped with a Rigid-Body for precise position and sensor collision detection but the Use Gravity property needs to be turned off and the Is kinematic property needs to be turned on.
This is how a moving arm of a robot looks like:
If you attach a Drive to a hierarchy level, Game4Automation automatically handles property settings for Kinematic movements.
To deliver fast collision detection, Game4Automation uses an individual collision matrix. This matrix is automatically generated when you select Tools > game4automation > Apply standard settings.
Game4Automation is using the following special collision layers:
|g4a SensorMU||Layer for the collision body of moving units (MUs) that should interact with sensors such as light barriers. Due to the limitations with the Mesh Collider this collision body should be a Box Ccollider.|
|g4a TransportMU||Layer for the transport collision body of an MU. This can be a mesh collider to provide realistic MU collisions.|
|g4a Sensor||Layer for Sensor detection areas such as light beams and so on. Usually this should be a box collider.|
|g4a Transport||Layer for the collision body of transport surfaces or for placing objects onto a plate.|
|g4a MU||Layer for MUs where one box collider is sufficient for transport collisions and sensor detections.|