Robot Programming, Simulation, and Digital Engineering

Introduction

Robot programming has developed from teaching individual motions at a robot controller to engineering complete cyber-physical production systems. A contemporary robot application may include mechanical design, trajectory generation, perception, safety logic, production databases, simulation, middleware, and real-time control. The engineer must therefore understand not only robot commands, but also how models, software, hardware, and operational data are integrated.

This chapter examines coordinate-based programming, offline programming (OLP), robot simulation, middleware, real-time interfaces, digital twins, virtual commissioning, version control, and hardware- and software-in-the-loop testing. The emphasis is on methods that allow a robot cell to be designed and validated before physical installation, while recognizing the differences between a simulation model and a certified industrial system.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain joint, Cartesian, tool, and work-object coordinate systems.
2. Develop structured robot programs using poses, frames, motion commands, and I/O.
3. Distinguish online programming, offline programming, simulation, and digital twinning.
4. Describe the roles of middleware and real-time communication interfaces.
5. Construct a basic CAD-based simulation and identify its assumptions and limitations.
6. Explain virtual commissioning and hardware- or software-in-the-loop testing.
7. Apply version-control, validation, safety, and documentation practices to robot projects.
8. Evaluate a robot-cell design using technical, operational, and ethical criteria.

1. Robot Programming as Systems Engineering

A robot program is an executable description of a physical process. It specifies where the robot should move, how it should move, when tools should operate, and how the system should respond to sensors and faults. A useful abstraction is:

This is not a physical equation but a systems model. Motion includes position, orientation, velocity, acceleration, and blending. Process logic includes sequencing, branching, recovery, and production recipes. I/O includes digital signals, analogue values, fieldbus messages, and network data. Safety functions must remain under appropriate safety-rated control; ordinary application code must not be treated as a substitute for a safety system.

A robot cell normally contains the robot manipulator, end-effector, fixtures, sensors, controller, programmable logic controller (PLC), safety controller, human–machine interface (HMI), and communication network. Programming must account for their interfaces and timing. A robot that reaches every target in simulation may still fail because of gripper delays, fixture tolerances, network latency, singularities, payload errors, or unsafe access paths.

Terminology

• Pose: Position and orientation of a rigid body.
• Waypoint: A programmed intermediate pose or joint configuration.
• Tool centre point (TCP): The point attached to the tool whose motion is commanded.
• Work object or work frame: A coordinate frame attached to a part, fixture, or workspace.
• Joint-space motion: Motion specified by joint variables.
• Cartesian motion: Motion specified relative to a coordinate frame in Cartesian space.
• Teach pendant: The operator interface used to jog, teach, and execute programs.
• Offline programming: Programming and verification using a computer model rather than exclusively teaching on the physical robot.
• Middleware: Software that manages communication, data representation, services, and coordination between applications and devices.
• Digital twin: A computational representation connected to a physical asset or process through data exchange and maintained for a defined purpose.

2. Coordinate-Based Robot Programming

2.1 Coordinate frames

Robot motion is described using coordinate frames. A frame has an origin and three mutually perpendicular axes. Common frames are the base frame, world frame, tool frame, and work-object frame. The tool frame is especially important because the TCP, rather than the robot flange, is usually the point that performs the operation.

A rigid-body pose can be represented by a homogeneous transformation matrix:

Here, {}^AT_B describes frame B relative to frame A; {}^AR_B is a 3 × 3 rotation matrix; and {}^Ap_B is a 3 × 1 position vector, normally in metres or millimetres. The bottom row makes the matrix suitable for multiplying homogeneous point coordinates. The rotation matrix must be orthonormal and have determinant +1. The transformation is valid for rigid bodies and assumes a right-handed coordinate convention.

Frame transformations compose by matrix multiplication:

The order matters. In general, matrix multiplication is not commutative. An inverse transformation is:

where R and p denote the rotation and position blocks of {}^AT_B.

2.2 Joint and Cartesian commands

A joint command specifies a vector of joint positions, such as q = [q₁,q₂,\ldots,q_n]^T. Joint values may be expressed in degrees or radians, but one project must use a consistent convention. Joint motion is often efficient and avoids unnecessary Cartesian constraints, but the TCP path between two configurations may not be a straight line.

A Cartesian command specifies a desired TCP pose. The controller uses inverse kinematics to calculate joint positions. For a serial robot, the forward-kinematic relationship is:

where q is the joint vector and x represents the pose. Inverse kinematics seeks q such that:

where x_d is the desired pose. Multiple solutions, no solution, joint limits, and singularities may exist. Consequently, a Cartesian target should be accompanied by a preferred configuration, allowable orientation, and approach direction.

Typical motion commands are:

• MoveJ: Joint-interpolated motion; generally fast and useful for free-space travel.
• MoveL: Linear TCP path in Cartesian space; useful for insertion, welding, and approach motions.
• MoveC or circular motion: Circular TCP interpolation; useful for curved process paths.
• Speed and acceleration commands: Define limits or profiles, subject to controller and safety constraints.
• Blend or zone commands: Permit continuous motion through waypoints, reducing cycle time but potentially reducing positional accuracy.

A robust program separates motion data from process logic. For example, the same pick-and-place routine can use different work-object frames for different fixtures rather than duplicating every coordinate. This improves maintainability and reduces the risk of inconsistent edits.

2.3 A structured program pattern

A generic sequence is:

INITIALIZE tool, work frame, speed, payload
CHECK safety state and cell permissives
MOVEJ safe approach configuration
MOVEJ above pick location
MOVEL pick approach
ACTIVATE gripper
WAIT until grip-confirmed or timeout
MOVEL retract
MOVEJ above place location
MOVEL place approach
DEACTIVATE gripper
WAIT until release-confirmed or timeout
MOVEJ safe configuration
REPORT cycle complete

The WAIT steps should have timeouts and fault handling. A program that waits indefinitely can stop production and conceal a sensor failure. A program that ignores confirmation can drop a part or collide with a fixture. Recovery routines should move to a known safe state and provide a diagnostic reason.

3. Offline Programming and CAD-Based Simulation

Offline programming uses a digital model of the robot, tooling, fixtures, parts, and environment. CAD geometry supplies dimensions and interfaces; the robot model supplies joint limits, reach, payload information, and controller-specific motion behavior. The engineer creates targets and paths, tests reachability and collisions, estimates cycle time, and exports a program or data package for the physical controller.

A typical OLP workflow is:

1. Define project units and coordinate conventions.
2. Import and simplify CAD models.
3. Select robot, controller, tool, fixtures, and sensors.
4. Calibrate or define base, tool, and work-object frames.
5. Create process targets and approach/retract paths.
6. Check reachability, joint limits, singularities, and collisions.
7. Simulate I/O, tool operation, and production sequencing.
8. Post-process controller-specific code.
9. Validate on the real controller at reduced speed.
10. Record deviations and update the model.

CAD models often contain excessive detail. Small fillets, threads, and internal features can increase simulation cost without improving collision detection. Simplification should preserve collision-critical surfaces, mounting interfaces, and process geometry.

Model fidelity and uncertainty

A simulation is an approximation. Sources of discrepancy include:

• robot geometric calibration errors;
• fixture and part tolerances;
• tool deflection and payload changes;
• controller interpolation and blending behavior;
• sensor and actuator delays;
• network latency and jitter;
• inaccurate friction or dynamics parameters;
• differences between nominal and installed frame locations.

A useful engineering practice is to classify simulation results as geometric, kinematic, dynamic, or operational validation. A geometric check may establish collision clearance; it does not prove that a flexible tool will not deflect. A kinematic check may establish reachability; it does not prove that the robot can achieve the required acceleration with the actual payload.

Example: reachability and clearance

Consider a planar two-link educational robot with link lengths L₁ = 0.40\ \text{m} and L₂ = 0.30\ \text{m}. Its maximum radial reach, when links are aligned, is:

Its minimum radial reach, when links fold in opposite directions, is:

Therefore, a target at radial distance 0.75 m is unreachable for this ideal planar model, while a target at 0.50 m may be reachable subject to joint limits and orientation requirements. This calculation assumes rigid links, a planar mechanism, and no obstacle or orientation constraint. In a CAD simulation, the same target must additionally be checked against the actual tool geometry and workspace obstacles.

4. Middleware and Real-Time Interfaces

Robot systems rarely operate as isolated controllers. Middleware provides communication abstractions so that planning, perception, control, logging, and visualization components can exchange information. ROS 2 is a prominent robotics middleware ecosystem using nodes, topics, services, actions, interfaces, parameters, and executors. It is compatible with many robots and simulation tools, but compatibility does not automatically mean deterministic hard-real-time control or safety certification.

Communication patterns

• Topic or publish–subscribe: A producer publishes messages and one or more consumers receive them. Suitable for sensor streams and status data.
• Service or request–response: A client requests a bounded operation and receives a response. Suitable for configuration or short transactions.
• Action: A goal is sent, progress is reported, and cancellation is possible. Suitable for long-running navigation or manipulation tasks.
• Direct real-time interface: A controller exchanges periodic commands and feedback with bounded timing. Suitable for servoing when the interface and controller support the required rates.

A real-time loop has a nominal period T and frequency:

For example, if T = 0.001\ \text{s}, then f = 1000\ \text{Hz}. This relationship assumes a stable periodic loop. It does not by itself guarantee real-time performance: computation time must remain below the period, and communication jitter must remain within the application’s tolerance.

In a control or servo interface, the system should specify command age, timestamp conventions, watchdog behavior, maximum permissible latency, and what occurs when messages stop. A safe default is generally to stop or enter a controlled fault state when communication validity is lost, but the exact behavior must follow the robot manufacturer’s and safety system’s requirements.

Interfaces and data contracts

A data contract defines message names, units, coordinate frames, timestamps, valid ranges, and error semantics. For example, a pose message should state whether position is in metres or millimetres, whether orientation uses a quaternion or Euler angles, and which frame the pose references. Many integration failures are semantic rather than electrical: a message arrives correctly but is interpreted in the wrong frame or unit.

5. Digital Twins and Virtual Commissioning

A digital twin is more than a static CAD model. It normally includes a computational model, a physical asset or process, a connection between them, and a defined purpose such as monitoring, optimization, diagnostics, or commissioning. The twin may operate at different fidelity levels. A geometric twin represents shape and pose; a kinematic twin represents motion constraints; a dynamic twin includes masses, forces, and timing; an operational twin includes PLC logic, recipes, alarms, and production states.

Virtual commissioning (VC) uses a virtual plant to test automation before or during physical installation. The actual PLC program may communicate with a simulated robot, conveyor, sensors, and actuators. This can reveal sequence errors, deadlocks, incorrect sensor logic, and unsuitable timing earlier than traditional commissioning.

A useful distinction is:

The terms are related but not interchangeable. A robot simulation may not contain the real PLC. A digital twin may be used after commissioning rather than for initial design. VC focuses particularly on validating automation and sequence behavior against a virtual plant.

6. Software- and Hardware-in-the-Loop Testing

Software-in-the-loop (SIL) executes the control or planning software against simulated plant behavior. It is inexpensive and repeatable, making it useful for unit tests, regression tests, path planning, and fault scenarios. SIL cannot reveal failures caused by physical wiring, controller scan behavior, sensor electrical characteristics, or mechanical compliance.

Hardware-in-the-loop (HIL) connects real hardware—such as a PLC, robot controller, drive, or safety-related interface—to a real-time simulation. HIL tests interfaces and timing without requiring a complete physical cell. It is more representative than SIL but more costly and technically demanding.

Testing should proceed in layers:

1. Unit tests for functions and transformations.
2. Model tests for frames, kinematics, and collision geometry.
3. SIL tests for sequences and fault handling.
4. HIL tests for communication, timing, and controller behavior.
5. Reduced-speed physical tests with guarded access.
6. Production validation using defined acceptance criteria.

Test cases should include normal cycles and abnormal conditions: missing parts, failed grip confirmation, emergency stop, communication loss, sensor disagreement, invalid recipe, power restoration, and recovery from an interrupted cycle. Each test should have a precondition, input, expected result, measured result, and disposition.

7. Version Control, Configuration, and Reproducibility

Robot projects contain many artifacts: robot programs, CAD files, controller backups, PLC code, ROS packages, configuration files, calibration records, simulation scenes, safety documents, and test reports. Version control provides a history of changes and supports collaboration. Git is commonly used for text-based source code, while large binary CAD or controller files may require appropriate artifact storage and naming conventions.

A professional repository should identify:

• project and robot-cell version;
• software and firmware versions;
• coordinate-frame definitions and calibration dates;
• tool and payload data;
• dependencies and container or build instructions;
• test results and known limitations;
• approval status for deployment.

A commit should describe one coherent change. Branches and pull requests support review, while tags can identify released configurations. Secrets, passwords, and production credentials should not be stored in ordinary repositories. Reproducibility requires more than preserving code: the exact model, dependency versions, parameters, compiler or interpreter version, and calibration data may affect behavior.

Change control is particularly important for safety-related functions. A seemingly minor change to a speed, frame, payload, or approach point may alter risk. Such changes require review and revalidation rather than informal editing on the shop floor.

8. Safety, Standards, and Responsible Engineering

Robot programming must be integrated with risk assessment and safeguarding. Hazards include crushing, impact, unexpected restart, sharp tools, stored energy, ejected workpieces, electrical hazards, and interaction with collaborative workspaces. A simulation can support hazard analysis but cannot replace a formal assessment.

The engineer should distinguish ordinary control from safety control. Emergency stops, guard interlocks, enabling devices, safe limited speed, safe limited position, and safe torque or force functions must be implemented through suitable safety-rated architectures where required. Relevant standards depend on jurisdiction and application; examples include ISO 10218 for industrial robots, ISO/TS 15066 for collaborative robot applications, ISO 12100 for machinery risk assessment, and IEC 61508-related functional-safety principles. Current editions and local legal requirements must be verified before deployment.

Digital engineering also creates governance issues. A connected robot may collect worker images, production data, or maintenance records. Access control, cybersecurity, data minimization, secure updates, and audit trails are therefore engineering requirements. An AI-based vision or planning system should be evaluated for false detections, bias in training data, explainability of failure modes, and a safe response when confidence is low. AI should not silently override a validated safety function.

9. Illustrative Case: Virtual Commissioning of a Pick-and-Place Cell

Background

A manufacturer is designing a cell in which a six-axis robot removes housings from an infeed conveyor, places them in a fixture, and transfers completed parts to an outfeed conveyor. The cell includes a PLC, photoelectric sensors, a vacuum gripper, a safety scanner, and an HMI.

Problem

The first physical prototype experienced three issues: the robot occasionally approached a housing before the conveyor had stopped, the vacuum sensor was ignored after a timeout, and the PLC sequence could remain waiting indefinitely when a part was absent. Reprogramming during installation increased downtime.

Analysis

The engineering team built a CAD-based model containing the robot, gripper, conveyor, fixtures, scanner zones, and simplified housings. A virtual PLC interface represented conveyor states, part-present signals, vacuum confirmation, and safety permissives. The team identified that the original sequence lacked an explicit handshake between conveyor stopping and robot permission. It also found that a nominal gripper delay had been omitted from the cycle model.

Approach

The revised sequence used the following state structure:

1. Idle: Wait for production enable and a valid recipe.
2. Request part: Command conveyor and wait for part-present confirmation.
3. Stop and verify: Command conveyor stop and require stopped feedback.
4. Pick: Approach, activate vacuum, and require vacuum confirmation within a timeout.
5. Place: Move through a collision-checked path and release the part.
6. Verify: Confirm release and fixture state.
7. Complete or fault: Record the cycle result and enter a defined recovery state.

The PLC was tested against the simulated plant using virtual commissioning. Fault cases included absent parts, failed vacuum, safety scanner interruption, delayed conveyor stopping, and communication loss. The physical robot controller was then connected in HIL testing, first at reduced speed and with simulated I/O, followed by guarded physical trials.

Outcome

The virtual tests exposed sequence deadlocks and an approach path with insufficient clearance. The HIL test revealed that a real controller’s status update was slower than the simulated status update, so the timeout and handshake logic were adjusted. Physical commissioning then required calibration and speed verification rather than redesign of the sequence.

Learning points

1. A digital model is valuable when it represents the interfaces and timing that matter to the process.
2. Explicit state machines are easier to test than unstructured waits and jumps.
3. Timeouts, fault states, and recovery paths are essential production features.
4. Simulation reduces risk but does not eliminate physical validation.
5. The model must be updated when measured physical behavior differs from assumptions.

10. Best-Practice Design Procedure

A practical robot-programming project should follow these principles:

• Establish units, frames, naming conventions, and configuration baselines before programming.
• Use a calibrated TCP and work-object frame; document how each was measured.
• Separate process logic, motion data, device drivers, and safety functions.
• Prefer meaningful named targets over unexplained coordinate arrays.
• Use approach and retreat points to control collision risk.
• Add confirmation signals and bounded timeouts to every important action.
• Test singularities, joint limits, payload changes, and communication loss.
• Keep simulation, controller, PLC, and CAD revisions traceable.
• Validate exported programs on the real controller at reduced speed.
• Require independent review for safety-relevant changes.
• Record assumptions, deviations, calibration results, and acceptance evidence.

11. Contemporary Developments

Current practice is moving toward cloud-supported engineering, containerized development, standardized robot descriptions, physics-based simulation, and continuous integration for automation software. ROS 2 and similar middleware support modular systems, while industrial protocols increasingly provide structured data and diagnostics. Machine learning is being applied to perception, grasp selection, anomaly detection, and predictive maintenance.

These developments improve flexibility but increase integration complexity. A model trained in simulation may suffer from the sim-to-real gap caused by lighting, friction, sensor noise, and unmodeled objects. Domain randomization, physical calibration, confidence thresholds, and fallback behaviors can reduce but not remove this gap. The responsible engineer treats AI as a component within a verified system, not as evidence that verification is unnecessary.

Chapter Summary

Robot applications are engineered systems combining coordinate-based motion, process logic, I/O, safety, and data. Joint and Cartesian commands serve different purposes, and reliable programming depends on correctly defined tool and work-object frames. Homogeneous transformations provide a consistent method for composing rigid-body poses, while inverse kinematics connects Cartesian targets to joint configurations.

Offline programming and CAD-based simulation support path creation, reachability analysis, collision checking, cycle-time estimation, and early debugging. Their results depend on model fidelity and must be confirmed against physical behavior. Middleware such as ROS 2 enables modular communication, but real-time performance requires explicit attention to timing, latency, jitter, watchdogs, and message semantics.

Digital twins, virtual commissioning, SIL, and HIL form complementary validation approaches. Version control and configuration management make robot systems reproducible and auditable. Safety-rated functions, cybersecurity, data governance, and responsible use of AI are essential parts of contemporary digital engineering. The most effective workflow combines simulation with layered testing and disciplined physical commissioning.

Key Terms

Coordinate frame: An origin and oriented axes used to describe position and orientation.

Homogeneous transformation: A matrix representation combining rotation and translation.

Tool centre point: The defined point on a tool whose motion is commanded.

Work-object frame: A frame attached to a workpiece, fixture, or workspace.

Joint-space motion: Motion specified by robot joint variables.

Cartesian motion: Motion specified by a position and orientation in a coordinate frame.

Forward kinematics: Calculation of pose from joint values.

Inverse kinematics: Calculation of joint values for a desired pose.

Offline programming: Robot programming using a computer model away from the physical cell.

CAD-based simulation: Simulation using computer-aided-design geometry and system models.

Middleware: Software supporting communication and coordination among system components.

Real-time interface: An interface with defined timing and bounded response requirements.

Digital twin: A connected computational representation of a physical asset or process.

Virtual commissioning: Testing automation against a virtual plant before physical commissioning.

Software-in-the-loop: Testing software with a simulated plant or environment.

Hardware-in-the-loop: Testing physical control hardware connected to a real-time simulation.

Version control: Managed recording of changes to software and engineering artifacts.

Virtual commissioning: Validation of automation logic using simulated equipment and processes.

Sim-to-real gap: Difference between simulated behavior and behavior of the physical system.

Review Questions

Short Answer Questions

1. What is the purpose of a tool centre point?
2. Distinguish joint-space motion from Cartesian motion.
3. Why are timeouts important in robot programs?
4. What is the main purpose of middleware in a robot system?
5. State one limitation of CAD-based simulation.

Long Answer Questions

1. Explain how homogeneous transformations support robot programming and frame calibration.
2. Describe a complete offline-programming workflow from CAD import to physical validation.
3. Compare software-in-the-loop, hardware-in-the-loop, and virtual commissioning.
4. Explain how version control and configuration management improve robot-cell reliability.
5. Discuss the relationship between robot programming, risk assessment, and safety-rated control.

Analytical / Application Questions

1. A robot reaches a target in simulation but collides with a fixture during installation. Identify at least four possible causes and propose a validation plan.
2. Design a state-machine sequence for a pick-and-place cell that handles absent parts, failed gripping, safety interruption, and communication loss.
3. A ROS-based planner publishes poses in metres relative to a world frame, while the robot controller expects millimetres relative to a work-object frame. Explain the transformations and interface checks required before deployment.

Multiple Choice Questions with Answers

Question 1

Which coordinate frame is normally attached to the end-effector and used to define the commanded process point?

A. World frame

B. Tool frame

C. Cell frame

D. PLC frame

Correct Answer: B. Tool frame

Question 2

What is the main characteristic of a MoveL command?

A. It interpolates joint angles independently

B. It moves only one joint

C. It maintains a linear TCP path in Cartesian space

D. It disables collision checking

Correct Answer: C. It maintains a linear TCP path in Cartesian space

Question 3

For a loop period of T = 0.001\ \text{s}, what is the nominal frequency?

A. 1 Hz

B. 10 Hz

C. 100 Hz

D. 1000 Hz

Correct Answer: D. 1000 Hz

Question 4

Which activity most directly tests a real PLC against a simulated plant?

A. CAD review

B. Software-in-the-loop

C. Virtual commissioning

D. Manual teaching

Correct Answer: C. Virtual commissioning

Question 5

Why must the order of homogeneous transformation multiplication be preserved?

A. Rotations have no units

B. Matrix multiplication is generally non-commutative

C. Translations cannot be represented in matrices

D. All robot frames are identical

Correct Answer: B. Matrix multiplication is generally non-commutative

Question 6

Which response is most appropriate when a gripper confirmation signal does not arrive?

A. Continue without checking

B. Increase robot speed

C. Use a bounded timeout and enter a defined fault or recovery state

D. Delete the sensor from the program

Correct Answer: C. Use a bounded timeout and enter a defined fault or recovery state

Question 7

What is a principal limitation of software-in-the-loop testing?

A. It cannot test algorithms

B. It cannot reveal all physical wiring and hardware-timing failures

C. It requires a complete physical cell

D. It cannot simulate sensors

Correct Answer: B. It cannot reveal all physical wiring and hardware-timing failures

Question 8

Which item is essential in a data contract for a robot pose message?

A. Screen brightness

B. Operator nationality

C. Reference frame and measurement units

D. CAD file colour

Correct Answer: C. Reference frame and measurement units

Question 9

What does a digital twin generally require beyond a static CAD model?

A. A connection to a physical asset or process and a defined engineering purpose

B. A larger monitor

C. Only a rendered image

D. Removal of all physical measurements

Correct Answer: A. A connection to a physical asset or process and a defined engineering purpose

Question 10

Which practice best supports reproducibility of a robot application?

A. Editing production files without records

B. Storing only the latest executable

C. Tracking code, dependencies, parameters, calibration, and test evidence

D. Using undocumented coordinate arrays

Correct Answer: C. Tracking code, dependencies, parameters, calibration, and test evidence