![]() |
Citazione:
anche costruendone uno ad hoc.. il costo rimarrebbe sempre superiore o simile.. già solo il modulo gps costa intorno ai 60euro.. altrimenti bosognerebbe perdere tempo in prove con vari gravitometri od accellerometri ed altri tipi di sensori.. ma la ricerca richiede tempo e soldi.. |
se mik permettete consiglierei di escludere il GPS per i seguenti motivi:
Se si vuole trovare una soluzione.... bisogna spremere le meningi PS: i sensori a ultrasuoni come si comportano quando sei a 100 mt di quota ???? cosa leggono ??? Non e' che non sentendo movimento pensano che di movimento non ce ne sia ???? |
Citazione:
|
Citazione:
esatto, se hanno bisogno di superficie riflettente.... in aria non c'è. Andrebbero attivati solo a bassa quota come suggerito da Giulio, sinceramente è una cosa che non mi piace nemmeno un po'. |
permettetemi di sognare un attimo.... e un bel trasponder come gli aerei veri con gestione completa dal banco della direzione... a mo' di torre di controllo... :rolleyes::fiu: |
Adesso sparo la mia... Seguo la discussione dall'inizio, secondo me non è assolutamente facile mettere d'accordo tutto, i modellisti che non vogliono troppo peso e fili che svolazzano e gli organizzatori che vorrebbero un automatismo che li aiuti, sia preciso e affidabile (soprattutto per evitare contestazioni all'atto della classifica). Mi è venuta in mente una cosa, premetto che non conosco bene come funzioni però funziona, sono anni che nelle gare di ciclismo, anche amatoriale, si usano dei sensori GPS molto piccoli e leggeri attaccati alla forcella. Se ci avete mai fatto caso sono quei bombolotti da un lato del mozzo davanti. Sto cercando informazioni a riguardo, ma essendo anche usati per stilare le classifiche degli arrivi in volata sono molto precisi, solitamente ogni corridore si compra il suo, al qualche corrisponde un numero (tipo MAC schede di rete) che viene registrato all'atto dell'iscrizione, tramite quello l'organizzazione conosce sempre la posizione della bici, e quindi anche quando questa bici è ferma, tutto sta a modificarlo per farlo partire all'atto dello sgancio. Credo che poi ci sia un SW per poter leggere le varie tracce GPS, il bello è che tutto funziona in tempo reale. Spero di trovare informazioni, se si ve le giro. |
Molto interessante Marco, probabile che integrino una sorta di trasponder, utile quando c'è un traguardo (li usano sulle auto RC tra l'altro). Facci sapere. :lol: |
Citazione:
un paio di anni fa telefonai ad una ditta che progetta/produce queste apparecchiature (non ricordo quale) ma ovviamente il fatto di mettere in ballo una "terza dimensione" , cioe' l'altezza, fa si che questi sistemi per noi non siano proponibili per il semplice fatto che si attivano al passaggio in un determinato punto fisso per la F3J e' inutilizzabile, ma pensandoci bene per l'aerotraino la cosa non sarebbe cosi' improponibile non conosco il regolamento ma mi pare che l'aliante di aerotraino deve atterrare da una direzione precisa, in asse pista e deve fermarsi in un determinato spazio (non ricordo quale, ma ipotizziamo 20 metri) dunque il modello per arrivare a fermarsi in quel rettangolo (che immaginiamo essere 10 per 20 metri) deve transitare per un punto preciso se all'inizio del mio rettangolo pongo un traguardo ed il modello deve passare per forza da li' ed ha poi 20 metri per fermarsi ... il gioco e' uguale per tutti, ben sapendo che il modello quando passa per il traguardo dovra' essere gia' quasi fermo, visto che dopo 20 metri sfora l'area di atterraggio fra fermare il tempo a modello fermo oppure al transito per il traguardo in fin dei conti ci saranno 2/3 secondi di differenza ; ed il traguardo sarebbe comunque uguale per tutti a questo punto un sistema automatico, oppure un omino sulla linea del traguardo che schiaccia una sorta di telecomando che attiva un sensore a bordo del modello, non e' cosa improponibile cio' comporterebbe una modifica regolamentare non so se l'aerotraino sia "ufficializzato" nelle norme FAI (ma anche in questo caso ogni paese puo' introdurre delle "local rules") ; credo che nella formula Pelizza fare modifiche regolamentari non comporti grossi sforzi g.generali |
AAAALT !!! fermi tutti per un attimo ! sembra evidente che la maggior difficoltà sia quella di stabilire il momento dello STOP cronometro :uhm: LOGGER : Come ha ben ribadito Simone, nonché dal titolo del thread, per fare un sistema infallibile al 100%, è necessario che abbia una sorta di Backup, da poter controllare quando accaduto durante il volo, o a fine lancio, o a fine gara, o a fronte di una contestazione (nelle gare ce ne sono SEMPRE...), o semplicemente ad un intervallo di tempo/lanci definito per comodità dalla direzione di Gara. Pertanto un Logger di qualsiasi tipo (che sia : GPS, Barometrico, a Ultrasuoni, tutti assieme...) è l'unico strumento in grado di permettere il backup, proprio come una Scatola Nera :wink:. SENSORE : Mentre riguardo al sensore, non si tratta tanto del tipo da scegliere, ma di disporre di un Software on-board che sia in grado non solo di rivelarne i valori, ma che sia in grado di rivelare se i valori misurati stanno variando o sono costanti !!!!! Scusate se banalizzo, ma aiuta a capire dove focalizzare la fantasia....:icon_rofl Infatti si tratta di riconoscere due STATI in cui si trova il mudel, che si, son ben diversi tra loro, ma non così facilmente risonoscibili da un sensore nudo e crudo da solo : STATO A) ==> modello in movimento STATO B) ==> modello fermo Ora dal punto di vista di qualsiasi sensore di rilevamento che si vorrà adottare, gli stati sono riconoscibili tra loro SOLAMENTE : valutando la variabilità delle misure nel tempo, dall'invariabilità delle misure nel tempo.:P E qui, non credo ci siano controindicazioni a dare per scontato, che qualsiasi sensore verrà adottato, continuerà a fornire misure in Continua Variazione SOLO e fintanto che il modello sarà in Movimento, mentre le misure resteranno inchiodate ad un valore FISSO ===> SOOOOOOLO a modello fermo !!:icon_rofl Quindi: STATO A) ==> misure in continua variazione... STATO B) ==> misure INCHIODATE ad un valore FISSO !!!! SOFTWARE : Ne ho già parlato ma ribadisco....:fiu: Il software a bordo del Logger dovrà quindi : - essere in grado di misurare la "derivata" delle misure - quando la derivata Zero permane per un "certo" intervallo di tempo/campioni, attiva uno switch logico - lo switch logico è preposto a Fermare il cronometro (che è stato dapprima attivato dal comando di sgancio...) - sottrae il "certo" tempo intercorso dall'inizio del rilevamento di Zero movimento al valore cronometrato - registra tale valore tra i log - invia in output il valore di tempo finale - la visualizzazione potrà essere immediata tramite display visibile dall'eterno (come ad esempio quello dell'UniLog), o mediante una qualsiasi interfaccia al PC della direzione di gara, (tra le quali sono ottime le USB, ma anche RS232, e perchè no ZigBee, WiFi, ecc....) ARMAMENTO dello START : Simone sono d'accordo sul avere un sistema per armare lo Start cronometro in modo Sicuro, e come dici tu una volta armato col pulsante, il conometro verrà avviato dal comando di sgancio (ma occhio..). Un modo semplice per risolvere la cosa potrebbe essere: su un canale libero metti uno switch che si userà come Armamento, mentri il trigger verrà attivato da un mix col comando di sgancio :wink:. OK questa è una cosa a carico del pilota, ma non ci sono molte altre scelte. La cosa vale per qualsiasi tipo di aggeggio si vorrà impiegare.... Si, L'UniLog ha un pulsante che può essere settato come start/stop manuale della Registrazione/Cronometro. In realtà l'UniLog può essere fatto partire : - o dopo un certo intervallo di tempo dall'accensione (ad esempio 5sec, o 15sec, fino a 99sec) - all'accensione dell'RX - mediante comando TX con soglia d'impulso da 1,1ms a 1,9ms - al superamente di un certo valore rilevato da un sensore Mentre per fermarlo, con il FW originale con cui viene fornito, è necessario premere il pulsante di cui è dotato Sto verificando sia se è possibile farlo partire, e fermarlo in altro modo, sia mediante artificio sviluppato ad hoc, da noi stessi, che direttamente dal produttore (che sarebbe la cosa migliore sia per noi che per lui...), ma tutto dipenderà da quanti pezzi saremo in grado di acquistargli :fiu: con certezza. Antonio. Citazione:
Citazione:
Citazione:
Citazione:
Citazione:
Citazione:
Citazione:
Citazione:
Citazione:
Citazione:
|
Vedendo qui effettivamente è un sistema a transponder, ma a occhio potrebbe essere adattato a questo scopo, devo chiedere a chi organizza le gare di bici. |
Il trasponder AERONAUTICO lo lascerei perdere troppo complicato e poi dovremmo IRRAGIARE su frequenze con autorizzazioni PTT ecc... Per la visualizzazione direi che se si usa un display sempre connesso al sistema si aumentano i pesi e ingombri. Se la cosa non e' difficoltosa direi che il "cronometro" dovrebbe essere connesso nel momento della verifica al display o alla apparecchiatura che magari identifica la sigla del velivolo e poi registra i dati di percorrenza. Questo per ridurre il peso anche del display e sopratutto per evitare che questo prediugichi posto di installazione e variazione di CG. Per la possibilita' di connetterlo wireless si puo' pensare a BT o altro ma poi si ricade nell'aumento di peso :(. Io penserei ad una cosa base che magari identifichi il momento di SGANCIO leggendo la posizione del servo e il momento del "veicolo fermo" previa analisi delle vibrazioni sui tre assi visto che immagino che a velivolo fermo non si abbiamo piu' movimenti per i tre assi. Per gli accelerometri no problem ci sono a costo zero per fare dei test, tanto poi implementare la lettura del servo si sa sia fattibile. Per la memorizzazione dei dati tipo logger ormai memorie piccole e capienti si trovano :wink: Nel WE e nelle mattine preste a mente fresca cerchero' di organizzare qualche test...mi manca molto il tempo quindi se qualcuno ne ha in piu' :P Continuo a seguire :wink: |
Citazione:
era ovviamente una battuta :rolleyes: grazie per la partecipazione, ti lascio cogitare in pace. :lol: |
Citazione:
PS. se c'e' bisogno pero' possiamo portarci in volo un TELIT triband GPRS + GPS e farci mandare giu i dati di telemetria ... basta avere una copertura TIM :wink::wink::wink: e l'ip fisso lo possiamo ottenere :wink: |
Citazione:
Peccato che la trasmissione di dati a terra non credo sia ammissibile in gara ... :nono: Antonio. |
...com'è che non sento piu' il brusio delle meningi che lavorano? :rolleyes: |
Citazione:
|
con 30-40 partecipanti, potenzialmente tutti per aria contemporaneamente (anche se di solito oltre la decina non succede mai) la vedo dura. Inoltre piu' che lo sgancio, il problema lo vedo all'atterraggio. E comunque, della decina di persone necessarie per un'ottima organizzazione, eliminare un cronometrista significa ridurre del 10% le persone necessarie. Per noi sarebbe un bel risultato abbattere tale numero del 70-80%.... B) |
Un'idea che mi era balenata i giorni scorsi, che non ho espresso per non turbare i cogitanti, sarebbe di portare la montagna a Maometto. Fermo restando il trofeo Dino Pelizza se lo si volesse portare avanti così com'è, per la F3I con regolamento Nazionale (attualmente F3I/P) si potrebbe ripensare un regolamento piu' moderno e soprattutto adatto alla rilevazione con logger GPS o barometrico, magari una formula basata sui guadagni di quota, seza l'assillo del secondo in atterraggio, che rende questa fase decisamente poco riproduzionistica. In tal senso si potrebbe rielaborare la proposta di modifica di Ehstì di qualche anno fa aggiungendo nuovi elementi. Certo che per una simile modifica occorrerebbe largo consenso. La mia è solo un'idea, ammetto di non avere pensato come si potrebbe modificare il regolamento. :wink: |
Citazione:
Dire solo " fate come volete, l'importante è che funzioni come sarebbe meglio che funzioni", fooorse è un tantino DISPERSIVO .... Se si vuole arrivare a qualcosa di concreto, non sarebbe male andare a step, e per singoli punti, ormai il brainstorming è andato + e + volte OT, e la facilità di divergere è piuttosto naturale su un forum. Perchè non tieni aggiornato un blog con i punti fermi dell'obbiettivo, a cui far riferimento nella discussione, aggiornando dove si è arrivati, ed eventualmente aggiustanto l'indirizzamento del target ? Aiuterebbe anche il discutere una cosa alla volta, senza mischiare assieme tutto ciò che viene in mente di volta in volta... Antonio. |
Antonio, non lo faro' MAI :rolleyes: |
Citazione:
Antonio. |
Citazione:
|
:wacko::wacko: a me sembra proprio che ve la stiate menando di brutto.. :D premetto che non conosco assolutamente la formula pelizza, ma da quello che ho capito dalla discussione, si tratta di calcolare il tempo di volo dal momento dello sgancio fino a quando il modello non è fermo immobile a terra... se lo sgancio come dite non è un problema, e il calcolo dei dati di volo compreso il tempo e dato ad un logger, credo che ricavare il momento di "modello fermo" sia una cacatina... se e dico SE il logger calcola quota 0 a tempo t... quota 0 a tempo t+1,... quota 0 a tempo t+5.... ecc.. allora il modello è fermo. o sbaglio? |
Purtroppo gli alimetri (tutti), hanno una tolleranza.. anche con modello fermo a terra hanno dlle leggere variazioni !! Citazione:
|
Citazione:
un modello puo' essere a quota zero, ma non fermo. Inoltre non esiste lo 0, ma un valore che, anche a quota costante, non è mai perfettamente costante. |
Citazione:
Intendo, quanto variano i tuoi ad esempio in 1sec, o in 3sec ??? Quanti campioni successivi rimangono mediamente COSTANTI tra due tipiche variazioni dovute a ste "tolleranze" ? Se lo strumento, oltre ad essere "preciso", è pure "sensibile", credo che sia in volo che solamente tendolo in mano possa mostrare una certa "variabilità" delle misure rilevate, certamente meno se il modello è fermo a terra. Pioi specificare/circostanziare meglio ?? Domani faccio due prove col mio, giusto per evitare di affermare cose non vere, anche se come anticipato, a 16 campionamenti al secondo, quando è a terra la misura praticamnte con cambia per nulla sul medio lungo, tra un campone e l'altro devo appunto controllare. Antonio. |
Citazione:
Ciò che conta è se sta fermo, inchiodato attorno ad un valore per un ragionevole intervallo di tempo. Appena lo prendi in mano, è giusto che il valore di quota cambi continuamente. Poi in volo non sta fermo MAIII, è preaticamente impossibile farlo stare fermo anche solo per una frazione di secondo. Anche se ho "impunemete" convinto MAH che la cosa non è affatto complicata, ciò che in realtà non è banale del tutto, è appunto il riconoscimento tra Variabile ed Inchiodato attorno ad un valore. Risolto tale punto, risplto pure il problema delo stop. Ma di riffa o di raffa, prima o poi, MAH o qualcun'altro, sapranno tirar fuori il modo per estrarre il tempo di volo ESATTO dall'UniLog. B) :wink: Antonio. |
Ri-premetto che non conosco la Pelizza e nemmeno i vari logger... percui posso essermi espresso male per coloro che invece con i vari logger hanno a che fare quotidianamente... quello che intendevo dire io è che se un logger è fatto decentemente, nel momento in cui un modello è in volo, a qualunque quota, sia essa 1000, 100 o 0... registra dei dati e i parametri variano.. (o sbaglio?).. mentre nel momento in cui un modello è fermo immobile i dati che vengono registrati nel tempo dovrebbero essere comunque costanti.. o quantomeno con minime variazioni del tutto trascurabili... non so poi se questi vari logger dispongano anche di un moduletto GPS... se così fosse sarebbe ancora più semplice individuare il punto di STOP del modello interpolando i dati del logger e il tracciato rilevato dal gps... cioè, se si analizzano il tracciato del gps e i dati di volo del logger, si dovrebbe riuscire a determinare il punto in cui al tempo t il tracciato è a x, nel tempo t+1 è sempre a x ... ecc.. o no? |
purtroppo, essendo la quota rilevata barometricamente, e' sufficiente una minima brezza a causare all'interno delle nostre fusoliere pressioni/depressini che fanno oscillare la misurazione. I test da me fatti con Zlog Mod3, Alti2 e Picolario evidenziano una profonda instabilita' al suolo (parliamo anche di +/- 3 mt), data dalla sensibilita' degli stumenti (che hanno una risoluzione di circa 30 cm, dato che leggono in piedi !!) Se provi adappoggiarlo su un superficie in casa, oscilla relativamente poco, ma se solo apri o chiudi una porta, magari anche distante, leggerai una variazione. Lasci immaginare cosa puoi leggere con lo strumneto in una fusoliera appoggiata al terreno, investita dal venticello e in balia delle turbolenze dell'erba. Non parliamo poi di cosa legge quando il modello e' attacato (a terra) dietro il trainatore, anche se a 20 e piu' metri di distanza, ma investito dal flusso dell'elica. Le fusoliere non possono essere stagne (lo strumento non leggerebbe) e quindi risentono di qualsiasi variazione esterna |
Citazione:
un GPS costa da solo piu di 50 euro, poi biogna interfacciarlo ad un microprocessore, che ne elabora i dati come dici te.. quindi bisogna scrivere un software che sia capace di leggere sti dati ed interpretarli.. il discorso della quota fissa e' giusto ma non praticabile, perche come han detto in precedenza le variazioni possono essere anche di quelche metro, ed un aliante in costante discesa..potrebbe riuscire a perdere 1 metro al secondo.. ma anche molto meno.. e questa perdita di quota diventa costante se il pilota e bravo.. quindi che succede?? il datalogger vede che la variazione di quota e' costante.. sotto al metro al secondo..e .. stoppa il timer... :shutup: contrariamente se la tolleranza e' troppo bassa, il timer non si ferma... senza contare che poi il GPS e armamentario vario pesano... e temo che senza sensori esterni, sarà difficile trovare la soluzione... |
| Tutti gli orari sono GMT +2. Adesso sono le 15:47. |
Basato su: vBulletin versione 3.8.11
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
E' vietata la riproduzione, anche solo in parte, di contenuti e grafica. Copyright 1998/2019 - K-Bits P.I. 09395831002