Tüm yazılar
23 · Ar-Ge ve donanım · 2025.11 · 5 dk

Raspberry Pi üzerinde telemetri arayüzü: veri akarken akıcı kalmak

Raspberry Pi üzerinde çalışan araç takip ve navigasyon sisteminde canlı GPS, interaktif harita ve anlık telemetriyi tek bir arayüzde topladım. Bu notta gömülü bir cihazda veri toplama ile arayüz performansını birlikte düşünmenin neleri değiştirdiğini anlatıyorum.

01Tek ekran fikri

Bu projeyi bireysel olarak geliştirdim: gömülü sistem, veri toplama, arayüz ve teknik altyapının tamamı bendeydi. Çıkış noktası basitti. Araçla ilgili konum ve durum verilerini ayrı kaynaklardan takip etmek yerine, bunları gömülü cihaz üzerinde tek bir anlaşılır arayüzde sunmak istedim. Canlı GPS verisi, interaktif harita, navigasyon ve anlık telemetri aynı ekranda bir araya geliyor.

Telemetri tarafında hız, sinyal gücü, batarya durumu ve sensör verileri yer alıyor. Kâğıt üzerinde bunları bir ekrana yerleştirmek zor görünmüyor. Asıl zorluk, hepsi aynı anda güncellenirken arayüzün akıcı kalması ve bunun güçlü bir masaüstü bilgisayarda değil, Raspberry Pi üzerinde gerçekleşmesi.

Tek ekran fikrinin bir de kullanıcı tarafı var. Araç içinde kullanılan bir arayüze uzun uzun bakılmıyor, bir bakışta okunabilmesi gerekiyor. Bu yüzden hangi bilginin ekranın neresinde duracağı, hangisinin büyük, hangisinin ikincil görüneceği de performans kadar önemli bir karar. Görsel sadelik ile teknik hafiflik çoğu zaman aynı yöne çekiyor: daha az öğe hem daha kolay okunuyor hem de cihazı daha az yoruyor.

02Gömülü cihaz farklı bir bütçe demek

Web arayüzü geliştirirken çoğu zaman güçlü bir makinenin üzerinde çalıştığımı unutuyorum. Gereksiz bir yeniden çizim, fazladan bir animasyon ya da sık tetiklenen bir güncelleme orada fark edilmeyebiliyor. Gömülü bir sistemde aynı alışkanlıklar hemen hissediliyor. İşlemci, bellek ve grafik kapasitesi sınırlı ve bu sınırı hem veri toplama hem de arayüz paylaşıyor.

Bu yüzden arayüzü tasarlarken her öğenin bir maliyeti olduğunu kabul ederek başladım. Ekranda görünen her değerin ne sıklıkla güncellenmesi gerektiğini ve hangi değişikliğin kullanıcıya gerçekten bir şey söylediğini düşünmek gerekiyor. Bir sayının saniyede defalarca değişmesi, okunabilirliğe hiçbir katkı sağlamadığı halde kaynak tüketebiliyor.

veri akışı
GPS ve sensörler ──> donanım seviyesinde veri toplama ──> güncel durum
                                                           ├──> harita ve navigasyon görünümü
                                                           └──> telemetri paneli (hız, sinyal, batarya, sensörler)

03Veri toplama ile arayüzü ayırmak

Donanım seviyesinde veri toplama ile kullanıcı arayüzünü bir araya getirirken ikisinin birbirini bekletmemesine özen gösterdim. Benim yaklaşımım, veriyi toplayan tarafın kendi ritminde çalışması ve arayüzün bu veriyi kendi ihtiyacı kadar okuması. Bir sensörden gelen her yeni değer, ekranın yeniden çizilmesi anlamına gelmek zorunda değil.

Bu ayrım, sorunları birbirinden yalıtmayı da kolaylaştırıyor. Bir veri kaynağı yavaşladığında ya da geçici olarak kesildiğinde arayüzün donmaması gerekiyor. Örneğin sinyal gücünün düşmesi kullanıcıya gösterilmesi gereken bir bilgi, arayüzü kilitleyen bir durum değil. Telemetri ekranının asıl işi de zaten bu tür değişimleri sakin bir biçimde görünür kılmak.

Her yeni değer ekrana koşmak zorunda değil: arayüz, veriyi ihtiyacı kadar okumalı.

04Harita en ağır bileşen

İnteraktif harita, arayüzün en çok kaynak isteyen parçası. Konum değiştikçe haritanın güncellenmesi, navigasyon bilgisinin üzerine işlenmesi ve kullanıcının haritayla etkileşime girebilmesi aynı anda gerçekleşiyor. Bu bileşeni telemetri paneliyle aynı sınırlı kaynakları paylaşacak şekilde dengelemek, bence bu tür bir sistemde optimizasyonun en kritik kısmı.

Burada genel bir ilkeye dayanıyorum: kullanıcının dikkatinin olduğu yere öncelik vermek. Araç hareket halindeyken konumun ve navigasyonun güncel kalması önemli. Telemetri değerlerinin okunabilir olması da önemli, ama her birinin milisaniye düzeyinde güncellenmesi gerekmiyor. Öncelikleri böyle ayırmak, sınırlı kaynağı daha bilinçli kullanmamı sağlıyor.

05Bütün katmanların aynı masada olması

Bütün katmanların bende olması, performans sorunlarına tek bir yerden bakabilmemi sağladı. Arayüzde hissedilen bir takılmanın kaynağı veri toplamada mı, sistem altyapısında mı, yoksa arayüzün kendisinde mi, bunu ayırt edebilmek için her katmanı tanımak gerekiyor. Bir ekipte bu sorular katmanlar ve kişiler arasında gidip gelebilir. Tek başına çalışırken hepsi aynı masada duruyor.

Bu proje, arayüz performansını sonradan iyileştirilecek bir ayrıntı olarak değil, veri akışının tasarımıyla birlikte düşünülmesi gereken bir konu olarak görmemi sağladı. Donanımdan gelen bilgiyi güncel tutmak ile ekranın akıcı kalması, aynı sorunun iki farklı yüzü.

İlgili yazılar
  1. 24Sahadan gelen veri: akıllı tarımda edge işleme ve bağlantı koşullarıAr-Ge ve donanım2025.105 dk
  2. 25Analizden altyapıya: freelance işlerde bütün süreci üstlenmekÜrün ve analiz2025.095 dk