Bu çalışma, fiziksel bir endüstriyel robot ile onun sanal karşılığını milisaniye ölçeğinde birlikte izleyebilmek ve farklı hareket planlama algoritmalarının simülasyonda değil gerçek donanım üzerinde nasıl davrandığını ölçebilmek için geliştirilen bir gerçek zamanlı robotik dijital ikiz ve Hardware-in-the-Loop (HIL) doğrulama çerçevesini inceliyor. Dijital ikiz, bu çalışmada yalnız robotun üç boyutlu bir simülasyonu değil; fiziksel UR10e robotundan gelen konum, yönelim, hız, eklem eforu, kuvvet ve tork verilerini sanal modelle zaman açısından eşleştiren ve davranış farklarını ölçülebilir hale getiren bir fiziksel-sanal doğrulama sistemidir. Araştırmada ROS 2, Apache Kafka, Elasticsearch, MariaDB, Gazebo, MoveIt 2, OMPL ve Functional Mock-up Unit (FMU) bileşenleri aynı veri zincirinde birleştirilmiştir.

Deneysel sistem, altı döner eklemli Universal Robots UR10e manipülatörünün Festo doğrusal eksen üzerine yerleştirilmesiyle oluşturulan 7 serbestlik dereceli bir robotik yapıyı kullanmaktadır. Robot dört bölmeli dar bir otobüs şasisi demonstratörü çevresinde hareket etmiş; 11 farklı OMPL planlayıcısı 10'ar kez çalıştırılmış ve toplam 110 fiziksel yürütme gerçekleştirilmiştir. Sistem 50 Hz hızında veri toplamış ve çalışma genelinde 785.192 senkronize ölçüm kullanılmıştır. Veri hattındaki eklem-temelli gecikmeler 0,09–15,51 ms aralığında ölçülmüş, böylece çalışmanın tanımladığı 20 ms'lik 50 Hz gerçek zaman sınırı içinde fiziksel ve sanal sistemin birlikte izlenebildiği gösterilmiştir.

Sonuçların en önemli yönlerinden biri, robotun bir komutu doğru takip etmesi ile simülasyon ve gerçek dünyanın aynı geometrik yolu üretmesinin aynı problem olmadığını göstermesidir. Fiziksel robotun TCP izleme hatası çoğu deneyde yaklaşık 2–4 mm düzeyinde kalırken, RRTstar için simülasyon ve gerçek dünya yolları arasındaki planlama düzeyi fark bir noktada 457,65 mm'ye ulaşmıştır. Çalışma bu makroskopik farkı topolojik sapma olarak yorumlamaktadır: gerçek nokta bulutundaki gürültü, kaynak dikişleri, yüzey düzensizlikleri ve algılayıcı örtülmeleri, örnekleme tabanlı planlayıcının simülasyondakinden tamamen farklı bir engel çevresinden geçmesine neden olabilmektedir. Dolayısıyla yüzlerce milimetrelik fark, robot motorlarının yüzlerce milimetre hata yaptığı anlamına gelmemektedir.

Bir robot dijital ikizi neden yalnızca bir simülasyon değildir?

Bu çalışmadaki dijital ikiz, fiziksel robot ve sanal model arasında sürekli veri alışverişi, ortak zaman referansı, fiziksel ölçüm doğrulaması ve davranış karşılaştırması kurduğu için klasik çevrimdışı simülasyondan ayrılır. Gazebo modeli fiziksel sistemin sanal karşılığıdır; ROS 2, RTDE ve Kafka ise fiziksel ölçümlerin bu sanal katmanla gerçek zamanlı ilişkilendirilmesini sağlar.

Fiziksel deney düzeneği

Deneyin merkezinde bir Universal Robots UR10e işbirlikçi robot bulunmaktadır. UR10e'nin altı döner eklemine ek olarak robot, Festo CMMT servo sürücülü bir doğrusal eksen üzerine monte edilmiştir. Böylece fiziksel çalışma alanı genişletilmiş ve sistem etkin olarak 7 serbestlik dereceli bir kinematik zincire dönüştürülmüştür.

Robotun çevresini algılamak için SICK Visionary T-Mini derinlik kamerası kullanılmıştır. Kameradan üretilen nokta bulutları, hareket planlayıcılarının karşılaştığı gerçek çevresel engel geometrisini temsil etmektedir. Fiziksel otobüs şasisinin, doğrusal eksenin ve diğer bileşenlerin konumları OptiTrack hareket yakalama sistemiyle milimetre ölçeğinde ölçülmüş; geometri Autodesk Fusion 360 içinde modellenerek Gazebo'ya URDF yapısı üzerinden aktarılmıştır.

Hesaplama altyapısı Ubuntu 22.04 LTS çalışan, Intel Core i9-14900 işlemci, NVIDIA RTX 4000 Ada GPU ve 64 GB RAM içeren bir iş istasyonunda kurulmuştur. Robot, doğrusal eksen ve görüntüleme sistemleri özel bir 1000 Mbps Ethernet ağına bağlanmıştır. ROS 2 Humble robot kontrol ve veri edinim katmanını, Gazebo Ignition 6.16.0 dijital ikiz ortamını, Apache Kafka 3.8.1 veri akışını, Elasticsearch 8.19.0 zaman serisi indekslemeyi ve MariaDB ilişkisel depolamayı üstlenmiştir.

Veri hattının dört işlevsel katmanı

Özel olarak geliştirilen double_ros2_kafka_bridge düğümü; /dynamic_joint_states, kuvvet-tork sensörü, TCP pozu ve diğer ROS 2 başlıklarını dinleyerek mesajları JSON'a dönüştürür ve Kafka'ya gönderir. ROS 2 tarafındaki yüksek frekanslı sensör başlıklarında Sensor_Data ve Best_Effort QoS profilleri, Kafka üreticisinde ise gecikmeyi azaltmak için linger.ms = 0 gibi ayarlar kullanılmıştır.

Robot verileri 50 Hz'de toplandığı için iki örnek arasındaki teorik zaman aralığı 20 ms'dir. Çalışmada “gerçek zamanlı” sınır bu 20 ms çevrim üzerinden tanımlanmıştır. Buradaki önemli ayrım, veri kaydının 50 Hz'de yapılmasına karşılık bazı yol uzunluğu hesaplamalarının daha sonra çevrimdışı olarak 0,5 saniyelik zaman pencerelerine indirgenmesidir. Bu çevrimdışı downsampling işlemi canlı veri hattının 50 Hz çözünürlüğünü değiştirmemektedir.

Hareket görevi neden zorlayıcıdır?

Deney senaryosu dört ana bölmeden oluşan dar bir otobüs şasisi çevresinde kurulmuştur. Robotun uç efektörü şasinin sağ ve sol taraflarında düşey taramalar gerçekleştirmiş, bölmeler içinde tam 360 derece yönelim hareketleri yapmıştır. Böyle bir ortam, yalnız başlangıç ve hedef noktası arasında yol bulmayı değil, dar geçitlerden çarpışmadan geçmeyi ve robotun fiziksel dinamik sınırlarını korumayı gerektirir.

Karşılaştırılan 11 OMPL planlayıcısı

Araştırmada KPIECE, EST, LBKPIECE, SBL, RRTConnect, BKPIECE, PRMstar, RRT, TRRT, RRTstar ve PRM kullanılmıştır. Planlayıcılar aynı başlangıç ve hedef koşullarında çalıştırılmış, fakat sabit bir rastgele sayı tohumu kullanılmamıştır. Böylece örnekleme tabanlı algoritmaların gerçek stokastik davranışı korunmuştur.

Tüm planlayıcılarda MoveIt 2 OMPL arayüzü ve AddTimeOptimalParameterization kullanılmıştır. Çarpışma kontrol çözünürlüğü longest_valid_segment_fraction = 0.005 olarak belirlenmiştir. Maksimum hız ve ivme ölçekleri fiziksel robot için 0,05, simülasyon için 0,1'dir. KDL kinematik çözücüsünün zaman aşımı 0,005 s; hedef konum toleransı 0,001 m ve hedef yönelim toleransı 0,001 rad'dır. Her planlayıcıya 5 saniyelik planlama süresi verilmiştir. Bu koşullarda 11 algoritmanın tamamı 10 denemenin 10'unu tamamlamış ve toplam 110 başarılı fiziksel yürütme elde edilmiştir.

Fiziksel robot hareketi ile dünya koordinatları nasıl eşleştirildi?

TCP ve doğrusal eksen farklı ROS başlıklarından ve farklı frekanslarda geldiği için yol uzunluğunu doğrudan ham örneklerden toplamak yüksek frekanslı jitter nedeniyle mesafeyi yapay olarak büyütebilir. Bu nedenle yol uzunluğu hesabının çevrimdışı aşamasında 0,5 s'lik zaman kutuları kullanılmıştır:

\[ t_{\mathrm{bin}}= \left\lfloor \frac{t_{\mathrm{raw}}}{\Delta t} \right\rfloor \Delta t \qquad \Delta t=0.5\,\mathrm{s} \]

Burada \(t_{\mathrm{raw}}\) ham sensör zaman damgasını, \(t_{\mathrm{bin}}\) aynı zaman penceresine indirgenmiş zaman damgasını gösterir. TCP ve doğrusal eksen kayıtları daha sonra en yakın zaman komşusu yöntemiyle birleştirilmiştir.

UR10e doğrusal ray üzerinde hareket ettiği için robot tabanına göre ölçülen TCP koordinatının sabit dünya koordinatına dönüştürülmesi gerekir:

\[ \begin{bmatrix} x_{\mathrm{world}}\\ y_{\mathrm{world}}\\ z_{\mathrm{world}} \end{bmatrix} = \begin{bmatrix} x_{\mathrm{base}}\\ y_{\mathrm{base}}\\ z_{\mathrm{base}} \end{bmatrix} + \begin{bmatrix} \delta_x\\ \delta_y+d_{\mathrm{rail}}(t)\\ \delta_z \end{bmatrix} \]

Kaynakta montaj ofsetleri \(\delta_x=-0.158\,\mathrm{m}\), \(\delta_y=0.115\,\mathrm{m}\) ve \(\delta_z=0.586\,\mathrm{m}\) olarak verilmektedir. \(d_{\mathrm{rail}}(t)\), doğrusal eksenin ilgili andaki konumudur.

Dünya koordinatlarına dönüştürülmüş ardışık TCP noktaları arasındaki Öklid mesafeleri toplanarak toplam Kartezyen yol uzunluğu hesaplanmıştır:

\[ L=\sum_{i=1}^{N-1} \sqrt{ (x_{i+1}-x_i)^2+ (y_{i+1}-y_i)^2+ (z_{i+1}-z_i)^2 } \]

Bu denklem, robotun eklem uzayındaki hareket miktarını değil, uç efektörün sabit dünya koordinat sisteminde kat ettiği üç boyutlu geometrik mesafeyi verir.

Veri seti ne içeriyor?

Çalışma, konum, yönelim, eklem hızları, eklem eforları, TCP kuvvet ve torkları, GPIO/araç sıcaklığı gibi meta veriler, gerçek ve simülasyon yörüngeleri ile çevresel nokta bulutlarını bir araya getirmektedir. Ham dinamik veriler 50 Hz'de kaydedilmiş, deney tekrarları yaklaşık 300–360 saniye sürmüştür. Toplam doğrulama havuzu 785.192 senkronize örneğe ulaşmıştır.

Kaynak, sıkıştırılmamış veri seti büyüklüğünü 9,97 GB olarak bildirmektedir. Bunun 3,36 GB'lık kısmı işlenmiş veriler, 6,61 GB'lık kısmı ise yörünge ve ilgili ham kayıtlar olarak açıklanmaktadır. Kaynağın ayrıntılı dizin anlatımı ile özet envanter tablosundaki bazı dosya sayıları birebir uyuşmadığından, dosya adedi konusunda özet tablo ile ayrıntılı dizin listesini tek bir kesin envantermiş gibi birleştirmek doğru değildir.

Çalışmanın Yöntemi ve Bulguları

Topolojik sapma neden robotun takip hatası değildir?

Çünkü robotun gerçek TCP izleme hatası çoğu deneyde birkaç milimetre düzeyindeyken topolojik sapma, simülasyon ve gerçek nokta bulutu üzerinde çalışan stokastik planlayıcının engelin farklı tarafından geçmesi sonucu oluşan makroskopik yol farkıdır. Kaynakta RRTstar için topolojik sapma RMSE'si 88,08 mm, en yüksek noktasal fark ise 457,65 mm olarak verilmiştir.

Fiziksel ve sanal robotun düşük seviyeli eşleşmesi

Fiziksel UR10e ile Gazebo modeli aynı zaman ekseninde karşılaştırıldığında TCP konum farkları çoğu deneyde yaklaşık 2–4 mm aralığında kalmıştır. Eklem konum RMSE değerleri 0,0092 rad ile 0,1089 rad arasında değişmektedir. Bazı bilek eklemlerinde anlık maksimum hatalar 1 rad'ın üzerine çıksa da çalışma bunların kinematik tekillik yakınları veya ani yüksek ivmeli yönelim değişimleri sırasında oluşan kısa süreli geçişler olduğunu belirtmektedir.

Eklem verilerinin çapraz korelasyonu ile hesaplanan ortalama gecikme değerleri 0,09 ms ile 15,51 ms arasındadır. En düşük değer dirsek ekleminde 0,09 ms, en yüksek değer wrist_3 ekleminde 15,51 ms olarak raporlanmıştır.

Hangi OMPL planlayıcısı daha iyidir?

Bu deney tek bir evrensel “en iyi” planlayıcı göstermemektedir; ölçüte göre sonuç değişmektedir. Bu dört bölmeli 7-DOF şasi senaryosunda KPIECE kısa ve düşük varyanslı yollar üretirken EST en düşük ortalama fiziksel yürütme süresini vermiştir. Buna karşılık bazı RRT ve PRM ailesi sonuçları daha uzun veya daha değişken yollar üretmiştir. Bu sıralama farklı robot geometrileri ve çalışma alanları için doğrudan genellenemez.

Tablodaki fiziksel yürütme süresi, robotun yörüngeyi fiziksel olarak tamamlaması için geçen süredir; ilk planlama hesaplama süresi bu değere dahil değildir. KPIECE'nin 0,53 m'lik yol uzunluğu standart sapması, bu deneyde en düşük değişkenliklerden birini göstermektedir. PRM'nin 6,80 m'lik standart sapması ise aynı başlangıç ve hedef koşullarında farklı tekrarlar arasında daha yüksek yol çeşitliliğine işaret etmektedir.

Planlayıcılar arasındaki fark yalnız gözlemsel değildir. On tekrar üzerinden yapılan Kruskal-Wallis H testi, gerçek fiziksel yürütme süresi için \(H=35.90,\ p<0.001\), gerçek yol uzunluğu için \(H=63.62,\ p<0.001\) vermiştir. Dolayısıyla bu özel deney düzeninde algoritmalar arasındaki dağılım farkları istatistiksel olarak anlamlıdır.

Planlama yükü de algoritmaya göre değişiyor

Kaynakta toplam kayıt süresinden fiziksel yürütme süresi çıkarılarak planlama yükü ayrıca değerlendirilmiştir. LBKPIECE için yaklaşık %34,6, BKPIECE için %30,5, PRM için %25,6 ve RRTConnect için %22,8 oranında planlama yükü bildirilmiştir. PRMstar ve RRTstar için tabloda yaklaşık sıfıra yakın dış planlama yükü görülmektedir. Bu değerler, algoritma tasarımının yalnız geometrik yolu değil toplam görev zamanlamasını da etkileyebildiğini göstermektedir.

Robot gerçek dünyada neden simülasyondan daha kısa bir yol yürüyebilir?

İncelenen örneklerden birinde simülasyonda planlanan yol 10.110,4 mm, fiziksel olarak yürütülen yol ise 9.776,3 mm'dir; fark yaklaşık 334 mm'dir. Bunun nedeni fiziksel robotun “daha doğru” bir planlayıcı kullanması değildir. OMPL keskin geometrik waypoint'ler üretirken ROS 2 joint trajectory controller ve UR10e'nin yerel kontrol sistemi waypoint geçişlerinde hız sürekliliğini korumak için spline interpolasyonu ve köşe yumuşatma uygular. Böylece TCP bazı keskin düğümlerin tam üzerinden geçmek yerine köşeyi iç taraftan yuvarlayabilir.

Bu bulgu, simülasyon benchmark'larında yalnız ham planlanan geometriye bakmanın yeterli olmadığını gösterir: fiziksel robot kontrolcüsü de yürütme sırasında ikinci bir hareket şekillendirme katmanı oluşturabilir.

Kuvvet ve tork verileri ne gösterdi?

TCP kuvvet-tork sensörü fiziksel temasın yanında ivmelenme, yavaşlama, uç efektör kütlesi ve yerçekimi telafisi artıklarından kaynaklanan dinamik kuvvetleri de ölçmektedir. Bu nedenle sensör değerinin sıfırdan farklı olması tek başına çarpışma anlamına gelmez.

Çalışmada çevrimdışı hareketli ortalama düşük geçiren filtre uygulanmış ve deneysel değerlendirme için kuvvette 120 N, torkta 5 Nm eşikleri kullanılmıştır. Bu eşikler çalışmanın kendi değerlendirme sınırlarıdır; evrensel robot güvenlik standardı olarak yorumlanmamalıdır. RRT kısa süreli olarak yaklaşık 100,089 N kuvvet tepe değeri üretmiş, PRM'de maksimum tork 3,709 Nm olarak ölçülmüştür. Ölçülen değerler çalışmada kullanılan eşiklerin altında kalmıştır.

TRRT'nin ortalama kuvvet büyüklüğü 5,509 N ile tablodaki en düşük değerlerden biridir; RRTstar'da kuvvet RMS değeri 10,33 N ve standart sapma 5,227 N ile belirgin biçimde daha yüksektir. Bu sonuçlar, geometrik olarak geçerli iki yolun fiziksel robot üzerinde aynı mekanik yükü üretmek zorunda olmadığını ortaya koymaktadır.

Simülasyon-gerçek dünya sapması neden yüzlerce milimetreye çıktı?

RRTstar için 27 hedef konum üzerinden hesaplanan simülasyon-gerçek dünya yörünge farkının RMSE değeri 88,08 mm, en yüksek farkı 457,65 mm'dir. Çalışma bu büyüklüğün zaman senkronizasyonundan veya robot kalibrasyonundan açıklanamayacağını vurgulamaktadır; çünkü aynı deneylerde düşük seviyeli TCP takibi birkaç milimetre düzeyindedir ve iletişim gecikmesi 20 ms çevrim sınırının altındadır.

Asıl neden planlama uzayının değişmesidir. CAD tabanlı simülasyon temiz geometrik yüzeylerle çalışırken gerçek derinlik kamerası kaynak dikişlerini, düzensiz yüzeyleri, sensör gürültüsünü ve örtülmeleri de görür. Stokastik planlayıcı bu yeni engel haritasında bir parçanın simülasyondakinin ters tarafından dolaşmayı seçebilir. Matematiksel olarak iki yol farklı bir homotopi sınıfına geçebilir. Bu nedenle “457,65 mm hata”, robot kolunun hedefinden yarım metre kaçtığı biçiminde okunmamalıdır.

200,66 mm minimum açıklık robotun bütün gövdesinin güvenli olduğunu kanıtlar mı?

Hayır. Kaynakta hesaplanan 200,66 mm değer, fiziksel TCP yörüngesinin filtrelenmiş gerçek nokta bulutundaki en yakın engel noktasına olan minimum mesafesidir. Çalışma gelecekte tüm robot bağlantılarının ve uç efektör hacminin modele eklenmesi gerektiğini açıkça belirtmektedir; dolayısıyla bu değer tam gövde ISO-uyumlu çarpışma garantisi olarak yorumlanmamalıdır.

Anlık TCP konumu \(P_{\mathrm{TCP}}(t)=[x(t),y(t),z(t)]\) ve çevredeki geçerli engel noktaları \(O=\{O_1,O_2,\ldots,O_k\}\) olarak tanımlandığında anlık en yakın engel mesafesi:

\[ d(t)= \min_{O_i\in O} \sqrt{ (x(t)-x_{O_i})^2+ (y(t)-y_{O_i})^2+ (z(t)-z_{O_i})^2 } \]

şeklinde hesaplanmıştır. Hesaplamayı hızlandırmak için KD-Tree araması kullanılmıştır. Tüm yörünge için minimum açıklık ise:

\[ C_{\min}=\min_t d(t) \]

olarak tanımlanmıştır. 171.000'den fazla geçerli fiziksel nokta üzerinde yapılan bu hesaplamada gözlenen minimum TCP açıklığı 200,66 mm'dir.

Gerçek nokta bulutu CAD modeline ne ekledi?

OctoMap tabanlı hacimsel incelemede 0,02 m voxel çözünürlüğü kullanılmıştır. 44 parçalı CAD modelinden oluşturulan başlangıç “belief map” 20.334 yaprak düğüm içerirken gerçek sensör taramaları eklendikten sonra harita 26.590 düğüme çıkmıştır.

İlk HIL turunun 26 sensör taramasından toplam 5.108.938 dünya-koordinatlı nokta elde edilmiştir. Bunların 1.884.392'si, yani %36,9'u şasi sınır hacmi içinde kalmış; 3.224.546 nokta şasi dışı gözlem olarak elenmiştir. 44 CAD parçasının 38'inde en az bir işgal edilmiş voxel saptanmış, yani tek tarama döngüsünde parça bazında %86,4 kapsama elde edilmiştir.

Başlangıçtaki 20.334 düğüm ile sensör verisi sonrasındaki 26.590 düğüm arasındaki 6.256 düğümlük fark; ideal CAD'ın içermediği kaynak dikişleri, iç yüzeyler ve gerçek yüzey düzensizliklerinin sensör tarafından yakalanmasıyla ilişkilendirilmiştir. Bu sonuç dijital ikiz için gerçek sensör verisinin neden yalnız “ek bilgi” değil, doğrudan çarpışma haritasını değiştirebilecek bir veri katmanı olduğunu gösterir.

FMU kinematik doğrulaması

Forward Kinematics FMU, UR10e'nin altı döner eklem açısını \(q_1-q_6\) girdi olarak alarak Denavit-Hartenberg parametrelerinden TCP konumu ve quaternion yönelimini üretmektedir. Burada önemli bir yöntem sınırı vardır: fiziksel sistem 7-DOF olmasına rağmen FMU doğrulaması UR10e'nin altı döner eklemini doğrudan modellemektedir. Doğrusal eksen, dünya koordinat dönüşümünde haricî bir translasyon ofseti olarak ele alınmıştır.

785.192 örnek üzerinde konum RMSE'si planlayıcıya göre 1,847 mm ile 2,081 mm arasında kalmıştır. Yönelim RMSE'si ise 0,129° ile 0,177° arasındadır. Böylece farklı OMPL yörüngelerine rağmen kinematik model hatasının yaklaşık aynı büyüklük düzeyinde kaldığı gösterilmiştir.

X ekseninde yaklaşık +0,886 ile +1,603 mm arasında sistematik pozitif bias gözlenmiştir. Kaynak bunu FMU'nun fiziksel araç TCP ofsetini içermeden robot flanş noktasını hesaplamasına bağlamaktadır. Başka bir deyişle bu, rastgele kinematik bozulmadan çok sabit ve düzeltilebilir bir geometrik ofsettir.

FMU tork modeli nerede zorlanıyor?

Inverse Dynamics FMU sonuçları altı robot ekleminde gerçek effort ölçümleriyle karşılaştırılmıştır. Joint 2 ve Joint 3 en yüksek mutlak tork RMSE değerlerini göstermiştir: sırasıyla ortalama 6,932 Nm ve 3,422 Nm. Joint 1 için ortalama RMSE 0,857 Nm; wrist eklemleri Joint 4, 5 ve 6 için sırasıyla yaklaşık 0,352, 0,352 ve 0,451 Nm'dir.

Bu farkın temel nedeni algoritma seçiminden çok fiziksel modelin yapısıdır. Kaynaktaki FMU ideal rijit cisim dinamiklerini kullanmakta; Coulomb ve viskoz eklem sürtünmesini, bazı Coriolis/merkezcil terimleri ve gerçek mekanizmadaki diğer doğrusal olmayan etkileri tam olarak içermemektedir. Yük taşıyan omuz ve dirsek eklemlerinde bu ihmal daha büyük tork sapmasına dönüşmektedir.

Planlayıcılar üzerinden bütün eklemler birlikte değerlendirildiğinde ortalama RMSE 2,007 Nm ile 2,125 Nm arasında dar bir aralıkta kalmaktadır. Bu durum, tork tahmin hatasının önemli bölümünün planlayıcı kimliğinden ziyade eklem mekaniği ve model varsayımları tarafından belirlendiğini desteklemektedir.

FMU hesaplaması gerçek zaman sınırına sığıyor mu?

Kaynak, tek Forward Kinematics FMU adımının ortalama yaklaşık 2,47 ms, inverse dynamics adımının ise yaklaşık 2,56 ms sürdüğünü bildirmektedir. ROS 2-Kafka bağlantısında ölçülen eklem-temelli iletişim gecikmeleri 0,09–15,51 ms arasındadır. Makale bu mimarinin 50 Hz için tanımlanan 20 ms çevrim sınırını koruduğunu raporlamaktadır.

Bu süreler yorumlanırken FK ve inverse dynamics sürelerinin, maksimum ağ gecikmesiyle her durumda ardışık tek bir kritik yol üzerinde mekanik olarak toplanmaması gerekir; kaynak sistemin çalışma biçimini gerçek zamanlı pipeline bütünü üzerinden doğrulamaktadır. Ayrıca paket kaybı ROS 2-Kafka köprüsünde %0,1'in altında bildirilmiş ve uzun süreli zaman kaymasının NTP sınırları içinde kaldığı belirtilmiştir.

Çalışmanın söylediği ve söylemediği

Çalışma, gerçek robot verisinin dijital ikiz ve hareket planlama benchmark'ına dahil edilmesinin simülasyonun sakladığı önemli farkları görünür hale getirebildiğini göstermektedir. Özellikle temiz CAD ortamındaki bir planlayıcı sonucu ile gürültülü fiziksel nokta bulutundaki yolun geometrik olarak ciddi biçimde ayrışabileceği deneysel olarak ortaya konmuştur.

Bununla birlikte çalışma tek bir kontrollü laboratuvar senaryosuna dayanmaktadır. Ortam titreşimi ve değişken aydınlatma gibi üretim sahası koşulları sistematik olarak sınanmamıştır. Kuvvet-tork incelemesi temas açısından zengin montaj/manipülasyon görevlerini kapsamamaktadır. Mevcut FMU altı UR10e eklemini doğrudan modeller; doğrusal eksenin tam dinamik modeli gelecekteki geliştirmeler arasındadır. Dinamik model sürtünme, Coriolis ve merkezcil etkileri eksiksiz içermemektedir. Ayrıca clearance değerlendirmesi TCP merkezlidir; bütün robot bağlantılarının hacimsel çarpışma analizi henüz gerçekleştirilmemiştir.

Bu nedenle burada görülen KPIECE, EST, RRT, PRM veya diğer planlayıcı davranışları “bu algoritma her robotta daha iyidir” biçiminde genellenemez. Kaynağın kendi verileri, planlayıcı performansının kinematik zincire, engel geometrisine, algılayıcı ortamına ve uygulanan fiziksel kontrol katmanına bağlı olduğunu göstermektedir.

Kaynak ve Yöntem Notu

Özgün başlık: Real-Time Big Data Pipelines for Industrial Robot Digital Twins: An OMPL Benchmarking Framework

Yazarlar: Metin Yılmaz; Cem Suha Yılmaz; Serhat Kahraman; Uğur Yayan.

Corresponding author: Metin Yılmaz.

Kurumlar: Autonomous Systems & Technology for TR-Metin Yılmaz; Eskişehir Osmangazi Üniversitesi Bilgisayar Mühendisliği Bölümü; Eskişehir Osmangazi Üniversitesi Elektrik-Elektronik Mühendisliği Bölümü; DEFTR Tek. Elek. Müh. Dan. Enerji ve Ulus. Tic. Ltd.; Eskişehir Osmangazi Üniversitesi Yazılım Mühendisliği Bölümü.

Dergi: Machines.

Yayınevi: MDPI.

Cilt / sayı / makale: 14 / 6 / 702.

Yayın tarihi: 18 Haziran 2026.

Gönderim / revizyon / kabul: 23 Nisan 2026 / 2 Haziran 2026 / 3 Haziran 2026.

DOI:10.3390/machines14060702

Kaynak türü ve hakemlik: Hakemli bilimsel dergi makalesi; yayımlanmış Version of Record.

Lisans: Creative Commons Attribution (CC BY).

Veri erişimi: Kaynak çalışma veri setini Mendeley Data üzerinde yayımlamaktadır: Mendeley Data — xsnpgfz5mb/3.

Finansman: Çalışma KDT Joint Undertaking Grant Agreement No. 101140216 kapsamında desteklenmiştir. Kaynak ayrıca İsveç Vinnova, Avusturya FFG, Business Finland, İtalya Ministry of Universities and Research, Portekiz FCT ve Türkiye'de TÜBİTAK 124N448 desteğini bildirmektedir.

Çıkar çatışması: Kaynağa göre Metin Yılmaz AST4TR, Serhat Kahraman DEFTR bünyesinde çalışmaktadır. Diğer yazarlar ticari veya finansal çıkar çatışması bildirmemiş; fon sağlayıcıların çalışma tasarımı, veri toplama/analizi, makale yazımı veya yayımlama kararında rolü olmadığı belirtilmiştir.

Yazar katkıları: Kavramsallaştırma M.Y. ve U.Y.; yöntem M.Y. ve C.S.Y.; yazılım M.Y.; doğrulama M.Y., C.S.Y. ve S.K.; biçimsel analiz M.Y. ve C.S.Y.; araştırma M.Y. ve S.K.; kaynaklar U.Y. ve C.S.Y.; veri kürasyonu ve görselleştirme M.Y.; denetim ve proje yönetimi U.Y. tarafından yürütülmüştür. Taslak metin M.Y. tarafından hazırlanmış, inceleme ve düzenleme C.S.Y., S.K. ve U.Y. tarafından yapılmıştır.

Yapay zekâ kullanım bildirimi: Yazarlar Gemini 3.1 Pro, Claude Opus 4.6 ve Claude Sonnet 4.6 modellerini yardımcı Python kodlarının ilk taslakları ve dil düzenlemesi için; ayrıca Grammarly'yi dil düzenlemesinde kullandıklarını açıklamıştır. Kaynağa göre AI araçları çalışmanın kavramsallaştırılması, fiziksel robot deneylerinin yürütülmesi veya temel bilimsel sonuçların türetilmesinde kullanılmamış; üretilen kod insan yazarlar tarafından test edilip doğrulanmıştır.

Temel yöntemsel sınırlar: Kontrollü laboratuvar ortamı; ortam titreşimi ve değişken aydınlatmanın kapsam dışında olması; temas ağırlıklı robot görevlerinin değerlendirilmemesi; FMU'nun doğrusal ekseni tam dinamik 7-DOF model olarak içermemesi; sürtünme ve bazı hız-bağımlı dinamik etkilerin ideal dinamik modelde eksik olması; güvenlik açıklığının bütün robot gövdesi yerine TCP-merkezli nokta bulutu mesafesiyle ölçülmesi.

Kaynak içi editoryal uyarı: Ana yöntem ve sonuç bölümlerindeki 11 planlayıcı listesiyle makalenin Sonuç bölümünde geçen “BiEST” ve “LazyPRM*” adları örtüşmemektedir. Ayrıca sonuç tartışmasındaki bir “Table 4” atfı, içerik bakımından Table 7'deki varyans verilerine işaret ediyor görünmektedir. Veri setinin ayrıntılı dizin anlatımı ile Table 5'teki özet dosya sayıları da tam olarak aynı değildir. Bu Verianla metni bu tutarsızlıkları düzeltip yeni kaynak gerçeği üretmek yerine görünür kılar ve sayısal yorumlarını doğrulanabilen ana yöntem/sonuç tablolarıyla sınırlar.