219 réponses à ce sujet

[Path]

Ben si, j'ai 2 types de suspension. 

 

Un châssis souple pour que les 4 roues soient bien plaquées au sol.

 

Et pour les vibrations, j'ai mis des petits amortisseurs que tu vois juste au dessus. Entre le châssis et le premier étage du boitier.

[Serveurperso]

Ah oui nickel j'avais pas vu la vidéo !

[Mike118]

ça semble sympa Le collecteur tournant il est dispo ?

 

Oui il est dispo collecteur tournant ... ( j'ai mis du temps à répondre dis donc ... )

[Path]

J'avais vu t'inquiet
Je dis pas non mais pas pour le moment. Je vais rester sur de la 2D pour la mise en place du robot. Peut-être après mes premières explorations. Je te tiens au courant.

[Path]

Quelques nouvelles de mon Hector.

Le premier étage (le rouge) est terminé. Assemblage, câblage, code. Le 12V reste sur cet étage. Le 5V remonte au dessus. Remonte aussi les 4 vitesses des roues.

J'attaque le 2e étage le jaune. Le mega doit redescendre les commandes des moteurs. Au passage, il doit aussi prendre les commandes arrivant du raspberry.

 

Hier je butais sur un problème très bête. Les nano du 1er étage envoient la vitesse toutes le 100 ms. Quand je debug, branché en usb, on a l'habitude de voir les leds tx et rx qui indiquent qu'il cause bien. Quand l'usb est débranché et qu'on ne passe plus que par les pin tx et rx, ces 2 led ne fonctionnent plus. Et c'est normal, c'est dans la doc de l'arduino. Ne le sachant pas, j'ai cru pendant un bon moment que la transmission ne fonctionnait pas. A cela s'ajoutait d'autres pb sur la mega en réception qui sont de l'ordre de l'interface clavier-chaise. Bref, tout ça pour dire que les led tx et rx du nano ne s'allument que pour l'usb.

 

Bref, j'avance.

[Serveurperso]

Pb d'ICC mdr !!!

[Serveurperso]

Hop good new ils ont pondu une MAJ du firmware RPLIDAR A2 pour supporter le 8K sur le même hardware:D

Je vais tenter cette semaine.

http://www.slamtec.com/cn/Support#rplidar-a2

https://wiki.slamtec...pageId=16154735

[Path]

Rho ben attends, je vais apprendre le chinois d'abord
Mais bonne nouvelle !!

[Path]

Voilà quelques nouvelles de l'avancement. Oui, oui, je suis toujours dessus. Et ça avance pas vite vu le peu de temps que j'ai. 

Le 1er étage étant fini, je suis sur le 2e. Le raspberry est à 50% et je viens de finir le mega.

 

 

J'ai fini le code du mega. https://github.com/P...ster/controleur

Algo mecanum  omnidirectional.pdf   1,88 Mo   170 téléchargement(s)

 

Il accepte les commandes venant du raspberry : strafe dans telle direction et /ou tourne sur la gauche ou la droite.

Il détecte les chocs et transmet l'info au raspberry.

Je me suis encore bien fait chier avec le réglage du PID ... C'est une vrai merde cet algo. Je connais pas mieux mais quelle merde à configurer. vraiment. 

Il affiche des infos sur le petit écran.

 

L'étage 2 est prêt à recevoir les commandes. Il me reste à définir ces commandes donc à mettre de l'intelligence dans le raspberry. Il doit le faire en fonction du nuage de points captés par le lidar. (Lidar toujours en 4K et je crois qu'il va le rester). Mon premier objectif est de s'éloigner des obstacles que je lui mettrai tout en évitant les murs.

 

 

 

[Mike118]

Je viens juste de comprendre que tu utilisais deux nano pour piloter deux moteurs et que la mega est le master de ces deux nano ! 

C'est marrant c'est exactement le même genre de configuration qui j'ai mis sur le robot octopus V0.  
Cette cascade de master slave =)

 

 

EDIT : en fait non je me suis trompé c'est pas exactement pareil ^^ 
Moi c'est les slave de plus bas niveau qui gérait les moteurs toi c'est un niveau au dessus avec la méga =)

[Path]

Pour être exacte, c'est 2 nano pour 4 moteurs

[Serveurperso]

Mais c'est quoi cette bouïne moi j'arrive à tout caser sur un arduino 8 bits 16MHz : la lecture des 4 encodeurs, la génération des 4 PWM, l'asservissement PID de tout ça, et l'odométrie + le protocole de trame radio temps réel à faible latence. et ça fonctionne absolument aussi bien que sur un PIC32 que j'ai mis uniquement pour traiter des milliers de points lidars et faire l'autopilote avec jojo.

 

Niveau charge CPU un seul arduino peux virtuellement gérer une dizaine de robots en pilotage manuel avec odométrie et asservissement et protocole faible latence.

 

EDIT : il suffit de quelques pages de code C pour un robot MECANUM complet asservi, odométriesé et pilotable via télécommande...

L'arduino peux aussi gérer une centrale inertielle complète en plus de tout ça... la preuve mes drones volent très bien:)

Le PIC32 80MHz c'est uniquement pour le défi de l'autopilote au lidar !

 

EDIT2 : avant que je connaisse jojo j'avais tout ça sur l'Arduino + la lecture de 8 capteurs ultrasons PWM et 12 télémètres infrarouges linéarisés + lecture courant + tension batterie. C'était le premier robot mecanum en ligne.

[Path]

Hé j'odomaîtrise comme je veux, comme je peux.  Comme tu vois, j'aime bien prévoir large

 

Dans mon code, il y a un truc qui n'est pas optimisé du tout. Je te le dis avant que tu ne bondisse de ta chaise ^^ C'est tout ce qui concerne la com série. J'utilise un encodage ascii. C'est très pratique pour la séparation des trames. (\n) Et pour la séparation des informations dans les trames. C'est très mal en cpu pour le décodage. Pas de binaire => de union ^^ Mais un parsing de string bien lourd. J'ai été formaté très jeune à ne pas aimer les commandes 'magiques'. A préférer le Keep It Silly Simple (KISS), pour que limite, le code n'est pas besoin de commentaire. Ok, ce n'est pas compatible avec l'embarqué où on va préférer compter les octets. D'où ma tendance à surdimensionner. Je prévois large aussi car c'est principalement de l'exploration. Je prévois de la marge pour les trucs qui pourraient venir après. ça m'évite de revoir la mécanique et l'électronique en cours de route.

 

C'est pas optimisé, c'est mon kiffe !!

[Serveurperso]

lol. Mais 16MHz pour faire de l'odométrie mecanum c'est très très très très très très large.

Et des trames binaires c'est largement plus K.I.S.S que de l'ASCII caca !

[Mike118]

KISS c'est très bien C'est ce qu'on fait aussi ! Et dans l'ensemble on fait suffisamment claire pour qu'il n'y ait pas besoin de commentaire ( surtout que le code n'est pas prêt à être release ... )

Par contre un union c'est très simple et ça a rien de magique ! =)

 

Le parsing de string c'est une méthode lourde et qui a ses limites certes mais efficaces et simple à mettre en place car les outils sont déjà existant ...  C'est comme ça que j'ai commencé moi aussi au début ... et j'ai évolué quand j'ai eu besoin d'évoluer =)

[Serveurperso]

la vache mais quelle idée de commencer en ASCII avec un système haut niveau or qu'il est plus simple et logique de comprendre des octets 8 bits et des mots 16 bits pour les types bas niveau.

[Mike118]

Il est plus simple de faire du haut niveau " interprétable faciliement " par l'utilisateur lambda ... surtout quand les fonctionnalités bas niveau qui décodent la trame existe déjà et sont déjà faite ... Il y a zéro dev à faire, et très peu de choix à faire, genre définir le start, le séparateur et le fin de trame .

 

Exemple concret avec cette trame: $123,200,0,115;  

 

Tout utilisateur lambda comprend facilement que "$"c'est le start de la trame, qu'il y a 4 valeurs séparé par le séparateur ", "et que le fin de trame est ";" ...
Et le code qui permet de récupérer les différentes valeurs d'un point de vue plus bas niveau existe déjà ... "readStringUntil " ... 

 

C'est justement le but du haut niveau de faire des couche d'abstraction qui simplifient l'ensemble ...  Et là les couches ont déjà été faites ...

 

Après d'un point de vue flux de donnée c'est sur que c'est pas optimisé... mais d'un point de vue dev c'est très simple ...
 

Ce qui est plus simple est plus logique pour certains ou certaine ne l'est pas forcément pour d'autre, il n'existe pas qu'une seule et unique façon de penser ou de voir les chose... 

[Serveurperso]

En dehors de devoir prévoir l'espace des données... le binaire c'est peu de complexité de dev supplémentaire pour beaucoup d'optimisation

 

EDIT : au final c'est le même boulot car il faut forcément maîtriser les type des données reçues pour pouvoir les utiliser dans les algos donc zéro pointé le protocole ASCII... Quitte à faire une couche d'abstraction autant faire des trames binaires de longeur variable avec séparation du modèle de données

[Path]

Je vous avais dit que vous alliez bondir ^^

 

Promis, dès que c'est stabilisé, je figerai les trames de ces com avec un joli struct et un union Mais il y aura toujours des séparateurs.

 

Y a rien de magique on est d'accord. La magie disparaît quand le code est lisible et compréhensible. Chacun sa montagne !! La compréhension est relative à chacun.

 

Ha on se refait pas que voulez-vous.

[Serveurperso]

Puis sur un Arduino faut tant que possible bosser en 8-bits types uint8_t ou int8_t et utiliser le wrap:)