Computer vision.

SLAM.

Control theory.

Kinematics.

Machine learning.

ROS.

And those things absolutely matter.

But as I spent more time building and working with technical systems, I realised that some of the skills I relied on most were rarely the ones that appeared prominently on a module syllabus.

Nobody really teaches you how to approach a robot that simply is not working.

Nobody gives you a lecture called:

How to understand a codebase with 200 files when you have never seen it before.

Or:

How to work out whether the problem is the sensor, the network, the software, the configuration, or the hardware.

Yet these are the situations you encounter constantly.

Looking back, I think there is a second robotics curriculum that sits underneath the formal one.

These are some of the most important things it contains.

1. Learning how to debug systematically

When something fails in robotics, the first explanation that comes to mind is often wrong.

Imagine a mobile robot suddenly starts drifting.

You might immediately suspect localisation.

But the actual problem could be:

A wheel encoder producing incorrect measurements.

A transform using the wrong frame.

A timestamp problem.

A sensor mounted slightly differently.

A controller behaving incorrectly.

Wheel slip.

A configuration value.

Or something mechanical.

The visible failure is often several layers away from the actual cause.

That makes robotics debugging different from simply fixing a syntax error.

You are debugging a system.

The skill is not knowing every possible failure in advance.

It is knowing how to reduce the number of possibilities.

I learned to ask a different question

Instead of asking:

Why is the robot broken?

Ask:

What is the earliest point in the system where reality stops matching what I expect?

That question is much easier to investigate.

Suppose a robot refuses to follow a planned path.

Do not immediately change the planner.

Check the chain.

Does the hardware respond correctly?

Are the sensors producing sensible measurements?

Does odometry look reasonable?

Is the robot pose correct?

Is the map correct?

Is the planner producing the trajectory you expect?

Is the controller actually receiving it?

Is the correct command reaching the motors?

You can think of it roughly as:

Hardware → Sensors → Communication → Estimation → Planning → Control → Behaviour

Start near the beginning.

Move through the system.

Find the first point where something becomes wrong.

That simple habit has been far more useful than randomly changing parameters until something starts working.

2. Reading code is a completely different skill from writing code

Learning programming usually means writing programs.

Then you enter a real project and discover another problem.

Most of the code was written by somebody else.

And there may be thousands of lines of it.

Suddenly the challenge is not:

How do I implement this function?

It is:

Where does this behaviour even come from?

Large robotics systems can contain packages for perception, hardware interfaces, control, configuration, networking, logging, launch files, state machines and many other things.

Trying to read the repository from beginning to end rarely helps.

You need to learn how to navigate it.

I stopped trying to understand everything

When entering an unfamiliar codebase, I now think in terms of a specific question.

For example:

Where does this sensor measurement enter the system?

Then follow the data.

Where is it received?

Where is it transformed?

Where is it stored?

Who consumes it?

What happens after that?

Or perhaps:

Where is this motor command created?

Find the command.

Trace backwards.

Which controller generated it?

What state did the controller receive?

Where did that state come from?

You are effectively building a map of the software as you investigate it.

You do not need to understand the entire repository.

You need to understand the path relevant to the problem you are solving.

3. Logs are often more useful than the code

This is something I underestimated early on.

When software behaves strangely, the instinct is often to start reading code.

But the first question should sometimes be:

What did the system actually do?

Logs can tell you.

Which process started?

Which process failed?

Which sensor disconnected?

What value was received?

When did the problem begin?

Was something retrying?

Was there a timeout?

Did a node crash?

Was the system running normally immediately before the failure?

Good logs turn invisible behaviour into evidence.

And debugging becomes much easier once you stop guessing.

A lot of these skills sound obvious when written down.

But learning them changed how I approached technical problems far more than learning another isolated algorithm.

The next part is the framework I would have wanted when I first started working with larger robotics systems.

Read more

SLAM.

Computer vision.

Control.

Machine learning.

Planning.

I expected my MSc in Robotics and Computation to give me a much bigger technical toolbox.

It did.

But looking back, the most valuable thing I learned was not any single algorithm.

It was understanding how everything fits together.

A robot does not care that your perception algorithm works beautifully on its own.

It does not care that your controller is mathematically elegant.

It does not care that your planner finds an optimal path.

The robot only works when all of those systems work together.

That changed the way I think about robotics.

1. Everything in robotics is connected

At university, robotics is naturally divided into subjects.

Robot vision.

Navigation.

Control theory.

Sensing and manipulation.

Deep learning.

Virtual environments.

That separation is useful when you are learning.

But a real robot does not experience those subjects separately.

Consider something as simple as asking a robot arm to pick up a cup.

The camera first needs to observe the scene.

The perception system needs to find the cup.

The robot needs to estimate where that cup is in 3D space.

That position needs to be transformed into the coordinate frame of the robot.

The grasping system needs to decide how to approach it.

The motion planner needs to find a path.

The controller needs to execute that path.

The hardware needs to physically respond.

Then the robot needs feedback to determine whether the grasp actually succeeded.

One task.

Many systems.

That was one of the biggest changes in how I started thinking about robotics.

Before, I would ask:

How does SLAM work?

Later, I started asking:

What information does SLAM need, what does it produce, and which part of the robot depends on that output?

That second question is much more useful.

The output of one subsystem becomes the assumption of the next.

If that assumption is wrong, the problem propagates through the robot.

2. Mathematics becomes easier when there is a robot attached to it

Robotics involves a lot of mathematics.

Linear algebra.

Calculus.

Probability.

Optimisation.

Geometry.

Differential equations.

At first, some of it can feel detached from the actual robot.

Then you encounter a physical problem that needs solving.

Suddenly, the mathematics has a purpose.

A transformation matrix is no longer simply something you manipulate during an exercise.

It answers a practical question:

The camera says the object is here. Where is that object relative to the robot’s gripper?

Probability becomes more meaningful when your sensors disagree.

Your wheel encoders estimate one movement.

Your IMU measures another.

Your camera provides another source of information.

Now the question becomes:

Given imperfect measurements, where do I actually believe the robot is?

Control theory changes in the same way.

Instead of simply calculating gains, you start thinking:

What command should I send now so that the physical state of the robot moves towards the state I want?

Robotics did not make the mathematics simpler.

It gave the mathematics a reason to exist.

That distinction made a huge difference for me.

3. Real robots never have perfect information

Another lesson that kept appearing across robotics was uncertainty.

A beginner often asks:

Where is the robot?

A more realistic robotics question is:

Where do I currently believe the robot is, and how confident am I in that estimate?

That difference sounds small.

It is fundamental.

Sensors are noisy.

Wheel encoders can be affected by slip.

IMUs drift.

Cameras can struggle with lighting, motion blur or poor visual features.

Maps become outdated.

Models do not perfectly represent physical systems.

Objects move.

People behave unpredictably.

The robot still needs to make a decision.

This is why concepts such as state estimation, Bayesian inference, Kalman filtering and sensor fusion appear so often in robotics.

You rarely know the exact state of the world.

You estimate it.

Then you act based on that estimate.

Then you measure again.

A useful mental model is:

Sense → Estimate → Plan → Control → Act → Sense again

Robotics is a continuous feedback process.

Uncertainty is not an edge case.

It is part of the problem.

Looking back, however, some of the most useful lessons were the ones I did not recognise as important at the time.

They were less about learning another algorithm and more about understanding how engineers decide what is actually worth building.

Read more

SLAM.

Computer vision.

Control.

Machine learning.

Planning.

Subscribe now

I expected my MSc in Robotics and Computation to give me a much bigger technical toolbox.

It did.

But looking back, the most valuable thing I learned was not any single algorithm.

It was understanding how everything fits together.

A robot does not care that your perception algorithm works beautifully on its own.

It does not care that your controller is mathematically elegant.

It does not care that your planner finds an optimal path.

The robot only works when all of those systems work together.

That changed the way I think about robotics.

1. Everything in robotics is connected

At university, robotics is naturally divided into subjects.

Robot vision.

Navigation.

Control theory.

Sensing and manipulation.

Deep learning.

Virtual environments.

That separation is useful when you are learning.

But a real robot does not experience those subjects separately.

Consider something as simple as asking a robot arm to pick up a cup.

The camera first needs to observe the scene.

The perception system needs to find the cup.

The robot needs to estimate where that cup is in 3D space.

That position needs to be transformed into the coordinate frame of the robot.

The grasping system needs to decide how to approach it.

The motion planner needs to find a path.

The controller needs to execute that path.

The hardware needs to physically respond.

Then the robot needs feedback to determine whether the grasp actually succeeded.

One task.

Many systems.

That was one of the biggest changes in how I started thinking about robotics.

Before, I would ask:

How does SLAM work?

Later, I started asking:

What information does SLAM need, what does it produce, and which part of the robot depends on that output?

That second question is much more useful.

The output of one subsystem becomes the assumption of the next.

If that assumption is wrong, the problem propagates through the robot.

2. Mathematics becomes easier when there is a robot attached to it

Robotics involves a lot of mathematics.

Linear algebra.

Calculus.

Probability.

Optimisation.

Geometry.

Differential equations.

At first, some of it can feel detached from the actual robot.

Then you encounter a physical problem that needs solving.

Suddenly, the mathematics has a purpose.

A transformation matrix is no longer simply something you manipulate during an exercise.

It answers a practical question:

The camera says the object is here. Where is that object relative to the robot’s gripper?

Probability becomes more meaningful when your sensors disagree.

Your wheel encoders estimate one movement.

Your IMU measures another.

Your camera provides another source of information.

Now the question becomes:

Given imperfect measurements, where do I actually believe the robot is?

Control theory changes in the same way.

Instead of simply calculating gains, you start thinking:

What command should I send now so that the physical state of the robot moves towards the state I want?

Robotics did not make the mathematics simpler.

It gave the mathematics a reason to exist.

That distinction made a huge difference for me.

3. Real robots never have perfect information

Another lesson that kept appearing across robotics was uncertainty.

A beginner often asks:

Where is the robot?

A more realistic robotics question is:

Where do I currently believe the robot is, and how confident am I in that estimate?

That difference sounds small.

It is fundamental.

Sensors are noisy.

Wheel encoders can be affected by slip.

IMUs drift.

Cameras can struggle with lighting, motion blur or poor visual features.

Maps become outdated.

Models do not perfectly represent physical systems.

Objects move.

People behave unpredictably.

The robot still needs to make a decision.

This is why concepts such as state estimation, Bayesian inference, Kalman filtering and sensor fusion appear so often in robotics.

You rarely know the exact state of the world.

You estimate it.

Then you act based on that estimate.

Then you measure again.

A useful mental model is:

Sense → Estimate → Plan → Control → Act → Sense again

Robotics is a continuous feedback process.

Uncertainty is not an edge case.

It is part of the problem.

Looking back, however, some of the most useful lessons were the ones I did not recognise as important at the time.

They were less about learning another algorithm and more about understanding how engineers decide what is actually worth building.

Read more

At first, I associated virtual environments mainly with VR headsets.

Games.

Simulations.

Digital spaces.

But the subject goes much deeper.

Subscribe now

Virtual environments combine computer graphics, human perception, interaction, sensing, modelling, and real-time systems.

They are not only about creating digital worlds.

They are about making those worlds feel believable, useful, and responsive.

The biggest lesson

A virtual environment is not simply a 3D scene.

It is an experience.

The system must understand:

What the user can see.

How the user moves.

What the user touches.

How the environment responds.

What makes the experience feel natural.

This makes virtual environments both an engineering problem and a human problem.

What virtual environments actually involve

The field brings together many different areas.

Computer graphics creates the visual world.

Sensors track movement and position.

Interaction systems allow users to manipulate objects.

Audio helps create spatial awareness.

Haptics provide physical feedback.

Human perception determines what feels believable.

A successful virtual environment depends on all these systems working together.

Real-time graphics became much more meaningful

In ordinary computer graphics, an image can take time to render.

In virtual reality, delay changes the entire experience.

The world must respond immediately when the user turns their head or moves their hand.

Even small delays can break immersion.

This introduced me to an important idea:

Performance is not only about speed.

It affects perception.

A visually impressive environment is not useful if it responds too slowly.

Human perception shapes the technology

One of the most interesting ideas was that digital environments do not need to recreate every detail of reality.

They need to recreate the details that matter to human perception.

Users notice some things immediately.

Motion.

Depth.

Lighting.

Scale.

Interaction.

Other details may have very little effect on the experience.

Understanding this allows engineers to use computation more efficiently.

Instead of modelling everything perfectly, they focus on what feels meaningful.

Tracking connects the user to the world

Virtual environments need to know where the user is.

Head position.

Hand movement.

Body orientation.

Direction of attention.

Tracking systems collect this information and update the environment continuously.

This is closely connected to robotics.

Both robots and virtual systems must estimate pose, process sensor data, and react to movement in real time.

The difference is the goal.

Robots estimate position to act in the physical world.

Virtual environments estimate position to update the digital world.

Presence is more than visual quality

One of the central ideas in virtual reality is presence.

Presence is the feeling of actually being inside the virtual environment.

High resolution helps.

But presence also depends on:

Accurate tracking.

Low latency.

Natural interaction.

Consistent scale.

Convincing audio.

Responsive environments.

A system can look realistic and still feel artificial.

Presence emerges when many small systems behave consistently.

Interaction is harder than it looks

Allowing someone to look around a virtual world is one problem.

Allowing them to interact naturally is much harder.

How should someone pick up an object?

How should virtual hands behave?

What happens when the user touches a surface?

How should the system communicate resistance or weight?

These questions connect software, hardware, perception, and human behaviour.

Interaction design is not only about making controls work.

It is about making them feel intuitive.

Haptics added another dimension

Visual and audio feedback are powerful.

But touch changes the experience.

Haptic systems attempt to recreate physical sensations such as vibration, resistance, texture, or force.

This is especially relevant in training, medical simulation, teleoperation, and robotics.

A user controlling a remote robot may need more than visual information.

Force feedback can help them understand contact with the environment.

This creates a direct connection between virtual environments and robot manipulation.

Digital environments can come from real places

Not every virtual environment is imagined.

Many are created from scans, images, depth measurements, or point clouds captured from the real world.

These scenes must be processed, simplified, and converted into representations that can run efficiently.

This introduces challenges in:

3D reconstruction.

Geometry processing.

Appearance modelling.

Scene understanding.

Real-time rendering.

The same data used to build robot maps can also help build immersive digital spaces.

Why this connected strongly with robotics

Virtual environments and robotics share many technical foundations.

Both use:

Sensing.

Tracking.

Mapping.

Pose estimation.

Computer vision.

Real-time processing.

Human interaction.

Simulation.

Virtual environments can also become testing spaces for robots.

Engineers can create realistic scenes, simulate sensors, study human behaviour, and test robot systems before deploying them physically.

What I found most valuable

The most valuable part was seeing how engineering and human perception connect.

A technically correct system does not automatically create a good experience.

It must also feel responsive, understandable, and comfortable.

That lesson applies far beyond virtual reality.

Robots working with humans face the same challenge.

They need to behave correctly.

But they also need to behave predictably.

The systems perspective

Virtual environments are a strong example of systems engineering.

Rendering cannot be separated from latency.

Tracking cannot be separated from interaction.

Audio cannot be separated from presence.

Hardware cannot be separated from human perception.

Every component affects the complete experience.

This is the same way I learned to think about robotics.

Individual technologies matter.

But the interactions between them matter more.

Why students should study virtual environments

Virtual environments teach skills that apply across many fields.

Computer graphics.

Robotics.

Simulation.

Gaming.

Medical technology.

Human computer interaction.

Digital twins.

Augmented reality.

The subject sits at the intersection of technical systems and human experience.

That makes it a valuable area for anyone interested in building technologies that people can enter, use, and trust.

TLDR

Studying virtual environments at UCL changed how I thought about digital worlds.

I learned that virtual environments are not only about graphics.

They combine sensing, tracking, modelling, rendering, audio, haptics, interaction, and human perception.

The most important lesson was simple:

A believable virtual world is not created by one technology.

It emerges when many systems work together in real time.

That systems perspective connects virtual environments closely with robotics, simulation, and human-centred engineering.

Subscribe now

Hit reply: I read every email.

Deep learning is often introduced through impressive results.

Image generation.

Object detection.

Language models.

Autonomous systems.

Subscribe now

But behind every successful model is a much less glamorous process.

Preparing data.

Choosing an architecture.

Training carefully.

Evaluating results.

Understanding why the model failed.

This module helped me see deep learning not as a collection of powerful models, but as a complete engineering workflow.

The biggest lesson

Before studying the module, it was easy to think that deep learning mainly meant choosing a neural network and training it.

The reality is much broader.

A model can perform well during training and still fail in practice.

It can memorise the data.

It can learn the wrong patterns.

It can produce impressive metrics while struggling on real examples.

Applied deep learning is not only about building neural networks.

It is about building neural networks that work reliably outside the training environment.

What we actually studied

The module introduced the main neural network architectures used across computer vision and natural language processing.

We worked with:

Convolutional neural networks.

Recurrent neural networks.

Transformers.

Variational autoencoders.

Generative adversarial networks.

Each architecture was connected to a practical task.

Image classification.

Image segmentation.

Text classification.

Character generation.

Language modelling.

Image generation.

This made the differences between the models much easier to understand.

Learning through Python

The practical work used Python, NumPy, and modern deep learning frameworks.

We could work with either PyTorch or TensorFlow.

This was useful because it shifted the focus from only understanding the theory to implementing complete training pipelines.

A typical workflow involved:

Loading and preparing data.

Defining the model.

Training it.

Evaluating its performance.

Saving and reviewing the results.

The implementation made the theory much more concrete.

Convolutional neural networks

One of the first major topics was convolutional neural networks.

CNNs are designed to process spatial information.

They are particularly useful for images because they can learn patterns such as edges, shapes, textures, and eventually complete objects.

We explored tasks such as image classification and image segmentation.

Classification asks:

What is inside this image?

Segmentation asks:

Which pixels belong to each object or region?

That difference is important in robotics.

A robot may not only need to know that a person is present.

It may need to know exactly where that person is in the scene.

Recurrent neural networks

We also studied recurrent neural networks.

RNNs are designed for sequential information.

Instead of treating every input independently, they use previous information when processing the current input.

This makes them useful for tasks involving text, speech, sensor readings, or any data that changes over time.

We applied them to text classification and character generation.

This introduced an important idea.

The order of information often matters as much as the information itself.

Transformers changed the scale of the problem

Transformers approach sequential data differently.

Rather than processing information one step at a time, they use attention to identify which parts of the input are most relevant.

This allows them to model long relationships more effectively.

We explored transformers through language modelling.

The most useful lesson was not simply how the architecture worked.

It was understanding why attention became such an important idea across modern artificial intelligence.

The same concept now appears in language, computer vision, robotics, and multimodal systems.

Generative models

The module also introduced generative deep learning.

Instead of only predicting a label, generative models learn how data is structured and create new examples.

We studied variational autoencoders for generating handwritten digits.

We also explored generative adversarial networks for creating face images.

These models introduced different challenges.

Training could become unstable.

Outputs could look realistic while lacking diversity.

Evaluation was less straightforward than ordinary classification.

This showed me that generating data is a very different problem from recognising it.

Training the model was only part of the work

A major part of applied deep learning is understanding what happens during training.

A model may be too simple and fail to learn the problem.

It may be too complex and memorise the training data.

It may perform well on one dataset but fail on slightly different examples.

This is why regularisation, validation, and evaluation matter.

The goal is not to achieve the lowest training loss.

The goal is to build a model that generalises.

Research and real applications are different

One of the most valuable ideas in the module was the distinction between deep learning research and applied deep learning.

A research result may demonstrate that an idea works under specific conditions.

A practical system must handle much more.

Limited compute.

Imperfect data.

Deployment constraints.

Changing inputs.

Reliability requirements.

The best model on paper is not always the best model for a real application.

That tradeoff is especially important in robotics, where latency, power, memory, and safety all matter.

Why this connected strongly with robotics

Deep learning has become an important part of modern robotics.

It is used in:

Object detection.

Semantic segmentation.

Human activity recognition.

Robot vision.

Language understanding.

Learning from demonstrations.

But a robot cannot depend on model accuracy alone.

The model must also run within the available hardware and respond quickly enough for the robot to act.

Studying applied deep learning helped me understand that model selection is also a systems engineering decision.

What I took away from the module

The biggest lesson was not one particular architecture.

It was learning the complete process.

Understand the task.

Prepare the data.

Choose an appropriate model.

Train it carefully.

Evaluate it honestly.

Study its failures.

Improve the system.

Deep learning becomes much less mysterious once you understand this workflow.

Why students should study applied deep learning

It is easy to copy a model from a tutorial and produce an output.

It is much harder to understand why it works.

Why it fails.

How to evaluate it.

How to deploy it.

How to choose between different approaches.

Those are the skills that turn deep learning from experimentation into engineering.

TLDR

Studying Applied Deep Learning at UCL helped me connect neural network theory with practical implementation.

We explored convolutional neural networks, recurrent neural networks, transformers, variational autoencoders, and generative adversarial networks.

We applied them to computer vision, language processing, and generative tasks using Python, PyTorch, and TensorFlow.

But the most important lesson was broader.

Applied deep learning is not only about building powerful models.

It is about building models that are trained carefully, evaluated honestly, and designed to work within real-world constraints.

Subscribe now

Hit reply: I read every email.

At first, control theory can feel very mathematical.

State space models.

Stability.

Kalman filters.

LQR.

Robust control.

Subscribe now

But underneath all that mathematics is a very practical question:

How do you make a robot do what you actually want it to do?

That question changed the way I understood robot motion.

The core idea

Imagine telling a robot arm:

Move to this position.

Or telling a drone:

Stay at this altitude.

Or telling a mobile robot:

Follow this trajectory.

Giving the command is easy.

Making the robot follow that command accurately, smoothly, and reliably is much harder.

That is where control theory comes in.

What control theory actually does

A controller continuously compares:

What I want the robot to do

with

What the robot is actually doing

It then calculates what should happen next.

This creates a feedback loop.

Measure.

Compare.

Correct.

Repeat.

Often hundreds or thousands of times every second.

This simple idea sits underneath an enormous amount of robotics.

We started with models

Before you can control a system, it helps to understand how that system behaves.

That means creating a mathematical model.

For example:

If I apply this motor command, how will the robot respond?

How quickly will it accelerate?

How will its position change?

How does the system evolve over time?

We studied state space models and the difference between discrete and continuous systems.

This gave us a mathematical way to describe robot behaviour.

Then came stability

Making something move is not enough.

It needs to move reliably.

A badly designed controller can cause a robot to:

Overshoot.

Oscillate.

Respond too slowly.

Or become completely unstable.

Stability asks whether the system eventually behaves the way we want it to.

This is one of the most important ideas in control theory.

PID was only the beginning

PID is probably the controller most robotics students encounter first.

You measure an error.

The controller tries to reduce it.

But real robotics quickly becomes more complicated.

What if you need to control several states at once?

What if the system has constraints?

What if the model is imperfect?

What if disturbances affect the robot?

This is where more advanced control methods become useful.

LQR changed how I thought about control

One of the techniques we studied was Linear Quadratic Regulation.

LQR asks something interesting.

Instead of simply reducing error, can we find a control strategy that balances performance with the effort required to achieve it?

You might want a robot to reach its target quickly.

But you might also want to avoid aggressive control inputs.

LQR provides a mathematical framework for balancing those objectives.

This introduced me to a much bigger idea in robotics:

Control is often an optimisation problem.

But robots cannot measure everything perfectly

There is another problem.

Controllers need information about the robot’s state.

Position.

Velocity.

Orientation.

Sometimes those quantities cannot be measured directly.

And sensors are never perfect.

This is where estimation becomes important.

Kalman filters connected sensing and control

We studied Kalman filters as part of estimation.

The idea is powerful.

You have a model predicting what the robot should be doing.

You also have noisy sensor measurements telling you what appears to be happening.

The Kalman filter combines both to estimate the state of the system.

This creates an important connection:

Sensing tells us what we can measure.

Estimation tells us what we believe the state is.

Control decides what to do next.

That loop appears everywhere in robotics.

Real robots are never perfect

Another important topic was robustness.

Mathematical models are approximations.

The real robot may have:

Different friction.

Different loads.

Sensor noise.

External disturbances.

Model errors.

A controller that works perfectly in simulation may perform badly on the physical robot.

Robust control is about designing systems that continue to behave well even when reality does not perfectly match the model.

Why control theory matters

Control sits between intelligence and physical behaviour.

A planner might calculate the perfect trajectory.

A perception system might understand the environment perfectly.

But eventually, something has to make the robot move.

Motors need commands.

Joints need torques.

Positions need correcting.

Disturbances need handling.

That is the job of control.

What I took away from studying it

The biggest lesson was not PID, LQR, Kalman filters, or any individual algorithm.

It was understanding the loop:

Model.

Measure.

Estimate.

Control.

Observe again.

Robots continuously repeat this process while interacting with the physical world.

Once I understood that, many other robotics concepts started connecting together.

Why students should learn control theory

It is tempting to jump directly into AI, computer vision, or robot learning.

Those areas are exciting.

But if you want to understand why robots physically behave the way they do, control theory is fundamental.

It appears in:

Robot arms.

Drones.

Autonomous vehicles.

Humanoids.

Mobile robots.

Almost anything that moves.

You do not need to master every equation immediately.

Start by understanding feedback.

Then understand models.

Then stability.

Then estimation.

The mathematics becomes much easier when you understand what problem it is trying to solve.

TLDR

Studying robot control theory at UCL taught me what happens between deciding to move and actually moving.

We studied concepts such as state space models, stability, Kalman filters, LQR, multivariable control, and robust control.

But the most important idea was simpler:

A robot constantly observes what is happening, estimates its state, compares it with what it wants, and corrects its behaviour.

Sense.

Estimate.

Control.

Repeat.

That feedback loop is one of the foundations of robotics.

Subscribe now

Hit reply: I read every email.

Before taking it, I thought robotics was mostly about making robots move.

How do you navigate?

How do you plan a path?

How do you control motors?

Subscribe now

This module showed me something different.

Moving is only half the problem.

The other half is interacting with the world.

The biggest lesson

A robot that can move is useful.

A robot that can understand, touch, and manipulate its environment becomes truly autonomous.

That is what this module focused on.

How can robots sense the world around them and interact with objects safely, accurately, and intelligently?

What we actually studied

The module combined two major areas.

Robot sensing.

Robot manipulation.

Together they answered one question.

How can a robot understand its surroundings well enough to perform useful physical tasks?

Some of the topics we explored included:

• robot kinematics

• pose representation

• visual sensing

• force and torque sensing

• robotic grasping

• human robot interaction

• reinforcement learning for manipulation

Although each topic looked different, they all supported the same goal.

Helping robots interact with the physical world.

Kinematics became practical

Before this module, kinematics felt like mathematics.

Transformation matrices.

Coordinate frames.

Forward and inverse kinematics.

During the module, it became much more intuitive.

Kinematics answers a practical question.

How do we move the robot’s end effector exactly where it needs to be?

Whether the robot is picking up a cup or assembling a product, everything starts with positioning.

Sensing is more than cameras

When people hear robot sensing, they usually think about cameras.

We quickly learned that robots rely on many different sensing systems.

Visual sensors help robots observe the environment.

Force and torque sensors tell robots how hard they are pushing.

Joint sensors estimate movement.

Together, these sensors help the robot understand both the world around it and its own physical state.

Good manipulation depends on both.

Grasping is harder than it looks

Picking up an object sounds simple.

Humans do it without thinking.

For robots, it is surprisingly difficult.

The robot must estimate:

Where is the object?

What shape is it?

How should I approach it?

How much force should I apply?

Too little force and the object slips.

Too much force and it may break.

Robotic grasping combines perception, planning, control, and sensing into one task.

Uncertainty exists everywhere

One theme appeared throughout the module.

The world is uncertain.

Objects are not always where you expect.

Sensors are noisy.

Lighting changes.

People move unexpectedly.

Instead of assuming perfect information, robots must continuously estimate and adapt.

This idea appears throughout modern robotics.

Human robot interaction changed my perspective

Not every robot works alone.

Many robots operate alongside people.

That introduces new challenges.

The robot must understand human behaviour.

Move safely.

React predictably.

Collaborate instead of simply executing commands.

Designing robots for people is very different from designing robots for factories.

Research became part of learning

One aspect I appreciated was the emphasis on reading research papers.

Instead of only learning existing techniques, we explored how new ideas are developed and evaluated.

This helped me understand that robotics is constantly evolving.

There is always a better algorithm, a better sensor, or a better way to solve a problem.

Learning never really stops.

What I took away from the module

The biggest lesson was simple.

Robots do not exist to move.

They exist to interact.

Everything we studied supported that idea.

Sensing allows robots to understand.

Manipulation allows robots to act.

Without sensing, manipulation becomes unreliable.

Without manipulation, sensing has little purpose.

The two are inseparable.

Why this matters for students

If you are learning robotics, do not only study motion.

Spend time understanding how robots perceive and interact with the world.

That is where many of the hardest and most interesting engineering problems exist.

It also helps you see robotics as a complete system rather than a collection of algorithms.

TLDR

Studying Robot Sensing and Manipulation at UCL changed the way I think about robotics.

The module connected kinematics, sensing, grasping, human robot interaction, and reinforcement learning into one complete picture.

It taught me that autonomous robots are not defined by how well they move.

They are defined by how well they understand and interact with the world around them.

Subscribe now

Hit reply: I read every email.

Robot Vision and Navigation.

At first, I thought it would simply teach robots how to use cameras.

I was wrong.

It taught me something much bigger.

Subscribe now

It taught me how autonomous robots understand where they are, build maps of the world, and navigate through environments they have never seen before.

This was the point where many robotics concepts I had learned separately finally connected.

The biggest lesson

Before this module, I…

I viewed robotics as individual topics.

Computer vision.

SLAM.

Localisation.

Navigation.

Sensor fusion.

After this module, I realised they are all part of one system.

A robot cannot navigate if it does not know where it is.

It cannot localise without sensing the environment.

It cannot build reliable maps without estimating motion.

Everything depends on everything else.

That systems perspective completely changed how I approached robotics.

What we actually learned

The module focused on one question.

How can a robot move safely and autonomously using its own sensors?

To answer that, we studied topics including:

• robot pose estimation

• visual localisation

• sensor fusion

• mapping

• SLAM

• 3D reconstruction

• motion estimation

• navigation

Rather than treating these as isolated subjects, we learned how they fit together to create an autonomous robot.

Vision is much more than cameras

One misconception I had was that robot vision was simply image processing.

It is much more than that.

Robot vision is about extracting useful information from images.

A robot needs to identify structure in the environment.

Estimate depth.

Recognise landmarks.

Track its own movement.

Build a representation of the world.

A camera captures pixels.

Robot vision turns those pixels into understanding.

Navigation begins with localisation

One idea appeared throughout the module.

Before a robot can decide where to go, it must know where it is.

Localisation is the foundation of navigation.

Without reliable localisation:

Maps become inaccurate.

Planning becomes unreliable.

Control becomes unstable.

This is why localisation is one of the most important problems in robotics.

Sensor fusion became much clearer

Real robots rarely rely on one sensor.

Instead, they combine information from multiple sources.

For example:

• cameras

• GPS

• IMUs

• wheel encoders

Each sensor has strengths.

Each sensor has weaknesses.

Combining them produces a more reliable estimate than any individual sensor could provide.

This idea appears throughout modern robotics.

SLAM finally made sense

SLAM is one of those topics that sounds intimidating.

Seeing it applied in the context of navigation made it much easier to understand.

The challenge is simple to describe.

The robot does not know where it is.

The robot does not have a map.

It must solve both problems at the same time.

Once I understood this relationship, many research papers became much easier to follow.

Theory met practical engineering

One thing I appreciated about the module was that it was not only theoretical.

We explored real systems and algorithms that are widely used in robotics, including visual SLAM and mapping approaches.

We also implemented practical solutions using programming languages such as Python, MATLAB, and C++.

That combination helped bridge the gap between mathematical concepts and working robotic systems.

What I took away from the module

The biggest takeaway was not a single algorithm.

It was a different way of thinking.

Robotics is not a collection of independent techniques.

It is a connected system.

Perception supports localisation.

Localisation supports mapping.

Mapping supports planning.

Planning supports control.

When one part becomes unreliable, every other part is affected.

Understanding those relationships has helped me far more than memorising individual algorithms.

Why this matters for students

If you are learning robotics today, do not study vision, localisation, or navigation in isolation.

Always ask:

How does this fit into the bigger system?

That question will help you connect concepts much faster.

It will also prepare you to understand how real autonomous robots operate.

TLDR

Studying Robot Vision and Navigation at UCL changed the way I think about robotics.

The module taught much more than computer vision.

It connected perception, localisation, sensor fusion, mapping, SLAM, and navigation into one complete system.

That systems perspective is one of the most valuable lessons I took from my robotics degree.

If you understand how these pieces work together, autonomous robotics becomes much easier to understand.

Stay tuned, I will share the best resources to learn in the upcoming issues.

Subscribe now

Hit reply: I read every email.

The technology was not good enough.

Sometimes that is true.

But more often, the robot is not the biggest problem.

Subscribe now

Many robotics startups build impressive demonstrations.

Very few build sustainable products.

There is a big difference.

The core idea

A robot is only one part of a business.

A successful robotics company must solve three problems:

Can the robot work?

Can it work reliably?

Will someone pay for it?

Many startups solve the first problem.

The remaining two are much harder.

Building a demo is different from building a product

A robot can work perfectly during a demonstration.

The environment is controlled.

The lighting is predictable.

The obstacles are known.

The battery is fully charged.

Real customers do not operate in controlled environments.

They expect the robot to work every day, in changing conditions, with minimal supervision.

That is a much higher standard.

Reliability is underestimated

A robot that succeeds 90% of the time sounds impressive.

Until you imagine using it every day.

If a warehouse robot performs hundreds of tasks each day, a small failure rate quickly becomes expensive.

Customers buy reliability.

Not demonstrations.

The real world is difficult

Every environment is different.

Floors change.

Lighting changes.

Weather changes.

People behave unpredictably.

Sensors become dirty.

Hardware wears out.

A robotics startup must design systems that continue working despite these challenges.

That is much harder than solving a laboratory problem.

Hardware moves slowly

Software can often be updated in minutes.

Hardware cannot.

Building prototypes takes time.

Testing takes time.

Manufacturing takes time.

Replacing faulty components takes time.

Every hardware decision has long term consequences.

Integration is harder than individual components

Many startups build excellent perception.

Others build excellent control.

Others build excellent hardware.

Customers do not buy individual components.

They buy complete systems.

Making sensing, localisation, planning, control, safety, and hardware work together reliably is one of the hardest engineering challenges.

The economics must work

Even if a robot performs well, it must create value.

It must save time.

Reduce costs.

Increase productivity.

Improve safety.

If the benefit is smaller than the cost of buying, maintaining, and operating the robot, businesses will not adopt it.

Good engineering alone is not enough.

Scaling changes everything

A robot that works once is a prototype.

A robot that works one thousand times is a product.

As production increases, new challenges appear:

• manufacturing

• maintenance

• spare parts

• software updates

• customer support

Many startups underestimate this stage.

Why strong engineering still matters

None of this means technology is unimportant.

Good engineering is essential.

But successful robotics companies combine engineering with reliability, operations, and business understanding.

The robot is only one piece of a much larger system.

What students can learn from this

If you want to work in robotics, do not only learn algorithms.

Learn how systems behave in the real world.

Understand reliability.

Think about maintenance.

Consider cost.

Learn why products succeed, not only why robots move.

These skills make you a stronger engineer.

TLDR

Most robotics startups do not fail because they cannot build a robot.

They fail because building a reliable, scalable, and economically valuable product is much harder than building a demonstration.

Robotics is not only about technology.

It is about turning technology into something people can depend on every day.

Subscribe now

Hit reply: I read every email.

How do I start learning robotics?

It is a fair question.

Robotics combines programming, electronics, mechanics, control, artificial intelligence, and mathematics.

Looking at everything at once can feel overwhelming.

Subscribe now

The mistake many beginners make is trying to learn all of it at the same time.

You do not need to.

You need a roadmap.

The core idea

Do not learn robotics as individual subjects.

Learn it as a system.

Every robot follows a simple flow.

It senses the world.

It understands where it is.

It decides what to do.

It moves.

Once you understand this flow, every topic has a place.

Step 1: Learn the basics of programming

Programming is how you communicate with a robot.

I recommend starting with Python.

It is widely used in robotics, easy to read, and supported by many robotics libraries.

Do not focus on writing advanced software.

Learn how to solve problems with code.

Step 2: Learn Linux

Most robotics software runs on Linux.

Become comfortable with:

• the terminal

• file management

• installing software

• using Git

• debugging applications

Linux is a tool you will use almost every day as a robotics engineer.

Step 3: Understand how robots work

Before building projects, understand the major building blocks.

Learn:

• sensing

• localisation

• mapping

• planning

• control

These concepts appear in almost every modern robot.

Do not worry about mastering them immediately.

Focus on understanding what each one does.

Step 4: Build small projects

This is where real learning begins.

Start simple.

Build a line-following robot.

Control a motor.

Read data from a sensor.

Create a basic obstacle avoidance robot.

Small projects teach lessons that books cannot.

Step 5: Learn ROS 2

Once you understand the basics, start learning ROS 2.

ROS 2 teaches you how modern robotics software is organised.

You will learn about:

• nodes

• topics

• services

• packages

• distributed systems

These concepts are widely used in industry.

Step 6: Learn simulation

Not everyone has access to expensive hardware.

Simulation allows you to experiment safely.

Tools such as Gazebo and Isaac Sim let you:

• test algorithms

• build robots

• practice navigation

• debug systems

Many robotics engineers spend significant time working in simulation before deploying to real robots.

Step 7: Learn by building

Reading alone is not enough.

Every concept should become a project.

Every project should teach a lesson.

Every lesson should prepare you for the next challenge.

Learning robotics is an active process.

What you should not do

Do not spend months collecting courses.

Do not wait until you know everything before building.

Do not compare your progress with people who have years of experience.

Robotics is learned through repetition.

Not perfection.

A simple roadmap

Programming.

Linux.

Robot fundamentals.

Small projects.

ROS 2.

Simulation.

Larger systems.

This order builds understanding naturally.

Why beginners struggle

Most people feel overwhelmed because they see robotics as dozens of unrelated topics.

It is not.

It is one system made of connected parts.

Once you understand how those parts fit together, learning becomes much easier.

TLDR

Start with programming and Linux.

Learn how robots sense, localise, plan, and move.

Build small projects.

Learn ROS 2.

Use simulation.

Most importantly, keep building.

You do not need to learn everything before you begin.

You only need to take the first step.

The rest becomes clearer as you go.

Subscribe now

Hit reply: I read every email.

A warehouse robot avoids obstacles.

A drone flies through a forest.

A delivery robot navigates busy sidewalks.

At first glance, it feels almost magical.

Subscribe now

But underneath, two systems work closely together:

Vision.

Navigation.

One helps the robot understand the world.

The other helps it move through that world.

What is robot vision?

Robot vision is the process of turning visual information into understanding.

Cameras capture images.

Software processes those images.

The robot extracts useful information such as:

• obstacles

• people

• objects

• free space

• landmarks

Robot vision is not the same as human vision.

Humans naturally understand scenes.

Robots must convert pixels into data they can reason about.

What is navigation?

Navigation is the process of moving safely from one place to another.

To navigate successfully, a robot needs to answer three questions:

Where am I?

Where do I want to go?

How do I get there safely?

Navigation combines localisation, mapping, planning, and control into a complete system.

How vision supports navigation

Vision helps robots understand their surroundings.

For example, cameras can help identify:

• obstacles

• doors

• lanes

• people

• traffic signs

This information improves navigation decisions.

Without perception, navigation becomes unreliable.

Without navigation, perception has no purpose.

A simple example

Imagine a delivery robot moving along a sidewalk.

Its cameras detect pedestrians.

Its localisation system estimates position.

Its map identifies available routes.

Its planner generates a path.

Its controller commands the motors.

Vision provides information.

Navigation uses that information to make decisions.

Vision is not only cameras

When people hear robot vision, they often think only about cameras.

In practice, robots may combine:

• RGB cameras

• stereo cameras

• depth cameras

• LiDAR

• thermal cameras

Each sensor contributes different information.

Many robots use sensor fusion to improve reliability.

Navigation is more than path planning

Many beginners think navigation means choosing a route.

Navigation includes much more:

• localisation

• mapping

• obstacle avoidance

• path planning

• motion control

A robot must continuously update its understanding of the environment while moving.

Why navigation is difficult

The real world changes constantly.

People move.

Lighting changes.

Objects appear unexpectedly.

Sensors become noisy.

Maps become outdated.

Robots must adapt continuously.

This is why navigation remains one of the hardest problems in robotics.

Why vision is difficult

Images contain enormous amounts of information.

The challenge is deciding what matters.

A robot must determine:

What is an obstacle?

What can be ignored?

What is moving?

What is safe?

Human brains solve these problems effortlessly.

Robots require significant computation.

Why robots use multiple systems together

No single technology solves navigation.

Vision alone is not enough.

Maps alone are not enough.

Planning alone is not enough.

Reliable navigation emerges when multiple systems work together.

This is why robotics engineers think in systems rather than algorithms.

A simple way to think about it

Vision answers:

What does the world look like?

Navigation answers:

What should I do next?

Together, they allow robots to move intelligently.

Why beginners struggle with these concepts

Beginners often learn vision and navigation separately.

They build object detectors.

They study path planning.

But real robots connect these systems continuously.

Understanding these interactions is what makes robotics start to feel intuitive.

TLDR

Robot vision helps robots understand their surroundings.

Navigation helps robots move safely toward a goal.

Vision provides information.

Navigation turns that information into action.

Neither system works well alone.

Modern robots succeed because sensing, localisation, mapping, planning, and control work together as one connected system.

Subscribe now

Hit reply: I read every email.

Kinematics.

Dynamics.

They appear in robot arms.
Mobile robots.
Humanoids.
Drones.

Subscribe now

Many beginners assume they are advanced topics that can be ignored.

They cannot.

These concepts form the foundation of robot motion.

The good news is that the core ideas are simpler than they sound.

The simplest way to think about it

Kinematics asks:

How does the robot move?

Dynamics asks:

Why does the robot move that way?

That is the fundamental difference.

Kinematics describes motion.

Dynamics explains the forces behind that motion.

What is kinematics?

Kinematics studies motion without worrying about forces.

Imagine a robotic arm.

You move the joints.

The end effector moves through space.

Kinematics helps answer questions such as:

• Where is the robot arm right now?

• Where will the end effector be if a joint rotates?

• What joint positions are needed to reach a target?

Kinematics focuses on geometry.

Positions.

Orientations.

Motion relationships.

It does not care how much force is required.

A simple example

Imagine a robotic arm picking up a cup.

The cup is located on a table.

Kinematics determines:

How should the joints move so the gripper reaches the cup?

It is purely a positioning problem.

No forces.

No motor torques.

Only motion.

What is dynamics?

Dynamics takes the next step.

It studies motion together with forces.

Now we ask:

How much torque is needed to move the arm?

How does gravity affect motion?

What happens when the robot lifts a heavy object?

What happens during acceleration?

Dynamics explains what causes movement.

A simple example

Imagine the same robotic arm.

This time the cup is replaced by a heavy toolbox.

The arm can still reach it.

Kinematics says the motion is possible.

Dynamics determines whether the motors can actually perform it.

This is a very important distinction.

Why robotics needs both

A robot that understands only kinematics can plan motion.

A robot that understands dynamics can execute motion realistically.

Real robots need both.

The planner may determine where the robot should go.

The controller must determine how much force is required to get there.

Where you see kinematics

Kinematics appears in:

• robot arms

• inverse kinematics

• path planning

• humanoid motion

• manipulator control

Any time a robot needs to determine position or movement, kinematics is involved.

Where you see dynamics

Dynamics appears in:

• motor control

• balancing robots

• drones

• humanoids

• force control

• trajectory tracking

Whenever forces, torques, mass, or acceleration matter, dynamics becomes important.

Why beginners struggle with these concepts

The terminology sounds intimidating.

Forward kinematics.

Inverse kinematics.

Rigid body dynamics.

Manipulator equations.

Many students immediately assume the topic is too advanced.

But the underlying ideas are intuitive.

Every robot moves.

Every movement has geometry.

Every movement requires force.

Kinematics studies the geometry.

Dynamics studies the force.

A useful mental model

Imagine pushing a shopping trolley.

Kinematics answers:

Where will the trolley go?

Dynamics answers:

How hard do I need to push?

Together, they describe the complete motion.

Why these concepts matter

Many robotics topics eventually build on them.

Control.

Motion planning.

Manipulation.

Locomotion.

Humanoid robotics.

Even modern robot learning systems often rely on kinematic and dynamic models underneath.

Understanding these ideas early makes many other topics easier.

TLDR

Kinematics describes motion.

Dynamics explains the forces behind motion.

Kinematics answers:
Where will the robot move?

Dynamics answers:
What is required to make that movement happen?

Together, they form the foundation of robot motion and control.

If you understand these two concepts, many areas of robotics become much easier to understand.

Subscribe now

Hit reply: I read every email.

The algorithm.
The AI model.
The robot itself.

But real robotics engineering starts somewhere else.

Subscribe now

System design.

Before a robot moves, maps, or makes decisions, engineers must decide how the entire system will be structured.

That structure affects everything that comes after.

What robot system design actually means

Robot system design is the process of deciding:

• what components the robot needs

• how those components communicate

• where computation happens

• how data flows through the system

• how the robot handles failure and uncertainty

It is not only about writing software.

It is about designing how the entire robot operates as a connected system.

The robot is a collection of systems

A robot is rarely one program.

It is usually many independent systems working together.

For example:

Sensors observe the environment.
Localisation estimates position.
Mapping builds world representation.
Planning chooses motion.
Control executes commands.
Safety systems monitor behaviour.

Each system has different timing, computation, and reliability requirements.

Good system design organises these interactions clearly.

The first question: what problem is the robot solving

Strong robot design begins with constraints.

Not technology.

Before choosing sensors or software, engineers ask:

Where will the robot operate
What tasks will it perform
How fast must it react
What failures are acceptable

A warehouse robot and a drone require completely different system designs because their constraints are different.

Hardware and software must be designed together

This is one of the biggest differences between robotics and pure software engineering.

Hardware affects software.
Software affects hardware.

For example:

A weak compute platform limits perception models.
Poor sensor placement affects localisation.
Battery limitations affect compute choices.

Good robotics engineers think about these tradeoffs early.

Data flow matters

One of the most important parts of robot system design is understanding how information moves.

Sensor data enters the system.
Perception processes it.
Localisation updates pose estimates.
Planning generates paths.
Controllers generate motor commands.

If this flow becomes delayed, unstable, or disorganised, the robot behaves poorly.

Many robotics problems are actually system design problems.

Timing changes everything

Not every part of the robot operates at the same speed.

Motor control may run at very high frequencies.
Planning may run more slowly.
Mapping may update periodically.

Good system design separates tasks based on timing requirements.

This prevents slow processes from affecting critical control loops.

Modularity is important

Large robotics systems become difficult to maintain without modularity.

Modular systems allow components to be:

• tested independently

• replaced easily

• debugged more clearly

This is one reason ROS 2 became widely used.

It encourages distributed, modular system design.

Safety must exist everywhere

Safety is not added at the end.

Good system design considers:

• emergency stopping

• sensor failure

• communication loss

• unstable behaviour

• hardware faults

Robots operating in the real world must handle unexpected situations safely.

Why beginners struggle with system design

Beginners usually focus on individual components.

They ask:

Which algorithm should I use
Which sensor is best
Which model is most accurate

These questions matter.

But system design asks a different question:

How do all these parts work together reliably

That shift is important.

A simple way to think about robot system design

Robot system design is about structure.

Not only what the robot does.
But how the robot is organised internally.

Strong robots are not built from isolated features.

They are built from stable interactions between systems.

Why this skill matters

As robots become larger and more autonomous, system complexity increases quickly.

Strong engineers are valuable because they can:

• organise complexity

• design reliable architectures

• reason about interactions

• anticipate failures

This is what turns robotics from experimentation into engineering.

TLDR

Robot system design is the process of organising how robotic systems work together.

It includes sensing, computation, communication, timing, control, and safety.

Strong robotics engineering is not only about algorithms.
It is about designing stable systems that operate reliably in the real world.

Subscribe now

Hit reply: I read every email.

Programming.
Computer vision.
AI.
ROS 2.
Control theory.

These are important.

Subscribe now

But there is another skill that separates strong robotics engineers from everyone else.

Systems thinking.

Almost nobody talks about it directly.
Yet it affects everything.

What systems thinking actually means

Systems thinking is the ability to understand how parts interact.

Not just what each component does individually.

But how sensing affects localisation.
How localisation affects planning.
How planning affects control.
How timing affects all of them.

Strong robotics engineers think in connections, not isolated modules.

Why this matters so much in robotics

A robot is not one program.

It is many systems running together:

• sensors

• communication

• estimation

• planning

• control

• hardware

• timing

• safety

Most robotics problems appear between systems, not inside them.

That is why robotics debugging feels difficult.

The visible problem is often not the real problem.

A simple example

Imagine a robot drifting while navigating.

A beginner may adjust the planner.

But the real issue could be:

• wheel slip

• encoder calibration

• delayed sensor updates

• unstable localisation

Without systems thinking, you fix symptoms instead of causes.

Another overlooked skill: debugging calmly

Many beginners panic when systems fail.

They start changing random parameters.

Strong engineers slow down instead.

They isolate the system.
They observe behaviour.
They narrow possibilities step by step.

Robotics rewards structured debugging more than fast guessing.

Reading code is often more important than writing code

This surprises many students.

Large robotics projects already exist.

ROS 2 stacks.
Navigation systems.
SLAM frameworks.
Perception pipelines.

A major skill is understanding existing systems.

This means learning how to:

• trace data flow

• understand architecture

• identify dependencies

• navigate large codebases

Writing code matters.
Reading systems matters more than most people realise.

Understanding timing

Timing is another overlooked skill.

In robotics:

• delayed sensor updates matter

• unstable loop timing matters

• communication latency matters

A robot may fail even if the logic is technically correct.

Many beginners focus only on algorithms while ignoring timing behaviour.

Real robots cannot ignore time.

Working with imperfect information

Robotics operates under uncertainty.

Sensors are noisy.
Actuators are imperfect.
Environments change constantly.

Strong engineers learn to reason under uncertainty instead of expecting perfect inputs.

This mindset is important.

Why these skills are overlooked

Tutorials usually focus on visible outcomes.

Train this model.
Run this package.
Build this demo.

But industry robotics depends heavily on invisible engineering skills:

• debugging

• architecture

• estimation

• timing awareness

• systems thinking

These skills develop slowly through building and observing real systems.

A simple way to think about it

Beginner robotics focuses on features.

Strong robotics engineering focuses on interactions.

That shift changes everything.

What helped me most

Not memorising more algorithms.

Understanding:

• how systems connect

• where failures propagate

• how robots behave under real constraints

That understanding made robotics feel less chaotic.

TLDR

The robotics skill nobody talks about is systems thinking.

Strong robotics engineers understand interactions between sensing, localisation, planning, control, hardware, and timing.

They debug calmly.
They reason through systems.
They work comfortably with uncertainty.

Robotics becomes much easier once you stop viewing it as isolated code and start viewing it as connected systems.

Subscribe now

Hit reply: I read every email.

At first, it seems similar.

You write code.
You run systems.
You debug behaviour.

But very quickly, robotics starts feeling different.

Harder.
Slower.
More unpredictable.

Subscribe now

A project that looks simple can take weeks.
A bug can come from anywhere.
A system that worked yesterday suddenly behaves differently today.

This feeling is common.

There are real reasons why robotics feels harder than traditional software engineering.

The core difference

Software engineering usually operates inside controlled environments.

Robotics operates in the physical world.

The physical world is noisy, delayed, and unpredictable.

That changes everything.

Software bugs are usually isolated

In software engineering, bugs are often easier to trace.

A function fails.
An API breaks.
A database query is wrong.

Inputs are usually consistent.

In robotics, one problem spreads through the system.

A small sensor error affects localisation.
Localisation affects planning.
Planning affects control.
Control affects movement.

The visible problem may be far away from the real cause.

Robotics combines many disciplines

Software engineering mainly focuses on software systems.

Robotics combines:

• software

• hardware

• control

• sensing

• networking

• timing

• physics

You are not only writing code.

You are coordinating systems that interact with reality.

This increases complexity quickly.

The real world is imperfect

A simulator behaves consistently.

The real world does not.

Wheels slip.
Sensors drift.
Lighting changes.
Motors behave differently under load.

Even if your code is correct, the environment changes the outcome.

This is one of the biggest mental shifts in robotics.

Timing matters much more

In many software systems, small delays are acceptable.

In robotics, timing directly affects behaviour.

A delayed sensor update may destabilise localisation.
A delayed control loop may cause oscillation.
A delayed command may cause unsafe motion.

Robots must react continuously while the world changes around them.

Debugging is harder

Robotics bugs are often invisible.

The robot may fail because of:

• sensor noise

• calibration drift

• communication delays

• hardware limitations

• incorrect assumptions between systems

You cannot always see the problem directly.

This is why robotics debugging requires systems thinking.

Progress feels slower

In software engineering, you can often build and test quickly.

Robotics adds physical setup:

• hardware integration

• power management

• calibration

• safety checks

• deployment

This slows iteration.

At first, this feels frustrating.

Over time, you realise it is part of building reliable systems.

Why this difficulty is valuable

Robotics forces you to think differently.

You learn:

• system architecture

• uncertainty handling

• debugging across layers

• real world constraints

• tradeoffs between hardware and software

These skills are difficult to develop in purely virtual systems.

A simple way to think about it

Software engineering mostly controls digital systems.

Robotics controls physical systems through software.

That extra layer of reality creates complexity.

Why beginners feel overwhelmed

Many beginners assume they are struggling because they are not smart enough.

Usually, the problem is simpler.

Robotics genuinely contains more interacting systems than most fields.

Feeling confused early on is normal.

The field becomes clearer once you stop viewing robots as isolated programs and start viewing them as connected systems.

What helps most

Small projects.
Patience.
Systems thinking.

The goal is not to master everything immediately.

The goal is to slowly understand how the pieces connect.

That is when robotics starts becoming enjoyable instead of overwhelming.

TLDR

Robotics feels harder than software engineering because it combines software with the physical world.

Sensors fail.
Timing matters.
Hardware introduces uncertainty.
Bugs spread across systems.

Robotics is not only coding.
It is coordinating imperfect systems in real environments.

That complexity is what makes the field difficult and fascinating at the same time.

Subscribe now

Hit reply: I read every email.

Big names.
Big offices.
Big brands.

There is nothing wrong with that.

Subscribe now

But many students overlook something important.

Smaller robotics startups can sometimes teach you far more.

Especially early in your career.

The core difference

Large companies usually have structure.

Teams are specialised.
Responsibilities are narrow.
Processes are established.

Smaller startups operate differently.

People work across systems.
Problems change quickly.
Everyone contributes wherever needed.

This changes how you learn.

You see the full system

In a small robotics startup, you often work close to the entire robot.

You may touch:

• sensors

• ROS 2 nodes

• perception

• debugging

• hardware integration

• testing

• deployment

You start understanding how everything connects.

This is one of the fastest ways to develop systems thinking.

You learn by solving real problems

Smaller teams usually move quickly.

There is less separation between learning and doing.

You are not only observing.
You are contributing.

You may help debug an issue one day and test hardware the next.

This exposure accelerates growth.

You work closer to experienced engineers

In many startups, teams are small.

This means you often communicate directly with senior engineers, founders, or technical leads.

You see how decisions are made.

You learn:

• how tradeoffs are evaluated

• how systems are designed

• how debugging happens in real environments

That exposure is valuable.

You become comfortable with uncertainty

Startups change constantly.

Requirements shift.
Priorities evolve.
Systems break unexpectedly.

At first this feels chaotic.

Over time, it teaches adaptability.

This is important because real robotics rarely behaves like tutorials.

You understand constraints earlier

Large companies often hide complexity behind existing infrastructure.

Startups expose constraints directly.

You begin thinking about:

• power limitations

• timing issues

• hardware reliability

• deployment challenges

• compute tradeoffs

You learn what it takes to make robots work outside controlled demos.

You may contribute faster

In some larger companies, interns mainly observe.

In smaller teams, your contribution may affect real systems quickly.

This creates stronger learning loops.

You build something.
You test it.
You see the consequences immediately.

That experience builds confidence.

Why smaller companies feel less attractive at first

Students often compare logos instead of learning environments.

Large companies feel safer and more prestigious.

Smaller startups may feel uncertain.

But early career growth often comes from exposure and responsibility, not brand size.

This does not mean large companies are bad

Large robotics companies offer many advantages:

• strong mentorship structures

• mature engineering practices

• exposure to large scale systems

The point is not that one is always better.

The point is that smaller startups can offer deeper hands-on learning than many students expect.

A simple way to think about it

Large companies often optimise for scale.
Smaller startups often optimise for speed.

As a student, speed of learning matters a lot.

Why this matters early in your career

Early on, breadth is powerful.

Understanding how sensing connects to planning, how hardware affects software, and how debugging happens across systems makes you a stronger engineer later.

Smaller robotics startups often accelerate this understanding.

TLDR

Smaller robotics startups can provide faster and broader learning.

You often work closer to the full system, contribute earlier, and interact directly with experienced engineers.

Large companies teach structure.
Smaller startups often teach systems thinking and adaptability.

Both are valuable.

But students should not underestimate how much growth can happen inside small teams.

Subscribe now

Hit reply: I read every email.

You apply.
You wait.
Nothing happens.

After a while, it starts to feel personal.

Subscribe now

It is usually not.

Most of the time, there are simple reasons behind it.

If you understand those reasons, you can fix them.

The core idea

Getting a reply is not only about being qualified.

It is about being clear, relevant, and visible.

Recruiters do not spend much time on each application.

They scan quickly and decide whether to move forward.

If your application does not communicate value in that short time, it gets ignored.

Reason 1: Your application feels generic

Many students send the same resume everywhere.

The same projects.
The same description.
The same message.

From the recruiter’s side, it looks like:

This person is applying to everything.

That reduces interest.

How to fix it

Make small adjustments for each application.

If the company works on drones, highlight control or perception.

If they build warehouse robots, highlight navigation or system design.

Show that you understand what they do.

Reason 2: Your projects are not clear

You may have good projects.

But if they are not explained well, they do not help.

A recruiter does not have time to read code deeply.

If they cannot understand your project in a few seconds, they move on.

How to fix it

For each project, make it easy to scan:

• what you built

• what problem it solves

• how it works

• what you learned

Clarity matters more than complexity.

Reason 3: No visible signal of hands-on work

Robotics is a practical field.

If your profile shows only theory, courses, or certificates, it creates doubt.

Recruiters want to see that you can build and test systems.

How to fix it

Show even small projects.

A simple robot.
A simulation.
A perception pipeline.

You do not need advanced work.

You need evidence of building.

Reason 4: You rely only on job boards

Many students apply through large platforms and wait.

These platforms are crowded.

Your application competes with many others.

It is easy to get lost.

How to fix it

Use direct outreach.

Find engineers or teams working in areas that interest you.

Send short, clear messages.

Explain:

• who you are

• what you are learning

• why their work matters to you

This increases visibility.

Reason 5: Your profile is hard to understand quickly

If someone opens your profile and feels confused, they move on.

Too many tools.
Too many unrelated projects.
No clear direction.

This creates friction.

How to fix it

Keep it simple.

Show:

• your focus

• a few strong projects

• clear explanations

Make it easy to understand in seconds.

Reason 6: You apply too late

Some roles receive many applications quickly.

If you apply late, your application may not be seen.

How to fix it

Apply early when possible.

Follow companies and apply when roles open.

Reason 7: You stop too early

Many students apply to a few roles and then stop.

They assume silence means rejection of ability.

Often, it is just part of the process.

How to fix it

Treat applications as a process.

Apply consistently.
Improve after each attempt.
Adjust based on feedback.

A simple way to think about it

Your application should answer quickly:

What can this person build
How clearly do they think
Why are they relevant to this role

If these answers are visible, replies increase.

Why this feels difficult

It feels like you need to be perfect.

You do not.

You need to be clear, relevant, and consistent.

That is enough to stand out.

TLDR

You do not get replies because your application is unclear, generic, or not visible enough.

Make your work easy to understand.
Show real projects.
Tailor your applications.
Reach out directly.
Apply consistently.

Replies improve when signals are clear.

Subscribe now

Hit reply: I read every email.

They imagine someone carefully reading each line, opening every project, and analysing every decision.

That is not what happens.

In most cases, you get less than a minute.

Often, less than thirty seconds.

Subscribe now

In that short time, a recruiter is not trying to understand everything about you.

They are trying to decide one thing.

Should I look deeper or move on

The core idea

Recruiters do not search for perfection.

They search for signals.

Strong signals make them pause.
Weak signals make them move on.

Your goal is not to impress with volume.

Your goal is to make the right signals visible quickly.

The first impression

The first few seconds are visual.

Before reading deeply, recruiters notice:

• your headline

• your role or focus

• how clearly your profile is structured

If your profile feels confusing or unfocused, they move on.

If it feels clear, they continue.

Clarity creates trust.

Your direction

Very quickly, recruiters try to understand:

What kind of robotics person is this

Are you focused on:

• perception

• control

• embedded systems

• autonomy

• general robotics

You do not need to be highly specialised.

But you need to show some direction.

A clear direction is easier to evaluate than a scattered profile.

Your projects

Projects are one of the strongest signals.

But recruiters do not read everything.

They scan.

They look for:

• real systems, not only tutorials

• clear descriptions

• visible outcomes

• signs of hands-on work

A simple working robot with clear explanation is stronger than a complex project with no clarity.

Your thinking

This is often underestimated.

Recruiters look for signs that you understand systems.

They notice:

• how you describe problems

• how you explain solutions

• whether you mention tradeoffs

• whether you understand limitations

This shows maturity.

It tells them you can work in real environments, not only follow instructions.

Your GitHub

GitHub is often checked quickly.

They look for:

• organised repositories

• readable documentation

• meaningful project structure

They do not expect perfection.

They expect effort and clarity.

Messy repositories create doubt.
Clean ones create confidence.

Consistency over time

A single strong project helps.

But consistent activity is stronger.

Recruiters notice:

• regular commits

• ongoing learning

• gradual improvement

Consistency signals reliability.

What they ignore

Many students focus on things that matter less.

Long lists of tools.
Many certificates.
Complex jargon.

These do not stand out in a quick scan.

Clarity and evidence matter more.

A simple way to think about it

In thirty seconds, a recruiter asks:

Does this person build things
Does this person understand what they build
Does this person seem worth a deeper look

If the answer is yes, they continue.

Why students struggle

Students try to include everything.

They add too many details.
Too many tools.
Too many projects without explanation.

This creates noise.

Noise hides the signals that matter.

What actually works

A clear profile.
A few strong projects.
Simple explanations.
Visible progress.

That is enough to create interest.

TLDR

Recruiters do not read everything.
They scan for signals.

Show clear direction.
Highlight real projects.
Explain your thinking.
Keep everything easy to understand.

You do not need to be perfect.

You need to be clear and real.

Subscribe now

Hit reply: I read every email.

But then they get stuck.

What should I include?
How many projects do I need?
Does it need to look perfect?
What if my projects are simple?

Subscribe now

A good robotics portfolio is not about looking impressive.

It is about making it easy for someone to trust your ability.

That is the real goal.

The core idea

Companies are not only evaluating projects.

They are evaluating signals.

Your portfolio should answer three questions quickly:

Can this person build things
Can this person think clearly
Would this person be useful on a team

If your portfolio answers those questions, it works.

Show real projects, not only certificates

Certificates can help, but they are not enough.

Robotics is a practical field.

People want to see what you built, tested, or improved.

Even simple projects matter:

• line follower robot

• obstacle avoidance robot

• ROS 2 simulation project

• object detection pipeline

• robotic arm controller

• sensor fusion demo

• autonomous rover prototype

Small projects with clear explanations are stronger than empty claims.

Explain your thinking

Many students only upload code or photos.

That misses the most valuable part.

Explain:

• what problem you were solving

• how the system worked

• what decisions you made

• what went wrong

• what you learned

This shows engineering maturity.

Companies want to understand how you think, not only what you built.

Make it easy to scan

Hiring teams do not spend an hour on each portfolio.

Make your work easy to understand in minutes.

For each project include:

• short title

• one sentence summary

• tools used

• images or short demo

• link to code

• key takeaway

Clarity wins.

Use GitHub properly

A GitHub profile can be part of your portfolio, but only if it is usable.

Good repositories should have:

• clear README files

• setup steps

• project purpose

• screenshots or videos

• organised folders

• meaningful commit history

Messy repositories create doubt.

Clean repositories create trust.

Show range, not randomness

It helps to show different sides of robotics.

For example:

• one hardware project

• one software project

• one simulation project

• one perception or AI project

This shows adaptability.

But keep a theme.

Do not upload random, unrelated experiments with no explanation.

Include unfinished lessons

Not every project must be perfect.

If a project failed but taught you something valuable, share that clearly.

Real engineering includes debugging, redesign, and iteration.

That honesty can be more powerful than pretending everything worked.

Where to host your portfolio

Keep it simple.

You can use:

• personal website

• GitHub profile

• Notion page

• LinkedIn featured section

• PDF portfolio

The platform matters less than clarity and quality.

What gets replies

Portfolios get replies when they feel real.

Real projects.
Real explanations.
Real progress.
Real curiosity.

A polished design helps, but substance matters more.

Why students struggle

Many students wait until they have advanced projects.

That delay is unnecessary.

Your portfolio should grow with you.

Start with what you have now.
Improve it over time.

Momentum is more valuable than perfection.

A simple formula

Build something.
Document it clearly.
Share what you learned.
Repeat.

That is how strong portfolios are built.

TLDR

A robotics portfolio should make trust easy.

Show real projects.
Explain your thinking.
Keep it easy to scan.
Use GitHub well.
Show progress, not perfection.

You do not need the best projects.

You need clear evidence that you can learn and build.

Subscribe now

Hit reply: I read every email.

It is getting the first opportunity.

Many students assume internships go only to top universities, people with connections, or candidates who already know everything.

Subscribe now

That is not how it works.

Most companies are looking for something simpler.

They want people who are curious, reliable, and able to learn quickly.

If you approach the search the right way, your chances improve a lot.

The core idea

Do not search for internships as if you are collecting job listings.

Search for teams that are building interesting things.

This mindset changes everything.

Instead of asking:

Where are openings

Ask:

Who is building robots I want to learn from

That leads to better opportunities and better applications.

Know the types of robotics companies

Robotics is broad.

Internships can exist in:

• autonomous vehicles

• drones

• warehouse automation

• industrial robotics

• medical robotics

• service robots

• agriculture robotics

• humanoids

• defence and aerospace

• robotics software tools

When students search only for companies with the word robotics in the title, they miss many opportunities.

Many companies build robotic systems without branding themselves that way.

Build signals before you apply

A resume alone is rarely enough.

You need visible proof that you care about the field.

This can come from:

• small robotics projects

• GitHub repositories

• simulation work

• ROS 2 practice

• technical posts

• coursework

• competition experience

You do not need a perfect portfolio.

You need evidence of momentum.

Use targeted outreach

Many internships are never found through large job boards.

Reach out directly.

Find engineers, founders, or hiring managers working in areas that interest you.

Write short, respectful messages.

Explain:

• who you are

• what you are learning

• why their work interests you

• how you would like to contribute or learn

Good outreach is specific and genuine.

Start smaller than you think

Many students apply only to famous companies.

This creates unnecessary competition.

Smaller startups, research labs, local automation firms, and niche robotics teams often provide better learning.

You may get more responsibility, more exposure, and closer mentorship.

Your first internship does not need to be prestigious.

It needs to be real.

Tailor every application

Do not send the same application everywhere.

If the company works on drones, highlight controls, embedded systems, or perception.

If they build warehouse robots, highlight navigation, software, or systems thinking.

Show that you understand what they do.

Generic applications are easy to ignore.

Be ready for practical conversations

Robotics interviews often test thinking more than memorisation.

You may be asked:

How would you design a simple robot
How would you debug a failing sensor
How would you make navigation safer
How would you structure software for multiple components

They want to see how you think through systems.

Use your learning journey as an advantage

You do not need years of experience.

If you are actively learning, building, and sharing progress, that matters.

Companies know interns are still developing.

They often care more about attitude, consistency, and problem-solving than polished expertise.

Why students struggle

Many students wait until they feel ready.

They delay applying until they know more tools, finish more projects, or feel more confident.

This slows progress.

Internships are part of learning, not something that happens after learning is complete.

A simple strategy

Learn publicly.
Build small projects.
Research companies.
Reach out thoughtfully.
Apply consistently.
Improve after each conversation.

That process works better than waiting for the perfect moment.

TLDR

Finding a robotics internship is not only about job boards.

Look for teams doing meaningful work.
Build visible proof of interest.
Reach out directly.
Apply to smaller companies, too.
Tailor your applications and be ready to think through real problems.

You do not need to know everything.

You need to start.

Subscribe now

Hit reply: I read every email.