Discussion:Projets IMA4 SC & SA 2018/2019
De Wiki de Projets IMA
Révision datée du 17 juin 2019 à 22:23 par Rex (discussion | contributions) (→Répartition des binômes)
Répartition des binômes
Projet | Analyse | Matériel | Mi-parcours | Fin de parcours | Wiki terminé | Rapport | Vidéo |
P9 Spider and I | La description des "concurrents" aurait pu être plus précise. Un effort sur le scénario d'usage qui aurait, lui aussi, pu être développé. Des coquilles. Un vague plan de travail. | Rien ou presque, fournisseur non utilisable. | N'utilisez pas le mode "code" (espace en première colonne) pour distinguer une ligne. Une progression régulière mais il faudrait résoudre les problèmes soulevés à la semaine 7. Le travail à réaliser est assez simple, un résultat parfait est attendu. | Très bon Wiki de type chronologique, précis, très bien illustré, rédigé en bon français. | Un rapport très correct, bien rédigé, bien structuré. | Quelques hésitations. Vous auriez du faire plus concis. La démonstration finale est correcte. Un bel effort tout de même. | |
P10 Capteur de niveau d'eau et de pollution | Des coquilles. Bonne description des concurrents. Un effort pour le scénario, bonne mise en contexte, forcer sur la description de l'usage. Un plan de travail correct. | Une liste préliminaire de matériels. Fournisseurs correctement choisis. Rien sur la page principale. | Coquilles inacceptables dans le Wiki. Wiki assez vide. Il est à espérer que le projet est plus avancé ! | Un effort net pour le Wiki, plus que quelques coquilles, des illustrations, le travail effectué est partiellement décrit, il manque cependant un bilan sur l'avancée du projet. | Un rapport moyen. Manque de relecture : "je vais d’avoir abordé". Pas de description du système complet (schéma global ?). Une meilleure prise de recul pour le bilan du projet mais avec quelques points laissés dans l'ombre. Une conclusion honnête cependant. | Pas de vidéo. | |
P12 Recyclage plastique imprimante 3D | Vous êtes sur pour les servo-moteurs ? Ne serait-ce point des moteurs pas à pas ? Très bonne description du produit à réaliser avec illustrations. Bel effort de rédaction, encore pas mal de coquilles surtout en fin de page. Bonne étude des concurrents. Un scénario d'usage un peu rapide qui ne donne pas assez envie d'acquérir le produit. Questions difficiles mal exploitées (une réponse à la première question pourrait aussi être "par l'expérience", pas de réponse à la seconde question). Une étude solide du projet même si la liste des tâches à effectuer manque. | Bonne question sur le budget, mais posez la si vous voulez une réponse :D Liste de matériel encore très embryonnaire : rien sur l'électronique, une discussion avec votre encadrant s'impose pour fixer la partie mécanique. | Wiki très bien tenu mais corrigez les quelques coquilles. Avancé du travail bien présenté. Vous devez toujours me présenter la note pour les matériels achetés chez Leroy-Merlin. | Un Wiki de type chronologique très correct, très bien illustré, pas trop de coquilles, un bilan sur le travail réalisé. | Rapport très correct. Synthétique, correctement rédigé avec une partie prospective intéressante.. | Une tentative méritante de démonstration de votre prototype. | |
P13 Emetteur / Récepteur analogique en bande 5725-5875 MHz | Un seul concurrent. Scénario d'usage ne donnant probablement pas la pleine mesure du produit. Rien sur la planification. | Rien. | Rien. Votre travail n'est pas évaluable. Votre projet est en péril. | Wiki abandonné. | Rapport sans introduction et sans présentation du contexte. Une partie très basique sur les techniques de modulation de signal. La partie conception du circuit n'est pas nulle mais pas à la hauteur de ce qui est attendu dans un projet IMA4. Conclusion lapidaire mais avec laquelle je suis d'accord : projet raté. Rapport nettement insuffisant. | Pas de vidéo. | |
P14 Voiture autonome en modèle réduit | Il me semble que le chassis doit être celui d'un modèle radio-commandé existant. Il me semble que le pilotage manuel n'est pas autorisé. Description un peu rapide des concurrents. Une synthèse du matériel et logiciels employés aurait été intéressant. Pour le scénario d'usage, une description avec la voiture comme sujet aurait être plus intéressant. La réponse à la première question ne va pas dans le sens de l'autonomie. Dire que python est le langage par défaut de la RPi n'a pas de sens. Vous avez tout intérêt à prendre le langage le plus efficace est ce n'est probablement pas python. Pas de servo-moteurs continus sur une voiture radio-commandé. Pas vraiement de plan de travail. Prenez contact avec votre encadrant direct, j'aimerais que vos choix soient validés, certains me paraissent discutables. | Aucune référence précise pour les matériels. Rien sur la page principale. | Wiki moyen, peu dense, très peu illustré. Vous partez comme les IMA5 sur une solution de votre cru alors que vous n'avez aucune expérience en réseaux de neurones. Il est à craindre que le résultat final soit décevant. | Le Wiki a été enfin alimenté. Le résultat est très correct, correctement alimenté, pas trop de coquilles, très bien illustré. Il permet de constater le travail réalisé. | Pour moi vous êtes, a minima, imprécis concernant le signal à utiliser pour contrôler la vitesse qui est bien un signal de contrôle de servo-moteur. Cela dit un rapport correct. En particulier le rapport est correctement structuré. | Très bien, la vidéo donne vraiment l'impression que l'apprentissage fonctionne :D | |
P22 Secure And Verified Public Announcements through Blockchain | Excellente rédaction. Une bonne tentative de description du projet mais toujours un flou sur le travail à réaliser. Cela aurait pu être levé avec une liste précise des tâches à effectuer (une tentative de liste dans les objectifs). | Pas de matériel nécessaire (une RPi peut-être). | Un wiki très propre. Travail effectué décrit.. Il manque juste l'information sur la validation du prototype 0 par l'encadrant direct. | Excellent Wiki. Peut-être un peu trop de code inclut dans le texte. | Très bon rapport mais un peu baclé à la fin (e.g. section "difficultés rencontrées"). | Pas de vidéo. | |
P26 Discussion pair à pair | Nombre de coquilles inacceptable. Rajouter dans les objectifs de devoir tenter une ouverture de bouclier pour TCP (TCP Hole Punching). Analyse du premier concurrent : le prétexte pour n'utiliser que des serveurs microsoft pour les supernoeuds skype est le faible nombre de machines d'utilisateurs non handicapées par des parefeux. Bonne réponse aux questions difficile. L'expérience de skype dit qu'il faut totalement éviter qu'un noeud utilisateur ait à relayer les communications d'un autre utilisateur (ce qui est d'ailleurs contraire aux objectifs). Il faut donc une solution de pair à pair pour tous les clients. En particulier, IPv6 doit être intégré dans les solutions possibles. Il ne me semble pas que l'enregistrement des utilisateurs soit nécessaire, elle nuit même à la vie privée. Il faut simplement mémoriser les utilisateurs connectés. | Pas de matériel listé pourtant il faut mettre en place un banc d'essai. | Coquilles inacceptables dans le Wiki. En fin de projet vous avez seulement mis en place le banc de test sans aucun développement d'un système de perçage de box que ce soit en UDP ou en TCP. | Un effort sur les coquilles même s'il en reste. Le Wiki est assez moyen. Une description chronologique mais avec des semaines très peu documentées. Il manque un bilan sur l'avancement du projet. Très peu de chose sur l'expérimentation avec TCP (un schéma des paquets échangés). Wiki assez pauvre en schémas pour un sujet qui s'y prêtait. | De trop nombreuses coquilles. Une introduction un peu rapide au perçage de masquarade. Il s'agit d'un travail bibliographique sans référence aux sources (indiquées dans le Wiki). Pas de recherche personnelle sur le sujet. La partie architecture du code est en fait une description fonction par fonction du code (on peut concevoir une telle description mais en annexe). La description du code est en effet nécessaire car le code s'il est bien indenté et commenté est inutilement complexe. La complexité tient à la ré-écriture de l'utilitaire nc et à un protocole de communication avec le mandataire de connexion mal conçu. Vous avez passé trop de temps sur ces parties au détriment du perçage de masquarade lui-même. De plus vous manipulez les paquets réseau au travers de la bibliothèque des socket alors qu'une interface plus bas niveau aurait pu vous faciliter la vie pour ce genre de sujet. La mauvaise conception de votre code (duplication UDP/TCP et IPv4/IPv6) est exactement reflété dans votre rapport ce qui en fait un document confus. Vous êtes hors-sujet concernant IPv6, il n'y avait rien à implanter, juste à tester que les deux pairs avaient des adresses IPv6 et qu'ils pouvaient communiquer directement. La liste des problèmes rencontrés montre un peu trop que vos connaissances de TCP/IP sont perfectibles. Cette section est elle aussi particulièrement confuse, votre réflexion est loin d'être aboutie. Le rapport manque de synthèse et d'appropriation des protocoles TCP/IP, il réflète bien, en cela, le travail effectué. | Pas de vidéo. | |
P28 Affichage à billes | Pour les panneaux d'affichage publicitaire, je ne suis pas sur que la consommation puisse être qualifiée d'énorme (il semble que si, à la lecture de votre réponse aux questions difficiles mais cela doit comprendre l'éclairage dont votre produit pourrait avec aussi besoin). Rédaction très correcte. Un gros effort sur les illustrations. Un scénario d'usage, lui aussi, bien rédigé. La réponse à la question difficile sur l'énergie consommée par votre produit ne me convainc pas : partez sur la différence d'énergie potentielle pour monter une bille pas sur la force à exercer qu'il faudrait intégrer sur la hauteur de la remontée. Il faut approfondir l'analyse des tâches à effectuer. | Il me semble avoir demandé de limiter la complexité du dispositif : 8 moteurs ?? Pas de références précises pour les matériels (lien sur le matériel dans le site du fournisseur). | Très bon Wiki. Avancé du travail très bien présenté. On attend avec impatience le résultat des tests sur le prototype "carton". | Wiki correct. Le travail est bien présenté et bien illustré (malgré une vidéo sur youtube) mais au final le Wiki est peu dense. De semaine en semaine reviennent les mêmes problèmes mécaniques et de calibrage du capteur de couleur. | Rapport correct. Le rapport se lit très bien (bonne rédaction, bien illustré) mais manque de fond. Les points durs sont évacués (tremblement des servos ou fonctionnement erratique du capteur de couleurs). Une étude plus scientifique (bilan énergétique, étude du calibrage du capteur) aurait été nécessaire. | La magie du montage ! Très bien. | |
P30 Système minimal de gestion de conteneurs | Excellent Wiki à ce jour. Rédaction très claire. Très bonne introduction. Tâches à réalisées clairement listées (mais dans les objectifs). Présentation très correcte du "concurrent principal". Un scénario d'usage correct (j'aurais plutôt insisté sur la faible consommation du système en ressources que sur l'installation dans un système fortement personnalisé). Un calendrier prévisionnel. Le second "concurrent" est en fait l'ancienne couche bas niveau de Docker . Il faudrait utiliser la syntaxe Wiki mais ne touchez à rien avant la séance du 10 décembre cela me fera un exemple parfait pour expliquer cette syntaxe.
|
Pas de matériel nécessaire (une machine virtuelle sera concédée en cours de projet). | Wiki très complet et très propre. Avancé du travail bien présenté. Il faut arriver à finaliser les scripts de gestion des conteneurs. | Un excellent Wiki. La partie chronologique est probablement la moins dense mais la qualité du travail transpire de l'état de l'art et des autres section de ce Wiki très complet. | Le rapport est propre. Bien rédigé et écrit en LaTeX. Le problème principale est la disproportion entre la partie état de l'art et la partie travail réalisé. Vous auriez du plus insister sur votre travail sans tomber dans le piège de décrire chaque script. Il fallait trouver une méthode pour montrer le bon fonctionnement de ces scripts. Les scripts sont écrits très proprement avec quelques coquilles de français. L'architecture est modulaire mais il faut mettre le chemin du répertoire de ces scripts dans le PATH pour éviter des erreurs de présence de scripts. | Pas de vidéo. | |
P31 Robot hexapode de mesure de RSSI WiFi | Beaucoup trop de coquilles. Bonne présentation des "concurrents" qui vous servent aussi pour expliquer que votre projet est leur synthèse. Le scénario d'usage se tient. Bonne réponse à la question. Je ne crois pas trop au positionnement par RFID (il faut être sur un tag RFID pour le lire). Etes-vous sur pour l'Arduino méga ? Un Uno avec un bouclier PWM ne serait-il pas plus efficace ? | Effort de liste de matériel avec des références précises. Pas de liste sur la page principale. | N'utilisez pas le mode "code" de mediawiki (espace en première colonne) pour distinguer des lignes. Utilisez la syntaxe pour les items. Wiki très peu dense. L'avancement du projet semble être suspendu. Un bel effort pour la partie mécanique (les pattes du robot). Par contre la partie programmation semble très peu avancée. | Un Wiki finalement correct mais qui se termine abruptement. Il manque la partie test et un bilan sur le projet. Quelques coquilles. | Une présentation de rapport assez primitive. Un peu trop d'extraits de codes très basiques (voire un peu maladroit avec duplication de code). Le rapport est peu dense, comme dit pour un autre rapport, une approche plus scientifique était attendue pour analyser les problèmes rencontrés : calcul énergétique pour les problèmes d'alimentation, calcul de forces pour la puissance des servos et enfin déverminage plus poussé du circuit imprimé. Rapport correct sans plus. | Très bien, exactement le type de vidéo demandée. | |
P32 Robe augmentée | En français l'abréviation de Monsieur est M. Mr est l'abrévation de Mister donc à n'utiliser qu'en anglosaxonnerie. Attention nous avons une expérience du fil à coudre conducteur et cela ne marche pas très bien sauf sur une surface très réduite. Le scénario d'usage est perturbant : cela semble être un scénario pour deux produits différents. Vous avez considérablement simplifié le projet (sous-ensemble de projets déjà réalisés), la réalisation devra être impeccable pour que cela puisse être validé comme projet IMA4. | La liste du matériel précise ce que vous souhaitez faire. Que vient faire la platine d'essai dans cette liste ? Pour le prototype ? Vous ne parlez pas du tout de la carte contrôleur. C'est une Lilypad ? | Wiki bien illustré mais une rédaction séche. Développez un peu. OK pour les cartes électroniques mais vous devriez présenter une esquisse de la robe telle que vous souhaitez la réaliser. | Le Wiki est toujours très bien illustré (y compris avec des extraits de code) mais avec assez peu d'explications rédigées. Pas de prise de recul sur le travail effectué. | Un rapport écrit avec une interligne complète ... Soit 14 pages en tout. Des extraits complets de documents techniques inclus dans le rapport (et non en annexe). Même remarque que pour le Wiki concernant III-1 et III-2 : trop d'illustrations pas assez de synthèse rédigée. La partie assemblage de la robe est aussi baclée que dans le Wiki. Aucun bilan et perspective. Un rapport moyen au mieux. | Discours un peu confus en première partie. La démonstration est un peu en deçà de ce qui aurait pu être présenté.. | |
P33 Collier à animations lumineuses | Un français imaginatif avec un nombre de coquilles dans la moyenne. Un scénario d'usage rocambolesque (il doit me manquer quelques références) mais acceptable. Des concurrents pertinents. Réponses aux questions acceptables. Se limiter à trois plaques ne me semble pas pertinent (même si vous pouvez faire un premier test sur trois plaques). Pour l'étude de la communication prévoyez un prototype avec quelques Arduino. | Une liste de matériel qui semble être établie à la hâte. Il manque de nombreux composants électroniques pour faire tourner micro-contrôleurs et pilotes de LED. Pas de référence précise pour les composants. | Rien sur votre travail, il n'est donc pas évaluable. Votre projet est en péril. Vous devriez avoir fait les tests de communication sur le bus SPI et avoir conçu votre PCB. | Un Wiki très mal présenté. Peu de contenu (hormis des photos de PCB non totalement soudés en pleine résolution). Assez d'accord avec la conclusion "Ce projet très peu concluant et convainquant n'a pas été mené à bien, il est un échec". | Rapport écrit en LaTeX. Une demi-douzaine de pages avec des illustrations prenant la page entière ou presque (schéma électronique, PCB partiellement soudé voire même un simple contour pour les plaques). Rapport insuffisant. | Pas de vidéo. | |
P35 Machine Learning pour navigation autonome de robots mobiles | Il n'est pas tenu compte des erreurs de français. Dans la partie objectifs, la première sous-partie devrait plutôt s'appeler "partie robotique", il n'y a rien d'électronique ici. Le travail a effectuer est assez flou. En particulier le Wiki ne contient rien sur les bibliothèques de "machine learning" à utiliser. | Le matériel est fourni par les encadrants directs (AIP ?) | J'ai peur que votre Wiki rende bien compte du travail effectué jusque là : uniquement des études, rien de concret à part utiliser une manette pour acquérir des jeux de données. C'est très inquiétant en cette période de fin de projet. Votre projet pourrait ne pas être validé. | Un Wiki très correct en définitive hormis la fin bien abrupte (pas de bilan du travail effectué, il manque les schémas présentés en soutenance). La rédaction est tout à faite correcte vu que le français n'est pas votre langue maternelle. Wiki bien illustré. Le travail effectué, en particulier à partir de la semaine 11, est décrit. | Un très grand effort de rédaction. Un effort de synthèse, vous avez présenté la solution fonctionnelle en faisant juste une référence à votre première tentative, c'est très bien. Peut-être un peu trop d'extraits de codes pas vraiment indispensables. Contrairement au Wiki les résultats sont présentés sous forme de cartes. | Pas de vidéo. | |
P37 Station de recharge intelligente pour robot mobile | Trop de coquilles. Il semble que le sujet initial ne correspond plus à ce qui est demandé, merci de préciser le nouveau sujet, calibrage du robot ?Comment comptez-vous calibrer un préhenseur avec simplement du code (pas de réponse au niveau de la question difficile) ? Un seul concurrrent et sur la partie obsolète du projet. Une analyse du travail a effectuer qui ne tient pas compte de l'abandon du sujet original. | Aucune liste de matériel | Rien à redire sur votre Wiki. Il me semble bien rendre compte de l'avancé de votre projet. Une liste de matériel finalisée en fin de projet : vous prenez de grands risques. Je vous rappelle qu'un prototype fonctionnel est attendu. | Peu de soin apporté à la présentation du Wiki. Beaucoup d'images en pleine taille et très peu de rédaction, en particulier en fin de Wiki. Pas de bilan du travail effectué. | Une assez bonne première partie (2.1 à 2.5) sur la conception de l'alimentation. Comme dans le Wiki, la partie 2.6 (réalisation et tests) est pratiquement vide ne comportant que des photos et des schémas. Un bilan du travail réalisé honnête : seule la conception de l'alimentation a été correctement effectuée. Rapport insuffisant. | Pas de vidéo. | |
P38 Interface Graphique pour Robotino 2 Upgradé | Choix des "concurrents" peu pertinents ou il fallait insister sur les différences entre ces robots et le robotino 2 amélioré. Le scénario d'usage se tient. Bonne réponse à la question "difficile". Il semble que le but du projet se réduise à créer une interface web avec une bibliothèque spécifique. L'interface devra être irréprochable pour constituer un projet IMA4. | Projet purement informatique, pas de matériel nécessaire (autre qu'un robotino amélioré). | N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Corrigez les coquilles ! En cette fin de projet vous semblez bien peu avancés sur l'interface Web. Rien sur la démonstration de fonctionnement du robotino que vous devez implanter. Il va falloir diantrement accélérer ! | Wiki final très correct. Très bonne idée votre mini-tutoriel WT. Pour les copies d'écrans de votre application, vous auriez du utiliser un tableau d'images et pas autant d'images les unes à la suite des autres sans aucun texte. Vous auriez pu faire un bilan du travail réalisé. | Rapport correct. Attention cependant à votre tendance à mettre trop d'extraits de code et à expliquer fonction par fonction comment fonctionne votre application. Votre rapport n'est pas assez synthètique. Il donne cependant une bonne idée du travail réalisé même s'il ne contient pas de bilan du travail effectué. | La première partie de la vidéo est une soutenance filmée. Démonstration de l'interface écran par écran. La partie sur la démonstration "cercle" est intéressante. Bon, je ne verrais jamais votre démonstration de hockey ... . | |
P40 RFID/NFC | L'objectif est clairement explicité et dans un français très correct. Des concurrents peu pertinents et une analyse trop hâtive des dits concurrents. La réponse sur la question de la difficulté du projet n'est pas convaincante. Votre application de contrôle du robotino par smartphone se devra d'être irréprochable pour constituer un projet IMA4. | Attention, tout votre projet repose sur la validité des lecteur RFID commandés. Si ces lecteurs ne sont pas utilisables votre projet tombe à l'eau. Vous avez étudié la compatibilité des lecteurs avec les robotino ? | Vous semblez avoir avancé dans votre projet mais vos dernières entrées dans le Wiki sont trop courtes pour permettre de juger. Etoffez votre Wiki en décrivant mieux cette application (copies d'écrans). Je ne vois aucune trace de la partie de connexion IP automatique via NFC au robotino ? | Finalement un Wiki peu dense. Certaines entrées comportent pas mal de coquilles. Wiki donnant la sensation d'avoir été cloturé dans l'urgence. | Rapport correct, assez bien rédigé. Le rapport reprend entièrement la partie analyse du Wiki, ce qui est légitime. Par contre le rapport se termine aussi abruptement que le Wiki avec un très court bilan de ce qui reste à faire mais sans comparer la réalisation avec ce qui était demandé. Je ne doute pas que ce projet permette à Xinwei d'avoir assez de matière pour mener à bien son M2. | Vidéo demandée mais non réalisée. | |
P42 Coupe de robotique des écoles primaires | Beaucoup trop de coquilles. Objectifs très clairement précisés. Analyse des concurrents et réponse lapidaires. Le fait que vous ne respectiez pas le cahier des charges imposé aux enfants est problématique. Une liste précise des tâches a effectuer. Un calendrier prévisionnel. | Bel effort de liste de matériel. Quelques composants chez des fournisseurs non agréés. Liste sur la page principale. | Wiki plus que correct qui donne bien une idée de la progression. Tentez d'appeler Robotshop pour savoir ce qu'est devenue la commande. Il faut aussi que vous vous penchiez sur le PCB de commande des LED et servo-moteurs de la piste. | Vous êtes retombés dans votre travers concernant les coquilles. Relisez ! En faisant abstraction des coquilles, le Wiki est bien illustré et permet de se rendre compte du travail réalisé. Il manque cependant une partie rédigée pour synthétiser ce qui marche et ce qui ne marche pas. Vous auriez du aussi parler de l'organisation de la CREP ce qui pour le coup est vraiment IMA. Wiki très correct. | Un rapport très complet décrivant votre travail au-delà du robot et de la piste (logiciels annexes et organisation de la CREP). Encore trop de coquilles. Il est clair à la lecture de votre rapport que vous avez visé trop haut. Cela dit vos encadrants, moi le premier, auraient du vous recadrer pour vous demander de revenir à un cahier des charges raisonnable. | Vidéo indispensable mais non réalisée. | |
P44 Clônes améliorés des modules ARDUINO | Restriction du sujet à la conception et réalisation d'une seule carte, ce qui est, ma foi, prudent. Bonne description de "concurrents". Des coquilles mais sans plus. Ne mettez pas d'espace ou d'accents dans les noms des fichiers téléchargés. Scénario d'usage acceptable. Clairement vous avez déjà pas mal réfléchi à votre carte. | Une liste de matériel mais sans lien vers le composant chez un fournisseur agréé. | Rien sur la réalisation. Votre travail n'est pas évaluable. Votre projet est en péril. | Un point sur l'avancement à la semaine 8. Un style particulier mais en décalage avec l'état d'avancement du projet. Liste de matériel en semaine 9. Le Wiki se termine sur le fait que la carte est prête à être imprimée le 9 mai (fabrication chimique demandée). Wiki insuffisant. | Aucun contexte. Le rapport s'ouvre par le schéma électronique de la carte. S'ensuit une description des parties de la carte. La seconde partie est une description du placement des parties pour le routage avec force copies de PCB. Sans transition le rapport se termine par une conclusion affirmant que la carte est terminée (cahier des charges respecté). Effectivement un ingénieur se doit d'être sûr de lui et savoir s'imposer mais là, sans aucun test, nous sommes plus près de la fraude que de l'assurance. Rapport insuffisant mais assez révélateur de l'avancement du projet. Peut-être avez-vous passé trop de temps sur les autres projets et pas assez sur le votre ? | Pas de vidéo. | |
P45 Sac à main ou sac à dos solaire | Wiki très bien illustré, rédaction assez correcte (quelques coquilles). Bonne description de concurrents, scénario d'usage convenable. Réponses un peu rapides aux questions "difficiles" | Une liste de composants qui parait encore bien préliminaire. Aucun lien sur les composants chez les fournisseurs. | Vous avez posé quelques réflexions dans votre Wiki. Cependant aucune trace de réalisation. Une liste de matériel exploitable trop tardive. | Des éléments ont été ajoutés (schéma global du système) et étapes de fabrication du sac à dos. Très peu d'éléments dispersés sur l'application Web. Le Wiki n'éclaircit pas l'absence de tentative de conception d'une carte maison. Un Wiki moyen. | Le rapport n'est pas plus clair au niveau du PCB. Il est mentionné un PCB terminé mais non soudé. Quel PCB ? Le rapport ne montre même pas une photo de la partie électronique. Ce rapport donne une impression de dissimulation de problèmes dont le principal est l'absence de conception d'une carte de contrôle de la recharge comme demandé dans le sujet. | Vidéo demandée mais non réalisée. | |
P46 Kit Robot | PLutôt bien rédigé malgré quelques coquilles. Objectifs bien fixés. Concurrents décrits en détail (un peu de synthèse n'aurait pas fait de mal). Scénario d'usage très correct. | Un liste de composants bien avancée. Des liens vers les fournisseurs. Matériels sur la page principale. | Le Wiki est correct. Vous semblez avoir terminé la phase de conception même s'il manque les informations sur le PCB. Disons que je serais rassuré quand vous aurez découpé les pièces du chassis et fait réaliser la carte électronique. En une phrase : il est plus que temps d'avoir des résultats tangibles ! | Il y aurait matière à chipoter mais soyons raisonnable : Excellent Wiki ! | Votre mise en page est moche (passez à LaTeX) sinon il s'agit d'un excellent rapport. | Très bien ! | |
P57 Mise à jour over the air | Bon cahier des charges qui répond aux questions que l'on pourrait se poser à la lecture du reste de la page. Quelle différence entre votre solution et Dualoptiboot du coup ? Dualoptiboot ne comprend pas la partie matérielle ? Allez-vous l'utiliser ? Un scénario d'usage bien rapide. La réponse semble à coté de la question, il semble que vous répondez à la question "comment vérifier une somme de contrôle avant de flasher la mémoire programme ?". Comment allez vous gérer la clef de chiffrement ? Elle est figée dans l'amorceur ? Je crois comprendre en fin de page que vous voulez fixer une clef par capteur, cela casse le principe de la mise à jour par diffusion radio, non ? | Une première liste de matériel sans lien vers les sites des fournisseurs agréés. | N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Cinq semaines pour router une carte ? Au minimum donnez les problèmes rencontrés et les résultats obtenus. Dans l'état de vacuité de votre Wiki, il est légitime de douter de la validation du projet. | Au final votre Wiki est correct. En particulier votre phase de déverminage de vos cartes en fin de projet sont assez bien rendu. Correctement rédigé, correctement illustré. Il manque tout de même une comparaison entre le travail réalisé et ce qui été demandé. | Trop de coquilles. La description du déverminage de la carte est intéressant mais pourrait être plus synthétique. Un certain recul en fin de rapport sur le travail effectué et les suite à donner. Rapport correct. | Vidéo possible mais non réalisée. | |
P63 Etude de la consommation d'un capteur de pollution | Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire. | Une liste de matériel avec des liens vers des fournisseurs. Par contre les fournisseurs choisis ne sont pas forcément utilisables. | Il y a comme un trou entre la semaine 3 et la semaine 7 ? Un problème de légende et de figure. Wiki acceptable. Les cartes doivent être vérifiées et réalisées de toute urgence. | En définitive un très bon Wiki, très bien rédigé et très bien illustré. Il ne manque qu'un bilan du travail réalisé. | Très bon rapport avec une démarche scientifique. | Vidéo demandée mais non réalisée. | |
P70 Impact du matériel et du logiciel sur le rayonnement électromagnétique | Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire. | Une liste de matériels très embryonnaire et sans lien exploitable. | Le Wiki n'est pas à jour et ne permet pas de se faire une idée du travail des deux dernières semaines. Rien à redire sur le travail antérieur. | Finalement un très bon Wiki avec de nombreux résultats bien présentés. Et une conclusion !. | Rien à redire sur le rapport, clair, bien rédigé avec une conclusion précise. Personnellement j'aurais préféré une présentation plus rapide des résultat en omettant certains graphes mais d'autres lecteurs peuvent vouloir la totale. | Pas de vidéo. | |
P72 Mesure du courant simple | Rédaction correcte. Wiki bien illustré. Une partie analyse correcte. | Une liste de matériel bien avancée avec des liens exploitables. Recopiez les liens sur la page principale. | Wiki très correct. Bien illustré. Il manque le schematic de la carte, vous l'avez réalisé n'est-ce pas ? Vous devriez déjà avoir routé et réalisé votre carte. | Wiki très correct avec une analyse détaillé des fonctionnalités réalisées (ou pas). | Un rapport correct, bien rédigé. Equilibré entre la partie conception et la partie réalisation. La conclusion est cependant difficile à faire passer, si vraiment vous n'étiez qu'à un changement de résistances d'un test positif il fallait dégager le temps pour effectuer cette modification. Au pire après la soutenance. | Pas de vidéo. | |
P73 Ecriture automatique de partition musicale | Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire. Un calendrier prévisionnel. | Une tentative de liste de matériel qui ne pourra effectivement être finalisé qu'après discussions avec un électronicien. | Wiki très correct. Bien illustré. Par contre vous semblez marquer le pas sur ces deux dernières semaines alors qu'il s'agirait, au contraire, de mettre un coup d'accélerateur. Routez cette carte, il est plus que temps ! | Très bon Wiki. | Très bon rapport bien qu'un peu austère sur la forme (et pourquoi pas). | Bonne démonstration.. |
Présence
Projet | Elèves | 10/12/2018 | 16/01/2019 | 23/01/2019 | 30/01/2019 | 06/02/2019 | 13/02/2019 | 27/02/2019 | 06/03/2019 | 13/03/2019 | 20/03/2019 | 27/03/2019 | 03/04/2019 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
P9 Spider and I | Nestor Martinez / Lina Mejbar | OK | E305 | E305 | E305 | E304 | A208 | E304
Présents |
E304 | E304
Présents |
E304 | E304 | E304 |
P10 Capteur de niveau d'eau et de pollution | Antoine Branquart | Absent (certificat médical) | E305 | E305 | E301 | Absent (certificat médical) | E301 | E303
Présent |
Excusé (malade) | C201
Présent |
C201 | C201 | C201 |
P12 Recyclage plastique imprimante 3D | Corentin Danjou / Pol Mulon | OK | E305 | E305 | E301 | E304/E301 | E301 | E303
Présents |
E303 | E303
Présents |
E304 / C201 | Fabricarium / C201 | Fabricarium |
P13 Emetteur / Récepteur analogique en bande 5725-5875 MHz | Arthur Reviron | Absent | C201 | C201 | C201 | C201 | C201
Présent |
C201
Présent |
|||||
P14 Voiture autonome en modèle réduit | Hugo Dejaegher / Brandon Elemva | OK | E306 | E306 | E306 | E306 | E306 | E306 + Fabricarium | E306
Présents |
E306 | E306
Présents |
E306 | E306 |
P22 Secure And Verified Public Announcements through Blockchain | Arezki Ait Mouheb | OK | E306 | E305 | E306 | E306 | E306 | E306
Présent |
E306 | E306
Présent |
E306 | E306 | E306 |
P26 Discussion pair à pair | Fabien Di Natale / Ibrahim Ben Dhiab | OK | E304 | E304 | E304 | E304 | E304 | E304
Présents |
E304 | E304
Présents |
E304 | E304 | E304 |
P28 Affichage à billes | Flora Dziedzic / Martin Michel | OK | Fabricarium | E305 | Fabricarium | Fabricarium | A311 | Fabricarium | Fabricarium
Présents |
Fabricarium | Fabricarium
Présents |
Fabricarium | Fabricarium |
P30 Système minimal de gestion de conteneurs | Hind Malti | OK | E304 | E304 | E304 | E304 | E303 | E306
Présente |
E306 | E306
Présents |
E306 | E306 | E306 |
P31 Robot hexapode de mesure de RSSI WiFi | Rémi Foucault / Hugo Velly | OK | E304 | E304 | E304 / Fabricarium | E304 / Fabricarium | E304 | E303
Présents |
E303 | E303
Présents |
E303/C202-bis | E304 | C201 |
P32 Robe augmentée | Brinda Muzakare / Yan Xuelu | OK | E304 | E304 | E304 | E304 | E304 | E304
Présentes |
E304 | E304
Présentes |
E304 | E304 | |
P33 Collier à animations lumineuses | Loris Ahouassou | OK | E306 | E305 | E304 | E304 | C201 | E304
Présent |
E304 |
Absent |
E304 | E304 | E304 |
P35 Machine Learning pour navigation autonome de robots mobiles | Wenjing Chen / Puyuan Lin | OK | E304 | E305 | C304 | C102 | C304 | C304
Absents |
C002
Présents |
C002
Présents |
|||
P37 Station de recharge intelligente pour robot mobile | Guillaume Declerck / Pierre Guigo | OK | E305 | E305 | E301 | E303 | E301 | E303
Pierre Guigo présent Guillaume Declerck absent |
E303 & C201 | C201 & E303
Présents |
C203 | ||
P38 Interface Graphique pour Robotino 2 Upgradé | François Brassart / Jérôme Haon | OK | E304 | E304 | E303 | E304 | E305 | E304
Présents |
E304 | E304
Présents |
C304 | C304 | C304 |
P40 RFID/NFC | Jean De Dieu Nduwamungu / Xinwei Hu | OK | E305 | E304 | E304 | E304 | E304 | E304
Présents |
E304 | E304
Présents |
E304 | E304 | |
P42 Coupe de robotique des écoles primaires | Pierre Frison / Thibault Lepoivre | OK | E305 | E305 | E304 | Fabricarium | E301(fab fermé) | Fabricarium
Présents |
Fabricarium | Fab et C201
Présents |
Fabricarium | E303 (Lepoivre) / frison absent(malade) | C201 |
P44 Clônes améliorés des modules ARDUINO | Théau Moinat | OK | C201 | C201 | C201 | C201 | C201
Présent |
C201 | C201
Présent |
||||
P45 Sac à main ou sac à dos solaire | Mathis Dupré | OK | E305 | E305 | E301 | E304 | E306 | E306 | E306
Présent |
E306 | E306
Présent |
C201 | |
P46 Kit Robot | Valentin Pitre / Gaëlle Bernard | OK | E304 | E305 | E303 | E304 | A208 | E304 | E304
Présents |
E304
Présents |
E304 | C202 | C202/E306 |
P57 Mise à jour over the air | Florent Leroy | OK | C201 | C201 | C201 | C201 | C201 | C201
Présent |
C201 | C201
Présent |
C201 & E304 | C201 & E304 | E304 |
P63 Etude de la consommation d'un capteur de pollution | Victor Lorthios / Juliette Obled | OK | C201 | C201 | C201 | C201 | C201 | C201+E303
Présents |
E303 | C201
Présents |
C201 | C201 | |
P70 Impact du matériel et du logiciel sur le rayonnement électromagnétique | Antoine Moreau / Souheib Khinache | OK | E305 | E305 | E304 | E304 | E304 | E304
Présents |
E304 | Fabricarium
Présents |
Fabricarium | Fabricarium | Fabricarium |
P72 Mesure du courant simple | Raphaël Martin | OK | E305 | E305 | E301 | E303 | E303 | E303 | E303
Présent |
E303 | E303
Présent |
E303 | Fabricarium |
P73 Ecriture automatique de partition musicale | Hugo Leurent / Fabien Ronckier | OK | C201 | C201 | C201 | C201 | C201 | C201
Présents |
C201 | C201
Présents |
C201 | C201 | C201 |