PRE2024 3 Group18: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Line 88: Line 88:


=== Problem Statement ===
=== Problem Statement ===
When considering automated deliveries using robots, there are two main issues. First off, navigating tight spaces like corridors can be difficult for bulky, four wheeled delivery robots. A self-balancing robot can drive with just 2 wheels and therefore be built more compact allowing it to move in more complicated environments. Additionally, a problem current delivery robots face is the risk of tipping over, getting them stuck. A human has to intervene in order to put them back on track. A self-balancing robot can keep itself from tipping and be more autonomous.  
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.  


'''Objectives:'''
'''Main objectives:'''
*Design robot capable of holding/handling a small package
*The design should be able to aid the user in crossing a road, regardless of external sensory cues already put in place


*Robot should be able to balance itself on two wheels
*The design must have audible, or otherwise noticeable, alerts for the user, that are easily understood by said user


*Robot should be able to deliver packages by being able to move in different directions
*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
*Make robot look a bit human (User research)
**Ex. hidden in the user's clothing
An extended list of all features can be found at ''MoScoW part.''


==Target Group==
==Target Group==
Line 104: Line 105:
Primary Users:
Primary Users:


*Package delivery companies: would reduce cost of deliveries and allow delivery robots to complete more complicated deliveries
*People with affected vision that would have sizeable trouble navigating traffic independently: ranging from visually impaired to fully blind
 
*Customers ordering packages: would benefit from automated deliveries
 
*Stores or warehouses: could move around packages/items


Secondary Users:  
Secondary Users:  


*Pedestrians: robot must consider other people when moving
*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.
 
 
'''''What Do They Require?'''''
 
Package delivery companies: Move around without falling over or dropping package, sensor that detects objects to not bump into them, move in tight spaces.
 
Customers: Undamaged package, schedule deliveries more conveniently, robots can be more appealing if it appears human-like  


Stores or warehouses: Navigate store aisles, smooth and stable movement


Pedestrians: Robot should avoid people and pedestrians should not be too bothered by the robot
'''''What Do They Require?'''''


== State of the Art Literature Research==
== State of the Art Literature Research==
Line 164: Line 153:
|-
|-
|Jada van der Heijden
|Jada van der Heijden
|Meeting (2h), Editing wiki to reflect subject change (1h), Contacting institutions for user research (1h), Setting up user research (interview questions) (2h), User research (2h)
|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
|7
|-
|-

Revision as of 16:48, 23 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

Project Planning
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)

Project Roles
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.

Target Group

Who Are the Users?

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.


What Do They Require?

State of the Art Literature Research

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

  1. The robot should be capable of holding/handling a small package
  2. The robot should be able to balance itself on two wheels
  3. The robot should be able to deliver packages by being able to move in different directions
    1. Specify:
  4. Robot is well built (stable)
  5. The robot uses sensors and motors in a meaningful way
  6. The robot has a clear USEr link
    1. Specify: The robot should be of use to the user group and interact with the world and that user group in a meaningful way