Pianificazione traiettoria di un drone

[spud]

Un saluto a tutti.
Ho un ardrone 2.0; per un progetto di meccatronica con il mio gruppo dobbiamo programmarlo per fargli seguire delle traiettorie autonomamente.
Usiamo questo programma che da ubuntu ci permette di leggere dati da dai sensori e dargli comandi programmandolo in javascript, quindi diciamo che dopo non poca fatica questa parte è fatta.

Attualmente siamo in grado di:

• misurare l'altitudine
• misurare la velocità x, y e z
• misurare gli angoli r, p e y
• farlo muovere avanti, indietro, di lato, su e giu e controllarne la velocità da 10 a 100% di quella massima
• misurare altre cose che suppongo non servano per la mia applicazione

Quello che dobbiamo fare ora è la pianificazione di traiettoria.
Ho pensato di fissare uno spazio di lavoro 3d (abbiamo studiato robotica industriale quindi siamo abituati a usare spazi di lavoro fissi), fissare dei punti per i quali deve passare e poi interpolarli. Il punto è come fare a guidarlo, mi spiego meglio, non abbiamo modo di rilevare la sua posizione, possiamo misurare solo quello che ho elencato sopra.
Potrei misurare le velocità x e y ogni intervallo di tempo T e poi tramite integrazione a tempo discreto ricavare lo spazio x e y perocrso, sapendo da dove è partito ricaviamo la sua posizione, e quindi come guidarlo per raggiungere il prossimo punto. Può essere applicabile questo procedimento? Avete mai avuto a che fare con cose del genere?

(saranno cavoli farglielo fare in javascript, in 5 anni di uni per ogni progetto ho dovuto imparare un lingaggio diverso, solo per la tesi ne ho imparati 3 e uno non l'ho neanche usato, meno male che mi piace )

dimaios mi permetto di taggarti

Grazie a tutti

[Candy]

Ho capito poco, però chissà, alle volte le idee semplici...
Fino a qualche secolo fa la longitudine non era rilevabile con gli strumenti a disposizione, quindi, veniva approssimata in funzione della velocità e della rotta.
Non sarà facile, ma se non hai altri riferimenti...

[spud]

L'alternativa era farlo open loop ma se già con la retroazione sarà tutto molto poco preciso ti lascio immaginare cosa potrebbe farmi un po' di arietta..

però chissà, alle volte le idee semplici...

Sarcasmo? Non mi sembra poco semplice, infondo sono somme e prodotti, sarà un casino da implementare questo si.

Fino a qualche secolo fa la longitudine non era rilevabile con gli strumenti a disposizione, quindi, veniva approssimata in funzione della velocità e della rotta

è esattamente quello che voglio fare io, con la differenza che io ho la posizione nell'istante precedente, la velocità nell istante precedente e in quello attuale, tramite il passo di campionamento mi calcolo la posizione nell'istante attuale.
In base a questa posizione do potenza e direzione al drone per fargli raggiundere il punto che vogliamo attraversi, una volta raggiunto il punto si ripeterà l'operazione per il prossimo punto, fin che non si termina la traiettoria.

Tra l'altro ci accontenteremo che ci vada vicino con una traiettoria il più smooth possibile perché troppe vibrazioni lo destabilizzano tanto.

[spud]

Qualcosa del genere: sia il generico passo di campionamento, la posizione e la velocità.

è nota perché all'inizio sarà posizionato in un punto di riferimento nello spazio di lavoro, un punto a caso, l'origine, e anche lo è perché partiamo da fermi.





questo problema poi lo scompongo nelle direzioni x e y perché in queste direzioni posso misurare solo la velocità, mentre per l'asse z ho l'altimetro a ultrasuoni sotto quindi posso misurarla direttamente (anche con una certa precisione credo). Nel codice rimarrebbero da risolvere:





quidi per ogni direzione dovrei salvarmi: posizione e velocità nell'istante precedente, la velocità nell'istante attuale la misuro e la posizione nell'istante attuale la calcolo.

Non so se adesso la mia idea è un po più chiara.

[dimaios]

spud, il problema che provi a risolvere non è banale se vuoi fare le cose per bene.

Ti posso illustrare come procederei se dovessi risolvere il problema.

CONSIDERAZIONE 1

AR Drone 2.0 è dotato dei seguenti sensori :

[1] Accelerometro a 3-assi
[2] Il giroscopio a 3-assi
[3] Il magnetometro a 3-assi
[4] 2 sensori a ultrasuoni per la determinazione dell'altitudine fino a 6 metri
[5] 1 sensore di pressione
[6] 1 Telecamera ad alta risoluzione

Visto che sono presenti li sfrutterei tutti.

CONSIDERAZIONE 2

Il controllo della traiettoria dovrebbe essere fatto onboard e non su una macchina esterna al drone ove potresti generare la traiettoria ideale offline e successivamente scaricarla sulla mainboard del quadrocopter.
Infatti si generano i seguenti problemi :

[1] Non tutti i dati relativi ai sensori potrebbero essere disponibili
[2] La comunicazione potrebbe interrompersi con conseguente perdita dei campioni
[3] La frequenza di refresh dei dati non è paragonabile a quella ottenibile onboard
[4] Il controllore di traiettoria dovrebbe funzionare realtime e non a tempo di campionamento variabile con jitter incontrollato.

CONSIDERAZIONE 3

Per ottenere un risultato degno di nota bisogna impiegare un modello del quadrocopter altrimenti il filtraggio dei segnali derivanti dai sensori potrebbe non essere compatibile con la dinamica del velivolo falsando la predizione della posizione dalle altre grandezze.
Fondamentalmente ti serve assolutamente un osservatore dello stato.
Nel robotic toolbox di Peter Corke c'è già il modello del drone per cui basta ricavarsi le matrici dinamiche inserendo i dati reali del tuo drone.


Per iniziare impiegherei molto i sensori e poco il modello.
Prendi in considerazione la massa del velivolo concentrata nel baricentro e le forze di propulsione applicate alle distanze ove risiedono i baricentri dei rotori ( modello 3D ovviamente ).
Potrebbe essere sufficiente ....
Se non lo è si passa alle "maniere forti" calcolandosi l'intera matrice dinamica!

Prima di tutto comunque ti consiglio di fare la lista di tutti i sensori.
Leggendo i relativi datasheet devi indagare bene riguardo la banda, precisione e ripetibilità delle misure fornite per poter "pesare" opportunamente i segnali in ingresso allo stimatore.

[spud]

Grazie mille per la risposta.

Riguardo alla considerazione 1; la documentazione non è moltissima, mi sono trovato a dover decifrare questo frammento di codice:

Codice: Seleziona tutto

Sample Data for reference:
{ header: 1432778632,
droneState:
{ flying: 0,
videoEnabled: 0,
visionEnabled: 1,
controlAlgorithm: 0,
altitudeControlAlgorithm: 1,
startButtonState: 0,
controlCommandAck: 1,
cameraReady: 1,
travellingEnabled: 0,
usbReady: 0,
navdataDemo: 1,
navdataBootstrap: 0,
motorProblem: 0,
communicationLost: 0,
softwareFault: 0,
lowBattery: 1,
userEmergencyLanding: 0,
timerElapsed: 0,
MagnometerNeedsCalibration: 0,
anglesOutOfRange: 0,
tooMuchWind: 0,
ultrasonicSensorDeaf: 0,
cutoutDetected: 0,
picVersionNumberOk: 1,
atCodecThreadOn: 1,
navdataThreadOn: 1,
videoThreadOn: 1,
acquisitionThreadOn: 1,
controlWatchdogDelay: 0,
adcWatchdogDelay: 0,
comWatchdogProblem: 0,
emergencyLanding: 0 },
sequenceNumber: 4661,
visionFlag: 1,
demo:
{ controlState: 'CTRL_LANDED',
flyState: 'FLYING_OK',
batteryPercentage: 15,
rotation:
{ frontBack: 0.887,
pitch: 0.887,
theta: 0.887,
y: 0.887,
leftRight: -0.072,
roll: -0.072,
phi: -0.072,
x: -0.072,
clockwise: 52.492,
yaw: 52.492,
psi: 52.492,
z: 52.492 },
frontBackDegrees: 0.887,
leftRightDegrees: -0.072,
clockwiseDegrees: 52.492,
altitude: 0,
altitudeMeters: 0,
velocity: { x: 0, y: 0, z: 0 },
xVelocity: 0,
yVelocity: 0,
zVelocity: 0,
frameIndex: 0,
detection: { camera: [Object], tagIndex: 0 },
drone: { camera: [Object] } },
visionDetect:
{ nbDetected: 0,
type: [ 0, 0, 0, 0 ],
xc: [ 0, 0, 0, 0 ],
yc: [ 0, 0, 0, 0 ],
width: [ 0, 0, 0, 0 ],
height: [ 0, 0, 0, 0 ],
dist: [ 0, 0, 0, 0 ],
orientationAngle: [ 0, 0, 0, 0 ],
rotation: [ [Object], [Object], [Object], [Object] ],
translation: [ [Object], [Object], [Object], [Object] ],
cameraSource: [ 0, 0, 0, 0 ] } }
*/

per estrarre i dati che arrivano, la cosa non è ancora molto chiara ma ci combatterò ancora.

Il fatto è che, assumendo per un attimo di dover implementare il mio ragionamento, se dovessi usare le acellerazioni invece delle velocità, dovrei fare una doppia integrazione introducendo ancora più rumore di calcolo.

Per quanto riguarda la considerazione 2; anche a me piacerebbe controllare onboard, specialmente perché mi troverei a programmare in C (casa dolce dasa), ho provato a fare un telnet e un ftp al drone per vedere come è fatto dentro e ci sono riuscito facilmente, ho anche trovato il cross-compiler gcc per il processore che monta (un arm), però questa strada mi preoccupa anche.

La cosa frustrante è che in teoria il kernel è chiuso quindi la documentazione scarseggia.

Ti faccio una domanda, secondo te il controllo è fatto dal sistema operativo? Oppure ha dei moduli 'esterni' che il sistema operativo interpreta? (chiedo perdono lo so che mi esprimo molto male)
Un' altra cosa, il controllo real time non lo so fare, è un qualcosa tipo controllore a isteresi?

Riguardo la considerazione 3; ho due tesi di due ragazzi che si sono occupati di modellare e simulare il drone per cui le matrici di rotazione e le lagrangiane in teoria le ho già pronte.

Concludendo, tu mi dici di farmi prima un modello semplice per avere un idea del comportamento dell'oggetto e poi scrivere un programma che esegue il controllo da caricare direttamente onboard?

[dimaios]

Ti faccio una domanda, secondo te il controllo è fatto dal sistema operativo? Oppure ha dei moduli 'esterni' che il sistema operativo interpreta? (chiedo perdono lo so che mi esprimo molto male)
Un' altra cosa, il controllo real time non lo so fare, è un qualcosa tipo controllore a isteresi?

No. Il drone monta una versione di linux ritagliata ad-hoc mentre il controllo è una applicazione separata.

Un' altra cosa, il controllo real time non lo so fare, è un qualcosa tipo controllore a isteresi?

Controllo realtime significa che esiste una relazione temporale deterministica tra acquisizione elaborazione e set dei riferimenti. Tutti e 3 i task di controllo devono girare con jitter molto limitato rispetto al periodo di campionamento. Inoltre la dinamica del controllore e dell'osservatore devono essere in termini di banda molto più rapidi del processo controllato.

Concludendo, tu mi dici di farmi prima un modello semplice per avere un idea del comportamento dell'oggetto e poi scrivere un programma che esegue il controllo da caricare direttamente onboard?

Sarebbe ottimale.
Prima di fare qualsiasi cosa devi stimare la dinamica del sistema ( banda del processo ) e la velocità con la quale riesci a campionare i dati relativi ai sensori ( sia onboard che sul PC ).
Confrontando questi indicatori capisci cosa puoi e cosa non puoi fare.

[spud]

Va bene grazie mille dimaios.
A questo punto penso sia meglio dividere il lavoro, siccome siamo in quattro, due di noi studiano il modello e altri due fanno le prove sul drone per fare le verifiche che mi hai consigliato.

P.S. Quando vieni a farci un'altra lezione?

[dimaios]

Quando vieni a farci un'altra lezione?

Ah! ..... spud eri forse tra gli studenti del corso di robotica che hanno seguito il mio seminario di automazione industriale ?

[spud]

Sisi sono venuto a mettere la password per accedere al PC da cui hai fatto la presentazione, il drone ci è stato affidado dal prof. Miani.