*RISOLTO* Utilizzo laser lidar con servi, rallentamenti e problematiche elettr..

[Maurotec]

mmmmmm diciamo quindi che abbiamo eliminato uno dei sospettati riguardo la creazione del problema del freeze del codice (durante l'esecuzione) quando si utilizza l'alimentazione da batteria?

No, al momento non c'è motivo di parlare di freeze, c'è solo la certezza che dallo stepdown esce la giusta differenza di potenziale, e pertanto puoi procedere ad alimentare il tutto da batteria.

Anzi, prima di collegare il cavo USB accendi l'interruttore e poi colleghi USB.
La MEGA ha uno switch mosfet che seleziona la sorgente di alimentazione, dopo avere collegato la USB il circuito si accorge che l'ingresso 5V è già alimentato e pertanto la 4.29 della USB non viene usata.

[aldoz]

Anzi, prima di collegare il cavo USB accendi l'interruttore e poi colleghi USB.
La MEGA ha uno switch mosfet che seleziona la sorgente di alimentazione, dopo avere collegato la USB il circuito si accorge che l'ingresso 5V è già alimentato e pertanto la 4.29 della USB non viene usata.

Ahh pensa che ho sempre fatto il contrario : prima usb e poi accensione batteria..

Purtroppo non ho ancora i condensatori per fare nuovi test ma ne aprofitto per chiedere conferma che lo schema qui sotto sia corretto per quanto riguarda appunto l'uso dei vari condensatori

[Maurotec]

Purtroppo non ho ancora i condensatori per fare nuovi test ma ne aprofitto per chiedere conferma che lo schema qui sotto sia corretto per quanto riguarda appunto l'uso dei vari condensatori

Schema Ok, puoi anche procedere senza condensatori perché sulla MEGA ci sono già dei condensatori, sulla scheda ADAFRUIT non è verificato ma figurati se ladyada non c'è li mette.

Sul LIDAR non so, ma è pratica diffusa l'uso di condensatori.

Per cui secondo me dovrebbe funzionare senza freeze anche così, per questo ti avevo detto che prima della cura va trovata la malattia.

Ciao.   

[aldoz]

Schema Ok, puoi anche procedere senza condensatori perché sulla MEGA ci sono già dei condensatori, sulla scheda ADAFRUIT non è verificato ma figurati se ladyada non c'è li mette.

Sul LIDAR non so, ma è pratica diffusa l'uso di condensatori.

Per cui secondo me dovrebbe funzionare senza freeze anche così, per questo ti avevo detto che prima della cura va trovata la malattia.

Ciao.   

mauro entro domani provero' nuovamente la scansione con questa configurazione ma...
...questa configurazione è quella nella quale avveniva il freeze! :\  non c'e' nulla di diverso.. tranne il fatto che domani accendero' per prima l'alimentazione della batteria e solo sucessivamente inseriro' il cavo usb.
Comunque domani ritesterò tutto e vi faro' sapere!
e ragazzi, per ora, a tutti, GRAZIE per il grandissimo aiuto!

[Maurotec]

Non conosco come lavora LIDAR, in effetti ho fatto una ricerca su LIDAR LITE v2 è ho trovato una libreria, questa, mentre tu usi direttamente la wire, c'è un motivo?

Ciao.

[aldoz]

Non conosco come lavora LIDAR, in effetti ho fatto una ricerca su LIDAR LITE v2 è ho trovato una libreria, questa, mentre tu usi direttamente la wire, c'è un motivo?

Ciao.

Ciao Mauro, grazie per questa libreria ma è solo per la versione Lidar v2 con ETICHETTA BLU! purtroppo io ho la prima versione della v2, con etichetta grigia :\
Non so cosa cambia, ma so che i codici e librerie per il lidar v2 con etichetta blu non funzionano per il mio lidar.

Per quanto riguarda la mia situazione, ora il laser (sfruttando l2c oppure wire) funziona molto bene sia con l'alimentazione da rete elettrica sia con alimentazione da batteria.
Importantissimoil consiglio che mi hai dato riguardo il fatto di accendere prima la batteria e solo dopo inserire il cavo usb!
Ora quando alimento con batteria, non ho piu' blocchi

Per quanto riguarda i rallentamenti, ho parzialmente risolto riducendo la variabile "nackack" a 25 (il codice originale aveva 100).
Diciamo che il problema del rallentamento lo ottengo solo nelle scansioni 1x1 cioe' quelle con piu' risoluzione.
Sembra proprio che l'Arduino accumuli fatica! e ho accertato che tale rallentamento avviene (sempre eseguendo scansioni accurate in alta risoluzione) anche quando la scheda NON è connessa usb.. (quindi alimentata dalla batteria e assenza di processing)

Lo dico perche' mi stavo convincendo che tale rallentamento provenisse, in qualche modo, dal collegamento della scheda con il pc e invece sembra proprio la mia arduino Mega, quando esegue scansioni cosi' prolungate, fatichi, e' come se si riempisse una bottiglia finche' non c'e' piu' spazio per altra acqua...

Abbassando a 25 la variabile nackack sono riuscito a trovare un buon compromesso che mi permette almeno di evitare tali rallentamenti nelle scansioni a media/bassa risoluzione (che appunto impiegano un lasso di tempo inferiore per eseguire la scansione).

oltretutto se abbasso ancor di piu' il valore di questa variabile, ottengo nuovamente i rallentamenti al posto di ulteriori miglioramenti.. (mah)

Ah, ho provato con diversi baud rate 115200, 57600 ma mi è sembrato che questo settaggio non c'entri con questi rallentamenti.

[aldoz]

EDIT:

Per quanto riguarda i rallentamenti, ho parzialmente risolto riducendo la variabile "nackack" a 25 (il codice originale aveva 100).
Diciamo che il problema del rallentamento lo ottengo solo nelle scansioni 1x1 cioe' quelle con piu' risoluzione.
Sembra proprio che l'Arduino accumuli fatica! e ho accertato che tale rallentamento avviene (sempre eseguendo scansioni accurate in alta risoluzione) anche quando la scheda NON è connessa usb.. (quindi alimentata dalla batteria e assenza di processing)

Dopo ulteriori test, non sono piu' cosi' sicuro che il cambio del valore della variabile neackack sia in qualche modo legato a tali rallentamenti..
La cosa di cui sono piu' certo è che tali rallentamenti avvengono quando la scansione dura piu' di 20/30 secondi.
Ecco perchè eseguendo scansioni con risoluzione media (che impiega circa 11 secondi per essere eseguita) tali rallentamenti non avvengono mai.
Bisogna che la scansione duri di piu' per avere tali rallentamenti; sembra proprio che qualche "buffer" vada oltre la sua capacita'.. classico collo di bottiglia.

E confermo che per "resettare" tale rallentamento e ottenere nuovamente la velocita' corretta, bisogna staccare e riattaccare l'alimentazione USB (se la Mega è alimentata dall'usb) o spegnere e riaccendere l'alimentazione da batteria (se la Mega, appunto, è alimentata dalla batteria)
Quindi è un problema "resettabile" solo staccando e riattaccando l'alimentazione dell' Arduino Mega.

A questo punto mi manca solo provare tutto utilizzando l'ultimo schema, quello che usa le coppie di condensatori piazzati in prossimità dei dispositivi.
Appena avro' tutto, faro' dei test e vi aggiornerò!
Se intanto vi venisse in mente qualche altra soluzione teorica per risolvere questi rallentamenti, sono tutto orecchi!

PS : il mio laser:
   LIDAR-Lite Laser Rangefinder (PulsedLight)
        Product Code: RB-Pli-01
non sono piu' cosi' sicuro che sia il V2.. anche se quando lo ordinai lessi appunto V2..
mah

[Maurotec]

Leggi questo post di @milefori.https://forum.arduino.cc/index.php?topic=618406.msg4191629#msg4191629

Li si consiglia di modificare un cavo USB rimuovendo i due conduttori di alimentazione.

Il rischio è nei confronti del chip USB del PC, tuttavia potrebbe pure non accadere nulla di disastroso, in sostanza alimentare da USB e contemporaneamente da +5V non è esente da rischi.  

Abbassando a 25 la variabile nackack sono riuscito a trovare un buon compromesso che mi permette almeno di evitare tali rallentamenti nelle scansioni a media/bassa risoluzione (che appunto impiegano un lasso di tempo inferiore per eseguire la scansione).

Io non avevo risposto apposta perché nonostante non avesse senso per me, l'importate era che funzionava e magari mi sfuggiva qualcosa. Ora tu mi confermi che non risolve il problema.

Ecco perchè eseguendo scansioni con risoluzione media (che impiega circa 11 secondi per essere eseguita) tali rallentamenti non avvengono mai.
Bisogna che la scansione duri di piu' per avere tali rallentamenti; sembra proprio che qualche "buffer" vada oltre la sua capacita'.. classico collo di bottiglia.

Il buffer della seriale si riempe solo se si inseriscono nella unità ti tempo più dati di quanti se ne possono spedire con il baud rate selezionato. Comunque per verificare basta evitare di spedire da seriale,
Ciao.

[aldoz]

Leggi questo post di @milefori.

Li si consiglia di modificare un cavo USB rimuovendo i due conduttori di alimentazione.

Il rischio è nei confronti del chip USB del PC, tuttavia potrebbe pure non accadere nulla di disastroso, in sostanza alimentare da USB e contemporaneamente da +5V non è esente da rischi.  

Non capisco bene a cosa ti riferisci (queste tue parole sono senza un testo in "Quote") ma di sicuro dopo il tuo consiglio di accendere prima la batteria e solo dopo inserire il cavo usb, ho risolto i problemi di freeze del codice quando appunto alimento il tutto con la batteria.

Io non avevo risposto apposta perché nonostante non avesse senso per me, l'importate era che funzionava e magari mi sfuggiva qualcosa. Ora tu mi confermi che non risolve il problema.

Si, in effetti ad ora non ho capito a cosa serva la variabile nackack..  
sto facendo anche in questi minuti dei test e ho notato che abbassando tale variabile a 25, otterro'il rallentamento verso i 30 secondi di scansione;
utilizzando un valore di 100 ottengo il rallentamento nei primi 10 secondi.
Ho parecchi test oramai che confermano questo ma comunque continuo a non afferrare il senso di tale variabile.. anche perchè riducendolo ulteriormente si ottiene il rallentamento immediatamente dopo 1 o 2 secondi.. mah...

Il buffer della seriale si riempe solo se si inseriscono nella unità ti tempo più dati di quanti se ne possono spedire con il baud rate selezionato. Comunque per verificare basta evitare di spedire da seriale,
Ciao.

Queste tue parole mi dovrebbero consigliare di aumentare il baud rate..
cio' creerebbe un flusso dati disponibile ben piu' "largo" dell'attuale e quindi teoricamente non dovrebbe piu' avvenire il collo di bottiglia, o tuttalpiu' dovrebbe avvenire piu' tardi nel tempo e invece, purtroppo, anche con baud rate tipo 250000, 500000, 1000000 la strana logica di questi rallentamenti non cambia.. avvengono lo stesso..
ma poi perchè si e' costretti a spegnere e riaccendere l'alimentazione per riottenere il codice alla giusta velocita'??
Dovrebbe bastare semplicemente un riavvio del codice! e invece no, bisogna proprio togliere e rimettere l'alimentazione...
non è che sia proprio la mia Mega danneggiata? (ne ha visti tanti di brutti cablaggi in questi anni)

Ps ho dei condensatori da 1500 e 2200 uF. posso tentare di usare questi? o sono troppo alti di uF rispetto a quelli consigliati da 47uF?

[aldoz]

EDIT :
Altro indizio..

durante l'esecuzione, a velocita' normale, della scansione la lucina TX è fissa con rapidissimi e momentanei spegnimenti

Durante i rallentamenti questa lucina TX invece lampeggia chiaramente (si accende e si spegne in maniera ben visibile)


Ora sto provando con il delay dei nackack portato da 1 a 5ms..
Sono alla sesta scansione ad alta risoluzione di seguito
e per ora zero rallentamenti!!.. (ottenendo anche una scansione piu' limpida seppur piu' lenta)

quindi forse era il famoso overpolling... ("Wait 1 ms to prevent overpolling") ed evidentemente 1millisecondo era troppo poco per scansioni cosi' lunghe come quella in alta risoluzione

[aldoz]

Ragazzi! dopo ulteriori test posso confermare che questo mio thread puo' essere modificato in RISOLTO.
Confermo le parole in grosseto del mio ultimo commento.

Entrambi i due problemi iniziali(i rallentamenti e i freeze del codice) sono stati quindi risolti.

GRAZIE davvero a Mauro e Claudio! e ancora una volta questo forum si dimostra per me ed il mio progetto, indispensabile!

[Maurotec]

Non capisco bene a cosa ti riferisci (queste tue parole sono senza un testo in "Quote")

Colpa mia, mancava il link, ora l'ho corretto. 

Entrambi i due problemi iniziali(i rallentamenti e i freeze del codice) sono stati quindi risolti.

GRAZIE davvero a Mauro e Claudio! e ancora una volta questo forum si dimostra per me ed il mio progetto, indispensabile!

Ottimo, letto anche in merito ad overpoling e mi chiedo se non ci sia modo di evitarlo. La wire (o i2c) usano gli interrupt e mi pare si possa configurare una funzione utente la quale viene chiamata quando ci sono dati da leggere, ma non so come si possa al momento integrare con LIDAR a cui ho dedicato poco tempo.

Per me ancora rimane il mistero del rallentamento che una volta innescato va via solo dopo un reset.

Ps ho dei condensatori da 1500 e 2200 uF. posso tentare di usare questi? o sono troppo alti di uF rispetto a quelli consigliati da 47uF?

No, ma solo perché sono troppo ingombranti e senza i 100nF e lavoro sprecato, piuttosto ci sarebbe da sistemare il cablaggio, ad esempio potresti usare delle schedine millefori e dei morsetti a vite così eviteresti anche di saldare condensatori volanti, ma questo credo che sia meglio pensarci quando il tutto è pienamente funzionante e testato. Se vuoi rivedere il cablaggio sperimentale vale quanto detto in precedenza, cioè morsetti volanti mammut.

Ciao.

[aldoz]

Colpa mia, mancava il link, ora l'ho corretto. 

Ma figurati!! comunque ora me lo leggo

Per me ancora rimane il mistero del rallentamento che una volta innescato va via solo dopo un reset.

In effetti è una roba strana.. come se qualcosa nella Mega si "svuotasse" SOLO ed ESCLUSIVAMENTE dopo aver "staccato e rialacciato" la corrente..

No, ma solo perché sono troppo ingombranti e senza i 100nF e lavoro sprecato, piuttosto ci sarebbe da sistemare il cablaggio, ad esempio potresti usare delle schedine millefori e dei morsetti a vite così eviteresti anche di saldare condensatori volanti, ma questo credo che sia meglio pensarci quando il tutto è pienamente funzionante e testato. Se vuoi rivedere il cablaggio sperimentale vale quanto detto in precedenza, cioè morsetti volanti mammut.

Appena avro' a disposizione i condensatori a 47uF e quelli da mettergli in parallelo (quelli da nF), faro' immediatamente nuovi test! (certo ora sono risolti i problemi ma punto a creare un cablaggio corretto)

Mauro, ancora GRAZIE 1000!