``

Değer Değil, Adres Saklamak

Normal bir değişken doğrudan veri taşır. Gösterici ise bu verinin bulunduğu konumu taşır. Örneğin int sayi = 42; ifadesi bellekte bir tamsayı oluşturur. &sayi, bu değişkenin adresini verir; *ptr ise göstericinin tuttuğu adrese giderek oradaki değere erişir.

#include <stdio.h>

int main(void) {
    int sayi = 42;
    int *ptr = &sayi;

    printf("Deger: %d\n", sayi);
    printf("Adres: %p\n", (void *)ptr);
    printf("Pointer uzerinden deger: %d\n", *ptr);

    *ptr = 99; /* Adresteki gerçek değeri değiştirir. */
    printf("Yeni deger: %d\n", sayi);
    return 0;
}

Burada int *ptr, ptr değişkeninin bir int adresi taşıyacağını belirtir. *ptr = 99 işlemi kopyayı değil, doğrudan sayi değişkenini değiştirir. Göstericilerin fonksiyonlara “dışarıdaki” veriyi değiştirme gücü vermesi de bu mantığa dayanır.

Bellek ve Tür Bilgisi

Bir adresi yalnızca sayı gibi düşünmek eksik kalır. Göstericinin türü, derleyiciye o adreste kaç baytlık ve nasıl yorumlanacak bir veri bulunduğunu söyler. Tipik bir sistemde char 1 bayt, int 4 bayt olabilir; ancak kesin boyutlar platforma bağlıdır ve sizeof ile öğrenilmelidir.

Bir dizinin başlangıç adresi $A$, eleman boyutu $s$ ve erişilecek indis $i$ olsun. İlgili elemanın adresi şu şekilde hesaplanır:

Bu nedenle işaretçi aritmetiği sıradan tam sayı aritmetiğinden farklıdır. ptr + 1, adresi bir bayt değil, gösterilen türün boyutu kadar ilerletir.

#include <stdio.h>

int main(void) {
    int sayilar[] = {10, 20, 30, 40};
    int *ptr = sayilar;

    for (size_t i = 0; i < 4; i++) {
        printf("%zu: %d\n", i, *(ptr + i));
    }
    return 0;
}

*(ptr + i) ile ptr[i] eşdeğerdir. Hatta sayilar[i] ifadesi de temelde başlangıç adresinden uygun miktarda ilerleyip değeri çözme işlemidir.

NULL ve Tehlikeli Göstericiler

Başlatılmamış bir gösterici rastgele bir adres taşıyabilir. NULL, göstericinin geçerli bir nesneyi göstermediğini açıkça belirtir. Ancak NULL göstericiyi çözmek, yani *ptr kullanmak tanımsız davranıştır.

int *ptr = NULL;

if (ptr != NULL) {
    /* Yalnızca geçerli adres varsa erişilir. */
    *ptr = 5;
}

Benzer şekilde yaşam süresi bitmiş yerel değişkenlerin adresleri ve free ile serbest bırakılmış bölgeleri gösteren işaretçiler “sarkan gösterici” oluşturur. Dizi sınırını aşmak da komşunun posta kutusunu kendi kutunuz sanmaya benzer: Adres vardır, fakat erişim hakkınız yoktur.

Sonuç

Göstericiler C’nin performans ve kontrol gücünün merkezindedir. & adres alır, * adresteki veriyi çözer, tür bilgisi ise aritmetik adımların boyutunu belirler. Güvenli kullanım için göstericileri başlatmak, NULL kontrolü yapmak, nesnelerin yaşam süresini izlemek ve dizi sınırlarını korumak gerekir. Bu kurallar oturduğunda belleğin karanlık sokakları, tabelaları gayet okunaklı bir mahalleye dönüşür.

``

C# nereden geldi?

C#, Microsoft tarafından .NET platformunun temel dillerinden biri olarak geliştirildi. Dilin baş mimarı Anders Hejlsberg’dir; ilk sürüm 2000 yılında duyurulmuş, .NET Framework ile birlikte 2002 yılında yaygın kullanıma açılmıştır. C++, Java ve Delphi gibi dillerden fikirler taşısa da zamanla kendine özgü, modern bir kimlik kazanmıştır.

C# başlangıçta Windows uygulamalarıyla özdeşleşse de günümüzde açık kaynaklı ve platformlar arası .NET üzerinde çalışır. Web uygulamalarından oyunlara, masaüstü yazılımlarından bulut servislerine kadar geniş bir kullanım alanına sahiptir.

Bu ayrım önemlidir: C# bir dildir, .NET bir platformdur, CLR ise bu platformun çalışma zamanı motorudur.

Derleme süreci nasıl işler?

C# kaynak kodu doğrudan işlemcinin anlayacağı makine koduna çevrilmez. Önce Roslyn derleyicisi tarafından Common Intermediate Language olarak bilinen CIL’e dönüştürülür. CIL, işlemciden büyük ölçüde bağımsız bir ara dildir. Derleme sonucunda .dll veya .exe uzantılı bir assembly oluşur.

Bir assembly yalnızca CIL komutlarını içermez. Türler, metotlar, sürüm bilgileri ve bağımlılıklar gibi metadata bilgilerini de taşır. Çalıştırma sırasında CLR içindeki Just-In-Time derleyicisi, ihtiyaç duyulan metotların CIL kodunu hedef işlemcinin makine koduna çevirir.

Süreci şöyle özetleyebiliriz:

C# kaynak kodu
      ↓ Roslyn
CIL + metadata içeren assembly
      ↓ CLR ve JIT
Makine kodu
      ↓
İşlemci

Toplam çalışma maliyeti basitleştirilmiş biçimde şu şekilde düşünülebilir:

JIT maliyeti ilk çağrıda hissedilebilir; ancak üretilen yerel kod sonraki çağrılarda yeniden kullanılabilir. .NET ayrıca uygulamayı önceden yerel koda yaklaştıran ReadyToRun ve Native AOT gibi seçenekler de sunar.

CLR hangi işleri üstlenir?

CLR, yalnızca kodu çalıştıran pasif bir katman değildir. Bellek yönetimi, hata işleme, güvenlik kontrolleri, iş parçacıkları ve tür güvenliği gibi sorumlulukları üstlenir. En bilinen bileşenlerinden biri Garbage Collector, yani çöp toplayıcıdır. Artık erişilemeyen nesnelerin belleğini otomatik olarak geri kazanır.

using System;

public sealed class Urun
{
    public string Ad { get; }
    public decimal Fiyat { get; }

    public Urun(string ad, decimal fiyat)
    {
        Ad = ad;
        Fiyat = fiyat;
    }

    public decimal KdvliFiyat(decimal oran) => Fiyat * (1 + oran);
}

var urun = new Urun("Klavye", 1200m);
Console.WriteLine(urun.KdvliFiyat(0.20m));

Bu örnekte Urun nesnesi yönetilen bellekte oluşturulur. CLR nesnenin yaşam döngüsünü izler; nesneye erişim kalmadığında ayrılan alan GC tarafından temizlenebilir. Geliştiricinin çoğu durumda belleği elle serbest bırakması gerekmez.

CTS ve CLS neden önemlidir?

Common Type System, .NET dillerinin ortak tür modelini tanımlar. Örneğin C# dilindeki int, CLR düzeyinde System.Int32 türüne karşılık gelir. Common Language Specification ise farklı .NET dillerinin birbiriyle uyumlu çalışabilmesi için takip etmesi gereken kuralları belirler.

Sonuç olarak C# kodu tek başına yolculuk etmez. Roslyn, CIL, assembly, JIT ve CLR katmanları birlikte çalışarak taşınabilir, güvenli ve yönetilebilir bir yürütme ortamı oluşturur. Bu mimariyi bilmek, yalnızca kod yazmayı değil, kodun gerçekte nasıl hayata geçtiğini de anlamaktır.

Const doğruluğu gerçekte ne söyler?

Bir nesneye const erişim, gözlemlenebilir durumunun değiştirilmeyeceği sözünü verir. Üye fonksiyonun sonundaki const ise bu sözün fonksiyon arayüzündeki karşılığıdır:

class User {
public:
    const std::string& name() const {
        return name_;
    }

private:
    std::string name_;
};

Burada ilk const, döndürülen referans üzerinden metnin değiştirilemeyeceğini; ikinci const ise name() çağrısının User nesnesini değiştirmediğini belirtir. İki kullanım farklı soruları yanıtlar: “Sonuç değiştirilebilir mi?” ve “İşlem nesneyi değiştiriyor mu?”

Bunu kabaca bir durum geçişiyle ifade edebiliriz. Salt okunur işlem için beklenen ilişki:

Burada $S$ nesnenin başlangıç durumu, $R$ sonuçtur. Değiştirici bir işlemdeyse yeni durum $S’$ oluşabilir:

const, ilk davranışı tür sistemi seviyesinde ilan eder ve derleyicinin bu sözleşmeyi denetlemesini sağlar.

Küçük ihmal, büyük arayüz problemi

Aşağıdaki fonksiyon nesneyi değiştirmese bile const olarak işaretlenmemiştir:

class Report {
public:
    std::string summary() { // Aslında değişiklik yapmıyor
        return title_ + ": " + body_;
    }

private:
    std::string title_;
    std::string body_;
};

Bu eksiklik yüzünden const Report& alan kodlar summary() metodunu çağıramaz. Sorunu geçici olarak aşmak isteyen geliştiriciler nesneleri gereksiz yere kopyalayabilir, parametrelerden const niteliğini kaldırabilir veya daha kötüsü const_cast kullanabilir. Böylece yerel bir ihmal, çağrı zinciri boyunca yayılır.

Sonradan eklemek neden pahalıdır?

Bir metoda sonradan const eklemek kaynak kod düzeyinde küçük görünür:

std::string summary() const;

Fakat gerçek projede bu değişiklik; çağrılan yardımcı metotların, kullanılan işaretçilerin ve önbelleklerin de incelenmesini gerektirir. Ayrıca üye fonksiyonun const niteliği türünün parçasıdır. Sanal fonksiyonlarda taban ve türetilmiş sınıfların imzaları eşleşmelidir:

struct Document {
    virtual std::string title() const = 0;
};

struct Invoice : Document {
    std::string title() const override {
        return "Fatura";
    }
};

Taban sınıfa sonradan const eklemek, bütün türetilmiş sınıfları değiştirebilir. Paylaşılan kütüphanelerde bu durum kaynak ve ikili uyumluluk planlarını da etkiler.

Mantıksal const ve önbellekleme

Bazen bir sorgu sonucu önbelleğe alınır. Kullanıcının gözünde nesne değişmezken içeride teknik bir güncelleme gerekir. Bunun için mutable bilinçli biçimde kullanılabilir:

class Calculator {
public:
    int result() const {
        if (!cached_) {
            cache_ = expensiveCalculation();
            cached_ = true;
        }
        return cache_;
    }

private:
    int expensiveCalculation() const { return 42; }
    mutable bool cached_ = false;
    mutable int cache_ = 0;
};

Bu yaklaşım fiziksel değil, mantıksal değişmezliği temsil eder. Yine de mutable, eşzamanlı erişimi otomatik olarak güvenli yapmaz; gerekirse kilit veya atomik tür kullanılmalıdır.

Sağlam arayüz için pratik ölçüt

Bir metot tasarlarken önce “Bu işlem nesnenin kullanıcı tarafından gözlemlenen anlamını değiştiriyor mu?” diye sorun. Yanıt hayırsa metodu const yapın. Parametrelerde mümkün olduğunda const T&, sahiplik aktarılmıyorsa salt okunur işaretçi veya görünüm türleri kullanın. const doğruluğunu baştan kurmak birkaç saniye; yıllar sonra bütün API ağında düzeltmek ise pahalı bir mimari operasyondur. Kısacası const, kısıtlama değil, gelecekteki kullanım biçimlerine açılan güvenli bir kapıdır.

C++’ta const T& gördüğümüzde genellikle “güvenli, değiştirilemez referans” diye düşünürüz. Ancak geçici nesneler devreye girdiğinde konu yalnızca değiştirilebilirlikten ibaret değildir. Referansın neye, nerede ve nasıl bağlandığı; geçici nesnenin hemen yok edilmesini de kapsam sonuna kadar yaşamasını da sağlayabilir. Kısacası const, bazen nesneye adeta fazladan can verir.

``

Geçici nesne nedir?

Bir ifadenin sonucunu taşımak için oluşturulan, genellikle adı olmayan nesneye geçici nesne denir. Örneğin std::string("merhaba") bir geçici nesne üretir. Normal koşullarda bu nesne, içinde oluşturulduğu tam ifadenin sonunda yok edilir. Çoğu zaman bu nokta noktalı virgüldür.

std::string("merhaba"); // Nesne bu satırın sonunda yok edilir.

Basitleştirilmiş biçimde geçici nesnenin olağan ömrünü şöyle düşünebiliriz:

Fakat uygun bir yerel referansa doğrudan bağlama yapılırsa ömür, referansın kapsamına kadar uzatılabilir:

const referans neden özel?

Lvalue referansları normalde geçici nesnelere bağlanamaz:

std::string& a = std::string("C++"); // Hata

Bunun nedeni, kısa ömürlü ve isimsiz bir değerin değiştirilebilir bir lvalue referansı üzerinden kullanılmasının riskli kabul edilmesidir. Buna karşılık const lvalue referansı bağlanabilir:

const std::string& a = std::string("C++");
std::cout << a; // Güvenli: geçicinin ömrü a'nın kapsamına uzatıldı.

Son satır kritik bir ayrıntıdır. Bir fonksiyon parametresine bağlanan geçici, fonksiyon çağrısı bittikten sonra saklanamaz.

const std::string* adres;

void sakla(const std::string& metin) {
    adres = &metin;
}

sakla(std::string("kaybolacak"));
// Bu noktadan sonra adres dangling pointer!

metin, fonksiyon içinde geçerlidir; fakat çağrının bulunduğu tam ifade sona erince geçici nesne yok edilir.

Referansı döndürmek ömrü uzatmaz

En tehlikeli sürprizlerden biri, fonksiyondan const referans döndürmektir:

const std::string& üret() {
    return std::string("geçici"); // Hatalı: yok edilecek nesneye referans
}

const burada koruyucu kalkan değildir. Fonksiyon sona erdiğinde geçici nesne yok edilir ve dönen referans boşa çıkar. Doğru yaklaşım değeri döndürmektir:

std::string üret() {
    return std::string("güvenli");
}

Modern C++, kopya eleme ve taşıma sayesinde bu kodu çoğunlukla ek maliyet oluşturmadan çalıştırır.

İkinci referans ikinci bir ömür vermez

Ömür uzatma aktarılabilir bir özellik değildir:

const std::string& ilk = std::string("örnek");
const std::string& ikinci = ilk;

Nesnenin ömrü ilk nedeniyle uzatılmıştır. ikinci, aynı nesneye başka bir takma ad verir; ömrü yeniden başlatmaz veya kendi kapsamına göre genişletmez. Eğer ikinci, ilkten daha uzun yaşarsa dangling referansa dönüşebilir.

const dönüş değeri her zaman yararlı değildir

Eski kodlarda const T döndüren fonksiyonlar görülebilir:

const std::string oluştur();

Bu kullanım, modern C++’ta taşıma işlemlerini engelleyebilir; çünkü taşıma kurucuları çoğunlukla T&& bekler, const T&& değil. Değer döndüren fonksiyonlarda genellikle yalnızca T tercih edilmelidir.

Özet kural şudur: Yerel const T& ve T&&, doğrudan bağlandıkları geçicinin ömrünü uzatabilir. Parametreler, döndürülen referanslar ve başka bir referans üzerinden yapılan bağlamalar için aynı güvenceyi varsaymayın. const, değişikliği sınırlar; her durumda ömür yönetmez.

C++’ta dinamik bellek yönetirken delete ile delete[] arasındaki iki köşeli parantez küçük görünebilir. Ancak yanlış silme ifadesini kullanmak; bellek sızıntısı, eksik yıkıcı çağrıları, heap bozulması ve yalnızca üretim ortamında ortaya çıkan gizemli çökmeler gibi ciddi sonuçlara yol açabilir. ``

Temel eşleştirme kuralı

C++’ta bellek ayırma ve serbest bırakma işlemleri doğru biçimde eşleştirilmelidir:

Başka bir ifadeyle şu eşitlik korunmalıdır:

new[] ile oluşturulan bir diziyi normal delete ile silmek tanımsız davranıştır. Tanımsız davranış, programın mutlaka anında çökeceği anlamına gelmez. Program düzgün çalışıyor gibi görünebilir, rastgele sonuç üretebilir veya başka bir noktada çökebilir. Tehlikeli olan da budur.

Neden iki farklı silme işlemi var?

Tek bir nesne oluşturulduğunda çalışma zamanı yalnızca o nesnenin yıkıcısını çağırır ve belleği serbest bırakır. Dizilerde ise her elemanın ayrı ayrı yok edilmesi gerekir.

Bir dizi $n$ elemandan oluşuyorsa beklenen yıkıcı çağrısı sayısı şöyledir:

Bazı C++ çalışma zamanı uygulamaları, ayrılan bloğun başında eleman sayısını saklayan ve halk arasında array cookie denilen ek bilgiler tutar. delete[], bu bilgiyi kullanarak kaç yıkıcı çağrılması gerektiğini belirleyebilir. Standart, bu mekanizmanın nasıl uygulanacağını zorunlu kılmaz; fakat programcıya doğru silme ifadesini kullanma sorumluluğunu verir.

class Sensor {
public:
    Sensor() = default;

    ~Sensor() {
        // Dosya, soket veya başka bir kaynak burada kapatılabilir.
    }
};

int main() {
    Sensor* sensors = new Sensor[4];

    // Dört elemanın da yıkıcısını çalıştırır.
    delete[] sensors;
}

Burada delete sensors; kullanılsaydı sonuç tanımsız olurdu. Yalnızca ilk elemanın yıkıcısının çağrılacağını varsaymak bile güvenli değildir; standart böyle bir garanti sunmaz.

İlkel türlerde sorun yok mu?

int veya double gibi türlerin yıkıcısı olmadığı için yanlış kullanımın zararsız olduğu düşünülebilir:

int* scores = new int[100];
delete scores; // Hatalı: delete[] kullanılmalıydı.

Bu kod yine tanımsız davranıştır. Bellek yöneticisi dizi tahsisini farklı biçimde izleyebilir. Hata hemen görünmese bile heap yapısı bozulabilir. Doğru kullanım şöyledir:

int* scores = new int[100];
delete[] scores;
scores = nullptr;

İşaretçiyi nullptr yapmak, aynı işaretçinin yanlışlıkla tekrar silinmesi riskini azaltabilir. Ayrıca delete nullptr ve delete[] nullptr güvenlidir; ikisi de işlem yapmaz.

Hataları nasıl yakalarız?

AddressSanitizer, Valgrind ve benzeri araçlar tahsis-silme uyumsuzluklarını bulabilir. GCC veya Clang ile örnek bir kontrol derlemesi şöyledir:

g++ -std=c++20 -Wall -Wextra -fsanitize=address main.cpp
./a.out

Derleyici uyarıları yardımcı olsa da işaretçi farklı fonksiyonlara taşındığında hatayı her zaman yakalayamaz.

Modern C++ çözümü

En güvenli yaklaşım, çıplak new[] kullanmaktan kaçınmaktır. Boyutu çalışma zamanında belirlenen diziler için std::vector, sabit boyutlular için std::array tercih edilmelidir:

#include <vector>

int main() {
    std::vector<int> scores(100);
    scores[0] = 42;
} // Bellek otomatik olarak temizlenir.

Dinamik bir diziye gerçekten ihtiyaç varsa std::unique_ptr<T[]> kullanılabilir. Böylece doğru delete[] otomatik olarak çağrılır. Kısacası, new gördüğünüzde delete, new[] gördüğünüzde delete[] düşünün; daha iyisi, bu işi RAII kapsayıcılarına bırakın.

``

Temel mekanik düzen

Bu robotlarda aynı eksen üzerinde bulunan iki bağımsız tahrik tekerleği vardır. Tekerlekler arasındaki mesafeye iz genişliği veya dingil uzunluğu denir ve genellikle $L$ ile gösterilir. Sol tekerleğin doğrusal hızı $v_l$, sağ tekerleğinki ise $v_r$ olsun.

Robotun merkezinin ileri yönlü doğrusal hızı iki tekerlek hızının ortalamasıdır:

Açısal hız ise tekerlekler arasındaki hız farkıyla belirlenir:

Bu ikinci denklem robotun dönüş mantığını özetler. Hız farkı büyüdükçe robot daha hızlı döner. Tekerlekler arası mesafe büyüdükçe aynı hız farkıyla elde edilen açısal hız azalır; çünkü geniş bir robotu çevirmek daha zordur.

Buradaki sağ ve sol yön işaretleri, kullanılan koordinat sistemine göre ters tanımlanabilir. Önemli olan yazılımın ve matematiksel modelin aynı işaret kuralını kullanmasıdır.

Görünmez dönüş merkezi: ICC

Robot viraj alırken iki tekerlek aynı merkez çevresinde fakat farklı yarıçaplarda yay çizer. Bu ortak noktaya Anlık Dönüş Merkezi ya da ICC denir. İç taraftaki tekerlek daha kısa, dış taraftaki tekerlek daha uzun yol aldığı için dış tekerlek daha hızlı dönmelidir.

Robot merkezinin dönüş yarıçapı $R$, açısal hız sıfır değilken şöyle bulunabilir:

Tekerlek hızları birbirine yaklaştığında paydadaki fark küçülür ve $R$ büyür; robot geniş bir yay çizer. Hızlar eşit olduğunda yarıçap teorik olarak sonsuza gider, yani hareket düz bir çizgiye dönüşür. Hızlar eşit büyüklükte ve zıt yönlü olduğundaysa $v=0$ olur; dönüş merkezi robotun tam ortasına gelir.

Basit bir hız hesabı

Aşağıdaki Python fonksiyonu, tekerlek hızlarından robotun doğrusal ve açısal hızını hesaplar:

def robot_hizi(sol_hiz, sag_hiz, tekerlek_araligi):
    dogrusal_hiz = (sag_hiz + sol_hiz) / 2
    acisal_hiz = (sag_hiz - sol_hiz) / tekerlek_araligi
    return dogrusal_hiz, acisal_hiz

v, omega = robot_hizi(0.20, 0.40, 0.30)
print(v, omega)

Bu örnekte robotun doğrusal hızı $0.30\ m/s$, açısal hızı yaklaşık $0.67\ rad/s$ olur. Sağ tekerlek daha hızlı olduğu için robot sola yönelir.

Motorlar genellikle doğrusal hız yerine açısal tekerlek hızıyla kontrol edilir. Tekerlek yarıçapı $r$ ve motor açısal hızı $ω_w$ ise doğrusal hız:

bağıntısıyla bulunur. Böylece enkoderden ölçülen dönüş hızı, robot kinematiğinde kullanılabilir.

Gerçek dünya neden formüllerden daha huysuzdur?

Teorik model tekerleklerin kaymadığını varsayar. Gerçekte zemin sürtünmesi, motor farklılıkları, pil gerilimi ve ağırlık dağılımı dönüşü etkiler. Aynı PWM değeri iki motorda aynı hızı üretmeyebilir. Bu nedenle enkoder geri bildirimi ve PID kontrolü kullanılarak her tekerleğin hedef hızı ayrı ayrı korunur.

Kısacası diferansiyel sürüş, mekanik olarak sade fakat matematiksel olarak güçlüdür: ortalama hız robotu ilerletir, hız farkı ise döndürür. İki motorun uyumlu anlaşmazlığı, robotun tüm yön kabiliyetini oluşturur.

``

Tek Bir Sensör Neden Yetmez?

Her sensör çevreyi farklı bir fiziksel ilkeye göre gözlemler. Kameralar görünür ışığı, radar elektromanyetik dalgaların yansımasını, LiDAR ise lazer darbelerinin dönüş süresini kullanır. Bu çeşitlilik aynı zamanda hata çeşitliliği demektir. Kamera sisi yoğun bir duvar gibi görebilirken radar sisin içinden çalışmayı sürdürebilir. Buna karşılık radar, nesnenin bisiklet mi yoksa trafik levhası mı olduğunu kamera kadar başarılı sınıflandıramaz.

Güven, Ağırlık ve Olasılık

Füzyonun temel fikri, bütün sensörlere eşit oy hakkı vermek değildir. Sistem, mevcut koşullara göre her ölçümün güvenilirliğini değerlendirir. Bir sensörün ölçümü $z_i$, güven ağırlığı $w_i$ ise basit bir birleşik tahmin şöyle yazılabilir:

Yoğun siste kameranın $w$ değeri azaltılırken radarın ağırlığı artırılabilir. Daha gelişmiş sistemlerde Kalman filtresi, genişletilmiş Kalman filtresi, parçacık filtresi veya Bayesçi çıkarım kullanılır. Bayes yaklaşımı, yeni bir ölçüm geldiğinde önceki inancı günceller:

Burada $P(x)$ önceki tahmini, $P(z\vert x)$ ölçümün bu tahmin altında görülme olasılığını, $P(x\vert z)$ ise güncellenmiş sonucu temsil eder. Böylece araç, “Radar önümde bir şey olduğunu söylüyor ama kamera emin değil” durumunu matematiksel olarak çözebilir.

Basit Bir Uyarlanabilir Füzyon Örneği

Aşağıdaki Python kodu, hava durumuna göre kamera ve radar ölçümlerinin ağırlıklarını değiştirir. Gerçek araçlarda belirsizlik kovaryans matrisleri ve zaman senkronizasyonu kullanılır; bu örnek temel mantığı görünür kılar.

def fuse_distance(camera, radar, weather):
    # Açık havada kamera daha güvenilirken siste radar öne çıkar.
    weights = {
        "clear": (0.6, 0.4),
        "rain":  (0.3, 0.7),
        "fog":   (0.15, 0.85)
    }

    camera_w, radar_w = weights.get(weather, (0.5, 0.5))
    return camera * camera_w + radar * radar_w

result = fuse_distance(camera=24.0, radar=21.5, weather="fog")
print(f"Tahmini mesafe: {result:.2f} metre")

Burada sisli havada radar ölçümü sonuca daha fazla yön verir. Fakat yalnızca hava etiketi kullanmak yeterli değildir. Kamera kontrastı, LiDAR dönüş yoğunluğu, radar sinyal-gürültü oranı ve sensör sıcaklığı gibi anlık kalite göstergeleri de ağırlıkları dinamik biçimde değiştirmelidir.

Füzyonun Gizli Kahramanları

Başarılı bir sistem için sensörlerin kalibrasyonu ve zaman eşlemesi kritiktir. Milisaniyelik gecikme, hızlı hareket eden bir aracın farklı konumlarda algılanmasına yol açabilir. Ayrıca sensörler ortak koordinat sistemine dönüştürülmelidir. Aksi hâlde radarın “ön sağ” dediği nesne, kamera görüntüsünde yanlış piksele bağlanır.

Sonuç olarak sensör füzyonu kötü havayı ortadan kaldırmaz; belirsizliği yönetilebilir hâle getirir. Güvenilir otonomi, en parlak sensöre sahip olmak değil, hangi sensöre ne zaman güvenileceğini bilmektir. Robotik aracın süper gücü kusursuz görmek değil, şüphe etmeyi matematikle öğrenmektir.

Standartlar neden gereklidir?

Robot güvenliğinde temel yaklaşım, “Çarpışma olursa dururuz” demek değildir. Öncelikle tehlike belirlenir, risk tahmin edilir ve tasarım yoluyla azaltılır. ISO 12100 bu genel risk değerlendirme mantığını sunarken ISO 10218 endüstriyel robot sistemlerine ilişkin güvenlik şartlarını tanımlar. İş birliğine dayalı uygulamalarda kullanılan ISO/TS 15066 ise insan vücudunun farklı bölgeleri için temas, basınç ve kuvvet değerlendirmelerine rehberlik eder.

Standartların izlediği hiyerarşi kabaca şöyledir:

1. Tehlikeyi mümkünse tasarımdan kaldırmak.
2. Hızı, kuvveti ve hareket alanını sınırlandırmak.
3. Sensörler ve güvenlik fonksiyonları kullanmak.
4. Kalan riskleri kullanıcıya bildirmek ve eğitim sağlamak.

Buradaki önemli ayrıntı şudur: Üzerinde “cobot” etiketi bulunan bir robot kendiliğinden güvenli değildir. Robot, uç efektör, taşınan parça, çalışma hızı ve çevredeki yüzeyler birlikte değerlendirilmelidir. Yumuşak robot kolu sivri bir metal parça taşıyorsa güvenlik hikâyesinin kötü karakteri o parça olabilir.

Dört temel iş birliği yaklaşımı

Hız ve mesafe izleme yaklaşımında robotun yalnızca mevcut konumu değil, durmak için ihtiyaç duyduğu alan da önemlidir. Basitleştirilmiş durma mesafesi şöyle düşünülebilir:

Burada $v$ robot hızı, $T$ algılama ve kontrol gecikmesi, $a$ frenleme ivmesi, $C$ ise sensör belirsizliği ve güvenlik payıdır. Hız iki katına çıktığında frenleme bölümünün dört kat büyümesi, hızlı robotların neden daha geniş güvenlik mesafesine ihtiyaç duyduğunu açıklar.

Çarpışmada taşınan enerji de önemlidir:

Etkili kütle $m$ aynı kalsa bile hızdaki küçük artışlar temas enerjisini belirgin biçimde yükseltir. Bu nedenle güvenlik sistemleri çoğu zaman insan yaklaştıkça hızı kademeli azaltır.

Basit bir hız sınırlandırma mantığı

Aşağıdaki örnek, ölçülen insan-robot mesafesine göre hız komutu üretir:

def guvenli_hiz(mesafe, azami_hiz=1.0):
    if mesafe < 0.4:
        return 0.0       # Tehlikeli yakınlık: dur
    if mesafe < 1.0:
        return azami_hiz * (mesafe - 0.4) / 0.6
    return azami_hiz

robot_hizi = guvenli_hiz(sensor_mesafesi)

Bu kod öğretici bir modeldir; gerçek bir güvenlik fonksiyonu değildir. Endüstriyel uygulamalarda sıradan kamera, işletim sistemi veya Python betiği tek başına yeterli kabul edilmez. Güvenlik dereceli sensörler, yedekli kontrol kanalları, hata teşhisi ve ISO 13849 gibi standartlara göre doğrulanmış performans seviyeleri gerekir.

Temasın türü de sonucu değiştirir

Standartlar geçici temas ile sıkışmalı teması ayırır. Robotun çarpıp geri çekildiği geçici temas kısa sürebilir; insanın robot ile duvar arasında sıkıştığı yarı statik temas ise daha tehlikelidir. Ayrıca baş, boyun ve göğüs gibi bölgelerin toleransı kol veya elden farklıdır. Bu nedenle tek bir evrensel kuvvet sınırı kullanmak yerine vücut bölgesi, temas alanı, süre ve basınç birlikte incelenir.

Sonuç olarak HRI güvenliği, robota dev bir acil durdurma düğmesi takmaktan ibaret değildir. Güvenli tasarım; mekanik yapı, sensörler, yazılım, doğrulama testleri ve insan davranışının ortak ürünüdür. İyi uygulanmış standartlar teması tamamen yok etmeyebilir, fakat temasın oluşma ihtimalini ve gerçekleştiğinde vereceği zararı ölçülebilir biçimde azaltır.

İki tekerlekli bir robotun devrilmeden ayakta kalması ilk bakışta sihir gibi görünür. Oysa robotun yaptığı şey, düşmeye başladığı yönü sürekli ölçmek ve tekerleklerini aynı yöne sürerek gövdesini yeniden ağırlık merkezinin altına taşımaktır. Bu hızlı geri besleme döngüsü; mekanik, sensör füzyonu ve kontrol teorisinin eğlenceli bir birleşimidir. ``

Ters sarkaç mantığı

Normal bir sarkaç aşağı doğru asılıyken kararlıdır. Ters sarkaçta ise kütle, dönme noktasının üzerinde bulunur. Robotun gövdesi dik konumdan çok az uzaklaştığında yer çekimi onu daha da fazla yatırır. Bu nedenle sistem doğal olarak kararsızdır.

Robotun eğim açısını $theta$, dik konumu da $theta = 0$ kabul edelim. Basitleştirilmiş açısal hareket yaklaşık olarak şöyle düşünülebilir:

Burada $I$ eylemsizlik momenti, $m$ gövde kütlesi, $g$ yer çekimi ivmesi, $l$ ağırlık merkezinin tekerlek eksenine uzaklığı ve $u$ motorların oluşturduğu düzeltici etkidir. Küçük açılarda $sin(theta) yaklaşık theta$ olduğundan model doğrusal hâle getirilebilir. Kontrolcünün görevi, uygun $u$ değerini üreterek açıyı sıfıra yaklaştırmaktır.

Robot eğildiğini nasıl anlar?

MPU6050 gibi bir IMU, ivmeölçer ve jiroskop içerir. İvmeölçer uzun vadede güvenilir bir açı tahmini sunar fakat titreşimlerden etkilenir. Jiroskop hızlı hareketleri iyi ölçer ancak zamanla sürüklenir. İki ölçüm tamamlayıcı filtreyle birleştirilebilir:

$alpha$ çoğunlukla 0,95 ile 0,99 arasında seçilir. Böylece kısa vadede jiroskopa, uzun vadede ivmeölçere güvenilir.

PID kontrolü

En yaygın yaklaşım PID kontrolcüdür. Hata, hedef açı ile ölçülen açı arasındaki farktır:

Kontrol çıkışı ise üç davranışı birleştirir:

Aşağıdaki Arduino tarzı örnek, filtrelenmiş açı üzerinden temel kontrol çıkışını hesaplar:

float kp = 28.0, ki = 0.8, kd = 1.4;
float integral = 0, previousError = 0;

float updateController(float angle, float dt) {
  float targetAngle = 0.0;
  float error = targetAngle - angle;

  integral += error * dt;
  integral = constrain(integral, -20.0, 20.0);

  float derivative = (error - previousError) / dt;
  previousError = error;

  float output = kp * error + ki * integral + kd * derivative;
  return constrain(output, -255.0, 255.0);
}

Fonksiyon, motor sürücüsüne gönderilecek yönlü PWM değerini üretir. İntegral sınırı, motorlar doygundayken hatanın kontrolsüz birikmesini önleyen anti-windup yöntemidir. Robot güvenlik açısını, örneğin 35 dereceyi aşarsa motorlar kapatılmalıdır.

Ayar yaparken izlenecek yol

Önce $K_i$ ve $K_d$ sıfırlanır. $K_p$, robot tepki verene kadar artırılır. Sürekli sallanma başladığında biraz azaltılır. Ardından $K_d$ eklenerek hareket sönümlenir. Son olarak küçük bir $K_i$, ağırlık dağılımından kaynaklanan kalıcı hatayı temizler.

Kontrol döngüsünün sabit aralıklarla, tercihen 200–500 Hz civarında çalışması önemlidir. Gevşek şasi, boşluklu dişliler, düşük torklu motorlar veya gecikmeli yazılım en iyi PID ayarını bile bozabilir. Başarılı bir dengeleme robotu yalnızca iyi kod değil; sağlam mekanik, temiz sensör verisi ve düzenli zamanlama ister. Kısacası robot düşmeyi engellemez; düşüşü saniyede yüzlerce kez ustaca yakalar.

Java Neden Katı Tipli Bir Dildir?

Java, statik ve güçlü tipli bir programlama dilidir. Statik tipleme, değişken tiplerinin derleme aşamasında bilinmesi anlamına gelir. Güçlü tipleme ise uyumsuz tipler arasında kontrolsüz işlem yapılmasını engeller.

Örneğin aşağıdaki kod derlenemez:

int yas = 25;
yas = "yirmi beş"; // Hata: String, int değişkenine atanamaz

Derleyicinin bu itirazı aslında dostça bir uyarıdır. Aksi hâlde program, çalışma sırasında beklenmedik sonuçlarla karşılaşabilirdi. Tip güvenliği sayesinde bir değişkenin hangi değerleri taşıyabileceği ve üzerinde hangi işlemlerin uygulanabileceği bellidir.

İlkel Veri Tipleri

Java’da doğrudan değer saklayan sekiz adet primitive, yani ilkel veri tipi bulunur. Bunlar nesne değildir ve genellikle hızlı, düşük maliyetli veri işlemleri için kullanılır.

$n$ bitlik işaretli bir tam sayının teorik değer aralığı şu şekilde hesaplanır:

Dolayısıyla 8 bitlik byte, $-128$ ile $127$ arasında değer alabilir. Daha büyük bir değer atamaya çalışmak derleme hatasına neden olur.

Değişken Tanımlama ve Tür Dönüşümü

Bir değişken; tip, isim ve isteğe bağlı başlangıç değerinden oluşur:

int ogrenciSayisi = 24;
double sicaklik = 21.5;
char seviye = 'A';
boolean aktifMi = true;

Küçük kapsamlı bir tipten daha geniş kapsamlı tipe geçiş çoğunlukla otomatik yapılır. Buna widening conversion denir. Tersi yönde ise veri kaybı oluşabileceği için açık dönüşüm gerekir.

int puan = 95;
double ondalikliPuan = puan; // Otomatik dönüşüm

double fiyat = 49.99;
int tamFiyat = (int) fiyat;   // Açık dönüşüm: sonuç 49

Diziler: Aynı Tipten Verilerin Takımı

Dizi, aynı veri tipindeki birden fazla değeri sabit uzunlukta saklar. Java dizileri nesnedir; ancak içlerinde ilkel değerler veya nesne referansları bulunabilir.

int[] notlar = {85, 90, 72, 100};

System.out.println(notlar[0]); // 85
System.out.println(notlar.length); // 4

Dizi indeksleri sıfırdan başlar. Uzunluğu $n$ olan bir dizinin geçerli indeks aralığı $0$ ile $n-1$ arasındadır. Bu sınırın dışına çıkılması ArrayIndexOutOfBoundsException üretir.

Diziler sonradan da oluşturulabilir:

String[] diller = new String[3];
diller[0] = "Java";
diller[1] = "Kotlin";
diller[2] = "Python";

for (String dil : diller) {
    System.out.println(dil);
}

Buradaki geliştirilmiş for döngüsü, indeks yönetmeden her elemanı sırayla okur. Dizinin uzunluğu oluşturulduktan sonra değişmez; dinamik boyut gerekiyorsa ArrayList tercih edilir.

Sonuç olarak Java’nın katı tip sistemi, programcıyı kısıtlamak için değil güvenilir kod üretmeye yönlendirmek için vardır. Doğru veri tipini seçmek belleği ve niyeti netleştirirken diziler, benzer verileri düzenli biçimde yönetmenin temelini oluşturur.