Aaa Inventori Cercasi....

[lol21]

batterie credo che siano più affidabili le li-ion o le li-fe che le li-po.

ad ogni modo pensavo e se si mettesse una grande elica centrale tipo elicotter che abbia il compito di sollevare il modello e utilizzassimo motori elettrici molto più leggeri e quindi batterie minori per comandarlo/dirigerlo?

ciao
lol21

[elettro]

scusate, magari dico una baggianata pazzesca, ma per l'elettrico perchè vi limitate alle batterie? una cella all'idrogeno sarebbe molto più efficiente no? anzi, a serbatoio pieno la struttura sarebbe addirittura più leggera che a serbatoio vuoto :-)
Il rendimento delle celle idrogeno, se non erro, è 1.5:1 con quelle a benzina: se per 100km usi 1.5 litri di benzina, di idrogeno ne usi solo 1. In oltre, se non si sale troppo di quota, non serve nemmeno il serbatoio per l'ossigeno. Le normali celle però funzionano a 3 o 4 atmosfere al massimo, per questo non so quanto sia fattibile
magari aggiungere una valvola di sfogo azionabile a mano per evitare di crashare col pieno di idrogeno...

Certo una cella+serbatoio di idrogeno non è economico, sinceramente non saprei nemmeno dove guardare i prezzi.

Per la ricarica, sia delle batterie che della cella idrogeno, vanno benissimo dei pannelli solari a terra.

ps. cercando qualcosa sulle celle idrogeno ho trovato questo documento (tesi?) sull'uso di idrogeno su di un uav.. ScienceDirect - Journal of Power Sources : Fuel cell system with sodium borohydride as hydrogen source for unmanned aerial vehicles

[pipposoft]

Scusatemi, mi state facendo sentire più ignorante di quello che sono... 'ala soffiata' tipo effetto Coanda. ??? Cosa è?

Areis, escluderei i motori da kart, per quanto scostumatamente potenti siano, altrettanto inaffidabili, proprio per via della loro caratteristica di tirar fuori una vagonata di HP in una finestra RPM, molto stretta, la musica cambia se mi parli di deltamotore, precisamente il contrario dei Kart ;)

Confermo quanto detto da ElNonino, anche volendo usate sistemi di alimentazione ad iniezione, e governor vari, non credo si riesca a Sincronizzare con la precisione richiesta per la stabilizzazione motori a scoppio,*

Pur rimanendo orientato su motore endotermico.!

Non escludo, la possibilità di usare i 4 *motori elettrici, per la sola stabilizzazione, veloci nei cambiamenti di giri, più gestibili *e precisi degli scoppio !

Benvenuto Magnetron1 !
Che ha sottolineato costo e peso delle batterie, eccessivo da usare come propulsione principale ;)
Poi ci pone la domanda,
"Per quale scopo deve essere realizzato questo sistema...."

Mi permetto di rispondere a nome di tutti:
CAZZEGGIO...
si proprio così, non esiste un perchè. Si fa questa discussione, per il gusto di scambiare opinioni, esperienze concetti (in modo civile) per il piacere di appacare il Virus che ci ha oramai contagiato ... Lo chiamano modellismo ;-) e vedo che non ha risparmiato neanche Te...
Benvenuto nel Club !

Se poi, come ho già scritto da qualche parte, oltre a un BRAIN TRAINING... riuscissimo anche a materializzare quello che pian piano sta prendendo forma,*
Grande soddisfazione e gratificazione da parte di Tutti coloro che in qualche modo vi hanno contribuito !

Niente di commerciale, niente con secondi fini, adesso rubo una Frase ad un mio amico... Facciamo volare le nostre idee!!!

Grande Crisinvolo, con i 3000 euro per il funerale!*
Sto ancora ridendo...

LoL, per portare in giro 800A ci vanno dei cavi particolari, capaci di trasportare tale potenza, quindi sono indicati, cavi di diametro grosso, e con molti fili, sottilissimi, per farti un'esempio, i 25000 Volt di un cinescopio delle vecchie TV, si collegano con un conduttore rigido da 0.75mm , mentre i 200A di una Saldatrice si trasferiscono con un 10/12 mmq formato da tantissimi filetto sottili come capelli ...

.... A conti fatti, considerando il peso specifico del rame, ci portiamo in giro 1/2 pilota !!! Azz...

ZioJos, non preoccupiamoci di permessi, certificazioni o altro, in questa fase ci rallentano, e poi come ho scritto all'inizio, non dobbiamo mettere su, una compagnia di aerotaxi , il successo, è progettarlo, il successo del successo, è realizzarlo e vederlo volare con un fantoccio da 100kg
;-)
Se poi ci sarà qualcche PAZZO, si stipuli una poliza vita, e si tenga pronto a scrivere il proprio nome nel Guinness dei Records !

Riguardo la scheda di controllo, non mi ci dilungherei più di tanto, in giro c'è *già l'impossibile, per non parlare poi, che non abbiamo problemi di ingombri, quindi una mini ITX con Linux o altre diavolerie del genere, potenza di calcolo a GoGo...
Per il FW - Gli esperti siete voi :-)

C'è qualcuno bravino in disegno che tiri giù una bozza di "monoscopio" volante con un rotore grande centrale, 4 più piccoli nei 4 angoli con delle alette laterali?
Cominciamo a guardarlo in faccia ;)


••• Non dimenticate di proporre il NOME!

Pippo

[elettro]

sconsiglio assolutamente un "mini ITX con Linux" o qualsiasi altro processore/cpu che richiede un sistema operativo. Parlo da programmatore, la complessità di quei software è alta, e non sono specifici per quella piattaforma. Risultato: possibile lag, piantamenti, crash, ANCHE su linux. Parlo da persona che ha sostituito tutti i windows con linux, NON mi fiderei mai a sapere che la stabilizzazione è governata da un sistema del genere, anche senza l'uso di un'interfaccia grafica e sistema compilato/modificato appositamente.

La stabilizzazione deve essere fatta da un microcontrollore, o magari da un PLC, insomma nessuna complessità aggiunta al già complicato sistema di navigazione. Niente multithreading, a che ci serve? possiamo ottenerlo con un uso adeguato delle funzioni di lettura del tempo, senza la complicazione di kernel, processi, thread, priorità...

insomma vale la stessa regola della meccanica: ciò che non c'è non si può rompere/impallare. Che poi questo sistema di navigazione si interfacci con un PC con la sua "stupida" GUI per inserire/leggere i dati etc... mi va benissimo, ma se il PC si impalla il sistema deve proseguire senza problemi.

Ricordo che con 16MHz a 8bit e SENZA fpu (alu per i float) la maggior parte di software funziona (arduino), e basta salire a 40/60MHz magari con alu per stare "tranquilli con i tempi". Per quel che ho visto in giro, il grosso problema non è il tempo CPU, ma la memoria residente del programma

[lol21]

sconsiglio assolutamente un "mini ITX con Linux" o qualsiasi altro processore/cpu che richiede un sistema operativo. Parlo da programmatore, la complessità di quei software è alta, e non sono specifici per quella piattaforma. Risultato: possibile lag, piantamenti, crash, ANCHE su linux. Parlo da persona che ha sostituito tutti i windows con linux, NON mi fiderei mai a sapere che la stabilizzazione è governata da un sistema del genere, anche senza l'uso di un'interfaccia grafica e sistema compilato/modificato appositamente.

La stabilizzazione deve essere fatta da un microcontrollore, o magari da un PLC, insomma nessuna complessità aggiunta al già complicato sistema di navigazione. Niente multithreading, a che ci serve? possiamo ottenerlo con un uso adeguato delle funzioni di lettura del tempo, senza la complicazione di kernel, processi, thread, priorità...

insomma vale la stessa regola della meccanica: ciò che non c'è non si può rompere/impallare. Che poi questo sistema di navigazione si interfacci con un PC con la sua "stupida" GUI per inserire/leggere i dati etc... mi va benissimo, ma se il PC si impalla il sistema deve proseguire senza problemi.

Ricordo che con 16MHz a 8bit e SENZA fpu (alu per i float) la maggior parte di software funziona (arduino), e basta salire a 40/60MHz magari con alu per stare "tranquilli con i tempi". Per quel che ho visto in giro, il grosso problema non è il tempo CPU, ma la memoria residente del programma

parliamo in caso di arm con linux embedded, alla fine rimane una piccola parte del kernel il tutto va poi riscritto ma in maniera più comoda e pratica che permette mooolte più cose in modo mooolto più semplice.

anche se in realtà se volessimo mettere un mini ITX con linux non ci sarebbe alcun problema: basta ricompilare il sistema adattandolo appositamente a quello specifico hardware.

non capisco che crash potresti avere su un sistema ad hoc. Non stiamo parlando di mettere il disco ed installare ma di rifare per metà un kernel tenendo le parti più stabili e di base.
Inoltre non si passa oltre di frequenza ma di tipo di processore, un 8bit non andrà mai bene, basta mettere un GPS e sei fottuto, serve almeno un 32bit direi.

Io andavo sugli ARM e comunque credo che il multitasking sia davvero utile se pensi a quante equazioni saranno da svolgere in tempi di pochissimi millisecondi, ovvio che ad un aumento di "bit" diciamo aumenti anche la frequenza perchè è quello che richiedono le architetture

ciao
lol21

[ElNonino]

@elettro: con me sfondi una porta aperta, ti quoto al 1000%.

un PLC forse, anzi senza forse, è lentino ma un piccolo micretto a 16bit per esagerare basta ed avanza se programmato bene, in fin dei conti deve solo leggere qualche sensore e controllare alcuni motori/servi/accessori.

lol fidati i s.o. sono fonte di rogne a non finire, nei sistemi di controllo seri non si possono usare, immaginati un abs che giri sotto win7 e chi si fiderebbe ?

Un idea di disegno da cui partire potrebbe essere quella del mio DuctedKopter, io vedrei il pilota seduto stile F1 con alle spalle il ventolone di sostentamento, di fianco i 2 motori anteriori di stabilizzazione e dietro al ventolone gli altri 2 con in mezzo batterie e sistemi di bordo.

[elettro]

non capisco che crash potresti avere su un sistema ad hoc. Non stiamo parlando di mettere il disco ed installare ma di rifare per metà un kernel tenendo le parti più stabili e di base.

ah bè, se per te riscrive una parte di kernel è una cosa semplice...
se pensi che un kernel sviluppato da anni da geni della programmazione con decenni di esperienza sulle spalle HA dei bug, non vedo come noi potremmo fare di meglio.

credo che il multitasking sia davvero utile se pensi a quante equazioni saranno da svolgere in tempi di pochissimi millisecondi

il multitaskig, a meno che non sia sviluppato su di un sistema multicore, è UN RALLENTAMENTO, perché anziché aggiornare solo il tuo codice, devi aggiornare il kernel che poi aggiorna i tuoi thread... insomma AGGIUNGI codice.

Inoltre non si passa oltre di frequenza ma di tipo di processore, un 8bit non andrà mai bene, basta mettere un GPS e sei fottuto, serve almeno un 32bit direi.

su questo ai ragione, ma esistono microcontrollori a 32bit... poi sinceramente io farei: un micro che controlla solo l'assetto base (accelerometri, gyro, magnetometri, barometro), uno che gestisce la navigazione (GPS, triangolazioni di segnale, calcolo di rotta) e infine un micro o PC che gestisce le comunicazioni con l'utente o altri apparati. In questo modo, l'unico sistema vitale alla macchina è l'assetto base, che sarà magari doppio, un errore del sistema di navigazione spingerà l'assetto base ad un atterraggio in posizione attuale, un errore nel sistema di comunicazione spingerà ad un return-to-base o proseguimento della rotta o un atterraggio in posizione attuale (in base a cosa è stato "deciso" a priori)

se pensi a quante equazioni saranno da svolgere in tempi di pochissimi millisecondi

se una funzione è molto lunga da risolvere, e bloccherebbe il resto del micro per troppo tempo, la si divide in più "step", ed ogni ciclo eseguirebbe un pezzo di step.

Un grosso vantaggio di non avere il kernel, è che i tempi di esecuzione sono DETERMINISTICI, ovvero puoi calcolare esattamente il tempo di esecuzione di una formula, o il tempo massimo di esecuzione di una funzione (considerando negli if e nei cicli il caso peggiore). Questo permette una suddivisione a step molto precisa, anche se molto laboriosa. l'unico problema sono gli eventuali interrupt, che essendo nel sistema base solo verso la comunicazione seriale e ppm, ovvero a tempi fissi, è possibile calcolare, ovviamente assumendo il caso peggiore.

Nel kernel, invece, è molto più complicato: devi anche considerare il tempo del kernel, le priorità dei thread, i lock alle risorse condivise, etc...


edit: @ElNonino: mi hai preceduto mentre scrivevo questo papiro, però mi sembrava d'obbligo non dire "facciamo così, punto e basta" ma specificare bene le motivazioni.

[lol21]

ok mi avete convinto
ad ogni modo per il multitasking io proponevo un A9 proprio per il dual core e lasciare ad un core sistemi di assetto e all'altro trigonometria di GPS e cose quindi più complesse e l'interfacciamento con l'utente affidato ad un micro tipo atmega328 che non ha molta potenza di calcolo ma gestire un LCD alfanumerico ed inviare dati in seriale o I2C o protocollo da decidere è capacissimo

ciao
lol21

[pipposoft]

Ecco scatenato l'impossibile sulla scheda di controllo,
Allora, dico la mia, penso sia prematuro parlarne,
Ancora non sappiamo cosa controllare, non possiamo sapere
Cosa usare,
Se dobbiamo gestire motori elettrici,
Se dobbiamo stabilizzare con servi,
Se dobbiamo usare una IMU intelligente o una testina sensori
Comunque, dimassima, dico:
W i microcontrollori
W il multicontrollo

Facciamo la meccanica, poi la controlliamo ;-)

Pippo

[ElNonino]

Ecco scatenato l'impossibile sulla scheda di controllo,
Allora, dico la mia, penso sia prematuro parlarne,
Ancora non sappiamo cosa controllare, non possiamo sapere
Cosa usare,
Se dobbiamo gestire motori elettrici,
Se dobbiamo stabilizzare con servi,
Se dobbiamo usare una IMU intelligente o una testina sensori
Comunque, dimassima, dico:
W i microcontrollori
W il multicontrollo

Facciamo la meccanica, poi la controlliamo ;-)

Pippo

Approvato al 100%, per il mio progetto di UAV-coso evoluto sono ancora fermo alla meccanica, l'elettronica so come farla e non sarà un problema.

@elettro: sei stato chiarissimo, purtroppo molti giovani programmatori non sanno cosa sia il determinismo ed usano interrupt a go-go, mentre in certi ambiti è quasi vietato utilizzarne più di uno nel main ed al massimo un paio per servizi non critici, aborrono anche l'uso di variabili globali e magari non conoscono l'uso del DMA etc etc etc.

L'unico sistema multitasking efficiente che conosco è la donna: riesce a guidare l'auto, a fumare, a parlare al cellulare ed ad arrotare i pedoni tutto contemporaneamente

Se qualcuno avesse il disegno stilizzato di un pilota seduto stile F1 vettoriale od anche raster un disegnino della meccanica lo potrei buttar giù con Inventor.

[areis81]

Se qualcuno avesse il disegno stilizzato di un pilota seduto stile F1 vettoriale od anche raster un disegnino della meccanica lo potrei buttar giù con Inventor.

suggerisco una posizione tipo 'moto' più che formula uno. il motivo è semplice: lasciare al pilota libertà di movimento per migliorare la stabilizzazione e permettere un'espulsione dello stesso più rapida e semplice in caso di incidenti. essere scaraventati fuori da quel coso in movimento non è bello, ma è meglio che rimanerci intrappolati con le eliche che ti sfrantullano allegramente! :-(
non dimentichiamo che in caso di problemi non ha la possibilità di planare nè di entrare in autorotazione. sarebbe bello anche un sistema eventuale di eiezione di paracadute balistico per il solo pilota, magari da zaino a propulsione a razzo come quelli seri (con altri 15$ ce la si cava per quello! :-)

[pidue]

parliamo in caso di arm con linux embedded, alla fine rimane una piccola parte del kernel il tutto va poi riscritto ma in maniera più comoda e pratica che permette mooolte più cose in modo mooolto più semplice.

anche se in realtà se volessimo mettere un mini ITX con linux non ci sarebbe alcun problema: basta ricompilare il sistema adattandolo appositamente a quello specifico hardware.

non capisco che crash potresti avere su un sistema ad hoc. Non stiamo parlando di mettere il disco ed installare ma di rifare per metà un kernel tenendo le parti più stabili e di base.
Inoltre non si passa oltre di frequenza ma di tipo di processore, un 8bit non andrà mai bene, basta mettere un GPS e sei fottuto, serve almeno un 32bit direi.

Io andavo sugli ARM e comunque credo che il multitasking sia davvero utile se pensi a quante equazioni saranno da svolgere in tempi di pochissimi millisecondi, ovvio che ad un aumento di "bit" diciamo aumenti anche la frequenza perchè è quello che richiedono le architetture

ciao
lol21

io lascerei perdere linux, miniITX, 32bit, multitasking, ricompilazioni, ecc.ecc. Testare tutte queste cose in un ambiente simulato 'realistico' ha un costo folle, conviene affidarsi a qualcosa di già pronto. Se volete un qualcosa che voli anche da solo, buttate un occhio qua: MEMS IMU - 6DOF Inertial Sensors & Autolpilots For UAV, Drone and Underwater Vehicles- with Gyro, Accelerometer & GPS - Guidance, Navigation and Control . Se volete qualcosa di solido, schede PC/104, non ci sono alternative.

[ziojos]

Se non si deve trasportare "il pazzo" il progetto si semplifica se resta un modello
anche se grosso. I costi comunque non saranno banali ma diventano più fattibili.

Si può fare a meno del motore aeronautico e pensare ad un elettrico un pò spinto con due di quelli usati sul kart descritto nei due link seguenti si potrebbe spingere il coassiale.

Ormai nei kart vincono (o vincerebbero se non esclusi per regolamento) i motori elettrici, le caratteristiche elettromeccaniche in caso di tutto elettrico sarebbero simili a quelle di questo kart del costo 12 K€ :

‪Go kart elettrico batte tutti i 125cc‬‏ - YouTube

‪Dati tecnici Kart Elettrico‬‏ - YouTube

Oggi si trovano anche moto da cross ed enduro elettriche e molto performanti


ovviamente il "pippocoso" sarà molto più complesso del kart

Per le pile a combustibile la vedo veramente dura in termini economici.
La Honda ne ha di molto buone e relativamente leggere .... ma non credo che le regali ammesso che sia disposta a darle.

Ciao

[ElNonino]

i Kart non volano, con 11Cv una motoretta passa i 150 km/h con la stessa potenza non si alza un mezzo ad ala fissa.

Le Lipo sono pericolose oltre certe dimensioni/capacità, io vivo di elettroni però per alcune cose la combustione interna è ancora, ad oggi, preferibile ed avvantaggiata.

Se volete la fabbrica delle A123 costruisce celle particolari, su specifica del cliente, con prestazioni notevoli, sono utilizzate da quasi tutte le case automobilistiche che hanno modelli elettrici in catalogo.

Bisogna per me intendersi su una cosa, studiamo un modello futuribile od un veicolo realizzabile in termini di tempo ragionevoli ?

Se si optasse per la seconda soluzione bisognerebbe stabilire ad esempio un possibile costo del prodotto finale; questo non con l'intento di sfruttamento commerciale del progetto ma per far restare tutti con i piedi per terra.

[lol21]

ma per la scheda:
Pandaboard
consolidata, ottimo kernel, dual core, potenza fin troppa dite che non va bene?

ciao
lol21 (il fissato con l'elettronica sapendo poco)