8 réponses à ce sujet

[Luos]

Je vous avais promis plus d'information à propos de mon projet (Luos Robotics), et nous arrivons enfin à une phase ou nous trouvons le temps de travailler sur notre communication   .

 

Vous êtes tous des développeurs de robots, vous avez donc tous probablement expérimenté la manière actuelle pour développer une machine : 

 1. On identifie la problématique

 2. On imagine un moyen de résoudre la problématique

 3. On liste toute les fonctions dont on vas avoir besoin pour y répondre

 4. On étudie chaque élément qui devra constituer le robot pour établir une architecture

 5. On développe l'architecture

 6. On développe chaque élément sur cette architecture

 7. On développe le comportement générale du robot

 8. On test

 9. En cas d'échec des tests, on retourne à la phase 2 ( sans parler des aléas technique...)

 

Pour simplifier tous ça, il faudrait limiter au maximum le temps que représente chaque étape et surtout atteindre l'étape de test le plus rapidement possible afin d'éviter d'avoir à tout recommencer.

Chez Luos Robotics c'est ce que nous essayons de résoudre.

 

Nous avons développé une architecture robotique modulaire qui permet très simplement d'ajouter ou retirer un ou plusieurs éléments dans un robot sans aucune carte centrale. Un peu comme si tous les capteurs, moteurs, et batteries avaient le même connecteur et pouvaient tous se brancher les uns aux autres.

Avec ce concept on peut résumer les étapes de conception : 

 1. On identifie la problématique

 2. On imagine un moyen de résoudre la problématique

 3. On liste toute les groupes fonctionnel dont on vas avoir besoin pour y répondre

 4. On test chaque groupe fonctionnel indépendamment

 5. On assemble tous les groupes fonctionnels ensemble pour obtenir une machine

 

Pour optimiser encore le process il faut réduire au maximum le temps pour réaliser les taches 4 et 5.

Mieux que des explications, je vous propose de regarder une vidéo qui l'explique :

 

Voici un exemple très basic d'utilisation :

[Mike118]

En gros si je résume l'architecture robotique proposé par LUOS c'est :

Un microcontrôleur dans chaque module, avec un code déjà flashé, qui communique de manière bidirectionnelle sur un bus de communication. 
Je suppose qu'il faut ajouter un " maitre " qui peut être "programmé" avec un langage haut niveau spécifique orienté objet ?  

 

Est ce bien résumé ? 

Quel est le protocole de communication entre les différentes cartes ?
Les modules peuvent ils être utilisé avec un arduino par exemple ? 

 

 

 

[Luos]

Plutôt bien résumé oui.

 

Chaque module est constitué d'une petite carte mère que nous appelons L0. Cette carte mère contiens un microcontrôleur, un convertisseur de puissance, quelques mesures, et une interface de communication. Par dessus cette carte mère on ajoute un "shield" qui viens typer la carte mère. On ajoute alors un firmware qui correspond au shield du module.

Tous les modules se branche les uns au autres et il n'y a pas vraiment de carte mère.

 

Pour le moment le firmware ne peut pas être modifié par l'utilisateur. Pour faire un code pour son robot il faut utiliser un module spéciale que nous appelons "Gate". Les modules Gate permettent de relier le robot a un ordinateur (pour le moment en USB ou wifi). Depuis l'ordinateur on peut consulter les valeurs des capteurs et piloter les différent éléments, ça permet d'avoir le comportement du robot qui tourne sur un ordi. On a un module Raspberry Pi qui permet d'embarqué le code sur le robot. Actuellement on peut donc considérer que l'ordinateur est la carte mère du robot.

Ce mode de fonctionnement permet de créer un seul programme pour plusieurs robots distinct en les connectant tous au même ordinateur. Par exemple un robot est en mesure d'utiliser un capteur déporté en wifi, ou-bien un robot peut être utilisé comme source d'information pour un autre robot ou comme une télécommande...

 

Plus tard nous donnerons accès au code du module à l'utilisateurs afin de lui permettre de complètement se passer d'ordinateur. Dans le réseaux chaque module est capable de piloter n'importe quel autre module, le réseaux est multi-master. L'idée est de faire ce que nous appelons des "comportement réflexe".

 

Prenons un exemple simple, on a un robot avec 2 roue et un capteur de distance à l'avant pour repérer les murs. On pourra placer un bout de code dans le capteur de distance qui agit directement sur les roue dès qu'un obstacle apparait. Dans le code principale du robot il n'y aura plus besoin de prendre en compte ce genre de comportement et le temps de réaction sera optimale.

 

Le bus est constitué d'un protocole maison que nous appelons Robus et nous utilisons du RS485 pour permettre un transit d'information rapide et robuste. Robus nous permet également de retrouver l'emplacement de chaque module dans le réseaux et nous attribuons des identifiant en fonction de cet emplacement. Pour le moment nous ne gérons que le montages de module en série mais nous proposerons des hub permettant des montages en étoile plus tard. Sur le connecteur des modules nous passons également de la puissance, de 5 à 24V jusqu'à 7A.

 

Pour être compatible avec arduino il faut ajouter un peut d'électronique (un driver RS485, quelques GPIO, Une alim, et des connecteurs). En réalité nos premier prototypes (dans ma précédente boite qui à fait naitre ce projet) était constitué d'arduino pro (ATMEGA328P) :

Nous allons probablement faire un shield pour permettre d'utiliser des Arduinos simplement. Pour le moment nos utilisateurs se contentent de notre module GPIO qui permet de contrôler des entrées sorties numérique et analogique.

 

Nous allons nous efforcer d'expliquer tous ça au fur et à mesure avec des tutos et des exemples.

[cocothebo]

Salut,

 

Surement beaucoup de travail sur le projet mais je reste circonspect sur le résultat et l'intérêt.

 

Peut être que j'ai raté quelquechose mais pour simplifier le truc, pour moi là on a un système de modules actionneurs/capteurs que l'on peut assembler facilement. Puis il faut une tour de contrôle qui n'est pas dans ces modules (le PC quoi, un PI).

Le gros avantage c'est que les modules s'assemblent sans difficultés, pas besoin de paramétrer des tonnes de trucs, mais après ça le gros d'un robot c'est pas d'arriver à controller un moteur ou lire l'état d'un potentiomètre, c'est de justement réaliser son "cerveau" et la je ne crois pas que la solution apporte énormément, plutôt cosmétique à mon avis, avec un environnement unifié qui permet d'avoir accès facilement aux modules dans un langage assez haut niveau.

(Je passe sur la conception mécanique vu que ça ne me semble pas du tout le sujet ici)

 

Bref la cible est qui? Parce que si je prends qqu qui veut faire de la robotique "sérieuse" (ie. les gens du forum quoi, pas des chercheurs ou autre, mais pas qqu qui veut juste refaire un AT-AT parce qu'il aime Star Wars), le plus long sera pas d'associer 10 servo et 5 capteurs, ce sera de faire fonctionner l'ensemble de façon cohérente.

Et pour celui qui veut jsute faire rapidemment un petit robot (pas péjoratif, sans se prendre la tête quoi), quel est l'avantage de la solution par rapport aux LEGO par exemple? Surtout que la on reste su du Python ce qui peut faire peur à des débutant, un langage graphique serait il me semble plus approprié.

Voila j'ai du mal à voir qui cela peut intéresser mais je me doute que vous y avez déjà pensé/étudié pour se lancer dans la création d'entreprise.

 

Ce qui serait top (à mon avis), c'est d'avoir quelque chose un peu comme le KNX pour la domestique, en gros un ensemble de modules indépendant qui sont capables de faire des actions sans avoir besoin d'un acteur principal, bref chaque module indépendant avec ses actions programmées pour lui.

Si je termine le // avec KNX, on fait une programmation globale (pas le choix faut bien y passer) mais chaque module reçoit son bout de code autonome.

 

Après attention, ne pas se méprendre sur mon discours ici, ce n'est pas faire juste du bashing parce que c'est top de voir des gens essayer de faire avancer le bouzin et surtout venir nous expliquer leur démarche ici!

Et je vous souhaite que la boîte fonctionne, je sais à quel point c'est difficile de monter et surtout faire vivre une boîte...

[Oracid]

quel est l'avantage de la solution par rapport aux LEGO par exemple?

Oui, justement ! Puisqu'on en parle.
Pourquoi aucune entreprise française, voir européenne, ne ferait pas des modules électroniques compatibles Lego et/ou Mindstorms.
Dans ce domaine, les seules entreprises sur ce créneau sont américaines, comme celle-ci, http://www.mindsensors.com/. Le problème, c'est que les frais de port sont prohibitifs.

Quitte à faire du Lego, autant allez jusqu'au bout. Et là, le marché est circonscrit, bien déterminé et bien existant. Avec des jeunes, mais également des adultes qui ont de gros, voir très gros moyens. Un site incontournable, https://www.eurobric...and-model-team/

Ceci dit, on peut faire du compatible Lego et du pas compatible, pourquoi pas ! Mais là, à mon avis, le marché est très petit et en tout cas extrêmement concurrencé par les chinois.
Oui, c'est vrai qu'aujourd'hui les chinois se lance également dans le Lego, mais à mon avis, il n'est pas trop tard pour réagir.

Vous voulez des idées ? Y a qu'à demander.

[Luos]

Ta réponse et très intéressante et surprenante !

 

Je ne m'attendais pas à des retours si pertinent et avec un telle profondeur, j'aimerais tellement que tous le monde comprenne si bien le fond du problème.

 

 

Peut être que j'ai raté quelque chose mais pour simplifier le truc, pour moi là on a un système de modules actionneurs/capteurs que l'on peut assembler facilement. Puis il faut une tour de contrôle qui n'est pas dans ces modules (le PC quoi, un PI).

Tu n'a rien raté c'est exactement le fonctionnement actuel du système. Nous allons débloqué les features au fur et a mesure cette version est notre (MVP) produit minimum viable. Il a fallu faire des choix sur les choses a développer en premier pour sortir une solution le plus rapidement possible qui soit utilisable.

 

Le gros avantage c'est que les modules s'assemblent sans difficultés, pas besoin de paramétrer des tonnes de trucs, mais après ça le gros d'un robot c'est pas d'arriver à controller un moteur ou lire l'état d'un potentiomètre, c'est de justement réaliser son "cerveau" et la je ne crois pas que la solution apporte énormément, plutôt cosmétique à mon avis, avec un environnement unifié qui permet d'avoir accès facilement aux modules dans un langage assez haut niveau.

(Je passe sur la conception mécanique vu que ça ne me semble pas du tout le sujet ici)

Notre solution ne remplace pas l'intégralité des étapes de développement du robot. En effet on ne change rien au problème de mécanique ou de comportement haut niveaux du robot. Notre Job c'est de proposer une solution qui vas simplifier et isoler les problématiques lié a l'électronique et au code bas niveaux.

 

Bref la cible est qui? Parce que si je prends qqu qui veut faire de la robotique "sérieuse" (ie. les gens du forum quoi, pas des chercheurs ou autre, mais pas qqu qui veut juste refaire un AT-AT parce qu'il aime Star Wars), le plus long sera pas d'associer 10 servo et 5 capteurs, ce sera de faire fonctionner l'ensemble de façon cohérente.

Et pour celui qui veut jsute faire rapidemment un petit robot (pas péjoratif, sans se prendre la tête quoi), quel est l'avantage de la solution par rapport aux LEGO par exemple? Surtout que la on reste su du Python ce qui peut faire peur à des débutant, un langage graphique serait il me semble plus approprié.

Voila j'ai du mal à voir qui cela peut intéresser mais je me doute que vous y avez déjà pensé/étudié pour se lancer dans la création d'entreprise.

Encore une fois tu as raison, notre système deviens pertinent à partir du moment ou ton robot doit avoir plusieurs microcontrôleurs. Dans le cas d'un robot avec quelques servomoteurs de modélisme et quelques capteurs une Arduino sera probablement plus approprié la plupart du temps. Mais par exemple une machine qui a besoin d'avoir du contrôle en couple fin sur du brushless vas monopoliser 1 microcontôleur par paire de moteur, il deviens alors très important d'avoir un système fiable et efficace pour relier ces sous systèmes.

 

Les modules disponible actuellement sont basiques et beaucoup de nos clients réalise leurs propre modules basé sur notre technologie.

Notre cible principale c'est les développeurs de machines spéciale complexe, ou les entreprises de robotique qui cherche une base robuste et avec de mécanisme de maintenance avancé.

Notre technologie est aussi utilisé par des chercheurs, des artistes, des professeurs, et des poles innovation plutôt pour les aspects prototypage simple. Nous allons donc continuer a mettre à disposition des modules "générique"

Nous avons une version de scratch 3 qui permet le pilotage de module mais pour le moment personne ne l'utilise et on ne la maintiens plus vraiment. Nous l'avons présenté à la conf Scratch de l'an dernier : 

 

 

Ce qui serait top (à mon avis), c'est d'avoir quelque chose un peu comme le KNX pour la domestique, en gros un ensemble de modules indépendant qui sont capables de faire des actions sans avoir besoin d'un acteur principal, bref chaque module indépendant avec ses actions programmées pour lui.

Si je termine le // avec KNX, on fait une programmation globale (pas le choix faut bien y passer) mais chaque module reçoit son bout de code autonome.

KNX est le bus qui est le plus proche de notre technologie. Chaque module est indépendant et peut piloter ou consulter n'importe quel autre module du réseaux, il peut aussi accueillir du code utilisateur. Par exemple le capteur de distance à l'avant d'un robot à roue peut ordonner au moteurs de bloquer en cas de detection d'obstacle. Nous appelons ça des "comportements réflexe".

En interne on fait déjà ce genre de chose mais pour le moment on limite encore les accès à nos utilisateurs car ces features sont encore instable et brouillons. Encore une fois pour le moment l'utilisation de la techno est limité au minimum et nous la ferons évoluer le plus rapidement possible. Le hardware des modules actuels sera en mesure de gérer toutes ces choses grace au future versions firmware.

 

La principale différence que nous avons avec KNX c'est que le nombre de module référencé ne correspond pas au nombre de cartes dans le réseaux. Dans une carte il peut y avoir plusieurs "modules virtuel".

Par exemple notre module dynamixel génère dynamiquement des modules virtuel à la détection des moteurs. En python, l'utilisateur voit donc apparaître chaque moteur Dynamixel qu'il ajoute comme un module indépendant qu'il peut nommer et piloter.

 

J'espère avoir répondu au mieux à tes interrogations et nous faisons tout pour tenter d'expliquer tous ça au gens de la manière la pus claire possible.

[Luos]

Oui, justement ! Puisqu'on en parle.
Pourquoi aucune entreprise française, voir européenne, ne ferait pas des modules électroniques compatibles Lego et/ou Mindstorms.
Dans ce domaine, les seules entreprises sur ce créneau sont américaines, comme celle-ci, http://www.mindsensors.com/. Le problème, c'est que les frais de port sont prohibitifs.

Quitte à faire du Lego, autant allez jusqu'au bout. Et là, le marché est circonscrit, bien déterminé et bien existant. Avec des jeunes, mais également des adultes qui ont de gros, voir très gros moyens. Un site incontournable, https://www.eurobric...and-model-team/

Ceci dit, on peut faire du compatible Lego et du pas compatible, pourquoi pas ! Mais là, à mon avis, le marché est très petit et en tout cas extrêmement concurrencé par les chinois.
Oui, c'est vrai qu'aujourd'hui les chinois se lance également dans le Lego, mais à mon avis, il n'est pas trop tard pour réagir.

Vous voulez des idées ? Y a qu'à demander.

Il me semble que Génération Robot, une boite Bordelaise à développé une brique Légo wifi...

 

Nous adorerions avoir une compatibilité avec l'environnement Légo (je suis également un grand fan). Pour le moment nous sommes contrains à travailler uniquement sur les sujets qui sont porté par nos client (il faut bien manger...).

[Oracid]

Il me semble que Génération Robot, une boite Bordelaise à développé une brique Légo wifi...

C'est vrai, je les avais oublié.
En fait, ils vendent entre autres les produits Mindsensors. Ils ne fabriquent pas, il me semble.
Pour le wifi, c'est déjà inclus dans l'EV3, mais je ne pourrais pas t'en dire plus.

Sinon, dommage ! Il y a certainement du business à faire autour de Lego.

[cocothebo]

Super, merci pour la réponse

 

Et je n'aurais pas pensé que la cible soit justement des dev spéciaux. Je voyais plus cela comme une simplification pour "tout le monde" d'où mes interrogations.

 

Pour la comparaison KNX, je pense que votre système reste proche dans l'idée, surtout qu'un module KNX (vu comme une adresse) permet souvent des fonctions multiples ou permet de voir plusieurs actionneurs comme pour votre cas avec les servos.

C'est je trouve super, quoi pour la domotique ça me semble un concept vraiment important ce côté complétement décentralisé, en robotique j'avoue que j'ai un peu plus de mal à voir comment implémenter cela sur des projets complexes.

Et même si je ne suis pas complétement adepte du biomimétisme à tout va, on peut remarquer que les organismes à "intelligence" déportée sont plutôt des organismes assez simple, sinon ya quand même presque toujours (toujours?) un cerveau en chef d'orchestre.

Par contre effectivement un certain nombre de réactions sont réflexes et ne passe pas par ce cerveau, souvent les réactions primaires qui se doivent d'être très rapide.

 

Bref au final votre solution avec un module style Rasp PI pourrait être assez proche de "l'architecture" évoluée de la nature, un cerveau pour les traitements les plus complexes, mais un peu de réactions déportées pour quand les réactions se doivent d'être les plus rapide possible.

 

 

Une chose de sûre, je vais suivre vos développements!