Guida di un quadrotore verso un bersaglio

Sto lavorando a un quadrotore. Conosco la sua posizione - , dove vorrei andare - posizione target , e da quel momento calcolo un vettore - un vettore unitario che mi porterà al mio obiettivo: $a$ $b$ $c$

c = b - a
c = normalize(c)

Poiché un quadrotore può muoversi in qualsiasi direzione senza rotazione, quello che ho cercato di fare è

ruotare di dall'angolo di imbardata dei robot $c$
dividerlo nei suoi componenti $x, y$
passali al robot come angoli di rollio e beccheggio.

Il problema è che se l'imbardata è 0 ° ± 5, allora funziona, ma se l'imbardata è vicina a +90 o -90 non riesce e si dirige verso direzioni sbagliate. La mia domanda è: mi sto perdendo qualcosa di ovvio qui?

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
fonte

Come stai calcolando l'angolo di imbardata? Inoltre, quale controller stai utilizzando e come vengono inviati i dati?

— DaemonMaker,

Interessante domanda @Hamza, benvenuto in Robotica .

— Mark Booth

@Hamza, che lingua e quale sistema stai usando? Sto anche lavorando su un quadricottero con il linguaggio di programmazione Atmega328 e Ada. Se hai un blog sul progetto, ti preghiamo di condividere.

Hai ragione @MarkBooth, avevo due schede aperte e intendevo contrassegnare l'altro post come duplicato. Ho segnato questo per errore e non ho visto alcun modo per annullarlo. Dato che ci vuole più di un voto per chiuderlo, ho pensato che non sarebbe stato un problema. Non mi ero reso conto tuttavia che ha pubblicato un commento per mio conto.

— DaemonMaker

Nessun problema @DaemonMaker accadono queste cose. Chiudi come voti duplicati ora pubblica automaticamente commenti, che ritengo sia una funzione utile in quanto spinge le persone a rivedere l'altra domanda prima di esprimere un voto da soli.

— Mark Booth

Risposte:

Riapplicando la tua soluzione, ottengo questo:

Angolo tra i vettori

Innanzitutto, vuoi l'angolo tra i punti $A$ e $B$ , non specificamente il vettore dell'unità.

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

Angolo di imbardata del veicolo

$\psi$ $\theta$

Heading vs Yaw

$y$

La rosa dei Venti

$x$

La sovrapposizione di 90 gradi tra queste misurazioni, combinata con l'aggiunta (invece di sottrarre) l'imbardata del veicolo dall'imbardata desiderata, può essere il motivo per cui le cose hanno funzionato quando il bersaglio era entro ± 5 ° e si sono comportati male a ± 90 °.

Conversione ai componenti X e Y

$(\theta-\psi)$ $x$ $y$

Controllo PID

Si può essere meglio serviti usando circuiti di controllo PID per il rollio e il passo del veicolo. Cioè, una volta risolto il tuo codice e sei in grado di colpire il tuo obiettivo, suppongo che inizierai invece a superarlo, oscillando avanti e indietro. Un PID correttamente regolato eviterà che ciò accada, consentendoti comunque di avvicinarti rapidamente al bersaglio.

$x$ $y$

— Ian
fonte

C'è qualche modifica lì, oltre il 90% e cambia totalmente la risposta (da PID a ATAN2). Ma le tue abilità di formula grafica appariscente sono bestie!

— Spiked3,

Consiglio ancora il PID (è lì in fondo), ho appena esaminato la parte iniziale della domanda per assicurarmi che i miei presupposti fossero corretti. Le formule grafiche fanno parte della formattazione del lattice, che vale la pena provare.

— Ian,

"La direzione della bussola inizia dall'asse y positivo e aumenta in senso orario, mentre l'imbardata inizia dall'asse x positivo e aumenta in senso antiorario" riferimento? "convertire il componente x di (θ − ψ) in roll e il componente y in pitch" Non capisco affatto - più spiegazione per favore (mi manca qualcosa).

— Spiked3,

La domanda originale menzionava "passare [i componenti xey] al robot come angoli di rollio e beccheggio", che per me indica che il quadricoptero si sposta lateralmente cambiando l'angolo di rollio, e avanti e indietro cambiando l'angolo di beccheggio. Aggiungerò un po 'di chiarezza.

— Ian,

pulito. Non l'ho mai visto fare così. Ho visto, e faccio da solo, capovolgere cos / sin per ottenere gli stessi risultati. Dovrò pensare ancora un po 'al tiro / al lancio. Sì, ciò causerebbe movimento, ma non sono sicuro di come ciò abbia a che fare con dove sei e dove stai andando, oltre alla velocità con cui ci arrivi. Grazie.

— Spiked3,

Presumo che tu stia parlando di un vettore 3D qui. Puoi generalizzare normalize()così? È così comune (non l'ho mai visto, quindi se lo è, allora notizie per me). In caso contrario, a tutti i componenti X e Y si applicano evidenti problemi di avvolgimento della bussola. Perché non chiamarli roll and / o pitch e / o yaw? (mescolando la nomenclatura 3D e 2D confonde la domanda).

La mia normalizzazione 2D è simile a questa;

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);
}

Se è davvero un quad, suppongo che i tuoi componenti X e Y siano davvero YAW, Altitudine ((X, Y) e Z). Dovrai gestire il YAW(X, Y)2D e semplicemente scendere o guadagnare altitudine per Z (e di nuovo è per questo che sospetto che la normalizzazione sia più di quanto tu non abbia).

— Spiked3
fonte