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.

Oui c'est très évolutif, je pense ajouter une géolocalisation d’intérieur en ultra large bande (UWB) car je trouve que les algos SLAM avec ce genre de lidars relativement abordables sont expérimentaux et usines à gaz (faut ROS), lents et peut fiables (j'aime le genre zéro bug en H24/7) d'ou le code C sur PIC32 sans OS....

Non ça me dérange pas car c'est sous mon contrôle et y a pas beaucoup de visites souvent des potes ou des réguliers que je connais depuis un bye. c'est surtout des bonnes rigolades et une sorte de truc "vivant" que je peux désactiver en 1 clic au besoin.

Oui pour les caméras, analogique CCD PAL. Pour des raisons de liaison radio longue portée (je joue parfois dans mon parking avec 5/6 murs en béton armé à traverser) et la résolution faible permet un straming fluide dans le canal node.js

J'aimerais aussi ajouter une zone de script sur la page (avec un bouton upload) permettant de balancer une séquence de commandes simples que le robot exécutera de lui même en toute autonomie comme :

Avancer de 50cm

Tourner de 45 degrés

Avancer à 50cm de l'obstacle

S'aligner à l'obstacle de droite : Ramer-Douglas-Peucker embarqué fonctionnel mais j'ai une difficulté pour lui faire fermer le cercle et en cas d'obstacle sur le robot, donc reste du taf.

ça pourrait permettre de lui faire faire des missions complexes en boucle sans se décaler, sans localisation indoor et sans faire de SLAM !

- Lui ajouter un bras avec capteur de pression sur la pince et lui dire de pincer avec puissance asservie (bras pilotable par exemple en X-Y commutable en X-Z à la souris / au tactile)

etc. etc... ya tellement de choses à faire

...

Hannn Yo Pascal !! Trop bon ça 113.gif J'adore !! Avec du nodeJS dedans en plus !! Félicitations.

Mais viens plus souvent

lol, du NodeJS avec Apache en front, reverse proxy websocket, multiplexé, comme ça toutes les instances de serveurs node (dont celle du robot) passe par le port 80 (ou 443) top moumoute comme la moquette sur laquelle le robot roule !!! et node ne sert que du contenu websocket (socket.io) pas de statique

scanner 3d ? ou ça c'est un scanner 2D - Un "télémètre à balayage laser 2D par triangulation" lol - : le RPLIDAR v2

J'aime bien Bender (Futurama) moi mdr

Oui il est possible de simplifier. (c'est pas un tuto lol)

Dans mon robot je n'ai aucun OS, c'est uniquement un PIC32, du C codé par moi (et l'équipe qui développe le portage du CORE Arduino pour PIC32), et du hardware !!! Pas d'OS + code très maitrisé = pas de plantage !!!

Je te recommande de commencer en full numérique WiFi et PI car tu peux gérer le robot + la vidéo.

Je te recommande aussi d'associer la PI et un Arduino mega si possible pour être au top niveau I/O et UART (serial ports TTL) mais pour un ptit robot basique pas besoin !!!

Un serveur NodeJS sur ta PI, une IP fixe ou un DDNS gratos MAJ par ton boitier qui fait le routage - ou ta box - j'ai aperçu un thread node sur PI ici, du modérateur ci dessus.

Un logiciel serveur en Node, du coup ce sera ton robot le serveur IP, moi j'ai un intermédiaire, serveurperso.com qui synthétise les commandes des multiples visiteurs en trames radio régulières (TDD).

Un logiciel client en JavaScript (dans du HTML5, perso je fais du XHTML5 en fait car très pedantic lol)

Une liaison de données entre ton serveur et le robot -> IP via WiFi pour simplifier -> moi ce sont des radiomodem UHF à bande assez étroite

Une liaison vidéo entre ta caméra et ton serveur -> IP car ta PI génère facilement du MJEG, documente toi sur MJPG-Streamer (version patchée PI cam) c'est une tuerie -> moi c'est de la vidéo analogique avec un poste de réception développé maison, donc acquisition USB qui ajoute un pico poil de latence par rapport a du numérique de bout en bout d'ailleurs (surtout si numérique sans compression temporelle, le MJPEG étant une compression image a image, uniquement spatiale).

moi j'ai fait :

COMMANDE & Telemetrie : visiteur <-> IP <-> serveur <-> modems UHF <-> PIC32 du robot

VIDEO (attention c compliqué) : robot -> TX analogique PAL -> RX analogique maison (usine à gaz a lui tout seul) -> Clé USB acquisition vidéo sur le serveur -> /dev/video hardware -> ffmpeg pour déinterlace -> /dev/video virtuel -> MJPEG streamer -> Code NodeJS (et la je résume a fond) -> Client.

Je te propose

COMMANDE & télémétrie : visiteur -> IP -> serveur Node dans ton robot -> I/O de la PI attaqués direct en Node (ou une étape suplémentaire avec SERIAL PORT si tu veux un arduino intermédiaire pour avoir masse d'I/O)

VIDEO : Raspicam -> MJPEG_Streamer -> tu balances direct le flux dans Firefox ça fonctionne ! mais t'auras de la latence sauf si comme moi tu codes le client vidéo MJPEG javascript !

C'est long de tout expliquer:s il me faut des questions précise.

Par exemple pour la liaison vidéo entre le serveur node et le client je décode le MJPEG que je stock image à image dans une variable globale de NodeJS et que mon client JavaScript récupère, encodée en base64 et affiche dans une balise IMG d'un élément CANVAS (je crois que j'ai pas sauté d'étapes)

Je peux te filer des sous systèmes mais à toi d'adapter ou poser des questions précise

une PI va être limite pour la partie vidéo si elle passe par NodeJS je pense... même une 3, pour du PAL du 720 576 alors avec la PI cam si utilisée en HD les FPS c'est mort.

Ou alors faut faire du simple push de JPEG, voila la soluce la plus simple. direct de la PI cam au client sans passer par Node. simplifions comme une bête cam sur IP

Non, absolument aucune PI sur ce projet.

(Même si j'ai 5 PI qui tournent chez moi 24/7, les webcam du site, de l'imprimante 3D entre autres)

Le robot tourne avec un PIC32MX 80MHz "ChipKitifié" c'est à dire "Arduinoifié". Tout comme un ARM "Arduinoifié" donne un Arduino Due...

Un PIC32 et du code C non bloquant ça donne puissance monumentale pour gérer un robot.

J'utilise les 4 UART avec un gros FIFO, je doit utiliser entre 5 et 10% de la puissance du PIC32, avec l'odométrie omnidirectionnelle, la lecture du LIDAR + la conversion polaire cartésien et l'anti colision avec sa logique floue (sans lib fuzzy / optimisée), l'asservissement PID des 4 moteurs (idem sans lib, code arithmétique integer maison, faire de la boucle ouverte pour les moteurs d'un robot c'est caca), la génération des PWM full hardware du PIC32...

Le robot ne fait rien au niveau vidéo, c'est juste comme de la CCTV, un transmetteur vidéo analogique, sauf le multiplexeur analogique pour changer de cam, c'est aussi le PIC32 qui le pilote (4 bits = 16 caméras possibles)

Tout en integer sauf les maths de l'odométrie et du LIDAR. (le PIC32 éclate le Cortex M3 en float)

Jamais de delay() (ou toute fonctions similaires) dans du code. Jamais. Amen. Toujours faire des machines à état. Vive switch/case...

Un simple Arduino mega 8 bit à assez de puissance pour faire la même chose, (quite à faire une lookup tables de sinus et la trigo en integer c'est tout)

Softserial parce qu'on manque de port et qu'on utilise un Arduino classique avec un seul UART, idem que delay() -> poubelle.

lol

J'ajoute même qu'utiliser les I/O de la PI pour lire écrire des capteurs ou pire générer du PWM c'est crado (sauf si ya un module hard, j'ai pas vérifié).

Il faut n'utiliser que l'UART de la PI, le /dev/serial sous Linux, et commander un arduino, avec un petit protocole maison, et du bon code bas niveau pour exploiter les moteurs, capteurs & co du robot.

Le PID dans l'Arduino bien entendu. On ne fait rien de temps réel ou de génération de signaux avec Linux c'est pas fait pour c'est du bricolage.

Fonctionnement écrit à l'arrache :

- Quand un client fait un drag sur l'image du site, à chaque event de mousemove le javascript balance les coordonnées relatives au serveur NodeJS.

- Le serveur NodeJS récupère les events de tout les clients et les intègrent à un X Y global.

- Ce X Y global est injecté dans des trames qui sont envoyées à intervalle réguliers sur un /dev/serial.

- Un modem radio UHF (codé par moi, un fork du firmware SiK que j'ai mis sur GitHub) récupère les trames via son UART et les balancent à la radio.

- Sur le robot une radio récupère les trames et rempli l'UART de l'Arduino PIC32.

- Une machine d'état dans la loop() vérifie si ya un octet dans l'UART, si oui il le récupère dans un buffer. (idem pour toute la trame).

- Le robot dispose de plusieurs fonctions non bloquantes comme le PID, l'odométrie (qui est envoyée dans la trame retour télémétrie:)

- Dans le robot la trame reçue ressemble à [ $R | Souris X 16 bits | Y 16 bits | Selecteur de cam | Velocity X | Y | Theta | Flags pour commander des I/O ]

- Chaque trame est redondante avec la précédente, 10% des trames suffisent à piloter le robot (comme un drone ou n'importe quelle RC en gros)

- Quand le robot reçoit une trame il répond par une trame de télémétrie, si y fait dodo il se réveille. Si y'en a pas depuis N secondes bah dodo veille:)

- Le serveur NodeJS dispose donc de la télémétrie et la balance aussi aux clients (socket.io broadcast), et le JavaScript se charge de l'affichage...

*Il est donc possible de zapper l'étape radio, d'embarquer la PI direct sur le robot... de balancer via /dev/serial à un Arduino, et au final faire le même genre de robot que le mien.*

donc si je résume : 

 

Pour la vidéo : 

Robot et N camera => Multiplexeur piloté par le PIC 32 => émetteur analogique type RC sans fil  ....  Récepteur analogique => Décodeur ?? Fait maison qui sort en USB => Serveur    

Au passage j'en déduis qu'en sortie du multiplexeur analogique tu rajoutes directement sur l'image les différentes information lidar et autre ... 

 

 

 pour les commandes et les retours de capteurs : 

Serveur <=> USB to UART émetteur récepteur   <.....>  Emetteur Récepteur UART <=> PIC 32  sur le robot ,     

 

 

ai-je bien résumé ? 

J'étais en train d'écrire le post au dessus qui répond lol.

Mais : pas de données dans la vidéo analogique.

La liaison radio numérique est bi-directionnelle. C'est du Half Duplex ou plus exactement du TDD pour Time Division Duplexing (et donc du TDM pour Time Division Multiplexing avec seulement 2 interlocuteurs)

Pour expliquer le principe NodeJS fait un setInterval() à 20Hz ce qui laisse le temps d'un échange avec le robot, qui répond immédiatement à la trame de commande par une trame de télémétrie. ça ping-pong en permanence.

Exact donc.

oui c'est 100% perso d'ou le nom serveurperso.com c'est mon joujou

Le serveur et le client disposent uniquement de la télémétrie qui comporte en vrac :

Différentes mesures de supervision comme Tension batterie, PWM MAX = rapport cyclique maximum pour la roue du robot qui force le plus, Erreur MAX = la roue du robot qui est le plus en retard sur la consigne de velocité (se produit quand le PWM à 100% ne suffit pas à bouffer l'erreur) l'alerte "erreur maximum atteinte" se produit à 10 degrés de retard sur une roue, et la un anti windup intégral fait "patiner" virtuellement la roue par rapport à la consigne:D

Lidar = le volume de données "Lidariennes" dans la trame après compression, X/Y 16 bits en mm.

L'Odométrie du robot, X, Y Theta sur 16 bits en mm et degrés fixed point Q4 et Q6 lol:)

RSSI = Indicateur de niveau de signal reçu pour le serveur et le robot, avec la quantité de bruis (= une simple mesure de RSSI en absence de porteuse radio)

Il n'y a que 1000 lignes de C sur le robot des lignes courtes et lisibles en tout avec les libs !

Donc quand tu as cette trame côté serveur tu peux faire des logs côté serveur et la broadcaster à tout les clients

Les client s'occupe d'un affichage cool avec de la trigo à gogo maniaquement optimisée (mais pas integer comme je fais sur un Arduin 8 bits faut pas pousser).

 

J'aime !!

 

Dis, NodeJS, il tourne pas sur un PIC. Je suis  sûr qu'on comprendrait mieux ton système si tu nous faisais un schéma

Nan mais c'est trop simple.

ROBOT = PIC32 et c'est tout, si on oublie le Si1000 de la radio qui comporte un 8025 8 bits je crois.

Serveurperso.com = le serveur NodeJS qui crache dans /dev/serial pour le modem 8025 8 bits.

Le visiteur et son JavaScript qui papote en Socket.IO à Node.js au travers d'Apache hihi

Sans parler de la partie vidéo est est aussi un PIC32 mais tout seul dans son coin branché sur un /dev/video via USB.

Voila tout simple non ?

Le LIDAR est utilisé pour " éviter les obstacles " mais cela se fait directement sur le robot non ? 
Genre le robot reçoit " va à gauche "  mais il refuse de se déplacer à gauche quand le LIDAR indique qu'il y a un obstacle à gauche , c'est bien ça ? 
( Par opposition au fait de : voir côté serveur que si  l'utilisateur derrière son PC demande d'aller à gauche on va voir si il y a un obstacle à gauche dans les trames lidar , et par conséquent on décide d'envoyer ou pas la consigne ) 

Ainsi mis a part de permettre d'afficher les données LIDAR, sur le flux vidéo ( et éventuellement les loger ? ) tu projettes d'utiliser les données LIDAR pour quelque chose non ? Par ce que sinon utiliser un OSD permettrait d'optimiser la chose non ?  

En tout cas je suis fan du travail réalisé !

 

100% EXACT.

Et oui le par opposition est Caca:)

Un OSD c'est tout moche ça bave et ça bouffe de la FAIBLE résolution vidéo.

Ya déjà la liaison UHF bi-directionnelle donc vive l'incrustation côté client.

Rien ne m'empeche de faire une groundstation embedded avec un PIC32 qui pilote un affichage OSD aussi.

Les données LIDAR servent a faire un anti collision quasi infaillible intégré au robot et ça c'est déjà moumoute. A pleine vitesse il commence à freiner à 50cm de l'obstacle sans qu'on s'en rende compte:) ce sont simplement des clamps de vélocité proportionnels à la distance.

Par contre j'ai une branche de dev avec un algo Ramer-Douglas-Peucker et donc ça va servir à envoyer des commandes plus puissantes au robot, du genre "Aligne toi bien nickel à 10cm du mur qui se trouve devant toi"

je parle toujours du firmware PIC32 du robot la.

Puis aussi si tu cliques sur la ligne de texte SOUS la vidéo, ça arrête le streaming vidéo, et donc avec une bande passante toute moisie tu pilotes le robot au LIDAR, c'est t'y pas beau ?

Ah tiens faut que j'ajoute une commande de coupure de tout le matos RF-vidéo sur le robot.

Mode pilotage live d'un robot à quelques Kbps de bande passante et 300mA de conso !!

oops j'édit comme un goret...

côté serveur c'est du javascript aussi.

tu peux remarquer dans le log que parfois des actions semble faites par des visiteurs déjà déconnectés, ce sont en fait les propriétaire d'une instance utilisée par tout le monde.

Du genre c'est le visiteur qui réveil le robot qui l'endormiras aussi, même si il est déjà partit depuis 5 minutes par exemple.

le serveur du robot c'est un seul script de quelques pages, c'est juste un proxy séquenceur qui fait la synthèse des clients (intégration)

le plus complexe c'est la gestion de la vidéo, entrée et sortie de veille

Démarrage et arrêt des processus consommateurs mono instance mais qui bouffent masse CPU sur le serveur.

tout est fait façon "never trust the client" (sécurité)

Le robot aussi never trust le server !!! vu que la liaison radio est non chiffrée, d'ailleurs ce ne serait pas du tout compliqué a faire!!!!

le serveur tout est fait à base de callback de setInterval ou de setTimeout.

Genre t'as un user qui balance un ordre.

si ton interval ne fonctionne pas déjà alors tu le démarre.

dedans tu balances des trames au robot

après un certain temps sans ordre tu l'arrêtes.

etc...

attention si c'est pas hyper bien réfléchi ça termine en spaghetti intellectuel !!!! une fonction de trace est très importante pour bosser.

mate mon log https://www.serveurp...om/robotlog.txt c'est ce qui s'affiche en live en dessous. très pratique pour debug

Oui sympas le log =) 

 

dedans je peux même lire que tu utilise des dynamixel ^^ 

Des AX12 je suppose, Pour le pan et tilt de la caméra  non ? =)  

Et au passage quels sont les caméra que tu utilise ? J'ai essayé de tourner la caméra pour mieux la voir avec les autre caméra, mais j'ai eu du mal à la distinguer ^^ 

 

et pour finir le convertisseur analogique USB pour les caméra tu la fait toi même c'est bien ça ? ou bien est ce que j'ai mal compris ? Les truc tout fait du commerce ne t'allaient ? Parce que trop de latence ? Problème pour être reconnu ? Autre ? 

Oui des Dyamixels AX12 pour le pan & tilt, la tourelle avec 3 des caméras, je n'utilise la liaison que dans un seul sens (microcontrôleur vers AX12, begin(1000000); c'est tout) pas besoin de lire le bus dynamixels donc pas de 74LS241. J'ai juste deux toute petite fonction void goalPosition(uint8_t id, uint16_t n) et void action(). et les servos se positionnent au top (quoi que ça trop d'overshoot, j'aimerais bien un firmware mieux que ça, ou les hacker et faire mon code) mais ça suffit.

Ce sont les tout petits PCB des caméras "RunCam" de 2 et quelques cm sur 2 et quelques cm avec un capteur CCD 1/3 de pouce Sony Super HAD2. Je trouve que c'est le meilleur utilisé par RunCam. La moins cher et aussi la meilleure car les autres sont en CMOS et je suis pas fan du CMOS pour les caméras analogique. Il existe des centaines de cam de ce type avec ce capteur mais le soft de celles ci est au top niveau config et les couleurs sont améliorées par rapport aux autres caméras PAL qu'on trouve car ils utilise une pré accentuation optimisée et non standard.

Vu que la société n'est pas capable d'avoir un stock uniforme au niveau des boitiers (les couleurs de peinture change, la sérigraphie change, aléatoirement selon la caméra) j'ai pesté et viré les boitiers d'origine puis j'ai 3D Print mes propres boitiers en noir, et paf ça fait une caméra cubique trop pratique à placer partout sur un robot. J'ai aussi mis mes propres objectifs (les wide angle) trouvé après plusieurs achats / comparaison d'ouvertures / qualité.

Caméras -> multiplexeur commandé par le PIC32 -> TX Lawmate 1.2/1.3GHz 1 watt (c'est le meilleur TX vidéo du marché à aprox. 100 euros) -> ondes radio -> mon système de réception analogique qui fonctionnellement fait le même boulot d'un récepteur d'origine -> clé USB de capture vidéo -> PC serveur web serveurperso.com -> pfSense -> fibre Orange pro -> toi

Rien de spécial mis à part que j'ai mis du temps à trouver le bon dongle USB de capture vidéo qui est a la fois reconnu par Debian sans rien modifier et a la fois ne crash pas quand les signaux PAL sont déformés par la liaison radio analogique. Et que mon récepteur est une usine à gaz avec 8 antennes en diversity c'est pour ça que l'image ne "saute" pas souvent (et ça crache 1W à côté, et les préamplificateurs du récepteur sont débranchés ça fait des atténuateurs de 30db donc liaison vidéo quasi filaire lol, en l'état le système est sous exploité, sauf quand je met le robot au sous sol).

Tout à fait d'accord entre le spaghetti et callback mais j'ai toujours du mal à comprendre le système que tu prends la peine de présenter. T'as pas un petit schéma ? Je suis sur que le travail qu'il représente mérite une meilleure présentation.

Je n'ai pas fait de doc. Zero doc, je suis tellement maniaque sur la doc quand j'en fait au boulot que la ça me prendrais un temps de ouf pour faire des docs d'architecture du serveur + robot qui me plaisent (et flemme, chez moi je fais juste ce qui m'amuse lol).

T'as pas compris quoi ? C'est tout con. T'as un appliance firewall un serveur une radio sur un port USB vu comme un port COM virtuel, que NodeJS crache des trames dedans. Et que pour la vidéo c'est séparé t'as un dongle USB qui fait un périphérique, que NodeJS lit dedans (même si ça passe par d'autres trucs avant)

Je vous fais un schémas brouillon de l'architecture physique et fonctionnelle lol

Attention ça pique les yeux ! Mais voila, ça synthétise bien :

Je tique sur 

 

Du coup j'ai deux questions :
1) Quelle est la fameurse clé usb de capture vidéo que tu as retenu
2) L'avantage de ton récepteur " usine à gaz" c'est la portée ? Est ce qu'il est reproductible ?  

Je commence sérieusement à songer à faire un système similaire avec une autre plateforme robotique ! =) 
Donc je sens que je vais avoir beaucoup de questions sur la partie serveur ... 

En charge de revanche si je peux t'aider hésite pas ^^ !  Sur la partie recharge du robot par exemple ... ou autre ... Mais je ne vois pas bien quoi car tu as l'air de bien maîtriser tous tes sujets

Tu tiques lol. C'est un récepteur vidéo ultra sensible qui coute quelques milliers d'euros à reproduire à l'identique. A la base prévu pour faire du drone illégal en zone difficile tout en gardant un petit TX à bas prix sur le drone (100€). Je ne partage pas sa conception pour éviter que ceux qui bossent avec des drones squattent encore plus la bande radioamateur pour faire du FPV...

Pour un robot roulant la liaison radio encore plus malmené qu'avec de l'aérien du coup c'est un usage idéal:)

Avec deux récepteurs comtech modifiés (filtre saw, ça se vent déjà pré modifié parfois) et un oracle diversity tu peux obtenir un truc pas trop mal. Il faut une licence radioamateur pour jouer à TX de la vidéo sur 1280MHz en France ! Tu peux remplacer par du 5.8 mais la portée fait pitié et ça devient pas trop rentable par rapport à utiliser ton WiFi en full digital. T'auras pleins de sautes de l'image.

ça revient à parler de FPV tout ça...

Pour les questions sur le serveur OK:)

Pour la charge c'est quasi terminé. Reste qu'a faire un 3D print pour la base et le contact qui sera 2 bandes de cuivre l'une au dessus de l'autre, et des pogo sur le robot. Ou l'inverse, pogo sur l'embase et 2 bandes sur le robot. Toute l'electronique fonctionne déjà sauf que c'est une prise, d’ailleurs la batterie est à plat (coupure sécurité tension basse) je re-branche en rentrant vers 13/14H lol