Robotik Mühendisliği

2017 başında AKINSOFT ve AKINROBOTICS'te robot kontrolü, otonomi, davranış modelleme, konuşma teknolojileri, görüntü işleme ve telemetri aynı ürün geliştirme ortamında kesişiyordu. 2016-2019 arasındaki çalışmalarım, robotun mekanik ve elektronik gerçekliği ile yazılımın durum, zamanlama ve hata davranışını ayrı katmanlar değil, tek bir sistem olarak ele almamı gerektirdi.

Robotik bu dönemde benim için yalnız akademik bir konu değildi; doğrudan üretim ortamında yazılım geliştirdiğim bir alandı. O tarihte Kırıkkale Üniversitesi Bilgisayar Mühendisliği eğitimimi tamamlamıştım. AKINSOFT'ta çalışırken Sakarya Üniversitesi Mekatronik programından mezun oldum ve Afyon Kocatepe Üniversitesi Mekatronik Mühendisliği eğitimine başladım. Böylece algoritma, işletim sistemi, ağ, veri yapıları ve yazılım mühendisliği temelleri; elektrik motorları, sensörler, mekanik, kontrol, elektronik ve fiziksel sistem davranışıyla aynı mesleki problem üzerinde birleşmeye başladı.

Bir yıl önceki Baykar stajım da bu geçişte önemli bir basamaktı. TMS570/lwIP gömülü ağ çalışmaları, aviyonik donanım-yazılım hata ayıklaması, telemetri ve MISRA C/statik analiz deneyimi; robotik sistemlerde daha sonra karşılaştığım gerçek zamanlılık, gözlenebilirlik, fiziksel geri besleme ve güvenilir yazılım problemlerine doğrudan hazırlık sağladı. Bu bağın havacılık tarafını Aviyonik Sistemler ve İnsansız Hava Araçları notunda ayrıca ele alıyorum.

Robotik mühendisliğini tek bir cihaz sınıfı olarak değil, algılama, hesaplama, karar, kontrol ve fiziksel eylemin aynı zaman çizgisinde birleştiği sistem mühendisliği alanı olarak ele alıyorum. Kaynak kod doğru olsa bile sensör yanlış ölçüyorsa, zaman damgası eskiyse, aktüatör doygunluğa girdiyse veya operatör arayüzü fiziksel durumu yanlış gösteriyorsa robot doğru çalışmış sayılmaz.

Ünite 1: Robotik mühendisliğinin sistem çerçevesi

Robot ile otomasyon arasındaki sınır

Her otomatik makine robot değildir; her robot da tam otonom değildir. Robotik sistemler genellikle fiziksel çevreyle algılama ve eylem yoluyla etkileşir, programlanabilir davranış üretir ve en azından belirli durum değişikliklerine göre farklı tepki verebilir.

Bir sistemin otonomi düzeyi tek bir ikili özellik değildir. Aynı robot:

• bazı görevleri doğrudan operatör komutuyla,
• bazılarını yarı otonom,
• bazılarını tamamen otomatik

yürütebilir.

Bu nedenle robotik tasarımda ilk soru “robot otonom mu?” değil, hangi karar hangi katmanda ve hangi güven sınırları içinde veriliyor? olmalıdır.

Algıla-karar ver-eyle çevrimi

Bir robotu en genel biçimde şu çevrimle ifade etmek mümkündür:

çevre -> sensörler -> durum kestirimi -> karar / plan -> kontrol -> eyleyiciler -> çevre

Bu çevrimde her ok bir mühendislik sınırıdır. Sensör verisinin elektriksel işaretten sayısal değere dönüşmesi, zamanlanması, filtrelenmesi ve bir üst katmana taşınması ayrı problemlerdir. Benzer biçimde üst düzey “kolu uzat” isteği, motor sürücüsünün anlayacağı gerilim/akım/PWM düzeyine doğrudan çevrilemez; arada kinematik, yörünge ve kontrol katmanları bulunur.

Robotik neden disiplinler arasıdır?

Robotik mühendisliği aynı anda şu alanlara dayanabilir:

• mekanik tasarım ve mukavemet,
• elektrik ve elektronik,
• sensörler ve ölçme,
• motorlar, sürücüler, hidrolik ve pnömatik,
• kontrol kuramı,
• sinyal işleme,
• gömülü sistemler,
• gerçek zamanlı yazılım,
• bilgisayarlı görü,
• konuşma işleme,
• yapay zeka,
• ağ ve haberleşme,
• insan-makine etkileşimi.

Mekatronik sistemlerin temelleri ile robotik arasındaki güçlü bağ buradan gelir. Mekatronik, bu alt sistemlerin birlikte tasarlanmasını öğretir; robotik ise bu bütünleşmeyi algılama, davranış ve hareket üretimiyle daha ileri taşır.

Ünite 2: Robot mimarisi ve temel alt sistemler

Mekanik gövde ve kinematik yapı

Robotun fiziksel gövdesi yük taşır, eklemleri sınırlar ve çalışma uzayını belirler. Manipülatörlerde bağlantı elemanları ve eklemler bir kinematik zincir oluşturur. Mobil robotlarda ise şasi, tekerlek/palet/bacak geometrisi ve kütle dağılımı hareket kabiliyetini belirler.

Bir robotun yazılımını tasarlarken mekanik geometriyi “donanım ekibinin konusu” olarak dışarıda bırakmak doğru değildir. Eklemin fiziksel hareket aralığı, boşluğu, sürtünmesi, redüksiyon oranı ve atalet momenti kontrol yazılımının davranışını doğrudan etkiler.

Eklemler ve serbestlik derecesi

En temel eklem türleri:

• dönel eklem,
• prizmatik eklem

olarak düşünülebilir. Bir dönel eklem açısal, prizmatik eklem doğrusal hareket üretir.

Bir robotun serbestlik derecesi, bağımsız hareket değişkenlerinin sayısını ifade eder. Üç boyutlu uzayda serbest bir rijit cismin altı serbestlik derecesi vardır:

• x, y, z doğrusal hareketleri,
• roll, pitch, yaw dönmeleri.

Bir manipülatörün eklem sayısı ile görev uzayındaki etkin serbestlik derecesi her zaman birebir aynı anlamı taşımaz. Kısıtlar, kapalı kinematik zincirler ve tekil konumlar kullanılabilir hareket uzayını değiştirir.

Uç eyleyici

Manipülatörün çevreyle doğrudan iş yapan son bileşeni uç eyleyicidir. Uç eyleyici:

• iki veya üç parmaklı tutucu,
• vakum tutucu,
• elektromıknatıs,
• kaynak tabancası,
• boya aparatı,
• tornavida,
• ölçüm probu

olabilir.

Uç eyleyici seçimi yalnız “nesneyi tutabiliyor mu?” sorusuna indirgenemez. Nesnenin yüzeyi, ağırlığı, kırılganlığı, izin verilen kavrama kuvveti, konum toleransı ve süreç hızı birlikte değerlendirilir.

Robot sınıfları

Mekanik yapı ve kullanım biçimine göre yaygın sınıflar arasında:

• Kartezyen robotlar,
• silindirik robotlar,
• küresel/polar robotlar,
• SCARA yapıları,
• mafsallı robot kolları,
• paralel robotlar,
• tekerlekli/paletli mobil robotlar,
• bacaklı robotlar,
• insansı robotlar

bulunur.

Bu sınıflandırmalar “en iyi robot” seçmez. Her geometri çalışma uzayı, rijitlik, hız, taşıma kapasitesi, kontrol karmaşıklığı ve maliyet arasında farklı bir ödünleşim oluşturur.

Ünite 3: Eyleyiciler, sürücüler ve güç sistemi

Elektrik motorları

Robotik sistemlerde hareket çoğunlukla elektrik motorlarıyla üretilir. DC motor, BLDC motor, step motor ve servo sistemlerin avantajları farklıdır.

Bir motor seçerken yalnız azami devir sayısına bakmak yeterli değildir. Temel değişkenler:

• sürekli ve tepe moment,
• hız aralığı,
• moment-hız eğrisi,
• rotor ataleti,
• verim,
• besleme gerilimi,
• sürücü gereksinimi,
• ısıl sınırlar,
• geri besleme çözünürlüğüdür.

Motorun katalogda yüksek hız üretebilmesi, robot ekleminde aynı hızın kullanılabileceği anlamına gelmez. Redüktör, yük ataleti, mekanik dayanım ve kontrol çevrimi birlikte sınır koyar.

Servo sistem

Servo, yalnız küçük model motorlarının adı değildir. Genel anlamıyla servo sistem; hedef büyüklüğü geri beslemeyle izleyen hareket sistemidir.

Basit bir konum servosu şu çevrimi kurar:

hedef konum -> kontrolcü -> motor sürücüsü -> motor/eklem -> konum sensörü -> geri besleme

AKINSOFT dönemimde robotik kontrol yazılımında fiziksel hareketin yalnız komut üretmekten ibaret olmadığını sürekli gördüm. Komutun “gönderildi” olması ile eklemin gerçekten hedefe ulaşması farklı durumlardır. Üst seviye davranışın doğru ilerleyebilmesi için geri besleme ve zamanlama bilgisinin güvenilir olması gerekir.

Aktarma organları

Motorun hareketi doğrudan kullanılmayabilir. Dişli kutuları, kayış-kasnak, zincir, vida-mil, harmonik redüktör veya başka mekanizmalar:

• hızı azaltabilir,
• momenti artırabilir,
• hareket yönünü değiştirebilir,
• doğrusal harekete dönüştürebilir.

Aktarma oranı büyüdükçe motor tarafında gereken moment azalabilir; buna karşılık boşluk, sürtünme, esneklik ve verim kaybı kontrol doğruluğunu etkileyebilir.

Hidrolik ve pnömatik eyleyiciler

Yüksek kuvvet gereken uygulamalarda hidrolik sistemler; hızlı, basit doğrusal hareketlerde pnömatik sistemler kullanılabilir. Bunların kontrol problemi elektrik motorlarından farklıdır. Basınç, valf dinamiği, sıkıştırılabilirlik, kaçak ve akış karakteristiği önem kazanır.

Sakarya Üniversitesi Mekatronik eğitiminde elektrik motorları, hidrolik ve pnömatik gibi konuların aynı müfredatta bulunmasının mesleki karşılığını robotik sistemlerde daha açık gördüm: yazılımın “hareket” olarak gördüğü soyut komut, farklı fiziksel eyleyici türlerinde tamamen farklı dinamiklere sahiptir.

Güç bütçesi

Mobil robotlarda enerji sınırlı bir kaynaktır. Toplam güç bütçesi yalnız motorlardan oluşmaz:

• işlemci/GPU,
• sensörler,
• kamera,
• haberleşme birimleri,
• sürücüler,
• ses sistemi,
• yardımcı elektronik

aynı kaynağı paylaşabilir.

Ani motor akımı, besleme geriliminde düşüm oluşturarak işlemci veya sensör tarafını etkileyebilir. Bu nedenle güç bütünlüğü, yazılımda görülen rastlantısal yeniden başlama veya iletişim hatalarının gerçek nedeni olabilir.

Ünite 4: Sensörler, ölçüm ve robot algısı

İç ve dış algılama

Robot sensörleri işlevsel olarak iki grupta düşünülebilir:

İç algılama: robotun kendi durumunu ölçer.

• eklem konumu,
• hız,
• motor akımı,
• sıcaklık,
• batarya seviyesi,
• yönelim.

Dış algılama: çevreyle ilgili bilgi sağlar.

• kamera,
• lidar,
• ultrasonik sensör,
• kuvvet/tork sensörü,
• yakınlık sensörü,
• mikrofon,
• ışık sensörü.

Bu ayrım mutlak değildir. Örneğin bir kamera hem çevre algısı hem kalibrasyon/konum kestirimi için kullanılabilir.

Ölçüm, gerçeklik değildir

Her sensör şu sorularla birlikte ele alınmalıdır:

• çözünürlüğü nedir?
• doğruluğu nedir?
• bias var mı?
• gürültü spektrumu nasıl?
• örnekleme hızı nedir?
• gecikmesi ne kadar?
• doygunluk sınırı nedir?
• veri ne zaman geçersiz kabul edilir?

Ölçüm değerini fiziksel gerçekliğin kendisi gibi kullanmak, robotik yazılımda en tehlikeli soyutlama hatalarından biridir.

Enkoderler

Döner veya doğrusal enkoderler eklem konumunu ve buradan türetilen hızı ölçmek için kullanılır. Artımlı enkoder bağıl hareket verir; mutlak enkoder güç kesilse bile konumu kodlayabilir.

Konumdan hız türetirken fark alma işlemi ölçüm gürültüsünü büyütebilir:

v[k] ≈ (x[k] - x[k-1]) / Δt

Bu nedenle filtreleme ile gecikme arasında denge gerekir. Aşırı filtreleme daha temiz grafik üretirken kontrol için eski veri sağlayabilir.

IMU ve yönelim

IMU; ivmeölçer ve jiroskop başta olmak üzere hareket kestiriminde kullanılan sensörleri bir araya getirir. Jiroskop entegrasyonu zamanla sürüklenebilir; ivmeölçer ise doğrusal ivme ve yerçekimini birlikte görür. Manyetometre çevresel manyetik bozulmadan etkilenebilir.

Bu yüzden tek sensör yerine sensör füzyonu kullanmak yaygındır. Filtreleme ve durum kestirimi yaklaşımı probleme göre tamamlayıcı filtre, Kalman ailesi veya başka yöntemlerle kurulabilir.

Kamera ve görüntü işleme

Kamera yüksek bilgi yoğunluğu sağlar fakat ham görüntü doğrudan “anlam” değildir. Tipik bir işleme hattı:

kamera -> kare yakalama -> ön işleme -> özellik/nesne çıkarımı -> izleme -> karar katmanı

AKINSOFT ve AKINROBOTICS'te görüntü işleme çalışmalarımda yalnız algoritmanın tek karede doğru sonuç vermesi yeterli değildi. Sonucun robot davranışında kullanılabilmesi için gecikme, güncellik ve üst seviye davranışla zaman uyumu da gerekiyordu. Bir algılama sonucu 500 ms önceki sahneyi doğru tanımlıyorsa, hareketli robot için bugün yanlış kararın girdisi olabilir.

Ses algısı

Mikrofon dizisi veya tek mikrofon, robotun sesli komut alması ve çevresel sesleri işlemesi için kullanılabilir. Robotik bağlamda konuşma tanıma sonucu yalnız metin değildir; fiziksel eylem tetikleyebilen bir kontrol girdisidir. Bu nedenle güven eşiği, bağlam, yanlış kabul ve iptal davranışı önemlidir.

Ünite 5: Koordinat sistemleri ve kinematik

Konum ve yönelim

Robotik hesaplamalarda “nerede?” sorusu tek başına yeterli değildir; “hangi yönde?” sorusu da gerekir. Bir uç eyleyicinin uzaydaki durumu genellikle konum ve yönelim birlikte düşünülerek ifade edilir.

Üç boyutlu konum:

p = [x y z]^T

ile gösterilebilir. Yönelim için dönme matrisi, Euler açıları veya quaternion gibi temsiller kullanılabilir.

Referans çerçeveleri

Bir robot üzerinde birden fazla koordinat çerçevesi bulunabilir:

• dünya çerçevesi,
• robot tabanı,
• gövde,
• eklemler,
• uç eyleyici,
• kamera,
• hedef nesne.

Bir kameranın ölçtüğü nesne konumunu robot koluna vermek için kamera ile robot tabanı arasındaki geometrik dönüşüm bilinmelidir.

Homojen dönüşüm matrisi konum ve yönelimi tek yapıda taşır:

T = [ R  p ]
    [ 0  1 ]

Burada R 3x3 dönme matrisi, p ise 3x1 konum vektörüdür.

İleri kinematik

İleri kinematik, eklem değişkenleri bilindiğinde uç eyleyicinin konum ve yönelimini bulur:

q -> x

Seri manipülatörde dönüşümler zincirlenir:

T_0^n(q) = A_1(q_1) A_2(q_2) ... A_n(q_n)

Bu hesap, ekranda robot modelini çizmekten hareket kontrolüne kadar birçok işlevin temelidir.

Ters kinematik

Ters kinematikte istenen uç eyleyici duruşundan eklem değerleri aranır:

x -> q

Problem ileri kinematiğe göre daha zordur. Bir hedef için:

• tek çözüm,
• birden fazla çözüm,
• sonsuz çözüm,
• hiç çözüm

olabilir.

Yazılım yalnız matematiksel çözüm üretmemelidir. Eklem limitleri, çarpışma, mekanik kablo sınırları ve mevcut konuma göre en uygun çözüm de değerlendirilmelidir.

Çalışma uzayı

Robotun ulaşabildiği konum ve yönelimlerin tamamı çalışma uzayını oluşturur. Çalışma uzayı mekanik geometri, eklem sınırları ve tekilliklerle belirlenir.

Bir hedefin koordinat olarak tanımlanabilmesi onun robot tarafından erişilebilir olduğu anlamına gelmez.

Ünite 6: Jacobian, tekillik ve robot dinamiği

Diferansiyel kinematik

Uç eyleyici hızı ile eklem hızları arasındaki ilişki Jacobian matrisiyle ifade edilir:

x_dot = J(q) q_dot

J(q) robot konfigürasyonuna bağlıdır. Robot hareket ettikçe Jacobian da değişir.

Bu ilişki hız kontrolü, kuvvet dönüşümü, ters kinematiğin sayısal çözümleri ve tekillik analizi için önemlidir.

Tekillik

Bazı robot konfigürasyonlarında Jacobian gerekli rank koşulunu kaybedebilir. Bu durumda robot belirli görev uzayı yönlerinde hareket kabiliyetini kaybedebilir veya küçük görev uzayı hızı için çok büyük eklem hızları gerekebilir.

Tekillik yalnız matematiksel bir istisna değildir. Gerçek sistemde:

• hız komutlarının büyümesi,
• moment taleplerinin artması,
• kontrolün hassaslaşması,
• yol planlayıcının başarısız olması

gibi sonuçlar doğurabilir.

Kuvvet ve moment ilişkisi

İdealize edilmiş biçimde uç eyleyicideki kuvvet ile eklem momentleri arasında:

τ = J(q)^T F

ilişkisi kullanılır.

Bu, robot kolunun çevreye uyguladığı kuvvetin eklemlerde nasıl bir yük oluşturduğunu anlamada temel araçlardan biridir.

Dinamik model

Seri bir robotun hareket denklemi genel biçimde:

M(q) q_ddot + C(q, q_dot) q_dot + g(q) + f(q_dot) = τ

şeklinde ifade edilebilir.

Burada:

• M(q): kütle/atalet matrisi,
• C: Coriolis ve merkezkaç etkileri,
• g(q): yerçekimi,
• f: sürtünme,
• τ: eklem momentleridir.

Düşük hızda çalışan basit bir sistemde ayrıntılı dinamik model gerekmeyebilir. Yüksek hız, yüksek hassasiyet veya değişken yükte ise yalnız kinematik yeterli olmaz.

Ünite 7: Robot kontrolü ve geri besleme

Açık ve kapalı çevrim

Açık çevrim sistemde komut verilir fakat çıktı üzerinden düzeltme yapılmaz. Kapalı çevrimde ise ölçülen durum hedefle karşılaştırılır.

hata = hedef - ölçülen

Bu yapı Otomatik Kontrol notunun robotik karşılığıdır.

PID kontrol

Yaygın kontrol yapılarından biri PID'dir:

u(t) = Kp e(t) + Ki ∫e(t)dt + Kd de(t)/dt

• P terimi mevcut hataya,
• I terimi biriken hataya,
• D terimi hata değişim hızına

tepki verir.

Robot eklemlerinde PID yaygındır ancak her problem için tek başına yeterli değildir. Besleme ileri denetim, yerçekimi telafisi, durum geri beslemesi, tork kontrolü ve model tabanlı yöntemler gerekebilir.

Kaskat kontrol

Bir servo sistemde çevrimler katmanlı olabilir:

konum çevrimi -> hız çevrimi -> akım/moment çevrimi -> motor

İç çevrim daha hızlı çalışır. Dış çevrim daha üst düzey hedefi üretir. Yazılım mimarisi de bu zaman ölçeklerine uymalıdır.

Doygunluk ve anti-windup

Gerçek eyleyici sonsuz komut üretemez. Motor gerilimi, akım, hız ve mekanik sınırlar vardır. Kontrolcü bu sınırları yok sayarsa özellikle integral terimi birikip toparlanmayı geciktirebilir.

Robot kontrolünde yazılımın fiziksel sınırları modellemesi bu nedenle zorunludur.

Güvenli durum

Haberleşme kopması, sensör geçersizliği veya kontrolcü hatasında sistemin nasıl davranacağı önceden tanımlanmalıdır. “Komut gelmiyorsa son komutu sürdür” bazı sistemlerde tehlikelidir. Başka bir sistemde ise ani duruş daha tehlikeli olabilir.

Güvenli davranış robotun görevine ve fiziksel yapısına göre tasarlanır.

Ünite 8: Hareket planlama, görev yürütme ve otonomi

Yol ve yörünge ayrımı

Yol, geometrik olarak nereden geçileceğini; yörünge ise bunun zamanla nasıl yürütüleceğini ifade eder.

Bir yol çarpışmasız olabilir ancak hızlanma ve moment sınırları nedeniyle fiziksel olarak uygulanamayabilir.

Arama ve planlama

Izgara veya grafik tabanlı ortamlarda Dijkstra ve A* gibi arama algoritmaları; sürekli yüksek boyutlu uzaylarda örnekleme tabanlı yöntemler kullanılabilir. Robotik planlama problemi yalnız en kısa yolu bulmak değildir. Maliyet fonksiyonu:

• mesafe,
• enerji,
• çarpışma riski,
• dönüş sayısı,
• zaman,
• görüş alanı

gibi etkenleri içerebilir.

Davranış katmanı

AKINROBOTICS'te AR-CORE üzerinde çalışırken üst seviye davranışın tek bir “AI fonksiyonu” olmadığını doğrudan gördüm. Bir davranış:

• başlatılmalı,
• alt adımlara ayrılmalı,
• olaylarla kesilebilmeli,
• başarısızlık üretmeli,
• gerektiğinde geri alınmalı,
• başka davranışlarla önceliklendirilmelidir.

Bu nedenle otonomi çoğu zaman durum makineleri, davranış ağaçları, görev grafikleri, olay sistemleri ve planlayıcıların birlikte çalıştığı bir yürütme problemidir.

Ağaç ve devre tabanlı görsel programlama

AKINSOFT dönemimde davranışların görsel olarak tanımlanmasını sağlayan ağaç/devre yaklaşımı üzerinde belirgin biçimde çalıştım. Buradaki esas problem blokları ekrana yerleştirmek değildi; kullanıcı tarafından kurulan yapının çalışma zamanında güvenilir biçimde yürütülmesiydi.

Bir görsel davranış editöründe:

• geçersiz bağlantılar engellenmeli,
• veri tipleri korunmalı,
• parametreler doğrulanmalı,
• döngüler ve bağımlılıklar kontrol edilmeli,
• çalışma zamanı hatası görünür olmalı,
• yürütme motoru UI'dan ayrılmalıdır.

Bu yaklaşım daha sonra farklı yazılım alanlarında kullandığım önemli bir ilkeyi pekiştirdi: kullanıcıya esneklik verirken geçersiz durum uzayını daraltmak gerekir.

Otonomi ve belirsizlik

Sensör verisi kesin değildir. Otonom davranış katmanı bu nedenle “nesne bulundu/bulunmadı” gibi aşırı kesin ikilikler yerine güven, yaş, kaynak ve geçerlilik bilgisini gerektiğinde taşımalıdır.

Fiziksel sistemde yanlış pozitif sonuç, yalnız hatalı bir etiket değil, gerçek hareket üretebilir.

Ünite 9: Gömülü sistem ve robot yazılım mimarisi

Katmanlı mimari

Bir robot yazılımını şu katmanlarla düşünmek yararlıdır:

Donanım / sürücüler
        ↓
Cihaz soyutlama ve haberleşme
        ↓
Gerçek zamanlı kontrol
        ↓
Durum ve yetenek servisleri
        ↓
Davranış / görev / otonomi
        ↓
Operatör arayüzü ve harici sistemler

Her projede bu kadar kesin katman bulunması gerekmez; fakat sorumlulukların ayrılması donanım değişikliğinin üst seviyedeki bütün yazılıma yayılmasını önler.

AROS / AR-CONTROL deneyimi

AKINSOFT & AKINROBOTICS çalışmalarımın merkezinde AROS / AR-CONTROL robot kontrol yazılımı vardı. Burada tek bir motor komutundan çok daha geniş bir problemle uğraştım:

• farklı alt sistemlerin durumunu izleme,
• komut sıralaması,
• haberleşme sürekliliği,
• hata sonrası toparlanma,
• fiziksel sistem ile yazılım durumunun eşleştirilmesi,
• üst seviye davranıştan gelen isteklerin güvenli biçimde yürütülmesi.

C, C++, C#, Java ve Python gibi farklı dilleri aynı ürün ailesinin farklı ihtiyaçlarında kullandım. Donanıma yakın zaman duyarlı kod ile GUI veya üst seviye karar katmanının gereksinimleri aynı değildi. Dil ve çalışma ortamı seçimini katmanın sorumluluğuna göre değerlendirmek burada doğal hale geldi.

Mikrodenetleyiciler ve çevre birimleri

Robotun alt seviyesinde:

• GPIO,
• PWM,
• ADC,
• enkoder sayıcıları,
• UART,
• SPI,
• I2C,
• CAN veya benzeri veri yolları

gibi çevre birimleri bulunabilir.

Bu katmanda zamanlama, interrupt davranışı, buffer yönetimi ve hata durumları fiziksel sonuç üretir. Mikroişlemci, Mikrodenetleyiciler, FPGA ve PLC alanındaki çalışmalarım ile 2015 Baykar'daki TMS570/lwIP deneyimi, AKINROBOTICS'teki robot yazılımını anlamamı kolaylaştıran doğrudan altyapıydı.

Gerçek zamanlılık

Gerçek zamanlı sistem, yalnız hızlı sistem değildir. Önemli olan hesaplamanın doğru sonuca doğru zaman sınırı içinde ulaşmasıdır.

Bir görüntü işleme görevi 200 ms geç sonuç verdiğinde kullanıcı yalnız küçük bir gecikme görebilir. Aynı 200 ms, denge veya eklem kontrol çevriminde kabul edilemez olabilir.

Bu nedenle robot yazılımında gecikme tek sayı olarak ölçülmez; gecikmenin hangi kontrol halkasında oluştuğu belirleyicidir.

Eşzamanlılık

Robot üzerinde aynı anda:

• sensör okuma,
• kontrol,
• telemetri,
• görüntü işleme,
• konuşma tanıma,
• kullanıcı komutu,
• loglama

çalışabilir.

Thread sayısını artırmak tek başına çözüm değildir. Paylaşılan durumun sahipliği, kilit süresi, öncelik terslenmesi, kuyruk büyümesi ve eski verinin işlenmesi kontrol edilmelidir.

Ünite 10: Haberleşme, telemetri ve dağıtık durum

Komut ile durum aynı şey değildir

Bir komutun gönderilmesi, alındığı veya uygulandığı anlamına gelmez. Sağlam bir protokol gerektiğinde şu durumları ayırmalıdır:

oluşturuldu -> gönderildi -> alındı -> kabul edildi -> uygulanıyor -> tamamlandı / başarısız

Robot GUI'sinin “başarılı” işareti vermesi için hangi aşamanın yeterli olduğu açıkça tanımlanmalıdır.

Telemetri

Telemetri yalnız hata ayıklama çıktısı değildir. Robotun çalışma anındaki durumunu daha sonra açıklayabilmek için mühendislik kanıtıdır.

Yararlı telemetri:

• zaman damgası,
• durum kimliği,
• sensör değerleri,
• komutlar,
• kontrolcü çıktıları,
• hata kodları,
• bağlantı durumu,
• kaynak kullanımı

gibi veriler taşıyabilir.

AR-CONTROL ve AR-GUI çalışmalarında telemetriyi, fiziksel robot ile operatör arayüzü arasındaki durum tutarlılığını görmenin temel araçlarından biri olarak kullandım.

Veri güncelliği

Dağıtık robotik sistemde “en son alınan değer” her zaman “şu an geçerli değer” değildir. Paket gecikmiş, sırada beklemiş veya yeniden iletilmiş olabilir.

Bu nedenle veriye:

• ölçüm zamanı,
• alınma zamanı,
• sıra numarası,
• geçerlilik süresi

gibi bağlamlar eklemek gerekebilir.

Bağlantı kaybı

Bağlantı kaybı yalnız ağ katmanı hatası değildir. Robotun görev mantığında bir olaydır.

Üst seviye sistem şu sorulara cevap vermelidir:

• robot son görevi sürdürmeli mi?
• durmalı mı?
• güvenli konuma dönmeli mi?
• yerel otonomiyle devam etmeli mi?
• operatöre hangi durum gösterilmeli?

Bu düşünce Bilgisayar Ağları ile robot kontrolü arasındaki doğrudan bağdır.

Ünite 11: İnsan-robot etkileşimi, GUI, konuşma ve görüntü

AR-GUI ve operatör arayüzü

AR-GUI üzerinde çalışırken bir robot kontrol arayüzünün klasik CRUD ekranından tamamen farklı olduğunu gördüm. Kullanıcı ekranda gördüğü durumun fiziksel dünyadaki robotla uyumlu olduğuna güvenmek zorundadır.

Arayüz:

• bağlantı durumunu,
• robot modunu,
• aktif görevi,
• sensör/eklem durumunu,
• kritik hatayı,
• uygulanmakta olan komutu

ayırt edilebilir biçimde göstermelidir.

Eski telemetriyi yeni veri gibi sunmak veya uygulanmamış bir komutu uygulanmış göstermek yalnız UX hatası değildir; operasyonel hata üretir.

Bu yaklaşım günümüzde UI/UX mühendisliği çalışmalarımda savunduğum “durum görünürlüğü” ilkesinin fiziksel sistemlerdeki karşılığıdır.

Konuşma tanıma

AKINROBOTICS'te belirgin biçimde uğraştığım alanlardan biri HMM tabanlı otomatik konuşma tanıma idi. Günümüzde transformer tabanlı ASR yaygın olsa da o dönemde akustik özellik çıkarımı, HMM durumları, sözlük/dil bilgisi ve karar süreçleri daha görünür bileşenlerdi.

Robotik kullanımda ASR için doğruluk tek ölçüt değildir. Şunlar da önemlidir:

• yanlış komut kabul oranı,
• gürültü altında davranış,
• komut başlangıç/bitiş tespiti,
• tanıma gecikmesi,
• güven eşiği,
• mevcut davranış bağlamı.

Bir masaüstü dikte sistemindeki yanlış kelime kullanıcı tarafından düzeltilebilir. Fiziksel hareket başlatan yanlış robot komutu ise farklı güvenlik sınıfındadır.

Konuşma işleme tarafındaki bu erken deneyim, daha sonra MFCC ile özellik çıkarımı, otomatik konuşma tanıma ve üretim ölçekli ASR sistemleri üzerinde çalışmamın teknik başlangıç noktalarından biri oldu.

Konuşma sentezleme

TTS, robotun yalnız “konuşmasını” sağlamaz; sistem durumunu insana ileten bir çıktı kanalıdır. Sesli çıktı:

• hareketle zamanlanmalı,
• kesilebilir olmalı,
• yanlış durum bildirmemeli,
• yüksek öncelikli uyarıyla çatışmamalıdır.

Robotun “işlem tamamlandı” demesi ile görevin gerçekten tamamlanması aynı state değişimine bağlı olmalıdır.

Görüntü işleme

Robotik görüntü işleme algoritması; kamera, kalibrasyon, görüntü zamanı, işlem gecikmesi ve davranış katmanından ayrı düşünülemez.

Bir nesne algılama sisteminin yüksek doğruluğu, sonuç fiziksel hareket başlamadan önce geçerliliğini yitiriyorsa yeterli değildir. Bu nedenle throughput kadar age-of-information, yani bilginin yaşı da önemlidir.

Ünite 12: Endüstriyel, mobil ve insansı robotlar

Endüstriyel robotlar

Endüstride robotların güçlü olduğu işler genellikle:

• tekrarlı,
• hassas,
• ağır,
• tehlikeli,
• yüksek çevrim hızına sahip

görevlerdir.

Robotik uygulamalar içinde punta ve ark kaynağı, boyama, yükleme-boşaltma ve montaj; tekrarlanabilirlik ile proses güvenliğinin birlikte değerlendirildiği klasik endüstriyel örneklerdir.

Bir endüstriyel robot seçerken yalnız erişim mesafesi değil:

• taşıma kapasitesi,
• tekrarlanabilirlik,
• çevrim süresi,
• çalışma uzayı,
• proses kuvveti,
• güvenlik bölgesi,
• entegrasyon maliyeti,
• bakım kabiliyeti

değerlendirilmelidir.

Mobil robotlar

Mobil robotlarda ana problem manipülatörden farklıdır. Robotun kendi tabanı çevrede hareket ettiği için konum kestirimi, haritalama ve yol planlama öne çıkar.

Tekerlek kinematiği, kayma, zemin koşulları ve sensör görüşü lokalizasyonun doğruluğunu belirler. GPS dış ortamda yardımcı olabilir; iç ortamda lidar, kamera, odometri ve başka sensörlerin birleşimi gerekebilir.

Tehlikeli ortam robotları

Robotların önemli kullanım alanlarından biri insan için riskli ortamlardır. Maden, biyokimyasal numune alma, radyasyon ve yangın gibi ortamlar; robotun yalnız görevi değil, kendi çevresel dayanımını da tasarım problemi haline getirir.

Bu uygulamalar “insanı robota değiştir” kadar basit değildir. Robotun kendisi de:

• sıcaklık,
• radyasyon,
• su,
• toz,
• patlayıcı atmosfer,
• kimyasal kirlenme

nedeniyle arızalanabilir. Dolayısıyla çevre dayanımı görev tasarımının parçasıdır.

İnsansı robotlar

İnsansı robot, insan biçimini yalnız görsel amaçla taklit etmez. İnsan ortamlarına uyum, merdiven/kapı/araç gibi insan ölçülerine göre tasarlanmış çevrede çalışma ve doğal etkileşim gibi hedefler humanoid tasarımı anlamlı kılar.

Buna karşılık serbestlik derecesi arttıkça:

• kinematik,
• denge,
• enerji tüketimi,
• gerçek zamanlı kontrol,
• kablolama,
• mekanik dayanım,
• yazılım durum uzayı

hızla karmaşıklaşır.

AKINROBOTICS'teki insansı robot çalışmaları bu karmaşıklığı günlük mühendislik problemi haline getiren dönemdi.

Ünite 13: Simülasyon, test ve hata ayıklama

ADA H4 ve simülasyon

ADA H4 çalışmalarında grafiksel arayüz ve simülasyon yazılımı üzerinde görev aldım. Simülasyonu yalnız demo görüntüsü olarak değil, gerçek robot üzerinde pahalı veya riskli olabilecek durumları daha kontrollü değerlendirme aracı olarak kullandım.

Simülasyonun temel sınırı şudur: fiziksel sistemin gecikme, sürtünme, boşluk, gürültü ve hata davranışı modele doğru yansıtılmadıkça simülasyon gereğinden iyimser olabilir.

SIL, HIL ve gerçek sistem

Robot yazılımı farklı seviyelerde doğrulanabilir:

• yazılım içinde simülasyon,
• model/algoritma testi,
• Software-in-the-Loop,
• Hardware-in-the-Loop,
• tezgah testi,
• gerçek robot testi.

Her seviyenin bulduğu hata türü farklıdır. Bir kinematik birim testi yanlış işaretli dönüşümü yakalayabilir; ancak motor sürücüsündeki elektriksel gürültüyü yakalayamaz.

Uçtan uca hata ayıklama

Fiziksel robotta “kol yanlış yere gidiyor” problemi şu zincirin herhangi bir noktasında olabilir:

hedef -> ters kinematik -> yörünge -> kontrol -> sürücü -> motor -> mekanik -> sensör -> geri besleme

Bu nedenle iyi hata ayıklama katmanlar arasında veri izler.

2015 Baykar'da gömülü yazılım, elektronik devre ve gerçek sinyali aynı problem üzerinde takip etmiş olmam; AKINROBOTICS'te fiziksel robot ile yazılım durumunu birlikte inceleme yaklaşımımı doğrudan etkiledi.

Log ve yeniden üretilebilirlik

Bir robot hatası laboratuvarda tekrar üretilemiyorsa şu veriler kritik hale gelir:

• zaman çizelgesi,
• komutlar,
• sensörler,
• konfigürasyon,
• yazılım sürümü,
• hata kodları,
• sistem modu.

“Bende çalıştı” fiziksel sistem için yeterli doğrulama değildir.

Ünite 14: Güvenilirlik, güvenlik ve bakım yapılabilirlik

Fiziksel sınırların yazılımla korunması

Robot yazılımı eklem limitlerini, hız sınırlarını, sıcaklık ve akım sınırlarını yalnız GUI doğrulaması olarak görmemelidir. Kritik sınırlar mümkün olduğunca ilgili düşük seviyede de uygulanmalıdır.

Tek bir üst seviye yazılım hatası, mekanik sınırın aşılmasına yol açmamalıdır.

Watchdog ve yaşam belirtisi

Dağıtık robot sistemlerinde bir bileşenin çalışıyor görünmesi ile gerçekten görevini zamanında yapması farklıdır. Watchdog veya heartbeat mekanizması:

• süreç yaşıyor mu,
• döngü ilerliyor mu,
• veri güncel mi,
• kontrol görevi deadline içinde mi

gibi farklı anlamlarda tasarlanabilir.

Hata izolasyonu

Bir kamera arızası, hareketin tamamını zorunlu olarak durdurmalı mı? Cevap göreve bağlıdır. Sistem fonksiyonları kritik önemine göre ayrılırsa bir alt sistem hatasının gereksiz yere bütün robotu çökertmesi önlenebilir.

Programlama standartları

Baykar'daki MISRA C ve statik analiz çalışmalarımdan sonra AKINSOFT döneminde de sürdürülebilirlik ve kod standardı konularını fiziksel sistem güvenilirliğinin parçası olarak değerlendirdim. Robotik kod tabanı uzun süre yaşadığında:

• cihaz bağımlılıklarının izole edilmesi,
• ortak veri modelleri,
• deterministik durum geçişleri,
• açık hata sözleşmeleri,
• sorumlulukların ayrılması

bakım maliyetini ve hata yayılımını doğrudan etkiler.

Güvenlik

Robot güvenliği yalnız acil durdurma düğmesi değildir. Risk; robotun hızı, kuvveti, çalışma alanı, insanla fiziksel yakınlığı ve kontrol biçimine bağlıdır. Endüstriyel uygulamalarda mekanik koruma, emniyet devreleri, yazılım limitleri ve operasyon prosedürü birlikte düşünülür.

Ünite 15: AKINSOFT & AKINROBOTICS deneyimimin mühendislik bağlamı

Eğitim ile işin aynı dönemde birleşmesi

AKINSOFT'taki çalışma dönemim, benim için bilgisayar mühendisliği ile mekatroniğin gerçek anlamda birleştiği dönemdi. Kırıkkale Üniversitesi Bilgisayar Mühendisliği geçmişim bana algoritma, yazılım, işletim sistemi, ağ ve bilgisayar mimarisi tabanı sağlamıştı. Sakarya Üniversitesi Mekatronik eğitimi; motor, elektronik, kontrol, hidrolik/pnömatik ve mekanik tasarımın yazılım dışındaki fiziksel katmanlarını güçlendirdi. AKINSOFT'ta çalışırken bu programdan mezun olup Afyon Kocatepe Üniversitesi Mekatronik Mühendisliği programına başlamam, teorik ve pratik öğrenmenin aynı dönemde birbirini beslemesini sağladı.

Derslerde gördüğüm bir kontrol veya sensör konusu işte fiziksel robot davranışı olarak karşıma çıkıyor; işte yaşadığım problem ise üniversitedeki matematik ve sistem modellemesinin neden gerekli olduğunu daha görünür hale getiriyordu.

AROS / AR-CONTROL

En yoğun çalıştığım alanlardan biri robot kontrol yazılımıydı. Buradaki mühendislik problemi; cihazlara komut göndermekten, robotun gerçek durumu ile yazılım durumu arasında güvenilir bir eşleme kurmaya kadar uzanıyordu.

Kontrol yazılımı benim için şu soruların cevabıydı:

• robot şu anda hangi durumda?
• hangi komut yürütülüyor?
• komut gerçekten fiziksel olarak uygulandı mı?
• sensör geri bildirimi bunu doğruluyor mu?
• haberleşme kesilirse ne olacak?
• hata üst katmana nasıl yansıyacak?

AR-CORE ve otonomi

AR-CORE tarafında davranışların daha üst seviyede yönetimi, görev akışı, olaylar ve otonomi üzerinde çalıştım. Burada önemli olan tek tek fonksiyonların varlığı değil, bu fonksiyonların zaman içinde doğru sırada ve doğru koşullarda birleşmesiydi.

Otonominin en zor kısmının çoğu zaman “zeki algoritma” değil, sınır durumlarını yönetmek olduğunu burada öğrendim.

AR-GUI

Operatör arayüzü tarafında telemetri, hata, mod ve komutların fiziksel sistemle tutarlı gösterilmesi üzerine çalıştım. Bu deneyim daha sonra geliştirdiğim bütün gerçek zamanlı kullanıcı arayüzlerinde şu ilkeye dönüştü:

UI, sistem durumunu süsleyen yüzey değil; sistem durumunun güvenilir bir temsilidir.

HMM tabanlı ASR ve TTS

Robotun kullanıcıyla konuşma üzerinden etkileşiminde HMM tabanlı ASR, özellik çıkarımı, tanıma mantığı ve davranış entegrasyonuyla uğraştım. TTS tarafında ise konuşmanın yalnız üretilmesi değil, robotun davranış zaman çizgisine doğru yerleştirilmesi önemliydi.

Bu çalışmalar daha sonra ses işleme, konuşmacı tanıma ve büyük ölçekli konuşma tanıma sistemlerine geçişimde güçlü bir temel oluşturdu.

Görüntü işleme

Kamera verisinin işlenmesi, görüntüden anlamlı bilgi çıkarılması ve bu bilginin davranış katmanında kullanılması üzerinde çalıştım. Buradaki en kalıcı ders, algoritmik doğruluğun tek başına yeterli olmadığıydı. Robotik sistemde sonuç zamanında ve geçerli bağlam içinde üretilmelidir.

Görsel davranış programlama

Ağaç/devre tabanlı görsel programlama üzerinde yaptığım çalışmalar, domain davranışını kaynak koddan ayırmanın erken bir örneğiydi. Görsel model kullanıcıya kolaylık sağlarken yürütme motorunun tip, durum, hata ve zamanlama kurallarını koruması gerekiyordu.

Bugün “niyet ile gerçekleme katmanını ayırmak” olarak ifade ettiğim birçok yazılım mimarisi fikrinin erken pratik karşılıklarından biri bu çalışmaydı.

Teknik sorumluluğun genişlemesi

Görevim zaman içinde tek tek modül geliştirmekten kontrol yazılımının daha geniş teknik bütünlüğünü değerlendirmeye doğru genişledi. Bu, yalnız daha fazla kod yazmak anlamına gelmiyordu. Alt sistem sınırları, ekip içi entegrasyon, hata davranışı ve sürdürülebilirlik daha önemli hale geldi.

Bu dönem robotik mühendisliğini benim için bir uzmanlık başlığından çok sistem düşünme biçimi haline getirdi.

Ünite 16: Robotik mühendisliğinden çıkardığım genel ilkeler

Fizik, yazılım gereksiniminin parçasıdır

Yazılım fiziksel sistemi kontrol ediyorsa mekanik ve elektriksel sınırlar “harici detay” değildir.

Ölçüm ile gerçek aynı değildir

Sensör değerinin hata, zaman ve geçerlilik bağlamı korunmalıdır.

Otonomi durum yönetimidir

Planlama ve yapay zeka önemli olsa da güvenilir otonomi; başarısızlık, kesinti, öncelik ve geri kazanım davranışı olmadan tamamlanmış sayılmaz.

Gecikmenin yeri önemlidir

100 ms GUI gecikmesi ile 100 ms motor kontrol gecikmesi aynı değildir.

Telemetri tasarım gereksinimidir

Fiziksel sistemin sahadaki davranışı sonradan açıklanabilmelidir.

Arayüz güvenilirlik zincirinin parçasıdır

Operatör yanlış durumu görüyorsa alttaki doğru hesaplama görevi kurtarmayabilir.

Simülasyon gerçeğin yerine geçmez

Model, gerçek sistemin hangi özelliklerini içermiyorsa o alanlarda güvence sağlayamaz.

Modülerlik yalnız kod estetiği değildir

Donanım revizyonları ve çok katmanlı robot yazılımı, iyi sınırlandırılmamış bağımlılıkların maliyetini çok hızlı büyütür.

Sonuç

Robotik mühendisliği, mekanik bir gövdeye yazılım eklemek değildir.

Sensör fiziksel dünyayı ölçer.

Durum kestirimi ölçümü anlamlı modele dönüştürür.

Planlama ve davranış katmanı ne yapılacağını belirler.

Kontrol, istenen davranışı zaman içinde fiziksel sisteme uygular.

Eyleyici elektriksel komutu kuvvet ve harekete çevirir.

Telemetri sistemin ne yaptığını görünür kılar.

Operatör arayüzü insanı bu çevrime bağlar.

Güvenlik, hata yönetimi ve test ise bu parçaların tek tek değil birlikte güvenilir olmasını sağlamaya çalışır.

Benim açımdan robotik, 2015'te Baykar'da gördüğüm gömülü ve fiziksel sistem disiplininin 2016-2019 AKINSOFT & AKINROBOTICS döneminde çok daha geniş bir uygulamaya dönüşmesidir. Bilgisayar mühendisliği altyapım, eş zamanlı devam eden mekatronik eğitimlerim ve gerçek insansı robot yazılımı geliştirme deneyimi aynı dönemde birbirini besledi.

AROS/AR-CONTROL, AR-CORE, AR-GUI, ADA H4, görsel davranış programlama, HMM tabanlı konuşma tanıma, TTS, görüntü işleme ve telemetri üzerinde çalışmak bana robotik sistemde “yazılım” diye bağımsız bir ada olmadığını gösterdi.

Bir robotun davranışı; kod, elektronik, mekanik, kontrol, veri ve zamanın ortak sonucudur.

Kaynaklar

Bruno Siciliano, Lorenzo Sciavicco, Luigi Villani, Giuseppe Oriolo, Robotics: Modelling, Planning and Control, Springer.

Mark W. Spong, Seth Hutchinson, M. Vidyasagar, Robot Modeling and Control, Wiley.

John J. Craig, Introduction to Robotics: Mechanics and Control, Pearson.

Peter Corke, Robotics, Vision and Control: Fundamental Algorithms in MATLAB, Springer.

AKINSOFT ve AKINROBOTICS iş deneyimim

Mekatronik Sistemlerin Temelleri

Otomatik Kontrol

Aviyonik Sistemler ve İnsansız Hava Araçları