Week 4,5,6: Designen: Difference between revisions
(→Eurest) |
No edit summary |
||
(58 intermediate revisions by 4 users not shown) | |||
Line 5: | Line 5: | ||
Een van de eerste beslissingen die wij hebben genomen was dat wij moesten kiezen tussen bijvoorbeeld een rijdende robot of een drone. De reden dat wij niet voor de drone hebben gekozen is dat deze veel lawaai maken en dus de rust in het Metaforum kunnen verstoren. Bovendien hebben deze voertuigen onnodig veel energie nodig. Een ander idee was om de robot aan een rails in het plafond te hangen zodat bezoekers van het Metaforum minder last hebben van de robot. Dit zou echter veel problemen veroorzaken met betrekking tot de infrastructuur. Naast dat dit systeem aangelegd zou moeten worden en dit afdoet aan het architectonische ontwerp van het Metaforum en de robot ook verschillende verdiepingen zou moeten begaan, leent het dak van Metaforum zich niet goed voor een rails aan het plafond. Er zitten namelijk veel hoogteverschillen in het dak. Daarnaast zou een systeem met rails veroorzaken dat de robot alleen op specifieke plekken kan komen. Om deze redenen hebben wij dus gekozen voor een rijdende robot. | Een van de eerste beslissingen die wij hebben genomen was dat wij moesten kiezen tussen bijvoorbeeld een rijdende robot of een drone. De reden dat wij niet voor de drone hebben gekozen is dat deze veel lawaai maken en dus de rust in het Metaforum kunnen verstoren. Bovendien hebben deze voertuigen onnodig veel energie nodig. Een ander idee was om de robot aan een rails in het plafond te hangen zodat bezoekers van het Metaforum minder last hebben van de robot. Dit zou echter veel problemen veroorzaken met betrekking tot de infrastructuur. Naast dat dit systeem aangelegd zou moeten worden en dit afdoet aan het architectonische ontwerp van het Metaforum en de robot ook verschillende verdiepingen zou moeten begaan, leent het dak van Metaforum zich niet goed voor een rails aan het plafond. Er zitten namelijk veel hoogteverschillen in het dak. Daarnaast zou een systeem met rails veroorzaken dat de robot alleen op specifieke plekken kan komen. Om deze redenen hebben wij dus gekozen voor een rijdende robot. | ||
===Vorm=== | ===Vorm=== | ||
Uit de enquête bleek dat mensen voorkeur hebben voor een niet | Uit de enquête bleek dat mensen voorkeur hebben voor een niet humanoïde robot. Om deze reden en hebben wij voor de vorm van de robot gekozen voor een balk. Omdat wij gaan werken met een systeem met kastjes (zie privacy) is dit de meest efficiënte vorm. Des te kleiner de robot, des te minder last mensen hier van hebben. Daarentegen is een grote robot weer opvallender wat ook voordelen heeft. Mensen hebben een grote voorkeur voor een robot van ongeveer 80cm. Dit is dus het formaat waar we naar gaan streven. Dit zal echter afgewogen moeten worden tegen onder andere de omgevingen waarin de robot zou moeten kunnen rijden en de hoeveelheid voedsel die in dit geval mee genomen kan worden. | ||
===Inlogsysteem=== | ===Inlogsysteem=== | ||
Bovenop de robot komt een schermpje waar mensen op kunnen inloggen of een systeem waar mensen hun campuskaart voor kunnen houden. Zie Veiligheid voor een uitgebreide uitleg over dit onderwerp. | Bovenop de robot komt een schermpje waar mensen op kunnen inloggen of een systeem waar mensen hun campuskaart voor kunnen houden. Zie [[#Veiligheid|Veiligheid]] voor een uitgebreide uitleg over dit onderwerp. | ||
===Extra's=== | ===Extra's=== | ||
Uit de enquêtes bleek dat veel mensen nog zaten met het probleem dat afval nog steeds weggebracht moest worden. Dit is ook de reden dat voedsel uit de kantine verboden is in de bibliotheek. Hierom overwegen wij ook een prullenbak bij de robot te voegen waar mensen hun afval direct kwijt kunnen. | Uit de enquêtes bleek dat veel mensen nog zaten met het probleem dat afval nog steeds weggebracht moest worden. Dit is ook de reden dat voedsel uit de kantine verboden is in de bibliotheek. Hierom overwegen wij ook een prullenbak bij de robot te voegen waar mensen hun afval direct kwijt kunnen. | ||
Line 15: | Line 16: | ||
= Wettelijke eisen = | = Wettelijke eisen = | ||
Het eerste belangrijke aspect waar in het design rekening mee moet worden gehouden zijn wettelijke eisen. Deze staan vermeld in de Nederlandse Voedselveiligheidseisen. Deze eisen staan overzichtelijk vermeld in een document van ServSafe International. Sommige van deze wetten zijn van belang bij het ontwerpen van de robot. Deze hebben voornamelijk te maken met het vervoer en de temperatuur van het voedsel. Hieronder zijn de belangrijkste regels vermeld onder het hoofdstuk waarin zij in dit document te vinden zijn. | Het eerste belangrijke aspect waar in het design rekening mee moet worden gehouden zijn wettelijke eisen. Deze staan vermeld in de Nederlandse Voedselveiligheidseisen. Deze eisen staan overzichtelijk vermeld in een document van ServSafe International. <ref name="NVVE"> ServSafe International (2012). 'Nederlansde Voedselveiligheidsvoorschriften'.</ref> Sommige van deze wetten zijn van belang bij het ontwerpen van de robot. Deze hebben voornamelijk te maken met het vervoer en de temperatuur van het voedsel. Hieronder zijn de belangrijkste regels vermeld onder het hoofdstuk waarin zij in dit document te vinden zijn. | ||
==Nederlandse Voedselveiligheidseisen== | ==Nederlandse Voedselveiligheidseisen== | ||
*Voedsel met verhoogd microbiologisch risico is het hoogst tussen de 7 en 60 graden | *Voedsel met verhoogd microbiologisch risico is het hoogst tussen de 7 en 60 graden Celsius. Dit wordt de temperaturengevarenzone genoemd, omdat pathogenen in dit temperatuurbereik groeien. | ||
*Vooral gebruikt: Kerntemperatuurthermometer (verplicht voor temperatuurregistratie) | *Vooral gebruikt: Kerntemperatuurthermometer (verplicht voor temperatuurregistratie) | ||
*Verboden: Infraroodthermometer. | *Verboden: Infraroodthermometer. | ||
*Warme producten worden bij een temperatuur van ten minste 60 graden Celsius geserveerd. | *Warme producten worden bij een temperatuur van ten minste 60 graden Celsius geserveerd. | ||
*Koude producten worden bij een temperatuur van maximaal 7 graden Celsius geserveerd. | *Koude producten worden bij een temperatuur van maximaal 7 graden Celsius geserveerd. | ||
*In bediende gekoelde presentaties mogen producten die geheel van de gast zijn afgeschermd tot 2 dagen worden bewaard, waarbij de eerste uitgiftedag niet meetelt. Met uitzondering van risicovolle producten, deze mogen slechts 1 dag worden verstrekt. Warme producten mogen maximaal gedurende een hele dag worden aangeboden in de bain marie. Mag tot 2 uur worden bewaard mits het voedsel: op 7 graden Celcius is voor het uit de | *In bediende gekoelde presentaties mogen producten die geheel van de gast zijn afgeschermd tot 2 dagen worden bewaard, waarbij de eerste uitgiftedag niet meetelt. Met uitzondering van risicovolle producten, deze mogen slechts 1 dag worden verstrekt. Warme producten mogen maximaal gedurende een hele dag worden aangeboden in de bain marie. Mag tot 2 uur worden bewaard mits het voedsel: op 7 graden Celcius is voor het uit de koelruimte wordt gehaald, een etiket heeft met verwijderingstijd/weggooitijd. | ||
*Restaurant (HORECA): Na bereiding moeten de producten gekoeld worden bij 7 graden Celsius of kouden. De 2-uursborging moet altijd aanvangen bij een temperatuur van 7 graden Celsius of kouder. Zelfbereide producten mogen ten hoogste 1 dag na bereiding worden gepresenteerd. Zelfbereide producten worden bijvoorbeeld geborgd met behulp van kaartjes op de (om)verpakking met daarop een tijdstip of codering. Verpakte producten moeten onuitwisbaar worden gemerkt. Onder borging gepresenteerde producten mogen niet uit het buffet gehaald worden om later nogmaals te worden gepresenteerd. Producten die nog in de terugkoelfase zitten en producten die na bereiding direct ongekoeld worden gepresenteerd hoeven niet aan de temperatuureis te voldoen. | *Restaurant (HORECA): Na bereiding moeten de producten gekoeld worden bij 7 graden Celsius of kouden. De 2-uursborging moet altijd aanvangen bij een temperatuur van 7 graden Celsius of kouder. Zelfbereide producten mogen ten hoogste 1 dag na bereiding worden gepresenteerd. Zelfbereide producten worden bijvoorbeeld geborgd met behulp van kaartjes op de (om)verpakking met daarop een tijdstip of codering. Verpakte producten moeten onuitwisbaar worden gemerkt. Onder borging gepresenteerde producten mogen niet uit het buffet gehaald worden om later nogmaals te worden gepresenteerd. Producten die nog in de terugkoelfase zitten en producten die na bereiding direct ongekoeld worden gepresenteerd hoeven niet aan de temperatuureis te voldoen. | ||
*Registratie (tenzij presentatie korter is dan 2 uur en restanten worden weggegooid) moet aantoonbaar zijn: datum, naam product, aantal of hoeveelheid product, begin en/of eindtijd, aantal of hoeveelheid derving, naam medewerker. | *Registratie (tenzij presentatie korter is dan 2 uur en restanten worden weggegooid) moet aantoonbaar zijn: datum, naam product, aantal of hoeveelheid product, begin en/of eindtijd, aantal of hoeveelheid derving, naam medewerker. | ||
Line 39: | Line 40: | ||
==Conclusie== | ==Conclusie== | ||
Belangrijk is dus dat in de bezorgrobot de temperatuur gecontroleerd kan worden. Warme producten moeten bij een temperatuur van minimaal 60 graden bij de gebruiker bezorgd worden, koude producten bij maximaal 7 graden.Voor het meten van deze temperatuur is een infraroodthemperatuurmeter verboden. Het voedsel wordt bezorgd door heel Metaforum dus moet rekening gehouden worden met verontreiniging. Na elke levering moeten de lades schoongemaakt worden, daarnaast moeten verschillende voedingsmiddelen gescheiden van elkaar vervoerd worden. | Belangrijk is dus dat in de bezorgrobot de temperatuur gecontroleerd kan worden. Warme producten moeten bij een temperatuur van minimaal 60 graden bij de gebruiker bezorgd worden, koude producten bij maximaal 7 graden.Voor het meten van deze temperatuur is een infraroodthemperatuurmeter verboden. Het voedsel wordt bezorgd door heel Metaforum dus moet rekening gehouden worden met verontreiniging. Na elke levering moeten de lades schoongemaakt worden, daarnaast moeten verschillende voedingsmiddelen gescheiden van elkaar vervoerd worden. | ||
=USE aspecten= | =USE aspecten= | ||
==User enquête== | ==User enquête== | ||
Line 69: | Line 71: | ||
Met Richard Cornelissen hebben wij ook gesproken over de grootte die de robot zou moeten krijgen. Het liefst zou hij de robot zo groot mogelijk willen hebben. Cornelissen noemt verschillende voordelen van dit idee. Ten eerste komt het de bekendheid van Eurest ten goede. Daarnaast kan er op deze manier zo veel mogelijk voedsel vervoerd worden en dus zo veel mogelijk klanten bediend worden. Ten slotte noemt Cornelissen de veiligheid. Een grotere robot springt meer in het oog waardoor er minder kans is op ongelukken met omstanders, aangezien deze de robot zien aankomen. | Met Richard Cornelissen hebben wij ook gesproken over de grootte die de robot zou moeten krijgen. Het liefst zou hij de robot zo groot mogelijk willen hebben. Cornelissen noemt verschillende voordelen van dit idee. Ten eerste komt het de bekendheid van Eurest ten goede. Daarnaast kan er op deze manier zo veel mogelijk voedsel vervoerd worden en dus zo veel mogelijk klanten bediend worden. Ten slotte noemt Cornelissen de veiligheid. Een grotere robot springt meer in het oog waardoor er minder kans is op ongelukken met omstanders, aangezien deze de robot zien aankomen. | ||
==Interview medewerkers | ==Interview medewerkers Eurest== | ||
===Planning=== | ===Planning=== | ||
Duidelijke uitleg idee. | Duidelijke uitleg idee. | ||
Line 83: | Line 85: | ||
Wat vindt u belangrijk aan uw taak dat de robot ook zou moeten kunnen? (robot – klant) | Wat vindt u belangrijk aan uw taak dat de robot ook zou moeten kunnen? (robot – klant) | ||
===Interview | ===Interview medewerkers (oa Lindy van Rooij)=== | ||
De eerste reacties van medewerkers op dit idee zijn positief. Zo wordt er ‘Super!’ en ‘Geweldig!’ geroepen. Ook vanuit medewerkers van Eurest is er dus zeker interesse in het gebruiken van een bezorgrobot. | De eerste reacties van medewerkers op dit idee zijn positief. Zo wordt er ‘Super!’ en ‘Geweldig!’ geroepen. Ook vanuit medewerkers van Eurest is er dus zeker interesse in het gebruiken van een bezorgrobot. | ||
Line 93: | Line 95: | ||
Naast een prullenbak heeft het personeel een voorkeur voor kastjes boven lades. Naast dat dit veel ruimte bespaart, is dit ook makkelijker schoon te maken. Ten slotte zouden medewerkers graag zien dat de robot in staat is door middel van spraak (en indien mogelijk spraakherkenning) te communiceren met de klanten om de robot klantvriendelijker te maken. Zo zou de robot kunnen zeggen ‘Hier is uw bestelling. Eet smakelijk!’ als deze het voedsel aflevert. | Naast een prullenbak heeft het personeel een voorkeur voor kastjes boven lades. Naast dat dit veel ruimte bespaart, is dit ook makkelijker schoon te maken. Ten slotte zouden medewerkers graag zien dat de robot in staat is door middel van spraak (en indien mogelijk spraakherkenning) te communiceren met de klanten om de robot klantvriendelijker te maken. Zo zou de robot kunnen zeggen ‘Hier is uw bestelling. Eet smakelijk!’ als deze het voedsel aflevert. | ||
Tijdens het interview met de medewerkers hebben wij het ook over de lift gehad. Dit heeft als reden dat de liften in Metaforum rond de pauze op dit moment al erg druk zijn. Een robot die mede | Tijdens het interview met de medewerkers hebben wij het ook over de lift gehad. Dit heeft als reden dat de liften in Metaforum rond de pauze op dit moment al erg druk zijn. Een robot die mede gebruik zou gaan maken van deze liften zou dit probleem alleen maar verergeren. Een oplossing op dit probleem is de dienstlift van Eurest. Deze gaat vanaf de keuken van Eurest naar de eerste verdieping. Volgens het personeel is het mogelijk om deze te gebruiken voor de robot, al zou deze wel aangepast moeten worden. Op dit moment kan de lift namelijk alleen bediend worden door medewerkers. Wel zou er genoeg ruimte voor de robot in deze lift en in de keuken moeten zijn. Tijdens dit gesprek hebben wij ook de kans gehad om de maten van de lift op te nemen. Deze zijn hieronder te vinden. | ||
Het enthousiasme van het personeel bleek ook uit de afronding van het gesprek. Er was namelijk veel interesse om met verschillende medewerkers in een pauze nog eens te brainstormen. Mochten hier nog resultaten uit komen, zouden deze naar ons gemaild worden. Daarnaast zou het personeel graag de simulatie willen zien. | Het enthousiasme van het personeel bleek ook uit de afronding van het gesprek. Er was namelijk veel interesse om met verschillende medewerkers in een pauze nog eens te brainstormen. Mochten hier nog resultaten uit komen, zouden deze naar ons gemaild worden. Daarnaast zou het personeel graag de simulatie willen zien. | ||
Line 122: | Line 124: | ||
===Veiligheidssysteem robot=== | ===Veiligheidssysteem robot=== | ||
Op het gebied van veiligheid rond autonome voertuigen is al veel onderzoek gedaan. Over het algemeen moet een zelfrijdende robot de volgende drie eisen voldoen: | Op het gebied van veiligheid rond autonome voertuigen is al veel onderzoek gedaan. Over het algemeen moet een zelfrijdende robot de volgende drie eisen voldoen: <ref name="Safaty"> Pace C., Seward W. (2005). 'A Model for Autonomous Safety Management in a Mobile Robot'. </ref> | ||
* Het herkennen van fouten, storingen of andere gevaren. | * Het herkennen van fouten, storingen of andere gevaren. | ||
Line 128: | Line 130: | ||
* Een beslissing nemen op basis van deze gevolgen. | * Een beslissing nemen op basis van deze gevolgen. | ||
Neem nu bijvoorbeeld KARIS. KARIS is een robot die in de industrie autonoom allerlei producten kan bezorgen. Door middel van twee laser scanners, een traagheidssensor, een gyrosensor en een ingebouwde roadmap kan de robot autonoom zijn route door het gebouw vinden. | Neem nu bijvoorbeeld KARIS. | ||
<ref name="KARIS">Trenkle A., Seibold Z., Stoll T. (Oktober 30, 2013). 'Safety Requirements and Safety Functions for Decentralized Controlled Autonomous Systems'. Presented on: 2013 XXIV International Conference on Information, Communication and Automation Technologies</ref> | |||
KARIS is een robot die in de industrie autonoom allerlei producten kan bezorgen. Door middel van twee laser scanners, een traagheidssensor, een gyrosensor en een ingebouwde roadmap kan de robot autonoom zijn route door het gebouw vinden. | |||
Om een botsing met een mens te voorkomen wordt gebruik gemaakt van laser scanners. Deze scanners spannen een ‘protected field’ op en zodra er een mens binnen dit gebied komt stopt de robot. Om de grootte van dit ‘protected field’ te bepalen is de remweg van de robot van belang. Nu is het zo dat de robot een niet al te grootte versnelling mag hebben. Dit heeft namelijk als gevolg dat het voedsel dat de robot mee voert niet goed blijft en dat het drinken gaat morsen. Maar omdat de veiligheid van mensen boven voedselveiligheid gaat kijken we eerst naar het geval waarin dit niet van belang is. In dit geval geldt: | Om een botsing met een mens te voorkomen wordt gebruik gemaakt van laser scanners. Deze scanners spannen een ‘protected field’ op en zodra er een mens binnen dit gebied komt stopt de robot. Om de grootte van dit ‘protected field’ te bepalen is de remweg van de robot van belang. Nu is het zo dat de robot een niet al te grootte versnelling mag hebben. Dit heeft namelijk als gevolg dat het voedsel dat de robot mee voert niet goed blijft en dat het drinken gaat morsen. Maar omdat de veiligheid van mensen boven voedselveiligheid gaat kijken we eerst naar het geval waarin dit niet van belang is. In dit geval geldt: | ||
Line 155: | Line 160: | ||
Het veiligheidssysteem dat KARIS gebruikt zou ook voor onze bezorgrobot gebruikt kunnen worden. Maar dit is niet de enige optie waar onderzoek naar is gedaan. Zo zijn er dus vele veiligheidssystemen die geschikt zijn voor onze robot. | Het veiligheidssysteem dat KARIS gebruikt zou ook voor onze bezorgrobot gebruikt kunnen worden. Maar dit is niet de enige optie waar onderzoek naar is gedaan. Zo zijn er dus vele veiligheidssystemen die geschikt zijn voor onze robot. | ||
=== Snelheid === | |||
In de vorige sectie is gebleken dat de snelheid van de robot een grote invloed heeft op de veiligheid. Wij hebben besloten om de robot een maximum snelheid te geven van 1 m/s. Dit heeft de volgende redenen: | |||
Ten eerste is dit ongeveer de snelheid van een mens die (niet al te snel) loopt. In Metaforum lopen mensen namelijk meestal iets langzamer dan gemiddeld. Dat de robot ongeveer even snel loopt als de mensen in Metaforum heeft verschillende voordelen die niet direct met veiligheid betrekking hebben: | |||
* Mensen hoeven niet aan de kans omdat de robot sneller gaat dan zij lopen. | |||
* Aan de andere kant hoeven mensen ook niet te wachten op de robot omdat deze te langzaam gaat. | |||
* Op deze manier ontstaat er dus minder chaos in de looppatronen van mensen in het metaforum. Het gevolg is dat omstanders minder last hebben van de gevolgen van de robot. | |||
Daarnaast zijn er verschillende voordelen vanuit een veiligheidsperspectief. Zo is de impact van een botsing van een robot met een mens ongeveer gelijk aan de impact als twee mensen tegen elkaar aanlopen, of als een mens hard tegen een obstakel aan loopt. Hierbij loopt de mens over het algemeen nooit ernstige verwondingen op, de robot heeft namelijk ook geen scherpe randen, punten of andere uitstekels. Daarnaast is de remweg van de robot bij deze snelheid niet groot (zie vorige sectie) dus de robot zal al afgeremd zijn voor deze werkelijk tegen een mens aan botst als deze botsing onvoorkombaar is. Ten slotte kan een mens met voedsel in zijn/haar hand rustig stoppen zonder dan het voedsel daar schade aan ondervindt. Dit maakt dat de robot bij deze snelheid dus ook veilig genoeg is voor het voedsel dat het vervoerd. | |||
=== Grootte robot === | === Grootte robot === | ||
Naast de snelheid zijn er enkele andere aspecten die van invloed zijn op de veiligheid van de robot. | |||
Naast | |||
Het eerste is geluidsfeedback. Uit de interviews met het personeel van Eurest bleek dat zij spraak wensten bij de robot om klantvriendelijkheid te verhogen. Het vermogen van de robot om te spreken of om geluid te kunnen maken zou gebruikt kunnen worden door de robot om opgemerkt te worden. | Het eerste is geluidsfeedback. Uit de interviews met het personeel van Eurest bleek dat zij spraak wensten bij de robot om klantvriendelijkheid te verhogen. Het vermogen van de robot om te spreken of om geluid te kunnen maken zou gebruikt kunnen worden door de robot om opgemerkt te worden. | ||
Line 166: | Line 180: | ||
=== Bescherming diefstal === | === Bescherming diefstal === | ||
Om het voedsel tegen diefstal te beschermen worden de kastjes waar het voedsel inkomt afgesloten. Deze kunnen door de student zelf geopend worden als de bestelling bezorgd wordt. Hoe dit precies in zijn werking gaat wordt | Om het voedsel tegen diefstal te beschermen worden de kastjes waar het voedsel inkomt afgesloten. Deze kunnen door de student zelf geopend worden als de bestelling bezorgd wordt. Hoe dit precies in zijn werking gaat, wordt in de sectie Uiterlijk en Functionaliteit uitgelegd. | ||
==Eurest== | ==Eurest== | ||
Line 174: | Line 188: | ||
Een van de grote vragen die het invoeren van een robot op de werkvloer automatisch met zich mee brengt is de waardigheid van het personeel dat deze taken nu uitvoert. Dit zou namelijk beschadigd kunnen worden door samen te moeten werken met deze robot. In plaats van zelf klanten te bedienen wordt een deel van het personeel ingezet als 'hulpje' van een robot die hiervoor zal gaan zorgen. | Een van de grote vragen die het invoeren van een robot op de werkvloer automatisch met zich mee brengt is de waardigheid van het personeel dat deze taken nu uitvoert. Dit zou namelijk beschadigd kunnen worden door samen te moeten werken met deze robot. In plaats van zelf klanten te bedienen wordt een deel van het personeel ingezet als 'hulpje' van een robot die hiervoor zal gaan zorgen. | ||
Echter toen wij met Eurest praatten was dit totaal geen probleem. Zij zijn juist blij als de robot hun huidige taken wat verlicht. Uit het interview bleek dat medewerkers van Eurest erg blij zouden zijn met de komst van de robot. Neem bijvoorbeeld het legen van de | Echter toen wij met Eurest praatten was dit totaal geen probleem. Zij zijn juist blij als de robot hun huidige taken wat verlicht. Uit het interview bleek dat medewerkers van Eurest erg blij zouden zijn met de komst van de robot. Neem bijvoorbeeld het legen van de prullenbak op de eerste verdieping. Op dit moment moet iemand van het personeel met een kar (die naar de eerste verdieping wordt gebracht met behulp van de dienstlift, terwijl het personeel de trap moet nemen) naar de eerste verdieping gebracht. Hier moeten alle vuilnisbakken, die vaak niet eens vol zitten maar vooral aangeduwd moeten worden, geleegd worden. Er moeten nieuwe vuilniszakken opgehangen worden. De medewerker moet weer naar beneden. De kar moet naar beneden worden gehaald. De vuilniszakken moeten weggegooid worden etc. En dit moet allemaal gebeuren op een moment dat het in de kantine op topdrukte is. Naast dat de robot de topdrukte in de pauze iets verlicht heeft deze ook een prullenbak. Voor personeel is het nu niet alleen veel makkelijk om vuilniszakken te verwisselen maar ook om het vuilnis even aan te duwen en vervolgens de robot met een nieuwe lading voedsel weer op pas te sturen. | ||
=== Werkgelegenheid === | === Werkgelegenheid === | ||
Een ander gevolg dat vaak op treed bij het invoeren van een robot op de werkvloer is een banenshift. In dit geval zal deze banenshift niet erg groot worden. De taken van huidige medewerkers van Eurest zullen iets | Een ander gevolg dat vaak op treed bij het invoeren van een robot op de werkvloer is een banenshift. In dit geval zal deze banenshift niet erg groot worden. De taken van huidige medewerkers van Eurest zullen iets veranderen maar hier is geen speciale technische kennis voor nodig. Er zullen ook weinig banen verdwijnen maar deze zullen voornamelijk verlicht worden. Een speciale technische dienst op de TU/e is waarschijnlijk niet nodig. Het is waarschijnlijker dat het bedrijf (of de groep) die deze robot ontwikkelt, langs komt als er een probleem is. Het is namelijk niet zo dat de kantine niet zonder robot zou kunnen als deze uit zou vallen. Dit heeft als gevolg dat de wachttijd op hulp bij de robot lang mag zijn en dus is iemand op de TU/e die van de techniek van de robot af weet overbodig. | ||
==Bereidheid tot aanschaffen== | ===Bereidheid tot aanschaffen=== | ||
Uit de verschillende interviews bleek dat Eurest interesse had in de komst van de robot. Niet alleen de kantinemedewerkers van Eurest vonden het geweldig omdat dit hen taken verlicht maar ook Eurest zelf. Dit zou namelijk een mooie aanvulling zijn op de huidige services van Eurest en is daarnaast een mooi reclamemiddel. | Uit de verschillende interviews bleek dat Eurest interesse had in de komst van de robot. Niet alleen de kantinemedewerkers van Eurest vonden het geweldig omdat dit hen taken verlicht maar ook Eurest zelf. Dit zou namelijk een mooie aanvulling zijn op de huidige services van Eurest en is daarnaast een mooi reclamemiddel. | ||
==Onderbouwing USE keuzes== | |||
===Algemeen=== | |||
====''Soort robot''==== | |||
Bij de keuze voor wat voor design we zouden gaan hebben we ons laten leiden door wat voor de users het minst storend zou zijn, voor de enterprise het beste rendement oplevert en voor de society het meest accepteerbare. | |||
*Drone: Te veel lawaai | |||
:De drone zou onveilige situaties kunnen creëren en geluidsoverlast veroorzaken voor de users. Verder zou het hoge energie verbruik de kosten en risico’s voor de enterprise vergroten. | |||
*Monorail: Afbreuk aan ontwerp pand + lastig te verwezenlijken | |||
:Voor de monorail zijn ook problemen. Ten eerste zou een rail afbreuk doen aan het Metaforum wat problemen levert voor de society. Ten tweede is het vrijwel niet te verwezenlijken vanwege zowel de kosten als het aanleggen van de infrastructuur zelf. | |||
====''Vorm''==== | |||
Voor de vorm is ook nagedacht aan wat de wens is van de verschillende USE aspecten. | |||
*Niet-humanoïde: Niet gewenst door users + lastig ontwerp | |||
:Zo gaven de users aan dat ze niet graag een humanoïde robot wilden, wat ook technisch lastig te realiseren valt. Ook de enterprise gaf aan dat een rijdend karretje een realistischer beeld is. | |||
*Grootte: Klein is fijn, maar groot voorkomt stoot | |||
:Voor de grootte valt meer te zeggen. Voor de users moet de robot niet zo groot zijn dat het stoort en zij zien de robot dan het liefst niet zo groot. De enterprise vindt eerder dat een grote opvallende robot meewerkt aan zowel de bekendheid van Eurest als voor de veiligheid, aangezien een grotere robot beter opvalt en er daardoor minder ongelukken gebeuren. | |||
====''Inlogsysteem''==== | |||
*Gebruik campuskaart | |||
:Voor het openen van de kastjes hebben we gekozen voor een systeem dat voor alle studenten en medewerkers van de TUe beschikbaar is, namelijk met behulp van de campuskaart. Dit systeem maakt het voor de robots makkelijk om te verwerken van wie welke bestelling zou moeten zijn wat belangrijk is voor de enterprise. Verder is het makkelijk te gebruiken en is het dus voor de users ook een goed systeem. | |||
====''Extra's''==== | |||
*Afvalverwerking | |||
:Het afleveren van het voedsel vereist ook een mate van ophalen van het afval. Zowel de users die gebruik zullen maken van de robot als de user medewerkers van de kantine geven aan dat afval een probleem vormt. Door een prullenbak in te bouwen wordt een deel van dit probleem verholpen. | |||
*Extra's vanuit de enterprise | |||
:Eurest is verplicht om extra’s als bestek te leveren. Vanuit de enterprise wordt dus gevraagd om een mogelijkheid om bestek en dergelijke te kunnen leveren. Dit heeft geleid tot het toevoegen van de bestekbak. | |||
===Wettelijke eisen=== | |||
====''Conclusie''==== | |||
Wettelijk zijn er meerdere constraints, maar slechts een aantal daarvan zijn van toepassing op onze robot. | |||
*Temperatuurcontrole: Minimaal 60 warm, maximaal 7 koud | |||
:Een belangrijk punt is dat de temperatuur gecontroleerd kan worden zodat voedsel op de juiste temperatuur wordt aangeleverd. Dit heeft geleid tot de keuze voor verschillende kastjes voor warme en koude soorten voedsel, waarbij in warme ruimtes een warmtelamp en ventilatie de temperatuur garandeert met minimaal kwaliteitsverlies. Koude ruimtes worden alleen geventileerd. | |||
*Geen infraroodtemperatuurmeter | |||
:Voor het vaststellen van de temperatuur van het voedsel mogen geen infraroodmiddelen gebruikt worden. | |||
*Verontreiniging: Regelmatige schoonmaak | |||
:Ook moet hygiëne gegarandeerd worden als eis van de society voor de user. Dit heeft gevolgen voor de user medewerkers omdat deze de robot schoon moeten maken na elke levering. | |||
===Uiterlijk=== | |||
*Kreukelzone: Veiligheid | |||
:Aan de voor en achterzijde is een kreukelzone ingebouwd met als doel de veiligheid van de omstanders (users) te beschermen. Door de kreukelzone wordt de kans op letsel geminimaliseerd omdat de kreukelzone bol is gevormd. Dit is veel minder schadelijk in geval van een ongeluk dan scherpe randen en hoeken. | |||
*Kleur: Veiligheid en Omgeving | |||
:Voor de kleur hebben we gekozen voor redelijk felle kleuren zodat de robot goed opvalt in zijn omgeving. Dit zorgt ervoor dat mensen de robot makkelijker kunnen opmerken en eventueel aan de kant gaan om ongelukken te voorkomen. | |||
:Verder hebben we ook gekeken naar het kleuren schema waarop het Metaforum gebaseerd is, zodat de robot daadwerkelijk past bij het Metaforum. Dit is gedaan zowel voor acceptatie, aangezien niemand blij wordt van een robot die vloekt met het gebouw, als met oogpunt op het voortzetten van het architectonische ontwerp van het Metaforum. | |||
:Om deze reden maken we gebruik van de kleurencombinatie geel-blauw. Geel is de kleur van het Metaforum en blauw wordt veel verwerkt in de wat kleinere details als wegwijzerbordjes. Verder is geel het type felle kleur wat goed helpt met opvallen met betrekking tot de veiligheid. | |||
:Omdat de voor en achterkant het meest moeten opvallen zijn deze geel gekleurd en omdat felle kleuren er sneller vies uitzien zien de delen die interactie vertonen met mensen gekleurd met het donkerdere blauw. | |||
===Algorithmic Design=== | |||
====''Pathfinding''==== | |||
:Zie verderop bij navigatiehulpmiddelen. | |||
====''Scheduling''==== | |||
:Om voor de users een zo prettig mogelijk systeem te hebben zijn de meest noodzakelijke punten waarop gecontroleerd moet worden het minimaliseren van het aantal robots, wat ook voor de enterprise erg belangrijk is qua kosten, het beperken van variatie in bezorgtijd en het zo vers mogelijk houden van het voedsel. Het zo vers mogelijk houden van het | |||
===Infrastructuur=== | |||
====''Deuren''==== | |||
:Omdat deuren vaak niet automatisch zijn, is dit een belemmering voor de ruimte waardoor de robot zich kan bewegen. Om dit te verhelpen is het theoretisch mogelijk alle deuren te vervangen, maar dit brengt veel kosten met zich mee en is daarom voor de enterprise geen aanlokkelijke gedachte. Hierom is besloten de robot alleen op de eerste verdieping van het Metaforum te laten bezorgen, aangezien dit een grote open ruimte is. | |||
====''Lift''==== | |||
:De kantine zit op de begane gronde en de robot bezorgt op de eerste. Aangezien de robot in de kantine wordt ingeladen is er een noodzakelijkheid tot het gebruik van de lift. Omdat de gewone liften te vaak gebruikt worden door users is dit geen goede lift, maar de werk lift naar de kantine zelf is wel een goede lift. Deze is nog niet gebouwd op automatisch gebruik maar in gesprekken met Eurest als enterprise is gebleken dat eventuele aanpassingen aan de lift wel te verwezenlijken zijn. | |||
====''Laadstation''==== | |||
:Voor de user medewerkers van de kantine is het gewenst dat de robot kan worden ingeladen met genoeg ruimte om dit te kunnen uitvoeren. Idealiter kan de robot gelijktijdig worden opgeladen, wat betekend dat het laadstation genoeg ruimte overlaat voor de medewerkers om hun werk te kunnen doen. | |||
====''Navigatiehulpmiddelen''==== | |||
:Door lijnen op de vloer te leggen wordt het makkelijker voor de robot om zijn route vast te houden en niet vast te komen te zitten. Uit de enquête is gebleken dat het merendeel van de users er geen problemen mee zouden hebben als er lijnen worden toegevoegd aan het Metaforum om de infrastructuur van de robot mogelijk te maken. | |||
====''Bezorgpunten''==== | |||
:Er is gekozen voor het bezorgen aan de uiteinden van tafels aangezien dit de enige manier is om te voldoen aan de eisen gesteld vanuit de enterprise en society. Dit is een vermindering van het comfort van de users, want uit de enquête blijkt dat de users het liefst persoonlijke bezorging zouden krijgen. Echter geeft de enquête ook aan dat de maximale afhaalafstand 5 meter is, wat betekend dat users bereid zijn om op te staan om hun eten op te halen. | |||
=Uiterlijk en Functionaliteit= | =Uiterlijk en Functionaliteit= | ||
Line 216: | Line 295: | ||
De formaten van de soorten voedsel zijn als volgt: | De formaten van de soorten voedsel zijn als volgt: | ||
: Koude dranken: 6x6x21 cm | |||
: Warme dranken: 5x5x8 cm | |||
: Soep: 8x8x8 cm | |||
: Belegde stokbroden: 5x35x5 cm | |||
: Panini's: 8x30x3 cm | |||
: Kleine broodjes: 15x10x3 | |||
===Soorten kastjes=== | ===Soorten kastjes=== | ||
Line 282: | Line 362: | ||
Dit valt net binnen de wensen van de users en is relatief makkelijk te implementeren. | Dit valt net binnen de wensen van de users en is relatief makkelijk te implementeren. | ||
== Hoe en wanneer wordt de robot opgeladen? | == Hoe en wanneer wordt de robot opgeladen? == | ||
Bij het cafetaria komt een laadstation en wachtruimte voor de robots, waar de robots kunnen opladen en wachten tot ze weer nodig zijn. | Bij het cafetaria komt een laadstation en wachtruimte voor de robots, waar de robots kunnen opladen en wachten tot ze weer nodig zijn. | ||
Het laadsysteem gaat via een contactplaat aan de onderkant, waarmee contact gemaakt wordt met elektrische circuits in de grond van het laad station. | Het laadsysteem gaat via een contactplaat aan de onderkant, waarmee contact gemaakt wordt met elektrische circuits in de grond van het laad station. | ||
Line 294: | Line 374: | ||
Dit beide is mogelijk door de kleurcombinatie geel-blauw te gebruiken. Donkerblauw is een kleur die naast geel op dit moment in veel details voor komt in het Metaforum. Denk hierbij bijvoorbeeld aan de wegwijzerbordjes. Geel is daarnaast ook een opvallende kleur. Een compleet gele robot zou echter té veel worden. Studenten zouden hierdoor bijvoorbeeld afgeleid kunnen worden en geel is een kleur die snel vies wordt. Om deze redenen zijn donker blauw en geel dus goede kleuren voor de robot. | Dit beide is mogelijk door de kleurcombinatie geel-blauw te gebruiken. Donkerblauw is een kleur die naast geel op dit moment in veel details voor komt in het Metaforum. Denk hierbij bijvoorbeeld aan de wegwijzerbordjes. Geel is daarnaast ook een opvallende kleur. Een compleet gele robot zou echter té veel worden. Studenten zouden hierdoor bijvoorbeeld afgeleid kunnen worden en geel is een kleur die snel vies wordt. Om deze redenen zijn donker blauw en geel dus goede kleuren voor de robot. | ||
De voor- en achterkant van de robot moeten het meest opvallen. Om deze reden hebben wij ervoor gekozen deze kanten geel te maken. Op een lichte kleur is vuil snel zichtbaar en dit zou af kunnen doen aan het gevoel wat mensen over de kwaliteit van Eurest hebben. Om deze reden zullen de vakjes een blauwe kleur krijgen. De bovenkant van de robot bevat beide kleuren. In de animatie zijn deze kleuren uitgebreid weergegeven. | |||
== Tijd == | |||
Voor de users is het van belang dat zij een indacatie hebben over hoe lang de robot er over doet om hun voedsel te bezorgen. Hiervoor zal bekend moeten zijn hoe lang de robot over een rondje doet. Wij schatten deze tijd in op ongeveer 10 minuten. Wij gaan er namelijk van uit dat er minstens twee robots door het Metaforum zullen gaan rijden. Op deze manier kan ismajden terwijl de andere ingeladen wordt. Eurest heeft dan precies 5 minuten om de vakjes indien nodig schoon te maken en te vullen met nieuwe bestellingen. Hierna zal de robot zo'n 30 seconden met de lift moeten. In totaal zal de robot met 1 m/s ongeveer anderhalve minuut doen over het rijden naar een student (als deze het verst van de lift af zit). De afstand die in dit geval afgelegd moet worden is namelijk ongeveer gelijk aan 100 meter. Verder zal de robot tussendoor een paar keer moeten stoppen voor endere studenten. We gaan ervan uit dat als de robot helemaal vol zit, deze op één plek kan stoppen voor meerdere studenten. Op deze manier wordt veel tijd bespaart en kan de robot dus binnen 5 minuten bij de gebruiker zijn. Toch zal het lastig worden om deze 10 minuten te garanderen. Dit heeft voornamelijk te maken met studenten die vergeten hun lunch op te halen (zoals bijvoorbeeld als zij de melding op hun telefoon niet door hebben) of als er een obstakel op de lijn ligt waar de robot overheen moet. | |||
= Algorithmic Design = | = Algorithmic Design = | ||
Line 309: | Line 392: | ||
Hoewel de lijnen waarover onze robot navigeert natuurlijk impliceren dat mensen er niet op moeten gaan staan en er geen objecten op moeten achterlaten is het negeren van deze mogelijkheid natuurlijk niet verstandig. Als robots een obstakel detecteren dat niet te omzeilen is kunnen ze dit naar de andere robots communiceren. Alle robots kunnen dan de bijbehorende zijde in hun model een oneindige waarde geven om dit obstakel te mijden. Bestellingen naar bestemmingen die door dit obstakel onbereikbaar gemaakt worden zouden naar de catering geretourneerd kunnen worden en nieuwe bestellingen kunnen worden afgewezen. De catering kan dan van dit obstakel op de hoogte worden gesteld waarna ze actie kunnen ondernemen. | Hoewel de lijnen waarover onze robot navigeert natuurlijk impliceren dat mensen er niet op moeten gaan staan en er geen objecten op moeten achterlaten is het negeren van deze mogelijkheid natuurlijk niet verstandig. Als robots een obstakel detecteren dat niet te omzeilen is kunnen ze dit naar de andere robots communiceren. Alle robots kunnen dan de bijbehorende zijde in hun model een oneindige waarde geven om dit obstakel te mijden. Bestellingen naar bestemmingen die door dit obstakel onbereikbaar gemaakt worden zouden naar de catering geretourneerd kunnen worden en nieuwe bestellingen kunnen worden afgewezen. De catering kan dan van dit obstakel op de hoogte worden gesteld waarna ze actie kunnen ondernemen. | ||
=== | Een ander algoritme dat geschikt zou kunnen zijn is Dijksta's algoritme. Jammer genoeg is Dijksta's algoritme slechts een versimpelde versie van A* (eigenlijk is A* een geavanceerdere versie van Dijksta's algoritme) door het ontbreken van een heuristieke functie. Dit maakt Dijksta's algoritme minder geschikt indien er genoeg rekenkracht is voor het uitvoeren van A*. Dijkstra's Algoritme is echter wel zuiniger in het gebruik van werkgeheugen. Daar de verschillen verwaarloosbaar zijn zouden beiden een geschikte keuze zijn. | ||
TODO | |||
=== Uiteindelijk Algoritme === | |||
Het algoritme dat uiteindelijk het meest geschikt is voor ons probleem is een real-time algoritme dat on-the-fly routes over een graaf kan berekenen en herberekenen. Het meest gebruikte algoritme dat aan deze eisen voldoet is A*. Omdat het MetaForum geen "schuine" paden kent is de manhattan distance een zeer geschikte heuristiek. Het ontbreken van shuine paden maakt de manhattan distance niet alleen een consistente, maar ook een toegestane heuristiek. Andere geschikte heuristieke functies zouden de hemelsbrede afstand of simpelweg 0 zijn, maar deze zullen minder accuraat blijken dan de manhattan distance. TODO altijd beste pad, heuristiek slechts voor rekentijd belangrijk, etc. | |||
TODO simulatie met A* in aan het MF gelijkende omgeving? | |||
== Scheduling == | == Scheduling == | ||
TODO | Omdat de robots tot wel 40 orders tegelijk bij zich kunnen dragen is het niet mogelijk om met brute kracht de optimale volgorde voor bezorging te bepalen. De hoeveelheid mogelijkheden kan namelijk oplopen tot een verbluffende 40!, een getal met wel 48 decimalen. Hoewel het aantal locaties waar de robots naartoe moeten beperkt wordt doordat er minder dan 40 aflever punten zijn (pigeon hole principle) is dit nog niet voldoende om het probleem alsnog met brute bracht op te lossen. Gelukkig is ons probleem een redelijk bekend probleem dat de term Vehicle Routing Problem with Time Windows (VRPTW) draagt. | ||
Bij het oplossen van een VRPTW probleem kunnen verschillende factoren geoptimaliseerd worden. Ten eerste kunnen de kosten van transport geminimaliseerd worden. Omdat het bij onze robots gaat om kleine afstanden en relatief zuinige elektromotoren zal de afstand die moet worden afgelegd geen grote rol spelen in de kosten van het systeem. Veel interessantere factoren zijn het aantal voertuigen minimaliseren, de hoeveelheid variatie tussen bezorgtijden minimaliseren en het voedsel zo vers mogelijk houden. Het minimaliseren van het aantal robots is in ons geval zeer belangrijk, daar de robots ongeveer TODO euro per stuk zullen gaan kosten. Ook een constante service bieden aan de gebruiker zal het gebruik van onze service een stuk aangenamer maken. Een gebruiker kan bij een lagere variatie in de bezorg tijd veel beter plannen. Als er bijvoorbeeld gegarandeerd wordt dat de robot altijd tussen de 3 en 5 minuten nodig zal hebben om de bestelling te bezorgen vanaf het moment van bestelling kan de gebruiker al 3 minuten voor het arriveren op het aflever punt bestellen en zal zo minder lang hoeven wachten. Tot slot is er het zo vers mogelijk houden van het voedsel. We denken dat die veruit de beste prestatie maatstaf is omdat de kwaliteit van het voedsel natuurlijk ten aller tijden gegarandeerd moet blijven. | |||
=== Genetic Algorithm === | |||
Een oplossing voor het VRPTW is een genetic algorithm als beschreven in /Perishable goods Delivery and Scheduling with time window by Genetic Algorithm/. Dit is een algoritme dat op evolutie gebaseerde technieken relatief snel een oplossing voor het probleem kan vinden. Dit zijn echter wel relatief intensieve algoritmes die dus het beste op een centrale machine kunnen worden uitgevoerd. De robots met computers uitrusten die krachtig genoeg zijn om de volgorde te bepalen met een genetic algoritme zou namelijk zowel duur zijn als leiden tot een aanzienlijke hitte afgifte door de vereiste hardware. | |||
= Proces = | = Proces = | ||
Line 332: | Line 423: | ||
=== Transport === | === Transport === | ||
Zodra de robot arriveert bij de gebruiker kan de bestelling uit de robot genomen worden. De order zal dan de status "received" krijgen. Als de robot niet leeg is, zal deze door rijden naar andere gebruikers. Als de robot wel leeg is zal hij terug keren naar de catering en zullen de bestellingen als "complete" gemarkeerd worden. Als een gebruiker niet binnen 2 minuten na arriveren de bestelling uit de robot neemt, wordt de bestelling als "rejected" gemarkeerd en zal het betaalde geld (eventueel na aftrek van service kosten) worden terugbetaald aan de gebruiker. | Zodra de robot arriveert bij de gebruiker kan de bestelling uit de robot genomen worden. De order zal dan de status "received" krijgen. Als de robot niet leeg is, zal deze door rijden naar andere gebruikers. Als de robot wel leeg is zal hij terug keren naar de catering en zullen de bestellingen als "complete" gemarkeerd worden. Als een gebruiker niet binnen 2 minuten na arriveren de bestelling uit de robot neemt, wordt de bestelling als "rejected" gemarkeerd en zal het betaalde geld (eventueel na aftrek van service kosten) worden terugbetaald aan de gebruiker. Ook zullen de artikelen die geretourneerd worden weer aan de voorraad toegevoegd worden. Artikelen die niet terug mogen nadat ze zich in de robot bevonden hebben, bijvoorbeeld door verminderde temperatuur of tijd sinds het bereiden kunnen door de catering weggegooid worden net als alle andere producten van een te lage kwaliteit. | ||
== Case Descriptions == | |||
'''Registeren''' | |||
''Hoofdsuccesscenario:'' | |||
:1. Student gaat naar de kantinepaal | |||
:2. Student scant zijn campuskaart | |||
:3. Student logt in met zijn s-nummer en stelt een wachtwoord in | |||
:4. Systeem registreert de nieuwe gegevens | |||
:5. Systeem stuurt een bevestigingsmail naar de TUe mail van de student | |||
:6. Student activeert zijn account via de link in de bevestigingsmail | |||
''Extensies:'' | |||
:6a: Link is verlopen | |||
:: 1. Student vraagt een nieuwe mail aan of doet niks en gegevens verlopen | |||
'''Opwaarderen tegoed''' | |||
''Hoofdsuccesscenario:'' | |||
:1. Student gaat naar de webapp | |||
:2. Student logt in met zijn gegevens | |||
:3. Student gaat naar opwaarderen | |||
:4. Systeem toont de mogelijke bedragen | |||
:5. Student kiest een opwaardeerbedrag | |||
:6. Systeem toont betaalmethoden (bv iDeal) | |||
:7. Student kiest betaalmethode | |||
:8. Student vult alle gegevens in | |||
:9. Student accepteert de gegevens | |||
:10. Systeem rond de betaling af en laadt het saldo bij | |||
''Extensies:'' | |||
:5a: verschillende mogelijkheden | |||
:: 1. Student kiest een eenmalig opwaardeerbedrag of een automatische opwaardeer optie zodat een vast bedrag altijd op het account staat | |||
:10a: Fout bij afronden opwaarderen | |||
:: 1. Student stopt het opwaarderen en probeert opnieuw of stopt met opwaarderen en sluit de webapp | |||
'''Bestelling''' | |||
''Hoofdsuccesscenario:'' | |||
:1. Student doorzoekt het menu van de app/webapp en stelt zijn menu samen | |||
:2. Student gaat naar het winkelwagentje | |||
:3. Systeem geeft de totale bestelling en de totale kosten weer | |||
:4. Student regelt de betaling en de afleverlocatie | |||
:5. Systeem autoriseert de betaling | |||
:6. Systeem bevestigd de verkoop | |||
:7. Systeem vermeld dat de bestelling succesvol is en verstuurt de bestelling naar het kantine personeel | |||
:8. Kantine personeel laadt een wachtende robot in | |||
:9. Robot vertrekt naar de afleverlocatie | |||
:10. Student logt in met campuskaart | |||
:11. Student pakt zijn bestelling | |||
:12. Robot gaat terug naar kantine | |||
''Extensies:'' | |||
:5a: Betaling mislukt of de afleverlocatie wordt niet geaccepteerd | |||
:: 1. Student vernieuwt de betalingsgegevens of stopt de bestelling | |||
:: 2. Student stelt opnieuw de afleverlocatie in of stopt de bestelling | |||
:12a: Er zijn mogelijk meerdere bestellingen | |||
:: 1. De robot gaat verder met de volgende bestelling of gaat terug naar de kantine indien alle bestellingen zijn afgehaald | |||
== Petrinet == | == Petrinet == | ||
Line 364: | Line 554: | ||
Na overweging van deze factoren is er gekozen om de robot de bestellingen aan de tafeluiteinden te laten afleveren. | Na overweging van deze factoren is er gekozen om de robot de bestellingen aan de tafeluiteinden te laten afleveren. | ||
== Userlokalisatie == | |||
Aangezien er is gekozen voor bezorging aan het tafeluiteinde, zal een specifiekere lokalisatie dan tafelkeuze niet nodig zijn. De user voert gewoonweg tijdens het bestellen het reeds bestaande tafelnummer van zijn tafel in. Andere systemen, zoals bijvoorbeeld GPS-lokalisatie, leveren te veel moeilijkheden op voor te weinig potentiële voordelen. | |||
=References= | |||
<references/> |
Latest revision as of 19:57, 25 October 2015
Terug naar: PRE2015_1_Groep2
Algemeen
Soort robot
Een van de eerste beslissingen die wij hebben genomen was dat wij moesten kiezen tussen bijvoorbeeld een rijdende robot of een drone. De reden dat wij niet voor de drone hebben gekozen is dat deze veel lawaai maken en dus de rust in het Metaforum kunnen verstoren. Bovendien hebben deze voertuigen onnodig veel energie nodig. Een ander idee was om de robot aan een rails in het plafond te hangen zodat bezoekers van het Metaforum minder last hebben van de robot. Dit zou echter veel problemen veroorzaken met betrekking tot de infrastructuur. Naast dat dit systeem aangelegd zou moeten worden en dit afdoet aan het architectonische ontwerp van het Metaforum en de robot ook verschillende verdiepingen zou moeten begaan, leent het dak van Metaforum zich niet goed voor een rails aan het plafond. Er zitten namelijk veel hoogteverschillen in het dak. Daarnaast zou een systeem met rails veroorzaken dat de robot alleen op specifieke plekken kan komen. Om deze redenen hebben wij dus gekozen voor een rijdende robot.
Vorm
Uit de enquête bleek dat mensen voorkeur hebben voor een niet humanoïde robot. Om deze reden en hebben wij voor de vorm van de robot gekozen voor een balk. Omdat wij gaan werken met een systeem met kastjes (zie privacy) is dit de meest efficiënte vorm. Des te kleiner de robot, des te minder last mensen hier van hebben. Daarentegen is een grote robot weer opvallender wat ook voordelen heeft. Mensen hebben een grote voorkeur voor een robot van ongeveer 80cm. Dit is dus het formaat waar we naar gaan streven. Dit zal echter afgewogen moeten worden tegen onder andere de omgevingen waarin de robot zou moeten kunnen rijden en de hoeveelheid voedsel die in dit geval mee genomen kan worden.
Inlogsysteem
Bovenop de robot komt een schermpje waar mensen op kunnen inloggen of een systeem waar mensen hun campuskaart voor kunnen houden. Zie Veiligheid voor een uitgebreide uitleg over dit onderwerp.
Extra's
Uit de enquêtes bleek dat veel mensen nog zaten met het probleem dat afval nog steeds weggebracht moest worden. Dit is ook de reden dat voedsel uit de kantine verboden is in de bibliotheek. Hierom overwegen wij ook een prullenbak bij de robot te voegen waar mensen hun afval direct kwijt kunnen.
Daarnaast moet de kantine onder andere bestek, peper, zout en servetten aanbieden. Hier voor moet dus ook ruimte is de robot gereserveerd worden.
Wettelijke eisen
Het eerste belangrijke aspect waar in het design rekening mee moet worden gehouden zijn wettelijke eisen. Deze staan vermeld in de Nederlandse Voedselveiligheidseisen. Deze eisen staan overzichtelijk vermeld in een document van ServSafe International. [1] Sommige van deze wetten zijn van belang bij het ontwerpen van de robot. Deze hebben voornamelijk te maken met het vervoer en de temperatuur van het voedsel. Hieronder zijn de belangrijkste regels vermeld onder het hoofdstuk waarin zij in dit document te vinden zijn.
Nederlandse Voedselveiligheidseisen
- Voedsel met verhoogd microbiologisch risico is het hoogst tussen de 7 en 60 graden Celsius. Dit wordt de temperaturengevarenzone genoemd, omdat pathogenen in dit temperatuurbereik groeien.
- Vooral gebruikt: Kerntemperatuurthermometer (verplicht voor temperatuurregistratie)
- Verboden: Infraroodthermometer.
- Warme producten worden bij een temperatuur van ten minste 60 graden Celsius geserveerd.
- Koude producten worden bij een temperatuur van maximaal 7 graden Celsius geserveerd.
- In bediende gekoelde presentaties mogen producten die geheel van de gast zijn afgeschermd tot 2 dagen worden bewaard, waarbij de eerste uitgiftedag niet meetelt. Met uitzondering van risicovolle producten, deze mogen slechts 1 dag worden verstrekt. Warme producten mogen maximaal gedurende een hele dag worden aangeboden in de bain marie. Mag tot 2 uur worden bewaard mits het voedsel: op 7 graden Celcius is voor het uit de koelruimte wordt gehaald, een etiket heeft met verwijderingstijd/weggooitijd.
- Restaurant (HORECA): Na bereiding moeten de producten gekoeld worden bij 7 graden Celsius of kouden. De 2-uursborging moet altijd aanvangen bij een temperatuur van 7 graden Celsius of kouder. Zelfbereide producten mogen ten hoogste 1 dag na bereiding worden gepresenteerd. Zelfbereide producten worden bijvoorbeeld geborgd met behulp van kaartjes op de (om)verpakking met daarop een tijdstip of codering. Verpakte producten moeten onuitwisbaar worden gemerkt. Onder borging gepresenteerde producten mogen niet uit het buffet gehaald worden om later nogmaals te worden gepresenteerd. Producten die nog in de terugkoelfase zitten en producten die na bereiding direct ongekoeld worden gepresenteerd hoeven niet aan de temperatuureis te voldoen.
- Registratie (tenzij presentatie korter is dan 2 uur en restanten worden weggegooid) moet aantoonbaar zijn: datum, naam product, aantal of hoeveelheid product, begin en/of eindtijd, aantal of hoeveelheid derving, naam medewerker.
- Bij presentatie van etenswaren op een buffet is een ademschot verplicht.
- Bij uitgifte van onverpakte producten ligt serveerbestek.
- Als uitgifte aan de gebruiker plaatsvindt in ruimten waar de voedingsmiddelen aan vervuiling bloot staan, dienen producten te worden afgedekt.
- Alle producten moeten na presenteren worden weg gegooid.
- Indien nodig moeten vervoermiddelen die worden gebruikt voor het vervoer van levensmiddelen, die levensmiddelen op de vereiste temperatuur houden en de mogelijkheid bieden om die temperatuur te bewaken.
- Vervoermiddelen die worden gebruikt voor het vervoer van levensmiddelen moeten schoon zijn en goed worden onderhouden om de levensmiddelen tegen verontreiniging te beschermen en moeten, indien nodig, zo zijn ontworpen en geconstrueerd dat zij goed kunnen worden schoongemaakt en/of ontsmet.
- Ruimten in voertuigen en/of containers mogen niet voor het vervoer van andere goederen dan levensmiddelen worden gebruikt indien zulks tot verontreiniging kan leiden.
- In vervoermiddelen die terzelfdertijd worden gebruikt voor het vervoer van andere producten dan levensmiddelen of voor het vervoer van verschillende levensmiddelen tegelijk moeten de producten, indien nodig, afdoende van elkaar gescheiden zijn.
- Vervoermiddelen die worden gebruikt voor het vervoer van andere producten dan levensmiddelen of voor het vervoer van verschillende levensmiddelen moeten tussen de verschillende vrachten afdoende worden schoongemaakt om verontreiniging te vermijden.
- Levensmiddelen in vervoermiddelen moeten zo worden geplaatst dat het risico van verontreiniging tot een minimum wordt beperkt.
Conclusie
Belangrijk is dus dat in de bezorgrobot de temperatuur gecontroleerd kan worden. Warme producten moeten bij een temperatuur van minimaal 60 graden bij de gebruiker bezorgd worden, koude producten bij maximaal 7 graden.Voor het meten van deze temperatuur is een infraroodthemperatuurmeter verboden. Het voedsel wordt bezorgd door heel Metaforum dus moet rekening gehouden worden met verontreiniging. Na elke levering moeten de lades schoongemaakt worden, daarnaast moeten verschillende voedingsmiddelen gescheiden van elkaar vervoerd worden.
USE aspecten
User enquête
Zie: Week 3: User enquête
Interview Eurest
Planning
Duidelijke uitleg idee.
Schetsen.
Zou u geïnteresseerd zijn in dit product?
Wat voor formaat heeft uw voorkeur? Om welke reden (meer gebruiker gericht / hoe veelheid en soort voedsel erin past / enz)?
Zou u willen dat alle producten met deze robot te bezorgen zijn of zijn er producten die u liever alleen in de kantine verkocht wil hebben?
Zijn er wetten of regels van Eurest waar wij in het ontwerpen van de robot rekening mee moeten houden? (tijd / temperatuur / enz)
(Hoe ziet u de banenshift voor u? (hier misschien rekening mee houden bij het interviewen van de medewerkers) Hoe ziet de baan van medewerkers er uit?)
Hoe veel mensen zijn er dagelijks in de kantine om eten te halen? Hoe veel hiervan komen er in de pauze langs?
Interview Richard Cornelissen
Na een duidelijke uitleg over het project en het laten zien van een aantal schetsen van het design is de eerste reactie vanuit Eurest positief. Cornelissen noemt het een mooi initiatief en vraagt zich af hoe we op het idee zijn gekomen. Volgens hem zou het een mooie aanvulling zijn op de huidige service die Eurest biedt en is dus zeker geïnteresseerd in de robot ook al ziet hij vele praktische moeilijkheden voor zich.
Eurest heeft zelf geen speciale regels voor de robot. Wel moeten zij zich houden aan de Nederlandse Voedselveiligheidsvoorschriften. Dit staat ook vermeld in een contract met de TU/e. Zo zijn zij bijvoorbeeld verplicht alles te registreren, van schoonmaaklijsten bij houden tot het registreren van temperaturen.
Een praktisch probleem dat Cornelissen voor zich ziet is het warm houden van het voedsel. Isoleren neemt namelijk een probleem met zich mee waar wij nog niet aan gedacht hadden. Door het voedsel in een gesloten ruimte te plaatsen gaat het namelijk condenseren. En een gevolg hiervan is dat het voedsel een slechtere kwaliteit krijgt. Dit moet voor Eurest zo veel mogelijk voorkomen worden. Cornelissen schat dat voedsel in een geïsoleerde ruimte binnen 5 minuten bij de klant moet zijn. Toch noemt hij dat wij dit ook moeten navragen bij de medewerkers omdat zij meer verstand hebben over dit onderwerp. Ook zouden zij meer informatie kunnen verschaffen over welk soort voedsel wel en niet vervoerd kan worden met deze robot. Over het idee om voedsel te verwarmen is hij meer enthousiast. Zeker als dit in combinatie is met ventilatie. In dit geval schat Cornelissen dat het voedsel in ongeveer 5 tot 10 minuten bezorgd moet worden. Met Richard Cornelissen hebben wij ook gesproken over de grootte die de robot zou moeten krijgen. Het liefst zou hij de robot zo groot mogelijk willen hebben. Cornelissen noemt verschillende voordelen van dit idee. Ten eerste komt het de bekendheid van Eurest ten goede. Daarnaast kan er op deze manier zo veel mogelijk voedsel vervoerd worden en dus zo veel mogelijk klanten bediend worden. Ten slotte noemt Cornelissen de veiligheid. Een grotere robot springt meer in het oog waardoor er minder kans is op ongelukken met omstanders, aangezien deze de robot zien aankomen.
Interview medewerkers Eurest
Planning
Duidelijke uitleg idee.
Schetsen.
Uitleg hoe hun baan eruit zou zien. (met behulp van antwoord Eurest)
Hoe staat u tegenover dit idee? (geïnteresseerd, voelt vervangen) Zou u met deze robot willen werken?
Hebt u eisen / wensen voor het ontwerp van de robot die uw taken makkelijker maken? (medewerker – robot)
Wat vindt u belangrijk aan uw taak dat de robot ook zou moeten kunnen? (robot – klant)
Interview medewerkers (oa Lindy van Rooij)
De eerste reacties van medewerkers op dit idee zijn positief. Zo wordt er ‘Super!’ en ‘Geweldig!’ geroepen. Ook vanuit medewerkers van Eurest is er dus zeker interesse in het gebruiken van een bezorgrobot.
De eerste wens die medewerkers voor de robot hebben is een prullenbak. In Metaforum zijn op dit moment verschillende prullenbakken. Echter lijken deze prullenbakken op dit moment erg snel vol omdat mensen afval niet aanduwen. Dit ziet er erg slordig uit en het is de taak van Eurest om dit te voorkomen. Dit heeft als gevolg dat medewerkers op het drukste moment van de dag (in de pauze) met een kar naar boven moeten om dit afval op te ruimen. En dit gaat ten koste van het bedienen van klanten in de kantine.
Met de medewerkers hebben wij het ook gehad over het warm houden van het voedsel. Lindy van Rooij is het niet eens met Richard Cornelissen over de maximale tijd waarin voedsel bezorgd moet worden. In een geïsoleerde ruimte zou voedsel binnen 3 minuten bij de klant moeten zijn. Bij het gebruik van een warmtelamp en/of ventilatie is deze tijd iets langer. Een probleem dat wel komt kijken bij het gebruik van een warmtelamp is korstvorming bij bijvoorbeeld kaas en saus. Dit heeft als gevolg dat de maximale bedieningstijd als nog rond de 5 minuten ligt.
Volgens Van Rooij komen er per dag gemiddeld 1600 klanten langs in de kantine. Het drukste moment van de dag is de lunchpauze. Tussen 12 uur en half 2 komen er gemiddeld 600 klanten langs. Daarnaast zijn er veel mensen die ’s ochtends koffie halen of ’s middags een snack.
Naast een prullenbak heeft het personeel een voorkeur voor kastjes boven lades. Naast dat dit veel ruimte bespaart, is dit ook makkelijker schoon te maken. Ten slotte zouden medewerkers graag zien dat de robot in staat is door middel van spraak (en indien mogelijk spraakherkenning) te communiceren met de klanten om de robot klantvriendelijker te maken. Zo zou de robot kunnen zeggen ‘Hier is uw bestelling. Eet smakelijk!’ als deze het voedsel aflevert. Tijdens het interview met de medewerkers hebben wij het ook over de lift gehad. Dit heeft als reden dat de liften in Metaforum rond de pauze op dit moment al erg druk zijn. Een robot die mede gebruik zou gaan maken van deze liften zou dit probleem alleen maar verergeren. Een oplossing op dit probleem is de dienstlift van Eurest. Deze gaat vanaf de keuken van Eurest naar de eerste verdieping. Volgens het personeel is het mogelijk om deze te gebruiken voor de robot, al zou deze wel aangepast moeten worden. Op dit moment kan de lift namelijk alleen bediend worden door medewerkers. Wel zou er genoeg ruimte voor de robot in deze lift en in de keuken moeten zijn. Tijdens dit gesprek hebben wij ook de kans gehad om de maten van de lift op te nemen. Deze zijn hieronder te vinden.
Het enthousiasme van het personeel bleek ook uit de afronding van het gesprek. Er was namelijk veel interesse om met verschillende medewerkers in een pauze nog eens te brainstormen. Mochten hier nog resultaten uit komen, zouden deze naar ons gemaild worden. Daarnaast zou het personeel graag de simulatie willen zien.
Afmetingen lift
Breedte: 85 cm
Diepte: 130 cm
Hoogte: 141 cm
Maximaal gewicht: 500 kg
Breedte schacht: 118 cm
Afstand tafel-wand: 104 cm. Wel is het mogelijk deze tafels eenmalig te verschuiven voor de robot.
Veiligheid
Voedselveiligheid
Uit de Nederlandse Voedselveiligheidseisen konden we het volgende concluderen:
"Belangrijk is dus dat in de bezorgrobot de temperatuur gecontroleerd kan worden. Warme producten moeten bij een temperatuur van minimaal 60 graden bij de gebruiker bezorgd worden, koude producten bij maximaal 7 graden.Voor het meten van deze temperatuur is een infraroodthemperatuurmeter verboden. Het voedsel wordt bezorgd door heel Metaforum dus moet rekening gehouden worden met verontreiniging. Na elke levering moeten de lades schoongemaakt worden, daarnaast moeten verschillende voedingsmiddelen gescheiden van elkaar vervoerd worden."
In het stuk Uiterlijk en Functionaliteit zal besproken worden hoe de temperaturen gewaarborgd worden.
Na het interview met de medewerkers van Eurest zijn wij tot de conclusie gekomen dat wij beter kunnen werken met kastjes in plaats van laden. In dit geval is aan de eis dat kastjes na elke bestelling kort schoongemaakt moeten worden goed te voldoen. Door kastjes van verschillende formaten te maken kan ook aan de eis dat verschillende soorten voedsel gescheiden vervoerd moeten worden voldaan worden.
Veiligheidssysteem robot
Op het gebied van veiligheid rond autonome voertuigen is al veel onderzoek gedaan. Over het algemeen moet een zelfrijdende robot de volgende drie eisen voldoen: [2]
- Het herkennen van fouten, storingen of andere gevaren.
- De gevolgen van deze gevaren evalueren.
- Een beslissing nemen op basis van deze gevolgen.
Neem nu bijvoorbeeld KARIS. [3]
KARIS is een robot die in de industrie autonoom allerlei producten kan bezorgen. Door middel van twee laser scanners, een traagheidssensor, een gyrosensor en een ingebouwde roadmap kan de robot autonoom zijn route door het gebouw vinden.
Om een botsing met een mens te voorkomen wordt gebruik gemaakt van laser scanners. Deze scanners spannen een ‘protected field’ op en zodra er een mens binnen dit gebied komt stopt de robot. Om de grootte van dit ‘protected field’ te bepalen is de remweg van de robot van belang. Nu is het zo dat de robot een niet al te grootte versnelling mag hebben. Dit heeft namelijk als gevolg dat het voedsel dat de robot mee voert niet goed blijft en dat het drinken gaat morsen. Maar omdat de veiligheid van mensen boven voedselveiligheid gaat kijken we eerst naar het geval waarin dit niet van belang is. In dit geval geldt:
[math]\displaystyle{ a_{rem}=u \cdot g \hbox{ m/s}^2 }[/math]
U is in dit geval de minimale wrijvingscoëfficiënt en g de gravitatiekracht. Een materiaal dat veel gebruikt wordt voor wielen is vulkollan. De minimale wrijvingscoëfficiënt van dit materiaal op verschillende vloeren is 0.425. De zwaartekracht op aarde is [math]\displaystyle{ 9.81 \hbox{ m/s}^2 }[/math]. Dus geldt:
[math]\displaystyle{ a_{rem}=0.425 \cdot 9.81 \hbox{ m/s}^2=4.17 \hbox{ m/s}^2. }[/math]
Nu geldt:
[math]\displaystyle{ s_{rem}=\frac{v^2}{2\cdot a_{rem}} }[/math]
Dit levert de volgende grafiek:
In dit geval gaan we er dus wel vanuit dat een robot alles in het bereik van de scanners kan zien. Zo bijvoorbeeld ook spullen die laag op de grond liggen. Merk hierbij op dat de remversnelling maximaal [math]\displaystyle{ 4.17 \hbox{ m/s}^2 }[/math] is. Om deze reden zijn er ook enkele plots gemaakt voor lagere remversnelling:
De remweg is dus de straal van het gebied dat de scanners zouden moeten opspannen. Echter moeten hiervoor afwegingen gemaakt worden. Een hogere snelheid heeft als gevold dat de robot een grotere remweg heeft en dus sneller voor mensen moet stoppen. Evenzo moet een afweging gemaakt worden tussen een hogere remversnelling (maar minder goed voedsel) en een lagere remversnelling (en dus vaker moet stoppen).
Om obstakels op de vloer extra goed te observeren kan ook een techniek genaamd ‘Blind Man Stick’ helpen. In dit geval meet de robot continu de afstand tot de vloer een stuk voor hem. Als deze afstand afwijkt van wat deze zou moeten zijn ligt er dus een obstakel op de vloer.
Het veiligheidssysteem dat KARIS gebruikt zou ook voor onze bezorgrobot gebruikt kunnen worden. Maar dit is niet de enige optie waar onderzoek naar is gedaan. Zo zijn er dus vele veiligheidssystemen die geschikt zijn voor onze robot.
Snelheid
In de vorige sectie is gebleken dat de snelheid van de robot een grote invloed heeft op de veiligheid. Wij hebben besloten om de robot een maximum snelheid te geven van 1 m/s. Dit heeft de volgende redenen:
Ten eerste is dit ongeveer de snelheid van een mens die (niet al te snel) loopt. In Metaforum lopen mensen namelijk meestal iets langzamer dan gemiddeld. Dat de robot ongeveer even snel loopt als de mensen in Metaforum heeft verschillende voordelen die niet direct met veiligheid betrekking hebben:
- Mensen hoeven niet aan de kans omdat de robot sneller gaat dan zij lopen.
- Aan de andere kant hoeven mensen ook niet te wachten op de robot omdat deze te langzaam gaat.
- Op deze manier ontstaat er dus minder chaos in de looppatronen van mensen in het metaforum. Het gevolg is dat omstanders minder last hebben van de gevolgen van de robot.
Daarnaast zijn er verschillende voordelen vanuit een veiligheidsperspectief. Zo is de impact van een botsing van een robot met een mens ongeveer gelijk aan de impact als twee mensen tegen elkaar aanlopen, of als een mens hard tegen een obstakel aan loopt. Hierbij loopt de mens over het algemeen nooit ernstige verwondingen op, de robot heeft namelijk ook geen scherpe randen, punten of andere uitstekels. Daarnaast is de remweg van de robot bij deze snelheid niet groot (zie vorige sectie) dus de robot zal al afgeremd zijn voor deze werkelijk tegen een mens aan botst als deze botsing onvoorkombaar is. Ten slotte kan een mens met voedsel in zijn/haar hand rustig stoppen zonder dan het voedsel daar schade aan ondervindt. Dit maakt dat de robot bij deze snelheid dus ook veilig genoeg is voor het voedsel dat het vervoerd.
Grootte robot
Naast de snelheid zijn er enkele andere aspecten die van invloed zijn op de veiligheid van de robot.
Het eerste is geluidsfeedback. Uit de interviews met het personeel van Eurest bleek dat zij spraak wensten bij de robot om klantvriendelijkheid te verhogen. Het vermogen van de robot om te spreken of om geluid te kunnen maken zou gebruikt kunnen worden door de robot om opgemerkt te worden.
Daarnaast is het uiterlijk van de robot van belang. Niet alleen wordt een grotere robot eerder opgemerkt, een kleur kan de robot ook opvallender maken. Denk hierbij aan bijvoorbeeld gele vlakken op de robot. Naast dat de robot hierdoor herkenbaarder wordt, past deze daarmee ook goed in de omgeving van het Metaforum.
Bescherming diefstal
Om het voedsel tegen diefstal te beschermen worden de kastjes waar het voedsel inkomt afgesloten. Deze kunnen door de student zelf geopend worden als de bestelling bezorgd wordt. Hoe dit precies in zijn werking gaat, wordt in de sectie Uiterlijk en Functionaliteit uitgelegd.
Eurest
De komst van deze robot zal natuurlijk veel gevolgen hebben voor het huidige personeel van Eurest. Hieronder worden enkele gevolgen besproken. Daarnaast is natuurlijk de bereidheid van het aanschaffen van de robot van belang. Ook deze zal besproken worden.
Waardigheid van het kantinepersoneel
Een van de grote vragen die het invoeren van een robot op de werkvloer automatisch met zich mee brengt is de waardigheid van het personeel dat deze taken nu uitvoert. Dit zou namelijk beschadigd kunnen worden door samen te moeten werken met deze robot. In plaats van zelf klanten te bedienen wordt een deel van het personeel ingezet als 'hulpje' van een robot die hiervoor zal gaan zorgen.
Echter toen wij met Eurest praatten was dit totaal geen probleem. Zij zijn juist blij als de robot hun huidige taken wat verlicht. Uit het interview bleek dat medewerkers van Eurest erg blij zouden zijn met de komst van de robot. Neem bijvoorbeeld het legen van de prullenbak op de eerste verdieping. Op dit moment moet iemand van het personeel met een kar (die naar de eerste verdieping wordt gebracht met behulp van de dienstlift, terwijl het personeel de trap moet nemen) naar de eerste verdieping gebracht. Hier moeten alle vuilnisbakken, die vaak niet eens vol zitten maar vooral aangeduwd moeten worden, geleegd worden. Er moeten nieuwe vuilniszakken opgehangen worden. De medewerker moet weer naar beneden. De kar moet naar beneden worden gehaald. De vuilniszakken moeten weggegooid worden etc. En dit moet allemaal gebeuren op een moment dat het in de kantine op topdrukte is. Naast dat de robot de topdrukte in de pauze iets verlicht heeft deze ook een prullenbak. Voor personeel is het nu niet alleen veel makkelijk om vuilniszakken te verwisselen maar ook om het vuilnis even aan te duwen en vervolgens de robot met een nieuwe lading voedsel weer op pas te sturen.
Werkgelegenheid
Een ander gevolg dat vaak op treed bij het invoeren van een robot op de werkvloer is een banenshift. In dit geval zal deze banenshift niet erg groot worden. De taken van huidige medewerkers van Eurest zullen iets veranderen maar hier is geen speciale technische kennis voor nodig. Er zullen ook weinig banen verdwijnen maar deze zullen voornamelijk verlicht worden. Een speciale technische dienst op de TU/e is waarschijnlijk niet nodig. Het is waarschijnlijker dat het bedrijf (of de groep) die deze robot ontwikkelt, langs komt als er een probleem is. Het is namelijk niet zo dat de kantine niet zonder robot zou kunnen als deze uit zou vallen. Dit heeft als gevolg dat de wachttijd op hulp bij de robot lang mag zijn en dus is iemand op de TU/e die van de techniek van de robot af weet overbodig.
Bereidheid tot aanschaffen
Uit de verschillende interviews bleek dat Eurest interesse had in de komst van de robot. Niet alleen de kantinemedewerkers van Eurest vonden het geweldig omdat dit hen taken verlicht maar ook Eurest zelf. Dit zou namelijk een mooie aanvulling zijn op de huidige services van Eurest en is daarnaast een mooi reclamemiddel.
Onderbouwing USE keuzes
Algemeen
Soort robot
Bij de keuze voor wat voor design we zouden gaan hebben we ons laten leiden door wat voor de users het minst storend zou zijn, voor de enterprise het beste rendement oplevert en voor de society het meest accepteerbare.
- Drone: Te veel lawaai
- De drone zou onveilige situaties kunnen creëren en geluidsoverlast veroorzaken voor de users. Verder zou het hoge energie verbruik de kosten en risico’s voor de enterprise vergroten.
- Monorail: Afbreuk aan ontwerp pand + lastig te verwezenlijken
- Voor de monorail zijn ook problemen. Ten eerste zou een rail afbreuk doen aan het Metaforum wat problemen levert voor de society. Ten tweede is het vrijwel niet te verwezenlijken vanwege zowel de kosten als het aanleggen van de infrastructuur zelf.
Vorm
Voor de vorm is ook nagedacht aan wat de wens is van de verschillende USE aspecten.
- Niet-humanoïde: Niet gewenst door users + lastig ontwerp
- Zo gaven de users aan dat ze niet graag een humanoïde robot wilden, wat ook technisch lastig te realiseren valt. Ook de enterprise gaf aan dat een rijdend karretje een realistischer beeld is.
- Grootte: Klein is fijn, maar groot voorkomt stoot
- Voor de grootte valt meer te zeggen. Voor de users moet de robot niet zo groot zijn dat het stoort en zij zien de robot dan het liefst niet zo groot. De enterprise vindt eerder dat een grote opvallende robot meewerkt aan zowel de bekendheid van Eurest als voor de veiligheid, aangezien een grotere robot beter opvalt en er daardoor minder ongelukken gebeuren.
Inlogsysteem
- Gebruik campuskaart
- Voor het openen van de kastjes hebben we gekozen voor een systeem dat voor alle studenten en medewerkers van de TUe beschikbaar is, namelijk met behulp van de campuskaart. Dit systeem maakt het voor de robots makkelijk om te verwerken van wie welke bestelling zou moeten zijn wat belangrijk is voor de enterprise. Verder is het makkelijk te gebruiken en is het dus voor de users ook een goed systeem.
Extra's
- Afvalverwerking
- Het afleveren van het voedsel vereist ook een mate van ophalen van het afval. Zowel de users die gebruik zullen maken van de robot als de user medewerkers van de kantine geven aan dat afval een probleem vormt. Door een prullenbak in te bouwen wordt een deel van dit probleem verholpen.
- Extra's vanuit de enterprise
- Eurest is verplicht om extra’s als bestek te leveren. Vanuit de enterprise wordt dus gevraagd om een mogelijkheid om bestek en dergelijke te kunnen leveren. Dit heeft geleid tot het toevoegen van de bestekbak.
Wettelijke eisen
Conclusie
Wettelijk zijn er meerdere constraints, maar slechts een aantal daarvan zijn van toepassing op onze robot.
- Temperatuurcontrole: Minimaal 60 warm, maximaal 7 koud
- Een belangrijk punt is dat de temperatuur gecontroleerd kan worden zodat voedsel op de juiste temperatuur wordt aangeleverd. Dit heeft geleid tot de keuze voor verschillende kastjes voor warme en koude soorten voedsel, waarbij in warme ruimtes een warmtelamp en ventilatie de temperatuur garandeert met minimaal kwaliteitsverlies. Koude ruimtes worden alleen geventileerd.
- Geen infraroodtemperatuurmeter
- Voor het vaststellen van de temperatuur van het voedsel mogen geen infraroodmiddelen gebruikt worden.
- Verontreiniging: Regelmatige schoonmaak
- Ook moet hygiëne gegarandeerd worden als eis van de society voor de user. Dit heeft gevolgen voor de user medewerkers omdat deze de robot schoon moeten maken na elke levering.
Uiterlijk
- Kreukelzone: Veiligheid
- Aan de voor en achterzijde is een kreukelzone ingebouwd met als doel de veiligheid van de omstanders (users) te beschermen. Door de kreukelzone wordt de kans op letsel geminimaliseerd omdat de kreukelzone bol is gevormd. Dit is veel minder schadelijk in geval van een ongeluk dan scherpe randen en hoeken.
- Kleur: Veiligheid en Omgeving
- Voor de kleur hebben we gekozen voor redelijk felle kleuren zodat de robot goed opvalt in zijn omgeving. Dit zorgt ervoor dat mensen de robot makkelijker kunnen opmerken en eventueel aan de kant gaan om ongelukken te voorkomen.
- Verder hebben we ook gekeken naar het kleuren schema waarop het Metaforum gebaseerd is, zodat de robot daadwerkelijk past bij het Metaforum. Dit is gedaan zowel voor acceptatie, aangezien niemand blij wordt van een robot die vloekt met het gebouw, als met oogpunt op het voortzetten van het architectonische ontwerp van het Metaforum.
- Om deze reden maken we gebruik van de kleurencombinatie geel-blauw. Geel is de kleur van het Metaforum en blauw wordt veel verwerkt in de wat kleinere details als wegwijzerbordjes. Verder is geel het type felle kleur wat goed helpt met opvallen met betrekking tot de veiligheid.
- Omdat de voor en achterkant het meest moeten opvallen zijn deze geel gekleurd en omdat felle kleuren er sneller vies uitzien zien de delen die interactie vertonen met mensen gekleurd met het donkerdere blauw.
Algorithmic Design
Pathfinding
- Zie verderop bij navigatiehulpmiddelen.
Scheduling
- Om voor de users een zo prettig mogelijk systeem te hebben zijn de meest noodzakelijke punten waarop gecontroleerd moet worden het minimaliseren van het aantal robots, wat ook voor de enterprise erg belangrijk is qua kosten, het beperken van variatie in bezorgtijd en het zo vers mogelijk houden van het voedsel. Het zo vers mogelijk houden van het
Infrastructuur
Deuren
- Omdat deuren vaak niet automatisch zijn, is dit een belemmering voor de ruimte waardoor de robot zich kan bewegen. Om dit te verhelpen is het theoretisch mogelijk alle deuren te vervangen, maar dit brengt veel kosten met zich mee en is daarom voor de enterprise geen aanlokkelijke gedachte. Hierom is besloten de robot alleen op de eerste verdieping van het Metaforum te laten bezorgen, aangezien dit een grote open ruimte is.
Lift
- De kantine zit op de begane gronde en de robot bezorgt op de eerste. Aangezien de robot in de kantine wordt ingeladen is er een noodzakelijkheid tot het gebruik van de lift. Omdat de gewone liften te vaak gebruikt worden door users is dit geen goede lift, maar de werk lift naar de kantine zelf is wel een goede lift. Deze is nog niet gebouwd op automatisch gebruik maar in gesprekken met Eurest als enterprise is gebleken dat eventuele aanpassingen aan de lift wel te verwezenlijken zijn.
Laadstation
- Voor de user medewerkers van de kantine is het gewenst dat de robot kan worden ingeladen met genoeg ruimte om dit te kunnen uitvoeren. Idealiter kan de robot gelijktijdig worden opgeladen, wat betekend dat het laadstation genoeg ruimte overlaat voor de medewerkers om hun werk te kunnen doen.
- Door lijnen op de vloer te leggen wordt het makkelijker voor de robot om zijn route vast te houden en niet vast te komen te zitten. Uit de enquête is gebleken dat het merendeel van de users er geen problemen mee zouden hebben als er lijnen worden toegevoegd aan het Metaforum om de infrastructuur van de robot mogelijk te maken.
Bezorgpunten
- Er is gekozen voor het bezorgen aan de uiteinden van tafels aangezien dit de enige manier is om te voldoen aan de eisen gesteld vanuit de enterprise en society. Dit is een vermindering van het comfort van de users, want uit de enquête blijkt dat de users het liefst persoonlijke bezorging zouden krijgen. Echter geeft de enquête ook aan dat de maximale afhaalafstand 5 meter is, wat betekend dat users bereid zijn om op te staan om hun eten op te halen.
Uiterlijk en Functionaliteit
Grootte robot/kastjes
Gewenste formaat
Het design van de robot is sterk afhankelijk van de maximale grootte van de robot. Uit de enquête is gebleken dat een gemiddelde hoogte, het meest gewenst is onder de users. Gekeken naar de gebruikte afbeelding, zou dit rond heuphoogte van een gemiddeld mens zijn. Gebruik makende van de afbeeling uit National Geographic zou dit tussen de 0.80 en 1 meter hoog zijn. Wij streven dus naar een robot met deze hoogte.
Daarnaast moet de robot door het Metafurum rijden en dit levert ook enkele eisen op de grootte van de robot. Het belangrijkste hiervoor is de grootte van de lift. Zoals eerder genoemd zal de robot gebruik maken van de dienstlift van Eurest. Dit met de reden dat de normale liften in Metaforum zeker in de pauze zeer druk zijn en wij niet meer druk op dit systeem willen uitoefenen. Daarnaast is de gang van de kantine naar de gewone liften zó smal dat dit zeer strenge esen zou leggen op het formaat van de robot. In de keuken van Eurest (waar de dienstlift uit komt) is echter voldoende ruimte. Dit heeft als gevolg. De robot hoeft niet tussen tafels door (de robot zal het eten aan het uiteinde van de tafel bezorgen) en dus levert dit geen extra eisen op voor de grootte van de robot. De afmetingen van de lift zijn als volgt:
- Breedte: 85 cm
- Diepte: 130 cm
- Hoogte: 141 cm
Omdat de robot autonoom de lift in en uit moet rijden is het verstandig om wat speling tussen de robot en de lift te hebben. Dit zal uiteindelijk ook minder beschadigingen aan de robot opleveren. Als een lift omhoog of omlaag gaat zal deze namelijk is trillen en als de robot tegen de wand aan staat kan dit schade veroorzaken aan de robot. Om deze reden zijn de maximale afmetingen van de robot gelijk aan:
- Breedte: 75 cm
- Diepte: 120 cm
- Hoogte: 135 cm
Kastjes
Er is gekozen voor het gebruik van kastjes voor het voedel. Ten eerste is omdat de berging van het voedsel beveiligd moet zijn tegen diestal gekozen voor een afgesloten ruimte waarin het voedsel vervoerd wordt. Deze ruimtes gaan open met behulp van een inlogsysteem. (Zie Veiligheid voor meer informatie.) Daarna was er de keuze tussen laden en kastjes. Ons eerste idee om laden te gebruiken is ons afgeraden door Eurest. Naast dat het veel ruimte in neemt, moeten zij na elke bezorging zorgen dat de bergingsruimte van het voedsel schoon is. Echter is het voor medewerkers van Eurest lastiger om deze laden schoon te houden dan kastjes. Om deze redenen hebben wij dus voor kastjes gekozen om het voedsel tijdens het bezorgen in op te bergen.
Soorten voedsel
Voordat naar de grootte van de laden gekeken kan worden is van belang welke soorten voedsel vervoerd kunnen worden met de serveer robot. Mede door de strenge eisen over de bezorgtijd van Eurest is ervoor gekozen om niet alle soorten voedsel te bezorgen. Wij zullen warme maaltijden die niet lang in een afgesloten ruimte mogen liggen dus niet bezorgen. Wél heeft Eurest op dit moment panini"s en kleine broodjes zoals sucijzenbroodjes en worstenbroodjes op dit moment ook voor langere tijd onder een warmtelamp liggen. Omdat de kastjes aangepast zullen worden op het soort voedsel hebben wij er dus voor gekozen om de volgende soorten voedsel te bezorgen die in het huisige assortiment van Eurest (in metaforum) zitten:
- Koude dranken (denk hierbij aan flesjes water, cola, fanta etc)
- Warme dranken (zoals koffie en warme chocolademelk)
- Soep
- Belegde stokbroden
- Panini's
- Kleine broodjes zoals sucijzenbroodjes en worstenbroodjes (de broodjes die dus wel voor langere tijd in een afgesloten ruimte kunnen liggen.
Het voordeel van het beperken van het aantal soorten voedsel dat de robot bezorgt, heeft nog meer voordelen. Ten eerste wordt de druk op de robot kleiner. Als alle 600 mensen die normaal in de pauze eten uit de kantine halen, nu de robot zouden gebruiken zou de druk hierop te groot worden. Op deze manier verminderen wij de druk. Daarnaast hoeven er bijvoorbeeld geen vriesvakjes in de robot omdat Eurest ook ijs verkoopt terwijl dit bijvoorbeeld in de winter amper verkocht wordt. Zo'n vriesvakje koelen zou veel energie kosten en naast dat dit verspilling is, zouden deze vakjes ook veel ruimte innemen in de robot. Daarnaast hebben deze soorten voedsel allemaal vaste afmetingen. Zo variëert het formaat van een flesje drinken niet veel en komen soep en warme dranken altijd in dezelfde bekertjes. De formaten van de soorten voedsel zijn als volgt:
- Koude dranken: 6x6x21 cm
- Warme dranken: 5x5x8 cm
- Soep: 8x8x8 cm
- Belegde stokbroden: 5x35x5 cm
- Panini's: 8x30x3 cm
- Kleine broodjes: 15x10x3
Soorten kastjes
De formaten die de kastjes zullen krijgen zijn speciaal aan deze formaten aangepast. Ten eerste zijn er de warme en koude dranken. Voor deze soorten voedsel zijn de formaten van de kastjes als volgt: 25x10x10cm. Op deze manier passen alle soorten drinken in deze vakjes. Deze vakjes zullen nog wel gesplitst moeten worden in twee soorten: koude en warme kastjes. Deze kastjes zijn type 1. Voor de belegde stokbroden en panini's zijn de formaten als volgt: 20x15x10cm. Ook van deze kastjes zullen twee soorten gemaakt moeten worden. Alleen hoeft er in dit gevoel geen voedsel gekoeld te worden maar blijven de stokbroden het lekkerst op kamertemperatuur. Deze kastjes heten type 2. Het laatste soort kastje, type 3, is voor de kleine broodjes en de soep en heeft het volgende formaat: 20x15x10cm. Dit soort broodjes zal allemaal verwarmd moeten worden.
Kastensysteem
Eerder in deze sectie zjin de gewenste en uiterlijke grootte van de robot vermeld. In deze ruimte zullen zo veel mogelijk kastjes geplaatst worden om zo veel mogelijk mensen van eten te voorzien. Dit levert het volgende: aan alke zijwand (dus linker er rechter zijwand) van de robot liggen ten eerste 6 kastjes van Type 1, daarnaast 4 kastjes van type 2 en ten slotte 8 kastjes van type 3. Dit ziet er als volgt uit:
De wanden tussen kastjes en de buitenwanden zijn elk 2 cm dik. Hierin kan bijvoorbeeld bedrading komen mocht dit nodig zijn voor sloten etc. Daarnaast leverten deze wanden van 2 cm een isolatielaag waardoor de robot minder energie nodig heeft om het voedsel warm of koud te houden. De robot heeft dus een totale hoogte van 74 cm en het gedeelte van de laden heeft dus een lengte van 90 cm. Aan de voor en achterkant van de robot komen nog wel kreukelzones voor het geval dat er een botsing op treedt. Deze ruimte zal een bolle vorm hebben om schade door hoeken en scherpe randen te voorkomen en zal een dikte hebben van 15 cm. De totale lengte van de robot wordt dus 120 cm.
Naast het kastensysteem aan de zijkant van de robot komen er ook nog 4 kastjes op de bovenkant. Hiervan zijn er 2 van type 1 en 2 van type 2. Dit ziet er dus als volgt uit:
Ten slotte moet de temperatuur in elk van deze kastjes bepaald worden. Het warme voedsel moet bewaard worden bij een temperatuur van 60 graden en het koude voedsel bij een temperatuur van 5 graden.
- Type 1: In de kastjes van type 1 komen de warme dranken en koude dranken en in het geval dat er ruimte over is ook soep. Deze kastjes moeten dus verdeeld zijn in kastjes met een warme en kastjes met een koude temperatuur. Deze verdeling is ongeveer half om half (afhankelijk van de tijd van de dag). Er zijn dus 7 warme kastjes en 7 koude kastjes.
- Type 2: In deze kastjes komen de stokbroden en de panini's. Ook hier verwachten we een verdeling van ongeveer half om half. Er zijn dus 5 warme kastjes en 5 koude kastjes.
- Type 3: In deze kastjes wordt alleen warm voedsel geserveerd. Indien nodig kan hierin ook warme soep vervoerd worden.
Om energieverspilling te voorkomen is het het beste om warme kastjes bij elkaar te plaatsen. Om deze reden is besloten de kastjes op de volgende manier in warm en koud te verdelen:
Extra's
Naast dat er in de robot ruimte moet zijn voor de laden zitten er in de robot onder andere ook accu's, verwarmingselementen etc. Hiervoor is ruimte overgelaten in het midden van de robot, tussen de laden aan de linker en rechter zijde van de robot. Maar naast dat er in dit gedeelte elektrische componenten zitten moet er ook ruimte zijn voor enkele wensen van Eurest. Ten eerste biedt Eurest bij het voedsel servetten, bestek en zout en peper aan. Hiervoor is ruimte aan de bovenkant van de robot gereserveert. Deze ruimte heeft een afmeting van 12x40cm en is 10cm diep. Deze bak kan bijvoorbeeld als volgt ingedeeld worden:
In dit geval zijn de formaten van elke bak als volgt:
- Servetten: 12x25cm. De servetten van Eurest zijn 24x24cm en passen dus precies staand in deze bak. Een ander idee is om de servetten nog maals dubbel te vouwen en als een stapel in deze bak te leggen. Eurest kan hierin zelf beslissen waaraan zij voorkeur geven.
- Lepels, messen en vorken. Elk van deze bakken is 5x8cm. Dit is veel kleiner dan de bakken die Eurest op dit moment heeft staan voor bestek. Toch zouden deze bakken ruim voldoende moeten zijn om het bestek voor één levering in te zetten. Na elke levering kunnen deze bakken bijgevuld worden.
- De bakken voor zout en peper hebben de volgende afmetingen: 4x7.5cm. Dit klinkt klein maar omdat de bakken 10cm diep zijn, is er genoeg ruimte voor zout en peper.
Naast ruimte voor servetten, bestek, zout en peper maakte de medewerkers van Eurest ook duidelijk dat zij behoefte hebben aan ruimte voor een prullebak in de robot. Om deze reden is er aan de binnenkant van de robot ook ruimte overgelaten voor een vuilniszak. Aan de bovenkant is er ruimte waar het afval in gegooid kan worden. Daarnaast kan dit gedeelte van de robot geopend worden aan de bovenkant om de vuilniszak te vervangen.
De bovenkant van de robot ziet er uieindelijk dus als volgt uit:
Totale grootte
In de sectie kastensysteem stond al beschreven dat de robot een totale lengte zal hebben van 120cm en een hoogte van 74 centimeter. Om daarnaast genoeg ruimte te hebben voor onder andere de bestekbak, prullenbak en elektronische onderdelen zal de robot een breedte krijgen van 70cm.
Beveiliging
Veiligheid vs gemak
In de enquête is de volgende vraag gesteld: 'Wat vind je belangrijker in deze robot, weerstand tegen diefstal of meer gemak bij het openmaken?' Het resultaat was dat van de 150 mensen 57% een voorkeur heeft voor veiligheid boven gemak. Toch is er nog 43% dat liever meer gemak heeft bij het openmaken. Dit betekent dat wij een systeem zoeken waarbij de kasten afgesloten zijn, om diefstal te voorkomen. Het openen van de kastjes moet echter niet te moeilijk zijn. Om deze reden hebben wij gekozen voor het systeem wat de printer op de TU/e op dit moment ook gebruiken. Dit systeem werkt als volgt: Bij het eerste gebruik logt een student in op de printers met zijn/haar s-nummer en het bijbehorende wachtwoord. Daarna houdt de student zijn/haar studentenpas voor de scanner. Op dit moment koppelt de printer het s-nummer aan de studentenpas. Als de student daarna vanaf zijn/haar (persoonlijke) laptop print, hoeft hij/zij alleen nog maar zijn/haar studentenpas voor een willekeurige printer te houden en de documenten worden hierop geprint. Omdat de meeste studenten wel eens gebruik gemaakt hebben van dit systeem zijn de meeste s-nummers dus ook al aan studentenpas gekoppeld.
Het systeem dat de printers op dit moment gebruiken willen wij als volgt toepassen op onze robot: Een student zal zich eenmalig moeten aanmelden om gebruik te maken van deze service. Eurest staat namelijk los van de TU/e en heeft dus geen inzicht in de wachtwoorden van de TU/e. Een oplossing hiervoor is dat bij het aanmelden een activatiemail gestuurd wordt naar de studentenmail van de student. De naam van een student kan namelijk wel aan zijn/haar s-nummer gekoppeld worden. Als op de link in de activatiemail wordt geklikt kan een wachtwoord ingesteld worden. Vanaf dit moment kan de student op de site/app inloggen met zijn/haar s-nummer en zelfgekozen wachtwoord. De volgende stap is om een studentenkaart te koppelen aan het s-nummer. Voor de meeste studenten zal dit al gebeurt zijn bij gebruik van de printers. Het is niet de bedoeling dat dit koppelen ook op de robot kan. Dit kan namelijk veel tijd kosten terwijl mensen op hen eten zitten te wachten. Daarnaast is een scherm op de robot overbodig, kost veel geld, en heeft een grote kans op schade op te lopen. Een student zal dit dus nog steeds bij de printers moeten doen. Een andere optie is dat bij de kantine een paal komt te staan waarop een student zijn campuskaart aan zijn/haar s-nummer kan koppelen. Nadat een campuskaart gekoppeld is aan het s-nummer van de student is het mogelijk om via de site/app in te loggen, eten te bestellen en dit op te halen bij de robot door de campuskaart voor de scanner te houden. Als de scanner een campuskaart herkent zullen vervolgens de deurtjes van de kastjes, waarin het voedsel van de student zich bevindt, opengaan.
Gevolgen Eurest
Het gebruik van dit veilige en gebruiksvriendelijke systeem heeft wel gevolgen voor de medewerkers van Eurest. Zij zullen dus niet alleen op een scherm te zien krijgen welke bestellingen gedaan zijn, maar ook in wel vakje welke bestelling moet. Daarnaast zal personeel een kaart moeten hebben dat tegen de scanner aangehouden kan worden waardoor alle kastjes open gaan.
Hoe dichtbij levert de robot het voedsel af bij de gebruiker?
Wensen gebruikers
Uit de enquête blijkt dat een afhaalafstand van ongeveer 5 meter het meest wenselijk is. Het idee is dat de robot kan stoppen aan de kop van elke tafel en dat studenten vanaf daar hun bestelling kunnen ophalen. Dit valt net binnen de wensen van de users en is relatief makkelijk te implementeren.
Hoe en wanneer wordt de robot opgeladen?
Bij het cafetaria komt een laadstation en wachtruimte voor de robots, waar de robots kunnen opladen en wachten tot ze weer nodig zijn. Het laadsysteem gaat via een contactplaat aan de onderkant, waarmee contact gemaakt wordt met elektrische circuits in de grond van het laad station.
Uiterlijk
Zoals eerder genoemd heeft de robot een totale grootte van 120x70x74cm. Dit is echter zonder de wielen mee gerekend. Aan de voor en achterzijde van de robot heeft de robot een zogenaamde 'kreukelzone'. Deze loze ruimte is bol gevormd zodat een mens bij een botsing zo min mogelijk schade op loopt. Scherpe randen en hoeken hebben namelijk een veel grotere impact dan een afgeronde vorm. Verder zal de robot naast afgeronde randen een redelijk de vorm van een balk behouden.
Voor de kleur van de robot hebben wij op twee dingen gelet: veiligheid en omgeving.
- Veiligheid: Des te feller de robot gekleurd des te beter deze opvalt in zijn omgeving tussen mensen. En dit zorgt ervoor dat mensen de robot beter opmerken waardoor de kans op een aanrijding kleiner wordt.
- Omgeving: Het gebouw heeft na zijn transformatie van W-hal naar Metaforum meerdere architectonische prijzen gewonnen waaronder de LEAF Award 2013. De Tu/e is zeer trots op dit gebouw en dus zou het mooi zijn als de robot, bijvoorbeeld qua kleur, goed bij dit gebouw past.
Dit beide is mogelijk door de kleurcombinatie geel-blauw te gebruiken. Donkerblauw is een kleur die naast geel op dit moment in veel details voor komt in het Metaforum. Denk hierbij bijvoorbeeld aan de wegwijzerbordjes. Geel is daarnaast ook een opvallende kleur. Een compleet gele robot zou echter té veel worden. Studenten zouden hierdoor bijvoorbeeld afgeleid kunnen worden en geel is een kleur die snel vies wordt. Om deze redenen zijn donker blauw en geel dus goede kleuren voor de robot.
De voor- en achterkant van de robot moeten het meest opvallen. Om deze reden hebben wij ervoor gekozen deze kanten geel te maken. Op een lichte kleur is vuil snel zichtbaar en dit zou af kunnen doen aan het gevoel wat mensen over de kwaliteit van Eurest hebben. Om deze reden zullen de vakjes een blauwe kleur krijgen. De bovenkant van de robot bevat beide kleuren. In de animatie zijn deze kleuren uitgebreid weergegeven.
Tijd
Voor de users is het van belang dat zij een indacatie hebben over hoe lang de robot er over doet om hun voedsel te bezorgen. Hiervoor zal bekend moeten zijn hoe lang de robot over een rondje doet. Wij schatten deze tijd in op ongeveer 10 minuten. Wij gaan er namelijk van uit dat er minstens twee robots door het Metaforum zullen gaan rijden. Op deze manier kan ismajden terwijl de andere ingeladen wordt. Eurest heeft dan precies 5 minuten om de vakjes indien nodig schoon te maken en te vullen met nieuwe bestellingen. Hierna zal de robot zo'n 30 seconden met de lift moeten. In totaal zal de robot met 1 m/s ongeveer anderhalve minuut doen over het rijden naar een student (als deze het verst van de lift af zit). De afstand die in dit geval afgelegd moet worden is namelijk ongeveer gelijk aan 100 meter. Verder zal de robot tussendoor een paar keer moeten stoppen voor endere studenten. We gaan ervan uit dat als de robot helemaal vol zit, deze op één plek kan stoppen voor meerdere studenten. Op deze manier wordt veel tijd bespaart en kan de robot dus binnen 5 minuten bij de gebruiker zijn. Toch zal het lastig worden om deze 10 minuten te garanderen. Dit heeft voornamelijk te maken met studenten die vergeten hun lunch op te halen (zoals bijvoorbeeld als zij de melding op hun telefoon niet door hebben) of als er een obstakel op de lijn ligt waar de robot overheen moet.
Algorithmic Design
In dit hoofdstuk zullen we de verscheidene algoritmen beschrijven die kunnen komen kijken bij een robot als de onze. We zullen voor ieder van de problemen die de algoritmen kunnen oplossen voor de robot de beschikbare algoritmen beschrijven en tegen elkaar afwegen.
Pathfinding
Met de lijnen die op de vloer van het MetaForum geplaatst dienen te worden om onze robot te laten functioneren is de omgeving van de robot voor de robot met betrekking to het vinden van routes te vereenvoudigen tot een simpele graaf met een beperkt aantal knooppunten en gewogen zijdes. De knooppunten van deze graaf zijn de punten waarop de robots eten bezorgen en punten waarop de lijnen zich splitsen en weer samenvoegen. De lijnen tussen deze punten zijn de zijden van deze graaf. Omdat het een graaf betreft zijn er voldoende algoritmen beschikbaar om over deze graaf te navigeren.
Basisalgoritme
Omdat het MetaForum een simpele en eindige omgeving is zou het mogelijk zijn om van alle knopen de snelste route naar alle andere knopen een maal te berekenen en de robots uit te rusten met deze dataset. Op basis van deze dataset zouden robots dus de snelste route eenvoudig kunnen vinden. Hoewel dit een voordehandliggende oplossing zou zijn is deze niet praktisch. Het introduceren van meerdere robots en omgevingsinvloeden als rondlopende mensen en andere obstakels zorgt er namelijk voor dat een statische dataset ongeschikt is voor ons scenario. Het zou namelijk zo kunnen zijn dat een robot op een lijn rijdt waarop een andere robot in de tegengestelde richting rijdt. Nu zouden de robots langs elkaar kunnen rijden, maar dit maakt de breedte van de rijbaan die onze robots nodig hebben twee maal groot.
Een betere oplossing zou zijn om het alom bekende A* algoritme te gebruiken om de robots in real-time de snelste route te laten vinden. Door het gebruiken van een real-time algoritme zijn de observaties van de robot ook te verwerken in het interne model (de graaf) die de robots van de wereld (het MetaForum) hebben. De data dit de robots hebben kan onderling gedeeld worden om een nog completer beeld van de wereld te verkrijgen en daardoor dus nog efficiënter te werken. Het gewicht van de zijden in de graaf is de tijd die de robot nodig heeft om over de zijde te bewegen. In het begin kan dit een gok zijn. Zodra de robot in dienst is kan de robot het voortschrijdend gemiddelde van de daadwerkelijke tijden gebruiken. Zo optimaliseert de robot zichzelf tijdens het bedrijf en zal hij om kunnen gaan met veranderende omstandigheden. Ook zou het kunnen voorkomen dat er een recht stuk van de route van robot A op dit moment in beslag wordt genomen door een robot B die in de tegenovergestelde richting rijdt. Robot A kan nu met robot B communiceren en de tijd die robot B nog nodig heeft om het rechte stuk af te leggen op te vragen en dit in het gewicht van de zijde verwerken. Zo kan robot A beslissen om een andere route te nemen om het gebied waar robot B rijdt te vermijden, of om te wachten tot robot B van de route af is als dat tot een snellere bezorging zal leiden. De robots profiteren bij het delen van data dus niet alleen van data over de omgeving, maar ook data over de locatie van de robots zelf.
Hoewel de lijnen waarover onze robot navigeert natuurlijk impliceren dat mensen er niet op moeten gaan staan en er geen objecten op moeten achterlaten is het negeren van deze mogelijkheid natuurlijk niet verstandig. Als robots een obstakel detecteren dat niet te omzeilen is kunnen ze dit naar de andere robots communiceren. Alle robots kunnen dan de bijbehorende zijde in hun model een oneindige waarde geven om dit obstakel te mijden. Bestellingen naar bestemmingen die door dit obstakel onbereikbaar gemaakt worden zouden naar de catering geretourneerd kunnen worden en nieuwe bestellingen kunnen worden afgewezen. De catering kan dan van dit obstakel op de hoogte worden gesteld waarna ze actie kunnen ondernemen.
Een ander algoritme dat geschikt zou kunnen zijn is Dijksta's algoritme. Jammer genoeg is Dijksta's algoritme slechts een versimpelde versie van A* (eigenlijk is A* een geavanceerdere versie van Dijksta's algoritme) door het ontbreken van een heuristieke functie. Dit maakt Dijksta's algoritme minder geschikt indien er genoeg rekenkracht is voor het uitvoeren van A*. Dijkstra's Algoritme is echter wel zuiniger in het gebruik van werkgeheugen. Daar de verschillen verwaarloosbaar zijn zouden beiden een geschikte keuze zijn.
Uiteindelijk Algoritme
Het algoritme dat uiteindelijk het meest geschikt is voor ons probleem is een real-time algoritme dat on-the-fly routes over een graaf kan berekenen en herberekenen. Het meest gebruikte algoritme dat aan deze eisen voldoet is A*. Omdat het MetaForum geen "schuine" paden kent is de manhattan distance een zeer geschikte heuristiek. Het ontbreken van shuine paden maakt de manhattan distance niet alleen een consistente, maar ook een toegestane heuristiek. Andere geschikte heuristieke functies zouden de hemelsbrede afstand of simpelweg 0 zijn, maar deze zullen minder accuraat blijken dan de manhattan distance. TODO altijd beste pad, heuristiek slechts voor rekentijd belangrijk, etc. TODO simulatie met A* in aan het MF gelijkende omgeving?
Scheduling
Omdat de robots tot wel 40 orders tegelijk bij zich kunnen dragen is het niet mogelijk om met brute kracht de optimale volgorde voor bezorging te bepalen. De hoeveelheid mogelijkheden kan namelijk oplopen tot een verbluffende 40!, een getal met wel 48 decimalen. Hoewel het aantal locaties waar de robots naartoe moeten beperkt wordt doordat er minder dan 40 aflever punten zijn (pigeon hole principle) is dit nog niet voldoende om het probleem alsnog met brute bracht op te lossen. Gelukkig is ons probleem een redelijk bekend probleem dat de term Vehicle Routing Problem with Time Windows (VRPTW) draagt.
Bij het oplossen van een VRPTW probleem kunnen verschillende factoren geoptimaliseerd worden. Ten eerste kunnen de kosten van transport geminimaliseerd worden. Omdat het bij onze robots gaat om kleine afstanden en relatief zuinige elektromotoren zal de afstand die moet worden afgelegd geen grote rol spelen in de kosten van het systeem. Veel interessantere factoren zijn het aantal voertuigen minimaliseren, de hoeveelheid variatie tussen bezorgtijden minimaliseren en het voedsel zo vers mogelijk houden. Het minimaliseren van het aantal robots is in ons geval zeer belangrijk, daar de robots ongeveer TODO euro per stuk zullen gaan kosten. Ook een constante service bieden aan de gebruiker zal het gebruik van onze service een stuk aangenamer maken. Een gebruiker kan bij een lagere variatie in de bezorg tijd veel beter plannen. Als er bijvoorbeeld gegarandeerd wordt dat de robot altijd tussen de 3 en 5 minuten nodig zal hebben om de bestelling te bezorgen vanaf het moment van bestelling kan de gebruiker al 3 minuten voor het arriveren op het aflever punt bestellen en zal zo minder lang hoeven wachten. Tot slot is er het zo vers mogelijk houden van het voedsel. We denken dat die veruit de beste prestatie maatstaf is omdat de kwaliteit van het voedsel natuurlijk ten aller tijden gegarandeerd moet blijven.
Genetic Algorithm
Een oplossing voor het VRPTW is een genetic algorithm als beschreven in /Perishable goods Delivery and Scheduling with time window by Genetic Algorithm/. Dit is een algoritme dat op evolutie gebaseerde technieken relatief snel een oplossing voor het probleem kan vinden. Dit zijn echter wel relatief intensieve algoritmes die dus het beste op een centrale machine kunnen worden uitgevoerd. De robots met computers uitrusten die krachtig genoeg zijn om de volgorde te bepalen met een genetic algoritme zou namelijk zowel duur zijn als leiden tot een aanzienlijke hitte afgifte door de vereiste hardware.
Proces
In dit hoofdstuk zullen we het proces omtrent de robot beschrijven. Ten eerste zal er een beschrijving van het proces vanuit het perspectief van de gebruiker plaatsvinden. Daarna wordt dat aangevuld met een beschrijving van het proces vanuit het perspectief van de catering. Deze beschrijvingen zullen tot slot worden uitgedrukt in de vorm van een petrinet en vervolgens als dusdanig worden geanalyseerd.
Beschrijving
Uitzoeken
De gebruiker kan door het assortiment van de catering bladeren en producten aan hun order toevoegen. Zodra de gebruiker een product aan hun order wil toevoegen, wordt door het RoboCatering systeem de voorraad van dat product gecontroleerd. Als er geen of niet voldoende voorraad is krijgt de gebruiker hiervan een melding en wordt het product niet aan de order toegevoegd. De gebruiker kan voor het toevoegen van een product ook de order annuleren.
Bestellen
Als de gebruiker tevreden is mijn hun order kan ze besluiten om de order te bevestigen. De catering checkt dan opnieuw de voorraad. Als deze nog steeds voldoende is worden de bestelde producten tijdelijk van de voorraad afgetrokken. Zodra dit gebeurd is krijgt de order de status "confirmed". Als de voorraad niet voldoende is, krijgt de gebruiker hier een melding van en wordt de order niet bevestigd. De gebruiker kan dan de order aanpassen en opnieuw proberen. De gebruiker kan de order ook annuleren.
Betalen
Als de order is bevestigd, kan de gebruiker voor de artikelen betalen. Als de gebruiker heeft betaald, wordt de tijdelijke voorraadvermindering uit de vorige fase permanent gemaakt. Ook krijgt de order de status "paid". Als de gebruiker niet binnen vijf minuten betaald wordt de order geannuleerd en wordt de tijdelijke voorraadvermindering teruggedraaid.
Bereiden
Als de order de status betaald heeft gekregen zal de order door de catering in orde worden gemaakt. Zodra al de bestelde producten verzameld zijn gaat de status van de order van "paid" naar "ready". Zodra er genoeg orders op de robot staan of er een tijd van vijf minuten is verstreken zal de robot naar zijn bestemming vertrekken en krijgt de order de status "sent".
Transport
Zodra de robot arriveert bij de gebruiker kan de bestelling uit de robot genomen worden. De order zal dan de status "received" krijgen. Als de robot niet leeg is, zal deze door rijden naar andere gebruikers. Als de robot wel leeg is zal hij terug keren naar de catering en zullen de bestellingen als "complete" gemarkeerd worden. Als een gebruiker niet binnen 2 minuten na arriveren de bestelling uit de robot neemt, wordt de bestelling als "rejected" gemarkeerd en zal het betaalde geld (eventueel na aftrek van service kosten) worden terugbetaald aan de gebruiker. Ook zullen de artikelen die geretourneerd worden weer aan de voorraad toegevoegd worden. Artikelen die niet terug mogen nadat ze zich in de robot bevonden hebben, bijvoorbeeld door verminderde temperatuur of tijd sinds het bereiden kunnen door de catering weggegooid worden net als alle andere producten van een te lage kwaliteit.
Case Descriptions
Registeren
Hoofdsuccesscenario:
- 1. Student gaat naar de kantinepaal
- 2. Student scant zijn campuskaart
- 3. Student logt in met zijn s-nummer en stelt een wachtwoord in
- 4. Systeem registreert de nieuwe gegevens
- 5. Systeem stuurt een bevestigingsmail naar de TUe mail van de student
- 6. Student activeert zijn account via de link in de bevestigingsmail
Extensies:
- 6a: Link is verlopen
- 1. Student vraagt een nieuwe mail aan of doet niks en gegevens verlopen
Opwaarderen tegoed
Hoofdsuccesscenario:
- 1. Student gaat naar de webapp
- 2. Student logt in met zijn gegevens
- 3. Student gaat naar opwaarderen
- 4. Systeem toont de mogelijke bedragen
- 5. Student kiest een opwaardeerbedrag
- 6. Systeem toont betaalmethoden (bv iDeal)
- 7. Student kiest betaalmethode
- 8. Student vult alle gegevens in
- 9. Student accepteert de gegevens
- 10. Systeem rond de betaling af en laadt het saldo bij
Extensies:
- 5a: verschillende mogelijkheden
- 1. Student kiest een eenmalig opwaardeerbedrag of een automatische opwaardeer optie zodat een vast bedrag altijd op het account staat
- 10a: Fout bij afronden opwaarderen
- 1. Student stopt het opwaarderen en probeert opnieuw of stopt met opwaarderen en sluit de webapp
Bestelling
Hoofdsuccesscenario:
- 1. Student doorzoekt het menu van de app/webapp en stelt zijn menu samen
- 2. Student gaat naar het winkelwagentje
- 3. Systeem geeft de totale bestelling en de totale kosten weer
- 4. Student regelt de betaling en de afleverlocatie
- 5. Systeem autoriseert de betaling
- 6. Systeem bevestigd de verkoop
- 7. Systeem vermeld dat de bestelling succesvol is en verstuurt de bestelling naar het kantine personeel
- 8. Kantine personeel laadt een wachtende robot in
- 9. Robot vertrekt naar de afleverlocatie
- 10. Student logt in met campuskaart
- 11. Student pakt zijn bestelling
- 12. Robot gaat terug naar kantine
Extensies:
- 5a: Betaling mislukt of de afleverlocatie wordt niet geaccepteerd
- 1. Student vernieuwt de betalingsgegevens of stopt de bestelling
- 2. Student stelt opnieuw de afleverlocatie in of stopt de bestelling
- 12a: Er zijn mogelijk meerdere bestellingen
- 1. De robot gaat verder met de volgende bestelling of gaat terug naar de kantine indien alle bestellingen zijn afgehaald
Petrinet
Infrastructuur
Het gebruik van een robot stelt eisen aan de omgeving. De omgeving moet aangepast worden zodat de robot er kan werken. Er is geprobeerd de eisen tot een minimum te beperken door een relatief klein werkgebied (de eerste verdieping van het Metaforum) te kiezen.
Deuren
In het geval dat de robot door deuren moet kunnen, vereist dat grote aanpassingen aan de doorgangen die de robot zou gebruiken. Zelfs de voordehandliggende optie, de vervanging van de betreffende deuren door automatische schuifdeuren, brengt veel kosten met zich mee. Ook zijn schuifdeuren niet zonder meer op elke plek toe te passen. Door het werkgebied te beperken tot de eerste verdieping, wordt het probleem van deuren vermeden.
Lift
Aangezien de keuken op de begane grond is en de werkruimte van de robot de eerste verdieping beslaat, zal er een verticale afstand overbrugd moeten worden. Om de omgevingseisen zoveel mogelijk te beperken, kan de dienstlift in de buurt van de keuken hiervoor gebruikt worden. De robot is dan ook ontworpen met de afmetingen van die lift in gedachten.
Het gebruik van de lift door de robot is problematisch omdat de robot de huidige lift niet zelf kan bedienen. Een kantinemedewerker zou dit kunnen doen, maar hoewel dat werkt voor de weg omhoog is het nogal onpraktisch als de robot met de lift omlaag moet. De robot vult nagenoeg de hele lift, dus zou de medewerker de trap op en af moeten om de robot de lift binnen te laten. De meest efficiënte (en weinig ingrijpende) oplossing voor dit probleem is integratie van de liftelektronica met de robot. Als de robot een signaal naar de lift kan sturen dat hij naar de juiste verdieping moet komen, hoeft er geen mens aan te pas te komen.
Laadstation
De meest ingrijpende omgevingsverandering die nodig is voor de implementatie van de robot is de toevoeging van een laadstation waar de robot opgeladen en gevuld kan worden. Het opladen gebeurt via contactplaten onderin de robot en in de vloer van het station. Opvullen gebeurt handmatig door kantinemedewerkers. Er moet dus aan weerszijden van de robot genoeg ruimte zijn voor een persoon om bij alle vakjes te kunnen. Idealiter wordt het laadstation zo gepositioneerd dat het makkelijk bereikbaar is vanuit zowel de keuken als de dienstlift.
Om de robot door het Metaforum te loodsen, is er een systeem benodigd dat zijn locatie in real-time bijhoudt. Hiervoor zijn verschillende opties beschikbaar, elk met zijn eigen voor- en nadelen.
Een systeem gebaseerd op GPS vereist geen veranderingen aan de omgeving. Het nadeel ervan is dat de techniek de locatie van de robot niet precies genoeg kan weergeven. Een ingebouwde kaart is ook een weinig ingrijpende optie. De combinatie van zo’n kaart met afstandstellers en een kompas zou de robot de weg moeten kunnen wijzen. Nadelen van deze aanpak zijn het feit dat de kaart geupdate moet worden als de omgeving verandert en het feit dat de locatie berekend wordt relatief aan voorgaande locaties. Als de positie eenmaal onjuist bepaald wordt, voor wat voor reden dan ook, raakt het systeem compleet ontregeld.
Een andere optie is het gebruik van camera’s. Zowel “bird’s-eye” als “first-person” camera’s zijn te overwegen. First-person is erg inefficiënt voor deze toepassing, aangezien de layout van het Metaforum al van tevoren bekend is. Bird’s-eye is een van de betere opties: de camera zou nauwelijks te zien zijn, en de locatie zou in real time nauwkeurig bepaald kunnen worden. Een nadeel is dat het systeem niet meer werkt als de robot voor de camera onherkenbaar wordt gemaakt, bijvoorbeeld door een student die het herkenningspunt per ongeluk ofwel met opzet bedekt.
Een simpele maar ingrijpende optie is het aanbrengen van een lijnenstelsel op de vloer van het Metaforum waaruit de robot zijn locatie kan afleiden. Het feit dat de robot alleen maar vaste paden hoeft te volgen maakt deze optie aantrekkelijk. Een nadeel is dat zo’n grid van lijnen de “look” van het Metaforum zal veranderen. Aangezien uit de enquete blijkt dat users hier absoluut geen bezwaren tegen hebben, is er gekozen voor deze optie.
Bezorgpunten
Er zijn verschillende mogelijkheden te overwegen voor de bezorgpunten van de robot. De belangrijkste hiervan zijn persoonlijke bezorging bij de zitplaats van de user en bezorging aan de uiteinden van de lange tafels.
Bezorging aan de zitplaats heeft een groot voordeel: de user hoeft niet op te staan en te lopen om de bestelling op te halen. Bij een “gadget” als deze robot is comfort erg belangrijk. Als het gebruik van deze service veel moeite kost, zal er al snel een punt bereikt worden waarop users liever zelf hun eten gaan halen in de kantine. Helaas brengt deze manier van bezorgen veel complicaties met zich mee. Om te beginnen is er tussen de tafels weinig ruimte vrij, vooral op drukke momenten zoals pauzes, hetgeen het manouvreren van de robot lastig maakt. Ook het omgekeerde geval is problematisch: de aanwezigheid van de robot kan de bewegingsruimte van mensen die aan de tafels zitten beperken. Hiervan zouden vooral niet-klanten de dupe worden. Dit alles vergroot ook nog eens het probleem van tijdige bezorging. Persoonlijke aflevering kost de robot veel extra tijd ten opzichte van bezorging aan de tafeluiteinden. Hoewel uit de enquete blijkt dat users best langer op hun bestelling willen wachten als die dan wel persoonlijk afgeleverd wordt, zou dat strijdig kunnen zijn met de voorschriften wat betreft bezorgtijd en temperatuur.
Bezorging aan de uiteinden van de tafels vermindert de ernst van bovenstaande problemen aanzienlijk. Dat gaat wel ten koste van een deel van het gemak voor de user. Uit de enquete blijkt echter dat de meeste users tevreden zouden zijn met bezorging binnen 5 meter van hun zitplaats. De meeste zitplaatsen zijn minder dan 5 meter verwijderd van het uiteinde van de tafel dat aangrenst aan het gangpad. Ook impliceren die antwoorden dat de users het niet zo erg vinden om uit hun stoel te komen om het eten op te halen.
Na overweging van deze factoren is er gekozen om de robot de bestellingen aan de tafeluiteinden te laten afleveren.
Userlokalisatie
Aangezien er is gekozen voor bezorging aan het tafeluiteinde, zal een specifiekere lokalisatie dan tafelkeuze niet nodig zijn. De user voert gewoonweg tijdens het bestellen het reeds bestaande tafelnummer van zijn tafel in. Andere systemen, zoals bijvoorbeeld GPS-lokalisatie, leveren te veel moeilijkheden op voor te weinig potentiële voordelen.
References
- ↑ ServSafe International (2012). 'Nederlansde Voedselveiligheidsvoorschriften'.
- ↑ Pace C., Seward W. (2005). 'A Model for Autonomous Safety Management in a Mobile Robot'.
- ↑ Trenkle A., Seibold Z., Stoll T. (Oktober 30, 2013). 'Safety Requirements and Safety Functions for Decentralized Controlled Autonomous Systems'. Presented on: 2013 XXIV International Conference on Information, Communication and Automation Technologies