``

Açık kaynak erişilebilirliği nasıl artırıyor?

Açık kaynaklı donanımda devre şemaları, yazılım araçları, kütüphaneler ve örnek projeler toplulukla paylaşılır. Kullanıcı yalnızca hazır bir ürünü tüketmez; sistemin nasıl çalıştığını inceleyebilir, değiştirebilir ve yeniden üretebilir. Bu yaklaşım erişilebilirliği üç yönden güçlendirir:

• Ekonomik erişim: Düşük maliyetli kartlar ve uyumlu yan ürünler kullanılabilir.
• Bilgiye erişim: Ücretsiz belgeler, videolar ve topluluk forumları öğrenme sürecini destekler.
• Deneysel erişim: Öğrenci, hata yapmaktan korkmadan devreyi ve kodu değiştirebilir.

Robotik sistemlerin temelinde algılama, karar verme ve hareket etme döngüsü bulunur. Sensör çevreden veri toplar, kontrol birimi bu veriyi işler ve aktüatörler fiziksel tepki üretir:

Örneğin ultrasonik sensörün gönderdiği ses dalgasının geri dönüş süresi $t$, ses hızı $v$ ve engel uzaklığı $d$ arasındaki ilişki şöyledir:

İkiye bölünmesinin nedeni, ölçülen sürenin sesin engele gidişini ve geri dönüşünü birlikte içermesidir. Böyle bir formül, fizik bilgisini doğrudan çalışan bir robot üzerinde görünür hâle getirir.

Arduino mu, Raspberry Pi mı?

Her iki platform da robotik eğitiminde değerlidir; ancak aynı işi yapmak üzere tasarlanmamıştır.

Arduino, çizgi izleyen veya engelden kaçan bir robot için güçlü bir başlangıçtır. Raspberry Pi ise kamera görüntüsünden nesne tanıyan ya da web arayüzüyle yönetilen robotlarda öne çıkar. İki kart birlikte de kullanılabilir: Raspberry Pi yüksek seviyeli kararları verirken Arduino motorları zamanlamaya duyarlı biçimde kontrol edebilir.

Küçük bir robot refleksi

Aşağıdaki Arduino kodu, bir dijital sensör engel algıladığında motor kontrol çıkışını durdurur. Bu örnek, algılama-karar-hareket döngüsünün en sade hâlidir:

const int sensorPin = 2;
const int motorPin = 9;

void setup() {
  pinMode(sensorPin, INPUT);
  pinMode(motorPin, OUTPUT);
}

void loop() {
  bool engelVar = digitalRead(sensorPin);

  if (engelVar) {
    analogWrite(motorPin, 0);    // Motoru durdur
  } else {
    analogWrite(motorPin, 180);  // Orta-yüksek hızda ilerle
  }

  delay(20); // Sensörü saniyede yaklaşık 50 kez kontrol et
}

Kod yalnızca programlamayı değil, giriş-çıkış mantığını ve geri beslemeyi de öğretir. Öğrenci 180 değerini değiştirerek hızın davranışa etkisini gözlemleyebilir. Elbette gerçek bir motor doğrudan karta bağlanmamalı; motor sürücü devresi ve uygun güç kaynağı kullanılmalıdır.

Erişilebilirlik yalnızca düşük fiyat değildir

Ucuz kartlar tek başına eşit eğitim fırsatı oluşturmaz. İnternet erişimi, yerelleştirilmiş içerik, öğretmen eğitimi, yedek parça bulunabilirliği ve güvenli çalışma ortamı da önemlidir. Ayrıca açık kaynak projelerde belgelerin güncelliği değişebilir ve Raspberry Pi gibi kartların toplam maliyetine güç kaynağı, hafıza kartı ve çevre birimleri eklenebilir.

Buna rağmen bu platformların en büyük katkısı, öğrenciyi pasif kullanıcıdan üreticiye dönüştürmesidir. Bir LED’i yakmakla başlayan yolculuk; otonom araçlara, tarım robotlarına veya yapay zekâ destekli sistemlere uzanabilir. Robotik böylece ulaşılmaz bir gelecek teknolojisi değil, parçalarına ayrılıp anlaşılabilen ve yeniden tasarlanabilen bir öğrenme alanı hâline gelir.

Eşzamanlılık ve paralellik aynı şey değildir

Eşzamanlılık, birden fazla işin zaman aralıkları iç içe geçecek şekilde ilerlemesidir. Paralellik ise bu işlerin gerçekten aynı anda, örneğin farklı işlemci çekirdeklerinde çalışmasıdır.

Bir işin tek çekirdekte tamamlanma süresi $T_1$, $p$ çekirdekteki süresi $T_p$ ise teorik hızlanma şöyle ifade edilir:

İdeal durumda $S_p \approx p$ beklenir. Gerçekte görev oluşturma maliyeti, senkronizasyon ve paylaşılan kaynaklar nedeniyle bu değere nadiren ulaşılır.

TPL ile CPU ağırlıklı işleri çalıştırmak

TPL, görevlerin uygun iş parçacıklarına dağıtılmasını ThreadPool üzerinden yönetir. Böylece her iş için elle Thread oluşturmak gerekmez.

using System;
using System.Linq;
using System.Threading.Tasks;

int[] sayilar = Enumerable.Range(1, 8).ToArray();

Parallel.ForEach(sayilar, sayi =>
{
    double sonuc = Math.Sqrt(sayi) * Math.Pow(sayi, 3);
    Console.WriteLine($"{sayi}: {sonuc} - Thread: {Environment.CurrentManagedThreadId}");
});

Parallel.ForEach, koleksiyondaki hesaplamaları mümkün olduğunda farklı iş parçacıklarında yürütür. Ancak çok küçük işlemleri paralelleştirmek, yönetim maliyeti yüzünden normal bir döngüden daha yavaş olabilir. Önce ölçmek, sonra paralelleştirmek altın kuraldır.

Bağımsız görevleri başlatıp hepsinin bitmesini beklemek için Task.WhenAll kullanılabilir:

Task<int> hesap1 = Task.Run(() => Enumerable.Range(1, 1_000_000).Sum());
Task<int> hesap2 = Task.Run(() => Enumerable.Range(1, 500_000).Sum());

int[] sonuclar = await Task.WhenAll(hesap1, hesap2);
Console.WriteLine($"Toplam: {sonuclar.Sum()}");

Task.Run, CPU ağırlıklı senkron kodu ThreadPool üzerinde çalıştırır. Buna karşılık zaten asenkron olan HTTP veya veritabanı çağrılarını ayrıca Task.Run içine koymak genellikle gereksizdir.

async/await ile beklerken kaynak tüketmemek

async, metodun asenkron işlem içerebildiğini; await ise işlem tamamlanana kadar kontrolün çağırana geri verilebileceğini belirtir. Bu sırada iş parçacığının bloklanması gerekmez.

using System.Net.Http;

static async Task<int> SayfaBoyutuAsync(
    string adres,
    CancellationToken iptal)
{
    using HttpClient istemci = new();
    string icerik = await istemci.GetStringAsync(adres, iptal);
    return icerik.Length;
}

using CancellationTokenSource kaynak = new();
kaynak.CancelAfter(TimeSpan.FromSeconds(5));

try
{
    int boyut = await SayfaBoyutuAsync("https://example.com", kaynak.Token);
    Console.WriteLine($"İndirilen karakter: {boyut}");
}
catch (OperationCanceledException)
{
    Console.WriteLine("İşlem iptal edildi.");
}

Buradaki CancellationToken, uzun süren işlemin kontrollü biçimde durdurulmasını sağlar. await edilen görev hata üretirse istisna normal bir senkron metottaki gibi try/catch ile yakalanabilir.

Paylaşılan veriler ve yarış durumları

Birden fazla görev aynı değişkeni değiştirirse sonuç öngörülemez olabilir. Örneğin sayac++ atomik değildir; okuma, artırma ve yazma adımlarından oluşur. Güvenli artırma için Interlocked.Increment(ref sayac) veya daha karmaşık kritik bölgelerde lock kullanılmalıdır.

Modern C# kodunda temel yaklaşım basittir: I/O ağırlıklı işlemlerde doğal asenkron API’leri await edin, CPU ağırlıklı ve bağımsız hesaplamalarda TPL kullanın, paylaşılan durumu azaltın ve performans kararlarını mutlaka ölçümlerle doğrulayın.

C++ dünyasında bir nesne her zaman göründüğü şey olmayabilir. Elinizde Karakter* türünde bir işaretçi bulunurken, işaret edilen gerçek nesne bir Buyucu veya Savasci olabilir. Çalışma Zamanı Tür Bilgisi, yani RTTI (Run-Time Type Information), program çalışırken bu gerçek kimliği öğrenmemizi ve kalıtım hiyerarşilerinde güvenli dönüşümler yapmamızı sağlar. ``

RTTI neden gereklidir?

C++ değişkenlerinin çoğu tür bilgisi derleme zamanında bellidir. Ancak polimorfizm kullanıldığında statik tür ile dinamik tür birbirinden ayrılır:

• Statik tür: Değişkenin kaynak kodunda bildirilen türdür.
• Dinamik tür: Çalışma anında gerçekten oluşturulmuş nesnenin türüdür.

Bir Karakter* değişkeninin statik türü Karakter*, gösterdiği nesne Buyucu ise dinamik türü Buyucu olur. Bunu kabaca şu ilişkiyle gösterebiliriz:

RTTI özellikle taban sınıf üzerinden yönetilen nesnelerin alt sınıflarını ayırt etmek gerektiğinde devreye girer. Bunun çalışabilmesi için taban sınıfın polimorfik olması, yani en az bir sanal (virtual) fonksiyon içermesi gerekir. Genellikle sanal yıkıcı tanımlamak yeterlidir.

class Karakter {
public:
    virtual ~Karakter() = default;
};

class Buyucu : public Karakter {
public:
    void buyuYap() {
        std::cout << "Ateş topu!\n";
    }
};

Sanal yıkıcı hem RTTI kullanımını mümkün kılar hem de nesne taban sınıf işaretçisi üzerinden silindiğinde doğru yıkıcının çağrılmasını sağlar.

typeid ile türü incelemek

typeid operatörü bir ifade veya tür hakkında std::type_info nesnesi döndürür. İki türün aynı olup olmadığı güvenilir biçimde karşılaştırılabilir:

#include <iostream>
#include <typeinfo>

Karakter* karakter = new Buyucu();

if (typeid(*karakter) == typeid(Buyucu)) {
    std::cout << "Bu karakter gerçekten bir büyücü.\n";
}

delete karakter;

Burada typeid(*karakter) dinamik türü bulur. Buna karşılık typeid(karakter) işaretçinin kendi türünü, yani Karakter* türünü verir. type_info::name() da kullanılabilir; ancak döndürdüğü metnin biçimi derleyiciye bağlıdır ve program mantığı için güvenilir değildir.

dynamic_cast ile güvenli dönüşüm

dynamic_cast, polimorfik kalıtım hiyerarşilerinde çalışma zamanı kontrolü yapar. İşaretçi dönüşümü başarısız olursa nullptr döndürür:

Karakter* karakter = new Buyucu();

if (Buyucu* buyucu = dynamic_cast<Buyucu*>(karakter)) {
    buyucu->buyuYap();
} else {
    std::cout << "Bu karakter büyü yapamaz.\n";
}

 delete karakter;

Referanslarda başarısızlık nullptr ile bildirilemez. Bu nedenle dynamic_cast<Buyucu&> başarısız olduğunda std::bad_cast istisnası fırlatır.

Dönüşüm araçlarının karşılaştırması

static_cast ile aşağı dönüşüm yapılabilir, fakat nesne hedef türde değilse davranış tanımsız olabilir. Başka bir deyişle hız uğruna emniyet kemerini çıkarmış olursunuz.

Tasarım açısından son notlar

RTTI kullanışlıdır ancak her nesnenin türünü sürekli sorgulamak tasarım kokusuna dönüşebilir. Çoğu durumda sanal fonksiyonlar daha temiz bir çözüm sunar: nesneye “Sen büyücü müsün?” diye sormak yerine doğrudan eylemYap() çağrısı yapılabilir.

Yine de eklenti sistemleri, nesne editörleri ve heterojen koleksiyonlar gibi alanlarda RTTI oldukça değerlidir. Kural basittir: Tür gerçekten belirsizse dynamic_cast, davranış polimorfik biçimde ifade edilebiliyorsa sanal fonksiyon kullanın. Böylece C++ nesneleri maskelerini çıkarsa bile programınız şaşırmaz.

``

Iterator neden geçersiz olur?

Iterator, çoğu zaman bir elemana ulaşmayı sağlayan adres benzeri bir nesnedir. Bir eleman silindiğinde konteyner, belleğini yeniden düzenleyebilir. Iterator artık yaşayan bir elemana işaret etmiyorsa onu karşılaştırmak, artırmak veya dereference etmek güvenli değildir.

Örneğin vector, elemanlarını ardışık bellekte tutar. İndisi $i$ olan eleman silindiğinde arkasındaki yaklaşık

eleman sola taşınır. Böylece silinen elemanı ve sonrasını gösteren iterator’lar geçersizleşir. İşlemin zaman karmaşıklığı da bu taşıma nedeniyle genel olarak $O(n)$ olur.

std::vector<int> sayilar{1, 2, 3, 4, 5};
auto it = sayilar.begin() + 2; // 3

sayilar.erase(it);
// it artık geçersizdir!
// std::cout << *it; // Tanımsız davranış

Buradaki yaygın yanılgı, it değişkeninin otomatik olarak sıradaki elemana geçeceğini düşünmektir. Oysa erase, eski iterator’ı onarmaz; bunun yerine geçerli olan sonraki iterator’ı döndürür.

Güvenli silme deseni

Dolaşma sırasında silme yapılacaksa erase dönüş değeri kullanılmalıdır:

std::vector<int> sayilar{1, 2, 3, 4, 5, 6};

for (auto it = sayilar.begin(); it != sayilar.end(); ) {
    if (*it % 2 == 0) {
        it = sayilar.erase(it); // Sonraki geçerli konumu al
    } else {
        ++it;                   // Yalnızca silinmediyse ilerle
    }
}

Döngünün üçüncü bölümü özellikle boş bırakılmıştır. Hem erase sonrasında hem de döngü sonunda ++it çalıştırılsaydı bir eleman atlanabilirdi.

Konteynerlere göre kurallar

list düğüm tabanlı olduğu için bir düğümün çıkarılması diğer düğümlerin adreslerini değiştirmez. map ve set gibi ağaç tabanlı yapılarda da benzer bir güvence vardır. Buna rağmen silinen iterator’ın kendisini kullanmak her durumda hatadır.

deque daha dikkatli ele alınmalıdır: Baştan veya sondan silmenin kuralları daha sınırlı etkiler doğurabilirken ortadan silme, iterator’ları geniş ölçüde geçersizleştirir. Kodun taşınabilir ve anlaşılır olması için daima erase dönüş değerini kullanmak en güvenli yaklaşımdır.

Modern C++ ile erase_if

Amaç yalnızca koşula uyan elemanları temizlemekse C++20, iterator yönetimini gizleyen daha okunaklı bir araç sunar:

#include <algorithm>
#include <vector>

std::vector<int> sayilar{1, 2, 3, 4, 5, 6};

std::erase_if(sayilar, [](int deger) {
    return deger % 2 == 0;
});

Eski standartlarda vector için erase-remove deyimi kullanılır:

sayilar.erase(
    std::remove_if(sayilar.begin(), sayilar.end(),
                   [](int x) { return x % 2 == 0; }),
    sayilar.end()
);

remove_if fiziksel silme yapmaz; korunacak elemanları öne taşır ve mantıksal yeni sonu döndürür. Asıl küçültmeyi erase gerçekleştirir.

Kısa kural şudur: Bir silme işleminden sonra eski iterator’ın hâlâ geçerli olduğunu varsayma. Konteynerin geçersizleştirme kurallarını kontrol et, mümkünse erase tarafından döndürülen iterator’ı kullan ve toplu koşullu silmelerde std::erase_if tercih et. Böylece iterator’ların hayaletlere dönüşmesini engellersin.

``

Üç aracın temel zihinsel modeli

Bu araçların hepsi standart girdiyi okuyabilir ve boru hatlarında kullanılabilir; ancak metne farklı gözlüklerle bakarlar.

• grep, satırların belirli bir desene uyup uymadığıyla ilgilenir.
• sed, metni satır satır dönüştüren bir akış düzenleyicisidir.
• awk, kayıtları alanlara ayırıp koşul, değişken ve aritmetik kullanabilen küçük bir programlama dilidir.

Bir dosyada $n$ satır, her satırda ortalama $m$ karakter varsa basit tarama maliyeti kabaca $O(nm)$ olur. Araç seçiminin asıl farkı çoğunlukla teorik karmaşıklık değil, aynı işi ifade etmek için gereken zihinsel ve sözdizimsel karmaşıklıktır.

grep ile tornavida kullanmak

grep yalnızca eşleşen satırları seçmek için mükemmeldir:

grep -i "error" app.log

Bu komut, büyük-küçük harfi önemsemeden error içeren satırları getirir. Fakat ikinci sütundaki değerleri toplamak istiyorsak grep, görevi tek başına doğal biçimde ifade edemez. Karmaşık grep, cut, paste ve bc zincirleri kurulabilir; ancak bu, market alışverişine forkliftle gitmeye benzer.

Doğal çözüm awk kullanmaktır:

awk '{ toplam += $2 } END { print toplam }' satis.txt

Burada her satır bir kayıt, boşluklarla ayrılmış parçalar ise alan kabul edilir. $2 ikinci alanı, END ise bütün kayıtlar işlendikten sonraki aşamayı temsil eder.

sed ile muhasebe yapmaya çalışmak

sed, değiştirme işlemlerinde parlar:

sed 's/http:/https:/g' adresler.txt

Komut, her satırdaki tüm http: ifadelerini https: ile değiştirir. Buna karşılık sayısal karşılaştırma, toplam veya ortalama gerektiğinde sed komutları hızla anlaşılmaz hâle gelir.

Örneğin üçüncü sütunu 100’den büyük kayıtları seçmek için doğru yaklaşım şudur:

awk '$3 > 100 { print $1, $3 }' veriler.txt

Ortalama hesaplamak da doğrudandır. Değerlerin toplamı $S$, kayıt sayısı $N$ ise ortalama

olur:

awk '{ s += $3; n++ } END { if (n) print s / n }' veriler.txt

awk ile basit aramayı büyütmek

awk '/hata/' app.log geçerli bir komuttur; fakat yalnızca eşleşen satırları istiyorsak niyetimizi grep 'hata' app.log daha açık anlatır. awk, alan seçimi veya ek mantık devreye girdiğinde anlam kazanır:

awk '$2 == "ERROR" && $4 >= 500 { print $1, $4 }' app.log

Bu örnek hem alan karşılaştırır hem sayısal koşul uygular. Yani awk burada gerçekten maaşını hak eder.

Araçlar rakip değil, ekip arkadaşıdır

Tek bir komuta bütün işi yüklemek zorunda değiliz. Önce ilgili satırları filtreleyip sonra metni dönüştürebiliriz:

grep '^WARN' app.log | sed 's/^WARN/UYARI/'

Yine de gereksiz süreçlerden kaçınmak gerekir. Aynı işlem tek ve anlaşılır bir awk programıyla yapılabiliyorsa uzun boru hattı kurmak hata ayıklamayı zorlaştırabilir.

Pratik karar kuralı basittir: Buluyorsan grep, değiştiriyorsan sed, alanlar üzerinde düşünüyor veya hesaplıyorsan awk. Görev büyüdükçe kabuk komutlarını zorlamak yerine Python gibi genel amaçlı bir dile geçmek de yenilgi değil, doğru mühendislik kararıdır.

İstisna nedir?

İstisna, programın normal çalışma akışını bozan bir olaydır. Java’da istisnalar nesne olarak temsil edilir ve temel olarak Throwable sınıfından türetilir. Bir sorun oluştuğunda istisna “fırlatılır”; uygun bir yönetici bulunduğunda ise “yakalanır”.

Bu davranışı basitçe şöyle düşünebiliriz:

Java’daki hata hiyerarşisinin iki önemli kolu vardır:

try ve catch nasıl çalışır?

Risk oluşturabilecek kod try bloğuna yazılır. Bir istisna meydana gelirse Java, ilgili türü karşılayan catch bloğunu arar. Böylece uygulama tamamen sonlanmak yerine alternatif bir davranış gösterebilir.

public class BolmeOrnegi {
    public static void main(String[] args) {
        int bolunen = 24;
        int bolen = 0;

        try {
            int sonuc = bolunen / bolen;
            System.out.println("Sonuç: " + sonuc);
        } catch (ArithmeticException e) {
            System.out.println("Bir sayı sıfıra bölünemez.");
            System.out.println("Teknik ayrıntı: " + e.getMessage());
        }

        System.out.println("Program çalışmaya devam ediyor.");
    }
}

Burada sıfıra bölme işlemi ArithmeticException üretir. catch bloğu hatayı yakalar, kullanıcıya anlaşılır bir mesaj verir ve programın sonraki satırlara devam etmesini sağlar.

Birden fazla hata türü için birden fazla catch kullanılabilir. Ancak özel istisnalar önce, daha genel olanlar sonra yazılmalıdır. Aksi hâlde genel blok diğerlerini erişilemez yapabilir.

finally neden kullanılır?

finally bloğu, istisna oluşsa da oluşmasa da çalıştırılması gereken işlemler içindir. Dosya kapatmak, bağlantıyı sonlandırmak veya geçici kaynakları temizlemek klasik kullanım örnekleridir.

try {
    System.out.println("Veritabanı işlemi başlatıldı.");
    // Riskli sorgular burada çalıştırılır.
} catch (RuntimeException e) {
    System.out.println("İşlem başarısız: " + e.getMessage());
} finally {
    System.out.println("Bağlantı ve kaynaklar temizleniyor.");
}

Modern Java’da dosya ve benzeri AutoCloseable kaynaklar için try-with-resources daha güvenlidir:

try (var okuyucu = new java.io.BufferedReader(
        new java.io.FileReader("veriler.txt"))) {
    System.out.println(okuyucu.readLine());
} catch (java.io.IOException e) {
    System.out.println("Dosya okunamadı: " + e.getMessage());
}

Bu yapı, okuyucuyu otomatik kapatır ve unutulan kaynaklar yüzünden oluşabilecek sızıntıları azaltır.

Sağlam istisna yönetimi için ipuçları

• Boş bir catch bloğu kullanarak hatayı sessizce yutmayın.
• Kullanıcıya anlaşılır, geliştiriciye ayrıntılı günlük mesajları sağlayın.
• Yalnızca gerçekten yönetebileceğiniz istisnaları yakalayın.
• Exception gibi aşırı genel türleri gereksiz yere kullanmayın.
• İstisnaları normal karar mekanizması yerine koymayın.

İyi tasarlanmış istisna yönetimi, uygulamanın hiç hata vermemesi anlamına gelmez. Asıl başarı; hata geldiğinde paniklemeyen, kaynaklarını temizleyen, kullanıcıyı bilgilendiren ve mümkünse güvenli biçimde yoluna devam eden bir sistem kurmaktır.

``

PID kontrolcü, ölçülen durum ile hedef arasındaki hatayı kullanarak eyleyiciye uygulanacak komutu hesaplar. Temel denklem şöyledir:

Burada $e(t)$ hedef ile ölçüm arasındaki farktır. $K_p$ anlık hataya, $K_i$ geçmişte biriken hataya, $K_d$ ise hatanın değişim hızına tepki verir. Üç kazanç birlikte çalışır; fakat her biri robotun davranışını farklı yönde iter.

Aşırı salınım neden oluşur?

Yüksek $K_p$, robota “Hata büyük, daha sert hareket et!” der. Ancak motor ve mekanik sistem atalet taşır. Robot hedefe ulaştığında hareket enerjisi henüz kaybolmamıştır; bu nedenle hedefi geçer. Kontrolcü ters yönde komut verir ve süreç salınıma dönüşebilir. $K_i$ de geçmiş hataları toplamaya devam ederse hedefe varılmış olsa bile güçlü komut üretebilir. Buna integral windup, yani integral yığılması denir.

Yüzde aşım yaklaşık olarak şu şekilde ölçülür:

Örneğin hedef açı $90°$, görülen tepe değer $99°$ ise aşım yüzde 10’dur. Hassas bir kavrayıcı için bu oran tehlikeliyken, hızlı hareket eden basit bir mobil robot için kabul edilebilir olabilir.

Yavaş tepki neden her zaman güvenli değildir?

Kazançları fazla düşük tutmak aşımı azaltabilir; ancak robot komutlara geç yanıt verir. Denge robotunda bu gecikme düşmeye, çizgi izleyen robotta parkurdan çıkmaya yol açabilir. Dolayısıyla yalnızca aşımı küçültmek yeterli değildir. Yükselme süresi, oturma süresi, kalıcı hata ve kontrol sinyalinin büyüklüğü birlikte değerlendirilmelidir.

Pratik tuning sırası

Önce $K_i$ ve $K_d$ sıfırlanır, ardından $K_p$ robot hızlı tepki verip salınım sınırına yaklaşana kadar artırılır. Sonra $K_d$ eklenerek hareket sönümlenir. En son küçük bir $K_i$, sürtünme veya yük nedeniyle kalan sabit hatayı temizlemek için kullanılır. Her değişiklikten sonra aynı hedef, yük ve başlangıç koşullarıyla test yapmak önemlidir.

Aşağıdaki Python kodu, ölçüm kayıtlarından aşım ve yaklaşık oturma süresini hesaplar:

import numpy as np

def response_metrics(time, output, target, tolerance=0.02):
    output = np.asarray(output)
    error = np.abs(output - target)

    overshoot = max(0.0, (output.max() - target) / abs(target) * 100)
    limit = tolerance * abs(target)
    settling_time = None

    for i in range(len(output)):
        if np.all(error[i:] <= limit):
            settling_time = time[i]
            break

    return {'overshoot_percent': overshoot,
            'settling_time': settling_time}

Kod, tepe değeri kullanarak yüzde aşımı bulur ve çıktının yüzde 2 tolerans bandında kalmaya başladığı zamanı oturma süresi kabul eder. Böylece tuning, “gözüme iyi göründü” yaklaşımından ölçülebilir bir optimizasyona dönüşür.

Sonuç olarak ideal PID ayarı evrensel değildir. Robotun kütlesi, motor gücü, sensör gürültüsü ve görevi denge noktasını belirler. İyi tuning, en hızlı veya en sakin hareketi değil; görevin izin verdiği aşım sınırında yeterince hızlı, kararlı ve güvenli tepkiyi hedefler.

``

Hareket kısıtı ne demektir?

Bir robotun konfigürasyonu genellikle

ile gösterilir. Burada $x$ ve $y$ konumu, $\theta$ ise yönelimi temsil eder. Robot üç boyutlu bir konfigürasyon uzayında bulunsa da her yönde anlık hız üretemeyebilir.

Bir kısıt yalnızca konfigürasyon değişkenleriyle

şeklinde yazılabiliyorsa holonomik kabul edilir. Kısıt hızlara bağlıysa ve konum düzeyinde bütünleştirilemiyorsa non-holonomik davranış ortaya çıkar. Bu tür kısıtların yaygın gösterimi şöyledir:

Örneğin diferansiyel sürüşlü bir robotun yana kaymama koşulu:

biçimindedir. Denklem basitçe şunu söyler: Robotun tekerlek ekseni doğrultusunda yanal hızı yoktur. Yani robot araba park eder gibi birkaç manevra yapmak zorunda kalabilir.

İki hareket dünyasının karşılaştırması

Holonomik bir platform için A* algoritması iki boyutlu ızgarada kısa bir yol bulabilir. Robot, gerektiğinde yönünü değiştirmeden yana kayabilir. Non-holonomik bir araçta ise aynı yol üzerindeki doksan derecelik köşe fiziksel olarak uygulanamayabilir.

Yol planlamasına etkisi

Non-holonomik planlamada yalnızca engellerden kaçmak yetmez. Planlayıcı; yönelim, minimum dönüş yarıçapı, geri hareket izni ve direksiyon sınırı gibi değişkenleri de değerlendirmelidir. Bu nedenle klasik A* yerine Hybrid A*, state lattice, RRT, RRT* veya Dubins ve Reeds–Shepp eğrileri kullanılabilir.

Dubins aracı yalnızca ileri hareket eder ve eğriliği sınırlıdır. Reeds–Shepp modeli ise geri vitese de izin verir. Böylece iki durum arasındaki mesafe, Öklid uzaklığından daha gerçekçi hesaplanır:

Çünkü kuş uçuşu en kısa çizgi, otomobil sürüşü açısından her zaman uygulanabilir değildir.

Basit bir kısıt kontrolü

Aşağıdaki Python fonksiyonu, diferansiyel robotun verilen dünya hızlarında yanal kayma üretip üretmediğini denetler:

import math

def hareket_gecerli_mi(theta, vx, vy, tolerans=1e-3):
    # Robot gövdesine göre yanal hız bileşenini hesaplar.
    yanal_hiz = -math.sin(theta) * vx + math.cos(theta) * vy
    return abs(yanal_hiz) < tolerans

print(hareket_gecerli_mi(0.0, 1.0, 0.0))  # True: ileri hareket
print(hareket_gecerli_mi(0.0, 0.0, 1.0))  # False: doğrudan yana kayma

Gerçek bir planlayıcı, komşu durum üretirken yalnızca bu koşulu test etmekle kalmaz; robotun hareket modelini kısa bir süre boyunca simüle eder. Örneğin

modeliyle farklı $v$ ve $\omega$ komutları denenerek erişilebilir yeni düğümler oluşturulur. Böylece arama ağacındaki her bağlantı gerçekten uygulanabilir olur.

Sonuç

Holonomik planlama geometrik olarak “Nereden geçebilirim?” sorusuna odaklanırken non-holonomik planlama buna “Oraya hangi yönelim ve manevrayla ulaşabilirim?” sorusunu ekler. Daha gerçekçi kısıtlar daha fazla hesaplama gerektirir; ancak uygulanamayan kısa bir yol yerine güvenli, pürüzsüz ve sürülebilir bir rota üretir. Robotik dünyasında en kısa yol bazen düz çizgi değil, doğru kıvrımdır.

``

History expansion nedir?

Bash, etkileşimli kullanımda önceki komutları hızlıca çağırmak için ! ile başlayan ifadeleri yorumlayabilir. Örneğin !! son komutu, !42 geçmişteki 42 numaralı komutu, !git ise git ile başlayan son komutu temsil eder.

Bunu basitçe şu dönüşümle düşünebiliriz:

Buradaki $H$, history expansion etkinse ünlem ifadelerini geçmişteki komutlarla değiştiren fonksiyondur. Özellik kapalıysa $H(x)=x$ olur; yani metin değişmeden kalır.

Bash’in etkileşimli olmayan betiklerinde history expansion normalde kapalıdır. Ancak betik source ile etkileşimli bir kabuğa yüklenirse, bash -H ile başlatılırsa veya kod içinde set -H çalıştırılırsa özellik devreye girebilir. Bu yüzden “Betikte asla olmaz” varsayımı güvenli değildir.

Çifte tırnak her zaman korumaz

Shell programlamasında çifte tırnağın özel karakterleri tamamen etkisizleştirdiği sanılır. Oysa history expansion etkin olduğunda !, çifte tırnak içinde de yorumlanabilir:

#!/usr/bin/env bash
set -H

password="Guclu!Parola"
echo "$password"

Bash, !Parola için uygun bir geçmiş olayı arayabilir ve event not found hatası üretebilir. Üstelik expansion, değişkenin değerinden çok kaynak satırı okunurken önem kazanır. Bu nedenle davranış kabuk sürümüne, çalışma biçimine ve bağlama göre şaşırtıcı görünebilir.

En güvenli çözüm: Özelliği kapatmak

History expansion gerekmeyen bir betiğin başında özelliği açıkça kapatabilirsiniz:

#!/usr/bin/env bash
set +H
# Aynı işlemin daha açıklayıcı karşılığı:
set +o histexpand

message="Dağıtım tamamlandı!"
printf '%s\n' "$message"

set +H, histexpand seçeneğini kapatır. Buradaki artı işaretinin seçeneği kapatması ilk bakışta ters gelebilir: Bash’te set -H açar, set +H kapatır.

Sabit bir değer söz konusuysa tek tırnak da kullanılabilir:

printf '%s\n' 'İşlem başarılı!'
printf '%s\n' 'api-token: abc!123'

Ancak tek tırnak içinde değişken genişletmesi yapılmaz. Örneğin 'Merhaba $USER!', kullanıcı adını değil, doğrudan $USER metnini yazdırır.

Durumu teşhis etmek

Seçeneğin mevcut durumunu aşağıdaki komutla görebilirsiniz:

set -o | grep histexpand

Çıktıda histexpand on görülüyorsa ünlem genişletmesi açıktır. Betik source script.sh biçiminde çalıştırılıyorsa aynı kabuğun seçeneklerini miras alabileceğini unutmayın. Bağımsız çalıştırma için yürütme izni verip ./script.sh kullanmak daha öngörülebilir olabilir.

Özetle ünlem kaynaklı hatalarda yalnızca kaçış karakterleriyle boğuşmayın. Önce kabuğun türünü, betiğin nasıl çalıştırıldığını ve histexpand durumunu kontrol edin. Otomasyon kodunda geçmiş komut sihrine ihtiyaç yoksa set +H diyerek sürprizi daha perde açılmadan bitirin.

Potansiyel alanın temel mantığı

Robotun konumu $q$, hedef konumu ise $q_g$ olsun. Sistemdeki toplam potansiyel enerji, çekici ve itici bileşenlerin toplamıdır:

Hedefin oluşturduğu çekici potansiyel çoğunlukla şöyle tanımlanır:

Burada $k_{att}$ çekim katsayısıdır. Engellere ait itici potansiyel ise robot engele belirli bir mesafeden daha yakın olduğunda etkinleşir:

$\rho(q)$ en yakın engele olan mesafeyi, $\rho_0$ ise engelin etki mesafesini temsil eder. Robotun hareket yönü, toplam potansiyelin negatif gradyanından elde edilir:

Başka bir deyişle robot, enerji yüzeyinde aşağı doğru yuvarlanan bir bilye gibidir. Sorun, yüzeydeki her çukurun gerçek hedef olmamasıdır.

Yerel minimum nasıl oluşur?

Yerel minimumda çekici ve itici kuvvetler birbirini dengeler:

Robot hedefte olmadığı hâlde bileşke kuvvet sıfır olduğu için hareket komutu üretemez. Özellikle U biçimli engeller, birbirine yakın engeller ve hedefin bir engelin hemen arkasında bulunması bu riski artırır. Dar geçitlerde görülen sağa-sola salınım ise tam anlamıyla yerel minimum değildir; fakat yöntemin yalnızca anlık geometrik bilgiye dayanmasından kaynaklanan benzer bir başarısızlıktır.

Basit bir kuvvet hesabı

Aşağıdaki Python fonksiyonu, iki boyutlu ortamda hedef çekimini ve engel itmesini hesaplar. Kod, yöntemin yerel ve tepkisel yapısını görünür kılar:

import numpy as np

def potential_force(position, goal, obstacles,
                    k_att=1.0, k_rep=0.8, influence=2.0):
    position = np.asarray(position, dtype=float)
    goal = np.asarray(goal, dtype=float)

    force = k_att * (goal - position)

    for obstacle in obstacles:
        delta = position - np.asarray(obstacle, dtype=float)
        distance = np.linalg.norm(delta)

        if 1e-6 < distance < influence:
            direction = delta / distance
            magnitude = k_rep * (1 / distance - 1 / influence) / distance**2
            force += magnitude * direction

    return force

Robot her çevrimde bu kuvvetin yönünde küçük bir adım atabilir. Ancak fonksiyon geçmiş hareketleri veya engelin genel şeklini bilmez. Hesaplanan kuvvet sıfıra yaklaşırsa robot, önünde geçerli bir çıkış olsa bile onu keşfedemeyebilir.

Tuzaktan kurtulma yöntemleri

Yerel minimum riskini azaltmak için birkaç yaklaşım kullanılabilir:

• Rastgele kaçış kuvveti: Robot uzun süre ilerleyemezse geçici bir rastgele yön eklenir.
• Teğetsel kuvvet: Engeli yalnızca itmek yerine çevresinden dolaşmayı teşvik eden bir bileşen uygulanır.
• Ara hedefler: Global planlayıcının ürettiği yol üzerindeki noktalar sırayla hedef seçilir.
• Harmonik potansiyeller: Laplace tabanlı alanlarla hedef dışındaki minimumların oluşması sınırlandırılır.
• Hibrit planlama: A*, Dijkstra veya RRT global rota için; potansiyel alan ise anlık kaçınma için kullanılır.

Pratikte en güvenilir çözüm hibrit yaklaşımdır. Yapay potansiyel alan hızlı refleksler sağlarken global planlayıcı, robotun bazen hedefe yaklaşmak için önce hedeften uzaklaşması gerektiğini anlayabilir. Böylece robot görünmez bir çukurda düşüncelere dalmak yerine yoluna devam eder.