Weekly notes

Meeting 1

• Er is wel budget. Om onderdelen te krijgen, moet je wel even duidelijk maken waarom je het nodig hebt (mooi praatje).
• Een idee om minder aandacht aan de constructie van de robot zelf te hoeven besteden is bijvoorbeeld uit lego lopende spinnen te maken.
• Als het meer gaat om de interactie, hoe belangrijk is dan het uiterlijk?

Doelen van de communicatie:

• Wat voor soort interactie willen we?
• Geruststellen / Spraakverbinding met hulpverlener

Andere vragen:

• Hoe autonoom willen we de robot? Kan bijvoorbeeld ook bestuurd worden door iemand met een camera.
• In dat geval speciale personen inzetten om met de robot de omgeving te analyseren. Die personen kunnen het goed inschatten.
• Warmte sensoren om personen te vinden
• Hoe volgt hij zijn pad? Hoe navigeert hij in een disaster area, want je kan hem geen route meegeven.
• Shared control

Nu 2 doelen:

• Het vinden van mensen in rampgebieden
• De interactie tussen robot en mensen

Kiezen wat haalbaar is in 7 weken.

Meeting 2

Persona:

• niet specifiek profiel voor een slachtoffer
  • pak een gemiddelde leeftijd, algemene behoeftes van een slachtoffer.
• Goed nadenken over welke verschillende invalshoeken een rol spelen
  • kijken naar literatuur, bijvoorbeeld over ervaringen van slachtoffers.
• Hulpverleners, nu iemand van de brandweer. Misschien ook nog een medisch persoon.
  • kan ook weer in de literatuur kijken

Design:

• hoe specifiek het wordt ligt aan onszelf.

Users:

• user analyse gekoppeld aan user needs
• kijken naar de wensen en problemen van onze users, dit ook meenemen in ons design.

• Probleem nog verder uitleggen
• systeem eisen
• requirements → die volgen uit wat de stakeholders nodig hebben.

Onze functies die we nu hebben uitgezocht nog meer focussen op de user. We zijn nu eigenlijk twee stappen tegelijk aan doen. We zijn al bezig met uitzoeken hoe we dus bijvoorbeeld slachtoffers moeten benaderen , met welk licht, etc. Maar we moeten eerst dus requirements stellen, om te kijken welke functies we willen. → we denken in feite al te veel vooruit.

To do: Eisen stellen, zodat we ons kunnen focussen. De wiki meer analytisch maken.

Conclusie: De eisen moeten we eerst algemeen opstellen vanuit de users, en vanuit daar kijken op welke eisen en functies we dus willen focussen. (voor ons dus uiterlijk, benadering etc.) Daarna kunnen we dus kijken naar welke functies me moeten uitkijken, wat we moeten uitzoeken in de literatuur etc.

Meeting 3

Requirements:

• Moeten ze nog SMART gedefinieerd worden?
  • Requirement moet inderdaad SMART zijn. We moeten duidelijker specificeren zodat het echt duidelijk is.
  • Lap tekst is goed om onze requirements te onderbouwen. Het is nuttig, maar nog niet heel overzichtelijk als je alleen naar de dikgedrukte delen kijkt.
  • Marges en waarden geven aan requirements, voor bijvoorbeeld requirement van tiny.
• Voor ons hebben we dus het onderscheid gemaakt in requirements van met welke we gaan werken en welke niet. --> Dit nog ergens aangeven??

Design:

• Mogen we al beginnen met een brainstorm sessie nu we onze requirements duidelijk hebben?
• Nadenken over welke eisen we willen stellen voor het design in verband met de requirements.
• Type communicatie?
• Moeten we vanuit de literatuurstudie
  • Literatuurstudie kan helpen om te weten welke manier het meest bijdragen aan geruststelling van de slachtoffers. Het is daarna wel aan ons om te kijken hoe we die manier dan toepassen.
  • Niet te direct denken zoals bv 'we willen beeldscherm' , maar gaat makkelijk kapot dus doen we niet. Nee dan --> kijken aan welke eisen het beeldscherm moet voldoen, zoeken ernaar en dan pas realiseren. Zo alles aanpakken.

Focus:

• Vooral psychologisch aspect
• Geruststellen
  • communicatie
  • approach
  • uiterlijk

Conclusie:

• Requirements nog SMART uitwerken.
• Onderzoeken en onze specifieke requirements uitwerken in combinatie.
• De drie aspecten van geruststelling verder uitwerken.

Meeting 3a

Nonverbal communication:

• Verbal communication is the task of the aid worker, we can't do much about it (Watcha gonna do bout it)
• SOTA, we want to focus on the part that has the least research in rescue events.

Safety:

• We are not gonna focus on this
• SOTA, we want to focus on the part that has the least research

Efficiency:

• We are not gonna focus on this
• SOTA, we want to focus on the part that has the least research

Ready for use:

User friendly:

• We do not focus on this, because this does not have a high enough relevance.

Meeting 4

• Slachtoffers zitten niet op het puin maar eronder, ze zitten in onmogelijke situaties. dus is een scherm zichtbaar? kun je dichtbij de slachtoffers komen?

hoe kun je erachter komen hoe nuttig een scherm is in een noodgebied? → literatuur studie, meer onderzoek, competities voor rescue robots (Robot League) gebruiken voor voorkennis

• Concrete manier met pijp om een robot IN het puin te kruipen. Manier van hoe reddingswerkers tegen het probleem aankijken. → passen de wielen in zo’n buis?

• Wat wordt jullie eindproduct? focussen op psychologisch effect en non-verbale communicatie. onderzoeken naar het uiterlijk of niet? hoe komt het scherm eruit zien? is dat relevant? Focussen we nu op uiterlijk (scherm?) of op het geruststellen van slachtoffers.

• Het is niet de bedoeling om te pushen of om te zeggen wat wij moeten doen, maar om feedback te geven. Wat is nu precies jullie focus? En antwoord te kunnen geven op de ‘waarom’ vraag. Ga terug naar wat je uiteindelijk wilde, kijk wat je daarvan nog kunt doen.

• Uiteindelijk wil je op iets kunnen inzoomen, specifiek uitwerken en dat helemaal te kunnen onderbouwen. Denk vooral na over welke beslissing je neemt en WAAROM.