Serveurperso

Hey lardon! T'as oublié d'indiquer la provenance de la majorité de ce matos 😂

Hop ça avance toujours, un nouveau petit robot qui fait la surface d'une PI !

L'interface affichera de moins en moins de chose, juste ce qui est nécessaire en fonction du robot.

 

 

Bonjour:D Les estiens ? (ça se dit comme ça ?)

 

Hou la elle est nerveuse la vidéo, ça risque pas d'être trop speed pour être joué à distance ? Il va falloir le calmer avec une inclinaison réduite ? La latence du retour vidéo est d'environ 200ms si la connexion et les performances du client permettent de rester en flux tendu, la latence du contrôle est celle du ping + la celle de la mécanique.

 

ça me rappelle mon jeu avec une bille sensiblement de la même taille : j'ai voulu faire le labyrinthe en bois, j'ai pris le plus gros possible pour que ce soit plus lent, mais le problème est que transmission à ficelle ça se décale assez rapidement, sinon c'était jouable (pilotage X Y de servos 9g) mais il faudrait une prise direct ou courroie crantée genre qu'on utilise sur les moteurs pas à pas en impression 3D...

 

Sinon pour maximiser les performances un electro-aimant pourrait être mieux qu'un servomoteur mais ça risque de compliquer l'interfaçage sur une raspberry pi seule (sans arduino)... Quoi qu'il existe des cartes relais avec PWM en entrée, utilisés par les radiomodelistes...

 

Pour l'instant on dispose des moyens de commande suivants :

 

- De 8 boutons de type inverseurs, switchs ON/OFF -> un clic qui inverse l'état d'une GPIO sur la PI, pratique pour allumer et éteindre des sous systèmes sur un robot avec des relais ou des mosfets... Ils sont mappés sur les touches clavier PC de 1 à 8 (Shift + 1, 2, 3...).

 

- D'un positionnement de servomoteurs par drag'n'drop à la souris sur la vidéo (PWM servo), c'est utilisé pour les têtes et pince (outils) X-Y des robots

 

- De 3 modes de commandes en vélocité, utilisés pour déplacer un robot :

   1 - par joystick-souris ou écran tactile, drag'n'drop sur la croix centrale.

   2 - par impulsions au clavier (touches Z E R S D F) ou au clic "plus / moins" sur les flèches -> le robot à un pilotage de type jeu asteroid, déroutant mais très précis quand on est habitué.

   3 - Façon "tout ou rien" au clavier avec les touches fléchées classiques. -> pilotage au clavier de base qu'on rencontre dans tout les jeux.

 

C'est cette 3ème façon "tout ou rien" sur les flèche du clavier, qui combinée à de simples servomoteurs branchés (la ou habituellement on met les contrôleurs moteurs des roues des robots), peuvent faire un appuis + relâchement comme le souhaite l'utilisateur... de cette façon le servomoteur reproduit un appui tout ou rien identique au doigt de l'utilisateur sur le clavier PC.

 

Il est possible d'y brancher aussi les fameux cartes relais avec entrée PWM de modelisme.

 

Je sais pas si je suis assez claire au pire Mike m'aidera à ajouter de l'info... Par contre ça me donne l'idée de développer un mode "Bouton POUSSOIR" - > appuis clavier ON / relâchement clavier OFF, configurable pour les 8 fonctions qui sont actuellement uniquement des inverseurs type switchs ON/OFF hop liste "TODO"...

 

Avec les touches fléchées ça fait actuellement 4 télé-boutons poussoirs, utiliser tant que possible les switchs inverseurs pour le reste... Les icônes seront customisables par la suite.

 

Bouïnez bien !

 

Pascal

Les risques sont *quasi* inexistants... Grand adepte du serveur auto hébergé à la maison depuis les débuts d'internet et j'ai jamais eu le moindre problème.

 

Il suffit d'avoir une distrib Linux (préférablement strict minimale en mode console) tenue up to date (apt update / apt upgrade) et appliquer les bases de sécurité dont on trouve les tutos partout sur le net.

 

La base c'est d'avoir un password SSH correct ou mieux : n'accepter qu'une clé RSA privée

(/etc/ssh/sshd_config décommenter le PasswordAuthentication yes et le foutre à no après avoir mis ton id_rsa.pub dans ~/.ssh/authorized_keys et garder au chaud le id_rsa clé privée)

 

Le quasi c'est :

 

 - Se faire DDOS dans le cas d'une connexion ADSL + un gosse sur internet ne t'aime pas et obtient ton IP systématiquement. ça dure jamais bien longtemps et c'est possible dans le cas ou tu fait un site publique ayant un domaine et que le gosse en question ai une pseudo raison d'être innervé après toi.

 

Pour s'amuser (vécu) on peux faire rentrer les fameux vulnerability scan bots dans de fausses machines qui n'ont accès à rien (PI, VMs...) et étudier leurs actions en live.

C'est encore plus drôle quand le "hacker" crois tenir une trouvaille et se connecte manuellement dans le pot de miel monté comme un escape room prévu pour lui faire miroiter des choses tout en le faisant souffrir sur la durée.

 

"tuer une mouche avec un canon" :

- Qui va se faire chier à exploiter une vulnérabilité zero-day pour obtenir le root sur une PI et gagner l'accès a la lumière du salon de tonton jacky-les-lumières à trifouilly-les-oie ?

 

Il y a beaucoup de choses à dire sur la sécurité mais à partir d'un certain point sur une PI domotique perso ça devient de la parano pure et simple... Sauf si c'est pour s'amuser et c'est ce qui compte !

Le seul moyen que j'ai trouvé, passer par au dessus, permet de ne pas du tout marquer la nappe et ce à aucun endroit. Je suis maniaque avec le matos lol

Et j'ai une tête avec un servo + un engrenage qui permet à l'axe X / pan de faire presque le tour complet et aucun soucis.

Il devrait y avoir moyen de passer la nappe par dessous mais il faut forcément plier d'une certaine façon et faire des "accordéons" ou des boucles au niveau des articulations.

 

Les seules caméras -PI- utilisables sur des petits robots sont des grands angle de 170 degrés, les caméras officielles sont inutilisables - ça zoom / serre de trop et rend le pilotage désagréable - et il n'existe actuellement un seul modèle qui comporte un filtre IRcut amovible (bientôt sur la boutique du site) et permet d'avoir de bonnes couleurs la journée et une sensibilité potable la nuit avec les 2 fameuses leds de 1 watt qui servent d'illumination infrarouge.

 

ça permet de très bien voir une pièce de 40m carré sans soucis. Je pense plus. Soit quelques mètres devant le robot, 4 ou 5 mètres je pense...

 

Niveau sensibilité c'est un capteur CMOS 1/4 de pouce avec un gain assez faible (impossibilité de faire apparaître le plancher de bruit à l'image) sans les projecteurs 2 * 1W IR il ne faut pas compter voir quoi que ce soit la nuit.

 

Il reste à étudier la coupure des leds car elles consomment pas mal et ont tendance a rester allumé longtemps après la bascule en mode journée de la caméra. il faut beaucoup de lumière pour qu'elles se coupent. Je pense qu'il faudra apporter une mod pour injecter un signal de coupure forcé des leds IR.

 

La sensibilité est très dépendante du temps d'expo de chaque images et le compromis idéal que j'ai trouvé entre la fluidité du H.264 et la sensibilité c'est le 25FPS qui correspond au bon vieux PAL utilisé par d'autres robots plus avancés ayant de vrais caméras ou il commence à être possible de parler "sensibilité"

 

Des photos sans illumination IR, avec IR, lumière fluo, et la denière photo ni l'un ni l'autre mais avec une caméra CCD couleur 1/4 de pouce + un traitement vidéo maison

J'ai imprimé un autre robot ce matin et paf, ça fait un petit frère pour l'autre !

Ce sont des prototype les kits doivent contenir un PCB pour câbler le tout plus facilement. Sinon voila comment j'ai fait :

 

Avec une Raspberry PI on dispose de 2 pin 5 volts (et plusieurs GND). Du coup on peux alimenter 2 servomoteurs sans avoir besoin de rien d'autres que des fils standard 2.54 femelle-femelle.

 

Vu que la "petite carte de conversion PWM servo en PWM 0 à 100%" dispose elle aussi de deux pins 5V (et 2 pins GND), elle redistribue le jus "elle et rend la place qu'elle prend"

 

On se retrouve avec un robot complet soit 2 moteurs CC et 2 servomoteurs pour la tête n'ayant juste besoin que de quelques fils 2.54 femelle-femelle !

 

Ce châssis respecte les contraintes suivante :

 

1) Pas cher et facile à reproduire

 

2) Un robot qui ne tombe pas

 

3) Qui ne reste pas coincé et qui peux rouler sur un câble ou un gros tapis.

 

4) Autonomie de la mort possible : Max 4 batteries 18650 de 3400mAh soit 13.600 ampères heures.

 - Mais il est possible de ne mettre qu'un LiPo ou une seule 18650 pour alléger le prix. (Tout est en parallèle.)

 

5) une tête qui permet de voir partout indépendamment de la position de la base, mais il est possible de ne monter qu'un seul axe (haut bas) ou aucun pour simplifier.

 

Vidéo d'un des premiers tests :

 

 

C'est aussi maniable que les autres robots qui coûtent chers - (le secret est de NE PAS utiliser de servomoteurs modifiés à rotation continue, ils ne permettent que du tout ou rien et ceci avec une précision très aléatoire - pente trop raide)

 

Voila des photos du montage aujoud'hui :

Enorme le spotmini qui danse !!!

 

Ce qui est en vert c'est le live le temps réel. Des points et lignes vertes (plus exactement clusters de points alignés) vues par le lidar.

 

Les lignes grises (features) sont la carte, elle est construite à l'aide des lignes vertes.

 

Quand on coupe la vidéo, les triangles gris sont les projections des lignes vertes et les lignes grises sont les projections de points verts :

ça aide au tuning de l'algo, à voir les superpositions de lignes ou de points par dessus des lignes (canaux alpha qui s’additionnent, truc purement visuel) .

Ben aucune technique de SLAM ne fonctionne hors portée du lidar:) enfin ça s'appelle de l’odométrie oui lol

d'ailleurs avec une odometrie correcte quand le robot retrouve des obstacles si il est dans la tolérance il se raccroche a la localisation nickel

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.

Alors Seb ça avance ? (je lui ai envoyé un SMS)

 

Optocouplage / filtrage d'alim à gogo obligatoire sur les I/O la dessus vu les parasites HV

 

Edit : je l'ai eu au tel il attend son Arduino:)

Hop! Nouvelles vidéos de la suite du développement du projet.

Test des fonctions multi-robots :


Demo visuelle de l'algorithme de cartographie et localisation simultanées (SLAM) :



Next : inscriptions sur vigibot.com qui permettra a n'importe qui de jouer avec des robots

Next2 : le tuto pour installer le client de cloud sur raspberry pi afin d'y connecter son robot avec le minimum de choses a faire ou à acheter = une PI, 2 servomoteurs et une PIcam

Les liaisons data/video sont compatibles avec du RAW UDP ou de la radio VHF/UHF brute sans correcteur d'erreur (moyennant l'ajout d'un CRC16 sur chaque trames). Pour dire c'est plus léger que Mavlink mais plus rigide. En gros c'est de la trame de télécommande de modelisme de taille fixe et optimisée pour la fluidité

La data est compatible avec des débits de quelques kilobauds et la vidéo H.264 est possible a partir de quelques centaines de kbauds en dégradant la qualité à mort.

Le son PCM a aurait besoin d'un codec mais existe avant tout pour la légèreté à l'encodage sur PI Zero et à la lecture ultra compatible côté client javascript.

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