Robot Programming & Simulation

The old, direct way is the teach pendant: a handheld console, wired to the controller, with which an operator physically jogs the arm - driving each joint or the TCP with buttons or a joystick - to a desired pose and presses 'save' to record that point. String the saved points together and you have a program. Teaching is intuitive, needs no computer model, and is perfect for a handful of points (a simple pick-and-place). Its limits are brutal for architecture: it is slow, it holds the robot out of production while you teach, the operator is in or beside the cell with the arm powered (a real hazard, mitigated by a hold-to-run 'deadman' switch and reduced teach-speed), and it cannot practically handle the thousands of unique points a fabrication path needs.

The modern way is offline programming (OLP): you build the entire program in software, on a computer, against a virtual model of the cell, and only send it to the real robot once it is proven. Nothing about the robot moves while you program; the arm keeps producing the previous job. Offline programming is the only sane way to drive the complex, parametric, thousands-of-points toolpaths that architectural fabrication generates - and, crucially, it lets you simulate before you run. Most real workflows blend the two: program offline, then fine-tune a few critical points on the pendant at teach-speed.

Architecture programs robots where it already models: inside Grasshopper, the visual programming environment for Rhino. Rather than learn a manufacturer's proprietary language, designers define the tool path parametrically - as a list of target planes (each a position plus orientation for the TCP) generated by the same geometry that drives the design - and a plugin turns those planes into robot instructions. This is the bridge between the parametric world of an earlier course and the physical robot.

The common plugins: KUKA|prc (KUKA parametric robot control) is the long-standing tool from the Association for Robots in Architecture for driving KUKA arms from Grasshopper; Robots is a popular open-source plugin supporting KUKA, ABB, UR and Staubli; and COMPAS, with its COMPAS FAB package, is an open Python framework for robotic fabrication research spanning multiple brands and integrating planning and simulation. All share the same logic: geometry gives target planes, you assign move types (PTP or LIN) and speeds, the plugin runs the inverse kinematics, checks reach and singularities, simulates the motion on screen, and finally posts the program to the robot's native format (KUKA KRL, ABB RAPID, UR script). You design the path; the toolchain handles the translation to each controller - a direct descendant of the CAM idea from Module 1, now in six axes.

Simulation is where a robot program is proven safe and correct before a single real motion. In the software you have a digital twin of the cell - the same arm, the same end-effector and its TCP, the fixtures, the workpiece, the fence - and you run the whole program virtually. The simulator checks the things that hurt: reach (is every target inside the envelope, with no joint past its limit?), collisions (does the tool, wrist or arm hit the fixture, the workpiece, the fence, or itself?), singularities (does any path pass through a pose that would whip a joint?), and cycle behaviour (does the sequence make sense, do tools change cleanly?). A fault found here costs nothing to fix; the same fault found on the floor can wreck a tool, ruin a workpiece, or injure a person.

This is the honest heart of robot safety in design practice: you assume nothing runs on the real robot until it has run clean in simulation. A worked mindset - a robot happily executing a program that drives its spindle into a steel clamp will not stop, back off or complain; it will push at full torque until something breaks. The simulator is the only place that mistake is free. Treat a passing simulation as necessary but not sufficient: models can be slightly wrong (a fixture a few millimetres off, a mis-measured TCP), so the real first run is still done deliberately - reduced speed, a finger on the e-stop, a dry run without material, stepping through, watching. Simulation removes the gross errors; careful commissioning catches the rest.

The complete workflow ties the module together. One: generate the geometry and, from it, the target planes for the TCP (in Grasshopper, driven by the design). Two: assign move types and speeds - PTP for rapid air moves, LIN for the process pass - and the tool, with its calibrated TCP. Three: simulate against the digital twin and iterate until it is clean - no reach errors, no collisions, no singularities. Four: post the program to the controller's native language. Five: commission on the real robot cautiously - verify the TCP and the workpiece position match the model, run at reduced speed first, dry-run without material, keep clear of the reach envelope, hand on the e-stop - then step up to production speed only once it behaves exactly as simulated.

Every step carries the module's lessons: the arm's payload and reach (6.1) bound what is possible, kinematics and the TCP (6.2) make the motion correct, the end-effector (6.3) does the work and defines the danger, and programming-with-simulation (6.4) makes it safe and repeatable. None of this replaces trained, supervised operation inside a guarded cell - it is the design-side discipline that makes that operation trustworthy. Master this loop and you can take a parametric idea all the way to a robotically-fabricated object, responsibly.

It is worth demystifying what 'posting' actually produces, because it connects straight back to Module 1. When the Grasshopper plugin finishes, it writes a program in the robot's native language - KRL for KUKA, RAPID for ABB, URScript for Universal Robots. Open one and it is surprisingly readable: a list of moves (a PTP or LIN command to a target), speeds, tool and frame declarations, and digital-output commands that switch the end-effector on and off (start the spindle, open the gripper, begin extruding). This is the six-axis cousin of the G-code a CNC reads: CAM-style software turning your geometry into low-level machine instructions. You rarely write it by hand, but knowing it exists - and that a line in it is one commanded motion - demystifies the machine.

Safety is not only guarding and simulation; it is also built into how the robot runs. Modern controllers offer safety-rated monitored speed and stop functions and configurable safety zones - the robot is electronically limited so that near a person, or inside a defined region, it cannot exceed a safe speed, and it triggers a protective stop if it does. Reduced-speed teach mode (the arm is capped at a slow speed whenever someone is programming it with the deadman held) is a legal and practical cornerstone. None of this makes an industrial arm casual to be around - the layered defence is deliberate: safe-rated software AND physical guarding AND simulation AND a cautious operator, because any one of them can fail. The designer's job in all this is upstream: hand over a program that has been simulated clean, so the people commissioning it on the real cell are checking your work, not discovering your mistakes at full speed.