Carte programmable Esus - Contrôle robot & IoT

Posté par . Édité par ZeroHeure, Davy Defaud, Benoît Sibaud, Pierre Jarillon et palm123. Modéré par Xavier Claude. Licence CC by-sa
26
26
sept.
2016
Do It Yourself

La carte programmable Esus est un nouveau projet proposé sur le site de financement participatif Kickstarter.

carte programmable Esus

Elle est conçue pour le contrôle d’un robot mobile ou des projets d’objets connectés. Pour la programmation, elle se programme avec l’IDE Arduino ou en langage Blockly pour les enfants. Un projet GitHub existe et la licence annoncée est Creative Commons BY-SA 3.0.

La carte Esus est une carte basée sur un microcontrôleur ESP8266 de 80 MHz avec les caractéristiques suivantes :

  • 6 entrées analogiques ;
  • bus SPI, I²C, série ;
  • communication Wi‐Fi ;
  • 2 ponts en H de 1 A,
  • 6 entrées‐sorties logiques,
  • régulateur à découpage ;
  • alimentation : 2,8 V à 11,8 V ;
  • dimensions : 80 × 50 mm ;
  • fabriqué en France ;
  • code source libre.

Pour participer à la campagne, c’est ici.

  • # Soyons positif.

    Posté par . Évalué à 4.

    Une carte, tout en un, en robotique, c'est génial, car rajouter des ponts en H, c'est compliqué, tout comme l'alim. Vous devriez même prévoir un support de pile type AA, sous la carte. Si la carte est vendu 35€, c'est un bon prix.

    Par contre, limiter les ponts en H à 1A, c'est pour un petit robot. Dommage de ne pas proposer un pont vers une Raspery Pi, c'est une sorte de norme en embarqué pas cher, non ?

    Prévoyez-vous de pouvoir connecter directement des servo moteurs (1 pwm + alim)? Un servo moteur est toujours très pratique, si jamais le robot a besoin de connaître la position exact d'un axe, il "suffit" de rajouter un potentiomètre mécanique, c'est précis et fiable (par contre il faut une entrée ADC).

    J'ai un peu une déformation venant de la coupe e=m6, avec des robots de 10 kg avec des vitesses de 30cm/s, très réactif. Mais peut-être une version suivante…

    L'idée, c'est d'avoir 2 ou 3 ponts en H, des entrées compteurs pour asservissement par roues codeuses, des entrées analogiques (plein, c'est pour les capteurs), des sorties PWM pour les servo-moteurs ou pour un moteur avec un seul sens. L'idéal est d'avoir un seul composant numérique, relier plein de PIC ou autre par I2C ou lien série, c'est lent et chiant à programmer. Le top, c'est d'avoir un cpu avec fpu, avec assez de mémoire pour être "maitre", si besoin un truc qui ressemble à un PC peut être ajouter en esclave (vidéo, communication).

    Par contre, cette liste au père noel, change complètement avec les Rasperry Pi zéro à 5€. Le seul problème est de créer une carte "puissance" minimaliste pour cette "zéro", mais il faut trouver un moyen fiable de relier plusieurs Rasperry ensemble par leur bus CAN.

    "La première sécurité est la liberté"

    • [^] # Re: Soyons positif.

      Posté par . Évalué à 2.

      Bonjour Nicolas Boulay,

      La carte Esus est faite pour les petits robots, le pont en H est limité à 1A par sorties. La carte Esus peut facilement communiquer avec une carte Raspberry Pi en I2C, SPI ou UART. De plus, la carte Esus peut alimenté la carte Raspberry Pi via une batterie Lipo. Il y un une alimentation boost/buck pour réaliser du +5V.

      Vous pouvez aussi contrôlé des servomoteurs de modélisme. Il y 6 entrées ADC sur la carte.

      • [^] # Re: Soyons positif.

        Posté par . Évalué à 3.

        Bonjour Nicolas,

        Ton projet mérite d'être soutenu. Je viens de me fendre de 35€ sur Kickstarter.
        Par contre, essaye de te faire relire avant de publier. Ton site est truffé de fautes de grammaires.
        Bonne continuation,

        Xavier

    • [^] # Re: Soyons positif.

      Posté par (page perso) . Évalué à 1.

      L'idéal est d'avoir un seul composant numérique, relier plein de PIC ou autre par I2C ou lien série, c'est lent et chiant à programmer.

      Quand j'ai fait de la robotique (à la coupe de France qui ne s'appellait déjà plus coupe e=m6), on avait un bootloader qui se souvenait du dernier binaire chargé dans nos PICs pour ne reprogrammer que les parties modifiées (souvent pas tant que ça). Un des PICs faisait proxy et permettait de programmer tous les autres à travers un bus CAN ou I2C. Le tout piloté par une UART bluetooth qui permettait de le faire sans même avoir à brancher un câble sur le robot, ce n'était pas lent, ni même chiant :)

      Sur la carte dont il est question ici, il y a déjà du wifi intégré, donc je pense que la question ne se pose même pas?

      • [^] # Re: Soyons positif.

        Posté par . Évalué à 2.

        ce n'était pas lent, ni même chiant :)

        Une fois en place sûrement, mais à implémenter ?

        Je ne suis pas un politicien ! J'ai un avenir à créer, pas un passé à défendre !

        • [^] # Re: Soyons positif.

          Posté par (page perso) . Évalué à 3.

          Ah ben oui il a fallu passer un peu de temps pour mettre les choses en place. Mais cela a servi et évolué pendant plusieurs années en réutilisant les mêmes cartes un peu génériques, et je pense que ça a été plus que largement rentabilisé.

          Bien souvent, on pouvait reprogrammer en moins d'une seconde car il y a plein de choses dans le code qui ne bougent pas la plupart du temps (on ne travaille que sur un petit morceau à la fois). Si on compare à l'approche du genre "brancher le pickit/ICD/… - réécrire le firmware - débrancher le pickit", qui prend déjà 1 minute quand ça marche bien, et parfois beaucoup plus (parce qu'on finit par casser un connecteur, que la carte à reprogrammer est dans un coin pas accessible du robot, parce que le robot est à 3 mètres et qu'i faut aller le chercher), y'a pas photo.

          C'est comme si on disait que les makefiles ça sert à rien, que ça va plus vite de lancer le compilateur à la main sous prétexte que y'a que 3 fichiers dans le projet. C'est vrai quand on compile 1 fois. Mais quand on compile 10 fois, il faut se poser des questions.

          Il faut utiliser ça:
          https://xkcd.com/1205/

          Sans tomber dans ça:
          https://xkcd.com/1319/

          • [^] # Re: Soyons positif.

            Posté par . Évalué à 2.

            Chez moi, les PIC ne servait que d'IO, sauf pour celui qui faisait l'asservissement en vitesse des 2 roues. Tout les paramètres étaient transmis par le PC relié par lien série.

            "La première sécurité est la liberté"

      • [^] # Re: Soyons positif.

        Posté par . Évalué à 2.

        On avait aussi 3 pic par I2C. Mais c'était impossible de faire plus de 100Hz de "round-trip" : lecture capteur, traitement, commande effecteur.

        Alors, il faillait faire par morceau, avec l'asservissement dans un coin, mais devait quand même donné l'erreur de position pour détecter un glissement, et avoir ses valeurs de PID en entrer, etc… Bref, c'était compliqué.

        "La première sécurité est la liberté"

  • # Concurrence chinoise

    Posté par . Évalué à 5.

  • # intéressant

    Posté par . Évalué à -6.

    La campagne sa sera quand ?

  • # Résultats de la campagne

    Posté par (page perso) . Évalué à 3.

    « 28 contributeurs ont engagé 1 352 € pour soutenir ce projet. » et « 1 352 € engagés sur 850 € »

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.