4  Choosing the Right Actuator

4.1 Start With the Story

Suppose the device must unlock a latch, open a vent, spin a fan, and warn a nearby person. Those are all actuator jobs, but they are not the same job. The story starts by naming the physical output before comparing parts.

Once the output is clear, the selection record becomes easier: continuous motion, positioned motion, binary switching, human feedback, or process change. Each family brings a different driver boundary, failure mode, and proof requirement.

4.2 Overview: Classify Actuators By The Job They Must Do

Actuator selection starts with the physical job, not with a favorite part. An IoT design may need continuous rotation, a fixed angle, step-by-step positioning, linear push or pull, high-power switching, light, sound, heat, or process movement. Each output type carries different power, driver, protection, and verification needs.

The first classification question is simple: what physical change must the system produce, and how will the system know that the change happened safely?

Figure 4.1: Classifying the output type narrows the actuator choice before comparing drivers, protection, evidence, and safe-state behavior.

For example, a greenhouse vent that must rotate about 60 degrees and hold against wind load is a positioned-motion problem, not a generic “small motor” problem. If the linkage needs 1.2 N of push at a 35 mm arm, the load torque is 1.2 x 0.035 = 0.042 N m. With a 2.5x margin, the actuator target is about 0.105 N m, plus enough travel range and a way to confirm the vent is actually open or closed. That points toward a servo, geared motor with limit switches, or stepper with homing, depending on duty and accuracy.

A pump or fan starts from a different classification. The output is continuous rotation and flow, so the key evidence is not final angle; it is speed, current, pressure, flow, or temperature change. A 12 V fan that runs at 0.7 A but starts at 2.1 A needs a driver and supply sized for startup, not just for normal running. A relay may switch the load, but it does not make a fan positional.

A lock, latch, alarm buzzer, or warning lamp is different again. A solenoid lock might need a short release pulse and a safe default state; a buzzer needs audibility and user recognition; a lamp needs visibility and current limiting. Classification turns the design from “choose a part” into “choose the output family, driver boundary, evidence path, and safe state that match the physical job.”

If you only need the intuition, this layer is enough: choose by output role, motion shape, positioning need, load behavior, driver boundary, and evidence required after the command.

4.2.1 Beginner Actuator Families

• Continuous motion: DC motors and fans are useful when the task is ongoing rotation, airflow, pumping, or wheel movement rather than a precise final position.
• Positioned motion: Servo motors, stepper motors, and geared mechanisms fit tasks where angle, step count, or repeatable position matters.
• Binary action: Relays, solenoids, valves, and locks fit on/off, open/closed, latch/release, and switch-isolated power tasks.
• Fluid-power motion: Hydraulic cylinders or fluid motors use pressurized liquid for high force, while pneumatic cylinders, pumps, and rack-and-pinion actuators use compressed air for fast linear or rotary motion. Their evidence includes pressure source, valve behavior, leaks, reserve capacity, and safe venting or default state.
• Material-response motion: Thermal, magnetic, shape-memory alloy, shape-memory polymer, and soft actuators can bend, contract, or deform when heated, magnetized, illuminated, or exposed to chemical or moisture changes. Their evidence includes stimulus range, response time, fatigue, recovery behavior, and whether the motion stays gentle enough for fragile objects.
• Mechanical conversion: Crankshafts, gears, rails, pulleys, chains, and rack-and-pinion mechanisms convert one motion into another, such as rotary motion into linear motion. Their evidence includes backlash, friction, travel limits, load margin, and jamming behavior.
• Human-visible output: LEDs, displays, buzzers, speakers, and haptic outputs communicate state to a person or nearby system.

4.2.2 Beginner Example

A smart vent, a warning buzzer, and a pump are all actuators, but they should not be selected from the same checklist. The vent needs movement and end-state evidence, the buzzer needs a clear human signal, and the pump needs power switching, protection, and flow or process evidence.

4.2.3 Overview Knowledge Check

4.3 Practitioner: Compare Types With A Selection Record

A useful actuator comparison record is a small design argument. It states the required output, lists realistic candidate types, rejects poor fits with reasons, and records the driver, protection, feedback, and failure behavior that must be tested.

4.3.1 How It Works: Actuator Selection Record

1. Define the output. Name the required motion, switching, light, sound, heat, or process action, including whether the final state must be known.
2. List candidate families. Compare only plausible actuator families for that output shape, such as DC motor, servo, stepper, relay, solenoid, or LED driver.
3. Check the load boundary. Record voltage, current, startup behavior, inductive behavior, isolation, and whether the controller needs a transistor, MOSFET, H-bridge, motor driver, relay module, or other interface.
4. Choose feedback evidence. Decide whether command success can be inferred, sensed directly, confirmed by limit switches, measured through current, or verified by process data.
5. Review failure behavior. Describe what should happen on power loss, stuck load, missed position, stale feedback, communication failure, or manual override.

4.3.2 Intermediate Example

A remote irrigation valve could use a solenoid valve, motorized ball valve, or relay-controlled pump. The right answer depends on whether the system needs normally-closed behavior, low standby power, partial positioning, serviceability, and direct evidence of flow. A selection record makes those tradeoffs explicit before hardware is ordered.

For mobile robots, the comparison also has to name the controllable degrees of freedom. A differential-drive robot may have planar state (x, y, heading) but only two direct wheel-speed commands, so it is non-holonomic: it cannot move sideways without changing heading over time. A holonomic platform has enough independently controlled motion axes to command every relevant degree of freedom directly. A quadrotor is another useful boundary case because its six-degree pose is controlled through fewer thrust and moment inputs, so the forward-kinematics record has to say how actuator commands change position and orientation over time.

The inverse question matters too. Forward kinematics predicts the body or world-frame motion that follows from wheel speeds, steering angle, rotor thrust, or joint commands. Inverse kinematics starts from the desired pose, velocity, or path and asks which actuator commands could produce it. Non-holonomic robots often cannot point directly at a goal and translate sideways; they need a feasible path, such as an arc or curve, plus feedback that checks whether the pose is still converging. An open-loop path replay may be acceptable for a bench demo, but a field robot needs closed-loop pose evidence because floor friction, wheel slip, obstacles, and sensor drift can invalidate the planned command.

That classification changes the evidence. A wheel motor command is not proof of a pose update; wheel slip, backlash, floor friction, battery voltage, and sensor delay can all disturb the motion model. A reviewable robot actuator record should name the body frame, controlled axes, actuator count, kinematic model, feedback sources, and the fallback when odometry or pose evidence stops matching the command.

4.3.3 Comparison Ledger

Candidate	Good Fit	Evidence Needed	Common Risk
DC motor	Continuous rotation, fans, pumps, wheels, and speed-controlled loads.	Driver rating, startup current, speed/load behavior, and protection for the power stage.	Assuming speed control also gives position knowledge.
Servo motor	Angle-oriented positioning where a compact integrated mechanism is enough.	Range, torque margin, supply behavior, command limits, and mechanical end-stop review.	Expecting every servo to tolerate the same load, duty cycle, or environment.
Stepper motor	Repeatable step movement where the load is predictable and missed steps are managed.	Driver current setting, acceleration profile, holding behavior, and homing or reference evidence.	Treating open-loop step count as proof that the mechanism actually reached position.
Relay or solenoid	Binary switching, latching, locking, releasing, and valve-like actions.	Coil/load separation, flyback or snubber protection, contact rating, and safe default state.	Ignoring inrush, inductive kick, contact wear, or power-loss behavior.
Hydraulic or pneumatic actuator	High-force or fast linear and rotary motion from pressurized liquid or air.	Pressure source, valve command path, leak behavior, stored-energy release, and end-position evidence.	Treating pressure availability as proof that the mechanism moved safely.
Shape-memory, thermal, magnetic, or soft actuator	Compact, lightweight, compliant, or delicate motion where stimulus-driven deformation is useful.	Stimulus level, response and recovery time, fatigue life, material limits, and temperature or field safety.	Ignoring slow response, hysteresis, material aging, or unintended heating.

4.3.4 Practitioner Knowledge Check

4.4 Under The Hood: Classification Also Defines Failure Boundaries

Actuator categories matter because they fail differently. A motor may stall, overshoot, or draw more current under load. A relay may wear contacts or weld shut. A solenoid may heat if energized too long. An LED or buzzer may be safe electrically but still fail the human-factor job if it is ambiguous or missed.

4.4.1 Why The Same Command Can Mean Different Things

A software command such as “open” or “turn on” is not enough evidence. The physical boundary determines what must be checked: driver state, load current, mechanical movement, final position, thermal behavior, isolation, manual override, and whether the default state is safe when power or communication fails.

Consider a door controller that can choose a relay-driven strike, a solenoid bolt, or a motorized latch. A relay may only prove that the controller energized a coil; it does not prove the contact did not weld, the strike received power, the door moved, or the door is now secure. If the strike draws 1.5 A at 12 V, the relay contact, wiring, fuse, and supply must be rated for that DC load and inrush. If the controller also drives an 80 mA relay coil, the coil still needs a transistor driver and flyback path because the microcontroller pin is not the load supply.

Thermal behavior changes the classification too. A solenoid drawing 0.5 A at 12 V dissipates 12 x 0.5 = 6 W while energized. If it pulses for 10 s every 60 s, the simple duty fraction is 10 / 60 = 0.167, so the average coil heat from the pulse pattern is roughly 1 W before enclosure effects. If the same solenoid is held continuously, the heat case is six times larger and may require a latching mechanism, reduced hold current, or a different actuator family.

That is why classification includes failure boundaries. The final answer must say what fails safe, what fails secure, what is sensed directly, and what is only inferred from a command.

4.4.2 Advanced Example

A building access controller might compare a relay-driven strike, a solenoid lock, and a motorized latch. The selection is not only about opening a door. The design must consider default state during power loss, local fire-safety requirements, manual release, driver isolation, status sensing, command audit, and whether the control system can tell the difference between “command sent” and “door actually secured.”

4.4.3 Failure-Boundary Checks

• Electrical boundary: Confirm the control signal, driver device, load supply, common reference or isolation, and protection path are appropriate for the actuator family.
• Mechanical boundary: Review travel, stops, load changes, friction, backlash, mounting, and whether movement can jam or injure people or equipment.
• Evidence boundary: Separate command acknowledgement from physical confirmation, and record what feedback proves the useful action happened.
• Safe-state boundary: Define the default state during reset, power loss, stale command, stuck output, and manual intervention.

4.4.4 Try It: Classify Before Choosing

Pick one actuator job, such as opening a vent, moving a camera, switching a pump, or warning a user. Write the output family, motion shape, driver boundary, feedback evidence, and safe default state. If one row is unclear, the actuator choice is not ready.

4.4.5 Under-The-Hood Knowledge Check

4.5 Summary

Actuator comparison is a design decision about physical output, not a shopping list. Classify the required action by output family, motion shape, positioning need, load behavior, driver boundary, feedback evidence, and safe-state behavior.

The same command can have very different risks depending on the actuator type. A reviewable IoT design shows how the low-power controller commands the load, how the load is protected, how the useful physical action is confirmed, and what the system does when the actuator or feedback path fails.

4.6 Key Takeaway

Choose actuator types by physical job and evidence: output role first, driver and protection second, verification and safe default state before release.

4.7 See Also

• Actuators: Use this for the broader actuator role in an IoT system and the logic-to-load boundary.
• DC Motors: Use this when the output is continuous rotation, wheels, fans, pumps, or speed-controlled motion.
• Servo Motors: Use this when angular position, command limits, and holding behavior matter.
• Relays and Solenoids: Use this for binary switching, locks, valves, isolation, and inductive-load protection.