Why it was needed

In Tunisia, hull inspections meant either pulling the ship out of the water, which is slow and expensive, or sending in a diver, which is risky. With the Compagnie Tunisienne de Navigation and MarConEx, we designed and built a small observation robot that streams live video from underwater.

What I built

The vehicle was modelled in SolidWorks, with water-flow simulations on the body and the propellers. Eight brushless thrusters, four vertical and four lateral, sit in PVC ducts and give the robot full movement on all six axes.

The watertight housing is a Ø110 mm PVC pressure tube with plexiglass end caps, flat gaskets and 14 stainless-steel screws. Cable glands and the junction box were sealed with resin, so fewer holes go into the main housing.

Inside are a Pixhawk running ArduSub, 8 motor controllers, two LiPo batteries, a pressure sensor for holding depth, and a Raspberry Pi 3B with a camera streaming HD video to the surface over Ethernet. The pilot flies it from QGroundControl over MAVLink with an Xbox controller, with automatic depth and heading hold.

Around the build we did the engineering studies (6-axis motion modelling, buoyancy calculations, functional analysis, and a full bill of materials with costing), then the hands-on work: CNC cutting, lathe machining, soldering, resin sealing and final assembly.

Why it was needed

SeaBot was piloting its first underwater robot from a regular laptop running open-source software. That setup had no protection and couldn’t be used outdoors. As the team built bigger robots with more instruments, they needed a dedicated control station. I designed it from start to finish: the software, the electrical system and the enclosure.

What I did

The pilot interface is Qt/QML with a C++ backend. It shows gauges for yaw, pitch and roll, plus depth, pressure, water temperature, the robot’s battery status, leak alerts and the live camera feed, with separate pages for robot setup, motor configuration, thruster tests and joystick setup. Joystick input is read with the QML Gamepad type and turned into motion commands (forward/back, left/right, up/down, lights, navigation mode), and each thruster can be tested on its own with a PWM slider.

On the hardware side I picked an onboard PC (Intel i5, NVMe SSD), a 17.3″ 4K main screen and a 7″ touchscreen for instrument data. I worked out the power budget, about 145 W, and designed a 4S12P pack of 18650 Li-ion cells (14.4 V, about 43 Ah) with a smart protection board.

The enclosure was modelled entirely in SolidWorks: an IP67 ABS case, CNC-cut plexiglass mounts for the screen and keyboard, and 3D-printed brackets in UV-resistant ApolloX.

To test it I built a stand-in for the robot’s internals. An ESP32 read the motion sensor and sent the data over serial, an ESP8266 drove the motor controllers, and an Ubuntu companion computer ran Python bridge programs. Thruster control, telemetry and live video all worked end to end.

Why it was needed

The idea came from my own job. Where I work, employees write their hours down on paper, and at pay time the boss collects the sheets and works out everyone’s hours by hand. I wanted to automate that. The project then grew to cover the other headache, planning the week itself: someone has to open and close every day, nobody should close at night and open the next morning, weekends have to rotate fairly, and some employees work in more than one store.

InventaLogic handles both halves: it generates the weekly schedule from each store’s own rules, and a check-in terminal at the store records real arrivals and departures, so the hours worked are counted automatically instead of collected on paper, and can be compared with the plan.

What I built

The scheduling engine works in two passes. A greedy pass first fills every shift, then a local search (hill climbing) keeps swapping shifts as long as the result gets better. It handles weekend rotation and adds up each employee’s hours across several stores. It is covered by Vitest tests and was checked against real convenience-store data.

The manager’s web app shows the week for every store, with coverage and hours per employee, a warning past 40 h, drag-and-drop shift swaps that are checked against the 11-hour rest rule, per-store rule settings, and an attendance page where any correction needs a reason. The backend moved from Flask (Python) to Express and Prisma on PostgreSQL, and the dashboard was rebuilt in React.

The check-in terminal is a Raspberry Pi 4 with a 7″ touchscreen running a Qt/QML app, in a case I designed in SolidWorks. Employees check in with a fingerprint or an NFC card: the GROW R558-S fingerprint sensor talks to the Pi over UART, which only worked once the port was set to two stop bits, and the PN532 NFC reader runs over I²C.

Hosting: the app is being deployed on my own Linux server at DigitalOcean.

My role: the system design, the scheduling rules and the engine logic, the terminal hardware, validating results with real store data, and deployment. Much of the web code was written with AI assistance (Claude Code).