Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

e14sbhargav — Thu, 13 Aug 2026 12:18:18 GMT

Current Revision posted to Documents by e14sbhargav on 8/13/2026 12:18:18 PM

Join Miloš Rašić as he builds a differential-drive mobile robot and explores the fundamentals of mobile robotics. In this instalment of the Introduction to Robotics series, he brings together electronics, mechanical design, motor control, encoder feedback, PID tuning, wireless communications and sensor-driven behaviours to create a robot capable of navigating a surface and mapping its edges. Along the way, Miloš demonstrates how wheel encoders enable speed control and odometry, how infrared sensors can be used as cliff detectors, and how a simple mapping algorithm can turn sensor data into useful environmental information. The project also highlights practical challenges including battery brownouts, logic-level compatibility, controller tuning and real-world testing. Whether you're building your first robot or looking to understand how mobile robotics systems are put together, this project provides a hands-on introduction to the concepts that underpin larger autonomous platforms, and you can find the supporting files below

Time to Build a Robot!

players.brightcove.net/.../index.html

Throughout this Introduction to Robotics series, Miloš Rašić has gradually built the knowledge needed to design, build and control robotic systems. It began with the fundamentals of electronics, sensors, actuators, CAD and mechanical design in Building the Foundations of Your First Robot, before moving into closed-loop control, motion profiles and robotic software concepts in PID Control, Motion Profiles and ROS Explained. The previous instalment then applied many of those concepts to a complete robot arm in Building and Programming a SCARA Industrial Robot Arm.

For the fourth part of the series, the focus shifts to one of the most recognisable categories of robotics: the mobile robot.

Unlike a robot arm that operates from a fixed base, a mobile robot must move through its environment, react to what it senses, maintain control of its motion and attempt to understand where it is. Even the simplest mobile robot quickly introduces concepts such as locomotion, wheel odometry, sensor-driven behaviours and environmental mapping.

The platform Miloš develops combines many of the ideas explored throughout the series into a compact differential-drive robot built around a Raspberry Pi Pico 2 W, geared motors with integrated encoders, infrared cliff sensors, wireless communications and a custom firmware and GUI stack.

“This was for people that were making their first robot and just wanted to see something move.”

Rather than introducing advanced SLAM systems, sensor fusion stacks or computer vision pipelines, the project focuses on the core building blocks that underpin mobile robotics. The result is a platform that remains approachable while still exposing many of the same challenges encountered in larger autonomous systems.

Bringing the Previous Parts Together

This project is the fourth instalment of the series where every subsystem relies on concepts already introduced.

Building the Foundations of Your First Robot - An Introduction to Robotics introduced the core hardware elements such as sensors, motors, microcontrollers, CAD design and manufacturing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics explored feedback systems, control loops and software structures used to regulate motion.
Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics demonstrated how those ideas could be combined into a complete robotic system with embedded firmware and a graphical user interface.

In this mobile robot platform, all of those concepts return. Motors require drivers, sensors require interpretation, encoder feedback must be processed, software needs to communicate with hardware, and control loops keep the system stable. The key difference is that the robot is no longer bolted to a workbench. It must move through the world while attempting to keep track of its own position.

Locomotion: How Do Mobile Robots Move?

Miloš begins by introducing locomotion, the ability of a robot to move from one place to another.

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

Robots can move in many different ways. Wheeled robots, walking robots, tracked vehicles and bio-inspired machines all fall under the broad category of locomotion. Since the objective of this project is to introduce the fundamentals of mobile robotics without adding unnecessary complexity, Miloš focuses on wheeled robots.

Even then, there are multiple approaches. A car changes direction by altering the angle of its steering wheels. Some robots use tracks while others employ more specialised wheel arrangements such as mecanum wheels. For this platform, the chosen solution is differential drive.

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot uses two powered drive wheels and a third passive support wheel, normally a caster. Steering is achieved entirely through the relative speed of the left and right wheels.

If both wheels rotate at the same speed, the robot travels in a straight line. If one wheel turns faster than the other, the robot follows a curve. If the wheels rotate in opposite directions, the robot can rotate on the spot.

The design keeps moving parts to a minimum while still demonstrating many important mobile robotics concepts.

“The vacuum robot is the prime example of a differential drive robot.”

That comparison is particularly fitting because robot vacuum cleaners use many of the same underlying principles explored in this project: differential drive, wheel feedback, environmental sensing and autonomous movement.

Selecting the Hardware

With the robot architecture decided, the next step was selecting the hardware.

The drive system is built around two DFROBOT geared DC motors with integrated encoders. The gearbox reduces the motor speed to something useful for driving a robot, while the encoder provides rotational feedback.

These encoders are important because they allow the robot to measure wheel speed and estimate wheel position. Without them, the firmware could only command a motor and hope it behaved as expected. With encoder feedback, movement can be measured, controlled and visualised.

“This here is an encoder.”

For anyone unfamiliar with encoders and feedback systems, the element14 Learning Center article Magnetic Encoders provides useful background on how rotational position and velocity can be measured electronically.

The motors are controlled through a DFROBOT dual motor driver. The microcontroller generates a direction signal and a PWM signal for each motor, while the motor driver handles the current required by the motors themselves.

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply)
//      battery    --> VM            (motor supply)

While deceptively simple, this arrangement introduces readers to one of the most common motor-control structures used throughout robotics.

Those wanting a deeper understanding of motor drive electronics can explore Motor Control: Motor Drive Control for Makers, which covers PWM, motor drivers and motor control fundamentals in more detail.

The Raspberry Pi Pico 2 W and Power System

To coordinate the robot's sensors, motors and communications, Miloš selected a Raspberry Pi Pico 2 W.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The Pico handles the embedded side of the project. It reads sensor data, processes encoder counts, executes the PID control loops, communicates with the GUI and generates motor commands.

This is another point where concepts from earlier parts of the series return. The microcontroller acts as the bridge between the electronic hardware and the software logic driving the robot's behaviour.

An interesting challenge emerged from the encoder hardware. The motor encoders operate using 5 V logic, while the Pico uses 3.3 V logic.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

A simple level-shifting circuit is therefore required between the encoder outputs and the microcontroller inputs. This kind of practical electrical consideration appears frequently in real robotics projects and is often overlooked when looking only at block diagrams.

The robot itself is powered from a four-cell AA battery pack, supplying approximately 6 V for the motors and supporting circuitry. A regulator generates the required logic voltage for the Pico and sensors.

Miloš jokingly highlights another very real robotics issue: battery quality.

If the supply voltage drops too far under load, motors may continue turning while the microcontroller resets unexpectedly, producing brownouts and unpredictable behaviour.

Power distribution often receives less attention than software or mechanics, but it has a huge influence on reliability. Readers interested in that topic may find Power Essentials for Makers useful supplementary reading.

Cliff Detection Instead of Obstacle Detection

Many consumer robots rely on bump sensors, cameras or LiDAR to detect obstacles. Rather than attempting to build a complete navigation system, Miloš deliberately simplifies the sensing challenge.

The robot uses five downward-facing infrared sensors as cliff detectors.

“Instead of detecting walls we will detect cliffs.”

This changes the problem from obstacle avoidance to edge detection. Rather than navigating around furniture, the robot explores a raised surface and attempts to identify where the surface ends.

The approach is particularly useful for demonstrating how sensor information can directly drive robotic behaviour without requiring complex perception systems.

The firmware includes logic specifically designed around this sensor arrangement.

// On a downward-facing cliff sensor a set bit means
// "this sensor SEES THE FLOOR".
// Danger is the absence of floor.

#define IR_CLIFFS(mask) ((uint8_t)((~(mask)) & IR_ALL_BITS))

The accompanying comment in the firmware highlights a surprisingly common mistake.

// Getting that backwards is not a cosmetic bug:
// it produces a robot that refuses to move on solid
// ground and drives happily over a cliff.

It is exactly the kind of observation that comes from testing on physical hardware rather than simulation.

Designing the Chassis

With the electronics established, attention shifted towards the mechanical design.

Miloš created the platform in Fusion 360 and structured it around a simple differential-drive layout consisting of two powered wheels and a caster.

“We’re going to drop into Fusion 360, do some CAD design.”

The project is intentionally straightforward so that readers can recreate it even if they do not have access to the exact same fabrication tools.

While the published design uses 3D-printed components, the robot could be built from much simpler materials. The important requirement is maintaining alignment between the drive wheels.

If the wheels are not parallel, the robot will naturally drift and produce misleading results during testing.

That lesson mirrors many industrial robotics projects: elegant software cannot compensate indefinitely for poor mechanical fundamentals.

Firmware, Communications and Software Architecture

The software is split into two major pieces. The first is embedded firmware running on the Pico. The second is a desktop GUI used for control, monitoring and tuning.

Readers who followed the SCARA robot arm build will recognise a very similar development workflow. Once again, Miloš combines embedded software and a graphical control environment into a single ecosystem.

The firmware is deliberately modular.

// Everything the host can ask for goes through here,
// so Serial and WiFi are guaranteed to behave identically.

This ensures that commands behave the same whether they are sent through USB Serial or over Wi-Fi.

The firmware also uses movement concepts familiar to anyone who has worked with CNC machines or 3D printers.

// Modal state (G90/G91, the last F,
// the programmed wheel target) lives here
// rather than in the controller.

The resulting system is flexible enough for interactive testing while remaining structured enough for more advanced automation later on.

Applying PID Control to a Real Robot

The theory behind PID control was explored previously in PID Control, Motion Profiles and ROS Explained. Rather than revisiting the mathematics, this project demonstrates how those concepts are applied to a mobile robot.

Each wheel uses encoder feedback to regulate speed through a closed-loop controller.

// SPEED loop (inner): error in mm/s -> output in duty

#define SPD_KP 0.0015f
#define SPD_KI 0.0080f

The GUI exposes tuning controls, making it possible to observe how the robot responds as controller values change.

Miloš demonstrates the practical tuning process by examining how quickly the wheel reaches its target speed. A response that is too slow typically indicates insufficient proportional gain. Increasing Kp improves responsiveness, but pushing it too far can create oscillation and instability.

Those behaviours become immediately visible when real motors, gearboxes, batteries and sensors enter the equation. The project therefore serves as a practical continuation of the PID concepts introduced earlier in the series, showing what they look like when attached to a physical robot rather than a simplified example. One of the biggest conceptual differences between this project and the earlier SCARA robot arm is localisation. A robot arm operates from a known position. Its joints move relative to a fixed base and its location in the world remains constant.

A mobile robot is different. Once it begins moving, it has to estimate where it is. This project deliberately avoids advanced localisation systems such as visual SLAM or sensor fusion. Instead, the platform introduces a simpler concept: wheel odometry.

By measuring wheel rotation using encoders, the robot can estimate how far it has travelled and build a rough picture of its movement.

“We are only here calculating where it is based on the encoder positions.”

While not perfectly accurate, odometry provides a powerful introduction to localisation and forms the basis of countless robotics systems.

Creating a Simple Mapping Behaviour

Once the platform could drive reliably and the sensors were functioning correctly, it was time to make the robot perform a task.

The chosen exercise was mapping the edge of a raised surface.

The mapping algorithm intentionally remains simple. Whenever a cliff sensor detects an edge, the robot reverses and changes direction. If the centre sensor detects a head-on edge, the robot performs a more substantial manoeuvre before continuing.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour is significant because it combines every major subsystem.

The mechanical design determines how the robot moves.
The motors execute the movement.
The encoders provide feedback.
The PID loops regulate motion.
The sensors detect the environment.
The algorithm determines how the robot reacts.

The GUI then visualises the results.

As the robot continues exploring, the triggered cliff detections begin forming a representation of the table edge.

“It’s forming a rather nice point cloud around the edges of the table.”

The robot is not creating a complete map in the modern SLAM sense, but it does demonstrate how movement and sensing can be combined to generate useful environmental information.

What Beginners Should Focus On and Further Learning on element14 Community

One of the most useful aspects of this project is that it intentionally avoids overwhelming complexity.

Rather than introducing every possible robotics concept at once, Miloš focuses on a small number of ideas and demonstrates how they fit together.

Differential-drive locomotion.
Motor control and motor drivers.
Wheel encoders.
PID speed regulation.
Microcontroller-based firmware.
Infrared sensing.
Wireless communications.
Simple mapping behaviour.
Basic odometry.

Along the way, readers also see the less glamorous aspects of robot development: wiring issues, logic-level compatibility, battery behaviour, sensor interpretation, wheel alignment and controller tuning. Those are often the challenges that consume the most development time on real projects. Readers wanting to explore the wider Introduction to Robotics series and related topics can continue with:

Final Thoughts

As the fourth instalment of the Introduction to Robotics series, this project acts as a bridge between foundational robotics theory and the challenges of mobile robotics.

The robot combines electronics, mechanical design, feedback control, embedded software and environmental sensing into a platform that is simple enough to understand yet capable enough to demonstrate genuine robotics concepts.

By the end of the project, the robot can drive, regulate its wheel speed, detect table edges, estimate its movement, visualise sensor data and build a rough representation of its surroundings.

Those capabilities may appear straightforward, but together they form the basis of a huge number of robotic systems.

“I would love to explore more complex robotics projects with you.”

Whether the next step is odometry improvements, more advanced mapping, ROS integration, navigation algorithms, sensor fusion or entirely new robot architectures, this platform provides a practical foundation on which those future topics can be built.

Supporting Files and Links

- Episode 727 Resource Files - Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

Bill of Materials / Parts Used

Product Name	Manufacturer	Quantity	Buy Kit
DFROBOT Motor	DFROBOT	2	Buy Now
DFROBOT Motor Driver	DFROBOT	1	Buy Now
Raspberry Pi Pico 2W	RASPBERRY PI	1	Buy Now
IR Sensor	SEEED STUDIO	5	Buy Now
Wheel	DFROBOT	2	Buy Now

Additional Parts

Product Name	Manufacturer	Quantity
AA battery holder		4
M3 machine screws
Small caster wheel
AA batteries		4
Perfboard and wires

Tags: embedded robotics programming, autonomous robot project, infrared cliff sensors, introduction to robotics, robotics for beginners, raspberry pi pico 2 w robot, robot wheel encoders, robot motor driver, wheel odometry, mobile robot platform, pid motor control, mobile robot mapping, e14presents_milosrasic, wireless robot control, friday_release, differential drive robot, diy robot build

Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

cstanton — Thu, 13 Aug 2026 12:18:18 GMT

Revision 7 posted to Documents by cstanton on 8/13/2026 12:18:18 PM

Time to Build a Robot!

players.brightcove.net/.../index.html

For the fourth part of the series, the focus shifts to one of the most recognisable categories of robotics: the mobile robot.

“This was for people that were making their first robot and just wanted to see something move.”

Bringing the Previous Parts Together

This project is the fourth instalment of the series where every subsystem relies on concepts already introduced.

Building the Foundations of Your First Robot - An Introduction to Robotics introduced the core hardware elements such as sensors, motors, microcontrollers, CAD design and manufacturing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics explored feedback systems, control loops and software structures used to regulate motion.
Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics demonstrated how those ideas could be combined into a complete robotic system with embedded firmware and a graphical user interface.

Locomotion: How Do Mobile Robots Move?

Miloš begins by introducing locomotion, the ability of a robot to move from one place to another.

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot uses two powered drive wheels and a third passive support wheel, normally a caster. Steering is achieved entirely through the relative speed of the left and right wheels.

The design keeps moving parts to a minimum while still demonstrating many important mobile robotics concepts.

“The vacuum robot is the prime example of a differential drive robot.”

Selecting the Hardware

With the robot architecture decided, the next step was selecting the hardware.

“This here is an encoder.”

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply)
//      battery    --> VM            (motor supply)

While deceptively simple, this arrangement introduces readers to one of the most common motor-control structures used throughout robotics.

The Raspberry Pi Pico 2 W and Power System

To coordinate the robot's sensors, motors and communications, Miloš selected a Raspberry Pi Pico 2 W.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The Pico handles the embedded side of the project. It reads sensor data, processes encoder counts, executes the PID control loops, communicates with the GUI and generates motor commands.

An interesting challenge emerged from the encoder hardware. The motor encoders operate using 5 V logic, while the Pico uses 3.3 V logic.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

Miloš jokingly highlights another very real robotics issue: battery quality.

If the supply voltage drops too far under load, motors may continue turning while the microcontroller resets unexpectedly, producing brownouts and unpredictable behaviour.

Cliff Detection Instead of Obstacle Detection

Many consumer robots rely on bump sensors, cameras or LiDAR to detect obstacles. Rather than attempting to build a complete navigation system, Miloš deliberately simplifies the sensing challenge.

The robot uses five downward-facing infrared sensors as cliff detectors.

“Instead of detecting walls we will detect cliffs.”

This changes the problem from obstacle avoidance to edge detection. Rather than navigating around furniture, the robot explores a raised surface and attempts to identify where the surface ends.

The approach is particularly useful for demonstrating how sensor information can directly drive robotic behaviour without requiring complex perception systems.

The firmware includes logic specifically designed around this sensor arrangement.

// On a downward-facing cliff sensor a set bit means
// "this sensor SEES THE FLOOR".
// Danger is the absence of floor.

#define IR_CLIFFS(mask) ((uint8_t)((~(mask)) & IR_ALL_BITS))

The accompanying comment in the firmware highlights a surprisingly common mistake.

// Getting that backwards is not a cosmetic bug:
// it produces a robot that refuses to move on solid
// ground and drives happily over a cliff.

It is exactly the kind of observation that comes from testing on physical hardware rather than simulation.

Designing the Chassis

With the electronics established, attention shifted towards the mechanical design.

Miloš created the platform in Fusion 360 and structured it around a simple differential-drive layout consisting of two powered wheels and a caster.

“We’re going to drop into Fusion 360, do some CAD design.”

The project is intentionally straightforward so that readers can recreate it even if they do not have access to the exact same fabrication tools.

While the published design uses 3D-printed components, the robot could be built from much simpler materials. The important requirement is maintaining alignment between the drive wheels.

If the wheels are not parallel, the robot will naturally drift and produce misleading results during testing.

That lesson mirrors many industrial robotics projects: elegant software cannot compensate indefinitely for poor mechanical fundamentals.

Firmware, Communications and Software Architecture

The software is split into two major pieces. The first is embedded firmware running on the Pico. The second is a desktop GUI used for control, monitoring and tuning.

The firmware is deliberately modular.

// Everything the host can ask for goes through here,
// so Serial and WiFi are guaranteed to behave identically.

This ensures that commands behave the same whether they are sent through USB Serial or over Wi-Fi.

The firmware also uses movement concepts familiar to anyone who has worked with CNC machines or 3D printers.

// Modal state (G90/G91, the last F,
// the programmed wheel target) lives here
// rather than in the controller.

The resulting system is flexible enough for interactive testing while remaining structured enough for more advanced automation later on.

Applying PID Control to a Real Robot

Each wheel uses encoder feedback to regulate speed through a closed-loop controller.

// SPEED loop (inner): error in mm/s -> output in duty

#define SPD_KP 0.0015f
#define SPD_KI 0.0080f

The GUI exposes tuning controls, making it possible to observe how the robot responds as controller values change.

By measuring wheel rotation using encoders, the robot can estimate how far it has travelled and build a rough picture of its movement.

“We are only here calculating where it is based on the encoder positions.”

While not perfectly accurate, odometry provides a powerful introduction to localisation and forms the basis of countless robotics systems.

Creating a Simple Mapping Behaviour

Once the platform could drive reliably and the sensors were functioning correctly, it was time to make the robot perform a task.

The chosen exercise was mapping the edge of a raised surface.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour is significant because it combines every major subsystem.

The mechanical design determines how the robot moves.
The motors execute the movement.
The encoders provide feedback.
The PID loops regulate motion.
The sensors detect the environment.
The algorithm determines how the robot reacts.

The GUI then visualises the results.

As the robot continues exploring, the triggered cliff detections begin forming a representation of the table edge.

“It’s forming a rather nice point cloud around the edges of the table.”

The robot is not creating a complete map in the modern SLAM sense, but it does demonstrate how movement and sensing can be combined to generate useful environmental information.

What Beginners Should Focus On and Further Learning on element14 Community

One of the most useful aspects of this project is that it intentionally avoids overwhelming complexity.

Rather than introducing every possible robotics concept at once, Miloš focuses on a small number of ideas and demonstrates how they fit together.

Differential-drive locomotion.
Motor control and motor drivers.
Wheel encoders.
PID speed regulation.
Microcontroller-based firmware.
Infrared sensing.
Wireless communications.
Simple mapping behaviour.
Basic odometry.

Final Thoughts

As the fourth instalment of the Introduction to Robotics series, this project acts as a bridge between foundational robotics theory and the challenges of mobile robotics.

By the end of the project, the robot can drive, regulate its wheel speed, detect table edges, estimate its movement, visualise sensor data and build a rough representation of its surroundings.

Those capabilities may appear straightforward, but together they form the basis of a huge number of robotic systems.

“I would love to explore more complex robotics projects with you.”

Supporting Files and Links

- Episode 727 Resource Files - Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

Bill of Materials / Parts Used

Product Name	Manufacturer	Quantity	Buy Kit
DFROBOT Motor	DFROBOT	2	Buy Now
DFROBOT Motor Driver	DFROBOT	1	Buy Now
Raspberry Pi Pico 2W	RASPBERRY PI	1	Buy Now
IR Sensor	SEEED STUDIO	5	Buy Now
Wheel	DFROBOT	2	Buy Now

Additional Parts

Product Name	Manufacturer	Quantity
AA battery holder		4
M3 machine screws
Small caster wheel
AA batteries		4
Perfboard and wires

Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

cstanton — Thu, 13 Aug 2026 12:17:31 GMT

Revision 6 posted to Documents by cstanton on 8/13/2026 12:17:31 PM

Time to Build a Robot!

players.brightcove.net/.../index.html

For the fourth part of the series, the focus shifts to one of the most recognisable categories of robotics: the mobile robot.

“This was for people that were making their first robot and just wanted to see something move.”

Bringing the Previous Parts Together

This project is the fourth instalment of the series where every subsystem relies on concepts already introduced.

Building the Foundations of Your First Robot - An Introduction to Robotics introduced the core hardware elements such as sensors, motors, microcontrollers, CAD design and manufacturing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics explored feedback systems, control loops and software structures used to regulate motion.
Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics demonstrated how those ideas could be combined into a complete robotic system with embedded firmware and a graphical user interface.

Locomotion: How Do Mobile Robots Move?

Miloš begins by introducing locomotion, the ability of a robot to move from one place to another.

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot uses two powered drive wheels and a third passive support wheel, normally a caster. Steering is achieved entirely through the relative speed of the left and right wheels.

The design keeps moving parts to a minimum while still demonstrating many important mobile robotics concepts.

“The vacuum robot is the prime example of a differential drive robot.”

Selecting the Hardware

With the robot architecture decided, the next step was selecting the hardware.

“This here is an encoder.”

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply)
//      battery    --> VM            (motor supply)

While deceptively simple, this arrangement introduces readers to one of the most common motor-control structures used throughout robotics.

The Raspberry Pi Pico 2 W and Power System

To coordinate the robot's sensors, motors and communications, Miloš selected a Raspberry Pi Pico 2 W.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The Pico handles the embedded side of the project. It reads sensor data, processes encoder counts, executes the PID control loops, communicates with the GUI and generates motor commands.

An interesting challenge emerged from the encoder hardware. The motor encoders operate using 5 V logic, while the Pico uses 3.3 V logic.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

Miloš jokingly highlights another very real robotics issue: battery quality.

If the supply voltage drops too far under load, motors may continue turning while the microcontroller resets unexpectedly, producing brownouts and unpredictable behaviour.

Cliff Detection Instead of Obstacle Detection

Many consumer robots rely on bump sensors, cameras or LiDAR to detect obstacles. Rather than attempting to build a complete navigation system, Miloš deliberately simplifies the sensing challenge.

The robot uses five downward-facing infrared sensors as cliff detectors.

“Instead of detecting walls we will detect cliffs.”

This changes the problem from obstacle avoidance to edge detection. Rather than navigating around furniture, the robot explores a raised surface and attempts to identify where the surface ends.

The approach is particularly useful for demonstrating how sensor information can directly drive robotic behaviour without requiring complex perception systems.

The firmware includes logic specifically designed around this sensor arrangement.

// On a downward-facing cliff sensor a set bit means
// "this sensor SEES THE FLOOR".
// Danger is the absence of floor.

#define IR_CLIFFS(mask) ((uint8_t)((~(mask)) & IR_ALL_BITS))

The accompanying comment in the firmware highlights a surprisingly common mistake.

// Getting that backwards is not a cosmetic bug:
// it produces a robot that refuses to move on solid
// ground and drives happily over a cliff.

It is exactly the kind of observation that comes from testing on physical hardware rather than simulation.

Designing the Chassis

With the electronics established, attention shifted towards the mechanical design.

Miloš created the platform in Fusion 360 and structured it around a simple differential-drive layout consisting of two powered wheels and a caster.

“We’re going to drop into Fusion 360, do some CAD design.”

The project is intentionally straightforward so that readers can recreate it even if they do not have access to the exact same fabrication tools.

While the published design uses 3D-printed components, the robot could be built from much simpler materials. The important requirement is maintaining alignment between the drive wheels.

If the wheels are not parallel, the robot will naturally drift and produce misleading results during testing.

That lesson mirrors many industrial robotics projects: elegant software cannot compensate indefinitely for poor mechanical fundamentals.

Firmware, Communications and Software Architecture

The software is split into two major pieces. The first is embedded firmware running on the Pico. The second is a desktop GUI used for control, monitoring and tuning.

The firmware is deliberately modular.

// Everything the host can ask for goes through here,
// so Serial and WiFi are guaranteed to behave identically.

This ensures that commands behave the same whether they are sent through USB Serial or over Wi-Fi.

The firmware also uses movement concepts familiar to anyone who has worked with CNC machines or 3D printers.

// Modal state (G90/G91, the last F,
// the programmed wheel target) lives here
// rather than in the controller.

The resulting system is flexible enough for interactive testing while remaining structured enough for more advanced automation later on.

Applying PID Control to a Real Robot

Each wheel uses encoder feedback to regulate speed through a closed-loop controller.

// SPEED loop (inner): error in mm/s -> output in duty

#define SPD_KP 0.0015f
#define SPD_KI 0.0080f

The GUI exposes tuning controls, making it possible to observe how the robot responds as controller values change.

By measuring wheel rotation using encoders, the robot can estimate how far it has travelled and build a rough picture of its movement.

“We are only here calculating where it is based on the encoder positions.”

While not perfectly accurate, odometry provides a powerful introduction to localisation and forms the basis of countless robotics systems.

Creating a Simple Mapping Behaviour

Once the platform could drive reliably and the sensors were functioning correctly, it was time to make the robot perform a task.

The chosen exercise was mapping the edge of a raised surface.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour is significant because it combines every major subsystem.

The mechanical design determines how the robot moves.
The motors execute the movement.
The encoders provide feedback.
The PID loops regulate motion.
The sensors detect the environment.
The algorithm determines how the robot reacts.

The GUI then visualises the results.

As the robot continues exploring, the triggered cliff detections begin forming a representation of the table edge.

“It’s forming a rather nice point cloud around the edges of the table.”

The robot is not creating a complete map in the modern SLAM sense, but it does demonstrate how movement and sensing can be combined to generate useful environmental information.

What Beginners Should Focus On and Further Learning on element14 Community

One of the most useful aspects of this project is that it intentionally avoids overwhelming complexity.

Rather than introducing every possible robotics concept at once, Miloš focuses on a small number of ideas and demonstrates how they fit together.

Differential-drive locomotion.
Motor control and motor drivers.
Wheel encoders.
PID speed regulation.
Microcontroller-based firmware.
Infrared sensing.
Wireless communications.
Simple mapping behaviour.
Basic odometry.

Final Thoughts

As the fourth instalment of the Introduction to Robotics series, this project acts as a bridge between foundational robotics theory and the challenges of mobile robotics.

By the end of the project, the robot can drive, regulate its wheel speed, detect table edges, estimate its movement, visualise sensor data and build a rough representation of its surroundings.

Those capabilities may appear straightforward, but together they form the basis of a huge number of robotic systems.

“I would love to explore more complex robotics projects with you.”

Supporting Files and Links

- Episode 727 Resource Files - Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

Bill of Materials / Parts Used

Product Name	Manufacturer	Quantity	Buy Kit
DFROBOT Motor	DFROBOT	2	Buy Now
DFROBOT Motor Driver	DFROBOT	1	Buy Now
Raspberry Pi Pico 2W	RASPBERRY PI	1	Buy Now
NOT THE SAME FORMFACTOR - IR Sensor	SEEED STUDIO	5	Buy Now
NOT USED IN VIDEO - Wheel	DFROBOT	2	Buy Now

Additional Parts

Product Name	Manufacturer	Quantity
AA battery holder		4
M3 machine screws
Small caster wheel
AA batteries		4
Perfboard and wires

Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

cstanton — Thu, 13 Aug 2026 11:51:30 GMT

Revision 5 posted to Documents by cstanton on 8/13/2026 11:51:30 AM

Time to Build a Robot!

players.brightcove.net/.../index.html

For the fourth part of the series, the focus shifts to one of the most recognisable categories of robotics: the mobile robot.

“This was for people that were making their first robot and just wanted to see something move.”

Bringing the Previous Parts Together

This project is the fourth instalment of the series where every subsystem relies on concepts already introduced.

Building the Foundations of Your First Robot - An Introduction to Robotics introduced the core hardware elements such as sensors, motors, microcontrollers, CAD design and manufacturing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics explored feedback systems, control loops and software structures used to regulate motion.
Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics demonstrated how those ideas could be combined into a complete robotic system with embedded firmware and a graphical user interface.

Locomotion: How Do Mobile Robots Move?

Miloš begins by introducing locomotion, the ability of a robot to move from one place to another.

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot uses two powered drive wheels and a third passive support wheel, normally a caster. Steering is achieved entirely through the relative speed of the left and right wheels.

The design keeps moving parts to a minimum while still demonstrating many important mobile robotics concepts.

“The vacuum robot is the prime example of a differential drive robot.”

Selecting the Hardware

With the robot architecture decided, the next step was selecting the hardware.

“This here is an encoder.”

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply)
//      battery    --> VM            (motor supply)

While deceptively simple, this arrangement introduces readers to one of the most common motor-control structures used throughout robotics.

The Raspberry Pi Pico 2 W and Power System

To coordinate the robot's sensors, motors and communications, Miloš selected a Raspberry Pi Pico 2 W.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The Pico handles the embedded side of the project. It reads sensor data, processes encoder counts, executes the PID control loops, communicates with the GUI and generates motor commands.

An interesting challenge emerged from the encoder hardware. The motor encoders operate using 5 V logic, while the Pico uses 3.3 V logic.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

Miloš jokingly highlights another very real robotics issue: battery quality.

If the supply voltage drops too far under load, motors may continue turning while the microcontroller resets unexpectedly, producing brownouts and unpredictable behaviour.

Cliff Detection Instead of Obstacle Detection

Many consumer robots rely on bump sensors, cameras or LiDAR to detect obstacles. Rather than attempting to build a complete navigation system, Miloš deliberately simplifies the sensing challenge.

The robot uses five downward-facing infrared sensors as cliff detectors.

“Instead of detecting walls we will detect cliffs.”

This changes the problem from obstacle avoidance to edge detection. Rather than navigating around furniture, the robot explores a raised surface and attempts to identify where the surface ends.

The approach is particularly useful for demonstrating how sensor information can directly drive robotic behaviour without requiring complex perception systems.

The firmware includes logic specifically designed around this sensor arrangement.

// On a downward-facing cliff sensor a set bit means
// "this sensor SEES THE FLOOR".
// Danger is the absence of floor.

#define IR_CLIFFS(mask) ((uint8_t)((~(mask)) & IR_ALL_BITS))

The accompanying comment in the firmware highlights a surprisingly common mistake.

// Getting that backwards is not a cosmetic bug:
// it produces a robot that refuses to move on solid
// ground and drives happily over a cliff.

It is exactly the kind of observation that comes from testing on physical hardware rather than simulation.

Designing the Chassis

With the electronics established, attention shifted towards the mechanical design.

Miloš created the platform in Fusion 360 and structured it around a simple differential-drive layout consisting of two powered wheels and a caster.

“We’re going to drop into Fusion 360, do some CAD design.”

The project is intentionally straightforward so that readers can recreate it even if they do not have access to the exact same fabrication tools.

While the published design uses 3D-printed components, the robot could be built from much simpler materials. The important requirement is maintaining alignment between the drive wheels.

If the wheels are not parallel, the robot will naturally drift and produce misleading results during testing.

That lesson mirrors many industrial robotics projects: elegant software cannot compensate indefinitely for poor mechanical fundamentals.

Firmware, Communications and Software Architecture

The software is split into two major pieces. The first is embedded firmware running on the Pico. The second is a desktop GUI used for control, monitoring and tuning.

The firmware is deliberately modular.

// Everything the host can ask for goes through here,
// so Serial and WiFi are guaranteed to behave identically.

This ensures that commands behave the same whether they are sent through USB Serial or over Wi-Fi.

The firmware also uses movement concepts familiar to anyone who has worked with CNC machines or 3D printers.

// Modal state (G90/G91, the last F,
// the programmed wheel target) lives here
// rather than in the controller.

The resulting system is flexible enough for interactive testing while remaining structured enough for more advanced automation later on.

Applying PID Control to a Real Robot

Each wheel uses encoder feedback to regulate speed through a closed-loop controller.

// SPEED loop (inner): error in mm/s -> output in duty

#define SPD_KP 0.0015f
#define SPD_KI 0.0080f

The GUI exposes tuning controls, making it possible to observe how the robot responds as controller values change.

Those behaviours become immediately visible when real motors, gearboxes, batteries and sensors enter the equation.

The project therefore serves as a practical continuation of the PID concepts introduced earlier in the series, showing what they look like when attached to a physical robot rather than a simplified example.

From Fixed Robots to Mobile Robots

One of the biggest conceptual differences between this project and the earlier SCARA robot arm is localisation.

A robot arm operates from a known position. Its joints move relative to a fixed base and its location in the world remains constant.

A mobile robot is different.

Once it begins moving, it has to estimate where it is.

This project deliberately avoids advanced localisation systems such as visual SLAM or sensor fusion. Instead, the platform introduces a simpler concept: wheel odometry.

By measuring wheel rotation using encoders, the robot can estimate how far it has travelled and build a rough picture of its movement.

“We are only here calculating where it is based on the encoder positions.”

While not perfectly accurate, odometry provides a powerful introduction to localisation and forms the basis of countless robotics systems.

Creating a Simple Mapping Behaviour

Once the platform could drive reliably and the sensors were functioning correctly, it was time to make the robot perform a task.

The chosen exercise was mapping the edge of a raised surface.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour is significant because it combines every major subsystem.

The mechanical design determines how the robot moves.
The motors execute the movement.
The encoders provide feedback.
The PID loops regulate motion.
The sensors detect the environment.
The algorithm determines how the robot reacts.

The GUI then visualises the results.

As the robot continues exploring, the triggered cliff detections begin forming a representation of the table edge.

“It’s forming a rather nice point cloud around the edges of the table.”

The robot is not creating a complete map in the modern SLAM sense, but it does demonstrate how movement and sensing can be combined to generate useful environmental information.

What Beginners Should Focus On

One of the most useful aspects of this project is that it intentionally avoids overwhelming complexity.

Rather than introducing every possible robotics concept at once, Miloš focuses on a small number of ideas and demonstrates how they fit together.

Differential-drive locomotion.
Motor control and motor drivers.
Wheel encoders.
PID speed regulation.
Microcontroller-based firmware.
Infrared sensing.
Wireless communications.
Simple mapping behaviour.
Basic odometry.

Those are often the challenges that consume the most development time on real projects.

Further Learning on element14 Community

Readers wanting to explore the wider Introduction to Robotics series and related topics can continue with:

Final Thoughts

As the fourth instalment of the Introduction to Robotics series, this project acts as a bridge between foundational robotics theory and the challenges of mobile robotics.

By the end of the project, the robot can drive, regulate its wheel speed, detect table edges, estimate its movement, visualise sensor data and build a rough representation of its surroundings.

Those capabilities may appear straightforward, but together they form the basis of a huge number of robotic systems.

“I would love to explore more complex robotics projects with you.”

Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

cstanton — Thu, 13 Aug 2026 09:27:50 GMT

Revision 4 posted to Documents by cstanton on 8/13/2026 9:27:50 AM

Loin Miloš Rašić as he builds a differential-drive mobile robot and explores the fundamentals of mobile robotics. In this instalment of the Introduction to Robotics series, he brings together electronics, mechanical design, motor control, encoder feedback, PID tuning, wireless communications and sensor-driven behaviours to create a robot capable of navigating a surface and mapping its edges.

Along the way, Miloš demonstrates how wheel encoders enable speed control and odometry, how infrared sensors can be used as cliff detectors, and how a simple mapping algorithm can turn sensor data into useful environmental information. The project also highlights practical challenges including battery brownouts, logic-level compatibility, controller tuning and real-world testing.

Whether you're building your first robot or looking to understand how mobile robotics systems are put together, this project provides a hands-on introduction to the concepts that underpin larger autonomous platforms, and you can find the supporting files below

Time to Build a Robot!

players.brightcove.net/.../index.html

For the fourth part of the series, the focus shifts to one of the most recognisable categories of robotics: the mobile robot.

“This was for people that were making their first robot and just wanted to see something move.”

Bringing the Previous Parts Together

This project is the fourth instalment of the series where every subsystem relies on concepts already introduced.

Building the Foundations of Your First Robot - An Introduction to Robotics introduced the core hardware elements such as sensors, motors, microcontrollers, CAD design and manufacturing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics explored feedback systems, control loops and software structures used to regulate motion.
Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics demonstrated how those ideas could be combined into a complete robotic system with embedded firmware and a graphical user interface.

Locomotion: How Do Mobile Robots Move?

Miloš begins by introducing locomotion, the ability of a robot to move from one place to another.

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot uses two powered drive wheels and a third passive support wheel, normally a caster. Steering is achieved entirely through the relative speed of the left and right wheels.

The design keeps moving parts to a minimum while still demonstrating many important mobile robotics concepts.

“The vacuum robot is the prime example of a differential drive robot.”

Selecting the Hardware

With the robot architecture decided, the next step was selecting the hardware.

“This here is an encoder.”

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply)
//      battery    --> VM            (motor supply)

While deceptively simple, this arrangement introduces readers to one of the most common motor-control structures used throughout robotics.

The Raspberry Pi Pico 2 W and Power System

To coordinate the robot's sensors, motors and communications, Miloš selected a Raspberry Pi Pico 2 W.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The Pico handles the embedded side of the project. It reads sensor data, processes encoder counts, executes the PID control loops, communicates with the GUI and generates motor commands.

An interesting challenge emerged from the encoder hardware. The motor encoders operate using 5 V logic, while the Pico uses 3.3 V logic.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

Miloš jokingly highlights another very real robotics issue: battery quality.

If the supply voltage drops too far under load, motors may continue turning while the microcontroller resets unexpectedly, producing brownouts and unpredictable behaviour.

Cliff Detection Instead of Obstacle Detection

Many consumer robots rely on bump sensors, cameras or LiDAR to detect obstacles. Rather than attempting to build a complete navigation system, Miloš deliberately simplifies the sensing challenge.

The robot uses five downward-facing infrared sensors as cliff detectors.

“Instead of detecting walls we will detect cliffs.”

This changes the problem from obstacle avoidance to edge detection. Rather than navigating around furniture, the robot explores a raised surface and attempts to identify where the surface ends.

The approach is particularly useful for demonstrating how sensor information can directly drive robotic behaviour without requiring complex perception systems.

The firmware includes logic specifically designed around this sensor arrangement.

// On a downward-facing cliff sensor a set bit means
// "this sensor SEES THE FLOOR".
// Danger is the absence of floor.

#define IR_CLIFFS(mask) ((uint8_t)((~(mask)) & IR_ALL_BITS))

The accompanying comment in the firmware highlights a surprisingly common mistake.

// Getting that backwards is not a cosmetic bug:
// it produces a robot that refuses to move on solid
// ground and drives happily over a cliff.

It is exactly the kind of observation that comes from testing on physical hardware rather than simulation.

Designing the Chassis

With the electronics established, attention shifted towards the mechanical design.

Miloš created the platform in Fusion 360 and structured it around a simple differential-drive layout consisting of two powered wheels and a caster.

“We’re going to drop into Fusion 360, do some CAD design.”

The project is intentionally straightforward so that readers can recreate it even if they do not have access to the exact same fabrication tools.

While the published design uses 3D-printed components, the robot could be built from much simpler materials. The important requirement is maintaining alignment between the drive wheels.

If the wheels are not parallel, the robot will naturally drift and produce misleading results during testing.

That lesson mirrors many industrial robotics projects: elegant software cannot compensate indefinitely for poor mechanical fundamentals.

Firmware, Communications and Software Architecture

The software is split into two major pieces. The first is embedded firmware running on the Pico. The second is a desktop GUI used for control, monitoring and tuning.

The firmware is deliberately modular.

// Everything the host can ask for goes through here,
// so Serial and WiFi are guaranteed to behave identically.

This ensures that commands behave the same whether they are sent through USB Serial or over Wi-Fi.

The firmware also uses movement concepts familiar to anyone who has worked with CNC machines or 3D printers.

// Modal state (G90/G91, the last F,
// the programmed wheel target) lives here
// rather than in the controller.

The resulting system is flexible enough for interactive testing while remaining structured enough for more advanced automation later on.

Applying PID Control to a Real Robot

Each wheel uses encoder feedback to regulate speed through a closed-loop controller.

// SPEED loop (inner): error in mm/s -> output in duty

#define SPD_KP 0.0015f
#define SPD_KI 0.0080f

The GUI exposes tuning controls, making it possible to observe how the robot responds as controller values change.

Those behaviours become immediately visible when real motors, gearboxes, batteries and sensors enter the equation.

From Fixed Robots to Mobile Robots

One of the biggest conceptual differences between this project and the earlier SCARA robot arm is localisation.

A robot arm operates from a known position. Its joints move relative to a fixed base and its location in the world remains constant.

A mobile robot is different.

Once it begins moving, it has to estimate where it is.

This project deliberately avoids advanced localisation systems such as visual SLAM or sensor fusion. Instead, the platform introduces a simpler concept: wheel odometry.

By measuring wheel rotation using encoders, the robot can estimate how far it has travelled and build a rough picture of its movement.

“We are only here calculating where it is based on the encoder positions.”

While not perfectly accurate, odometry provides a powerful introduction to localisation and forms the basis of countless robotics systems.

Creating a Simple Mapping Behaviour

Once the platform could drive reliably and the sensors were functioning correctly, it was time to make the robot perform a task.

The chosen exercise was mapping the edge of a raised surface.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour is significant because it combines every major subsystem.

The mechanical design determines how the robot moves.
The motors execute the movement.
The encoders provide feedback.
The PID loops regulate motion.
The sensors detect the environment.
The algorithm determines how the robot reacts.

The GUI then visualises the results.

As the robot continues exploring, the triggered cliff detections begin forming a representation of the table edge.

“It’s forming a rather nice point cloud around the edges of the table.”

The robot is not creating a complete map in the modern SLAM sense, but it does demonstrate how movement and sensing can be combined to generate useful environmental information.

What Beginners Should Focus On

One of the most useful aspects of this project is that it intentionally avoids overwhelming complexity.

Rather than introducing every possible robotics concept at once, Miloš focuses on a small number of ideas and demonstrates how they fit together.

Differential-drive locomotion.
Motor control and motor drivers.
Wheel encoders.
PID speed regulation.
Microcontroller-based firmware.
Infrared sensing.
Wireless communications.
Simple mapping behaviour.
Basic odometry.

Those are often the challenges that consume the most development time on real projects.

Further Learning on element14 Community

Readers wanting to explore the wider Introduction to Robotics series and related topics can continue with:

Final Thoughts

As the fourth instalment of the Introduction to Robotics series, this project acts as a bridge between foundational robotics theory and the challenges of mobile robotics.

By the end of the project, the robot can drive, regulate its wheel speed, detect table edges, estimate its movement, visualise sensor data and build a rough representation of its surroundings.

Those capabilities may appear straightforward, but together they form the basis of a huge number of robotic systems.

“I would love to explore more complex robotics projects with you.”

Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

cstanton — Thu, 13 Aug 2026 09:22:03 GMT

Revision 3 posted to Documents by cstanton on 8/13/2026 9:22:03 AM

Time to Build a Robot!

community.element14.com/.../Robotics-101-_2D00_-Ep.-4-_2D00_-Locomotion-_2600_-Mapping_5F00_V3.mp4

For the fourth part of the series, the focus shifts to one of the most recognisable categories of robotics: the mobile robot.

“This was for people that were making their first robot and just wanted to see something move.”

Bringing the Previous Parts Together

This project is the fourth instalment of the series where every subsystem relies on concepts already introduced.

Building the Foundations of Your First Robot - An Introduction to Robotics introduced the core hardware elements such as sensors, motors, microcontrollers, CAD design and manufacturing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics explored feedback systems, control loops and software structures used to regulate motion.
Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics demonstrated how those ideas could be combined into a complete robotic system with embedded firmware and a graphical user interface.

Locomotion: How Do Mobile Robots Move?

Miloš begins by introducing locomotion, the ability of a robot to move from one place to another.

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot uses two powered drive wheels and a third passive support wheel, normally a caster. Steering is achieved entirely through the relative speed of the left and right wheels.

The design keeps moving parts to a minimum while still demonstrating many important mobile robotics concepts.

“The vacuum robot is the prime example of a differential drive robot.”

Selecting the Hardware

With the robot architecture decided, the next step was selecting the hardware.

“This here is an encoder.”

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply)
//      battery    --> VM            (motor supply)

While deceptively simple, this arrangement introduces readers to one of the most common motor-control structures used throughout robotics.

The Raspberry Pi Pico 2 W and Power System

To coordinate the robot's sensors, motors and communications, Miloš selected a Raspberry Pi Pico 2 W.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The Pico handles the embedded side of the project. It reads sensor data, processes encoder counts, executes the PID control loops, communicates with the GUI and generates motor commands.

An interesting challenge emerged from the encoder hardware. The motor encoders operate using 5 V logic, while the Pico uses 3.3 V logic.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

Miloš jokingly highlights another very real robotics issue: battery quality.

If the supply voltage drops too far under load, motors may continue turning while the microcontroller resets unexpectedly, producing brownouts and unpredictable behaviour.

Cliff Detection Instead of Obstacle Detection

Many consumer robots rely on bump sensors, cameras or LiDAR to detect obstacles. Rather than attempting to build a complete navigation system, Miloš deliberately simplifies the sensing challenge.

The robot uses five downward-facing infrared sensors as cliff detectors.

“Instead of detecting walls we will detect cliffs.”

This changes the problem from obstacle avoidance to edge detection. Rather than navigating around furniture, the robot explores a raised surface and attempts to identify where the surface ends.

The approach is particularly useful for demonstrating how sensor information can directly drive robotic behaviour without requiring complex perception systems.

The firmware includes logic specifically designed around this sensor arrangement.

// On a downward-facing cliff sensor a set bit means
// "this sensor SEES THE FLOOR".
// Danger is the absence of floor.

#define IR_CLIFFS(mask) ((uint8_t)((~(mask)) & IR_ALL_BITS))

The accompanying comment in the firmware highlights a surprisingly common mistake.

// Getting that backwards is not a cosmetic bug:
// it produces a robot that refuses to move on solid
// ground and drives happily over a cliff.

It is exactly the kind of observation that comes from testing on physical hardware rather than simulation.

Designing the Chassis

With the electronics established, attention shifted towards the mechanical design.

Miloš created the platform in Fusion 360 and structured it around a simple differential-drive layout consisting of two powered wheels and a caster.

“We’re going to drop into Fusion 360, do some CAD design.”

The project is intentionally straightforward so that readers can recreate it even if they do not have access to the exact same fabrication tools.

While the published design uses 3D-printed components, the robot could be built from much simpler materials. The important requirement is maintaining alignment between the drive wheels.

If the wheels are not parallel, the robot will naturally drift and produce misleading results during testing.

That lesson mirrors many industrial robotics projects: elegant software cannot compensate indefinitely for poor mechanical fundamentals.

Firmware, Communications and Software Architecture

The software is split into two major pieces. The first is embedded firmware running on the Pico. The second is a desktop GUI used for control, monitoring and tuning.

The firmware is deliberately modular.

// Everything the host can ask for goes through here,
// so Serial and WiFi are guaranteed to behave identically.

This ensures that commands behave the same whether they are sent through USB Serial or over Wi-Fi.

The firmware also uses movement concepts familiar to anyone who has worked with CNC machines or 3D printers.

// Modal state (G90/G91, the last F,
// the programmed wheel target) lives here
// rather than in the controller.

The resulting system is flexible enough for interactive testing while remaining structured enough for more advanced automation later on.

Applying PID Control to a Real Robot

Each wheel uses encoder feedback to regulate speed through a closed-loop controller.

// SPEED loop (inner): error in mm/s -> output in duty

#define SPD_KP 0.0015f
#define SPD_KI 0.0080f

The GUI exposes tuning controls, making it possible to observe how the robot responds as controller values change.

Those behaviours become immediately visible when real motors, gearboxes, batteries and sensors enter the equation.

From Fixed Robots to Mobile Robots

One of the biggest conceptual differences between this project and the earlier SCARA robot arm is localisation.

A robot arm operates from a known position. Its joints move relative to a fixed base and its location in the world remains constant.

A mobile robot is different.

Once it begins moving, it has to estimate where it is.

This project deliberately avoids advanced localisation systems such as visual SLAM or sensor fusion. Instead, the platform introduces a simpler concept: wheel odometry.

By measuring wheel rotation using encoders, the robot can estimate how far it has travelled and build a rough picture of its movement.

“We are only here calculating where it is based on the encoder positions.”

While not perfectly accurate, odometry provides a powerful introduction to localisation and forms the basis of countless robotics systems.

Creating a Simple Mapping Behaviour

Once the platform could drive reliably and the sensors were functioning correctly, it was time to make the robot perform a task.

The chosen exercise was mapping the edge of a raised surface.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour is significant because it combines every major subsystem.

The mechanical design determines how the robot moves.
The motors execute the movement.
The encoders provide feedback.
The PID loops regulate motion.
The sensors detect the environment.
The algorithm determines how the robot reacts.

The GUI then visualises the results.

As the robot continues exploring, the triggered cliff detections begin forming a representation of the table edge.

“It’s forming a rather nice point cloud around the edges of the table.”

The robot is not creating a complete map in the modern SLAM sense, but it does demonstrate how movement and sensing can be combined to generate useful environmental information.

What Beginners Should Focus On

One of the most useful aspects of this project is that it intentionally avoids overwhelming complexity.

Rather than introducing every possible robotics concept at once, Miloš focuses on a small number of ideas and demonstrates how they fit together.

Differential-drive locomotion.
Motor control and motor drivers.
Wheel encoders.
PID speed regulation.
Microcontroller-based firmware.
Infrared sensing.
Wireless communications.
Simple mapping behaviour.
Basic odometry.

Those are often the challenges that consume the most development time on real projects.

Further Learning on element14 Community

Readers wanting to explore the wider Introduction to Robotics series and related topics can continue with:

Final Thoughts

As the fourth instalment of the Introduction to Robotics series, this project acts as a bridge between foundational robotics theory and the challenges of mobile robotics.

By the end of the project, the robot can drive, regulate its wheel speed, detect table edges, estimate its movement, visualise sensor data and build a rough representation of its surroundings.

Those capabilities may appear straightforward, but together they form the basis of a huge number of robotic systems.

“I would love to explore more complex robotics projects with you.”

Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

cstanton — Thu, 13 Aug 2026 09:15:03 GMT

Revision 2 posted to Documents by cstanton on 8/13/2026 9:15:03 AM

Time to Build a Robot!

community.element14.com/.../Robotics-101-_2D00_-Ep.-4-_2D00_-Locomotion-_2600_-Mapping_5F00_V3.mp4

For the fourth part of the series, the focus shifts to one of the most recognisable categories of robotics: the mobile robot.

“This was for people that were making their first robot and just wanted to see something move.”

Bringing the Previous Parts Together

This project is the fourth instalment of the series where every subsystem relies on concepts already introduced.

Building the Foundations of Your First Robot - An Introduction to Robotics introduced the core hardware elements such as sensors, motors, microcontrollers, CAD design and manufacturing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics explored feedback systems, control loops and software structures used to regulate motion.
Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics demonstrated how those ideas could be combined into a complete robotic system with embedded firmware and a graphical user interface.

Locomotion: How Do Mobile Robots Move?

Miloš begins by introducing locomotion, the ability of a robot to move from one place to another.

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot uses two powered drive wheels and a third passive support wheel, normally a caster. Steering is achieved entirely through the relative speed of the left and right wheels.

The design keeps moving parts to a minimum while still demonstrating many important mobile robotics concepts.

“The vacuum robot is the prime example of a differential drive robot.”

Selecting the Hardware

With the robot architecture decided, the next step was selecting the hardware.

“This here is an encoder.”

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply)
//      battery    --> VM            (motor supply)

While deceptively simple, this arrangement introduces readers to one of the most common motor-control structures used throughout robotics.

The Raspberry Pi Pico 2 W and Power System

To coordinate the robot's sensors, motors and communications, Miloš selected a Raspberry Pi Pico 2 W.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The Pico handles the embedded side of the project. It reads sensor data, processes encoder counts, executes the PID control loops, communicates with the GUI and generates motor commands.

An interesting challenge emerged from the encoder hardware. The motor encoders operate using 5 V logic, while the Pico uses 3.3 V logic.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

Miloš jokingly highlights another very real robotics issue: battery quality.

If the supply voltage drops too far under load, motors may continue turning while the microcontroller resets unexpectedly, producing brownouts and unpredictable behaviour.

Cliff Detection Instead of Obstacle Detection

Many consumer robots rely on bump sensors, cameras or LiDAR to detect obstacles. Rather than attempting to build a complete navigation system, Miloš deliberately simplifies the sensing challenge.

The robot uses five downward-facing infrared sensors as cliff detectors.

“Instead of detecting walls we will detect cliffs.”

This changes the problem from obstacle avoidance to edge detection. Rather than navigating around furniture, the robot explores a raised surface and attempts to identify where the surface ends.

The approach is particularly useful for demonstrating how sensor information can directly drive robotic behaviour without requiring complex perception systems.

The firmware includes logic specifically designed around this sensor arrangement.

// On a downward-facing cliff sensor a set bit means
// "this sensor SEES THE FLOOR".
// Danger is the absence of floor.

#define IR_CLIFFS(mask) ((uint8_t)((~(mask)) & IR_ALL_BITS))

The accompanying comment in the firmware highlights a surprisingly common mistake.

// Getting that backwards is not a cosmetic bug:
// it produces a robot that refuses to move on solid
// ground and drives happily over a cliff.

It is exactly the kind of observation that comes from testing on physical hardware rather than simulation.

Designing the Chassis

With the electronics established, attention shifted towards the mechanical design.

Miloš created the platform in Fusion 360 and structured it around a simple differential-drive layout consisting of two powered wheels and a caster.

“We’re going to drop into Fusion 360, do some CAD design.”

The project is intentionally straightforward so that readers can recreate it even if they do not have access to the exact same fabrication tools.

While the published design uses 3D-printed components, the robot could be built from much simpler materials. The important requirement is maintaining alignment between the drive wheels.

If the wheels are not parallel, the robot will naturally drift and produce misleading results during testing.

That lesson mirrors many industrial robotics projects: elegant software cannot compensate indefinitely for poor mechanical fundamentals.

Firmware, Communications and Software Architecture

The software is split into two major pieces. The first is embedded firmware running on the Pico. The second is a desktop GUI used for control, monitoring and tuning.

The firmware is deliberately modular.

// Everything the host can ask for goes through here,
// so Serial and WiFi are guaranteed to behave identically.

This ensures that commands behave the same whether they are sent through USB Serial or over Wi-Fi.

The firmware also uses movement concepts familiar to anyone who has worked with CNC machines or 3D printers.

// Modal state (G90/G91, the last F,
// the programmed wheel target) lives here
// rather than in the controller.

The resulting system is flexible enough for interactive testing while remaining structured enough for more advanced automation later on.

Applying PID Control to a Real Robot

Each wheel uses encoder feedback to regulate speed through a closed-loop controller.

// SPEED loop (inner): error in mm/s -> output in duty

#define SPD_KP 0.0015f
#define SPD_KI 0.0080f

The GUI exposes tuning controls, making it possible to observe how the robot responds as controller values change.

Those behaviours become immediately visible when real motors, gearboxes, batteries and sensors enter the equation.

From Fixed Robots to Mobile Robots

One of the biggest conceptual differences between this project and the earlier SCARA robot arm is localisation.

A robot arm operates from a known position. Its joints move relative to a fixed base and its location in the world remains constant.

A mobile robot is different.

Once it begins moving, it has to estimate where it is.

This project deliberately avoids advanced localisation systems such as visual SLAM or sensor fusion. Instead, the platform introduces a simpler concept: wheel odometry.

By measuring wheel rotation using encoders, the robot can estimate how far it has travelled and build a rough picture of its movement.

“We are only here calculating where it is based on the encoder positions.”

While not perfectly accurate, odometry provides a powerful introduction to localisation and forms the basis of countless robotics systems.

Creating a Simple Mapping Behaviour

Once the platform could drive reliably and the sensors were functioning correctly, it was time to make the robot perform a task.

The chosen exercise was mapping the edge of a raised surface.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour is significant because it combines every major subsystem.

The mechanical design determines how the robot moves.
The motors execute the movement.
The encoders provide feedback.
The PID loops regulate motion.
The sensors detect the environment.
The algorithm determines how the robot reacts.

The GUI then visualises the results.

As the robot continues exploring, the triggered cliff detections begin forming a representation of the table edge.

“It’s forming a rather nice point cloud around the edges of the table.”

The robot is not creating a complete map in the modern SLAM sense, but it does demonstrate how movement and sensing can be combined to generate useful environmental information.

What Beginners Should Focus On

One of the most useful aspects of this project is that it intentionally avoids overwhelming complexity.

Rather than introducing every possible robotics concept at once, Miloš focuses on a small number of ideas and demonstrates how they fit together.

Differential-drive locomotion.
Motor control and motor drivers.
Wheel encoders.
PID speed regulation.
Microcontroller-based firmware.
Infrared sensing.
Wireless communications.
Simple mapping behaviour.
Basic odometry.

Those are often the challenges that consume the most development time on real projects.

Further Learning on element14 Community

Readers wanting to explore the wider Introduction to Robotics series and related topics can continue with:

Final Thoughts

As the fourth instalment of the Introduction to Robotics series, this project acts as a bridge between foundational robotics theory and the challenges of mobile robotics.

By the end of the project, the robot can drive, regulate its wheel speed, detect table edges, estimate its movement, visualise sensor data and build a rough representation of its surroundings.

Those capabilities may appear straightforward, but together they form the basis of a huge number of robotic systems.

“I would love to explore more complex robotics projects with you.”

Designing a Mobile Robot Platform with Differential Drive, PID Control and Wireless Mapping

cstanton — Thu, 13 Aug 2026 08:58:09 GMT

Revision 1 posted to Documents by cstanton on 8/13/2026 8:58:09 AM

In this fourth part of his introduction to robotics, Miloš Rašić moves from robot arms and control theory into a practical mobile robot platform. The aim is not to build the most advanced autonomous rover possible, but to show how the core ideas behind robotics come together in a small, approachable machine: locomotion, motor control, feedback, power, software, sensors, CAD and a simple mapping behaviour.

The result is a compact differential-drive robot built around a Raspberry Pi Pico 2 W, two geared DC motors with encoders, a dual motor driver, five downward-facing IR sensors, a small caster wheel, and a custom firmware and GUI stack. It is designed to be something a maker can learn from, modify and recreate without needing industrial hardware or an expensive robotics platform.

“This was for people that were making their first robot and just wanted to see something move.”

That practical approach runs through the whole build. Miloš keeps the platform small, uses accessible components, and focuses on the important robotics lessons that appear again and again in larger systems: how the robot moves, how it senses wheel motion, how it avoids falling off an edge, how it communicates with a computer, and how a simple algorithm can turn sensor readings into useful behaviour.

If you are new to the field, the earlier parts of this introduction to robotics are worth reading first. The series starts with Building the Foundations of Your First Robot, then moves into PID Control, Motion Profiles and ROS Explained, before applying many of those ideas in the SCARA robot arm build.

Locomotion: How Does a Robot Move?

Miloš begins with locomotion, which is simply the ability to move from one place to another. In robotics, that question quickly turns into something more specific: what kind of movement can the machine perform, and what mechanical arrangement makes that movement possible?

“Locomotion is the ability of moving from one place to another. So in robotics it’s how does the robot move?”

There is no single fixed list of robot locomotion types. Wheeled robots, bipedal robots, tracked robots, quadrupeds, soft robots and worm-like robots all solve movement differently. For this build, Miloš deliberately chooses wheels because they are one of the easiest ways to get a robot moving across a flat surface.

Even then, “wheeled robot” covers several possible configurations. A car-style robot steers by changing the angle of its front wheels. A tank-style robot changes direction by varying the speed and direction of its left and right sides. Mecanum wheels allow sideways motion, but they add complexity. To keep the number of moving parts low, Miloš chooses a differential-drive layout.

“In this case the wheels are fixed, we can just play with their speed and direction.”

A differential-drive robot normally uses two powered wheels and one passive support wheel or caster. If both drive wheels rotate forward at the same speed, the robot moves forward. If they rotate backwards at the same speed, it reverses. If one wheel turns faster than the other, the robot follows a curve. If the wheels turn in opposite directions, the robot rotates on the spot.

This is one of the most useful beginner configurations because it teaches a lot of robotics without overcomplicating the mechanics. It is also familiar. Robot vacuum cleaners use the same basic idea, with drive wheels underneath and a caster or support point to keep the chassis balanced.

“The vacuum robot is the prime example of a differential drive robot.”

For readers wanting broader context, the element14 Community Robotics group is a useful place to browse projects, discussions and learning material around mobile robots, sensors and control systems.

The Parts of the Robot

The main hardware is intentionally direct. The bill of materials includes two DFROBOT geared motors, one DFROBOT motor driver, a Raspberry Pi Pico 2 W, five IR sensors, a small caster wheel, a 4 AA battery holder, M3 machine screws, perfboard and wiring.

The drive motors are the first major choice. Miloš selects small geared DC motors from DFROBOT with integrated encoders. The gearbox reduces the high speed of the motor into a lower, more usable wheel speed, while the encoder provides feedback about motor rotation.

That encoder feedback is important. Without it, the robot can only guess how far the wheels have turned based on the command sent to the motor. With encoders, the firmware can measure wheel speed and distance, making closed-loop speed control and rough position estimates possible.

“This here is an encoder.”

Encoders are one of the first feedback devices that beginners encounter in mobile robotics. The element14 Learning Center’s Magnetic Encoders module gives a useful overview of how rotary encoders convert mechanical motion into electrical signals representing position, velocity and direction.

To control the motors, the robot uses a dual motor driver. A microcontroller GPIO pin cannot safely power a DC motor directly. The microcontroller sends logic signals, while the motor driver handles the higher current needed by the motors. In this build, each motor channel has a direction input and a PWM signal for speed control.

// Wiring to the DRI0044 (TB6612FNG) breakout:
//      PICO           DRI0044
//      PIN_M?_PWM --> PWM1 / PWM2   (speed,     0..100% duty)
//      PIN_M?_DIR --> DIR1 / DIR2   (direction, LOW/HIGH)
//      3V3        --> VCC           (logic supply, 2.7-5.5V)
//      GND        --> GND
//      battery    --> VM            (motor supply, 2.5-12V)

This is a valuable detail for anyone recreating the project. The motor driver’s logic side and motor-power side are separate concerns. The Pico provides low-voltage logic, while the battery supplies the motors through the driver.

The Motor Control: Motor Drive Control for Makers module expands on brushed DC motors, motor drivers, PWM, torque, speed and the electronics used to control different motor types.

Microcontroller, Power and Logic Levels

The robot is built around the Raspberry Pi Pico 2 W. Miloš chooses it because it is compact, inexpensive, powerful enough for the control loops, and includes wireless connectivity.

“Why? Because it’s a really cheap and rather powerful microcontroller and it also has Wi-Fi and Bluetooth so we can easily control it wirelessly.”

The microcontroller handles the time-sensitive side of the robot. It reads encoder pulses, samples IR sensors, updates the PID loops, generates motor commands and communicates with the host-side software. For anyone getting started with embedded control, the element14 Learning Center’s Basics of Microcontrollers explains how MCUs read inputs, run software and control external hardware.

One practical issue appears immediately: logic voltage. Miloš points out that the motor encoders use 5 V logic while the Pico uses 3.3 V logic. That cannot be ignored. Feeding 5 V signals directly into a 3.3 V microcontroller input can damage the board or cause unreliable readings.

“The encoders on these motors are 5V logic and our microcontroller here is 3.3V logic so we also need a level translator.”

A small level-shifting breakout can solve this, or a resistor divider can be used where suitable. The guide is a good reminder that beginner robots are often full of these small electrical details. The robot may look like a mechanical project from the outside, but correct voltage levels, grounding and power distribution decide whether it behaves reliably.

Power is also a recurring theme. The robot uses a 4 AA battery pack, giving around 6 V for the motor supply, with regulation down to 3.3 V for the microcontroller and logic. Miloš specifically warns that poor batteries can cause brownouts, where voltage dips far enough for the electronics to reset or behave unpredictably.

Good batteries, solid wiring and sensible regulation are not glamorous parts of robotics, but they save a lot of debugging. The Power Essentials for Makers guide is a useful companion here, especially when thinking about batteries, current draw, regulators and power losses.

Using IR Sensors as Simple Cliff Detectors

Instead of using bump sensors or LIDAR, Miloš keeps the environmental sensing simple. The robot uses five downward-facing IR sensors as cliff detectors. These sensors are positioned so the robot can detect when the surface beneath it disappears, such as at the edge of a table.

“Mostly the robots like the Roomba have the bump sensors, some even have LiDAR to detect walls. Just to make it simpler for testing we will instead of detecting walls we will detect cliffs.”

This changes the mapping problem into something manageable. Rather than trying to map obstacles in a room, the robot explores a raised surface and records where the edge is. In effect, the absence of floor becomes the boundary.

The firmware reflects an easy mistake people can make with reflective IR sensors: the active sensor state does not necessarily mean danger. In this project, a sensor seeing the floor is normal. The danger condition is when the sensor no longer sees the floor.

// On a downward-facing cliff sensor a set bit means "this sensor SEES THE FLOOR".
// It does NOT mean danger -- danger is the ABSENCE of floor.
// Pointing down off the edge of a table, the bit goes to ZERO.
//
// Getting that backwards is not a cosmetic bug: it produces a robot that
// refuses to move on solid ground and drives happily over a cliff.
#define IR_CLIFFS(mask)     ((uint8_t)((~(mask)) & IR_ALL_BITS))

This is one of the most useful teaching details in the firmware. Sensor polarity should be understood and converted once, close to the hardware layer, so the rest of the software can think in terms of meaningful states such as “cliff detected” rather than “pin low” or “pin high”.

Designing the Chassis

Once the electronics were selected, Miloš moved into the mechanical design. The platform is designed in Fusion 360 and intended to be 3D printed, but the design remains intentionally simple.

“We’re going to drop into Fusion 360, do some CAD design and we’ll make all of the parts for the small mobile robot.”

The design uses two powered wheels and a small caster wheel. The key requirement is that the drive wheels are parallel and mounted securely. If they are misaligned, the robot will drift, scrub, or fight the controller. This is why even a simple chassis still benefits from careful layout.

Miloš also keeps the build accessible by noting that the same sort of robot could be constructed with simpler materials. A 3D printed chassis is clean and repeatable, but a beginner could still learn the core ideas with tongue depressors, popsicle sticks, cardboard or hot glue, provided the wheels are held straight and the sensors are mounted consistently.

That is a good way to approach a first robotics platform. CAD and 3D printing help, but they are not the actual lesson. The lesson is the relationship between the mechanical layout, the electronics and the software trying to control the machine.

Firmware and Communications

The software is split into two parts: firmware running on the Pico and a host-side GUI used for testing, tuning, driving and visualising the robot.

The firmware is written in a modular way. The command interpreter is shared across Serial and Wi-Fi so that both transports behave consistently. This prevents the common problem where USB commands and network commands end up having slightly different behaviours.

// Everything the host can ask for goes through here, so Serial and WiFi are
// guaranteed to behave identically -- there is exactly one implementation of
// every command, and the transport only supplies bytes.

That choice is particularly useful for debugging. When a robot can be controlled over USB during bench testing and wirelessly during normal operation, the command layer should not care which connection supplied the bytes.

The firmware also uses a command style inspired by G-code. Modal state such as absolute and relative movement is handled in the command processor, allowing movements to be described in a structured way.

// Modal state (G90/G91, the last F, the programmed wheel target) lives here
// rather than in the controller, exactly as it does in a 3D printer: relative
// moves are computed against the last PROGRAMMED position, never against the
// measured one. Using the measured position would make G91 accumulate the
// tracking error of every previous move.

This is a subtle but important software design decision. If relative moves were based on the measured position, tracking error from previous movements could accumulate into future commands. By basing relative moves on the last programmed position, the command stream remains predictable.

For anyone familiar with 3D printers, CNC machines or motion controllers, this structure will feel familiar. For beginners, it is a good example of how robotics software can borrow proven ideas from other motion-control domains.

The GUI: Driving, Testing and Tuning

The GUI gives the robot a practical development environment. It can show raw data, provide a top-down live view, visualise where the robot has moved, indicate where the IR sensors have triggered, and expose PID tuning controls.

Miloš also explains that AI tools helped with parts of the embedded and GUI workflow, particularly in creating modular firmware and a usable graphical interface. The important point is not that AI wrote the project, but that he used it as a tool while still testing the result against real hardware.

That physical testing is essential. A GUI can be perfectly drawn and firmware can appear sensible, but mobile robots reveal problems through movement: swapped motor wiring, inverted encoders, noisy sensors, timing issues, wheels rubbing, battery voltage sag, and controllers that are too slow or too aggressive.

“First with the motor driver then the encoders make sure that we get some readings then compare.”

This staged bring-up is exactly how a beginner should approach a robotics build. Test one subsystem at a time. Confirm the motor driver works. Confirm encoder counts change. Confirm direction is correct. Confirm sensors switch as expected. Only then run the whole robot as a system.

If you are still building confidence with software tools, the Introduction to Programming with Python learning module is a useful starting point for understanding the host-side scripting and GUI possibilities that often sit alongside microcontroller firmware.

Differential Drive Control

Once the robot can drive, the next step is making it drive in a controlled way. A differential-drive robot has three fundamental motion patterns:

Both wheels same speed, same direction: straight forward or backwards.
Both wheels same speed, opposite directions: rotate on the spot.
Both wheels same direction, different speeds: follow a curve.

These simple combinations are enough to create a wide range of movement. The robot does not need steering linkages because steering comes entirely from the relative speeds of the two drive wheels.

In the firmware, left and right motor channels are mapped explicitly. If the wheels appear swapped or turn the wrong way during bring-up, the documentation points out that the pin pairs or motor connectors can be exchanged.

// Driver channel 1 is taken to be the LEFT motor, channel 2 the RIGHT.
// If the wheels turn out to be swapped, exchange these two pin pairs
// or just swap the two motor connectors.
#define PIN_MOTOR_L_PWM      6      // -> DRI0044 PWM1
#define PIN_MOTOR_L_DIR      7      // -> DRI0044 DIR1
#define PIN_MOTOR_R_PWM      8      // -> DRI0044 PWM2
#define PIN_MOTOR_R_DIR      9      // -> DRI0044 DIR2

This is another practical point for first-time builders. If the robot spins when it should drive straight, or turns left when it should turn right, the issue may not be the control algorithm. It may simply be that one motor is wired backwards, one encoder is inverted, or left and right have been swapped.

PID Control and Tuning the Wheels

To make a differential-drive robot behave consistently, each wheel needs speed control. That is where PID control comes in. The controller compares a target wheel speed with the measured wheel speed from the encoder, calculates the error, and adjusts motor output to reduce that error.

The firmware includes default speed loop gains and feed-forward terms. Feed-forward provides a baseline output based on the expected motor behaviour, while the PID loop trims the result to correct the remaining error.

// SPEED loop (inner): error in mm/s  ->  output in duty [-1..+1]
// Feed-forward does most of the work; the PID only trims.
// Start here, then tune on hardware with M902 step-response captures.
#define SPD_KP                  0.0015f
#define SPD_KI                  0.0080f

This is a sensible way to teach PID on a real robot. Rather than expecting the PID loop to do everything, the system begins with an approximate feed-forward estimate and lets the controller correct the difference. That makes tuning less extreme and can help reduce oscillation.

In the GUI, Miloš tunes the wheel response by observing how the measured speed follows the target. If the proportional gain is too low, the wheel takes too long to reach the set speed. If the gain is pushed too high, the system becomes unstable and oscillates.

This is one of the most valuable demonstrations in the project because it shows the difference between theory and real hardware. A gain value that looks harmless in code can make a motor hunt, chatter or overshoot on the bench.

“It’s not an optimal algorithm by any stretches of imagination as you can see in the graphical user interface but it’s getting there.”

The earlier element14 guide on PID Control, Motion Profiles and ROS Explained is a strong companion to this section, as it covers PID terms, motion profiles, software architecture and the move from low-level control to higher-level robot behaviour. Another relevant element14 presents project is Using PID in Robotics, How Hard Could it Be?, which shows how PID tuning often involves practical iteration rather than simply picking three magic constants.

Safety, Faults and Real Hardware Protection

Because the robot moves on a table and uses motorised wheels, the firmware includes fault states and emergency-stop handling. That is good practice even on a small educational build.

enum FaultBits : uint16_t {
    FAULT_NONE      = 0x0000,
    FAULT_ESTOP     = 0x0001,   // M112 was issued
    FAULT_STALL_L   = 0x0002,   // left wheel stalled under load
    FAULT_STALL_R   = 0x0004,
    FAULT_ENC_L     = 0x0008,   // implausible left encoder behaviour
    FAULT_ENC_R     = 0x0010,
    FAULT_OVERRUN   = 0x0020,   // control loop missed its deadline repeatedly
    FAULT_SETTINGS  = 0x0040    // stored settings were corrupt, defaults loaded
};

These fault bits show a more mature approach than simply writing values to motors. The controller can recognise an emergency stop, stalled motors, implausible encoder behaviour, missed timing deadlines or bad settings. Even if a beginner does not implement every feature in their first robot, the structure is worth studying.

There is also a slew limit on motor output, which protects the gearbox and power supply from harsh command changes.

// Maximum duty change per control tick (slew limit). 1.0 = unlimited.
// 0.05 @ 1 kHz = full-scale in 20 ms; protects the gearbox and the supply.
#define MOTOR_SLEW_PER_TICK     0.05f

This links back to the earlier discussion of physical limits. A software command can change instantly. A motor, gearbox, battery and wheel cannot. Limiting how quickly motor duty can change helps keep the robot closer to what the hardware can actually do.

Mapping a Raised Surface

Once the robot can drive and the sensors work, Miloš gives it a behaviour: explore a raised surface and map the edge without falling off.

The algorithm is deliberately simple. When the robot detects an edge on one side, it backs up and turns away from the cliff. If the centre sensor detects an edge head-on, the robot backs up and performs two 90 degree turns to begin another scan line. Rear sensors help prevent it reversing off the edge, although positioning remains important.

“As we detect a certain edge we’re gonna go back, turn around, something similar that your robot vacuum is doing.”

This behaviour mimics the idea behind some robot vacuum movement patterns, but in a simplified form. Instead of building a complete SLAM system, the robot uses local sensor readings and simple motion rules to build up a rough picture of the boundary.

The GUI makes this visible by showing where the robot has travelled and where the cliff sensors have triggered. Over time, the triggered points form a rough edge map.

“As you can see it’s forming a rather nice point cloud around the edges of the table.”

This is a useful beginner-friendly way into robot mapping. It avoids the complexity of cameras, LIDAR, sensor fusion and global localisation, while still showing the idea that a robot can build a representation of its surroundings by moving, sensing and recording data.

For readers interested in where this can go next, the element14 Learning Center’s Essentials of Robot Operating System 2 introduces the software framework used in many more advanced robotics systems. It covers nodes, topics, services, message passing, simulation and the way ROS 2 supports modular robot software.

What Beginners Should Take from This Build

The most valuable part of this mobile robot platform is not any single component. It is the way the project connects different robotics ideas into a machine that can be tested and improved.

Locomotion: The robot moves using a differential-drive layout, one of the simplest useful mobile robot configurations.
Actuation: Geared DC motors provide wheel motion, while a motor driver supplies the current the microcontroller cannot provide directly.
Feedback: Encoders provide wheel speed and position information for closed-loop control.
Sensing: Downward-facing IR sensors detect the absence of floor and act as cliff detectors.
Control: PID loops regulate wheel speed and make movement more repeatable.
Power: Batteries, logic voltage, motor voltage and level shifting all affect reliability.
Software architecture: Firmware handles real-time control, while the GUI helps with testing, tuning and visualisation.
Autonomy: A simple edge-following and mapping behaviour shows how sensor readings can drive robot decisions.

Miloš also shows that robotics is full of small practical problems. Batteries can sag. Sensors can be inverted. Encoders can use different logic levels. Motors can be wired backwards. PID gains can oscillate. A caster wheel, sensor position or wheel alignment can change the way the robot behaves.

Those are not failures of the learning process. They are the learning process.

“Hopefully it won’t fall off the table.”

That line captures the fun of the project. The robot is simple enough to understand, but real enough to misbehave. It has motors, sensors, firmware, a GUI, PID tuning and a basic mapping algorithm. It is the kind of platform that rewards methodical testing and invites upgrades.

Where to Learn More on element14 Community

To go deeper into the topics used in this build, these element14 Community resources are good next steps:

Building the Foundations of Your First Robot - An Introduction to Robotics for sensors, actuators, microcontrollers, gearboxes, CAD and 3D printing.
PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics for control loops, motion profiles, software architecture and ROS.
Building and Programming a SCARA Industrial Robot Arm for kinematics, firmware, Python control software and coordinate-based motion.
Designing a Mobile Robot Platform with Inverse Kinematics and Wireless Control for a larger mobile robotics platform with wireless control, kinematics and future upgrade paths.
element14 Learning Center for structured learning across electronics, programming, power, motors and robotics.
The Basics of Microcontrollers for understanding how the Pico sits between sensors, software and actuators.
Motor Control: Motor Drive Control for Makers for the theory behind DC motors, motor drivers and PWM control.
Magnetic Encoders for more detail on rotational feedback devices.
Power Essentials for Makers for batteries, regulators and power design basics.
An Introduction to Programming with Python for the software side of GUI tools, scripts and robotics utilities.
Essentials of Robot Operating System 2 for the next step into modular robotics software, simulation and higher-level control.
Jeremy Blum Arduino Tutorials for foundational embedded electronics and programming topics that transfer well into small robotics builds.

Final Thoughts

This mobile robot platform is a strong capstone for an introduction to robotics because it pulls together electronics, mechanics, software and control in a visible way. A robot arm is excellent for learning kinematics and joint motion, but a mobile robot adds a different kind of challenge: it must move through an environment, react to sensors and keep track of what it is doing.

Miloš keeps the build deliberately approachable. There is no heavy sensor fusion, no advanced SLAM stack, and no attempt to hide every detail behind a kit. Instead, the project shows the practical path from parts on a bench to a robot that can move, measure, tune, react and map the edge of a surface.

“I would love to explore more complex robotics projects with you.”

From here, the upgrade path is clear. Better batteries, more accurate sensors, wheel odometry, wireless telemetry, ROS 2 integration, LIDAR, path planning or a more advanced mapping algorithm could all build on the same foundation. The important part is that the foundation is visible. The robot has two wheels, a caster, a microcontroller, motor feedback, cliff sensors, PID control and software that makes the whole thing understandable.

For a first mobile robot, that is exactly the right place to start.