Çok kısa cevap: 2
Sensörler
Sensörlerden tek bir düğümde mi yoksa ayrı ayrı mı okunduğuna ilişkin olarak, kendinize şu soruyu sormalısınız:
Sensörler diğeri olmadan anlamsız mı?
Bu soru, sensörlerin sıkıca bağlı olup olmadığını sorar. Örneğin, sıcaklığa duyarlı bir sensörünüz olduğunu (ve bunu telafi etmeniz gerektiğini) varsayalım. Öncelikle diğer sensörün değerini sabitlemek için bir sıcaklık sensörü eklersiniz. Bu senaryoda, her iki değeri de aynı anda okumak mantıklıdır, çünkü sıkıca bağlanırlar. Aslında, sıcaklık sensöründen okumalar olmadan, orijinal sensörden okumalar işe yaramaz.
Öte yandan, sensörler bireysel olarak faydalıysa, elbette onları ayrı düğümlerde tutun. Bunun birçok faydası vardır:
- Düğümler ayrı işlemcilerde çalıştırılabilir
- Düğümler gelecekteki robotlarda yeniden kullanılabilir
- Tek bir düğüm ile iletişim kurulamaması tüm sistemi düşürmez
- Hatalı bir sensör kartından alımın yeniden başlatılması, diğerlerinden ayrı olarak yapılabilir
Aslında, yukarıdaki faydalardan herhangi birine ihtiyacınız varsa, sensörler sıkıca bağlı olsa bile ayrı düğümlerle gitmek zorunda kalırsınız, ancak bu genellikle olmaz.
Aktüatörler
Bu benzer.
Aktüatörler diğeri olmadan anlamsız mı?
Örneğin, her tendon için (hangi nedenle olursa olsun) iki motorun bir eklemi bir veya diğer yönde hareket ettirmek için aynı anda çalışmaktan sorumlu olduğu robotik tendonlu bir bilek tasarlıyorsanız , aynı düğümde hizmet vermenin çok daha fazlasını sağladığı ayrıdan daha mantıklı.
Öte yandan, aktüatörlerin bağımsız olduğu durumlarda (yaygın durum), her aktüatör için bir düğüme sahip olmak mantıklıdır. Bu durumda, her biri farklı bir düğüme yerleştirilebilir. Sensörlerle aynı faydaların yanı sıra, bu ek fayda da vardır:
- Bir aktüatör durursa (herhangi bir nedenle), diğer aktüatörler hala çalışır. Gereksiz serbestlik dereceleri varsa, bunu tamamen telafi edebilirler.
Bunun bir anlamı var. Eğer varsa gerek uyum içinde çalışmalarına aktüatörler, daha sonra aynı düğüm koyun. Bu sadece iletişimdeki başarısızlıktan değil, farklı düğümlerin farklı gecikmeler anlamına gelmesinden kaynaklanmaktadır; dağıtılmış bir sistemde her düğüm ağın farklı bir kısmındadır ve bu nedenle gecikmelerdeki fark, merkezi bir sistemde, her işlemin zamanlamadaki şansı nedeniyle yüksek CPU yüklerinde farklı gecikmeler olur .
İşleyici Olmalı mı?
Cevap "duruma bağlı" olmasına rağmen, birçok avantajı olan ortak bir yaklaşım vardır. Adı değiştirelim ve "kontrolör" diyelim. Yaklaşım "evet, bir kontrolör olmalı" dır.
Bir denetleyiciye sahip olmanın avantajları (birçokları arasında):
- Ayrıştırma işlemi: her düğüm bir şeyden sorumludur, yani:
- Basitlik: ima eden
- Daha kolay geliştirme
- Daha kolay hata ayıklama
- Daha az hata
- Daha az başarısız olma şansı
- Yeniden kullanılabilirlik: çünkü aynı işlevsellik, aynı işlevselliğe (örneğin mesaj ve servis formatları) sahip olmaları durumunda farklı sensör düğümleri ile kullanılabilir.
- Ayrı bir donanımda yürütme: her bir düğüm ağda taşınabilir. Örneğin, sensör ve aktüatör düğümleri özel bir mikrodenetleyiciye ( örneğin Arduino (örneğin tavsiye etmiyorum)) ve bir PC'deki denetleyiciye taşınabilir .
- Aşırı çirkinlikten kaçının: sensörler aktüatörleri doğrudan etkilemek isterse sonuç sadece bir karışıklıktır. Kontrolör olmadığını varsayarsak, her duruma bakalım:
- Bir sensör düğümü: temel olarak bu, sensör düğümü ve denetleyicinin aynı düğüme bir araya getirildiği anlamına gelir. Çok kötü değil, ama çok gereksiz.
- Birçok sensör düğümü: bu karışıklık. Bu, kontrolörün sensör düğümleri arasında dağıtıldığı anlamına gelir . Bu nedenle, tüm sensör düğümleri, ilişkili aktüatör (ler) in nasıl kontrol edileceğini bilmek için birbirleriyle konuşmalıdır. İletişimde bir başarısızlık veya çeşitli gecikmeler olduğunu hayal edin, bunun ne kadar zor olduğunu göreceksiniz. Bunun tamamen gereksiz olduğu düşünüldüğünde, bunu yapmak için hiçbir neden yoktur!
Bunlar, dezavantajlar olduğunu söyledi. Daha fazla düğüme sahip olmak (yalnızca denetleyici değil, herhangi bir düğüm) şu anlama gelir:
- Daha fazla israf iletişim: verilerin ağ veya paylaşılan bellek aracılığıyla standart formatlarda (seri hale getirilmiş ve serileştirilmiş) hareket etmesi gerekir, ROS çekirdeği onlara bakmak ve bunları kime teslim edeceğine karar vermek zorundadır. Kısacası, bazı sistem kaynakları boşa harcanır. iletişimde. Birindeki tüm düğümler bu maliyet sıfır olabilirdi.
- Daha yüksek başarısızlık şansı: herhangi bir nedenle bir ağ bağlantısı kesilirse veya bir düğüm ölürse, sistemde bir hata vardır. Eğer buna hazırlıklı değilseniz, tüm sistemi kapatabilir. Şimdi bu aslında sistemin bir kısmını kaybedebilmek için genel olarak iyi bir şey ama hepsini değil ( zarif bozulma ), ancak bunun mümkün olduğunca kaçınılması gereken uygulamalar da var. İletişimi kesmek ve tüm kodları bir düğüme koymak aslında sistem kararlılığına yardımcı olur. Aşağı tarafı elbette, sistem ya iyi çalışıyor ya da aniden tamamen ölüyor.
- Kaotik zamanlamalar: her bir düğüm kendi kendine çalışır. Mesajlarının başkalarına ulaşması için geçen süre belirleyici değildir ve her zamana göre değişir. Düğümleriniz her mesaja zaman damgası basmadıkça (bir yan not olarak: ROS'un iyi bir dereceye kadar senkronize edilmiş saatlere sahip olmanız gerekir) ve her alıcı düğüm gecikmeyi dikkate alıp buna göre kontrol edemezse (bu çok zor bir görevdir) kendi başına), daha sonra birden fazla düğüme sahip olmak, verilerin yaşı hakkında yüksek belirsizlik anlamına gelir. Bu aslında (çoğu arasında) çoğu robotun bu kadar yavaş hareket etmesinin nedenlerinden biridir; kontrol döngüleri, tüm verilerin mevcut döneme karşılık geldiğinden emin olmak için yeterince yavaş olmalıdır. Gecikmeler büyüdükçe kontrol döngüsü yavaşlar.
Yukarıdaki tüm dezavantajlarda, çözüm, düğüm sayısını, tercihen tek bir düğüme azaltmaktır. Bir dakika, artık ROS kullanmıyor! Kesinlikle.
Özetlemek:
- Gecikmelerin zamanla yükselebileceği gerçek zamanlı olmayan sistemler için ROS kullanın. Bu durumda, istediğiniz kadar ROS düğümüne sahip olmaktan çekinmeyin. Aslında, her ROS düğümünün tek bir şey yapması çok iyi bir uygulamadır . Bu şekilde, çok basit hale gelirler ve yeniden kullanılabilir hale gelirler.
- Öte yandan, gerçek zamanlı sistemler için kesinlikle ROS'dan kaçının. Bunun için EtherCAT gibi orocos ve teknolojiler var ve çoğu zaman geçici çözümler.
Son olarak, pratikte ROS iyi durumda. Harika değil, ama iyi. Çoğu zaman sistem kritik değildir ve başarısızlık şansı o kadar küçüktür ki, şimdi ve sonra yeniden başlatma çok önemli değildir. Bu Devekuşu algoritması !
