PantherTank.NET - INTERFACCIA GIOCO/COMBAT

Versione Completa   Stampa   Cerca   Utenti   Iscriviti     Condividi : FacebookTwitter
Pagine: 1, 2, [3], 4, 5
plgGe
00martedì 23 luglio 2013 13:37
Di quello che scrivete non ci capisco niente però mi pare si stia sviluppando uno scambio di idee promettente per sviluppi operativi [SM=g2915775] .
Molto bene [SM=g2915736] [SM=g2915736] [SM=g2915736]

tigrotto1a6
00martedì 23 luglio 2013 14:55
Ho spostato un pochino troppo la discussione sul sistema di battaglia, esso in realtà è un completamento dell'interfaccia che Mauro aveva in mente. Siccome lui legge poco il forum le risposte verranno in tempi più o meno lunghi.
Mauro comunque era più affaccendato a creare un'interfaccia di guida e visione del mezzo attraverso smartphone, tablet, e così via, un'interfaccia grafica che mostri le immagini live del carro e che mostri vari parametri. Da li poi l'eventuale battaglia.
Il problema maggiore nel farlo è la banda da usare (wifi quasi sicuramente) e la riduzione dei ritardi nell'invio del video.
In pratica l'immagine analogica colpisce la telecamera che la converte in digitale, il segnale viene poi inviato, ricevuto, decodificato ed inviato al monitor, in tutto questo c'è ovviamente un tempo che dipende dal formato e compressione del file, dalla velocità hardware e dal segnale stesso. Quindi quello che si vede su schermo potrebbe essere quello che il carro vedeva mezzo secondo o un secondo prima. Certo, non andiamo veloci, ma nel puntamento potrebbe dare maggiori problemi come pure nel guidare dal monitor vicino ad ostacoli.
Una possibile soluzione è lasciare fare tutto al computer, cioè inviare il video in analogico, poi con un software ed una scheda di acquisizione rimettere il video sul computer (che comunque presenterà almeno un minimo ritardo) ed usare un overlay per sovrapporci il resto del programma... Ma qui bisognerebbe usare tutti la stessa scheda di acquisizione per vestire il programma su quello della scheda di acquisizione... Beh, altra idea insomma...
Se poi vogliamo farci male, alcuni software per webcam riescono ad identificare dei "beacon" IR, cioè dei led messi appunto per farli riconoscere, altre webcam permettono il riconoscimento facciale, il tutto dipende dal software... via software insomma si potrebbe creare un sistema che identifichi il carro e se si preme fuoco quando il carro è inquadrato al centro, invia il segnale "ti ho colpito"...
Hai voglia a spunti... Poi per la realizzazione è un altro paio di maniche!
DuncanIta
00mercoledì 24 luglio 2013 09:10
Per il video non la vedo così complicata, basta prendere una comunissima webcam usb ed attaccarla, facendo attenzione che sia compatibile con l'hardware scelto, poi si tratterebbe di inciare in streming. Unico dubbio grosso è, quanto carri vogliamo gestire contemportaneamente?

Perchè se son 5 la velocità di connessione dovrà essere X, se son 10 sarà 2X e non è detto che il wifi riesca a gestirla, anche un eventuale wifi a 300 Mbps


Allora riepiloghiamo un po'.

- Vogliamo un battle system
- Possibilita di degradare le prestazioni dei mezzi rispetto ai danni ricevuti
- possibilità di visualizzare cosa sta puntando il carro

Se concordate apro una board su trello per raccogliere tutte le esigenze e comincire a gestirle, ordinarle per priorità.
Questo perchè dobbiamo cominciare a scrivere qualcosa (ormai dopo le ferie, quindi a settembre) riducendo la complessità ed affrontando un problema alla volta, altrimenti rischiamo di voler far troppo ed alla fine non fare nulla.
Marco-64.
00mercoledì 24 luglio 2013 13:40
Riepilogando se ho capito bene,
creiamo una lan wifi nella zona in cui vogliamo battagliare e tramite quella scambiamo i dati tra i vari carri?
la web cam a cosa serve, per puntare il "nemico"?
perchè per il FPV si usano delle periferiche specifiche con il loro trasmettitore/ricevitore dedicato, attualmente lo usa solo Tigrotto 1a6.
questo un link a periferiche FPV:
www.hobbyking.com/hobbyking/store/__543__172__FPV_Telemetry-...
nello stesso sito trovi riferimenti per le telemetrie per gli ESc ed altre robette.
ciao ciao
tigrotto1a6
00mercoledì 24 luglio 2013 13:50
Si' l'idea migliore è di utilizzare una connessione wifi (o creare una rete ad altra fequenza) con cui comunicare carro vs periferiche (tablet, pc, altro) e viceversa.
La telecamera è il problema maggiore secondo me.
Cioè, il video va a riempire molta banda, per ovviare al limite si potrebbe usare un sistema analogico tipo quello per le chiavette tv che si collegano al pc. Il sistema sfrutta l'overlay video, cioè più o meno la visualizzazione del video su uno sfondo di un determinato colore, colore che potrebbe essere quello dell'interfaccia, ergo, vedremmo il carro sull'interfaccia.

Problemi:
Creazione del softwae in primis
Se si usa il video analogico c'è da guardare alle frequenze, dubito riusciremmo a mettere insieme più di 4 o 5 carri, contando che con il wifi per la trasmissione dati bisogna non usare i 2,4GHz di banda per il video.Il video digitale invece ha il problema dei ritardi...
DuncanIta
00mercoledì 24 luglio 2013 13:56
Se mi passate in pm le email da mettere in trello vi condivido la board che ho fatto in cui ho inserito giusto 4 cose, così potete vedere anche voi.

Comunque come detto facciamo un passo alla volta, per implementazioni successive.
plgGe
00mercoledì 24 luglio 2013 14:07
Pur non avendo bevuto alcoolici [SM=g1865386] quando leggo i vostri posts mi sento vacillare [SM=g8877] .

Cio-non-di-meno [SM=g10321] [SM=g27822] dico la mia.
E' vero che raggruppare 4-5 carri è già un'opera titanica però non si sa mai.
Allora se realizzare 'sti aggeggi che funzionino con una "...velocità di connessione ... 2X ..." non costasse molto di più di quelli che funzionano ad una velocità x direi di utilizzare il sistema più potente (non so se "potente" sia il termine corretto) per non mettere limiti alla provvidenza.
Sarebbe un peccato dover rinunciare a giocare tutti per un limite del sistema.
Invece se al sistema a velocita x basta aggiungere una valvola per farlo diventare 2x allora possiamo (potete) partire col sistema più leggero.

DuncanIta
00mercoledì 24 luglio 2013 14:39
Il problema è proprio tecnologico, le rete wifi più veloci attualmente arrivano 300 Mbps (in condizioni ottimali, oltreuttto mi pare che se ho più client collegati mi pare che la banda venga suddivisa tra tutti, quindi di fatto diminuisce), sono molti, ma avendo in battaglia 10 carri basteranno? Probabilmente si, ma fino a quando non cominciamo a fare prove sarà difficile rendersene effettivamente conto.
tigrotto1a6
00mercoledì 24 luglio 2013 15:26
Anche io sono a favore per un discorso di implementazioni successive... intanto facciamo le cose semplici, poi aumentiamo le difficoltà e anche io so che se si connettono più dispositivi la banda si divide nei vari utilizzatori
All'inizio del topic si parlava dell'interfaccia pc-carro per pilotarlo, direi che questa è la base...
Ora anche qui con l'evoluzione dei computer, tablet e smartphone pone un bel quesito... Su che piattaforma (android, mac os, Windows ecc...) sviluppare il programma?
Io vi dico da subito che sono contrario al mac, ma se poi decidete per quello vabbè, vedrò di adattarmi! Di mio direi Windows, un portatile non costa molto, offre un display più ampio di un tablettino di quelli da 7" e lo si usa per altri 200mila motivi.
Tra l'altro con lo sviluppo degli ultrabook presto anche il touch diventerà molto economico su quelle macchine.
I dati utili da trasferire dovrebbero essere:

Comandi (tx)
telemetria (rx)

Nella telemetria includerei i principali dati che dovrebbero essere i consumi del carro (potenza assorbita, corrente, voltaggio) e lascerei tanto spazio libero per il resto (sistema di battaglia ecc...)

Video, io direi che il video per ora vada trasmesso a bassa risoluzione, 640x480 a 16-20fps al massimo, ed usare la telecamera "coassialmente" al cannone. Eventuali altre telecamere (come per l'FPV) devono stare purtroppo a parte per ora, oppure far si che ci sia uno switching tra le telecamere direttamente dal modello, in modo che si invii una sola immagine via wifi.

Il discorso è ora vedere l'hardware che accomodi i sensori, e purtroppo quello lo si deve vedere con tutti gli eventuali ammennicoli che ci vogliamo mettere. Questo perché altrimenti si rischia di rimanere limitati e dover cambiare hardware ad ogni aggiunta(battaglia, telemetria completa, sensori vari)

Ci vuole un wattmetro o sensore di corrente + voltmetro;
Una o più telecamere
sensore gps (e/o inerziale)
Bussola (magnetometro) x2 (torretta e scafo)
sensore assetto (il meno importante)
Sensore IR ricevente gli spari (più sensori, più precisione)
Led potente per sparo degli impulsi
Interfaccia con il sistema RC per almeno 6 canali. [SM=g1865391]
Il resto è praticamente solo software.
Dimentico qualche cosa?
DuncanIta
00mercoledì 24 luglio 2013 15:31
Avevo in mente di fare tuto il più portabile possibile, niente di legato ad un'architettura particolare, addirittura se fosse possibile farlo con interfaccia da browser sarebbe l'ideale, in fondo se ogni carro dentro ha un minipc è possibile metterci un webserver dentro, a qual punto poi si ha la massima libertà.
Marco-64.
00mercoledì 24 luglio 2013 20:50
Io mi sto un pochino perdendo, mi spiego meglio:
ho appena preso la DX8 che ha la telemetria integrata,
si vuole eliminare il Radiocomando?
stavo seriamente pensando di comprare un sistema FPV meno male che non l'ho ancora preso,
non è più comodo usare un sistema FPV dedicato a parte cosi non ruba banda per i dati?
Secondo il mio parere sarebbe più comodo un sistema che si inserisce tra la ricevente del carro e le periferiche (ESC - Sound board - Servi Ecc....) gestendo il posizionamento, il battle sistem, la gestione dei danni.
non dimentichiamoci che per noi i consumi elettrici sono fondamentali, io ho a disposizione 24 Volt 22 A/h sul PzIII quando sara finito sullo Stuart ho una batteria da 12 volt 7 A/h, Pier - Luca - Iacopo - Demis hanno le stessa batterie mie, batterie prese in stock insieme [SM=g7278] [SM=g7278] , tigrotto so che va a 12 volt con batteria da auto sul tigre,
bisogna fare i conti anche con quello o,
dobbiamo aggiungere una altra batteria solo per il Minipc.
Ciao ciao
tigrotto1a6
00giovedì 25 luglio 2013 08:07
L'idea del topic era la sostituzione di tutto l'apparato radio con il sistema "computerizzato" così come penato da Mauro.
Non credo che il raspberry consumi molto di più di un sistema FPV, anzi, l'FPV trasmettendo video analogico necessita di molta potenza per la trasmissione, una trasmissione digitale ne richiede di meno.
Purtroppo però dalle idee ai fatti credo si parli di anni di attesa, quindi per ora si continua con i sistemi tradizionali.
Si potrebbe però discutere di priorità...
Per aggiungere miglioramenti evidenti anche al pubblico bisognerebbe fare sto benedetto sistema di battaglia, a prescindere da come si comanda il carro, solo che quella è in un'altra discussione, qui si parlava dell'interfaccia completa.
[SM=g27811]
Marco-64.
00giovedì 25 luglio 2013 08:20
no no questo è il topic giusto, solo che in questo si discute della parte hardware, c'è un altra discussione per la parte software.
ciao ciao
DuncanIta
00giovedì 25 luglio 2013 09:45
Basta decidere le priorità, come detto, aggiungere la parte radiocomando non dovrebbe essere un grosso problema visto che si trova molto già fatto tipo questo per esempio paulbleisch.com/blog/2013/01/03/simple-remote-controlled-ardui...

Come ho detto ho fatto una board su trello in cui è possibile cominciare a vedere meglio quali sono le richieste e le priorità, per avere accesso basta che mi mandate un messaggio privato con l'email su cui abilitare l'accesso
DuncanIta
00giovedì 25 luglio 2013 12:19
Cominciano ad arrivare le richieste per la board, ogni card che vedete è possibile editarla, commentarla, inserirci check list, allegarci immagini e link di documenti da google drive, o dropbox

In generale se avete propotre preferirei che le aggiungeste nella lista "Vorrei".

Vorrei anche usarla come piattaforma per decidere le priorità con la funzionalità messa a disposizione da Trello, cliccando su una card vedrete il tasto "Vote", poi ordineremo le card di conseguenza e qualla sarà la priorità che seguiremo.
DuncanIta
00giovedì 25 luglio 2013 16:23
Non vorrei essere troppo ottimista, ma ho trovato questo progetto, usato per i quadricotteri e già c'è molto da riusare, come l'interfacciamento con le riceventi delle seguenti marche: Spektrum, Graupner, Robe, Hitec, Futaba, Hitec, Sanwa

Ripeto non vorrei essere troppo ottimista, ma direi che dovrebbe essere possibile implementare nel battle system il degrado delle prestazioni secondo i danni assegnati.



P.S.: aggiungo il link dove ho trovato le informazioni
aeroquad.com
Aggiungo anche questo per completezza

www.arducopter.co.uk/
Marco-64.
00giovedì 25 luglio 2013 20:24
non so se è meglio qua o nel topic software, al massimo si sposta.

Metto un paio di link in cui viene spiegato come funziona un servo, lo metto perchè quello è il tipo di segnale con cui abbiamo a che fare, sia che dobbiamo comandare un servo o far funzionare un ESC, per simulare un danno si deve limitare l'escursione (Duty cycle) del servo/segnale o bloccarlo del tutto:
www.truckmodel.it/public/openasp/default.asp?modulo=pages&i...
in questo link c'è un circuito a comando seriale per pilotare 8 servi:
www.basicx.it/index.php?D=1&page=articoli.php&id=10
spero sia utile.
ciao ciao
DuncanIta
00giovedì 25 luglio 2013 20:57
Grazie, li metto nelle cose da studiare :)
DuncanIta
00domenica 28 luglio 2013 08:55
Grazie :)

Leggendo un po' in giro mi sto facendo l'idea che basti una Arduino Due per far tutto quello che ci serve.
Marco-64.
00domenica 28 luglio 2013 14:15
Non conoscendo niente di arduino ed essendo completamente a digiuno di programmazione, sto cercando di documentarmi e di trovare informazioni, ogni tanto trovo cose interessante, tipo questa applicazione:
minijoystich da Ps2 più 5 tasti:

fonte:
www.electan.com/arduino-shield-joystick-sparkfun-p-3077.html

si trovano anche i joystick senza tasti o i tasti solamente

molto interessante anche questa:
joystich 6 tasti (+1 mini interruttore a slitta?) e display da cellulare:

fonte:
www.tjskl.org.cn/products/freaduino_atmage328_joystick_shield_extended_rocker_panels_nokia_5110_lcd_display-mpz5361421-z5093382/showimage...
ciao ciao
Marco-64.
00domenica 28 luglio 2013 14:44
Visto che parlavate di eliminare il radiocomando, date un occhio quà:
www.cheapcontrolsystems.com/
usano un joypad wireless da Ps2 per comandare un carro.
ciao ciao
tigrotto1a6
00domenica 28 luglio 2013 18:14
Re:
DuncanIta, 28/07/2013 08:55:

Grazie :)

Leggendo un po' in giro mi sto facendo l'idea che basti una Arduino Due per far tutto quello che ci serve.




Con arduino DUE avremo grossi problemi di voltaggi, arduino 2 usa solo 3,3V, bisognerebbe affiancargli un adafruit servo shield che è un driver per servi. Il che è anche buono perchè con 2 semplici fili connessi all'I2C permette di comandare fino a 16 servi. (o comunque utenze in pwm)

Il problema è che arduino non gestisce gli input PPM (che è diverso da PWM) in maniera ottimale.
Ciò implica che se vogliamo usare arduino si deve seguire la strada del buttare via il radiocomando.
Vien da se che quindi si andrebbe con una trasmissione come il wifi o qualcosa a 433MHz. In ogni caso bisogna vedere i limiti che impongono in quanto a quantità di utenti, raggio d'azione e velocità di reazione.
Il carro deve essere gestibile nel campo visivo, direi almeno 50mt, di più fino ad ora non si è mai reso necessario, non sempre (specie per l'FPV) il carro però può essere a vista. E li si sa che 2,4GHz in presenza di muri si comporta non molto bene, si rischia di fermare il tutto poco dopo.
Bisognerebbe studiare l'aspetto suddetto per decidere se usare le vecchie radio (e a questo punto decidere cosa usare come piattaforma) o creare qualcosa di nuovo come comandi ed usare arduino. Il nuovo sistema deve avere almeno 6 canali proporzionali (analog) e il resto basta digitale (se ne servono di più fatelo sapere).

Per chiarificare meglio sull'uso di radio RC con arduino (problema grosso e al quale ho cercato soluzioni senza trovarne di pratiche) il problema come detto è gestire gli input.
Il PPM in pratica può essere scansionato da arduino solo tramite comando interrupt e arduino ne consente (se non ricordo male) solo 2. Non solo, la cosa appesantisce molto la capacità di calcolo dell'arduino e lo rende molto soggetto a finire fuori memoria.
Per utilizzare il PPM di chessò 10 canali, basterebbe usare un solo interrupt. Il trucchetto sarebbe quello di prendere il segnale completo che la radio invia alla ricevente, direttamente a monte della ricevente.
Ciò richiederebbe ad ognuno quindi di aprire la ricevente, trovare il punto dove il segnale radio diventa un segnale valido, prima che la ricevente lo separi per ogni canale, saldarci un filo e mandarlo ad arduino. Questo può risultare inpraticabile su alcune riceventi, potrebbe risultare difficle a qualche utente, e devo ammettere che senza un tutorial anche io non saprei come fare.
Arduino 2 potrebbe forse avere maggiori possibilità con un processore a 32bit, ma non so fino a quanti interrupt si possono usare.
Tutti gli altri esempi in cui si vede l'uso di una radio RC per pilotare qualcosa era per pilotare ON OFF senza proporzionalità.
Li si prendeva il segnale, si contava il tempo in cui l'impulso era high e si diceva SE superiore fai, se inferiore fai. Puoi gestire 3 o 4 stati, ma non troppi come per un segnale proporzionale.
Te lo dico perchè mi ci sono già arenato con il mio indicatore di giri motore per il semicingolato.
DuncanIta
00domenica 28 luglio 2013 23:27
Da quel che dicno le specidiche Arduino due può pilotare 54 canali digitali e 12 accnali analogici, non ci dovrebbero essere problemi.

Oltretutto viene usato insieme a riceventi futaba hitec ecc per pilotare i quadricotteri, se va bene per quegli usi non dovrebbero esserci problemi neanche con un carro, o mi son perso qualcosa?

Almeno un test lo farei, su arduino si trova una quantità enorme di materiale che può aiutarci a sveltire lo sviluppo

tigrotto1a6
00lunedì 29 luglio 2013 00:45
Re:
DuncanIta, 28/07/2013 23:27:

Da quel che dicno le specidiche Arduino due può pilotare 54 canali digitali e 12 accnali analogici, non ci dovrebbero essere problemi.

Oltretutto viene usato insieme a riceventi futaba hitec ecc per pilotare i quadricotteri, se va bene per quegli usi non dovrebbero esserci problemi neanche con un carro, o mi son perso qualcosa?

Almeno un test lo farei, su arduino si trova una quantità enorme di materiale che può aiutarci a sveltire lo sviluppo





Quando dici pilotare vuoi dire output, io ti parlo invece di input...
Non c'è verso, escluso gli interrupt, di leggere il segnale da una radio RC.
E il modo migliore sarebbe questo:
rcarduino.blogspot.it/2012/11/how-to-read-rc-receiver-ppm-str...

Il problema è che se lo fai per 2, 3 persone, puoi aprire e vedere dove si trova il de multiplexer e beccare il pin con il ppm, quando però rendi la cosa commerciale, il ppm in quel modo non lo puoi usare. Usando le uscite della ricevente saresti limitato a 2 uscite (2 interrupts che sono il limite di arduino).
Che poi arduino muova tutti i servi che ci servono, ok, ma con una radio RC solo nel modo di cui sopra possiamo dirgli come muoversi.

Per di più i servi funzionano a 5V e anche il loro segnale se non sbaglio viaggia su quei voltaggi, arduino due funziona a 3,3V sia in input che output, immagino che un segnale da 3,3V sia debole per alcuni dei servi che circolano in commercio. Quindi con il 2 lo shield sarebbe obbligatorio.
Aerei e quadricotteri spesso usano ardupilot, arduino con interrupt e segnale ppm preso come da link sopra, o arduino senza ausilio di sistema radio RC, quindi wifi o altro sistema di comunicazione.
Quello quindi che c'è da vedere è cosa usare... se andiamo con le radio RC, compatibili con l'intero pianeta, la via di arduino è più complicata, l'alternativa invece è quella di crearsi il controller usando o assemblando qualcosa (come quelli postati da marco) ma in tal caso bisogna vedere anche i limiti di quanta gente può usare contemporaneamente i carri, non vorrei che al 10mo che accende il carro, esso non si colleghi con il sistema di comando perché ce ne sono altri 9 già in trasmissione.
Io non voglio assolutamente frenare gli animi, ma siccome mi ci sono già arenato, vi dico le cose come stanno.
Se mi trovate una soluzione per usare un arduino con radio rc che sia possibile usare con tutte le radio senza modifiche vi accendo un cero in una qualsiasi chiesa. perché è quello che mi serve per il mio indicatore rpm motore che devo mettere al semicingolato. [SM=g27811]
DuncanIta
00lunedì 29 luglio 2013 08:48
Sono fuori, risposta veloce.

Arduino Due dovrebbe gestire 12 canali PWM

Per il problema del voltaggio ci dovrebbero essere shield specifici
DuncanIta
00lunedì 29 luglio 2013 10:28
Integro con questo link, scusate ancora la fretta

rcarduino.blogspot.it/2013/04/reading-rc-channels-with-arduino-due....
tigrotto1a6
00lunedì 29 luglio 2013 12:56
Come avevo detto io... lo shield è necessario come sono necessari più interrupt per gestire più canali. Arduino due pare essere in grado (col suo processore a 32bit) di supportare più interrupt così come si vede dallo sketch che hai postato. Bene, si può procedere ;) [SM=g27811]
Marco-64.
00lunedì 29 luglio 2013 14:09
Mi sono andato a cercare "adafruit servo shield "
trovato in italia quà:
www.robot-italy.com/it/adafruit-motor-stepper-servo-shield-for-arduino-kit-v...
e quà:
www.robotstore.it/product/358/Adafruit-Motor-Stepper-Servo-Shield-per-Ardu...
il sito del produttore quà:
www.adafruit.com/products/81
Non ho capito quanti servi (solo 2?) supporta ma, mi è risultato interessante che può pilotare direttamente sino a 4 motori dc, ottimo per l'alzo del cannone e il girare della torretta ho letto funzionanti da 4,5 volt a 25 volt DC 0,6 A continui 1.2 A di picco speriamo che reggano le batterie life che hanno qualche Volt in più.
ciao ciao
P.s. trovato solo ora questa versione:
www.adafruit.com/products/1438
1,2 a Continui 3 A di Picco con tensione da 4,5 volt a 13,5 volt
tigrotto1a6
00lunedì 29 luglio 2013 15:19
Io avevo visto un adafruit fino a 16 servi, comandati da 2 soli fili (connessione i2c)
Per i servi non c'è alcun problema, si usa solo il segnale e per la potenza si preleva a monte da un BEC dedicato o batteria, in modo che possano assorbire quanta più corrente serve senza appesantire arduino ed il suo shield.
Per i motori dato che arduino gestisce i PWM, tramite dei mosfet condensatori e resistenze si potrebbe creare un ESC apposito per i piccoli motori. Per i motori principali nonostante ci siano dei motor shield che arrivano a buoni amperaggi, io rimarrei sugli ESC modellistici che già usiamo. Se nel caso più in la alla bisogna potremmo crearne qualcuno apposta scegliendo dei buoni mosfet ad alta potenza e magari facendone funzionare diversi in "parallelo". [SM=g27811]
Questa è la versione 'lo-fi' del Forum Per visualizzare la versione completa clicca qui
Tutti gli orari sono GMT+01:00. Adesso sono le 10:25.
Copyright © 2000-2024 FFZ srl - www.freeforumzone.com