Project Scope
Control Model
OPC UA client writes axis values, Raspberry Pi server translates them into serial G-code, and FarmBot hardware executes the movement request.
Runtime Platform
Raspberry Pi 4 with FarmBot OS, Python OPC UA services, and serial communication to the Farmduino controller.
Operator Tooling
UaExpert and custom Python clients used to write values, verify node updates, and observe live command handling.
Evidence Base
Hardware photos, UaExpert and Thonny runtime captures, and Python files from the prototype.
Project Overview
This project explored how an OPC UA software interface could be connected to a small FarmBot prototype so movement requests could be sent from a client and executed by the hardware.
The setup used a Raspberry Pi control node, Python OPC UA services, serial communication to the motion controller, and runtime captures taken during testing.
For this page, the material was reorganized into one clear project page that explains the control path without exposing unnecessary background detail.
Why This Project Matters
The strongest part of the project is not the mechanical frame itself but the control integration: a higher-level software client writes values into an OPC UA namespace, and the local controller turns those values into concrete movement commands.
That is a useful pattern because it reflects the same separation seen in industrial environments where operator tooling, protocol layers, and device-level execution are distinct concerns.
It also shows work across several boundaries at once: protocol design, Python scripting, hardware connectivity, serial debugging, and documentation.
Control Flow
Software entry point
- UaExpert and Python clients connect to the OPC UA endpoint exposed by the Raspberry Pi.
- The writable namespace carries axis values or command data that the operator can change live during testing.
Controller bridge
- The server loop checks for hardware readiness before issuing movement instructions.
- Once the controller is ready, the Python service formats and sends approval and G-code commands over serial.
Physical execution
- Farmduino and the downstream electronics interpret the command stream and drive the motion hardware.
- Response values and validation screenshots document that the control path was exercised end-to-end during testing.
What I Implemented
- Configured an OPC UA server namespace for command and response variables.
- Built Python logic that checked the FarmBot ready state before sending motion commands.
- Connected the OPC UA layer to serial output so entered axis values could become G-code.
- Used UaExpert to validate node visibility, writes, and live value changes.
- Captured hardware photos, protocol screenshots, and software runtime output for the final documentation.
Validation and Evidence
The visuals on this page come from the real prototype work rather than recreated mockups. They show the namespace in UaExpert, the server and client scripts in Thonny, the full communication poster, and the hardware used in the build.
That combination matters because it demonstrates both sides of the work: the code and protocol layer are visible, but so is the physical target system and controller stack.
The result is still a prototype and not a production industrial controller, but it clearly shows real integration work rather than a purely theoretical design.
Key Learnings
- Protocol abstractions become much clearer when every logical node is mapped to a real device or action path.
- Bridging from a clean software interface into serial hardware control requires explicit readiness checks and simple but reliable state handling.
- Even small prototypes benefit from clear documentation because the architecture is easier to understand when the runtime output is preserved.