Un projet fou... mais tellement fun!

Hello tout le monde!

Autant vous le dire tout de suite, je vais vous présenter une envie qui me trotte dans la tête depuis un moment déjà, mais la réalisation promet d'être titanesque! (surtout pour moi, qui suis loin d'être expert! ^^)

En quelques mots, j'ai envie de faire des salles indoor de drones et autres véhicules RC, totalement automatisées (free-to-play oblige!), dans lesquelles nous pourrions jouer en ligne.

Autant dire que cela va soulever quelques défis techniques, aussi je viens vous proposer d'étudier la chose ensemble, l'union fait la force!

Les impératifs:

-une géolocalisation au poil de *** près (environ 1cm)
-une latence réduite à sa plus simple expression (très clairement, en dessous de 50ms, y compris connexion joueur/serveur)
-(toujours garder à l'esprit que plus il y a de véhicules ensembles sur le circuit, plus c'est fun! Gare aux interférences!)

Je précise que sur la latence nous avons une possibilité pour se simplifier la tâche si besoin, le "GPS" servira essentiellement au contrôle automatisé en local des véhicules, si l'on manque de temps on peut se passer d'envoyer les données calculées par nos soins dans les tuyaux du web.

Avant d'aller plus loin, laissez moi vous introduire une idée toute bête concernant le système "GPS" qui, je l'espère, vous séduira autant que moi...
Étant donné que nous parlons de salles indoor, je penses pouvoir me passer des phases de calculs harassantes, pour déterminer la position.
En lieu et place des systèmes que vous connaissez déjà, j'ai envie de faire un truc extrêmement redondant, avec une véritable multitude de récepteurs radiofréquences planqués dans le circuit, sans même prendre de précautions pour les positionner précisément.

Ensuite, pour que le système s'auto-configure, je coiffe mon circuit d'un châssis robotique 3 axes (comme une imprimante 3D), au bout duquel je viens fixer un des modules d'émission (celui qui sera sur les véhicules, un petit gueulard qui balance son nom et peut-être l'heure toutes les x ms).
Puis, je lance un programme dont la tâche sera de balader l'émetteur dans toutes les zones accessibles aux véhicules, afin de relever les données de réception qui correspondent à tel ou tel endroit de la "map".

Magique, non? :grinning:
Une idée que j'ai eu hier soir, 24h de réflexion n'ont pas suffit pour m'en dégouter, c'est plutôt bon signe!

Allez, passons à la partie plus technique, je vais commencer par une petite liste de ce que l'on trouveras niveau hardware côté véhicule et côté circuit, pour que vous cerniez un peu mieux de quoi je parles. (je restes volontairement vague)

Côté véhicule:
-Une UC, arduino ou autre contrôleur de vol, probablement plusieurs versions en fonction des exigences des différents types de véhicules.
-Des capteurs
-Un émetteur pour le "GPS"
-Un émetteur pour les capteurs (peut-être couplé avec l'émetteur "GPS")
-Un émetteur pour la vidéo (5.8Ghz)
-Un récepteur pour les commandes du drone

Côté circuit:
-Une multitudes de récepteurs pour le "GPS"
-Une réception des infos des capteurs
-Une réception des différents flux vidéos
-Un émetteur des commandes des véhicules (pour éviter de filtrer les redondances, il faudrait prévoir là un seul émetteur par véhicule, qui couvre toute la zone)
-ce qu'il faudra pour traiter les données et les envoyer en ligne, ou encore contrôler les véhicules en full-auto sur place, mais c'est un autre chapitre.

C'est encore très vague, mais vu qu'il faut bien commencer quelque part, je vais me concentrer tout d'abord sur la partie "GPS".
Pour faire ce petit miracle, 2 options intéressantes s'offrent à nous:
-travail sur la puissance de réception du signal
-travail sur la différence entre l'heure d'envoi et l'heure de réception du signal (probablement plus précis que la première, mais cela demande plus de calculs et plus de programmation, notamment une coordination régulière des horloges véhicules/circuit, bref c'est carrément plus compliqué, je la garde sous le coude en plan B!)

Donc, si je veux travailler sur la puissance du signal, il est bon d'envisager une technologie qui perd très rapidement de l'intensité avec la distance.
Elle me semble toute trouvée --> bluetooth

Une fois arrivé là me viennent nombre de questions que le novice que je suis a encore un peu de mal à résoudre, je suis sûr que vous allez pouvoir me faire gagner du temps!
Tout d'abord, par manque d'habitude j'ai beaucoup de mal à identifier la bonne architecture pour remonter les infos des récepteurs "GPS", ainsi que pour estimer les délais d'une telle architecture, si vous pouviez m'aider à y voir plus clair!

Question concrète: si j'ai entre 100 et 200 modules de réception bluetooth que je veux relier à une UC (une vraie, une grosse!) le plus rapidement possible; quelle architecture prévoir pour une latence la plus faible possible? (si ça prend plus de 5 voire maxi 10ms, j'abandonne!)

Autre question, si quelqu'un a l'habitude d'utiliser l'un ou l'autre des modules bluetooth pour arduino, savez vous s'il est aisé de récupérer des données fiables sur la puissance de réception du signal? Est-ce intégré/déjà réalisé? Ou bien une galère de plus à développer soi-même, ce qui m'orienterais vers le plan B?

Voici un bonne base pour les (nombreuses!) réflexions à venir, bravo si vous avez tenu jusque-là, en espérant que tout ceci puisse allez plus loin, imaginez seulement...
-des courses de bolides volants et roulants
-des décors "plus vrais que nature"
-des simulateurs de tout un tas de véhicules hors du commun, tels que des pelleteuses et des bulldozers, qui deviennent attrayants avec du vrai sable à pousser, un vrai terrain à modifier...
-des "sandboxs réelles" totalement gérées par la communauté, où l'on pourrait imaginer des joueurs qui construisent des circuits avec les bulldozers, tandis que d'autres viennent courir dessus en quad ou en buggy, par exemple.
-des couches virtuelles en plus de l'image filmée
-des jeux de tirs ne sont pas à exclure à terme, par exemple avec des drones, si leur positionnement deviens très très précis, nous pouvons imaginer tirer avec des projectiles virtuels, que l'on voit par dessus le retour caméra, avec le drone adverse qui part en vrille s'il est touché.
-(...)

C'est tout un monde de jeu qui s'ouvre à nous! :smiley:
Joyeuses fêtes! ^^

bonsoir
c'est bien d’être enthousiaste , mais là tu poste dans la section des réalisations et projets ... finis :grin:
Il faut poster là pour un nouveau sujet basique
http://forum.arduino.cc/index.php?action=post;board=33.0

edit :
merci à AWOL pour le "transfert"

jumab:
Autant vous le dire tout de suite, je vais vous présenter une envie qui me trotte dans la tête depuis un moment déjà, mais la réalisation promet d'être titanesque! (surtout pour moi, qui suis loin d'être expert! ^^)
Les impératifs:

-une géolocalisation au poil de *** près (environ 1cm)
...

Le (TON) premier probleme va etre de choisir le "bon vecteur" pour obtenir cette géolocalisation ! 8)

Woops, j'avais mal cerné la structure du forum, autant pour moi!

Artouste, quand tu me parles de choisir le "bon vecteur", il me semble que tu parles de la technologie bluetooth, dont j'ai parlé et sur laquelle j'ai posé des questions, il serait tout de même plus courtois de lire l'intégralité du message avant de venir me répondre sèchement que c'est MON problème...

Après, tu me tends une perche, le développement à plusieurs d'un projet open-source qui n'intéressera à l'évidence pas que moi me semble un bien meilleur "vecteur" que d’œuvrer seul dans mon coin...

jumab:
Woops, j'avais mal cerné la structure du forum, autant pour moi!

Artouste, quand tu me parles de choisir le "bon vecteur", il me semble que tu parles de la technologie bluetooth, dont j'ai parlé et sur laquelle j'ai posé des questions, il serait tout de même plus courtois de lire l'intégralité du message avant de venir me répondre sèchement que c'est MON problème...

Après, tu me tends une perche, le développement à plusieurs d'un projet open-source qui n'intéressera à l'évidence pas que moi me semble un bien meilleur "vecteur" que d’œuvrer seul dans mon coin...

:grin:
je n'ai jamais evoqué un vecteur de transfert d'info là (tu parle du BT alors que je me suis arrété à la "simple info de positionnement) , mais un vecteur de certification du positionnement !

et contrairement à ce que tu pourrais croire/deduire de ma reponse , j'ai parfaitement lu l'integralité de ton topic , et ...
si cela ne me m'interessait pas , je n'aurais meme pas pas pris la peine de te répondre et de demander un transfert. :grin:
Je suis qq'un de pragmatique = si pas déjà d'info fiable/precise de positionnement , ce n'est pas la peine de transmettre de l'info "pourrie/inexploitable/..." .

Comment envisage tu déjà de récupérer du positionnement relatif/absolu "indoor" avec une "précision" au cm ?
lorsque tu aura déjà repondu à ça , alors la transmission de l'info acquise sera "un jeu d'enfant"

Bon... alors toi tu rêves peut être un peu haut...

Comme dans tout projet, il y a au moins un c*nnard qui décourage un peu

Je me sens un peu comme ce c*nnard x)

Hum... commençons :

Ton projet est ambitieux, c' est bien mais le facteur humain y est trop présent, un exemple : imaginons un enfant de 11 ans (bien le stéréotype ?) Mauvais perdant, il perd une course et commence à dire que les véhicules ne sont pas égaux, il décide d' emm***er tout le monde (dont toi) et de créer des accidents ou de bloquer tout le monde sur la piste et après de détruire les beaux obstacles de tout le monde, pire ! Il pourrais endommager ou bloquer des voitures ! A partir de ça imagine les contraintes mécanique pour que la voiture soit incassable en gardant de la vitesse... Même sans penser aux problèmes techniques inhérents à ces systèmes, en plus il faut faire attention à une déconnexion brutale (dû à un problème chez le client ou autre...) qui peut bloquer la course ou créer un accident...

Tien, si une voiture se retourne, komankonfé ?

D' ailleurs, si tu veux intégrer des drones on reviens encore au problème de base, le facteur humain qui va te bousiller très certainement des drones...

Contrairement à un jeu de course "normal" ou on peux reset la partie à tout moment, là c' est du matos qui demande du travail, de l' argent et du temps.

Je suis sincèrement désolé de souligner tout ça mais c' est nécessaire.

Effectivement moi aussi je rêverais y jouer à ton truc, c' est génial mais rien que le temps de latence entre le retour vidéo, et l' envoi de commande ont de quoi tuer le gameplay... faut additionner le ping, le temps de réponse du moteur etc.

N' empêche que si tu persistes à vouloir le faire je serais le premier à vouloir t' aider ^^ mais pas à mettre dans toute les mains.

@ Artouste, désolé l'ami, j'ai décollé un peu vite, on s'était mal compris.

J'imagine que ce qui te chiffonnes, c'est comment je compte faire mes calculs pour déterminer la position.

C'est effectivement une partie du défi, un programme qu'il va falloir penser très finement pour tenir les délais, c'est une partie sur laquelle je ne me suis pas encore penché de trop près, ça ne me fait pas vraiment peur, on y arrivera vu la puissance des PC modernes!

Pour faire simple, visualise un immense tableau avec en abscisse entre 100 et 200 colonnes, pour chaque récepteur Bluetooth, et en ordonnée autant de milliers de lignes que de "cm3" de résolution, dans chaque case tu rentre la valeur de la puissance de réception. (ou un delta temps, plan B)

En fonctionnement, tu reçois une ligne d'un coup, et il faut retrouver à laquelle elle correspond dans le tableau.
Le tout en un temps record, c'est clairement un sacré défi mais encore une fois, je ne doutes pas qu'on puisse faire des miracles avec nos gros PC, à condition de lui ramener la ligne avec 200 informations en moins de 5ms! (et encore, j'suis trop sympa là, je ne comptes que pour 1 véhicule ^^)

@ TrolololGames, tu fais bien de soulever le facteur humain, j'y avais déjà pensé:
-risque de destruction des décors --> prévoir des décors assez solides
-risque d'endommager les véhicules --> difficile à éviter totalement, mais on peut prévoir de limiter les risques, carrosseries plus costauds que les bricoles commerciales programmées pour casser, et surtout ça ne coûte vraiment pas grand chose de remplacer des éléments. (j'ai déjà un business plan en tête, il n'y aurait pas vraiment de soucis de fric sur un tel évènement)
-risque de retournement --> prévoir des carrosseries anti-retournement
-risque de "joueur véreux" --> comme sur tous les serveurs de jeu, un système de "votekick" par les utilisateurs, et un droit de bannissement pour l'admin (pourquoi pas, même, demander une preuve officielle de l'identité des joueurs, pour limiter les doubles-comptes et responsabiliser les gens, tout simplement! Perso, ça ne me gênerais pas du tout de filer une copie de ma carte d'identité pour jouer à un tel truc gratuitement, je l'ai bien fait pour du poker! Qu'en pensez-vous?)
-Autres: un système d'alarme automatisé qui prévient l'admin quand un bug se produit sur le circuit, par exemple un véhicule qui ne serais pas rentré aux docks après ses 5-10min d'autonomie. Pour ce genre d'interventions, il faut à tout prix prévoir un système robotisé capable de lever les véhicules, pour que l'admin puisse dégager la piste à distance (une dépanneuse RC!)

Quand à la latence du flux vidéo, j'ai encore un léger doute sur la capacité du réseau à assumer un flux HD, si certains connaissent, je suis preneur d'avis sur le sujet.
A l'instinct, il me semble que ça fonctionnera au moins chez ceux qui sont proches du nœud principal, ce serait déjà une belle avancée!

Ps: il n'y a qu'en visant le ciel qu'on a une chance de l'atteindre! :wink:

Pour la destruction de décor je ne parlais pas trop de l' enceinte d' un circuit, je pensais plutôt aux bulldozers pour construire des saut ou autre...

D' ailleurs il faudrait dans ce cas essayer de faire une sorte d' arène avec un temps de construction (par les joueurs) et après une voiture automatisée (selon un parcour précis) viens passer l' obstacle, en mettant un réseau de caméra on peux regarder après coup l' action ^^ Bref ...

Par contre je ne saisi pas trop l' envergure du truc, free-to-play, dans des salles préparée et impraticable en fonctionnement (sauf ninja ?), avec des bagnoles faites sur mesure (pour résoudre autant de contraintes ça va être un peu chaud ^^ mais j' aimerais bien m' y pencher), des caméras sur chaque véhicule retransmettant en direct avec une latence minime, des capteurs capables de localiser une voiture sur le terrain (Je ne saisi pas trop l' utilité...

-> il ne suffirait pas de mettre toute les voitures d' un même terrain sur le même canal et de faire passer les instructions du client au serveur qui envoi ensuite une variables que seul une voiture peut retenir et comprendre ? Ex : le client tape sur son clavier "D", le logiciel comprend : "voiture n° 04 sur le circuit 3, va à droite" envoi au serveur : "v304d", le serveur passe ça aux bagnoles et la il suffit de mettre une condition sur chaque voiture : si la première lettre est V alors vérifier la suivante (ça confirme que c' est la requête d' un joueur destiné à une voiture), la deuxième lettre décrira à quel circuit la requête est destinée à partir de la on lit les deux suivantes, si elles sont égales à 04 alors lire la dernière lettre si c' est Q : aller à gauche, si c' est D aller à droite (tourner le servomoteur de la direction de X° à droite en gros). Bon, là je décris le fonctionnement parfait, il faudra envoyer ça (a partir de la troisième lettre) à toute les voitures et elles même se reconnaîtront)

Quel sera l' angle de la caméra ? Dans la voiture ? Chaud niveau visibilité... angle de vision pourri : problèmes de conduites et accidents en plus si il y a un probleme juste au niveau de la caméra mais pas du reste ça va être drôle 5000ms pour le conducteur x)

Et la connexion internet qu' il te faudra... un streaming de 40 contenu vidéos en simultané x'D
A moins d' avoir une connexion fibre 2go/s en débit montant ça va être ENCORE plus drôle x)

Si tu as un budget (relativement...) illimité je suis avec toi :stuck_out_tongue: j' aime bien ce genre de défit taré

jumab:
@ Artouste, désolé l'ami, j'ai décollé un peu vite, on s'était mal compris.

J'imagine que ce qui te chiffonnes, c'est comment je compte faire mes calculs pour déterminer la position.

C'est effectivement une partie du défi, un programme qu'il va falloir penser très finement pour tenir les délais, c'est une partie sur laquelle je ne me suis pas encore penché de trop près, ça ne me fait pas vraiment peur, on y arrivera vu la puissance des PC modernes!

bonjour
Le probleme de la precision de localisation ne butera pas sur un manque de puissance de calcul , mais sur la precision intrinseque des horloges de datation.
pose déjà bien ce probleme sur le papier et pose toi la question des choix technologiques aujourd'hui possible (couts/dispo/encomrement/... ) pour obtenir un positionnement de mobile déjà en 2D avec une precision centimetrique.

J' ai pas compris grand chose aux histoires de datation intrinsèques etc. Mais ça paraît très intelligent

Hum...

Ou sinon on met un accéléromètre et un ordinateur à côté qui calcul tout sur un univers en 3D ou 2D pour une map (je pense que tout les jeux de courses ont une minimap, on pourrais en créer une)... plus simple que de s' embêter à mettre plein de capteurs de partout et ça évite des pannes... (capteurs fragiles ou autre, un bon accéléromètre tient le coup) et ça évite aussi de brancher 236 capteurs pour un circuit :')

Comme tu dis les ordinateurs d' aujourd'hui sont très puissant, si tu lui fait bouffer du simple calcul (de vecteurs si je ne me trompe pas ?) ça va pas le déranger plus que ça je pense... surtout si tu veux un repérage centimètrique ce qui laisse une belle marge pour un ordinateur et pour le capteur

juste une question peut etre personnel mais tu es d'ou?

Avant de partir du un projet fou, essaye de trouver un fablab pas loin de chez toi pour te conseiller, t'orienter.

en electronique, tout est possible est imaginable, si ont a des sous, parce que çà demande du temps et de l'argent.
Au dela du projet qui est faisable, Free to play, ok mais comment tu vas payer toute la partie structure. Il faut louer une salle, serveur internet ect...

Quand tu vois les microkopter allemand, c'est pas donnés.

Quelques soit drone ou voiture RC, faut penser aussi au batterie et recharge, je lis plus haut le gamin de 11 sera pas content car sa voiture ne vas pas assez vite, eh oui mais sa batterie est a 50% alors que d'autre sont a 90%.

De même que le temps de jouer est assez court, on va dire Grand maximum 15 minutes. donc faut penser a tout cela;

TrolololGames:
J' ai pas compris grand chose aux histoires de datation intrinsèques etc. Mais ça paraît très intelligent

Les lois de la physique ne sont pas intelligentes , elles sont ... simplement :sunglasses:

Hello all!

Tout d'abord, coupons court à tous les soucis d'argent, voici comment je vois les choses: quiconque pourra facilement lever en financement participatif une somme non négligeable pour réaliser son circuit.

Restes à trouver un local non loin de la fibre, et une motivation financière plus grande, pour pousser les gens à s'équiper (nous vivons malheureusement encore dans un monde où rien ne prend de l'ampleur s'il n'y a une raison commerciale derrière...)

Pour cela, rien de plus simple, on peut proposer aux propriétaires de circuits d'installer de la pub, par exemple sur des écrans formats smartphone, le tout relié à une appli chargée de gérer, négocier les contrats de pub automatiquement.

On peut même envisager de rémunérer en fonction de la fréquentation de tel ou tel circuit, pour pousser les gens à se renouveler, à faire des décors toujours plus grandioses!

Bref, vous aurez compris, c'est un sacré coup de pied dans la fourmilière que l'on mettrait en faisant ça, on peut aller plus loin que le jeu vidéo tout en restant free-to-play!

TrolololGames, la géolocalisation, on ne peut pas y couper, les applications sont trop nombreuses...

  • toutes les 5/10 minutes le véhicule doit rentrer au garage pour recharger, une responsabilité qu'on ne peut pas laisser aux mains des utilisateurs, IMPÉRATIF.
    -Ça peut précisément servir à créer des zones d’exclusions sur le terrain, pour éviter que les bulldozers qui jouent dans le bac à sable ne viennent détruire le lac en fond de décor, par exemple.
    -Imagine, comme dans un jeu vidéo, la sortie des stands pilotée par l'ordinateur, avec un alignement parfait sur la grille de départ... La super classe!

Concernant l'angle caméra, il y aura une HD en place pilote, mais on peut aussi envisager d'en rajouter une seconde, plus petite, plus légère, et donc moins bonne résolution au bout d'un mat, en arrière du véhicule. Une solution qui présente néanmoins de nombreux inconvénients (vibrations, véhicule moche, résolution moche,...), ce n'est clairement pas quelque chose que je comptes implémenter dès le départ.
Ceci dit, tape "drone fpv racing" sur youtube, ça va te réconcilier avec ce mode de vue! ^^

Artouste, le fonctionnement basé sur les horloges reste mon plan B pour l'instant, mais il me semble que ça reste envisageable, étant donné qu'on recharge toutes les 10 minutes on peut en profiter pour resynchroniser les horloges.
Avec l'horloge interne de l'arduino, qui présente une erreur de 4s toutes les 24h, cela ramène à une précision de 27ms au bout de 10minutes.
On est d'accord, ça me semble limite pour géolocaliser, mais je n'ai fait aucun calcul, mon jugement sur le sujet est encore très peu scientifique...

Peu importe, pour l'instant je reste fixé sur le travail en puissance de réception, un côté analogique, très fluide qui me séduit beaucoup!
Je vais fouiller le net pour avoir des infos sur le sujet, et passer commande d'une ribambelles de modules sans fil différents, histoire de tester directement par moi-même.

Pour les solutions existantes de positionnement centimétriques, je n'en vois qu'une seule, le laser.
J'ai tourné le truc dans tous les sens, bien trop compliqué à implémenter, les véhicules volants et l'immense variété de circuits sont des obstacles majeurs, et les capteurs sont encore chers.
Il y en a d'autres qui font du positionnement centimétrique, directement au GPS (le vrai!), ce sont les boites Trimble et/ou Leïca, le duo de lobbyiste assez puissant pour aller demander les accords pour exploiter non pas 1, ni 2, mais bien 3 systèmes de géolocalisation, ce qui porte le nombre de satellites à 72.
Coût d'un tel bidule?
20 000€, vendu par camions entiers à tous les professionnels du bâtiment...
Sisi, un système très sain, très logique, j'vous assure! ::slight_smile:

Bref, à moins que j'ai mal fait mon travail de grand curieux (ce qui m'étonnerait!), un petit système de positionnement facile à déployer, peu cher et précis serait une nouveauté, un truc qui n'existe pas, une barrière technologique même, d'où l'intérêt de le développer!

Le coup de l'accéléromètre, j'y ai bien pensé, mais ça me semble trop limite pour garder la position de manière fiable, non?
Les variations de vitesse vont être nombreuse et brutales, j'ai de gros doutes sur la capacité d'un tel système à garder une précision centimétrique au bout de 10 minutes de run endiablé...

Bon, la question importante reste de savoir s'il est envisageable de monter la structure arborescente pour ramener les infos de tous les capteurs en une latence record, et à quel coût.
Si quelqu'un arrive à me répondre à propos de mes 100 capteurs, j'en serait fort aise et y verrais beaucoup plus clair!

Ps: hazerty565, tu as posté pendant que je répondais, je pense avoir éclairé pas mal de tes questions, du coup!
Mis à part que j’habite en Haute-Savoie, pour le fablab pourquoi pas, je dois bien pouvoir trouver ça à 50-60 bornes, mais... mon clavier est quand même beaucoup plus proche! :smiley:

Ps 2: sans vouloir vexer personne, les lois de la physiques sont, mais sont surtout très très mal comprises... :wink:

jumab:
Artouste, le fonctionnement basé sur les horloges reste mon plan B pour l'instant, mais il me semble que ça reste envisageable, étant donné qu'on recharge toutes les 10 minutes on peut en profiter pour resynchroniser les horloges.
Avec l'horloge interne de l'arduino, qui présente une erreur de 4s toutes les 24h, cela ramène à une précision de 27ms au bout de 10minutes.

Oui ... peut etre , et je ne verifie meme pas tes "valeurs"
comment espere tu avec ses(tes) valeurs obtenir une precision centimétrique dérivée , un rapide calcul de tête meme à un ou deux zero pres expose une precision de positionnement de l'ordre des milliers de km ? :sunglasses:

expose mieux comment tu va/pense atteindre une precision centimétrique (relative/absolue) ?

Je me repete :
Je comprend ton enthousiasme, mais je demeure et persiste pragmatique

ton projet ne vaut que par l'acquisition (A T0,T1,...Tx) au cm prés à TRef

Je reste à l'ecoute de ta solution sur ce point "excessivement' primordial 8)

Wow wow wow... ça part assez loin là... :o

Tu veux carrément qu' on puisse faire un "circuit en kit" à monter soi-même et à jouer avec des amis ?? Limite en locale pour que les latences ne soit pas trop élevé ?

Je suis contre le principe du financement par la pub, je pense qu' on bouffe assez de ces c**nerie tout les jours et je préfère amplement payer un abonnement pour ça. Les pubs ont le pouvoir de dénaturer un projet qui passe de "personnel" à "commercial" et dieu sais comme ce terme est mal reçu... Même si quelque part indispensable

Quickstarter ! Tu pourrais lever des fonds et ça ferais un peu parler ce genre de projet en gardant un rapport plus humain que une pub

Après renseigne toi sur les forums de robotique, les accéléromètres sont à mon avis assez précis... sous réserve de tous les reset à chaque départ, ça permettrait une marge d' erreur dû au capteur minime

Aussi je me demandais, comment tu comptes recharger les batterie entre chaque run ? Ça ne serais pas possible par inductance ? Pas besoin de contacte, limite si c' est possible on pourrais mettre des bobines sous le circuit pour recharger les voitures en permanence, certe pas énormément mais ça suffirait à éviter 20 min de rechargement entre deux courses de 10 min...
Je ne suis pas très renseigné sur ce type de technologie mais on pourrais y penser. (Et voir si ça ne créer pas d' interférences)

Mais les voitures seraient énorme... faudrait des circuits gigantesques pour bien s' éclater

Je m'incline Artouste, le plan B me semble aussi tomber à l'eau direct.
Quoique...
Et une synchro des horloges quasi-permanente, qui passerait en sans fil?
Probablement une bonne solution, non?
Voire carrément un système émission/réception, les balises demandent les coordonnées, tous les véhicules gueulent leur noms, on pourrait à ce moment utiliser uniquement l'horloge du pc pour les mesures. (+1 pour cette solution, elle me plait vraiment beaucoup!)

Toujours est-il que la solution A reste plus simple!

Tu veux carrément qu' on puisse faire un "circuit en kit" à monter soi-même et à jouer avec des amis ?? Limite en locale pour que les latences ne soit pas trop élevé ?

C'est bien ça, mis à part que les décors/véhicules sont au bon vouloir du fabricant, et qu'il ne tient qu'à lui de mettre ou non son truc en ligne, s'il a la fibre pas trop loin! (ce qui permet d'envisager de sacrée parties de jeux même sans le net, un réseau local et quelques potes, et en avant!)

Ensuite, j'ai au contraire l'intention de faire des véhicules le plus petit possible, j'avais déjà éliminé l'inductance pour ça.
Je pense tout bêtement à des contacts nus, positionné à un endroit bien pensé sur le modèle RC.

Concernant la pub, j'avais pris soin de souligner le mot "proposer" pour ne pas trop égratigner les sensibilités, nous pouvons avoir tous les choix possibles, mais si je fais un circuit free-to-play avec pub, toi un circuit payant, tu n'auras même pas de clients, oublie... (ou alors, on oublie arduino et le monde de l'open source pour faire une multinationale privée, on bride le marché pendant 5/10ans,... Chose que je ne ferais pas, par conviction!)

Clairement il faut un revenu d'exploitation, et clairement la pub me botte plus que l'abonnement, après libre à chacun de faire comme il le souhaite, c'est aussi cela le monde totalement libre amené par l'open source.

Les accéléromètres je reste très peu convaincu, j'ai déjà lu des gens qui disaient qu'ils n'avaient pas réussi, précisément sur des sites de robotique, si quelqu'un a des infos dans l'autre sens je suis preneur, mais je ne comptes pas passer plus de temps à chercher de ce côté.

Pour l'instant, Bluetooth (puissance du signal), et architecture pour remonter l'information.

Bonjour,

J'ai lu plusieurs fois le sujet complet... :o
Mon age avancé me fait rester dubitatif sur la possibilité que ce projet voie jamais le jour tant les problèmes sont nombreux et les solutions apportées plutôt légères. (Il n'y a rien de méchant ou d'agressif dans cette phrase :slight_smile: )
Mais c'est mon age avancé... :wink:

Comme disait je ne sais plus qui ( W. Churchill ?) : "Ils ne savaient pas que c'était impossible, alors ils l'ont fait !"
Donc allez-y, foncez ! Vous apprendrez toujours un tas de choses qui pourront servir ailleurs ou plus tard...

Par contre une question me turlupine : Pour quelle raison est-il nécessaire de connaître la position des véhicules au cm3 près ?

S'il existe des zones interdites, elles seront plus grande que quelques cm3 je suppose...

Il n'y a que quelques moments ou actions durant lesquelles la position devra être précise.(Rechargement, ... )

Pourquoi cette précision, compliquée à atteindre, est-elle requise ?

Coyotte

coyotte:
Par contre une question me turlupine : Pour quelle raison est-il nécessaire de connaître la position des véhicules au cm3 près ?

Parce que sans défi, on s'ennuie!
Héhé, plus sérieusement nous pouvons effectivement être un chouilla moins exigeants sur la précision, à condition toutefois de prévoir une solution très précise pour aller se recharger, par exemple suivre une ligne avec la caméra.

Mais ça m'embête de passer du temps à développer de l'à peu près, autant essayer de faire vraiment bien!

Pour le Bluetooth, le protocole que je cherchais existe, bien évidemment, c'est le RSSI, qui nous donne la puissance de réception.

D'autres que moi ont eu l'idée de faire de la localisation avec le RSSI du Bluetooth, leurs conclusions sont catastrophiques, mais aucun ne l'a fait comme j'ai envie de faire (un système dédié à un terrain donné, avec toutes les interférences de décors, et paramétré seulement ensuite)

Bref, plutôt une bonne nouvelle malgré tout, pour la précision il va falloir que je fabrique pour savoir, pas le choix, c'est nouveau!
Reste maintenant la grosse interrogation de la structure pour relier tout ça...

deja dans un premier temps realiser quelque chose de simple, un robot/ voiture/ drone ce que tu veux, dans ton garages, avec les technologies adequat, avec la possibilité de faire rouler ta voiture par internet, ou ton ordinateur en local, avec un module bluetooth/ wifi, avec le bluetooth RSSI traker tu a moyen de calculer la force du signal.

TU veux faire de l'open source, tout fait maison à ta sauce, mais à mon avis, il faudrait faire une carte personnalisé. Mais je partirai plutot sur une carte type yun, ou autre avec du linux embarqué comme les AR drone

Edit: tu as répondu pendant que je répondais aussi :slight_smile:

Non non, pas de yun, beaucoup trop gros, trop lourd et inutile!

A quoi bon une carte personnalisée?
On en a assez sur le marché qui feront le taff!

Bien évidemment, le début va se faire seul dans mon garage, mais le truc dur à développer ce ne sera pas les véhicules RC (il n'y a même rien à développer, juste à sélectionner une solution et à copier), mais bien leur système de positionnement!

Edit: les gros processeurs type yun, c'est utile si on veut calculer les données GPS à bord du véhicule, ce n'est pas pour rien que j'ai prévu de faire faire ça à la grosse bécane! :wink: