Serveurperso

Petite idée de sous projet sympathique pour avoir un jouet en ligne :

Je vais le réaliser immédiatement car c'est amusant ne coûte pas cher et très rapide à faire.

C'est aussi évolutif en technicité -> un algo computer vision pourra piloter la bille.

J'ai déjà commandé le labyrinthe en bois de ce type (prime ça arrive demain soir lol) :

https://www.amazon.f...0?ie=UTF8&psc=1

Planches options :

https://www.amazon.f...0?ie=UTF8&psc=1

La caméra sera bien évidemment fixée au dessus avec une led blanche d'éclairage (genre 1w).

Il n'y a besoin que de 2 servomoteurs pour le pilotage du plateau, en direct drive ou via une réduction/multiplication via courroie élastique et/ou impression 3D pour obtenir le bon rapport de pilotage.

Plus un servomoteur ou autres qui s'occupe de la remontée de la bille = encore chose amusante à faire.

c'est toujours mieux que de boucher les trous et devoir faire une rescousse pour éjecter la bille.

Actuellement le robot "Raspibot" : https://www.vigibot.com/ est le POC d'une PI toute seule capable de piloter plusieurs servomoteurs, soit autant qu'il y a d'I/O dispo sur la PI, avec une précision à la microseconde "jitter-free" grâce à DMA !

ça risque d'être rigolo de voir si 2 joueurs s'en sortent avec 50% de pilotage chacun (moyenne comme actuellement sur les robots) ou même tester avec un seul axe chacun.

Salut les roboticiens !!!

Tout d'abord attention, n'achetez pas ce produit de chez Waveshare Electronics : je vais expliquer pourquoi...

Je voulais deux kits pour développer *RAPIDEMENT* le code client de la version économique et basée exclusivement sur une Raspberry PI d'un robot connecté au futur cluster de serveurs de pilotage temps réel (dont je développe en ce moment l'interface multi-robots / multi-utilisateurs).

Premièrement : petite surprises au déballage pour le grand maniaque de la carte électronique que je suis : sur deux kits, deux PCBs sur quartes profondément rayés (du vernis jusqu'au cuivre) et des composants abimés/tordus, malgré la qualité de fabrication de type industrielle soudé à la machine, très propre mais bâclé, sans doute par une logistique pré/post production lamentable et/ou des salariés maltraités.

Secondo : les palonniers Tower Pro ne sont pas compatible avec l'axe X de ce kit pan & tilt à quelques dollar, et même sur la vidéo YouTube officielle ils en ont bavés pour l’assemblage, c'est archi-coupé de façon salle et bien hésitante voir à 5:44 :

https://youtu.be/ONg0qpxYWQo?t=344

Au premier visionnage on ne s'en rend pas compte, mais ça en devient presque risible de revoir le passage de la vidéo après avoir découper/limier à fond et dans tout les sens ce pauvre petit palonnier croix (le moins pire niveau compatibilité) pour au final se retrouver avec des trous qui ne peuvent pas tomber en face.

Les vis rikiki qui ne sont pas utilisables sans profonde modifications plasturgique bien crades, mais heureusement, il y a l'impression 3D pour tout refaire...

Cependant bye bye la mise en service *RAPIDO* que j'ai payée au prix fort soit 80 balle le kit pour me retrouver avec ce... Truc (pour ne pas dire autre chose)...

Un palonnier de servomoteur ça se taille uniquement dans la longueur le reste : affinage des bras et reperçage du plastique trop proche de trous déjà existants EST, pour un kit commercial du bricolage de bas étage.

Troisième point, et la c'est le carton rouge :

Ils se sont mélangé les pinceaux dans les entrées sorties du double pont en H (TB6612FNG) entre les A, les B, les 1 et les 2 (AIN1/AIN2/BIN1/BIN2).

C'est pas grave, si ce n'était que du software car j'ai tout bien re développé en Node.js ... pour au final me retrouver avec un robot ayant les deux hardware PWM de la Raspberry PI (soit les GPIO 12 et 13 du broadcom) sur LE MEME PUT1 DE MOTEUR (le gauche) ! Ce qui explique pourquoi ils ont utilisés du software PWM bien crado dans le code Python d'origine voir code python https://github.com/d...rc/AlphaBot2.py

Or que le pilotage de moteurs ne nécessite pas un timing précis au point de devoir faire du DMA, ils pouvais exploiter le PWM Hardware d'origine de nos PI 2/3... Voir même nous garder les HPWM suffisants pour les servomoteurs ou lieu de nous claquer cette interface I2C vers PWM pour contrôler les servomoteurs.

Et pendant ce temps la le buzzer qui nous éclate les oreilles aux parasites ultrasons, vive le filtrage... intégrer un filtre LC à la carte était bien trop compliqué pour Waveshare : "de l'analogique, au secours !!" les pauvres...

Moi les deux kits c'est retour à l'expéditeur !

Je vais passer quelques instants en mode prototypage (PI + jumper wire) pour trouver la combinaison H/PWM SoftPWM DMA/PWM permettant d'avoir les commandes les plus précises possible sans adjonction d'un Arduino. C'est important pour obtenir une version rikiki (PI Zéro) ou économique d'un robot malgré tout fluide et performant sur le web.

L'ajout d'un Arduino (ou autre microcontrôleur) reste la version idéale en architecture robotique : l'IHM / client web / Mathématiques SLAM en Node.js/C++ sous Linux et le temps réel en C/C++ sur un coprocesseur dédié les deux communicants en UART.

Pascal

Bonjour les roboticiens !

Pour ceux qui ne savent pas, je bosse avec Mike118 sur un framework complet de robot web autonome à faible latence. Du hardware en passant par le système d'exploitation jusqu’à l'interface web. Mettant en avant la plus faible réactivité possible et des déplacements rapides et précis...

Mike m'aide souvent à créer des algos avec des partie mathématique que je n'ai pas en tête et je l'en remercie.

Ce logiciel existe sur 3 robots au monde actuellement, les 2 miens et le sien, c'est tout. J'ouvre ce thread comme un "BLOG" de suivi sur l'avancement de ce problème sur lequel je rame depuis maintenant 2 jours, avec en prime ce driver de parcing 4K ulta-optimisé et fonctionnel à la fin...

Suite à l'implémentation d'arithmétique entière et d'une table de sinus 16-bits/16-bits dans la mémoire flash de notre PIC32 qui ne dispose pas d'une FPU, la puissance de traitement disponible à été démultipliée et du coup le mode 4K de ce LIDAR devient intéressant pour améliorer les perfs de nos algos de localisation:D

J'ai donc re-testé mon algo de décodage RPLIDAR 4K et il toujours bugué, le vilain bug n'est toujours pas mort malgré tout ce temps lol

Par contre niveau ressources dispo sur le PIC32 c'est la fête, il faut donc qu'on trouve ce problème absolument !

Le thread de Path qui à déjà fait le décodage 4K mais en JavaScript :

http://www.robot-maker.com/forum/topic/11759-le-rp-lidar-a2/

Le code concerné que je connais presque par coeur mais qui ne m'a pas aidé a résoudre mon bug :

https://github.com/P...express-scan.js

Les pages du datasheet RPLIDAR A2 qui nous intéressent vont de 19 à 23. Pour rappel :

La trame :

 Cabin.png   45,38 Ko   27 téléchargement(s)  Format.png   61,15 Ko   28 téléchargement(s)

Description des donnés :

 Format1.png   135,71 Ko   27 téléchargement(s)  Format2.png   69,43 Ko   26 téléchargement(s)

Le calcul de l'angle :

 Maths.png   38,74 Ko   27 téléchargement(s)

Le BUG :

Les points verts sont les impacts lasers avec un historique de quelques milliers de points = plusieurs frames lidar complètes.

Les lignes blanches sont celles qui sont affichées en ce moment = un fragment d'une trame lidar, soit 30 points (limitation bande passante radio)

0) L'algo 2K fonctionne parfaitement, mais pas en 4K

1) L'angle correct est horizontal, le robot est perpendiculaire au mur de devant, il est aligné à la pièce.

2) Une partie des mesures, si il en existe qui sont à une petite distance du robot sont correctes, on visualise les mystérieux décrochages de chaque côtés quand la distance augmente.

3) Le reste du nuage de point est en retard de 9 degrés !

Je recule légèrement le robot du mur de charge :

 1.png   40,02 Ko   27 téléchargement(s)  2.png   80,88 Ko   26 téléchargement(s)

Et encore plus loin :

 3.png   43,31 Ko   31 téléchargement(s)

Et sur cette capture, avec le robot au centre de la pièce, on vois bien les 9 degrés d'erreur niveau affichage du Theta

La pièce est inclinée or que le robot est parfaitement aligné :

 Erreur9deg.png   768,58 Ko   28 téléchargement(s)

J'édite totalement le premier post avec des vidéos de démo plus parlantes. C'est un résultat inespéré de pouvoir faire du SLAM (cartographie et localisation simultanées) parfaitement fluide sur un uC Arduino-like 80MHz du coup cette modif va donner un petit coup de vieux aux posts suivants:) Le SLAM est le résultat de notre travail avec Mike118 sans qui il n'existerait pas.

Vidéo avec pilotage web simultané de plusieurs robots chez moi :

Vidéo de Mike118 pour Vigirobotics.com avec la démo de notre algorithme de SLAM

Et enfin l'accès réel via le cloud Vigibot.com qui est une copie officielle de ma page sur serveur perso d'origine.

Ce "widget" donne accès a mon premier robot, il s'appelle "Radiobot" car c'est le seul de la flotte à disposer d'une liaison UHF longue portée "non-Wi-Fi" et aucune carte embarquée Linux à bord comme tout les autres :

Les autres robots sont sur www.vigibot.com qui sera bientôt en libre accès avec un fichier open-source pour faire rapidement un robot pas cher à l'aide d'une raspberry PI et de servomoteurs.