diff options
Diffstat (limited to 'readme.md')
-rw-r--r-- | readme.md | 49 |
1 files changed, 49 insertions, 0 deletions
@@ -14,6 +14,55 @@ gebruikte externe libraries: |-|-| |[yan9a/serial](https://github.com/yan9a/serial)|cross-compatibiliteit voor seriële poorten lezen/schrijven voor windows en linux| +## samenvatting werking + +Globaal gezien draait de robot altijd in een van twee 'standen'. De eerste +stand is voor het doolhof-gedeelte van de kaart, en de tweede is voor het +warenhuis-gedeelte. Tijdens de assessment kan het zijn dat de robot opgetild +wordt en ergens anders wordt neergezet in het doolhof gedeelte, en hier moet de +robot tegen kunnen. Om het doolhof op te lossen wordt of de rechterhandregel of +de linkerhandregel gebruikt, zodat de robot altijd een uitgang van het doolhof +kan vinden, zonder dat de robot zijn eigen positie binnen het doolhof hoeft te +weten, of überhaupt bewust hoeft te zijn van de lay-out van het doolhof zelf. +De overgang tussen het doolhof en het warenhuis wordt aangegeven met een soort +zebrapad die dezelfde breedte als de rest van de lijnen heeft. Vooraf wordt via +de client aangegeven aan de robot hoe groot het warenhuis is, en waar de in- en +uitgangen van het warenhuis zitten, zodat de robot zelfstandig naar het +afleverpunt en het oplaadstation kan rijden zodra alle bestellingen opgehaald +zijn. De volgende specificaties moeten nog exact afgesproken worden voordat er +een kaart gemaakt kan worden: + +- breedte van de lijn +- tegelgrootte (binnen warenhuis) +- exacte afmetingen van, en de hoeveelheid van de strepen in het zebrapad + +De lijnen van het doolhof hoeven niet te voldoen aan de tegelgrootte, maar de +in- en uitgangen moeten wel een rechte overloop hebben op het +warenhuis-gedeelte. + +## te bespreken + +- Consequent snake case gebruiken inplaats van camel case +- Hoe wordt de controle over de robot 'overhandigd' tussen verschillende + standen? +- Hoe weet de robot via welke in-/uitgang hij het warenhuis in/uit rijdt? + (barcode-scanner implementeren?) +- Globale status met alle sensor data en andere diagnostische info in een + struct zetten en toeganklijk maken vanuit aansturingsstanden? +- Middleware maken zodat er een soort pseudo-supervisor draait die het + overschakelen tussen standen kan beheren, en alle sensordata update in de + globale status struct? +- Misschien een globaal software diagram maken? +- Is het slim om de test stand voor de natte vloer (spinnen) ook een losse + 'stand' te maken? + - Noodstop ook een stand maken? +- Welke software wordt er gebruikt om de kaart te maken? + (moet met exacte afstanden kunnen werken, lieft in centimeters; als het kan + ook fijn om in samen te werken) + - Figma? + - Adobe Illustrator? + - MS Visio? + ## noob hoek hier wat korte uitleg over dingen die niet zijn uitgelegd in vorige blokken van |