Computer engineering student · Georgia Tech

Anuj
Kakkad

I build embedded software and firmware at the boundary between hardware and software—where a physical signal becomes data, a system makes a decision, and careful engineering turns an idea into something dependable.

Focus
Firmware & drivers
Next
Summer 2027 internship
Based
Atlanta, Georgia
Charcoal line drawing of a disassembled mechanical pencil
Ideas begin as marks on paper.

A / ABOUT ME

Engineer, maker, and careful observer

The person behind the projects

I am a computer engineering student at the Georgia Institute of Technology who enjoys understanding systems all the way from their physical inputs to the software that controls them.

That interest has taken me through embedded software, firmware, device drivers, hardware test automation, and computer vision. In each setting, I have been drawn to the same kind of question: how do you make a complex technical system observable, testable, and trustworthy? I like work that requires both low-level attention and a wider systems view—reading a datasheet, tracing a timing issue, designing an interface, and then stepping back to ask whether the whole product behaves the way a person expects.

My experiences have also shown me that good engineering is collaborative. A reliable solution is not only correct code or a clean circuit; it is also clear documentation, thoughtful abstraction, reproducible testing, and communication that helps a team make decisions. I have learned to value the moments when an experiment disproves an assumption, because those moments turn uncertainty into useful evidence.

Outside of engineering, chess and charcoal drawing shape the way I think. Chess trains me to examine consequences before acting, while drawing makes me slow down and notice proportion, texture, and detail. Both practices reward iteration. They remind me that strong technical work is rarely produced in one pass; it develops through observation, revision, and a willingness to look again.

B / RÉSUMÉ & EXPERIENCE

Evidence in practice

Charcoal drawing of a test instrument connected to a laptop

Intuitive

Software Engineering Intern

Developed a custom C driver for a high-voltage insulation tester using SCPI-over-serial with 1 kHz real-time monitoring. I implemented a mutex-synchronized background thread and 8,192-sample circular buffer, reduced mutex hold time to sub-microsecond duration, and created platform-agnostic thread and mutex abstractions for Windows and Linux. Direct serial communication reduced query latency by 45%, from 5.1 ms to 2.8 ms, compared with the vendor IVI driver using NI-VISA.

CSCPIWin32POSIX
Charcoal sketch of a compact circuit-board test fixture

Moderna

Technical Development Co-op

Developed C#/.NET drivers for an Advantech USB-5860 digital I/O controller with edge detection and debouncing. I built a state-machine test automation system with more than fifteen states, processing 300 tests per day across six stations, and implemented a simulated hardware abstraction layer that reduced hardware-dependent testing cycles by 50%. The system published measurements to Snowflake through RESTful APIs, while Jenkins automated builds and installer generation.

C#.NETJenkinsSnowflake
Charcoal sketch of a microscope and microfluidic slide

Sulchek BIOMEMS & Biomechanics Lab · Georgia Tech

Undergraduate Researcher

Built and trained a convolutional neural network in Python to detect cell clogging in microfluidic devices from microscopy imagery, achieving 97% accuracy on a 3,000-image dataset. I also implemented the image-preprocessing pipeline, including data augmentation and a train-validation split.

PythonTensorFlowComputer vision

C / CAREER GOALS

From here to there

A roadmap designed to evolve

My near-term goal is to earn an embedded software or firmware internship for Summer 2027. Long term, I want to design reliable embedded platforms where low-level software, device interfaces, and hardware constraints are considered together.

I am especially interested in roles that sit between hardware and application software: understanding a device’s electrical and timing requirements, building the driver or firmware that exposes its capability, and creating tests that make the full system dependable. I do not expect the path to be perfectly linear. Instead, I am using coursework, project work, research, and internships as structured experiments that reveal which problems and team environments bring out my best work.

  1. 01

    Now · Build depth

    Strengthen the fundamentals

    Deepen my understanding of data structures, digital design, object-oriented programming, operating systems, and embedded development. Continue practicing C/C++, Python, Bash, and low-level debugging while documenting what I learn.

  2. 02

    Next · Connect disciplines

    Ship complete systems

    Build projects that combine sensing, real-time software, algorithms, and hardware-aware optimization. Treat testing, measurement, and communication as design requirements rather than afterthoughts.

  3. 03

    College · Learn in context

    Seek high-feedback experiences

    Pursue internships, research, and engineering teams where I can learn from experienced designers, contribute to real deliverables, and see how technical tradeoffs change under schedule, safety, and product constraints.

  4. 04

    Long term · Own the interface

    Design trustworthy embedded platforms

    Grow into an engineer who can move between device behavior, firmware, system integration, and validation, helping teams build efficient products whose behavior can be explained, tested, and trusted.

D / DISCOVERY PROJECT FEATURE

Chess Specs

Embedded computer vision chess assistant

Charcoal concept drawing of smart glasses with a camera connected to an embedded board
Original project concept illustration · camera → board → move

Chess Specs explores a simple question with a difficult engineering answer: can a wearable embedded system watch a physical chessboard, understand the position, and recommend a move without sending the problem to the cloud?

Platform
ESP32-S3
Software
C / C++, ESP-IDF, FreeRTOS
Input
640 × 480 camera frames
Methods
Vision, state tracking, minimax
Chess Specs system architecture Camera frames flow through square change detection and board-state reconstruction into a chess search engine, which returns a recommended move to the user interface. 01 / SEECamera 02 / NOTICEChanges 03 / THINKSearch 04 / RESPONDMove
System architecture diagram created for this project feature.

01

The problem

Most digital chess tools begin with a position that is already represented as data. A person enters moves, uploads a notation file, or plays on a digital board. Chess Specs starts earlier, with an ordinary physical board. The system must observe pieces through a wearable camera, determine which squares changed, maintain a valid internal representation of the game, and provide a useful response on constrained embedded hardware.

That makes the project more than a chess engine. It is a pipeline of uncertain observations and stateful decisions. Lighting, camera position, hands moving across the board, and visually similar pieces can all create noise. Meanwhile, the software must preserve the order of moves and avoid allowing an old camera frame or a slow search to overwrite newer information. The design challenge is to divide this work into components that remain responsive, understandable, and testable.

02

The process

I organized the system around four responsibilities: see, understand, think, and coordinate. The “see” stage captures 640 × 480 frames from a camera connected to an ESP32-S3. Rather than attempt an unconstrained image-recognition problem, the vision approach uses the known geometry of a chessboard. Each square becomes a region that can be compared over time, allowing the system to focus on changes that may represent a move.

The “understand” stage translates visual change into board state. Starting from the standard initial position gives the software a strong prior: it knows which pieces can legally move and can compare observed square changes against possible transitions. This approach turns computer vision into one source of evidence rather than the sole authority. If an observation is ambiguous, game rules and the existing state help narrow the interpretation.

The “think” stage uses minimax search with alpha-beta pruning, iterative deepening, and material and positional evaluation. Iterative deepening is important on an embedded platform because it allows the search to produce a usable result at a shallow depth and improve it while time remains. Alpha-beta pruning reduces branches that cannot change the decision, helping limited compute go farther.

Finally, the “coordinate” stage uses FreeRTOS tasks, queues, and position versioning to keep vision, search, and user-interface work synchronized. Versioning matters because embedded systems are concurrent: a search result is only useful if it belongs to the current board state. Attaching identity to each position makes stale results detectable instead of silently wrong.

03

The outcome

The project produced an end-to-end architecture for capturing a physical board, reconstructing moves, and generating an on-device recommendation. Its most important result was not a single algorithm; it was the way the pipeline connected perception, state, search, and real-time coordination. Designing those boundaries made it possible to reason about where an error originated and what information each component needed.

Chess Specs also clarified the tradeoffs of edge computing. Keeping computation on-device can reduce latency, preserve privacy, and remove dependence on a network connection, but it demands careful use of memory and processing time. The project therefore became an exercise in deciding which assumptions could simplify the problem without making the system fragile.

04

Reflection & next steps

This work strengthened my interest in hardware/software co-design because every subsystem affected the others. Camera resolution influenced processing cost; state representation influenced concurrency; search strategy influenced response time; and user expectations influenced the acceptable balance between speed and depth. I learned to treat interfaces and synchronization as central design decisions rather than implementation details.

The next iteration will focus on testing under varied lighting and viewing angles, measuring end-to-end latency, and building a repeatable evaluation set for move detection. I also want to explore confidence scoring and recovery when the observed move is ambiguous. These additions would make system behavior easier to evaluate and would provide clearer evidence for future architectural choices.

PROJECT ARCHIVE / BUILT TO GROW

More work, one consistent lens

This archive will expand as I complete new coursework, research, and personal builds. Each entry will document the problem, my decisions, the evidence I collected, and what I would change next.

01

Microfluidic clog detection

Computer vision research using regional classification and temporal persistence.

02

Automated hardware test station

A state-driven C#/.NET platform for repeatable device measurement and pass/fail logic.

03

SCPI instrument driver

Cross-platform C software for low-latency measurement, buffering, and real-time monitoring.

E / TOOLKIT

What I work with

Programming

C, C++, C#, Java, Python, Bash

Platforms

Embedded Linux, FreeRTOS, ESP-IDF, Windows, Linux

Hardware

ESP32-S3, digital I/O controllers, I²C, SPI, UART

Software

CMake, GDB, Git, .NET, TensorFlow/TFLite, Jenkins, Snowflake

Communication

Design proposals, technical reports, presentations

Coursework

Data structures and algorithms, digital design logic, object-oriented programming

F / CONTACT

Let’s build something thoughtful.

I am seeking an embedded software or firmware internship for Summer 2027 and welcome conversations about device drivers, real-time systems, hardware-software integration, and embedded computer vision.