Projet Arduino

Quand l'utile rencontre le loisir :)

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Hello tout le monde,

Avant toute chose, je me présente rapidement histoire que ce soit plus simple pour communiquer et nous comprendre sur certains termes. J'ai la vingtaine et suis en dernière année d'ingénieur informatique. Avant ça, j'ai fait un DUT informatique.

J'ai un profil plutôt développement mais je tends à m'orienter vers du management d'équipes. Dans mon entreprise actuelle, je fais de la R&D mobile.

Niveau loisir, je fais de la moto. Et c'est ça qui a fait naître une petite idée dans mon cerveau hier. :)

Faute de solutions satisfaisantes sur le marché, j'aimerais construire/développer un système d'avertissement visuel en fonction de position GPS. Je vous donne un exemple d'utilisation d'un tel système :

  • un circuit (de pilote j'entends) possède une ligne de départ / arrivée (= coords GPS)

  • il possède aussi différents points stratégiques (virages, stand…) qui ont aussi leurs coords GPS

L'idée est de tenir une base de données de certaines coordonnées GPS, et que le système analyse en temps réel la position GPS, et si l'on se trouve dans un rayon donné (500m par exemple), une ou plusieurs LED puissantes s'allument.

Je connaissais Arduino et systèmes similaires (Raspberry pi) via ma veille technologique, mais je n'ai jamais mis le nez dedans. J'avoue que mes connaissances préhistoriques en électronique (ça doit remonter au collège !) y sont pour quelque chose.

D'après les rapides recherches que j'ai fait, pour un tel système j'aurais besoin d'une base Arduino puis d'un shield GPS ainsi que d'une LED (je vulgarise).

Mes questions/interrogations sont les suivantes :

(1) pour un tel système, est-ce que Arduino est la solution la plus adaptée ?

(2) le fonctionnement par shield est simple, mais le revers de la médaille me semble l'encombrement. J'ai l'impression que l’empilement des shields crée des systèmes bien plus gros qu'ils ne devraient

(3) niveau programmation, ça me semblait proche du C si ce n'en n'est pas directement, quel est le degré de complexité d'un système comme je le présente ci-dessus (surtout la partie SGBD qui pourrait être compliquée si pas de solutions existantes)

(4) de ce que j'ai vu, la différence principale entre Arduino et RPi est la puissance disponible. Il me faudrait un système fiable (pas de lag pour le GPS ni pour les calculs). Arduino ferait-il son job ?

(5) niveau budget j'ai pas de problème, je gagne ma vie. Cependant si je pouvais déjà acheter la carte Arduino qui correspondrait à mon usage final, ça m'arrangerait, plutôt que d'acheter une Uno qui me servirait à rien par la suite

Pour l'instant c'est tout ce qui me vient à l'esprit, merci à ceux qui pourront éclairer un peu ma lanterne. :)

Merci d'avance à tous, Jiyuu

Édité par Jiyuu

+0 -0
  1. Pour travailler sur une base de données, les 16 MHz de l'Arduino Uno me semblent un peu limites. Je pencherais plutôt sur des cartes à base d'ARM Cortex, comme la mbed LPC 1768

  2. Si tu reste sur Arduino il existe des versions beaucoup moins encombrantes comme l'Arduino Mini, Micro ou Nano. Pour le LPC 1768, il a déjà un form-factor réduit.

  3. Le langage Arduino est un mix de java/c++ (c'est selon l'humeur), sachant que derrière on a un microcontrôleur 8 bits relativement simple, en général les programmes ne sont pas ultra complexes, surtout que c'est fait pour des novices (ou non). Il y a pas mal de librairies existantes qui peuvent aider à utiliser des périphériques si on ne veut pas se taper la programmation du protocole. Pour le LPC1768, il fait partie du projet mbed qui propose une interface de développement en C++ avec des librairies communes pour toutes les cartes du projet. Ce n'est pas aussi simple qu'Arduino mais d'un autre côté le public visé n'est pas le même (faux-débutants avec des connaissances minimum en informatique) et surtout les plateforme sont beaucoup plus puissantes.

  4. Arduino -> pas d'OS. RPI -> Linux. A toi de voir.

  5. cf 2.

Édité par zeqL

+0 -0
Staff

Pour travailler sur une base de données, les 16 MHz de l'Arduino Uno me semblent un peu limites. Je pencherais plutôt sur des cartes à base d'ARM Cortex, comme la mbed LPC 1768

En même temps pour stocker 50 coordonnées GPS et allumer 3 LED, pas besoin d'un SGBD. J'entends par là qu'il faudrait un cahier des charges un peu plus précis. Si l'usage "les points à stocker sont chargés avant la course", pas besoin de plus qu'un arduino.

Un arduino peut avoir un form factor beaucoup plus réduit qu'un RPi et consommera beaucoup moins ce qui dans le cadre de ce projet peut etre important car le module devra probablement fonctionner sur batterie.

+0 -0

Tout pareil que Kje: pour un millier de coordonnées, la BDD n'est pas utile. Par contre, la place en mémoire peut devenir gênante. Il n'est pas très compliqué de calculer la distance de la position actuelle aux points sauvegardés avec un rafraichissement à quelques hertz.

Pour le GPS, tu dois pouvoir gagner la place du shield : un GPS s'interface généralement par une liaison série, tu mets le GPS là où il capte bien tu tire un fil (enfin 4 : Vcc, GND, Rx Tx) jusqu'à l'arduino, et pas besoin de shield.

As-tu une idée du nombre de points à gérer ?

+0 -0

dites les amis, avant de parler techno, utilité de BDD, linux embarqué ou pas, j'ai un peu comme une espece de question: le GPS shield arduino a vraisemblablement une précision à 5m près (j'ai pas été voir la doc). en course, c'est la moitié de largeur du circuit.

d'ailleurs, puisqu'on en est à parler de circuit, le GPS que j'utilise dans ma voiture semble faire moins d'1 actualisation de position par seconde. je ne sais pas comment il a été conçu, ni ce qui limite réellement ce taux de raffraichissement, mais je vais partir de là quand même pour le raisonnement. sachant qu'en course moto, 1s, ça peut représenter jusqu'à 100m en bout de ligne droite (300km/h, en motoGP, c'est pas impressionnant, les records qui sortent dans les premiers sur google sont plus proche de 350), ou même 30m à 100km/h, donc dans une situation de course crédible, on peut rajouter facilement 5m d'erreur sur un freinage "classique pour un virage qui est précédé d'une bonne prise d'élan" en fonction du taux de rafraichissement de ta puce GPS, et des 2-3 calculs que tu fais avec les données qui en viennent. (je connais pas réellement les conditions de course en moto, donc je donne des chiffres qui paraissent pertinents, mais qui ne le sont peut-être pas, si c'est le cas, ne me jetez pas de cailloux, je suis gentil).

du coup comme la loi de l'emmerdement maximal le prédit, en ingénierie, les erreur s'ajoutant TOUJOURS, on peut arriver à une bonne dizaine de mètres d'erreur, soit une erreur peut-être supérieure à la largeur de la piste. je sais pas si c'est vraiment pertinent de dire ça, mais je trouve ça presque dangereux de faire des repères de freinage soit beaucoup trop tôt (oui, sur circuit freiner beaucoup trop tôt peut aussi être dangereux, selon moi, au même titre que les voitures sans permis le sont sur route ouverte, mais là n'est pas le débat, de toute façon freiner trop tôt, ça peut aussi vouloir dire perdre du temps, donc en course, "il faut pas") soit à la bonne distance, mais du coup l'imprécision fait que si l'erreur du système est suffisante, bah c'est une sortie de piste…

Édité par remace

Oui. Non. Attends, je regarde mieux et je te dis.

+0 -0
Auteur du sujet

Hello tout le monde et merci pour vos réponses. Pour répondre aux points soulevés :

@zeqL : ça me rassure de voir des cartes moins encombrantes. Pour les langages de développement ou la complexité plus importante, c'est pas grave, j'ai le bagage suffisant pour comprendre, apprendre et développer sur les nouvelles plateformes.

Dans les recherches que j'ai mené, j'ai vu qu'il y avait des boards officielles (Arduino), des boards compatibles (reprennent les schémas Arduino mais manufacturées par des entreprises tierces) et les autres boards (non compatibles avec la plupart des shields, si j'ai bien compris). La mbed que tu évoques (ainsi que les autres Arduino miniaturisés), à quel niveau de compatibilité se situent-elles ?

Pour ce que tu évoques sur les différences (OS / Pas d'OS), c'est ce que je savais. Ma question était plus orientée sur les capacités des cartes, en terme de puissance (mis en regard avec mon projet).

@Kje, @Natalya : Je donnais l'exemple des courses sur circuit pour illustrer ma demande, mais vous avez raison, il faut être plus précis pour bien cerner le besoin, autant pour moi. J'y vois d'autres utilisations, qui pourraient grossir les données (rally routier avec des centaines de POI, zones de danger sur route ouverte, etc.). Grosso modo, j'aurais environ 5000 à 10 000 Points Of Interest (nature, longitude, latitude étant les 3 informations les plus importantes). Après le travail du système est de calculer en temps réel et trouver les POI dans un certain rayon (formule de haversine que j'ai déjà utilisé, pour ceux que ça intéresse). Sur un grand nombre de données, ça demande "un peu de temps".

Je parlais de SGBD histoire de vulgariser : derrière c'est du stockage de données puis sélection d'après des conditions parmi celles ci. Si vous avez des exemples de librairies Arduino pour la gestion de données avec opération, je suis preneur pour potasser tout ça. :)

@remace : ta remarque est très pertinente et comme tu le soulignes, la loi de murphy n'est jamais très loin. La question de la précision et rapidité du GPS rejoint mes questions sur la fiabilité évoquées dans mon premier post. La précision à 5 mètres serait une limite. Sur route (je le vois avec mon GPS de smartphone), c'est suffisamment précis pour m'indiquer des soucis sur la route (application style Coyote). Selon la nature du POI, la précision du GPS sera plus ou moins importante, je peux jouer un peu sur le rayon de recherche à la limite. Pour ce qui est de la fréquence de rafraîchissement, normalement ça se gère côté software, dans la limite des capacités du matériel, bien entendu.

Je te rassure, un système tel que celui que j'ai décrit, pour un usage piste, ne serait qu'un support. Je ne me fierai jamais à un système électronique pour me dire où freiner, on connait ces informations. Pour expliquer ce que j'entends par support, je vais faire un parallèle avec un autre élément que j'ai installé. Le tableau de bord des motos est toujours équipé d'un compte tour, à aiguille ou électronique. On sait tous le lire, on sait tous lire la zone rouge, et on sait tous à quel TRM (tour minute) le rupteur va intervenir. Cependant, pour un usage course, on a en général un shiftlight, une led très puissante, qui va clignoter dès l'arrivée de la zone rouge, puis de plus en plus vite pour nous indiquer de passer le rapport. C'est ce genre d'aide au pilotage que je cherche. Avoir une concentration optimale (un compte tour en moto ça grimpe très vite) sur le sujet, et un outil pour nous aider pour des éléments stratégiques.

J'espère que ces informations seront utiles pour la compréhension. :)

Edit : pour compléter ma réponse, en ce qui concerne l'alimentation j'ai deux options. Soit un fonctionnement par pile/batterie à recharger, soit, ce que je préférerais, un système qui se recharge avec la moto. J'entends par là que je me pique dans un fusible de la moto (veilleuse par exemple, car alimentation post-contact) et que ça alimente soit directement le système, soit recharge une batterie intermédiaire.

Édité par Jiyuu

+0 -0

Hello tout le monde et merci pour vos réponses. Pour répondre aux points soulevés : @remace : ta remarque est très pertinente et comme tu le soulignes, la loi de murphy n'est jamais très loin. La question de la précision et rapidité du GPS rejoint mes questions sur la fiabilité évoquées dans mon premier post. La précision à 5 mètres serait une limite. Sur route (je le vois avec mon GPS de smartphone), c'est suffisamment précis pour m'indiquer des soucis sur la route (application style Coyote). Selon la nature du POI, la précision du GPS sera plus ou moins importante, je peux jouer un peu sur le rayon de recherche à la limite. Pour ce qui est de la fréquence de rafraîchissement, normalement ça se gère côté software, dans la limite des capacités du matériel, bien entendu.

Jiyuu

bah tu tombe bien, les limites du matériel, c'est là que je voulais en venir… puis tu parles de ton application coyote, si je me trompe pas, elle t'avertit entre 100m et 1km avant le probleme, et la précision du point même de l'embrouille est pas vérifiée/vérifiable, puisqu'il y a une correction sur la position du POI une fois sur l'affichage.

Je te rassure, un système tel que celui que j'ai décrit, pour un usage piste, ne serait qu'un support. Je ne me fierai jamais à un système électronique pour me dire où freiner, on connait ces informations. Pour expliquer ce que j'entends par support, je vais faire un parallèle avec un autre élément que j'ai installé. Le tableau de bord des motos est toujours équipé d'un compte tour, à aiguille ou électronique. On sait tous le lire, on sait tous lire la zone rouge, et on sait tous à quel TRM (tour minute) le rupteur va intervenir. Cependant, pour un usage course, on a en général un shiftlight, une led très puissante, qui va clignoter dès l'arrivée de la zone rouge, puis de plus en plus vite pour nous indiquer de passer le rapport. C'est ce genre d'aide au pilotage que je cherche. Avoir une concentration optimale (un compte tour en moto ça grimpe très vite) sur le sujet, et un outil pour nous aider pour des éléments stratégiques.

Jiyuu

heu… oui je vois. sauf que la shiftlight est faite pour te faier lacher l'attention sur ton compte-tours, parce qu'il est normalement pas trop dans ton champ de vision quand tu roule (la vision s'étend en fait approximativement sur un cone à base elliptique, à format environ 16:9 ou 16:10, de grand axe horizontal. ce qui est bas dans ce cone est traité avec très peu d'attention de la part du cerveau, ce qui te fait détourner le regard pour regarder le compte-tours). hors, un repere de freinage, en général, il est placé proche du point de freinage, du bon coté de la piste, et dans ton champ de vision, et son approche est mieux appréciable que la fréquence de clignottement d'une led. du coup ça rend presque inutile une "brakelight" là ou un shiftlight est vraiment utile.

enfin j'veux dire… c'est le genre d'aide qui coute rien, si vraiment c'était utile, y'en aurait sur toutes les motos de course, au même titre que la shiftlight, le shifter, ou un contrôle de traction. exception faite des motos de rallye routier, puisqu'elles ont déjà un roadbook qui prend beaucoup de place, et qu'ils roulent quand même beaucoup moins vite que sur circuit. pis blague à part, en rallye routier, c'est Denis Bouan qui gagne toujours tout, et il a une R1 à peine modifiée :-P

dans tous les cas, rien ne t'empeche d'essayer de réaliser ton projet, mais rappelle toi que c'est à la fois dangereux sur piste si utilisé sans autre repere, et probablement redondant, voire inutile.

sans compter qu'en course, les reperes de freinage doivent changer suivant la météo, l'étant de la piste, et des pneus aussi, j'imagine, ce qui fait un systeme relativement peu adapté à une course, je suppose).

Édité par remace

Oui. Non. Attends, je regarde mieux et je te dis.

+0 -0
Auteur du sujet

Merci pour ton retour remace, je suis d'accord avec ce que tu dis. Après, avant tout, c'est pour le fun et le défi technique que fais ça. J'y vois une utilité pour m'avertir de certains éléments, d'autres sont plus gadgets.

Pour revenir brièvement au shiftlight, c'est non seulement fait car le compte tour n'est pas forcément lisible/bien placé, mais aussi pour que tu passes ton rapport au mieux. Ça peut paraître bête mais sur une moto qui tire court (moteur ou démultiplication, peu importe), ça aide bien. Mais c'est pas trop le sujet. ^^

Encore une fois, avant toute chose, et j'avais oublié de le préciser, mais mon projet c'est bien plus par curiosité intellectuelle que par pertinence/utilité. J'y crois quand même pour certains POI (après c'est ce que je ressens au pilotage et qui je pense pourrais m'intéresser), et qui ne teste pas ne peut pas savoir (mon boulot en R&D me le prouve au quotidien !).

Bref, revenons à nos moutons. Sur tous les points abordés, quelle board pourrait faire l'affaire d'après vous ? Des idées pour mon stockage de POI ? Avez-vous testé des shields ou systèmes GPS compatibles ? J'ai vu qu'Adafruit propose un shield "tracker GPS" avec slot SD qui se transforme en antenne GPS en l'absence de carte SD (c'est ce que j'ai cru comprendre). L'avantage de leur système c'est que l'antenne est déportable.

Autre idée que j'avais en tête, plus classique, une alarme homemade. J'ai vu un exemple sur Youtube avec accéléromètre et tout le tralala, ça peut être fun. :)

+0 -0
  • Le projet mBed n'a rien à voir avec le projet Arduino. Il n'y a donc pas de compatibilité mécanique entre les shields Arduino et les cartes du projet mbed (sauf cas particulier). De même pour le projet Arduino, les shields ne sont compatibles qu'avec le form-factor de la carte Arduino Uno (la Mega respecte aussi le form-factor), par exemple l'Arduino Mini ne pourra pas accueillir de shield de manière simple.

  • J'allais aussi soulever le problème de la capacité du GPS par rapport à la vitesse, remace l'a fait avant :) Les GPS "grand public" (abordable) ont une précision minimum de 2.5-3 mètres. Et au niveau rafraichissement on peut trouver facilement du 5Hz voire du 10Hz et même 20Hz.

Par exemple ce module de Sparkfun : https://www.sparkfun.com/products/11058 ou celui-ci d'Adafruit : http://www.adafruit.com/products/746 pourraient convenir à tes besoins

+0 -0
Auteur du sujet
  • En ce qui concerne mBed c'est ce que j'avais cru comprendre, merci pour ces précisions. Je n'avais pas trop compris que les shields étaient presque exclusivement faits pour le Uno. Dans des vidéos que j'ai vu, grosso modo, la Mega semble être une Uno avec des extensions (la partie avant [là où on retrouve le port USB] semble être identique à la Uno).

  • Niveau fréquence, je pense que ça sera suffisant. Les smartphones haut de gamme ont des puces entre 1Hz et 5 Hz (corrigez moi si je me trompe) il me semble ; et ça me convient presque. Les deux références que tu cites me semble ok.

  • Niveau board je nage encore totalement, ou presque. :o) Uno ? Mega ? Mini ? (la dernière a l'air de nécessiter des connaissances en électronique plus avancées …)

+0 -0

Personnellement je partirais sur la mbed pour sa puissance (Cortex M @ 96MHz) et sa taille réduite.

Car pour moi tu devra faire un peu de traitement par rapport à tes POI. Soit tu rentre toute une zone de coordonnées pour un POI, soit tu rentre une coordonnées et tu calcule si ta coordonnées actuelle est proche du POI.

(Pour Kje et Natalya aussi) Quand je parlais de base de données, pour moi des coordonnées dans un fichier texte (ou en mémoire) c'est une sorte de BDD :) Je rejoins Kje sur le fait que tu peux stocker les points en RAM. La question c'est quelle quantité de RAM tu as besoin et aussi si tu pensais faire des opérations complexes.

Potentiellement une Arduino Uno peut faire le job (peut-être en réfléchissant bien à l'implémentation et en optimisant), après si tu veux faire d'autres choses plus complexes dans le traitement, peut-être qu'un Cortex M3 comme sur la mbed LPC1768 sera plus adaptée.

Donc comme déjà dit par Natalya et Kje, il faudrait un cahier des charges un peu plus précis, notamment en terme de données à traiter ou en tout cas sur comment tu compte faire ton algo. Ou encore sur des évolution futures (faire de la télémétrie en plus par exemple)

+0 -0

Un peu hors sujet : Je viens de découvrir ca : https://www.sparkfun.com/products/13093 qqun a déjà entendu parler ?

Eskimon

Ca a été présenté au CES en janvier 2014 avec une autre carte de développement. La carte que tu donne en lien est déjà la seconde version qui date de septembre.

C'est adapté pour le marché des wearable.

Il y a un Intel Quark déjà utilisé sur la carte Galileo qui est compatible Arduino.

Je sais pas trop ce que ca donne en terme de puissance. Après ca à l'air d'être un truc modulaire. Tu as la carte de calcul et tu la plug sur une carte "mère" qui possède des I/Os.

Édité par zeqL

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte