Systems, machines, and the questions that survive the first working prototype.
I've been meaning to write here for years.
The pattern was reliable: buy a domain, scaffold a site, spend three evenings adjusting the typography, then leave the content directory empty. Apparently, I could engineer everything around writing except the part where I actually wrote.
So this time, the first deliverable is a post.
I'm interested in what happens after something starts working. Where does the time go? Who owns the state? What happens when a dependency disappears halfway through an operation? What does a controller do when the sensor is noisy and the mechanism has play?
Those questions tend to lead below the surface: from an endpoint to a process, from a process to a scheduler, from a motor command to current, heat, and motion. That's where I want this site to spend its time.
Who's writing this
I'm Anuj Karn, a Lead Full Stack Engineer at PivotX Advisors. I work across enterprise data and AI platforms, including finance and healthcare workflows. My responsibilities span application code, architecture, cloud infrastructure, access control, delivery, and leading the engineers who bring those pieces together.
Python, Go, TypeScript, and React are familiar tools. So are cloud platforms, databases, deployment pipelines, and the less photogenic work of making permissions and operational behavior understandable. A diagram is useful; knowing how to recover the system it describes is better.
I'm based in New Delhi, with home ties to the Kathmandu Valley and roots in Janakpur. Somewhere between work, travel, and the next unfinished project, I'm trying to make room for a much wider curiosity: robotics, intelligence, physics, photography, and eventually technologies that help us explore beyond Earth.
The job title describes part of my work. This notebook has room for the rest.
How I like to build
I want to be able to follow a system through its layers.
On Linux, that means being willing to inspect processes, sockets, namespaces, permissions, and resource limits when the application-level explanation stops making sense. I want a hypothesis before a command, and evidence afterward. A trace is useful when it answers a question; a terminal full of impressive output can still tell me nothing.
In architecture, I keep coming back to a few questions:
- Where does state live, and which component is allowed to change it?
- What can fail independently, and how far does that failure travel?
- Which operations can safely be retried, and what happens when they run twice?
- What would I need to observe to distinguish a slow dependency from a bad design?
- Could someone else reproduce the behavior and recover the system without me?
Sometimes the answer deserves a distributed system. Sometimes it deserves one process, a database, and fewer moving parts. I want to document the reasoning that makes the choice defensible.
Why write it down
First, memory is an unreliable dependency. I don't want to debug the same WSL2 and ROS 2 networking problem again with only a vague recollection that an interface setting mattered. I want the environment, the symptom, the failed hypotheses, and the fix in one place.
Second, writing exposes gaps. If I can't explain why I chose a control strategy or a service boundary, I probably owe the design another pass. A build log forces me to separate what I measured from what I merely expected.
Third, I want to find people who enjoy this kind of work. If your evening disappeared into a motor driver, a packet capture, or a paper you opened to answer one small question, we'll probably have something to discuss.
The work I want to put here
Robotics, starting at the actuator
The long-term goal is an arm on a mobile base. The immediate target is smaller: a pan/tilt camera head that moves predictably enough to deserve the next layer of complexity.
I'm exploring BLDC motors, cycloidal reductions, and quasi-direct-drive approaches. I want to understand the tradeoffs in torque, speed, backlash, compliance, heat, and how easily an external force can move the joint. Gear ratio alone won't settle the design.
The first control experiments will use SimpleFOC. Its closed-loop control modes provide a practical starting point for working with torque, velocity, and position control. My questions will be specific: how repeatably can I reach an angle, how does the response change under load, and what does the feedback signal actually tell me?
On the simulation side, I'm working toward a ROS 2 Jazzy and Gazebo setup on WSL2. The posts should include the awkward parts: coordinate frames, timestamps, discovery, environment configuration, and sourcing components in India.
A simulated joint, a spinning motor, and a useful actuator are different milestones. I'll keep their status explicit.
Learning systems, from the experiment upward
I also want to explore an agent that learns through interaction: observing an environment, taking actions, and improving its decisions from what happens next.
The starting point will be virtual, with deliberately small tasks. PyTorch, Gymnasium, MuJoCo, and implementations such as CleanRL are the tools I plan to work with. Before adding a learned world model, I want a baseline, a defined observation and action space, a reward I can explain, and an evaluation that can reveal failure.
Then come the more interesting questions. Does predicting future states improve decisions? Does a policy survive changes to the environment? Is an apparent improvement consistent across runs, or did I get attached to one favorable seed? What happens when observations are incomplete?
Eventually, I'd like this work to meet the robot. That introduces a harder boundary: a learned decision must become a bounded command that the physical control system can execute. Latency, actuator limits, and feedback become part of the experiment.
That is a research direction, with plenty left to learn. The posts will show baselines, configurations, failures, and results as they exist.
Engineering beyond the happy path
The professional side of this notebook will cover architecture decisions and delivery details that are easy to omit from a tutorial: identity across service boundaries, authorization, data ownership, retries, deployment and rollback, observability, and operating costs.
For AI systems, I'm especially interested in how tool use, workflow state, evaluation, and human review fit into the surrounding application. An impressive response is one event; the system has to handle what happens before and after it.
I'll also write about the practical engineering around security and audit requirements: how a control becomes an implementation, how its behavior is verified, and how evidence is retained. Examples from professional work will use generalized designs and synthetic data.
Photography, travel, and other ways of paying attention
I shoot on a Nikon D5300. There will be streets, landscapes, journeys, and occasional reminders that a camera bag occupies exactly the space I wanted for something else.
There will also be games and attempts to fill the holes in my understanding of mathematics and science. Photography makes me notice what I would otherwise walk past. Engineering often asks for the same patience.
What a useful post should leave behind
For a build log, I want the record to include the question, constraints, setup, decisions, evidence, and next experiment. If a result depends on a particular board revision, software version, or assumption, that belongs in the post.
A failure post should leave enough detail to help someone recognize the same failure. A successful experiment should leave enough detail to challenge the conclusion.
That's the editorial rhythm: build something small enough to inspect, measure what happened, revise the explanation, and choose the next experiment.
The machinery behind this page
The site lives at anujkarn.dev, with content managed in Sanity and a custom front end. The useful separation is between editing, content storage, and rendering. Sanity Studio is the editing interface; the structured content lives in Sanity's Content Lake, where the application can query it with GROQ.
I want the publishing workflow to support the material this notebook needs: readable code, diagrams, images, short animations, and corrections. I'll write about the schema, media pipeline, rendering, and caching once the setup has settled enough to explain honestly.
For now, the useful milestone is that there is something here to read.
Leave a trace
If you spot an incorrect assumption, a missing measurement, or a simpler design, tell me. I'd also like to hear about reliable component suppliers in India, useful papers, and projects that overlap with these questions.
Comments aren't wired up yet. Email works: hello@anukarn.dev.
The first build log I want to tackle is “Closing the loop: a BLDC motor, an encoder, and the first repeatable movement.”
The ambition is large. The next experiment should be small enough to finish.
— Anuj