dsPID33 HW-FW-SW

[guiott]

Orginalmente inviato da gyppe

....
Sono intanto un po spaesato su come funzioni l'accoppiata NavCon + sensboard. In pratica la nav si occupa di raggiungere una coordinata prefissata, dialogare con il pc, e accetta poi segnali dalla sens, ma come?
In pratica in un certo punto posso indicare la presenza di un ostacolo, ma ho visto che tu usi diversi sensori non solo frontali, quindi forse accetta anche l'indicazione della posizione degli ostacoli?

Guarda la tabella in fondo a questa pagina:
http://www.guiott.com/Rino/SensorBoa...dSoftware.html

la sensor board trasmette in maniera autonoma le informazioni sulla distanza degli oggetti sui tre lati (Dist[x]) e dei dati sui target rilevati.
La distanza degli ostacoli è il risultato di un elaborazione tra IR e US che fa l'Arduino. Le distanze dai target sono previste per un robot explorer ma non ancora implementate su Rino.

I dati ricevuti sono poi integrati con la posizione attuale del robot e la posizione assoluta degli ostacoli è memorizzata in una matrice.

[ribellion]

ho anch'io una domanda riguardante il firmware che si può aggiungere alle faq...

Se io l'encoder l'ho connesso direttamente alla ruota invece che all'albero motore ottengo solo 500 cpr per ogni giro di ruota " il valore di count dell'encoder" di conseguenza devo dichiarare slow encoder?

[guiott]

Orginalmente inviato da ribellion

ho anch'io una domanda riguardante il firmware che si può aggiungere alle faq...

Se io l'encoder l'ho connesso direttamente alla ruota invece che all'albero motore ottengo solo 500 cpr per ogni giro di ruota " il valore di count dell'encoder" di conseguenza devo dichiarare slow encoder?

Decisamente. Ragiona su come funziona l'input capture, conta i cicli di clock tra due fronti dell'encoder. Devi pensare al numero di conteggi che possono essere contenuti in un registro a 16 bit. Con un encoder "lento" (con pochi CPR) con il clock alla massima velocità, con il prescaler a 1, tra un impulso e l'altro dell'encoder ci possono essere più di 65535 colpi di clock. Quindi, ho inserisci una divisione del clock (prescaler) oppure devi contare tutte le volte che il registro va in overflow, con l'opzione slow encoder. In questo modo il registro è come se da 16 bit fosse espanso con i bit della variabile che gli dedichi per il conteggio degli overflow.

[gyppe]

Tutto chiaro grazie.

[ribellion]

Scrivo questo post per discutere sui problemi che stanno scaturendo dai test effettuati sulla mia piattaforma per tentare di ragionarci su.

Dunque:

Ho comprato una muin dsnav da robot italy per effettuare test ulteriori e vedere se confermavano la mia ipotesi di quello che accadeva con la robocontroller.



La mia configurazione:

piattaforma 4 ruote con sterzo a carro armato, 4 motori da 120 watt e riduttori 1:64, due di questi encoderizzati sull'albero finale, quello della ruota, mediante cinghia oring di precisione a 2 encoder industriali incrementali da 500 cpr della baumer.
I miei motori infatti non hanno il supporto encoder.

Pilotaggio tramite robocontroller o dsnav usando 2 ponti OSMC HCMD in LAP e i due encoder di cui uno con i canali invertiti.






Problemi riscontrati:

ROBOCONTROLLER CON FW DSPID 33:

1) Impostando la desspeed si ha la scheda che fa percorrere al veicolo una distanza a casaccio. DI solito di pochi cm oppure di diversi metri.
Sembra quasi che si fermi dopo 1 o 2 giri di ruota.


2) impostando il desangle il veicolo non sempre segue la logica dell'istruzione.

Es: impostando 30 gradi il veicolo girà di 30 gradi
impostando 60 il veicolo si gira di altri 30 gradi
impostando valori superiori a 180; es 235 il veicolo si gira di 235 gradi
impostando 360 il veicolo compie 3 giri su se stesso prima di fermarsi
impostando 0 il veicolo gira su stesso all'infinito anche dando il reset

3) la desidered distance e gli altri comandi non provocano alcuna risposta

4) il test di hyper terminal conferma il corretto funzionamento della comunicazione con la scheda

5) scollegando gli encoder e impostando la desider speed i motori girano all'infinito e non si fermano nemmeno impostando 0; o meglio, se si imposta 0 rallentano fino a fermarsi e subito ripartono.


Ipotesi problema:

1) encoder collegati male
2) canali encoder non correttamente polarizzati
3) scheda male alimentata


tesI:

1) i cavi erano malfunzionati e sono stati sostituiti con nuovi senza connettore

Risultati:

non è cambiato nulla, solamente il veicolo non va piu a scatti





MUIN DSNAV CON FW DSPID 33:


per il corretto funzionamento con il solo xbee ho disabilitato uart 1 e ponticellato tx e rx per evitare che la scheda permanga in errore e quindi ho testato.



1) impostando la des speed i motori partono correttamente alla velocità desiderata, dopo qualche secondo improvvisamente sbalzano andando a scatti per 2 secondi e poi riprendono la marcia correttamente.
Il problema è che impostando la velocità a 0 questi provano a fermarsi, ma subito ripartono a meno che durante la fermati io non fermi a mano gli encoder con la massima precisione.

2) toccando gli encoder a motori fermi: basta sfiorarne uno perchè dia un impulso, i motori partono tutti alla massima velocità senza mai fermarsi.
Sembra che seguano la direzione dell'encoder, perchè staccando la cinghia e fermando entrambi gli encoder si fermano; muovendo gli encoder a mano invece ogni gruppo di motori segue il verso di rotazione dell'encoder

e tutto questo senza inviare comandi alla scheda.


3) impostando il desired angle invece i motori seguono l'andamento dell'angolo, ma non si fermano.
Il comando halt non funziona.
I motori si fermano solo mantendo premuto il tasto reset finche i motori, o meglio gli encoder non sono completamente fermi.
Se al rilascio del reset anche un solo encoder si muove, questi ripartono ancora verso l'infinito.


Ipotesi:

1) fili rotti ancora
2) gli encoder trovandosi sulla ruota si fermano dopo rispetto ai motori
3) motori così grossi per spostare tanto peso procedono ancora di qualche mm per inerzia anche senza alimentazione.



Tesi:

1) i fili sono a posto
2) gli encoder sono correttamente collegati
3) la scheda è correttamente alimentata
4) la comunicazione è corretta



Risultati:

nessuna soluzione ancora trovata.

[guiott]

L'effetto di partire a palla lo fa quando è invertito l'encoder rispetto al motore. Il QEA e QEB devono essere in linea con la polarità del motore, altrimenti il PID è convinto di correggere la velocità in un senso invece la aumenta nell'altro non arrivando mai a trovare il punto di equilibrio. Normalmente basta invertire i fili del motore oppure il QEA rispetto al QEB tra encoder e scheda.
Il motore destro deve essere invertito rispetto al sinistro essendo montato a 180° rispetto a questo.

Domanda: hai configurato correttamente i valori di tutte le costanti in base ai tuoi parametri? CPR dell'encoder, rapporto di riduzione del motoriduttore, diametro delle ruote e tutto il resto?
Hai controllato che le variabili relative alla misura della velocità non sforino? Se i tuoi parametri sono molto diversi da quelli medi potrebbe accadere che il tempo tra un impulso e l'altro sia molto più alto e non basti 1ms. Ad esempio 8 CPR invece di 300 CPR. Il tuo 500 CPR sulla ruota con una riduzione di 1:64 risulta 7.8 CPR sull'asse motore (se non ci sono altre riduzioni tra asse ruota e encoder) non è molto, va ricalcolato tutto.

Insomma devi fare un passo alla volta.

[ribellion]

dunque

impostando gli encoder con valore di 8 cpr e il gear ratio a 64 invece degli originari 500 e 1 la cosa è molto migliorata.

se muovo gli encoder a motori fermi questi partono ancora ma a bassa velocità.


non è ancora cambiato il comportamento in accelerazione e decelerazione.

se imposto velocità superiori a 500 o inferiori a -500 i motori partono alla massima ed è tutto ok.

se imposto velocità basse invece partono normalmente e poi cominciano a scattare, come la scheda continuasse a intervallare il brake all'andamento ogni 800 ms.

controllando gli encoder, i canali a risultano correttamente in fase con il positivo e la direzione di ogni gruppo motore.


è cambiato invece il comportamento di fermata.

se imposto 0 i motori decelerano entrambi; si fermano... e poi cominciano ad alternarsi.

ogni gruppo esegue 1/4 di giro circa in senso opposto rispetto all'altro, come fosse un pendolo, finche: il movimento si fa sempre piu stretto portando i motori a fermarsi definitivamente dopo una ventina di volte.

Il tester in questo caso segna un passaggio di corrente di solo 30 ma per gruppo motore.
Visto che a 20 ma i motori sono fermi e vista la loro sensibilità nei confronti dei bassi voltaggi, potrebbe essere che l'inerzia rimasta dalla corsa unità al ponte che non chiude completamente azzerando la corrente che può circolare alimenti lo scherzetto degli encoder a motori fermi.

Ciò non spiega però come mai dopo 20 volte di "gongolaggio" i motori sono fermi


Forse mettendolo per terra cambierebbero le cose vero?


p.s.

one moment però, non vorrei dire una cavolata, ma essendo l'encoder bicanale un indicatore della direzione, è il canale A che deve essere in fase con la direzione e quindi col positivo dei motori giusto?

se io volessi controllare un motore per volta per assicurarmi il corretto collegamento dell'encoder: potrei variando manualmente l'impostazione di uno dei due pid da firmware?

[guiott]

E qui ti volevo

Quello è il comportamento di un PID non tarato. Ora devi cominciare a giocare con i parametri K fino a trovare le terne che vanno bene per la tua configurazione.

Il "dondolamento" alle basse velocità è dovuto al PID di velocità. Se imposti uno spazio da percorrere è dovuto al PID di distanza.

Come ti ho già detto, con un encoder a bassa risoluzione potrebbero esserci problemi proprio alle basse velocità, piuttosto che alle alte, perché tra un impulso e l'altro potrebbe passare un tempo superiore a quello di campionamento.

Devi farti un po' di calcoli per vedere i tuoi limiti. Puoi leggerti la parte di descrizione nel file descreng.txt per un esempio di calcolo.