Akınsoft ve Akın Robotics: Kontrol Yazılım Sorumlusu / Yönetici Bilgisayar Mühendisi

2016-2019 yılları arasında Akınsoft ve Akın Robotics'te Kontrol Yazılım Sorumlusu / Yönetici Bilgisayar Mühendisi olarak çalıştım. Bu dönem, yazılım mühendisliği ile mekatronik altyapımın aynı ürün üzerinde sürekli kesiştiği ilk uzun soluklu profesyonel çalışma ortamıydı.

İnsansı robotik sistemlerde bir davranışın ekranda doğru görünmesi yeterli değildir. Yazılımın ürettiği durum fiziksel harekete, sesli etkileşime, sensör yorumuna veya haberleşme trafiğine dönüşebilir. Bu nedenle robot yazılımını birbirinden bağımsız masaüstü programları olarak değil; algılama, karar, kontrol, iletişim ve kullanıcı etkileşiminin aynı zaman çizgisinde çalıştığı bir sistem olarak ele aldım.

Kamuya açık bu sayfada ürünlerin bilinen adlarını ve genel mühendislik kapsamını kullanıyorum. Kurum içi protokol biçimleri, donanım adreslemeleri, özel mesaj yapıları ve ayırt edici sistem ayrıntıları paylaşılmamaktadır.

AROS / AR-CONTROL: Robot Kontrol Yazılımı

Çalışmalarımın merkezinde AROS / AR-CONTROL robot kontrol yazılımı bulunuyordu. Kontrol yazılımının görevi yalnız bir komutu çevre birimine iletmek değildi. Robot üzerindeki farklı alt sistemlerden gelen durumların izlenmesi, komutların doğru sırada yürütülmesi, kullanıcı veya üst seviye davranış katmanından gelen isteklerin fiziksel sistemin mevcut durumuyla uyumlu hale getirilmesi gerekiyordu.

Bu tür bir yazılımda hata kavramı masaüstü uygulamasından farklıdır. Yanlış bir durum geçişi robotun fiziksel davranışını etkileyebilir; geciken bir komut bir sonraki hareket dizisini bozabilir; haberleşmedeki kısa süreli bir kopma arayüzde yalnız "bağlantı hatası" olarak kalmaz, kontrol zincirinin tamamını etkileyebilir.

Bu nedenle kontrol katmanında durum yönetimi, hata sonrası toparlanma, haberleşmenin sürekliliği ve komutların fiziksel sistem üzerindeki sonuçları birlikte değerlendirilmek zorundaydı.

C, C++, C# başta olmak üzere Java ve Python ile Windows, Linux ve gömülü çalışma ortamları arasında geliştirme yaptım. Dil seçimini tek başına teknoloji tercihi olarak değil, çalışılan katmanın gereksinimine göre ele alıyordum: donanıma yakın ve zaman duyarlı bölüm ile kullanıcı arayüzünün ihtiyaçları aynı değildi.

AR-CORE: Otonomi ve Davranışın Üst Seviyede Yönetimi

Robotun tek tek motorlarını veya cihazlarını çalıştırmak ile anlamlı bir davranış üretmek arasında ayrı bir katman bulunuyordu. AR-CORE üzerinde çalışırken otonom davranışın yalnız bir "AI fonksiyonu" olmadığını, durum, zamanlama, sensör bilgisi ve kontrol çıktılarının birlikte yönetilmesi gerektiğini doğrudan gördüm.

Otonomi yazılımında bir davranışın başlaması kadar ne zaman duracağı, hangi olayın onu kesebileceği, başarısız alt adımın üst seviyeye nasıl yansıtılacağı ve aynı anda gelen farklı isteklerin nasıl önceliklendirileceği de önemlidir.

Bu dönem davranış modelleme çalışmalarımın temelini oluşturdu. Robotun davranışlarını yalnız sabit bir prosedür listesiyle yönetmek yerine, daha üst seviyede ifade edilebilen ve gerektiğinde farklı senaryolara uyarlanabilen yapılar üzerinde çalıştım.

Bir davranışın teknik olarak tamamlanması ile kullanıcı açısından anlamlı biçimde tamamlanması aynı şey değildi. Örneğin hareket komutu sonlanmış olabilir; ancak ilgili sensör geri bildirimi bekleniyorsa davranış mantığı henüz bir sonraki adıma geçmemelidir. Bu tür durumlar, fiziksel sistemlerde state machine ve event tabanlı tasarımın önemini pratikte görünür hale getiriyordu.

Ağaç ve Devre Tabanlı Görsel Programlama

Davranışların yalnız kaynak kod içinde tanımlanması, robotik senaryo geliştiren herkesin aynı programlama ayrıntılarını bilmesini gerektiriyordu. Bu problemi azaltmak için ağaç ve devre yaklaşımından yararlanan görsel programlama modelleri üzerinde çalıştım.

Amaç blokları ekrana sürükleyip bağlamaktan daha genişti. Görsel olarak oluşturulan yapının çalışma zamanında deterministik biçimde yorumlanması, geçersiz bağlantıların engellenmesi, parametrelerin doğru tipe taşınması ve kullanıcı tarafından oluşturulan davranışın robot kontrol katmanına güvenli biçimde aktarılması gerekiyordu.

Bu çalışma bana daha sonra kurumsal yazılımlarda da sık karşılaşacağım bir problemi öğretti: kullanıcıya esneklik veren bir sistem, aynı zamanda geçersiz durum uzayını mümkün olduğunca daraltmalıdır. Serbestlik arttıkça doğrulama, tip güvenliği, hata modeli ve gözlenebilirlik daha önemli hale gelir.

Görsel programlama tarafı ayrıca domain bilgisini kaynak koddan ayırma fikrini güçlendirdi. Davranış tanımı bir kullanıcı veya uzman tarafından değiştirilebilirken, yürütme motorunun güvenilirlik kuralları ayrı kalmalıydı.

AR-GUI ve Operatör Arayüzleri

AR-GUI ve ilişkili grafiksel arayüzlerde robotun durumunun anlaşılır biçimde izlenmesi ve kontrol edilebilmesi üzerine çalıştım. Bir robot kontrol arayüzü, klasik veri giriş ekranından farklıdır. Kullanıcı ekranda gördüğü değer ile robotun fiziksel durumu arasında güvenilir bir ilişki bekler.

Arayüz tarafında telemetri, durum gösterimi, hata bilgisi ve kontrol komutlarının birlikte ele alınması gerekiyordu. Kullanıcıya eski bir durum gösterilmesi veya komutun ulaşmadığı halde arayüzde uygulanmış görünmesi kabul edilebilir değildi.

Bu nedenle GUI'yi sistemin geri kalanından bağımsız bir sunum katmanı olarak görmedim. Haberleşme, durum senkronizasyonu ve fiziksel sistem davranışı arayüz tasarımının parçasıydı.

Robotik arayüzde okunabilirlik de yalnız estetik konu değildir. Operatörün sistem durumunu kısa sürede anlayabilmesi, kritik hata ile bilgilendirme mesajını ayırt edebilmesi ve hangi komutun aktif olduğunu görebilmesi doğrudan kullanılabilirlik ve güvenilirlik problemidir.

ADA H4, Grafiksel Arayüz ve Simülasyon

ADA H4 çalışmalarında grafiksel arayüz ve simülasyon yazılımı üzerinde görev aldım. Simülasyon burada yalnız görsel bir demo değildi; fiziksel sistem üzerinde denenmesi maliyetli veya riskli olabilecek davranışları yazılım tarafında değerlendirmek, arayüz ve kontrol akışını geliştirme sürecinde sınamak için önemliydi.

Gerçek robot ile simülasyon arasındaki temel sorun, iki tarafın zamanlama ve durum davranışının aynı varsayımları paylaşmasını sağlamaktır. Simülasyonda anında gerçekleşen bir geçiş fiziksel sistemde motor hareketi, haberleşme gecikmesi veya sensör geri bildirimi nedeniyle farklı zaman alabilir. Bu ayrımı geliştirme sırasında görünür kılmak, gerçek sisteme geçişte ortaya çıkabilecek sorunları azaltıyordu.

Simülasyon aynı zamanda hata senaryolarını daha kontrollü üretme imkânı veriyordu. Normal kullanımda nadir görülen durumları fiziksel sistem üzerinde tekrar tekrar oluşturmak yerine yazılım tarafında sınamak, hata yönetimi ve arayüz davranışını geliştirmeyi kolaylaştırıyordu.

Konuşma Tanıma ve Konuşma Sentezleme

Robotla doğal kullanıcı etkileşiminin önemli parçalarından biri sesli iletişimdi. HMM tabanlı konuşma tanıma çalışmaları, konuşma sentezleme ve komutların robot davranışlarıyla ilişkilendirilmesi üzerinde çalıştım.

O dönemin konuşma tanıma sistemlerini bugün kullandığım transformer tabanlı modellerle geriye dönük olarak yeniden adlandırmıyorum. Çalışmanın gerçek bağlamı HMM tabanlı tanıma, özellik çıkarımı, karar mantığı ve robot davranışıyla bütünleştirmeydi.

Bir ASR çıktısının metin olarak doğru görünmesi robotik sistem için tek başarı ölçütü değildir. Komutun yanlış zamanda kabul edilmesi, gürültünün komut gibi değerlendirilmesi veya tanıma sonucunun uygun bağlama taşınmaması fiziksel davranış üretebilir. Bu nedenle konuşma tanımayı kullanıcı arayüzünden çok kontrol sisteminin girdilerinden biri olarak düşünmek gerekiyordu.

TTS tarafında da amaç yalnız metni sese çevirmek değildi. Robotun davranış durumu, konuşmanın zamanı ve kullanıcıyla etkileşim akışı birlikte düşünülüyordu. Sesli geri bildirimin fiziksel hareketle çakışmaması veya kullanıcıya yanlış sistem durumu ifade etmemesi gerekiyordu.

Bu çalışmalar daha sonraki konuşma tanıma ve ses işleme çalışmalarımın teknik temellerinden biri oldu; ancak bugünkü modelleri ve performans seviyelerini geçmiş döneme taşımadan, dönemin araçlarını kendi bağlamında değerlendiriyorum.

Görüntü İşleme ve Algılama

Robotik sistemlerde görüntü işleme çalışmalarında kamera verisinin işlenmesi, sahne veya hedefle ilgili özelliklerin çıkarılması ve elde edilen bilginin üst seviye davranışa aktarılması üzerine çalıştım.

Burada bir bilgisayarlı görü algoritmasının tek başına yüksek doğruluk göstermesi yeterli değildi. Kameradan veri alma, görüntü ön işleme, hesaplama süresi, sonuçların güncelliği ve davranış katmanının bu sonucu hangi zaman penceresinde kullandığı birlikte önem taşıyordu.

Bu nedenle görüntü işleme ile robot kontrolünü ayrı ürünler gibi değil, ortak gecikme ve durum bütçesi olan bir işlem hattı gibi ele aldım.

Algılama sonucu gecikmişse teknik olarak doğru olsa dahi robotun mevcut fiziksel durumunu temsil etmeyebilir. Bu, daha sonra gerçek zamanlı AI sistemlerinde sık kullandığım "freshness" yaklaşımının erken örneklerinden biriydi.

Haberleşme ve Telemetri

Robot üzerinde farklı yazılım ve donanım katmanlarının birlikte çalışabilmesi için haberleşme ve telemetri sürekli kullanılan altyapı bileşenleriydi. Kontrol komutlarının hedefe iletilmesi kadar, robotun gerçek durumunun geriye taşınması da önemliydi.

Telemetriyi yalnız debug için açılan bir pencere olarak görmedim. Sistemin hangi durumda olduğunu, hangi komutun ne zaman uygulandığını ve davranışın nerede beklenenden saptığını anlamanın temel araçlarından biriydi.

Farklı alt sistemlerin veri üretim hızları ve hata davranışları aynı değildi. Bir bileşenin kısa süreli gecikmesinin bütün kontrol döngüsünü bekletmemesi, eski verinin güncel durum gibi yorumlanmaması ve bağlantı kesintilerinin fiziksel sistem açısından güvenli karşılanması gereken konulardı.

Bu yaklaşım, telemetriyi gözlemleme verisi olmanın ötesinde sistem durumunun tutarlılığını değerlendiren bir araç haline getiriyordu.

Eşzamanlılık ve Performans

Robotik sistemler doğal olarak eşzamanlıdır. Sensör verisi gelirken kullanıcı komutu işlenebilir, konuşma tanıma ayrı bir hesaplama yükü oluşturabilir, telemetri akışı sürerken kontrol katmanı fiziksel hareketi yönetebilir.

Bu nedenle thread kullanmak tek başına çözüm değildi. Hangi işin hangi sıklıkta çalışacağı, paylaşılan durumun nasıl korunacağı, arayüz thread'i ile arka plan işlemlerinin nasıl ayrılacağı ve ağır bir algılama işinin kontrol tepkisini geciktirmemesi gerekiyordu.

Bu dönemde performans optimizasyonuna yalnız "kod daha hızlı çalışsın" açısından bakmamaya başladım. Robotik sistemde gecikmenin konumu önemlidir. Kullanıcının görsel arayüzünde 100 ms ile kontrol döngüsündeki 100 ms aynı sistem etkisine sahip değildir.

Aynı şekilde CPU kullanımını düşürmek de tek başına hedef değildir. Daha düşük CPU tüketimi daha fazla gecikme veya daha eski sensör verisi pahasına sağlanıyorsa sistem davranışı kötüleşebilir. Ölçülmesi gereken, fiziksel görevin uçtan uca davranışıdır.

Programlama Standartları ve Sürdürülebilirlik

Uzun süre geliştirilen robotik yazılımda çalışan ilk çözümün korunabilir olması önemliydi. Programlama standartları, nesne yönelimli tasarım, ortak veri modelleri ve modüller arasındaki sınırlar üzerinde çalıştım.

Kontrol, otonomi, GUI, konuşma ve görüntü işleme katmanlarının aynı kod tabanında birbirine bağımlı hale gelmesi değişiklik maliyetini hızla artırabilirdi. Bu nedenle sorumlulukları ayırmak, ortak davranışı tekrar etmemek ve bir modülün iç ayrıntısını diğerine taşımamak pratik bir gereksinimdi.

Robotik projelerde donanım revizyonları da yazılım sınırlarını test eder. Donanım ayrıntısı üst katmanlara sızmışsa küçük bir elektronik değişiklik geniş kod değişikliğine dönüşebilir. Bu nedenle arayüzlerin ve cihaz bağımlı katmanların belirgin olması bakım maliyetini doğrudan etkiliyordu.

Yönetici Bilgisayar Mühendisi ve Kontrol Yazılım Sorumluluğu

Görevim zaman içinde yalnız tek bir bileşen geliştirmekten, kontrol yazılımının daha geniş teknik bütünlüğünü takip etmeye evrildi. Bir değişikliğin yalnız kendi modülünde çalışması değil, robotun geri kalanıyla uyumlu olması gerekiyordu.

Bu sorumluluk kod inceleme, hata analizi, farklı modüllerin birlikte çalışması ve geliştirmenin fiziksel sistem üzerindeki sonucunu takip etmeyi içeriyordu. Robot üzerinde görülen bir sorun bazen kontrol yazılımından, bazen haberleşmeden, bazen algılama katmanından veya fiziksel sistemden kaynaklanabiliyordu. Doğru sorunu doğru katmana taşıyabilmek, doğrudan kod yazmak kadar önemli hale geldi.

Teknik sorumluluk arttıkça "benim kodum çalışıyor" yaklaşımı anlamını kaybeder. Ürün davranışı birden fazla modülün ortak sonucudur; kendi bileşeninizin sınırında bitmeyen sorunları da sistem seviyesinde takip etmek gerekir.

Bu Dönemin Profesyonel Etkisi

Akınsoft ve Akın Robotics dönemi benim için robotik teknoloji listesinden ibaret değildir. Bir kullanıcı komutunun mikrofon veya arayüzden başlayıp davranış modeline, kontrol katmanına, haberleşmeye ve fiziksel harekete kadar uzanan yolunu aynı sistem içinde görme fırsatı sundu.

Bu deneyim daha sonraki çalışmalarımda da koruduğum birkaç yaklaşımı netleştirdi: gerçek zamanlı davranışı uçtan uca ölçmek, algılama ile karar katmanını birbirinden ayırmak, fiziksel sistemde hatayı yalnız yazılım semptomuna göre sınıflandırmamak ve kullanıcı arayüzünü gerçek sistem durumundan koparmamak.

Bugün yapay zeka, konuşma işleme veya yüksek hacimli servis sistemleri üzerinde çalışırken kullandığım sistem yaklaşımının önemli bir bölümü, robotik sistemlerde farklı katmanların aynı fiziksel davranışı üretmek zorunda olduğu bu yıllarda şekillendi.

Akınsoft ve Akın Robotics

Teknik İçeriklerle Bağlantı

Bu dönemdeki robot kontrolü, sensör/aktüatör ve fiziksel sistem yaklaşımının teorik karşılığı Mekatronik Sistemlerin Temelleri ile Mikroişlemci, Mikrodenetleyiciler, FPGA ve PLC sayfalarında; konuşma tarafının devamı ise MFCC ile Konuşma Özellik Çıkarımı ve Whisper Mimarisi notlarımda görülebilir.