3 How Actuators Work

actuators

3.1 Start With the Story

Start with a room that is too hot. A sensor reports the temperature, and software decides to cool the room. An actuator is a device that makes a physical change. A fan, moving vent, relay, or valve can be the actuator in this example.

Keep four roles separate. Software asks for an action. A driver circuit switches the needed power. The actuator moves or signals. A later measurement provides feedback and shows whether the room changed. This split prevents unsafe wiring mistakes.

3.2 In 60 Seconds

Actuators are the output devices of IoT systems. Sensors measure the world. Software decides what should happen. Actuators then create motion, switching, light, sound, airflow, heat, or fluid movement.

The central rule is simple. A microcontroller is a small computer built to control hardware. Its general-purpose input/output pins, known as GPIO pins, send or read simple electrical signals. A GPIO pin can command an actuator, but it usually cannot power that actuator. Use a driver circuit, a suitable power supply, and protection for coils and motors before trusting the action.

3.3 Overview: Actuators Close The Sense-Decide-Act Loop

An IoT system becomes useful when it connects sensing to action. A temperature sensor can report a hot room. Only the fan motor, relay, vent, or valve changes the room. These physical outputs form the actuator layer.

Actuators include motors, servos, stepper motors, relays, solenoids, valves, pumps, heaters, LEDs, displays, buzzers, and speakers. A solenoid uses a coil to create movement. These devices differ in motion, power, precision, response time, and risk. Always ask two questions: what action is required, and what evidence shows that it happened safely?

Motor Max

“Sensing decides; actuating commits — and a commit to the physical world needs a safe stop.”

Through this chapter, Max runs one Motion Check on the load: the action committed, the limits that bound it, and the stop that ends it.

Make the loop concrete. In a greenhouse, the sensor may report 35 C, the controller may target 28 C, and the actuator path may run a 12 V, 0.5 A fan. The running electrical load is 12 x 0.5 = 6 W, but the startup current may be several times higher, so the fan cannot be treated as a GPIO accessory. The actuator design must include the driver, supply margin, wiring, protection, and a way to see that temperature or airflow actually changed.

Figure 3.1: A useful actuator path closes the loop: sense the condition, decide on the command, drive the physical output, and use feedback when the result matters.

Read Figure 3.1 from sensing through decision and drive, then follow the feedback arrow back to the measured condition. The loop matters because a command is only intent; the next observation supplies evidence that the physical output changed the process as expected.

An irrigation valve shows the same pattern with a different output. If a normally closed solenoid draws 0.4 A at 12 V, it dissipates 12 x 0.4 = 4.8 W while energized. A short watering pulse may be fine, but holding it open indefinitely changes the heat and battery budget. The control decision is only useful if the valve driver can energize the coil, the flyback path protects the electronics, and a flow, pressure, current, or timeout rule catches a stuck valve.

Max’s Motion Check

Commit: energize a normally closed solenoid valve — 0.4 A at 12 V, 4.8 W while held open.
Limits: a short watering pulse is fine; holding it open indefinitely changes the heat and battery budget.
Safe stop: the flyback path protects the electronics; a flow, pressure, current, or timeout rule catches a stuck valve.

The key beginner move is to name the boundary. Software owns the decision; the driver circuit owns power switching; the actuator owns the physical output; and feedback proves the result. Confusing those roles is how simple IoT projects end up with reset loops, overheated coils, jammed motors, or dashboards that claim success while nothing moved.

If you only need the intuition, remember this: sensors notice, controllers decide, actuators act, and feedback proves whether the action worked.

3.3.1 Output Families

Motion: DC motors, servo motors, stepper motors, pumps, valves, locks, dampers, and solenoids move or position something.
Switching: Relays, contactors, MOSFETs, and solid-state switches let low-power logic command higher-power loads.
Human Feedback: LEDs, displays, buzzers, speakers, and haptic outputs turn system state into visible, audible, or tactile signals.
Process Change: Heaters, fans, coolers, pumps, and valves change temperature, airflow, fluid flow, pressure, or another process state.

3.3.2 Beginner Examples

A greenhouse controller senses high temperature, decides to cool, and commands a fan motor.
A smart irrigation system senses dry soil, decides to water, and opens a normally closed solenoid valve.
A robot arm receives a target angle, decides a motion path, and commands a servo or stepper through a driver.
A safety monitor detects a fault and commands a buzzer, warning LED, relay cutoff, or all three.

3.4 Practitioner: Put A Driver Between Logic And Load

The first practical actuator design step is to separate the logic signal from the load current. GPIO pins are designed for small digital signals. Motors, relays, solenoids, heaters, lamps, and pumps often need more current, different voltage, inductive-load protection, or isolation.

A driver boundary lets the microcontroller command a power stage safely. The correct driver depends on the load: a MOSFET for a one-direction DC load, an H-bridge for a reversible motor, a relay or solid-state relay for switched loads, a servo signal with separate power, or a stepper driver with a current setting.

3.4.1 Wiring Review Workflow

Name the load. Record actuator type, voltage, running current, startup or inrush current, duty cycle, and environment.
Choose the driver. Match the load to a MOSFET, H-bridge, relay module, solenoid driver, servo supply, or stepper driver.
Protect the controller. Add flyback paths, current limits, fuses, isolation, heat paths, and shared-ground rules as appropriate.
Define safe defaults. Decide what happens on boot, reset, power loss, network loss, watchdog timeout, and emergency stop.
Prove the action. Decide whether command logging is enough or whether feedback from position, current, flow, pressure, speed, or process state is required.

3.4.2 Actuator Driver Boundary Review Ledger

Actuator Case	Why GPIO Alone Is Not Enough	Typical Interface	Evidence To Keep
DC motor or fan	Startup and stall current can exceed logic-pin limits, and the motor is an inductive moving load.	MOSFET for one direction, H-bridge for reverse, rated motor driver for higher current.	Supply voltage, startup current, driver rating, PWM rule, protection, and motion or process feedback.
Servo or stepper	Positioned motion needs a separate power path, current margin, and mechanical-limit review.	Servo control signal plus external power, or a current-limited stepper driver.	Target range, load, calibration, current setting, missed-step or overload behavior, and safe reset state.
Relay or solenoid	Coils require more current than GPIO and create voltage spikes when switched off.	Transistor or MOSFET driver with flyback diode, protected relay module, or solid-state switch.	Coil rating, contact or valve rating, flyback path, duty cycle, default state, and timeout behavior.
LED strip or buzzer	Large output arrays or audio devices may exceed pin current and need timing, current, or accessibility review.	Current-limited output, LED driver, MOSFET switch, buzzer driver, or amplifier.	Current limit, visibility or audibility, color or tone meaning, failure state, and user confirmation.

3.4.3 Starter Review Record

Physical action:
Actuator type:
Load voltage and current:
Driver or interface:
Protection:
Safe default:
Feedback evidence:
Retest trigger:

3.5 Under The Hood: Action Needs Feedback And Safe Failure

Under the hood, an actuator command crosses electrical, mechanical, and process boundaries. The software may set a PWM duty cycle, relay output, or step command, but the actual result depends on supply voltage, driver rating, wiring, load, friction, heating, timing, and physical limits.

That is why actuator systems often need feedback. Feedback can come from a sensor that measures the process, an encoder that measures motion, a limit switch that confirms position, current sensing that detects stall, flow sensing that confirms water movement, or a timeout that forces a safe state when proof does not arrive.

Each boundary has a failure mode that can be tested. On the electrical side, a motor that draws 2 A at startup through 0.3 ohm of wiring and connector resistance can lose about 2 x 0.3 = 0.6 V before the driver even sees the load. That voltage drop may be enough to reset a marginal controller supply. On the mechanical side, a motor may spin freely on the bench but stall once connected to a sticky linkage. On the process side, a pump may rotate while a blocked tube prevents flow.

Max’s Motion Check

Commit: spin the motor — 2 A startup current through 0.3 ohm of wiring and connector resistance.
Limits: 2 x 0.3 = 0.6 V lost before the driver even sees the load — enough to reset a marginal controller supply.
Safe stop: a motor can spin freely on the bench and still stall once connected to a sticky linkage — bench success is not proof.

Phoebe’s Field Notes: Why Wiring Resistance Is A Voltage Divider

The mathematical gist. The chapter’s 2 A startup current through 0.3 Ω of wiring loses 0.6 V. A 12-bit, 3.3 V ADC resolves about 0.806 mV per code, so amplitude is easy to see; timing is the risk, because a 1 ms startup pulse needs sampling above 1 kHz while a 100 Hz loop waits 10 ms between samples.

Safe failure means the system has a planned response for those cases. A fan might stop and log a fault after current stays above its startup band for too long. A solenoid might be limited to a 5 s energize window unless flow is detected. A servo-driven vent might require a limit switch, end-position current signature, or temperature trend before the dashboard claims the vent opened. The evidence should match the consequence: a status LED can be open loop, but water, heat, access control, and moving machinery need stronger proof.

Actuator acceptance should therefore test more than the happy path. Include boot defaults, brownout recovery, power loss, stuck load, repeated cycling, feedback loss, and manual override where they matter. The goal is not to make every actuator complicated; it is to make the proof and protection proportional to the physical risk.

3.5.1 Feedback And Safety Loops

Open Loop: The controller sends a command and assumes the action occurred. This can be acceptable for low-consequence indicators or simple outputs.
Closed Loop: The controller measures the result and adjusts or stops the actuator based on feedback from the mechanism or process.
Protection Loop: Flyback diodes, snubbers, fuses, current limits, thermal limits, watchdogs, and emergency stops protect during normal and fault conditions.
Fail-Safe State: The design should define what the actuator does when power, firmware, communication, feedback, or the physical load fails.

3.5.2 Failure Modes To Surface Early

Stall or jam: a motor is commanded on but cannot move, causing high current and heat.
Inductive kick: a relay, solenoid, or motor coil creates a damaging voltage spike when switched off.
Brownout: actuator startup current pulls the supply down and resets the controller.
Unsafe default: an output turns on during boot, reset, or network loss when it should remain off.
No action proof: software reports success because it sent a command, but the physical mechanism did not move.

3.5.3 Acceptance Evidence

Acceptance evidence should include normal command, startup, shutdown, reset, power-loss, blocked-load, repeated-use, and recovery cases where relevant. For low-risk indicators, visual or audible confirmation may be enough. For water, heat, motion, access control, or safety-related outputs, the evidence should include protective behavior and proof that the physical result matched the command.

The transition in Figure 3.2 shows why an actuator command must retain the uncertainty and scale limits of the sensor that produced it.

Figure 3.2: Miniaturised force-sensor scaling leads into a measured command, driver, actuator, and feedback chain.

In Figure 3.2, the Scaling trade-off card separates added mechanical displacement from added drift and a fixed electronics floor. The lower hand-off from SENSE through CONTROL and DRIVER to ACTUATOR reinforces the chapter rule: a GPIO-sized command requests action, while a protected power stage supplies energy and feedback confirms valve moves 12 mm.

3.6 See Also

Actuators Overview for the broader output-role and selection doctrine.
Actuator Types and Comparison for choosing between common actuator families.
DC Motors for continuous-motion motor driver and feedback details.
PWM Control for Actuators for duty cycle, frequency, servo pulses, and soft-start behavior.

3.7 Key Takeaway

Actuators turn IoT decisions into physical change, so every design needs the right driver boundary, protection, safe default, and feedback evidence for the consequence of the action.