PRE2024 3 Group18: Difference between revisions
Line 175: | Line 175: | ||
== Evaluation == | == Evaluation == | ||
Sem | |||
== Conclusion == | == Conclusion == |
Revision as of 11:58, 24 February 2025
Members
Name | Student Number | Division |
---|---|---|
Bas Gerrits | 1747371 | B |
Jada van der Heijden | 1756710 | BPT |
Dylan Jansen | 1485423 | B |
Elena Jansen | 1803654 | B |
Sem Janssen | 1747290 | B |
Approach, milestones and deliverables
Week | Milestones |
---|---|
Week 1 | Project orientation, brainstorming, defining deliverables and limitations, SotA research |
Week 2 | Deepened SotA research
Identifying and determining specifications (hardware, software, design (MoSCoW Prioritization)), UX Design: User research Create bill of materials |
Week 3 | Prototyping cycle: building and mock-ups
Order needed items UX Design: User Research Wiki: Specifications, Functionalities (sensors/motors used) |
Week 4 | Prototyping cycle
Finish balancing |
Week 5 | Evaluating and refining final design |
Week 6 | Demo/scenario testing, fine-tuning
Wiki: Testing results |
Week 7 | Presentation/demo preperations
Wiki: Finalize and improve (ex. Conclusion, Future work, Discussion) |
Name | Responsibilities |
---|---|
Bas Gerrits | Arduino control |
Jada van der Heijden | Administration, UX design, Wiki |
Dylan Jansen | (Opties) Code, Electronics ,CAD model, Construction, Control documentation |
Elena Jansen | Designing |
Sem Janssen | Hardware |
Problem statement and objectives
Problem Statement
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 system/robot/design that will aid them in most traffic situations to cross roads, even with the lack of external sensory cues.
Main objectives:
- The design should be able to aid the user in crossing a road, regardless of external sensory cues already put in place
- The design must have audible, or otherwise noticeable, alerts for the user, that are easily understood by said user
- The design must have a reliable detection system
- The design must be 'hidden': it should not disrupt the user's QoL and could be barely noticeable as technology
- Ex. hidden in the user's clothing
An extended list of all features can be found at MoScoW part.
User Experience Design 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 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.
USEr research
Target Group
Primary Users:
- People with affected vision that would have sizeable trouble navigating traffic independently: ranging from visually impaired to fully blind
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
What Do They Require?
!!From user research we will probably find that most blind people are elderly. We can conclude somewhere here then that we will focus on elderly people, and that that will have implications for the USEr aspects of the design as elderly people are notorious for interacting and responding differently to technology.!!
Society
How is the user group situated in society? How would society benifit from our design?
Enterprise
What businesses and companies are connected to this issue?
Stakeholder Analysis
To come in closer contact with our target groups, we reached out to multiple associations via mail. The following questions were asked (in Dutch), as a ways to gather preliminary information:
- Wat voor hulpmiddelen worden het vaakst gebruikt door slechtziende/blinde mensen?
- Welke aspecten van uw hulpmiddel vind u fijn, en wat vind u hinderen?
- Zijn er dingen waarvan u het gevoel heeft dat u die mist, en mogelijk extra assistentie van zou willen hebben (bijv. via een fysiek hulpmiddel?)
- Hoe navigeert u normaal het verkeer?
- Wat voor stappen neemt u als het gaat om de weg oversteken? Denk vooral aan of er verschil is in aanpak bij verschillende soorten oversteekplaatsen?
- Bijv. oversteekplaatsen met stoplicht en geluid, zebrapad, of een willekeurige weg zonder haptische of auditorische aspecten
- Wat voor stappen neemt u als het gaat om de weg oversteken? Denk vooral aan of er verschil is in aanpak bij verschillende soorten oversteekplaatsen?
- Hoe ervaart u het verkeer nu, zijn er dingen die u wat makkelijker afgaan, of dingen waar u vaak moeite mee heeft?
- Als het gaat om hulpmiddelen, legt u meer waarde aan haptische middelen (iets wat je vast kan houden, bijv. blindegeleidestok) of auditorische middelen (stemgeluid, piepjes) bij het verkeer?
Following these questions, we got answers from multiple associations that were able to give us additional information.
From this, we were able to setup interviews via x,y,z.
Additionally, via personal contacts, we were also able to visit an art workshop at StudioXplo on the 7th of February meant for the visually impaired. We were able to conduct some interviews with the intended users on site.
State of the Art Literature Research
Existing visually-impaired aiding materials
About road aids
Creating the solution
MosCoW Requirements
Prototypes/Design
Here we will put some different versions of a design of what we think will be a solution. We can pick one to work on.
Idea 1
Idea 2
Idea 3
Implementation
Evaluation
Sem
Conclusion
Discussion
Appendix
Timesheets
Week | Names | Breakdown | Total hrs |
---|---|---|---|
Week 1 | Bas Gerrits | Meeting & brainstorming (3h), SotA research (4h), working out concepts (1h), sub-problem solutions (2h) | 10 |
Jada van der Heijden | Meeting & brainstorming (3h), planning creation (2h), wiki cleanup (2h), SotA research (3h) | 10 | |
Dylan Jansen | Meeting & brainstorming (3h), SotA research (3h), working out concepts (2h), looking for reference material (2h) | 10 | |
Elena Jansen | Meeting & brainstorming (3h) | ||
Sem Janssen | Meeting & brainstorming (3h) | ||
Week 2 | Bas Gerrits | Meeting (2h) | |
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) | 7 | |
Dylan Jansen | Meeting (2h) | ||
Elena Jansen | Meeting (2h) | ||
Sem Janssen | Meeting (2h) | ||
Week 3 | Bas Gerrits | ||
Jada van der Heijden | |||
Dylan Jansen | |||
Elena Jansen | |||
Sem Janssen | |||
Week 4 | Bas Gerrits | ||
Jada van der Heijden | |||
Dylan Jansen | |||
Elena Jansen | |||
Sem Janssen | |||
Week 5 | Bas Gerrits | ||
Jada van der Heijden | |||
Dylan Jansen | |||
Elena Jansen | |||
Sem Janssen | |||
Week 6 | Bas Gerrits | ||
Jada van der Heijden | |||
Dylan Jansen | |||
Elena Jansen | |||
Sem Janssen | |||
Week 7 | Bas Gerrits | ||
Jada van der Heijden | |||
Dylan Jansen | |||
Elena Jansen | |||
Sem Janssen |
140 pp, 700 total, ~20 hrs a week
Backlog
What our robot should have, and what we want it to be able to do
- The robot should be capable of holding/handling a small package
- The robot should be able to balance itself on two wheels
- The robot should be able to deliver packages by being able to move in different directions
- Specify:
- Robot is well built (stable)
- The robot uses sensors and motors in a meaningful way
- The robot has a clear USEr link
- Specify: The robot should be of use to the user group and interact with the world and that user group in a meaningful way