iCHAIR
A wheelchair that listened, looked, and found its own way across the room.
The problem, as stated in 2007
A powered wheelchair existed. It was imported, expensive, and out of reach of nearly everyone in India who needed one.
The thesis opens with a number from the National Sample Survey Organisation: roughly 18.5 million disabled people in India in 2002, of whom about 57.5% had a locomotor disability. A manual wheelchair serves many of them. It does nothing for the ones who cannot push it.
So the brief was not "build a robot." It was: take an ordinary wheelchair frame, a pair of motors, a second-hand laptop and whatever the campus workshop had lying around, and end up with something a person could sit in and talk to. Cheap enough to actually be built. Upgradeable, because a PC was doing the thinking.
Three of us split it along the seams of the machine — mechanical systems, electronics, and the software that had to make the other two behave.
Joystick on the armrest
Four two-pole switches and an indicator LED, wired straight to the motors. When manual mode is on, the interface circuit is physically isolated from the drive. The computer cannot interfere.
You steer, by voice
The chair executes exactly what it hears and nothing more. The rider keeps full authority over the route; the machine contributes only muscle.
You name a room
Given a map of the floor, the chair picks its own route, watches for obstacles that aren't on the map, and re-plans around them mid-journey.
Four things worth remembering
Two decades later, these are the parts that still read as engineering rather than coursework.
A laser rangefinder made from a webcam and a laser pointer
Commercial laser rangefinders were precision instruments priced like precision instruments. The team built one instead. Clamp a laser pointer parallel to a webcam's optical axis, exactly 5.842 cm below it. Fire it at whatever is ahead. Scan the frame for the brightest red pixel. The further that dot sits from the centre of the image, the closer the obstacle.
That is the whole idea, and it collapses to one line of trigonometry: D = h / tan θ, where θ is recovered from the pixel offset by a straight line fitted from six measurements taken on the workshop floor — gain 0.002 rad/pixel, offset −0.04 rad.
The honest part is what the calibration data shows. Between 26 cm and 55 cm, the dot sweeps 38 pixels. Between 152 cm and 195 cm — a gap of 43 centimetres — it moves two. The instrument is sharp up close and nearly blind far away, which is precisely the accuracy profile an indoor wheelchair needs and precisely why it could be built for the price of a laser pointer.
| Pixels | Distance | θ actual |
|---|---|---|
| 100 | 26 cm | 0.18256 |
| 80 | 42 cm | 0.11379 |
| 62 | 55 cm | 0.08705 |
| 51 | 73 cm | 0.06566 |
| 39 | 152 cm | 0.03157 |
| 37 | 195 cm | 0.02461 |
They read the literature, found nothing that fit, and modified the algorithm
Classic A* assumes you know the map. A wheelchair in a real house does not: the map has the walls, but not the schoolbag someone dropped in the corridor twenty minutes ago.
The fix in the thesis is deliberately unglamorous and completely correct. Plan the shortest path over the known map. Drive it. When the rangefinder reports an obstacle in the vicinity of the current node, throw the remaining plan away and re-run A* with the current node as the new start and the original destination as the goal. Repeat until you arrive. They named it Multistep A*.
That is, in substance, the receding-horizon replanning that every modern robot navigation stack does — arrived at from first principles by three undergraduates who had concluded, correctly, that none of the published algorithms fit their problem as written.
The simulator generated random unknown obstacles the chair could not see in advance. On the run captured below: a 20-step solution found after expanding 227 nodes.
Five relays, one printer port, and a speech engine that kept mishearing "right"
There was no microcontroller in this design and no motor driver board. A laptop's parallel port raised five volts on a pin; a BC547 amplified it into the base of a 2N3055; the 2N3055 closed a relay; the relay switched a 100 W motor. A 1N4001 across each coil absorbed the inductive spike, and a pair of 1N4148s stood between the whole arrangement and the laptop, because a shorted transistor would otherwise have pushed 12 V into a port that expected 5.
Five switches — main power, two pole-changers, drive, rudder — encoded every motion the chair could make into single bytes written to 0x378, with the sensors read back from 0x379.
And then there is the most human artifact in the entire codebase. Microsoft's 2000-era dictation engine, listening to three Indian undergraduates in a workshop, kept hearing "rate", "write" and "great" when they said right. Rather than fight it, they mapped all four words to the same command.
| Motion | Out to 0x378 |
|---|---|
| All switches off | 0x20 |
| Drive forward | 0x29 |
| Drive reverse | 0x2F |
| Rudder forward | 0x31 |
| Rudder reverse | 0x37 |
// from the voice interface, 2007 if (_wcsicmp(dstrText, L"right") == 0) { (*x)=2; break; } if (_wcsicmp(dstrText, L"rate") == 0) { (*x)=2; break; } if (_wcsicmp(dstrText, L"write") == 0) { (*x)=2; break; } if (_wcsicmp(dstrText, L"great") == 0) { (*x)=2; break; }
The belt is a fuse
The main wheel is driven by chain and sprocket, straight off a bicycle. The steering castor is driven by a flexible belt, and the thesis is explicit about why it is not a chain: a belt tolerates axial misalignment, weighs less, and — the good bit — if the castor jams, the belt slips.
A mechanical fuse. The failure mode was designed in on purpose, so that a stuck wheel destroys nothing but a few seconds.
The numbers are just as deliberate. Two 100 W, 24 V geared PMDC motors turning at 30 rpm, a 0.4 m wheel and a 1:1 sprocket ratio put the chair at 12 metres per minute — roughly a seventh of walking pace. Nobody was going to be hurt by this machine.
It was actually built
Not a simulation, not a proposal. A steel frame in the NIT Calicut central workshop, with a laptop bungeed to the seat and a webcam zip-tied to the armrest.
The onboard computer. Webcam clamped to the armrest, laser pointer beside it, batteries in the box below. The whole autonomy stack ran on that laptop.
The switching module, mid-assembly. Five relays under the seat, hand-wired, standing between a printer port and two 100 W motors.
The steering castor and its motor. Two microswitches set at 90° told the software when the castor had reached straight-ahead or full lock.
Chain, sprocket, wheel. Bicycle parts doing robotics work.
What 2007 actually meant
Every piece of infrastructure that would make this project a weekend build today did not exist yet.
The thesis was submitted in April 2007. The first iPhone was still two months from shelves. ROS would not have a public release for three more years, and the Kinect — the sensor that made cheap depth perception ordinary — was three and a half years away. OpenCV still had "Intel" in front of its name. There was no Raspberry Pi, no Arduino ecosystem worth the name in an Indian campus workshop, no Stack Overflow to ask.
So the depth sensor had to be invented from a laser pointer and a webcam. The motor driver had to be transistors and relays on stripboard. The path planner had to be modified by hand because the published one did not fit. And the interface between the computer and the physical world was a printer port, addressed in hexadecimal.
The list below is not nostalgia. It is the measure of how much of this was substitution for infrastructure that had not been built yet.
2007 — what they had
- DepthWebcam + laser pointer, calibrated by hand on the workshop floor
- ComputeA laptop, bungeed to the seat, talking to LPT1
- DriverBC547 → 2N3055 → relay, per motor direction
- OdometryA rubber wheel counting chain links
- SpeechMicrosoft SAPI dictation, plus four spellings of "right"
- VisionIntel OpenCV, scanning for the brightest red pixel
2026 — what it would be
- DepthA solid-state LiDAR or a depth camera, out of the box
- ComputeA single board smaller than the battery terminal
- DriverAn off-the-shelf H-bridge, PWM speed control included
- OdometryWheel encoders fused with an IMU
- SpeechOn-device recognition that handles any accent
- VisionA segmentation model that names the obstacle it sees
That is the part that carried. The whole project is one integration problem wearing three costumes: a mechanical layer that actuates, an electronic layer that switches and senses, and a logical layer that decides — each with its own failure modes, meeting at interfaces nobody else had specified. Sequence the build, instrument what you cannot see, design the failure mode before it finds you, and know exactly which layer a bug lives in.
That is still the job. The parallel port just became an API.