Wajahat Mahmood

Software engineering  ·  Robotics systems

Wajahat
Mahmood

I build software that moves hardware, tests its limits, and makes the results useful.

C++ robot drivers. Python test automation. Full-stack applications.
Queens College CS · Graduating May 2027.
Open to 2027 software and robotics engineering roles.

C++ Python TypeScript ROS 2

Try a target, then change the constraints. You can also drag the arm’s target or focus the drawing and use arrow keys.

Open the Workcell Feasibility Lab → Go beyond a single target: check a six-pose transfer, compare fixture positions, and export a motion report.

How the arm demonstration works

A three-link planar chain uses FABRIK: place the tip at the target and work backward, then anchor the base and work forward, preserving each link’s length. Relative joint-angle limits are applied during the forward pass. The readout distinguishes a solved target from one limited by the constraints or outside the reach radius.

This is a geometric illustration, not a physical robot controller. Drag the target or focus the arm and use arrow keys; Home resets it. Reduced-motion preferences keep the controls available without animated easing.

Experience

hardware + software

  • rf IDEAS

    Software Engineer Intern, Robotics & Test Automation

    May 2026 – August 2026 · Schaumburg, IL

    Built Python software that sequences a six-axis xArm through RFID card pickup, barcode identification, reader configuration, and calibrated read-height tests. Background workers keep the interface responsive; completed results go to CSV, and joint telemetry feeds a separate ROS 2 visualization bridge.

    PythonxArm SDKpytestUDPCalibration
    • 3–12h
      Unattended
      run duration
    • 100+ h
      Unattended
      testing completed
    • 50+
      Cards used
      in validation
    • 6
      Reader
      models
    Demo1:25
    Credential Read Height Test control software GUI
    Control GUIScreenshot
    GitHub
    Inside the test system

    Scan card → map credentials → configure reader → pick + orient → descend until read → append result

    Problem. The manual validation workflow took roughly 30–40 engineer-hours per week. I automated the repeated positioning and configuration steps so large runs could continue unattended.

    Implementation. A keyboard-wedge listener identifies cards; a CSV maps them to reader configurations. A robot worker uses vacuum feedback and bounded pickup retries, then approaches a calibrated reader-top reference at four orientations. Tool-offset correction and wrist normalization make the poses and height calculation consistent.

    The difficult part. A card already inside the RF field can contaminate the next height measurement. Field-clearance moves and a final dwell at the approach floor give the reader time to register a new entry. Scanner focus handling also has to distinguish device input from someone typing in the GUI.

    Validation and boundaries. The repository has pytest checks for geometry, scanner focus, calibration storage, and result handling with fake-arm fixtures. Operational runs covered the cards, readers, and hours shown above. CSV records completed results; it is not a full crash-resume system. The vendor SDK supplies low-level motor control and inverse kinematics.

  • University of Michigan, Laboratory for Progress

    Robotics Software Engineering Researcher

    May 2025 – Jul 2025 · Ann Arbor, MI

    Implemented C++/SDL2 teleoperation for an RX-200 arm and contributed to RIX robotics middleware. Used atomics for desired joint velocities and a mutex around concurrent driver access. Added POSIX/TCP tests and fixed signal-bit reset and publisher handshake-readiness bugs.

    C++SDL2Interbotix SDKMutexes / atomics

    Research: Co-author, “RIX: A Minimal POSIX-Compliant Robot Operating System for Portable Robotics Education,” accepted to IEEE/RSJ IROS 2026. Related research presented at ABRCMS 2025. Michigan’s accepted-paper announcement ↗

    RX-200 driver source ↗
    Threads, driver ownership, and middleware

    SDL2 input → atomic velocity values → serialized SDK calls → RX-200 → joint-state publication

    My implementation. The original controller has input and command threads with 10 ms and 20 ms sleeps. My synchronization change adds a driver mutex, uses atomics for shared desired values, and moves shutdown motion after thread joins.

    Architecture evolved. Later executables separate controller messages, joint commands, and hardware state through RIX pub/sub. The modular driver requests a 60 Hz loop; that is a target, not a hard real-time deadline or measured rate for every executable.

    Beyond the driver. In upstream RIX libraries, I added GTests covering memory mappings, shared objects, endpoint semantics, and TCP modes. I also fixed a signal-bit clearing bug and waited for socket readability before a publisher handshake read. Those tests belong to middleware, not a driver-specific GTest suite.

Programs & activities

  • Google G-SWEP

    via Basta

    2026 · Mentorship program, not employment

    Selected for one-on-one mentorship from a Google software engineer through a 10-week program covering data structures, algorithms, and technical interview preparation.

    DSAInterview prepMentorship

  • CUNY Tech Prep

    Software Engineering Fellow

    Jul 2026 – Present

    Year-long full-stack fellowship with technical instruction, team projects, and industry mentorship across TypeScript, React/Next.js, Node.js, and PostgreSQL.

    TypeScriptReactNext.jsNode.jsPostgreSQL

Projects

GlanceScribe

AI MEDICAL SCRIBE

A four-person hackathon prototype pairing a live Meta-glasses video feed with browser-microphone transcription. ElevenLabs transcribes the audio; Gemini turns the committed transcript into draft SOAP notes. FFmpeg assembles recordings and selected highlights.

Node.js / ExpressSSEGeminiElevenLabsFFmpeg
GitHub Devpost YouTube
Winner
Best Healthcare
Hack Brooklyn ’26
Prototype
Draft notes
for review
From live streams to draft notes

Microphone → 16 kHz PCM → ElevenLabs WebSocket → transcript → SSE dashboard + Gemini SOAP

My work in the team build. I contributed the initial backend and recording integration; the final app combines that work with teammates’ interface and note-generation changes. The glasses stream arrives through an external client and an HTTP proxy, while browser microphone audio follows a separate path.

Implementation. The browser resamples audio to mono PCM and uses a short-lived transcription token. Committed text is appended on the server and sent to dashboards over SSE. Recording chunks are assembled with FFmpeg; transcript and body-focus intervals help select highlights.

Tradeoff. Simple in-memory session state made the hackathon integration quick, but does not isolate multiple clinical users. Gemini receives text for note generation, not video. JSON parsing is not clinical validation; this is a demonstration, not a deployed medical system.

DemoYouTube

CUNY Connect

STUDENT NETWORK

A networking platform for CUNY students, built with a hackathon team. Next.js Server Actions handle connections and messages; Supabase Realtime delivers new chat messages. Profile similarity and Gemini explanations drive recommendations, with caching and deterministic fallback scoring.

Next.jsTypeScriptSupabaseGeminiTailwindZod
GitHub
Messaging, matching, and failure paths

Profile → candidate filtering → weighted score → Gemini + Zod → seven-day cache or local fallback

My contribution. Built core networking, messaging, and recommendation features within the team project. Conversation creation checks accepted connections and uses a database function to reuse the same user pair. New-message subscriptions deduplicate messages by ID.

Implementation. Recommendations combine profile similarity with generated explanations. The response is validated with Zod and checked against allowed candidate IDs. Profile hashes and a seven-day expiry bound cache reuse; timeouts and missing credentials fall back to local scores.

Result and limits. Around 40 people were logged in during the demo, across different features; this was not a messaging load test. The app checks CUNY email domains, not student identity. Its RLS policies still need adversarial authorization tests and membership hardening before a wider release.

Student
profile
Feed +
network
Gemini
match
CTP ’26
Built at
CTP Hacks
~40
Logged-in users
during demo

Real-Time Collaborative Code Editor

CODING PLATFORM

A React/Monaco editor with debounced full-document updates through Flask and Socket.IO. C++ and Java runs use the Piston service; the static demo uses a separate peer-to-peer adapter. The pane here is an illustration with simulated peers, not a live session or a performance benchmark.

FlaskSocket.IOMonacoReactPiston API
120ms
Configured edit
debounce, not latency
Full buffer
Simple synchronization
not CRDT / OT
Live demo GitHub

Interactive illustration · simulated peers

session.cpp synced
01#include <asio.hpp>
02SharedDoc doc;
03on("edit", broadcast);
04auto n = merge(a, b);
05run(doc, Piston);
06// type · press Enter
local illustration · 0 interactions

Stack

BS CS · Queens College · May 2027
Languages
PythonC++TypeScript/JSSQL
Robotics & Systems
ROS 2 telemetryMultithreadingTCP / UDPRIX pub/subCalibration
Web
ReactNext.jsNode.jsFlaskPostgreSQLSupabaseSocket.IOWebSocketsREST APIs
AI integration
Gemini APIElevenLabs transcriptionZod validationFFmpeg
Tools
GitLinuxGTestpytestVitestSDL2