trepik
commented
8 years ago Dneska jsem se bavil s panem Janouskem a rikal ze si nemame priliz komplikovat zivot, smyslem projektu je pry odzkouset principy, jiz fungujici a pouzivane technologie. S navrhem kompletne vlastni implementace jak simulatoru tak ridiciho systemu take souhlasil a hlavne se mu pozdava, ze to je uplne nova problematika. Sam navrhl jednoduché vizuální zpracování simulace.
A ted jak jsem to pocas prednasky vymyslel?
Nase aplikace se bude starat o efektivní řízení uklízecích robotu. Mistem nasazeni bude IT firma. Systém bude mít za úkol efektivne využivat uklízecí roboty, k úklidu prostor firmy, bez toho aby narušoval pracovní proces.
Aplikaci bych rozdelil na tri casti:
- Ridici system (server)
- Generator událostí (klient)
- Simulátor/Vizualizátor
Ridici system Bude ridit roboty, fungujic jako server, ktery posloucha na nejakem portu. Pro kazdeho klienta pobezi zvlast vlakno, ktere ho bude "obsluhovat". Klienti budou budto roboti, nebo nabijeci stanice, nebo senzory. Vsechny tyto klienty by mohl teoreticky zastresovat jeden klient, ktery bude generovat udalosti. Ridici system bude vyhodnocovat data od klientu a na zaklade nich rozdavat prikazy robotum, zda a kam maji jit ukizet, kdy a kam se maji vratit nabit, a jak maji resit krizove situace.
Generator udalosti Napadaji mne tri moznosti:
- Jeden generator: generuje jak prijem dat od senzoru, tak od robotu, a podobne od nabijecich stanic v podstate funguje i jako planovac
- spostu klientu: Kazdy senzor, robot, stanice je samostatný klient, který komunikuje se servrem nezávisle na ostatních
- hybridní pristup: Kazdy robot je jako klient samostatne senzory jsou brany jako jeden "super klient"
Simulator/Vizualizator Tady moc nevim co by vlastne delal, spis asi ten vizualizator, jen tak jednoduse: planek mistnosti plus jednoduchy pohyb robotu a "vybarvovani uz uklizenych prostor"
Senzory mezi senzory pocitam tyto veci:
- udalosti kalendare (dnes uz nejsou planovane zadne porady v nektere z mistnosti, tak tam posleme robota uklidit)
- asynchroni udalost (nekdo zmackne cudlik a vyzada si okamzity uklid dane mistnosti)
- pohybové senzory (dele jak pul hodiny senic nepohlo, cas na uklid?)
- hodiny (pravidelny nocni uklid zacina ve 2 rano)
- dveřní senzory (dvere jsou zamcene, cas na uklid?)
prikazy robotum
- presun se na to a to misto
- zmapuj okoli pro uklid (rozlozeni nabytku se v prubehu zivota systemu muze menit)
- uklizej
- jdi se nabit do te a te nabijeci stanice (ne nutne nejblizsi)
- cekej (asi hlavnev pripade krizove situace)
dalsi postrehy
- roboti pravidelne odesilaji informace o stavu napajeni a data z akcelerometru na server
- server rozhoduje o nejblizsi nabijeci stanici, a take kdy se ma robot vratit aby neuvizl bez stavy
- predpokladame ze pocas nabijeni se robot i vycisti
- predpokladame ze robot uklidi na jedno nabiti urcitou plochu
reseni krizovych situaci
- narusitel v mistnosti (dvere, pohyb)
- vypadek elektriny (douklizet/vratit se do stanice, v pripade ze nedostal ping od serveru delsi dobu)
- loupez robota (vertikalni pohyb na akcelerometru)
mozna rozsireni
- predikce potreby robota, na zaklade poctu zapnutych PC, pripojeni do site, ... v dane mistnosti, robot se premisti na dane misto
- samovypocet rozlozeni nabijecih stanic a robotu
- pridavani mistnosti, robotu, stanic, senzoru v prubehu zivota systemu
- pouziti Haystack porjektu pro standardizovany prenos dat
xvaisr
Je potreba pridat dalsi temata a / nebo vybrat to, nakterem se zacne skutecne pracovat. Tohle issue je urcene jako thread, kde muzeme diskutovat o tom ktere tema se nakonec skutecne vybere. Vyucijicimu pripada jako nejzajimavejsi ta synchronizace roomba robotu. Ma to ovsem sva uskaly. Zbytek informaci je v readme. Muzeme zacit diskusi ...
Directed to: @trepik @OndrejBlucha