``

Önce beklentiyi doğru ayarlayalım

Bir beyin–bilgisayar arayüzü, İngilizce kısaltmasıyla BCI, kas hareketlerini zorunlu tutmadan sinirsel etkinlik üzerinden iletişim kurmayı hedefler. Örneğin kullanıcı sağ veya sol elini hareket ettirdiğini hayal eder; sistem bu iki durumu ayırt etmeye çalışır. Bazı sistemlerdeyse kullanıcı yanıp sönen seçeneklerden birine odaklanır. Buradaki bilgi, serbest düşüncenin içeriği değil, önceden tanımlanmış bir görevle ilişkili örüntüdür.

Ölçüm yöntemleri aynı kapıya farklı yollardan ulaşır:

Sinyalden komuta: küçük bir çeviri fabrikası

Tipik işlem zinciri şöyledir:

Ölçüm → temizleme → özellik çıkarımı → sınıflandırma → komut → geri bildirim.

EEG, tek bir nöronun konuşması değildir. Çok sayıda kaynağın elektriksel etkileri, ölçüm noktasında birbirine karışır. Göz kırpması, çene kasları ve elektrik şebekesi de bu karışıma katılabilir. Dolayısıyla yüksek genlik, otomatik olarak güçlü bir niyet anlamına gelmez.

Motor imgelemede sık incelenen özellikler, yaklaşık 8–13 Hz mu ve 13–30 Hz beta bantlarındaki güç değişimleridir. Bu değişimler kişiye ve göreve göre farklılaşır; sabit bir düşünce sözlüğü oluşturmazlar. Özellik vektörünü $h$ ile gösterirsek, basit bir ikili sınıflandırıcı şöyle yazılabilir:

Burada $w$ öğrenilen ağırlıkları, $b$ sabit terimi, $p$ ise modelin bir sınıfa verdiği olasılık tahminini temsil eder. Bu tahminin güvenilirliği ayrıca değerlendirilmelidir. Model, kişinin niyetini doğrudan bilmez; eğitim verisindeki ilişkilere dayanarak karar verir. Korelasyon, zihin okuma değildir.

Python ile bant gücünden sınıflandırmaya

Aşağıdaki örnek, NumPy, SciPy ve scikit-learn kullanır. Dosyada artefaktları önceden ele alınmış EEG denemeleri bulunmalıdır: X boyutu (deneme, kanal, örnek), y sağ/sol imgeleme etiketleri, oturum kayıt oturumu kimlikleri, fs örnekleme frekansıdır. En az üç farklı oturum gerekir.

import numpy as np
from scipy.signal import welch
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import GroupKFold, cross_val_score

d = np.load("eeg_denemeleri.npz")
X, y, oturum = d["X"], d["y"], d["oturum"]
fs = float(d["fs"])
f, psd = welch(X, fs=fs,
               nperseg=min(256, X.shape[-1]), axis=-1)

bantlar = []
for alt, ust in [(8, 13), (13, 30)]:
    sec = (f >= alt) & (f < ust)
    guc = np.trapezoid(psd[..., sec], f[sec], axis=-1)
    bantlar.append(np.log(guc + 1e-12))
F = np.concatenate(bantlar, axis=1)

model = make_pipeline(StandardScaler(),
                      LogisticRegression(max_iter=1000))
skorlar = cross_val_score(
    model, F, y, groups=oturum,
    cv=GroupKFold(n_splits=3), scoring="balanced_accuracy"
)
print(skorlar.mean())

Welch yöntemi güç spektrumunu tahmin eder; bant integralleri kanal başına özellik üretir. Logaritma, güç değerlerinin geniş aralığını sıkıştırır. Pipeline, ölçekleyicinin yalnızca eğitim bölümünde öğrenilmesini sağlar. Oturum bazlı bölme ise aynı kaydın benzer parçalarının eğitim ve teste karışmasını önler. Kod, NumPy 2 veya üzerindeki trapezoid işlevini kullanır.

Laboratuvardan gerçek hayata geçiş

Yüksek test başarısı, kullanışlı bir arayüz için tek başına yeterli değildir. Gecikme, yanlış komut sıklığı, kalibrasyon süresi ve kullanıcı yorgunluğu da ölçülmelidir. Dengeli doğruluk, sınıfların ayrı ayrı başarılarını eşit ağırlıkla değerlendirir. Rastgele deneme bölmek yerine yeni oturumlarda sınamak, günlük kullanım performansını anlamaya daha çok yardımcı olur.

Gerçek zamanlı sistemde kararsız tahminler komuta dönüştürülmeyebilir. Kullanıcıya geri bildirim vermek ve gerektiğinde onay istemek, özellikle tekerlekli sandalye gibi fiziksel sonuç doğuran uygulamalarda önemlidir. Bu örnek, güvenlik doğrulaması yapılmış bir kontrol sistemi değildir.

Sinirsel kayıtlar da hassas verilerdir: açık rıza, sınırlı saklama ve güvenli erişim tasarımın parçası olmalıdır. Klinik uygulamalarda profesyonel değerlendirme gerekir. Sonuç olarak düşünceden komuta geçmek mümkün; fakat başarılı BCI, sihirli bir okuyucu değil, kullanıcıyla birlikte öğrenen kontrollü bir çevirmen gibi çalışır.

Bir robotun sabah depoda kutu taşıyıp öğleden sonra serada bitki kontrolü yaptığını düşünün. Bunu iki ayrı makineyle çözmek mümkün; ancak modüler tasarım, aynı gövdenin hareket, algılama ve tutma bileşenlerini değiştirerek farklı görevlere uyarlanmasını sağlar. Robot biraz LEGO setine benzer, fakat burada parçaların yalnızca birbirine oturması değil, birlikte güvenle çalışması gerekir. ``

Modülerlik: Parçalardan Daha Büyük Bir Fikir

Modüler robot, belirli işlevleri bağımsız birimlere ayıran robot mimarisidir. Tekerlek takımı hareketi, kamera çevreyi algılamayı, kavrayıcı ise nesnelerle etkileşimi üstlenebilir. Her birimin görev sınırı ve bağlantı kuralları açıkça tanımlanır. Böylece bir bileşeni değiştirmek, robotun tamamını yeniden tasarlamayı gerektirmez. Buradaki temel ilke, işlevsel ayrıştırma ve standart arayüzlerdir.

Bu yaklaşımın iki yaygın biçimi vardır. Sabit gövdeli sistemlerde uç araçlar ve sensörler değiştirilir. Yeniden yapılandırılabilir sistemlerde ise bağlantılı modüller robotun fiziksel biçimini de değiştirebilir. İlk yaklaşım endüstriyel uygulamalarda daha kolay yönetilirken ikincisi daha geniş hareket olanakları sunar; buna karşılık kontrol ve bağlantı tasarımı zorlaşır.

Mimariyi $G=(V,E)$ grafiğiyle düşünebiliriz: $V$ modülleri, $E$ ise aralarındaki bağlantıları temsil eder. Bağlantının mekanik, elektriksel veya veri taşıyan niteliği önemlidir. Bir kameranın takılabilmesi, kontrol yazılımının onu kullanabileceği anlamına gelmez!

Esnekliğin Gizli Kahramanı: Arayüzler

Başarılı modülerlik, bağlantı noktasında başlar. Mekanik arayüz; ölçüleri, kilitleme yöntemini ve taşınabilecek yükü belirlemelidir. Elektriksel arayüz; gerilim, akım sınırı, kutuplama ve koruma düzenini tanımlar. Veri arayüzü ise mesaj biçimini, haberleşme hızını ve hata davranışını kapsar. CAN veya Ethernet kullanmak tek başına yeterli değildir; modüllerin aynı mesajların anlamında da anlaşması gerekir.

Yazılım tarafında sürücüler, donanım ayrıntılarını ortak yeteneklere dönüştürebilir. Örneğin farklı kavrayıcılar aynı “aç”, “kapat” ve “durum oku” işlemlerini sunar. Böylece görev planlayıcısı marka veya model yerine yeteneklerle çalışır. Yine de kavrama kuvveti ve konum hassasiyeti gibi sınırlar ayrıca bildirilmelidir.

Fizik kuralları ise tak-çıkar heyecanına kapılmaz. Bir kolun yükten kaynaklanan torku basitçe $T=F r$ ile hesaplanır. Burada $F$ kuvvet, $r$ dönme eksenine olan dik uzaklıktır. Aynı yükü iki kat uzağa taşımak, tork ihtiyacını iki katına çıkarır. Dolayısıyla daha uzun modül, daha güçlü motor veya daha düşük taşıma kapasitesi gerektirebilir.

Python ile Göreve Uygun Yapılandırma

Aşağıdaki örnek, seçilen modüllerin besleme gerilimini ve görev yeteneklerini denetler. Donanımı hareket ettirmez; yapılandırmanın yazılım düzeyindeki bir ön kontrolüdür. Python 3.9 ve üzeriyle çalışır.

from dataclasses import dataclass

@dataclass(frozen=True)
class Module:
    name: str
    capabilities: frozenset[str]
    voltage: int = 24

modules = {
    "drive": Module("Tekerlek", frozenset({"hareket"})),
    "gripper": Module("Kavrayıcı", frozenset({"kavrama"})),
    "camera": Module("Kamera", frozenset({"görüntüleme"})),
}

def configure(names, required):
    selected = [modules[name] for name in names]
    if any(module.voltage != 24 for module in selected):
        raise ValueError("Besleme gerilimi uyumsuz")
    available = frozenset().union(
        *(module.capabilities for module in selected)
    )
    missing = set(required) - available
    if missing:
        raise ValueError(f"Eksik yetenekler: {sorted(missing)}")
    return [module.name for module in selected]

print(configure(["drive", "gripper"], {"hareket", "kavrama"}))
print(configure(["drive", "camera"], {"hareket", "görüntüleme"}))

İlk çağrı taşıma, ikinci çağrı gözlem görevine uygun parçaları seçer. Gerçek uygulamada bu kontrole mekanik uyumluluk, akım bütçesi, haberleşme protokolü ve güvenlik kısıtları da eklenmelidir. Yetenek etiketi, performans garantisi değildir.

Parça Değiştiğinde Ne Yeniden Kontrol Edilmeli?

Modül değişimi sonrasında robotun kütlesi, ağırlık merkezi ve durma mesafesi değişebilir. Kamera değişirse kalibrasyon; kavrayıcı değişirse kuvvet sınırları ve araç koordinat sistemi güncellenmelidir. Yapılandırma kaydı tutmak, hangi donanımın hangi yazılım sürümüyle test edildiğini izlemeyi kolaylaştırır. Bu kayıtlar bakım ekibinin “Dün çalışıyordu!” bilmecesini çözmesinde özellikle değerlidir.

Sistem özel olarak enerjiliyken değişime uygun tasarlanmamışsa parçalar güç kesilerek değiştirilmelidir. Ardından bağlantılar doğrulanmalı, düşük hızda işlev testi yapılmalı ve güvenlik sınırları yeniden değerlendirilmelidir.

Modülerlik her durumda daha ucuz veya daha hafif değildir. Ek bağlantılar maliyet, boşluk ve arıza noktası yaratabilir. Ancak görevler sık değişiyorsa ortak gövdeyi korumak ciddi avantaj sağlar. İyi tasarlanmış modüler robot, her işi kusursuz yapan sihirli makine değil; yeni işleri kontrollü biçimde öğrenebilen bir mühendislik platformudur.

Bir banka hesabını programlamak istediğinizi düşünün: hesabın bakiyesi vardır, para çekilebilir ve işlemin sonucu öğrenilebilir. C# bu dünyayı sınıflar, nesneler ve metotlarla temsil eder. İşin eğlenceli kısmı, aynı hesaba iki farklı değişkenle ulaşabilmenizdir. Ancak bir nesneyi değiştirmekle, değişkenin gösterdiği nesneyi değiştirmek aynı şey değildir!

``

Sınıf plan, nesne çalışan örnektir

Sınıf, verileri ve davranışları bir araya getiren tür tanımıdır. Nesne, bu sınıftan oluşturulan somut örnektir. Metot ise bir nesnenin gerçekleştirebildiği işlemi tanımlar; ayrıca sınıfa ait statik metotlar da bulunabilir.

Bir sınıftan oluşturulan iki nesnenin bakiyeleri birbirinden bağımsız olabilir. Buna karşılık iki değişken aynı nesneye bağlanabilir. Aynı televizyonu yöneten iki kumanda düşünün: kumandalar farklıdır, fakat değiştirilen televizyon aynıdır.

C# sınıfları referans türüdür. Bir sınıf değişkeninin değeri, nesnenin kendisi değil, ona erişmeyi sağlayan referanstır. Referansı kopyalamak, nesneyi çoğaltmaz.

Durumu davranışla korumak

Aşağıdaki sınıf, bakiyenin dışarıdan doğrudan değiştirilmesini engeller. Kurucu metot başlangıç durumunu oluşturur; ParaCek ise çekim kurallarını uygular ve sonucu bildirir.

using System;

public class Hesap
{
    public decimal Bakiye { get; private set; }

    public Hesap(decimal bakiye)
    {
        if (bakiye < 0)
            throw new ArgumentOutOfRangeException(nameof(bakiye));

        Bakiye = bakiye;
    }

    public bool ParaCek(decimal tutar, out decimal kalan)
    {
        kalan = Bakiye;

        if (tutar <= 0 || tutar > Bakiye)
            return false;

        Bakiye -= tutar;
        kalan = Bakiye;
        return true;
    }
}

private set, bakiyenin yalnızca sınıf içinden atanabilmesini sağlar. Bu yaklaşım kapsülleme olarak adlandırılır: veriyi saklamaktan çok, geçerli durumları korumak önemlidir. Negatif başlangıç bakiyesi reddedilir; geçersiz çekim ise hesabı değiştirmez.

Başarılı çekimin matematiksel modeli şöyledir:

Burada $T$ çekilen tutardır; işlemin kabul koşulu $0 < T \leq B_{ilk}$ şeklindedir. Kod, bu koşulu denetleyerek nesnenin tutarlılığını korur. Para hesaplarında decimal, ondalık değerleri temsil etmek için genellikle double türünden daha uygundur.

Varsayılan aktarım, ref ve out

C# parametreleri varsayılan olarak değer ile aktarır. decimal parametresinde sayısal değer kopyalanır. Hesap parametresinde ise referansın değeri kopyalanır. Bu yüzden normal bir parametre üzerinden nesnenin özelliklerini değiştirmek mümkündür; bunun için ref gerekmez.

Ancak metot içinde normal parametreye new Hesap(...) atamak, çağıranın değişkenini başka nesneye yönlendirmez. Yalnızca parametrenin yerel kopyası değişir. İşte ref, çağıranın değişkenine erişim sağlayarak bu ayrımı görünür kılar.

ref ve out, hem metot bildiriminde hem çağrıda belirtilir. out parametresi, metot içinde okunmadan önce atanmalıdır. Örneğimizde kalan başlangıçta atanır; böylece başarısız çekimde bile kullanılabilir bir sonuç döner.

Referansı değiştirmek başka bir iştir

.NET 6+ konsol projesinde aşağıdaki üst düzey kullanım kodunu sınıf bildiriminden önce yerleştirebilirsiniz:

var hesap = new Hesap(100m);
var ortak = hesap;

bool basarili = hesap.ParaCek(30m, out decimal kalan);
Console.WriteLine($"Başarılı: {basarili}, kalan: {kalan}");

ortak.ParaCek(10m, out kalan);
Console.WriteLine(hesap.Bakiye); // 60

Yenile(ref hesap);
Console.WriteLine(hesap.Bakiye); // 0
Console.WriteLine(ortak.Bakiye); // 60

static void Yenile(ref Hesap hedef)
{
    hedef = new Hesap(0m);
}

İlk atamada ortak ve hesap aynı nesneyi gösterir. Dolayısıyla ortak üzerinden yapılan çekim, hesap üzerinden görülen bakiyeyi de değiştirir. Yenile ise ref sayesinde doğrudan hesap değişkeninin referansını değiştirir. ortak, eski nesneyi göstermeyi sürdürür; nesne topluca sıfırlanmamıştır.

Küçük bir seçim rehberi

Tek sonuç için çoğunlukla dönüş değerini kullanın. Başarı bilgisiyle ek sonuç gerekiyorsa out kullanışlıdır; int.TryParse bunun klasik örneğidir. Çağıranın mevcut değişkenini değiştirmek gerekiyorsa ref düşünülebilir. Son kontrol sorunuz şu olsun: “Nesnenin durumunu mu, değişkenin değerini mi değiştiriyorum?” Bu ayrım, referans karmaşasının büyük bölümünü çözer.

``

Titreşim neden değerli bir ipucudur?

Dönen tambur, motor, rulmanlar ve amortisörler farklı titreşim bileşenleri üretir. Dengesiz yük, dönme frekansı çevresindeki hareketi artırabilir; rulman hasarı ise darbe benzeri bileşenler oluşturabilir. Ancak aynı belirti birden fazla nedenden kaynaklanır. Sensörümüz dedektiftir, kahin değil!

Dakikada 1200 devir yapan tamburun dönme frekansı $1200/60=20\,\text{Hz}$ olur. Frekans analizi, titreşim enerjisinin hangi bölgelerde yoğunlaştığını gösterir. Bu bilgi, toplam titreşim seviyesinden daha açıklayıcı olabilir.

Bunlar kesin teşhis değildir. Aynı makine, aynı hızda bile farklı yüklerle farklı davranabilir.

Önce doğru veriyi toplayalım

Bir ivmeölçer, üretici önerilerine uygun ve güvenli bir gövde noktasına sabitlenebilir. Sensörün konumu ve montajı değişirse referans da değişir. Elektrik veya hareketli parçalar çevresindeki müdahaleler uzmanlık gerektirir.

Örnekleme hızı, ilgilenilen en yüksek frekansın iki katından büyük olmalıdır: $f_s>2f_{\max}$. Pratikte uygun kenar payı ve örnekleme öncesi anti-aliasing filtresi gerekir. Örneğin 2 kHz örnekleme, aşağıdaki örnekte kullanılan 300–800 Hz bandını incelemeye uygundur; bu bant her makine için evrensel değildir.

İki saniyelik pencerelerde üç özellik çıkaralım: RMS, basıklık ve bant enerjisi oranı. RMS genel titreşim seviyesini özetler:

Basıklık, darbe karakterine duyarlıdır. Bant enerjisi oranı ise seçilen frekans bölgesinin toplam güç içindeki payını gösterir. Öncesinde sinyal ortalamasını çıkararak sabit bileşeni azaltırız.

Python ile küçük bir erken uyarı motoru

Aşağıdaki kod, tek eksenli ivme penceresinden özellik çıkarır. Sağlıklı çalışma pencerelerinden hazırlanmış referans matrisiyle karşılaştırarak bir anomali puanı üretir. Her referans satırı aynı üç özelliği içermelidir.

import numpy as np
from scipy.signal import welch
from scipy.stats import kurtosis


def ozellikler(ivme, fs=2000):
    a = np.asarray(ivme, dtype=float)
    a = a - a.mean()
    f, p = welch(a, fs=fs, nperseg=min(len(a), 1024))
    bant = (f >= 300) & (f <= 800)
    return np.array([
        np.sqrt(np.mean(a ** 2)),
        kurtosis(a, fisher=False),
        p[bant].sum() / (p.sum() + 1e-12)
    ])


def alarm_puani(ivme, referans, fs=2000):
    ref = np.asarray(referans, dtype=float)
    medyan = np.median(ref, axis=0)
    mad = np.median(np.abs(ref - medyan), axis=0)
    z = (ozellikler(ivme, fs) - medyan) / (1.4826 * mad + 1e-6)
    return float(np.maximum(z, 0).max())

Medyan ve MAD, uç değerlerin referansı bozmasını azaltır. Puan yalnızca referansın üzerindeki sapmaları toplar; arıza olasılığı değildir. Sabit veya geçersiz sensör verileri ayrıca filtrelenmeli, çok küçük MAD değerleri için özellik bazında ölçek tabanları belirlenmelidir.

Veriyi değil, anlamını gönderelim

Sensör verisi önce yerel işlemcide özetlenebilir. Özellikler, tambur hızı, program aşaması ve zaman damgasıyla MQTT üzerinden TLS kullanılarak sunucuya iletilir. Cihaz kimlik doğrulaması ve erişim yetkileri de şarttır.

Bağlantı kesilirse yerel tampon kullanılabilir. Böylece internetin molası, izleme sisteminin hafızasını silmez.

Alarmdan gerçek tahmine geçiş

Referansları program, yük ve hız koşullarına göre ayırmak gerekir. Tek bir yüksek puan yerine birkaç karşılaştırılabilir pencerede kalıcı artış aranmalıdır. Eşikler gerçek saha verisiyle ayarlanır; yanlış alarm oranı ve bakım öncesi uyarı süresi birlikte ölçülür.

Gerçek kestirimci bakım için zaman içindeki eğilimler, servis kayıtları ve doğrulanmış arıza etiketleri gerekir. Bakım sonrası titreşimin normale dönmesi de değerli geri bildirimdir. Yalnızca titreşimden “rulman üç gün sonra bozulacak” demek güvenilir değildir. Başarılı sistem, gerektiğinde “alışılmadık bir değişim var, kontrol ettirelim” diyendir. Banyonun yeni dansçısını erken fark etmek bile iyi bir başlangıçtır!

Bir karakter düşünün: Karnı aç, uykusu var, ama komşusuyla dedikodu yapmayı da bırakamıyor. Simülasyon oyunlarını eğlenceli kılan tam olarak bu küçük çelişkilerdir. The Sims benzeri oyunlarda karakterler, yalnızca hazır animasyonlar oynatan kuklalar değildir; ihtiyaçları, çevresel fırsatları ve karar kuralları sayesinde yaşayan bir mahalle izlenimi yaratırlar.

``

Yapay yaşam: Bilinç değil, etkileşim

Yapay yaşam, canlı sistemlerin bazı özelliklerini hesaplamalı modellerle yeniden üretmeyi amaçlar. Oyunlarda bunun karşılığı; ihtiyaçları değişen, çevresini algılayan ve eylemlerinin sonuçlarından etkilenen ajanlardır. Buradaki ajan, kendi durumunu taşıyan bir karakterdir.

İnandırıcılık için insan zihnini bütünüyle simüle etmek gerekmez. Basit kuralların birleşmesiyle ortaya çıkan davranışlar üretilebilir: Aynı buzdolabına yönelen iki karakterden biri bekler, diğeri sohbet eder. Küçük bir kaynak çatışması, oyuncunun gözünde komik bir hikâyeye dönüşür.

Aşağıdaki model, bu yaklaşımı öğretmek içindir; The Sims’in gerçek kaynak kodunun birebir açıklaması değildir.

İhtiyaçları sayılara çevirmek

Her ihtiyacı $n_i$ ile gösterelim. Değerler sıfır ile bir arasında olsun: Sıfır, ihtiyaç karşılanmış; bir, ciddi eksiklik demektir. Böylece açlık ve enerji eksikliği aynı ölçekte karşılaştırılabilir.

Basit bir zaman güncellemesi şöyle yazılır:

Burada $h$ geçen süre, $r_i$ ise saniye başına artış hızıdır. Eylem tamamlandığında ilgili eksiklik azaltılır ve değer sıfırın altına düşmeyecek şekilde sınırlandırılır. Gerçek projelerde uyku gibi uzun eylemlerin etkisini tamamlanma anında değil, zaman boyunca uygulamak daha doğal sonuç verir.

Karar vermek: En faydalı eylem hangisi?

Utility AI, uygulanabilir eylemlere fayda puanı vererek seçim yapar. Basit bir puanlama kullanabiliriz:

$w_i$ ihtiyacın önemini, $d_i(a)$ eylemin sağlayacağı azalmayı, $T(a)$ süresini temsil eder. Minimum işlemi, zaten karşılanmış bir ihtiyaca gereğinden fazla fayda yazılmasını önler. Süre cezası ise uzak mutfağa yürümek gibi maliyetleri hesaba katabilir.

Python ile küçük bir karar motoru

Aşağıdaki örnek, önceden uygulanabilir olduğu belirlenmiş eylemler arasından seçim yapar. Karakterin mevcut eylemini değiştirmek için küçük bir avantaj eşiği kullanır:

from dataclasses import dataclass

@dataclass
class Action:
    name: str
    relief: dict[str, float]
    seconds: float

weights = {"hunger": 1.4, "energy": 1.2, "social": 0.8}
needs = {"hunger": 0.8, "energy": 0.5, "social": 0.3}

actions = [
    Action("yemek", {"hunger": 0.6}, 8),
    Action("uyumak", {"energy": 0.7}, 30),
    Action("sohbet", {"social": 0.5}, 12),
]

def score(action):
    benefit = sum(
        weights[key] * needs[key] * min(needs[key], relief)
        for key, relief in action.relief.items()
    )
    return benefit - 0.002 * action.seconds

def choose(available, current_name=None):
    if not available:
        return None
    best = max(available, key=score)
    current = next(
        (a for a in available if a.name == current_name), None
    )
    if current and score(best) < score(current) + 0.05:
        return current
    return best

print(choose(actions).name)

Action, eylemin etkisini ve süresini taşır. score, ihtiyaçlarla faydayı eşleştirir; choose ise en yüksek puanı seçer. Örnekte yemek kazanır. Eşik sayesinde karakter, puanlar birbirine yakınken sürekli fikir değiştirmez. Bu teknik histerezis olarak bilinir. Yine de mevcut eylem geçersizleşirse korunmaz; karar motoru başka bir seçenek arar.

Mahalleye hayat veren ayrıntılar

Puanlama tek başına yeterli değildir. Eylem adayları üretilirken nesnenin erişilebilirliği, kullanım kapasitesi ve yol bulma sonucu kontrol edilmelidir. Tuvaleti iki karakter aynı anda kullanmaya çalışıyorsa bir rezervasyon sistemi gerekir; yoksa dijital eviniz trafik kazasına döner.

Kişilik, ağırlıkları değiştirerek davranış çeşitliliği sağlar. Dışa dönük bir karakter sosyalliğe daha çok önem verebilir. İlişkiler, sohbetin beklenen faydasını; ruh hâli, eylem tercihlerini etkileyebilir. Bunlar rastgelelikten daha tutarlı farklılıklar üretir.

Son olarak aç kalma süresi, eylem değiştirme sıklığı ve nesne önündeki kuyrukları ölçün. Zaman adımını değiştirince davranışlar bozuluyorsa modeli yeniden ayarlayın. Başarılı yapay yaşam, en karmaşık algoritma değil; oyuncunun anlamlandırabildiği, tutarlı ama şaşırtıcı küçük hikâyeler üreten sistemdir.

Bir domatesin yolculuğu, market rafında başlamaz. Tarlada hasat edilir, paketlenir, kamyona yüklenir ve sonunda sofranıza ulaşır. Peki ambalajdaki “yerel üretim” iddiasını nasıl doğrulayabilirsiniz? Blok zincir, bu yolculuğun kayıtlarını farklı işletmeler arasında paylaşmayı ve sonradan yapılan değişiklikleri fark etmeyi sağlayabilir. Domatese dijital pasaport çıkarmaya hazır mısınız?

``

Temel Mantık: Birbirine Bağlanan Kayıtlar

İzlenebilirlik, bir ürünün kim tarafından, nerede ve ne zaman işlendiğini takip edebilmektir. Klasik sistemlerde kayıtlar çoğunlukla ayrı veritabanlarında tutulur. Çiftçinin defteriyle lojistik firmasının tablosu uyuşmadığında, gerçeği bulmak dedektiflik işine dönüşebilir.

Blok zincirde işlemler, ortak kurallarla doğrulanan bir deftere eklenir. Bloklar önceki blokların kriptografik özetlerine bağlanır. Basitleştirilmiş bir olay zincirini şöyle düşünebiliriz:

Burada $E_i$ yeni olay, $H$ özet fonksiyonu, $h_i$ yeni özettir. $\Vert$ verilerin birleştirilmesini gösterir. Eski kayıtta küçük bir değişiklik bile özeti değiştirir. Ancak güvenlik yalnızca bu matematikten gelmez: dijital imzalar, doğrulayıcılar ve uzlaşma mekanizması da gerekir.

Önce Ürünü Değil, Partiyi Tanımlayın

Her domatese ayrı kimlik vermek genellikle pahalıdır. Bunun yerine aynı hasattan gelen ürünler bir parti numarasıyla izlenebilir: DOM-2026-042 gibi.

Her olay; parti kimliği, aşama, zaman, işletme kimliği, miktar ve konum referansı taşımalıdır. Parti bölünürse yeni alt partiler oluşturulur; karıştırılırsa kaynak partiler açıkça ilişkilendirilir. Yoksa dijital pasaport, yolculuğun yarısında hafızasını kaybeder!

Miktar kontrolü de önemlidir. Basit bir denge için $Q_g = Q_c + Q_f + Q_k$ kullanılabilir: giren miktar; çıkan ürün, fire ve kalan stok toplamına eşit olmalıdır. Böylece 120 kilogram domatesten sihirli biçimde 180 kilogram ürün çıkması işaretlenir.

Küçük Bir Kod Deneyi

Aşağıdaki Node.js örneği, bir olayın önceki özete bağlanmasını gösterir. Bu, çalışan bir blok zincir değil; kayıt bağlantısının öğretici bir modelidir.

import { createHash } from "node:crypto";

const stages = new Set([
  "hasat", "paketleme", "sevkiyat", "teslim"
]);

function makeRecord(previousHash, event) {
  if (!stages.has(event.stage)) {
    throw new Error("Geçersiz aşama");
  }
  if (!(event.quantityKg > 0)) {
    throw new Error("Miktar pozitif olmalı");
  }

  const payload = JSON.stringify([
    event.batchId, event.stage, event.time,
    event.actorId, event.quantityKg
  ]);
  const hash = createHash("sha256")
    .update(previousHash + payload)
    .digest("hex");

  return { previousHash, payload, hash };
}

const harvest = makeRecord("0".repeat(64), {
  batchId: "DOM-2026-042", stage: "hasat",
  time: "2026-10-06T08:00:00Z",
  actorId: "ciftci-17", quantityKg: 120
});
console.log(harvest.hash);

Sabit alan sırası, aynı verinin aynı özeti üretmesine yardımcı olur. Sonraki olayda previousHash olarak harvest.hash kullanılır. Gerçek uygulamada şema doğrulaması, yetkilendirme ve imza kontrolü eklenmelidir. Tek kişinin yönettiği bu örnek zincir baştan hesaplanabilir; onu ortak uzlaşmayla korunan ağla karıştırmayın.

Değiştirilemezlik, Doğruluk Demek Değildir

Sensör yanlış ölçüyorsa blok zincir yanlış sıcaklığı sadakatle saklar. Buna fiziksel dünya ile dijital kayıt arasındaki güven problemi diyebiliriz. Kalibrasyon, mühürlü ambalaj, denetim ve güvenilir veri girişleri hâlâ gereklidir.

“Değiştirilemez” ifadesi de koşulludur: geçmişin değiştirilmesi ağın güvenlik varsayımları altında zorlaştırılır. Hatalı kayıt silinmek yerine, önceki olaya referans veren düzeltme işlemiyle tamamlanır.

Pilot Projeyi Nasıl Kurarsınız?

Bir üretici, paketleme tesisi ve marketle başlayın. Belgeleri ve ayrıntılı sensör verilerini erişim kontrollü depoda tutun; zincire özetlerini ve gerekli referansları yazın. Özet, belgenin değiştiğini gösterebilir ama belgenin erişilebilirliğini garanti etmez.

Ambalajdaki QR kod, tüketiciyi izlenebilirlik ekranına götürsün. Ticari sırları herkese açmadan köken ve aşamaları gösterin. Başarıyı işlem sayısıyla değil; geri çağırma süresi, kayıt eksikliği ve doğrulama maliyetiyle ölçün. Amaç domatesi teknolojiyle süslemek değil, sorun çıktığında doğru partiyi hızla bulmaktır.

Sabah mutfakta başlayan hareketlilik, öğleden sonra salona taşınan sakinlik… Evlerin de kendine özgü bir ritmi vardır. Hareket sensörleri, bu ritimdeki beklenmedik değişiklikleri görünür kılabilir. Ama amaç eve dijital bir Sherlock yerleştirmek değil; yaşlı veya yalnız yaşayan bireylerin bağımsızlığını korurken, gerektiğinde iletişim kurulmasını destekleyen, mahremiyete saygılı bir yardımcı geliştirmektir. ``

Sensör gerçekten neyi bilir?

Yaygın PIR sensörleri, görüş alanlarındaki kızılötesi değişimlerden hareket çıkarır. Birinin kim olduğunu, ne yaptığını veya sağlık durumunu doğrudan söylemezler. Dolayısıyla “hareket yok” ile “kişi tehlikede” aynı anlama gelmez: Uyku, dışarı çıkma, kitap okuma veya bağlantı arızası benzer kayıtlar oluşturabilir.

Temel veri akışı şöyledir: Sensör olayı, zaman damgası ve oda bilgisi yerel bir ağ geçidine ulaşır; ardından analiz için özetlenir. Saatlerin eşitlenmesi ve yinelenen kayıtların temizlenmesi önemlidir. Olay kaydı göndermeyen cihazın çalıştığını anlayabilmek için ayrıca düzenli durum mesajları gerekir. Aksi hâlde arızalı sensör, sessiz bir ev gibi görünür.

Ham olaylardan anlamlı özelliklere

Sensörün yeniden tetikleme süresi, olay sayısını etkiler. Bu nedenle yalnızca tetikleme sayısını karşılaştırmak yanıltıcıdır. Daha dengeli bir özellik, otuz dakikalık pencerede hareket görülen farklı dakikaların sayısıdır. Bütün odaların kayıtları birleştirilir; aynı dakika iki odada hareket varsa toplamda bir kez sayılır.

İlk üç veya dört hafta, kişinin kendi referansını oluşturmak için kullanılabilir. Hafta içi ve hafta sonu ayrı değerlendirilmelidir. Karşılaştırma başka insanların ortalamasıyla değil, aynı kişinin benzer zaman dilimlerindeki geçmişiyle yapılır.

Normalden uzaklığı ölçmek

Başlangıç için karmaşık bir sinir ağı şart değildir. Medyan, sıra dışı günlerden ortalamaya göre daha az etkilenir. Yayılımı ölçen medyan mutlak sapma ise $MAD = \operatorname{medyan}(\vert x_i-m\vert )$ şeklinde hesaplanır; burada $m$, geçmiş değerlerin medyanıdır.

Azalan etkinlik için kullanılabilecek sağlamlaştırılmış skor:

Burada $x_t$, güncel penceredeki hareketli dakika sayısıdır. Paydadaki 1, bir dakikalık alt sınırdır; geçmiş değerler aynı olduğunda sıfıra bölmeyi önler. Büyük pozitif skor, beklenenden düşük etkinlik gösterir. Örneğin medyan 18, MAD 3 ve güncel değer 2 olduğunda skor yaklaşık 3,6 olur. Ancak 3 gibi bir eşik yalnızca başlangıç tercihidir; klinik olarak doğrulanmış bir sınır değildir.

Python ile aday sapmaları çıkaralım

Aşağıdaki kod, geçmiş özetlerden profil oluşturur ve güncel pencereleri karşılaştırır. dilim, gün içindeki otuz dakikalık zaman aralığını temsil eder. Güncel kayıtların geçmiş eğitim verisine katılmaması önemlidir.

import pandas as pd

anahtar = ['gun_tipi', 'dilim']
grup = gecmis.groupby(anahtar)['aktif_dakika']

profil = grup.agg(merkez='median', ornek='count')
profil['mad'] = grup.apply(
    lambda s: (s - s.median()).abs().median()
)
profil['olcek'] = (1.4826 * profil['mad']).clip(lower=1)

sonuc = guncel.merge(
    profil.reset_index(),
    on=anahtar,
    how='left',
    validate='many_to_one'
)
sonuc['puan'] = (
    sonuc['merkez'] - sonuc['aktif_dakika']
) / sonuc['olcek']

sonuc['aday'] = (
    (sonuc['puan'] > 3)
    & (sonuc['ornek'] >= 6)
    & sonuc['sensorler_cevrimici']
    & sonuc['evde_olmasi_bekleniyor']
)

gecmis ve guncel, önceden hazırlanmış DataFrame tablolarıdır. Çıktı acil durum kararı değil, inceleme adayıdır. Evde bulunma beklentisi, yalnızca hareket yokluğundan çıkarılmamalı; kişinin belirttiği program gibi izinli bağlamlarla desteklenmelidir.

Alarm değil, kontrollü iletişim

Tek pencere yerine ardışık pencerelerdeki sapmalar değerlendirilebilir. Ancak beklemek acil durumları geciktirebileceğinden, bu sistem tıbbi alarmın yerine geçmez. Bildirim politikası kişiyle birlikte belirlenmeli; önce nazik bir kontrol mesajı, gerekiyorsa yetkilendirilmiş yakına bildirim düşünülmelidir.

Başarıyı yalnızca doğrulukla ölçmeyin. Haftalık yanlış bildirim sayısı, tespit gecikmesi ve gözden kaçan olaylar da izlenmelidir. Tatiller veya kalıcı rutin değişiklikleri sonrasında profil kontrollü biçimde güncellenmelidir.

Son olarak, açık rıza, bildirimleri durdurabilme, sınırlı saklama süresi ve erişim kontrolü tasarımın temelidir. Mümkünse ham verileri evde tutup yalnızca gerekli özetleri paylaşın. İyi sistem, her sessizliği felaket sayan değil; belirsizliğini kabul edip insan iletişimini destekleyen sistemdir.

``

Rastgelelik neden işe yarıyor?

Monte Carlo’nun temel fikri, hesaplanması zor bir dağılımı çok sayıda örnekle yaklaşık olarak keşfetmektir. Her senaryo, seçtiğimiz modelin ürettiği olası bir gelecektir. Senaryoların sonunda portföy değerlerini sıralayarak kayıpların ne kadar büyük olabileceğini inceleriz.

Buradaki kritik ayrım şudur: Rastgele sayı üretmek, doğru piyasa modeli kurmakla aynı şey değildir. Yanlış varsayımlardan üretilen milyonlarca senaryo, yalnızca yanlışlığı daha hassas hesaplar.

Basit bir başlangıç modeli geometrik Brown hareketidir. Bu modelde gelecekteki fiyat şöyle yazılır:

Burada $S_0$ başlangıç fiyatı, $\mu$ yıllık beklenen getiri parametresi, $\sigma$ yıllık volatilite, $T$ ise yıl cinsinden süredir. Normal dağılımlı değişken fiyatın kendisini değil, logaritmik getirisini etkiler; böylece fiyatlar pozitif kalır.

Bu yaklaşım anlaşılırdır, ancak sabit volatilite ve normal logaritmik getiriler gibi güçlü varsayımlar taşır. Gerçek piyasalardaki sıçramaları ve kalın kuyrukları eksik temsil edebilir.

İki varlıkla küçük bir risk laboratuvarı

Bir milyon liralık portföyün yüzde 60’ını birinci, yüzde 40’ını ikinci varlığa ayıralım. Ufkumuz on işlem günü olsun. İki varlık tamamen bağımsız hareket etmediği için korelasyonu da modele eklemeliyiz.

Aşağıdaki NumPy kodu, Cholesky ayrıştırmasıyla ilişkili normal örnekler üretir. Ardından her senaryoda dönem sonu portföy değerini ve kaybı hesaplar:

import numpy as np

rng = np.random.default_rng(42)
n = 100_000
T = 10 / 252
initial = 1_000_000
weights = np.array([0.60, 0.40])
mu = np.array([0.08, 0.10])
sigma = np.array([0.20, 0.30])
corr = np.array([[1.0, 0.4], [0.4, 1.0]])

chol = np.linalg.cholesky(corr)
z = rng.standard_normal((n, 2)) @ chol.T

multipliers = np.exp(
    (mu - 0.5 * sigma**2) * T
    + sigma * np.sqrt(T) * z
)
terminal_values = initial * (multipliers @ weights)
losses = initial - terminal_values

var99 = np.quantile(losses, 0.99)
es99 = losses[losses >= var99].mean()

print(f"%99 VaR: {var99:,.0f} TL")
print(f"%99 ES: {es99:,.0f} TL")

Sabit tohum, sonuçların tekrar üretilebilmesini sağlar. Cholesky dönüşümü, bağımsız çekilişleri hedef korelasyona sahip şoklara dönüştürür. Kullanılan korelasyon matrisinin pozitif tanımlı olması gerekir.

Kod, başlangıçta alınan varlıkların elde tutulduğunu varsayar; günlük yeniden dengeleme yapmaz. Ayrıca bütün fiyat yollarını değil, doğrudan dönem sonunu örnekler. Bu model altında dönem sonu riski için yeterlidir; bariyer opsiyonları veya dönem içindeki maksimum kayıp gibi yola bağlı ölçüler için zaman adımları gerekir. Parametreler örnektir; yatırım önerisi değildir.

VaR ve ES bize ne söylüyor?

Kaybı $L=V_0-V_T$ olarak tanımlıyoruz. Pozitif değer zarar, negatif değer kazanç demektir. Yüzde 99 VaR, kayıp dağılımının yüzde 99’luk kantilidir:

Örneğin VaR 80 bin lira çıkarsa, modeldeki on günlük kayıpların yaklaşık yüzde 99’u bu eşiği aşmaz. Bu, kalan yüzde 1’de ne olacağını söylemez ve gerçek dünyaya verilmiş bir garanti değildir.

Kodda ES, eşik üzerindeki kayıpların ortalamasıdır. Bu sürekli dağılım örneğinde, felaket mahallesinin ortalama faturasını gösterir.

Simülasyonu gerçekçilikle terbiye etmek

Volatiliteyi geçmiş verilerden tahmin ederken veri sıklığını ve yıllıklaştırmayı tutarlı seçin. Buradaki $\mu$, gerçek dünya risk analizi içindir; opsiyon fiyatlamasındaki risksiz faiz parametresiyle otomatik olarak değiştirilmemelidir.

Korelasyonların krizlerde yükselebileceğini ayrıca sınayın. Volatiliteyi ikiye katlayıp korelasyonu 0.95 yaparak sonuçları karşılaştırmak, modelin hassasiyetini gösteren basit bir stres denemesidir; krizi eksiksiz temsil etmez.

Senaryo sayısını artırmak örnekleme hatasını azaltır. Düzenli koşullarda standart hatalar kabaca $1/\sqrt{N}$ ölçeğinde küçülür; fakat model hatası ortadan kalkmaz. Farklı tohumlarla tekrarlama, kuyruk örnek sayısını kontrol etme ve geçmiş gerçekleşmelerle geriye dönük sınama bu yüzden önemlidir.

Monte Carlo geleceği bilmez. Daha faydalı bir iş yapar: Varsayımlarınızın hangi geleceklerde canınızı yakabileceğini gösterir. Risk yönetimi de tam burada, güzel görünen ortalamaların arkasındaki tatsız sürprizleri sorgulayarak başlar.

``

Altın çoğalınca neden herkes zenginleşmez?

Paranın değeri, yalnızca sahip olduğunuz miktardan değil, onunla satın alabildiğiniz şeylerden gelir. Oyuncuların cüzdanları büyürken ticarete konu olan ürünlerin miktarı aynı hızda artmıyorsa fiyatlar üzerinde yükseliş baskısı oluşabilir.

Bu ilişkiyi düşünmek için klasik miktar denklemi yararlıdır:

Burada $M$ para miktarı, $V$ paranın dolaşım hızı, $P$ fiyat düzeyi ve $Y$ işlem gören reel mal ve hizmet hacmidir. Denklem tek başına bir tahmin makinesi değildir. Oyuncular altını biriktirirse dolaşım yavaşlayabilir; üretim artarsa fiyat baskısı hafifleyebilir. Ayrıca yalnızca nadir bir kılıcın pahalanması, genel enflasyon anlamına gelmez.

Gerçek ekonomiyle akrabalık ilişkisi

Benzetmenin sınırı önemlidir: Gerçek hayatta vergilendirilen para yeniden harcanabilir. Oyunda ise bir onarım ücreti gerçekten siliniyorsa para arzını azaltır. Geliştirici ayrıca bir eşyanın bulunma ihtimalini tek satırla değiştirebilir; gerçek ekonomide bakır madenine böyle bir yama gönderemezsiniz.

Kaynaklar ve giderler: Musluk ile lavabo

Ekonomi tasarımında para yaratan mekanizmalara kaynak, parayı dolaşımdan kaldıran mekanizmalara gider denir. Basit bilanço şöyledir:

$F_t$ dönemde yaratılan, $S_t$ ise silinen paradır. Oyuncular arasındaki normal alışveriş parayı yok etmez; yalnızca sahibini değiştirir. Pazar komisyonu ancak sistem tarafından siliniyorsa gider sayılır.

Denge, her gün kaynaklarla giderleri eşitlemek değildir. Oyuncu sayısı ve üretim büyürken daha fazla para gerekebilir. Buna karşılık sınırsız tekrarlanabilen görevler, botlarla birleşince ekonomiye yangın hortumuyla altın püskürtebilir.

İyi giderler oyuncuya değer sunar: kozmetik seçenekler, isteğe bağlı hizmetler veya anlamlı üretim maliyetleri. Sürekli yükselen zorunlu onarım ücretleri ise ekonomiyi düzeltirken eğlenceyi bozabilir. Lavaboyu açmak için oyuncunun evini su altında bırakmayın.

Python ile küçük bir erken uyarı sistemi

Aşağıdaki örnek, sabit bir referans sepetindeki piyasa fiyatlarını karşılaştırır. Ağırlıklar başlangıç dönemindeki harcama paylarını temsil eder. Fiyat artışı ve pozitif net para üretimi birlikte görülürse inceleme için küçük bir ödül ayarlaması önerilir.

BASE = {
    "iksir": (10, 0.40),
    "demir": (20, 0.35),
    "ekmek": (5, 0.25),
}


def economic_signal(prices, net_flow):
    if any(prices[item] <= 0 for item in BASE):
        raise ValueError("Fiyatlar pozitif olmalı")

    index = sum(
        weight * prices[item] / baseline
        for item, (baseline, weight) in BASE.items()
    )
    multiplier = 0.97 if index > 1.08 and net_flow > 0 else 1.0
    return {"index": round(index, 3), "reward_multiplier": multiplier}


prices = {"iksir": 12, "demir": 22, "ekmek": 5}
print(economic_signal(prices, net_flow=5000))

Sonuçtaki 1.115, referans sepete göre yüzde 11,5 fiyat artışıdır. Önerilen 0.97, ödüllerde yüzde üç azaltma anlamına gelir. Ancak yüzde sekizlik eşik örnektir; bu kod otomatik merkez bankası değil, gösterge panelinin başlangıcıdır. Gerçek uygulamada eksik veri kontrolü ve yeterli işlem hacmi de gerekir.

Dengeyi ölç, oyuncuyu unutma

Tek günlük fiyatlara tepki vermek yerine haftalık eğilimleri, işlem hacmini ve manipülasyona dayanıklı fiyat istatistiklerini izleyin. Yeni başlayanlarla deneyimli oyuncuları ayrı değerlendirin: Ortalama servet artarken yeni oyuncunun ilk ekipmanına ulaşma süresi uzayabilir.

Birden fazla para birimi varsa her birinin kaynaklarını, giderlerini ve dönüşüm yollarını takip edin. Açıkları kapatmak çoğu zaman herkesten daha fazla ücret almaktan daha etkilidir. Değişiklikleri küçük uygulayın, sonuçlarını karşılaştırın ve gerekçelerini açıklayın.

Başarılı oyun ekonomisi, fiyatların sonsuza kadar sabit kaldığı ekonomi değildir. Oyuncunun emeğinin anlamlı kaldığı, ticaretin canlı olduğu ve yeni gelenlerin yarışa katılabildiği ekonomidir. Sonuçta amaç kusursuz bir hesap tablosu değil, yarın da giriş yapmak isteyeceğiniz bir dünyadır.

``

Önce modelin sınırlarını çizelim

Dikey uçan, rüzgârdan etkilenmeyen ve yön değiştirmeyen bir roket düşünelim. Durum değişkenlerimiz yükseklik $h$, dikey hız $v$ ve toplam kütle $m$ olsun. Pozitif yön yukarıdır; başlangıçta roket yerde ve hareketsizdir. Yakıt dışında kütle kaybı olmadığını varsayıyoruz. Bu basitleştirmeler gerçek uçuşun bütün ayrıntılarını kapsamaz, ancak temel fiziği görünür kılar.

Yakıt, itki ve hareket denklemleri

Motorun saniyede tükettiği yakıt miktarına $q$, etkin egzoz hızına $v_e$ diyelim. Motor çalışırken:

Buradaki $v_e$, egzozun rokete göre hızını ve seçilen modeldeki basınç katkısını temsil eden etkin değerdir. Sabit $q$ ve $v_e$ altında itki sabittir; fakat roket hafiflediği için aynı itkinin ürettiği ivme büyür. Gaz pedalını sabit tutup aracın yükünü azaltmak gibi!

Hareket denklemleri ise şöyledir:

$v\vert v\vert $ ifadesi önemlidir: Sürükleme yükselirken aşağı, düşerken yukarı yönelir. Değişken kütleli sistemde egzozun momentum etkisi zaten itkinin içindedir; ayrıca bir $v\,dm/dt$ terimi eklemek bu etkiyi yanlış biçimde tekrar sayar.

Atmosfer ve yerçekimi için basit ama kullanışlı iki yaklaşım seçebiliriz:

Burada $H$ atmosferin ölçek yüksekliği, $R$ Dünya yarıçapıdır. $C_D$ sürükleme katsayısı, $A$ ise referans kesit alanıdır. Gerçekte $C_D$ hızla değişebilir; şimdilik sabit kabul ediyoruz.

Neden sayısal entegrasyon?

Bu denklemler birbirine bağlıdır: Yükseklik yoğunluğu, yoğunluk sürüklemeyi, sürükleme de hızı değiştirir. Genel durumda tek bir kapalı formül aramak yerine zaman boyunca küçük ilerlemeler hesaplarız. Ancak küçük adım seçmek tek başına doğruluk garantisi değildir; yöntemin mertebesi ve hata kontrolü de belirleyicidir.

Python ile iki aşamalı uçuş

Aşağıdaki örnek önce yanmayı, sonra motorsuz uçuşu çözer. Sabit tüketimde yanma süresi $(m_0-m_d)/q$ olduğundan aşamaları tam bu noktada ayırırız. Böylece motor kapanışındaki süreksizliği çözücüye açıkça bildiririz.

import numpy as np
from scipy.integrate import solve_ivp

m0, md = 500.0, 300.0  # kg: toplam ve kuru kütle
q, ve = 4.0, 2200.0    # kg/s ve m/s
Cd, A = 0.4, 0.3
rho0, H = 1.225, 8500.0
R, g0 = 6.371e6, 9.81
burn_time = (m0 - md) / q

def dynamics(t, y, burning):
    h, v, m = y
    rho = rho0 * np.exp(-h / H)
    gravity = g0 * (R / (R + h)) ** 2
    drag = 0.5 * rho * Cd * A * v * abs(v)
    thrust = q * ve if burning else 0.0
    dm = -q if burning else 0.0
    return [v, (thrust - drag) / m - gravity, dm]

def ground(t, y):
    return y[0]

ground.terminal = True
ground.direction = -1
options = dict(rtol=1e-7, atol=[1e-3, 1e-4, 1e-6],
               max_step=1.0)

powered = solve_ivp(
    lambda t, y: dynamics(t, y, True),
    (0, burn_time), [0.0, 0.0, m0], **options
)
if not powered.success:
    raise RuntimeError(powered.message)

state = powered.y[:, -1].copy()
state[2] = md  # Yuvarlama farkını gider.
coast = solve_ivp(
    lambda t, y: dynamics(t, y, False),
    (burn_time, 600.0), state, events=ground, **options
)
if not coast.success:
    raise RuntimeError(coast.message)
if coast.t_events[0].size:
    print('Yere dönüş zamanı:', coast.t_events[0][0])
else:
    print('600 saniye içinde yere dönüş gerçekleşmedi.')

ground olayı, yüksekliğin azalarak sıfırı geçmesini yakalar ve çözümü durdurur. Bileşenlere ayrı mutlak toleranslar vermemizin nedeni yükseklik, hız ve kütlenin farklı birimlere sahip olmasıdır. Seçilen başlangıç itkisinin ağırlıktan büyük olması da kalkışı mümkün kılar.

Sonuçlara güvenmeden önce

Sürükleme ve yerçekimini kaldırarak çözümü roket denklemiyle karşılaştırın:

Ardından toleransları sıkılaştırıp sonuçların yakınsadığını kontrol edin. Kütlenin kuru kütlenin altına inmediğini doğrulayın. Bu model eğitim içindir; gerçek uçuş analizinde atmosfer verileri, değişken itki, yönelim ve yapısal sınırlar da gerekir. Roket bilimi zor olabilir, ama ilk sağlam adım doğru denklemdir!