séparation des taches et question de vocabulaire

Si vous ne savez pas dans quelle rubrique poster c'est très certainement celle-ci. Tout ce qui ne concerne pas un robot mais peut intéresser la communauté.
If you do not know where to post it is most certainly this one. Anything that does not concern a robot but may interest the community.
Post Reply
Sandro
Posts: 17
Joined: Tue 02 Jun 2015, 11:15

séparation des taches et question de vocabulaire

Post by Sandro » Sun 21 Jun 2015, 13:49

Bonjour,
dans le cadre d'un projet d'étude, j'ai décidé avec 9 autres personnes de construire un robot (dans le cadre de la coupe de France de robotique). Hors, la direction des études nous demande de travailler en groupes de 5 à 7 personnes (mais plusieurs groupes peuvent collaborer).
On compte donc faire 2 groupes de 5, l'un construisant le robot (hardware) et écrivant les fonctions d'interaction avec le matériel (avancer de 15cm, saisir l'objet qui se trouve à 5 cm, ...) et le second s’occupant de la vision artificielle et de la partie "intelligence artificielle".

Mes 2 questions sont donc:
-est ce que ce découpage des taches vous semble cohérent, ou en auriez vous un meilleur à proposer?
-est-ce qu'il y a un nom pour la partie logicielle qui sert à faire l'interface entre le matériel et la partie de logiciel "pur"?

Merci d'avance
Sandro

User avatar
zeus
PMI
Posts: 4181
Joined: Thu 24 May 2001, 02:00
Location: colombe

Re: séparation des taches et question de vocabulaire

Post by zeus » Mon 22 Jun 2015, 10:24

de mon point de vu c'est délicat car la partit logiciel aura besoin de la partie hardware qui peu évolué au cour de l'année.

le problème de la découpe étant donc qu'il risque d'avoir un temps non linéaire sur chaque équipe du projet.

de mon sens si il faut séparé en 2 groupe autant faire 2 robots (et rien ne vous empêche de faire des partie commune)

pour le moment il est autoriser d'avoir un robot secondaire et un robot principale dans les équipes ( je dit pour le moment car je ne sais pas si ca sera reconduit l'année prochaine))

bref si le règlement autorise 2 robots vous faite une équipes et vous vous répartisse les action sur la table
si le règlement n'autorise pas 2 robots vous faite 2 équipes

Amare
Posts: 196
Joined: Fri 15 Jan 2010, 17:46

Re: séparation des taches et question de vocabulaire

Post by Amare » Mon 22 Jun 2015, 13:19

Sandro wrote:Mes 2 questions sont donc:
-est ce que ce découpage des taches vous semble cohérent, ou en auriez vous un meilleur à proposer?
Ce découpage est classique (séparer haut et bas niveau), de nombreuses équipe le font.... Mais je ne compte plus les équipes qui arrivent à la coupe avec l'équipe "hard" qui passe à la coupe des nuits blanches a essayer de faire avancer le robot pendant que l'équipe "IA" se tourne les pouces en peaufinant sur le papier une IA de performante (enfin performante tant qu'on a pas pu la tester). L'inverse peut aussi exister mais est plus rare.

Bref si c'est votre première participation, avec aucune personnes qui a déja réalisé une base roulante fonctionnelle, je vous conseillerai comme l'as déja dit Zeus de faire deux robots.
ARE (2005 et 2006), AMARE (2010: 41ème ,2011: 25ème), MLRobotic - 2013(.Bot : 84ème, 2014 (.leg): 54ème, 2015(.leg): 56ème)
http://blog.mlrobotic.com

Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Re: séparation des taches et question de vocabulaire

Post by Keuronde » Mon 22 Jun 2015, 13:23

Sandro wrote:-est ce que ce découpage des taches vous semble cohérent, ou en auriez vous un meilleur à proposer?
Je dirais que le découpage n'est pas optimal !
Même dans le cas où vous arrivez assez tôt à figer l'interface logicielle entre les deux projets, il y a un risque que je ne prendrais pas à votre place :
De nombreuses équipes arrivent à la coupe sans avoir un robot qui roule droit, si c'est votre cas le second groupe verra sont travail totalement jeté à la poubelle. Pas cool !
Pour une première participation c'est un risque qui est vraiment présent. S'il fallait proposer une autre répartition des tâches, je tenterai :
  • Base roulante (Déplacement, localisation du robot, asservissement)
  • Actionneurs et stratégie
Avec chacun sa carte électronique/son microcontroleur/son processeur, une communication par message avec une liste de commandes définies très tôt dans le projet.

Après vous avez peut-être déjà des acquis solides dans un domaine...
Sandro wrote:-est-ce qu'il y a un nom pour la partie logicielle qui sert à faire l'interface entre le matériel et la partie de logiciel "pur"?
On appelle parfois ça de la programmation bas niveau
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

Sandro
Posts: 17
Joined: Tue 02 Jun 2015, 11:15

Re: séparation des taches et question de vocabulaire

Post by Sandro » Mon 22 Jun 2015, 16:23

Merci beaucoup pour vos réponses.

Pour ce qui est de l'expérience en robotique, j'en ai fait un peu à base d'un jeu de construction (malheureusement sans carte programmable, je me contentais d'un petit composant préprogrammé, de relais/transistors et d'électro-mécanique)) : je n'ai jamais eut de problèmes pour aller (quasiment) droit (en utilisant un capteur de champ magnétique ou une barrière photovoltaïque pour reconnaitre la position "tout droit"). Sinon, il y en a un autre dans le groupe qui a déjà construit un robot de sumo.

Mais de toute façon, la répartition en 2 groupes semble être tombée à l'eau entre temps (la moitié de l'équipe m'a lâchée pour un autre projet).


Et merci pour la réponse à la question de vocabulaire : je savais qu'on pouvait parler de bas niveau pour des langages de programmations nécessitant une (relativement) bonne compréhension de l'ordinateur (assembleur, dans une moindre mesure le C), mais je n'étais pas sur si cela s'appliquait aussi au sein d'un langage.

Bonne journée
Sandro

arno
PMI
Posts: 685
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: séparation des taches et question de vocabulaire

Post by arno » Tue 23 Jun 2015, 01:22

Salut,

Il est difficile de trouver un découpage en 2 groupes indépendants. Un robot, ce n'est pas 2 ensembles, mais un tas de modules (chassis mécanique, actionneurs, capteurs, différents logiciels, ...).

Si tu découpes en tâches la réalisation du robot, et que tu met un planning dessus, tu risques de voir que tous tes découpages logiques font qu'un groupe attends l'autre.
Si il faut attendre d'avoir fini le bas niveau pour faire les tests en live du haut niveau, l'équipe bas niveau va se tourner les pouces à la fin si ils ont fini, ou au contraire, l'équipe haut niveau risque d'attendre sans rien faire si le bas niveau galère.

Il est plus facile et efficace d'organiser une seule équipe, avec des tâches repartie une personne à la fois, mais c'est pas évident à faire passer dans le cadre de projet académiques.

Dans le cas idéal, tu as une liste de tâche et le planning qui va avec (genre gantt donner les dépendances entre les tâches), et tu dépiles dans l'ordre en commancant par ce dont tout le monde dépend (la base roulante/marchante/volante... ;) ), pour finir par les "nice to have" si il reste du temps (les trajectoires circulaires, si tu n'as pas de base roulante fiable, c'est inutile). Certains gros sujets devant être attaqués en parrallèle, genre la vision qui ne peut pas être fait en une semaine avant la coupe (mais ça doit apparaitre dans le planning selon la durée estimée).
Après c'est de la gestion de projet et être capable selon les résultats rencontrés d'ajouter ou retirer certaines tâches pour avoir un robot fonctionnel à la coupe, même si il ne fait pas exactement tout ce qui avait été prévu. Par exemple, rerouter les ressources de la vision sur la stratégie si elle est à la bourre, car une vision finie si rien ne peut l'utiliser, c'est une perte de temps (mais en apprennant plein de trucs on est d'accord!).

Je te rassure, on a tendance à ne pas aller jusque là dans la plannification, mais a repartir un ou plusieurs des sous-ensemble à chaque membre (une carte elec, un firmware, un actionneur mécanique, l'IA, la gestion d'un capteur...), avec une grosse entraide lors de l'assemblage du bouzin et des tests.

Pour le jargon, on parle souvent de "bas niveau" pour ce qui est proche du materiel (comme les drivers moteurs) et de "haut niveau" pour ce qui est plus abstrait (la commande "avancer de 10cm" abstrait les détails des moteurs et de la mécanique).
Pour le code en lui même, on utilise souvent "firmware" pour le code de bas niveau embarqué dans des microcontrôleurs, "middleware" pour l'interface entre haut et bas niveau (l'API en somme), et je ne suis pas sur qu'il y ait de nom pour le haut niveau plus précis que "software"....

Post Reply