Actuellement j'ai une paire de modems à MODULATION LoRa (PSK) ça fonctionne sans problème pour la télécommande vu que c'est du simple TDD (time division du duplex) mais j'imagine que ça ne respecte pas la spec du LoRa en rapport cyclique. 9600 bauds c'est a l'aise si je réduit le nombre de points lidar envoyés par trames alors sur un robot basique sans lidar 1200 bauds no problemo.Je me suis efforcer a garder le contrôle en mode télécommande de modelisme et une télécommande de modelisme c'est plutôt du débit Minitel que du 56K lol
Par contre la vidéo c'est une autre affaire

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.

Le HSDPA tombe à 1.8Mbps de download pour un utilisateur qui pilote un robot c'est OK mais si pas en déplacement rapide (transports / voiture).

 

Pour le pilotage des robots un download de 1Mbps c'est le strict minimum pour que ça fonctionne en rognant toutes les marges avec la qualité actuelle et le son basse latence.

 

Pour la connexion d'un robot lui même c'est du 1Mbps d'upload qu'il, faut mais extrêmement stable (ADSL2+).

Ce qui signifie 4G préférable car la 3G+ sera limite car l'upload tombe souvent sous les 1Mbps,

Et si la liaison robot -> serveur prend du retard c'est tout les utilisateur qui le subissent.

Suite à non respect des consignes, Gamepigeek (Pierre) ici présent n'est plus admis sur mon serveur de développement !

 

Il n'aura pas tenu jusqu'au premier robot lol

 

Sinon sur le serveur de prod l'identification et le contrôle d'accès se fera par compte avec email valide, le truc classique quoi.

En plus le premier vigibot sera un robot open-source, avec une simple raspberry pi et des servomoteurs. il y aura aussi la version raspberry pi + arduino pour pouvoir bidouiller d'avantage

Un point suffisamment remarquable qui mérite un post supplémentaire sur les batteries :

 

Il faut se taper 4 VIS pour ouvrir le robot en deux pour sortir très très difficilement les batteries (super chiant moi qui aime pas rayer le cul et l'isolant des accus que je prend neuf pour chaque appareils) afin de recharger...

 

Bref a l'heure de l'objet connecté H.24 pour moi c'est un gros fail.

Ben oui j'ai bien aimé sur le coup, j'ai oublié de parler de l'alim :

 

Ce sont des 14500 des Lithium plus petites que les 18650 (forcément lol) qui font la taille des classiques R6 ou AA.

Une entrée USB câblée sur un USB to serial TTL avec alimentation 5V utilisable afin de ne pas pomper les accus, pas de reboot à la bascule batterie/alim USB.

On dispose donc de 2 cellules 600/750mA en série pour faire du 7.2V puis d'un step down pour fournir le 5V à la PI.

En série ce qui est une grosse connerie car inexploitable pour une base de recharge DIY, une mise en parallèle était préférable malgré le rendement légèrement plus faible d'un step up (et encore) qui aurait permis une charge USB DIY en toute sécurité sans adjonction d'un module BMS pour l'équilibrage.

 

Le socle double-14500 est juste, et il est difficile de faire rentrer la version protected des 14500 (accus avec PCB de sécurité sous/sur voltage)

 

Donc je répète pas de gestion de batterie : ni coupure tension minimum ni chargeur intégré... ni possibilité simple d'ajout DIY de base de recharge.

 

J'ai pas vu si ils avaient eu l'intelligence de câbler un analog input pour surveiller la tension... mais j'ai des doutes

 

Il y a un neopixel à quelques diodes RGB intégré (pas testé) une série de capteurs pour un suiveur de lignes, 2 capteurs d'obstacles tout-ou-rien à l'avant...

 

Enfin voila quoi... Vaux mieux le faire sois même. On va en design de biens mieux avec Mike, ou il sera facile de se positionner sur un chargeur, à induction ou pas. La base de recharge à distance, c'est la base en robotique. Surtout pour notre système de "robot casting".

 

Pascal

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

 

Hop encore un boulot de terminé : j'ai refactoré le code de la gestion clavier PC sur le client afin d'ajouter les touches fléchées.

 

Maintenant il suffit d'utiliser les touches fléchées pour piloter le robot, l’appuie et le relâchement multi touche du clavier est pris en compte sans latence exactement comme dans un jeu vidéo.

 

J'ai mis avant arrière tourner gauche droite sur les flèches, et le staffe "Suppr" et "Page down".

 

Si un jours je modifie le code du robot pour avoir la rotation du corps (Theta) à l'aide du X de la souris, le pilotage serait 100% identique à celui des gamers PC clavier-souris (mais avec le straff aux fleches droite-gauche du coup).

 

Reste le mode vidéo plein écran:D

C'est possible de rentrer les plans d'une map à la main ? Ou à partir d'un plan jpeg et d'une échelle ?

Tu scanes les plans d'un bâtiment et le robot se débrouille! Pour des missions dans des zones à risque

Alors du coup oui complètement vu qu'actuellement il suffit de lui donner un point de départ et des plans perpendiculaires les uns aux autres.

Avec Mike on est en passe de faire du SLAM orthogonal complet c'est à dire que le robot sera capable de se localiser et de construire sa carte simultanément et tout seul avec pour seule limitation un immeuble construit avec un certain nombre de murs ou repères perpendiculaires les uns aux autres ce qui est majoritairement le cas dans les intérieurs actuels

Après je doit porter les mathématiques côté Linux ce qui va nous permettre de faire évoluer l’algorithme de SLAM maison pour qu'il se repère avec n'importe quel type d'obstacle car on aura créé un framework en C méga optimisé capable de fonctionner sur une puce 80MHz.

La particularité de notre algo c'est qu'il est 100% vectoriel et n'a pas besoin de carte type bitmap / grille d'occupation pour fonctionner.

J'ai eu une micro misère pour lancer un binaire "pic32-gcc" qui est compilé pour du ARMEL (sans support de calculs virgule flottante hardware)

 

En fait il faut observer son binaire avec l'utilitaire SUPER PRATIQUE "file" souvent négligé :

 

(root|~/.uecide/compilers/pic32-tools/bin) file pic32-gcc
pic32-gcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, stripped
 

Or que si j'observe un binaire à la con d'origine :

 

(root|/lib) file /bin/more
/bin/more: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=60c21f8546cd76867c06d91364ffbfc4190cb9d3, stripped

 

Hop Bingo, dans mon /lib le seul ld-linux que j'ai est "ld-linux-armhf.so.3" et pas "ld-linux.so.3" j'ai donc fait un lien symbolique avec :

ln -s ld-linux-armhf.so.3 ld-linux.so.3

et hop

ld-linux.so.3 -> ld-linux-armhf.so.3

 

Il s'agit de l'éditeur de lien dynamique qui est propre à une architecture.

Maintenant je peux lancer mes compilations PIC32 onboard sur la XU4Q comme avec la PI mais en mode tuuuuurboooooooooooo

Voila c'est fini

https://www.serveurp...com/?page=robot

Cliquer sur "Ptibot" et bouger la caméra pour le voir fonctionner.

 

En quelques heures j'ai refait l'OS et porté l'application PI -> ODROID

L'audio est maintenant nickel, et la vidéo top fluide (car la PI avais vraiment du mal à tenir le 100Mo/sec sur l'USB) et latence au niveau d'une raspberry+PIcam

Sauf que la j'encode le H.264 logiciellement -> futur évolution voir si je peux utiliser le GPU pour encore réduire la conso.

En parlant de conso je ne visualise pas d'augmentation par rapport a la PI

C'est toujours la même chose avec plus ou moins de puissance et plus ou moins de périphérique et I/O et plus ou moins de communauté donc de support technique. Les gens ont peur de changer mais Linux reste Linux et un microcontrôleur reste un microcontrôleur.

 

En vrac :

 

Avec la ODROID adieu le Wi-Fi intégré, adieu le DAC (sortie son, ya un port I2S inutilisé), un port USB de moins mais :

 

Bonjour l'USB3 et le Gigabit Ethernet (pas utile sur mon projet)

Bonjour la puissance supplémentaire, facteur entre 5 et 10 versus une PI3

La XU4Q dispose d'un port microSD avec un interrupteur qui permet de passer sur un port eMMC, une petite carte avec une puce flash pour avoir de meilleurs perfs en I/O système de fichier... j'ai pris une 16Go ça coute dans les 40 euros je crois, plus cher qu'une microSD mais conçu pour être plus solide dans le temps.

 

Les connectique sont sur les 2 longs côté donc c'est chiant par rapport à la PI qui sort en ligne mais c'est un détail suffit de réorganiser l'espace sur le robot...

 

Niveau logiciel j'utilise que des distribs minimalistes du genre Debian Netinstall, et ce partout, aussi bien sur PC que sur mes cartes headless (sans écrans)

J'ai claqué la distrib ARMBIAN sur la puce eMMC à l'aide d'un adaptateur compatible microSD vendu sur le site de hardkernel et d'autres.

ça boot, le service SSH est déjà prêt suffit de brancher sur le réseau et retrouver l'IP DHCP.

 

Direct je fait mon git init dans /etc (git et build-essencial sont déjà préinstallés) pour suivre et avoir l'historique de commits en commits des moindres modifications de confs par moi ou les MAJ de paquets.

 

apt-get update/upgrade, un seul paquet à MAJ c'est bien maintenu ! la commande armbian-setup permet de configurer les params régionaux (locales) et le réseau en 2 secondes.

 

J'ai claqué nodejs et c'est partit, le tout en moins d'une heure

Et la je suis sur une remise en question de la Raspberry PI (3 / 3+) que je vais garder exclusivement pour usage avec RaspiCam et pas pour faire de l'acquisition en RAW sur port USB car je suis a la limite au niveau perf et impossible d'obtenir l'audio USB correctement avec la vidéo YUV qui tire à plus de 100Mo/sec.

 

Un mini robot est en construction sans lidar, sans PID roues, 100% Raspberry PI, avec un pan&tilt à la tête !

 

Du coup j'ai commandé une ODROID XU4Q - la version fanless de la XU4 dont la partie aluminimum est bien trop faiblarde, je prefère ajouter un ventilo lent sur ma XU4Q car ça chauffe pas mal! mais c'est une petite bombe en performance elle sera dédiée au robots avec plus d'une seule caméra avec les mêmes performance et faible latence que le gros robot initial.

 

Conf logicielle validée & montage in progress sur "Ptibot", celui avec la pince et les 3 caméras.

La couche physique Dynamixels c'est du Serial TTL dont TX et RX sont mis en commun sur un seul fil.

 

Je peste contre les Dynamixels car 1 mégabaud sur du niveau TTL c'est pas fiable je baisse à 115K et du coup vu qu'ils ont fait un système HALF DUPLEX (partage des fils TX et RX) ça fait des collisions et des corruptions à gogo du coup je vire le monitoring et du coup je me retrouve avec de bêtes servomoteurs pilotables sans retour d'informations. Tout ça pour économiser un fil sur le bus les bandes de rats ! en même temps j'ai pas besoin du retour et ça fonctionne bien donc OK

 

En même temps c'est sûrement ma faute car je pilote en 3.3V directement depuis le microcontrôleur. Mais ils font chier d'avoir mis qu'un fil pour TX et RX

 

Le protocole est un protocole série tout bête les trames ressemblent à ceci :

 

(le map() c'est qu'on rentre la position avec des angles standardisés en 16 bits pour des maths integers ultra rapide)

void servosGoalPosition(uint8_t id, uint16_t angle16) {
 uint16_t n = map(angle16, DYNAMIXELANGLE16MIN, DYNAMIXELANGLE16MAX, DYNAMIXELMIN, DYNAMIXELMAX);
 uint8_t n1 = n & 0xFF;
 uint8_t n2 = n >> 8;
 uint8_t sum = ~(id + 0x05 + 0x04 + 0x1E + n1 + n2);

 TXSERVOS.write(0xFF);
 TXSERVOS.write(0xFF);
 TXSERVOS.write(id);
 TXSERVOS.write(0x05);
 TXSERVOS.write(0x04);
 TXSERVOS.write(0x1E);
 TXSERVOS.write(n1);
 TXSERVOS.write(n2);
 TXSERVOS.write(sum);
}

void servosAction() {
 TXSERVOS.write(0xFF);
 TXSERVOS.write(0xFF);
 TXSERVOS.write(0xFE);
 TXSERVOS.write(0x02);
 TXSERVOS.write(0x05);
 TXSERVOS.write(0xFA);
}

void servosTorque(uint8_t enable) {
 uint8_t sum = ~(0xFE + 0x05 + 0x03 + 0x18 + enable + enable);
 TXSERVOS.write(0xFF);
 TXSERVOS.write(0xFF);
 TXSERVOS.write(0xFE);
 TXSERVOS.write(0x05);
 TXSERVOS.write(0x03);
 TXSERVOS.write(0x18);
 TXSERVOS.write(enable);
 TXSERVOS.write(enable); // LED
 TXSERVOS.write(sum);
}

Sans oublier les technique de communication pour piloter le servo, avantage/inconvénient liés au servos donc pourquoi pas

Oui ici on parle de modèles de servomoteurs, performance / prix, des technologies des moteurs et de boucles d'asservissement

Justement c'est ce que j'ai mis dans mon pavé qui explique que c'est impossible, comment tu veux faire tourner un rotor bobiné sans noyau et sans collecteur avec un stator bobiné et piloté électroniquement ? mdrlolxd

En résumé besoin de mouvement rapide tout en gardant une conso correcte = coreless

Besoin d'une grande durée de vie = brushless

C'est différent, le Coreless privilégie le faible moment d'inertie et donc l'agilité et le rendement lors des changements de vitesse de rotation. et le Brushless la durée de vie et le rendement à couple constant.

 

Par opposition aux moteurs Cored classiques qui utilisent des aimants ferrites et un rotor bobiné, les deux types de moteurs utilisent des aimants permanents au néodyme fer bore (NdFeB) ce qu augmente de beaucoup leurs rapports taille puissance.

 

Le Bruless privilégie la durée de vie car il n'a pas de collecteur à balais ou charbons, pas de pièce d'usure hormis les roulements et le reste de l'assemblage du servomoteur (comme le potentiomètre qui s'use, or qu'un encodeur optique ou HAL n'aura pas ce pb);

 

La commutation électronique du Brushless augmente aussi son rendement qui sera donc supérieur au Coreless HORMIS les démarrages et changement de vitesse ou il se fera "explosé" par le Coreless.

 

La partie mobile du Brushless (rotor) est forcément la partie magnétique, vu que la partie bobinée (électro-aimants) doit être statique (le stator) pour être pilotée par de l’électronique, il sera plus lourd au démarrage qu'un Coreless dont le rotor est une bobine seule tenue par sa méthode d'enroulement spéciale et de la résine.

 

Après la puissance du brushless pourrait compenser sa lourdeur pour une bonne agilité mais il consommera forcément plus qu'un coreless si les changements de consigne sont violents et répétés (hexapod...).

Le Coreless c'est vraiment le top sur un servomoteur le rotor léger diminue le moment d'inertie et un servo coreless c'est souvent plus de 100 euros et réservé aux hauts de gamme

J'ai commandé des (2) Alphabot2 pour les webiser et les motoréducteurs n'ont pas d'encodeurs... boucle ouverte obligatoire en même temps vu les petits trucs ça ira surtout que la tête comporte un pan&tilt ce qui est le plus important pour regarder partout façon fluide avec le H.264

ça, c'est la base :

 

http://playground.arduino.cc/Code/SimpleTimer

 

Tu mets le run dans la boucle principal et tu peux exécuter des fonctions à intervalle précis.

Hello.

 

Euh ce ne sont pas les "for" et les "while" qui sont problématiques bien au contraire c'est obligatoire.

Ce qui compte c'est le temps d'exécution et donc le code que tu mets dedans et le nombre d'itérations VERSUS les performances que t'as besoin.

 

delay est ok au boot (fonction setup) mais des tout petits delais pour initialiser du hardware ça passe.

Après dans un contexte d'exécution normal devoir utiliser delay signifie code caca. A recoder avec utilisation du timer (millis...) et des machines d'états = switch case case case...