I have been thinking about how loosely the word robotics is sometimes used.
Build a circuit, connect a sensor to an Arduino, control a motor, and the project is immediately described as robotics.
There is nothing wrong with building those systems. In fact, they are important building blocks for many robots. The problem is that we often confuse the components and technologies used to build a robot with the discipline of robotics itself.
Hardware engineering, embedded systems, and robotics overlap considerably, but they are not the same field.
Understanding that distinction matters.
Hardware is not robotics
Hardware engineering deals primarily with the physical implementation of a system.
It concerns electronic circuits, processors, sensors, actuators, power systems, signal conditioning, communication interfaces, PCB design, and the electrical constraints that determine whether a system can actually be built and operate reliably.
A hardware engineer could design the electronics for a robot, but could just as easily design the electronics for a medical device, an automobile, an industrial controller, a satellite, or a power system.
The hardware does not become “robotics” simply because a motor or sensor is involved.
Hardware provides the physical platform on which a robotic system can exist.
Embedded systems are not robotics
Embedded systems sit much closer to robotics, but the distinction remains.
An embedded system is a computing system designed to perform a particular function within a larger physical system. It typically involves a processor or microcontroller, firmware, sensors, actuators, communication interfaces, and real-time constraints.
Programming an STM32 to read an encoder and control a motor is embedded engineering.
Designing firmware that communicates with several sensors over CAN is embedded engineering.
Writing firmware that receives a command and produces a precise actuator response is embedded engineering.
All of these things can exist inside a robot.
But they can also exist inside an automobile, drone, washing machine, medical instrument, industrial machine, camera, or aircraft.
So an embedded system is not automatically a robotic system.
So what makes something robotics?
This is where the distinction becomes interesting.
Robotics is concerned with the design and behaviour of machines that sense, reason about, and act upon the physical world.
The important part is not simply that a machine contains a processor, sensor, or motor.
It is the way those elements are brought together to produce purposeful physical behaviour.
Robotics deals with questions such as:
How does a robot determine where it is?
How does it estimate the state of its body and environment?
How does it represent its position and orientation in space?
How does it determine where its end-effector should be?
How should its joints move to reach a desired position?
How should it generate a feasible trajectory?
How does it maintain stability while moving?
How does it react when the environment changes?
How does it perceive objects and determine how to interact with them?
How can it plan a safe path from one location to another?
These questions take us into the core of robotics.
Kinematics.
Dynamics.
Motion planning.
Trajectory generation.
Control.
State estimation.
Localization.
Mapping.
Computer vision.
Manipulation.
Navigation.
Human-robot interaction.
These are not simply questions about making electronics work. They are questions about machines operating and making decisions in the physical world.
Consider a robotic arm
Suppose we have a six-degree-of-freedom robotic arm.
The hardware engineer may design the PCB, select the motor drivers, develop the power architecture, and integrate the encoders.
The embedded engineer may write the firmware responsible for reading those encoders, communicating with the controllers, and commanding the motors.
But then we encounter a different problem.
We want the end-effector to move to a specific position and orientation.
Which joint angles will achieve that pose?
That is an inverse kinematics problem.
Once we know the desired configuration, how should the robot move through those configurations?
That becomes a trajectory planning problem.
How do we ensure the robot follows that trajectory accurately despite disturbances, load changes, friction, and modelling errors?
Now we are dealing with control.
What happens if an obstacle appears in the robot’s path?
Now motion planning becomes relevant.
How does the robot determine its position relative to the environment?
Now we enter state estimation, localization, perception, and potentially mapping.
This is where robotics begins to distinguish itself from simply controlling electronic hardware.
The same principle applies to humanoid robots
A humanoid robot is not defined by having two arms, two legs, cameras, servos, and a microcontroller.
The difficult engineering problems begin when we ask the robot to actually function as a physical agent.
How does it maintain balance?
How does it estimate the state of its body?
How does it coordinate multiple joints?
How does it generate a walking gait?
How does it respond when its foot encounters an unexpected surface?
How does it perceive an object?
How does it determine whether and how that object can be grasped?
How does it plan and execute a movement while respecting the physical limitations of its body?
These are fundamentally robotic problems.
The motors, sensors, processors, PCBs, and firmware are necessary.
But they are not the entirety of the problem.
Robotics is multidisciplinary by nature
This is also why robotics is difficult to place inside a single traditional engineering discipline.
A serious robotic system can require knowledge from:
Mechanical Engineering for mechanisms, structures, actuators, and physical design.
Electrical and Electronics Engineering for sensing, power, electronics, and hardware.
Embedded Systems for low-level computation, communication, and real-time control.
Control Engineering for regulating the behaviour of dynamic systems.
Computer Science for algorithms, software, planning, perception, and artificial intelligence.
Mathematics for modelling, geometry, optimization, probability, and system analysis.
Robotics sits at the intersection of these areas because the problem itself is interdisciplinary.
The objective is not merely to build the individual components.
It is to make the complete machine function coherently in the physical world.
This does not make hardware or embedded systems less important
Quite the opposite.
A robotics engineer who does not understand the underlying hardware will eventually encounter limitations that cannot be solved purely in software.
An embedded engineer working on robotics needs to understand the physical system being controlled.
A hardware engineer designing electronics for a robot needs to understand the requirements imposed by sensing, actuation, control, and computation.
The fields complement one another.
The mistake is simply treating them as interchangeable terms.
So where is the boundary?
There is no perfectly rigid boundary between these disciplines.
A robotics engineer can be an excellent embedded engineer.
An embedded engineer can specialize in robotic systems.
A hardware engineer can design sophisticated robotic platforms.
There is significant overlap.
But overlap does not mean equivalence.
A useful way to think about it is:
Hardware engineering asks:
How do we build the physical electronic system?
Embedded systems asks:
How do we make that hardware compute, communicate, sense, and respond?
Robotics asks:
How do we make a physical machine perceive its environment, understand its state, plan, control its motion, and perform purposeful actions in the real world?
That last question is what makes robotics distinct.
So I think we should be careful about reducing robotics to:
“Arduino + sensor + motor.”
Those may be the first components through which many people encounter robotics, but they are only the beginning.
Robotics is ultimately about machines interacting with the physical world through sensing, computation, control, and action.
And the deeper you go into the field, the more you realise that making a motor turn is the easy part.
Making an entire machine move intelligently, reliably, safely, and purposefully is the real challenge.
That is robotics.
