Yavaş (30Hz) bir sistemle hızlı (200Hz) gerçek zamanlı bir sistemi nasıl kontrol edebilirim?

Şu anda, birden fazla kontrollü serbestlik ve sensör derecesine sahip bir mobil robot + monte kol tasarlıyoruz.

İki bölümden oluşan bir mimari düşünüyorum:

1. Kol motorlarını ve enkoderleri kontrol etmek için bir dizi gerçek zamanlı kontrolör (Xenomai gibi bir RTOS çalıştıran Raspeberry Pis veya çıplak metal mikrodenetleyiciler). Bu makinelere mikro denetleyicilerin sayısına bağlı olarak x = 1,2,3… ile RTx diyelim. Bu kontrol döngüsü 200Hz'de çalışacaktır.

2. SLAM, mocap ve yüksek seviyeli mantığı çalıştırmak için ROS çalıştıran güçlü bir vanilya linux makinesi (robotun görevine karar verin ve motorların istenen konumunu ve hızını hesaplayın). Bu kontrol döngüsü 30Hz'de çalışacaktır.

Çerçevemin daha fazla motor, daha fazla sensör, daha fazla PC (örneğin harici mocap için) hesaba katmak için ölçeklenebilir olması gerektiğini biliyorum.

Benim asıl sorun farklı RTx PC1 ile iletişim kurmak karar vermek. Robot mimarisiyle ilgili makalelere baktım (örneğin HRP2 ), çoğu zaman üst düzey kontrol mimarisini tanımlarlar, ancak henüz düşük seviyenin yüksek seviyeyle ve ölçeklenebilir bir şekilde nasıl iletişim kuracağı hakkında bilgi bulamadım. Bir şey mi kaçırdım?

Motor kontrolünü sağlayan hızlı RT makinelerini PC1 ile bağlamak için TCP / IP, CAN ve UART'ı düşündüm:

• TCP / IP: deterministik değil, yerleştirilmesi kolaydır. Determinizm gerçek bir mesele midir (sadece 30Hz'de düşük hızda kullanılacağı için)?
• CAN: Yavaş, çok güvenilir, arabalara yönelik (robotlarla CAN kullanan bazı örnekler var, ancak egzotik görünüyordu)
• UART: Motor kontrolü için sadece bir RT makinem olsaydı, UART'ı düşünürdüm ama sanırım bu port birçok RTx ile iyi ölçeklenmiyor TCP / IP, deterministik olmayan özellikleri nedeniyle gerçekten bir sorun değil mi? Kullanımı çok kolay…

Şu anda hiçbir çözüm benim için gerçekten açık görünmüyor. Belirli bir güvenilir ve ölçeklenebilir çözüm kullanarak ciddi bir robot örneği bulamadığım için, seçim yapmaktan kendimi emin değilim.

Bu noktaya veya literatüre işaret edecek herhangi bir kimse var mı? Robotlarda kullanılan tipik veya genel iletişim çözümleri var mı?

Bence iyi bir ilk adım attınız; problemi mobil bir platforma (konum belirsizliği olan ve hareket etmesi gereken) ve kola (gerçek zamanlı olarak kodlayıcılar aracılığıyla gerçek bir pozisyon kesinliği olan) böldünüz.

Robot mimarisiyle ilgili makalelere baktım [...] ancak henüz düşük seviyenin yüksek seviyeyle ve ölçeklenebilir bir şekilde nasıl iletişim kurabileceği hakkında bilgi bulamadım. Bir şey mi kaçırdım?

Açıklamanızdan, her RTx denetleyicisini doğrudan ROS çalıştıran PC1'e bağlamaya çalıştığınız anlaşılıyor. Kaçırdığınız şey, ROS'un farklı hızlarda veri üretebilecek ve tüketebilecek bir grup uygulamayı ele alacak şekilde tasarlanmasıdır .

Uygulamanızın ihtiyacı olan bir iletişim köprüsüdür - 200Hz döngünüz ile ROS ortamınız arasındaki tek bir arayüz. Diğer bir deyişle, yerine PC1 her RTx denetleyicisi bağlama bölgesinin hep birlikte RTx kontrolörleri bağlayıp bağlanmak bu PC1 için.

Örneğin , RTx sistemlerini birbirine bağlamak için bir I2C Bus kullanın ve "Arm Master" (AM) olarak başka bir RTx kontrol cihazı ekleyin. AM'nin görevi bazı PC1 dostu format ve protokollerde gelen komutları kabul etmek ve bu komutları I2C mesajlarına dönüştürmektir. Ardından, AM'ye komut göndermek için bir ROS uygulaması yazarsınız.

I2C ile yapmanın başka bir yolu, I2C kontrol cihazını doğrudan PC1'e koymak ve tüm kol kontrol mantığını bir ROS uygulamasına yazmak olacaktır. Bu, hedefinize ulaşmak için daha akıcı bir yol gibi görünebilir, ancak sistemin modülerliğini kaldırdığınızda hata ayıklamayı daha zor hale getirebilir - bu sorunu kolayca test edilebilir iki bileşen yerine büyük bir karmaşık sistem olarak gidermeniz gerekir.

Çok sayıda iletişim düğümünün gerekli olduğu herhangi bir uygulamanın (sensörler veya aktüatörler) kablolama karmaşıklığı, determinizm ve sistem karmaşıklığı nedeniyle bir sistem veriyolu olarak (UART veya Ethernet gibi noktadan noktaya bağlantıların aksine) uygulanmasından fayda sağlayacağını söyleyebilirim. modülerlik.

Herhangi bir kontrol sistemi, yüksek bant genişliği kanallarının (Ethernet gibi) genellikle zayıf olduğu yüksek derecede bir determinizm gerektirir (özellikle büyük miktarda programlama titremesi getiren genel amaçlı bir işletim sistemi ile kullanıldığında, determinizmin programlanması hakkında bir tartışma için aşağıdaki bağlantıya bakın . ). Uygulama işlemcileri (Raspberry Pi'nin ARM11'i gibi) muhtemelen gerçek zamanlı sistemlere de zayıf bir uyum sağlar (kesme gecikmesi ve talimat borusu astarı gibi etkiler nedeniyle). Bir ARM uygulama çekirdeği ile bir mikro denetleyicinin gerçek zamanlı davranışını karşılaştıran aşağıdaki digikey tartışmasına bakın .

Entegre CAN'ın kullanılabilirliği UART (RS-485) veya I2C (henüz) kadar yaygın değil, çünkü dağıtılmış algılama ve çalıştırma problemini gerçekten basitleştirdiğini düşünüyorum. Ve her zamanki 1 Mbps yavaş gibi görünse de, tüm veri yolu üyelerinin yenileme hızları hesaplandıktan sonra genellikle fazlasıyla yeterlidir (ve veri yolu uzunluğuna, empedansına ve alıcı vericilerin buna izin verip vermemesine bağlı olarak iletim hızı her zaman artırılabilir). Temel olarak en kötü durum yanıt sürelerini garanti eden parlak simülasyon yazılımı da mevcuttur (örneğin, RealTime-at-work-RTaW-Sim adlı ücretsiz bir CAN veriyolu analizörüne sahiptir). Ve son olarak, entegre CAN ile MEMS sensörlerinin kullanılabilirliği oldukça zayıf görünüyor.

Aktüatörlerin bir veri yolu (veya halka) olarak yapılandırıldığı bir başka örnek, her motorun bir UART bağlantısı aracılığıyla bir sonrakine zincirleme bağlandığı Dynamixels AX ve MX serisidir. Çok sayıda aktüatörünüz varsa bu, sistem tasarımını büyük ölçüde basitleştirir.

Ancak, asıl soruya geri dönmek için, sisteminizi komutlar yerine gerçek zamanlı ayar noktaları olarak tanımlarsanız (örneğin, goto açısı gibi bir komut vermek yerine motor açısını sürekli olarak yayınlarsanız), 200 Hz ve 30 Hz döngü.

Bir kerede çözmeye çalıştığınız 2 ayrı (ancak ilgili) sorununuz var gibi görünüyor. Bilmenizi daha küçük parçalara ayıralım:

1. Nasıl mı iletişim hızlı kontrolörü (200Hz) yavaş bir sistemde (30Hz) komutları ve nasıl veri benim 30Hz adlı düşünce için 200Hz arka alınan iletişim kuruyorlar?
2. Robota yalnızca 30Hz'de ne yapacağını söyleyebildiğimde 200Hz'de neler olduğunu nasıl kontrol edebilirim?

Öğe 1, orijinal sorunuzun işaret ettiği gibi donanımda çözülebilir - verileri 200Hz'de sıralayabilir ve paketi 30Hz'de daha yüksek düzey sisteminize gönderebilirsiniz. Bunu ne kadar veri göndermek istediğinize bağlı olarak TCP / IP veya muhtemelen CAN ile yapabilirsiniz. Farklı donanımların farklı maksimum veri hızları vardır. Diğer yayınlarda önerildiği gibi iletişim köprüsü / hakem olarak işlev görmesi için ROS gibi bir mimari düzeyi eklemek de yardımcı olabilir.

Madde 2, yalnızca donanım ile çözülemeyen bir kontrol teorisi problemidir. İstediğiniz SLAM, konum ve hız saptamaları ve görev saptamanın, daha az bilgi gönderip aldıkları için daha akıllı olması gerekir. Muhtemelen 2 kontrol döngüsü isteyeceksiniz : 1 200Hz'de ve 1 30Hz'de.

İleri besleme, geri besleme ve PID kontrol döngülerini kapsayan başka birçok soru var, ancak özellikle ölçeklenebilirliği sordunuz - çoğu dev sistemin ölçeğinin, kontrol döngülerini ve mantığı katmanlayarak , gerekli minimum bilgi hangi donanımda olursa olsun ile sonuçlanırsın. Örneğin, en üst seviye kontrol cihazınız hızı sadece saniyede 30 kez değiştiremez, sadece en alt seviyeye sadece hedef pozisyon puanları ve ortalama bir hedef hız verebilir.