Documents

Clem has always had a healthy suspicion of expensive industrial hardware. Looking at the price of programmable logic controllers (PLCs), his initial reaction was much the same as many makers staring at a catalogue of industrial equipment: surely there cannot be that much inside a PLC to justify the cost.

Rather than speculate, he decided to build one.

The result is a PocketBeagle 2 based PLC project that starts out as a straightforward maker build and gradually evolves into something much closer to a genuine industrial controller. Along the way, it becomes a lesson in electrical isolation, PCB layout, device tree configuration, realtime processing and the countless small decisions that separate a prototype from a product.

As Clem puts it:

"Sometimes they are actually just an Arduino in a fancy box and some relays... but there are also legacy systems with big brand names and high price tags and these are built for reliability."

His goal was not to reproduce an industrial PLC exactly, but to understand where all that engineering effort goes.

Starting with an Open PLC Platform

Commercial PLCs often come with proprietary software ecosystems, vendor lock-in and long-term support guarantees. Clem wanted to approach the problem from a different direction.

Instead of using a dedicated PLC platform, he based his design around the PocketBeagle 2, a compact Linux-capable development board built around Texas Instruments' AM6254 Sitara processor.

What attracted him was the combination of high-level Linux functionality and low-level deterministic control.

"I wanted it to have serious capabilities. It should have realtime Linux support and it also should have a deterministic way of controlling the inputs and outputs."

Unlike many maker boards, the PocketBeagle 2 includes two Programmable Realtime Units (PRUs), effectively dedicated microcontroller-class cores integrated into the processor.

These can operate independently from Linux and are designed specifically for tasks that require predictable timing.

"We have the Linux controls around USB devices, high-level stuff like AI models and communication with networks and other devices, and then the PRUs can control all the inputs and outputs."

The AM6254 architecture immediately begins to resemble the split architecture found in many industrial systems. Linux handles networking, storage and complex applications while dedicated realtime processors handle machine control.

Clem even points out that the second PRU could act as a watchdog, redundancy controller or cross-checking processor, similar to techniques found in safety-oriented industrial equipment.

Version One: The Maker Approach

The first PLC design intentionally follows the path many hobbyists would take.

A Hammond DIN rail enclosure serves as the mechanical foundation, while a relatively simple two-layer PCB carries the electronics. The board includes:

PocketBeagle 2 controller
Microchip USB2514 USB 2.0 hub controller
Four analogue input channels
Four relay outputs
ULN2003 Darlington relay driver
Dual USB host ports
DIN rail mounting format

The PCB itself was designed quickly.

"I eyeballed the position of all the connectors and I tried to put as many features in here as possible."

Rather than spending days optimising every mechanical detail, the focus was on getting something functional into the enclosure as quickly as possible.

One feature Clem was especially keen to exploit was the PocketBeagle 2's integrated twelve-bit ADC. Unlike a typical Raspberry Pi, analogue inputs can be connected directly to the processor without requiring additional converter hardware.

The analogue channels are exposed through simple screw terminals, providing an easy way to interact with sensors and control inputs. The USB subsystem was another area where the project deliberately pushed the platform. By integrating the USB2514 hub controller, the PLC gains multiple USB ports for cameras, storage devices and peripherals.

On paper, it looked remarkably capable. Unfortunately, industrial design concerns do not appear on a schematic until something goes wrong.

When "Works" Isn't Good Enough

The first design functions. For many projects, that would be a success.

For a PLC, however, functionality is only the starting point.

Clem soon began identifying weaknesses that would become serious problems in an industrial environment.

The first issue was electrical safety.

"There is no real isolation in the original design. In case something goes wrong there could potentially be 230 volts everywhere in the system."

The relay outputs are capable of switching mains-voltage loads, yet the control electronics existed dangerously close to circuitry carrying higher voltages.

Industrial equipment depends heavily on segregation between control electronics and power electronics. Without that separation, failures can have consequences far beyond a damaged PCB.

The USB implementation also lacked many of the protections expected in a commercial design.

The original version provided only the minimum necessary circuitry to make the USB hub operate.

There was:

No ESD protection
No overcurrent protection
No controlled fault response
No dedicated USB power monitoring

These omissions are common in maker projects because they are often invisible during normal operation. Industrial equipment, by contrast, must survive repeated abuse from the outside world.

Analogue routing presented another problem.

"I've routed my analogue ports right next to the relays. That will not work very good because they will couple into it."

Relay switching generates electrical noise. Placing sensitive ADC signals next to relay circuits creates opportunities for incorrect readings, instability and potentially damage.

These are exactly the sort of layout considerations that are easy to overlook when the first goal is simply getting a board manufactured.

Building a More Professional Controller

The second board revision demonstrates how quickly extra engineering effort accumulates.

Clem moved to a four-layer PCB, improved component selection, reworked the enclosure integration and fundamentally redesigned the relay section.

More importantly, he stopped trying to maximise feature count and instead prioritised reliability.

"I preferred having good layout instead of more features on there because that is what the professional world considers the most important bit. Safe and reliable operation."

The revised USB implementation became significantly more sophisticated.

Dedicated current-limiting circuitry and fault detection were added to protect both connected peripherals and the PLC itself.

"These have current control chips specifically ordered and they have to detect if something goes wrong so your device that you plug into these USB ports can't destroy the overall thing."

This redesign required additional board area, forcing the reduction from four easily accessible USB ports down to two.

That trade-off between capability and robustness appears repeatedly throughout industrial design.

Isolation the Right Way

The most dramatic change involved the relay outputs. The revised PCB treats the relay circuitry and logic circuitry almost as completely separate systems. A dedicated isolation boundary divides the board into two sections. The only intentional signal path crossing that boundary is an optocoupler.

"An optocoupler is a way of galvanic isolation meaning there is no actual direct connection between these two halves. It is just and only a connection by light."

The relay control signals pass through an optocoupler before driving the ULN2003 relay driver.

This ensures that electrical disturbances from the relay side cannot directly propagate into the processor circuitry.

Even power supplies were separated.

Two isolated DIN rail power supplies were used: one dedicated to logic electronics and another for relay operation.

"We're truly isolated."

The resulting architecture begins to resemble industrial control hardware far more closely than the original all-in-one design.

The Device Tree Learning Curve

One of the most educational aspects of the project came from the software side.

Developers accustomed to Arduino or Raspberry Pi ecosystems often expect GPIO pins to work immediately.

The PocketBeagle 2 takes a more embedded Linux approach.

GPIO functionality must first be defined through device tree overlays.

"The apparently simple job of making a GPIO output starts involving device trees, pin multiplexing and the details of the underlying SoC."

Because the AM6254 allows pins to serve multiple functions, Linux must be explicitly told how they are being used.

Clem candidly describes the experience:

"Device tree overlays are very intimidating and complicated and I don't even halfway know what I actually did there."

Once configured correctly, however, the flexibility becomes apparent. Linux gains direct access to GPIO, ADC resources and other processor features while still allowing PRU-based realtime control.

That flexibility is one of the PocketBeagle 2's greatest strengths, but it comes with a significantly steeper learning curve than many maker platforms.

Working with the Onboard ADC

The analogue subsystem proved much more straightforward.

Clem exposed four ADC channels and demonstrated how Linux can read them directly through the Industrial I/O framework.

The Python implementation is refreshingly simple.

ADC_PATH = "/sys/bus/iio/devices/iio:device0"
VREF = 1.8
ADC_MAX = 4095

return (raw / ADC_MAX) * VREF

Raw readings are collected from Linux system files and converted into voltages using the 12-bit ADC range. The implementation continuously reads all four channels and reports both raw counts and calculated voltages.

This direct ADC access became a key part of the final demonstration.

A Useful Failure

Unfortunately, not everything worked perfectly.

One of the relay isolation circuits exposed a design mistake.

The optocouplers were treated like standard logic devices rather than LED-driven isolation components.

Current-limiting resistors had been omitted.

"With a 3.3 volt logic level I should have used a 330 ohm resistor."

The result was that the optocoupler LEDs never switched fully off once activated.

"Once the LED activates for the first time it sits there drawing current at about two volts and never deactivates again."

The relays therefore refused to operate correctly during the final demonstration.

Rather than hide the mistake, Clem used it to illustrate a reality of professional hardware development: unfamiliar parts frequently behave differently from assumptions made during schematic capture.

Testing, redesign and verification are fundamental parts of the engineering process.

Live Colour Detection Demo

For the final demonstration, the PLC uses its analogue inputs, USB subsystem, Linux environment and networking stack simultaneously.

A USB webcam streams video into OpenCV while two analogue channels control detection parameters.

One analogue input selects the target hue while another sets the intensity threshold.

The software converts ADC values into colour detection parameters in realtime.

application_hue = int(
    (raw / ADC_MAX) * 255
)

opencv_hue = int(
    (application_hue / 255) * 179
)

A value of 150 corresponds approximately to blue, allowing trim potentiometers wired to the PLC to tune colour detection while the system is operating.

The software analyses webcam imagery, performs HSV filtering, calculates contour sizes and overlays detection results on the live image.

Results are then streamed over the network using a built-in web server.

During testing, Clem adjusted the analogue inputs live while watching colour detection track the blue colour of his shirt.

"We can set the hue and the saturation with these analogue potentiometers on the fly and observe the stream over the network."

The demonstration neatly combines nearly every subsystem available on the PLC.

So Why Are PLCs So Expensive?

By the end of the project, Clem's original question had evolved considerably. The first board genuinely supports the argument that many PLCs appear to be little more than a processor, some I/O and a box.

The second board reveals the hidden engineering. Isolation barriers. ESD protection. Current limiting. Optocouplers. Power integrity. Analogue layout. Device tree configuration. Mechanical integration. Realtime processing. Redundancy. Testing. Verification.

None of these individually seem particularly dramatic. Together they account for a substantial amount of engineering effort.

"Now that we know how incredibly difficult it is to make a real PLC, a system that has redundancy, safety, watchdogs and all these constructive features to make the relays safe and all the connections and inputs reliable, I think we can appreciate that sometimes they just have to cost more."

That does not mean every industrial PLC automatically represents good value. It does demonstrate that the real complexity often lies in the details that nobody notices until they are missing. Clem set out to build a PLC to understand where the money goes. What he discovered is that making something look like a PLC is relatively easy.

Building something that begins to behave like a professional industrial controller is a completely different challenge.

Supporting Files and Links

- Episode 728 Resources - Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

Bill of Materials

Product Name	Manufacturer	Quantity	Buy Kit
Optocoupler, Darlington Output, 4 Channel, DIP, 16 Pins, 50 mA, 5.3 kV, 500 %	ISOCOM	1	Buy Now
USB Connector, USB Type A, USB 2.0, Receptacle, 4 Ways, Through Hole Mount, Vertical	multicomp	2	Buy Now
Wire-To-Board Terminal Block, 5.08 mm, 3 Ways, 30 AWG, 12 AWG, 3.31 mm², Screw	würth	9	Buy Now
Plastic Enclosure, DIN Rail, Polycarbonate, 90 mm, 105 mm, 58 mm, IP20	Hammond	1	Buy Now
Pin Header, Board-to-Board, 2.54 mm, 2 Rows, 40 Contacts, Surface Mount	Multicomp pro	2	Buy Now
Development Kit, PocketBeagle 2, AM6254, ARM Cortex-A53 / Cortex-M4F	beagleboard	1	Buy Now
Flash Memory Card, MicroSDHC Card, 16 GB, Class 10, UHS-I U1, A1	integral	1	Buy Now
DARLINGTON TRANSISTOR ARRAY, SOIC-16	onsemi	1	Buy Now
General Purpose Relay, ORWH Series, Power, Non Latching, SPDT, 5 VDC, 10 A	TE	4	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, 1 Output, 15 W, 5 VDC, 3 A	meanwell	1	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, Industrial & Household, 1 Output, 15 W, 5 VDC, 3 A	multicomp pro	1	Buy Now
USB Interface, USB Hub Controller, USB 2.0, 3 V, 3.6 V, QFN, 36 Pins	microchip	1	Buy Now
ETHERNET ADAPTER, USB3.0 GIGABIT WHI		1	Buy Now
DIN Mounting Rail, DIN Mounting Rail, Racks & Cabinets, 1 m, 7.5 mm, 35 mm, Steel		1	Buy Now
TVS Diode, WE-TVS, Unidirectional, 5 V, 6.8 V, SOT-23, 6 Pins	würth	4	Buy Now
MIC2025	Microchip	2	MIC2025

Additional Parts

Product Name	Manufacturer	Quantity
Crystal and caps for the usb2514→ 24MHz
usb current control ICs + mosfets

Tags: plc, kicad pcb design, pocketbeagle 2, embedded linux, am6254, e14presents_mayermakes, analogue inputs, optocoupler, USB2514, industrial automation, diy plc, industrial control systems, programmable logic controller, ti sitara, friday_release, galvanic isolation, realtime linux

Trinamic Open Source Ventilator (TOSV) Teardown: An Open Hardware Approach to Medical Ventilation -- Episode 460

cstanton — Thu, 20 Aug 2026 16:13:00 GMT

Current Revision posted to Documents by cstanton on 8/20/2026 4:13:00 PM

Rather than presenting a typical maker build, Clem's examination of the Trinamic Open Source Ventilator (TOSV) focuses on a project created during a period when hospitals worldwide were facing unprecedented demand for respiratory support equipment. The TOSV initiative was conceived as a fully open-source reference design that could be manufactured locally and developed collaboratively, while still pursuing the level of engineering discipline expected of medical equipment. The project combines a Raspberry Pi 4, Trinamic motion-control technology, precision pressure sensing, and an openly available hardware and software stack.

Breathe Deep and Dive In

www.youtube.com/watch

Why an Open-Source Ventilator?

From the outset, Clem is careful to distinguish this project from the many emergency breathing-assistance concepts that appeared during the COVID-19 pandemic. He highlights a concern that runs throughout the entire teardown: a ventilator is not merely a motor pushing air through a tube.

"Ventilation is a very complicated topic. It's not trivial at all."

He explains that many people associate artificial respiration with emergency first aid, but a ventilator intended for patients suffering from lung damage operates on an entirely different level. Pressure, airflow, oxygen mixing, timing, lung response, and patient safety must all be carefully managed.

"If you ventilate or respire a patient that has damaged lungs even in the slightest wrong way, you will possibly kill him or her or at least damage the lungs further."

This perspective informs every design decision within the TOSV project. Rather than producing a quickly assembled emergency device, Trinamic's goal was to create an open-source platform capable of moving towards medical certification while remaining accessible to manufacturers around the world.

Motion Control Meets Medical Engineering

Trinamic built its reputation around precision motor control, particularly through the TMC family of motion-control devices widely used in industrial equipment and 3D printers. Clem points out that a ventilator is fundamentally a motion-control problem: a motor must react continuously to changing sensor inputs while maintaining strict operating limits.

"They are specialists in motion control and motion control is what these ventilators are doing."

Rather than driving a motor at a constant speed, the system processes live pressure data and dynamically adjusts airflow. Incoming air pressure, oxygen injection, patient breathing characteristics, and exhaust pressure are continually monitored.

"The device reacts dynamically to all these sensory data."

According to Trinamic's published material, the design uses the TMC4671-LA servo controller together with the TMC6100 gate driver to control the blower assembly, forming the heart of the ventilator's closed-loop control system.

Hardware Architecture

The teardown reveals a design that balances accessibility with functionality. The main enclosure consists of 3D-printed components combined with laser-cut acrylic panels, allowing the internals to remain visible during development and demonstration.

"The main body is 3D printed and it has acrylic laser cut panels so you can see the inside."

At the centre of the system sits a Raspberry Pi 4, responsible for user interaction and higher-level control. Attached to the Pi is a 7-inch Raspberry Pi touchscreen alongside Trinamic's custom controller board.

"The main brains of the project is a Raspberry Pi 4."

Mounted above the motion-control hardware is a pressure-sensing subsystem which, at the time of filming, still relied on hand-assembled sensor hardware. Trinamic was already preparing production-ready versions of the sensor board so manufacturers could reproduce the complete design using the released design files.

The project's openness extends beyond the firmware. Mechanical CAD, PCB layouts, software, and supporting documentation are all intended to be freely available for local manufacture and adaptation.

Precision Sensors Over Improvisation

One of the most important observations in the teardown concerns the pressure sensors. Rather than relying on improvised sensing arrangements, the system uses medical-grade, high-accuracy sensors that represent a substantial proportion of the overall cost.

"These are the most expensive items in the BOM."

"They are high precision and they are suitable for these medical applications."

Clem repeatedly stresses that the project avoids estimated behaviour and unverified assumptions. Pressure targets, volume targets, and safety parameters can all be measured and controlled directly by qualified operators.

"There is no guesswork involved. It's science and doctors can at any time control the whole process."

This commitment to measured feedback is reflected throughout the firmware architecture. Configuration structures include dedicated parameters for pressure regulation, volume regulation, PEEP management, inhalation and exhalation timing, and multiple PID control loops. For example:

uint16_t pidPressure_P_param;
uint16_t pidPressure_I_param;

uint16_t pidVolume_P_param;
uint16_t pidVolume_I_param;

uint32_t pPEEP;
uint32_t volumeMax;

The firmware also exposes functions dedicated to pressure management:

bool bldc_setTargetPressure(uint8_t motor, int32_t pressure);
int32 bldc_getActualPressure(uint8_t motor);
int32_t bldc_getPressureErrorSum(uint8_t motor);

These interfaces illustrate that pressure regulation was treated as a primary control objective rather than a secondary measurement, aligning closely with Clem's emphasis on accuracy and repeatable operation.

A Proper Ventilator, Not a Bag-Squeezer

During the teardown, Clem contrasts the TOSV with a common category of pandemic-era projects built around mechanically compressing manual resuscitation bags. While useful for emergency concepts, those approaches face significant limitations when precise respiratory control is required.

"It's not just any blower fan or these bags that you see often in ventilation projects where you just squeeze the bags."

Instead, the TOSV employs a blower-based system similar in concept to respiratory devices used in clinical and assisted-breathing applications. The fan is controlled through closed-loop motor control, allowing pressure and airflow characteristics to be adjusted continuously rather than mechanically approximated.

The wider open-hardware ecosystem surrounding the project also produced alternative mechanical implementations, including turbine-based enclosure concepts developed by the community around the TOSV electronics platform.

Intelligent Patient Interaction and User Interface and Safety Systems

One of the most revealing sections of the teardown occurs when Clem briefly experiences the machine himself. Rather than forcing airflow at a fixed rate, he notices how the device responds to breathing effort and gradually influences the user's respiratory rhythm.

"It doesn't force the air into my lungs."

"It's a very intelligent device that dynamically adapts to the person that is breathing with it."

This observation highlights a design aspect that is easy to miss when looking only at schematics: the ventilator is intended to cooperate with the patient rather than simply overpower the respiratory system. Achieving that behaviour requires the interplay of sensors, control algorithms, motor regulation, and carefully tuned operating parameters.

The touchscreen interface provides immediate access to operating data as well as clinician configuration settings. Clem notes that the software presents critical information clearly while also incorporating safeguards against accidental misuse.

A particularly interesting example is the shutdown procedure. Stopping the machine requires intentionally pressing and holding the command rather than tapping a button accidentally.

"I have to tap on there and leave it there for a set amount of time before I can switch it off so you don't switch off a patient by accident."

Alarm handling and calibration reminders are also built into the design.

"The unit also complains about any anomalies and alarms the user."

"It also complains that it hasn't been calibrated for a set period of time."

The system additionally supports Ethernet connectivity, enabling remote monitoring capabilities and allowing clinical staff to review device status without being directly beside the machine.

Availability Over Exclusivity and Future Development Considerations

The primary objective of the project was never to outperform commercial ventilators. Clem repeatedly returns to a simpler goal: availability.

"The point with this device is not to be better than a currently available ventilator."

Instead, the design provides a path for manufacturers to build proven hardware locally when supply chains become constrained. As shown during the teardown, Trinamic released the CAD files, PCB files, firmware, software, and supporting documentation specifically to encourage broader adoption.

At the time the unit was examined, certification had not yet been completed, although development had been informed through consultation with doctors and respiratory specialists.

"Trinamic was in contact with a lot of doctors and specialists, especially for lung treatment."

Several future directions emerge from the discussion. Production-ready pressure sensor boards were still being finalised, alternative pressure sensors could potentially be supported to improve availability, and certification efforts would ultimately need to be pursued on a country-by-country basis.

Clem also identifies a broader ambition extending beyond ventilators alone:

"One day we should have an open source alternative for every crucial medical device."

Rather than viewing TOSV as a finished endpoint, he presents it as part of a larger movement towards openly documented, locally manufacturable medical technology that can be mobilised rapidly during future emergencies.

When this project first went live, it was the early years of what became a several year pandemic the likes of the generation had never seen. Trinamic released this hardware and its files in the hope that it supported those that needed it, and over time, the resources available to reproduce this were pulled.

The element14 Community has retrieved the files and repositories to allow you to be able to rebuild this project should you need to explore, experiment and invent. Understanding that this project does not hold as a validated, certified medical device.

But open source should be open, right?

Supporting Files and Links:

Episode 460 Resource Files - Trinamic Open Source Ventilator (TOSV) Teardown - Contains files for the Reference Design Board and archive of github repositories
Bonus Content: Trinamic Open Source Ventilator (TOSV)
Bonus Content: Trinamic Open Source Ventilator Project
Trinamic Open Source Ventilator

Product Name	Manufacturer	Quantity	Buy Now
Reference Design Board, TMC4671/TMC6100, Ventilators / Respirator System	Trinamic	1
RASPBERRY PI 4 MODEL B, CORTEX-A72, 8GB	Raspberry Pi	1	Buy Now
Daughter Board, Raspberry Pi 7" Touch Screen Display, 10 Finger Capacitive Touch	Raspberry Pi	1
MOTOR DRIVER, -40 TO 125DEG C (TMC4671-LA)	Trinamic	1	Buy Now
MOTOR DRIVER, -40 TO 125DEG C (TMC6100-LA)	Trinamic	1	Buy Now
PRESSURE SENSOR ADD-ON BOARD	Trianmic	1	Buy Now

Trinamic Open Source Ventilator (TOSV) Teardown

element14 Presents | About Clem | Project Videos

Tags: medical equipment, open-source, open-source software, respirator, healthcare, pressure sensor, clem, engineer, raspi, trinamic motion control, beatmungsgerät, trinamic, motor control, medical ventilator, e14presents_mayermakes, tmc4671, open source ventilator, beademing, raspberry pi 4, raspberry pi, covid-19, motion control, Raspberry Pi Touchscreen, engineering, tmc6100, medical, beatmung, diy ventilator, diy medical ventilator, motor driver, medical engineering, coronavirus, covid19, friday_release, sensor, Open-source Hardware, mayermakes, e14p_CMM

Trinamic Open Source Ventilator (TOSV) Teardown: An Open Hardware Approach to Medical Ventilation -- Episode 460

cstanton — Thu, 20 Aug 2026 16:05:37 GMT

Revision 8 posted to Documents by cstanton on 8/20/2026 4:05:37 PM

Breathe Deep and Dive In

www.youtube.com/watch

Why an Open-Source Ventilator?

"Ventilation is a very complicated topic. It's not trivial at all."

"If you ventilate or respire a patient that has damaged lungs even in the slightest wrong way, you will possibly kill him or her or at least damage the lungs further."

Motion Control Meets Medical Engineering

"They are specialists in motion control and motion control is what these ventilators are doing."

"The device reacts dynamically to all these sensory data."

Hardware Architecture

"The main body is 3D printed and it has acrylic laser cut panels so you can see the inside."

"The main brains of the project is a Raspberry Pi 4."

The project's openness extends beyond the firmware. Mechanical CAD, PCB layouts, software, and supporting documentation are all intended to be freely available for local manufacture and adaptation.

Precision Sensors Over Improvisation

"These are the most expensive items in the BOM."

"They are high precision and they are suitable for these medical applications."

"There is no guesswork involved. It's science and doctors can at any time control the whole process."

uint16_t pidPressure_P_param;
uint16_t pidPressure_I_param;

uint16_t pidVolume_P_param;
uint16_t pidVolume_I_param;

uint32_t pPEEP;
uint32_t volumeMax;

The firmware also exposes functions dedicated to pressure management:

bool bldc_setTargetPressure(uint8_t motor, int32_t pressure);
int32 bldc_getActualPressure(uint8_t motor);
int32_t bldc_getPressureErrorSum(uint8_t motor);

A Proper Ventilator, Not a Bag-Squeezer

"It's not just any blower fan or these bags that you see often in ventilation projects where you just squeeze the bags."

Intelligent Patient Interaction

"It doesn't force the air into my lungs."

"It's a very intelligent device that dynamically adapts to the person that is breathing with it."

User Interface and Safety Systems

A particularly interesting example is the shutdown procedure. Stopping the machine requires intentionally pressing and holding the command rather than tapping a button accidentally.

"I have to tap on there and leave it there for a set amount of time before I can switch it off so you don't switch off a patient by accident."

Alarm handling and calibration reminders are also built into the design.

"The unit also complains about any anomalies and alarms the user."

"It also complains that it hasn't been calibrated for a set period of time."

The system additionally supports Ethernet connectivity, enabling remote monitoring capabilities and allowing clinical staff to review device status without being directly beside the machine.

Availability Over Exclusivity

The primary objective of the project was never to outperform commercial ventilators. Clem repeatedly returns to a simpler goal: availability.

"The point with this device is not to be better than a currently available ventilator."

At the time the unit was examined, certification had not yet been completed, although development had been informed through consultation with doctors and respiratory specialists.

"Trinamic was in contact with a lot of doctors and specialists, especially for lung treatment."

Future Development Considerations

Clem also identifies a broader ambition extending beyond ventilators alone:

"One day we should have an open source alternative for every crucial medical device."

Final Thoughts

But open source should be open, right?

Supporting Files and Links:

Episode 460 Resource Files - Trinamic Open Source Ventilator (TOSV) Teardown - Contains files for the Reference Design Board and archive of github repositories
Bonus Content: Trinamic Open Source Ventilator (TOSV)
Bonus Content: Trinamic Open Source Ventilator Project
Trinamic Open Source Ventilator

Product Name	Manufacturer	Quantity	Buy Now
Reference Design Board, TMC4671/TMC6100, Ventilators / Respirator System	Trinamic	1
RASPBERRY PI 4 MODEL B, CORTEX-A72, 8GB	Raspberry Pi	1	Buy Now
Daughter Board, Raspberry Pi 7" Touch Screen Display, 10 Finger Capacitive Touch	Raspberry Pi	1
MOTOR DRIVER, -40 TO 125DEG C (TMC4671-LA)	Trinamic	1	Buy Now
MOTOR DRIVER, -40 TO 125DEG C (TMC6100-LA)	Trinamic	1	Buy Now
PRESSURE SENSOR ADD-ON BOARD	Trianmic	1	Buy Now

Trinamic Open Source Ventilator (TOSV) Teardown

element14 Presents | About Clem | Project Videos

Trinamic Open Source Ventilator (TOSV) Teardown: An Open Hardware Approach to Medical Ventilation -- Episode 460

cstanton — Thu, 20 Aug 2026 16:04:56 GMT

Revision 7 posted to Documents by cstanton on 8/20/2026 4:04:56 PM

Breathe Deep and Dive In

www.youtube.com/watch

Why an Open-Source Ventilator?

"Ventilation is a very complicated topic. It's not trivial at all."

"If you ventilate or respire a patient that has damaged lungs even in the slightest wrong way, you will possibly kill him or her or at least damage the lungs further."

Motion Control Meets Medical Engineering

"They are specialists in motion control and motion control is what these ventilators are doing."

"The device reacts dynamically to all these sensory data."

Hardware Architecture

"The main body is 3D printed and it has acrylic laser cut panels so you can see the inside."

"The main brains of the project is a Raspberry Pi 4."

The project's openness extends beyond the firmware. Mechanical CAD, PCB layouts, software, and supporting documentation are all intended to be freely available for local manufacture and adaptation. 【4-e1d7a7】【5-b5e330】

Precision Sensors Over Improvisation

"These are the most expensive items in the BOM."

"They are high precision and they are suitable for these medical applications."

"There is no guesswork involved. It's science and doctors can at any time control the whole process."

uint16_t pidPressure_P_param;
uint16_t pidPressure_I_param;

uint16_t pidVolume_P_param;
uint16_t pidVolume_I_param;

uint32_t pPEEP;
uint32_t volumeMax;

The firmware also exposes functions dedicated to pressure management:

bool bldc_setTargetPressure(uint8_t motor, int32_t pressure);
int32 bldc_getActualPressure(uint8_t motor);
int32_t bldc_getPressureErrorSum(uint8_t motor);

A Proper Ventilator, Not a Bag-Squeezer

"It's not just any blower fan or these bags that you see often in ventilation projects where you just squeeze the bags."

Intelligent Patient Interaction

"It doesn't force the air into my lungs."

"It's a very intelligent device that dynamically adapts to the person that is breathing with it."

User Interface and Safety Systems

A particularly interesting example is the shutdown procedure. Stopping the machine requires intentionally pressing and holding the command rather than tapping a button accidentally.

"I have to tap on there and leave it there for a set amount of time before I can switch it off so you don't switch off a patient by accident."

Alarm handling and calibration reminders are also built into the design.

"The unit also complains about any anomalies and alarms the user."

"It also complains that it hasn't been calibrated for a set period of time."

The system additionally supports Ethernet connectivity, enabling remote monitoring capabilities and allowing clinical staff to review device status without being directly beside the machine.

Availability Over Exclusivity

The primary objective of the project was never to outperform commercial ventilators. Clem repeatedly returns to a simpler goal: availability.

"The point with this device is not to be better than a currently available ventilator."

At the time the unit was examined, certification had not yet been completed, although development had been informed through consultation with doctors and respiratory specialists.

"Trinamic was in contact with a lot of doctors and specialists, especially for lung treatment."

Future Development Considerations

Clem also identifies a broader ambition extending beyond ventilators alone:

"One day we should have an open source alternative for every crucial medical device."

Final Thoughts

But open source should be open, right?

Supporting Files and Links:

Episode 460 Resource Files - Trinamic Open Source Ventilator (TOSV) Teardown - Contains files for the Reference Design Board and archive of github repositories
Bonus Content: Trinamic Open Source Ventilator (TOSV)
Bonus Content: Trinamic Open Source Ventilator Project
Trinamic Open Source Ventilator

Product Name	Manufacturer	Quantity	Buy Now
Reference Design Board, TMC4671/TMC6100, Ventilators / Respirator System	Trinamic	1
RASPBERRY PI 4 MODEL B, CORTEX-A72, 8GB	Raspberry Pi	1	Buy Now
Daughter Board, Raspberry Pi 7" Touch Screen Display, 10 Finger Capacitive Touch	Raspberry Pi	1
MOTOR DRIVER, -40 TO 125DEG C (TMC4671-LA)	Trinamic	1	Buy Now
MOTOR DRIVER, -40 TO 125DEG C (TMC6100-LA)	Trinamic	1	Buy Now
PRESSURE SENSOR ADD-ON BOARD	Trianmic	1	Buy Now

Trinamic Open Source Ventilator (TOSV) Teardown

element14 Presents | About Clem | Project Videos

Project Video Release Archive

e14sbhargav — Thu, 20 Aug 2026 14:05:17 GMT

Revision 225 posted to Documents by e14sbhargav on 8/20/2026 2:05:17 PM

Project Video Releases

element14 presents | Meet the Hosts

Episode 728: Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

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

Episode 725: Clem's Workbench Upgrade to Automated Lab with Programmable Instruments and Python

Episode 724: Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics

Episode 723: Building a Privacy-First Workshop Security Camera with PocketBeagle 2

Episode 722: PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics

Episode 721: Designing a Smarter Workbench: Inside Mark’s 8-Channel Power Monitoring System

Episode 720: Building the Foundations of Your First Robot - An Introduction to Robotics

Episode 719: Turning a Broken Robot Vacuum into a Network-Controlled Raspberry Pi 5 Rover

Episode 718: Creating a Multi-Function ESP32 Desk Pet with Custom PCB and Audio Processing

Episode 717: Simulating Prey Vision with Raspberry Pi 5: A Dual Camera Perception Experiment

Episode 716: Designing a Mobile Robot Platform with Inverse Kinematics and Wireless Control

Episode 715: How to Build a Reaction-Based Catch Game Using Arduino and Relays

Episode 714: Find EMI Fast with a Low‑Cost, Automated Way to See Where Your PCB Radiates

Episode 713: How to Make an LED Sculpture React to Sound with micro:bit

Episode 712: Designing a More Capable Dual Motor Driver Beyond the L298N (What worked and what didn't)

Episode 711: Modern Edge AI on Raspberry Pi 5 for an Animatronic Tracker: Vision Acceleration with AI Hat+ and AI Camera

Episode 710: Your First Real PCB in KiCad : An Arduino Compatible Board Designed from Scratch

Episode 709: Was that my Number!? Fixing Café Order Chaos with a Raspberry Pi Announcer

Episode 708: Reviving a Vintage LED Sign with Arduino and PS/2 Control

Episode 707: Building a Circuit Sculpture with LED Filament

Episode 706: ESP32 + RFID = Smart Access Control in a Simple DIY Build

Episode 705: Building a Super Smooth Z-Scale Train Controller with Arduino

Episode 704: Hacking an IKEA Desk into a Programmable Electric Workstation

Episode 703: How to Set Up the Raspberry Pi 5: Complete Beginner Step-by-Step Guide

Episode 702: Build Your Own USB Looper for Serial Debugging and File Transfer

Episode 701: From Snooze to Launch: The Arduino-Powered LEGO Alarm Clock Inspired by Artemis 2

Episode 700: How Voice Recognition Works on Raspberry Pi (and Why It’s Easy to Break)

Episode 699: GimmeGPIO: A Simple Way to Get GPIO on Laptops and Desktops

Episode 698: Building a Practical Electronics Workbench for Makers and Engineers

Episode 697: A Smart, Safe 3D Printer Cabinet Using Raspberry Pi and Node-RED

Episode 696: How a Pulse Metal Detector Works, and How to Build One

Episode 695: A DIY Test and Programming Rig Built for Small-Batch Electronics Production

Episode 694: Earn Your Fitness Reward with a Smart Cookie Jar Using Strava and ESP32

Episode 693: Open-Source Multicolour 3D Printing Upgrade: Clem’s 3D Chameleon Remix

Episode 692: Build Your own ESP32 Fitness Heart Rate Monitor / Tracker

Episode 691: How Accurate Is Bluetooth Channel Sounding? A Deep Dive with the nRF54L15

Episode 690: Meet the PlatypusBot: Now Powered by Raspberry Pi & ROS

Episode 689: How Clem Built a Handheld Sci-Fi Communicator That Really Works

Episode 688: Building the Cylon Pumpkin: Combining a Larson Scanner and Vocoder for Halloween

Episode 687: Turning a $10 Air Fryer into an Arduino powered Filament Dryer

Episode 686: Creepy Motion-Activated Painting You Can Build Yourself

Episode 685: When Your Body Becomes the Instrument: Clem Builds the “Dröne” Synth

Episode 684: Building an Audio Reactive LED Matrix with a micro:bit and NeoPixels

Episode 683: How to Make a Portable Emergency Radio with an Arduino Nano in a Mint TinT

Episode 682: DIY RF Modulator + Raspberry Pi Pico = Gaming on a Sony Watchman FD-10A CRT

Episode 681: Turn anything into an Arduino Module: Reusing Everyday Electronics

Episode 680: From Kit to Custom Design: Building a Tube-Based FM Radio

Episode 679: ESP32 Duolingo Owl Project: Never Miss a Lesson Again

Episode 678: Open Source ATtiny3226 Arduino Calculator – Hardware, Case & Code Build

Episode 677: Make Your Own Vocoder with Teensy 4.0 - Voice of a Cylon?!

Episode 676: I Tried Building 16 ATtiny Robots with Vibration Motors – It Was a Disaster

Episode 675:Avoid Conflict with this ESP32 Defcon Task Tracker

Episode 674: Building an Open Source Blood Pressure & Heart Signal Monitor

Episode 673: Building an ESP32 Powered Warhammer 40k Rhino with Dynamic LED Effects!

Episode 672: Building an Autonomous LEGO Train with CircuitPython and LIDAR

Episode 671: PlatypusBot - Scavenging for Robotics Parts

Episode 670: Build your own Larson Scanner

Episode 669: Creating an ESD (Or Lightning!) Detector!

Episode 668: Designing an Arduino PID Controlled Micro Drone

Episode 667: Emulating a Speech Synthesis Chip with an ESP32

Episode 666: How Far Can I2C Go?

Episode 665: Raspberry Pi AI Tracking Eye of Sauron - AI AL Barad Dur

Episode 664: Learn how to Make a Photo Booth with the ESP32 and Telegram Automation!

Episode 663: Upcycling a Vintage Microphone into an Emergency Radio System

Episode 662: Making a Stronger Affordable DIY Robot Arm with 3D Printing with Raspberry Pi Pico

Episode 661: Clem makes his own LED Wristwatch

Episode 660: LoFi Beats to Solder To

Episode 659: DIY Single Board Computer with ESP32 and Raspberry Pi Pico

Episode 658: A Smart Youtube Counter With An Audio Analyzer

Episode 657: How to Control a LEGO Mindstorms kit with AI and Raspberry Pi 5

Episode 656: DIY Jig for your Laser Cutter with Custom Arduino Automation

Episode 655: DIY Hot Plate for SMD Soldering Using Raspberry Pi Pico

Episode 654: How Do BattleBots Work? In the Pit with HyperShock

Episode 653: Edge-lit 7-Segment Display Clock Using Raspberry Pi Pico

Episode 652: Smart Windows and Blinds with Arduino and Raspberry Pi Pico

Episode 651: Design for Manufacturing - Project to Product by Modifying Off-the-Shelf Cases

Episode 650: Using Nordic's nRF7002, My Dehumidifier Tells Me When It's Full!

Episode 649: Giant Retro Gaming Magic Mirror with a Raspberry Pi 5!

Episode 648: Home AI Image Generation Server with LattePanda and Stable Diffusion

Episode 647: Building an Open-Source Tool for Cave Surveying

Episode 646: Creating a Digital Roulette Table with an ESP32 DevKit

Episode 645: Practical DIY Pi Pico Current Load Circuits

Episode 644: Turning a Raspberry Pi Pico into a GPU!

Episode 643: Making a Tribble that Detects Klingons

Episode 642: Making a Time-lapse Camera with a Raspberry Pi 5

Episode 641: Moon Phase Display with Raspberry Pi Pico

Episode 640: Tinkering vs Engineering: Can You Build a Laptop from Scratch?

Episode 639: Off-Grid Remote Generator Starter?

Episode 638: RP2040 PCB: Design, Turn-On, and Debug - How Hard Could It Be?

Episode 637: Making Music with a Lego Guitar and Capacitive Touch

Episode 636: Creating an IMU based 3D Mouse with an ESP32-S3

Episode 635: Vintage Electronics Exploration with a Bally Cypress Gardens Bingo Machine

Episode 634: Craft a Festive LED Christmas Sweater Featuring the ATtiny416

Episode 633: Spying Under the Christmas Tree with an Arduino-powered Ornament

Episode 632: Revamping Old School Pinball with an ESP32

Episode 631: All-Purpose Debugging: A Practical Universal Screen with LCD Displays

Episode 630: Mega IIe: First Fully Functional Computer built around the Apple Mega-II Chip

Episode 629: Backpack Splash: Mark's Water Gun Upgrade for Epic Outdoor Water Wars!

Episode 628: Affordable DIY Robot Arm - A Deep Dive into 3D Printing and Servo Motors

Episode 627: Creating sudostick - From Prototype to Product

Episode 626: Catching you Up on Bonesnapper Ridge - Off-Grid Maker Shop

Episode 625: Interactive Magic - Creating an Enchanted Cauldron

Episode 624: Modding A Smoke Machine to Add Motion Detection

Episode 623: How to Run Linux on an ESP32

Episode 622: Building Spooky Fun: Halloween Sound Pranks with nRF 5340 BLE Audio

Episode 621: Color Sensor-Based Water Quality Tracker: DIY Environmental Monitoring

Episode 620: Stey-by-Step Guide to Creating your own Speaking Animatronic Hat

Episode 619: How to Build an Open Source Bluetooth Mechanical Keyboard

Episode 618: Upgrading My Racing Sim with a Force-Sensitive Keyboard

Episode 617: Simplify Network Monitoring: Building an ESP32-Powered Solution

Episode 616: Mastering Oven Control: Precision Resin Curing with DIY Modifications - How Hard Can it Be?

Episode 615: Building a Unique USB Card Reader: From Idea to Prototype

Episode 614: Using PID (Proportional-Integral-Derivative) in Robotics - How Hard Could It Be?

Episode 613: Building a Magic Wand Talking Sound Board

Episode 612: Handheld BASIC computer in Badge Format with the Arduino Uno

Episode 611: How to Run the Distance to the Moon with Strava Data and a Pico W Board

Episode 610: How to Embroider with Circuits and Conductive Thread

Episode 609: Updating a Fujitsu N860-2500-T111 Keyboard to Work with a PS2 Standard

Episode 608: Making the Simplest DIY Wind Energy Generator - How Hard Could it Be?

Episode 607: From Strava to Motion: Creating an Arduino-Powered Arcade Game with Running Data

Episode 606: How to Use LoRaWAN to Launch Model Rockets Wirelessly

Episode 605: Arduino and LEDs Make Solitaire Easier to Solve

Episode 604: Charlieplexing Buttons and LEDs at the Same Time - How Hard Can It Be?

Episode 603: Create Your Own Air Hockey Table with Arduino Scoring

Episode 602: DIY AC Dimmer Circuit: Control Your Lights with a Raspberry Pi Pico

Episode 601: How to Reverse Engineer Electronics: Building a Developer Board for a Coding Class

Episode 600: Building My Dream Digital Clock: DIY 7 Segment Display with a Cute Robot Twist!

Episode 599: How to Build a Spectrum Analyzer with Lego Bricks & Discrete Electronics

Episode 598: How To Build a Portable, Solar-Charged Off-Grid Power Station

Episode 597: How to Build a Robot that Celebrates Good Grades with Arduino

Episode 596: How to Build Your Own Voice Assistant with MyCroft AI - How Hard Can It Be?

Episode 595: Member Challenge Accepted - Universal LANC Controller for DSLR cameras

Episode 594: Repairing a Neewer 660 Studio light - How Hard Can It Be?

Episode 593: Playing 3D Famicom Games Wirelessly on the NES - How Hard Could It Be?

Episode 592: Lamptopus: Spinning LED Desk Lamp

Episode 591: Building A Bluetooth Speaker in 5 Minutes - How Hard Can It Be?

Episode 590: Seven Kingdoms Open Source Bartop Arcade

Episode 589: Upgrading the iMac G4 With a NUC

Episode 588: Highlights from element14 presents 2022

Episode 587: Create Your Own Talking Stress Indicator

Episode 586: DIY Open Source Bluetooth Headphones

Episode 585: Enhancing a Magnifying Headband with Auto Sensing Light

Episode 584: Going Beyond Periodic Wakes: Using WiFi to Revive a Sleeping Device

Episode 583: Epic Neopixel Birthday Cake

Episode 582: Smart Christmas Decoration with Raspberry Pi Pico and MQTT

Episode 581: Bee-Saving Electronics Prototype

Episode 580: DIY Low Cost Capacitance Meter Using a 555 Timer

Episode 579: How to Make a Basketball Auto Score Keeper Using Colour Sensing

Episode 578: Build your Own Bat Detector with Analog Parts

Episode 577: The Game Guy Mini, Upgrading the Unportable Game Boy!

Episode 576: Build your own Underwater Drone with 3D Printed Parts

Episode 575: How to Make a Secured Parcel Pickup Box with Arduino

Episode 574: Ghost Rider Halloween Costume

Episode 573: Using a Pi Pico to Convert Keyboard Input to Morse Code

Episode 572: How to Use an ESP32 & Camera to Know You've Got Mail!

Episode 571: Using Dead Batteries to Test for Dead Batteries

Episode 570: Making a WiFi Connected Audio Spectrum Analyzer with ESP32

Episode 569: Multi-Spectrum UV Resin Curing Station with Würth LEDs

Episode 568: How to Make a Custom Soundboard with the STM32F4 using FreeCAD

Episode 567: Synced NeoPixel Mickey Mouse Ears

Episode 566: How to Automate Industrial Welding Positioners with Arduino

Episode 565: Measuring Destructive Testing Force with a 20 Ton Hydraulic Press

Episode 564: Build a VU Meter with LED Pixelated Nixie Tubes

Episode 563: Creating Augmented Reality Circuits with Meta Quest 2 and Unity

Episode 562: Pi Home Temperature Monitoring System

Episode 561: WiFi to Parallel Port Ascii Art Dot-Matrix Printer

Episode 560: Raspberry Pi Controlled Lego Train with Build HAT

Episode 559: Create a Magic Makeup Mirror with Pose Detection

Episode 558: 3D Object Rendering Using an FPGA

Episode 557: Create your own Handheld Serial Monitor for Project Debugging

Episode 556: Hacking a Hotel POS Tablet - How Hard Can it Be?

Episode 555: Dance Central Pose Estimation Game with Tensorflow and Raspberry Pi

Episode 554: Arduino Uno Mini Limited Edition LED Necklace

Episode 553: Adding a Parallel Printer Port to an Android Phone

Episode 552: Magical Potion Bottle Rack

Episode 551: Can We Rebuild a 1930s Accounting Machine?

Episode 550: DIY Electronic Controlled Motorized Wheelchair

Episode 549: Using a Teletype Machine as a USB Printer with Arduino

Episode 548: Electronic Fidget Cube, Building Your Ideas!

Episode 547: Creating a “Mummy” Wake Word Detector with Raspberry Pi and Edge Impulse

Episode 546: Mapping the Outputs of a 1960s Teletype Machine - How Hard Can it Be?

Episode 545: Designing a Custom PCB for Microsoft Jacdac

Episode 544: Reviving the 1984 IBM 5155 - How Hard Can It Be?

Episode 543: Lego Spike Prime Weather Station with Raspberry Pi

Episode 542: A Noise-Free DIY Switching Power Supply - How Hard Can It Be?

Episode 541: Vintage Laptop Battery Replaced with USB Power - How Hard Can It Be?

Episode 540: Object Detection for Smart Recycling

Episode 539: Training a Machine to Recognize Objects - How Hard Can It Be?

Episode 538: How to Build a Quadruped Robot - NO MATH!

Episode 537: Build a Phonograph Preamplifier - How Hard Can It Be?

Episode 536: Interactive Light-Up Window with Pose Detection using a Raspberry Pi and micro:bit

Episode 535: Repair a Sega Game Gear - How Hard Can It Be?

Episode 534: Open Source Inventory Warehousing System

Episode 533: Jumbo DIY LED

Episode 532: World’s First Single-Chip Apple II Boots!

Episode 531: Game Guy - The Unportable Game Boy

Episode 530: MQTT controlled LED Christmas Baubles with Raspberry Pi Pico

Episode 529: UPDI Program for new ATTiny

Episode 528: Let's Build an Electronic Fidget Cube!

Episode 527: Interactive Light Up Window using a Raspberry Pi and micro:bit

Episode 526: CNC Router Remote Control

Episode 525: DIY Helmholtz Snow Globe

Episode 524: Arduino IoT Cloud Weather Station

Episode 523: Make your Own Auto-Sensing Solder Fume Extractor

Episode 522: Siren Head Halloween Wearable Costume

Episode 521: DIY Static Grass Applicator

Episode 520: Adding Android Auto as Non-Permanent Add-On with Raspberry Pi

Episode 519: Make Your Own Ye Olde Book Nook Diorama with Arduino

Episode 518: Guitar Vacuum Tube Distortion Pedal

Episode 517: Emulate an EPROM - How Hard Could it Be?

Episode 516: Modding a Wireless Doorbell with Raspberry Pi and ESP8266

Episode 515: Upcycling a Lenovo PC into a Raspberry Pi WiFi Access Point

Episode 514: Making a 3D Graphics Card for the Atari 800 XL

Episode 513: Bike Speedometer with Arduino and GPS

Episode 512: You Cannot Buy This Vacuum Tube Tester. You Build It!

Episode 511: Raspberry Pi Powered Cheeseball Launcher

Episode 510: Laser Cutter Command Station

Episode 509: DIY Discrete Logic LED Countdown Timer

Episode 508: Raspberry Pi FPV Rover Easy Robot Arm Upgrade

Episode 507: Massive Raspberry Pi

Episode 506: DIY Star Trek Tricorder from Build Inside the Box

Episode 505: Super 8 Camera Digitizer

Episode 504: DIY Sump Pump Alarm

Episode 503: Meet Cheesoid - The Robot That Smells!

Episode 502: Make Your Bike a Pokebike!

Episode 501: Raspberry Pi NFC Button-Free Music Player

Episode 500: Build Inside The Box Challenge!

Episode 499: DIY Four Channel Arduino Servo Tester

Episode 498: Raspberry Pi Smart Water Dispenser

Episode 497: RFID Pocket Money Keeper

Episode 496: Compute Module 4 Powered 3D Printer Board

Episode 495: Magic GIF Ball Powered By Raspberry Pi

Episode 494: Keyboard Shortcuts Keypad with Raspberry Pi Pico

Episode 493: NeoPixel 7 Segment Display Clock Update

Episode 492: Arduino vs 555 Timer - Tiny Slot Car Racers

Episode 491: Arduino Single-Wheel Balancing Robot

Episode 490: DIY Raspberry Pi Pico Fizz Buzz Multiplication Game

Episode 489: Build An FPV Rover with Raspberry Pi

Episode 488: DIY Raspberry Pi Cyberdeck

Episode 487: DIY MagSafe Battery Charger

Episode 486: Make The Ultimate Phone Charging Camping Flashlight

Episode 485: How To Make A Custom PCB From Design To Assembly

Episode 484: Raspberry Pi Bird Watching Camera

Episode 483: DIY Miniature Multimeter

Episode 482: Gigantic 3D Printed 7 Segment Display Clock

Episode 481: DIY LOST Swan Station Split Flap Display Timer

Episode 480: DIY Toothbrush Timer

Episode 479: Raspberry Pi 2XL Robot Assistant Part 2

Episode 478: Upgrading A Christmas Train

Episode 477: Metal Plate Your 3D Prints with a DIY Galvanizing Machine

Episode 476: IoT Arduino NTP World Clock with SPI Display

Episode 475: DIY Wall Mounted Arduino Barometer

Episode 474: Continuum Robot Tentacle Prototype

Episode 473: Mendel 3D Printer Upgrade and Maintenance

Episode 472: DIY Hydration Reminder System

Episode 471: DIY Dance Dance Revolution Mat

Episode 470: Voice Activated Inspector Gadget Hat

Episode 469: Nintendo Super Scope Modded For Modern Televisions

Episode 468: Socially Distanced Halloween Candy Dispenser

Episode 467: Repairing the World's First Laptop! (Epson HX-20)

Episode 466: Arduino-powered Hexadecimal Color Code Clock

Episode 465: Lego Raspberry Pi HQ Camera

Episode 464: Particle Voice Recognition for Home Appliances

Episode 463: Raspberry Pi Speech to Text LED Face Mask

Episode 462: Joycon Controlled Electronic Rock'Em Sock'Em Robots

Episode 461: Portal 2 Security Camera with Raspberry Pi 2

Episode 460: Trinamic Open Source Ventilator (TOSV) Teardown

Episode 459: Raspberry Pi 4 VR Conference Call Assistant

Episode 458: DIY Arduino Automated Metal Bending Machine

Episode 457: Raspberry Pi 4 Animatronic Rosie the Robot from the Jetsons

Episode 456: Unhackable Arduino Switch Matrix

Episode 455: Arduino Unit Conversion Calculator

Episode 454: Soldering Up the rc2014 Homebrew Z80 Computer Kit

Episode 453: Build an Anti-Troll Bot Using TensorFlow and Arduino

Episode 452: Raspberry Pi 4 Experimental Resin 3D Printer Updated!

Episode 451: Build an Off Grid Wikipedia with Raspberry Pi

Episode 450: Sega GameGear Rebuild with LEDs

Episode 449: DIY Tamagotchi - Build a Virtual Pet

Episode 448: DIY Raspberry Pi 4 Boxing Game

Episode 447: DIY Stop Motion Rig with LattePanda

Episode 446: Raspberry Pi 2XL Robot Assistant Part 1

Episode 445: Raspberry Pi 4 Animatronic BD-1 Companion Robot

Episode 444: Raspberry Pi 4 DVR

Episode 443: Arduino Uno RC Remote - Can It Be Done?

Episode 442: Make Your Own Giant Servo

Episode 441: Raspberry Pi 4 International Space Station Tracker

Episode 440: DIY Arduino Helicopter Collective Joystick Control

Episode 439 - Mechanical Arcade Game with Barebones Arduino

Episode 438: Smartphone Controlled DIY Rover Using Websockets

Episode 437: DIY Motorized Zoom for Your DSLR

Episode 436: Automated Raspberry Pi Planet Tracking GOTO Telescope

Episode 435: Raspberry Pi 4 Music Player w/Analog Controls

Episode 434: Infineon Smart City Model

Episode 433: Arduino Based Love Tester

Episode 432: Super FX Sword using the BBC micro:bit

Episode 431: Room-Sized Studio Light Speakers Combo

Episode 430: Flaming Xylophone Rubens' Tube

Episode 429: YouTuber "On Air" Light with Particle Mesh Network

Episode 428: Raspberry Pi 4 CRT-based VR Headset

Episode 427: DIY Retro Gaming Portable on a Budget!

Episode 426: Retro TV Ads Holiday Ornament

Episode 425: Make Your Own Raspberry Pi 4 Photobooth!

Episode 424: DIY Escape Room Puzzle

Episode 423: Programmable Arduino Synthesizer Watch

Episode 422: Raspberry Pi E-Ink Task Organizer

Episode 421: Raspberry Pi 4 Commodore SX-64 Inspired Portable Computer

Episode 420: DIY Shapeoko CNC Pendant

Episode 419: Altair 8800 Laptop

Episode 418: Animatronic Terminator Skull with BeagleBone® AI

Episode 417: #Pipboy 2000 Mk II

Episode 416: DIY #3DPrinted Label Spooler

Episode 415: Iron Man Helmet Heads Up Display

Episode 414: Raspberry Pi 4 Experimental Resin 3D Printer

Episode 413: Animatronic Claptrap Case Mod Part 2

Episode 412: Get to Know Your ADC with a DIY Temperature Probe

Episode 411: Animatronic Claptrap Computer Case - Part 1

Episode 410: MacPro G5 Cheese Grater with Raspberry Pi 4

Episode 409: Commodore SX-64 Restoration

Episode 408: Hand Soldered LED Oscilloscope

Episode 407: The Ultimate Raspberry Pi 4 Laptop

Episode 406: Automated Robot Artist

Episode 405: RC Ornithopter Concept

Episode 404: Arduino Powered Close Encounters Midi Light Board

Episode 403: Upcycled IoT Coffee Pot Ramen Maker

Episode 402: PiPhone++ The Giant Raspberry Pi Flip Phone

Episode 401: Matrix Voice Controlled Robot

Episode 400: The Ultimate Raspberry Pi Stress Test

Episode 399: Candle-Powered Robotl

Episode 398: Let Me Out Hooman! Bluetooth Dog Doorbell

Episode 397: Steam Powered Retropie Console

Episode 396: Arduino Retro LED Matrix Handheld

Episode 395: Raspberry Pi Stop Motion Machine

Episode 394: Animatronic GLaDOS Head with Raspberry Pi

Episode 393: GameBoy Walkman

Episode 392: Multi-Line Telephone Intercom

Episode 391: First Person View RC Car with PS2 Steering Wheel

Episode 390: Retro Texting Smart Watch of the Future!

Episode 389: PlayStation Classic Portable Prototype

Episode 388: FPGA MIDI Music Synthesizer

Episode 387: Rotocell - The Rotary Cell Phone of the Future!

Episode 386: Xybernaut Wearable PC

Episode 385: 20 PCB Design Pitfalls

Episode 384: Retro Gaming Handheld Without a PCB

Episode 383: Gameboy Wireless Link Cable (DMG1)

Episode 382: Modding a Super 8 Camera into a Digital

Episode 381: Reverse Music Box

Episode 380: NES Zapper on RetroPie

Episode 379: Macroscope Soldering Tool

Episode 378: Invader ZIM Animatronic GIR

Episode 377: Altair 8800 Replica

Episode 376: 4D Gaming with the Matrix Creator

Episode 375: Hacked Fetal Detector Music Synthesizer

Episode 374: Raspberry Pi Donkey Kong Holiday Ornament

Episode 373: Raspberry Pi Fallout Terminal PC

Episode 372: Raspberry Pi Auto Etch A Sketch™

Episode 371: FPGA "Game Genie" for Atari 2600

Episode 370: Raspberry Pi NOAA Satellite Receiver

Episode 369: Recreating the Atari Portfolio

Episode 368: Arduino Automatic Wire Cutter and Stripper

Episode 367: Most Useless IoT Device Ever - Part 2

Episode 366: Infinity Icosahedron

Episode 365: Twilight Zone Fortune Telling Machine

Episode 364: Raspberry Pi Virtual Reality Arcade #VR

Episode 363 - Add a Motor to your Bike with Arduino

Episode 362: Most Worthless IoT Device Ever Pt. 1

Episode 361: R.O.B Rebuild and Upgrade

Episode 360: Make Your Own Raspberry Pi Cell Phone

Episode 359: Make Your Own CNC Pyrography Wood Burner

Episode 358: The Shrimp of Terror!

Episode 357: Raspberry Pi Asteroid Tracker

Episode 356: Bank to the Future with Arduino & TI

Episode 355: Raspberry Pi Pirate Radio

Episode 354: Tiny Vacuum Forming Machine

Episode 353: Program Your Own FPGA Video Game

Episode 352: Pripyat - DIY Geiger Counter

Episode 349: Raspberry Pi Selfie Rocket

See All Previous Episodes

Tags: episode releases, friday_release_archive, element14 presents, project videos, episodes, friday releases, episode release archive, episode archive, friday release archive, project_videos

Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

cstanton — Thu, 20 Aug 2026 09:35:47 GMT

Revision 3 posted to Documents by cstanton on 8/20/2026 9:35:47 AM

Watch Clem Pocket the Industrialisation

Rather than speculate, he decided to build one.

As Clem puts it:

"Sometimes they are actually just an Arduino in a fancy box and some relays... but there are also legacy systems with big brand names and high price tags and these are built for reliability."

His goal was not to reproduce an industrial PLC exactly, but to understand where all that engineering effort goes.

Starting with an Open PLC Platform

Commercial PLCs often come with proprietary software ecosystems, vendor lock-in and long-term support guarantees. Clem wanted to approach the problem from a different direction.

Instead of using a dedicated PLC platform, he based his design around the PocketBeagle 2, a compact Linux-capable development board built around Texas Instruments' AM6254 Sitara processor.

What attracted him was the combination of high-level Linux functionality and low-level deterministic control.

"I wanted it to have serious capabilities. It should have realtime Linux support and it also should have a deterministic way of controlling the inputs and outputs."

Unlike many maker boards, the PocketBeagle 2 includes two Programmable Realtime Units (PRUs), effectively dedicated microcontroller-class cores integrated into the processor.

These can operate independently from Linux and are designed specifically for tasks that require predictable timing.

"We have the Linux controls around USB devices, high-level stuff like AI models and communication with networks and other devices, and then the PRUs can control all the inputs and outputs."

Clem even points out that the second PRU could act as a watchdog, redundancy controller or cross-checking processor, similar to techniques found in safety-oriented industrial equipment.

Version One: The Maker Approach

The first PLC design intentionally follows the path many hobbyists would take.

A Hammond DIN rail enclosure serves as the mechanical foundation, while a relatively simple two-layer PCB carries the electronics. The board includes:

PocketBeagle 2 controller
Microchip USB2514 USB 2.0 hub controller
Four analogue input channels
Four relay outputs
ULN2003 Darlington relay driver
Dual USB host ports
DIN rail mounting format

The PCB itself was designed quickly.

"I eyeballed the position of all the connectors and I tried to put as many features in here as possible."

Rather than spending days optimising every mechanical detail, the focus was on getting something functional into the enclosure as quickly as possible.

On paper, it looked remarkably capable. Unfortunately, industrial design concerns do not appear on a schematic until something goes wrong.

When "Works" Isn't Good Enough

The first design functions. For many projects, that would be a success.

For a PLC, however, functionality is only the starting point.

Clem soon began identifying weaknesses that would become serious problems in an industrial environment.

The first issue was electrical safety.

"There is no real isolation in the original design. In case something goes wrong there could potentially be 230 volts everywhere in the system."

The relay outputs are capable of switching mains-voltage loads, yet the control electronics existed dangerously close to circuitry carrying higher voltages.

Industrial equipment depends heavily on segregation between control electronics and power electronics. Without that separation, failures can have consequences far beyond a damaged PCB.

The USB implementation also lacked many of the protections expected in a commercial design.

The original version provided only the minimum necessary circuitry to make the USB hub operate.

There was:

No ESD protection
No overcurrent protection
No controlled fault response
No dedicated USB power monitoring

These omissions are common in maker projects because they are often invisible during normal operation. Industrial equipment, by contrast, must survive repeated abuse from the outside world.

Analogue routing presented another problem.

"I've routed my analogue ports right next to the relays. That will not work very good because they will couple into it."

Relay switching generates electrical noise. Placing sensitive ADC signals next to relay circuits creates opportunities for incorrect readings, instability and potentially damage.

These are exactly the sort of layout considerations that are easy to overlook when the first goal is simply getting a board manufactured.

Building a More Professional Controller

The second board revision demonstrates how quickly extra engineering effort accumulates.

Clem moved to a four-layer PCB, improved component selection, reworked the enclosure integration and fundamentally redesigned the relay section.

More importantly, he stopped trying to maximise feature count and instead prioritised reliability.

"I preferred having good layout instead of more features on there because that is what the professional world considers the most important bit. Safe and reliable operation."

The revised USB implementation became significantly more sophisticated.

Dedicated current-limiting circuitry and fault detection were added to protect both connected peripherals and the PLC itself.

"These have current control chips specifically ordered and they have to detect if something goes wrong so your device that you plug into these USB ports can't destroy the overall thing."

This redesign required additional board area, forcing the reduction from four easily accessible USB ports down to two.

That trade-off between capability and robustness appears repeatedly throughout industrial design.

Isolation the Right Way

"An optocoupler is a way of galvanic isolation meaning there is no actual direct connection between these two halves. It is just and only a connection by light."

The relay control signals pass through an optocoupler before driving the ULN2003 relay driver.

This ensures that electrical disturbances from the relay side cannot directly propagate into the processor circuitry.

Even power supplies were separated.

Two isolated DIN rail power supplies were used: one dedicated to logic electronics and another for relay operation.

"We're truly isolated."

The resulting architecture begins to resemble industrial control hardware far more closely than the original all-in-one design.

The Device Tree Learning Curve

One of the most educational aspects of the project came from the software side.

Developers accustomed to Arduino or Raspberry Pi ecosystems often expect GPIO pins to work immediately.

The PocketBeagle 2 takes a more embedded Linux approach.

GPIO functionality must first be defined through device tree overlays.

"The apparently simple job of making a GPIO output starts involving device trees, pin multiplexing and the details of the underlying SoC."

Because the AM6254 allows pins to serve multiple functions, Linux must be explicitly told how they are being used.

Clem candidly describes the experience:

"Device tree overlays are very intimidating and complicated and I don't even halfway know what I actually did there."

Once configured correctly, however, the flexibility becomes apparent. Linux gains direct access to GPIO, ADC resources and other processor features while still allowing PRU-based realtime control.

That flexibility is one of the PocketBeagle 2's greatest strengths, but it comes with a significantly steeper learning curve than many maker platforms.

Working with the Onboard ADC

The analogue subsystem proved much more straightforward.

Clem exposed four ADC channels and demonstrated how Linux can read them directly through the Industrial I/O framework.

The Python implementation is refreshingly simple.

ADC_PATH = "/sys/bus/iio/devices/iio:device0"
VREF = 1.8
ADC_MAX = 4095

return (raw / ADC_MAX) * VREF

This direct ADC access became a key part of the final demonstration.

A Useful Failure

Unfortunately, not everything worked perfectly.

One of the relay isolation circuits exposed a design mistake.

The optocouplers were treated like standard logic devices rather than LED-driven isolation components.

Current-limiting resistors had been omitted.

"With a 3.3 volt logic level I should have used a 330 ohm resistor."

The result was that the optocoupler LEDs never switched fully off once activated.

"Once the LED activates for the first time it sits there drawing current at about two volts and never deactivates again."

The relays therefore refused to operate correctly during the final demonstration.

Rather than hide the mistake, Clem used it to illustrate a reality of professional hardware development: unfamiliar parts frequently behave differently from assumptions made during schematic capture.

Testing, redesign and verification are fundamental parts of the engineering process.

Live Colour Detection Demo

For the final demonstration, the PLC uses its analogue inputs, USB subsystem, Linux environment and networking stack simultaneously.

A USB webcam streams video into OpenCV while two analogue channels control detection parameters.

One analogue input selects the target hue while another sets the intensity threshold.

The software converts ADC values into colour detection parameters in realtime.

application_hue = int(
    (raw / ADC_MAX) * 255
)

opencv_hue = int(
    (application_hue / 255) * 179
)

A value of 150 corresponds approximately to blue, allowing trim potentiometers wired to the PLC to tune colour detection while the system is operating.

The software analyses webcam imagery, performs HSV filtering, calculates contour sizes and overlays detection results on the live image.

Results are then streamed over the network using a built-in web server.

During testing, Clem adjusted the analogue inputs live while watching colour detection track the blue colour of his shirt.

"We can set the hue and the saturation with these analogue potentiometers on the fly and observe the stream over the network."

The demonstration neatly combines nearly every subsystem available on the PLC.

So Why Are PLCs So Expensive?

None of these individually seem particularly dramatic. Together they account for a substantial amount of engineering effort.

"Now that we know how incredibly difficult it is to make a real PLC, a system that has redundancy, safety, watchdogs and all these constructive features to make the relays safe and all the connections and inputs reliable, I think we can appreciate that sometimes they just have to cost more."

Building something that begins to behave like a professional industrial controller is a completely different challenge.

Supporting Files and Links

- Episode 728 Resources - Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

Bill of Materials

Product Name	Manufacturer	Quantity	Buy Kit
Optocoupler, Darlington Output, 4 Channel, DIP, 16 Pins, 50 mA, 5.3 kV, 500 %	ISOCOM	1	Buy Now
USB Connector, USB Type A, USB 2.0, Receptacle, 4 Ways, Through Hole Mount, Vertical	multicomp	2	Buy Now
Wire-To-Board Terminal Block, 5.08 mm, 3 Ways, 30 AWG, 12 AWG, 3.31 mm², Screw	würth	9	Buy Now
Plastic Enclosure, DIN Rail, Polycarbonate, 90 mm, 105 mm, 58 mm, IP20	hammond Mit freundlichen Grüßen	1	Buy Now
Pin Header, Board-to-Board, 2.54 mm, 2 Rows, 40 Contacts, Surface Mount	multicomp pro	2	Buy Now
Development Kit, PocketBeagle 2, AM6254, ARM Cortex-A53 / Cortex-M4F	beagleboard	1	Buy Now
Flash Memory Card, MicroSDHC Card, 16 GB, Class 10, UHS-I U1, A1	integral	1	Buy Now
DARLINGTON TRANSISTOR ARRAY, SOIC-16	onsemi	1	Buy Now
General Purpose Relay, ORWH Series, Power, Non Latching, SPDT, 5 VDC, 10 A	TE	4	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, 1 Output, 15 W, 5 VDC, 3 A	meanwell	1	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, Industrial & Household, 1 Output, 15 W, 5 VDC, 3 A	multicomp pro	1	Buy Now
USB Interface, USB Hub Controller, USB 2.0, 3 V, 3.6 V, QFN, 36 Pins	microchip	1	Buy Now
ETHERNET ADAPTER, USB3.0 GIGABIT WHI		1	Buy Now
DIN Mounting Rail, DIN Mounting Rail, Racks & Cabinets, 1 m, 7.5 mm, 35 mm, Steel		1	Buy Now
TVS Diode, WE-TVS, Unidirectional, 5 V, 6.8 V, SOT-23, 6 Pins	würth	4	Buy Now

Additional Parts

Product Name	Manufacturer	Quantity
Crystal and caps for the usb2514→ 24MHz
usb current control ICs + mosfets

Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

e14sbhargav — Thu, 20 Aug 2026 09:35:47 GMT

Revision 4 posted to Documents by e14sbhargav on 8/20/2026 9:35:47 AM

Watch Clem Pocket the Industrialisation

Rather than speculate, he decided to build one.

As Clem puts it:

"Sometimes they are actually just an Arduino in a fancy box and some relays... but there are also legacy systems with big brand names and high price tags and these are built for reliability."

His goal was not to reproduce an industrial PLC exactly, but to understand where all that engineering effort goes.

Starting with an Open PLC Platform

Commercial PLCs often come with proprietary software ecosystems, vendor lock-in and long-term support guarantees. Clem wanted to approach the problem from a different direction.

Instead of using a dedicated PLC platform, he based his design around the PocketBeagle 2, a compact Linux-capable development board built around Texas Instruments' AM6254 Sitara processor.

What attracted him was the combination of high-level Linux functionality and low-level deterministic control.

"I wanted it to have serious capabilities. It should have realtime Linux support and it also should have a deterministic way of controlling the inputs and outputs."

Unlike many maker boards, the PocketBeagle 2 includes two Programmable Realtime Units (PRUs), effectively dedicated microcontroller-class cores integrated into the processor.

These can operate independently from Linux and are designed specifically for tasks that require predictable timing.

"We have the Linux controls around USB devices, high-level stuff like AI models and communication with networks and other devices, and then the PRUs can control all the inputs and outputs."

Clem even points out that the second PRU could act as a watchdog, redundancy controller or cross-checking processor, similar to techniques found in safety-oriented industrial equipment.

Version One: The Maker Approach

The first PLC design intentionally follows the path many hobbyists would take.

A Hammond DIN rail enclosure serves as the mechanical foundation, while a relatively simple two-layer PCB carries the electronics. The board includes:

PocketBeagle 2 controller
Microchip USB2514 USB 2.0 hub controller
Four analogue input channels
Four relay outputs
ULN2003 Darlington relay driver
Dual USB host ports
DIN rail mounting format

The PCB itself was designed quickly.

"I eyeballed the position of all the connectors and I tried to put as many features in here as possible."

Rather than spending days optimising every mechanical detail, the focus was on getting something functional into the enclosure as quickly as possible.

On paper, it looked remarkably capable. Unfortunately, industrial design concerns do not appear on a schematic until something goes wrong.

When "Works" Isn't Good Enough

The first design functions. For many projects, that would be a success.

For a PLC, however, functionality is only the starting point.

Clem soon began identifying weaknesses that would become serious problems in an industrial environment.

The first issue was electrical safety.

"There is no real isolation in the original design. In case something goes wrong there could potentially be 230 volts everywhere in the system."

The relay outputs are capable of switching mains-voltage loads, yet the control electronics existed dangerously close to circuitry carrying higher voltages.

Industrial equipment depends heavily on segregation between control electronics and power electronics. Without that separation, failures can have consequences far beyond a damaged PCB.

The USB implementation also lacked many of the protections expected in a commercial design.

The original version provided only the minimum necessary circuitry to make the USB hub operate.

There was:

No ESD protection
No overcurrent protection
No controlled fault response
No dedicated USB power monitoring

These omissions are common in maker projects because they are often invisible during normal operation. Industrial equipment, by contrast, must survive repeated abuse from the outside world.

Analogue routing presented another problem.

"I've routed my analogue ports right next to the relays. That will not work very good because they will couple into it."

Relay switching generates electrical noise. Placing sensitive ADC signals next to relay circuits creates opportunities for incorrect readings, instability and potentially damage.

These are exactly the sort of layout considerations that are easy to overlook when the first goal is simply getting a board manufactured.

Building a More Professional Controller

The second board revision demonstrates how quickly extra engineering effort accumulates.

Clem moved to a four-layer PCB, improved component selection, reworked the enclosure integration and fundamentally redesigned the relay section.

More importantly, he stopped trying to maximise feature count and instead prioritised reliability.

"I preferred having good layout instead of more features on there because that is what the professional world considers the most important bit. Safe and reliable operation."

The revised USB implementation became significantly more sophisticated.

Dedicated current-limiting circuitry and fault detection were added to protect both connected peripherals and the PLC itself.

"These have current control chips specifically ordered and they have to detect if something goes wrong so your device that you plug into these USB ports can't destroy the overall thing."

This redesign required additional board area, forcing the reduction from four easily accessible USB ports down to two.

That trade-off between capability and robustness appears repeatedly throughout industrial design.

Isolation the Right Way

"An optocoupler is a way of galvanic isolation meaning there is no actual direct connection between these two halves. It is just and only a connection by light."

The relay control signals pass through an optocoupler before driving the ULN2003 relay driver.

This ensures that electrical disturbances from the relay side cannot directly propagate into the processor circuitry.

Even power supplies were separated.

Two isolated DIN rail power supplies were used: one dedicated to logic electronics and another for relay operation.

"We're truly isolated."

The resulting architecture begins to resemble industrial control hardware far more closely than the original all-in-one design.

The Device Tree Learning Curve

One of the most educational aspects of the project came from the software side.

Developers accustomed to Arduino or Raspberry Pi ecosystems often expect GPIO pins to work immediately.

The PocketBeagle 2 takes a more embedded Linux approach.

GPIO functionality must first be defined through device tree overlays.

"The apparently simple job of making a GPIO output starts involving device trees, pin multiplexing and the details of the underlying SoC."

Because the AM6254 allows pins to serve multiple functions, Linux must be explicitly told how they are being used.

Clem candidly describes the experience:

"Device tree overlays are very intimidating and complicated and I don't even halfway know what I actually did there."

Once configured correctly, however, the flexibility becomes apparent. Linux gains direct access to GPIO, ADC resources and other processor features while still allowing PRU-based realtime control.

That flexibility is one of the PocketBeagle 2's greatest strengths, but it comes with a significantly steeper learning curve than many maker platforms.

Working with the Onboard ADC

The analogue subsystem proved much more straightforward.

Clem exposed four ADC channels and demonstrated how Linux can read them directly through the Industrial I/O framework.

The Python implementation is refreshingly simple.

ADC_PATH = "/sys/bus/iio/devices/iio:device0"
VREF = 1.8
ADC_MAX = 4095

return (raw / ADC_MAX) * VREF

This direct ADC access became a key part of the final demonstration.

A Useful Failure

Unfortunately, not everything worked perfectly.

One of the relay isolation circuits exposed a design mistake.

The optocouplers were treated like standard logic devices rather than LED-driven isolation components.

Current-limiting resistors had been omitted.

"With a 3.3 volt logic level I should have used a 330 ohm resistor."

The result was that the optocoupler LEDs never switched fully off once activated.

"Once the LED activates for the first time it sits there drawing current at about two volts and never deactivates again."

The relays therefore refused to operate correctly during the final demonstration.

Rather than hide the mistake, Clem used it to illustrate a reality of professional hardware development: unfamiliar parts frequently behave differently from assumptions made during schematic capture.

Testing, redesign and verification are fundamental parts of the engineering process.

Live Colour Detection Demo

For the final demonstration, the PLC uses its analogue inputs, USB subsystem, Linux environment and networking stack simultaneously.

A USB webcam streams video into OpenCV while two analogue channels control detection parameters.

One analogue input selects the target hue while another sets the intensity threshold.

The software converts ADC values into colour detection parameters in realtime.

application_hue = int(
    (raw / ADC_MAX) * 255
)

opencv_hue = int(
    (application_hue / 255) * 179
)

A value of 150 corresponds approximately to blue, allowing trim potentiometers wired to the PLC to tune colour detection while the system is operating.

The software analyses webcam imagery, performs HSV filtering, calculates contour sizes and overlays detection results on the live image.

Results are then streamed over the network using a built-in web server.

During testing, Clem adjusted the analogue inputs live while watching colour detection track the blue colour of his shirt.

"We can set the hue and the saturation with these analogue potentiometers on the fly and observe the stream over the network."

The demonstration neatly combines nearly every subsystem available on the PLC.

So Why Are PLCs So Expensive?

None of these individually seem particularly dramatic. Together they account for a substantial amount of engineering effort.

"Now that we know how incredibly difficult it is to make a real PLC, a system that has redundancy, safety, watchdogs and all these constructive features to make the relays safe and all the connections and inputs reliable, I think we can appreciate that sometimes they just have to cost more."

Building something that begins to behave like a professional industrial controller is a completely different challenge.

Supporting Files and Links

- Episode 728 Resources - Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

Bill of Materials

Product Name	Manufacturer	Quantity	Buy Kit
Optocoupler, Darlington Output, 4 Channel, DIP, 16 Pins, 50 mA, 5.3 kV, 500 %	ISOCOM	1	Buy Now
USB Connector, USB Type A, USB 2.0, Receptacle, 4 Ways, Through Hole Mount, Vertical	multicomp	2	Buy Now
Wire-To-Board Terminal Block, 5.08 mm, 3 Ways, 30 AWG, 12 AWG, 3.31 mm², Screw	würth	9	Buy Now
Plastic Enclosure, DIN Rail, Polycarbonate, 90 mm, 105 mm, 58 mm, IP20	hammond Mit freundlichen Grüßen	1	Buy Now
Pin Header, Board-to-Board, 2.54 mm, 2 Rows, 40 Contacts, Surface Mount	multicomp pro	2	Buy Now
Development Kit, PocketBeagle 2, AM6254, ARM Cortex-A53 / Cortex-M4F	beagleboard	1	Buy Now
Flash Memory Card, MicroSDHC Card, 16 GB, Class 10, UHS-I U1, A1	integral	1	Buy Now
DARLINGTON TRANSISTOR ARRAY, SOIC-16	onsemi	1	Buy Now
General Purpose Relay, ORWH Series, Power, Non Latching, SPDT, 5 VDC, 10 A	TE	4	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, 1 Output, 15 W, 5 VDC, 3 A	meanwell	1	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, Industrial & Household, 1 Output, 15 W, 5 VDC, 3 A	multicomp pro	1	Buy Now
USB Interface, USB Hub Controller, USB 2.0, 3 V, 3.6 V, QFN, 36 Pins	microchip	1	Buy Now
ETHERNET ADAPTER, USB3.0 GIGABIT WHI		1	Buy Now
DIN Mounting Rail, DIN Mounting Rail, Racks & Cabinets, 1 m, 7.5 mm, 35 mm, Steel		1	Buy Now
TVS Diode, WE-TVS, Unidirectional, 5 V, 6.8 V, SOT-23, 6 Pins	würth	4	Buy Now

Additional Parts

Product Name	Manufacturer	Quantity
Crystal and caps for the usb2514→ 24MHz
usb current control ICs + mosfets

Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

cstanton — Thu, 20 Aug 2026 09:21:28 GMT

Revision 2 posted to Documents by cstanton on 8/20/2026 9:21:28 AM

Watch Clem Pocket the Industrialisation

community.element14.com/.../The-Industrial-PocketBeagle-PLC.mp4

Rather than speculate, he decided to build one.

As Clem puts it:

"Sometimes they are actually just an Arduino in a fancy box and some relays... but there are also legacy systems with big brand names and high price tags and these are built for reliability."

His goal was not to reproduce an industrial PLC exactly, but to understand where all that engineering effort goes.

Starting with an Open PLC Platform

Commercial PLCs often come with proprietary software ecosystems, vendor lock-in and long-term support guarantees. Clem wanted to approach the problem from a different direction.

Instead of using a dedicated PLC platform, he based his design around the PocketBeagle 2, a compact Linux-capable development board built around Texas Instruments' AM6254 Sitara processor.

What attracted him was the combination of high-level Linux functionality and low-level deterministic control.

"I wanted it to have serious capabilities. It should have realtime Linux support and it also should have a deterministic way of controlling the inputs and outputs."

Unlike many maker boards, the PocketBeagle 2 includes two Programmable Realtime Units (PRUs), effectively dedicated microcontroller-class cores integrated into the processor.

These can operate independently from Linux and are designed specifically for tasks that require predictable timing.

"We have the Linux controls around USB devices, high-level stuff like AI models and communication with networks and other devices, and then the PRUs can control all the inputs and outputs."

Clem even points out that the second PRU could act as a watchdog, redundancy controller or cross-checking processor, similar to techniques found in safety-oriented industrial equipment.

Version One: The Maker Approach

The first PLC design intentionally follows the path many hobbyists would take.

A Hammond DIN rail enclosure serves as the mechanical foundation, while a relatively simple two-layer PCB carries the electronics. The board includes:

PocketBeagle 2 controller
Microchip USB2514 USB 2.0 hub controller
Four analogue input channels
Four relay outputs
ULN2003 Darlington relay driver
Dual USB host ports
DIN rail mounting format

The PCB itself was designed quickly.

"I eyeballed the position of all the connectors and I tried to put as many features in here as possible."

Rather than spending days optimising every mechanical detail, the focus was on getting something functional into the enclosure as quickly as possible.

On paper, it looked remarkably capable. Unfortunately, industrial design concerns do not appear on a schematic until something goes wrong.

When "Works" Isn't Good Enough

The first design functions. For many projects, that would be a success.

For a PLC, however, functionality is only the starting point.

Clem soon began identifying weaknesses that would become serious problems in an industrial environment.

The first issue was electrical safety.

"There is no real isolation in the original design. In case something goes wrong there could potentially be 230 volts everywhere in the system."

The relay outputs are capable of switching mains-voltage loads, yet the control electronics existed dangerously close to circuitry carrying higher voltages.

Industrial equipment depends heavily on segregation between control electronics and power electronics. Without that separation, failures can have consequences far beyond a damaged PCB.

The USB implementation also lacked many of the protections expected in a commercial design.

The original version provided only the minimum necessary circuitry to make the USB hub operate.

There was:

No ESD protection
No overcurrent protection
No controlled fault response
No dedicated USB power monitoring

These omissions are common in maker projects because they are often invisible during normal operation. Industrial equipment, by contrast, must survive repeated abuse from the outside world.

Analogue routing presented another problem.

"I've routed my analogue ports right next to the relays. That will not work very good because they will couple into it."

Relay switching generates electrical noise. Placing sensitive ADC signals next to relay circuits creates opportunities for incorrect readings, instability and potentially damage.

These are exactly the sort of layout considerations that are easy to overlook when the first goal is simply getting a board manufactured.

Building a More Professional Controller

The second board revision demonstrates how quickly extra engineering effort accumulates.

Clem moved to a four-layer PCB, improved component selection, reworked the enclosure integration and fundamentally redesigned the relay section.

More importantly, he stopped trying to maximise feature count and instead prioritised reliability.

"I preferred having good layout instead of more features on there because that is what the professional world considers the most important bit. Safe and reliable operation."

The revised USB implementation became significantly more sophisticated.

Dedicated current-limiting circuitry and fault detection were added to protect both connected peripherals and the PLC itself.

"These have current control chips specifically ordered and they have to detect if something goes wrong so your device that you plug into these USB ports can't destroy the overall thing."

This redesign required additional board area, forcing the reduction from four easily accessible USB ports down to two.

That trade-off between capability and robustness appears repeatedly throughout industrial design.

Isolation the Right Way

The most dramatic change involved the relay outputs.

The revised PCB treats the relay circuitry and logic circuitry almost as completely separate systems.

A dedicated isolation boundary divides the board into two sections.

The only intentional signal path crossing that boundary is an optocoupler.

"An optocoupler is a way of galvanic isolation meaning there is no actual direct connection between these two halves. It is just and only a connection by light."

The relay control signals pass through an optocoupler before driving the ULN2003 relay driver.

This ensures that electrical disturbances from the relay side cannot directly propagate into the processor circuitry.

Even power supplies were separated.

Two isolated DIN rail power supplies were used: one dedicated to logic electronics and another for relay operation.

"We're truly isolated."

The resulting architecture begins to resemble industrial control hardware far more closely than the original all-in-one design.

The Device Tree Learning Curve

One of the most educational aspects of the project came from the software side.

Developers accustomed to Arduino or Raspberry Pi ecosystems often expect GPIO pins to work immediately.

The PocketBeagle 2 takes a more embedded Linux approach.

GPIO functionality must first be defined through device tree overlays.

"The apparently simple job of making a GPIO output starts involving device trees, pin multiplexing and the details of the underlying SoC."

Because the AM6254 allows pins to serve multiple functions, Linux must be explicitly told how they are being used.

Clem candidly describes the experience:

"Device tree overlays are very intimidating and complicated and I don't even halfway know what I actually did there."

Once configured correctly, however, the flexibility becomes apparent. Linux gains direct access to GPIO, ADC resources and other processor features while still allowing PRU-based realtime control.

That flexibility is one of the PocketBeagle 2's greatest strengths, but it comes with a significantly steeper learning curve than many maker platforms.

Working with the Onboard ADC

The analogue subsystem proved much more straightforward.

Clem exposed four ADC channels and demonstrated how Linux can read them directly through the Industrial I/O framework.

The Python implementation is refreshingly simple.

ADC_PATH = "/sys/bus/iio/devices/iio:device0"
VREF = 1.8
ADC_MAX = 4095

return (raw / ADC_MAX) * VREF

This direct ADC access became a key part of the final demonstration.

A Useful Failure

Unfortunately, not everything worked perfectly.

One of the relay isolation circuits exposed a design mistake.

The optocouplers were treated like standard logic devices rather than LED-driven isolation components.

Current-limiting resistors had been omitted.

"With a 3.3 volt logic level I should have used a 330 ohm resistor."

The result was that the optocoupler LEDs never switched fully off once activated.

"Once the LED activates for the first time it sits there drawing current at about two volts and never deactivates again."

The relays therefore refused to operate correctly during the final demonstration.

Rather than hide the mistake, Clem used it to illustrate a reality of professional hardware development: unfamiliar parts frequently behave differently from assumptions made during schematic capture.

Testing, redesign and verification are fundamental parts of the engineering process.

Live Colour Detection Demo

For the final demonstration, the PLC uses its analogue inputs, USB subsystem, Linux environment and networking stack simultaneously.

A USB webcam streams video into OpenCV while two analogue channels control detection parameters.

One analogue input selects the target hue while another sets the intensity threshold.

The software converts ADC values into colour detection parameters in realtime.

application_hue = int(
    (raw / ADC_MAX) * 255
)

opencv_hue = int(
    (application_hue / 255) * 179
)

A value of 150 corresponds approximately to blue, allowing trim potentiometers wired to the PLC to tune colour detection while the system is operating.

The software analyses webcam imagery, performs HSV filtering, calculates contour sizes and overlays detection results on the live image.

Results are then streamed over the network using a built-in web server.

During testing, Clem adjusted the analogue inputs live while watching colour detection track the blue colour of his shirt.

"We can set the hue and the saturation with these analogue potentiometers on the fly and observe the stream over the network."

The demonstration neatly combines nearly every subsystem available on the PLC.

So Why Are PLCs So Expensive?

None of these individually seem particularly dramatic. Together they account for a substantial amount of engineering effort.

"Now that we know how incredibly difficult it is to make a real PLC, a system that has redundancy, safety, watchdogs and all these constructive features to make the relays safe and all the connections and inputs reliable, I think we can appreciate that sometimes they just have to cost more."

Building something that begins to behave like a professional industrial controller is a completely different challenge.

Supporting Files and Links

community.element14.com/.../The-Industrial-PocketBeagle-PLC.mp4

Bill of Materials

Product Name	Manufacturer	Quantity	Buy Kit
Optocoupler, Darlington Output, 4 Channel, DIP, 16 Pins, 50 mA, 5.3 kV, 500 %	ISOCOM	1	Buy Now
USB Connector, USB Type A, USB 2.0, Receptacle, 4 Ways, Through Hole Mount, Vertical	multicomp	2	Buy Now
Wire-To-Board Terminal Block, 5.08 mm, 3 Ways, 30 AWG, 12 AWG, 3.31 mm², Screw	würth	9	Buy Now
Plastic Enclosure, DIN Rail, Polycarbonate, 90 mm, 105 mm, 58 mm, IP20	hammond Mit freundlichen Grüßen	1	Buy Now
Pin Header, Board-to-Board, 2.54 mm, 2 Rows, 40 Contacts, Surface Mount	multicomp pro	2	Buy Now
Development Kit, PocketBeagle 2, AM6254, ARM Cortex-A53 / Cortex-M4F	beagleboard	1	Buy Now
Flash Memory Card, MicroSDHC Card, 16 GB, Class 10, UHS-I U1, A1	integral	1	Buy Now
DARLINGTON TRANSISTOR ARRAY, SOIC-16	onsemi	1	Buy Now
General Purpose Relay, ORWH Series, Power, Non Latching, SPDT, 5 VDC, 10 A	TE	4	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, 1 Output, 15 W, 5 VDC, 3 A	meanwell	1	Buy Now
AC/DC DIN Rail Power Supply (PSU), ITE, Industrial & Household, 1 Output, 15 W, 5 VDC, 3 A	multicomp pro	1	Buy Now
USB Interface, USB Hub Controller, USB 2.0, 3 V, 3.6 V, QFN, 36 Pins	microchip	1	Buy Now
ETHERNET ADAPTER, USB3.0 GIGABIT WHI		1	Buy Now
DIN Mounting Rail, DIN Mounting Rail, Racks & Cabinets, 1 m, 7.5 mm, 35 mm, Steel		1	Buy Now
TVS Diode, WE-TVS, Unidirectional, 5 V, 6.8 V, SOT-23, 6 Pins	würth	4	Buy Now

Additional Parts

Product Name	Manufacturer	Quantity
Crystal and caps for the usb2514→ 24MHz
usb current control ICs + mosfets

Building a DIY PLC with PocketBeagle 2: Finding Out Why Industrial Controllers Cost So Much

cstanton — Wed, 19 Aug 2026 17:15:25 GMT

Revision 1 posted to Documents by cstanton on 8/19/2026 5:15:25 PM

Watch Clem Pocket the Industrialisation

Rather than speculate, he decided to build one.

As Clem puts it:

"Sometimes they are actually just an Arduino in a fancy box and some relays... but there are also legacy systems with big brand names and high price tags and these are built for reliability."

His goal was not to reproduce an industrial PLC exactly, but to understand where all that engineering effort goes.

Starting with an Open PLC Platform

Commercial PLCs often come with proprietary software ecosystems, vendor lock-in and long-term support guarantees. Clem wanted to approach the problem from a different direction.

Instead of using a dedicated PLC platform, he based his design around the PocketBeagle 2, a compact Linux-capable development board built around Texas Instruments' AM6254 Sitara processor.

What attracted him was the combination of high-level Linux functionality and low-level deterministic control.

"I wanted it to have serious capabilities. It should have realtime Linux support and it also should have a deterministic way of controlling the inputs and outputs."

Unlike many maker boards, the PocketBeagle 2 includes two Programmable Realtime Units (PRUs), effectively dedicated microcontroller-class cores integrated into the processor.

These can operate independently from Linux and are designed specifically for tasks that require predictable timing.

"We have the Linux controls around USB devices, high-level stuff like AI models and communication with networks and other devices, and then the PRUs can control all the inputs and outputs."

Clem even points out that the second PRU could act as a watchdog, redundancy controller or cross-checking processor, similar to techniques found in safety-oriented industrial equipment.

Version One: The Maker Approach

The first PLC design intentionally follows the path many hobbyists would take.

A Hammond DIN rail enclosure serves as the mechanical foundation, while a relatively simple two-layer PCB carries the electronics. The board includes:

PocketBeagle 2 controller
Microchip USB2514 USB 2.0 hub controller
Four analogue input channels
Four relay outputs
ULN2003 Darlington relay driver
Dual USB host ports
DIN rail mounting format

The PCB itself was designed quickly.

"I eyeballed the position of all the connectors and I tried to put as many features in here as possible."

Rather than spending days optimising every mechanical detail, the focus was on getting something functional into the enclosure as quickly as possible.

The analogue channels are exposed through simple screw terminals, providing an easy way to interact with sensors and control inputs.

The USB subsystem was another area where the project deliberately pushed the platform. By integrating the USB2514 hub controller, the PLC gains multiple USB ports for cameras, storage devices and peripherals.

On paper, it looked remarkably capable.

Unfortunately, industrial design concerns do not appear on a schematic until something goes wrong.

When "Works" Isn't Good Enough

The first design functions. For many projects, that would be a success.

For a PLC, however, functionality is only the starting point.

Clem soon began identifying weaknesses that would become serious problems in an industrial environment.

The first issue was electrical safety.

"There is no real isolation in the original design. In case something goes wrong there could potentially be 230 volts everywhere in the system."

The relay outputs are capable of switching mains-voltage loads, yet the control electronics existed dangerously close to circuitry carrying higher voltages.

Industrial equipment depends heavily on segregation between control electronics and power electronics. Without that separation, failures can have consequences far beyond a damaged PCB.

The USB implementation also lacked many of the protections expected in a commercial design.

The original version provided only the minimum necessary circuitry to make the USB hub operate.

There was:

No ESD protection
No overcurrent protection
No controlled fault response
No dedicated USB power monitoring

These omissions are common in maker projects because they are often invisible during normal operation. Industrial equipment, by contrast, must survive repeated abuse from the outside world.

Analogue routing presented another problem.

"I've routed my analogue ports right next to the relays. That will not work very good because they will couple into it."

Relay switching generates electrical noise. Placing sensitive ADC signals next to relay circuits creates opportunities for incorrect readings, instability and potentially damage.

These are exactly the sort of layout considerations that are easy to overlook when the first goal is simply getting a board manufactured.

Building a More Professional Controller

The second board revision demonstrates how quickly extra engineering effort accumulates.

Clem moved to a four-layer PCB, improved component selection, reworked the enclosure integration and fundamentally redesigned the relay section.

More importantly, he stopped trying to maximise feature count and instead prioritised reliability.

"I preferred having good layout instead of more features on there because that is what the professional world considers the most important bit. Safe and reliable operation."

The revised USB implementation became significantly more sophisticated.

Dedicated current-limiting circuitry and fault detection were added to protect both connected peripherals and the PLC itself.

"These have current control chips specifically ordered and they have to detect if something goes wrong so your device that you plug into these USB ports can't destroy the overall thing."

This redesign required additional board area, forcing the reduction from four easily accessible USB ports down to two.

That trade-off between capability and robustness appears repeatedly throughout industrial design.

Isolation the Right Way

The most dramatic change involved the relay outputs.

The revised PCB treats the relay circuitry and logic circuitry almost as completely separate systems.

A dedicated isolation boundary divides the board into two sections.

The only intentional signal path crossing that boundary is an optocoupler.

"An optocoupler is a way of galvanic isolation meaning there is no actual direct connection between these two halves. It is just and only a connection by light."

The relay control signals pass through an optocoupler before driving the ULN2003 relay driver.

This ensures that electrical disturbances from the relay side cannot directly propagate into the processor circuitry.

Even power supplies were separated.

Two isolated DIN rail power supplies were used: one dedicated to logic electronics and another for relay operation.

"We're truly isolated."

The resulting architecture begins to resemble industrial control hardware far more closely than the original all-in-one design.

The Device Tree Learning Curve

One of the most educational aspects of the project came from the software side.

Developers accustomed to Arduino or Raspberry Pi ecosystems often expect GPIO pins to work immediately.

The PocketBeagle 2 takes a more embedded Linux approach.

GPIO functionality must first be defined through device tree overlays.

"The apparently simple job of making a GPIO output starts involving device trees, pin multiplexing and the details of the underlying SoC."

Because the AM6254 allows pins to serve multiple functions, Linux must be explicitly told how they are being used.

Clem candidly describes the experience:

"Device tree overlays are very intimidating and complicated and I don't even halfway know what I actually did there."

Once configured correctly, however, the flexibility becomes apparent. Linux gains direct access to GPIO, ADC resources and other processor features while still allowing PRU-based realtime control.

That flexibility is one of the PocketBeagle 2's greatest strengths, but it comes with a significantly steeper learning curve than many maker platforms.

Working with the Onboard ADC

The analogue subsystem proved much more straightforward.

Clem exposed four ADC channels and demonstrated how Linux can read them directly through the Industrial I/O framework.

The Python implementation is refreshingly simple.

ADC_PATH = "/sys/bus/iio/devices/iio:device0"
VREF = 1.8
ADC_MAX = 4095

return (raw / ADC_MAX) * VREF

Raw readings are collected from Linux system files and converted into voltages using the 12-bit ADC range.

The implementation continuously reads all four channels and reports both raw counts and calculated voltages.

This direct ADC access became a key part of the final demonstration.

A Useful Failure

Unfortunately, not everything worked perfectly.

One of the relay isolation circuits exposed a design mistake.

The optocouplers were treated like standard logic devices rather than LED-driven isolation components.

Current-limiting resistors had been omitted.

"With a 3.3 volt logic level I should have used a 330 ohm resistor."

The result was that the optocoupler LEDs never switched fully off once activated.

"Once the LED activates for the first time it sits there drawing current at about two volts and never deactivates again."

The relays therefore refused to operate correctly during the final demonstration.

Rather than hide the mistake, Clem used it to illustrate a reality of professional hardware development: unfamiliar parts frequently behave differently from assumptions made during schematic capture.

Testing, redesign and verification are fundamental parts of the engineering process.

Live Colour Detection Demo

For the final demonstration, the PLC uses its analogue inputs, USB subsystem, Linux environment and networking stack simultaneously.

A USB webcam streams video into OpenCV while two analogue channels control detection parameters.

One analogue input selects the target hue while another sets the intensity threshold.

The software converts ADC values into colour detection parameters in realtime.

application_hue = int(
    (raw / ADC_MAX) * 255
)

opencv_hue = int(
    (application_hue / 255) * 179
)

A value of 150 corresponds approximately to blue, allowing trim potentiometers wired to the PLC to tune colour detection while the system is operating.

The software analyses webcam imagery, performs HSV filtering, calculates contour sizes and overlays detection results on the live image.

Results are then streamed over the network using a built-in web server.

During testing, Clem adjusted the analogue inputs live while watching colour detection track the blue colour of his shirt.

"We can set the hue and the saturation with these analogue potentiometers on the fly and observe the stream over the network."

The demonstration neatly combines nearly every subsystem available on the PLC.

So Why Are PLCs So Expensive?

None of these individually seem particularly dramatic. Together they account for a substantial amount of engineering effort.

"Now that we know how incredibly difficult it is to make a real PLC, a system that has redundancy, safety, watchdogs and all these constructive features to make the relays safe and all the connections and inputs reliable, I think we can appreciate that sometimes they just have to cost more."

Building something that begins to behave like a professional industrial controller is a completely different challenge.

Project Video Release Archive

e14sbhargav — Thu, 13 Aug 2026 14:05:44 GMT

Revision 224 posted to Documents by e14sbhargav on 8/13/2026 2:05:44 PM

Project Video Releases

element14 presents | Meet the Hosts

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

Episode 725: Clem's Workbench Upgrade to Automated Lab with Programmable Instruments and Python

Episode 724: Building and Programming a SCARA Industrial Robot Arm – An Introduction to Robotics

Episode 723: Building a Privacy-First Workshop Security Camera with PocketBeagle 2

Episode 722: PID Control, Motion Profiles and ROS Explained - An Introduction to Robotics

Episode 721: Designing a Smarter Workbench: Inside Mark’s 8-Channel Power Monitoring System

Episode 720: Building the Foundations of Your First Robot - An Introduction to Robotics

Episode 719: Turning a Broken Robot Vacuum into a Network-Controlled Raspberry Pi 5 Rover

Episode 718: Creating a Multi-Function ESP32 Desk Pet with Custom PCB and Audio Processing

Episode 717: Simulating Prey Vision with Raspberry Pi 5: A Dual Camera Perception Experiment

Episode 716: Designing a Mobile Robot Platform with Inverse Kinematics and Wireless Control

Episode 715: How to Build a Reaction-Based Catch Game Using Arduino and Relays

Episode 714: Find EMI Fast with a Low‑Cost, Automated Way to See Where Your PCB Radiates

Episode 713: How to Make an LED Sculpture React to Sound with micro:bit

Episode 712: Designing a More Capable Dual Motor Driver Beyond the L298N (What worked and what didn't)

Episode 711: Modern Edge AI on Raspberry Pi 5 for an Animatronic Tracker: Vision Acceleration with AI Hat+ and AI Camera

Episode 710: Your First Real PCB in KiCad : An Arduino Compatible Board Designed from Scratch

Episode 709: Was that my Number!? Fixing Café Order Chaos with a Raspberry Pi Announcer

Episode 708: Reviving a Vintage LED Sign with Arduino and PS/2 Control

Episode 707: Building a Circuit Sculpture with LED Filament

Episode 706: ESP32 + RFID = Smart Access Control in a Simple DIY Build

Episode 705: Building a Super Smooth Z-Scale Train Controller with Arduino

Episode 704: Hacking an IKEA Desk into a Programmable Electric Workstation

Episode 703: How to Set Up the Raspberry Pi 5: Complete Beginner Step-by-Step Guide

Episode 702: Build Your Own USB Looper for Serial Debugging and File Transfer

Episode 701: From Snooze to Launch: The Arduino-Powered LEGO Alarm Clock Inspired by Artemis 2

Episode 700: How Voice Recognition Works on Raspberry Pi (and Why It’s Easy to Break)

Episode 699: GimmeGPIO: A Simple Way to Get GPIO on Laptops and Desktops

Episode 698: Building a Practical Electronics Workbench for Makers and Engineers

Episode 697: A Smart, Safe 3D Printer Cabinet Using Raspberry Pi and Node-RED

Episode 696: How a Pulse Metal Detector Works, and How to Build One

Episode 695: A DIY Test and Programming Rig Built for Small-Batch Electronics Production

Episode 694: Earn Your Fitness Reward with a Smart Cookie Jar Using Strava and ESP32

Episode 693: Open-Source Multicolour 3D Printing Upgrade: Clem’s 3D Chameleon Remix

Episode 692: Build Your own ESP32 Fitness Heart Rate Monitor / Tracker

Episode 691: How Accurate Is Bluetooth Channel Sounding? A Deep Dive with the nRF54L15

Episode 690: Meet the PlatypusBot: Now Powered by Raspberry Pi & ROS

Episode 689: How Clem Built a Handheld Sci-Fi Communicator That Really Works

Episode 688: Building the Cylon Pumpkin: Combining a Larson Scanner and Vocoder for Halloween

Episode 687: Turning a $10 Air Fryer into an Arduino powered Filament Dryer

Episode 686: Creepy Motion-Activated Painting You Can Build Yourself

Episode 685: When Your Body Becomes the Instrument: Clem Builds the “Dröne” Synth

Episode 684: Building an Audio Reactive LED Matrix with a micro:bit and NeoPixels

Episode 683: How to Make a Portable Emergency Radio with an Arduino Nano in a Mint TinT

Episode 682: DIY RF Modulator + Raspberry Pi Pico = Gaming on a Sony Watchman FD-10A CRT

Episode 681: Turn anything into an Arduino Module: Reusing Everyday Electronics

Episode 680: From Kit to Custom Design: Building a Tube-Based FM Radio

Episode 679: ESP32 Duolingo Owl Project: Never Miss a Lesson Again

Episode 678: Open Source ATtiny3226 Arduino Calculator – Hardware, Case & Code Build

Episode 677: Make Your Own Vocoder with Teensy 4.0 - Voice of a Cylon?!

Episode 676: I Tried Building 16 ATtiny Robots with Vibration Motors – It Was a Disaster

Episode 675:Avoid Conflict with this ESP32 Defcon Task Tracker

Episode 674: Building an Open Source Blood Pressure & Heart Signal Monitor

Episode 673: Building an ESP32 Powered Warhammer 40k Rhino with Dynamic LED Effects!

Episode 672: Building an Autonomous LEGO Train with CircuitPython and LIDAR

Episode 671: PlatypusBot - Scavenging for Robotics Parts

Episode 670: Build your own Larson Scanner

Episode 669: Creating an ESD (Or Lightning!) Detector!

Episode 668: Designing an Arduino PID Controlled Micro Drone

Episode 667: Emulating a Speech Synthesis Chip with an ESP32

Episode 666: How Far Can I2C Go?

Episode 665: Raspberry Pi AI Tracking Eye of Sauron - AI AL Barad Dur

Episode 664: Learn how to Make a Photo Booth with the ESP32 and Telegram Automation!

Episode 663: Upcycling a Vintage Microphone into an Emergency Radio System

Episode 662: Making a Stronger Affordable DIY Robot Arm with 3D Printing with Raspberry Pi Pico

Episode 661: Clem makes his own LED Wristwatch

Episode 660: LoFi Beats to Solder To

Episode 659: DIY Single Board Computer with ESP32 and Raspberry Pi Pico

Episode 658: A Smart Youtube Counter With An Audio Analyzer

Episode 657: How to Control a LEGO Mindstorms kit with AI and Raspberry Pi 5

Episode 656: DIY Jig for your Laser Cutter with Custom Arduino Automation

Episode 655: DIY Hot Plate for SMD Soldering Using Raspberry Pi Pico

Episode 654: How Do BattleBots Work? In the Pit with HyperShock

Episode 653: Edge-lit 7-Segment Display Clock Using Raspberry Pi Pico

Episode 652: Smart Windows and Blinds with Arduino and Raspberry Pi Pico

Episode 651: Design for Manufacturing - Project to Product by Modifying Off-the-Shelf Cases

Episode 650: Using Nordic's nRF7002, My Dehumidifier Tells Me When It's Full!

Episode 649: Giant Retro Gaming Magic Mirror with a Raspberry Pi 5!

Episode 648: Home AI Image Generation Server with LattePanda and Stable Diffusion

Episode 647: Building an Open-Source Tool for Cave Surveying

Episode 646: Creating a Digital Roulette Table with an ESP32 DevKit

Episode 645: Practical DIY Pi Pico Current Load Circuits

Episode 644: Turning a Raspberry Pi Pico into a GPU!

Episode 643: Making a Tribble that Detects Klingons

Episode 642: Making a Time-lapse Camera with a Raspberry Pi 5

Episode 641: Moon Phase Display with Raspberry Pi Pico

Episode 640: Tinkering vs Engineering: Can You Build a Laptop from Scratch?

Episode 639: Off-Grid Remote Generator Starter?

Episode 638: RP2040 PCB: Design, Turn-On, and Debug - How Hard Could It Be?

Episode 637: Making Music with a Lego Guitar and Capacitive Touch

Episode 636: Creating an IMU based 3D Mouse with an ESP32-S3

Episode 635: Vintage Electronics Exploration with a Bally Cypress Gardens Bingo Machine

Episode 634: Craft a Festive LED Christmas Sweater Featuring the ATtiny416

Episode 633: Spying Under the Christmas Tree with an Arduino-powered Ornament

Episode 632: Revamping Old School Pinball with an ESP32

Episode 631: All-Purpose Debugging: A Practical Universal Screen with LCD Displays

Episode 630: Mega IIe: First Fully Functional Computer built around the Apple Mega-II Chip

Episode 629: Backpack Splash: Mark's Water Gun Upgrade for Epic Outdoor Water Wars!

Episode 628: Affordable DIY Robot Arm - A Deep Dive into 3D Printing and Servo Motors

Episode 627: Creating sudostick - From Prototype to Product

Episode 626: Catching you Up on Bonesnapper Ridge - Off-Grid Maker Shop

Episode 625: Interactive Magic - Creating an Enchanted Cauldron

Episode 624: Modding A Smoke Machine to Add Motion Detection

Episode 623: How to Run Linux on an ESP32

Episode 622: Building Spooky Fun: Halloween Sound Pranks with nRF 5340 BLE Audio

Episode 621: Color Sensor-Based Water Quality Tracker: DIY Environmental Monitoring

Episode 620: Stey-by-Step Guide to Creating your own Speaking Animatronic Hat

Episode 619: How to Build an Open Source Bluetooth Mechanical Keyboard

Episode 618: Upgrading My Racing Sim with a Force-Sensitive Keyboard

Episode 617: Simplify Network Monitoring: Building an ESP32-Powered Solution

Episode 616: Mastering Oven Control: Precision Resin Curing with DIY Modifications - How Hard Can it Be?

Episode 615: Building a Unique USB Card Reader: From Idea to Prototype

Episode 614: Using PID (Proportional-Integral-Derivative) in Robotics - How Hard Could It Be?

Episode 613: Building a Magic Wand Talking Sound Board

Episode 612: Handheld BASIC computer in Badge Format with the Arduino Uno

Episode 611: How to Run the Distance to the Moon with Strava Data and a Pico W Board

Episode 610: How to Embroider with Circuits and Conductive Thread

Episode 609: Updating a Fujitsu N860-2500-T111 Keyboard to Work with a PS2 Standard

Episode 608: Making the Simplest DIY Wind Energy Generator - How Hard Could it Be?

Episode 607: From Strava to Motion: Creating an Arduino-Powered Arcade Game with Running Data

Episode 606: How to Use LoRaWAN to Launch Model Rockets Wirelessly

Episode 605: Arduino and LEDs Make Solitaire Easier to Solve

Episode 604: Charlieplexing Buttons and LEDs at the Same Time - How Hard Can It Be?

Episode 603: Create Your Own Air Hockey Table with Arduino Scoring

Episode 602: DIY AC Dimmer Circuit: Control Your Lights with a Raspberry Pi Pico

Episode 601: How to Reverse Engineer Electronics: Building a Developer Board for a Coding Class

Episode 600: Building My Dream Digital Clock: DIY 7 Segment Display with a Cute Robot Twist!

Episode 599: How to Build a Spectrum Analyzer with Lego Bricks & Discrete Electronics

Episode 598: How To Build a Portable, Solar-Charged Off-Grid Power Station

Episode 597: How to Build a Robot that Celebrates Good Grades with Arduino

Episode 596: How to Build Your Own Voice Assistant with MyCroft AI - How Hard Can It Be?

Episode 595: Member Challenge Accepted - Universal LANC Controller for DSLR cameras

Episode 594: Repairing a Neewer 660 Studio light - How Hard Can It Be?

Episode 593: Playing 3D Famicom Games Wirelessly on the NES - How Hard Could It Be?

Episode 592: Lamptopus: Spinning LED Desk Lamp

Episode 591: Building A Bluetooth Speaker in 5 Minutes - How Hard Can It Be?

Episode 590: Seven Kingdoms Open Source Bartop Arcade

Episode 589: Upgrading the iMac G4 With a NUC

Episode 588: Highlights from element14 presents 2022

Episode 587: Create Your Own Talking Stress Indicator

Episode 586: DIY Open Source Bluetooth Headphones

Episode 585: Enhancing a Magnifying Headband with Auto Sensing Light

Episode 584: Going Beyond Periodic Wakes: Using WiFi to Revive a Sleeping Device

Episode 583: Epic Neopixel Birthday Cake

Episode 582: Smart Christmas Decoration with Raspberry Pi Pico and MQTT

Episode 581: Bee-Saving Electronics Prototype

Episode 580: DIY Low Cost Capacitance Meter Using a 555 Timer

Episode 579: How to Make a Basketball Auto Score Keeper Using Colour Sensing

Episode 578: Build your Own Bat Detector with Analog Parts

Episode 577: The Game Guy Mini, Upgrading the Unportable Game Boy!

Episode 576: Build your own Underwater Drone with 3D Printed Parts

Episode 575: How to Make a Secured Parcel Pickup Box with Arduino

Episode 574: Ghost Rider Halloween Costume

Episode 573: Using a Pi Pico to Convert Keyboard Input to Morse Code

Episode 572: How to Use an ESP32 & Camera to Know You've Got Mail!

Episode 571: Using Dead Batteries to Test for Dead Batteries

Episode 570: Making a WiFi Connected Audio Spectrum Analyzer with ESP32

Episode 569: Multi-Spectrum UV Resin Curing Station with Würth LEDs

Episode 568: How to Make a Custom Soundboard with the STM32F4 using FreeCAD

Episode 567: Synced NeoPixel Mickey Mouse Ears

Episode 566: How to Automate Industrial Welding Positioners with Arduino

Episode 565: Measuring Destructive Testing Force with a 20 Ton Hydraulic Press

Episode 564: Build a VU Meter with LED Pixelated Nixie Tubes

Episode 563: Creating Augmented Reality Circuits with Meta Quest 2 and Unity

Episode 562: Pi Home Temperature Monitoring System

Episode 561: WiFi to Parallel Port Ascii Art Dot-Matrix Printer

Episode 560: Raspberry Pi Controlled Lego Train with Build HAT

Episode 559: Create a Magic Makeup Mirror with Pose Detection

Episode 558: 3D Object Rendering Using an FPGA

Episode 557: Create your own Handheld Serial Monitor for Project Debugging

Episode 556: Hacking a Hotel POS Tablet - How Hard Can it Be?

Episode 555: Dance Central Pose Estimation Game with Tensorflow and Raspberry Pi

Episode 554: Arduino Uno Mini Limited Edition LED Necklace

Episode 553: Adding a Parallel Printer Port to an Android Phone

Episode 552: Magical Potion Bottle Rack

Episode 551: Can We Rebuild a 1930s Accounting Machine?

Episode 550: DIY Electronic Controlled Motorized Wheelchair

Episode 549: Using a Teletype Machine as a USB Printer with Arduino

Episode 548: Electronic Fidget Cube, Building Your Ideas!

Episode 547: Creating a “Mummy” Wake Word Detector with Raspberry Pi and Edge Impulse

Episode 546: Mapping the Outputs of a 1960s Teletype Machine - How Hard Can it Be?

Episode 545: Designing a Custom PCB for Microsoft Jacdac

Episode 544: Reviving the 1984 IBM 5155 - How Hard Can It Be?

Episode 543: Lego Spike Prime Weather Station with Raspberry Pi

Episode 542: A Noise-Free DIY Switching Power Supply - How Hard Can It Be?

Episode 541: Vintage Laptop Battery Replaced with USB Power - How Hard Can It Be?

Episode 540: Object Detection for Smart Recycling

Episode 539: Training a Machine to Recognize Objects - How Hard Can It Be?

Episode 538: How to Build a Quadruped Robot - NO MATH!

Episode 537: Build a Phonograph Preamplifier - How Hard Can It Be?

Episode 536: Interactive Light-Up Window with Pose Detection using a Raspberry Pi and micro:bit

Episode 535: Repair a Sega Game Gear - How Hard Can It Be?

Episode 534: Open Source Inventory Warehousing System

Episode 533: Jumbo DIY LED

Episode 532: World’s First Single-Chip Apple II Boots!

Episode 531: Game Guy - The Unportable Game Boy

Episode 530: MQTT controlled LED Christmas Baubles with Raspberry Pi Pico

Episode 529: UPDI Program for new ATTiny

Episode 528: Let's Build an Electronic Fidget Cube!

Episode 527: Interactive Light Up Window using a Raspberry Pi and micro:bit

Episode 526: CNC Router Remote Control

Episode 525: DIY Helmholtz Snow Globe

Episode 524: Arduino IoT Cloud Weather Station

Episode 523: Make your Own Auto-Sensing Solder Fume Extractor

Episode 522: Siren Head Halloween Wearable Costume

Episode 521: DIY Static Grass Applicator

Episode 520: Adding Android Auto as Non-Permanent Add-On with Raspberry Pi

Episode 519: Make Your Own Ye Olde Book Nook Diorama with Arduino

Episode 518: Guitar Vacuum Tube Distortion Pedal

Episode 517: Emulate an EPROM - How Hard Could it Be?

Episode 516: Modding a Wireless Doorbell with Raspberry Pi and ESP8266

Episode 515: Upcycling a Lenovo PC into a Raspberry Pi WiFi Access Point

Episode 514: Making a 3D Graphics Card for the Atari 800 XL

Episode 513: Bike Speedometer with Arduino and GPS

Episode 512: You Cannot Buy This Vacuum Tube Tester. You Build It!

Episode 511: Raspberry Pi Powered Cheeseball Launcher

Episode 510: Laser Cutter Command Station

Episode 509: DIY Discrete Logic LED Countdown Timer

Episode 508: Raspberry Pi FPV Rover Easy Robot Arm Upgrade

Episode 507: Massive Raspberry Pi

Episode 506: DIY Star Trek Tricorder from Build Inside the Box

Episode 505: Super 8 Camera Digitizer

Episode 504: DIY Sump Pump Alarm

Episode 503: Meet Cheesoid - The Robot That Smells!

Episode 502: Make Your Bike a Pokebike!

Episode 501: Raspberry Pi NFC Button-Free Music Player

Episode 500: Build Inside The Box Challenge!

Episode 499: DIY Four Channel Arduino Servo Tester

Episode 498: Raspberry Pi Smart Water Dispenser

Episode 497: RFID Pocket Money Keeper

Episode 496: Compute Module 4 Powered 3D Printer Board

Episode 495: Magic GIF Ball Powered By Raspberry Pi

Episode 494: Keyboard Shortcuts Keypad with Raspberry Pi Pico

Episode 493: NeoPixel 7 Segment Display Clock Update

Episode 492: Arduino vs 555 Timer - Tiny Slot Car Racers

Episode 491: Arduino Single-Wheel Balancing Robot

Episode 490: DIY Raspberry Pi Pico Fizz Buzz Multiplication Game

Episode 489: Build An FPV Rover with Raspberry Pi

Episode 488: DIY Raspberry Pi Cyberdeck

Episode 487: DIY MagSafe Battery Charger

Episode 486: Make The Ultimate Phone Charging Camping Flashlight

Episode 485: How To Make A Custom PCB From Design To Assembly

Episode 484: Raspberry Pi Bird Watching Camera

Episode 483: DIY Miniature Multimeter

Episode 482: Gigantic 3D Printed 7 Segment Display Clock

Episode 481: DIY LOST Swan Station Split Flap Display Timer

Episode 480: DIY Toothbrush Timer

Episode 479: Raspberry Pi 2XL Robot Assistant Part 2

Episode 478: Upgrading A Christmas Train

Episode 477: Metal Plate Your 3D Prints with a DIY Galvanizing Machine

Episode 476: IoT Arduino NTP World Clock with SPI Display

Episode 475: DIY Wall Mounted Arduino Barometer

Episode 474: Continuum Robot Tentacle Prototype

Episode 473: Mendel 3D Printer Upgrade and Maintenance

Episode 472: DIY Hydration Reminder System

Episode 471: DIY Dance Dance Revolution Mat

Episode 470: Voice Activated Inspector Gadget Hat

Episode 469: Nintendo Super Scope Modded For Modern Televisions

Episode 468: Socially Distanced Halloween Candy Dispenser

Episode 467: Repairing the World's First Laptop! (Epson HX-20)

Episode 466: Arduino-powered Hexadecimal Color Code Clock

Episode 465: Lego Raspberry Pi HQ Camera

Episode 464: Particle Voice Recognition for Home Appliances

Episode 463: Raspberry Pi Speech to Text LED Face Mask

Episode 462: Joycon Controlled Electronic Rock'Em Sock'Em Robots

Episode 461: Portal 2 Security Camera with Raspberry Pi 2

Episode 460: Trinamic Open Source Ventilator (TOSV) Teardown

Episode 459: Raspberry Pi 4 VR Conference Call Assistant

Episode 458: DIY Arduino Automated Metal Bending Machine

Episode 457: Raspberry Pi 4 Animatronic Rosie the Robot from the Jetsons

Episode 456: Unhackable Arduino Switch Matrix

Episode 455: Arduino Unit Conversion Calculator

Episode 454: Soldering Up the rc2014 Homebrew Z80 Computer Kit

Episode 453: Build an Anti-Troll Bot Using TensorFlow and Arduino

Episode 452: Raspberry Pi 4 Experimental Resin 3D Printer Updated!

Episode 451: Build an Off Grid Wikipedia with Raspberry Pi

Episode 450: Sega GameGear Rebuild with LEDs

Episode 449: DIY Tamagotchi - Build a Virtual Pet

Episode 448: DIY Raspberry Pi 4 Boxing Game

Episode 447: DIY Stop Motion Rig with LattePanda

Episode 446: Raspberry Pi 2XL Robot Assistant Part 1

Episode 445: Raspberry Pi 4 Animatronic BD-1 Companion Robot

Episode 444: Raspberry Pi 4 DVR

Episode 443: Arduino Uno RC Remote - Can It Be Done?

Episode 442: Make Your Own Giant Servo

Episode 441: Raspberry Pi 4 International Space Station Tracker

Episode 440: DIY Arduino Helicopter Collective Joystick Control

Episode 439 - Mechanical Arcade Game with Barebones Arduino

Episode 438: Smartphone Controlled DIY Rover Using Websockets

Episode 437: DIY Motorized Zoom for Your DSLR

Episode 436: Automated Raspberry Pi Planet Tracking GOTO Telescope

Episode 435: Raspberry Pi 4 Music Player w/Analog Controls

Episode 434: Infineon Smart City Model

Episode 433: Arduino Based Love Tester

Episode 432: Super FX Sword using the BBC micro:bit

Episode 431: Room-Sized Studio Light Speakers Combo

Episode 430: Flaming Xylophone Rubens' Tube

Episode 429: YouTuber "On Air" Light with Particle Mesh Network

Episode 428: Raspberry Pi 4 CRT-based VR Headset

Episode 427: DIY Retro Gaming Portable on a Budget!

Episode 426: Retro TV Ads Holiday Ornament

Episode 425: Make Your Own Raspberry Pi 4 Photobooth!

Episode 424: DIY Escape Room Puzzle

Episode 423: Programmable Arduino Synthesizer Watch

Episode 422: Raspberry Pi E-Ink Task Organizer

Episode 421: Raspberry Pi 4 Commodore SX-64 Inspired Portable Computer

Episode 420: DIY Shapeoko CNC Pendant

Episode 419: Altair 8800 Laptop

Episode 418: Animatronic Terminator Skull with BeagleBone® AI

Episode 417: #Pipboy 2000 Mk II

Episode 416: DIY #3DPrinted Label Spooler

Episode 415: Iron Man Helmet Heads Up Display

Episode 414: Raspberry Pi 4 Experimental Resin 3D Printer

Episode 413: Animatronic Claptrap Case Mod Part 2

Episode 412: Get to Know Your ADC with a DIY Temperature Probe

Episode 411: Animatronic Claptrap Computer Case - Part 1

Episode 410: MacPro G5 Cheese Grater with Raspberry Pi 4

Episode 409: Commodore SX-64 Restoration

Episode 408: Hand Soldered LED Oscilloscope

Episode 407: The Ultimate Raspberry Pi 4 Laptop

Episode 406: Automated Robot Artist

Episode 405: RC Ornithopter Concept

Episode 404: Arduino Powered Close Encounters Midi Light Board

Episode 403: Upcycled IoT Coffee Pot Ramen Maker

Episode 402: PiPhone++ The Giant Raspberry Pi Flip Phone

Episode 401: Matrix Voice Controlled Robot

Episode 400: The Ultimate Raspberry Pi Stress Test

Episode 399: Candle-Powered Robotl

Episode 398: Let Me Out Hooman! Bluetooth Dog Doorbell

Episode 397: Steam Powered Retropie Console

Episode 396: Arduino Retro LED Matrix Handheld

Episode 395: Raspberry Pi Stop Motion Machine

Episode 394: Animatronic GLaDOS Head with Raspberry Pi

Episode 393: GameBoy Walkman

Episode 392: Multi-Line Telephone Intercom

Episode 391: First Person View RC Car with PS2 Steering Wheel

Episode 390: Retro Texting Smart Watch of the Future!

Episode 389: PlayStation Classic Portable Prototype

Episode 388: FPGA MIDI Music Synthesizer

Episode 387: Rotocell - The Rotary Cell Phone of the Future!

Episode 386: Xybernaut Wearable PC

Episode 385: 20 PCB Design Pitfalls

Episode 384: Retro Gaming Handheld Without a PCB

Episode 383: Gameboy Wireless Link Cable (DMG1)

Episode 382: Modding a Super 8 Camera into a Digital

Episode 381: Reverse Music Box

Episode 380: NES Zapper on RetroPie

Episode 379: Macroscope Soldering Tool

Episode 378: Invader ZIM Animatronic GIR

Episode 377: Altair 8800 Replica

Episode 376: 4D Gaming with the Matrix Creator

Episode 375: Hacked Fetal Detector Music Synthesizer

Episode 374: Raspberry Pi Donkey Kong Holiday Ornament

Episode 373: Raspberry Pi Fallout Terminal PC

Episode 372: Raspberry Pi Auto Etch A Sketch™

Episode 371: FPGA "Game Genie" for Atari 2600

Episode 370: Raspberry Pi NOAA Satellite Receiver

Episode 369: Recreating the Atari Portfolio

Episode 368: Arduino Automatic Wire Cutter and Stripper

Episode 367: Most Useless IoT Device Ever - Part 2

Episode 366: Infinity Icosahedron

Episode 365: Twilight Zone Fortune Telling Machine

Episode 364: Raspberry Pi Virtual Reality Arcade #VR

Episode 363 - Add a Motor to your Bike with Arduino

Episode 362: Most Worthless IoT Device Ever Pt. 1

Episode 361: R.O.B Rebuild and Upgrade

Episode 360: Make Your Own Raspberry Pi Cell Phone

Episode 359: Make Your Own CNC Pyrography Wood Burner

Episode 358: The Shrimp of Terror!

Episode 357: Raspberry Pi Asteroid Tracker

Episode 356: Bank to the Future with Arduino & TI

Episode 355: Raspberry Pi Pirate Radio

Episode 354: Tiny Vacuum Forming Machine

Episode 353: Program Your Own FPGA Video Game

Episode 352: Pripyat - DIY Geiger Counter

Episode 349: Raspberry Pi Selfie Rocket

See All Previous Episodes

Tags: episode releases, friday_release_archive, element14 presents, project videos, episodes, friday releases, episode release archive, episode archive, friday release archive, project_videos

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

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!

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

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

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

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

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

Time to Build a Robot!

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

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

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!