Altri nuovi sistemi FLYBARLESS

[vs0587]

Sistema FBL Tarot............. in Italia......

TAROT 3 Axis Gyro

[sescot]

Originalmente inviato da vs0587

Sistema FBL Tarot............. in Italia......

TAROT 3 Axis Gyro

88 commenti... Va via come il pane!

[infinity]

Originalmente inviato da tecman

intanto il pm me lo hai mandato come un fulmine
paura ehhh!!!

io, ti ho mandato pm? ma quando mai? Io i PM neanche li so mandare!

ok..lo confesso un po' di strizza mi era venuta!

[eriskio]

Originalmente inviato da Heliup

Non sia mai che si parla di qualcosa di tecnico e magari si impara qualcosa, molto meglio le solite polemiche sui prezzi

Corrado

Cito il tuo commento solo come spunto di riflessione.
Vedi so per certo che Archi è anni che si occupa per lavoro di programmazione di automazione industriale e io è oltre un decennio che per lavoro sviluppo software realtime e sistemi per telecomunicazioni. Stiamo parlando (con tutti i 'se' e i 'ma' del caso, che ci sono sempre) di un mondo su cui possiamo aprire un'enciclopedia.
E qui chissà quanti altri hanno attività simili e/o esperienze concrete sull'argomento (che ovviamente non conosco - a cominciare da Alexvan).
La diatriba Sistema Operativo sì o no è una cosa lunga e complessa che se vogliamo possiamo anche affrontare e comunque sarebbe una discussione che non porta praticamente a nulla: il software non importa come lo fai ma deve funzionare ed essere efficiente - possibilmente a costi inferiori della concorrenza.
Le soluzioni che indicava Alexvan hanno pregi & difetti come in ogni cosa del resto: utilizzare sistemi di sviluppo evoluti significa pagare di piu' in hardware ad esempio e quindi - a fronte di una possibile riduzione dei costi di sviluppo - si ha un incremento del costo di produzione del pezzo singolo.
Caso per caso va' valutata la convenienza e spesso vale piu' lo skill degli sviluppatori che si hanno in casa (ovvero la loro capacità di scrivere codice efficiente e velocemente ottimizzando i tempi di sviluppo) piuttosto che inseguire la moda del momento (che significa allungare i tempi di sviluppo aggiungendo un overhead notevole di "istruzione e studio").
Insomma, al di là dell'ultima novità, i fattori che conducono ad una scelta sono - come potete ben immaginare - notevoli.
Ma quel che piu' importa è che - indipendentemente dai tools di sviluppo e dal linguaggio utilizzato - si raggiunga il risultato voluto.
Esistono del resto in rete miriadi di applicazioni (anche per PC) scritte addirittura in Assembler che sono delle vere e proprie "chicche" perchè compatte (pochi Kb), massimamente efficienti (velocità da paura) e assolutamente affidabili (e i programmatori Russi in questo sono dei campioni, ma questo è un altro discorso ).
Certo ormai anche sui MC e sui sistemi embedded/realtime è difficile dover ricorrere al vecchio Assembler e si scrive tutto in C/C++, almeno (ma esistono notevoli risultati ad esempio con linguaggi funzionali - Erlang per citarne uno del mio ambiente - e non procedurali). Sviluppare sistemi embedded in java - a parte il notevole esercizio di stile - per un prodotto commerciale è abbastanza da folli, almeno per quello che so' io.
Certo è che nel caso di una centralina flybarless - dovessi progettarla io - l'ultima cosa che mi verrebbe in mente è di metterci sopra un Sist Op "battezzato", o quantomeno non sarebbe questo un problema di particolare rilievo. In fondo scrivere un motore efficiente di scheduling/message passing o un piccolo sistema "event driven" per la gestione interrrupt - specie con linguaggi ad oggetti - non è problematico e di solito chi sviluppa questo tipo di applicazioni ha nel cassetto piu' templates o canovacci belli e pronti da riutilizzare allo scopo, senza troppa fatica.
E' per tutti questi motivi che mi sembrava di andare OT - pensando all'interesse dei modellisti e non degli sviluppatori - , ma mica detto che io abbia ragione, anzi! Io ho solo espresso un mio punto di vista e se vogliamo continuare, per me va' piu' che benissimo!

Sicuramente io pur lavorando nel settore informatico non mi occupo certo di sistemi di automazione industriale, automotive o embedded. Quindi la mia è più una curiosità di sapere come sta evolvendo questo ramo un po particolare del mondo it.

Cambiando leggermente discorso: abbiamo visto come arduino ha avuto importanti ricadute sui multirotore. E come abbiamo vista la problematica è talmente simile (sempre di giroscopi e stabilizzazione su tre assi si tratta...) che lo stesso hw può svolgere entrambe le cose. Non sarebbe carino avere un sistema di stabilizzazione su tre assi per heli open e liberamente customizzabile da chi è in grado di farlo?

Vi risulta qualche progetto in tal senso?

[torazza]

Originalmente inviato da m.rik

Non era assolutamente mia intenzione fare del terrorismo. Volevo solo far presente che non sempre è tutt'oro ciò che luccica (un bel display luccicoso) ma che in questi sistemi con display incorporato non è solo "tutto meglio". Oltre a quello del maggior costo, ci sono anche altri aspetti negativi (tanto o poco che sia nel mio ragionamento non contava).
Io poi a livello di costi dovrei mettere in preventivo di rifare gli occhiali da lettura o i bifocali per riuscire a leggere questi micro display. Soprattutto quello del GT5.
La spesa inizia a più che raddoppiare se li prendo antigraffio e fotocromatici e con una nuova montatura .

Comunque sia, agganciandomi alla tua analisi, ammesso che le ipotesi di maggior consumo e maggior peso corrispondano al vero, anche soli 2,4 secondi di volo in meno sono un bel minutino di volo in meno e perso ogni 25 voli.
Non è terrorismo è solo "il rovescio della medaglia" (per restare nel campo numismatico).


Ciao

L'analisi dei tempi di volo è pessimistica. Per farti un esempio il protos stretch FBL @2700rpm, senza pale e palini assorbe 84W solo per gli attriti di trasmissione, che sono indipendenti dal peso. Se aggiungi pale e palini a 0° questo numero aumenterà parecchio (almeno il triplo), quindi circa 10A. Se consideri che scaricando in 4 minuti 2Ah hai un assorbimento medio di 30A, almeno il 30-35% è indipendente dal peso (e non abbiamo contato la resistenza aerodinamica all'avanzamento e l'incidenza delle pale che aumenta le dissipazioni all'aumentare dell'angolo...). Quindi i 2,4 secondi credo siano in realtà 1,5s o meno... inoltre un display non può assorbire diversi ampere... sara al massimo qualche decina di mA...
In ogni caso concordo con te sui pesi anche io ci faccio molto caso: pensa che sostituendo il servo di coda da 25g con un MKS "metallico" da 60g ero molto contrariato da questa aggiunta di peso...
Eriskio può aiutarci sui numeri, anche lui ha fatto delle isure sui suoi heli.
Beato te che hai problemi di vista da vicino: io sono miope ed è peggio :-) vedrei benissimo il display microscopico, meno l'heli quando è distante :-(
Ciao

Originalmente inviato da eriskio

Certo ormai anche sui MC e sui sistemi embedded/realtime è difficile dover ricorrere al vecchio Assembler e si scrive tutto in C/C++, almeno (ma esistono notevoli risultati ad esempio con linguaggi funzionali - Erlang per citarne uno del mio ambiente - e non procedurali). Sviluppare sistemi embedded in java - a parte il notevole esercizio di stile - per un prodotto commerciale è abbastanza da folli, almeno per quello che so' io.
Certo è che nel caso di una centralina flybarless - dovessi progettarla io - l'ultima cosa che mi verrebbe in mente è di metterci sopra un Sist Op "battezzato", o quantomeno non sarebbe questo un problema di particolare rilievo. In fondo scrivere un motore efficiente di scheduling/message passing o un piccolo sistema "event driven" per la gestione interrrupt - specie con linguaggi ad oggetti - non è problematico e di solito chi sviluppa questo tipo di applicazioni ha nel cassetto piu' templates o canovacci belli e pronti da riutilizzare allo scopo, senza troppa fatica.

Io parlo di soluzioni tipo questa FreeRTOS-A Free professional grade RTOS supporting 27 architectures, including ARM7, ARM9, Cortex-M3, RX600, MSP430, MSP430X, MicroBlaze, AVR, x86, PIC32, PIC24, dsPIC, H8S, HCS12 and 8051. Non certo un sistema operativo come linux... Non mi occupo specificatamente di sistemi embedded ma da bravo sviluppatore mi sembra un ottimo punto di partenza per realizzare soluzioni embedded senza reinventare la ruota...

[eriskio]

Originalmente inviato da Alexvan

Sicuramente io pur lavorando nel settore informatico non mi occupo certo di sistemi di automazione industriale, automotive o embedded. Quindi la mia è più una curiosità di sapere come sta evolvendo questo ramo un po particolare del mondo it.

Cambiando leggermente discorso: abbiamo visto come arduino ha avuto importanti ricadute sui multirotore. E come abbiamo vista la problematica è talmente simile (sempre di giroscopi e stabilizzazione su tre assi si tratta...) che lo stesso hw può svolgere entrambe le cose. Non sarebbe carino avere un sistema di stabilizzazione su tre assi per heli open e liberamente customizzabile da chi è in grado di farlo?

Vi risulta qualche progetto in tal senso?

Beh ad esempio si può partire da questo hardware con scheda Arduino (Così ci semplifichiamo la vita ) ; e ci sarebbe da provare anche questo FreeIMU oppure questo, sempre per Arduino.
Solo idee buttate lì, tanto per suggerire qualche punto di partenza, ovviamente.

Ciao


Edito: in effetti non conosco sistemi/progetti freeware per flybarless heli, ho letto male la tua domanda, scusa. I sistemi suggeriti potrebbero essere solo punti di partenza per un eventuale progetto.

Ovvaimente la lista è lunga:
BeRTOS — Not only kernel
Prex - Embedded Real-Time Operating System
TNKernel real-time system
...

Son tutti opensource!

Continuiamo ad inventare la ruota?

Originalmente inviato da eriskio

Beh ad esempio si può partire da questo hardware con scheda Arduino (Così ci semplifichiamo la vita ) ; e ci sarebbe da provare anche questo FreeIMU oppure questo, sempre per Arduino.
Solo idee buttate lì, tanto per suggerire qualche punto di partenza, ovviamente.

Ciao


Edito: in effetti non conosco sistemi/progetti freeware per flybarless heli, ho letto male la tua domanda, scusa. I sistemi suggeriti potrebbero essere solo punti di partenza per un eventuale progetto.

Vado a studiare... servirebbe pure un modello da utilizzare come stub durante lo sviluppo. Una sorta di simulatore. Esisterà qualcosina di opensource adattabile?