Computational Engineer · ML · Simulation · Robotics
I'm a computational engineer. I work at the intersection of physics, engineering, and software, on the problems that don't have an off-the-shelf answer.
The hardest problems live where several fields overlap. Take robotics: a robot that loses its target isn't a vision problem or a control problem or a software problem on its own. It's all of them at once.
I work across all three, producing systems whose behaviour you can trust. Only edge cases imposed by nature are out of reach. The case studies below show what that looks like.
A closer look at how a hard problem became a working system.
A vision-guided robot kept losing the person it was meant to follow whenever they moved too quickly. The problem was diagnosed as a concurrency-model failure, and the system was rearchitected from Python to Rust, after which the robot held its target where it had previously lost it, with end-to-end latency roughly halved.
Read case study 3 minA startup needed to see drones in the sky reliably, tell them apart from the birds and planes that fool most detectors, and know where each one was heading. I built a real-time system that does all three, and beats the published state of the art at drone detection on every object size, on the same public benchmark. On one brutally hard clip the best published model missed the drone in all 300 frames; mine found it in 262.
Read case study 4 minGetting an AI to generate things is easy. Getting one you can trust to act on someone's behalf, unsupervised, is the hard part, and it is an engineering problem more than a prompting one. I built such a system for personalized cold outreach, where a single mistake lands in a stranger's inbox. By hand, one can write maybe 50 personalized emails a day. The system can now run until it hits the email provider's send limit, which is ten times higher than that, at the same personalization and the same reply rate, with the operator out of the loop.
Read case study 6 minA finite-element model of a steel shaft, built with straight-edged elements, predicts the bend of the part to within about five percent of the exact answer. That agreement turns out to be an accident: two unrelated errors happen to cancel each other out. Redesigning the geometry makes it obvious that using straight-edged elements for a bending problem can lead to a prediction that is, in the worst case, 60% off.
Read case study 5 minFrom the reference letters of people I worked with directly.
Much of the difficulty was in the robot rather than the code. Its SDK was poorly documented, and a fair amount of the machine's behavior had to be determined by running it and observing it rather than by reading what it was meant to do. He worked through that independently. Midway through, I saw the robot hit an obstacle and tip over, and asked what could be done. He suggested using the lidar already on the robot to stop it acting close to an obstacle, and implemented it within the week without the rest of the schedule slipping.
He began by reproducing the published model we were benchmarking against, matching its reported results to within about one percent, before building a new model that outperformed it. He worked largely independently. I gave him a broad problem, and he returned a scoped one, solved and well documented. The work he handed back was clear and checkable. I would be glad to work with him again.
He is the kind of engineer who can take a loosely defined problem and turn it into a working system. The code he leaves behind is tested, documented, and structured so that others in the lab can build on it.
Selected engineering work across automation, robotics, and research systems.
Lets an operator inspect a hazardous industrial site remotely. The whole system is driven by plain language: the operator tells it what he is looking for, and the system handles the rest, built on semantic navigation and an adaptive memory of the places it has seen.
Improved robot responsiveness in high-stakes situations. A Rust port of the Loaden runtime targeting edge devices with hardware accelerators, trading Python's flexibility for predictable low-latency execution and compile-time safety.
Cut down time spent on physical experiments by identifying laser parameter limits in simulation before any rock is touched. A finite element model of laser-induced thermal stress in rock, built with FEniCSx and Gmsh and validated against analytical solutions.
A real-time system that detects drones, tells them apart from birds, planes, and helicopters, and forecasts where each is heading. It beats the published state of the art, with the biggest gains on the small, distant drones.
Gives operators a single screen to monitor a live robot without needing terminal access or raw log files. Built as a full-stack dashboard that streams telemetry, camera feeds, and system logs in real time via a Flask/Socket.IO backend and React frontend.
Cut the human time required to run targeted outreach campaigns to zero. A cloud-based system that accepts a high-level category instruction and operates end-to-end without intervention.
Built a system that made it systematic to detect whether political risk ratings are in structurally distinct states rather than relying on visual inspection or domain intuition. The pipeline implements statistical jump models, graph auto-encoders, and tuned classifiers on political risk time series.
Built a system that made it tractable to synthesise patterns across ~600 academic papers that no human team could read in full in a reasonable timeframe. The pipeline runs end-to-end NLP analysis using LDA and BERT topic modelling with semantic cross-validation and visualisations.
Frees tradespeople from carrying loads on construction sites by automating the logistics entirely. Built as the core automation stack for an autonomous load-carrying robot, covering coordination logic, motion planning, and system-level control in Python and ROS.
Denis Zenios