How robots sense and act
Follow a parcel robot through sensing, control, powered movement and measured feedback; explore why a stop request is different from stopping.
Reviewed 2026-10-23
How does a goal become movement?
Our fictional parcel robot must reach a corridor destination. Measurements, commands and powered wheels connect its delivery goal to real movement.
Fictional wheeled delivery robot; a spatial illustration, not a measured map or route-planning system.
Notes and sources for this step
What this guide explains
Our question is: how does a robot turn a goal into useful movement? We follow a fictional wheeled robot carrying a parcel down a corridor. We focus on sensing, control, powered action, and feedback. Mapping, route planning, mechanical design, and detailed controller mathematics are outside this short guide.
What we mean by robotics
Robotics concerns machines that perform physical tasks and the systems used to build and control them. Robots can be arms, rovers, or other forms; they need not resemble people. Some operate autonomously, while others depend on human control. Source: NASA — What Is Robotics? (Grades 5–8), https://www.nasa.gov/learning-resources/for-kids-and-students/what-is-robotics-grades-5-8/ . This older educational article supports these stable distinctions, not current mission status.
Sense, choose, act, and measure again.
A controller chooses commands. Sensors return measured results to that controller, closing the feedback loop and informing its next decision.
Solid arrows carry the command/action path; dashed arrows return information. Operations can run at different rates in real systems.
Notes and sources for this step
The controller and the feedback
A controller is the part of the system that decides how to command movement. Feedback means returning measured results to that controller. A robot can have several loops: one may adjust wheel speed while another responds to obstacles. This four-step view simplifies operations that can run at different rates.
Why the return path matters
A command is an intention, not proof of an outcome. Feedback lets a controller react to a difference between intended and measured behavior, within the limits of its sensors and design. Source: Modern Robotics — 11.1: Control System Overview, Lynch and Park, Northwestern University, https://modernrobotics.northwestern.edu/nu-gm-book-resource/11-1-control-system-overview/ .
A reading is a clue about the world.
A range sensor measures distances to surfaces. A programmed region turns some nearby readings into an obstacle estimate, without identifying the object.
Illustrative range rays and configured stop region. Real sensors have incomplete coverage, noise and missed detections.
Notes and sources for this step
Our delivery robot's assumption
In this example, a working range sensor detects the box in the corridor. The software treats readings inside a configured region as an obstacle. It does not need to identify the object as a box to decide to stop.
Real readings have limits
Coverage, measurement error, and missed detections limit what the controller can know. A useful estimate is not a complete or perfect view of the world. Nav2 provides a real software example that accepts laser, point-cloud, or range data and tests configured regions for obstacles. Source: Nav2 Jazzy documentation — Collision Monitor Node, https://docs.nav2.org/jazzy/configuration_and_development/configuration_guide/core_servers/collision_monitor/configuring_collision_monitor_node/ .
Compare the goal with the measurement.
Compare target and measured forward speeds on one scale. Their difference is a speed error, not a motor voltage.
Illustrative forward speeds in metres per second. Target and measurement refer to the same direction. Initial example: 0.50 − 0.30 = 0.20 m/s.
Notes and sources for this step
Read the units
Metres per second (m/s) measure speed. These invented values illustrate arithmetic, not measured robot performance. We assume target and measurement describe forward speed in the same direction and at the same moment. Target minus measured speed gives a positive speed error of 0.2 m/s.
An error helps choose a command
A speed controller can use this difference to adjust motor effort. The difference is not itself a motor voltage; using it to set voltage requires a control rule with the appropriate units. The actual control rule also depends on the robot, its limits, and the task; stopping for an obstacle can override the speed target. Source: Modern Robotics — 11.1: Control System Overview, https://modernrobotics.northwestern.edu/nu-gm-book-resource/11-1-control-system-overview/ .
A command still needs physical power.
The controller sends information. A battery supplies energy; a driver regulates power to the motor, an actuator that turns the wheels.
A simplified electric drive. Signal and energy are different inputs; gearbox details, losses and electrical return paths are omitted.
Notes and sources for this step
Commands and energy do different jobs
The controller sends information. The power supply provides energy, and a motor driver regulates electrical power to the motor in response to commands. The motor is an actuator: a component that produces physical action. Not every robot uses electric motors; this is the drive system assumed in our example.
Movement depends on the physical system
Load, contact with the floor, and available motor effort affect the result. A turning wheel can slip instead of moving the body as expected. This is another reason to measure outcomes rather than assuming commands succeeded. Source: Modern Robotics — 11.1: Control System Overview, https://modernrobotics.northwestern.edu/nu-gm-book-resource/11-1-control-system-overview/ .
The goal stays. The next action changes.
Step through an illustrative obstacle encounter. A stop request can be zero while the robot’s measured body speed is still above zero.
Illustrative snapshots, not a dynamics simulation. We assume early detection, suitable working sensors and enough grip/drive ability; no safe distance is established.
Notes and sources for this step
A deliberately simple example
This fictional robot has a known destination, working sensors, and a configured obstacle rule. We assume the box is detected early enough and the drive can stop on this floor. The four steps describe a control sequence, not a tested safety system or a universal stopping distance. A stopped robot may need a new route or human help before delivery can continue.
A real software counterpart
Nav2's collision monitor can request stopping or slowing when sensor points enter configured zones. Its documentation explicitly says it does not provide hard real-time safety certification. Source: Nav2 Jazzy documentation — Collision Monitor Node, https://docs.nav2.org/jazzy/configuration_and_development/configuration_guide/core_servers/collision_monitor/configuring_collision_monitor_node/ .
A robot does not have to use AI.
Hand-written rules and learned perception models can feed the same controller. Responding to a measurement does not itself require machine learning.
The two information routes can coexist. AI is broader than learned models; this view only contrasts one learned perception component with a direct stop rule.
Notes and sources for this step
Feedback does not require learning
Our obstacle rule can be programmed directly. Responding to a changing measurement does not, by itself, mean a machine is learning or using AI. A robot can also combine learned perception with programmed control rules.
Robotics and AI overlap
Robotics deals with physical action; AI can help with perception or decision-making. Neither a human-like body nor a learned model is required for the feedback loop explained here. Source: International Federation of Robotics — AI in robotics: separating fact from fiction, https://ifr.org/post/ai-in-robotics-blog . We use its distinction between programmed robot behavior and AI, not its dated economic or regulatory discussion.
Feedback helps within physical limits.
Explore a toy stopping-distance model: response delay adds travel before slowing begins. Real stopping also depends on sensing, grip, load and drive limits.
Toy constant-deceleration arithmetic only. It is not a tested robot, a safety guarantee, or a usable safe stopping-distance specification.
Notes and sources for this step
Why detecting a box is not enough
If detection arrives too late, the robot may not stop before contact. Stopping depends on factors such as initial speed, response delay, braking ability, load, and floor grip. We specify no safe distance because it must be established for the actual system and conditions.
Feedback is not a guarantee
A controller cannot correct an unseen error through that missing measurement alone, and an actuator cannot deliver unlimited force. Poorly designed feedback can also behave badly. Source: Modern Robotics — 11.1: Control System Overview, https://modernrobotics.northwestern.edu/nu-gm-book-resource/11-1-control-system-overview/ . For the limits of the obstacle software example, see Nav2 — Collision Monitor Node, https://docs.nav2.org/jazzy/configuration_and_development/configuration_guide/core_servers/collision_monitor/configuring_collision_monitor_node/ .
Which measurement checks body motion?
A wheel can rotate while the body slips. Decide which information best checks the robot’s physical movement after a stop request.
After a stop request on a slippery floor, the wheel sensor reports no rotation. Which extra observation most directly checks whether the robot body is still sliding?
- A new suitable measurement of body motion relative to the corridor.
- Another copy of the same zero-wheel-speed reading.
- Confirmation that the controller requested zero speed.
Read the answer
That observes the body relative to the world. With a working, suitable sensor, it can reveal sliding that a wheel sensor alone misses.
Notes and sources for this step
What the answer assumes
Assume the extra sensor works and can estimate body motion relative to the corridor at this moment. No sensor gives unlimited certainty. The question compares what each observation measures, not a certified stopping procedure.
The distinction to keep
A command describes an intention, wheel rotation describes a component, and body-relative motion describes the outcome of interest. Choose feedback suited to the physical quantity you need to check.
Look for the loop in any robot.
Apply the loop to a robot arm: identify the target, powered joints and returned measurements. A goal and a measured outcome remain different.
Simplified arm example. Target marker, powered joints and measured feedback describe roles; this is not an inverse-kinematics or reachability calculation.
Notes and sources for this step
Use the model beyond the corridor
For a robot arm, ask what measures joint motion, what computes motor commands, and what checks whether the arm reached the intended position. For a human-controlled robot, ask which choices the person makes and which control loops the machine handles. The split varies by system.
A useful next question
When a robot makes a mistake, trace the chain: was the goal appropriate, was the measurement usable, was the command suitable, and could the mechanism carry it out? This is a way to organize questions, not a promise that every fault has only one cause.