Author's Preface

In 2016 I bought a Raspberry Pi. I wanted it to do more than live on a screen and a command line — I wanted it to drive something I could see and touch. So I found three brushless motors, drew the structure, built the brackets, wired it up, and made a three-axis robotic arm by hand. It was hardly elegant, but the first time the three joints slowly turned under program control, I truly felt, for the first time, that a single line of code was changing the physical world.

Once I went deeper, the problems multiplied quickly. Brushless motors need drivers to receive PWM control signals, and encoders to report joint positions. I added an attitude sensor, limit switches, and current/voltage sampling so the arm could make sense of its attitude, limits, and load. Some sensors connected over I²C, some over SPI or a serial port, and the limit signals went straight into GPIO. The differences between these interfaces were more than swapping a cable: I²C meant device addressing, SPI meant agreeing on clock and chip-select, serial meant aligning baud rate and data format, and PWM carried control values through frequency and duty cycle. That was when I understood: the protocol decides whether two components can understand each other accurately.

I went back and forth between wiring and code. Arm jitter might mean position data arriving too late; angle jumps might just be bus interference. The Raspberry Pi runs a general-purpose operating system — good for computation, communication, and task orchestration, but not for real-time control with strict timing. Gradually I learned to pull acquisition, communication, computation, and control apart, and to see that a system works reliably only when every layer knows exactly what it is responsible for.

Later I wanted to see the arm's state on my computer, and to send it tasks remotely. The range of devices I worked with kept growing, and the protocols grew from board-level I²C, SPI, and serial to the industrial mainstream — Modbus RTU, Modbus TCP — and then to MQTT and HTTP at the platform level. Each had its own division of labor: Modbus organizes reads and writes around registers, MQTT carries device messages, HTTP exposes platform APIs. The real difficulty was not writing yet another isolated parser, but absorbing these differences — consolidating the data into unified devices, points, states, and commands, and handling reconnection and execution confirmation. These questions gradually led me to IoT platforms, and IoT DC3 grew from protocol parsing into device access, data collection, and platform services.

In 2024 I began connecting large language models to IoT DC3. The first time an agent fetched live device data from a natural-language instruction, I thought of that robotic arm again. The interaction had changed; the underlying problems had not. AI can understand intent, analyze anomalies, and call authorized tools — but it cannot replace closed-loop control, cannot take over safety interlocks, and must never operate devices without boundaries. Data must be collected reliably, device capabilities must be described accurately, and permissions and failure handling must be decided in advance. Only then does intelligence have somewhere to stand.

This book distills what I learned on the journey that began with that three-axis arm: how devices connect, how data flows, how a platform holds a complex system together, and where AI should — and should not — take part. IoT DC3 appears throughout to illustrate engineering choices, but it is not the only answer. Above all, I hope that when you face a new sensor, an unfamiliar protocol, or a model that seems capable of anything, you know which questions to ask first, and which fundamentals cannot be skipped.

The cover carries four words: Sense, Reason, Act, Evolve. They are the loop that robotic arm taught me — sensing turns the physical world into trustworthy data; reasoning turns data into candidate judgments; action carries a judgment back into the physical world through a deterministic boundary; and evolution is the way this loop unfolds over time: every step toward more autonomy must first be proven sound by new constraints.