Arseni Aliakseichyk
Embedded and Infrastructure Engineer
Maze-Solving Robot Platform
Two-Board Robotics Platform for Three Algorithm Teams
GlobalLogic Poland • Jun – Sep 2026During my 2026 internship at GlobalLogic Poland I designed and built, from scratch, the platform for an autonomous maze-solving robot: a mecanum robot that maps and solves a walled maze. Three application teams wrote the solving algorithm in Python. Everything underneath it was mine: the drive firmware, the Python platform on the robot, the delivery pipeline, the build infrastructure, the simulator and the documentation the teams worked from.
The robot is split across two boards on three wires. The drive board (ESP32-S3, C on ESP-IDF with FreeRTOS) owns motion and sensing. A second ESP32-S3 runs MicroPython and gives the teams one small, safe API, so their code never touches a pin, a socket or a packet. The boards talk over a framed 921,600-baud UART link authenticated with a SipHash-2-4 MAC and sequence numbers; telemetry arrives at 20 Hz and wall-sensor frames at 15 Hz.
Drive firmware - C, ESP-IDF, FreeRTOS (~9,000 lines)
- 200 Hz safety and motion core: every command passes the same chain - watchdog, arming, mecanum mixing, deadband, slew limit - before it reaches the motors
- Arming after boot or stop plus a 350 ms command watchdog, so a crashed client or a closed browser tab stops the robot instead of letting it run
- PI heading hold on gyro yaw (ICM-20948) keeps "drive forward" straight without any help from the algorithm
- Six VL53L7CX time-of-flight sensors (4×4 zones each) behind a TCA9548A I2C mux; four gearmotors with quadrature encoders
- Signed OTA updates (RSA-3072) with A/B slots and bootloader rollback
Platform for the teams - MicroPython (~4,600 lines)
- Push-to-robot delivery: git push, lint gate, HMAC-SHA256-signed bundle, trial install, promotion after 30 s without a crash; three crashes fall back to a safe state with the upload page still available
- Fail-closed web interface on the board: without a provisioned key every control request is refused
- Crash forensics: liveness stamps in RTC memory show after a watchdog reset whether the team's code, the platform or something below Python stopped first
- Brought up the new board and moved the platform from ESP32-C3 to ESP32-S3 after measuring its memory limits; the solver now runs on the robot at 19.4 Hz with about 1.8 MB of heap free
Infrastructure and process
- Self-hosted GitLab and an Ubuntu build server: a dedicated service user, per-team SSH isolation, a post-receive hook that lints code and builds signed bundles, and per-team download URLs
- GitLab CI for the teams' repositories, with jobs running in parallel so one push reports every problem at once
- Jira/Scrum with story points; I prepared and presented the sprint reviews
Bench work, simulation and documentation
- Duty-to-speed characterization accurate within 5% over 100–500 mm/s
- Found why the robot took 1.5 s to start moving: the motor driver's dead zone had been tuned with the wheels off the floor. Restoring the factory value cut the delay to 0.4 s and added 44% to the distance covered in the first four seconds
- A simulator that runs the teams' code with no robot, using the same safety chain plus sensor noise and link dropouts; modelling wall-contact torque made a real heading failure reproducible on a laptop
- A 31-page API reference whose code examples are executed against the real platform and their printed output compared, so the document cannot drift from the code
- Found by code review that a negative
sleep()parked the team's code for about 50 days while the board still looked healthy; fixed with a regression test
Not mine
- The chassis CAD and 3D-printed parts were designed by the team's CAD engineer, and the maze-solving algorithms belong to the three application teams