PRE2024 3 Group18

Members

Name	Student Number	Division
Bas Gerrits	1747371	BEE
Jada van der Heijden	1756710	BPT
Dylan Jansen	1485423	BEE
Elena Jansen	1803654	BID
Sem Janssen	1747290	BEE

Approach, milestones and deliverables

Project Planning

Week	Milestones
Week 1	Project orientation Initial topic ideas Creating planning Defining deliverables Defining target user group
Week 2	Wiki layout Task distribution SotA research UX Design: User research
Week 3	UX Design: User Interviews Identifying specifications (MoSCoW Prioritization) Wiki: Specifications, Functionalities (sensors/motors used)
Week 4	Prototyping system overview UX Design: Processing interviews Bill of materials
Week 5	Evaluating and refining final design Order needed items
Week 6	Prototype creation and testing Wiki: Prototype description & Testing results
Week 7	Presentation/demo preperations Wiki: Finalize and improve

Project Roles

Name	Responsibilities
Bas Gerrits	Sensor research
Jada van der Heijden	Administration, UX design, Wiki
Dylan Jansen	SotA, Prototype
Elena Jansen	Designing, UX research
Sem Janssen	Potential solutions, Prototype, Feedback Devices

Problem statement and objectives

Problem Statement

Sketch of the road scenario

When encountering an environment as ever-changing and unpredictable as traffic, it is important for every traffic participant to have the widest range of information about the situation available to them, for safety reasons. Most roads are already covered in guiding materials: traffic lights, cross walks and level crossings have visual, tactile and auditory signals that are able to relay as much information to users of traffic as possible. Unfortunately, some user groups are more dependent on certain type of signals than others, for example due to disabilities. Not every crossing or road has all of these sensory cues, therefore it is important to find a solution for those user groups that struggle with this lack of information and therefore feel less safe in traffic. In specific, we are looking at visually impaired people, and creating a tool that will aid them in crossing roads, even with the lack of external sensory cues. The specific scenario used for this project is a 50km/h road with bike lanes on both sides, with no accessibility features, red lights or zebra. This scenario was recreated in Photoshop in the image on the right.

Main objectives

• The design aids the user in crossing roads regardless of external sensory cues present, thus giving more independence to the user.​
• The design has an audible testing phase and then gives intuitive haptic feedback for crossing roads.​
• The design must have a reliable detection system. ​
• The design does not restrict the user in any way from wearing what they want, participating in activities, not calling extra unnecessary attention to the user. ​

An extended list of all features can be found at MoScoW part.

State of the Art Literature Research

Existing visually-impaired aiding materials

Glidance, a prototype guidance robot for visually impaired people

Today there already exist a lot of aids for visually impaired people. Some of these can also be applied to help cross the road. The most common form of aid for visually impaired people when crossing is audio traffic signals and tactile pavement. Audio traffic signals provide audible tones when it’s safe to cross the road. Tactile pavement are patterns on the side walk to alert visually impaired people to hazards or important locations like cross walk. These aids are already widely applied but come with the drawback that it is only available at dedicated cross walks. This means visually impaired people might still not be able to cross at locations they would like to, which doesn’t positively affect their independence.

Another option is smartphone apps. There are currently two different types of apps that visually impaired people can use. The first is apps that use a video call to connect visually impaired people to someone that can guide them through the use of the camera. Examples of these apps are Be My Eyes and Aira. The second type is an app utilising AI to describe scenes using the phone’s camera. An example of this is Seeing AI by Microsoft. The reliability of this sort of app is of course a major question, however during research Aira was found to greatly improve QoL in severely visually impaired individuals. There have also been others apps developed but often not widely tested or used and others with a monthly subscription of 20 euros a month which is quite costly.

There have also been attempts to make guidance robots. These robots autonomously guide, avoid obstacles, stay on a safe path, and help you get to your destination. Glidance is one of these robots currently in the testing stage. It promises obstacle avoidance, the ability to detect doors and stairs, and a voice to describe the scene. In its demonstration it also shows the ability to navigate to and across cross walks. It navigates to a nearby cross walk, slows down and comes to a standstill before the pavement ends, and keeps in mind the traffic. It also gives the user subtle tactile feedback to communicate certain events to them. These robots could in some ways replace the tasks of guidance dogs. There are also projects that try to make the dogs robot-like. Even though this might make the implementation harder than it needs to be. It seems the reason for the shape of a dog is to make the robot feel more like a companion.  

Noa by Biped.ai worn by a user

There also exist some wearable/accessory options for blind people. Some examples are the OrCam MyEye: A device attachable to glasses that helps visually impaired users by reading text aloud, recognising faces, and identifying objects in real time. Or the eSight Glasses: Electronic glasses that enhance vision for people with legal blindness by providing a real-time video feed displayed on special lenses. There's also the Sunu Band (no longer available): A wristband equipped with sonar technology that provides haptic feedback when obstacles are near, helping users detect objects and navigate around them. While these devices can all technically assist in crossing the road, none of them are specifically designed for that purpose. The OrCam MyEye could maybe help identify oncoming traffic but may not be able to judge their speed. The eSight Glasses are unfortunately not applicable to all types of blindness. And the Sunu Band would most likely not react fast enough to fast-driving cars. Lastly, there are some smart canes that come with features like haptic feedback or GPS that can help guide users to the safest crossing points.

https://babbage.com/ Had a product called the N-vibe consisting of two vibrating bracelets giving feedback on surroundings but if you look it up on their site the page seems to be deleted https://babbage.com/?s=n+vibe The product used to be a GPS that helps blind people get from point a to point b in a less invasive way with feedback through vibration. This feedback through vibration has been tested in multiple scenarios and tends to work. This would also be a good idea for our project. Babbage is a company with many solutions for visually impaired people with products slightly similar to our goal but nothing quite like it yet.

Biped.ai developed a wearable vest called 'NOA'. "NOA is a revolutionary vest worn like a backpack that guides people with blindness and low vision in complement to canes & dogs. With cameras, a computer, and hands-free operation, it speaks to you to give you clear instructions.Through audio feedback, NOA identifies obstacles, provides GPS navigation, describes surroundings, and helps locate important things like cross walks and doors - both indoors and outdoors." (description from their official site).

User Experience Design Research: USEr research

For this project, we will employ a process similar to UX design:

• We will contact the stakeholders or target group, which is in this case visually impaired people, to understand what they need and what our design could do for them
• Based on their insight and literature user research, we will further specify our requirements list from the USE side
• Combined with requirements formed via the SotA research, a finished list will emerge with everything needed to start the design process
• From then we build, prototype and iterate until needs are met

Below are the USE related steps to this process.

Target Group

Primary Users:

• People with affected vision that would have sizeable trouble navigating traffic independently or crave more independence in unknown areas: ranging from heavily visually impaired to fully blind (<10%)

Our user group only focusses on those who are able to independently take part of traffic in at least some familiar situations.

Secondary Users:

• Road users: any moving being or thing on the road will be in contact with the system.
• Fellow pedestrians: the system must consider other people when moving. This is a separate user category, as the system may have to interact with these users in a different way than, for example, oncoming traffic.

Users

General information

As not everyone is as educated on visually challenged people and what different percentages mean for people sight some general information is included.

Interviewed users have said that just a percentage is not always enough to illustrate the level of blindness. Thus we combine it with the kind of blindness in our survey and interview.

An example, Peter from Videlio has 0.5% with tunnel vision, and George (70yo) has complete blindness.

• "Total blindness: This is when a person cannot see anything, including light.
• Low vision: Low vision describes visual impairments that healthcare professionals cannot treat using conventional methods, such as glasses, medication, or surgery.
• Legal blindness: “Legal blindness” is a term the United States government uses to determine who is eligible for certain types of aid. To qualify, a person must have 20/200 Trusted Source vision or less in their better-seeing eye, even with the best correction.
• Visual impairment: Visual impairment is a general term that describes people with any vision loss that interferes with daily activities, such as reading and watching TV."

In the Netherlands we use different terms and fractions. These are used in answers to our interview questions:

• Milde – gezichtsscherpte slechter dan 6/12 tot 6/18 50%-33%
• Matig – gezichtsscherpte slechter dan 6/18 tot 6/60 33%-10%
• Ernstig – gezichtsscherpte slechter dan 6/60 tot 3/60 10%-5%
• Blindheid – gezichtsscherpte slechter dan 3/60 <5%

6/60 means that what a person with 20/20 vision can see at 60 meters, doesnt stop being blurry until 6 meters. For 3/60 this is 3 meters.

The Dutch version of legal blindness: "Maatschappelijk blind: Your visual acuity is between 2% and 5%. You can still see light and the outlines of people and objects, but your visual impairment has a major impact on your life. Sometimes a person may see sharply, but there is a (severe) limitation in the field of vision, such as tunnel vision. If your field of vision is less than 10 degrees, this is referred to as maatschappelijk blind."

For 50%-10% people can usually be in traffic by themselves with no issues and no tools. Sometimes high contrast glasses are used or other magnification tools. Starting at 10% a lot of people use a cane to look for obstacles. This is why we focus on people with less than 10% vision or rapidly declining vision for our research and as our target group.

At 2% vision people can still count fingers from 1m distance. However this can differ with different kinds of blindness;

Tunnel vision, central vision loss (the centre of vision is blurry), peripheral vision loss, blurry vision, fluctuating vision (vision changes due to blood sugar etc), Hemianopia (loss of vision in half of the vision field on one or both eyes), light perception blindness (Being able to see shape and a little coulor).

What Do They Require?

The main takeaway here is that visually impaired people are still very capable people, and have developed different strategies for how to go about everyday life.

"I have driven a car, a jet ski, I have gone running, I have climbed a mountain. Barriers don’t exist we put them in front of us." (Azeem Amir, 2018)

‘Not having 20/20 vision is not an inability or disability its just not having the level of vision the world deems acceptable. I'm not disabled because I'm blind but because the sighted world has decided so.’. This was said by Azeem Amir in a Ted Talk about how being blind would never stop him. In the interviews and research it came forward again and again that being blind does not mean you can not be an active participant in traffic. While there are people that lost a lot of independence due to being blind there is a big group that goes outside daily, takes the bus, walks in the city, crosses the street. There are however still situations where it does not feel safe to cross a busy street in which case users have reported having to walk around it, even for kilometres, or asking for help from a stranger. This can be annoying and frustrating. In a Belgian interview with blind children a boy said the worst thing about being blind was not being able to cycle and walk everywhere by himself, interviewing users also reflected this. So our number one objective with this project is to give back that independence.

A requirement of the product is not drawing to much attention to the user. This is because while some have no problem showing the world they're legally blind and need help, others prefer not to have a device announce they are blind over and over.

Something that came forward in the interviews is that google maps and other auditory feedback software lack a repeat button. Traffic can be loud and then when the audible cue is missed it is hard to figure out where to go or what to do. So while audio is helpful it is only helpful if it can be repeated or is not the sole accessible option. Popular crossing methods include listening to parallel traffic, the logic being if the traffic parallel to the user is driving the traffic in front can not go. In the Netherlands there is also a legal protocol that says when a blind person sticks up their cane all traffic is required by law to stop and let them cross. In reality this is often not the case with many people not stopping. The AD also posted an article on this in 2023 stating that half of cyclists and drivers don't stop, causing one-third of blind people to feel unsafe crossing the road.

Blind people do not like to be grouped with disabled people, or even mentally challenged people. They might not have the same vision as us but that is the only difference. There is nothing wrong with their mind, they are not helpless children. Blind people also might not look aware of their surroundings but they often are. When designing this has to be kept in mind. Blind people can still get complicated solutions, can understand a design process and thus why a product might be expensive. Often accessibility solutions can be simple, but we do not need to oversimplify it so they can understand.

For our interviews a lot of the interviewed people were fairly old, this also makes sense as our main contact that used his network was Peter who is not young himself, and because as we get older chances of our vision decreasing increase. Many of them due to their lack of vision have learned to use technology and more complicated devices than the average elderly person. They also might be more open to trying new things. This does not go for everyone so we still have to be careful with a intuitive UX design but less so than with other elders.

Society & enterprise

How is the user group situated in society? How would society benefit from our design? What is the market like?

People that are visually impaired are somewhat treated differently in society. In general, there are plenty of guidelines and modes of help accessible for this group of people, considering globally at least 2.2 billion have a near or distance vision impairment. In the Netherlands there are 200 000 people with a 10%- 0% level of sight ('ernsitge slechtziendheid' and 'blindheid'). It is important to remember that when someone is legally blind a big percentage has some form of rest vision left. Peter who we have interviewed for this project and is a member of innovation space on campus, has 0.5% sight with tunnelvision. This means Peter can only see something in the very centre. Sam from a Willem Wever interview has 3% with tunnel vision and can be seen in the interview wearing special glasses through which he can still watch tv and read. Society often forgets this and simply assume blind people see nothing at all. This is true a 70 year old man we interviewed, but not for all target users.

The most popular aids for visually challenged people is currently the cane and the support dog. Using these blind people navigate their way through traffic. In the Netherlands it is written in the law that when the cane is raised cars have to stop. In reality this does not always happen, especially bikes do not stop, this was said in multiple interviews. Many people do have the decency to stop but it is not a fail proof method. Blind people thus remain dependant on their environment. Consistency, markings, auditory feedback and physical buttons are there to make being independent more accessible. These features are more prominent in big cities, which is why our scenario takes place in a town road with no accessibility features.

Many interviewed people reported apps on their phones, projects from other students, reports from products in other countries, paid monthly devices, etc. There are a lot of option for improvement being designed or researched but none are being brought into the big market. Peter from Videlio says the community does not get much funding or attention in new innovations. Which is why he has taken it into his own hands to create a light up cane for at night, which until now does not even exist for Dutch users.

There is a lot of research on universities and school projects because it is an 'interesting user group' with a lot of potential for new innovations, but they do not get actual new products on the market. People with a vision of less than 10% make up such a small part of society that there is simply not enough demand for new products as those are very expensive to develop, which is a shame.

As society stands right now, the aids that exist do help in aiding visually impaired people in their day to day life, but do not give them the right amount of security and confidence needed for people to feel more independent, and more at equal pace as people without impaired vision. In order to close up this gap, creating a design that will focus more on giving users a bigger sense of interdependency and self-reliance is key.

User Experience Design Research: Stakeholder Analysis

To come in closer contact with our target groups, we reached out to multiple associations via mail. Some example questions were given to show the associations what our interviews could potentially look like.

Following these questions, we got answers from multiple associations that were able to give us additional information and potentially participate in the interviews.

From this, we were able to setup interviews via Peter Meuleman, researcher and founder of Videlio Foundation. This foundation focusses on enhancing daily life for the visually impaired through personal guidance, influencing governmental policies and stimulating innovation in the field of assisting tools. Peter himself is very involved in the research and technological aspects of these tools, and was willing to be interviewed by us for this project. He also provided us with interviewees via his foundation and his personal circle.

Additionally, through a personal contact, we were able to visit StudioXplo on the 21st of March to conduct some in-person interviews.

These interview were semi-structured, with a structured version being sent as an announcement on www.kimbols.be (in Dutch) via Microsoft Forms. The announcement, form link and the questions can be found in the Appendix as well.

Interview results

With these interviews, we were aiming to find answers to the following research questions:

• How do visually impaired people experience crossing the road?
• What wishes do visually impaired people have when it comes to new and pre-existing aids?
• How can we improve the sense of security and independency for visually impaired people when it comes to crossing the road?

From the interviews, a (deductive) thematic analysis was done. As we went into these interviews with a predefined goal and some pre-exiting notions on what the participants might answer, the approach is deductive.

A total of 17 people were interviewed, of which 5 were done via call (semi-structured), two face to face (semi-structured) and 10 via Microsoft Forms (structured). The average age of respondents was around 53, with ages ranging from 31 - 69. A large amount of participants reported to be fully blind, with some stating to have legal blindness or low vision.

Thematic Analysis

Theme	Codes
Experience of traffic	Little attention to pedestrians Abundance of non-marked obstacles Very dependant on situation Familiar = comfort
Experience of crossing the road	Unclarity about crossing location Lack of attention from other traffic users Lack or abundance of auditory information Taking detours for dangerous roads
Road crossing strategies	Patience for safety Focus on listening to traffic Being visible to other traffic users Confidence Cyclists Asking for help if needed
Aid system needs	Not being able to pick up everything Aid should not be handheld Preference for tactile information + haptic feedback Control over product

Experience of traffic

Overall, participants gave very varying answers when it came to their general experience with traffic. Almost all users use a white cane, with some having an additional guide dog. Most if not all participants expressed that they are able to move around freely and with general ease and comfort, but that it is dependant on the situation at hand. Most participants expressed their experience with traffic to worsen in a higher-stake situation, with busy roads. This is mostly due to other traffic users 'being impatient and racing on '. This point comes back multiple times, with people expressing that at peak hours they could lose track of the situation easier.

Additionally, it was mentioned that participants could find it hard to navigate new situations, especially those where things are not marked properly. One participant mentioned that there are cases of bike paths right behind a road with a cross walk, where the cross walk doesn't extend to the bike path. She mentioned that it is hard to anticipate for situations like this, where there are unexpected obstacles. Things such as curbs or tactile guiding lines being blocked off by for example café tables or billboards were also mentioned as hazards. Another participant talked about the struggles of road work and construction noise throwing her off even on familiar routes.

Experience of crossing the road

The point of the sound guidance at traffic lights or traffic control systems (rateltikker) came up multiple times. Participants mentioned that these really help, but are not available everywhere, sometimes turned off or the sound is too low. When it comes to these types of auditory information, participants mentioned that, since they rely much on their hearing, the lack of auditory signals can make it hard for them to cross. Things such as cyclists, electric vehicles and On the other hand,

Participants also mentioned it can sometimes be hard to find the spot to cross the road. One participant mentioned that the sound of the traffic can be a hint to a traffic light being present ("If the traffic is all going and then suddenly stops, I know there is a traffic light nearby"), but if there are no guidelines (no rateltikker or tactile guiding lines), she would not know where to cross the road.

Another participant talked about how he always avoids crossing in corners of the road and knows other blind people do this too, because the corner is one of the more dangerous parts to cross.

Road crossing strategies

A general theme that comes up is safety first. Many participants described an approach of patience and clarity when it comes to crossing the road. Firstly, if the road was too busy (a high-speed road, two-way road or at peak hour), many participants would choose to avoid the road or find the safest spot to cross. If there is no other option, some would also ask cyclists to aid in crossing the road. Secondly, all participants described that they would carefully listen to traffic, and try to cross when it is least busy. Many mentioned they would do this when they were absolutely sure nothing was coming (no sound from traffic, even then still waiting a bit). Then, in order to actually cross, the participants that owned a white cane would then lift their cane or push it towards the road, so that other users can see that they want to cross. Participants clearly stated visibility as an important thing, but mentioned even then some traffic users would not stop.

Two participants mentioned that in order to show you want to cross, you should just move confidently and without hesitation, since otherwise traffic will just keep moving. Other participants seem to share this sentiment of traffic being unpredictable, but seem to prefer waiting until they are certain it is safe: when there is hesitation, they would not cross.

An additional issue brought up was cyclists (or electric vehicles): these were hard to hear, and would often refuse to stop. This issue of traffic users being impatient was mentioned before in experience of traffic, and seems to reoccur here and restrict the participants' crossing strategies.

Two-way roads are a point of interests: some participants mentioned these type of roads as hard to cross. Most participants prefer to cross the road in one go, and for two-way roads, it is hard to anticipate whether there is a car coming from the other side, and whether cars are willing to stop and wait. Many mentioned the concept of parallel traffic in order to identify when to cross: if the traffic parallel to them is surging, they know not to cross and vice versa. People with some form of vision left are more confident in crossing roads with two lanes, especially during daylight.

Aid system needs

In general, one of the main issues brought up, which is mentioned before in Road crossing strategies, is that there are some traffic users that the participants are unable to hear. Their aids are not able to detect these sorts of things, and circumstances such as loud wind or traffic can make it hard for the participants themselves to pick these things up.

Almost all users expressed a preference for an aid system with tactile information, especially when considering the overload of auditory information already present in traffic (cars, beeps, wind etc.). One participant mentioned that a combination of the two could be used as a way of learning how the aid works (this participant also travels with other visually impaired friends, and mentioned the auditory component could aid their friends in crossing the road together).

Many users expressed concern when it comes to control: most prefer to have absolute control over the aid system, with many expressing concern and distrust ("A sensor is not a solution" and "I'd rather not use this"). Some prefer minimal control, mostly due to their energy going towards crossing the road already. One participant mentioned as an example that they would like to be able to turn their system on and off whenever it suits the situation. Another participant asked for a stand-by mode where it would not fully turn off and recognise when it is time to cross a road but this would be much harder in application.

Participants also said they would prefer to not have to hold the system in their hand, as most already have their hands full with their other aids and if they were to drop the product it could be harder to retrieve.

Insight overview

Overall, the general idea that independency is an important aspect for our user group has become very clear from our interviews. From the four themes created in the analysis, we can set up a more comprehensive list of what our user group seems to need and desire in the context of crossing roads.

As for the research questions:

• How do visually impaired people experience crossing the road?
  • Many things were mentioned about the general scanning of surroundings, also in unknown areas. A common struggle is finding the actual point of where to stand to safely cross the road. A spot where the user is visible to others, a crossing, a green light, it is not always easy to find. In unknown surroundings, users are more prone to avoid the situation entirely. Roads have different setups: a common obstacle is a road that is in the middle divided by a car parking, bushes, tiles etc. It is thus important to consider that our product should not be dependant on the type of road of general differing traffic situations.
  • Not all legally blind people are capable of taking part in traffic by themselves. When it comes to our product, we want to limit it to those who are able to go places without assistance. Other aspects mentioned related to the detections of objects and surroundings mentioned by the interviewees will not be taken into account when it comes to the product itself, as this is outside the scope of the project at this moment.
  • Attention to cyclists is an unexpected extra point of interest: as interviewees mentioned these are hard to hear and are more prone to not stopping, it is important that our product is able to detect and differentiate all sorts of traffic, not just cars.
  • Users generally prefer to cross the road in one go. With respect to this, our device should let the user know when it is safe to cross the road entirely, not partially.
• What wishes do visually impaired people have when it comes to new and pre-existing aids?
  • Users have a general need for the product to be out of the users' way, or the need of the product not interrupting their general road-crossing procedures. This includes a general preference for the product to not be in their hands, not be too heavy. As a solution to this issue, we opt to place the sensors on the shoulders of the user, and a bracelet for the feedback.
  • A general preference for tactile feedback over auditory feedback was mentioned, with the usage of auditory feedback being an additional mode of help. Auditory feedback can not be heard due to surrounding sounds, but can also help fellow (visually impaired) pedestrians in giving information on when to cross the road. Additionally, some visually impaired people (especially as they age) have declining hearing. The auditory feedback should at most be secondary to tactile with all these considerations.
    • The vibrations should already be on, also when the user cannot cross yet (with respect to the users mentioning that some traffic aids can be off or to low, leading to annoyance).
  • The product can be visible, since our user group usually already has aids that indicate to others that they are visually impaired. Combined with the reluctance and uncertainty of whether traffic actually stops, is it important that the users do not look like they are not visually impaired.
• How can we improve the sense of security and independency for visually impaired people when it comes to crossing the road?
  • In order to give the users more independence, it is best to give the users a lot of control over the product. This means giving them the choice of what level of feedback they want to receive, and allowing them to turn the product off or on whenever they like.
  • In terms of security, the product should in practice always be on, and the product needs to have a long battery life to ensure it does not give faulty readings.

MoSCoW Requirements

From the user interview we can infer some design requirements. These will be organised using the MoSCoW method. First off, the product will have to give feedback to the user. It was mentioned in the interviews that audio feedback might not always be heard, however vibrational feedback can be felt and might be more reliable. Therefore vibrational feedback will be the feedback method of choice and audio is seen as an optional feature. Many visually impaired people also already use tools to help them, it should be taken into consideration that our solution does not impact the use of those tools or it could even integrate with them. Interviewees also mentioned that what they would like is to be more independent, this is therefore also a priority for the solution. Ideally it would create more opportunities for visually impaired people to cross the road where and when they want. Some people mentioned in the interviews they don't like drawing much attention to their blindness, therefore a the implementation should be rather discrete. This could be difficult however, as quite a few devices are needed which might be difficult to completely hide. A very important step of designing a road crossing aid is of course safety because mistakes could injure or even cost someone their life. Thus, safety should be a high priority when making a product. It's also clear from the interviews that users do not need the solution to be simplified for them and are capable of handling more complicated devices. The solution can thus be allowed to be more advanced.

Because the group of visually impaired users is quite diverse, a decision must be made about who to design for specifically. As people with minor visual impairments do not require much in the way of assistance in crossing the road, focusing the design around people with moderate to severe blindness will provide more usefulness. Furthermore, the solution will not be able to replace the place of current blind assistance tool but rather act as an additional help. While AI detection of cars, bicycles, or other traffic could provide a good solution to evaluating traffic situations, this is outside of the scope of the project and will therefore not be considered.

The table below summarises the design requirements.

Must	Should	Could	Won't
Give vibration feedback	Not draw too much attention	Give audio feedback	Be designed for people with minor visual impairments
Ensure safety	Allow new road crossing opportunities	Integrate with existing aids	Implement AI detection
Not get in the way	Not obstruct use of canes/dogs	Be complex/advanced	Replace existing aids
Provide extra independence	Allow crossing the road in one go	Detect all kinds of traffic	Detect the physical road layout

Design ideas

Visualisation to calculate the minimum distance.

To safely cross a road with a speed limit of 50 km/h using distance detection technology, we need to calculate the minimum distance the sensor must measure.

Assuming a standard two-lane road width of 7.9 meters to be on the safe side, the middle of the second lane is at 5.8 meters. This gives us a height h of 5.8 meters.

The average walking speed is 4.8 km/h, which converts to 1.33 m/s. Therefore, crossing the road takes approximately 5.925 seconds.

The distance d can now be calculated. A car travelling at 50 km/h moves at 13.88 m/s, so: 

[math]\displaystyle{ d=13.88 * 5.925 = 82.24 }[/math] meters

Applying the Pythagorean theorem, the radius r is:

[math]\displaystyle{ r=\sqrt(d^2 + h^2)=\sqrt(82.24^2 + 5.8^2)=82.44 }[/math]

This means the sensor needs to measure a minimum distance of approximately 82.44 meters to ensure safe crossing. However, the required distance needs to be greater to ensure the user can cross the road safely. Users also need enough time to react to the device's feedback and make a decision based on additional cues, such as sound. Since the distance is significantly greater than the height, the height factor has minimal influence on the calculation and can be neglected. To be on the safe side, the threshold is set to 9 seconds by default. However, users can adjust this value in the settings based on what they feel comfortable with. To help prevent accidents, the threshold cannot be set lower than 8 seconds.

Sensors

There are 3 main ways to measure distances which we will discuss and evaluate for our application: Ultrasonic sound sensor, lidar/radar, or an AI camera.

Radar/Lidar sensor

This section discusses radar versus Lidar. Lidar and radar sensors are both able to measure distances of at least 100 meters. Both sensors are widely used, for example, in autonomous vehicles, robotics, traffic control and surveillance systems. To determine the best sensor for this application, the strengths and weaknesses are evaluated.

The benefits of the lidar sensor are as follows:

• High precision and resolution: Lidar uses laser beams, which offer high accuracy and resolution. It can be used for 3D mapping of environments and object detections. Due to the high resolution, it can make great measurements.
• 3D mapping: The lidar sensor sends light beams in all directions, creating 3D images of the surroundings. This can be useful when implementing an AI with lidar helping the person navigate the surroundings. It can detect the difference between trucks, cars, bicycles and pedestrians.

The drawbacks of the lidar sensor are as follows:

• Weather conditions: The range decreases significantly when the conditions are not ideal. The conditions the lidar sensor struggles with are rain, fog, snow, dust and smoke. The light beam scatters, reducing the accuracy. Bright sunlight can cause noise to the data.
• Expensive: Lidar sensors are expensive, which would make the product quite expensive and not appealing to the user.
• Surface: The surface matters when measuring using light. Lidar sensors struggle with reflective and transparent surfaces, which results in inaccurate data.
• Power consumption: Lidar systems consume more power than radar sensors, which is not ideal when using a battery system to power the device.

The benefits of the radar sensor are as follows:

• Longer range: Radar sensors are able to measure up to much larger ranges.
• Robustness: The radar sensor is less affected by rain, fog or snow, making it more reliable for different weather conditions. The sensor is also not affected by sunlight because it uses radio waves.
• Lower cost: Most radar sensors are less expensive than lidar sensors, especially when comparing sensors with the same measuring ranges. Thus making the product less expensive for the user.
• Smaller: The radar sensor is significantly smaller in size than the lidar sensor.

The drawbacks of the radar sensor are as follows:

• Lower resolution: The radar sensor provides less data than the lidar sensor. Radar sensors have a hard time differentiating between similar objects and small objects. The situation measured using the radar sensor is less detailed than the lidar.
• Busy environments: When there are multiple reflecting surfaces, a lot of echoes arise from the surfaces, causing the radar sensor to pick up more objects than there are in the surroundings.
• Angles: Increasing the angle at which the radar sensor can measure the environment decreases the distance. Due to this the product needs two radar sensors to measure in 2 different directions to check if it is clear to cross the road.
• Frequency dependent: The resolution of the radar sensor is dependent on the frequency of the sensor. Increasing the frequency increases the resolution of the radar but also increasing the price.

In conclusion, the lidar provides better resolution however for this application the high resolution is not necessary to measure road users. The sensor needs to accurately measure position and speed of road users. If sensor picks up more road users at the same place because of echoes that doesn’t matter because filters can solve this problem. The robustness of the sensor is important to reliable operation in all weather condition. Cost is also an important factor. While the radar sensor requires two units to function, it is still cheaper compared to a single LIDAR sensor. Additionally, power consumption is important to keep the device compact and light, avoiding the need for a large battery. That is why the radar sensor is most optimal for this application.

The LiDAR and radar sensors that were investigated can be found at the following links: LIDAR sensor and Radar sensor.

Ultrasound using Doppler effect

This section discusses ultrasound sensors to measure distance utilising the Doppler effect (Doppler shift). This technology is already widely researched and used in applications for blind and visually impaired people. In essence, it means that a high frequency sound wave is emitted which will reflect back from the object of significance. Whenever this object is moving towards the receiver it will "squish" the reflected sound wave, decreasing its wavelength and increasing its frequency (higher pitch). The opposite can be said for an object that moves away from the receiver; the wavelength increases and the frequency decreases. This difference between the original incident frequency and the reflected frequency can be compared and used to calculate the speed of the detected object.

The Doppler effect is very useful in our situation but ultrasound is the weaker link in this system. Ultrasound, generally, has a maximum range of about 21 meters which is far below the required range of 80-100 meters. Secondly, it measures at a slow rate (200 Hz) which means it can be quite inaccurate in quickly changing environments. Lastly, ultrasound is susceptible to differences in vapour concentrations of the air which changes the speed of sound in air, which can decrease accuracy of measurement results.

Wearable AI camera

This wearable device has a camera built into it in order to be able to view traffic scenes visually impaired people might want to cross but lack the vision to do so safely. The cameras send their video to some kind on small computer running an AI image processing model. This model would then extract some parameters that are important for safely crossing the road, think about: if there is oncoming traffic; other pedestrians; how long crossing would take; or whether there are traffic islands. This information can then also be communicated back to the user according to their preferences: audio (like a voice or certain tones) or haptic (through vibration patterns). The device could be implemented in various wearable forms. For example: a camera attached to glasses, something worn around the chest or waist, a hat, or on the shoulder. The main concerns is that the user feels most comfortable with the solution, like being easy to use, not being in the way, and being hidden if it makes them self-conscious.

This idea requires a quite sophisticated AI model, it is of concern that the computer is able to quickly process cars and relay the information back to the user or else the window to safely cross the road might have already passed. It also needs to be reliable, should it misidentify a car or misjudge is speed it could have a negative impact for the users life expectancy. Running an AI model like is proposed could also pose a challenge on a small computer. The computer has to be attached to the user is some way and can be quite obtrusive if it is too large. Users might also feel it makes them uncomfortable if it is very noticeable that they are wearing some aid and a large computer could make it difficult to make discrete. On the other side, an advanced model could probably not run locally on a very small machine, especially considering the fast reaction times required.

Feedback

Feedback is the communication of spatial information to visually impaired people to perceive their surroundings. There are two main types of feedback that are explored for this project, specifically; haptic feedback and auditory feedback. Haptics are feedback devices relating to touch and auditory devices utilise sound to convey information.

It is important that the feedback device adheres to the following:

1. The signal must be noticeable, over all traffic noises and stimuli surrounding the user
2. The signal must clearly indicate whether it is time to walk (Go condition) or to keep still (No-Go condition), and these conditions must be distinguishable
3. The signal must not be confused by any other surrounding stimuli

These rules must be adhered to in order to properly carry over the information from the device to the user, and for the user to use said information to then make their decisions.

Haptic Feedback

Haptic means “relating to the sense of touch”. Haptic feedback is therefore a class of feedback devices that utilise the sense of touch for conveying information. These haptic systems can also be divided into three categories: graspable, wearable, and touchable devices.

Different types of haptic devices

Graspable devices are typically kinaesthetic i.e. force-feedback devices, which allow the user to push and/or be pushed back by the device.

Wearable systems include devices that can be worn on the hands, arms or other parts of the body and provide haptic feedback directly to the skin. Usually this is done by vibrating at different frequencies and/or in different vibrational patterns, like alternating long and short pulses (similarly to Morse code). Utilising vibrations to convey information is a technique that is already widely used in smartphones and game controllers.

Finally, touchable systems are devices with changing tactile features and surfaces that can be explored by the user.  

For our purposes, a wearable system seems to be the most logical. A VIP can wear the device and can immediately receive information gathered in the surroundings by vibrations directly on the skin. A human can sense different vibrations ranging from 5 to 400 Hz.

Auditory Feedback

When it comes to sound cues, there are multiple aspects to consider. Most crossings with traffic lights already have an auditory system set up (rateltikker) in order to signal to the pedestrians whether they can cross or not. To mimic this type of auditory pedestrian signal, the same type of considerations should be used for our design. From the book Accessible Pedestrian Signals by Billie L. Bentzen, some guidelines and additional info had been laid out that can be considered when looking at what kinds of sounds, what volume levels and what frequencies are best to use.

The sound of the aiding device must be audible over the sounds of traffic. The details of noise levels around intersections are out of scope for this specific research, as there are many factors that go with determining the noise level (such as wind conditions, temperature, height of receiver and so on). Therefore, we will keep this straightforward, and use information of research with similar conditions as our key scenario, a 50 k/m road with no traffic lights.

In general, a signal that is 5dB above surrounding sound from the receiver is loud enough for the pedestrian to hear and process the sound made. As the sound in our scenario will be coming from the a device relatively close to the user, we do not need to be that concerned with it being audible from across the street. From research and simulations on traffic noises at intersections, the general noise sound levels around intersections lay around 65-70 dB. For a signal then to be heard, a sound of 70-75 dB seems to be loud enough to be audible.

As for frequency levels of sound, research shows that high-frequencies sounds are easier to distinguish and detect from traffic sounds that low- or medium-frequency sounds. For example, the results from a study done by Hsieh M.C. et al. from 2021, where the auditory detectability of electric vehicle warning sounds at different volumes, distances, and environmental noise levels was tested, shows an overall preference for the high-frequency warning sound. This sound was not affected by environmental noise. Things to note however, is that the detection rate (whether participants could detect the sound) of the higher sound pressure level (51 dBA) was significantly higher than the lower sound pressure level (46 dBA) under the high-frequency sound. This means that, when using high-frequency sound, it is imperative that a higher sound pressure level is used in order for users to actually detect the sound. Additionally, this research was done about electric vehicle warning sounds, which are by nature harder-to-detect sounds. This study however still informs us that even under these lower sound level conditions, high-frequency sounds are preferred.

Research from Szeto, A. Y. et al. also notes this usage of high-frequency sounds: low-frequency sounds require longer durations and intensity to be heard, and low-frequency masking of the auditory signals can occur in traffic, even when most of the sound energy in traffic noise occurs in frequencies below 2000 Hz. From their testing, using different types of sounds (cuckoo vs. chirp, which we will get into later), for the signal to be audible, there needs to be a good balance between the potential of the low-frequency masking of the traffic noise (<1000 Hz) and the aspects of hearing loss for higher frequency sounds (>2500 Hz) most common in elderly adults. Their advice is to use signals with frequencies between 2000 - 3000 Hz, with harmonics up to 7000 Hz. Best is to use an array of frequencies, that are continuous and have a duration of 500 ms. Varying the frequency around 2500 Hz, with a minimum of 2000 and maximum of 3000 Hz is recommended by Szero, A. Y. et al. The book on Accessible Pedestrian Signals by Billie L. Bentzen supports this idea: high harmonics, with continuous varying frequencies.

As for type of sound, there are multiple options as well:

• Voice messages: messages that communicate in speech are optimal for alerting pedestrians and their surroundings that the pedestrian is wanting to cross, as this signal is understandable and meaningful to everyone (ex. 'Please wait to cross')
• Tones: chirp and cuckoo sounds. In America, the high-frequency, short duration 'chirp' and low-frequency, long duration 'cuckoo' type sounds are used to indicate east/west and north/south cross walks respectively. Additionally, the chirp sounds are of higher frequency compared to the cuckoo sounds, and are therefore easier to detect. In turn, this higher frequency sound is harder to detect for elderly people, as mentioned before. Another point of consideration is that pedestrians have mentioned that mockingbirds or other surrounding animals may imitate these sounds, therefore making it harder to distinguish from their surroundings.
• Tones: major and minor scales. Major scales in music are often associated with positive emotions, as minor scales are associated with negatives. Additionally, minor scales exhibit more uncertainty and variability, which can evoke feelings of instability. Compared to the major scale, a minor scale contains pitches that are lower than expected, paralleling characteristics of sad speech, which often features lower pitch and slower tempo.

Considering this research, it is thus important to think about the trade-off between how meaningful the auditory message can be in context of its' surroundings, in order to make it distinguishable but still relay the information of whether crossing is safe or not.

Creating the solution

A system overview of the road crossing aid

Keeping in mind the design requirements, we can start thinking about the prototype. First of all, there will have to be some feedback to the user when it is safe to cross the road. It was clear there is a preference for vibrational feedback so a vibration motor will be used for this purpose. The next step is to think about how to attach this to the user so they can feel it. There are several options here: one is to attach some kind of belt to the waist, another to make a vest , and lastly to have a wristband. In the interviews some people asked for discreet options and other preferred familiar placings. As such the wristband seems like the best choice here, which is what the prototype will use. That being said the other solutions are not without merit. Their larger size might allow them to embed multiple vibrational motors allowing for more detailed or directional feedback.

Next is to think about the detection of traffic. From multiple design options the long range lidar sensor seems the most reliable and as safety (and thus reliability) is very important, this is the detection method of choice. The chosen sensor is the Texas Instruments AWR2243 radar sensor, the details of will be discussed below.

Simulation

To write a simulation for a radar sensor, we need to understand how a radar sensor works. Radar stands for Radio Detection and Ranging. The radar sensor uses radio waves to detect objects and measures the distance, velocity and their position. The radar sensor transmits radio waves through an antenna. The electromagnetic waves travel at the speed of light and have a frequency ranging from 1 to 110 GHz. The radio waves reflect off objects. The reflection depends on the material. The antenna receives the reflective waves. From the time it takes to transmit and receive the radio waves, the distance can be calculated using the following equation.

[math]\displaystyle{ Distance = \frac{speed \ of \ light \cdot time}{2} }[/math]

If the object is moving, the frequency of the reflected wave will be different than the frequency of the transmitted wave. This is called the Doppler effect. The Doppler frequency shift is dependent on the velocity between the radar sensor and the object. Since the blind person is standing still, the velocity is in all scenarios 0 m/s, which simplifies the simulation. The velocity can be calculated using the Doppler shift equation:

[math]\displaystyle{ f_d = \frac{2 \cdot v f_0 }{c} }[/math]

where [math]\displaystyle{ f_d }[/math] is the Doppler shift frequency, [math]\displaystyle{ v }[/math] is the relative velocity of the object, [math]\displaystyle{ f_0 }[/math] is the transmitted frequency and [math]\displaystyle{ c }[/math] is the speed of light.

The radar simulation is based on a MATLAB radar package. The helperMFSKSystemSetup.m file is used to set up the predefined situation. The situation can be set up by giving the distance and velocity of the vehicles. The model propagates in free space. The transmitter and receiver are also defined in the setup file. Lastly, the user velocity is set to zero.

The radar sensor is demonstrated using the Multiple Frequency Shift Keying (MFSK) waveform. The MFSK waveform’s time frequency representation helps identify the vehicles. The key parameters for the FMSK waveform are sample rate, sweep bandwidth, step time, and steps per sweep. The radar sensor does not provide all these parameters. The distance and velocity are calculated using the beat frequency and phase difference and Doppler estimation. The MFSK waveform provides the range and speed estimations. If there are ghost targets, they will be filtered out later. The estimated range and speed have a small difference with the set distance and velocity.

The code filters the values if there are random outliers that the radar sensor would not be able to pick up. Speeds above 100 km/h and distances larger than 200 meters are filtered out. Also, if a road user is traveling away from the user, the road user can be filtered out. If the radar sensor measures multiple road users with similar speed, the values are averaged out. Since the radar sometimes picks up a road user multiple times because of CFAR peak detections. This also gives more accurate results. Then, with the distance and velocity of the road users, the arrival times of each road user can be calculated. The threshold time to cross the road can be set. The threshold time is compared to the arrival times. If the arrival times are larger than the threshold, the device will signal the user that it is safe to cross.

The following sections of the code are extras that would not be included in the design since the radar sensor constantly examines situations. The simulation runs only once, using a predefined situation. It sorts the arrival times and calculates the differences between them. If the difference exceeds the threshold, the corresponding position is selected, and the system signals the user when it is safe to proceed after the arrival time for that position has passed. The last part of the code is to visualise the predefined situation. Showing that the radar sensor is working and the user can safely cross the road after receiving the feedback from the device.

Additionally, if the user signals their intention to cross by using a stick, the sensor also checks if the traffic is slowing down. If the sensor detects that the first car in each lane has stopped and traffic has come to a halt in both directions (if traffic is present). It will signal that it is safe to cross, even if there are still vehicles further behind that need to slow down due to the car in front. This is achieved by monitoring the XY positions of the cars and bicycles and verifying if their speeds have decreased to zero. This is not implemented in the simulation since the simulation does not continuously sense the situation.

Physical product design

Design wearable sensor:

Function:

Analyse the traffic situation and give a signal to the bracelet of whether to cross or not.

Sensors:

• Radar
• Speaker
• Bluetooth

Requirements:

• Can not be heavy
• Camera needs to maintain the right angle
• Has to be moveable as not the same clothes/hats etc are worn through every season
• Has to view the road the user is trying to cross on both sides

Inspiration/reasoning: Two radars are needed because otherwise the one radar would have to be manually turned from left to right. Users reported not wanting the sensor in their hands, in fear of dropping it, it being stolen or because their hands are full. Attaching it to the front of the user is equally not an option as users told us it is dangerous for a blind person to look from side to side as this signals to the cars and other traffic that they can see, which means the traffic wont accommodate for them.

Placement of the sensor was decided by the final interview in which our preliminary design was discussed. The team was deciding between attaching it to the cane or having the user wear it on the shoulders. It was explained that a cane is constantly swayed from side to side and gets stuck behind surfaces, tiles, etc. and thus receives a lot of impact and movement. This would make the sensor unstable. As well as the legal protocol in the Netherlands of sticking the cane vertical and then forward when crossing roads. This would prevent the sensor from being angled in the right direction before crossing. Shoulders was said to be a good solution.

There was doubt about the aesthetics of having sensors on the shoulders, this could look silly or robotic, but a user assured us that it was a good idea. "Out of experience I will tell you that blind people can be willing to sacrifice some looks for independence, functionality and comfort." (translation of Peter 2025). And after functionality is working aesthetics can be improved.

For the clip on function it has to be sturdy so the angle of the radar stays in place, yet moveable so the user can wear it through the seasons.

A way to do this is adding multiple attachment options, a clip on works for a t-shirt but not on a sweater, pins work on a sweater but not on a jacket. By adding a clips, pins and a strap the user can adjust it to their needs.

Sketch:

Sketch of radar as a wearable

The radar sensor used in the simulation

Sketch of a possible design for the wearable radar. The top of the wearable is not reflective of what the actual product would look like due to the radar having a different area that has to not be covered and this differs per radar. For our radar it is the white area in the image on the right the sketch. It does illustrate the several ways of keeping the radar on the shoulders. A combination of pins, a band and a clip makes sure it works for all sizes and clothes.

Design feedback wristband:

Function: Letting the user know when it is safe to cross the road and when it is not.

Sensors:

• Vibration plate
• Charging port
• Mini speaker (optional but ideal)
• Some sort of Bluetooth/Wi-Fi connection

Requirements:

• Has to be chargeable
• On/off button
• Can not easily fall off, has to be easy to put on
• Can not be bulky
• Discreet and fashionable

Inspiration:

Xiaomi smartband 7

For the design a bracelet that is as flat as possible is ideal. Users have to wear it through all seasons and bulky watches do not go under all winter sweaters and jackets. Having a bulky watch can also be uncomfortable.

Because of the flat design there needs to be a flat charging option. Looking at affordability, easy to use, compactness and efficiency, the magnetic pogo pin charger is the best option. In the image on the right it can be seen in a Xiaomi smartband which is an affordable smartwatch. This charger is magnetic and thus easy for a blind person to use.

Sketch of the wristband

Product sketch: Using the previously talked about requirements this sketch was made.

The bracelet is worn using a strong magnetic strap this way it is easy to put on, no clasps needed. The charger pins are also magnetic, the charger pops right on.

The purpose of the mini speaker is for notifying the user when it is charging, being able to send a signal from a phone to let the user know where it is.

The vibration plate in the sketch is a flat rectangle but in our prototype it will be a little thicker circle as we are working with budget and short term availability.

Using a little bit of a wider band ensures the sensor will stay flat against the skin and the band will not move around too much. It is also more comfortable in daily use.

The band has a very unisex feel and can be used by young and old, men and women. Multiple colours could be sold.

Improvements:

With the speaker and a Bluetooth sensor installed the band could also have potential for further programming or to be connected to an app.

The vibration sensor could double as a navigation tool or a sonar sensor could be added to notify the user of surroundings.

Implementation

The next step is to create the prototype and implement the feedback and sensing aspects of the design. The sensing was tested as proof of concept via a simulation, while the feedback was tested with criticism from users.

The physical prototype

The prototype made can be seen in the picture next to the materials table. This prototype uses the following materials:

Materials Table

Materials	What for?	Representation in actual design:
Arduino Uno board	Sending timed signals to drive the feedback components, turning the system on and off.	The final design would have a small single board computer like a raspbery pi which would provide more compute power needed to process the sensor data, can also facilitate wireless communitation between the feedback devices.
Buttons (3x)	Turning on the system (for the user), switching between conditions.	The final design would have one button on the wristwatch, so that the user can turn the sensing device on or off whenever they want.
Vibrating Modules (2x)	Causes the main vibration function of the device, with a No-Go and Go condition accompanied with differing modes of vibration.	The final design would have these vibration modules inside the wristband as described in the product sketches. In the protoype these are laid bare so that during testing it is easier to sense if they work or change the wiring.
Speaker	Providing auditory feedback to the user, plays an upbeat sound for a Go condition and a glum sound for a No-Go condition.	The final design would have earpieces so that the user can clearly hear the audio signals. These would be completely optional should the user not find them nessecary.

Testing the modes of vibration

The physical prototype was made with two vibrating modules inside the wristband. To test the mode of vibration, four different modes were tested. The reasoning behind each of these modes is based on the literature research.

• Mode 1: Variating waiting time. The No-Go condition used long waiting times between pulses, the Go condition used close-rapid pulses. Length of the pulses is equal in both conditions.
  • The rhythm is a 100ms vibration followed by a 900ms wait in No-Go and a 100ms vibration followed by a 100ms wait in Go.
  • This mode is similar to how a rateltikker works, but in vibration format instead of auditory.
• Mode 2: Variating pulse time. The No-Go condition used long pulses, the Go condition used short pulses. Waiting time between pulses is equal in both conditions.
  • The rhythm is a 800ms vibration followed by a 100ms wait in No-Go and a 100ms vibration followed by a 100ms wait in Go.
  • The idea of this mode is that it mimics the pulses used in morse code to differentiate between different conditions.
• Mode 3: Variating intensity of pulse. The No-Go condition used low-intensity pulses, the Go condition used high-intensity pulses. Waiting time between and length of pulses is equal in both conditions.
  • The rhythm is the same as in the 1st mode but the power of vibration is 55% of the full power in No-Go and 90% of the full power in Go.
  • The idea of this mode was that a higher intensity of the pulse is easy to notice when the environment is quite busy, giving a sense of urgency via the device.
• Mode 4: Combining Mode 2 & 3.
  • The rhythm is a 800ms vibration at 55% power followed by a 100ms wait in No-Go and a 100ms vibration at 90% power followed by a 100ms wait in Go.
  • This was done to see if combining different modes of information would increase the clarity of the information relayed to the user.

We tested each mode once, without giving any instruction. Then, each mode was played again, and the tester was asked about their opinions, with a main focus on whether the No-go & Go conditions were 1. Differentiable, and 2. Clear & Readable.

The physical prototype worn, showing the vibrating modules

From this testing we concluded the following:

• Mode 1 & 2 are the most clear and differentiable to the testers. There was a preference for Mode 1, as some testers mentioned the prolonged vibrating of the No-Go condition in Mode 2 could end up being 'annoying' to the user.
• Variating the intensity of the pulse on our prototype was limited. The intensity of the pulses is controlled via the amount of voltage sent to the vibrating modules. Due to the max voltage the system could handle, the high-intensity vibration could only go so far. Testers said the low-intensity vibration was too low: it was still noticeable, but when taken into the context of a busy crossing situation, it might be easy to get used to or miss the stimulus. They also mentioned the high-intensity vibration was not high enough. Just like prior, they mentioned users might get used to the continuous stimulus, making it seem less intense than it is and causing the difference between the two conditions to become less noticeable. This is also known as habituation in the field of Psychology. This is a form of learning where the response to a certain stimulus decreases when the exposure of the stimulus is prolonged.
• From Mode 4 it was clear that the intensity did add some increased meaning for some testers, but others found it confusing as it added another mode of information to an already differing set of conditions.

Considering the preferences mentioned in testing, the problem of habituation and the familiarity of the stimulus, we opted to use Mode 1 for the prototype.

Testing the sensing

To test the sensing, a simulation was made in MATLAB to mimic how the radar sensor would function in our actual product. This was mostly described early in this project, but here is how we demonstrated it during the demo:

Visualized simulation of the radar

The code of the simulation can be found here.

Choosing mode of sound

From the research done under design ideas, and the possibilities of the prototype, we decided on the following:

• Considering our hardware options, tones we can use are between B6/C7 - F#7 (between 2000 - 3000 Hz).
• We can unfortunately not change the volume of the speaker, but ideally the volume would be around 70 dB.

From this, we have multiple options:

1. Imitating the regular sound made by guides at traffic lights. For the No-Go conditions, this would be alternating notes of x and x, with a duration of 500ms and wait time ?ms.
2. Using scales to indicate Go or No-Go. Using a major scale for Go, and a minor scale for No-Go, based on the positive and negative connotations of these scales. A negative, minor scale could evoke feelings of instability and uncertainty, therefore making it clearer to the user that it is not yet safe to cross. Using C Major (C, D, E, F, G, A, and B) and D minor (D, E, F, G, A, B♭, and C) in the 7th octave. Playing C7 to F7 in succession low to high in major as a jingle for the Go condition, and B♭6 to E7 high to low in minor as a jingle for the No-Go condition.
3. Additionally, for a more constant sound, C7, E7 and G7 (C7 Major chord) could be alternated in order for the Go condition, while B♭6, D♭7, F7 (Bb7 Minor chord) could be alternated for the No-Go condition.
4. Another simplified version, similar to the rateltikker idea, is alternating and G7 with A7 for the No-Go condition, and B♭6 with B6 for the No-Go condition.

During the demo, we intended to use option 2 as a complimentary jingle to the vibration modes. In the case of the audio needing to be supplementary to the vibration, either option 3 or 4 would be used.

If this prototype were to be transformed into a viable product, we would opt for single-use audio messages, such as 'Please wait to cross' and 'You can cross the road now!' instead of x. Audio messages would aid the user more in their learning process of understanding the modes of vibration, and would also aid them in alerting others around them auditorily that they are actively attempting to cross. This would also comply with our stakeholder research, as these type of audio messages would also relay to fellow pedestrians when it is safe to cross, and could by extension aid other visually impaired pedestrians outside the user (for example, if the user is going out with their friends who are also visually impaired, this type of auditory messaging would then allow their friends to use the product as well by extension). The single-use, meaning this sound would only be heard at the point of each condition being activated, would ensure that the user does not get a sensory overload with the addition of this audio guidance to the vibration modes. We would consider having the audio message connected to the No-Go condition to be repeated once every few seconds, but we believe that the vibration modes would already get the idea across enough. If we were to want to give the users a more streamlines learning process, we could move from audio messages, to option 4 - 3 - 2, and then completely off, in order. This way, the audio functions would go from a more literal way of giving information (audio messages literally telling the user to go or stop, and the literal copy of a rateltikker sound which should be familiar to the users) to a more symbolic idea of indication (purely giving te infomation via musical notes). In the end, we would like the choice to be up to the user itself, meaning we might give them a separate guide on how to switch between modes.

Conclusion

Our final developed tool should fulfil our aim to help people with heavy visual impairments to cross roads that lack accessibility. As it stands, our design and prototype are proof of concept for a larger idea that could help visually impaired people regain more control and confidence over their lives within traffic.

Our design mainly focuses on roads without accessibility and finding out how these type of rounds impact the experience of traffic in our user group. Using the interview questions, we found out that crossing large roads, such as our scenario road (two lane road with bike lanes on both sides, 50 km/h and no lights, zebras or anything) is indeed a hard road to cross for our user group. As mentioned, for our user group this is a difficult crossing, one that the majority would avoid. Overall, much insight was found on how visually impaired people converse with traffic, what their strengths and weaknesses are and what kinds of things they desire as additional help. We found out that for many, this experience is quite different, depending on how independent the interviewee already was on a personal level. But overall, general issues such as lack or overload of auditory stimuli, lack of knowledge and therefore difficulty of identifying certain traffic situations were reoccurring problems.

We were able to solve the issue of hard-to-notice stimuli via our bracelet. The wearable bracelet we designed will give the user feedback of whether to cross the road or not through vibrations, after the radar sensors attached on both shoulders give the signal that it is safe. This vibration method gives the users an easy to identify signal that is independent from all the auditory noise around the user. By giving the user control over the device and its' feedback modes, the central theme of increase in independence and confidence is enhanced as well.

Short recap of the use of the product: The user stands at the edge of the road parallel to the traffic, turns on the wearables. Now a vibration will start, pulses with some time apart. The radars on both shoulders scan the oncoming traffic. It looks at all cars and bicycles coming the users way and calculates their distance and speed and the users time to cross the road. When traffic has slowed down, stopped, or there is a safe gap, the device increases the speed of the vibrations, similar to the feedback from a rattling traffic light button. At the same time, the speaker can emit an audible signal to alert the user that it is safe to cross the road. Once the user has crossed or no longer needs the signal, the device can be turned off, stopping the vibrations and sound.

Overall, we believe we succeeded in creating a product that enhances the user's independence, and one that is not trying to replace exciting aids.

Discussion

Unfortunately, our prototype is not fully in line with our full vision for the final product yet. Thus, we were also not able to fully test it yet in the real traffic situation. However, considering the simulations done, general specifications of the sensors and hardware used, and insights from our interviews, it is safe to assume that our product and idea would fare well when developed more. While our simulation does work to check if it would correctly recognise the situation and say when it is safe to cross, it does use numbers under certain assumptions If this were to become a real product, the simulation would be replaced by real-world scenario testing. Additionally, there would be safety laws in place for us to create this product, so definitely more precautions would be taken as well. In future work/ further development of the product the radar could be bought or made (more budget friendly), and then more testing could be done in real traffic situations to further validate the product proposal. ​

Should the project have been continued, there are a couple things that could have also been done or even been done differently when it comes to the designing and/or making of the prototype: ​

Communication between sub-systems ​

Currently the simulation and the feedback system work separately from one another. To trigger the feedback system, a button was added to be pressed when the simulation gives the Go signal. The simulation could have been connected to the feedback system to allow a go signal in the simulation to directly trigger the feedback. This proved to difficult for the scope of this project however. ​

Additionally, instead of the current feedback system connected with wires, wireless communication between components was envisioned for the final product. As mentioned before, this would require a Raspberry Pi for Wi-Fi/Bluetooth and research and testing would have to be done about whether these protocols are reliable enough for the situation we are applying it to. ​

Full wearable system ​

The final prototype as it stands is implemented on a breadboard. If time had allowed for it, we would have liked to have the system be fully wearable. For example, the radar mounted to the shoulders communicating with the microcontroller. Then in turn, this could send signals to earpieces and the wristband to give the Go signal to the user. This would have allowed for some real world testing of the device, from which the user groups opinions of the idea in practice could have followed. Having a real-time test with users within our target-group with a better developed prototype might also show more insights in aspects of the design of the product that we might not have anticipated for. It would thus be useful in future work to do more testing in order to have a more circular design process with iterations and improvements on the way. ​

Additional wanted functions by users ​

There are many functions our user group would love to see that we simply did not focus this project on. It is not a tool that tells you where the roads are, it assumes the user is at the road, turns it on, gets feedback on whether it is safe to cross and does so. It is not a navigation tool and it is not a product that tells you about the world around you, like the seeing eye app and the sonar bracelet. Navigation and sonar location of surroundings would be good additions to have a multi purpose traffic tool. If the functions were to be extended to general navigation the vibration sensors could also be placed in a vest or belt to have 360 degrees of feedback. Or adding an additional bracelet like the N-vibe from state of the art. It might prove useful especially to add functionality for the visibility of surroundings, as it might enhance the safety and accuracy of the detection and sensor of the device. ​

Various traffic situations

This project was based around the assumption of a simple 50 km/h road with two lanes and two bike paths. This assumption is rather specific and neglects many other possible situations that occur in traffic. Ideally, our device should also be able to work in these situations. Therefore, in next iterations of the design of our product, this assumption should be more generalised so that our device is able to function in real world dynamic traffic. This would, for example, mean that the detection system would need to be more advanced to more accurately differentiate between road users and/or an algorithm/system that decides first if the road is generally safe enough to cross. As mentioned before, this could be in the form of also detecting specific road characteristics, or a more complex detection system. Additionally, the idea was that the users would cross the road in one go: according to our calculations this would in theory be safe, but would definitely need real-life testing in order to really ensure this. Reflecting on this, our feedback system could also be improved upon based on testing feedback from users when fully focussed on the idea of crossing in one go: our signals might not be as reliable in the case they might stop working or suddenly detect another vehicle while the user is already crossing in the Go-condition (this shouldn't happen, but it is imperative this is still tested for safety reasons).

Further development of the project

We encourage others to continue this project and attempt to take it a step closer to being available for real world use. Many users reported lacking such a product or one that has a navigation tool that replaces their eyes, feel free to continue our project and add this function. This user group gets asked for interviews of school projects all the time, but none of them actually become real and they are left with the same lack of good apps/devices. There is not much money in the industry and also a relatively little amount of users in the Netherlands. Continue our research and maybe sometime a full product will be available that will be helpful to visually impaired people, together we could make the change!

Appendix

Timesheets

Week	Names	Breakdown	Total hrs
Week 1	Bas Gerrits	Meeting & brainstorming (4h), SotA research (4h), working out concepts (1h), sub-problem solutions (2h), lecture (3h), tell eachother strenghts + weakness (1h)	14
	Jada van der Heijden	Meeting & brainstorming (4h), planning creation (2h), wiki cleanup (2h), SotA research (3h), lecture (3h), tell eachother strenghts + weakness (1h)	15
	Dylan Jansen	Meeting & brainstorming (4h), SotA research (3h), working out concepts (2h), looking for reference material (2h), lecture (3h), tell eachother strengths + weakness (1h)	14
	Elena Jansen	Meeting & brainstorming (4h), subject research (4h), reading previous wikis (30m), document (30min), research new topic (1h), lecture (3h), tell eachother strengths + weakness (1h)	14
	Sem Janssen	Meeting & brainstorming (4h), self balancing application research (4h), reading wikis (1h), working out ideas (1h), lecture (3h), tell eachother strengths + weakness (1h)	14
Week 2	Bas Gerrits	Meeting (2h), User research (2h), MoSCoW (2h), research sensor possibilities (1h), design (2h), design problem solving (4h), online meeting (1h)	14
	Jada van der Heijden	Meeting (2h), Editing wiki to reflect subject change (2h), Contacting institutions for user research (1h), Setting up user research (interview questions) (1h), User research (2h), online meeting (1h)	9
	Dylan Jansen	Meeting (2h), Contacting robotics lab (1h), SotA research for new subject (4h), Looking for reference material (2h), Updating Wiki (1h), Prototype research (2h), online meeting (1h)	13
	Elena Jansen	Meeting (2h), user research + make document (7h), call with Peter about interviews (1h), creating text for Peters network (30min), interview questions (2h), online meeting (1h)	13.5
	Sem Janssen	Meeting (2h), online meeting (1h), SotA research for new subject (3h), initial research for possible prototype (2h), wiki update (0.5h)	9.5
Week 3	Bas Gerrits	Meeting (3h), Ultrasound vs Lidar vs Radar (3h) Finding lidar and radar sensors (3h), Theoritical situation conditions (3h), weekend meeting (2h)	14
	Jada van der Heijden	Meeting (3h), Editing User Research wiki (4h), Refining interview questions (3h), weekend meeting (2h)	12
	Dylan Jansen	Meeting (3h), Updating Wiki (1h), Uploading and refining SotA (4h), Ideas for prototype (2h), Bill of materials for prototype (2h), Weekend meeting (2h)	14
	Elena Jansen	Meeting (3h), Making interview questions for online (2h), put user research in wiki (3h), emailing users (1h), weekend meeting (2h), initial sketches for final design (2h)	14
	Sem Janssen	Meeting (3h), Looking at different options for relaying feedback (4), weekend meeting (2h), research initial design ideas (3h)	12
Week 4	Bas Gerrits	Meeting (3h), online update meeting (1h), Understanding radar sensors (4h) Finding a suitable radar sensor (4h)	12
	Jada van der Heijden	Meeting (3h), Editing User Research wiki (5h), Refining interview questions (2h), Interviewing (1h), online update meeting (1h),	12
	Dylan Jansen	Meeting (3h), working out a potential design (3h), adding design description to wiki (2h), discussion on best solution (2h) ,online update meeting (1h), picking up components (1h)	12
	Elena Jansen	less hours due to being away all week. I will make up for it. online update meeting (1h), emailing/ texting users phone interviews (30min), reading + summarize paper (3h), mailing about face 2 face interviews (30min), catch up via notes and wiki (1h)	6
	Sem Janssen	Meeting (3h), online update meeting (1h), research ultrasound sensor (2.5h), research Doppler effect radar (1.5h), updating wiki (1h)	9
Week 5	Bas Gerrits	tutor meeting + after meeting (2h), online meeting (1h), weekend meeting (2h), Searching for suitable radar simulations packages (6h), Testing the package (4h)	15
	Jada van der Heijden	tutor meeting + after meeting (2h), online meeting (1h), gathering interview results (2h), interview thematic analysis (5h), weekend meeting (2h),	12
	Dylan Jansen	Tutor meeting + after meeting (2h), Online meeting (1h), Robotics lab visit (4h), MoSCoW requirements (2h), Simulation (3h), Weekend meeting (2h)	14
	Elena Jansen	tutor meeting + after meeting (2h), online meeting (1h), interview 1 (1h), interview 2 (2h), real life visit for interviews + preparation (6h) , analysing forms interviews (1h), updating wiki (2h), emailing with participants (30m), designing bracelet + radar wearable (+sketching) (4h), weekend meeting (2h), wiki update (30m)	23
	Sem Janssen	online meeting (1h), weekend meeting (2h), research vibrational patterns (4h), research auditory feedback (2h), write items on researched subjects (2.5h)	11.5
Week 6	Bas Gerrits	morning meeting (1h), coach + after meeting (2h), online meeting (1h), wednesday meeting (3h) Working on simulation (12h)	19
	Jada van der Heijden	morning meeting (1h), coach + after meeting (2h), adding to the wiki (6h), online meeting (1h), wednesday meeting (3h)	13
	Dylan Jansen	Morning meeting (1h), Coach + After meeting (2h), Online meeting (1h), Wednesday meeting (3h), Building/Coding prototype (5h), Adding prototype description to Wiki (2h), Trying to integrate protoype with simulation (2h)	16
	Elena Jansen	morning meeting (1h), coach + after meeting (2h), interview Peter (1h), Design sensor + sketch + wiki (4h), User research wiki finish (2h), update interview section (1h), Interviews in Appendix (1h), update state of the art (1h), check everyones wiki (1h), online meeting (1h), User interviews edit wiki (3h)	18
	Sem Janssen	morning meeting (1h), coach + after meeting (2h), online meeting (1h), wednesday meeting (3h), haptic + auditory feedback research (2h), work on simulation for presentation (2h), prototype work (2h)	13
Week 7	Bas Gerrits	meeting (4h), testing vibration modules (1h), working on presentation, presentation meeting (2h), add hours to timesheet, presentations + after meeting (3h), Finishing the simulation (6h), Writing wiki (8h), Feedback form (1h)	24
	Jada van der Heijden	meeting (4h), testing vibration modules (1h), working on presentation (2h), practice presentation (1h), update wiki (Implementation (2h), Auditory research (5h)), presentations + after meeting (3h), wiki reread and adjustments (7h), Feedback form (1h)	26
	Dylan Jansen	Meeting (4h), Testing vibration & audio modes (2h), Presentation meeting (2h), Adding presentation slide about prototype (1h), Practicing presentation (1h), Final protype testing and adjustments (2h), Presentations (3h), Wiki meeting (1h), Finalizing wiki (4h), Feedback form (1h)	21
	Elena Jansen	meeting tutors (30m) + after (2.5h), other meeting (1h), testing vibration modules (1h), presentation layout and slides (2.5h), practice presentation at home (1h), meeting wednesday (2h), update wiki (4h), write discussion + conclusion (2h), add hours to timesheet (30m), road scenario sketch (20min), presentation meeting (2h), presentations + after meeting (3h), appendix (1h), Feedback form (1h)	23.5
	Sem Janssen	Meeting (4h), testing vibration modules (2h), testing auditory feedback module (2.5h), working on presentation/simulation (5h), presentation meeting (2h), update wiki + add hours to timesheet (1.5h), presentations + after meeting (3h), Feedback form (1h)	21

Interviews

Due to privacy for our participants full interview answers and names are not included. Summaries and the interview questions are given.

Link to the forms:

https://forms.office.com/e/s9FKAxLv7R

https://www.kimbols.be/oproepjes/oproep-ervaring-van-het-verkeer-onder-slechtziende-blinde-mensen.html

Questions for both the forms and interviews done via the phone

Hallo, wat fijn dat je ons wil helpen met ons universiteit project! Deze enquête gaat over hoe blinde en slechtziende navigeren in het verkeer, specifiek tijdens het oversteken.

Algemene vragen

1. Wat is uw leeftijd?

1. Wat is uw geslacht?

1. Watvoor soort blindheid heeft u? Wat is uw visus/gezichtsscherpte?

Omgaan met slechtziendheid in het dagelijks leven

1. Hoe is normaal uw ervaring met het verkeer wanneer u te voet van A naar B gaat?

1. Zijn er situaties waarin het niet voelt alsof u helemaal zelfstandig kan zijn? (Hoe voelt u zich in het verkeer?)

1. Zijn er bepaalde soort obstakels of situaties die voor u lastiger zijn in het verkeer? Bijvoorbeeld nieuwe locaties of wegen zonder duidelijk oversteekpunt.  

Oversteken

Voor dit onderzoek zijn wij geïnteresseerd in de gedachte processen/strategieën die u heeft waar u misschien normaal niet over nadenkt. Mensen pakken immers bepaalde dingen op een andere manier aan en letten op andere dingen.

1. Hoe pakt u oversteken aan? Beschrijf welke stappen u neemt om over te steken en waar u op let als het gaat om kiezen wanneer u oversteekt. Bijvoorbeeld het luisteren naar parallel verkeer.  

1. Verschilt de aanpak voor het soort oversteekplaats? (Zebrapad, stoplicht, dorpsweg)

1. Wat zijn waarnemingen/signalen waar u vooral op let terwijl u oversteekt?

Hulpmiddelen

1. Wat voor hulpmiddelen gebruikt u voor het oversteken?

1. Zijn er dingen waarvan u het gevoel heeft dat u mist? Zijn er dingen die u niet kan waarnemen met de huidige hulpmiddelen die u heeft?          

Scenario

Voor ons project werken wij met een scenario; Neem een 50 k/m weg waar regelmatig auto's rijden, zonder zebrapad of stoplicht als scenario. Neem aan dat u op weg bent naar bijvoorbeeld een supermarkt, en dat uw navigatie/route u over deze weg heen stuurt.

1. Wat zou u doen in dit scenario? Waarom zou u deze weg wel of niet oversteken?

1. Op een schaal van 1/5, hoe zelfstandig kan u op dit moment een weg zoals deze oversteken?

1. Op een schaal van 1/5, hoe veilig zou u zich voelen als u een weg zoals deze (zelf) moet oversteken?

1. Als u zelf al hulpmiddelen gebruikt, zouden deze helpen in deze situatie?

Overig (Design)

Wij zijn bezig met het ontwerpen van een hulpmiddel dat kan helpen met het oversteken van wegen zoals in het scenario. Het hoofddoel hierbij is dat het een extra hulpmiddel is dat extra zekerheid, zelfstandigheid en gevoel van veiligheid kan aanbieden.

1. Waar zou het dragen van een sensor comfortabel voor u zijn?  
2. Hoeveel controle zou u willen hebben op het apparaat? Zou het meer een soort automatische sensor moeten zijn (minimale controle) of een zelf te bedienen scanner (maximale controle)?  

1. Maakt het een verschil voor u als het apparaat zichtbaar is voor anderen?

1. Heeft u liever dat een hulpmiddel informatie aan u geeft door middel van geluid of door middel van gevoel? Wat is het verschil hierin voor u?

Summaries phone/ in real life:

These are short summaries of how different participants gave us different insights.

The answers to the forms are not summarised here, insights and answers to these can be found in the interview section of the wiki.

P1: 70 year old man, full blindness, he had tested a lot of products currently on the market as well as school projects similar to ours, vibration sensors, navigation tools, traffic help. Despite him being 70 he had a lot of experience with technology and didn't mind trying new tech solutions. His stories about these tools gave us some new state of the art as well as wants and needs in products like these.

Peter: Peter is a system architect and advocate for visually impaired. He himself is also blind (0.5% with only central vision), he agreed to do interviews with us and even put out a message to his network asking others to help us with our project. Through this we got our phone interviews. We did called two times, once before we had our product and once after our plan was nearly done. The second call the interview questions given above were not used. This interview was un-structured and consisted of catching him up on our work and proposing the product. This was especially useful as it was used to validate decisions and solve final dilemmas on the design and function.

P3: (irl) This interview lead us to create a more precise user group. This older woman has ushers and is blind with decreasing hearing. She is not an active independent participant in traffic and is not interested in any tools and gadgets. So while she fit our initial user group she is not interested in our product or applicable to the majority of our interview questions.

P4: This woman is an artist and has no vision left. She loves to go on walks in her neighbourhood and has a set route of 6km, but on lesser known roads she would be very interested in our product. She gave valuable insights on battery life, wanting an audio to learn but haptic to get feedback, in what situations she would use it etc. She has no interest in using any tools on the routes she knows, she likes walking by herself without help, unless she gets lost then her neighbours step in. The tool would really be for new roads or roads she avoids. If we were to add extra functions she requested the device recognise a road she has to cross is coming.

P5: Woman in her 40s. Likes to go on walks with her friends, who are also visually impaired. Mentioned using parallel traffic in order to know where roads, traffic lights and general crossings are. Mentioned she used a testing device for traffic before, but said that while she was walking aside the road that it would keep making sounds and found this really annoying. She gave a lot of examples on different type of road situations and how she handled it, such as mentioning that it can be unclear if a road has a separate, non zebra crossing marked bike trail after the road. Overall she seemed confident in traffic, with a lot of pre-set strategies, but was very open and encouraging to try new technologies. She also mentioned the idea of using vibration and sound in combination, in order to also help her visually impaired friends.

Our initial subject

In this wiki we have included some dead-ends that provided us with insights, not all work done was relevant to include. Certain papers studied were chosen not to include, some calculations and sensors, all research done on our previous subject the self balancing robot was not included. While we thought the self balancing technology was really interesting the main reason it was discontinued was the lack of a user group and goal. There are many self balancing robots out there, from huge companies and at home projects. For a cheaper smaller self balancing robot it was hard to find an interesting objective/ problem statement. For our current project all of us felt a lot of passion so after the first tutor meeting the subject was changed.