Jump to content

[Cantiere Kilo Class Trumpeter 1/114] Conversione RC


Call_Me_V

Recommended Posts

Non ci posso credere....il grande @andreavcc....che piacere leggerti sulle pagine del forum :wink:

 

....e si pian pianino il Kilo sta prendendo forma, sono ancora lontano dalla chiusura cantiere ma sono contento che stiamo curando tutti i dettagli e trovando tutte le soluzioni migliori per arrivare al mio primo modello RC :dribble:

 

Concordo sull'apparente facilità del modello che però nasconde non poche insidie nella sua realizzazione....ma dalla mia c'è stato sempre l'attento occhio vigile del mitico Ocean's One!!

 

3 hours ago, andreavcc said:

Se potrò essere utile in qualcosa sarà per me un piacere 

 

ma certamente, anzi adesso passiamo all'elettronica e potremo sbizzarrirci su quanto implementare.......siiiiii parteeeee :smiley28:

 

@Ocean's One abbiamo scritto i due precedenti post nello stesso momento e sono stati sfalsati come tempistiche.....comunque la tua fantasia vedrà "presto" la luce, magari non tutta a primo giro ma sicuramente buona parte. Come anticipato da te, le dimensioni del Kilo non permettono grandi "manovre" su quanto inserire, perciò la telecamera e la boa non riusciremo a prevederle.....per il resto "se po' fa" :biggrin: o per meglio dire credo che già in questo cantiere potremo implementare il tutto, se abbiamo anche la disponibilità di @gepard lato software potremo procedere ancora più spediti!!!

 

Considerate che sto facendo un minimo di schema a blocchi per condividere con voi quanto inserire e di sicuro sarà presente la scheda con giroscopio, accelerometro, magnetometro e pressostato (ovvero 9 gradi di libertà con pressostato), un po' di elettronica per la lettura batterie e presenza acqua nel WTC, un regolatore 5V, display OLED, ovviamente la ricevente e gli ESC per i due motori, il tutto pilotato da Arduino. Perciò l'idea è quella di far passare tutto sull'Arduino e utilizzare la ricevente soltanto per ricezione segnali. Inserirò un'ulteriore chicca ma la lasciamo per dopo. :biggrin:

Con tutto ciò direi che dobbiamo solo capire insieme quali funzionalità realizzare e come realizzarle, come da lista di Ocean's One.....una alla volta le implementiamo tutte!!

 

Vi mando il diagramma a blocchi di domani.

________________________________________________

 

5 hours ago, Ocean's One said:

Però, se fra un anno o due Call_Me_V ci vorrà stupire, sono sicuro che queste cose sono alla sua portata....(per il modellone, invece, glielo posso dare io) 

 

sono curioso del modellone che vorresti proporre :dribble: ....io qualcosina come secondo cantiere l'ho già prevista

20200722_183503.thumb.jpg.72c3306564927bbf2f2b213b0da67b0a.jpg

 

immaginavi qualcosa oltre il metro? :biggrin:

Link to comment
Share on other sites

  • Replies 220
  • Created
  • Last Reply

Top Posters In This Topic

1 hour ago, Call_Me_V said:

 ....io qualcosina come secondo cantiere l'ho già prevista

 

 

wow hai un bel pò di lavoro che ti attende 😁
e a mio modesto parere hai anche indovinato in un certo qual modo, la sequenza corretta dei modelli
-seawolf
-VIIC
-Skipjack
il primo ti darà più spazio interno e meno problemi anche perchè l'opera morta è decisamente minore di quella del kilo. Il tipo VII avrà bisogno di un wtc di diametro limitante ma si sviluppa bene in lunghezza. Lo skipjack ha delle dimensioni che ti permettono di inserire all'interno anche una moka per far bella figura con gli altri modellisti presenti alla regata 😁

Ma tornando al kilo, io in elettronica sono sotto zero, quindi mi limiterò a seguirvi silenzioso... 😉

Link to comment
Share on other sites

6 hours ago, Ocean's One said:

Ma quante voglie ci fa venire questo uso eccellente dell'elettronica!

Gepard, Call_Me_V, siete dei tentatori.

 

Per parte mia, cedendo ai sogni, mi immagino un modellone più grosso del Kiletto, con telecamera e trasmissione dell'immagine a terra con boa.

Sovraimpresse sull'immagine, potrebbero esserci le indicazioni di:

- profondità

- rotta (si trova una bussola o giroscopio adatto, no?)

- gradi di beccheggio (giroscopio MEMS)

- carica della batteria

- allarmi in corso (batteria bassa, quota eccessiva,...)

- percentuale di riempimento della cassa di zavorra (contando i giri del motore, se è uno stepper)

- eventualmente, una linea orizzontale che mostra il beccheggio zero

- se la telecamera è orientabile con comando separato, i suoi gradi di azimut o inclinazione

- temperature?? Batteria o motore?

- Funzioni attive: autoquota on/off, livello di intervento del pitch controller, luci accese/spente, etc

 

E poi mi fermo perché già così sto sognando troppo!

Però, se fra un anno o due Call_Me_V ci vorrà stupire, sono sicuro che queste cose sono alla sua portata...

(per il modellone, invece, glielo posso dare io) 

 

FINE OFF TOPIC!!!

E scusate il volo di fantasia. Ogni tanto ci vuole  :smile:

 

Vuoi fare un ROV ?

 

Sognare non costa nulla quindi io ci aggiungo un bel sistema a revolver di lancio siluri e idrofoni per permettere al battello in autonomia di inseguire altri modelli immersi o di superficie o di raggiungere un determinato target acustico (ad esempio per farlo tornare al punto di partenza)

 

I siluri sarebbero elettrici, alimentati da supercap con carica di tipo wireless a bordo modello. Tempo fa ho fatto qualche prova e un supercap da 1F a 2.7V può alimentare un micro motore coreless per decine di secondi, da 3F fino ad 1 minuto. Per la carica wireless ancora non ho trovato un circuito sufficientemente miniaturizzato ed economico.

 

Il meccanismo a revolver del tubo di lancio può usare lo stesso meccanismo delle penne a sfera, avete notato che ogni pressione del pulsante, fino ad un certo punto fa compiere una rotazione di una frazione di giro e premendo più a fondo spinge la punta della biro qualche mm oltre per poi tornare in una delle due posizioni stabili ? Quindi, con un solo servo si può comandare sia la carica del tubo che il lancio del siluro...

 

E gli idrofoni, almeno 4, potrebbero semplicemente indicare il vettore di direzione del suono più forte captato (magari filtrati/sintonizzati per "sentire" la rotazione delle eliche) 

Link to comment
Share on other sites

7 hours ago, Call_Me_V said:

Di sicuro l'idea di complicare la meccanica del modello non mi alletta per niente perciò l'aggiunta di camere o altro vorrei assolutamente evitare

Penso sia sufficiente sigillare la schedina in guaina termo restringente o sacchettino di plastica da cui escono solo i cavetti di i2c+alimentazione (senza creare un contenitore), posizionandola poi fuori dal WTC: sotto o sopra il WTC, nella zona un po' libera a poppa o nella vela.

Link to comment
Share on other sites

Quanto fermento....ottimo, mi fa piacere, tante belle idee da mettere in pratica..... @gepard le proposte ovviamente non sono per il kilo !?!? :blink:

Scherzo, ottime pensate, considera che sto recuperando dalla cina delle micro batterie che potranno essere inserite in siluri per il classe VII....con il tempo ci arriveremo!!

 

11 minutes ago, gepard said:

Penso sia sufficiente sigillare la schedina in guaina termo restringente o sacchettino di plastica da cui escono solo i cavetti di i2c+alimentazione (senza creare un contenitore), posizionandola poi fuori dal WTC: sotto o sopra il WTC, nella zona un po' libera a poppa o nella vela.

 

Grazie per la dritta ma preferisco non avere nulla fuori dal WTC, almeno per questo modello!

 

1 hour ago, andreavcc said:

wow hai un bel pò di lavoro che ti attende 😁

 

Mi sono portato avanti :biggrin: è da qualche anno che cerco offerte sui vari modelli (risparmiando un bel po' di soldi), mettendone da parte "giusto" qualcuno per il futuro!! Leggendo i tuoi commenti su tutti i vari modelli mi viene voglia di farli tutti insieme....ahahah

Link to comment
Share on other sites

9 hours ago, Call_Me_V said:

 le proposte ovviamente non sono per il kilo !?!? 

Ovviamente...

 

...no ?!

 

Queste proposte le ho ideate anni fa quando volevo realizzare in scala 1:48 il modello dell'Akula da cui ho "rubato" il nickname, il Gepard.

 

Ma se andrò in pensione (sempre che non la aboliscano prima) e sarò ancora lucido, il mio sogno è la realizzazione, sempre in scala 1:48, del Leonardo da Vinci con CA2 approntato per le missioni su Freetown e New York.

 

Scusate l'OT.

 

Ritornando sul pezzo, mi è venuto in mente che man mano che la sacca di zavorra si riempie ed aumenta la pressione nel WTC la pompa dovrà sopportare una maggiore resistenza, hai fatto delle prove in proposito con i motorini che intendi utilizzare ?

Edited by gepard
Link to comment
Share on other sites

38 minutes ago, gepard said:

Ritornando sul pezzo, mi è venuto in mente che man mano che la sacca di zavorra si riempie ed aumenta la pressione nel WTC la pompa dovrà sopportare una maggiore resistenza, hai fatto delle prove in proposito con i motorini che intendi utilizzare ?

 

Ben trovato anche al buon Gepard, la sua considerazione sulla pressione interna non è di poco conto. La pressione interna aumenta e organi di tenuta (se non erro delle camere a grasso), caps e pompa vengono messi alla prova in maniera seria... di quanti cm cubi d'acqua hai bisogno per immergerti? quant'è il volume interno disponibile all'interno del wtc? 

Link to comment
Share on other sites

Ciao ragazzi,

ho cercato di schematizzare rapidamente in Fritzing una sorta di architettura di sistema.

image.thumb.png.c124c59d5aa9743ebbec354142e52c09.png

 

Come potete notare non ho esplicitato tutte le connessioni (alimentazioni, giri di massa, protocolli) e non ho effettuato un collegamento puntuale di tutto ma ho solo riportato i componenti fondamentali che vorrei utilizzare e come vorrei gestirli, ovvero centralizzare tutto su Arduino per fargli gestire il sistema in base a quanto in arrivo dalla ricevente, per poi attuare strategie varie (che definiremo insieme) in completa autonomia. 

Spero che a colpo d'occhio sia più comprensibile rispetto alla lista della spesa. Solo per essere precisi ho anche aggiunto in maniere opzionale una schedina per la memorizzazione dei parametri che permette di salvare tutto su microSD. In più la scheda con i 9 gradi di libertà ha a bordo, un magnetometro, un giroscopio e un accelerometro.....insomma è ben carrozzata!!

 

Detto ciò, la mia idea è partire con un componente alla volta e con voi approfondirei i dettagli per capire insieme come deve comportarsi a livello funzionale (magari facendo confronti e paragoni con i nostri amati sottomarini reali) per poi passare a problemi/soluzioni/ottimizzazioni e in una fase finale al test sul Kilo. Che ne dite? Vi piace l'idea? :smile:

 

Per davi un'idea, con il sistema che vedete nell'immagine e riprendendo il post con tutte le ottime idee di @Ocean's One se escludiamo la boa e la telecamera, tutto il resto è già implementabile, dobbiamo "solo" (per così dire) decidere le strategie e le funzionalità. Credete che un sistema così possa essere completo? o secondo voi manca ancora qualcosa? Cambiereste qualcosa?

 

Io un'altra idea la metterei in campo ma ve ne parlo in futuro altrimenti aggiungerei entropia.....mentre mi piacerebbe rimanere focalizzato sul sistema. :biggrin:

 

7 hours ago, andreavcc said:

la sua considerazione sulla pressione interna non è di poco conto. La pressione interna aumenta e organi di tenuta (se non erro delle camere a grasso), caps e pompa vengono messi alla prova in maniera seria... di quanti cm cubi d'acqua hai bisogno per immergerti? quant'è il volume interno disponibile all'interno del wtc? 

 

....e a questo punto visto che siamo "in corsa" per la pompa peristaltica partirei proprio da qui, concordo con voi che l'aumento di pressione potrebbe essere non banale e va sicuramente gestito/curato come aspetto. Tengo a precisare che non sono ancora riuscito a fare test, conto in due giorni di mettere in funzione la pompa e inserirla nel WTC per le prime prove.....e vediamo come vanno....speriamo la pompa/motore tengano!!!

 

@andreavcc riguardo l'acqua da imbarcare, si aggira sugli 85 g e devo dirti che non riesco a stimare se tanti o pochi in rapporto alla pressione generata nel WTC, comunque lo scopriremo con l'aiuto del mitico pressostato BMP280 :biggrin:

 

Invece riguardo l'effetto che tale variazione avrà sui tappi e l'eventualità che possa espellerli in modo parziale o totale, ho previsto degli agganci tra tappi del WTC e scafo nella parte sottostante e per la parte superiore ci sarà la possibilità di avvitare i tappi sui supporti che tengono il WTC ancorato allo scafo....i modelli 3D sono in lavorazione, li finisco e ve li mostro :wink:

 

 

Link to comment
Share on other sites

Attendiamo allora la prova della pompa per vedere se ci sono problemi di pressione. 

Per l'elettronica non saprei cos'altro aggiungere... praticamente hai già messo tutto. Siamo quasi alla guida autonoma di terzo livello 😁

Link to comment
Share on other sites

Andrea, com'è bello rivederti "sul pezzo"!

Fra l'altro, il tema della pressione interna io non l'avevo finora affrontato e i commenti tuoi e di Gepard sono assolutamente utili allo sviluppo di un buon progetto.

Sull'onda di ciò vorrei ipotizzare una risposta teorica, nell'attesa delle misure pratiche che farà Call_Me_V.

 

Il secondo punto è quello della "guida autonoma di terzo livello", come dici tu Andrea :smile:

Anche queste scelte le vorrei commentare, anche se per ora l'interesse massimo deve rimanere sulla pressione interna.

Dunque, andiamo con ordine:

 

 

PRESSIONE INTERNA AL WTC

La capacità della sacca è di circa 85 g = 85 mL.

Dobbiamo confrontarla con il volume libero interno, che non è noto. Possiamo però fare una stima spannometrica, che è meglio di niente, riprendendo gli ottimi numeri che Call_Me_V ha riportato.

Dunque, il volume totale del WTC è di circa 630 mL. Sappiamo poi che il peso del WTC è di 156 g, che divisi per una densità media delle varie plastiche di 1,2 darebbe un volume di circa 130 mL.

Quindi, 630-130 = 500 mL dovrebbe essere il volume di aria all'interno del WTC.

C'è poi lo spazio rubato dai componenti interni, alcuni pesanti come batterie e motori, altri leggeri come l'elettronica e i supporti. Spaziamo da una densità di 1,2 (plastica) a 2,7 (alluminio) a 7,8 (acciaio). E' difficile fare una media, ma moooolto ad occhio direi di tenere 2,5 come densità media.

I componenti interni pesano circa 400 g, quindi hanno un volume i circa 400/2,5 = 160 mL.

Ergo, il volume interno libero nel WTC è più o meno di 500-160 = 340 mL.

 

Che fatica, ma siamo arrivati fin qua.

Ora confrontiamo i 340 mL di volume interno libero nel WTC con gli 85 della sacca piena.

E' esattamente 1/4 (al netto delle varie ed inevitabili approssimazioni).

Quindi, a sacca piena il volume libero nel WTC diventa 3/4,  e quindi la pressione interna diventa 4/3, come ci insegna la fisica (PV=nRT=costante).

In conclusione, all'interno ci sarà la pressione atmosferica iniziale, aumentata di 1/3 per dare appunto il totalone di 4/3 che dicevamo.

Quindi, l'aumento di pressione è pari a 1/3 bar = 333 mbar.

 

Certamente è tantino, ma vediamo se è ancora accettabile.

Innanzitutto, il pressostato deve essere differenziale e non assoluto. Infatti, per scattare al limite corretto, deve leggere la pressione che insiste sulla parete della sacca, ossia la differenza fra la pressione interna e quella esterna (dove quest'ultima è quella che c'è dentro il WTC). Questo valore, come suggerisce Bruggen, può essere vicino ai 62 mbar.

Call_Me_V, se il tuo pressostato è differenziale, può funzionare bene. Se invece è assoluto ed ha un solo ingresso di pressione, in teoria dovresti tararlo a 333+62 = 400 mbar circa. Però attenzione, perchè dovresti sempre richiudere il WTC a sacca vuota, perchè quella volta che lo richiudi con la sacca un po' piena perdi i riferimenti e rischi di farla scoppiare.

Quindi, per favore, no pressostato assoluto ma solo differenziale.

Veniamo ora al secondo problema: gli sforzi sui tappi. 333 mbar causano 0,33 kg di forza su ogni cm2 del tappo del WTC, ossia circa 6,5 kg su un diametro 50 mm e area 20 cm2 circa.

E' una bella sberla, che rischia veramente di sparare fuori i tappi se non li fissi bene.

Possibili soluzioni:

1) Chiudi sempre il WTC a sacca piena, o usa una valvola che scarichi l'aria in eccesso la prima volta che riempi la sacca. Non avresti più problemi di sovrapressione, ma al contrario quando svuoti la sacca la tua pompa deve vincere anche la depressione nel WTC che invece chiamerebbe acqua dentro la sacca rendendo lo svuotamento più difficoltoso.

2) Chiudi sempre il WTC con la sacca piena al 50%, così hai una sovrapressione di 0,16 mbar a sacca completamente piena, che ti aiuta nello svuotamento almeno fino a metà (che già basta per emergere). Poi è vero che per svuotare tutta la sacca la pompa farà più fatica, perchè nel WTC si crea una depressione fino a -0,167 mbar, però questa è minore del caso iniziale e comunque non è indispensabile svuotare tutta la sacca per emergere.

Per inciso, visto che la max sovrapressione sarà solo di +0,167 mbar, anche la spinta sui tappi sarà la metà del caso iniziale, ovvero solo 3 kg circa, un po' più facili da gestire.

 _____________

 

 ELETTRONICA

Call_Me_V, volevo parlarti anche di questa, ma vedo che ho già scritto un romanzo.

Allora ti scrivo solo la considerazione fondamentale, che è anche il mio sentito consiglio: usa il modello e vedi cosa ti piace!

Le nostre passioni non sono tutte uguali, e anche il modo di divertirsi con i sub RC è molto personale.

 

Per esempio, vedere il tuo Kiletto procedere in superficie e poi immergersi di slancio, con una dinamica simile ai battelli veri, sarà molto appagante. Poi sarai gratificato di vedere la sua risposta ai timoni, riportandolo il affioramento o magari cercando di rimanere a quota periscopica... 

Insomma, la riproduzione di un sottomarino militare ben si presta ad essere osservato dal fuori, apprezzando le sue risposte ai tuoi comandi, e l'eleganza della sua manovra.

 

Però c'è anche l'aspetto opposto: pilotaggio con visuale in prima persona, attraverso telecamera, per fare manovre di fino ed avvicinamenti a qualcosa che vedi sott'acqua, con un modello molto manovrabile tipo ROV, batiscafo o sottomarino da ricerca, con mille luci da accendere ed altre funzioni ausiliarie, e tutti gli ausili per la manovra che ti può dare l'elettronica, sognando magari di avvicinarti sott'acqua al modello del Titanic affondato. E se lo vuoi fare davvero, te lo presto: 

Oppure, se ti piace, fai la lotta con gli storioni come ho fatto io ( :doh: )

 

Insomma, pilotaggio di fino in prima persona contro fascino di un modello che vedi evolvere come quelli veri. Quale dei due?

Secondo me è ancora presto per decidere: prima devi pilotare il Kilo, senza troppe complicazioni, e poi farai le tue scelte.

Se alla fine andrai sul sub da ricerca, un bel po' di pezzi te li posso dare io.

Per i modelli di sottomarini militari vedo invece che sei ben messo... :thumbsup: 

Ciao!

 

Edited by Ocean's One
Link to comment
Share on other sites

1 hour ago, andreavcc said:

Siamo quasi alla guida autonoma di terzo livello

 

e poi ci ritroviamo a recuperare il modello da qua sopra:

 

Devils_Tower_CROP-800x533.jpg

 

Ah, no quelli sono gli incontri ravvicinati del terzo "tipo" !!! 😁

Dal punto di vista del software, come dicono gli anglosassoni, first things first:

 

- acquisizione comandi da rx e pilotaggio diretto dei servi e degli ESC -> il tuboduino

 

E già per questo c'è da valutare se richiede meno risorse computazionali la lettura del segnale composto ppm usando un singolo pin di input di Arduino (probabilmente richiede un piccolo intervento, saldatura di un filo, sulla rx per recuperare quel segnale prima che entri del demultiplexer) oppure la campionatura delle 4 uscite per i servo dalla rx usando 4 pin di input di Arduino.

 

Second things second:

 

- gestione pressostato per impedire l'esplosione della sacca di immersione -> l'arduficiere

 

Third things third:

 

- failsafe con gestione di stato batteria e sensore acqua per comandare emersione rapida, timoni di profondità a salire e propulsore -> l'arduschettino

 

Last things last:

 

- gestione IMU (scheda 9DOF) per iniziare basta il solo controllo dell'assetto orizzontale e pilotaggio dei timoni orizzontali (automatic pitch control) -> il livellino

 

Per il controllo della rotta occorre prevedere anche un "protocollo" di comunicazione ad alto livello tra operatore e battello (rotta rispetto ad un riferimento, es. north-up, course-up, head-up, velocità e modalità di approccio alla rotta comandata) oltre alla gestione di giroscopio e magnetometro -> l'arduo-ino

 

Il controllo del display l'hai già fatto...

Link to comment
Share on other sites

Beh, direi che il buon Gepard ha fatto un ottimo punto della situazione, anche condito con un po' di umorismo "arduinico". Concordo in tutto.

 

1) "Tuboduino" first: acquisizione dei segnali rx e pilotaggio di servi/ESC: indispensabile, e quindi giustamente priorità 1! Consigli operativi da Gepard ne vedo già diversi...

 

2) "Arduficiere" second: gestione pressostato, questo è certo!

Qui forse la gestione dei pressostati si potrebbe usare anche per verificare le falle (pressione interna aumentata se il battello è in profondità) ma anche per il rilievo della profondità con presa esterna, ma non la consiglierei ora. Solo più avanti. 

 

3) "Arduschettino" - failsafe per batteria bassa sicuramente da fare, magari splittato su due livelli di voltaggio, mandando prima la pompa a svuotare e poi tagliando definitivamente tutti i motori per evitare che la batteria LiPo faccia un bel botto perché troppo scarica (oppure questa funzione ce l'ha già l'ESC?)

Il sensore acqua è certo una bella idea, ma con 85 g di spinta il salvataggio può avvenire solo se l'acqua entrata per falla è meno di questa quantità, altrimenti è inutile (a meno di dare tutto motore e timoni a salire, certo, ma allora stiamo attenti a non mixarlo con il segnale di LiPo scarica, altrimenti il botto c'è.)

 

4) "Livellino": controllo assetto orizzontale = pitch controller. Bello, ma funzionerebbe meglio con i servi dei timoni orizzontali divisi fra anteriori e posteriori. Così come sono ora forse non è il massimo. Concordo a dargli priorità ultima, e magari valutare l'intervento solo dopo i primi collaudi in acqua.

 

5) "Arduo-ino" e tanta bella elettronica aggiuntiva. Entusiasmante, ma da valutare bene se questo è il modello giusto. Io andrei su qualcosa di più grande, e soltanto dopo che tu Call_Me_V ti sarai fatto sufficiente esperienza.

______________

 

Ad ogni modo, direi proprio che con Gepard a supporto non avrai problemi ad affrontare tutte queste necessità.

Ciao!

 

Link to comment
Share on other sites

.....con tutte queste info non saprei da dove partire nel rispondervi :biggrin: ....perciò riprendo da dove avevo lasciato, ovvero dallo schematico postato!!

 

Mi è parso di capire da tutti i commenti che come configurazione hardware vi piace e non cambiereste nulla, questo mi fa piacere, direi che il sistema è abbastanza completo e si possano implementare molte funzionalità a livello firmware che magari a oggi vengono fatte con componentistica discreta o non vengono per niente considerate. Forse ci renderemo conto che qualcosa andrà modificata/cambiata ma comunque può essere considerata una buona base di partenza hardware.


Prima di andare oltre volevo sottolineare che i nomi in perfetto stile Arduino sono fantastici :biggrin: e visto che in fase finale di cantiere vorrei ri-progettare una board dedicata con tutte le funzionalità che stiamo trattando, vi anticipo che sarà "battezzata" --> SUBMAR-INO

 

A questo punto, riprendendo l'ottima lista già postata da @gepard / @Ocean's One e visto che avete già analizzato i vari punti ampiamente, dettagliando quali possano essere le fasi di sviluppo futuro del progetto, converrebbe focalizzarsi solo sul primo componente da implementare, ovvero il pressostato!!! Perciò parto da quanto già esplicitato nei post precedenti e provo ad aggiungere qualche altra idea da implementare, principalmente legate a strategie di guasto (fault) in modo tale da avere degli automatismi aggiuntivi per evitare disastri

  • Funzionalità ottenute con il pressostato --> misura pressione assoluta e temperatura WTC
    1. check se il sensore è al "fondo scala" in fase di avvio elettronica --> fault sul LCD e LOG su SD -->  submarino non permetterà di utilizzare nessuna funzione
    2. check aumento pressione oltre il range prestabilito --> fault sul LCD e LOG su SD -->  attivo procedura fail safe (stacco propulsioni, imposto i timoni in "emersione" e attivo pompa peristaltica per emergere)
    3. check se non avviene nessuna variazione di pressione pur avendo la pompa attiva --> fault sul LCD e LOG su SD -->  attivo procedura fail safe (stacco propulsioni, imposto i timoni in "emersione" e attivo pompa peristaltica per emergere)
    4. Considerando quanto anticipato sui conteggi dettagliati di @Ocean's One relativi alle pressioni e la necessità di dover chiudere il WTC con la cassa di immersione non per forza vuota, potrebbe essere interessante permettere una configurazione submarino per cassa immersione piena/vuota o a metà --> avendo un LCD a disposizione, manca un "meccanismo" per poter interagire con il sistema.....perciò probabilmente inserirò un mini Joystick con il tasto integrato :dribble:.....di "roba" ne ho già considerata tanta.....ma questa aggiunta non è eccessiva!!!
    5. Strategia one shot di "apprendimento" all'avvio per trovare il massimo valore di acqua da immettere nella cassa per permettere la corretta/desiderata immersione--> selezionabile se farla o meno con joystick/LCD --> submarino memorizzerà tale valore per le volte successive
    6. check se la temperatura è in un range prestabilito --> fault sul LCD e LOG su SD -->  submarino non permetterà di utilizzare nessuna funzione

Non so se tale lista sia esaustiva, in ogni caso se vi vengono in mente altre cose da inserire/prevedere ditemi pure così le valutiamo insieme!! :smile:

 

Passando oltre, volevo farvi vedere un video sullo stato dell'arte dello sviluppo, che riguarda

  • Comunicazioni stabilite, Arduino "comprende" i 6 canali (che probabilmente saranno 5) e visualizza in modo grezzo (senza nessun campionamento) le informazioni sul display (nel video ho movimentato vari canali). Riguardo questa parte devo ancora prevedere/configurare correttamente gestione trim, fail safe, range usabili, eventuali mix di segnale.
  • Pilotaggio servo 
  • Pilotaggio ESC/motore/pompa, nel video non è presente, ve lo posto prossimamente ma comunque la catena funziona, nel senso che riesco a far funzionare in entrambe le direzioni la pompa e l'acqua fluisce tra due bicchieri......adesso passo all'ottimizzazione e inserimento del tutto nel WTC, probabilmente partirò da un setup senza pressostato e poi lo inserirò in una fase successiva.
 

e visto che ormai le foto non bastano più per farvi vedere gli avanzamenti, man mano che vado ad aggiungere le nuove funzionalità vi aggiorno con altri video :biggrin:

 

___________________________________________________________________

 

 

On 23/7/2020 at 23:18, Ocean's One said:

Allora ti scrivo solo la considerazione fondamentale, che è anche il mio sentito consiglio: usa il modello e vedi cosa ti piace!

Le nostre passioni non sono tutte uguali, e anche il modo di divertirsi con i sub RC è molto personale.

 

@Ocean's One grazie per il consiglio e soprattutto complimenti per il modello.....l'ebrezza della guerra con gli storioni non l'avevo mai vissuta :biggrin:

Volevo però dirti che come in alcune occasioni accade "il viaggio può essere più interessante della meta" e senza essere ulteriormente poetico :doh: ti confesso che a oggi non mi ero posto questa domanda, probabilmente perché volevo fare un discorso con voi un po' più generale, ovvero definire l'architettura HW, scegliere insieme le funzionalità che volevamo vedere applicate sul modello e poi implementare tutto sul firmware.....per terminare con una scheda HW dedicata (progettata e assemblata) che magari si può installare ovunque e programmare come si vuole.....l'idea del Submar-ino:cool:!!! Perciò se da qui a qualche tempo, il modello con tutta la meccanica, l'hw e il firmware aggiuntivi funziona come desiderato, sarebbe già un grande passo.....di sicuro gli storioni li lascio per una prossima volta!!

Link to comment
Share on other sites

Carissimo,

vedo tutto il lavoro che hai già fatto sull’elettronica, che è entusiasmante.

Ora capisco meglio anche i tuoi gusti: come scrivi, il piacere non è solo arrivare alla meta del modello funzionante, ma è anche il “viaggio” stesso: sviluppare da zero cotanta elettronica è certamente una bella soddisfazione, e il tuo entusiasmo traspare da quanto scrivi...

 

Se non posso aggiungere nulla sui temi elettronici (per quello c’è Gepard), invece posso portare la tua attenzione su quel po’ di fisica che regola il funzionamento del pressostato.

Dunque, mi sembra di capire che il modulo che tu usi ha un solo segnale assoluto di pressione.

Purtroppo, come ti ho detto, ciò non è ottimale perché la pressione della sacca piena va valutata in rapporto alla pressione interna nel WTC: quindi ti suggerisco vivamente di usare due moduli di pressione, se ciascuno ha un solo canale, dei quali uno dei due andrà connesso ad una derivazione del tubo della sacca, dopo la pompa.

In teoria si potrebbe lavorare con un canale solo, leggendo la pressione assoluta ma a patto di chiudere il WTC sempre allo stesso modo e con la sacca ugualmente piena. 

Ma se anche così fosse, ed è già difficile, tieni conto che un incremento della temperatura interna di 30 gradi, certamente possibile, aumenta la pressione interna di 100 mbar e falsa tutte le valutazioni.

Quindi, la misura differenziale della pressione direi che è indispensabile. Eventualmente la fai con un doppio modulo e calcoli la differenza via software con Arduino.

 

Vedo anche che hai previsto un check iniziale per verificare se il sensore è al "fondo scala" in fase di avvio elettronica --> fault sul LCD e LOG su SD -->  submarino non permetterà di utilizzare nessuna funzione.

Direi che va bene. Ci metti un LED che segnala l’anomalia, vero?

 

Invece, andrebbero sistemati i check di routine che hai previsto.

Cosa intendi per “check aumento pressione oltre il range prestabilito --> fault sul LCD e LOG su SD -->  attivo procedura fail safe (stacco propulsioni, imposto i timoni in "emersione" e attivo pompa peristaltica per emergere)”?

Se è il raggiungimento della massima pressione nella sacca, non è un allarme ma si tratta di una cosa che succede molto spesso: semplicemente, in questa condizione la pompa non deve più gonfiare la sacca, ma può sempre sgonfiarla su comando e questa non è una condizione di reale emergenza. Va solo inibito il comando di riempimento.

 

C’è poi il check che hai previsto se non avviene nessuna variazione di pressione pur avendo la pompa attiva --> fault sul LCD e LOG su SD -->  attivo procedura fail safe.

Ci può stare, perché vorrebbe dire che il motore non gira oppure la sacca è bucata.

Però considera che la pressione nella sacca cresce pochissimo finché la sacca è quasi piena e poi si impenna solo nell’ultimo 10% della capacità. Potrebbero esserci dei falsi allarmi se questo sistema non è abbastanza sensibile.

Io starei su un pressostato differenziale ben tarato ed eventualmente un sensore acqua a bordo.

 

Hai descritto anche la procedura di fail safe, prevedendo stacco propulsioni, timoni a risalire e pompa a svuotare, ma io correggerei mantenendo la propulsione con motore avanti, timoni di profondità a risalire e timone di direzione tutto da una parte, per risalire a spirale.

Questo ci può stare per allarme acqua a bordo, mentre per la perdita del segnale radio puoi usare la stessa procedura o magari anche solo la pompa a risalire, se il segnale radio è ballerino ma non proprio assente.

Invece, se hai allarme per batteria bassa devi svuotare la sacca ma tenere ferma la propulsione, per non stressare la LiPo sotto il suo voltaggio minimo (altrimenti booooooommmm!)

 

Infine, l’autoapprendimento: bella l’idea, ma vediamo di renderla veramente utile. Non serve avere chissà quanti livelli memorizzati di riempimento della sacca, perché finché il modello è emerso regoli ad occhio il galleggiamento.

La sacca tutta vuota si ottiene dopo un tempo sufficiente di pompa a svuotare, quella tutta piena di ha quando scatta il pressostato della sacca, e quindi è anch’essa facilmente raggiungibile.

Invece, potresti abilitare un’unica funzione aggiuntiva: dietro chiamata, in automatico il modello dovrebbe riempire la sacca fino a quando scatta il pressostato, e poi dare pompa indietro per 2-3 secondi, per svuotare la sacca del 10% circa. In questa condizione la spinta positiva è minima e il modello può immergersi e tenere la quota con i soli timoni, ma essendo leggermente positivo risalirebbe da solo in superficie se non lo vedi più e lasci i comandi o anche in caso di blackout totale.

E’ il massimo della sicurezza, ed è anche quello che il Dir ti suggeriva in un post precedente.

 

Per ora mi fermo qui. 

Come vedi, il mio scopo è darti degli input per fare un tuning dell’elettronica (che tu “mastichi” perfettamente) mirato ad una buona funzionalità del modello (per il quale io conosco i punti più critici)

Sempre senza esagerare, e tenendo al primo posto la sicurezza e la funzionalità.

 

Link to comment
Share on other sites

.....grande @Ocean's One.....vai che ci stiamo fasando  :thumbsup:

 

On 30/7/2020 at 23:00, Ocean's One said:

Come vedi, il mio scopo è darti degli input per fare un tuning dell’elettronica (che tu “mastichi” perfettamente) mirato ad una buona funzionalità del modello (per il quale io conosco i punti più critici)

 

Perfetto, hai colto in pieno quanto dicevo, faremo un giusto mix per la riuscita ottimale del modello!!! 

 

Partiamo dal semplice :biggrin:

 

On 30/7/2020 at 23:00, Ocean's One said:

Vedo anche che hai previsto un check iniziale per verificare se il sensore è al "fondo scala" in fase di avvio elettronica --> fault sul LCD e LOG su SD -->  submarino non permetterà di utilizzare nessuna funzione.

Direi che va bene. Ci metti un LED che segnala l’anomalia, vero?

 

Allora, per completezza ho diviso questo controllo in due, il primo è previsto in fase di avvio che sostanzialmente verifica se il pressostato è presente e sta comunicando. Funzionalità implementata come da video

 

 

praticamente viene fatto un check all'avvio del fw (firmware) e nel caso in cui non trova il pressostato (uno o due che siano) non è possibile continuare con l'utilizzo di Submarino; a questo punto viene indicato sul display il fault (guasto) e viene data indicazione di cosa fare. Come funzionalità è un po' eccessiva ma è tutelante :wink:.

In aggiunta per il momento faccio lampeggiare il LED presente sulla board di Arduino, in futuro sulla board dedicata capiremo cosa fare....magari possiamo prevedere un LED per ogni tipologia di guasto di colori differenti (anche un RGB unico) o una tempistica diversa di lampeggiamento del led....vedremo poi......ovviamente i dati sul display sono da mare....:happy:

 

 

Il secondo controllo (vero e proprio di lettura fondo scala) invece lo sto inserendo ogni volta che leggo il sensore, ovvero controllo se i dati ricevuti (pressione e temperatura) non sono oltre il fondo scala. Questo mi permette di avere un controllo sulla consistenza/correttezza dei dati ricevuti ogni volta che devo utilizzarli. Nel caso in cui i dati non andassero bene, essendo il pressostato un elemento cruciale del progetto, non vorrei navigare senza dati sulla pressione interna al WTC, perciò bisognerà prevedere anche in questo caso una procedura di "fail safe" (FS), di sicuro andrà scaricata la cassa d'immersione per far riemergere il sottomarino e magari propulsioni attive, timoni di profondità in emersione e timone direzionale su uno dei due fine corsa. Se per voi va bene darei il nome di Spiral_FS (sull'onda di quanto scritto nel precedente post da Ocean's One) a questa procedura di fail safe in modo tale da identificarla e richiamarla facilmente in futuro :cool:

 

Continuiamo con le cose semplici:biggrin:

 

On 30/7/2020 at 23:00, Ocean's One said:

Invece, andrebbero sistemati i check di routine che hai previsto. Cosa intendi per “check aumento pressione oltre il range prestabilito --> fault sul LCD e LOG su SD -->  attivo procedura fail safe (stacco propulsioni, imposto i timoni in "emersione" e attivo pompa peristaltica per emergere)”?

Se è il raggiungimento della massima pressione nella sacca, non è un allarme ma si tratta di una cosa che succede molto spesso: semplicemente, in questa condizione la pompa non deve più gonfiare la sacca, ma può sempre sgonfiarla su comando e questa non è una condizione di reale emergenza. Va solo inibito il comando di riempimento.

 

Concordo, prevedo solo una strategia di massimo riempimento.....

 

On 30/7/2020 at 23:00, Ocean's One said:

Hai descritto anche la procedura di fail safe, prevedendo stacco propulsioni, timoni a risalire e pompa a svuotare, ma io correggerei mantenendo la propulsione con motore avanti, timoni di profondità a risalire e timone di direzione tutto da una parte, per risalire a spirale. Questo ci può stare per allarme acqua a bordo, mentre per la perdita del segnale radio puoi usare la stessa procedura o magari anche solo la pompa a risalire, se il segnale radio è ballerino ma non proprio assente. Invece, se hai allarme per batteria bassa devi svuotare la sacca ma tenere ferma la propulsione, per non stressare la LiPo sotto il suo voltaggio minimo (altrimenti booooooommmm!)

 

Non avevo pensato nel discriminare i vari eventi di fail safe sui guasti mentre così è molto meglio e ben pensata come strategia. A tal proposito farei nascere un nuovo nome per questa strategia Wo_Prop_FS (without propeller FS), ovvero scarico la cassa d'immersione, blocco i servo e stoppo le propulsioni (magari metto anche l'elettronica in basso consumo).

Tenete presente che nell'implementare le varie funzionalità precedenti, man mano che scrivo il firmware vi aggiorno e ne discutiamo ulteriormente nei dettagli!!

 

Passiamo alle ultime due note "dolenti" :doh:, lettura differenziale pressostato e autoapprendimento.

Riguardo la lettura differenziale, non ci sono problemi da un punto di vista hardware nell'inserire un ulteriore pressostato, il peso è di 3 g come board e viaggia su I2C perciò non avrò altri pin aggiuntivi da prevedere ma dovrò solo indirizzarlo diversamente sul bus. Riguardo il concetto della misura e i vantaggi che ne conseguono mi sono chiari (anche se probabilmente si complicherà non poco il sistema) ma non capisco come installeresti il secondo sensore, ovvero il primo lo lasciamo in un punto qualsiasi del WTC e il secondo dovrei "appiccicarlo" sul tubicino verso la cassa dopo la pompa? o magari sulla pompa stessa?

 

Infine per l'auto apprendimento, hai realmente descritto un AUTO-apprendimento.....e direi che è fattibile. :thumbsup:

Io invece stavo pensando a qualcosa di manuale, ovvero è l'utente che sceglie il massimo valore d'immersione del sottomarino e Submarino memorizza tale valore come massimo riempimento della cassa, riscalando tutta la dinamica. Una routine del tipo, attivo una procedura di apprendimento cassa d'immersione, submarino comincia a riempire la cassa e man mano che il sottomarino si immerge, l'utente a suo piacimento sceglie quale deve essere il valore massimo d'immersione (non per forza la massima capienza della cassa), mediante uno switch su radiocomando.......in ogni caso mi sembra più furba la tua strategia perché prevede anche qualche percentuale di margine sul riempimento.

 

Riguardo le tue seguenti considerazioni

On 30/7/2020 at 23:00, Ocean's One said:

Ma se anche così fosse, ed è già difficile, tieni conto che un incremento della temperatura interna di 30 gradi, certamente possibile, aumenta la pressione interna di 100 mbar e falsa tutte le valutazioni.

........

Però considera che la pressione nella sacca cresce pochissimo finché la sacca è quasi piena e poi si impenna solo nell’ultimo 10% della capacità. Potrebbero esserci dei falsi allarmi se questo sistema non è abbastanza sensibile.

 

Il legame da te indicato è assolutamente da tene presente nella scrittura del firmware altrimenti si rischia di combinare pasticci e la cosa si complica ulteriormente....perciò mi sto studiando più attentamente il datasheet del pressostato anche se il suo utilizzo è "mascherato" da librerie dedicate scritte da altri....vediamo se sarà necessario modificare anche quelle :doh:

Considera che la sensibilità di questo sensore è molto spinta, da datasheet riportano una accuratezza assoluta di 1 - 1.7 mbar (e risoluzione 0.0016 mbar) perciò credo che riusciremo a discriminare anche le piccole variazioni di pressione nella fase iniziale di riempimento cassa (discriminandole dal rumore di fondo eventuale in lettura)......sicuramente con i primi test si chiariranno meglio tante cose :biggrin:

 

Vi lascio un video aggiuntivo......sto inserendo anche una prima interfaccia a menu sul display per rendere più agevole l'utilizzo di Submarino

 

 

non avendo tasti sotto mano mi sono attrezzato con un po' di fili e le resistenze interne di pullup del micro......con il Joystick 5 vie e il toggle implementato sarà tutto più semplice!! :dribble:

Per il momento non riesco a farvi vedere alcuni sottomenu presenti....devo prima ottimizzare il codice gestendo meglio le memorie del micro (RAM/flash) altrimenti con la gestione display saturo tutto :doh:

 

___________________________________________

P.S.: solo un chiarimento, ho scritto nel post precedente LCD, in realtà è un display OLED, perciò utilizzerò quest'ultimo nome per il futuro.

 

P.S.2:  per il momento non ho implementato la funzionalità della memorizzazione dati su memory card, perciò i guasti saranno solo riportati sul display in una fasce più avanzata e stabile del firmware sarà presente anche il Log dati durante l'utilizzo.

Edited by Call_Me_V
Link to comment
Share on other sites

3 hours ago, Call_Me_V said:

l'utente a suo piacimento sceglie quale deve essere il valore massimo d'immersione (non per forza la massima capienza della cassa), mediante uno switch su radiocomando....

 

Buona sera a tutti,

Vincenzo, leggendo gli ultimi aggiornamenti mi era venuto in mente lo stesso pensiero...

Trovare un modo per dire al pressostato qual'è la pressione minima e massima, al di là di come di volta in volta tu vorrai chiudere il wtc.... questo ti permette una gestione "più  sciolta" della chiusura del cilindro.

Quindi ricapitolando tu chiudi il cilindro con la sacca gonfia a metà , e poi la svuoti completamente. A operazione completata con uno switch dici a arduino "pressione minima" , oltre questa disabilita il comando emersione.

Poi metti il modello in acqua e sempre manovrando la pompa in manuale cerchi il giusto riempimento, ed una volta ottenuto dici con lo switch "pressione massima", oltre questo valore inibire il comando immersione. 

Dopo di che ti rimane il gusto del pilotaggio a cuor leggero sicuro che il tuo direttore di macchina Mar_ino Sub gestirà la cosa al meglio 😉

Link to comment
Share on other sites

Ciao Andrea,

 

17 hours ago, andreavcc said:

Dopo di che ti rimane il gusto del pilotaggio a cuor leggero sicuro che il tuo direttore di macchina Mar_ino Sub gestirà la cosa al meglio 😉

 

perfetto, l'idea era quella :wink:

Considera che passando attraverso Arduino, tutti i segnali della ricevente (leve e switch) possono assumere qualsiasi pilotaggio e/o possono essere usati e riutilizzati come si vuole......nel senso che si decide quale deve essere la procedura per entrare nella routine di configurazione, tipo con i tasti si seleziona sul display la procedura di "ricerca dati immersione", poi parte un timer di 3-5 minuti in cui l'utente ha la possibilità di richiudere il WTC e il sottomarino per poi metterlo in acqua. A questo punto con uno switch/leva sul comando si scarica la cassa caricata a metà (o altro), come da te indicato e a quel punto si trova la giusta immersione caricando la cassa gradualmente e con uno switch/leva si chiude la procedura. A quel punto il sottomarino memorizza tali dati e si mette in automatico in una configurazione "guida/utilizzo", riconfigurando gli ingressi da ricevente e le uscite verso servi/motori per permettere un utilizzo normale. 

 

Perciò possiamo decidere qualsiasi strategia da implementare a nostro uso e consumo......dobbiamo solo definire i dettagli volta per volta e principalmente avere una buona affidabilità sul pressostato per evitare danni!!! 

 

Volevo anche sottolineare che questa strategia non esclude quella automatica di @Ocean's One, anzi possiamo prevederle entrambe :biggrin:

 

Edited by Call_Me_V
Link to comment
Share on other sites

Solo qualche commento per Andrea e per Vincenzo.

 

@andreavcc

Concordo in pieno sui livelli min e max di pressione, solo che questi livelli devono essere differenziali e non assoluti.

Infatti, se fossero assoluti, sarebbe molto diverso riempire la sacca  a 1080 mbar contro una pressione nel WTC di 1000 mbar, oppure di 1100 bar! Nel secondo caso la sacca rimarrebbe completamente vuota.

Urge un pressostato, anzi un manometro, relativo e non assoluto.

 

@Call_Me_V

Innanzitutto rispondo alla tua domanda sulla disposizione dei pressostati/manometri.

Partendo dall'esterno: presa d'acqua => tubo verso la pompa => pompa => tubo verso la sacca => derivazione a T =>  tubo verso il pressostato => pressostato per p sacca / (e sull'altro ramo del T) => tubo verso la sacca => sacca. 

(prevedi solo un addolcimento della lettura istantanea del pressostato quando la pompa è in funzione, perchè farà un po di salti...)

Il secondo pressostato misurerà invece la p interna al WTC e non richiede particolari connessioni, mentre come hai visto il pressostato per p sacca avrà bisogno di una connessione idonea per il tubo.

_________

 

Aggiungo infine che i metodi di apprendimento proposti da Andrea e da me non sono poi così diversi: per entrambi va comunque bene la conferma manuale al raggiungimento della sacca piena come dedotto osservando il modello in acqua; il metodo di Andrea prevede di memorizzare la pressione di riferimento a sacca piena in modo ottimale, mentre il mio prevede di definire il tempo di svuotamento (3-4 s?)dopo aver raggiunto la sacca piena per avere l'assetto di immersione ottimale.

Entrambe le logiche non hanno nulla di difficile, dipende solo se Submar-Ino preferirà memorizzare una pressione oppure un tempo di riferimento.

Ciò ovviamente dipende dai gusti del suo programmatore...

 

Link to comment
Share on other sites

Comincio a pensare che il pressostato mi perseguiterà per tutto il progetto :doh:

 

On 3/8/2020 at 22:02, Ocean's One said:

Partendo dall'esterno: presa d'acqua => tubo verso la pompa => pompa => tubo verso la sacca => derivazione a T =>  tubo verso il pressostato => pressostato per p sacca / (e sull'altro ramo del T) => tubo verso la sacca => sacca. 

 

.....stavo immaginando il doppione del primo pressostato.....ma a quanto pare ero fuori strada....questo stravolgerebbe non poco l'architettura!! Comunque faccio qualche valutazione su quest'ultima proposta, continuo l'approfondimento del BMP280 e ti dico :wink:

 

On 3/8/2020 at 22:02, Ocean's One said:

Entrambe le logiche non hanno nulla di difficile, dipende solo se Submar-Ino preferirà memorizzare una pressione oppure un tempo di riferimento.

 

concordo sulla difficoltà, nulla di complicato, rispetto la scelta pressione/tempo vi saprò dire meglio appena implemento la funzionalità.....ne riparliamo a breve!!! 

_______________________________________________

 

Visto che la volta scorsa non vi avevo postato il video della pampa, lo faccio ora

 

Nel recipiente sono presenti circa 120 g di acqua......la pompa non sforza (ho lasciato l'audio in questo video perciò mettete le casse a tutto volume:biggrin:) e spero che continui così anche con la cassa d'immersione presente!! Nel video vedete il CH 2 cambiare in modo proporzionale alla posizione dello stick sinistro. Ho sistemato varie parti del firmware e ora riesco a pilotare due servo, la pompa e la propulsione.....ma il viaggio è ancora lungo :smile:

 

Vedo di realizzare una cassa d'immersione abbozzata con un pallone da festa "bello spesso" e vi dico come va.....in modo tale che poi passo allo step successivo di mettere tutto nel WTC e allora cominceremo a divertirci con il pressostato!! :dribble:

 

Edited by Call_Me_V
Link to comment
Share on other sites

Visto che il sistema sta rispondendo bene e visto che in questo momento non riesco a realizzare una cassa d'immersione con camera d'aria di bicicletta (come consigliatomi da @Ocean's One) mi sono attrezzato per recuperare un bel pallone da festa di compleanno :smiley25:

20200807_014248.thumb.jpg.6f69b9f8ec800454be1e4fe3fe12257b.jpg

 

abbastanza spesso e ho fascettato accuratamente un tubo da 4 mm diametro esterno e 2 mm diametro interno. A questo punto ho fatto un po' di prove di riempimento con la pompa e in fine l'ho riempito con 140 g di acqua e lasciato pieno e attaccato alla pompa priva di alimentazione per 6 ore......nessuna perdita. Direi che qualche prova "abbozzata" con il WTC si possa fare!!! :smiley26:

 

Vi posto un video della prova di riempimento e svuotamento del palloncino

 

devo dire che la pompa/motore continuano a comportarsi egregiamente, non riesco in questi giorni a misurare le correnti/assorbimenti ma farò tutto successivamente. Ovviamente la posizione del tubo nel palloncino non è da lasciare al caso e andranno tenuti un po' accorgimenti per non avere problemi (esempio la pompa non pesca bene l'acqua) in fase di svuotamento cassa immersione!!

 

......e ora si passa alle cose serie, ottimizzo il necessario e inserisco tutto nel WTC :cool:

 

Link to comment
Share on other sites

Vincenzo, per l'acquisto della sacca ti consiglio questo sito. E' in oriente quindi i tempi di spedizione non sono proprio immediati, ma il venditore è affidabile ed è munito di un po di chincaglieria utile ai nostri scopi 😉

Link to comment
Share on other sites

Grazie del link Andrea, hanno cose molto interessanti e ho trovato anche due sacche che farebbero al caso mio, una principalmente a singolo tubo da 120 g....se la realizzazione della sacca con camera d'aria con Ocean's One salta, acquisto una di queste.....per quanto ti devo dire che il palloncino da festa fa la sua funzione :biggrin: magari due palloncini così uno nell'altro potrebbero essere un po' più sicuri!!

 

Link to comment
Share on other sites

Call_Me_V,

il consiglio che vorrei darti e di non realizzare  i componenti a tutti i costi, se questi si trovano già in commercio.

Certamente saresti in grado di costruirti una sacca partendo dalla gomma della camera d’aria, ma perché farlo?
Stai già portando innumerevoli innovazioni sul tuo modello, che per la sacca di immersione è senz’altro preferibile scegliere qualcosa di esistente, secondo me.

Oltretutto, se da quel sito scegli una sacca a doppio tubo, potrai collegarne il secondo direttamente al pressostato, evitando sdoppiamenti a T e raccorderia varia.
_________
 

In aggiunta a tutto ciò, hai visto che nel sito segnalato da Andrea si può anche acquistare un micro-pressostato differenziale (300 mbar)?

Certo, quello è un semplice contatto aperto-chiuso che scatta oltre la pressione impostata, ma pensandoci bene è proprio quello che ti serve per controllare il troppo-pieno della sacca.
Poi, se vuoi, tieni pure anche un manometro assoluto per la pressione interna nel WTC, che dialogherà con il tuo amato Arduino.

Lo so, immagino che anche in questa situazione tu senta il bisogno di lasciare la tua impronta. Allora considera che un miglioramento si può apportare anche a questa semplice elettronica: per ora il contatto di questo pressostato è normalmente aperto, che si chiude solo al raggiungimento della pressione limite, ma questa non è la condizione più sicura.

Infatti, cosa succederebbe se dopo la manutenzione periodica ti dimenticassi di ricollegare il cavo del pressostato?
Al raggiungimento della pressione limite la pompa continuerebbe a funzionare distruggendo la sacca.

(per inciso, questa cosa mi è già successa una quindicina di anni fa sul mio Neptune, prima che avvisassi la Thunder Tiger di modificare il pressostato).

L’intervento correttivo è in effetti abbastanza semplice: in parallelo al contatto normalmente aperto, salda una resistenza di valore molto elevato, di qualche migliaio di Ohm.

In questo modo, la tua mirabile elettronica potrà fare un check iniziale sulla presenza del pressostato andando a leggere una resistenza elevata, ma non infinita.
Nel caso invece che il pressostato non fosse collegato, la mancata lettura di un valore finito di Ohm non consentirebbe l’utilizzo del modello.

Poi, in caso di funzionamento normale, la chiusura del contatto del pressostato a zero Ohm darebbe il segnale di arresto pompa.

 

Bene, ecco la mia ulteriore piccola dose di consigli, nella speranza che ti possano risultare utili.

 

Edited by Ocean's One
Link to comment
Share on other sites

Submarino... submarino... submarino... hmmm... come nome per questo sistema di controllo di navigazione integrato a prova di guasto con logica migliorata digitalmente, non riesco proprio a farmelo piacere.

 

Certo, è per modelli di sottomarini (prefisso sub-)...

Certo, è basato su Arduino (suffisso -ino)...

Certo, è originale  per via della storpiatura/fusione dei termini "sottomarino" / "submarine" / "arduino" che sembra il risultato di una metamorfosi magmatica...

 

Però, a mio parere, lo trovo... come dire... stonato e poco altisonante per rappresentare un sistema che è in fase di progettazione e sviluppo da parte dei migliori tecnici ed esperti di Betasom (e ho detto tutto) e  che ha il potenziale di diventare il corrispettivo per il modellismo navale in scala dei famosi ArduPilot(*) e MultiWii(**).

 

(* Sì lo so, c'è ArduSub che però 1.non gira su hardware di bassa potenza come i piccoli ATMega che equipaggiano le schede Arduino e 2.è esclusivo per i ROV e non per i modelli in scala)

 

(** MultiWii con le sue mille e mille configurazioni può controllare qualsiasi cosa sia in grado di volare, gira sulle schede Arduino e può essere una buona fonte di ispirazione ma dal punto di vista dell'implementazione del SW, proprio a causa delle sue mille e mille configurazioni, è un vero incubo, non sto ad entrare nel dettaglio ma se volete dare un'occhiata il link punta al mio fork github in cui ho provato con estrema fatica a fare un po' di ordine)  

 

Ora, poichè non mi sento di far parte di qesto fior fior di tecnici ed esperti, mi limito a proporre le mie strambe idee su cose futili ed inutili e pensa che ti ripensa, oggi mi è venuta l'ispirazione per un nome che a me piace: DELFINO (tutto maiuscolo).

 

Perchè il termine DELFINO:

  1. Il Delfino è stato il primo sottomarino della Marina Militare Italiana.

    Questo sistema ha tutte le caratteristche per diventare il primo computer di bordo per modelli naviganti partorito da menti Betasom.
     
  2. Le caratteristiche dei delfini le conoscete tutti: sono ottimi nuotatori, sono mammiferi quindi necessitano di aria per respirare (come i sommergibili) ma possono stare in immersione molto a lungo (come i sottomarini), hanno capacità di ecolocalizzazione, sono animali sociali ed estremamente socievoli e posseggono capacità comunicative notevoli.

    Questo sistema ha le potenzialità per fornire ai nostri modelli le stesse prestazioni di un delfino (ecolocalizzazione, comunicazione e socializzazione compresi)
     
  3. Ha il suffisso -ino.

    Beh, questo sistema è basato sulla tecnologia Arduino.
     
  4. E' un nome sufficientemente generico e qiundi forse non dovrebbe cozzare con nessun marchio registrato.

Ok, bel nome, ma... che c'azzecca (come direbbe qualcuno) ?

 

Già, che c'azzecca ? boh ? e allora pensa che ti ripensa, dopo aver consultato tutti i Manuali Delle Giovani Marmotte e tutte le storie con Qui, Quo, Qua, il Gran Mogol e i loro compagni, ho trovato il collegamento, e capirete anche perchè deve essere scritto tutto maiuscolo, eccolo qui:

D       Digitally
 E      Enhanced
  L     Logic
   F    Fail safe
    I   Integrated
     N  Navigation
      O cOntroller

 

Ok, questo è il meglio che abbia partorito, vuole dire tutto e non vuol dire nulla (mi viene in mente Raul Cremona che imita Silvan: "Signori guardate, che cosa sto facendo ? Niente ma lo sto facendo molto bene !").

 

Essendo il sistema in progettazione/sviluppo un sistema aperto ho pensato che anche il suo nome lo debba essere, indicando solo che implementa un "generico" ausilio digitale alla navigazione sicura dei nostri modelli navali (sommergibili, sottomarini, ROV, UUV, AUV, o, perchè no, di superficie)

 

Inoltre sia il termine DELFINO sia la descrizione dell'acronimo sono sufficientemente generici e agnostici riguardo la piattaforma hardware quindi non strettamente legati alle schede basate su Arduino.

 

Che ne pensate ?

Edited by gepard
Link to comment
Share on other sites

Che dire Gepard, splendidamente Italico, almeno fino all'anagramma... un nome che riporta al mare, ad antiche glorie, a destrezza nella navigazione. Personalmente non potrei che essere d'accordo 😉

Link to comment
Share on other sites

@gepard per me l'idea è buona, per quanto il nome sia molto impegnativo se lo si considera e associa alla Marina Militare e al battello omonimo.....direi tanto impegnati per un progettino di questo tipo!!  :smile:

 

A Submarino non ci sono particolarmente affezionato, è stato un nome "di getto" che come da te anticipato associa due mondi ma il tuo ragionamento fila e l'anagramma è anche ben studiato, perciò visto che non ho voce in capitolo riguardo i trascorsi storici del battello Delfino....mi affido al vostro giudizio, di sicuro se a voi piace, sarei contento che un sistema nato nella base possa portare un nome così importante :wink:

 

 

16 hours ago, gepard said:

Ora, poichè non mi sento di far parte di qesto fior fior di tecnici ed esperti, mi limito a proporre le mie strambe idee su cose futili ed inutili e pensa che ti ripensa,

 

non dirlo neanche, il tuo supporto sarà utile e fondamentale.....anzi se hai un po' di tempo a disposizione e l'idea ti può piacere possiamo sviluppare il firmware a 4 mani. Dimmi tu!!

 

16 hours ago, gepard said:

(** MultiWii con le sue mille e mille configurazioni può controllare qualsiasi cosa sia in grado di volare, gira sulle schede Arduino e può essere una buona fonte di ispirazione ma dal punto di vista dell'implementazione del SW, proprio a causa delle sue mille e mille configurazioni, è un vero incubo, non sto ad entrare nel dettaglio ma se volete dare un'occhiata il link punta al mio fork github in cui ho provato con estrema fatica a fare un po' di ordine)  

 

La nostra chiacchierata/aperitivo a Lingotto di qualche anno fa su questa idea è più viva che mai, ho visto i tuoi progressi sul fork, complimenti:smiley19:.....per quanto, partire da esso per questo primo sviluppo mi è sembrato "troppo", magari in futuro, quando avremo un hardware stabile e una board dedicata potremo pensare di riadattare il tutto.

In più l'idea di partire nello sviluppo di un firmware "da zero", discutendone le strategie passo dopo passo e trovando le migliori soluzioni insieme alle migliori menti della base mi allettava molto di più :biggrin:

 

____________________

 

@Ocean's One non mi sono dimenticato dei tuoi consigli, sto approfondendo un po' di dettagli per farti "una proposta che non potrai rrrifutare"  (con accento siciliano ovviamente)!!!!

 

 

Edited by Call_Me_V
Link to comment
Share on other sites

20 minutes ago, Call_Me_V said:

In più l'idea di partire nello sviluppo di un firmware "da zero", discutendone le strategie passo dopo passo e trovando le migliori soluzioni insieme alle migliori menti della base mi allettava molto di più :biggrin:

 

Ti posso assicurare che sono pienamente d'accordo con te, MultiWii servirà per raccattare un po' di algoritmi e idee di codice ma anche io sono dell'idea che sia più "pulito" partire da zero.

 

In questi giorni sto lavorando al codice per acquisire gli impulsi PPM compositi utilizzando un solo pin del processore.

 

Non si tratterà di un semplice campionamento, sto aggiungendo la funzionalità di DSR (Digital Signature Recognition) per "riconoscere" la trasmittente e, se accoppiata ad un opportuno encoder a lato trasmittente di avere la possibilità di comandare in multiplex sulla stessa frequenza fino a 16 modelli (1 attivo e 15 in stand-by) oltre a gestire una quantità elevata di comandi proporzionali e digitali ON/OFF olte ai  4 proporzionali diretti dei i joystick:

 

(12 proporzionali multiplexati + 40 ON/OFF multiplxati) * 16 per un totale di 192 prop multiplex + 56 on/off multiplex per ogni modello

 

Usando 10 canali in un frame di trasmissione della durata di 22.5ms.

 

In un sottomarino tutti sti comandi non servono ma posso immaginare una nave di superficie con tutti i cannoni, le torrette, gli argani e chi più ne ha ne metta.

Link to comment
Share on other sites

59 minutes ago, gepard said:

In questi giorni sto lavorando al codice per acquisire gli impulsi PPM compositi utilizzando un solo pin del processore.

 

Molto interessante, hai già postato qualcosa su github o altro?

.....allora immagino che sarai preso.....comunque, se e quando vorrai la proposta di sviluppo a 4 mani è sempre valida :wink:

Link to comment
Share on other sites

...non vi seguo più. Mi perdo qui... finchè l'elettronica ha la funzione di rendere flessibile e adattabile la mera meccanica, ancora comprendo la logica che governa ceri imput. Ora però sono tagliato fuori. E aver cliccato sui link mi è stato solo di sconforto. Mi resta però la profonda ammirazione per le vostre capacità. Ingegneri che riescono a porre la scienza allo stesso piano della passione. Che rendono logica e gioco possibili. Io conto poco, ma il tifo per voi lo faccio. 

Link to comment
Share on other sites

Fanghino,

ti dirò, non li seguo più neanch’io!

In fatto di elettronica Gepard e Call_Me_V sono TROPPO avanti!

 

Ma va bene così, non c’è da dispiacersi: ognuno è esperto nel suo, e il bello di questa base è proprio riuscire a mettere insieme competenze diverse.

Io posso dire la mia per quanto riguarda il progetto è il bilanciamento del battello, ma lascio senz’altro a loro la messa in pratica delle singole funzionalità attraverso i dispositivi elettronici.

Considera che ogni grosso progetto è costituito da molte attività, nelle quali il singolo può essere attore o semplice utilizzatore: per esempio io mi accontento di chiedere alcune funzionalità ben definite all’elettronica, come lo spegnere la pompa al raggiungimento di una pressione definita. Come questo si trasformi in una serie di istruzioni software da impartire ad Arduino, beh, lo lascio ai due esperti di cui sopra!


Poi, il contrario c’è stato quando Call_Me_V Ha avuto bisogno di istruzioni circa il bilanciamento del battello: in quel caso sono stato io a dare il mio contributo, mentre lui era l’utilizzatore di queste informazioni.

 

Vedi quindi il bello della nostra Base: ognuno fa la sua parte, e sono sicuro che risultati saranno molto appaganti!

L’unione fa la forza, e qui a Betasom siamo certamente molto uniti


________
 

Edit:
Gepard, DELFINO è un nome impegnativo, ma certamente adatto.

Mi chiedo solo se, per renderlo un po’ meno generico, non si possa scrivere in modo più caratteristico

Magari D.E.L.F.I.N.O. oppure Delf-INO oppure D.E.L.F.INO (Diving ELectronics For arduINO)

 

Edited by Ocean's One
Link to comment
Share on other sites

Iscandar, a ciascuno il suo.

Spesso notiamo il tuo contributo, che di solito è di natura storico-informativa. Ti ricordi che, quando si è trattato di cercare la posizione esatta della linea di galleggiamento del Kilo, tu hai supportato Call_Me_V con delle valide immagini di riferimento?

Quindi, come vedi, la squadra ha bisogno di tutti... 👍

Link to comment
Share on other sites

Pienamente d'accordo con tutte le considerazioni fatte!!!

 

Riguardo il nome

9 hours ago, Ocean's One said:

Magari D.E.L.F.I.N.O. oppure Delf-INO oppure D.E.L.F.INO (Diving ELectronics For arduINO)

 

I punti tra le lettere li sconsiglierei pur concordando sul fatto di anagrammare il nome. In ogni caso mi è parso di capire che la proposta di cambio nome sia passata, magari scritto come DELFino 🐬 :biggrin:

 

Link to comment
Share on other sites

ci siamo quasi.....dopo vari tentativi di inserire tutto nel WTC per fare le prove con pompa e pressostato, mi sono piantato perché ovviamente la breadboard con tutti i fili volanti (a rischio di disconnessione e/o corti) non erano la migliore scelta.....anche per un primo test!!!

20200807_162415.thumb.jpg.59e5d2ca50697a3fdffa1723711a27c6.jpg

 

Perciò ho recuperato una millefori e collegato il tutto

20200814_094755.thumb.jpg.a17cae802e0acfd4073d950646637692.jpg20200814_094805.thumb.jpg.c8bfb1e5af661d3f4f749b996d3fe860.jpg

20200814_095018.thumb.jpg.ea5a7cfdcf7d15e6a8cf26df169202f9.jpg

 

devo solo finire di sistemare/ottimizzare il firmware perché purtroppo la libreria del display OLED occupa metà della memoria di Arduino (circa 1K di 2K di SRAM) :doh: e tra librerie di servo, BMP280, protocolli e un minimo di logica.....diciamo che non siamo messi benissimo!! Questo solo per dirvi che su una delle varianti di board definitiva di DELFino non ci sarà un ATmega 328P (del nano) ma un 2560 (del mega). Così darà alla scheda maggiore possibilità di utilizzo.

 

Entro domani parto con le prime prove e vi aggiorno......:cool:

 

Edited by Call_Me_V
Link to comment
Share on other sites

2 hours ago, Call_Me_V said:

purtroppo la libreria del display OLED occupa metà della memoria di Arduino (circa 1K di 2K di SRAM)

 

Immagino che l'OLED sia un dislay grafico e quindi abbia bisogno in un buffer di memoria pari alla dimensione in pixel X*Y, corretto ?

 

Per la versione HW definitiva hai visto se esistono display su bus I2C che siano solo testuali (in questo modo occorrerebbe mandargli solo le stringe del testo da visualizzare) ?

 

Anche con processore più "capiente" mi sembra uno spreco di risorse usare tanta RAM per un componente che sarebbe utilie solo con battello aperto e all'asciutto.

 

Link to comment
Share on other sites

36 minutes ago, gepard said:

Immagino che l'OLED sia un dislay grafico e quindi abbia bisogno in un buffer di memoria pari alla dimensione in pixel X*Y, corretto ?

 

Si, il ragionamento è corretto, il display OLED è un 128x64 con un buffer da 1k. 

 

2 hours ago, gepard said:

Per la versione HW definitiva hai visto se esistono display su bus I2C che siano solo testuali (in questo modo occorrerebbe mandargli solo le stringe del testo da visualizzare) ?

 

I display di cui parli non mi entusiasmano a livello di resa, se li consideri così integrati. Perciò al massimo converto il display OLED 128x64 in un 128x32, con un guadagnando di 512k in memoria, però almeno mantengo il display grafico.

Dovremmo fare un discorso più ampio ma non vorrei aprirlo ora, visto che di 'carne al fuoco' ne abbiamo tanta.....ma il sistema a cui sto pensando e verso cui vorrei andare è un sistema scalabile in hw e sw, perciò in una variante per sottomarini di piccola taglia si potrà prevedere un OLED 128x32 o magari eliminarlo proprio e considerare altre tipologie di feedback.

 

Link to comment
Share on other sites

E se al posto del display si mettesse un modulo bluetooth BLE 4.0 (compatibile anche con iOS, i bt classici NON funzionano con iOS) ?

 

In questo modo:

 

1) DELFino trasmetterebbe solo i dati grezzi senza richiedere chissà quali risorse di memoria e processore

2) sarebbe anche un canale di input ad esempio per impostare i fail safe e un sacco di altre cose interessanti operando solo da smartphone con una connessione priva di interferenze (per via del pairing BT)

3) il tutto potrebbe avvenire sia a battello aperto che a battello chiuso e in navigazione di superficie entro una certa distanza.

Link to comment
Share on other sites

@gepard in realtà hai anticipato un argomento interessante ma che avrei voluto proporvi in futuro a "bocce ferme" (a livello di sistema), ovvero la connessione bidirezionale tra battello e uno smartphone o altri dispositivi, per permettere lo sharing (bidirezionale) di dati di qualsiasi tipo.......e per battelli grossi (dotati di telecamera), perché no anche lo streaming video a 2.4 GHz fatto dalla superficie :biggrin:

 

Però al posto di una connessione Bluetooth stavo pensando a una connessione wifi client/server o magari Serverless (distribuita) sui 2.4 GHz, questo comporterebbe non pochi vantaggi. Infatti a tal proposto, qualche settimana fa ho cominciato a fare delle prove della reale possibilità di implementare un sistema di questo tipo e quindi ho realizzato vari test per verificarne la fattibilità. Vi posto due video a riguardo

 

 

Praticamente nel WTC e sulla breadboard inquadrata ci sono due dispositivi wifi, il primo funge da server e rileva le informazioni dal pressostato (temperatura/pressione), il secondo da client e richiede i vari dati che poi visualizza sul display OLED. Non considerate la latenza di aggiornamento dei parametri a video perché per rapidità ho lasciato tutto lo stack TCP/IP con anche delay di vario genere.

Come potete notare si riesce a stabilire una connessione superficiale ma anche in immersione......ovviamente nel test condotto non sono in un laghetto con tutte le problematiche del caso (acqua sporca, distanza, interferenze e via dicendo) ma in una condizione abbastanza positiva.....ma questo serviva solo per capirne la fattibilità e direi che è fattibile :thumbsup:

 

.....cominciate a pensare le varie applicazioni ma comunque ne riparliamo in dettaglio più avanti :biggrin: per i momento sto mangiando pane e pressostato!!!

Link to comment
Share on other sites

  • 2 weeks later...

.....dopo la fine della vacanze e l'inizio delle attività lavorative......è ora di riprendere anche il cantiere da dove avevamo lasciato, per il momento non trattando ancora l'argomento wifi che sarà un tema da chiusura cantiere ma riprendendo dal nostro amato pressostato!!!

 

Come vi dicevo in precedenza, vorrei fare "una proposta che non si può rrrrifiutare" (si sente l'accento siciliano?) ma vorrei arrivarci dopo un minimo di analisi di alcune caratteristiche del pressostato. Magari qualcuno avrà già sfogliato la scheda tecnica che avevo postato un po' di tempo fa, in ogni caso lasciatemi fare un preambolo del sensore, che non vuole essere una riscrittura del datasheet ma cercherò di fare un "breve" sunto delle caratteristiche più salienti legate al cantiere.

 

Il BMP280 è un sensore MEMS della Bosch con una tecnologia proprietaria APSM (Advanced Porus Silicon Membrane - una particolare tecnologia di realizzazione del componente), pensato per varie tipologie di mercati, dall'automotive al consumer ma principalmente realizzato per applicazioni "mobile".  Non è altro che un sensore barometrico assoluto di pressione all'interno di un package 2 x 2.5 mm^2 e vista la sua integrazione, bassi consumi, misure estremamente precise/accurate, reiezione ai disturbi, possibilità di configurazione, protocolli di comunicazione disponibili.....e chi più ne ha più ne metta......è diventato un riferimento in campi d'impiego più disparati.....e speriamo che vada bene anche per DELF-ino.

 

Solo per dare un'idea, essendo stato progettato per applicazioni in cui è richiesta un'accuratezza/risoluzione/sensibilità molto alta, il sensore ha un'accuratezza relativa dell'ordine di +-0.12 mbar (+- 1 metro riconsiderandola come variazione di altitudine), il tutto con un coefficiente di offset in temperatura (TCO) mooooolto basso, dell'ordine dei 0.015 mbar/k. Quest'ultimo parametro è intrinseco nei sensori di pressione, ovvero la temperatura influisce sull'accuratezza dei sensori di pressione e quindi rimane sempre un piccolo errore di temperatura nel campo di temperatura nominale nonostante un'ampia gamma di misure di compensazione. Tale coefficiente descrive un errore (lineare), a partire da un punto di riferimento (in generale la temperatura ambiente), perciò sempre "presente/predicibile", perciò non ce ne preoccupiamo più di tanto.  Ci sono tanti altri parametri da considerare in aggiunta (reiezione dai disturbi/rumore, affidabilità nel ciclo vita e via dicendo), ma questo è solo per dire che tale dispositivo è estremamente sensibile.

 

Considerando invece la logica, il BMP280 consiste in un sensore di pressione piezo-resistivo associato a un ASIC (ovvero Application Specific Integrated Circuit, un circuito integrato creato appositamente per risolvere un'applicazione di calcolo/elaborazione ben precisa), per capire è l'opposto di Arduino, programmabile per qualsiasi scopo. Questo dispositivo dedicato alla lettura del sensore, non fa altro che effettuare delle conversioni analogico/digitali del dato misurato, a cui può applicare dei filtri/compensazioni per poi renderlo disponibile su un bus di comunicazione SPI o I2C......e qui si aprono vari mondi ma per evitare di fare un trattato e annoiarvi eccessivamente,  visto che chiunque si è confrontato con un Arduino ne ha sicuramente sentito parlare, senza scendere troppo nei dettagli il bus adottato è l'I2C. Solo per comprensione, diciamo che (in modo molto blando) per i meno addetti ai lavori, questo protocollo di comunicazione I2C altro non è che la "lingua" con cui Arduino interroga il sensore e riceve i risultati. In aggiunta, attraverso questo linguaggio, i sensori "intelligenti" danno la possibilità all'utilizzatore non solo di richiedere/ricevere i dati ma anche di configurare il sensore per "lavorare in diversi modi", per esempio variarne l'accuratezza di misura, il tempo di misura, i consumi e così via. Direi che come intro basta e avanza!!

 
Vi riporto una brevissima analisi dei parametri più importanti che ho impostato nel sensore.

Partiamo dalle tre tipologie di funzionamento, ovvero il sensore può lavorare in "sleep/forced/normal mode". Nella prima modalità il dispositivo semplicemente non effettua nessuna misura e diminuisce il suo consumo di corrente al minimo; nella modalità forced viene effettuata una misura secondo determinati parametri e tempistiche riportate nel datasheet e poi passa in modalità sleep. Infine nella modalità normal, il sensore ciclicamente alterna varie misure (a seconda della configurazione che vedremo a breve) a una modalità di stand-by per un determinato intervallo di tempo. Visto che in questa fase di sviluppo la "power consumption" non è tra i vincoli di progetto :biggrin: la modalità impostata nel firmware è la normal. Selezionando e/o mixando le precedenti modalità con delle caratteristiche di oversampling (sovra-campionamento del segnale acquisito, senza eccedere nell'approfondimento del termine, principalmente serve per diminuire il rumore di misura e aumentare la risoluzione) si riesce ad avere un sensore che ha dei consumi "irrisori" oppure dal lato diametralmente opposto un sensore con una risoluzione "altissima". Questa opzione configurabile di sovra-campionamento è applicabile sia alla misura di temperatura che di pressione, mediante un parametro/registro del sensore. Per avere un'idea riporto la tabella della pressione che trovate nel datasheet del componente:

image.png.dda507e7995e398cc5568c5800aa5e17.png 

 

la misura della pressione può anche non essere effettuata nel caso in cui si utilizzi il sensore come sensore di temperatura....ma non è il nostro caso.

Come noterete dalla tabella, l'oversampling è impastabile con valori discreti/definiti da 1 a 16, maggiore è il sovra-campionamento minore sarà il rumore e maggiore sarà la risoluzione. Se tale parametro è impostato a 16, si ha la risoluzione massima del sensore ovvero 0,0016 mbar.  Tutto ciò per sottolineare che questo dispositivo è estremamente "sensibile" e che la misura rilevata ha già subito un processo hw/sw a basso livello (senza neanche aver attuato algoritmi di nessun genere da alto livello) contribuendo a diminuisce il rumore e l'incertezza di misura per rendere il dato attendibile. 

 

Se tale risoluzione la rapportiamo a qualche post fa di @Ocean's One in cui parlavamo di una variazione stimata dell'ordine dei 333 mbar per 85 ml di cassa d'immersione, direi che possiamo effettuare delle misure molto "fini" su tutto il range e implementare l'algoritmo d'interesse per tutte le varie condizioni, decidendo il range di variazione delle misure, tendo conto di una granularità di dati estremamente fine.


Dalla tabella precedente si nota anche un suggerimento rispetto il campionamento della temperatura (legato alla pressione). Tornando a sottolineare che per questa fase i bassi consumi non sono d'interesse ma preferisco avere un'alta risoluzione, ho impostato a 16 l'oversampling della pressione e di conseguenza un oversampling in temperatura pari a 2. Per completezza riporto anche la tabella della temperatura

image.png.e303bcb2a999d3cbcecb8f907a09fef4.png


Come noterete con un settaggio pari a 2 si ottiene una risoluzione pari a 0.0025 °C, perciò più che sufficiente per il nostro scopo.


Infine (e perdonatemi se mi sono già dilungato parecchio), un ultimo parametro interessante da impostare è il filtro digitale IIR (Infinite Impulse Response - su internet di informazioni in merito sul suo funzionamento se ne trovano un'infinità).....ma basti pensare che mediante la configurazione di questo filtro c'è la possibilità di eliminare delle variazioni repentine sui valori del sensore ed eliminare eventuali disturbi di misura rendendo la misura maggiormente immune a variazioni anomale. Perciò in definitiva la configurazione a oggi impostata nel sensore è la seguente

image.png.0ef1a8298d41593f1cda4314eb26b5f6.png

 

Diciamo che a questo punto abbiamo un po' di info per comprendere meglio quanto possa essere configurabile, sensibile e robusto (a livello di misure) questo sensore.....perciò dopo questo preambolo volevo arrivare a qualche considerazione per proporre una soluzione che  mi frulla in testa da quando ho adottato questo sensore e che non si può rrrrifiutare!!! :biggrin:

 

Pur comprendendo pienamente che come più volte sottolineato da @Ocean's One in vari commenti, converrebbe avere un pressostato differenziale e non assoluto, l'idea di non stravolgere il sistema/architettura proposta (andando ad aggiungere un manometro/pressostato direttamente sul tubo per rilevare la pressione della sacca) mi alletta parecchio. Se a questo si aggiunge la disponibilità di un sensore come il BMP280 (con caratteristiche molto raffinate), la mia idea e proposta è quella di utilizzare solo questo sensore assoluto e implementare mediante l'algoritmo di DELF-ino tutti i casi possibili di funzionamento a cui associare gli eventi di guasto. Questo potrebbe permette di avere un sistema robusto a prova di errore umano, come nel caso anticipatoci da @Ocean's One  in cui è esplosa la cassa d'immersione.....

On 9/8/2020 at 14:44, Ocean's One said:

Infatti, cosa succederebbe se dopo la manutenzione periodica ti dimenticassi di ricollegare il cavo del pressostato?
Al raggiungimento della pressione limite la pompa continuerebbe a funzionare distruggendo la sacca. (per inciso, questa cosa mi è già successa una quindicina di anni fa sul mio Neptune, prima che avvisassi la Thunder Tiger di modificare il pressostato).

 

Anche questa casistica può essere coperta con la giusta strategia firmware e un solo pressostato......non si rileva il pressostato la pompa non parte. Oppure problematiche relative a una eventuale connessione invertita delle fasi di pilotaggio della pompa, che la farebbe funzionare in modo inverso con possibili cause di esplosione sacca........una strategia da adottare potrebbe essere--> quando il sistema si attiva e viene chiuso nel WTC (....e già queste poche parole si potrebbero tradurre in qualsiasi strategia ancora da vedere :smile:), parte un check sulle fasi della pompa che viene pilotata per un breve periodo e il micro rileva una minima variazione di pressione; in base a tale variazione (positiva o negativa) si può decidere se il firmware in automatico "comprenda" come pilotare la pompa e in seguito imposti i due versi delle fasi per riempire e svuotare la cassa in modo corretto....oppure dia a display una segnalazione di fault che dica di invertire fisicamente le fasi del motore!! .....E questo è solo un altro esempio :cool:

 

Anche nel caso del ragionamento riguardo la connessione temperatura/pressione, si possono implementare algoritmi per la loro gestione, infatti riprendendo quanto giustamente evidenziato nel seguente post

On 30/7/2020 at 23:00, Ocean's One said:

Ma se anche così fosse, ed è già difficile, tieni conto che un incremento della temperatura interna di 30 gradi, certamente possibile, aumenta la pressione interna di 100 mbar e falsa tutte le valutazioni.

 

si può pensare di prevedere un check costante sulla temperatura e rimodulare il valore letto della pressione in base al cambio di temperatura....avendo una sensibilità/risoluzione così elevata sulla pressione e un micro che la può comprendere/gestire a suo piacimento, si può realmente fare un software intelligente che preveda e gestisca le casistiche che possono presentarsi, non so se rendo l'idea della potenzialità che abbiamo!!

 

Infine e dopo la smetto di insistere :biggrin: rispetto a quanto detto in precedenza nel seguente post

On 30/7/2020 at 23:00, Ocean's One said:

Però considera che la pressione nella sacca cresce pochissimo finché la sacca è quasi piena e poi si impenna solo nell’ultimo 10% della capacità. Potrebbero esserci dei falsi allarmi se questo sistema non è abbastanza sensibile.

 

con il BMP280 riusciamo a verificare costantemente in maniera fine e attendibile tutto il range di utilizzo e non solo l'ultimo 10% di riempimento..... questo credo sia un enorme vantaggio da poter sfruttare a nostro uso e consumo. Solo per darvi l'idea di quanto si riesce a rilevare, bastano 1-2 giri di pompa peristaltica per far variare minimamente la pressione del WTC......e il BMP280 vede tale variazione!!!

 

Vi posto un video di qualche giorno fa, non sono riuscito a fare inquadrature decenti e perdonate per i rumori di fondo, comunque fornisce una primissima idea del sistema chiuso e le misure del pressostato

 

nel video ho fatto qualche ciclo parziale di riempimento e svuotamento della cassa d'immersione....parziale perché come previsto dal mitico @Ocean's One qualche tempo fa, se tento di riempire la cassa d'immersione completamente senza nessun blocco sui tappi, aumenta talmente tanto la pressione che il tappo di prua viene letteralmente "sparato" fuori dal WTC. In più nella parte finale del video si nota come inesorabilmente la pressione nella camera stagna tende a diminuire, perciò ho qualche perdita....che dopo un'accorta analisi in acqua/bollicine dovrei aver capito da dove si origina, perciò sistemo i tappi e vi faccio qualche video migliore.

 

Che ne pensate? L'idea comincia a piacere anche a voi?

 

Direi che per il momento è tutto :cool:

 

Edited by Call_Me_V
Link to comment
Share on other sites

Ed ecco il nostro amico subito a riprendere l’impegnativo cantiere...!

Vincenzo, sei già sul pezzo? E che pezzo: questo MEMS della Bosch sembra proprio un vero gioiello.

Già conoscevo la qualità dei MEMS Bosch per motivi di lavoro, ma vedere questa risoluzione fa impressione: siamo a livello di qualche centesimo di mm di colonna d’acqua!!!

Tant’è vero che io, fossi in te, non userei questo gioiello per controllare il riempimento della sacca, ma lo collegherei ad una presa esterna per avere un misuratore della pressione d’acqua, ovvero un profondimetro.

Questo dispositivo sarebbe capace di misurare la quota con una risoluzione di almeno 1 mm, ma anche soltanto 1 cm sarebbe grasso che cola!
Inoltre, se collegato al circuito di gestione dei piani di profondità, potrebbe servirti per sviluppare un circuito per il mantenimento della quota durante la navigazione sommersa (quello che io chiamo autoquota), interfacciato con i timoni e/o con la pompa di immersione.

Domanda: tu dici che il sensore MEMS la tecnologia APSM, ovvero una membrana in silicone, ma ti risulta che questa sia waterproof?

Per quanto sopra, in effetti servirebbe...

________
 

Complimenti per aver già messo a punto un sistema funzionante che comprenda tutto, come si vede nel video.

Tuttavia, in merito alla logica di funzionamento, ho ancora diversi commenti da fare.

Tu dici che il sensore è in grado di discriminare tutte le fasi di riempimento della sacca è non solo l’ultimo 10%, cosa certamente confermata.

Tuttavia, la grandezza misurata e la pressione interna al WTC, che non è sufficientemente affidabile per i nostri scopi.

Mi spiego meglio: la pressione misurata cresce costantemente proprio per il fatto che anche il volume di aria nel WTC decresce con continuità, visto che la pompa continua immettere nella sacca una portata d’acqua costante, riducendo così il volume del WTC in progressione.

Tuttavia, non sappiamo quale sia esattamente la pressione DENTRO la sacca.

Finché essa è solo parzialmente gonfia, c’è l’equilibrio fra pressione interna nella sacca e pressione nel WTC, visto che la parete della sacca è deformabile, e quindi la pressione che tu misuri è significativa. Tuttavia, quando andiamo a sforzare le pareti in gomma della sacca, la pressione in essa cresce molto più rapidamente della pressione esterna, e quindi tu non avresti uno strumento in grado di accorgersi di questo fatto, con il rischio di fare scoppiare la sacca.

Teoricamente, è vero che tu potresti registrare il valore di pressione limite (anche se più basso dell’effettivo nella sacca) e dire all’elettronica di fermarsi a quel punto,

Ma allora dovresti essere sicuro della costanza di questo valore limite.

Mi spiego: supponiamo che l’aria nel wWTC trafili leggermente verso l’esterno dopo alcune decine di minuti di immersione (ricordiamoci quanta extra-pressione c’è all’interno del WTC a sacca piena). Se in questa condizione tu fai un ulteriore ciclo di svuotamento e poi di riempimento, l’elettronica pretenderebbe di fermare la pompa molto più tardi, visto che la pressione interna ora è più bassa, con il serio rischio di fare scoppiare la sacca.

 

Ora, anche se io sceglierei un pressostato differenziale, non dico che questo sistema basato su una misura assoluta sia completamente da scartare: Può funzionare, ma sotto alcune condizioni:

 

- Non ci devono essere trafilamenti di aria fuori dal WTC quando questo è in pressione: quindi, ben venga una tua prova in acqua, dove riempirai completamente la sacca e lascerai il WTC in pressione immerso per qualche ora, leggendo dal display la pressione, che non deve calare nel tempo.

 

- Viceversa, se decidi di chiudere il WTC a sacca piena, devi ripetere la prova in acqua lasciando la sacca vuota (ovvero con il WTC in depressione), e verificare che la pressione interna si mantenga ad un valore costante e non cresca nel tempo (il che fra l’altro significa che sta entrando acqua!)

 

- Ad ogni modo, tutto ciò deve essere completato da una funzione aggiuntiva, ossia una vera e propria sequenza di inizializzazione, che ora provo a spiegarti.

Appena chiuso il WTC, aziona la pompa a svuotare e tienila attiva per un tempo sufficiente ad essere sicuro che la sacca sia completamente vuota.

Dopodiché, leggi e registra il valore di pressione interna in queste condizioni.

A questo punto, il tuo software calcolerà la pressione limite per questa tornata di utilizzo, sommando alla pressione a sacca vuota un valore costante che avrai trovato sperimentalmente in precedenza e pari all’incremento di pressione che c’è durante il riempimento della sacca fino al massimo previsto.

 

Tutto ciò non è impossibile, ma certamente è da studiare bene.

 

 

p.s. se posso fare il rude meccanico, io continuerei a preferire un pressostato differenziale on/off  per fermare la pompa a sacca piena.

Il tuo gioiellino MEMS che sarebbe molto più utile come profondimetro, per esempio.

Ma questa è solo la mia idea…

Link to comment
Share on other sites

Per il problema dell'evitare l'esplosione della sacca io agirei in modo "meccanico" ovvero metterei uno switch che verrebbe chiuso dalla sacca al raggiungimento di un determinato volume...

 

Per l'autoquota, assumendo che i cavalli siano sferici (*), userei questo algoritmo, in simil arduinese:

 

var pressione_di_livello;

 

setup()

{

    pressione_di_livello=BMP280();

}

 

loop()

{

    if (pompa_in_funzione())

    {

        pressione_di_livello=BMP280();

    }

    else

    {

          pressione_di_livello=compensazione_temperatura(pressione_di_livello);

    

    servo_profondita(BMP280() - pressione_di_livello);

    }

}

 

servo_profondita(var delta_pressione)

{

    if (canale_profondita==0)

    {

        servo[profondita]=f(delta_pressione)

    }

}

 

(*): i cavalli sarebbero sferici se si riuscisse in qualche modo a far variare la pressione interna al WTC al variare della pressione esterna, ovvero il WTC non dovrebbe essere troppo rigido alla compressione ma solo all'espansione.

Inoltre si assume che non ci siano perdite o infiltrazioni, ma questo lo si lascia ai costruttori del battello 😛

 

Edited by gepard
invio errato
Link to comment
Share on other sites

Mitico Marco.....mi fa piacere che hai già scritto un pezzo di algoritmo per come funzionerà il pressostato, la strada è quella giusta!!! :biggrin:

 

Comprendo le tue remore e i tuoi dubbi nell'utilizzare questo pressostato per rilevare la pressione del WTC al posto di un semplice pressostato differenziale e comprendo che probabilmente stiamo complicando non poco le cose ma vorrei provarci almeno per capirne la fattibilità e i limiti sul campo, la semplicità di una tale architettura mi piace troppo:dribble:.....Tanto la strada tracciata/fattibile con il pressostato differenziale è sempre percorribile in futuro e nel caso in cui arriviamo a un nulla di fatto, possiamo applicarla...considerando anche l'ottima modifica con la resistenza in parallelo da te indicata :wink:

 

Che ne dite proviamo questa sfida a singolo pressostato assoluto? :showoff:

 

Riprendiamo i tuoi ragionamenti molto interessanti del post precedente, 

19 hours ago, Ocean's One said:

Tuttavia, quando andiamo a sforzare le pareti in gomma della sacca, la pressione in essa cresce molto più rapidamente della pressione esterna, e quindi tu non avresti uno strumento in grado di accorgersi di questo fatto, con il rischio di fare scoppiare la sacca.

 

fenomeno chiaro, provo a fare delle misure per analizzare meglio la cosa e fornirvi dei dati concreti....ma una domanda mi sorge spontanea (e magari è una castroneria) tenendo presente che svuotando il palloncino dall'acqua presente, con la pompa peristaltica riesco a fare il "vuoto" (passatemi il termine) al suo interno ed eliminare anche l'aria eventualmente presente.... se prendessi una sacca un po' più grande del necessario (tipo da 130 ml per caricarla con 85 ml) in modo tale da non sforzare le sue pareti, potrebbe essere migliorativo? potremmo limitare il fenomeno da te indicato?

 

19 hours ago, Ocean's One said:

- Non ci devono essere trafilamenti di aria fuori dal WTC quando questo è in pressione: quindi, ben venga una tua prova in acqua, dove riempirai completamente la sacca e lascerai il WTC in pressione immerso per qualche ora, leggendo dal display la pressione, che non deve calare nel tempo.

- Viceversa, se decidi di chiudere il WTC a sacca piena, devi ripetere la prova in acqua lasciando la sacca vuota (ovvero con il WTC in depressione), e verificare che la pressione interna si mantenga ad un valore costante e non cresca nel tempo (il che fra l’altro significa che sta entrando acqua!)

 

Appena sistemo i trafilamenti le due prove le faccio in sequenza e vi posto qualche video così verifichiamo insieme il tutto e mi dite cosa ne pensate.

 

19 hours ago, Ocean's One said:

- Ad ogni modo, tutto ciò deve essere completato da una funzione aggiuntiva, ossia una vera e propria sequenza di inizializzazione, che ora provo a spiegarti.

Appena chiuso il WTC, aziona la pompa a svuotare e tienila attiva per un tempo sufficiente ad essere sicuro che la sacca sia completamente vuota. Dopodiché, leggi e registra il valore di pressione interna in queste condizioni. A questo punto, il tuo software calcolerà la pressione limite per questa tornata di utilizzo, sommando alla pressione a sacca vuota un valore costante che avrai trovato sperimentalmente in precedenza e pari all’incremento di pressione che c’è durante il riempimento della sacca fino al massimo previsto.

 

Gli algoritmi prendono forma :smiley19: la procedura di inizializzazione sarà la fase più delicata.

 

19 hours ago, Ocean's One said:

Tutto ciò non è impossibile, ma certamente è da studiare bene.

 

e lo stiamo facendo....:smiley28:

 

Riguardo l'autoquota, l'idea è bella ma purtroppo un tale sensore non è fatto per essere utilizzato direttamente in acqua in più non si avrebbero riferimenti corretti sulle sue caratteristiche di risposta.....perciò se vogliamo farlo ci dobbiamo inventare altro!!  Invece riguardo il discorso di utilizzare uno switch per rilevare 

 

Link to comment
Share on other sites

@Call_Me_V nel seguente sistema potresti verificare se la pompa peristaltica ha delle variazioni di assorbimento di corrente nei passaggi tra gli stati 1,2,3 e 4 ?

   757739020_SnorkelBallastSystem(2).thumb.jpg.8d910778003673ccb8e26306f3b2b061.jpg

 

A : tubo di ingresso/uscita acqua

B : cassa di zavorra rigida

C snorkel

 

Gli stati 4 e 1 una volta raggiunti sono stabili fintanto che non si inverte la direzione di rotazione del motore della pompa.

 

A battello emerso il sistema è in stato 1

A battello immerso il sistema è in stato 4

2 e 3 sono stati intermedi

Edited by gepard
refuso
Link to comment
Share on other sites

Ciao @gepard l'idea di utilizzare uno "shunt" per le correnti assorbite dalla pompa peristaltica è fattibile senza problemi, si realizza anche rapidamente.....considera che generalmente utilizzo il driver/amplificatore INA214 della Texas Instruments molto semplice, immediato e parecchio accurato ma vedo che per Arduino ci sono già delle librerie fatte bene per l'INA219 (un parente del precedente :biggrin:) che tra le altre cose funziona anche lui in I2C.....bisognerebbe fare 4 conti ma non la vedo problematica.

 

Solo che guardando il tuo schema hai considerato una zavorra rigida e uno snorkel.....stai già pensando a una cassa d'immersione di qualche tipo? hai qualche link di riferimento?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Forum Statistics

    • Total Topics
      45k
    • Total Posts
      521.7k
×
×
  • Create New...