The engineering question
How can a small robotic platform stay attached to a ferromagnetic wall, move controllably, and support inspection tasks? Wall Patrol One brings adhesion, motion, electronics and software into one evolving system.
The current design has moved from an early track concept toward rubber-wheel rear drive with an electro-permanent magnetic chassis. Its story is a sequence of decisions and verification tasks, not a claim of a finished field-ready robot.
A system with distinct responsibilities
| Layer | Current direction | Responsibility |
|---|---|---|
| High-level computation | Raspberry Pi 5 · 8 GB | Host-side software, interfaces and system coordination. |
| Real-time control | STM32G474RET6 · RTOS | Motor control, acquisition and low-level control tasks. |
| Communication | CAN · isolated interface | An expandable interface between control and peripheral modules. |
| Physical platform | Wheels + magnetic chassis | Wall adhesion, locomotion and mechanical integration. |
The interface architecture is a development baseline. It does not establish that every module is integrated and tested.
Magnetic adhesion & mechanical design
ANSYS Maxwell supports the magnetic adhesion study. The design considers the least favorable attachment condition and includes a pull-off-force margin relative to the platform weight.
A design criterion is not a measured adhesion result. Actual margin depends on the magnetic circuit, air gap, wall thickness and surface condition, as well as the real assembled mass. Mechanical mounting, wheel traction and load distribution must be checked together.
Control board · v0.3
The v0.3 architecture was frozen in August 2026 around the STM32G474RET6. Its development spans power domains, motor drive, isolated communication, sensing and debug access.
| Subsystem | Recorded components / interfaces |
|---|---|
| Controller | STM32G474RET6 · 24 MHz crystal · SWD |
| Motor drive | AT8236 H-bridge; left/right motor channels |
| Communication | ISO1042 isolated CAN · CH340 USB–serial |
| Power | Isolated DC–DC; 3.3 V regulation; distinct power/logic/CAN domains |
| Sensing & interface | MPU6050 · OLED / HMI · button input |
The board record covers schematic decisions and procurement changes. Firmware and wiring must follow the actual assembled board rather than an assumed generic STM32 pinout.
Firmware, interfaces & feedback
The current software direction combines Raspberry Pi 5 with STM32 control and a frozen V1 communication protocol. A virtual vehicle simulator supports early interface testing; an Android v1.0.0 installation has also been recorded.
Recent work focuses on motor-button debugging and OLED display of left/right real-time speed. These are active test tasks; requesting a behavior or generating code is not evidence that the motors have passed the corresponding hardware test.
Decisions between versions
- Early concept
A smaller controller-led platform
An initial STM32 + ESP8266 direction provided the starting point.
- System revision
Raspberry Pi 5 + STM32
Separate high-level computation from real-time control; retain CAN as the expansion direction.
- August 2026
Control-board baseline v0.3
Freeze the schematic architecture and record component substitutions against the actual build.
- Current
Bring-up and integration
Motor control, speed feedback, OLED and physical system debugging remain the focus.
Testing & what remains open
- Keep a known-good wiring and firmware baseline for each hardware test.
- Check supply rails, debug access and individual interfaces before combined motor operation.
- Separate direction control, encoder feedback and displayed speed as distinct verification steps.
- Validate magnetic attachment and mobility on representative wall conditions before making inspection-performance claims.
No measured payload, climbing speed, pull-off force or endurance is published on this page because the underlying test data were not supplied for this website update.
Selected records
Control-board v0.3 & development records
Schematic baseline, component decisions, V1 protocol, virtual vehicle testing and embedded-software iterations.
Source records are retained in the project archive. No hardware gallery or download is invented when its source files are not part of this website snapshot.
Next engineering steps
Close the motor and feedback tests, document the actual board wiring and firmware revision, then progress toward coordinated motion and adhesion testing. Add real photographs, measured curves and release documents as those records become available.
