Quadrotor'u Hedefe Doğru Yönlendirme

Bir quadrotor üzerinde çalışıyorum. Pozisyonunu biliyorum - $a$ , nereye gitmek istiyorum - hedef pozisyon $b$ ve bundan bir vektör hesaplıyorum $c$ - beni hedefime götürecek bir birim vektörü:

c = b - a
c = normalize(c)

Bir quadrotor dönmeden herhangi bir yönde hareket edebileceğinden, yapmaya çalıştığım şey

döndür $c$ robotların sapma açısı
içine böl $x, y$ bileşenler
onları yuvarlanma ve eğim açıları olarak robota geçirin.

Sorun şu ki, sapma 0 ° ± 5 ise, bu işe yarar, ancak sapma +90 veya -90'a yakınsa başarısız olur ve yanlış yönlere yönelir. Sorum şu: Burada bariz bir şeyi mi kaçırıyorum?

quadcopter uav navigation slam kinect computer-vision algorithm c++ ransac mobile-robot arduino microcontroller machine-learning simulator rcservo arduino software wifi c software simulator children multi-agent ros roomba irobot-create slam kalman-filter control wiring routing motion kinect motor electronics power mobile-robot design nxt programming-languages mindstorms algorithm not-exactly-c nxt programming-languages mindstorms not-exactly-c raspberry-pi operating-systems mobile-robot robotic-arm sensors kinect nxt programming-languages mindstorms sensors circuit motion-planning algorithm rrt theory design electronics accelerometer calibration arduino sensors accelerometer

— Hamza
kaynak

Sapma açısını nasıl hesaplıyorsunuz? Ayrıca, hangi denetleyiciyi kullanıyorsunuz ve veriyi nasıl gönderiyorsunuz?

— DaemonMaker

İlginç bir soru @Hamza, hoş geldiniz Robotik .

— Mark Booth

@Hamza, Hangi dili ve sistemi kullanıyorsunuz? Ayrıca Atmega328 ve Ada programlama dili ile bir quadcopter üzerinde çalışıyorum. Proje hakkında bir blogunuz varsa lütfen paylaşın.

@MarkBooth doğru, açık iki sekme vardı ve diğer yazı yinelenen olarak işaretlemek niyetindeydim. Bunu yanlışlıkla işaretledim ve geri almanın bir yolunu görmedim. Kapatmanın birden fazla oy alması göz önüne alındığında, bunun bir sorun olmayacağını düşündüm. Ancak benim adıma bir yorum gönderdi farkında değildi.

— DaemonMaker

Sorun yok @DaemonMaker bu şeyler olur. Yinelenen oylar artık otomatik olarak yorum gönderirken, insanların yakın bir oy vermeden önce diğer soruyu gözden geçirmelerini isteyen yararlı bir özellik olduğunu düşünüyorum.

— Mark Booth

Yanıtlar:

Çözümünüzü yeniden uygulayarak şunu elde ederim:

Vektörler Arası Açı

İlk olarak, noktalar arasındaki açıyı istiyorsunuz $A$ ve $B$ - özellikle birim vektörü değil.

( Fx Programlama ile ): $\theta = math.atan2(B_{x}-A_{x}, B_{y}-A_{y})$

Araç Sapma Açısı

Sonraki (ve bu sorunu olduğunu sanıyorum) yapmanız gerekir çıkarma aracın sapma açısı $\psi$ hesapladığınızdan $\theta$ .

Heading vs Yaw

Aracınızın "yalpa açısı" için bir pusula kullanıyorsanız, bu da sizin hatanız olabilir; yön ve sapma aynı değil . Pusula yönü pozitif boyunca sıfır $y$ ekseni, saat yönünde döndükçe artar :

Pusula gülü

Pozlama boyunca yaw sıfır $x$ saat yönünün tersine döndükçe artan eksen :

Bu ölçümler arasındaki 90 derece üst üste binme, aracın istenen yalpadan sapmasını (çıkarmak yerine) eklemekle birleştiğinde, hedefiniz ± 5 ° içinde olduğunda ve ± 90 ° 'de kötü davrandığında neden olabilir.

X ve Y Bileşenlerine Dönüşüm

Oradan, bu sonucu dönüştürdüğünüzü söylüyorsunuz $(\theta-\psi)$ onun içine $x$ ve $y$ bileşenleri, onları rulo ve eğim açıları olarak robota geçirir. Yukarıdaki düzeltmelerle, bu noktada istenen sonucu almalısınız. Bununla birlikte, bu bileşenleri eğim açılarına doğrudan eşlemek sorunlu olabilir, çünkü aracın hızını (gerçekten, momentumu) değil, sadece konum farkını düşünürsünüz.

PID Kontrolü

En iyi şekilde aracın rulo ve eğimi için PID kontrol döngüleri kullanılarak servis yapılabilir. Yani, kodunuzu düzelttikten ve hedefinize vurabildiğinizde, tahminim bunun yerine onu aşmaya başlayacaksınız - ileri geri salınıyor. Doğru ayarlanmış bir PID, hedefe hızlı bir şekilde yaklaşmanıza izin verirken bunun olmasını önler.

Takmak yerine $x$ ve $y$ yuvarlanma ve eğimde, bunları yuvarlanma ve eğim PID'lerinin girdi olarak kabul ettiği hata değerleri olarak düşünün .

— Ian
kaynak

Bu bazı düzenleme var,% 90'ın üzerinde ve cevabı tamamen değiştiriyor (PID'den ATAN2'ye). Ama gösterişli grafik formül becerileriniz canavardır!

— Spiked3

Hala PID'yi tavsiye ediyorum (altta var), sadece varsayımlarımın doğru olduğundan emin olmak için sorunun başlangıç kısmında çalıştım. Grafik formüller, görülmeye değer Lateks biçimlendirmesinin bir parçasıdır.

— Ian

"pusula yönü pozitif y ekseninden başlar ve saat yönünde artarken sapma pozitif x ekseninden başlar ve saat yönünün tersine artar" referansı? "(θ − ψ) x bileşeni rulo ve y bileşeni adım dönüştürme" Hiç anlamıyorum - daha fazla açıklama lütfen (bir şey eksik).

— Spiked3

Orijinal soru, "[x ve y bileşenlerini] robota dönüş ve eğim açıları olarak geçirmekten" bahsetti. Biraz açıklık getireceğim.

— Ian

düzgün. Hiç böyle yapıldığını görmedim. Aynı sonuçları elde etmek için gördüm ve kendim yapıyorum. Rulo / saha üzerinde biraz daha düşünmem gerekecek. Evet, bu harekete neden olur, ancak bunun, bulunduğunuz yer ve gidişinizle nasıl bir ilgisi olduğundan emin değilim. Teşekkürler.

— Spiked3

Burada bir 3B vektörden bahsettiğinizi varsayalım. Bu şekilde genelleme yapabilir misiniz normalize()? Bu yaygın mı (daha önce hiç görmedim, eğer öyleyse, bana haber). Aksi takdirde, X ve Y bileşenlerinin her biri için belirgin pusula sarma sorunları geçerlidir. Neden onlara yuvarlanma ve / veya eğim ve / veya sapma demiyorsunuz? (3D ve 2D adlandırmaların karıştırılması soruyu karıştırır).

2B normalleştirmem şöyle görünür;

int Pilot_QuickestTurnTo(int hdgNow, int hdgNew)
{
    hdgNow = Pilot_Hdg360(hdgNow);
    hdgNew = Pilot_Hdg360(hdgNew);
    if (hdgNow < hdgNew)
        hdgNow += 360;
    int left = hdgNow - hdgNew;
        return (left < 181 ? -left : 360 - left);
}

Gerçekten bir dörtlü ise, X ve Y bileşenlerinizin gerçekten YAW, Rakım ((X, Y) ve Z) olduğunu varsayıyorum. 2D'yi ele almanız YAW(X, Y)ve Z için düşmeniz veya irtifa almanız gerekecek (ve bu yüzden normalleştirmenin sahip olduğunuzdan daha fazla olduğundan şüpheleniyorum).

— Spiked3
kaynak