Both hands
already on the bike
Riders accept orders, follow navigation, answer calls and confirm reroutes while both hands work the vehicle and both eyes watch traffic.
Tapp, a glove that lets gig riders accept a ride without letting go of the handlebar
Multimodal Interactions · NID Bengaluru · 2026
Intro
Gig riders decide on a ride in one or two seconds, with both hands on the bars and both eyes on traffic. Tapp moves that decision off the screen and onto the fingertips.
Tapp is a wearable, app-connected accept/reject interface for two-wheeler gig riders on Swiggy, Zomato, Rapido and Uber. The app does the mental arithmetic and shows a single good-or-bad signal; the rider confirms with a finger gesture made without loosening their grip. With Anjali Vishnu, I took it from rider interviews to a working ESP32 glove paired with an Android app.
- Course
- Multimodal Interactions
- Team
- Akhil Cleatus
- Anjali Vishnu
- Mentors
- Dr. Mamata Rao
- Athul Dinesh
- Skills
- Physical computing
- Interaction design
- App UI
Delivery and bike-taxi riders rely on their phones while riding, creating a conflict between staying connected to work and staying focused on the road.
Outcome
A two-second, multi-variable judgment becomes one green or red light, answered with a pinch. The rider never takes a hand off the bar.
At a Glance
A double pinch accepts the ride. The light has already told you whether it’s worth it.
The problem
The moment the phone asks for attention,
both hands are already busy
Reaching for a handlebar-mounted phone pulls grip and attention away exactly when road risk is highest.
30–40%
of road accidents linked to phone use
Doctors at the COMET 2025 conclave on medical emergency and trauma, as reported by The Times of India, April 2025.
The Times of India
https://timesofindia.indiatimes.com › city › articleshow
Over 30% road accidents due to mobile phone use, say docs
13 Apr 2025 — Experts at the Conclave of Medical Emergency and Trauma (COMET) 2025 said, “Around 30-40% of road accident cases are linked to mobile phone …
NDTV
https://www.ndtv.com › India News
Phone Use While Driving Causes More Deaths Than Red …
4 Sept 2024 — Using mobile phones while driving has caused four times more deaths than red light jumping, according to a new study. with 61,038 fatalities in …
“Not how do we make the phone hands-free but which tasks can survive being done while moving, through which non-visual channel, and at what cost to grip.”
Research
What actually makes a rider accept a ride?
We onboarded riders by asking what matters to them (₹/hour, short pickups, busy destinations, heading home, avoiding traffic), then ran structured interviews: what do you check first, what makes you reject instantly, have you ever accepted and regretted it a second later?
The decisionthrough a rider’s eyes.
Personas built from rider conversations in Bengaluru. Quotes are paraphrased from what they told us.
Ravi, 27Food delivery rider · Koramangala
“If I don’t accept in a few seconds, someone else gets it. So I pick up the phone even while I’m moving.”
Riding through Silk Board traffic Manju, 29Grocery + food rider · HSR Layout
“I accept first and check the pay later. Sometimes it’s a bad order, but if I stop to think, it’s gone.”
Imran, 31Bike-taxi + delivery rider · Whitefield
“When there’s a passenger behind me and I reach for the phone, they get scared. One customer asked me to stop and do it later.”
Priya, 28Bike-taxi passenger · Indiranagar
“The rider kept tapping his phone at every signal, and once while moving. I held on to the seat the whole ride.”
Suresh, 24Quick-commerce rider · E-City
“In this traffic you can’t take a hand off the handle. Buses on one side, autos on the other. The phone mount is useless then.”
Arun, 35Full-time delivery rider · Jayanagar
“Between a signal turning green and a bus cutting in, there’s no moment where looking down is safe.”
Kiran, 33Bike-taxi + food rider · Marathahalli
“When an order pops up with a customer on the back, I either miss it or scare them. Both cost me.”
Rider with a passenger, phone in mount
What we thought happens
“₹300 for 10 km, good or bad?”
One fare-per-distance number judged in isolation, the assumption baked into most accept screens.
What actually happens
“Where will I end up, what will it cost me in time and fuel, will I get another ride there, and is it better than waiting?”
A forward-looking judgment made in one or two seconds, often one-handed, in motion.
The hierarchy of attention, in the order riders read an offer
Where am I going?
Destination comes first; it decides the next 20–40 minutes.
How much am I getting?
Read relative to distance and time, not as an absolute number.
How far is the pickup?
Long pickups are the single most common reason to reject.
How long is the ride?
Duration shapes fatigue and how many more rides fit the shift.
What happens after I get there?
Riders weigh demand at the drop point before they accept.
Instant rejectLong pickup distance or time
Named first and most often, before fare or destination. But reject too many and the algorithm sends fewer rides from that area.
Instant acceptHigh earnings or surge
A big enough number overrides the rest of the evaluation almost entirely.
Design principle
Automate the cognition, not the agency.
The system does the arithmetic: pay rate, pickup distance, payout and zone, checked against the bar the rider set. The rider still makes the call, with a pinch.
Tools like Mystro and Gig U already automate the decision, by removing the driver
They run a rule the driver configured once (accept if ₹/hr ≥ 100 and trip < 40 min) and only hand over the ambiguous middle. Tapp keeps the same contextual computation, but every offer still reaches the rider as one signal, confirmed with a physical gesture instead of a screen tap.
Mystro, Gig U
Rules remove the driver
Rules set once at onboarding: ₹/hr, ₹/km, trip time, areas, rating.
Runs a fixed decision tree and only hands over the ambiguous middle.
The driver is taken out of the decision.
Our approach
Tapp keeps the rider in charge
Same filtering, but every offer can still reach the rider.
The decision is compressed into one signal: green or red.
The rider confirms with a gesture, not a screen tap.
Unwanted offers lapse quietly, so frequent rejects don’t cost future offers.
Gestures
Riders never fully let go of the grip, so the gesture can’t ask them to
Car steering wheels and bike switch clusters already put controls under the thumbs. On a two-wheeler, though, the left thumb also works the horn and indicators while the fingers hold the clutch, and the right hand owns the throttle. We started on a bicycle rig in class, then photographed nineteen poses on a real grip.
Where interactions already live
The handlebar is already full, and the grip is never let go
Two-wheeler riders, most ride-hailing drivers in dense Indian cities, rely on split left and right switch clusters. Any new control has to fit around them.
Headlight high/low beam(press)
Indicator switch(left / right)
Horn(press)
Kill switch(on/off)
Start button(press)
Ride mode(press)
Left grip(clutch hand)
Right grip(throttle hand)
Left cluster
Horn, indicators, headlight beam
Worked by the left thumb while the same hand pulls the clutch. It only tolerates light, deliberate presses.
Right cluster
Start/kill switch, ride mode, thumb brake
Shares space with the throttle hand: the busiest, most safety-critical spot on the vehicle.
Design takeaway
Riders have far less spare movement than car drivers. Tapp’s main gesture lives on the index finger and thumb of the left hand, and never asks for a full release of the grip.
Multimodal interaction matrix
Mapping every channel, phase by phase, before choosing a gesture
Nineteen poses on a real grip. Three survived.
01 Pinch to accept
An offer lands: one buzz, and a green light if it clears the bar. Pinch the touch pad to take it; the light turns blue.
03 Squeeze to re-centre
Map drifted? Squeeze the grip for half a second. Two short buzzes, and the map snaps back.
04 Straighten to answer
A call comes in. Bend, then straighten the index finger and hold for 2 s. A tick at 1 s, a buzz when it connects.
Hard to trigger by accident,
easy to trigger on purpose
Riders wear the glove for hours while gripping, braking and shifting. Every gesture had to survive that without firing by mistake.
Hold, don’t tap
Each gesture must be held: 60 ms on the touch pad, half a second of squeeze, two seconds of a straight finger. A bump on the road is too short to count.
Two steps to answer a call
The finger must first be bent on the grip, then straightened and held. Simply letting go of the handle doesn’t answer anything.
Tuned through testing
A resistor calmed the over-sensitive flex sensor, the force sensor now needs a firmer press, and the touch pad no longer fires before contact.
A buzz for every action
The glove vibrates when a gesture is accepted, then ignores input for a moment so one gesture can’t fire twice.
Resilience
Built for the real shift, not a clean demo
Traffic, dust, heat and irregular breaks were treated as design inputs. These are the conditions the glove is designed for; field tests will confirm each one.
Rain, wet gloves
Logic reads relative bend, not an absolute value, so moisture drift matters less.
Dust and grit
Accept zone relies on sensors inside the glove, not an exposed surface.
Engine vibration
Every gesture must be held, so high-frequency buzz never counts.
Sweat, long shifts
Gestures are read from bend, pressure and timing, not skin contact.
Glove off
The app falls back to on-screen Accept and Decline buttons.
Stop-and-go traffic
Short holds fit the moments at a signal when the hands are freest.
Prototype
Three sensors, a coin motor and an ESP32 on one riding glove
A touch sensor registers taps to accept rides, a flex sensor on the index finger detects bends to answer calls, and a force sensor in the palm detects grip pressure to re-centre the map. An RGB LED and a coin vibration motor provide visual and haptic feedback for each action. Powered by an ESP32, the prototype evolved through repeated trials, testing, and iterations.
- Flex Sensor
- Force Sensor (FSR)
- Touch Sensor
- Coin Motor
- RGB LED
- ESP32
Each round of the glovefixed what the last one got wrong
From a breadboard on the bench to a glove that survives a ride
Breadboard
ESP32, sensors and LED proven on the bench before anything touched a glove.
Sensor placement
Marking where each finger bends and presses on a real grip.
App and firmware
The Android app built in Android Studio, wired to gesture events over Bluetooth.
Calibration
Tuning thresholds until gestures fired only when the rider meant them.
Touch Sensor( Index finger tip)
Force Sensor( Palm force sensing)
Flex sensor( Inside index finger along length )
RGB LED( Status Indicator )
Main Module(ESP32 + Battery + Haptic Driver )
The circuit
Pin-for-pin from the final firmware. Both bend and pressure sensors are voltage dividers into the ESP32’s ADC; the motor is switched through a MOSFET with a flyback diode.
The app
Set your bar once. The glove and app do the filtering.
During onboarding, riders set a minimum pay rate, pickup distance, payout and zones. With Matching on, offers that miss the bar are skipped quietly. With it off, every offer shows up and the glove lights green for a match or red for one that doesn’t. Each offer runs on a six-second countdown, so doing nothing is a decision too.
Every offer checked
against your bar.
Riders set a minimum pay rate, pickup distance, payout and zones once. With Matching on, offers that miss the bar are skipped quietly and the glove lights red.
Set your barPay rate, pickup, payout, zones
Below your barGlove lights red, six-second countdown
A match lights green.
Pinch twice to take it.
When an offer clears the bar the glove glows green. A double pinch on the grip accepts it, and doing nothing lets it lapse, so no tap on the phone is needed.
A matchGreen light, double-pinch to accept
Trip acceptedBlue light, start the route
Eyes stay on the road.
The glove does the rest.
Mid-ride, a squeeze on the grip re-centres the map, and straightening a finger answers a customer call, all without letting go of the handlebar.
NavigatingSqueeze the grip to re-centre
Incoming callStraighten a finger to answer
Testing
How we’ll prove it works on a real shift
We borrowed the shape of a published smart-glove study for riders: repeatability in the lab, false triggers against everyday motions, then a short field pilot with a usability score. In-class bicycle trials and rider feedback shaped the gestures; the formal numbers below are still to be collected.
Testing in progress
Testing glove gestures and validating responses through the mobile app.
What the glove listens for
Each gesture is a timed pattern, not a single reading, so resting noise and quick knocks never fire.
Why the flex sensor has two thresholds
A finger resting straight would answer every call. So the glove must first see a bend (above 400), then a straightened finger held for 2 seconds. After it fires, it disarms until the next bend.
Three sessions
Session 1
Lab repeatability
One rider on a parked bike, engine off and then idling. Each gesture 20 times with gloves on.
Measures: Detection rate · time to event (serial log)
Session 2
Everyday motions
The glove stays armed through braking, gear shifts, visor wipes, horn and indicators, and rough road, 20 times each.
Measures: Unwanted events per motion
Session 3
Field pilot
Five gig riders, a short loop, accepting offers by phone tap and by glove.
Measures: Time to accept · glances at phone · SUS
What testing taught us
Initial testing revealed multiple sensor issues when connected to the ESP32, mainly due to wiring and voltage compatibility. Each sensor required individual calibration and circuit adjustments to ensure reliable readings. The fixes below are now integrated into the final firmware and circuit.
Flex sensor · answer call
Too sensitive
Small, everyday finger movements on the grip were enough to read as a gesture.
Before After (firmware) Trigger Any bend Bend > 400, then < 300 Hold None 2 s straight Re-fire Immediate Re-bend + 3 s cooldown Fix
Reduced sensitivity with a 10 kΩ resistor in the divider, then added two thresholds: bend above 400 to arm, straighten below 300 and hold 2 s to fire.
Force sensor · re-centre
Accidental triggers
Resting pressure from a normal grip kept crossing the threshold and re-centred the map when no one asked.
Before After (firmware) Trigger Any reading ≥ 50 Reading ≥ 50 Hold None 0.5 s squeeze Re-fire Immediate 2 s cooldown Fix
Retuned the sensor and made the squeeze count only if held for 0.5 s, with a 2 s cooldown, so only a deliberate squeeze re-centres.
Touch pad · accept order
Fired before touching
The pad triggered as the finger came close, before actually touching it.
Before After (firmware) Trigger Finger near pad Actual contact Hold None 60 ms steady Re-fire Immediate Release + 0.5 s Fix
Corrected the sensitivity and required 60 ms of steady contact, with release needed before it can fire again.
What we expect to measure
Projections based on the firmware thresholds and our parked-bike trials. These are targets for the formal sessions, not measured results.
Formal measurements (detection rate, false triggers, time to accept, SUS) follow the protocol above and come next. Method adapted from M. Borghetti, N. F. Lopomo and M. Serpelloni, “Novel Smart Glove for Ride Monitoring in Light Mobility,” Instruments 9(1):6, 2025.
Reflection
The best interactions are simple, natural, and fit the rider’s context
Designing beyond the screen meant treating rain, dust, engine vibration, sweat and stop-and-go traffic as design inputs, not edge cases. Next, I’d measure the false-positive rate against a library of everyday riding motions, then pilot the glove with a small group of riders on real shifts.
- Designing beyond screens
- Gesture, haptics and light together
- Iterating with rider feedback
- Sensors and microcontrollers
- Safety vs. usability