``

Fonksiyon aşırı yükleme nedir?

Function overloading, aynı kapsam içerisinde aynı isimli fakat farklı parametre listelerine sahip birden fazla fonksiyon tanımlamaktır. Parametre listesindeki tür, sayı veya sıralama değiştiğinde yeni bir overload meydana gelir.

#include <iostream>
#include <string>

int topla(int a, int b) {
    return a + b;
}

double topla(double a, double b) {
    return a + b;
}

std::string topla(const std::string& a, const std::string& b) {
    return a + b;
}

int main() {
    std::cout << topla(4, 7) << '\n';
    std::cout << topla(2.5, 1.8) << '\n';
    std::cout << topla(std::string("Merhaba "), std::string("C++"));
}

Burada topla(4, 7) çağrısı int sürümünü, ondalıklı argümanlar double sürümünü seçer. Son sürüm ise iki metni birleştirir. const std::string& kullanılması, metinlerin gereksiz yere kopyalanmasını önler.

Derleyici doğru fonksiyonu nasıl seçer?

Derleyici, çağrıdaki argümanları mevcut adayların parametreleriyle karşılaştırır. Bu sürece overload resolution denir. Basitleştirilmiş biçimde her aday için bir dönüşüm maliyeti düşünülebilir:

Burada $C_i$, ilgili argümanın parametre türüne dönüştürülme maliyetidir. En düşük $S$ değerine sahip aday seçilir. Tam eşleşme genellikle standart tür dönüşümünden, standart dönüşüm de kullanıcı tanımlı dönüşümden daha güçlüdür.

Neler overload oluşturur?

Aşağıdaki fonksiyonlar geçerli biçimde aşırı yüklenebilir:

void yazdir(int deger);
void yazdir(double deger);
void yazdir(int deger, int tekrar);
void yazdir(const std::string& metin);

Birincisi ve ikincisi parametre türüyle, üçüncüsü parametre sayısıyla ayrılır. Ancak yalnızca dönüş türünü değiştirmek yeterli değildir:

int hesapla(int x);
// double hesapla(int x); // Hata: Parametre listesi aynı!

Çağıran kod yalnızca hesapla(5) yazdığında hangi dönüş türünü istediğini derleyici kesin olarak anlayamaz. Bu nedenle dönüş türü, fonksiyon aşırı yükleme imzasının ayırt edici parçası değildir.

Belirsizlik tuzağı

Dönüşümler eşit derecede uygun olduğunda derleyici seçim yapamaz:

void goster(long deger) {}
void goster(double deger) {}

int main() {
    // goster(10); // Belirsiz çağrı
    goster(10L);   // long sürümü
    goster(10.0);  // double sürümü
}

10, int türündedir ve hem long hem de double türüne dönüştürülebilir. L ve .0 ekleriyle niyet açıkça belirtilir. Benzer sorunlar varsayılan parametrelerle de oluşabilir.

Ne zaman kullanmalıyız?

Aşırı yüklenen fonksiyonlar kavramsal olarak aynı işi yapmalıdır. yazdir, hesapla veya ekle gibi işlemler bunun için uygundur. Bir overload dosya silerken diğeri matematiksel hesap yapıyorsa ortak isim geliştiriciyi şaşırtır.

Kısacası function overloading, C++ arayüzlerini esnek ve okunabilir hâle getirir. Parametre listelerini belirgin tuttuğunuz, örtük dönüşümleri sınırladığınız ve her sürüme aynı kavramsal sorumluluğu verdiğiniz sürece tek bir isim gerçekten birçok yeteneği zarifçe taşıyabilir.

İstisna yönetiminin temel mantığı

Normal koşullarda fonksiyonlar sonuçlarını return ile döndürür. Ancak bir fonksiyon görevini tamamlayamıyorsa sıradan bir sonuç döndürmek yanıltıcı olabilir. Örneğin pozitif sayı bekleyen bir karekök fonksiyonuna negatif değer verilmesi ayrı bir kontrol akışı gerektirir.

İstisna oluştuğunda program, uygun bir catch bloğu bulana kadar çağrı zincirinde geriye ilerler. Bu sürece stack unwinding denir. Matematiksel olarak bir fonksiyonun geçerli kümesini şöyle gösterebiliriz:

Burada $x < 0$ olması, fonksiyon sözleşmesinin ihlal edildiğini belirtir.

Temel try, throw ve catch kullanımı

Aşağıdaki örnek, bölme işleminden önce paydayı denetler. Sıfıra bölme tespit edildiğinde std::runtime_error nesnesi fırlatılır:

#include <iostream>
#include <stdexcept>

double bol(double pay, double payda) {
    if (payda == 0.0) {
        throw std::runtime_error("Sıfıra bölme girişimi!");
    }
    return pay / payda;
}

int main() {
    try {
        std::cout << bol(42, 0) << '\n';
    } catch (const std::runtime_error& hata) {
        std::cerr << "Hata: " << hata.what() << '\n';
    }
}

İstisnanın const referansla yakalanması gereksiz kopyalamayı engeller ve çok biçimliliği korur. what() metodu ise hatanın açıklamasını verir. Program kontrolsüz biçimde çökmek yerine kullanıcıya anlamlı bir mesaj sunar.

Standart mı, özel istisna mı?

C++ standart kütüphanesi std::exception tabanlı birçok hata türü sağlar.

Uygulamaya özgü hatalar için özel bir sınıf da tanımlanabilir:

#include <stdexcept>
#include <string>

class BakiyeHatasi : public std::runtime_error {
public:
    explicit BakiyeHatasi(const std::string& mesaj)
        : std::runtime_error(mesaj) {}
};

void paraCek(double bakiye, double miktar) {
    if (miktar > bakiye) {
        throw BakiyeHatasi("Yetersiz bakiye");
    }
}

Bu yaklaşım, çağıran kodun banka işlemlerine özgü problemi diğer çalışma zamanı hatalarından ayırmasını sağlar.

Yakalama sırası ve yeniden fırlatma

catch blokları özel türden genel türe doğru sıralanmalıdır. Aksi hâlde std::exception gibi genel bir blok, türetilmiş bütün istisnaları önce yakalayabilir.

try {
    paraCek(100, 250);
} catch (const BakiyeHatasi& hata) {
    std::cerr << hata.what() << '\n';
    throw; // Aynı istisnayı üst seviyeye iletir
} catch (const std::exception& hata) {
    std::cerr << "Genel hata: " << hata.what() << '\n';
}

Parametresiz throw;, mevcut istisnayı türünü kaybetmeden yeniden fırlatır. Bu yöntem, alt seviyede kayıt tutup üst seviyede kullanıcıya cevap vermek için kullanışlıdır.

Güvenli tasarım için kısa kurallar

İstisnaları sıradan döngü kontrolü amacıyla değil, gerçekten olağan dışı durumlar için kullanın. Kaynak yönetiminde RAII yaklaşımını tercih edin; std::vector, std::string ve akıllı işaretçiler stack unwinding sırasında otomatik olarak temizlenir. Yıkıcılar mümkünse istisna fırlatmamalıdır. Ayrıca yalnızca gerçekten garanti verebildiğiniz fonksiyonları noexcept olarak işaretleyin.

Doğru tasarlanmış istisna yönetimi hataları yok etmez; onları görünür, sınıflandırılabilir ve güvenli biçimde yönetilebilir hâle getirir. Böylece programınız ilk beklenmedik durumda havlu atmak yerine kontrollü bir iniş yapar.

C++ şablonlarında özelleştirme ve aşırı yükleme aynı hedefe gidiyormuş gibi görünür: belirli türlerde farklı davranmak. Fakat derleyicinin gözünde bunlar iki ayrı mekanizmadır. Overloading adaylar arasındaki yarışı belirlerken specialization, yarışı kazanan şablonun özel bir sürümünün bulunup bulunmadığına bakar. Küçük görünen bu sıra farkı, şaşırtıcı sonuçların kaynağıdır.

``

İki mekanizmanın temel anlamı

Bir fonksiyon şablonunu aşırı yüklediğimizde derleyicinin aday listesine yeni bir fonksiyon şablonu ekleriz. Açık özelleştirme ise yeni ve bağımsız bir aday oluşturmaz; mevcut birincil şablonun belirli argümanlar için alternatif uygulamasını tanımlar.

#include <iostream>

template<typename T>
void goster(T) {
    std::cout << "Genel sürüm\n";
}

template<>
void goster<int>(int) {
    std::cout << "int özelleştirmesi\n";
}

template<typename T>
void goster(T*) {
    std::cout << "İşaretçi overload'u\n";
}

Burada üç bildirim varmış gibi görünse de overload çözümlemesinde yalnızca goster(T) ve goster(T*) yarışır. goster<int> ise ilk şablona bağlı bir açık özelleştirmedir.

Derleyicinin seçim sırası

Basitleştirilmiş süreç şöyledir:

1. Görünür fonksiyonlar ve fonksiyon şablonları aday kümeye alınır.
2. Şablon argüman çıkarımı yapılır.
3. Dönüşüm kalitesi ve şablonların kısmi sıralaması değerlendirilir.
4. En iyi overload seçilir.
5. Kazanan bir fonksiyon şablonuysa ona ait açık özelleştirme aranır.

Bunu kabaca

şeklinde düşünebiliriz. Buradaki $C$, uygun adaylar kümesidir. İşlemlerin sırası ters değildir; specialization önce yarışıp overload’u yenemez.

Klasik işaretçi sürprizi

int* p = nullptr;
goster(p);

İlk bakışta T = int* olduğundan genel şablonun int* özelleştirmesinin aranacağı düşünülebilir. Ancak goster(T*), int* argümanı için goster(T) şablonundan daha özeldir. Dolayısıyla pointer overload’u yarışı kazanır. Derleyici artık yalnızca bu kazanan şablona bağlı bir explicit specialization olup olmadığına bakar; diğer birincil şablonun özelleştirmesine geri dönmez.

Bu nedenle bir specialization’ın hangi birincil şablona bağlı olduğu kritik önemdedir. Bildirim sırası ve specialization bildiriminin çağrıdan önce görünür olması da ayrı derleme birimlerinde ciddi farklar yaratabilir. Açık özelleştirme, örtük örneklemeye yol açan ilk kullanımdan önce bildirilmelidir.

Neden fonksiyon şablonları kısmen özelleştirilemez?

Sınıf şablonlarında kısmi özelleştirme geçerlidir:

template<typename T>
struct Bilgi;

template<typename T>
struct Bilgi<T*> {
    static constexpr bool pointer = true;
};

Fakat aşağıdaki fonksiyon biçimi geçersizdir:

template<typename T>
void isle<T*>(T*); // Geçersiz kısmi specialization

Fonksiyonlarda aynı niyet overload ile ifade edilir:

template<typename T>
void isle(T*) {
    // Türetilen her işaretçi türü için ortak davranış
}

Bunun önemli nedeni, fonksiyonlarda zaten overload çözümlemesi bulunmasıdır. Kısmi specialization da eklenseydi iki ayrı sıralama sistemi birbiriyle çakışabilirdi.

Pratik tercih rehberi

Bir tür ailesini yakalamak istiyorsanız overload kullanın. Yalnızca tek ve kesin bir şablon argümanı kombinasyonunda davranışı değiştirecekseniz explicit specialization düşünülebilir. Bununla birlikte fonksiyonlarda overload çoğu zaman daha okunabilir ve öngörülebilirdir.

Modern C++ kodunda if constexpr, kavramlar ve requires ifadeleri de güçlü alternatiflerdir. Özellikle kısıtlı overload’lar, niyeti doğrudan tür sistemi üzerinden anlatır. Altın kural şudur: specialization’ı bağımsız yarışmacı sanmayın; o, ancak bağlı olduğu şablon yarışı kazandığında sahneye çıkan yedek oyuncudur.

Artıklılık ne anlama gelir?

Bir manipülatörün eklem değişkenlerini $q \in R^n$, uç efektör görevini ise $x \in R^m$ ile gösterelim. İleri kinematik ilişki

şeklindedir. Eğer eklem sayısı görev uzayının boyutundan büyükse, yani $n > m$ ise sistem redundant kabul edilir. Örneğin üç boyutlu uzayda yalnızca uç noktanın konumunu kontrol etmek için üç bağımsız değişken yeterliyken yedi eklemli bir kol dört adet fazladan serbestlik derecesine sahiptir.

Bu fazlalık gereksiz değildir. Aynı uç efektör konumunu üreten birden fazla eklem yapılandırması bulunabilir. Robot böylece ana görevi bozmadan dirseğini bir engelden uzaklaştırabilir, eklem sınırlarından kaçabilir veya daha rahat bir duruş seçebilir.

Jacobian ve sıfır uzayı

Eklem hızları ile uç efektör hızı arasındaki ilişki Jacobian matrisiyle kurulur:

Redundant bir sistemde ters çözüm tek değildir. Yaygın hız çözümü şöyledir:

Burada $J^+$ Jacobian’ın sözde tersidir. İlk terim uç efektörü hedeflenen yönde hareket ettirir. İkinci terim ise Jacobian’ın sıfır uzayında kalır; başka bir deyişle uç efektör hareketini değiştirmeden eklemleri oynatır. Engel kaçınma sihrinin büyük bölümü bu ikinci terimdedir.

$z$ vektörü, robotu engelden uzaklaştıran bir maliyet fonksiyonunun negatif gradyanı olarak seçilebilir:

$H(q)$ robot ile engel arasındaki mesafe azaldıkça büyüyen bir ceza fonksiyonu olabilir. Böylece robot bir eliyle hedefe ilerlerken “dirseğini içeri çekebilir.”

Basit bir hesaplama örneği

Aşağıdaki Python kodu, ana uç efektör hızına sıfır uzayı üzerinden ikincil bir kaçınma hareketi ekler:

import numpy as np

def redundant_velocity(J, target_velocity, avoidance_gradient, gain=0.4):
    J_pinv = np.linalg.pinv(J)
    identity = np.eye(J.shape[1])

    primary = J_pinv @ target_velocity
    null_space = identity - J_pinv @ J
    secondary = null_space @ (-gain * avoidance_gradient)

    return primary + secondary

primary hedefe ulaşma görevini gerçekleştirir. secondary ise engel maliyetini azaltmaya çalışır. null_space izdüşümü sayesinde ikincil hareket, ideal matematiksel koşullarda uç efektörün istenen hızını bozmaz.

Potansiyel alan yaklaşımı

Engeller çoğu zaman itici potansiyel alanlarla modellenir. Engel ile robot noktası arasındaki mesafe $d$, etkinin başladığı güvenli mesafe $d_0$ olsun:

Robot engelden uzaktaysa ceza sıfırdır; yaklaştıkça hızla büyür. Bu yöntem sezgiseldir fakat yerel minimumlara takılabilir. Ayrıca yalnızca uç efektörü değil, dirsek ve bağlantılar üzerindeki örnek noktaları da kontrol etmek gerekir.

Sonuç olarak fazladan serbestlik derecesi, robota yalnızca daha fazla hareket değil, aynı hedefe giderken daha iyi hareket seçme özgürlüğü verir. Doğru kontrol algoritmasıyla redundant kol; engellerden kaçınabilir, eklem sınırlarını koruyabilir ve çalışma alanında çok daha güvenli davranabilir.

Operatörler: Programın hesaplama araçları

Operatörler, bir veya daha fazla değer üzerinde işlem yapan sembollerdir. Örneğin + toplama yaparken > iki değeri karşılaştırır. Bir ifadenin sonucu başka bir operatörün girdisi olabilir. Bu nedenle işlem önceliğini anlamak önemlidir.

Örneğin aşağıdaki matematiksel ifade Java’da da aynı öncelik mantığıyla değerlendirilir:

Çarpma önce çalışır. Sonucun 28 olması isteniyorsa parantez kullanılmalıdır: (10 + 4) * 2.

Mod alma operatörü %, özellikle çift-tek kontrolünde kullanışlıdır. Bir $n$ sayısı için $n \bmod 2 = 0$ ise sayı çifttir.

Karar yapıları: Yol ayrımındaki Java

if, else if ve else, koşullara göre farklı kod blokları çalıştırır. Koşulun sonucu mutlaka true veya false olmalıdır.

int puan = 78;

if (puan >= 85) {
    System.out.println("Pekiyi");
} else if (puan >= 50) {
    System.out.println("Geçti");
} else {
    System.out.println("Kaldı");
}

Bu kod, karşılaştırma operatörleriyle puanı sınıflandırır. Koşullar yukarıdan aşağıya sınanır ve ilk doğru bloğun ardından yapı sona erer. Dolayısıyla daha özel veya yüksek eşikli koşulların önce yazılması önemlidir.

Sabit seçeneklerin bulunduğu durumlarda switch daha okunaklı olabilir:

String rol = "editor";

switch (rol) {
    case "admin" -> System.out.println("Tam yetki");
    case "editor" -> System.out.println("İçerik düzenleme yetkisi");
    default -> System.out.println("Sınırlı yetki");
}

Üçlü operatörün biçimi koşul ? doğruDeğer : yanlışDeğer şeklindedir. Örneğin yas >= 18 ? "Yetişkin" : "Çocuk" ifadesi kısa bir karar üretir; ancak iç içe kullanılırsa okunabilirliği hızla düşürür.

Döngüler: Tekrarın kontrollü hâli

Döngüler, aynı işlemi belirli bir koşul sağlandığı sürece tekrarlar. for tekrar sayısı bilindiğinde, while koşul ön planda olduğunda, do-while ise bloğun en az bir kez çalışması gerektiğinde tercih edilir.

int toplam = 0;

for (int i = 1; i <= 5; i++) {
    toplam += i;
}

System.out.println(toplam); // 15

Bu döngü $1+2+3+4+5=15$ toplamını hesaplar. Başlangıç değeri, devam koşulu ve artış işlemi aynı satırda görüldüğü için akış kolayca izlenebilir.

break döngüyü tamamen sonlandırırken continue yalnızca mevcut turu atlar. Bunlar güçlü araçlardır; gereğinden fazla kullanılmaları akışı takip etmeyi zorlaştırabilir.

Kısa devre değerlendirmesi

Mantıksal && operatörü ilk koşul yanlışsa ikinci koşulu çalıştırmaz. || ise ilk koşul doğruysa devamını değerlendirmez:

if (kullanici != null && kullanici.isActive()) {
    System.out.println("Giriş başarılı");
}

Burada önce null kontrolü yapılır. Böylece var olmayan bir nesne üzerinde metot çağrılması ve NullPointerException oluşması engellenir.

Sonuç olarak operatörler veriyi dönüştürür, karar ifadeleri uygun yolu seçer ve döngüler tekrarları yönetir. Sağlam bir Java programında bu üçlü birlikte çalışır: doğru koşul kurulur, akış bilinçli biçimde yönlendirilir ve her tekrarın ne zaman biteceği açıkça tanımlanır.

``

Green Project ve Oak’ın Doğuşu

Java’nın hikâyesi 1991 yılında Sun Microsystems bünyesindeki Green Project ile başladı. James Gosling, Mike Sheridan ve Patrick Naughton gibi mühendisler, televizyon kutuları ve ev cihazları için güvenilir bir yazılım platformu geliştirmeye çalışıyordu. C ve C++ güçlüydü; ancak donanıma bağımlılık, elle bellek yönetimi ve işaretçi hataları bu cihazlar için ciddi risk oluşturuyordu.

Gosling tarafından geliştirilen dil önce, ofisinin önündeki ağaçtan esinlenilerek Oak adını aldı. Oak isminin başka bir şirket tarafından tescillenmiş olması nedeniyle dilin adı daha sonra Java olarak değiştirildi. Projenin cihaz pazarı beklenen hızda büyümese de internetin yükselişi, taşınabilir kod fikrine yeni bir sahne hazırladı. Java, 1995 yılında resmen tanıtıldı.

Java’nın temel felsefesi şu sloganla özetlendi: Write Once, Run Anywhere — bir kez yaz, her yerde çalıştır.

Kaynak Koddan Bayt Koda

Java derleyicisi, kaynak kodunu doğrudan belirli bir işlemcinin makine diline dönüştürmez. Bunun yerine JVM’nin anlayabileceği ara temsil olan bayt kodu üretir.

public class MerhabaJVM {
    public static void main(String[] args) {
        int javaYasi = 2026 - 1995;
        System.out.println("Java yaklaşık " + javaYasi + " yaşında!");
    }
}

Bu sınıf şu komutla derlenir:

javac MerhabaJVM.java
java MerhabaJVM

javac komutu kaynak dosyadan MerhabaJVM.class dosyasını üretir. Bu dosya işlemciye özel makine kodu değil, JVM komutları içerir. javap -c MerhabaJVM komutu kullanılarak bayt kod talimatları incelenebilir.

Süreci matematiksel bir dönüşüm gibi gösterebiliriz:

Aynı .class dosyasının farklı sistemlerde çalışabilmesinin koşulu, her sistem için uygun bir JVM bulunmasıdır. Dolayısıyla taşınabilir olan JVM’nin kendisi değil, JVM üzerinde çalışacak şekilde üretilen bayt koddur.

JVM Tam Olarak Ne Yapar?

Java Virtual Machine, fiziksel işlemci ile Java programı arasında soyut bir bilgisayar gibi davranır. Sınıfları yükler, bayt kodunu doğrular, belleği düzenler ve kodu çalıştırır. JVM’nin başlıca bileşenleri şunlardır:

• Class Loader: Gerekli sınıfları çalışma anında yükler.
• Bytecode Verifier: Talimatların güvenli ve kurallara uygun olduğunu denetler.
• Execution Engine: Bayt kodu yorumlar veya makine koduna dönüştürür.
• Garbage Collector: Kullanılmayan nesnelerin belleğini otomatik olarak geri kazanır.
• Runtime Data Areas: Heap, stack ve metot alanı gibi bellek bölgelerini yönetir.

İlk JVM’ler bayt kodu çoğunlukla yorumluyordu. Modern JVM’lerdeki JIT derleyici, sık çalışan kod bölümlerini çalışma sırasında yerel makine koduna çevirir. Basitleştirilmiş performans fikri şöyle ifade edilebilir:

Başlangıçta JIT maliyeti oluşsa da tekrar sayısı $n$ büyüdükçe optimize edilmiş kod önemli hız kazandırır.

Java’nın Evrimi

Java zaman içinde yalnızca bir dil olmaktan çıkıp büyük bir platforma dönüştü. Java 5 generics ve annotation özelliklerini, Java 8 lambda ifadelerini ve Stream API’yi getirdi. Java 9 modül sistemini tanıttı; sonraki sürümler record, sealed class, pattern matching ve virtual thread gibi modern yetenekler ekledi.

Bugün Java’nın gücü; olgun kütüphane ekosistemi, geriye dönük uyumluluk yaklaşımı ve JVM’nin gelişmiş optimizasyonlarında yatıyor. Üstelik Kotlin, Scala ve Clojure gibi diller de JVM üzerinde çalışabiliyor. Kısacası Oak’ın küçük cihazlar için filizlenen fikri, milyonlarca uygulamayı taşıyan oldukça büyük bir ormana dönüştü.

``

Önce problem uzayını tanıyalım

Yol planlamada robotun bulunabileceği tüm durumlar konfigürasyon uzayı, yani $C$-space ile temsil edilir. İki boyutlu hareket eden noktasal bir robot için durum $(x,y)$ olabilir. Robotun yönü de önemliyse durum $(x,y,\theta)$ hâline gelir. Eklemli bir robot kolunda ise her eklem açısı yeni bir boyut ekler.

Engellerin kapladığı durumlar $C_{obs}$, güvenli durumlar ise $C_{free}$ olarak gösterilir. Amaç, başlangıç $q_{start}$ ile hedef $q_{goal}$ arasında tamamen $C_{free}$ içinde kalan bir yol bulmaktır.

A* çoğunlukla ayrıklaştırılmış grafiklerde çalışır. RRT ise sürekli ve yüksek boyutlu uzayları örnekleyerek grafik oluşturur. Temel ayrım burada başlar.

A*: Maliyeti ve hedefi birlikte düşünmek

A*, incelenecek düğümleri şu puana göre seçer:

Burada $g(n)$ başlangıçtan $n$ düğümüne kadar ödenen gerçek maliyet, $h(n)$ ise hedeften ne kadar uzakta olunduğunu tahmin eden sezgisel fonksiyondur. Izgara haritalarda Öklid uzaklığı $h(n)=\sqrt{(x_g-x_n)^2+(y_g-y_n)^2}$ olarak kullanılabilir.

Eğer $h(n)$ gerçek kalan maliyeti abartmıyorsa A*, en düşük maliyetli yolu bulmayı garanti eder. Ancak büyük veya çok boyutlu haritalarda bellekte tuttuğu açık ve kapalı düğüm kümeleri hızla büyüyebilir.

from heapq import heappush, heappop

def astar(start, goal, neighbors, heuristic):
    queue = [(0, start)]
    cost = {start: 0}
    parent = {start: None}

    while queue:
        _, current = heappop(queue)
        if current == goal:
            return parent

        for nxt, step_cost in neighbors(current):
            new_cost = cost[current] + step_cost
            if nxt not in cost or new_cost < cost[nxt]:
                cost[nxt] = new_cost
                priority = new_cost + heuristic(nxt, goal)
                heappush(queue, (priority, nxt))
                parent[nxt] = current

Bu sade uygulama, komşuları değerlendirerek en umut verici düğümü öncelik kuyruğundan seçer. Dönen parent sözlüğü geriye doğru izlenerek yol oluşturulur.

RRT: Boşluğa rastgele dallar uzatmak

RRT başlangıç durumunu ağacın kökü yapar. Ardından uzaydan rastgele bir $q_{rand}$ noktası seçer, ağaçtaki en yakın $q_{near}$ düğümünü bulur ve ona doğru sınırlı bir adım atarak $q_{new}$ üretir. Bağlantı engelle çakışmıyorsa yeni düğüm ağaca eklenir.

def rrt(start, goal, sample, nearest, steer, collision_free):
    tree = [start]
    parent = {start: None}

    for _ in range(5000):
        random_state = sample(goal)
        near = nearest(tree, random_state)
        new = steer(near, random_state)

        if collision_free(near, new):
            tree.append(new)
            parent[new] = near
            if collision_free(new, goal):
                parent[goal] = new
                return parent

sample(goal) zaman zaman doğrudan hedefi seçerse goal bias uygulanır ve arama hızlanabilir. RRT bir çözümü çabuk bulabilir; fakat bulunan yol genellikle zikzaklıdır ve en kısa yol garantisi yoktur. Bu nedenle sonradan yol yumuşatma yapılır veya asimptotik olarak optimum çözüme yaklaşan RRT* kullanılır.

Hızlı karşılaştırma

Hangisini seçmeli?

Depo robotu gibi iki boyutlu, bilinen bir maliyet haritasında çalışan sistemlerde A* güçlü ve öngörülebilir bir tercihtir. Robot kolu, insansız hava aracı veya karmaşık hareket kısıtları bulunan bir araç söz konusuysa RRT daha doğal olabilir. Pratik sistemler ikisini birleştirebilir: RRT ile uygulanabilir bir koridor bulunup A* veya optimizasyon yöntemleriyle yol iyileştirilebilir. Kısacası A* haritayı dikkatle okuyan bir kâşif, RRT ise hızla farklı yönlere dal uzatan bir öncüdür.

Denetimli öğrenmenin temel mantığı

Denetimli öğrenmede model, giriş ve doğru çıktı çiftlerinden oluşan bir veri kümesiyle eğitilir. Bir kamera görüntüsü $x$, görüntüdeki nesnenin etiketi ise $y$ olsun. Modelin amacı, görüntüyü etikete dönüştüren yaklaşık bir $f_\theta$ fonksiyonu öğrenmektir:

Buradaki $\theta$, sinir ağının eğitim sırasında ayarlanan parametrelerini temsil eder. Model tahmini ile gerçek etiket arasındaki fark bir kayıp fonksiyonuyla ölçülür:

Kısacası model, yaptığı hataları azaltarak öğrenir. Fakat doğru cevapları gösteren $y_i$ etiketleri azsa, hatalıysa veya gerçek çalışma ortamını temsil etmiyorsa robot sağlam bir algı geliştiremez.

Robotikte etiket neden pahalıdır?

İnternetteki kedi fotoğraflarını sınıflandırmak görece kolaydır. Robotik verilerde ise yalnızca “bu bir kutudur” demek yetmeyebilir. Kutunun piksel düzeyindeki sınırı, üç boyutlu konumu, yönelimi, uzaklığı ve tutulabilir bölgeleri de işaretlenebilir. LiDAR nokta bulutları, termal kameralar ve kuvvet sensörleri gibi farklı kaynaklar işi daha da zorlaştırır.

Üstelik fabrikada toplanan veriler, açık havada çalışan bir robotu temsil etmeyebilir. Bu durum dağılım kayması olarak adlandırılır. Eğitim verisi $P_{train}(x)$ ile gerçek ortam $P_{real}(x)$ farklı olduğunda yüksek laboratuvar başarısı sahada hızla düşebilir.

Az etiketin model üzerindeki etkileri

Etiketli veri eksikliği yalnızca doğruluğu azaltmaz. Nadir nesneler yeterince görülmediği için sınıf dengesizliği oluşur. Model arka plan, renk veya ışık gibi yanıltıcı ipuçlarını ezberleyebilir. Yeni bir kamera açısı karşısında şaşırabilir ve belirsiz olduğu durumlarda bile aşırı güvenli tahminler üretebilir. Otonom araç veya cerrahi robot gibi güvenlik kritik sistemlerde bu, basit bir yazılım hatasından çok daha ciddi sonuçlar doğurur.

Darboğazı aşma yöntemleri

Aktif öğrenmede model, en kararsız olduğu görüntüleri insana gönderir. Aşağıdaki basitleştirilmiş örnek, en düşük güvene sahip tahminleri seçer:

def etiketlenecekleri_sec(model, etiketsiz_veri, adet=20):
    # Her örnek için sınıf olasılıklarını hesaplar.
    olasiliklar = model.predict_proba(etiketsiz_veri)

    # En yüksek olasılık düşükse model kararsız kabul edilir.
    guvenler = olasiliklar.max(axis=1)
    indeksler = guvenler.argsort()[:adet]
    return indeksler

Bu yöntem, her görüntüyü etiketlemek yerine öğrenmeye en fazla katkı sağlayacak örneklere odaklanır. Sentetik veriyle birleştiğinde maliyet daha da düşürülebilir. Alan rastgeleleştirme kullanılarak simülasyondaki ışık, doku, kamera açısı ve nesne konumu sürekli değiştirilir; böylece model tek bir yapay görünüme bağlanmaz.

Sonuç

Robotik algılamanın sınırı çoğu zaman model mimarisi değil, verinin kalitesi ve çeşitliliğidir. Daha büyük bir sinir ağı, eksik dünya bilgisini sihirli biçimde tamamlayamaz. Başarılı sistemler; az sayıdaki kaliteli etiketi, bol miktarda etiketsiz veri, simülasyon, aktif öğrenme ve dikkatli saha testleriyle birleştirir. Robotlara görmeyi öğretirken asıl soru “Kaç görüntümüz var?” değil, “Bu görüntüler robotun karşılaşacağı dünyayı ne kadar iyi anlatıyor?” olmalıdır.

Here-document nasıl çalışır?

Here-document, bir komutun standart girdisine çok satırlı içerik gönderir. Genel sözdizimi şöyledir:

cat <<EOF
Merhaba dünya
EOF

Shell, <<EOF ifadesini gördüğünde sonraki satırları okumaya başlar. Yalnızca tamamı EOF olan bir satırla karşılaştığında okumayı bırakır. Buradaki EOF özel bir anahtar kelime değildir; SON, METIN veya başka bir ad da seçilebilir.

Bunu bir eşitlik gibi düşünebiliriz. Açılışta tanımlanan sınırlayıcı $D$ olsun. Kapanışın geçerli olması için okunan satır $L$ şu koşulu sağlamalıdır:

Satırın başında boşluk varsa gerçekte $L = \text{“ EOF”}$ olur. Bu değer EOF ile aynı değildir. Dolayısıyla $L \neq D$ ve here-document kapanmaz.

Girinti neden sınırlayıcıyı bozar?

Aşağıdaki kod estetik görünse de hatalıdır:

if true; then
    cat <<EOF
    Kullanıcı bulundu.
    EOF
fi

Kapanış satırındaki dört boşluk da verinin parçasıdır. Shell EOF ararken ` EOF` görür. Bash çoğunlukla dosyanın sonuna kadar okumayı sürdürür ve sınırlayıcının bulunamadığını belirten bir uyarı verir.

Çözüm 1: Sınırlayıcıyı satır başına taşımak

En taşınabilir çözüm, kapanış sınırlayıcısını girintisiz yazmaktır:

if true; then
    cat <<EOF
Kullanıcı bulundu.
İşlem başlatılıyor.
EOF
fi

Bu yaklaşım POSIX uyumludur. Dezavantajı, metnin çevresindeki kodla hizalanmamasıdır. Buna rağmen farklı Shell ortamlarında güvenilir davranması nedeniyle genellikle en güvenli seçimdir.

Çözüm 2: <<-EOF ve sekme kullanmak

Tireli biçim, here-document satırlarının başındaki sekme karakterlerini kaldırır:

if true; then
	cat <<-EOF
	Kullanıcı bulundu.
	İşlem başlatılıyor.
	EOF
fi

Bu kodda girintiler gerçek tab karakteri olmalıdır. Dört boşluk, ekranda sekmeyle aynı görünebilir fakat aynı karakter değildir. Matematiksel olarak temizleme işlemini $T$ ile gösterirsek, <<- için karşılaştırma $T(L)=D$ biçiminde yapılır; burada $T$, yalnızca baştaki tab karakterlerini siler.

Değişken genişletmesini de unutmayın

Sınırlayıcının tırnaklanması, içerikte değişkenlerin çalışıp çalışmayacağını belirler:

name="Ada"

cat <<EOF
Merhaba $name
EOF

cat <<'EOF'
Bu kez $name aynen yazılır.
EOF

İlk blok Merhaba Ada üretirken ikinci blok $name metnini değiştirmeden basar. Girinti problemiyle tırnaklama birbirinden ayrı konulardır: <<- sekmeleri yönetir, 'EOF' ise değişken ve komut genişletmesini engeller.

Pratik hata ayıklama

Editörünüz boşluk ve tab karakterlerini görünür yapabiliyorsa bu özelliği açın. Ayrıca sorunlu satırı incelemek için sed -n l dosya.sh kullanılabilir; tab karakterleri genellikle \t olarak görünür. Özetle kapanış sınırlayıcısını tamamen sola yaslamak en sade çözümdür. Kod hizalaması şartsa <<-EOF kullanın, fakat girintinin boşluk değil gerçek sekme olduğundan emin olun. Shell gözünde güzel hizalama değil, baytların birebir eşleşmesi önemlidir.

Bir robotun odadaki nesneleri toplaması etkileyicidir; yüzlerce küçük robotun lider olmadan alan taraması, yük taşıması veya kayıp bir kişiyi araması ise bilim kurgu gibi görünür. Sürü robotiği, tam olarak bu kolektif davranışı inceler. Karıncaların yiyecek bulması ve kuşların çarpışmadan uçması gibi doğadaki örneklerden esinlenen yaklaşımda karmaşık görevler, basit yerel kurallara uyan çok sayıda robot tarafından çözülür.

``

Merkezi olmayan koordinasyon nedir?

Geleneksel bir robot filosunda merkezi bilgisayar, her robota nereye gideceğini söyleyebilir. Sürü robotiğinde ise çoğunlukla böyle bir komutan bulunmaz. Her robot yalnızca sensörlerinden, yakın komşularından ve çevrede bırakılan dolaylı işaretlerden yararlanarak karar verir. Başka bir deyişle hiçbir robot büyük resmin tamamını görmez; ancak sürü, yerel etkileşimlerden küresel bir düzen üretir.

Bu olgu belirme veya emergence olarak adlandırılır. Bir robotun davranışını basitçe şöyle modelleyebiliriz:

Burada $u_i(t)$ robotun hareket komutunu, $x_i(t)$ kendi durumunu, $N_i(t)$ algıladığı komşuları ve $E_i(t)$ çevresel bilgiyi temsil eder. Fonksiyon basit olsa bile bütün robotların tekrar eden etkileşimi karmaşık sonuçlar doğurabilir.

Basit kurallar, şaşırtıcı sonuçlar

Sürülerde sık kullanılan üç hareket kuralı vardır: komşularla çarpışmayı önleyen ayrılma, aynı yönde ilerlemeyi sağlayan hizalanma ve grubun yakınında kalmayı sağlayan uyum. Robot $i$ için birleşik hız komutu şu şekilde yazılabilir:

$$

$$\alpha$, $\beta$ ve $\gamma$ katsayıları sürünün karakterini değiştirir. Ayrılma ağırlığı düşükse robotlar birbirine girebilir; uyum aşırı yüksekse sürü hedef yerine kendi merkezine takıntılı hâle gelebilir. Robotların bile ayar tutturması gerekiyor!

Aşağıdaki Python benzeri kod, bir robotun komşularına göre yönünü güncelleyen sadeleştirilmiş bir kontrol döngüsüdür:

def yeni_hiz(robot, komsular, hedef):
    ayrilma = carpismadan_kac(robot, komsular)
    hizalanma = ortalama_hiz(komsular)
    uyum = komsu_merkezine_git(robot, komsular)
    gorev = hedefe_yonel(robot, hedef)

    return (1.5 * ayrilma
            + 0.8 * hizalanma
            + 0.6 * uyum
            + 1.2 * gorev)

Bu fonksiyon merkezi bir plan istemez. Her robot aynı döngüyü kendi ölçümleriyle çalıştırır. Katsayılar simülasyonda denenebilir veya pekiştirmeli öğrenmeyle optimize edilebilir.

Sürü görevleri nasıl bölüşür?

Koordinasyon yalnızca birlikte hareket etmek değildir. Robotlar keşif, taşıma ve iletişim rölesi gibi rolleri de paylaşabilir. Örneğin bir robot hedef bulduğunda dijital bir “feromon” bırakabilir. Diğerleri bu işaretin yoğunluğunu takip ederken işaret zamanla buharlaşır. Böylece eski bilgiler unutulur, güncel ve kısa rotalar güçlenir.

Bir görevin robot tarafından seçilme olasılığı eşik modeliyle ifade edilebilir:

Burada $s$ görevin uyarı gücü, $\theta$ robotun uzmanlık eşiğidir. Farklı eşikler, önceden lider atamadan doğal bir iş bölümü oluşturur.

Güçlü ama kusursuz değil

Sürü robotiği arama-kurtarma, hassas tarım, depo otomasyonu, uzay keşfi ve çevresel izleme için dayanıklı çözümler sunar. Ancak zayıf iletişim, sensör gürültüsü, enerji sınırları ve yerel kuralların beklenmeyen davranışlar üretmesi ciddi sorunlardır. Ayrıca yüzlerce robotun güvenli olduğunu matematiksel olarak doğrulamak, tek robotu doğrulamaktan çok daha zordur.

Yine de yaklaşımın temel fikri son derece güçlüdür: Karmaşıklık her zaman karmaşık bir yöneticiden gelmek zorunda değildir. Doğru yerel kurallar, sürekli geri bildirim ve yeterli sayıda katılımcı birleştiğinde, sürü tek tek üyelerinden çok daha yetenekli bir sisteme dönüşebilir.