Aller au contenu


Luos

Inscrit(e) (le) 12 juil. 2018
Déconnecté Dernière activité janv. 24 2023 04:05
-----

Messages que j'ai postés

Dans le sujet : Aide compréhension shémas luos

24 février 2021 - 02:52

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.


Dans le sujet : Une nouvelle manière de développer des robots.

26 octobre 2018 - 03:18

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...).


Dans le sujet : Une nouvelle manière de développer des robots.

26 octobre 2018 - 03:07

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.


Dans le sujet : Une nouvelle manière de développer des robots.

25 octobre 2018 - 09:46

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.

Dans le sujet : Moi c'est Luos

12 juillet 2018 - 01:46

J'ai déjà posté une vidéo de doggy dans un post traitant des robots quadruped et de moteur direct drive.

 

Je ferais peut être un post sur ce robot la d'ailleur, la façon dont il a été développé est interérsante...

 

Je vais ajouter à mon poste quelques vidéos de réalisation que nous avons fait dans ma précédente boite et dont j'aurais moins l'occasion de parler. ;)

 

Pour le reste j'ouvrirais des topics pour engager des discutions.

 

Merci à tous pour votre accueil,