Robots, animatronics and connected things
A robot is a control loop with a safety case bolted to the outside. An animatronic is a puppet whose strings are servos. A smart device is a radio with an opinion about whose cloud it belongs to. Underneath all three is one question: does the machine know what actually happened, or only what it asked for?
The heart of it
Closed loop, and what open loop costs you
Every machine that moves is doing one of two things. In an open loop it sends a command and assumes it worked — energise the solenoid, so the flap is open. In a closed loop it sends the command and then measures the result, compares it with what it asked for, and corrects the difference, continuously.
The measurement is the whole difference, and it is not about precision. It is about knowing. An open-loop machine whose belt has slipped, whose load has jammed, or whose air has run out reports success in exactly the same voice as one that worked. A closed-loop machine sees an error it cannot reduce and can raise a fault.
That is why anything with real energy in it on a show — a winch, a lift, a revolve, an arm — is closed loop with position feedback, driven over EtherCAT from something like a CX5140 running TwinCAT, and why the encoder question on the transducers page is a safety question rather than a resolution one.
What the measurement is actually buying
Introduce a disturbance — a load, a jam, a belt slipping — and watch what each kind of machine knows about it.
Where it is
Forward kinematics is arithmetic, inverse kinematics is a search
Give a robot arm its joint angles and asking where the tip ends up is straightforward geometry, worked out link by link. That is forward kinematics and it always has exactly one answer.
Now reverse it. You know where you want the tip to be; what angles get it there? That is inverse kinematics, and it is a different kind of problem entirely. There may be no solution — the point is out of reach. There may be several — elbow up or elbow down. There may be infinitely many, if the arm has more joints than the task needs. And some of the valid answers will drive the arm through a piece of scenery on the way.
That asymmetry is why show automation is usually programmed by teaching positions rather than by specifying coordinates: you drive the machine where you want it, record the joint values, and play them back. It sidesteps inverse kinematics entirely and it makes the recorded path something a human watched happen.
It is also why a machine that can reach a point still needs its whole path checked — the same distinction as a drone show being proven collision-free offline rather than trusting live avoidance.
The muscles
What actually does the moving
Animatronics
A puppet whose strings are servos
A character with fifteen moving parts is fifteen actuators, each taking a position, all updating together many times a second. The engineering is not the individual joints — it is the choreography and the fallback.
Movement is authored on a timeline, in exactly the way animation is authored, and played back against the show clock so that a blink lands on a word. Some rigs are driven live by a performer wearing a controller; most are a mixture, with a recorded base and a live layer.
What makes it a show discipline rather than a robotics one is everything around the movement. End stops, physical as well as in software, so a servo cannot drive a jaw through a skull. Torque limits so a hand that meets an obstruction stops rather than pushing. A defined rest position that the whole rig can be driven to safely on power-up or fault, because an animatronic that fails mid-gesture and stays there is a problem in front of an audience. And duty cycle, because a servo holding a heavy limb against gravity for a two-hour show is being asked to do something quite different from moving it.
Connected things
What actually happens when a device joins a network
A "smart" device is a small computer with a radio and a service behind it, and the interesting decisions are all in the layers people never see.
- Mesh is resilient, not quick. Every hop adds latency and jitter. Excellent for a sensor reporting every minute, wrong for anything a cue waits on.
- Local control is a specification, not a preference. Write it into the brief for anything installed, or you will discover the dependency on the day the line drops.
- Matter reduces integration work; it does not remove vendor lock-in. The extras that made you choose the product are usually outside the standard.
- Consumer devices are not show devices. No locking connectors, no redundancy, cheerful automatic firmware updates the night before a show. Fine in a rehearsal room, not in a rig.
- Every radio in the building is in somebody's spectrum. A mesh of forty 2.4 GHz devices is a real neighbour to your wireless systems.
Where the line is
Control is not permission
This is the same rule as the pyro arming chain and the safety channel on a PLC, and it belongs here too because a robot is the most tempting place to break it.
A show network can tell a machine what to do. It cannot be what makes the machine safe. Emergency stops, limits, guarding, light curtains and interlocks are a separate rated channel that stays valid when the control system is confused, disconnected, or running the wrong version of a file.
The reason is simple enough to state in one line: the control system is where the bugs are, and it is also where the laptop is.
The hardware index covers motion control and show controllers with what each one speaks, and the standards index has the machinery-safety documents. If you work in this area and a description here does not match practice, open an issue.
- How does a robot know where it is?
- How is an animatronic driven?
- What is Matter and Thread?
Where to go next
These pages are a chain rather than a library — the next one along usually answers the question this one raised.
Everything on this page, in the index
Each of these has its own entry with sources, ports, gotchas and an open gap where a field is missing.