14 réponses à ce sujet

[Fsociety]

Bonjour,

 

Je vais être amené prochainement a choisir des composants électroniques pour le contrôle de mon robot, cependant je ne m'y connais pas beaucoup, voir pas du tout en électronique.

 

Tout d'abord voici une liste de composants que mon robot va potentiellement avoir :

 

- Moteurs DC

- Servomoteurs (ou moteurs pas a pas).

- Capteurs distance ( Je ne connais pas encore quel type j’utiliserais mais c'est pour la détection d'obstacles).

- Caméra ( Pour de la reconnaissance faciale/objets).

- Capteur sonore ( Reconnaissance vocale)

- Potentiellement un micro pour que mon robot puisse dire deux trois mots

 

 

La liste peut évoluer en fonction de l'avancé du projet et si je souhaite rajouter des fonctionnalités a mon robot, mais globalement on peut dire que c'est une liste qui se rapproche beaucoup de la liste final de composants qui constitueront mon robot.

 

Voici donc mes questions :

 

Partie Actionneurs :

 

- D'abord je sais que pour contrôler mes moteurs,servomoteurs.. j'ai besoin d'un "driver motor" pour générer assez (amplifier) de courant, donc mis a part le voltage et le courant quel autres critères dois je prendre en compte pour le choix d'un "driver" ?

 

- Peut on contrôler a la fois un servomoteur et moteur DC avec le même "motor driver" ?

 

Partie Microcontrôleur :

 

- Dans un but d'apprendre a utiliser  ROS dans un vrai projet robotique, je cherche a savoir dans un premier temps quels sont les critères pour choisir un microcontrôleur  pour contrôler tout mon robot et dans un second temps quel microcontrôleur marcherait avec du ROS.

 

- Sur quels critères dois je choisir mon microcontrôleur ?

 

- Y'a t'il un lien entre le choix d'un microcontrôleur et l’utilisation de ROS ?

 

- Y'a t'il des cas ou on utilise plusieurs microcontrôleurs pour un même robot ? si oui pourquoi ?

 

 

 

 

Histoire d’être sur que ma façon de voir les choses est bonne, serait t'il possible d'avoir votre avis sur ca :

 

Pour moi, le robot fonctionne ainsi : le microcontrôleur est le composant sur lequel on va téléverser notre code, puis en fonction des données qu'il va recevoir a partir des capteurs il enverra un signal au "motor driver" qui lui par la suite se chargera de faire tourner le bon moteur/servomoteurs.

 

 

Merci et bon weekend !

 

 

 

[Mike118]

Partie actionneur : 

=> Pour choisir un driver de moteur cc le principe est assez simple tu regardes les caractéristiques du moteur que tu as choisis  voltage et ampérage et tu prends un driver de moteur qui est capable de suivre ... 

=> Un servomoteur contient déjà ses drivers, donc pas besoin d'ajouter un driver de moteur en plus pour les servomoteurs.

 

Partie microcontrôleur : 

 

Si tu veux utiliser ROS il te faut un " Ordinateur " et pas juste un " Microcontrôleur " . 

Tu peux prendre un raspberry pi par exemple  raspberry pi 4   ( Mieux vaut avoir un peu de puissance sous le capot pour faire tourner ROS ... )

Plus d'info sur la différence entre micro-contrôleur ( genre arduino ) et ordinateur ( genre raspberry pi )  normalement ça devrait répondre à pas mal de questions je pense. 

Hésite pas à reposer des questions si ça n'a pas suffit ! =)

[Sandro]

Pour compléter la réponse de Mike :

 

- Sur quels critères dois je choisir mon microcontrôleur ?

Tout d'abord, comme dit Mike, il faut différencier micro-controleur (type Arduino) et micro-ordinateur (type Raspberry pi)

 

Pour un micro-controleur, les principaux critères sont :

- la facilité d'utilisation

- la tension de fonctionnement (5V, 3.3V ou 1.8V en général), qui déterminent ce que tu peux y connecter directement

- le nombre de pins d'entrée/sortie et leurs types (combien de pins numériques, combien d'entrées analogiques, combien de PWMs, combiens de pins d'intéruption, combien de ports de commnication et lesquels (I2C, UART, SPI, US, CAN, ...)

- la puissance de calcul

- la mémoire (RAM et flash)

 

En pratique, si tu débutes, je te conseilles un Arduino Uno ou un Arduino Mega si tu as beaucoup de choses à connecter. En soit, c'est loin d'être le mieux en termes rapport performance/prix, mais les Arduinos sont très faciles à utiliser, très bien documentés, et ont une très grosse communauté (tu trouvera plein de monde sur ce forum par exemple qui pourra t'aider si tu as un problème dans ton code Arduino ; si tu prends un STM32 par exemple à la place, tu aura probablement bien plus de capacités à prix égal, mais c'est beaucoup plus dur à prendre en main, et je ne sais pas si tu trouvera quelqu'un sur ce forum qui pourra t'aider).

Une fois que tu sera à l'aise en général avec les Arduinos, si tu as des besoins spécifiques, il sera toujours temps de chercher un microcontroleur qui correspond exactement à ton cahier des charges

 

 

- Y'a t'il un lien entre le choix d'un microcontrôleur et l’utilisation de ROS ?

Sur un micro-controleur, tu vas probablement manquer de puissance pour faire tourner ROS, et j'ai de gros doutes que tu trouves des binaires pour l'installer (peut-être qu'il y a moyen de compiler depuis les sources sur certains gros microcontroleurs). En gros, ROS, c'est prévu pour tourner sur un (micro) ordinateur sous linux. Le choix classique en robotique amateur est le Raspberry Pi (là encore, une grosse communoté et pas mal de documentations), mais si besoin, tu peux aussi utiliser quelque chose de plus puissant (par exemple un Odroid, voir encore bien plus puissant si tu en as le besoin et le budget (au travail, on utilise une Jetson Xavier : 8 coeurs, GPU 512 coeurs, 32Go de RAM ... mais 750€)). Pour commencer, un raspberry Pi 4 est je pense un bon choix.

 

 

- Y'a t'il des cas ou on utilise plusieurs microcontrôleurs pour un même robot ? si oui pourquoi ?

Oui.

Tout d'abord, un micro-controleur + un micro-ordinateur est très classique, car chacun est bon sur des points différents :

- l'ordinateur est bon pour faire de gros calculs rapidement (ex : traitement d'image, machine learning, navigation, ...), mais ne permet pas de gérer facilement du temps réel, et n'est pas très proatique pour interagir avec l'électronique

- le micro-controleur est plus lent, et ne pourra pas faire de gros calculs. Par contre on maîtrise très bien ce qui s'y passe, on peut donc facilement faire du controle "bas niveau" en temps réel (commande de moteurs, ...). De plus, il a plein d'entrées solties de différents types (numériques, analogiques, PWM, ...) qui font que c'est très pratique pour interagir avec de l'électronique (drivers de moteurs, capteurs, ...)

 

Ensuite, plusieurs micro-controleurs, c'est aussi parfois utile :

- pour gérer beaucoup d'entrées sorties (j'ai un projet perso en cours où j'ai 16 moteurs, avec pour chacun une limitation de courant et une mesure de courant, et pour 8 d'entre eux un retour de position : j'ai décidé d'utiliser 8 microcontroleurs, chacun gérant deux moteurs avec tous ce qui vas avec (j'ai aussi un raspberry pi (micro-ordinateur) qui commande le tout)

- pour séparer les fonctions (par exemple un micro-controleur qui gère les capteurs de proximité, et un autre qui s'occupe des moteurs) : souvent on peut tout regrouper, mais parfois ça peut être utile de séparer, par exemple si on veut créer un circuit imprimé pour chaque fonctionnalité

- pour garantir que plusieurs choses peuvent se produire chacune pile au bon moment : si tu as besoin de controleur super vite un moteur (par exemple une fois toutes les 1ms exactement), tu peux avoir du mal à en même temps lire 10000 fois par second un capteur à intervalles régulier : si tu utilises un micro-controleur pour lire le capteur, et l'autre pour controler le moteur, tu peux garantir que tu pourra faire chaque chose pile au bon moment

[Fsociety]

Partie actionneur : 

=> Pour choisir un driver de moteur cc le principe est assez simple tu regardes les caractéristiques du moteur que tu as choisis  voltage et ampérage et tu prends un driver de moteur qui est capable de suivre ... 

=> Un servomoteur contient déjà ses drivers, donc pas besoin d'ajouter un driver de moteur en plus pour les servomoteurs.

 

Partie microcontrôleur : 

 

Si tu veux utiliser ROS il te faut un " Ordinateur " et pas juste un " Microcontrôleur " . 

Tu peux prendre un raspberry pi par exemple  raspberry pi 4   ( Mieux vaut avoir un peu de puissance sous le capot pour faire tourner ROS ... )

Plus d'info sur la différence entre micro-contrôleur ( genre arduino ) et ordinateur ( genre raspberry pi )  normalement ça devrait répondre à pas mal de questions je pense. 

Hésite pas à reposer des questions si ça n'a pas suffit ! =)

 

Merci pour le lien Mike, effectivement ça répond a certaines de mes interrogations.

 

Du coup pour contrôler les servomoteurs j'ai juste besoin de les commander en PWM a partir du microcontrôleur c'est bien ça ?

 

 

Pour compléter la réponse de Mike :

Tout d'abord, comme dit Mike, il faut différencier micro-controleur (type Arduino) et micro-ordinateur (type Raspberry pi)

 

Pour un micro-controleur, les principaux critères sont :

- la facilité d'utilisation

- la tension de fonctionnement (5V, 3.3V ou 1.8V en général), qui déterminent ce que tu peux y connecter directement

- le nombre de pins d'entrée/sortie et leurs types (combien de pins numériques, combien d'entrées analogiques, combien de PWMs, combiens de pins d'intéruption, combien de ports de commnication et lesquels (I2C, UART, SPI, US, CAN, ...)

- la puissance de calcul

- la mémoire (RAM et flash)

 

En pratique, si tu débutes, je te conseilles un Arduino Uno ou un Arduino Mega si tu as beaucoup de choses à connecter. En soit, c'est loin d'être le mieux en termes rapport performance/prix, mais les Arduinos sont très faciles à utiliser, très bien documentés, et ont une très grosse communauté (tu trouvera plein de monde sur ce forum par exemple qui pourra t'aider si tu as un problème dans ton code Arduino ; si tu prends un STM32 par exemple à la place, tu aura probablement bien plus de capacités à prix égal, mais c'est beaucoup plus dur à prendre en main, et je ne sais pas si tu trouvera quelqu'un sur ce forum qui pourra t'aider).

Une fois que tu sera à l'aise en général avec les Arduinos, si tu as des besoins spécifiques, il sera toujours temps de chercher un microcontroleur qui correspond exactement à ton cahier des charges

 

Sur un micro-controleur, tu vas probablement manquer de puissance pour faire tourner ROS, et j'ai de gros doutes que tu trouves des binaires pour l'installer (peut-être qu'il y a moyen de compiler depuis les sources sur certains gros microcontroleurs). En gros, ROS, c'est prévu pour tourner sur un (micro) ordinateur sous linux. Le choix classique en robotique amateur est le Raspberry Pi (là encore, une grosse communoté et pas mal de documentations), mais si besoin, tu peux aussi utiliser quelque chose de plus puissant (par exemple un Odroid, voir encore bien plus puissant si tu en as le besoin et le budget (au travail, on utilise une Jetson Xavier : 8 coeurs, GPU 512 coeurs, 32Go de RAM ... mais 750€)). Pour commencer, un raspberry Pi 4 est je pense un bon choix.

 

Oui.

Tout d'abord, un micro-controleur + un micro-ordinateur est très classique, car chacun est bon sur des points différents :

- l'ordinateur est bon pour faire de gros calculs rapidement (ex : traitement d'image, machine learning, navigation, ...), mais ne permet pas de gérer facilement du temps réel, et n'est pas très proatique pour interagir avec l'électronique

- le micro-controleur est plus lent, et ne pourra pas faire de gros calculs. Par contre on maîtrise très bien ce qui s'y passe, on peut donc facilement faire du controle "bas niveau" en temps réel (commande de moteurs, ...). De plus, il a plein d'entrées solties de différents types (numériques, analogiques, PWM, ...) qui font que c'est très pratique pour interagir avec de l'électronique (drivers de moteurs, capteurs, ...)

 

Ensuite, plusieurs micro-controleurs, c'est aussi parfois utile :

- pour gérer beaucoup d'entrées sorties (j'ai un projet perso en cours où j'ai 16 moteurs, avec pour chacun une limitation de courant et une mesure de courant, et pour 8 d'entre eux un retour de position : j'ai décidé d'utiliser 8 microcontroleurs, chacun gérant deux moteurs avec tous ce qui vas avec (j'ai aussi un raspberry pi (micro-ordinateur) qui commande le tout)

- pour séparer les fonctions (par exemple un micro-controleur qui gère les capteurs de proximité, et un autre qui s'occupe des moteurs) : souvent on peut tout regrouper, mais parfois ça peut être utile de séparer, par exemple si on veut créer un circuit imprimé pour chaque fonctionnalité

- pour garantir que plusieurs choses peuvent se produire chacune pile au bon moment : si tu as besoin de controleur super vite un moteur (par exemple une fois toutes les 1ms exactement), tu peux avoir du mal à en même temps lire 10000 fois par second un capteur à intervalles régulier : si tu utilises un micro-controleur pour lire le capteur, et l'autre pour controler le moteur, tu peux garantir que tu pourra faire chaque chose pile au bon moment

 

Tout d'abord merci beaucoup pour ces explications détaillées, ça éclairci certaines zones d'ombres haha .

 

Je pense donc que je vais prendre une Raspberry PI 4 comme micro-ordinateur et malgré la simplicité d’utilisation d'Arduino je préfère quand même prendre un STM32 ( car j'ai cru comprendre que les microcontrôleur ST sont souvent utilisée dans le monde professionnel ) , l'idée c'est que j'apprenne a utiliser des outils qui me serviront plus tard pour mes stages ou futur boulot.

 

Du coup, j'aurais quelques questions si tu le permet :

 

- Comment se passe la communication entre le micro ordinateur et le micro contrôleur ? Supposons que j'écrive on va dire mon code en C++ ( orienté objet ) en utilisant le concept ROS, quels type de données dois je envoyer a mon micro contrôleur a partir de mon micro ordinateur par exemple pour faire bouger tel ou tel moteur ou allumer tel ou tel LED. ( ou bien sa dépend du microcontrôleur qu'on choisi).

 

- Comment on récupère/envoi les données du micro ordinateur vers le micro contrôleur ? c'est a dire comment peut on les synchroniser ? 

 

- Peut on utiliser une Arduino et un ST en même temps ? par exemple l’Arduino s'occupe des capteurs et le ST des moteurs ?

 

- Connaîtrai tu un site/documentation pour apprendre un peu plus sur le sujet ?

 

 

Donc même si j'ai par exemple : 4 moteurs DC , 10 servomoteurs et plusieurs capteurs (je ne connais pas encore le nombre) un seul micro contrôleur suffit pour contrôler l'ensemble du robot ?

 

 

Merci encore Mike et Sandro pour votre aide !

[Oracid]

- Comment se passe la communication entre le micro ordinateur et le micro contrôleur ? Supposons que j'écrive on va dire mon code en C++ ( orienté objet ) en utilisant le concept ROS, quels type de données dois je envoyer a mon micro contrôleur a partir de mon micro ordinateur par exemple pour faire bouger tel ou tel moteur ou allumer tel ou tel LED. ( ou bien sa dépend du microcontrôleur qu'on choisi).

Concernant ROS, la prise en main a l'air de s'améliorer en combinant l'utilisation de ROS et Webots (aujourd'hui gratuit).

Cela dépasse, de loin, mes compétences, alors voici un tutorial qui pourrait t'aider. Il y en a beaucoup d'autres.

https://www.youtube....waml_Rz1SU-76Sp

 

 

Concernant l'utilisation de servos à la place de moteurs, j'insiste sur le fait que cela me semble une solution qu'à condition que les couples soit comparables.

 

<je ne suis pas sûr que 2 sujets sur le même projet constituent un avantage>

[Mike118]

En théorie tu peux utiliser autant de microcontrôleur que tu veux en même temps. Donc aucun soucis pour avoir une arduino + un stm32 + une raspberry pi.

En pratique on évite juste de trop en mettre ( car il faut mettre en place les protocoles de communications entre les différentes cartes et faire les différents programmes. 

Bref il faut trouver un bon compromis entre " mettre autant de microcontrôleur que nécessaire pour faciliter les contrôles des choses " / " ne pas mettre trop de microcontrôleur pour faciliter les communication entre les différents microcontrôleurs " . 

Pour les moyens de commuications entre les cartes tu as beaucoup de bus de communication standard du  genre UART, I2C, SPI ... ( Même parfois du CAN en natif )  tu pourras envoyer des données via ces bus, mais c'est à toi de coder le "protocole d'échange de données " qui passe dans ce bus. Exemple "Quelle donnée j'envoie pour faire bouger tel moteur " 

Idem Si tu veux de la synchronisation ( exemple synchro de mouvement entre deux cartes ) là aussi c'est à toi de mettre le protocole en place ... mais du coup pour simplifier il est plus rentable de mettre les choses qui doivent être synchro ensemble sur le même micro-contrôleur ...

 

 

[Fsociety]

Concernant ROS, la prise en main a l'air de s'améliorer en combinant l'utilisation de ROS et Webots (aujourd'hui gratuit).

Cela dépasse, de loin, mes compétences, alors voici un tutorial qui pourrait t'aider. Il y en a beaucoup d'autres.

https://www.youtube....waml_Rz1SU-76Sp

 

 

Concernant l'utilisation de servos à la place de moteurs, j'insiste sur le fait que cela me semble une solution qu'à condition que les couples soit comparables.

 

<je ne suis pas sûr que 2 sujets sur le même projet constituent un avantage>

 

Merci pour le lien youtube, le premier sujet c'est pour le choix des moteur, celui la c'est pour l'électronique qui permet de contrôler les moteurs/servomoteurs

 

En théorie tu peux utiliser autant de microcontrôleur que tu veux en même temps. Donc aucun soucis pour avoir une arduino + un stm32 + une raspberry pi.

En pratique on évite juste de trop en mettre ( car il faut mettre en place les protocoles de communications entre les différentes cartes et faire les différents programmes. 

Bref il faut trouver un bon compromis entre " mettre autant de microcontrôleur que nécessaire pour faciliter les contrôles des choses " / " ne pas mettre trop de microcontrôleur pour faciliter les communication entre les différents microcontrôleurs " . 

Pour les moyens de commuications entre les cartes tu as beaucoup de bus de communication standard du  genre UART, I2C, SPI ... ( Même parfois du CAN en natif )  tu pourras envoyer des données via ces bus, mais c'est à toi de coder le "protocole d'échange de données " qui passe dans ce bus. Exemple "Quelle donnée j'envoie pour faire bouger tel moteur " 

Idem Si tu veux de la synchronisation ( exemple synchro de mouvement entre deux cartes ) là aussi c'est à toi de mettre le protocole en place ... mais du coup pour simplifier il est plus rentable de mettre les choses qui doivent être synchro ensemble sur le même micro-contrôleur ...

 

 

 

D'accord merci pour ces infos, je vais de ce pas me renseigner sur comment on peut réaliser ces protocole d'échange de données et ce que ça représente.

[Fsociety]

Bonjour !

 

Me re-voila a nouveau après m’être renseigné un peu sur les BUS de communication existant .

 

Donc voici les choix que j'ai fait et les raisons pour lesquelles j'ai choisi tel ou tel composant :

 

- Micro-ordinateur : Raspberry PI  |  Pour pouvoir faire tourner et utiliser ROS et pour le prix qui est bas donc idéal pour un projet personnelle.

 

- Microcontrôleur : STM32-F103 NUCLEO-64 | Utilisation plus difficile qu'avec un Arduino mais  les microcontrôleurs ST sont très utilisé dans le "monde" robotique professionnel donc j'ai tout intérêt a apprendre a m'en servir, en plus c'est pas cher et plus performant qu'une carte Arduino de ce que j'ai compris.

 

- BUS de communication : CAN  | Premièrement parce-que c'est un BUS de type " multi-maître " , on peut établir des priorités et permet de transmettre jusqu’à 30 mètres a une vitesse de 1Mbits/s ( Je n'ai pas choisi le SPI car il permet la communication uniquement entre composants sur une même carte ou entre un Arduino et son shield et n’est pas approprié à une communication entre cartes sur une plus longue distance, en ce qui concerne le IC il est plus lent) , J'ai également décider d’utiliser un BUS de communication CAN car il est également très utilisé dans la robotique mobile donc autant apprendre a s'en servir.

 

 

Qu'en pensez vous ? Y'a t'il d'autres composants ou données sur les quels je devrais me pencher ?

 

Merci encore !

[R1D1]

J'ai lu la discussion très rapidement, mais à propos de ROS et du microcontrôleur : il n'y a a priori pas de contrainte tant que tu peux faire communiquer ton MC et ton ordi. Tu as plusieurs designs avec ROS qui doivent théoriquement marcher :

- Un noeud d'interface qui tourne sur l'ordi (RPi dans ton cas). Ce noeud (qui est un programme C++, Python,etc. utilisant le framework ROS) est chargé de faire la communication avec le microcontrôleur (en utilisant un port série en général). Ça signifie que tu dois écrire le code de communication, mais le firmware du microcontrôleur est indépendant de ROS.

- tu utilises ROS serial, qui est un package ROS fait pour utiliser les topics avec un microcontrôleur. Ça marche bien avec Arduino, il y a sûrement d'autres MC supportés. Le firmware du MC utilise donc la logique de ROs (les topics) pour envoyer des infos vers l'ordi, donc pas besoin de faire tourner de noeud d'interface sur l'ordi, tu peux lire directement les infos.

[Fsociety]

Bonjour,

 

Merci R1D1 pour ton aide.

 

Ok donc si j'ai bien compris si j'utilise ROS serial je n'ai pas besoin décrire le code de communication entre le MC et l'ordi car il permet directement la lecture de données ?

 

Si c'est le cas j'aimerais bien savoir quels sont les cas ou il est plus judicieux de créer le code de communication et surtout a quoi ressemble un code de communication entre ordi et MC?

 

Donc si je peut illustrer ça par un exemple de contrôle de moteur:

 

J'écris mon programme en C++ qui me permet d'envoyer un signal PWM au bon moteur en fonction des données capteurs ultrasons reçu, donc je vais publier sur un topic ex : "motorPWM" et en même temps sub a un topic "distanceSensor".

 

Une fois terminé, je vais sur mon IDE Arduino et cette fois j'écris mon code de façon a lire les données du capteur et les envoyer sur le topic "distanceSensor" et je sub au topic"motorPWM" pour récupérer la valeur PWM a envoyer a mon moteur.

 

 

Donc en gros, sur mon ordi c'est la ou j'écris mes programmes de calculs(positions,vitesse,valeur X..etc) et j’envoie ces valeurs a un topic donné, et mon Arduino se charge de récupérer ces valeurs et de faire tel ou tel action.

 

 

Du coup pas besoin de BUS de communication, si la communication se fait par USB ? ou j'ai mal compris quelque chose ?

 

 

Serait t'il possible de voir un exemple concret de projet ou de tuto sur le sujet si possible ?

 

 

Merci pour votre aide et conseils !

[Ludovic Dille]

Hello,

Techniquement l'USB est aussi un un BUS mais passons. Donc pour la communication entre ta Rpi et ton arduino, l'USB suffit (et normalement pour ton stm32 ça devrait aussi marcher). Par contre tu devras surement utiliser d'autres protocles de communication avec tes capteurs (souvent I2C ou SPI).

Pour ce qui est des tutos je pense qu'il doit y en avoir pas mal qui montrent la liaison entre une rpi et l'arduino

[R1D1]

ROS Serial te mâche le travail de communication, mais au prix de certaines limitations : http://wiki.ros.org/rosserialToutes les plateformes ne sont pas supportées. Selon le hardware, tu peux vouloir contrôler les trames plus précisément que ce que ne permet les messages ROS.

En termes d'exemples, tu peux regarder ce tuto : http://wiki.ros.org/rosserial_arduino/Tutorials/Blinkpour une version très simple de l'utilisation de ROS Serial. Si tu veux faire sans ROS, il faut gentiment invoquer Oliver qui a passé du temps sur ce sujet.

[Fsociety]

Bonjour,

 

Désolé pour ma réponse tardive, J'ai commencé a utiliser ROS Serial histoire de le prendre en main j'ai fait un programme tout simple et ça marche  !

 

J'ai une question qui est peut être bête, mais je préfere la poser et en avoir le cœur net !

 

Est ce que l'avantage d’utiliser ROS est le fait de pouvoir parallélisé les taches ( comme les thread peut être? )?

 

D'ailleurs, si quelqu'un aurait le temps de checker mon code ca serait cool d'avoir un avis sur ma facon de faire !

 

Merci !

[R1D1]

ROS facilite beaucoup d'aspects de la programmation de robots, et un aspect important est la modularité du logiciel : pouvoir remplacer l'algorithme de navigation N1 par N2 juste en démarrant un programme (noeud) différent, c'est vraiment pratique. Le fait d'avoir des mécanismes "faciles" à mettre en œuvre pour faire communiquer des programmes entre eux permet de se concentrer sur le développement des algorithmes. Pas besoin de réécrire ces interfaces à chaque fois. Le parallélisme est effectivement important (avoir l'évitement d'obstacles qui tourne toujours pendant que le robot planifie comment aller d'un point A à mais sans GPU, ça reste du faux parallélisme (corrigez-moi si j'ai tord -- les programmes sont appelés en série, sur des fenêtres de temps suffisamment faibles pour que ça ressemble à une exécution parallèle).

 

Pour ton code, poste-le (peut-être dans un autre fil de discussion, on dérive un peu dans celui-ci) et je jetterai un oeil.

[Fsociety]

Merci R1D1 pour ces explications  , en effet je vais poster mon code dans la rubrique Programmation du forum !

 

Encore une fois merci a tous ceux qui ont répondu a mes questions