Project Closing Report-10July2015

1
ONBOARD: BUS IDENTIFICATION SYSTEM FOR VISUALLY
IMPAIRED
COMPLETION REPORT
SUBMITTED TO TIDE, DST
JULY 2015
ASSISTECH
ANSK SCHOOL OF INFORMATION TECHNOLOGY
INDIAN INSTITUTE OF TECHNOLOGY DELHI

3
ACKNOWLEDGEMENTS
A project of this magnitude cannot be carried out without help and support from a large number of
people from various organizations.
Specifically, we are grateful to DIMTS for facilitating Delhi trials on Cluster buses under their charge.
Support extended by DIMTS staff specifically Ms. Manica Agrawal, Mr. Sanjiv Sahai, Mr. Abhijit Sarkar and
Mr. C.K. Goel was very significant. We are very grateful to NAB Delhi, Saksham and CBW Delhi who
contacted and recruited the users. Clearly these numerous users whose inputs were very useful in making
OnBoard robust and user friendly are part of the silent team responsible for OnBoard development.
Mumbai trials were much larger in size and scope and thus required considerable logistic support.
MumbaiFirst and its CEO Mr. Shishir Joshi played a key role in contacting BEST and pursuing them to
facilitate conduct of trials on BEST buses. BEST, itself played a key role by not only providing buses but
also being helpful in installation as well as maintenance of these devices during trials. Numerous staff
members at the BackBay depot helped the team. At the management level, we initiated dialogue when
Mr. OP Gupta ex-GM was in position and fully supported the idea. Subsequently the project was carried
out with Dr. J.Patil as GM of BEST along with his team of Mr. S.N.Victor (Officer on special duty), and Mr.
A.R.Merchant, Asst. Traffic Supdt (Airport operation). All of them fully supported the project but the
enthusiasm of Dr. J.Patil, GM BEST was really a great morale booster for the team. We are really grateful
to BEST team for the effort put up by them in organizing the closing ceremony.
Our special thanks to XRCVC, Mumbai without whom there would have been no trials in Mumbai. Formally
speaking as part of the pre-trial partnership agreement, they recruited the users, helped in training them
and obtained much of the feedback. But apart from that the contribution of Dr. Sam Taraporewala and
his team has been much beyond these formal roles. They provided the anchor required for any such
activity happening outside of the base. We relied completely on them for help in solving all problems that
we could not handle ourselves. On the other hand, while being fully supportive and being integral part of
our efforts, they also provided critical “external” feedback so essential for carrying out quality work.
Though almost everyone at XRCVC were involved at some stage or other, specifically we would like
acknowledge the solid contributions made by Prof. Sam Taraporewala, Mr. Krishna Warrior, and Ms. Neha
Trivedi, all of XRCVC.
Our special thanks to IIT Bombay for accommodating our team while in Mumbai. Dean of Students office
at IIT Bombay was most cooperative for helping a sister Institution when shortage of accommodation is
clearly a major issue in all campuses. Further Prof. Dinesh Sharma (EE) and Dr. Parag Chaudhury (CSE)
offered laboratory space for debugging and off-site testing.
Finally, we are thankful to DST and more specifically the TIDE Committee for providing us an opportunity
to carry this project forward. We are sure that with their continued support we would be in a position to
create a major impact on inclusion of visually impaired in the society.

4
IIT DELHI TEAM MEMBERS
S.NO. NAME DESIGNATION PERIOD OF
ASSOCIATION
ROLE
1 M. BALAKRISHNAN PROFESSOR, CSE THROUGHOUT THE
PROJECT PERIOD
PI AN OVERALL MENTORSHIP AND PLANNING
2 P.V.M. RAO PROFESSOR, ME THROUGHOUT THE
PROJECT PERIOD
CO-PI AND MENTORSHIP FOR MECHANICAL
DESIGN, INSTALLATION ETC.
3 DHEERAJ MEHRA PROJECT
SCIENTIST
10.11.2013 TO
30.08.2014
COORDINATION
4 DEEPAK GUPTA PROJECT
ASSISTANT
25.9.2013 TO
30.06.2015
SYSTEM DESIGN, SUB-SYSTEM ELECTRONIC
DESIGN, TESTING AND TRIAL COORDINATION
5 T. VISHWARATH PROJECT
ASSOCIATE
18.07.2014 TILL
NOW
MECHANICAL DESIGN, INSTALLATION AND TRIALS
6 NEIL SHAH SR. PROJECT
ASSISTANT
23.07.2014 TILL
30.06.2015
ELECTRONIC DESIGN, TESTING AND TRIALS
7 RADHIKA
DHARWADKAR
PROJECT
ASSOCIATE
06.09.2013 TILL
NOW
DESIGN UP-GRADATION, TESTING AND REPORT
WRITING
8 JENNY CHARAN CONTRACTUAL 01.04.2015 TO
30.06.2015
FLEXIBLE ANTENNA DESIGN
9 RADHIKA
PRABHAKAR
CONTRACTUAL 14.10.2013 TO
13.04.2014
ELECTRONIC DESIGN AND TESTING

5
Trial Report on the Bus Identification System for Visually Impaired
(OnBoard)
Executive Summary
In developing countries an overwhelming percentage of visually impaired people can only afford
to use public transport as their common mode of transportation. Identifying and boarding these
transport vehicles without seeking aid from others is a big challenge that they face on a daily
basis. This is mainly because route numbers are displayed on the number plate (/LEDs) can only
b read by the sighted and the buses stop in a range of 20 to 25 meters making it very difficult to
locate the entrance to the bus by the visually impaired.
To ease the use of public transport for visually impaired people, OnBoard, an entirely user-
controlled radio-frequency based system, has been designed by IIT Delhi. The main objective of
this globally unique solution is to provide an affordable and easy to use navigation system that
will aid visually impaired people to identify and board public buses independently. Route
numbers are collected by the device on radio frequency whereas an audio cue is provided for the
user to identify the location of the door.
The system comprises of two main modules: User Module and Bus Module. A typical transaction
consists of two phases
i. Query phase: When user presses the Query Button on the User Module, it transmits query
over RF. Each bus module in the vicinity which receives this query responds by transmitting
its route number. All the received numbers are sequentially spoken out by the user module.
ii. Bus selection and boarding phase: On hearing the desired route number user can select it
by pressing the Select Button. This selection triggers a voice output from the speaker of the
desired bus. This output speaking out the bus number acts as an auditory cue to guide the
user towards the entrance of the bus. If the desired route number bus(es) have not arrived,
the user need not press the select button and wait.
There is one more module named Route number feeding module, which is used at the bus depot
for programming the set of routes this bus can ply on. This device also provides remote diagnostic
capability with a view to help maintain the module.
OnBoard system started as an undergraduate project many years ago but later went through
different stages of prototyping and testing. Initial trials, both inside and outside the campus were
conducted with the IIT Delhi bus. This being a globally novel solution, an Indian patent application
is pending with the IPR office. For larger scale pilot trials, finally the group received some funding
from DST under their TIDE scheme.
Under TIDE-DST project two major trials were conducted.
i. Limited Delhi Trials
Delhi trials were possible due to the support from DIMTS Delhi. The device was installed in orange
colour cluster buses operated through DIMTS. Delhi trials were a supervised boarding trial

6
conducted in two stages. In the first stage, 5 users made a total of 20 successful supervised
boarding. In the second stage, systems were installed on 6 DIMTS buses and one NAB bus. Ten
users participated in this stage and did a total of 100 supervised boarding. Various usage
scenarios were tested during the trials.
Based on the feedback received from the users following refinements were carried out before
going for the larger pilot scale trials.
a) User Module: Sound quality was improved. Buzzer was included in the module to indicate
the battery status. Beep was provided as feedback on button press. The device periodically
speaks out “charging” while the device is being charged.
b) Bus Module: Bus module was redesigned to have two parts: The speaker-antenna module
and the battery-amplifier module. Also a relay was added for power optimization. Other
modifications were done to ease the installation of the module on the bus.
ii. Pilot Scale Mumbai Trials
Mumbai trials were a large scale field trials and was conducted in two stages; supervised boarding
and unsupervised boarding. For supervised trials a total of 95 supervised boarding and 56 semi-
supervised boarding were first performed. Having obtained confidence from this exercise, a total
of 348 unsupervised boarding by 21 users were conducted. Apart from user feedback, the
maintenance and handling of Bus module during the trial period was also studied.
Based on the feedback received from the users as well as the bus drivers and conductors,
following post-trial refinements have been carried out.
a) User Module: Antenna is re-designed to fit inside the module. CC1110 RF chip has replaced
CC1010 chip to reduce the size of the module. User interface while listening to the numbers
has been made more efficient so that buses do not get missed in the process of identification
itself. Other minor modifications have also been carried out to improve the module in various
ways.
b) Bus Module: Route number feeding module has been designed to configure bus routes on
the bus modules easily at the depot. Instead of a fixed route number, now the driver has an
extra switch which allows the driver to choose from the list of pre-programmed numbers.
Trials were immensely successful with nearly 90% of the users being able to board the first
available bus on their chosen route independently. Trials clearly established the effectiveness of
the system in giving visually impaired persons access to public buses. The system in its current
version is ready for deployment. Outside of the initial objectives, users have also suggested other
enhancements like help in identifying bus stops as well as de-boarding from the busses. Within
ASSISTECH we have already initiated research in these areas.
Going forward we plan to work on three fronts:
i. Raise funding to support a scaled up 1000 bus deployment on BEST.
ii. Identify an industrial partner and carry out the technology transfer for mass production
Pursue with the authorities for regulation/guidelines that promotes installation
of these devices on all public buses.

7
CONTENTS
1 INTRODUCTION.............................................................................................................................................9
2 APPROACH ....................................................................................................................................................9
2.1 USER MODULE.................................................................................................................................................9
2.2 BUS MODULE ................................................................................................................................................10
2.3 SYSTEM OPERATION........................................................................................................................................11
2.3.1 Query Stage...........................................................................................................................................11
2.3.2 Selection Stage......................................................................................................................................12
2.4 SYSTEM SOFTWARE FLOW................................................................................................................................12
2.4.1 User Module software flow ..................................................................................................................12
2.4.2 Bus Module software flow....................................................................................................................14
3 TRIALS .........................................................................................................................................................14
3.1 DELHI TRIALS .................................................................................................................................................15
3.1.1 Trial Overview .......................................................................................................................................15
3.1.2 Trial learning .........................................................................................................................................17
3.1.3 Post-Trial refinement ............................................................................................................................18
3.2 MUMBAI TRIALS.............................................................................................................................................19
3.2.1 Trial Overview .......................................................................................................................................20
3.2.2 Trial learning .........................................................................................................................................23
3.2.3 User Feedback .......................................................................................................................................26
3.2.4 Post-Trial refinement ............................................................................................................................28
4 FUTURE ENHANCEMENTS............................................................................................................................29
4.1 USER RESPONSE .............................................................................................................................................29
4.2 FUTURE DESIRED ENHANCEMENTS.....................................................................................................................30
5 CONCLUSION AND FUTURE WORK ..............................................................................................................31

8
LIST OF FIGURES
FIGURE 1: USER MODULE ............................................................................................................................................9
FIGURE 2: BUS MODULE ............................................................................................................................................10
FIGURE 3: DESCRIPTION OF QUERY STAGE......................................................................................................................11
FIGURE 4: DESCRIPTION OF SELECTION STAGE .................................................................................................................12
FIGURE 5: USER MODULE SOFTWARE FLOW...................................................................................................................12
FIGURE 6: USER MODULE SOFTWARE FLOW (CONTINUED...)............................................................................................13
FIGURE 7: BUS MODULE SOFTWARE FLOW ....................................................................................................................14
FIGURE 8: SHOWING FROM LEFT A) DISTANCE WHEN QUERY WAS SUCCESSFUL AND B) DISTANCE WHEN BUS STOPS........................17
FIGURE 9: SHOWING FROM LEFT A) NO. OF QUERIES DONE AND B) NO. OF SELECTIONS DONE...................................................17
FIGURE 10: SHOWING FROM LEFT A) DISTANCE OF BUS FROM USER WHEN QUERIED B) DISTANCE BETWEEN USER & BUS................23
FIGURE 11: SHOWING FROM LEFT A) SUCCESSFUL NUMBER OF QUERIES AND B) NO. OF SELECTIONS .........................................24
Figure 12: A) DISTINGUISH BETWEEN MULTIPLE BUSES AND B) SUCCESSFUL NAVIGATION TO THE DOOR .....................................24
FIGURE 13: A) DATA ON COLLISION/INJURIES EXPERIENCED AND B) DATA ON SUCCESSFUL BOARDING ........................................25
FIGURE 14: DATA ON USEFULNESS OF ONBOARD SYSTEM .................................................................................................26
FIGURE 15: USER EXPERIENCE.....................................................................................................................................27
FIGURE 16: MAJOR ENHANCEMENTS AND ACCEPTANCE FEEDBACK .....................................................................................30
LIST OF TABLES
TABLE 1: TRAINING ACTIVITY DESCRIPTION.....................................................................................................................15
TABLE 2: USER ENROLMENT DATA................................................................................................................................15
TABLE 3: AGE AND GENDER DISTRIBUTION OF USERS.........................................................................................................22
TABLE 4: FREQUENCY OF THE BUSES ON ROUTE 121 AND 134 ............................................................................................25
TABLE 5: RESULTS OF THE SECOND STAGE TRIALS. ............................................................................................................26
TABLE 6: EXPECTED PRICE OF THE DEVICE .......................................................................................................................30

9
1 Introduction
In developing countries an overwhelming percentage of visually impaired people can only afford to use
public transport as their common mode of commute. On the other hand, identifying and boarding these
transport vehicles without seeking aid from others is a big challenge they face on a daily basis.
Identification is difficult mainly because route numbers are displayed on the number plate / LED displays
and there is no passenger number announcement at bus stops. Moreover, number of vehicles (buses)
arrive together and line up arbitrarily at the stop. Many times it is embarrassing for a user to ask co-
travelers the required information every time a vehicle approaches the stop. And sometimes even after
bus is identified, it is difficult to navigate towards the bus and board it, as the physical location of the bus
entrance is unknown.
OnBoard is an answer to the challenge visually impaired people face while boarding public vehicles. The
main objective of this project is to provide an affordable and easy to use navigation system that will aid
visually impaired people to board public transport independently without any assistance.
2 Approach
OnBoard is an entirely user-controlled radio-frequency based system, with which the visually impaired
people can board the buses independently.
The system comprises of three main units:
i. User Module
ii. Bus Module
iii. Diagnostic and route number programming module
2.1 User Module
This is hand held device which works on rechargeable battery and is light and compact. This device along
with bus module which is mounted on Bus is used by the user to board the preferred bus independently.
User Module has power switch, query button, select button and switch for selecting auto
query/normal mode. This module operates in two modes.
 Auto Query mode:
In this mode the device keeps sending query at a given interval till it receives the bus number the
user is interested in.
FIGURE 1: USER MODULE

10
 Normal Query mode:
Query is sent out only when the user wishes to know the bus number by pressing the query
button.
With help of the User module user can send query to all the buses in the vicinity, either by operating in
auto query mode or by pressing the query button. Device will read out numbers of all the buses that
respond to the query. User after listening to the number can either press select button to select the bus
number or can ignore to listen to the next bus number.
Apart from this, user can also preload bus numbers of interest. Use case for this would be when a user is
taking same bus route daily to work/school. He/ She can preconfigure all the bus numbers in that route
and store it on the device. On query when the user module receives bus numbers it will check the numbers
against the preloaded numbers. It will read out only those numbers which match the preloaded numbers.
2.2 Bus Module
Part of the Bus Module that consists of a speaker would be installed on the bus window near the door.
This speaks out the selected route number which acts as the audio cue for user to locate the door of the
bus and thus helps him/her in boarding the bus.
Bus Module has a speaker with the RF unit and currently has a battery unit to power the module but
eventually will be powered by the battery of the bus in the final installation.
Bus Module once switched on, continuously waits for query packets from the user. When it receives query
packet it will send the bus number. As there can be multiple buses on a given stand, there is possibility
that buses can send its number simultaneously leading to collision. In order to avoid this, Query response
time is divided into 5 slots (assuming at most 5 buses to be present simultaneously). Each bus before
sending its number generates a random slot and waits for its slot in the Query response time.
After sending its number it waits for ACK (acknowledge) packet from the user. ACK packet has all the bus
numbers the user has received in response to its query. Bus module on receiving ACK packet checks its
number. If it is available it will wait for select packet for a given period. If it doesn’t find its number, it will
send the number again.
FIGURE 2: BUS MODULE

11
When bus module receives select packet and if the received packet is for its own number then it reads
out the number on the speaker else it will ignore the packet. And then continues to listen and wait for the
query packet.
Diagnostic and route number programming module
This module operates in two modes,
i. Diagnostics Mode
In this mode administrator at the depot can trigger various diagnostic tests on the required bus
module and collect the results for further analysis. This mode is needed for checking and
maintaining the health of the bus modules. Communication in this mode happens over RF.
ii. Programming Mode
In this mode administrator can configure bus module for all possible routes that the given bus can
take. Bus driver now can choose the route he will be taking from the configured bus route.
Configuring the bus routes happens over RF and selection of the bus route can be done using the
switches provided on the Bus module.
2.3 System Operation
System operates in two stages:
 Query Stage
 Selection Stage
2.3.1 Query Stage
The user module operates in two modes; auto query mode or normal mode. In auto query mode, when
user switches the device on, query is sent out periodically. On the other hand in normal mode, query is
sent out only when the user presses the query button. All the buses in this stage are listening to RF
channel. The queries sent by the user devices on the RF channel reaches all the buses in the vicinity of 30-
40 meters.
Each bus on receiving the query will respond with their respective bus numbers. On receiving these bus
numbers, user module will read them out sequentially.
FIGURE 3: DESCRIPTION OF QUERY STAGE

12
2.3.2 Selection Stage
Bus module after sending the bus number, listens on RF channel for user selection. User can select the
desired route by pressing select button when the desired bus number is read out by the module. This
selection is sent to all the bus modules in the vicinity. But only the bus with the selected number will read
out the route number on its speaker. This gives auditory cue to user for boarding the preferred bus as the
speaker is located close (next) to the front door of the bus.
2.4 System Software Flow
2.4.1 User Module software flow
Audio o/p:
speak out nums
User preloads
bus nums.
Audio o/p:
play Welcome
msg
Master Mode
No
Yes
Listen on Low
freq channel
Is channel
free?
Device started
Query button
pressed
Auto Query
enabled
-Initialize.
-Wait for user i/p
Save input
num
Yes
Wait for
user i/p
User
exited?
No
Slave Mode
A
B
FIGURE 4: DESCRIPTION OF SELECTION STAGE
FIGURE 5: USER MODULE SOFTWARE FLOW
User Configured
number DB

13
Rxed
Ack?
Send the num
to audio o/p
No
No
Yes
No
Yes
No
Yes
Yes
NoYesSend the bus num
to the bus
User Selected
num?
Send Query
packet
Wait for Bus nums for : 5(num of
slot) * 120ms (slot period)
Rxed Bus
num.?
Wait for user to select
num ( with a timeout )
Is AutoQ
enabled?
Is bus nums
preloaded?
Is Rxed nums
in the list?
Compile the list of all bus nums
Rxed so far & send it in Ack
Master mode
Slave mode
Wait for Ack from master:
5(num of slot) * 120ms
A
A
B
No
FIGURE 6: USER MODULE SOFTWARE FLOW (CONTINUED...)
User Configured
number DB

14
2.4.2 Bus Module software flow
3 Trials
Initial trials at Delhi followed by full-scale pilot trials at Mumbai were carried out to study feasibility and
user requirement. Before the trials, hands-on training was given to each enrolled users. As given below
training program comprised of six simple activities for easy learning and understanding of the system.
Activity
No.
Title Function
1 An overview Familiarize user with the OnBoard device and its
functionality
2 Holding the User Module Learn the correct techniques of holding the user module
Device
started
Audio O/P
Speak out Welcome
msg and configured bus
route
Wait for Ack
Ack Rxed/User
has num?
Send Bus num
Wait for query
Query Rxed?
10 tries?
Wait for user to
select the num
User selected
num?
Speak our bus num and
wait for next query
FIGURE 7: BUS MODULE SOFTWARE FLOW

15
3 User Module buttons Locate and identify the use of different buttons and
switches
4 User Module battery
charging
Learn how to charge the user module
5 Customized modes of
operation
Learn different modes of operation like auto-query and
default mode
6 Real time usage of the
module
Operating the module in a natural controlled
environment
TABLE 1: TRAINING ACTIVITY DESCRIPTION
3.1 Delhi Trials
Delhi trials were conducted in collaboration with DIMTS (Delhi Integrated Multi-Modal Transit System), a
joint venture of Government of National Capital Territory of Delhi and IDFC Foundation. Twelve users from
NAB, Saksham and Center for Blind Women enrolled for the trials.
S.No Organizations
involved
Number of
participants
Male Female Age band(in years)
1 Saksham Trust 2 2 0 19-35
2 National Association
for blind (NAB)
8 7 1 22-45
3 Center for Blind women 2 0 2 19-26
TABLE 2: USER ENROLMENT DATA
For conducting trials DIMTS provided access to buses on the route which is frequently used by the users
who participated in the trials. The system was installed on five public buses on route nos. 507 and 764.
3.1.1 Trial Overview
I. Trials were conducted in two phases,
i. Setup Phase and Supervised Trials
In this phase the bus module were installed appropriately in the buses. Main objective of this
phase was to understand the mobility of the Delhi buses and testing the functioning of both the
modules under real time scenarios.
During this phase system was tested with 5 users who made 20 successful boarding. These trials
were supervised by team members from IIT Delhi.
ii. Permanent installation of Bus module in Buses and Supervised Trials
Main purpose of this phase was to see how the bus modules were maintained and used by the
DMITS staff. This gives us insight to the effectiveness of the system not only from the user
perspective but also to identify the support required at the bus depot when the system gets
deployed for the large scale field trials.

16
i. Bus modules were permanently installed on 6 Cluster buses (coordinated by DIMTS) and 1 NAB
school bus.
ii. Twelve users participated in this stage and the users cumulatively boarded the Cluster buses
(coordinated by DIMTS) 100 times.
iii. Four students participated and used this system to board their school bus at NAB for two
months.
II. Usage Scenarios tested during the trials:
i. Multiple users
OnBoard system supports multiple users simultaneously. Bus module responds to other queries
once it finishes servicing the previous query. This scenario was tested on Field with two users
boarding bus by sending query one after the other and bus responding to both the queries.
ii. Identifying the entry of the bus
The speaker is installed on the window near the entrance of the bus, users are able to navigate
towards the bus door without having to touch and follow the bus body with hand/white cane.
During the trials, users were able to take the audio cue to locate the bus door.
iii. Re-orientation of path to traverse
User module can trigger speaker output from the bus of interest by sending multiple queries and
select continuously, in case the bus moves ahead slowly owing to traffic congestions etc. This will
help user in re-orienting himself to the new location of the bus.
iv. Multiple bus scenario
When multiple buses approach a bus stop simultaneously, it becomes difficult for the user to
board the bus of interest without help. Using OnBoard system, user can keep track of the location
of the bus of interest among multiple buses by triggering voice output from the bus speaker.
v. Bus stopping far from stop
In case when bus driver is not able to stop the bus at the designated place, user has to navigate
for longer distance towards the bus leading to a high probability of missing the bus. OnBoard
speakers output is audible from a distance of 30 meters which assists user in navigating towards
the bus. Further this speaker output is also audible to driver and conductor which will indicate
them that a person with special needs wants to board their bus
vi. User alerted in advance
OnBoard system is completely user triggered and enables the user to query the bus well in
advance of the bus stopping at the bus stop. User can be alerted of buses that is approaching the
stop while it is still 30+ meters from the stop.

17
3.1.2 Trial learning
i. Range of operation.
In our study, 73.3% times the user was able to query the bus successfully at a distance greater
than 5 meters
FIGURE 8: SHOWING FROM LEFT A) DISTANCE WHEN QUERY WAS SUCCESSFUL AND B) DISTANCE WHEN BUS STOPS.
ii. Distance of the bus from the user when it stops
Statistics from the trials show that 67% times bus stops at a distance greater than 3 meters. Thus
it becomes necessary to have a suitable navigation tool for the user.
iii. Number of queries done
To get response from the bus, query has to be initiated in time as the bus approaches the bus
stop. As shown in the graph below, in 66% of the cases the user has to query multiple times when
the desired bus was at a far-off distance. This shows that the user is able to sense a bus entering
the bay area of the bus stop.
FIGURE 9:SHOWING FROM LEFT A) NO. OF QUERIES DONE AND B) NO. OF SELECTIONS DONE
iv. Number of selections after locking the preference of bus
In order to navigate safely to the bus door the user may need to hear audio cues repeatedly from
the bus as he/she might be disoriented or the bus may have moved some distance since it was
0
2
4
6
8
10
Frequency
Range of bus(in meters)
0
2
4
6
8
10
12
Frequency
Distance in meters
0
5
10
15
20
Frequency
No. of queries
0
5
10
15
Frequency
No of times

18
last queried. In few cases the user was able to board the bus without triggering the speaker output
more than once. This shows that the speaker functions as a guidepost and the user can navigate
his way to the bus door by triggering select multiple times. In 37% of cases selections were done
twice, before boarding. An interesting case was of partial visual impairment, where the device
was required in order to identify a route number but not for navigating towards the bus entry.
v. Successful boarding
During the trials, a total of 12 users cumulatively attempted 100 boarding. Of these 94 were
successful and six were not. On each occasion the users were successful in correctly identifying
the desired buses. In spite of identifying the buses correctly, on six occasions the user could not
successfully board. The major reasons identified for the misses are:
 The buses not stopping at the specified location
 Buses entering the stop simultaneously one behind the other
 The driver not stopping at all or stopping for a very short duration.
3.1.3 Post-Trial refinement
FIGURE 12: SUCCESSFUL BOARDING OF INDIVIDUAL USERS
I. USER MODULE
i. User module sound amplification
A sound amplifier (AP4890) has been added to the user module to improve the user
experience while using the device at a noisy bus stop. The sound levels have increased from
around 60db to 75db.
ii. Speaker upgrade
New speakers with more clarity were identified and used in the user module.
iii. Charge level indicator
A Buzzer is used to indicate the battery status / charge level when the device is switched on.
Three beeps indicate that the battery charge level is between 70% and 100%. Two beeps
indicate that battery charge lies between 30% and 70%. Finally, a single beep indicates that
the battery is low and its charge level is less than 30%.
iv. Beep on button press
0
5
10
15
20
Numberofboardings
Users
boardings per user
successful boarding

19
To give a positive confirmation to the user that a button (query / select) has been properly
pressed, a beep feedback is provided while the button is pressed
v. Charging Status Indicator and Affordable cost
Replaced the Battery IC MAX8606 with BQ2057. This was done to reduce the cost (reduced
by INR 50) and add a more reliable charging status indication. The user device periodically
speaks out “charging” while the device is on and it is being charged.
II. BUS MODULE
i. Overall Design
The overall design of the bus module has been improved. The initial bus module was bulky
and difficult to install. The new design has two parts: The speaker/antenna module is installed
on the railings of the bus and the rest of the components (battery, amplifier) are installed
beneath the seat of the bus.
ii. Long wire antenna connectors
We have now switched to the long wire antenna connectors to install the antenna at a suitable
place for better communication.
iii. Power Optimization
A relay has been added to bring down the power usage when the device is in sleep mode. The
amplifier / speaker section were initially consuming power while the device was not in use.
The improvement has brought down the re-charging requirement from 1 day to 7 days of
usage.
3.2 Mumbai Trials
The next phase was large scale trails of OnBoard in Mumbai. Preparation for this trails was based on the
feedback from previous trials in Delhi. During Mumbai trials, initially a total of 95 supervised boarding and
56 semi-supervised were conducted. This was followed by a total of 348 unsupervised boarding by 21
users over a span of 2 months. Even the maintenance and handling of Bus module during the trial period
was studied, which gave insight to the design of the bus module.
Following is the list of the design refinements of the system that were carried out to make it robust and
easy to maintain during Mumbai trials.
I. BUS MODULE
i. For timely indication of system failures, a LED grid has been incorporated to indicate successful
charging in progress, sufficient battery power and a healthy functional system.
ii. A variable potentiometer was provided so that the sound level could be adjusted manually
according to the need based on the environmental noise.
iii. Bus module was modified and made lighter than the earlier version which was 11 KGs (2KGs
speaker module and 9KGs under-the-seat module) to a new version which weighs only around
5.5KGs (Speaker module weighs 2KGs and under-the-seat module weighs only 3.5KGs).
iv. The charging port was integrated along with the other circuitry and was shifted to the exterior of
the box. This eliminated the need of the transformer and the rectifier, which simplified the charging
circuit of the battery.

20
v. Sleep mode was introduced by adding a relay to bus module. In this mode, the module consumes
less power which reduced the re-charging requirement from once every day to once in 7 days.
vi. The connecting wires, for antenna and power line, between the speaker and amplifier unit were
made detachable. So that during system failure, only the amplifier unit could be replaced and not
the entire system.
vii. The antenna was placed inside the speaker box which reduced the chances of being tampered as
seen in the earlier trials when antenna was placed outside. Placing antenna inside the box didn’t
affect the range as the box is made of wood.
viii. Padded aluminium casing was designed for battery and amplifier unit. This casing was placed and
secured through clamping with the under seat railings. This protected the unit from jerks during
the bus motion.
II. USER MODULE
i. Based on the feedback from previous trials, material and colouring of the casing was changed. The
module was more smooth and easy to handle.
ii. Provision for connecting neck sling was added in the module. This was useful as user need not hold
the device all the time.
iii. Provision for connecting a head phone was made.
3.2.1 Trial Overview
The two major routes 121 and 134 were identified for installation of the systems. Total of 25 units were
installed on these routes covering all the buses deployed on a typical day. Trials were conducted in two
stages,
 Supervised Trials
 Unsupervised Trials
I. SUPERVISED TRIALS
In this stage 70 visually impaired users were given training and out of them 56 users took part in
the trials. A total of 95 boardings were conducted of which 85 trials were successful. Of these 10
boarding were completed semi-independently.
Users were called for the trials based on their availability and were guided to a bus-stop of route
121 and/or 134. The bus-stops having poor infrastructure and which were potentially dangerous
owing to construction/re-work were identified and excluded from the trials.
During the trials users were accompanied by sighted buddies to ensure safety as well as record
user’s boarding experience. They only played the role of coordinator and did not interfere with
the user while operating the system. Since this being first stage of trial, device functionality,
conduct of drivers, conductors and co-passenger at the bus stop was observed. In case the user
had done more than one boarding and was confident enough he/she was dropped at a bus-stop
en-route and was intimated when the bus was starting from the bus-depot.
Following is the list of parameters that were considered for study during Supervised stage,

21
RF communication range between the user and bus module was determined to be 30-40
meters under lab conditions. But in real life condition this can reduce considerably due to
metallic components in the environment hindering the performance of the antenna. Thus this
parameter was considered to check the effectiveness of the antenna range on field.
ii. Distance of user from the bus when it stops.
General observation is that most of the times buses do not stop at the designated spot. Due
to this visually impaired people face lot of inconvenience and many times they miss the bus.
This parameter would also help to assess how effective the OnBoard system was in helping
users navigate towards the door of the bus.
iii. Successful number of queries.
User would initiate query multiple times if he/she is unable to select the required bus number
in a given window or the query never reached bus. Thus this parameter would indicate the
comfort level of the user for selecting required bus number and also the effectiveness of the
RF communication between the User and Bus module.
iv. Number of selections after locking the preference of bus.
Once selection is done, OnBoard Bus Module would read out the number on the speaker once.
In order to navigate safely to the bus door, the user may need to hear audio cues repeatedly
from the bus. This would indicate the effectiveness of the OnBoard system in navigating the
user to the bus.
v. Did user distinguish multiple buses?
In real-life scenario multiple buses may stop at a given bus stop. This generally confuses visually
impaired people and may lead to boarding of wrong bus. This parameter will help in accessing
OnBoard system in such situation.
vi. Was user successful in navigating to the door of the bus?
Many times after identifying the bus to be boarded visually impaired people uses white cane
to travel along the bus to get to the door, many times they miss the bus by the time they are
able to locate the door. Bus module has the speaker mounted on the front window which aids
the user to locate the door with help of audio cue. This helps in accessing the effectiveness of
the location of the speaker.
vii. Did User experience any injury/collisions?
This will give information on how safe were semi-independent/independent boarding using
OnBoard system.
viii. Successfully boarded independently?
This will help in accessing usefulness of OnBoard system and how much difference it made to
the visually impaired commuters.
II. UNSUPERVISED TRIALS

22
A total of 21 users were enrolled in the trials. Main focus of the unsupervised trials was to validate
the system functionality across a large section of the population. To get a wide representation of
typical user, enrolment was done with age, gender as well as level of visual impairment as shown
in the table below.
Criterion Variable No. of users
Age Above 30 12
Below 30 9
Gender Male 13
Female 8
Level of visual
impairment
Blind 16
Low vision 5
TABLE 3: AGE AND GENDER DISTRIBUTION OF USERS
In this stage, the users were issued a user-module for the duration of the trial. Each user had to
complete 20 boardings. In order to validate the system’s effectiveness throughout the trials, the
user was required to board the designated bus from a pre-identified bus-stop. In these 20
boardings, he/she had to complete 10 boardings on route #121 bus and 10 boardings on route
#134 bus.
In a day, 9AM to 11AM and 4PM to 8PM was considered as peak hours and rest of the day was
considered as non-peak hours. In the above 20 boardings, user had to also complete 10 boardings
in peak hours and 10 boardings in non-peak hours.
During this stage following data was recorded for each boarding.
i. User information
ii. Boarding stop
iii. Bus number
iv. Time of arrival
v. Time of boarding the bus
vi. Their perceived anxiety level on a scale of 0 to 5 (level of user comfort in using the device)
vii. Door of entry (either front or back; if back the reasons)
viii. Any information of missed buses; buses whose systems were not working or buses without
system
ix. Any device (user module) mal-function
x. Any other comments

23
3.2.2 Trial learning
I. SUPERVISED BOARDING
As mentioned in previous section various parameters were studied and following are the results.
During the trials it was observed that 66.7% (as shown in the graph) of the users sensed arrival
of the bus when the distance was between 5-10 meters. Since this range is supported by the
device, users were able to successfully query the Bus module.
ii. Distance of user from the bus when it stops.
Trial statistics show that 27% of times the bus stopped at a distance greater than 5 meters.
Even with this distance audio cue was sufficient for user to locate the bus.
FIGURE 10: SHOWING FROM LEFT A) DISTANCE OF BUS FROM USER WHEN QUERIED B) DISTANCE BETWEEN USER & BUS
iii. Successful number of queries.
This information is useful to determine whether the user has been able to query the bus
successfully on the bus entering the stop. A higher value indicates that the user wants to
confirm the bus number or is not able to immediately press the select button after querying.
In 56% of the cases the user successfully selected the bus after querying once.
iv. Number of selections after locking the preference of bus.
Many times user may have to hear audio cues repeatedly from the bus as he/she might be
disoriented or the bus may have moved some distance since it was last queried.
Study showed that 36% of the cases selections were done once or twice, before boarding. In
39% of the cases the speaker was activated 3 or 4 times. In both the cases user was able to
board the bus successfully. This showed how bus module provided audio cue to the user in
navigating his/her way to the bus door.
0
5
10
15
20
0-5 5 to 10 10 to 15
Frequency
Distance in meters
0
5
10
15
20
25
30
35
0-5 5 to 10 10 to 15
Frequency
Distance in meters

24
FIGURE 11: SHOWING FROM LEFT A) SUCCESSFUL NUMBER OF QUERIES AND B) NO. OF SELECTIONS
v. Did user distinguish multiple buses?
In the study it was seen that with the help of OnBoard system, user was mostly able to identify
the bus when there were multiple buses on the stop. Only in few cases the user could not
distinguish due to external factors like interference of sighted passenger.
vi. Has user reached the door directly?
Study showed that in 81% of the cases the user was able to reach the door directly. However
in some cases some users reached the door after following the bus body with hand as they
were using the device for the first time.
Figure 12: A) DISTINGUISH BETWEEN MULTIPLE BUSES AND B) SUCCESSFUL NAVIGATION TO THE DOOR
vii. Did user experience any injury/collisions?
In 89% of the trials the user had reached the door safely from his starting point without
colliding with co-travellers. In four cases, however the user collided with other people in the
hurry to board/de-board the bus.
viii. Successfully boarded independently?
The user independently finished the boarding successfully in 80% of the trials. Failures were
due to external factors like some users needed assistance to approach the door after querying
0
5
10
15
20
25
1 2 3 4 5 Failure
Frequency
Number of queries
0
2
4
6
8
10
12
14
16
0 1 or 2 3 or 4 5 or 6
Frequrncy
No. of selections
0 10 20 30 40
Yes
No
Frequency
Observation
0 10 20 30 40
Yes
No
Frequency
Observation

25
since the driver did not wait till the user boarded the bus. And in few cases the user did not
press the select button after successfully querying. In one case the bus did not stop.
FIGURE 13: A) DATA ON COLLISION/INJURIES EXPERIENCED AND B) DATA ON SUCCESSFUL BOARDING
II. UNSUPERVISED BOARDING
A total of 21 users participated in the unsupervised trials and a total of 348 boarding were
completed in total. The same two bus route 121 and 134 were considered for the unsupervised
boarding.
Focus of the study in this stage was to estimate “fractional waiting time” which is the ratio of the
waiting time of a user for given bus and the frequency of that bus. This estimate helps in
determining the OnBoard system’s effectiveness. A value greater than 1 indicates that the user
has waited more time than the average frequency of the bus at that particular bus stop.
Total of 279 cases the users were able to board the first bus that enters the stop, in 54 cases the
waiting time exceeded the frequency of buses and in 15 cases it exceeded twice the time of the
frequency of the buses. Note this time is a pessimistic estimation as there are more than one
reason for the users to miss a bus as explained later.
Following two table shows the frequency of the buses on different routes and the fractional
waiting time.
Bus route Peak/Non-peak Time in
min(weekday)
Time in min
(Weekend/holiday)
121 Peak 15 25
Non-peak 20 30
134 Peak 25 35
Non-peak 30 40
TABLE 4: FREQUENCY OF THE BUSES ON ROUTE 121 AND 134
0 10 20 30 40
no
yes
Frequency
Observation
Collisions/injuries
experienced
0 10 20 30 40
Yes
No
Need assistance
Frequency
Observation
Successfully boarded (Yes / No)

26
No. of boardings First attempt Second attempt More than 2
attempts
Average Fractional
waiting time
348 279 54 15 0.97
TABLE 5: RESULTS OF THE SECOND STAGE TRIALS.
The most prominent reasons of a user not being able to board the desired bus are as given below:
i. Bus battery running low
Bus module was able to respond to the query but did not have enough power to drive the
speakers so as to announce the route number through the speaker when the number was
selected.
ii. Bus module being switched off
In some cases bus module was switched off or was not even present as the buses were
swapped between routes. Since the module did not have the feature of changing the route
number when buses were swapped, the module was switched off in order to avoid confusion.
iii. User did not query the system
In few cases the user was not able to distinguish among multiple buses at heavy traffic bus-
stop and did not query the buses on time.
3.2.3 User Feedback
i. System utility
The above figure shows the response of the user towards the usefulness of the OnBoard
system. In general it was seen that anxiety to board the bus was reduced with the system.
0 5 10 15 20 25
Was bus boarding easier
Does device solve the problem of Bus
identification
Does the device solve the problem of Bus
Localization
Has this device reduced the anxiety level
Has this device made you more confident
Does the device increase safety at the time of
bus boarding
Does this device make you more independant
Does this device reduce your travel time?
No. of users
Parameter
FIGURE 14: DATA ON USEFULNESS OF ONBOARD SYSTEM

27
They were more confident and felt independent as boarding the bus became a lot easier with
the help of the system.
Many users expressed the need of a device which will also help them in de-boarding by
speaking out the bus stop names.
ii. Device related feedback
 Safety: General feedback was that device increases the safety except with two users who
mentioned that due to the chaotic traffic, vehicles came in between them and the bus at the
time of bus boarding.
 Device related issues: The bus battery when low affected the system performance. Hence
users got late response from the bus module. In one case user module fell down and the
antenna was broken. Feedback was to have more robust user module. Some felt it was
difficult to manage both cane and the user module.
 Seeking external help: In one case the user had to seek external help in locating the correct
bus stop for her particular bus number.
But apart from this few cases, users generally reported that they were independent in identifying
and boarding the bus.
0 2 4 6 8 10 12 14 16 18 20 22
Was Conduct of drivers and conductors cooperative
Did the bus stop sufficiently long enough
for you to board after selection?
Was the reaction from fellow
co-travelers positive?
Any device related issues
that made you uncomfortable at the bus
stop?
Did you have to seek external help during
your boardings?
Does the device increase safety at the
time of bus boarding
No. of users
On-field experience
FIGURE 15: USER EXPERIENCE

28
3.2.4 Post-Trial refinement
I. USER MODULE
i. Antenna Design
Earlier antenna of the user module was protruding out making it inconvenient to keep the
device inside the pocket or bag. Also in one case antenna broke when device slipped out of
hand. Thus the antenna is being re-designed so that it can be enclosed inside the module.
ii. Power Switch
Users complained of switch turning on accidently when the user module was placed inside the
bag. And also they complained that the switch was rough and pointed. This switch is now
upgraded to a soft sliding key.
iii. Provision to skip the bus numbers
In some situations, there are many buses on the stop and bus number of interest may be
readout at the end of the list. In this case, user has to listen to all the bus numbers of little
interest before the needed bus number is readout. Many times it may happen that bus may
not stop for that long before the user can listen to the number and select. So having provision
of skipping bus numbers will help user to scan through the numbers quickly.
In selection stage when bus numbers are being readout by the module user can press query
button to go to next number in the list. Now query button is used for querying in query stage
and for going to next number in the selection stage.
iv. More time to select the bus number
During the trials, multiple users complained of having to query more than once since they were
not able to select the number within the defined period as the period is very small. But if we
increase the select period then when there are multiple buses at the stop then it would
increase the overall number readout time. And this would increase the chance of bus leaving
the stop even before the user listens to the number and selects.
With number skipping provision as explained in the above section, user can skip numbers
quickly till he/she hears the number of his/her choice. With this provision we are able to
increase the select period without having other side effects.
v. Programming restricted set
With this feature user will listen to only those bus numbers which have been programmed by
the user. If user is travelling daily by the same route buses, then he/she can configure all the
bus numbers going through that route. With this user module will readout the numbers of the
bus on the stop only if it matches with the preconfigured numbers.

29
vi. Head phone jack
Earlier head phone jack was not useable since the volume was too loud with the amplifier and
was not audible without amplifier. The head-phone jack circuit was modified to give out
acceptable volume.
vi. User Module Miniaturization
We have switched to CC1110 from CC1010 as our RF communication IC. This has helped us
reduce the size of the user module. And even the antenna is designed to fit inside this reduced
module.
II. BUS MODULE
i. Should be able to change bus numbers easily.
There weren’t many comments received on the bus module though one clear requirement
emerged. We had earlier assumed that the buses once deployed on a route in the morning
continue on the same route. This assumption was valid in case of the cluster buses in Delhi as
the owner of the bus had permission to ply only on one route. In case of BEST the same bus
was deployed on more than one route depending on the dynamic requirements and many
times even without coming to the depot. Thus it was clear that the driver should be able to
change the bus number easily when the buses interchanged the route. For this a major change
has been incorporated in the bus module which can now be configured with multiple bus
numbers and the driver can choose the number based on the route.
ii. Ease of configuring bus numbers on the bus modules
To accommodate this new unit named as Diagnostics and Number Feeding Unit is designed.
With help of this unit, Bus Module can be configured with multiple bus numbers, typically all
the routes on which the buses for that depot operate. Also depot technician can initiate
diagnostic tests regularly to check the condition of the Bus Module of each bus at the depot.
4 Future Enhancements
4.1 User Response
The following table shows the response of 21 users with regards to various factors related to
enhancements including the future versions of the device as well as acceptance of the technology.

30
FIGURE 16: MAJOR ENHANCEMENTS AND ACCEPTANCE FEEDBACK
The response given by users with regards to the price of the module is shown in the table given below.
Sl.No Range(in Rupees) No. of users
1 <500 8
2 500-1000 8
3 1000-2000 2
4 >2000 2
TABLE 6: EXPECTED PRICE OF THE DEVICE
Many Bus drivers complained that selection by the user from the other direction bus stop triggered the
speaker of their bus module (which was going in opposite direction) creating confusion. Thus there is a
need of having the direction sense in the selection as up route or down route for the given number is
selected.
4.2 Future Desired Enhancements
Based on the feedback and also for the convenience of the users, following enhancements in the
future versions could be considered.
i. Integrating User Module in mobile or reducing the size of the module
Some users complained of the need to carry an extra device and also about the device being
bulky. Future enhancement would either integrate the functionality of the user module on
smart phone or make device more sleek and light. Miniaturization is possible and also today
smart phones do not have any long range device to device communication medium without
GSM. Thus a sleek, light weight user friendly module is what is envisaged for scaling up.
0 2 4 6 8 10 12 14 16 18 20 22
If this device is launched into the market
would you buy it?
Would you like to have a device that can
give you the information of the route?
Will you be comfortable using a
Smartphone app in place of user
module?
Would you like to have the device
provide you information for your de-boarding?
No. of users
Future work and possible modifications

31
ii. Ability to distinguish between buses in the two different directions
Currently busses plying in opposite direction would respond to the selection by the user on the
other side and this created some confusion to the bus drivers. But interestingly users could
distinguish and did not complain on this. One solution is that the user is asked to request with
an additional number indicating the direction. This has major training issues as normally such
numbers are not used in city buses and would require additional training. Further, the driver
would have to change a switch each time the bus starts back on the reverse journey. The other
alternative is to have directional antenna on the bus. In directional antenna Bus Module, will
respond to the only those requests which are triggered within 180 degree angle facing the bus
stop. Thus it will eliminate or will not receive any requests triggered from the opposite
direction. In scaled up trials this would be attempted.
iii. Assistance in identification of bus stops
Clearly bus stops in the city are of very different nature. Sometime just a signboard on the road
indicates a bus stop without any additional structure. Many visually impaired users have
indicated major difficulties in identifying the location of the bus stops. We have started looking
into technology solutions that are simple and cost effective to address this issue.
iv. OnBoard system with bus stop information
Currently OnBoard system aids user in boarding the bus successfully but once the user is on
the bus it does not provide any details of the approaching bus stops. Thus for de-boarding they
have to rely either on the conductor or on the co-passengers. Thus incorporating GPS which
could give out bus stop names based on the approximate location of the bus and also the list
of bus stops on the route, will make users completely independent. A separate project to
develop such a mobile application has been initiated based on this feedback.
5 Conclusion and future work
OnBoard system enables visually impaired people to independently board public buses. The system has
been validated by first a set of trials on Cluster buses operated by DIMTS in Delhi followed by a large scale
pilot trials on two routes in Mumbai. These trials, started with supervised boardings but was followed up
with nearly 350 unsupervised boardings. A number of limitations/deficiencies pointed out after the first
set of trials were corrected and there was a vast improvement in performance in the pilot trials at
Mumbai. Again a number of changes based on feedback received from Mumbai trials have been
incorporated in the design and the same would be validated when scaled operation happens.
Users who participated in these trials gave very positive feedback about the system as described in the
previous sections. First the trials clearly establish the utility of the system in giving visually impaired access
to public buses. The system in its current version is ready for deployment. In fact Dr. Patil, GM of BEST has
given us a letter of support and indicated willingness of BEST in scaling up the system with a view to
deployment on its entire fleet of 4000+ buses.
Going forward we plan to work on three fronts:

32
i. Raise funding and prepare for a scaled up deployment on BEST. Though BEST has indicated
consent for installing on all of its 4000+ buses, we propose to start by installing on 1000 buses
with may be 1000 users in the first stage before taking up the deployment on the entire fleet.
Production, installation and deployment over a 6 month period would require approximately Rs.
1.0 crore and one of the immediate tasks is to raise these funds. A project plan is under
preparation for the same.
ii. Identify an industrial partner and carry out the technology transfer. This would be followed by
optimizing for manufacturability as well as production of these devices by the industrial partner.
Even in the scaled up deployment and trials, we expect this partner to play a major role.
iii. Prepare a proposal and pursue with the Ministry of Social Justice and Empowerment for a
regulation that mandates or at least promotes installation of these devices on public buses.
Clearly in this sector without such regulatory support, inclusion is not going to happen if one is
dependent only on market forces.
Outside of the initial objectives, users have also suggested other enhancements to address the issue of
comprehensive accessibility of public busses. This includes support for identifying bus stops as well as de-
boarding from the busses. Within ASSISTECH we are already initiating research in these areas.

Project Closing Report-10July2015

Recommended

Recommended

More Related Content

Similar to Project Closing Report-10July2015

Similar to Project Closing Report-10July2015 (20)

Project Closing Report-10July2015