245 réponses à ce sujet

[Jan]

le travail que tu as réalisé est énorme ! si tu es seul là dessus félicitations !  En plus ton site est valide W3C juste histoire de mettre la petite cerise sur le gâteau...

[Mike118]

 

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

 

 

Donc l'affichage des données lidar, et la boite jaune qu'on voit sur la vidéo tu le fais côté serveur ? 

 

le travail que tu as réalisé est énorme ! si tu es seul là dessus félicitations !  En plus ton site est valide W3C juste histoire de mettre la petite cerise sur le gâteau... 

 

 

 je trouve moi aussi que le travail réalisé est énorme

 

[Serveurperso]

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 !

[Serveurperso]

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

[Path]

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

 

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

[Mike118]

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é !

 

[Serveurperso]

 

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 ?

[Serveurperso]

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.

[Serveurperso]

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 !!

[Mike118]

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 !!

 

 

 

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"

etc...

 

En effet je reconnais toute l'utilité  =) 

Bon du coup la partie robot ça va je maîtrise, il me reste à maîtriser la partie côté serveur ... gloups ! x) 

 

[Serveurperso]

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.

[Serveurperso]

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!!!!

[Serveurperso]

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

[Mike118]

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 ? 

[Path]

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.

[Serveurperso]

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)

[Serveurperso]

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

[Mike118]

Je tique sur 

 

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

 

 

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

 

 

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  

[Path]

Moi je suis fan !!

[Serveurperso]

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