Çevrim dışı programın doğrulanması

Kanca

Aşağıdaki programı çalıştırmadan önce dur ve tahminini söyle: hedef erişilebilir mi, basarili hangi değeri yazdıracak? Sonra çalıştır. Çevrim dışı doğrulama, bu iki adımın — önce tahmin, sonra kontrol — disipline edilmiş halinden ibarettir.

Ne oldu

Çevrim dışı programlama (offline programming, OLP), bir robot programını gerçek donanımı meşgul etmeden, bir bilgisayarda (genelde bir simülasyon üzerinde) hazırlama yöntemidir — 2012 tarihli bir derleme makalenin sınıflandırdığı endüstriyel robot programlama yöntemlerinden biri, teach pendant ile "çevrim içi" (online) elle öğretmenin karşıtı. OLP'nin asıl değeri sadece "kod yazmak" değil, o kodu ÇALIŞTIRMADAN ÖNCE DOĞRULAMAKTIR:

• Hedef konum robotun erişim alanı (workspace) içinde mi?
• Yörünge bir engele veya robotun kendi gövdesine çarpıyor mu?
• Program, üretim hattını gerçekten durdurmadan önce beklenen sonucu veriyor mu?

Yukarıdaki CodeRunner sahnesinde robot.hedefe_git(x, y) çağrısı tam bu doğrulamayı model alıyor: fonksiyon, hedefe analitik ters kinematikle ulaşmayı DENER ve başarısızsa False döner — gerçek robota hiçbir komut gitmeden, hedefin erişilemez olduğunu ÖNCEDEN öğrenirsin. Yukarıdaki kodda hedefi (1.2, 0.6) değiştirip robotun erişim sınırlarının (bkz. generic-2dof için toplam kol uzunluğu 1.8, minimum erişim 0.2) dışına çıkardığında hedefe_git False döndürecek — bu, gerçek donanıma gönderilmeden yakalanan bir hata.

Gerçek dünyada

Bu platformun reference-python/ klasöründeki backend/api/main.py dosyasındaki POST /plan uç noktası da aynı ilkeyi izliyor: bir yol, robota hiç gönderilmeden önce is_collision_free ile doğrulanıp PLANLANIYOR, sonra sonuç (başarılı/başarısız, yol uzunluğu, düğüm sayısı) API üzerinden dönüyor. Endüstride ticari OLP yazılımları da (robot üreticilerinin kendi simülasyon araçları dahil) aynı adımı izler: program önce sanal ortamda çalıştırılır, erişilebilirlik ve çarpışma kontrolü geçerse gerçek kontrolöre aktarılır. g-universite-sim-to-real-farki dersinde gördüğün gibi, simülasyonda geçen bir doğrulama gerçek donanımda HALA ekstra bir kontrol (yavaş hızda ilk deneme, "dry run") gerektirir — OLP riski azaltır, sıfırlamaz.

Dene

Yukarıdaki kodda hedef koordinatlarını değiştirerek robotun erişim alanının içinde ve dışında birer nokta dene. hedefe_gitin True döndüğü durumda eklem açılarının robotu görsel olarak nereye götürdüğüne, False döndüğü durumda ise hedefe_gitin eklem açılarını hiç değiştirmediğine (robot bir önceki eklem_ac duruşunda kaldığına) dikkat et — bu ikinci durum, gerçek bir robotta ASLA gerçekleşmemesi gereken bir komuttur ve simülasyon onu ÜCRETSİZ yakalamış oldu.

Kaynak kodu: inverseKinematicsAnalytical2Dof, create_plan

Sonraki

Hat G burada tamamlanıyor: URDF ile bir robotu tanımladın, PyBullet ile onu fiziksel bir sahneye yerleştirdin, dijital ikiz ile simülasyonun sınırlarını gördün, sim-to-real farkı ile bu sınırların nereden geldiğini öğrendin, ve son olarak bir programı gerçek donanıma göndermeden önce nasıl doğruladığını gördün. Hat D'deki (robot programlama dilleri) dersler, bu doğrulanmış programın gerçek bir robot kontrolöründe (RAPID, KRL, ROS 2) nasıl ifade edildiğini ele alıyor.