On-body Indoor Navigational Assistance
for the Visually-impaired
After
our initial idea for navigating a helicopter was rejected, given the example of
previous teams, we decided to develop a system that would navigate people with
impaired vision around a building. We decided to make a belt that has four
motors that vibrate according to which direction the person should go. We are
using a network of Prospeckz to achieve the indoor navigation. Our initial
scenario was for a hotel and having the belts help people with impaired vision
around the hotel. While we were testing our belt with actual person, she
suggested that this device will be very good for home use. She liked the idea
and mentioned that it will be good if we have a sound that will warn her if she
is approaching a door or a wall. On the picture she is using the belt, but her dog
does not want to leave her alone.

Here is a block diagram that gives a broad view of how our system is structured. We have the belt that consists of four motors, a compass and one prospeckz. It sends its location information to the Controller every second and receives instructions from the Controller for which direction it needs to go. When an instruction is received it uses the compass to find the right direction and then vibrates the corresponding motor on the belt. The network of prospeckz in the building transfers the packages and helps with the navigation. It uses the 6LoWPan protocol for the transfer vie wireless connection. The Controller has a user interface from which one could change the settings of the network, start the belt with current location, direction and destination, track the belt and manually control it.
Next is the use case
diagram for our system, which shows a bit more detail about the functionality
of the system. What we did not have time to implement was the smart phone and
the emergency call, but we managed to implement the rest of the use cases.
Here is what each of us contributed to the system:
Igor Czerwinski – setting up 6LoWPan and the network; Location packets;
Dimo Iliev – Electronics and programming the prospeckz on the belt;
James McKeown – Compass; Communication between the Controller and the network;
Tsveta Stoyanova – Controller and user interface; Use case diagram and requirements;
To finish the picture we have our functional and non-functional requirements for all parts of the system.
Requirements for the controller
Requirement: 1
Description: User should be able to
create a receiver in the system with initial position, direction and
destination that would start navigating the receiver automatically
Rationale: This is the main functionality our system should have as
all receivers should be automatically controlled
Fit Criterion: User should be able to create a receiver
Requirement type: Functional
Requirement: 2
Description: User should be able to
track the belt visually using the controller user interface
Rationale: If the receiver is going in a wrong direction of an
emergency signal is issued, the user will be able to go and help
Fit Criterion: User should know at all times where the receivers are
Requirement type: Functional
Requirement: 3
Description: User should be able to
control the receiver manually
Rationale: It will be used for a small demonstration to the visually
impaired person to make him familiar with the belt
Fit Criterion: User will be able to control any of the receivers manually
Requirement type: Functional
Requirement: 4
Description: User should be able to
change some of the settings of the receiver and the network from the controller
Rationale: The prospeckz in the network might change and will be
different for every system
Fit Criterion: user will be able to change settings like the number of prospeckz and their location
Requirement type: Functional
Requirement: 5
Description: The interface of the
controller should be easy to use
Rationale: The user should not need to think too much about doing an
action in the system
Fit Criterion: Such interface will make the work of the user more enjoyable
Requirement type: Non-functional
Requirement: 6
Description: If the user is on a wrong
path to the destination, the system should give them the right instructions to
continue
Rationale: The user might turn the right direction, or the system may send a wrong direction in which case there should be a way to recover and go on the right path to the destination
Fit Criterion: Recovery from such errors is important to the visually impaired people
Requirement type: Nonfunctional
Requirement: 7
Description: The Controller should be
able to support up to 255 receivers
Rationale: The system should allow more than one receiver at a time
Fit Criterion: The system will be able to support multiple receivers
Requirement type:
Functional
Requirements for the network
Requirement: 8
Description: Routing nodes
in the network should be able to deliver packets from the controller to
the right receiver
Rationale: Packets should be delivered to the right receiver and
should not get lost on the way
Fit Criterion: Routing nodes will deliver the packets with instructions to the right receiver
Requirement type: Functional
Requirement: 9
Description: Routing nodes in the
network should transmit packets at least 2 kB\s
Rationale: The transmission speed should be high enough for the user
not to notice any delay
Fit Criterion: At that speed the user will not notice any delay
Requirement type: Non-functional
Requirement: 10
Description: Routing nodes in the
network should discard corrupt or invalid packets
Rationale: Corrupt packets will carry wrong information and invalid
packets might be from a different network
Fit Criterion: Corrupt or invalid packets should not be sent in the network
Requirement type: Non-functional
Requirement: 11
Description: Routing nodes in the
network should be capable of routing messages simultaneously from
up to 255 receivers to the controller
Rationale: The system should be able to cope with 255 receivers, so
the network should know where to send the packets
Fit Criterion: Routing nodes should transmit the packets to the right receiver for up to 255 receivers
Requirement type: Non-functional
Requirement: 12
Description: Routing nodes in the
network should provide means of locating each of 255 receivers
Rationale: Locating the receivers is in important part of the
functionality of the controller
Fit Criterion: Routing nodes should help receivers send the appropriate location information
Requirement type: Functional
Requirements for the hardware
Requirement: 13
Description: The belt should be easy
to understand by people with impaired vision
Rationale: They will be the main users, so it should be intuitive for
them to use it
Fit Criterion: If it is easy to use, people with impaired vision will be able to use it and will like it
Requirement type: Non-functional
Requirement: 14
Description: Vibration of the motors
should be strong enough to be felt through clothes
Rationale: If people cannot feel the vibrations, they will not be able
to use the belt
Fit Criterion: Vibration should be strong enough to feel, but not strong enough to hurt people
Requirement type: Non-functional
Requirement: 15
Description: The duration of the
battery should last for a whole run and a replacement battery must be provided
with easy to change method
Rationale: If there is no battery there will be no vibration or not
strong enough vibration
Fit Criterion: Battery should last enough and be easy to replace if needed
Requirement type: Non-functional
Requirement: 16
Description: The belt should be safe
for the user
Rationale: No part of the belt should be harmful to the user
Fit Criterion: Safety is very important
Requirement type: Nonfunctional
Requirement: 17
Description: The belt should give a signal
to the user when it is turned on
Rationale: User should be made aware that the belt is on and might
start vibrating
Fit Criterion: User should be prepared for any signals from the belt
Requirement type: Non-functional
Requirement: 18
Description: The belt should give a
warning when the battery is running
out
Rationale: User should know why the belt has stopped vibrating and
should know in advance if it was because of the battery
Fit Criterion: User should know if the battery should be changed soon.
Requirement type: Non-functional
Requirement: 19
Description: The belt should be
constructed in a way that the unexpected faults are minimised
Rationale: The construction of the belt must have potential faults
prevention mechanisms from the design to the final product
Fit Criterion: Potential faults should be minimized from the design stage
Requirement type:
Non-functional
Requirements for the protocol/packet structure
Requirement: 20
Description: The packet should contain enough
information for the receiver to accurately represent its current state and
location.
Rationale:
The main function of the packets is to carry information about state and
location
Fit Criterion: Packets should contain enough bits to represent the needed information by the receiver
Requirement type: Functional
Requirement: 21
Description: The packet should allow
the GUI to control the motors on the belt.
Rationale: Packets are the instructions the GUI sends to control a
belt
Fit Criterion: Packets should enable the GUI to send all the needed information
Requirement type: Functional
Requirement: 22
Description: The packet should be
lightweight, due to the bandwidth constraints of the wireless communications
Rationale: Packets should be 8 bits long
Fit Criterion: Packets should not be longer than needed
Requirement type: Non-functional
Requirement: 23
Description: The packet structure
should allow the GUI to communicate with multiple receivers simultaneously
Rationale: There should be information for which receiver should get
the packet
Fit Criterion: All packets should have a receiver to be able to distinguish them
Requirement type:
Functional
Requirements for the Controller-Gateway Interface
Requirement: 24
Description: The gateway should
receive network layer packets from the router nodes via the wireless interface
and deliver these packets to the Controller via wired UART interface
Rationale: This interface should be the vital connection between the
Controller and the network
Fit Criterion: Packets should be passed to the network via that gateway interface
Requirement type: Functional
Requirement: 25
Description: The interface should
have the ability to handle multiple users using the system
Rationale: The system should support multiple users and there should
be the needed support for that
Fit Criterion: Interface should support multiple users
Requirement type: Functional
Requirement: 26
Description: The interface should filter
any unwanted or erroneous packets
Rationale: Packets not with the length we need might be from other
network or might cause an error in the system, so they should not be passed to
the GUI or the network
Fit Criterion: Network and GUI will be safe from unwanted or erroneous packets
Requirement type: Non-functional
Requirements for the Compass
Requirement: 27
Description: The compass should use
a communication protocol supported by prospeckz - i2c
Rationale: As we are using the prospeckz the compass should be
compatible with them
Fit Criterion: I2c protocol is needed for the compass communication
Requirement type:
Functional
Requirement: 28
Description: The compass should be
accurate to +/-10degrees
Rationale: Anything more than this would result in wrong commands to
the belt
Fit Criterion: Compass should be quite accurate
Requirement type: Non-functional
Requirement: 29
Description: The compass should
compute headings in the range 0-360
Rationale: This is the main functionality of the compass
Fit Criterion: Compass should have a range from 0 to 360
Requirement type: Non-functional
Requirement: 30
Description: The sensor should be
suitable for indoor use - ie should not be affected by stray magnetic field
Rationale: Our system is mainly for indoor use, so the compass should
work in those conditions
Fit Criterion: Compass should work both indoors and outdoors
Requirement type: Non-functional
Requirement: 31
Description: The compass should be low power
Rationale:
The battery on the belt should last enough and it will help if the compass is
low power
Fit Criterion: The compass will not use up the battery of the belt very fast
Requirement type: Non-functional