Yuvraj
Singh
Industrial Engineering student at Purdue University, Class of 2029. Steering & Brakes, Purdue Baja Racing. Summer researcher at the match Institute, Hannover, Germany.
I'm a sophomore studying Industrial Engineering at Purdue, where I spend most of my time on the parts of a machine that have to fail predictably: brakes, drivetrain, and the structures that hold them together. On Purdue Baja Racing, I work on the Steering & Brakes subsystem — thermal analysis and rotor design for a car that has to survive four hours of endurance racing — and helped out with the drivetrain team on CAD/CAM for the competition gearbox.
This past summer I researched at match — the Institute of Assembly Technology and Robotics in Hannover, Germany, where I designed and built RobotSelector, a mixed-reality app for identifying industrial KUKA robots and streaming their live sensor telemetry — my first experience working inside a European research lab.
I'm also part of Purdue's Student Engineering Research Program (SERP), continuing that same AR/telemetry work, and I founded Future Engineers Academy, a free non-profit that runs hands-on STEM programming for elementary and middle-school kids around Long Island.
Quick Specs
Researcher
Designed and built RobotSelector, a mixed-reality app for identifying industrial KUKA robotic arms and displaying live sensor telemetry, developed in parallel for Apple Vision Pro (visionOS) and iPad (iPadOS).
- Engineered an ARKit + RealityKit selection system letting users tap or gaze-select a real robot and highlight it with a dynamic AR overlay
- Integrated a custom-trained Roboflow instance-segmentation model for KUKA-specific detection via a serverless REST pipeline, replacing generic foreground segmentation
- Built a live telemetry system pulling temperature, speed, and load from InfluxDB into a floating SwiftUI panel anchored in 3D space above the robot
- Diagnosed a visionOS platform constraint (no public API for raw camera frames) and architected a forward-compatible pipeline with a static-image fallback, ready to accept live frames the moment Apple exposes the capability
Member — Steering & Brakes
Design, analysis, and validation work on the car's braking system, including thermal analysis of the brake rotors under endurance-race loading. Also helped the drivetrain team with CAD/CAM on the competition gearbox.
- 1st Overall, 1st Endurance, 1st Hill Climb — Baja SAE Oregon 2026
- Brake rotor thermal modeling built on the team's DCR documentation and validated vehicle parameters
Captain / Drive Coach
Nearly five years on a FIRST robotics team, moving from member to Drive Team Captain and Drive Coach, plus starting a community outreach program for the wider FRC community.
- Won FIRST Impact Award (2024) and Engineering Inspiration Award (2022, 2023, 2024)
- Won the Long Island Regional (2022); finalist at the New York City Regional (2024)
- Placed #19 at the international competition as Drive Team Captain (2024–2025)
- Founded FIRST Together, a community outreach program for the FRC community
Founder
A free non-profit introducing elementary and middle-school kids to STEM — forensics, engineering, biology — through hands-on activities and presentations, currently running at the Hicksville Public Library and expanding to Queens, the greater New York area, and Indiana.
| Award | Program | Year |
|---|---|---|
| 1st Overall · 1st Endurance · 1st Hill Climb | Baja SAE Oregon | 2026 |
| FIRST Impact Award | FIRST Robotics Competition | 2024 |
| Engineering Inspiration Award | FIRST Robotics Competition | 2022, 2023, 2024 |
| Long Island Regional Winner | FIRST Robotics Competition | 2022 |
| New York City Regional Finalist | FIRST Robotics Competition | 2024 |
| 3rd Place Engineering Finalist, Long Island | Junior Science & Humanities Symposium | 2023–2024 |
Endurance racing puts a brake rotor through hundreds of hard stops over four hours — the question this script answers is whether a given rotor design can absorb that heat without cracking. It walks the full DRB flowchart end to end: total braking energy, how that energy splits between rotor and pad, single-stop temperature rise, a multi-hour endurance simulation with convective cooling, a thermal-stress failure check, and finally a sizing sweep for how much mass can be pocketed out of the rotor before it violates its thermal budget.
- Vehicle inputs are pulled from the team's Overall DCR Falcon Baseline — measured 392 lb (177.8 kg) comp-ready weight and 35.4 mph top speed — not estimates.
- Brake bias (65% rear / 35% front) comes from the Steering & Brakes design poster's actual achieved value, not the DCR's target range.
- Every assumption that isn't backed by a measurement is flagged inline as
EDIT MEin the script, so the model is explicit about where it's still conservative versus where it's grounded in real data.
| Parameter | Value | Source |
|---|---|---|
| Vehicle mass | 177.8 kg (392 lb) | Overall DCR Falcon Baseline — measured, comp-ready |
| Top speed | 15.83 m/s (35.4 mph, 2WD) | Overall DCR Falcon Baseline — measured |
| Brake bias | 65% rear / 35% front | Steering & Brakes design poster — achieved value |
| Rotor material | Steel 4130, annealed | Rotor material spec |
| Rotor mass (CAD) | 0.451 kg | Current CAD model — updated from 0.35 kg |
| Rotor OD / ID | 177.8 mm / 78.2 mm | Current CAD model |
| Rotor thickness | 2.286 mm | Current CAD model |
| Endurance event count | ~60 brake events / hr | Derived from 3:51.4 avg lap time, ~4 zones/lap |
The endurance simulation originally treated the rotor as stationary, with zero
forced convection, even though the car is actually moving and getting airflow
between brake zones. That assumption was unrealistically pessimistic for a full
4-hour race, so it's been replaced with a light-forced-convection estimate
(h_conv
≈ 50 W/m²K, still well below full ram-air cooling at speed). Re-running with
that change, plus the updated 0.451 kg CAD mass, dropped simulated peak rotor
temperature from ~406°C to 310.6°C and raised the thermal factor of safety
from 0.57 to 0.76.
0.76 is progress, not a pass. The rotor now fails by a smaller margin instead of a larger one, but it's still under the 1.0 threshold at the simulated peak — reached about 3.8 hours into the 240-event run, with the rotor cooling back down to 56.6°C by the end. That's the real open problem here, not the cooling coefficient: the model still predicts a crack risk under this specific duty cycle.
The mass side of the ledger looks healthier. The current 0.451 kg CAD rotor clears the 0.132 kg thermal-capacity floor by a 242% margin, and a known prior-year rotor (0.450 kg) clears the same floor by 241.5% in the new reference-rotor cross-check (Stage 6) — so there's room to add material for thermal capacity without meaningfully hurting the pocketing budget. Next step is deciding whether to close the FOS gap with more mass, better real cooling data, or both.
A destructive pinion testing rig was built by modifying a previous destructive rotor jig in SolidWorks, then assembled and run in the Baja shop. The goal was to validate the current car's pinion tooth geometry under increasing static load and check it against the team's analytical hand-calculator before trusting either one blindly.
Initial validation at 0.5" face width — the current car's configuration, reduced from 0.65" — held up to roughly 105 ft-lbs with no visible tooth wear, chipping, or deformation, closely matching the calculator's prediction. That's a solid baseline, but a rig that never breaks anything doesn't tell you where the real limit is.
- 0.5" face width pinion held exactly as expected, with no signs of failure at ~105 ft-lbs
- Strong correlation between test results and the analytical calculator at baseline
- Rig proved reliable for repeatable data collection across load conditions
- Face width reduced to 0.1–0.15" to intentionally push the geometry past its limit
Rig Modification
Adapted a prior destructive rotor jig in SolidWorks for the pinion's drive interface and static load path.
Baseline Validation
0.5" face width (current car config) held ~105 ft-lbs with zero visible tooth wear or deformation — closely matched the calculator.
Reduced-Width Setup
Machined a 0.1–0.15" face width pinion, deliberately undersized to force a failure under load.
Destructive Test & Failure
Loaded to failure on camera, capturing the peak load and failure mode for direct model correlation.
The reduced 0.1–0.15" face width did exactly what the 0.5" baseline couldn't: it failed. The load climbed steadily on the digital readout, then spiked and dropped out the instant the tooth gave way — a clean, repeatable failure event instead of an assumption.
That failure point is the actual data the team needed. The 0.5" baseline only confirmed the calculator was directionally right; this test gives a real number to calibrate it against — the same rigor applied everywhere on this site: be explicit about what's measured versus assumed.
Industrial mixed reality lets a technician look at real machinery and see live, contextual data floating in space, with no separate dashboard or manual lookup required. RobotSelector recognizes a specific KUKA robot through the camera, lets the user select it with a gaze-and-pinch or a tap, and displays its live telemetry — temperature, speed, load — directly above it in AR.
- Targets two platforms from largely shared code: Apple Vision Pro (visionOS, hands-free gaze + pinch) and iPad (iPadOS, tap-to-select via ARKit raycasting), so it can be tested on hardware available in the lab.
- Grew out of an earlier iOS object-detection prototype (AVFoundation + Core ML), then moved to ARKit scene reconstruction on Vision Pro, then added a custom-trained computer-vision model and live sensor telemetry.
- Key challenge: consumer AR platforms are built around strict camera-privacy models, and general-purpose vision models don't reliably distinguish one KUKA arm from the surrounding machinery — both had to be solved from scratch.
| Concept | visionOS | iPad |
|---|---|---|
| Entry point | ImmersiveSpace + WindowGroup | WindowGroup only |
| AR view | RealityView | ARView via UIViewRepresentable |
| Gesture | SpatialTapGesture | UITapGestureRecognizer |
| Mesh access | SceneReconstructionProvider | ARWorldTrackingConfiguration |
| Hit detection | Collision on mesh entities | arView.raycast() |
| Highlight | Material on mesh entity | Sphere entity at hit point |
iOS Camera Prototype
Live AVFoundation feed with Vision-framework object detection to learn the core capture pipeline before touching AR.
Core ML Object Detection
Upgraded from Vision rectangle detection (fell over on curved objects) to a YOLOv3 Core ML model via VNCoreMLRequest.
visionOS Mesh Selection
Built the first RobotSelector visionOS app — ARKit SceneReconstructionProvider meshes the room, tap highlights the chunk.
iPad Port
Ported selection logic to iPad using ARWorldTrackingConfiguration and arView.raycast(), with automatic LiDAR fallback.
InfluxDB Telemetry
Added an InfluxDB client (line-protocol writes, Flux queries) and a floating RobotDataOverlay panel above the selected robot.
Custom ML via Roboflow
Replaced generic Vision segmentation with a custom-trained Roboflow instance-segmentation model, secured via an .xcconfig API key.
Camera Restriction Discovered
Found that visionOS 1.0–1.2 exposes no public API for raw camera frames — a deliberate privacy limit, not a bug — and built static-image workarounds to keep developing.
Live camera access, multi-robot routing
Full hardware implementation on physical Apple Vision Pro once Apple exposes a frame-stream API — no iPad needed.
visionOS Camera Restriction
As of visionOS 1.0–1.2, Apple provides no public API to stream raw camera frames — an intentional privacy decision, not a bug — which blocked the planned Roboflow inference loop on Vision Pro hardware.
Fix — mesh-entity tap selection (geometry, not pixels) as a fallback, plus static test images cycled through the asset catalog to develop and demo the ML pipeline while awaiting a future frame-access API.
Generic Segmentation Wasn't Enough
Apple's built-in VNGenerateForegroundInstanceMaskRequest segments any foreground object — it cannot tell a KUKA arm apart from other lab equipment, and offered no class labels or confidence scores.
Fix — trained a custom Roboflow instance-segmentation model on labeled KUKA images, called via the Roboflow Serverless API every 1.5s, filtering results to the KUKA class at ≥ 50% confidence.
One Codebase, Two Interaction Models
visionOS uses gaze + pinch with mesh-entity collision; iPad has no gaze input and must raycast from a 2D tap into the 3D world. Early attempts duplicated app logic per platform.
Fix — kept ARKit session setup and gesture handling platform-specific, but shared all RealityKit entity, material, and InfluxDB telemetry code unchanged across both targets.
Flickering & Camera Freezes
Early iOS prototype bounding boxes flickered because every detection shared the ID "Object," and later builds froze because Vision/Core ML work competed with the camera session on the same thread.
Fix — gave each detection a stable UUID (Identifiable), throttled inference to every 3–6 frames, capped zoom, and dropped capture resolution to 720p to keep the pipeline responsive.
iPad prototype, running on live hardware
Screen recording of RobotSelector on a physical iPad, raycasting onto a real KUKA arm and pulling live telemetry through the floating overlay.
Everything on this site is backed by a real engineering notebook and a real deliverable. The samples below are pulled directly from the 44-page notebook I kept while building RobotSelector, and from the SERP research poster the project was presented on — full files are one click away if you want to read the whole thing.
SERP Research Poster
Reduced-width pinion, loaded to failure
Static load test on the 0.1–0.15" face-width pinion, filmed in the Baja shop — load climbs on the digital readout until the tooth fails and the pinion pops out of mesh.
This test is the direct follow-up to the 0.5" baseline validation — reducing the pinion face width on purpose to find the actual failure point instead of assuming one.
Pinion Torque Test Update #1
Some solid early results. Ran initial validation at 0.5" face width (current car setup, reduced from 0.65") — up to ~105 ft-lbs with no visible damage (no tooth wear, chipping, or deformation). Calculator correlation looked solid at the baseline condition.
- 0.5" face width pinion held exactly as expected under static load
- No signs of failure yet — good confidence check for the calculator and current design assumptions
- Next step: 0.1–0.15" face width test, aiming to push to actual failure and get a real data point for model correlation
Overall: baseline looked good — then it was just a matter of taking it to failure.
Baseline vs. Destructive
| Face Width | Load Applied | Outcome |
|---|---|---|
| 0.5" (current car) | ~105 ft-lbs | No visible damage — baseline confirmed |
| 0.1–0.15" (reduced) | Loaded to failure | Tooth failure achieved — destructive data point |