Címke: C


2017. Július 09.

Durba-tó interaktív adatok

írta: Xaint

Teszt jelleggel beépítettem a highcharts-ot, ami egy JavaScript alapú, interaktív grafikonok rajzolására használható kis függvénykönyvtár.

 

Created with Highstock 5.0.12DátumVízmélységHőmérsékletDurba-tó vízmélység és hőmérséklet adatokVízmélység (cm)VízhőmérsékletLéghőmérséklet22. Máj24. Máj26. Máj28. Máj30. Máj1. Jún3. Jún5. Jún7. Jún9. Jún11. Jún13. Jún15. Jún17. Jún19. Jún21. Jún23. Jún25. Jún27. Jún29. Jún1. Júl3. Júl5. Júl7. Júl9. Júl17017518018519019520020521021522022523010203040Highcharts.com


A fenti grafikonon ki-be kapcsolhatjuk a megjeleníteni kívánt adatsorokat, vagy ránagyíthatunk a grafikon bármelyik részére. A grafikonba kattintva pedig teljes képernyőssé tehetjük azt (ezt a Highslide API-nak köszönhetjük smiley).

Címkék:


2017. Június 26.

Város koordináta és térkép letöltés

írta: Xaint

Ma, a távirányító-vevő páros programozása közben arra gondoltam, milyen király lenne, ha a távirányítón a szimpla GPS hosszúsági és szélességi koordinátákon kívül a legközelebbi város neve is megjelenne.

Mivel SD kártya olvasó van a távirányítóban és a hajóban is, így az adatok tárolása megoldott. Már csak Magyarország városainak listájára volt szükségem, azok GPS koordinátáival együtt.

Miután olyan letölthető csv / txt fájlt, ami készen tartalmazná a szükséges információt, néhány perc keresgélés után sem találtam, arra gondoltam más utat választok. Ekkor találtam rá a latitudelongitude.org/hu nevű oldalra. Ez tartalmazza ugyan a városok neveit (nem mindet) és azok hosszúsági és szélességi fokait, ám ezt több oldalra tördelve.

Így gondoltam nem keresgélek tovább, hanem inkább összedobok egy kis alkalmazást C#-ben, ami bejárja az oldalt és lementi a szükséges információkat egy txt-be:
 


Persze amíg a programozással szöszöltem, az egész ötletet továbbgondoltam. Mi lenne, ha a kijelzőn az adott helység kis térképét is meg tudnánk nézni. Persze semmi "multiple zoom level" meg ilyesmi, ahhoz az Atmega644P már kevés lenne... (Bár annyit talán még bele lehetne erőszakolni a mikrovezérlőbe, hogy ha pl. egy adott településen, az adott tóról van közeli műholdképünk, akkor a hajó pozícióját a műholdképen is meg lehetne jeleníteni. Talán.. angel)

Mindenesetre statikus térképeket van lehetőségünk lekérni a Google-től, a Google Static Maps API használatával, ami egy alap felhasználónak 640x640 pixeles maximum képfelbontást és 25.000 térképletöltést engedélyez 24 óránként, ingyen. Nekünk egy 2"-os 160x128-as felbontású kijelzőnk van, és a latitudelongitude.org adatbázisa szerint pedig 276 városunk. Az előírt kvóta betartásával nem lenne gond...

Miután a latitudelongitude.org oldalról sikerült bekebelezni a szükséges adatokat, a térképrészletek letöltése sem volt annyira nehéz. laugh

A kis képek letöltését az alábbi kóddal oldottam meg:

foreach (ListViewItem i in listView1.Items)
	{
	string outFile = System.IO.Path.Combine("images/hybrid", i.SubItems[4].Text + "_hybrid" + ".png");
	System.IO.Directory.CreateDirectory("images/hybrid");

	// Download file
	var request = (HttpWebRequest)WebRequest.Create("https://maps.googleapis.com/maps/api/staticmap?center=Hungary," + i.SubItems[1].Text + "," + i.SubItems[0].Text + "&zoom=11&size=160x128&maptype=hybrid&key=YOURKEY");
	request.Proxy = null;
	request.UserAgent = @"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36";
	using (var response = await request.GetResponseAsync())
	{
	    using (var reader = new BinaryReader(response.GetResponseStream()))
	    {
	        // Read file 
	        byte[] bytes = await reader.ReadAllBytes();

	        // Write to folder 
	        using (var fs = new FileStream(outFile, FileMode.Create))
	        {
	            await fs.WriteAsync(bytes, 0, bytes.Length);
	        }
	    }
	}
	this.Invoke(new Action(() => progressBar2.PerformStep()));
	}

 

A hibrid, vagyis a műholdképek letöltése mellett még az egyszerű térkép (roadmap) verziót is lekaptam, ha már ott jártam:


 

Update: Közben úgy tűnik, egy problémát mindenképpen orvosolnom kell majd a későbbiekben. A távirányítóban ugyanis a kijelző, az nrf24l01 rádió modul, és az SD kártya olvasó is SPI buszon keresztül kommunikál a mikrovezérlővel. Mivel eddig az SD kártyával nem nagyon foglalkoztam (leszámítva a bekapcsoláskor egy egyszerű írás/olvasás tesztet txt-be), így semmi problémát nem vettem észre. Ám, a kijelző inicializálása után, és a rádiómodul használata közben történő SD kártya műveletek kifagyasztják a mikrovezérlőt surprise. Valószínűleg a kijelzőhöz használt, agyonoptimalizált függvénykönyvtár lesz a ludas. Ennek sajnos még utána kell járjak. (Az eredeti terv, mármint az adott GPS koordinátához tartozó városnév megjelenítése persze megoldható, hisz a hajón is van SD kártya (ott működik is), és az onnan beolvasott városnevet egyszerűen átküldhetjük rádión a távirányítóra, amikor az szükséges.)



2017. Május 27.

Durba-tó új adatok szoftverfrissítés után

írta: Xaint

Ma 14:35-kor ismét mintát vettem az eddigi adatokból, tudni akartam, hogyan muzsikál az új vízhőmérő szonda, illetve, hogy sikerült-e a vízmélységmérő szenzor éjszakai kilengéseit korrigálni a frissített szoftverrel.

Egyelőre most úgy tűnik, hogy minden jó. Íme:

 

 

A 25-ei éjfél után még látható egy negyedik, a léghőmérséklettel fordítottan arányos megugrás a vízmélység adataiban, ám 26-án és 27-én annak már nyoma sincs. A léghőmérséklet adataiból egyébként szépen kivehető egy 24-én záporokkal érkező lehűlés.

Az alábbi képen pedig az összes hőmérő, plusz a vízmélység adatai együttesen láthatók (a doboz hőmérséklet az ATmega beépített hőérzékelőjén alapul):

 

 

 

Címkék: , , ,


2017. Május 24.

Durba-tó adatgyűjtő szoftverfrissítés

írta: Xaint

Ma délután feltöltöttem a mérőeszközre a tegnap említett, 32 mérés átlagát figyelembe vevő szoftverfrissítést. Közben ha már felnyitottam a kis dobozkát, ismét készítettem egy mentést az SD-kártyán lévő adatokról.

Most viszont azon gondolkodom, hogy talán a hőmérséklet kompenzációt is be kellett volna építenem a kódba. De akkor mit csinálnék holnap vagy holnap után, nem igaz? cheeky

Mindenesetre a tegnap megjövendölt kicsúcsosodás beteljesedni látszik:

 

 

Remélem a szélesebb átlagolás csökkenti vagy teljesen eltünteti a zavaró csúcsokat. Azért szépen látszik a vízszint emelkedése.

Persze a történetnek itt sajnos még nincsen vége. Íme a vízhőmérséklet grafikonja:

 

 

Azért 2.5 napot kibírt a házilag kreált "vízálló" hőmérő szondám. Utána úgy tűnik, szépen beázott. Sajnos elfelejtettem, hogy a szilikon tömítőpaszta nem tapad valami jól az ugyancsak szilikonból készült csőhöz. Na de semmi baj, már legyártottam egy másik, fém kupakba ültetett, majd epoxi ragasztóval kiöntött szondát. Remélem ez tovább fogja bírni. Sajnos kicserélni csak holnap fogom tudni.

Legalább az akkumulátor töltöttségével nincsen probléma: wink

 

Címkék: , , , ,


2017. Május 23.

Durba-tó előzetes szenzor adatok

írta: Xaint

Ma, azaz kb. 2 nappal a kitelepítés után gyorsan lemásoltam az adatokat a tóhoz rohamtempóban összetákolt kombinált mérő és naplózó eszköz SD kártyájáról. Egyrészt kíváncsi voltam arra, hogy egyáltalán működik-e, és nem kuszáltam össze valamit a nagy sietségben, illetve ha működik a mérőeszköz, nincs-e szükség valamiféle utólagos szoftveres vagy hardveres korrekcióra.

Az előzetes adatokból is már szépen látszanak bizonyos jelenségek. Például, hogy a vízhőmérséklet - a mérőszonda sekély vízben való elhelyezkedése lévén viszonylag gyorsan - de kissé lemaradva követi a levegő hőmérséklet változásait:

 

 

Ám ennél egy sokkal érdekesebb dolgot vettem észre, amikor megnéztem, hogyan emelkedik a vízszint a folyamatos töltés hatására:

 

 

Mikor megláttam a fenti grafikont és összevetettem a léghőmérséklet változásával, rögtön eszembe jutott, hogy a hang terjedési sebessége a levegőben nem állandó, hanem függ a léghőmérséklettől (meg a páratartalomtól, stb.) és, hogy talán ez zavarhatja meg az ultrahangos távolságmérő szenzort. A hang terjedési sebessége ugyanis Celsius fokonként kb. 0.6 m/s-al nő:

 

 

Megoldásként a távolságmérésből származó adatokat az aktuális léghőmérsékletnek megfelelően kompenzálni kellene ( ~0.55 cm / °C) a szoftverben. Egyelőre kísérletképpen megpróbálkozok csupán az átlagoló algoritmus módosításával, a jelenlegi kód ugyanis 15 percenként végez méréseket és az előző 9 méréssel együtt vett átlagot veszi, vagyis ~2.5 óra időintervallummal számol. A mérések számát módosítottam 32-re, így minden mérésbe az előző 8 óra átlaga kerül. Ez kb. a grafikonon is látható csúcsok időtartama. Reméljük ettől majd kisimul az a fránya görbe. laugh

A tó vízszintje naponta megközelítőleg 3.5 cm-t emelkedik, ami elég közel van ennek az egyébként Ebay-ről származó ultrahangos távolságmérő szenzornak a hibahatárához. Ám a fenti két anomáliát leszámítva azért jól látható a várt, növekvő tendencia.

A kódot holnap frissítem, illetve újra lementem az eddigi, immár bő 3 napot magába foglaló mérési eredményeket. Természetesen azokból egy újabb kicsúcsosodásra számítok! cheeky

Címkék: , , , ,


2017. Május 19.

Durba-tó vízszintmérő szenzor

írta: Xaint

Május elejére elkészültünk az új Durba-tó medrének kialakításával, így nem maradt más hátra, mint a vízzel való feltöltése. Ennek apropóján ma összedobtam egy AVR mikrovezérlővel működő naplózó eszközt, ami a következő adatokat rögzíti:

  • dátum és idő
  • vízmélység
  • vízhőmérséklet
  • levegő hőmérséklet
  • akkumulátor feszültsége

Mivel gyorsan kész akartam lenni, ezért az egészet egy próbanyákon állítottam össze, egyedi nyomtatott áramkört tervezni és gyártani ugyanis sokkal időigényesebb. És mivel én mindennek szeretek egyedi nyákot készíteni, így el is felejtettem, hogy a próbapanelos módszer mennyivel egyszerűbb és persze szórakoztatóbb mint napokat tölteni pusztán a tervezéssel. cheeky

    

A kis mérőeszköz egy ATmega328P mikrovezérlőre épül (Arduino Pro Mini), ami egyetlen Li-Ion akkumulátorról működik, van benne egy egycellás töltésvezérlő IC (TP4056), 0.5 wattos napelem, valós idejű óra (DS1307), egy JSN-SR04T ultrahangos távolságmérő szenzor, SD-kártya olvasó, illetve egy 433MHz-en működő adó (MX-FS-03V) ami jelenleg nincs bekötve.

Sajnos az ultrahangos távolságmérő stabil működéséhez 5V tápfeszültségre és meglehetősen nagy áramra (~30mA) van szükség  így egy DC-DC boost konvertert is be kellett építsek, ami természetesen csak a mérések idején aktív, vagyis mindössze néhány milliszekundumig. Épp akadt egy használaton kívüli, összeszerelt boost konverterem ami az MCP1640T IC-re épül. Ennek üzemi árama mindössze 19µA.

A hőmérséklet mérését 1N4148-as egyenirányító diódákkal oldottam meg, "rendes" hőmérő IC-nek ugyanis mindig híján vagyok. Egyszerű diódával és egy néhány k-s ellenállással is elérhető az 1 Cº-os pontosság. 

Az egység egy kiszuperált elektronikai kötődobozba került, amit a tervezett legmagasabb vízszintnél némileg magasabban helyeztem el.

A helyszínen még szükség volt egy gyors kalibrációra, mert a távolságmérő a vízszint távolságát méri az egységhez viszonyítva, nekünk viszont az aktuális vízmélységre van szükségünk. Mivel az ultrahangos adó-vevő épp a doboz aljával egy síkban van, így a kalibráláshoz csak azt kellett leolvasni a mérőoszlopról, hogy a doboz alja milyen magasan helyezkedik el:

Vagyis 280 cm (mínusz a mért érték = aktuális vízmélység). A mérőoszlop a tó legmélyebb pontján mért értéket mutatja.

Jelenleg 15 percenként készülnek a mérések, amiből néhány nap múlva készítek egy-két grafikont is.

Ezen adatoknak persze gyakorlati haszna nem sok van, inkább csak érdekesség, a későbbiekben viszont akár a teljesen automatizált vízszint-szabályozás is megoldható lenne az eszközzel.

De az persze csakis egyedileg készített nyákkal!

Címkék: , , , ,


2017. Április 16.

Az etetőhajó vezérlőjének gyártása 2.

írta: Xaint

Ma is sikerült némi előrehaladást elérnem  a hajóba szánt vezérlő pár nappal ezelőtt levilágított NYÁK-jával kapcsolatban. Kész a maratás, a fúrás, a kémiai ónozás, de még a forrasztásgátló lakk felvitelével is sikerült végeznem. Ez utóbbi nem sikerült 100%-osra, de a panel azon részein, ahol igazán fontos, ott nincs probléma vele. Valószínűleg valamilyen zsír vagy koszréteg maradhatott a NYÁK azon részén, ahol a forrasztásgátló maszk nem kötött oda. De ez szerencsére csak néhány tüskesor csatlakozó körüli részt érint, a felületszerelt alkatrészeknél jól sikerült (a tisztítással azért alaposabban kell foglalkozzam a továbbiakban). angel

 

      

 

A NYÁK immár forrasztásra készen áll, bár nem tudom mikor lesz lesz időm az összeszerelésre, élesztésre, hibajavításra.

Ui.: Közben rendeltem a hajóba néhány nélkülözhetetlen alkatrészt: kormánylapát, tönkcső, hajócsavar, 2db. szervo, stb., mert a hajótesttel is foglalkoznom kellene. smiley



2017. Április 11.

Az etetőhajó vezérlőjének gyártása

írta: Xaint

Az utóbbi időben szinte semmi időm nem jutott arra, hogy az etetőhajó projektjével érdemben foglalkozni tudjak, ám - többnyire a rossz időnek köszönhetően - most úgy tűnik, akad rá egy-két napom. Mivel a hajóba szánt elektronika NYÁK-terve egy ideje már gyártásra kész állapotban volt, így csak néhány nyugodt órácskára volt szükségem ahhoz, hogy a tervekből végre kézzel fogható dolog szülessen.

Első lépésként ún. illesztési lyukakat kellett fúrjak a már megfelelő méretre vágott NYÁK-lemezbe. Ehhez most dry-fóliát használtam, melyet a NYÁK egyik oldalára laminálva, egy csak a furatokat tartalmazó maszkon keresztül levilágítottam. Előhívás után a NYÁK különböző pontjain néhány lyukat kifúrtam, később ezeket használtam a végleges maszkok illesztéséhez. A feleslegessé vált dry-fóliát aceton segítségével távolítottam el.

Ezután a NYÁK-lemezt folyó víz alatt, extra finom csiszolószivaccsal tisztítottam meg. A szárazra törölt NYÁK-ot izopropil-alkohollal áttöröltem, majd  megfelelően méretre vágott dry-fóliát lamináltam annak mindkét oldalára. Ezután következett a megfelelő maszkok nyomtatása EAGLE-ből, írásvetítő fóliára. A maszkból mindig két-két darabot nyomtatok, melyeket illesztés után pillanatragasztóval ragasztok össze. Erre sajnos azért van szükség, mert az UV levilágítás során egyetlen réteg toner nem biztosít megfelelő takarást (nem elég sötét). Az egyik oldali maszkot a furatokra illesztve következett a levilágítás, melyet a másik oldallal is ugyanígy megismételtem, ügyelve a pontos illesztésre.
 

        

 

A levilágítás után bedobtam a NYÁK-ot egy kis előhívóba (nálam ez víz + szódabikarbóna), melyben addig tartottam, míg a megfelelő (nem levilágított) részekről leoldódott a dry-fólia. Ez kb 20 percet vett igénybe.

Mivel ez egy olyan pont, ahol a munkát biztonságosan abba lehet hagyni, és a NYÁK-ot félre lehet tenni, ezért a maratást, fúrást, stb. egy másik alkalommal fogom elvégezni.



2017. Március 03.

Screen space reflections

írta: Xaint

Nemrég játszottam a Battlefield 1-el, és feltűnt, hogy a fejlesztők milyen jól használják a Frostbite motorban a screen space reflection effektet, és, hogy az milyen sokat dob a vizuális élményen. Annyira megtetszett, hogy gondoltam adok neki egy esélyt az én saját gyártású Sponza színteremen - azaz a szoba modellemen! laugh





De előbb jöjjön a Battlefield 1-ből néhány példa, hogy miről is beszélek:
 

        
 

         


Itt pedig egy a teszteléshez használt, sebtiben összedobott teszt színtér: cheeky
 

 

És íme az effekt a szoba modellemen, működés közben (a frissen felmosott padló effekt): broken heart
 

        
 

        

 

Természetesen, képtér alapú effektus lévén az algoritmusnak szüksége van arra, hogy a tükröződő objektum szerepeljen a képen ahhoz, hogy a tükröződést ki lehessen számítani (képtér alapú sugárkövetés). Ha egy adott objektum kikerül a képernyőről, annak tükröződését már nem tudjuk tovább valós időben megjeleníteni, ami miatt az eltűnő, majd az objektum újbóli megjelenése után megint előkerülő tükröződést sokan inkább idegesítőnek találják. Ám ha nem visszük túlzásba, igenis sokat dobhat a valósághű ábrázoláson, ami miatt a legtöbb nagy játékfejlesztő cég egyszerűen nem hagyhatja ki a legújabb játékaikból ezt az egyébként igen erőforrásigényes effektet.

Update (2017.07.20.): crying R.I.P. Chester Bennington.
 



2017. Január 21.

Alerion Engine Update

írta: Xaint

Hosszú idő után (~6 év smiley) belepiszkáltam kicsit a szakdogának szánt játékmotoromba. Először is javítottam jó néhány ismert bugot, közben felfedeztem kb. kétszer annyi újat.

Bekerült a motorba az animált karakterek támogatása, amit jelenleg az MD2 fájlformátum képvisel (Pl:  Quake 2,  Max Payne stb.), de tervezem az MD3 és MD5 modellformátum beépítését is.

A pályaformátumot illetően még mindig (a jól bejáratott) bináris térparticionáló fa adatstruktúra áll rendelkezésre. Az animált karakterek ütközhetnek a BSP fával, illetve egymással. A játék egyéb entitásaival (pl. töltények, rakéták vagy egyéb felvehető tárgyak) való ütköztetés még csak részben megoldott.
 


 

Szegény "ellenséges" karakterek még elég butuskák. Mindössze egy néhány perc alatt összetákolt, bedrótozott mesterséges intelligenciát kaptak, amiben az útkeresés abból áll, hogy szembe fordulnak velem és addig közelednek amíg egy bizonyos távolságon belülre nem érnek.

Legalább elmondhatjuk, hogy hűségesen követnek cheeky :