Picproje Elektronik Sitesi

BİLGİSAYAR => Gömülü İşletim Sistemleri => Konuyu başlatan: gumush - 26 Ekim 2018, 11:28:27

Başlık: Tasarim Tavsiyesi
Gönderen: gumush - 26 Ekim 2018, 11:28:27
Merhaba ,

Uzerinde calistigimiz bir sistemin tasarimi ile ilgili sizlere danismak istiyorum.

Sistem
5-25 RPI Zero W
1-2  RPI 3
1-3  Wireless Router

Sistem kablosuz ag uzerinden iletisim kuruyor. Wireless Router'larin amaci MESH ile sistemdeki nodelarin olabildigince kapsana bilmesini saglamak oluyor. Ancak buna ragmen node'larin baglanti hizlari degisken olabiliyor. Node'larin bir kismi ic mekanda bir kismi dis mekanda olabiliyor.Dis mekanda olanar hareketli sistemlerin uzerinde yer aliyor.

RPI Zero W'ler uzerinde sensorler var bu sensorler UART , SPI , I2C ve BLE  uzerinden bagli sensorler ve farkli veri ornekleme hizlarina sahipler. Bu sensorlerin verilerini alip kaydetmek icin farkli processleri calistirmayi dusunuyoruz. Bu sekilde hem performans sorunlarini asar hemde gelistirme ve hata ayiklama sureclerini daha kolay yonetebiliriz diye dusunuyoruz. Agirlikli olarak gelistirmeleri python uzerinden yapmayi planliyoruz.

Ama unite olarak RPI3 dusunduk ama bunu gerekli olursa daha performansli bir seyler degistiredebiliriz ( denemelerimiz yeterli olabilecegi yonunde

Temelde anaunite uzerinde calisan bir webserver olacak bunla baglanan cihazlar ( 1-2 cihaz baglanacak maksimum ) buradan verileri gorebilecek , cihazlari yonetebilecek. 

Hedef islerler sunlar olacak;

A- Ana unite uzerinden acik olan node'lari tarayabilelim.
B- Ana unite uzerinden node'lara erisip oradaki bazi environmental degiskenleri belirleyebilelim.
C- Ana unite uzerinden node'larda calisan veri kayit processlerinin durumlarini ogrenebilelim , bunlari acip kapatabilelim
D- Node'lar uzerinde sensorlere erisilip veri kaydedilmesi
E- Ana unite uzerinden verilerin onizlemesini yapabilelim.
F- Kayit sonrasinda verileri anaunite uzerine alabilelim ( Tercihen bu islem kayit sirasindada baslasin )
G- Ana unite uzerinden node'larin yazilimlarini guncelleyebilelim

Node'lar uzerinde python+flask calistiralim iletisimi buyuk oranda bunun uzerinden surdurelim diye dusunuyoruz.
Ana unite uzerindede python+flask+mysql calistiralim erisimleride bunun uzerinden yapalim diye dusunuyoruz.

python+flask tercih etme nedenimiz gelistirmenin hizli ve cabuk olmasi , dokumantasyonlarinin yeterli olmasi , uzerinde yapilabilecek degisikliklere acik olmasi. Bunun yerine hepsine farkli islemler icin farkli deamon'lar yazmak alternatifi var ancak o bize biraz daha uzak. Birde anaunite uzerindeki islemleri web uzerinden eriserek yapacagimiz icin zaten flask kullanacaktik boylece sistemde daha az cesit yazilim kullanmis oluruz diye dusunduk.

A- Ana unite uzerinden acik olan node'lari tarayabilelim.

Bu nispeten basit gibi mevcut c'class'daki tum makineleri tarayip sonra flask'in acik oldugu portlari tariyoruz. Acik olan makineleri bu sekilde bulabiliriz. Hatta buradaki bir adresi cagirip buradan bir durum kodu dondurerek o node'daki bazi parametreleri ( sensor durumu , hdd alani gibi ) gorebiliriz.

B- Ana unite uzerinden node'lara erisip oradaki bazi environmental degiskenleri belirleyebilelim.

Burada anaunite uzerinde calisan web server'a baglanip arayuzden komutu veriyoruz. Bu komut bir python script'ini calistiriyor. O node' uzerindeki bir URL'yi parametre ile cagiriyor. Node uzerinde tetiklenen python script'i ise gidip gereken parametreleri degistiriyor.

C- Ana unite uzerinden node'larda calisan veri kayit processlerinin durumlarini ogrenebilelim , bunlari acip kapatabilelim

Bu ana unite uzerinde calisan , surekli olarak tetiklenen ( her s' yada 2s'de bir gibi ) bir islem olabilir. Bunun icin anaunite uzerindeki process gidip node'lar uzerinden bir URL'yi cagiriyor. O URL gerekli deamonlari tarayarak bir durum kodu donusturuyor. ( Hazir , kayit devam ediyor yada hata su gibi )
Bunlari acip kapatma isi biraz daha karisik gibi geldi bize. Node'un os'u basladiginda bu processler baslayip gidip sensorlerine baglanmali ve beklemeli eger baglanamadiysa soruldugunda vermek uzere durum kodlarini ona gore belirlemeliler.
Sonra bunlarin calisan deamon'larina belirli komulari verebilmeliyim. Durum kodu isteme , kaydi baslatma , kaydi durdurma , belirli bir sure icin kayit alma gibi. Bu kisim bize zor gelen kisim. Daha once bir deamon yazip buna gelen parametrelere gore islem yapmamistik. Birde ornegin kayda baslamis ve devam eden isleme kaydi durdur diyecegiz. Oda girip belirli islemleri yapip kaydi durduracak gibi.

D- Node'lar uzerinde sensorlere erisilip veri kaydedilmesi

Bu kisim icin sorun verilerin yazilmaya basladiktan sonra halen yazim devam ederken okunmak istenmesinden kaynaklaniyor. Bunun icin SQLlite gibi yada birden cok erisime izin veren RPI Zero W uzerinde cok zorlanmayacak bir veritabani olabilir diye dusunuyoruz.Boylece process'ler sorun etmeden buraya verileri yazabilir. Ana unite yine eszamanli erisim problemlerini dusunmeden buradan verileri onizleme olusturmak icin sorgulayabilir. Hatta replication vs gibi yazilima ait ozellikler ile cokda ugrasmadan verilerin anaunite uzerine aktarilmasi saglanabilir. En cok kafamizi kurcalayan kisim burasi.

E- Ana unite uzerinden verilerin onizlemesini yapabilelim.

Eger verileri veritabanina kaydettiysek bu kisim biraz daha kolay olabilir. Ana unite node'un veritabanina baglanir son 5 kaydi okur , o oturum icin daha once aldigi verilere ekler ve gorsellestirir. Burada bu islemi belirli araliklar ile tetikleyebiliriz ( Bu sirada 5000 veri bile kaydedilmis olsa son 5 veriyi alacak bu bir cok durum icin kabul edilebilirde olsa bazi durumlarda bir onceki aldigi veriden sona kadar olan verilerin ortalamasini almasi gibi veritabanina azda olsa yuk getirebilecek sorgulamalarda olabileceginden bu kisimda bizi endiselendiriyor )

F- Kayit sonrasinda verileri anaunite uzerine alabilelim ( Tercihen bu islem kayit sirasindada baslasin )

Burada yontem nispeten daha iyi gibi. Yani oturum sonlandirinda tum node'lara git verileri oku , aktar. ( dosya sistemi uzerinden direk sqlite dosyalarinin aktarimida olabilir boyle cok daha hizli olacaktir ) Bu durumda node'lar uzerinde kayit islemleri icin her oturumda farkli bir sqlite dosyasi kullanilabilir.

G- Ana unite uzerinden node'larin yazilimlarini guncelleyebilelim

Bu kisim bizim icin simdilik oncelik disi oldugundan bunu gecebiliriz.Bunun icin simdilik alternatifimiz herseyi docker uzerinde calistirmak boylece guncelleme icin imajlari degistirmemiz yeterli olacak. Henuz denemedigimiz ise calisan bir container UART , I2C , SPI , BLE gibi donanimlara erisebilir mi ? Yada iki farkli container erismek isterse sistem bunu nasil yapiyor kismi ama simdilik yukaridakilere odaklanmak istiyoruz.


Gorusleriniz benim icin cok faydali olabilir, desteklerinizi bekliyorum.

Uzun yazdim ama ozellikle iki konuda takildim ;
verileri nereye kaydetmeliyim , bu kayitlari kayit devam ederken nasil okuyabilir yada nasil transfer etmeye baslayabilirim , veritabani kullanmak biraz asiri cozum mu olur ?
bir process kayit halindeki bir dongudeyken nasil parametre alabilir ? Aklimda dosya sistemi uzerinde bir dosyaya islem biti yazmak geldi ama 4000hz'de veri kaydetmeye calisan bir sistemin birde buna benzer bir aralikta dosyasistemine erismesi cok mantikli gelmedi. https://github.com/serverdensity/python-daemon var ama burada sadece baslar , durdur , ,yeniden baslat parametreleri var. Bu durumda calisan  process'e 3 saniye kayit al dur diyemeyecegiz.

simdiden tesekkur ederim.
Başlık: Ynt: Tasarim Tavsiyesi
Gönderen: foseydon - 26 Ekim 2018, 14:09:44
ben naçizhane yorumumu yazayım. bu işi lora, mqtt ve özel donanımla halletmek daha verimli ve ucuz olur. ama ya zaman darlığından ya bilgi eksikliğinden vs. bu işi hazır donanımla halledelim denilmiş, haliyle bütün tasarımda bunun üzerine şekillenmiş. en basitinden kablosuz ağ olarak wi-fi kullanıyorsunuz anladığım kadarı ile, bunun sebebi hazır donanımda bu olması ve bununla kolay olacak olması. oysa ki, ISM bandından daha düşük bir frekans kullansanız performansınız artar.
Başlık: Ynt: Tasarim Tavsiyesi
Gönderen: gumush - 26 Ekim 2018, 16:29:53
Yanitiniz icin cok tesekkur ederim. Aslinda wifi kullanma nedenimiz toplamda yuksek veri trafigi olacagini dusunmemiz,  mesh networking gibi kisimlar icinde ayrica bir gelistirme yapmamizin gerekmeyecek olmasi.

Sistemdeki sensorlerden oldukca yuksek miktarda veri gelebiliyor. MQTT ile yaptigimiz denemelerde basarili olamadik. ESP8266 ile olusturdugumuz TCP-UART bridge ilede istedigimiz performansi alamadik. Aslinda RPI ve WIFI'ye gecme nedenimiz bu oldu.

Başlık: Ynt: Tasarim Tavsiyesi
Gönderen: SpeedyX - 26 Ekim 2018, 23:53:05
Alıntı yapılan: gumush - 26 Ekim 2018, 16:29:53toplamda yuksek veri trafigi olacagini dusunmemiz
Merhaba,

Baştan tüm fizibiliteyi çıkarmış olmalısınız ki sistem tasarımı tavsiyesi alabilesiniz, öncelikle sayılarla gelmenizde yarar var; mesafeler, node sayıları, hızlar, veri boyutları, sıklıklar gibi veriler... (verilenler - istenilenler mantığı)

Benim anladığım kadarıyla, sizin "yüksek veri trafiği" için yüksek memory ve her node da bufferlama gerekiyor, çünkü sisteminiz bottleneck durumuna çok müsait görünüyor.
Başlık: Ynt: Tasarim Tavsiyesi
Gönderen: hwdesigner - 27 Ekim 2018, 00:14:49
RPI kullanmadım ancak fikir vereceğini düşündüğüm bir şeyden bahsetmek istiyorum.

Stm32 serisi denetleyicilerde DMA bulunuyor. Haberleşme hattı olsun, sensör datası adc v.s olsun aldığı bilgiyi direk belleğe yazıyor. İşlemcinin ana döngüsü bundan etkilenmiyor. Ve denetleyici olduğu için bu tarz işler için yapılmış. RPI nin yanına yaklaşamayacağı hızda örneklemeler yapabiliyor v.s

Kısacası veri kaydetmeyi DMA ile yapıp kayıtları bir veri tabanına yollamayı işlemcinin döngüsünde yapabilir misiniz sorusu geliyor aklıma.

Ethernete ve fazla fazla yeteceği bir çok cevre birimine sahip. Gömülü ile aranız iyiyse alternatif olabilir.

Lora da başarılı bir sistem. 115200 sizi kurtarırsa Rfsolition yada microchip in güzel ürünleri var. bizzat 1-2 kilometrede testler yaptım. Wifi için imkansız olabilecek koşullarda çalışıyorlar.

Başlık: Ynt: Tasarim Tavsiyesi
Gönderen: gumush - 28 Ekim 2018, 09:17:57
Sensor 1  - 10hz , 4 x 16bit int
Sensor 2  - 400hz , 9 x 16bit int ( Bu sensor uzerinden 32Khz'ya kadar veri alinabiliyor ancak bunu daha sonraki asamalara birakacagiz )
Sensor 3  - 10hz , 6 x 32bit int
Sensor 4  - 10hz , 4 x 16bit int 
Sensor 5  - 10hz , 6 x 16bit int seklinde.

Mesafeler 120m x 120m bir kare icinde hepsi diyebiliriz.

Onerileriniz icin tesekkur ederim.

Aslinda gomulu sistemler yerine yazilim yada linux kisminda'mi acmaliyim diye dusunuyorum. Cunku sistemi donanimsal olarak degistirmeyi dusunmuyoruz ( calisan sistem kaniti ve prototip asamasi sonrasinda farkli mimarileri dusunuebiliriz ). Bu nedenle odaklanmak istedigimiz bu sistem uzerindeki yazilim cozumleri. Bende konuyu buraya acarak sizleri yanlis yonlendirmis olabilirim.

Sizce konuyu baska bir yere tasimalimiyim ?
Başlık: Ynt: Tasarim Tavsiyesi
Gönderen: foseydon - 02 Kasım 2018, 15:51:38
rpi ile bu tarz işlere girmedim, o yüzden o yönde yorum yapmam abes olur. Fakat, ilk önerime istinaden ve verdiğiniz ek bilgiye bakarak bu işi mqtt vs. ile rhatça halledebiliyor olmalnız lazım. veri gönderme sıklığınız kabaca 40-45 bit/second ki bu bayağı düşük. bütçe el veriyorsa, hazır lora ürünlerinden alıp deneme yapmak faydalı olabilir.

ek: @ ile veya alıntı yaparak beni eklerseniz yazdıklarınıza takip etmem kolay olur. genelde güncen konulara bakıp çıkıyorum.