Luos

Bonjour R2D21995,

Je viens juste de découvrir ta question.

On est plusieurs de chez Luos à être inscrit sur ce forum mais on a quelques difficultés a y contribuer régulièrement

Je vais passer sur mes notifications pour tenter d'améliorer mes réglages.

On a ajouté pas mal de carte (dont pas mal d'Arduino) directement utilisable avec Luos. On est en train d'ajouter des exemples qui fonctionne sur certaines cartes de développement Nucleo et Discovery de chez STM (c'est en cours de review et ça devrais être publié dans la semaine).

Aussi, on a récemment publié un nouveaux routage beaucoup plus simple permettant de relier des cartes de développement les unes aux autres sans aucune électronique complémentaire, juste quelques fils => https://docs.luos.io...eference-design

Ce routage one wire est amplement suffisant pour des projets qui n'on pas de contrainte particulière en CEM ou de longueur de câbles. On a de très bonne performance avec ce montage et il ne représente aucun changement d'un point de vue logiciel.

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.

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 :

Bonjour à tous,

Je suis Nicolas et j'ai 30 ans.

Je travail dans la robotique depuis un bon moment maintenant, je suis spécialisé en informatique embarqué mais j'ai également des compétences technique en électroniques info haut niveaux et mécanique.

Voici quelque robots/projets que j'ai pu développé durant mon parcours : 

 - NAO (aldebaran robotics)

 - 3 robots Eurobot

 - Makingbot (association)

 - Poppy (Poppy project) 

 - Reachy (Pollen Robotics) 

 - Doggy  (Pollen Robotics) 

 - Terrapi (terrarium connecté qui reproduit les conditions météorologique d'une zone géographique donnée)

 - Luos Robotics (mon projet de boite actuel, j'en parlerais dans un topic dédié)

Depuis une dizaine d'années je concentre mes activités et mon travail pour simplifier le développement de robot. J'ai développé une architecture robotique modulaire qui fait l'objet d'une nouvelle entreprise.

Bonjour à tous,

C'est le premier post de ce forum que je lis et c'est déjà super intéréssant ! 

Je ne vois pas trop ce qu'est ce soucis de vibration dont vous parlez.

Vous voulez parler de la stabilité en position du moteur (PID) ou du cogging?

si certain d'entre vous ne savent pas ce qu'est le cogging : Le cogging c'est un phénomène qu'on peut voir facilement sur un moteur brushless en le faisant tourner à la main. On sent des petits cran qui sont due à l'alignement des bobines et des aimants.

Si la vibration dont vous parlez est bien le cogging en générale pour l'éviter on fait une cogging map (une mesure de l'influence du cogging sur le couple en fonction de l'angle) pour pouvoir compenser le phénomène en soft.

Sinon en robot quadruped j'ai fait ça (il a pas le dynamisme d'un robot quasi direct drive) :