Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: lopata 23. 01. 2017, 17:52:20
-
Ahoj,
dělám „robota“ na RaspberryPi platformě a potřeboval bych zkontrolovat, jestli mám +- dobrej nápad. Ten robot je akorát pár servomotorků na mávání rukama, displej a k tomu pak dobastlím co mě ještě napadne. Pojízdný to naštěstí není :D. Chci to řídit přes web a IR ovladačem od telky.
Řídící program napíšu v Pythonu (ranec knihoven, jednoduchost). Pythoní skript na začátku přečte konfigurační texťák a pak klasicky nekonečnej while (točí servama...). Měl jsem v plánu, že systemd by ten skript mohl po startu spustit (a taky hlídat, jestli nespadl, a kdyby jo, tak ho zase pustit). Může to takhle fungovat?
Do konfiguračního texťáku bych ukládal nějaký nastavení co zobrazovat, jak se chovat apod. (nebude se to měnit moc často). Formát asi JSON, XML nebo něco takovýho.
Na web bych měl Apache, jako stránku napíšu něco jednoduchýho v php. Na stránce si člověk zadá co chce a tlačítkem odešle formulář. Tím php skriptem to pak uložím do toho texťáku a zavolám si restart toho skriptu (exec nebo shell --> systemctl restart blabla). Není to moc prasárna?
Ovladač by hlídal LIRCem. Viděl jsem tam nějakou irexec funkci, tak bych si ji zavolal, aby zase: uložila nastavení do texťáku a restartovala Pythoní skript.
Mohlo by to fungovat/není to zbytečně složitý? (S linuxem moc dlouho nedělám (cca rok))
Díky za případné postřehy
-
Zvážil bych, jestli nepoužít nějaký webserver spuštěný jako vlákno přímo v tom Pythonu. Při přijetí požadavku by tak mohl rovnou ovlivnit chod. Totéž s LIRC.
-
Případně tomu ovládacímu skriptu lze posílat příkazy pomocí D-Busu (https://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html); web by pak ale musel být v něčem, co umí D-Bus (třeba Python/Django). S PHP by šlo použít pojmenovanou rouru (FIFO soubor), kterou by se posílaly textové příkazy. Restartování při každé změně chování je IMO docela prasárna.
-
Tak to vidím tak, že přes víkend zkusím udělat v pythonu ten LIRC + webovku. Když mi to nepůjde, tak to prostě budu restartovat...
Ten D-Bus/roura zní zajímavě, jestli mi zbyde čas, podívám se na to.
Díky za tipy! :)
-
mrkni na Flask http://flask.pocoo.org/ (http://flask.pocoo.org/) zatim jsem to nepouzil, ale parkrat na to narazil. Vypada to ze zapomoci par dekoratoru udelas webovej ksicht stejne jako u Click http://click.pocoo.org/5/ (http://click.pocoo.org/5/) CLI.
-
diky, okouknu to, vcera jsem rychle googloval a nasel jsem jen nejaky webpy, tak ten Flask zkusim
-
Tak to vidím tak, že přes víkend zkusím udělat v pythonu ten LIRC + webovku. Když mi to nepůjde, tak to prostě budu restartovat...
Ten D-Bus/roura zní zajímavě, jestli mi zbyde čas, podívám se na to.
Díky za tipy! :)
Na restartování po změně konfigurace není nic špatného. Je to bezestavové a ladí se to snadněji než meziprocesová komunikace.
-
Zvážil bych, jestli nepoužít nějaký webserver spuštěný jako vlákno přímo v tom Pythonu. Při přijetí požadavku by tak mohl rovnou ovlivnit chod. Totéž s LIRC.
To byla první věc, co mě napadla - proč tam cpát kravský Apache s blbým PHP, když Python určitě má nějaký malinký webserver.
-
...a to restartování je prasárna, protože ten Python si určitě bude držet nějaké stavy robotu, takže by se to muselo nějak ukončovat a zase inicializovat... Prostě je to hovadina, má to běžet jako stavová, řídicí aplikace komunikující některým z uvedených kanálů s venkem.
-
V práci dělám v javě (v idee), doma jsem si pohrál s pythonem https://github.com/pavhofman/plabs-player . Python je fajn, jednoduchý, ale znovu bych jej už nezvolil. Absence typové kontroly a takřka nulové možnosti bezpečného refaktoringu (i v Pycharmu), člověk zjistí typovou chybu až po spuštění (např. klasicky zapomenutá explicitní konverze intu na str atd.), abstraktní metody formou vyhození NotImplementedException, nepovinné anotace vstupních a návratových hodnot, které editoru až tak nepomáhají. Rovněž neustálý boj mezi python2.7 a python3 - půlka příkladů na netu je na starý, půlka na nový, člověk musí hlídat stáří příspěvků atd. Sice je na python spoustu knihoven, ale to na javu taku. Dobré je, že runtime pythonu nezabere tolik místa na fleš disku malé krabičky, ale to už dnes není tak kritické.
-
V práci dělám v javě (v idee), doma jsem si pohrál s pythonem https://github.com/pavhofman/plabs-player . Python je fajn, jednoduchý, ale znovu bych jej už nezvolil. Absence typové kontroly a takřka nulové možnosti bezpečného refaktoringu (i v Pycharmu), člověk zjistí typovou chybu až po spuštění (např. klasicky zapomenutá explicitní konverze intu na str atd.), abstraktní metody formou vyhození NotImplementedException, nepovinné anotace vstupních a návratových hodnot, které editoru až tak nepomáhají. Rovněž neustálý boj mezi python2.7 a python3 - půlka příkladů na netu je na starý, půlka na nový, člověk musí hlídat stáří příspěvků atd. Sice je na python spoustu knihoven, ale to na javu taku. Dobré je, že runtime pythonu nezabere tolik místa na fleš disku malé krabičky, ale to už dnes není tak kritické.
Jen pár postřehů, které by vás mohly ušetřit některých z popisovaných problémů. O tomto typu aplikací nic nevím, možná budou mé rady k ničemu.
Pro vynucení implementace abstraktních metod existuje knihovna https://docs.python.org/3/library/abc.html.
V testech bych se snažil používat asserty. Knihovna UnitTest je stejná jako v Javě. Umožní vám to spouštět testy po každé změně a nezatěžovat se kontrolou výstupu. Chápu, že u všech testů této aplikace to nejde.
V editoru nebo IDE bych zapnul kontrolu dodržování PEP8.
-
Pro vynucení implementace abstraktních metod existuje knihovna https://docs.python.org/3/library/abc.html.
Díky za tip. Bohužel to zase kontroluje existenci implementace až při běhu - takže to místo jedné výjimky hodí jinou. Jsem rozmazlený z idei dát "implementovat" a předgeneruje to všechny metody, které musím implementovat pro korektní kompilaci. A hned vidím, co všechno musím dodělat. Kompilátor to jinak dál nepustí...
V editoru nebo IDE bych zapnul kontrolu dodržování PEP8.
To jsem v Pycharmu měl, ale stejně to korektní třídy moc nenabízelo, nápověda byla spíš "fulltextová" podle názvu.
Chápu důvody, ale proč se mořit, když to jde jednodušeji v jiném jazyce...
-
Pro vynucení implementace abstraktních metod existuje knihovna https://docs.python.org/3/library/abc.html.
Díky za tip. Bohužel to zase kontroluje existenci implementace až při běhu - takže to místo jedné výjimky hodí jinou. Jsem rozmazlený z idei dát "implementovat" a předgeneruje to všechny metody, které musím implementovat pro korektní kompilaci. A hned vidím, co všechno musím dodělat. Kompilátor to jinak dál nepustí...
je v tom rozdíl. Tohle vyhodí výjimku při spuštění skriptu. Většina linterů na to upozorní už při psaní. NotImplementedError je vyhazována při použití.
-
Nečetl jsem ostatní odpovědi, tak se omlouvám za případné opakování nebo hlouposti.
Já bych do toho šel trošičku jinak.
1. Načtení texťáku bych dal do while, tím by odpadla potřeba restartu
2. Zahlédl jsem jedním okem doporučení číst IR přímo v Pythonu - na to bych se podíval, to je dobrej nápad
3. Co se ovládání z webu týče, podle mě je exec prasárna, šel bych třeba cestou "Zapsat konfiguraci do texťáku, vytvořit soubor 'reload' a Python skript by ve while kontroloval přítomnost 'reload' a v případě že existuje by znovu načetl konfiguraci z texťáku a smazal 'reload'"
Asi je to pořád bastlení, ale myslím si, že alespoň trochu systematičtější :-)
-
To jsem v Pycharmu měl, ale stejně to korektní třídy moc nenabízelo, nápověda byla spíš "fulltextová" podle názvu.
Chápu důvody, ale proč se mořit, když to jde jednodušeji v jiném jazyce...
Mořil jste se, protože jste nevyužil výhod pythonu. Mohl jste si například ušetřit práci vynecháním boilerplate kódu.
-
Hm, to nevím, co máš konkrétně na mysli. Pro mě je podstatné, aby byl spolehlivý a předvídatelný. Např. bych rád "generifikoval" Queue https://github.com/pavhofman/plabs-player/blob/master/abstractwriter.py#L15 , aby bylo na první pohled vidět , že se do ní dávají jen a pouze objekty třídy AbstractScreen https://github.com/pavhofman/plabs-player/blob/master/abstractscreen.py#L20 (tedy konkrétní potomci představující různé obrazovky displeje). To samé fronta pro vstupní povely https://github.com/pavhofman/plabs-player/commit/9b425f254432fcd1147e8cb2b6175876613d0bfc#diff-d8c11be2b3b970dca323967adfa49ffaR19 - obsahuje jen potomky třídy AbstractCommand https://github.com/pavhofman/plabs-player/blob/master/abstractcommand.py#L4 , kteří každý umí provádět jiný příkaz. Normální objektový přístup, nemám žádný zájem míchat ve vstupní/výstupní frontě vzájemně nekompatibilní objekty.
Jo, je to přístup z javy, ale přijde mi logický a čistý.
-
Ahoj,
konečné automaty se v průmyslu implementují pomocí PLC obvodů, levnější obdobu můžeš najít i přímo pro Raspberry Pi3:
http://rpishop.cz/raspberry-pi-sady/312-rex-starter-sada-s-raspberry-pi-3.html
(nicméně je zapotřebí zjistit, jak je to s podporou IR)
-
Hm, to nevím, co máš konkrétně na mysli. Pro mě je podstatné, aby byl spolehlivý a předvídatelný. Např. bych rád "generifikoval" Queue https://github.com/pavhofman/plabs-player/blob/master/abstractwriter.py#L15 , aby bylo na první pohled vidět , že se do ní dávají jen a pouze objekty třídy AbstractScreen https://github.com/pavhofman/plabs-player/blob/master/abstractscreen.py#L20 (tedy konkrétní potomci představující různé obrazovky displeje). To samé fronta pro vstupní povely https://github.com/pavhofman/plabs-player/commit/9b425f254432fcd1147e8cb2b6175876613d0bfc#diff-d8c11be2b3b970dca323967adfa49ffaR19 - obsahuje jen potomky třídy AbstractCommand https://github.com/pavhofman/plabs-player/blob/master/abstractcommand.py#L4 , kteří každý umí provádět jiný příkaz. Normální objektový přístup, nemám žádný zájem míchat ve vstupní/výstupní frontě vzájemně nekompatibilní objekty.
Jo, je to přístup z javy, ale přijde mi logický a čistý.
Neměl by být problém obalit queue.Queue typovanou verzí. V budoucnu to určitě někdo udělá. Type hinty jsou stále novinka a moc lidí to nepoužívá.
-
Python skript by ve while kontroloval přítomnost 'reload'
Šmarjá. Tak alespoň inotify nebo signál. Ale nejlepší by bylo mu konfiguraci poslat rourou/soketem.
-
Hm, to nevím, co máš konkrétně na mysli. Pro mě je podstatné, aby byl spolehlivý a předvídatelný. Např. bych rád "generifikoval" Queue https://github.com/pavhofman/plabs-player/blob/master/abstractwriter.py#L15 , aby bylo na první pohled vidět , že se do ní dávají jen a pouze objekty třídy AbstractScreen https://github.com/pavhofman/plabs-player/blob/master/abstractscreen.py#L20 (tedy konkrétní potomci představující různé obrazovky displeje). To samé fronta pro vstupní povely https://github.com/pavhofman/plabs-player/commit/9b425f254432fcd1147e8cb2b6175876613d0bfc#diff-d8c11be2b3b970dca323967adfa49ffaR19 - obsahuje jen potomky třídy AbstractCommand https://github.com/pavhofman/plabs-player/blob/master/abstractcommand.py#L4 , kteří každý umí provádět jiný příkaz. Normální objektový přístup, nemám žádný zájem míchat ve vstupní/výstupní frontě vzájemně nekompatibilní objekty.
Jo, je to přístup z javy, ale přijde mi logický a čistý.
Neměl by být problém obalit queue.Queue typovanou verzí. V budoucnu to určitě někdo udělá. Type hinty jsou stále novinka a moc lidí to nepoužívá.
https://github.com/python/typeshed/blob/master/stdlib/3/queue.pyi
s mypy funguje tohle. Stačí to dát do import path a přidat hint
# type: Queue[AbstractScreen]
-
Díky, to vypadá použitelně. Ale je to pořád dost syrové, nekompletní, navíc se tohle vše (z mého pohledu základní věci) musí doinstalovávat.
Příští projekt použiju rovnou javu, python asi není pro mě :-) Ale díky za tipy.