Robotics Fundamentals
What Is Robotics?
Robotics is the field that designs, builds and programs robots. See how mechanical engineering, electronics and computing overlap. And what appears only where they meet.
beginner · 12 min read
Lesson content
A robot is a machine. Robotics is the field that designs, builds, programs and studies those machines.
That difference matters more than it sounds. Robotics is not one subject. It is several engineering disciplines that all have to agree with each other about the same lump of metal.
And they do not always want to.
Definition
Robotics
The branch of engineering concerned with the design, construction, operation and use of robots, together with the computer systems that control them.
Formal definition
An interdisciplinary field integrating mechanical design, electrical and electronic engineering, control theory and computer science to create machines that sense, reason about and act on the physical world.
Look at the middle of that diagram for a second, because it is the whole point of the field.
Mechanical engineering on its own gives you a linkage. Electronics on its own gives you a motor and a sensor. Computing on its own gives you a program.
None of those is a robot.
A robot only appears where all three meet at the same time, in the same object, agreeing about the same millisecond.
- Mechanical engineering
The body: links, joints, gears, bearings, structures and the study of how they move and carry load.
Decides reach, payload, stiffness and how much mass the motors have to fling around. Every later software problem is easier or harder because of a mechanical choice made first.
- Electrical and electronic engineering
The nerves and muscles: motors, drivers, sensors, power supplies, signal conditioning and communications.
Sets how much torque is available, how noisy the sensor readings are and how long the robot runs before the battery dies.
- Computer science
The programs: perception, planning, decision-making and the middleware that ties it all together.
The same hardware becomes a completely different robot with different software, which is exactly what makes a robot reprogrammable.
- Control theory and mathematics
The laws that turn a goal into a command: kinematics, dynamics, feedback and stability. It sits where mechanics and computing overlap, because it is the maths that lets code move a body on purpose.
This is where a robot stops being a mechanism and starts being a controlled mechanism. It is also where most of the maths in this curriculum lives.
Why can't the three just take turns: mechanics first, then electronics, then code?
Because every choice one of them makes ties the hands of the others. And it runs in both directions.
Watch it happen. Make the arm longer and you need more torque. More torque means a bigger motor. A bigger motor is heavier, so the structure has to be stiffer. A stiffer structure is heavier again, which needs more torque. You are back where you started, with a heavier robot.
Meanwhile the control engineer cannot tune anything without knowing the gear ratio. The programmer cannot promise a behaviour without knowing how fast the sensors report.
Teams that pass the design down a chain find out it does not fit at integration time, when changing anything is expensive. Robotics is co-design, or it is rework.
Example
One requirement, three consequences
"The robot must pick up a 2 kg part at 800 mm reach."
Mechanical: 2 × 9.81 × 0.8 ≈ 16 N·m at the shoulder before you have accelerated anything, so the link must not flex under that.
Electrical: a motor and gearbox that deliver 16 N·m continuously, plus the current, driver and cooling to match.
Control: the inertia changes as the arm extends, so the loop needs gain scheduling or a dynamic model.
Software: the gripper must confirm it actually has the part before the arm moves, or the first miss becomes a projectile.
One sentence in a spec and every discipline in the building has work to do.
Robotics is architecture, not bricklaying
A bricklayer, an electrician and a plumber each have a complete craft of their own.
An architect has to know enough of all three to design a building where the pipes do not run through the beams.
Robotics is the architect's role.
You will rarely be the best control theorist or the best mechanical designer in the room. You are the one who has to know how their choices collide.
| A robot | Robotics | |
|---|---|---|
| What it is | A physical machine | A field of study and practice |
| You can | Buy one, switch it on | Study it, work in it |
| Made of | Links, motors, sensors, code | Mechanics, electronics, computing, control |
| Example sentence | "This robot has six axes." | "She works in robotics." |
What it is
- A robot
- A physical machine
- Robotics
- A field of study and practice
You can
- A robot
- Buy one, switch it on
- Robotics
- Study it, work in it
Made of
- A robot
- Links, motors, sensors, code
- Robotics
- Mechanics, electronics, computing, control
Example sentence
- A robot
- "This robot has six axes."
- Robotics
- "She works in robotics."
Robotics is unusual among engineering fields in one more way. Its problems are open-world.
A bridge is designed for known loads, in a known place and it will not move. A robot is asked to work in a room whose contents change daily, with sensors that are noisy and occasionally just wrong, next to people who do unpredictable things.
So a robot rarely knows anything. It estimates. That is why probability turns up everywhere in this field: in sensor fusion, in localisation, in almost every lesson that comes later.
How this curriculum maps onto the diagram
Mechanical
Actuation & Mechanics covers links, joints, gears, wheels and grippers. Add the geometry half of Kinematics & Motion.
Electronic
Sensing & Perception covers transducers, signal conditioning, encoders, IMUs and cameras. Motors live in Actuation.
Computing
ROS Fundamentals, ROS 2 in Depth and Projects build the software that makes all of the above one working system.
Where mechanics meets computing
Kinematics & Motion and Control & Navigation: transforms, the Jacobian, trajectories, PID and beyond. This is the control overlap on the diagram.
And one more field entirely
Human–Robot Interaction, which draws on psychology and design rather than engineering, because a robot that people cannot work with has not solved the problem.
Treating robotics as "programming, but for machines".
Most robot failures are physical: a gripper that cannot hold the part, a sensor that cannot see it, a motor that stalls. Code cannot fix any of those.
Waiting for the hardware to be finished before starting the software.
Build a simulated robot from day one. It exposes the interface problems while they are still cheap to fix.
Assuming you must master every field before you can build anything.
You need working literacy in all of them and real depth in one or two. Start by building something small and end to end. The gaps will announce themselves.
Key takeaway
- A robot is the machine. Robotics is the field that designs, builds and programs it.
- Three engineering families meet in it: mechanical, electronic and computing. Human–Robot Interaction joins them wherever people are involved.
- The interesting parts live in the overlaps: mechatronics, embedded code and control.
- Their decisions constrain each other in both directions, so robotics is co-design rather than a handover chain.
- Robotics problems are open-world, which is why estimation and probability run through the whole field.
Finished this lesson?
Guest progress is saved on this device.