Simulation & transfer
Collision detection
Collision detection determines whether geometric representations of a robot, itself, or its environment intersect or come within a specified distance. Robotics systems use it for self-collision checking, environment collision checking, motion planning, simulation, and safety monitoring, but its result depends on the geometry, poses, margins, and update timing supplied.
Also known as: robot collision checking, collision checking
Updated
Collision checking operates on a model
MoveIt's planning scene combines robot state with a representation of the surrounding world for collision queries. Checks may include robot links against obstacles and one robot link against another.
The geometry is usually simplified relative to the physical surfaces. Primitive shapes or reduced meshes make queries faster but can add false clearances or false collisions. An allowed-collision matrix may deliberately ignore pairs that are always adjacent or permitted to touch.
Discrete and continuous checks answer different questions
A discrete check tests geometry at a particular configuration. A fast motion can be clear at two sampled endpoints while passing through an obstacle between them. Continuous collision detection considers motion over an interval. The Flexible Collision Library supports collision, distance and continuous-collision queries for common geometric representations.
Distance thresholds and safety padding can be more useful than a binary intersection result when localisation and geometry are uncertain.
Detection is not physical contact prediction
Collision detection identifies geometric overlap or proximity. A contact model estimates forces or impulses after contact, and a safety system must decide how the robot responds. None of these guarantees that an unmodelled person or object will be sensed.
Simulation and planning records should version the collision meshes, disabled pairs, margins, environment geometry and checking resolution. When reporting collision-free demonstrations, state whether clearance was checked continuously and whether the scene came from measured geometry or a curated model.
Sources
Related terms
Hardware & control
Motion planning
Motion planning is the computation of a feasible path or trajectory that moves a robot from an initial condition toward a goal while satisfying constraints such as collision avoidance, joint limits, contact, balance, or dynamics. The planner searches over possible robot motions; a controller is still needed to execute the result.
Hardware & control
Robot embodiment
A robot embodiment is the particular body and sensorimotor interface through which a robot perceives and acts. It includes morphology and kinematics, actuators, end effectors, sensors, physical limits, and the observation and action conventions exposed to a controller or learned policy. Two robots can perform the same task while having different embodiments.
Simulation & transfer
Digital twin
A digital twin is a fit-for-purpose digital representation of a specific physical robot, asset or process that is kept synchronised with its real counterpart through operational data. It may contain geometry, dynamics and simulation models, but the maintained link to an identified real system distinguishes it from an ordinary, standalone simulator.
Data & collection
Robot state
Robot state is the set of variables used to describe a robot at a particular time, such as joint positions and velocities, base pose, end-effector pose, gripper state, actuator measurements, or estimated motion. In control theory, a complete state contains enough information to predict future evolution given an action; in robot datasets, “state” often means only the measured or estimated subset that was logged.
Data & collection
Trajectory
A trajectory is a time-ordered sequence of states or observations, actions and, where applicable, rewards generated as an agent or robot evolves. A complete episode or policy rollout often yields a trajectory, but the terms are not universally identical: trajectories may be partial, while episodes have dataset- or environment-defined boundaries.
Simulation & transfer
Sim-to-real
Sim-to-real is the transfer of a model, policy or behaviour developed wholly or partly in simulation to a physical robot or real environment. The central problem is the reality gap: errors in simulated dynamics, sensing, appearance and timing can make a strategy successful in simulation but unreliable or unsafe on hardware.