İstisna nedir?

İstisna, program çalışırken normal akışı bozan olağan dışı bir durumu temsil eden nesnedir. C# içerisindeki bütün istisnalar doğrudan veya dolaylı olarak System.Exception sınıfından türetilir.

Bir işlemin başarısız olma olasılığını $P(E)$, hatanın sisteme vereceği zararı da $C(E)$ ile gösterirsek basitleştirilmiş risk hesabı şöyle yazılabilir:

İstisna yönetimi hatanın oluşma ihtimalini her zaman azaltmaz; fakat $C(E)$ değerini düşürerek hatanın uygulamanın tamamına yayılmasını engeller.

try-catch-finally mimarisi

Aşağıdaki örnek bir dosyayı okumayı dener, olası hataları türlerine göre izole eder ve işlem sonunda bilgi verir:

try
{
    string metin = File.ReadAllText("ayarlar.json");
    Console.WriteLine(metin);
}
catch (FileNotFoundException ex)
{
    Console.WriteLine($"Dosya bulunamadı: {ex.FileName}");
}
catch (UnauthorizedAccessException)
{
    Console.WriteLine("Dosyaya erişim yetkiniz yok.");
}
catch (IOException ex)
{
    Console.WriteLine($"Girdi/çıktı hatası: {ex.Message}");
}
finally
{
    Console.WriteLine("Dosya okuma denemesi tamamlandı.");
}

catch blokları özelden genele doğru sıralanmalıdır. Önce Exception yakalanırsa daha özel bloklara sıra gelmez. Ayrıca her yerde genel Exception yakalayıp hatayı sessizce yutmak, yangın alarmının pilini çıkarmaya benzer: ortam sessizleşir ama yangın devam eder.

Bir istisnayı aynı çağrı yığını bilgisiyle yeniden göndermek için throw; kullanılmalıdır. throw ex; ifadesi yığın izini değiştirerek hatanın gerçek kaynağını bulmayı zorlaştırabilir.

Özel hata sınıfları

İş kuralları için hazır istisnalar her zaman yeterince açıklayıcı değildir. Örneğin stok miktarının yetersiz olması teknik değil, alan odaklı bir problemdir:

public class YetersizStokException : Exception
{
    public int MevcutStok { get; }

    public YetersizStokException(string mesaj, int mevcutStok)
        : base(mesaj)
    {
        MevcutStok = mevcutStok;
    }
}

public static void SiparisVer(int istenen, int stok)
{
    if (istenen > stok)
    {
        throw new YetersizStokException(
            "İstenen miktar stoktan fazla.", stok);
    }
}

Bu sınıf, hataya yalnızca mesaj değil, MevcutStok gibi yapılandırılmış bağlam da ekler. Üst katman böylece kullanıcıya uygun bildirim gösterebilir veya işlemi başka bir depoya yönlendirebilir.

Sağlam kullanım ilkeleri

• İstisnaları yalnızca gerçekten olağan dışı durumlarda kullanın; normal kontrol akışını throw ile kurmayın.
• ArgumentException, InvalidOperationException ve FileNotFoundException gibi uygun hazır türleri tercih edin.
• Hataları bağlam bilgisiyle loglayın; parola ve erişim anahtarı gibi hassas verileri kaydetmeyin.
• IDisposable kaynaklarında mümkünse using kullanın; derleyici gerekli temizliği güvenli biçimde oluşturur.
• Kullanıcıya sade mesaj, geliştiriciye ise ayrıntılı log sağlayın.

Doğru tasarlanmış istisna yönetimi hataları yok etmez; onları sınırlar, görünür kılar ve uygulamanın güvenli biçimde toparlanmasına yardımcı olur. Kısacası try-catch-finally, kodun emniyet kemeridir: kazayı engellemeyebilir ama sonucunu ciddi ölçüde kontrol eder.

``

Bağlama tam olarak nedir?

Bağlama, bir çağrı ifadesinin çalıştırılacak fonksiyon gövdesiyle eşleştirilmesidir. Statik bağlamada karar, değişkenin derleme zamanındaki türüne göre verilir. Dinamik bağlamada ise virtual mekanizması üzerinden nesnenin çalışma zamanındaki gerçek türü kullanılır.

Bunu kabaca şöyle düşünebiliriz:

Fonksiyon sanal değilse çoğunlukla $T_{statik}$ belirleyicidir. Sanal fonksiyon çağrısında ise uygun koşullarda $T_{dinamik}$ devreye girer.

Hata 1: Sanal olmayan yıkıcı

Polimorfik bir taban sınıfın yıkıcısını sanal yapmamak, en tehlikeli karışıklıklardan biridir:

#include <iostream>

class Kaynak {
public:
    ~Kaynak() { std::cout << "Kaynak kapandı\n"; }
};

class Dosya : public Kaynak {
public:
    ~Dosya() { std::cout << "Dosya kapandı\n"; }
};

int main() {
    Kaynak* kaynak = new Dosya;
    delete kaynak; // Tanımsız davranış!
}

delete işlemi taban işaretçisi üzerinden yapıldığı için yıkıcının dinamik davranması gerekir. Çözüm basittir:

virtual ~Kaynak() = default;

Bir sınıfta sanal metot varsa yıkıcının da genellikle sanal olması beklenir.

Hata 2: Varsayılan argümanların sanal olduğunu sanmak

Sanal fonksiyonun gövdesi dinamik, varsayılan argümanı ise statik olarak seçilir:

#include <iostream>

struct Bildirim {
    virtual void gonder(int oncelik = 1) {
        std::cout << oncelik << '\n';
    }
};

struct Alarm : Bildirim {
    void gonder(int oncelik = 9) override {
        std::cout << oncelik << '\n';
    }
};

int main() {
    Alarm alarm;
    Bildirim& b = alarm;
    b.gonder(); // Alarm::gonder çalışır, fakat argüman 1 olur.
}

Ortaya hibrit bir sonuç çıkar: gövde alt sınıftan, değer taban sınıftan gelir. Varsayılan değeri tek yerde tanımlamak veya parametresiz ayrı bir sanal olmayan arayüz kullanmak daha güvenlidir.

Hata 3: Kurucuda sanal çağrı

Kurucu sırasında nesnenin alt sınıf bölümü henüz hazır değildir. Bu nedenle taban kurucusundan yapılan sanal çağrı, alt sınıf sürümüne gitmez:

struct Motor {
    Motor() { baslat(); }
    virtual void baslat() { /* taban davranışı */ }
};

struct TurboMotor : Motor {
    void baslat() override { /* turbo henüz hazır olmayabilir */ }
};

Nesneyi oluşturduktan sonra çağrılan bir initialize() metodu veya fabrika fonksiyonu kullanmak daha açık bir yaşam döngüsü sağlar.

Hata 4: Nesne dilimleme

Alt sınıf nesnesini değer olarak taban türe kopyalamak dinamik tür bilgisini keser:

void calistir(Motor motor) { // Kopyalama ve dilimleme
    motor.baslat();
}

Bunun yerine Motor&, Motor* veya uygun bir akıllı işaretçi kullanılmalıdır.

Sağlam tasarım kontrol listesi

• Ezilen her metoda override ekleyin.
• Polimorfik tabanlarda sanal yıkıcı kullanın.
• Sanal metotlarda farklı varsayılan argümanlardan kaçının.
• Kurucu ve yıkıcılarda sanal dispatch’e güvenmeyin.
• Polimorfik nesneleri değer yerine referans veya işaretçiyle taşıyın.
• Overload ile override kavramlarını aynı şey sanmayın.

Kısacası virtual, tasarıma sihir serpiştiren bir kelime değildir. Hangi kararın derleyiciye, hangisinin çalışma zamanına bırakıldığını açıkça belirlemek gerekir; aksi hâlde kod derlenir, çalışır ve tam en kötü anda yanlış şeyi yapar.

Yürüme döngüsü neden periyodiktir?

Bir gait cycle, aynı ayağın iki benzer teması arasındaki hareket dizisidir. Döngü genellikle tek destek, çift destek, salınım ve temas geçişi evrelerine ayrılır. Eklem açıları tam olarak tekrarlanmasa bile sistem durumunun benzer bir yörüngeyi izlemesi beklenir.

Robotun durumu şu vektörle gösterilebilir:

Burada $\mathbf{q}$ eklem konumlarını, $\dot{\mathbf{q}}$ ise hızları temsil eder. Kararlı yürüyüşte durum uzayındaki hareket, limit döngü adı verilen kapalı bir yörünge oluşturur. Robot küçük bir itme aldığında yörüngeden uzaklaşabilir; önemli olan birebir aynı noktaya değil, tekrar bu döngüye yaklaşmasıdır. Buna yörüngesel kararlılık denir.

Zaman değil, faz neden önemlidir?

Sadece saate bakarak “robot adımın yüzde 40’ında” demek yanıltıcı olabilir. Yokuş, zemin esnekliği veya dışarıdan gelen bir itme adım süresini değiştirir. Faz değişkeni ise hareketin fiziksel ilerleyişini takip eder:

Örneğin kalça açısı ve açısal hızı birlikte kullanılarak faz düzleminde bir yörünge çizilebilir. Böylece kontrolcü, kronometreden bağımsız biçimde ayağın salınımın başında mı yoksa yere temas etmek üzere mi olduğunu anlayabilir.

Kararlılık nasıl ölçülür?

Yürümenin belirli bir olayında, örneğin sağ topuk temasında, sistem durumu örneklenebilir. Bu kesite Poincaré kesiti denir. Ardışık adımlar arasındaki ilişki

şeklinde yazılır. Sabit yürüyüş için $\mathbf{x}^=P(\mathbf{x}^)$ olmalıdır. Haritanın sabit nokta çevresindeki özdeğerleri, yani Floquet çarpanları, kritik bilgiyi verir. Baskın çarpanın mutlak değeri $\vert \lambda_{max}\vert <1$ ise sapmalar küçülür; $\vert \lambda_{max}\vert >1$ ise robot birkaç adım sonra dramatik bir “yerçekimiyle tanışma” yaşayabilir.

Basit bir faz portresi

Aşağıdaki Python kodu, idealize edilmiş bir eklem hareketinin açı-hız faz portresini üretir. Kapalı eğri, periyodik davranışın görsel imzasıdır:

import numpy as np
import matplotlib.pyplot as plt

# Bir adımlık örnek kalça açısı
phase = np.linspace(0, 2 * np.pi, 500)
angle = 0.35 * np.sin(phase)
angular_velocity = 0.35 * np.cos(phase)

plt.plot(angle, angular_velocity)
plt.xlabel("Eklem açısı (rad)")
plt.ylabel("Açısal hız (rad/s)")
plt.title("Kalça Eklemi Faz Portresi")
plt.grid(True)
plt.axis("equal")
plt.show()

Gerçek robotta eğrinin kalınlaşması sensör gürültüsünü, giderek genişlemesi kararsızlığı, bozucu sonrası yeniden daralması ise toparlanmayı gösterebilir. Bu analiz; ZMP, basınç merkezi ve gövde kütle merkezi ölçümleriyle birleştirildiğinde daha anlamlı hâle gelir.

Kontrolcüye sağladığı avantaj

Faz analizi sayesinde kontrol sistemi ayağın yere temas zamanını ayarlayabilir, adım uzunluğunu değiştirebilir ve gövde momentumunu dengeleyebilir. Ayrıca farklı hızlardaki yürüyüşler tek bir faz koordinatında karşılaştırılabilir. Kısacası faz, robotun yalnızca ne yaptığını değil, hareketin hangi bölümünde ve ne kadar kararlı biçimde yaptığını söyler. Dengeli bir humanoid için doğru adım kadar, doğru anda atılan adım da belirleyicidir.

İki bacak üzerinde yürümek insanlar için sıradan, robotlar için ise sürekli çözülmesi gereken bir denge problemidir. Robotun kütle merkezi destek alanının dışına çıktığında yer çekimi hemen devreye girer ve pahalı metal kahramanımız yere doğru dramatik bir yolculuğa başlar. Ters sarkaç modeli, bu karmaşık gövde ve eklem sistemini daha anlaşılır bir fizik problemine dönüştürerek denge denetleyicilerinin tasarlanmasını kolaylaştırır.

``

Robot neden ters sarkaç olarak modellenir?

Klasik sarkaçta kütle aşağıdadır ve sistem doğal olarak kararlı durumuna dönmek ister. Ters sarkaçta ise kütle dönme noktasının üzerindedir. Küçük bir eğim bile kütlenin daha fazla uzaklaşmasına yol açar. İki bacaklı robot da ayakları üzerinde dururken benzer biçimde doğal olarak kararsızdır.

Basitleştirilmiş modelde robotun toplam kütlesi, kütle merkezinde bulunan noktasal bir $m$ kütlesi olarak kabul edilir. Bacak ise uzunluğu $l$ olan, kütlesiz bir çubuk gibi düşünülür. Robotun dikey eksene göre açısı $\theta$ ise temel dinamik yaklaşık olarak şöyledir:

Burada $g$ yer çekimi ivmesini, $\tau$ ise ayak bileği veya eş değer eklem torkunu gösterir. Denge çevresindeki küçük açılarda $\sin(\theta)\approx\theta$ kabulü yapılabilir:

$\theta$ katsayısının pozitif olması kritik ayrıntıdır: kontrol uygulanmazsa eğim kendiliğinden büyür.

Basitleştirme seçenekleri

Özellikle Doğrusal Ters Sarkaç Modeli (LIPM), kütle merkezinin yatay hareketini incelemek için kullanılır. Sabit $z_c$ yüksekliğinde yatay dinamik:

şeklindedir. Buradaki $x$ kütle merkezinin yatay konumu, $p$ ise basınç merkezi veya ideal koşullarda Zero Moment Point (ZMP) konumudur. Dengeyi korumak için $p$ değerinin ayağın oluşturduğu destek çokgeni içinde kalması gerekir.

Denetleyici nasıl müdahale eder?

Robot; IMU, eklem enkoderleri ve ayak tabanı kuvvet sensörlerinden veri toplar. Bu ölçümlerle açı, açısal hız ve kütle merkezi durumu tahmin edilir. Ardından PID, durum geri besleme veya LQR gibi bir denetleyici düzeltici tork üretir.

Durum vektörü $X=[\theta,\dot{\theta}]^T$ seçildiğinde LQR yaklaşımı

kontrol yasasını kullanır. $K$ kazancı, açı hatası ile enerji tüketimi arasında sistematik bir denge kurar. Aşağıdaki Python örneği, basitleştirilmiş bir geri besleme döngüsünü simüle eder:

import numpy as np

m, l, g = 20.0, 0.8, 9.81
dt = 0.002
K = np.array([450.0, 90.0])
state = np.array([0.12, 0.0])  # açı ve açısal hız

for _ in range(3000):
    theta, omega = state
    torque = -K @ state
    acceleration = (g / l) * theta + torque / (m * l**2)

    omega += acceleration * dt
    theta += omega * dt
    state = np.array([theta, omega])

print(f"Son açı: {np.degrees(state[0]):.4f} derece")

Kod, robot öne eğildiğinde ters yönde tork uygulayarak açıyı sıfıra yaklaştırır. Gerçek robotta tork sınırları, sensör gürültüsü, gecikme ve ayağın kayması da modele eklenmelidir.

Ayakta durmaktan yürümeye

Yürüme sırasında destek noktası sürekli değişir. Denetleyici yalnızca mevcut düşüşü engellemez; bir sonraki ayağın nereye basacağını da planlar. Küçük bozucular ayak bileği torkuyla, daha büyük bozucular kalça hareketiyle, çok güçlü itmeler ise yeni bir adımla karşılanır. Böylece ters sarkaç modeli, kusursuz bir robot kopyası olmaktan ziyade, karmaşık denge problemini gerçek zamanlı çözülebilen kullanışlı bir haritaya dönüştürür.

MRO tam olarak nedir?

MRO, bir özellik veya metot aranırken sınıfların hangi sırayla ziyaret edileceğini belirtir. Python 3 bu sırayı oluşturmak için C3 doğrusallaştırma algoritmasını kullanır. Amaç; çocuk sınıfları ebeveynlerden önce tutmak, sınıf bildirimindeki soldan sağa önceliği korumak ve kalıtım ağında tutarlı bir sıra üretmektir.

Bir C sınıfı, B1, B2, ..., Bn sınıflarından türetiliyorsa sıralama kabaca şöyle ifade edilir:

Buradaki merge, başka listelerin kuyruklarında bulunmayan uygun bir baş elemanı seçer. Bu kural, bir sınıfın kendi alt sınıfından önce aranmasını engeller.

Beklenmedik davranış örneği

Aşağıdaki örnekte iki ara sınıf aynı metodu değiştirir:

class Temel:
    def mesaj(self):
        return "Temel"

class A(Temel):
    def mesaj(self):
        return "A -> " + super().mesaj()

class B(Temel):
    def mesaj(self):
        return "B -> " + super().mesaj()

class C(A, B):
    pass

nesne = C()
print(nesne.mesaj())
print(C.mro())

Çıktı şu yapıdadır:

A -> B -> Temel
[C, A, B, Temel, object]

Şaşırtıcı nokta, A içindeki super() çağrısının doğrudan Temel sınıfına gitmemesidir. super(), “ebeveynimi çağır” anlamına gelmez; mevcut MRO’da benden sonraki sınıfa geç demektir. Dolayısıyla C(A, B) için A sonrasında B çalışır.

Ebeveynlerin sırasını değiştirirsek sonuç da değişir:

class D(B, A):
    pass

print(D().mesaj())
# B -> A -> Temel

Yalnızca sınıf bildirimindeki sıra değişmesine rağmen davranış tersine dönmüştür. Özellikle mixin kullanılan büyük projelerde bu durum sessiz ve zor bulunan hatalar doğurabilir.

super() zinciri nasıl güvenli kurulur?

İşbirlikçi çoklu kalıtımda zincire katılan bütün sınıflar uyumlu davranmalıdır. Her sınıf super() çağırmalı, metot imzaları birbiriyle çelişmemeli ve zincir doğrudan sınıf adıyla kesilmemelidir.

class KayitMixin:
    def kaydet(self, **kwargs):
        print("Kayıt günlüğü oluşturuldu")
        return super().kaydet(**kwargs)

class DogrulamaMixin:
    def kaydet(self, **kwargs):
        if not kwargs.get("ad"):
            raise ValueError("ad gerekli")
        return super().kaydet(**kwargs)

class Depo:
    def kaydet(self, **kwargs):
        return f"Kaydedildi: {kwargs['ad']}"

class Servis(KayitMixin, DogrulamaMixin, Depo):
    pass

Bu tasarımda her katman yalnızca kendi görevini yapar ve kontrolü sıradaki sınıfa bırakır. Servis.mro() çağrısı, gerçek yürütme yolunu incelemenin en pratik yöntemidir.

Akılda tutulması gerekenler

MRO’yu bir soy ağacından çok, Python’ın önceden hazırladığı bir ziyaret listesi gibi düşünün. super() bu listede tek adım ilerler. Beklenmedik bir sonuçla karşılaştığınızda Sinif.__mro__ veya Sinif.mro() çıktısını kontrol edin; ebeveyn sırasını bilinçli belirleyin ve doğrudan A.metot(self) çağrılarından kaçının. Çoklu kalıtım güçlüdür, fakat MRO okunmadan kullanıldığında kod tabanına küçük bir labirent yerleştirebilir.

Dekoratör aslında ne yapar?

Bir dekoratör, bir fonksiyonu parametre olarak alır ve yerine genellikle başka bir fonksiyon döndürür. Matematiksel olarak dekoratör dönüşümünü şöyle düşünebiliriz:

Burada $f$ orijinal fonksiyon, $D$ dekoratör ve $g$ çağrıların yönlendirildiği yeni fonksiyondur. Python’daki @dekorator sözdizimi ise temelde şu eşitliğin kısa yazımıdır:

Basit bir zamanlama dekoratörü yazalım:

import time

def zaman_olc(func):
    def wrapper(*args, **kwargs):
        baslangic = time.perf_counter()
        sonuc = func(*args, **kwargs)
        sure = time.perf_counter() - baslangic
        print(f"Çalışma süresi: {sure:.6f} saniye")
        return sonuc

    return wrapper

@zaman_olc
def topla(a, b):
    """İki sayıyı toplar."""
    return a + b

wrapper, farklı imzalara sahip fonksiyonlarla çalışabilmek için *args ve **kwargs kullanır. Önce zamanı kaydeder, orijinal fonksiyonu çalıştırır ve geçen süreyi ekrana yazar.

Metadata neden kaybolur?

Dekoratör uygulandıktan sonra topla değişkeni artık orijinal fonksiyonu değil, döndürülen wrapper fonksiyonunu gösterir. Bu nedenle aşağıdaki sonuçlar şaşırtıcı olabilir:

print(topla.__name__)  # wrapper
print(topla.__doc__)   # None

Python açısından ortada gizem yoktur: Yeni nesnenin metadata’sı okunmaktadır. Sorun özellikle dokümantasyon araçlarında, hata ayıklamada, testlerde ve fonksiyon adını kullanan framework’lerde belirginleşir.

functools.wraps kurtarmaya geliyor

Çözüm, iç fonksiyonun üzerine @wraps(func) eklemektir:

import time
from functools import wraps

def zaman_olc(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        baslangic = time.perf_counter()
        sonuc = func(*args, **kwargs)
        sure = time.perf_counter() - baslangic
        print(f"Çalışma süresi: {sure:.6f} saniye")
        return sonuc

    return wrapper

@zaman_olc
def topla(a, b):
    """İki sayıyı toplar."""
    return a + b

print(topla.__name__)  # topla
print(topla.__doc__)   # İki sayıyı toplar.

wraps, kendi başına sihirli bir kopyalama motoru değildir; functools.update_wrapper fonksiyonunun dekoratör biçiminde kullanılmasını sağlar. Varsayılan olarak __module__, __name__, __qualname__, __doc__, __annotations__ ve __type_params__ gibi nitelikleri wrapper’a aktarır. Ayrıca wrapper’ın sözlüğünü günceller.

Bonus: __wrapped__ ve introspection

wraps, wrapper’a __wrapped__ niteliğini de ekler. Böylece orijinal fonksiyona doğrudan ulaşılabilir:

print(topla.__wrapped__(3, 4))  # 7; zaman ölçümü yapılmaz

inspect.signature gibi introspection araçları da bu zinciri takip ederek anlamlı sonuçlar üretir:

from inspect import signature

print(signature(topla))  # (a, b)

Bu özellik yalnızca kozmetik değildir. IDE desteği, otomatik API dokümantasyonu, bağımlılık enjeksiyonu ve test araçları doğru metadata’ya güvenir. Özetle dekoratör yazarken @wraps(func) kullanmak, emniyet kemeri takmak gibidir: Kod onsuz da ilerleyebilir, fakat ilk sert virajda neden gerekli olduğunu anlarsınız.

Bir robot kolunun elektrik kesildikten sonra eklemlerinin nerede olduğunu hâlâ bilmesi sihir değildir; doğru enkoder seçimidir. Motor milinin veya mekanik bir eksenin açısal konumunu ölçen enkoderler, hareket kontrol sistemlerinin gözü gibidir. Ancak mutlak (absolute) ve artımlı (incremental) enkoderler konumu aynı biçimde anlatmaz: biri doğrudan adres verirken diğeri atılan adımları sayar. ``

Enkoder neyi ölçer?

Döner enkoder, mil hareketini elektriksel sinyallere dönüştürür. Ölçülen temel büyüklük açısal konumdur. Bir tam tur $360^\circ$ veya $2\pi$ radyan olduğuna göre, tur başına $N$ farklı konum üreten bir enkoderin teorik çözünürlüğü şöyledir:

Örneğin 1024 konumlu bir enkoder için çözünürlük yaklaşık $0{,}3516^\circ$ olur. Fakat “kaç farklı konum ölçülüyor?” sorusu kadar, “bu konum bilgisi nasıl saklanıyor?” sorusu da önemlidir.

Artımlı enkoder: Hareketin muhasebecisi

Artımlı enkoder, mil döndükçe A ve B kanallarında darbeler üretir. Denetleyici bu darbeleri sayarak başlangıç noktasına göre bağıl konumu hesaplar:

Burada $C$ sayılan darbe miktarı, $P$ ise kullanılan sayım yöntemine göre bir turdaki toplam sayımdır. A ve B sinyalleri arasında faz farkı bulunduğundan dönüş yönü de anlaşılır. Bazı modellerdeki Z kanalı ise her turda bir kez referans darbesi verir.

Önemli nokta şudur: Artımlı enkoder kendi başına “mil 127 derecede” demez. Yalnızca “başlangıçtan beri şu kadar ilerledim” der. Güç kesildiğinde denetleyicideki sayaç kaybolursa konum bilgisi de kaybolabilir. Bu nedenle açılışta limit anahtarına ilerleme veya Z darbesini arama gibi bir homing işlemi gerekir.

Mutlak enkoder: Her konumun kimliği vardır

Mutlak enkoderde her mekanik konuma özgü bir dijital kod atanır. Mil dururken veya sistem yeniden açıldığında kod okunarak konum doğrudan belirlenebilir. Bu yaklaşım, apartman merdivenlerini saymak yerine kapının üzerindeki numaraya bakmaya benzer.

Tek turlu modeller bir tur içindeki açıyı bildirir. Çok turlu modeller ise hem tur içi açıyı hem de tamamlanan tur sayısını korur. Haberleşme SSI, BiSS-C, CANopen veya EtherCAT gibi arayüzlerle gerçekleştirilebilir. Kodlama sırasında geçiş hatalarını azaltmak için sıklıkla Gray kodu kullanılır; komşu iki konum arasında yalnızca bir bit değişir.

Küçük bir artımlı sayıcı örneği

Aşağıdaki Python kodu, dört kat kenar sayımıyla elde edilen sayacı açıya dönüştürür. Gerçek sistemlerde sayaç, mikrodenetleyicinin kesme veya donanımsal encoder birimiyle güncellenir.

PPR = 1024
quadrature_factor = 4
counts_per_rev = PPR * quadrature_factor

def position_deg(counter):
    normalized = counter % counts_per_rev
    return normalized * 360.0 / counts_per_rev

print(position_deg(1536))  # 135 derece

Kod yalnızca sayacı yorumlar; başlangıç referansını kendiliğinden keşfetmez. Sayaç yanlış başlatılırsa hesaplanan açı da aynı miktarda kayar. Mutlak enkoderde ise okunan sayısal değer, uygun ölçekleme ile doğrudan açıya çevrilir.

Hangisi seçilmeli?

Elektrik kesintisinden sonra eksenin hareket ettirilmeden bilinmesi gerekiyorsa mutlak enkoder güçlü adaydır. Maliyet kritikse, açılışta referanslama yapılabiliyorsa veya temel hedef hız ölçmekse artımlı enkoder yeterli olabilir. Robotik uygulamalarda karar yalnız çözünürlüğe göre verilmemelidir; güvenlik, kablolama, haberleşme gecikmesi, maksimum hız ve homing süresi de değerlendirilmelidir. Kısacası artımlı enkoder yolculuğu sayar, mutlak enkoder ise bulunduğu adresi bilir.

``

Kararlılık neden bu kadar önemli?

Bir dinamik sistemi genel olarak

şeklinde ifade edebiliriz. Burada $x$ sistemin durumu, $u$ ise kontrol girişidir. Kontrolcünün görevi, örneğin robotun eklem açılarını hedeflenen denge noktasına taşımaktır.

Klasik yaklaşımda $u=K(x)$ seçilir ve kapalı çevrim sisteminin davranışı matematiksel olarak incelenir. Lyapunov teorisi bunun en güçlü araçlarından biridir. Pozitif tanımlı bir $V(x)$ fonksiyonu için

koşulları sağlanıyorsa sistemin denge noktasına doğru ilerlediği gösterilebilir. Başka bir ifadeyle enerji benzeri bir değer sürekli azalır. Robot, matematiksel bir yokuştan aşağı yuvarlanarak hedefe yaklaşır.

Sinir ağı kontrolcüsünde ise giriş genellikle

biçimindedir. Çok katmanlı ve doğrusal olmayan $\pi_\theta$ fonksiyonu, milyonlarca parametre içerebilir. Bu nedenle tüm durum uzayında $\dot{V}(x)<0$ olduğunu kanıtlamak oldukça zordur.

Klasik ve öğrenen kontrolcü karşılaştırması

Buradaki temel sorun sinir ağlarının mutlaka kararsız olması değildir. Sorun, eğitim başarısının kanıt anlamına gelmemesidir. Bir kontrolcünün milyonlarca simülasyonda hata yapmaması, henüz denenmemiş bir durumda güvenli kalacağını garanti etmez. Özellikle dağılım kayması, sensör arızası, model belirsizliği ve dış bozucular robotu eğitim verisinin dışına taşıyabilir.

Simülasyon testi neden yeterli değildir?

Aşağıdaki basit Python kodu, öğrenilmiş bir kontrolcüyü farklı başlangıç durumlarında deneyerek son durum normunu ölçer:

import numpy as np

def controller(x):
    # Gerçekte burada eğitilmiş sinir ağı çalıştırılır.
    return -1.8 * x + 0.15 * np.tanh(4 * x)

def simulate(x, dt=0.01, steps=1000):
    for _ in range(steps):
        u = controller(x)
        x = x + dt * (-0.4 * x + u)
    return x

for x0 in np.linspace(-5, 5, 21):
    final_state = simulate(x0)
    print(x0, abs(final_state))

Bu deney faydalıdır; çünkü başarısız başlangıç bölgelerini ortaya çıkarabilir. Ancak yalnızca 21 nokta test edilir. Sürekli durum uzayında sonsuz sayıda olasılık bulunduğundan, başarılı sonuçlar biçimsel bir ispat oluşturmaz. Test güven verir, kanıt ise sınırları tanımlar.

Garantiyi güçlendiren yaklaşımlar

Araştırmacılar bu açığı kapatmak için birkaç yöntemi birlikte kullanıyor:

• Lyapunov tabanlı öğrenme: Ağ, yalnızca görev ödülünü değil, $\dot{V}(x)<0$ koşulunu da dikkate alarak eğitilir.
• Control Barrier Function: Kontrol girişleri güvenli durum kümesinde kalacak şekilde filtrelenir.
• Hibrit mimari: Sinir ağı yüksek performanslı komut üretirken klasik kontrolcü güvenlik katmanı olarak çalışır.
• Doğrulama araçları: Aralık analizi, erişilebilirlik analizi ve karma tamsayılı programlama ile ağın belirli bölgelerdeki çıktıları sınırlandırılır.
• Gürbüzlük analizi: Bozucular altında durumun sınırlı kaldığını göstermek için input-to-state stability gibi kavramlardan yararlanılır.

Pratikte en güvenli yaklaşım, sinir ağını tek başına direksiyona oturtmak yerine ona matematik bilen bir yardımcı pilot vermektir. Öğrenen kontrolcü çeviklik ve uyarlanabilirlik sağlarken klasik katman fiziksel sınırları, tork kısıtlarını ve güvenli çalışma bölgesini korur.

Sonuç olarak robotikte başarı ölçütü yalnızca görevi tamamlamak değildir. Kontrolcünün hangi koşullarda güvenli olduğunu bilmek de gerekir. Sinir ağları güçlü sürücülerdir; fakat kararlılık kanıtı olmadan emniyet kemerleri henüz tam bağlanmış sayılmaz.

Bir robot fabrikadan kusursuz kalibre edilmiş biçimde çıksa bile bu durum sonsuza kadar sürmez. Kamera, LiDAR, IMU, enkoder ve GPS gibi sensörlerin ölçümleri; sıcaklık, titreşim, mekanik aşınma ve elektronik yaşlanma nedeniyle zamanla birbirinden uzaklaşır. Robot hâlâ veri topluyor gibi görünür, ancak artık dünyayı hafifçe “yamuk” algılıyordur. İşte bu yavaş bozulmaya kalibrasyon kayması, yani drift denir.

``

Çoklu sensör kalibrasyonu nedir?

Çoklu sensörlü bir sistemde yalnızca her sensörün kendi doğruluğu değil, sensörlerin birbirleriyle olan geometrik ve zamansal ilişkileri de önemlidir. Örneğin kamera ile LiDAR arasındaki dönüşüm genellikle şu katı cisim dönüşümüyle gösterilir:

Burada $\mathbf{R}$ dönme matrisini, $\mathbf{t}$ ise öteleme vektörünü temsil eder. Sensör yuvasının bir vida kadar oynaması bile bu dış parametreleri değiştirir. Benzer şekilde kameranın odak uzaklığı veya mercek bozulması gibi iç parametreler de sıcaklık ve darbe etkisiyle sapabilir.

Zamansal kalibrasyon da en az geometrik kalibrasyon kadar kritiktir. Kamera görüntüsü ile IMU ölçümü arasında $\Delta t$ gecikmesi varsa hızlı hareket sırasında aynı fiziksel an karşılaştırılmaz. Açısal hız $\omega$ olduğunda yaklaşık yönelim hatası şöyle büyür:

Robot hızlandıkça küçücük bir saat farkının büyük konum hatasına dönüşmesinin nedeni budur.

Drift neden oluşur?

Drift her zaman doğrusal ilerlemez. Robot soğukken farklı, çalışma sıcaklığına ulaştığında farklı davranabilir. Bu nedenle yalnızca “ayda bir kalibre et” yaklaşımı her sistem için yeterli değildir.

Yeniden kalibrasyon zamanı nasıl anlaşılır?

Kalibrasyon sağlığı, sensörlerin ortak gözlemleri arasındaki residual, yani artık hata üzerinden izlenebilir. Ölçülen değer $z_i$, modelin tahmini $h_i(\mathbf{x})$ ise toplam hata:

şeklinde tanımlanabilir. $J$ değerinin sürekli yükselmesi, sensör ilişkisinin bozulduğuna işaret eder. Ancak hareketli nesneler, yağmur veya kirli mercek de residual değerini artırabileceğinden tek ölçümle karar verilmemelidir.

Aşağıdaki Python örneği, hata serisinin hareketli ortalamasını izleyerek basit bir yeniden kalibrasyon uyarısı üretir:

from collections import deque

class CalibrationMonitor:
    def __init__(self, window=30, threshold=1.5):
        self.errors = deque(maxlen=window)
        self.threshold = threshold

    def update(self, residual):
        self.errors.append(residual)
        if len(self.errors) < self.errors.maxlen:
            return False

        mean_error = sum(self.errors) / len(self.errors)
        return mean_error > self.threshold

monitor = CalibrationMonitor(window=30, threshold=1.5)

for error in [0.8] * 20 + [1.9] * 30:
    if monitor.update(error):
        print("Yeniden kalibrasyon öneriliyor!")
        break

Bu kod ani bir sıçrama yerine son 30 ölçümün ortalamasını kullanır. Gerçek sistemlerde sıcaklık, robot hızı ve titreşim seviyesi de karara eklenerek yanlış alarmlar azaltılabilir.

Takvim mi, koşul bazlı bakım mı?

Güvenlik kritik robotlarda en sağlam çözüm genellikle hibrittir: residual değerleri sürekli izlenir, eşik aşılırsa erken bakım yapılır ve buna rağmen belirli aralıklarla doğrulama kalibrasyonu uygulanır. Ayrıca kalibrasyon parametreleri sıcaklıkla birlikte kaydedilmeli, sensör montajları işaretlenmeli ve her bakım sonrası referans veri setiyle test edilmelidir.

Sonuç olarak kalibrasyon tek seferlik bir kurulum adımı değil, robotun yaşam döngüsü boyunca yönetilmesi gereken bir sağlık göstergesidir. Robotun dünyayı doğru görmesini istiyorsak yalnızca sensörlerin çalışıp çalışmadığını değil, hâlâ aynı dünyaya bakıp bakmadıklarını da sorgulamalıyız.

``

Ortam değişkeni nedir?

Shell, başlattığı süreçlere anahtar-değer çiftlerinden oluşan bir ortam aktarır. Örneğin aşağıdaki komut, APP_MODE değişkenini mevcut shell ve onun alt süreçleri için erişilebilir yapar:

export APP_MODE=development
node app.js

Normal koşullarda çocuk süreç, ebeveyn sürecin dışa aktarılmış değişkenlerinin bir kopyasını alır. Bunu basitleştirerek şu şekilde ifade edebiliriz:

Burada $E$, sürece aktarılan ortam değişkenleri kümesidir. Ancak araya sudo girdiğinde yeni süreç yalnızca shell tarafından değil, ayrıca sudo güvenlik politikası tarafından hazırlanır:

Yani yalnızca izin verilen değişkenler korunur; geri kalanı temizlenir veya güvenli varsayılanlarla değiştirilir.

Neden temizleniyor?

Bir ortam değişkeni masum görünse de çalıştırılacak kodu etkileyebilir. PATH, LD_PRELOAD, PYTHONPATH ve benzeri değişkenler yanlış programın ya da kütüphanenin root yetkisiyle yüklenmesine yol açabilir. Kullanıcının bütün ortamını doğrudan yönetici sürecine taşımak, yetki yükseltme açığı oluşturabilir.

Birçok sistemde /etc/sudoers içindeki env_reset seçeneği bu filtrelemeyi etkinleştirir. Ayrıca secure_path, sudo ile çalıştırılan komutlarda kullanılacak güvenilir bir PATH tanımlar.

Önce problemi doğrulayın

Aynı değişkeni normal kullanıcı ve sudo ortamında karşılaştırabilirsiniz:

export APP_MODE=development
printenv APP_MODE
sudo printenv APP_MODE

İlk komut development yazarken ikinci komut boş sonuç verebilir. Ortamların tamamını karşılaştırmak için çıktıları sıralayıp diff kullanmak daha açıklayıcıdır:

env | sort > /tmp/user-env.txt
sudo env | sort > /tmp/sudo-env.txt
diff -u /tmp/user-env.txt /tmp/sudo-env.txt

Bu kod, iki ortam arasındaki eklenen, kaldırılan veya değiştirilen değerleri gösterir.

Güvenli çözüm seçenekleri

Yalnızca gerekli değişkeni komut satırında geçirmek genellikle en açık çözümdür:

sudo APP_MODE=production /opt/myapp/start.sh

Değişken mevcut shell değerinden alınacaksa şu biçim kullanılabilir:

sudo APP_MODE="$APP_MODE" /opt/myapp/start.sh

Tüm ortamı korumayı denemek için sudo -E kullanılabilir:

sudo -E ./deploy.sh

Ancak -E, sistemdeki sudoers politikası izin vermiyorsa etkisiz olabilir. Ayrıca hassas veya davranış değiştirici değişkenleri root sürecine taşımak risklidir.

Kalıcı ve kontrollü izin için sudo visudo ile yapılandırma düzenlenebilir:

Defaults env_keep += "APP_MODE API_ENDPOINT"

visudo, sözdizimini doğrulayarak hatalı bir dosya yüzünden sudo erişiminin bozulmasını önler. API anahtarlarını bu listeye gelişigüzel eklemek yerine secret manager, korumalı yapılandırma dosyası veya systemd kimlik bilgileri kullanmak daha doğrudur.

Sonuç olarak sudo, değişkenlerinizi unutmaz; onları güvenlik kontrolünden geçirir. En iyi yaklaşım, bütün ortamı taşımak yerine ihtiyaç duyulan değişkenleri açıkça ve mümkün olan en dar kapsamda aktarmaktır.