02 / Robot control · Collaborative platform
How do you connect an experiment, its hardware and the data needed to understand it?
Inside the engineering / Interactive walkthrough
In the ball-balancing module, observations become an estimate, then a correction and a record of what happened. Select a stage to see its job in the system.
The report describes camera-based tracking and load-cell readings beneath the plate. These are different ways to observe the same physical experiment.
Each sensor has different limitations. Camera visibility and force calibration matter before a controller can trust the observations.
A guided reading of the repository technical report. This panel does not run the controller or reproduce its experimental results.
The report describes camera-based tracking and load-cell readings beneath the plate. These are different ways to observe the same physical experiment.
Why it matters: Each sensor has different limitations. Camera visibility and force calibration matter before a controller can trust the observations.
Input: Camera frames and serial load-cell readings
Output: Visual position and force-based observations
The documented estimator combines position estimates according to confidence and filters velocity. Online identification uses observations and previous control input to estimate the system’s response.
Why it matters: The controller needs an estimate of motion, not only a raw sensor value. Online identification lets the system estimate model parameters from incoming data instead of treating them as fixed assumptions.
Input: Sensor observations and previous control input
Output: Estimated position, velocity and model parameters
The control pipeline considers the ball’s position and velocity, selects a response and converts the correction into joint targets. The report describes clamping targets to calibration bounds before sending them to the actuators.
Why it matters: The correction must become a command that fits the hardware’s configured range, rather than an unconstrained model output.
Input: Estimated state, target position and calibration
Output: Bounded joint commands for the robot
The platform publishes telemetry to the interface. Repository guides and experiment figures let a reader inspect the architecture and the software-in-the-loop tests separately.
Why it matters: A system is easier to study when its commands, observations and test context can be reviewed together. Simulation figures remain labelled as simulation.
Input: Commands, observations and experiment context
Output: Telemetry, plots and development records
01 / The project
Core engineering team: Bilal Sabugar, Aditya Jadav and Archie Veera. My June–July 2026 research internship at the IITGN Robotics Lab included the ball-balancing work. OSRS brings hardware, perception and MuJoCo simulation into a common software platform.
02 / My contribution
My credited responsibilities cover platform engineering, full-stack robotics and recursive least squares (RLS) identification—a method for estimating system behaviour from incoming data.
The project discloses AI-assisted development under human engineering direction in AI_DISCLOSURE.md.
03 / Purpose & architecture
A controller is difficult to study when hardware commands, sensor observations and test records are disconnected. OSRS gives the team a shared platform for observing and repeating robotics experiments.
A Python/FastAPI runtime connects robot interfaces, OpenCV perception and MuJoCo simulation to a React dashboard. The ball-balancing work joins camera and force estimates with control and online identification. Repository manuals describe the physical connections and calibration separately from software-in-the-loop evaluation.
04 / Engineering decisions
Robot, perception, research and simulation modules sit behind shared runtime services. This lets a new experiment reuse the command interface and telemetry instead of building a separate application.
The ball-balancing work combines visual tracking and load-cell estimates with a control loop. Its research notes describe the progression from simulated cooperative arms to a physical dual-arm platform.
A React interface exposes commands and telemetry while the Python backend handles hardware and simulation. Source manuals document hardware connections, calibration and the experimental architecture.
Experiment evidence / Software-in-the-loop
The repository compares manual gains with auto-tuning across 20 simulated trials per configuration. Auto-tuning settled sooner on average, but increased overshoot and final position error. These are reported test results, not physical-robot performance.
| Metric | Manual gains | Auto-tuning |
|---|---|---|
| Settling time | 3.63 ± 0.79 s | 2.19 ± 0.36 s |
| Overshoot | 9.15 ± 2.13% | 14.82 ± 1.12% |
| Steady-state error | 0.93 ± 0.17 cm | 1.64 ± 0.37 cm |
Settling means remaining within 2 cm of the target for one continuous second. Steady-state error is mean absolute error over the final two seconds. Source: results_summary.json and run_experiments.py. The controller runs against a synthetic ball-and-plate plant; these experiments have not been independently re-run for this portfolio.
05 / Results & current scope
A public robotics codebase, hardware and simulation guides, and a technical report documenting ball balancing and online system identification.
Engineering principleA useful robotics experiment needs more than a controller: it needs connected hardware, visible data and a way to repeat the test.
Repository figures include software-in-the-loop experiments. Simulation traces must not be read as physical hardware performance. The associated report is available as project research documentation; no independent journal publication is claimed here.
06 / Source material
Tell me what you need to build, test or understand. Mention OSRS if it is a useful starting point.
Discuss your project