Transcripen – Enquête terrain et données recueillies

Envoyé par c20barbo le 9 Nov 2021 dans TAF COUAD | 0 commentaire

Nous présentons le déroulement de notre enquête terrain ainsi que les informations recueillies lors de chaque entretien.

Déroulement de la recherche sur le terrain

Comme indiqué dans la méthodologie de l’enquête terrain, nous avons interviewé à la fois des journalistes et des étudiants afin de comprendre la problématique de récupération du contenu d’un discours lorsque la personne doit être impliquée dans ce-dernier, les premiers rencontrant cette problématique lors d’interviews journalistiques, les seconds lors de leurs cours / conférences.

Déroulement de la recherche sur le terrain – Journaliste

Phase d’observation : entretiens exploratoires

Nous avons accompagné un journaliste du journal économique l’Agefi quotidien tout au long de sa journée ; de la revue de presse matinale, à la conférence de rédaction, aux interviews téléphoniques et physiques de l’après-midi, à la vérification des informations de mi-après-midi, jusqu’à la rédaction de l’article. Nous n’avons pas pu assister au rendez-vous pendant le déjeuner, ni à l’afterwork du soir.

Dans cette journée d’observation, plusieurs points marquants ont été soulignés. Premièrement, lors de la conférence de rédaction, consistant en un récapitulatif des articles à rédiger dans la journée, des interviews de la journée et des observations à obtenir de celles-ci, nous avons pu constater la part importante des interviews dans le quotidien d’un journaliste. Effectivement, nous avons constaté que chaque journaliste de l’Agefi a en moyenne 3 interviews / conférences de presse dans la journée, contre 1 article en moyenne à rédiger dans cette même journée. En d’autres termes, les journalistes de l’Agefi passent la plus grande partie de leur temps en interview. Cette observation a confirmé notre première hypothèse sur la prépondérance des interviews dans la journée d’un journaliste. Aussi, nous avons constaté que les informations à obtenir de ces interviews sont nombreux (3 à 4 informations à obtenir à chaque fois), mais aussi précis et techniques (des données chiffrées précises, des opinions précises, …). Cette observation a également confirmé notre hypothèse sur le fait que les journalistes sont actifs lors de l’interview tant ils doivent diriger l’interview et amener l’interlocuteur à lui donner les informations souhaitées.

Cette phase d’observation nous a permis d’affiner les questions que l’on souhaitait poser aux journalistes pour les entretiens dirigés ainsi que d’affiner nos hypothèses.

Phase de confirmation / réfutation des hypothèses

Nous avons ensuite effectué 6 entretiens semi-directifs, 5 à des journalistes économiques (3 journalistes de l’Agefi, une journaliste de News Assurances Pro, un journaliste de Wansquare) et un à un journaliste politique de Marianne. Les entretiens se sont déroulés en physique pour les journalistes de l’Agefi, et par téléphone pour les autres. L’objectif de ces-dernier était d’en savoir plus sur (i) la prise de note des journalistes lors des interviews, sur l’enregistrement des journalistes de leurs interviews, ainsi que sur (iii) la transcription des enregistrements audios. En d’autres termes, nous voulions ici savoir comment les journalistes récupèrent actuellement le contenu des interviews auxquelles ils participent et les difficultés qu’ils rencontrent. Ces entretiens étaient très intéressants, tant certains journalistes se sont livrés sur leurs problème quotidien à ce sujet, tant ils ont donné des exemples concrets pour illustrer leurs propos et tant l’ensemble des journalistes interrogés rencontre ce problème au quotidien. Il était également intéressant de voir que les journalistes politiques connaissaient la même problématique, et donc que celle-ci n’était pas intrinsèque au métier de journaliste économique. Cette phase d’entretiens semi-directifs a en revanche réfuté une de nos hypothèses : celle sur le fait que les journalistes enregistrent les interviews / n’arrivent pas à prendre des notes lorsqu’ils assistent à la sortie d’exclusivité. Effectivement, un seul journaliste nous a donné comme exemple un cas s’exclusivité. Quant aux autres, ils ont détaillé des situations problématiques de prise de note / enregistrement du contenu de l’interview dans l’objectif de restituer cette-dernière plus tard. Ainsi, nous avons pu finaliser, grâce à ces réponses, nos hypothèses, en ajoutant notamment l’hypothèse selon laquelle les journalistes sont particulièrement touchés par la problématique lors de restitution de longues interviews qu’ils doivent réutiliser plus tard.

Phase finale

L’entretien semi-directif nous a permis d’être encore plus précis sur contenu de l’interview. L’objectif était ici d’obtenir des informations plus précises sur la problématique rencontrée par les journalistes. C’est pourquoi nous avons réalisé un questionnaire que nous avons envoyé à une quinzaine de journalistes, dont 14 journalistes économiques (7 à l’Agefi, 2 des Echos Capital Finance, 2 de Wansquare, 2 de News Assurances Pro), et un journaliste politique de l’Opinion.

Le questionnaire visait dans un premier temps à comprendre l’ampleur du problème rencontré par les journalistes (en termes d’heures perdues par jour), ainsi que les circonstances dans lesquelles ce problème apparaissait. Nous avons ainsi obtenu (i) le temps moyen entre l’interview et le moment de récupération de l’information (30 minutes en moyenne sur les 10 ayant répondu à la question), (ii) le temps moyen passé à la transcription d’enregistrements par jour (1h), et enfin (iii) sur le type d’interview enregistré (conférences de presse, interviews longues (>1h)). Nous avons ainsi confirmé l’hypothèse émise à la suite des entretiens semi-directifs selon laquelle les journalistes sont particulièrement touchés par la problématique lors de restitution de longues interviews qu’ils doivent réutiliser plus tard.

Aussi, le questionnaire visait à comprendre les outils utilisés par les journalistes afin d’éclaircir la forme et l’utilité que devait prendre notre objet communiquant. Ici, l’intégralité des journalistes interviewés nous ont fait part de leur utilisation d’un stylo et d’un cahier pour prendre des notes pendant l’interview, et d’un logiciel de traitement de texte tel que word / open office pour rédiger leurs articles sur leurs ordinateurs portables personnel et / ou professionnel, 4/7 journalistes de l’Agefi, les 2 journalistes de News Assurances Pro, les 2 journalistes des Echos Capital Finance ainsi que le journaliste politique de l’Opinion nous ont fait part également de leur utilisation d’un enregistreur lors des interviews et conférences. Aussi, 2 journalistes nous ont fait part du fait qu’ils utilisent au quotidien une radio portable qu’ils écoutent partout où ils vont.

Déroulement de la recherche sur le terrain – Etudiants

Nous avons interviewé quelques étudiants de l’IMT Atlantique. Ce qui revient tout le temps c’est la difficulté d’écouter et de suivre le cours tout en prenant des notes. Pour une meilleure compréhension du cours, la prise de notes est souvent négligée car, pour certains, il y a eu une différence notable sur leurs notes en se concentrant sur ce qui est dit au lieu d’essayer de tout noter. Aussi, certains vont prendre des notes que pour des cours avec des notions compliqués; ils vont ainsi noter des mot-clés, des éléments importants à retenir.

Mais une problématique qui ressort même avec cette méthode c’est la pertinence des notes prises. En effet, pour tous les étudiants interviewés, ils remontent la difficulté à se relire des fois. Ils oublient la signification de certains éléments et n’arrivent plus à se retrouver dans leurs notes qui perdent leur utilité.

Certains utilisent des outils comprenant l’enregistrement de la parole. Mais, pour eux, la prise de tout le contenu du cours n’est pas intéressant car elle nécessite du temps derrière pour trier et récupérer les informations pertinentes. L’autre aspect préoccupant aussi est l’autorisation du professeur pour l’enregistrement.

Aussi un des interviewé a révélé qu’il serait intéressant d’avoir une fonctionnalité qui ressortirait tout ce qui a été dit la dernière minute ne prenant conscience que tardivement de l’importance de ce qui vient d’être dit.

Conclusion

Pour conclure, nos interviews nous ont permis de confirmer un certain nombre d’hypothèses et d’en réfuter d’autres:

Hypothèses confirmées :

• La transcription d’un enregistrement audio issu d’une interview / conférence est longue

• La transcription d’un enregistrement audio issu d’une interview / conférence n’apporte rien et fait perdre du temps

• La transcription est principalement utile pour des conférences / interviews longues (plusieurs heures)

• Il est plus facile de naviguer dans un texte que dans un audio

Hypothèses réfutées et / ou modifiées :

Nous avons modifié l’hypothèse selon laquelle un enregistrement est utile sur le moment (cas d’exclusivité pour les journalistes / de relecture du cours juste après pour les étudiants): la transcription d’un audio / d’une conférence est effectuée plusieurs temps après que l’enregistrement ait été effectué (pour les révisons des partiels pour les étudiants / pour la rédaction d’un article plusieurs jours après pour un journaliste.

Personna

Ecocard – Etat de l’art

Envoyé par m20barat le 4 Nov 2021 dans Projets | 0 commentaire

Baraton Maxime, Blondel Victor, Czernichow Mila, Reynaud Louis

           Dans un premier temps nous nous sommes penchés sur le problème de la surconsommation d’énergie par les entreprises. Nous avons ensuite privilégié les entreprises de 30 à 50 employés maximum afin de pouvoir déployer une solution plus facilement et de façon moins coûteuse dans un premier temps. Nous avons également centré notre problème sur la consommation d’énergie inutile, c’est-à-dire lorsque des appareils électriques consomment de l’énergie alors qu’ils ne sont pas utilisés. Nous pouvons prendre l’exemple d’un écran d’ordinateur laissé en veille au lieu de l’éteindre correctement. C’est un problème qui touche les patrons de ce type d’entreprise qui souhaitent réduire leur consommation d’énergie pour des raisons budgétaire ou écologique.

Afin d’explorer ce problème nous voulions d’abord des preuves de l’existence de ce problème ou du moins de l’existence de consommation inutile d’énergie.

[1] Pour cela nous avons trouvé un grand nombre de chiffres sur le site de l’ADEME, concernant la consommation des appareils en veille mais aussi [2] sur les gestes permettant de réduire la consommation inutile de ces appareils. 

Nous avons ensuite recherché des solutions techniques. [3] Nous avons pensé aux systèmes de carte dans les hôtels : une carte permettant d’alimenter en électricité la chambre d’hôtel et étant donc retirée lorsque le client quitte sa chambre. Nous voulions réaliser la même chose pour les postes de travail : une carte qui centralise la connexion et la déconnexion de tous les équipements électriques du bureau. 

[4] Après un entretien avec un élève de IMT Atlantique nous avons appris l’existence des multiprises maître-esclaves qui représentent une bonne partie de la solution. En effet, de tous les équipements du bureau seul l’ordinateur doit être éteint d’une façon spéciale. Ces multiprises permettent le fonctionnement suivant : lorsque l’ordinateur à été éteint les autres appareils du poste s’éteignent avec lui. Cette prise centralise donc l’alimentation du bureau sur l’état éteint ou allumé de l’ordinateur. [5] La plus grosse tâche reste donc d’éteindre l’ordinateur et de l’allumer de façon centralisée avec la carte.

Le prototype serait donc un boîtier, une carte et une multiprise maître-esclave. On connecte l’alimentation de l’ordinateur sur la prise maître et tous les autres équipements sur les prises esclaves. Ensuite le boîtier est connecté à l’ordinateur et il permet de l’éteindre et de l’allumer. Enfin la carte permet d’activer le boîtier : si la  carte est insérée dans le boîtier, l’employé arrive au bureau, on allume l’ordinateur et cela allume les autres équipements. Si l’employé quitte son bureau, il retire la carte ce qui provoque l’arrêt de l’ordinateur puis tous les équipements ne sont plus alimentés. Ainsi aucun équipement ne consomme d’énergie quand l’employé n’est pas à son poste.

Bibliographie

[1]

« Le saviez-vous ? », ADEME. https://www.ademe.fr/entreprises-monde-agricole/performance-energetique-energies-renouvelables/lenergie-bureaux/dossier/equipements-electriques/saviez (consulté le oct. 19, 2021).

[2]

« Matériel informatique : place à la sobriété », Agir pour la transition écologique | ADEME. https://agirpourlatransition.ademe.fr/particuliers/bureau/numerique/materiel-informatique-place-a-sobriete (consulté le oct. 20, 2021).

 [3]

« Cartes RFID pour les hôtels | Découvrez les cartes-clés de HOTEK ». https://www.hotek.nl/fr/rfid/carte-rfid (consulté le oct. 13, 2021).

[4]

fixit, « Les multiprises avec fonction master / slave », Réparer Facile, nov. 14, 2009. https://www.reparer-facile.fr/actualite/informatique-multiprise-fonction-master-slave/ (consulté le oct. 26, 2021).

[5]

1. Rédac, « Allumer ou éteindre un PC à distance ». https://www.commentcamarche.net/informatique/windows/1657-allumer-ou-eteindre-un-pc-a-distance/ (consulté le oct. 26, 2021).

Mini-projet capteur météo et LoRaWAN avec la Lopy4

Envoyé par clanglai le 18 Oct 2021 dans TAF COUAD, Projets | 0 commentaire

Dans ce mini-projet, il s’agit de transmettre les informations de température et hygrométrie d’une pièce à un serveur du réseau The Things Networks à l’aide à l’aide du protocole LoRaWAN.

Sommaire

Etape 1 Accéder au réseau The Things Network (TTN)

Etape 2 Récupérer les données de température et humidité du DHT11

Etape 3 Envoi des données de température et humidité sur le serveur TTN

Matériel/logiciel :

Etape 1 Accéder au réseau The Things Network (TTN)

a) Découverte du réseau TTN et de la plateforme web

La figure 1 présente l’architecture classique d’un réseau LoRaWAN, dite en étoile. Chaque noeud (ou end device) peut être connecté à plusieurs passerelles (gateways), qui sont elles-mêmes connectées à un serveur d’application qui va collecter, choisir voire, traiter les données. Les gateways ne font que relayer les paquets de données. Si le serveur d’application reçoit plusieurs fois le même paquet en provenance de plusieurs passerelles, il est  capable de choisir celui avec la meilleure qualité de signal.

FIG 1. Par Germain GAUDARD — Travail personnel, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=64159124

Il existe plusieurs réseaux publics d’opérateurs LoRaWAN. Dans ce mini-projet, nous choisissons le réseau The Things Network (TTN), qui est un réseau public open-source, qui peut être utilisé sans contrainte commerciale ou privée.

L’équipe pédagogique a préalablement déclaré les noeuds LoPy4 sur l’interface de TTN appelée, The Things Stack Community Edition.

Exemple de tutorial pour déclarer un device de type LoPy4 (lien vers tuto spécifique).

Demandez login et mdp à l’enseignant.e présent.e pour accéder à la plateforme [4].

Les devices sont nommés selon leur adresse MAC (voir Bien démarrer avec la LoPy4 pour lire l’adresse MAC [19]). Avant toute chose identifiez votre device en lisant son adresse MAC.

Dans l’application tp-lora-cooc de la plateforme The Things Stack Community Edition [4], repérez votre device et cliquez pour obtenir des informations supplémentaires :

Figure. Tableau de bord TTN de l’application tp-lora-cooc

Notez la valeur de AppEUI, DevEUI et AppKey. Les 3 éléments permettent de mettre en place une connexion LoRaWAN sécurisée avec le serveur TTN.

Dans l’onglet Live data, vous observerez plus tard les données qui sont remontées de votre noeud (uplink) ou qui sont envoyées à votre noeud (downlink). Dans l’onglet Messaging, vous pouvez simuler l’envoi de données uplink au serveur, vous pouvez également programmer des envois de données downlink. Vous pouvez également appliquer un code aux données reçues et envoyées permettant de les formatter pour les rendre lisibles par un humain (Payload formatters).

Toutes ces actions seront expérimentées un peu plus loin.

b) Se connecter au réseau TTN à partir de votre LoPy4 et envoyer vos 1ers paquets

Vous allez connecter votre Lopy4 au réseau TTN et envoyez vos 1ers paquets en uplink sur le réseau TTN.

• Récupérez le code main_template.py sur gitlab [5]
• Modifiez DevEUI et AppKey selon les paramètres indiqués sur la plateforme TTN
• Modifiez le nom en main.py et chargez sur le device
• Observez les print dans la console pymakr ainsi que la couleur de la LED qui vous indique l’évolution de la connexion
• Une fois la connexion effectuée (CONNECTED!!), observez les messages remontés (payload) sur la plateforme dans l’onglet Live data du device.

Figure. Console live data du device

Questions

1. Quelle est la forme des paquets remontés (payload) dans live data ?  Quel est le lien avec les données envoyées de la lopy qui sont sous la forme PKT + entier ? La table de correspondance Decimal <>Hexadecimal<>Caractère ASCII [10] va vous aider. On remarque par exemple que le code hexadécimal du caractère P est 50.
2. Utilisez lora.stats() et comparez avec la variable consumed_airtime sur la plateforme en cliquant sur l’évènement (event details)
3. Quel est le SNR de la transmission ? lisez la variable SNR dans l’onglet Live data. Observez les variations (min/max).
4. Calculez la marge de transmission pour le min et le max à partir du SNR récupéré dans la console et du SNR limit donné ci-dessous pour le SF utilisé (Cf. [7] video 17 slide 16 et vidéo 16 slide 4, supports disponibles en pdf sur Moodle)

Figure. Mobilefish.com – LoRa/LoRaWAN tutorial – SNR limit and Receiver sensibility [7]

5. Quel est le spreading factor ? Varie-t-il pendant la transmission ?

6. À l’initialisation de la transmission, modifiez le spreading factor dans main.py en choisissant SF égal à 10. soit DR=2 [17]

s.setsockopt(socket.SOL_LORA, socket.SO_DR, 2)

Observez l’effet dans la console du device sur la plateforme TTN.

7. Ajoutez la fonctionnalité d’adaptive data rate (adr=True), observez la variation du SF au cours de la transmission. Expliquez.
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868, device_class=LoRa.CLASS_C, adr=True)

c) Décrypter les messages envoyés sur la gateway

Dans la console gateway, observez les paquets remontés sur le serveur TTN. En cliquant sur l’event, vous pouvez accéder à différentes informations comme les informations sur la transmission, par exemple :

settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 12,
"coding_rate": "4/5"

On trouve également des informations sur le paquet transmis

"message": {
"raw_payload": "QDQjCyYAqAAC5OFiPQ/CfAA=",
"payload": {
"m_hdr": {
"m_type": "UNCONFIRMED_UP"
},
"mic": "D8J8AA==",
"mac_payload": {
"f_hdr": {
"dev_addr": "260B2334",
"f_ctrl": {},
"f_cnt": 168
},
"f_port": 2,
"frm_payload": "5OFiPQ=="
}
},

Le MIC ainsi que le DevAddr sont en clair. Par contre, le message est crypté (« 5OFiPQ==").

Sur [18] (LoRaWAN 1.0.x packet decoder), vous pouvez décoder le raw_payload de votre message :

Questions

1. Après décodage, identifiez le Message Type ; DevAddr ; FRMPayload
2. Vérifiez que le FRMPayload ne correspond pas au message envoyé (Live data du device). En effet, le message est crypté ! Récupérez la NwkSKey et la AppSKey dans la console de votre device (Overview). Entrez-les dans votre décodeur et vérifiez que le FRMPayload décrypté après décodage est identique au message envoyé.

d) Envoyer des paquets du serveur TTN vers votre Lopy4 (Downlink)

Pour cela, nous allons programmer des envois downlink à partir de la plateforme TTN, onglet Messaging du device.

• Décommentez les lignes de code correspondantes à la réception d’un message dans main.py sur la LoPy4
• Téléversez le code dans la LoPy4
• Après la connexion au réseau TTN, observez la réception du 1er paquet sur l’interface, puis la LoPy est en attente de réception d’un paquet
• Programmez un envoi downlink (exemple FF) dans la console Gateway sur la plateforme TTN

• Observez la réception du paquet sur la LoPy (via le print dans la console pymakr), puis l’envoi d’un nouveau paquet en uplink.

L’attente de réception d’un paquet bloque l’envoi de tout nouveau paquet.

• Programmez l’envoi de plusieurs paquets dans la console (Push to downlink queue)

Si la qualité de la transmission est suffisante, le protocole ADR devrait modifier le Data Rate (SF et puissance d’émission).

Figure. Downlink messages envoyés vers le device. (FF puis AA puis BB). Le 1er message reçu sur le device est MAC payload = 45 car le message est crypté.

e) Décoder le paquet downlink envoyé du serveur vers la LoPy4 et reçu au niveau de la gateway

Comme pour le message Uplink reçu au niveau de la gateway, le message Downlink transmis du serveur vers la gateway est crypté.

On peut lire le DevAddr, le compteur de paquet, Le FRMPayload est encrypté, il est donc différent du message envoyé par la Lopy. En utilisant le NwkSKey (hex-encoded; optional) et le AppSKey, vous pouvez décrypter le paquet envoyé par la Lopy. Vérifiez que le FRMPayload décrypte correspond bien au message envoyé par la Lopy.

Etape 2 Récupérer les données de température et humidité du DHT11

Pour cette étape, nous allons utiliser la LoPy4 uniquement en tant que micro-contrôleur (pas de transmission sans fil) pour récupérer les données du capteur de température et humidité DHT11. La data sheet du capteur est donnée ici [2]. Il est monté sur une carte à 3 broches SE052, dont la data sheet est donnée ici [8].

• Récupérez le dossier DHT11 sur gitlab [9]
• Enregistrer le répertoire en local. L’arborescence et le nom des fichiers doivent être conservés (1 fichier main.py, 1 répertoire lib, 1 fichier dht.py dans le répertoire lib). Supprimez les fichiers cachés en .gitxxx.
• Dans le main.py, identifiez la broche de la LopY qui sera utilisée
• Branchez les fils entre le capteur DHT11 et la LoPy4. S pour signal sur la broche identifiée dans le main.py, – pour GND, VCC pour la broche du milieu sur 3V3. Attention si les fils sont mal branchés la petite led orange de l’expansion board va flasher.

branchement du capteur SE052

Branchement DFR0067

• Téléversez le code (car il faut charger la librairie dht.py)
• Observez les données récupérées dans la console pymakr
• Dans le fichier dht.py, lisez le code correspondant à read(). Comparez avec le chronogramme de  communication ci-dessous (extrait de la data sheet [2]). Qu’observe-t-on en sortie de la fonction pulses_get() ? Quels sont les intervalles de temps qui permettent de définir si le capteur envoie un ‘0’ ou un ‘1’ ?

Figure. Chronogramme de communication entre DHT11 et MCU ([2], p.5).

• Repérez le format des données dans la data sheet ([2], p.5), comparez avec la fonction read(). Combien d’octets sont envoyés du capteur vers la Lopy (MCU)? Quels sont les octets qui contiennent les données ? À quoi sert le checksum ?

Etape 3 Envoi des données de température et humidité sur le serveur TTN

Nous allons maintenant intégrer les 2 codes précédents pour envoyer les données de température et humidité sur le serveur TTN.

a) Intégration des 2 codes précédents

À vous de jouer !

Attention au format des données transmises via LoRaWAN. Utilisez la fonction bytes() pour envoyer des octets.

La table de correspondance Decimal <>Hexadecimal<>Caractère ASCII [10] peut vous aider.

Références

[1] « Démarrer avec Lopy4 Pycom | Téléfab ». https://telefab.fr/2021/09/27/demarrer-avec-lopy4-pycom/ (consulté le oct. 19, 2021).

[2] « DHT11.pdf · main · LANGLAIS Charlotte / TP lora COOC », GitLab. https://gitlab.imt-atlantique.fr/clanglai/tp-lora-cooc/-/blob/main/DHT11.pdf (consulté le oct. 19, 2021).

[3] « TTN Mapper ». https://ttnmapper.org/colour-radar/ (consulté le oct. 19, 2021).

[4] « Management platform for The Things Network », The Things Network Console. https://eu1.cloud.thethings.network/console (consulté le oct. 19, 2021).

[5] « OTAA/main_template.py · main · LANGLAIS Charlotte / TP lora COOC », GitLab. https://gitlab.imt-atlantique.fr/clanglai/tp-lora-cooc/-/blob/main/OTAA/main_template.py (consulté le oct. 19, 2021).

[6] « LoRa ». https://docs.pycom.io/firmwareapi/pycom/network/lora/ (consulté le oct. 19, 2021).

[7] « Mobilefish.com – LoRa/LoRaWAN tutorial. » https://www.mobilefish.com/developer/lorawan/lorawan_quickguide_tutorial.html (consulté le oct. 19, 2021).

[8] GO TRONIC, « Capteur de t° et d’humidité DHT11 ST052 », GO TRONIC. Consulté le: 16 septembre 2024. [En ligne]. Disponible sur: https://www.gotronic.fr/art-capteur-de-t-et-d-humidite-dht11-st052-26117.htm

[9] « DHT11 · main · LANGLAIS Charlotte / TP lora COOC », GitLab. https://gitlab.imt-atlantique.fr/clanglai/tp-lora-cooc/-/tree/main/DHT11 (consulté le oct. 19, 2021).

[10] « Fichier:ASCII-Table-wide.svg — Wikipédia ». https://commons.wikimedia.org/wiki/File:ASCII-Table-wide.svg(consulté le oct. 19, 2021).

[11] « Tutorial on how to build a Pycom LoPy4 weather station », HackMD. https://hackmd.io/@ehTrKNe5RYyySf6QXbWMWA/ByVCoGFAU (consulté le oct. 19, 2021).

[12] « Automating a floor fan with DHT11 sensor », HackMD. https://hackmd.io/@abbeabbe/ByNXPfGyv (consulté le oct. 19, 2021).

[13] « Plant Sensor », Hackster.io. https://www.hackster.io/55480/plant-sensor-a9937f (consulté le oct. 19, 2021).

[14] « Ubidots ». https://www.thethingsindustries.com/docs/integrations/cloud-integrations/ubidots/ (consulté le oct. 19, 2021).

[15] « Cayenne ». https://www.thethingsindustries.com/docs/integrations/cloud-integrations/cayenne/ (consulté le oct. 19, 2021).

[16] « LoRa et LoRaWAN pour l’internet des objets ». Udemy. https://www.udemy.com/course/lora-et-lorawan-pour-linternet-des-objets/learn/lecture/20927430#overview (consulté le oct. 3, 2022).

[17] « Méthodes et constructeur de la classe LoRa ». https://docs.pycom.io/firmwareapi/pycom/network/lora/

[18] « Lora Packet Decoder ». Consulté le: 4 octobre 2024. [En ligne]. Disponible sur: https://lora-packet.vercel.app/

Projet CODEV n°28 : Coupe de France de robotique

Envoyé par n20aidou le 18 Oct 2021 dans Projets | 0 commentaire

Nous sommes trois étudiants en FISE A1 et dans le cadre de notre projet CODEV, nous avons collaboré avec le club de robotique d’IMT Atlantique en vue de sa participation à l’édition 2021 de la Coupe de France de robotique qui se déroulera début juillet. Notre projet s’est donc inscrit donc dans un projet plus large, celui d’engranger le plus de points possible lors de l’édition 2021 de la compétition et de remettre en place les bases techniques et matérielles qui seront utiles lors des éditions futures de la coupe.

Le déroulement d’un match de la Coupe de France de robotique peut se résumer de la façon suivante : deux équipes s’affrontent en plaçant un ou deux robots (et parfois des systèmes électroniques secondaires) sur une aire de jeu afin d’engranger un maximum de points en 100 secondes.

Aire de jeu de l’édition 2021 de la coupe

Notre travail s’est concentré sur la conception et la fabrication du phare, un système annexe au robot principal de l’équipe qui peut rapporter jusqu’à 15 points sur les 93 points disponibles au maximum (sans compter les bonus). Le phare doit être placé par l’équipe dans une zone de l’aire de jeu appelée “zone rocheuse” et doit être allumé au cours du match par un système impliquant un contact physique avec un des robots de l’équipe. Une fois allumé, il doit se déployer et allumer une source lumineuse avec balayage pour signaler la zone rocheuse. Ce système est également soumis à de nombreuses contraintes (dictées par le règlement de la coupe[1]) portant sur ses dimensions, son amplitude de déploiement, son système d’éclairage ou encore son alimentation. Cependant, nous étions  très libres au niveau du choix de la méthode de déploiement du phare. Le déploiement doit être déclenché par une action physique du phare, cependant il peut mettre en jeu un système purement mécanique (par exemple un système de ressorts) ou un ensemble mécatronique plus complexe. Au vu du temps nous étant accordé pour travailler sur ce projet, nous avons choisi de concevoir un phare basé sur un système mécatronique. La conception de ce type de système est particulièrement complexe, mais permet l’acquisition de compétences en électronique, en informatique mais également en mécanique, un sujet peu abordé en première année dans notre filière.

Notre travail s’est donc décomposé selon les étapes suivantes : nous avons tout d’abord longuement réfléchi sur la technologie de déploiement du phare, pour finalement aboutir à un mécanisme d’élévateur en ciseaux. La modélisation 3D du système à l’aide du logiciel de modélisation 3D Autodesk Inventor nous a ensuite  permis de dimensionner les différentes pièces et de valider de façon théorique certaines performances du phare.

  Modèle 3D

Après avoir obtenu un modèle 3D satisfaisant, il était nécessaire de réaliser un premier prototype d’un étage à l’aide d’une découpe laser et d’impressions 3D. Ce premier prototype a permis de souligner les défauts de notre modélisation en vue d’une amélioration de notre prototype. Finalement, nous avons pu fabriquer un prototype mécanique fonctionnel respectant la majorité des contraintes.

Prototype mécanique

Il ne nous restait donc plus qu’à mettre ce prototype en mouvement à l’aide du circuit électronique suivant, piloté par une carte Arduino Uno.

Voici donc le système final, dont nous sommes assez satisfaits car il respecte la majorité des contraintes fixées par le cahier des charges :

Au repos

Après déploiement

Il existe cependant certaines perspectives d’amélioration, avec notamment l’ajout d’étages supplémentaires au système (un étage correspondant à un « X » du système élévateur à ciseaux), l’ajout d’un pont en H permettant de contrôler la descente du phare et enfin la réduction des jeux de liaisons.

Nicolas Aïdoune, Yao-Hua Xu et Mouna Wamra.

Aller plus loin avec la LoPy4

Envoyé par clanglai le 4 Oct 2021 dans Projets, TAF COUAD | 0 commentaire

Voici quelques exercices pas à pas pour aller plus loin dans l’utilisation de la LoPy4 et la compréhension de la couche PHY du standard LoRa.

Si vous démarrez avec la LoPy4, consultez l’article Démarrer avec Lopy4 Pycom

Nous allons utiliser 2 LoPy4. l’une en émetteur (TX), l’autre en récepteur (RX).

Le code utilisé est celui du Ping Pong : Le code est disponible ici [1].

S’il y a plusieurs LoPy actives à proximité, choisissez qui sera le noeud TX et le noeud RX et particularisez la transmission.

Exemple pour la transmission dite A:

Côté TX :

s.send('PingA')

Côté RX :

if s.recv(64) == b'PingA':

Les méthodes utilisées sont celles présenteés sur cette page [2].

Vous pouvez par exemple récupérer la taille de la bande ou la modifier :

# get raw LoRa Bandwidth
lora.bandwidth()

# set raw LoRa Bandwidth
lora.bandwidth(LoRa.BW_125KHZ)

Pour cela, vous aurez sans doute besoin de lire la valeur des constantes (print). Par exemple :  LoRa.CODING_4_5 , LoRa.ALWAYS_ON, LoRa.BW_125KHZ, etc. [2].

Utilisez la commande print pour voir l’effet de la modification des paramètres. Exemple :

print('Coding rate {}'.format(lora.coding_rate()))

À chaque modification du code, vous devez charger le nouveau code (sync project to device dans Pymakr:Projects), puis  rebooter le device (ctrl+alt+f sur VSC ou bouton reset de la Lopy).

Les paramètres typiques d’une transmission LoRa en Europe sont détaillés dans [8].

1) Récupérer les paramètres LoRa d’une transmission

À partir de la méthode lora.stats(),

1. Du côté TX,  identifiez les paramètres suivants liés à l’émission de data:  spreading factor, puissance émise, fréquence utilisée, time on air
2. Du côté RX, identifiez les paramètres liés à la réception de data : spreading factor, RSSI, SNR

Faire attention aux unités

À partir d’autres méthodes (à chercher sur  [2]), identifiez :

1. bande de transmission,
2. coding rate,
3. power mode,
4. taille de préambule

Pour cela, vous aurez sans doute besoin de lire la valeur des constantes (print). Par exemple :  LoRa.CODING_4_5 , LoRa.ALWAYS_ON, LoRa.BW_125KHZ, etc. Ou bien consultez [2].

2) Faire varier le RSSI

Dans cette partie, nous supposons que vous avez « appairé » 2 Lopy ensemble (A et B), en particularisant la transmission. Exemple ci-dessous. 

Côté TX (A) :
s.send('PingA')
Côté RX (B) :
if s.recv(64) == b'PingA'

En modifiant l’environnement de transmission

Exemple 1 : antenne couchée ou debout

Exemple 2 : éloigner les 2 noeuds, placer les noeuds derrière des objets, etc. Si vous utilisez votre PC, sortez de la salle ! Allez à l’étage (Archipel), ou allez à l’extérieur.

Laissez passer plusieurs trames et observez sur plusieurs trames avant de changer l’environnement.

Quel impact sur le RSSI  côté RX B ? Expliquez.

En arrêtant l’émission du Pong

Côté RX B, commenter la  partie :
s.send('PongB')

pour arrêter l’émission du Pong. Chargez le code, puis ré-initialisez les 2 Lopy.

Quel impact sur le sftx côté RX ? sur le time on air ? Expliquez.

Quel impact sur le RSSI et le sfrx côté TX  A ? Expliquez.

En modifiant la puissance d’émission

Quelle est la puissance d’émission par défaut ? Diminuez la puissance d’émission d’un des 2 devices et observez le RSSI de l’autre côté.

Issu de la documentation Pycom [9] :

Vérifier les RSSI typiques

À l’aide de la data sheet ([5] p.20), vérifiez que les RSSI observés sont typiques d’une transmission LoRa, en comparant les RSSI observés avec les RSSI limite (receiver sensitivity). Attention au spreading factor utilisé.

3) Faire varier le time on air

En faisant varier la taille du message

Modifiez la taille du message envoyé pour faire varier le time on air.

Calculez le nombre d’octets (bytes) de votre message [7]

À l’aide du calculateur https://loratools.nl/#/airtime [4],  des paramètres de transmission et du nombre d’octets du message, calculez le time on air. Comparez-le au  time on air observé.

Quel est le duty cycle pour la bande ISM Europe ? Comment la taille du message influence le temps d’attente entre 2 envois ? [6]

Donnez la valeur du duty cycle pour votre message telle que calculée  dans [4]et vérifiez que cela correspond bien au duty cycle de la réglementation.

En faisant varier le coding rate

Quel est le time on air pour un coding rate à l’émetteur de 4/5 ? Idem pour 1/2. Déduisez quel est l’impact du coding rate sur le time on air.

Quel est l’avantage d’un coding rate de 1/2 par rapport à celui de 4/5 ?

4) Faire varier le spreading factor

Changez le spreading factor à l’émetteur de 7 à 8 : à partir du constructeur à l’initialisation, ou à partir de la méthode lora.sf()

Observez le récepteur. Pourquoi le message n’est-il pas reçu ?

Rendez cohérent le spreading factor du côté du récepteur (sf=8).

Observez  les variations sur le time on air. À partir de la formule de calcul du Time On Air, montrer que ce dernier double lorsqu’on augmente le SF d’un point.

Comparez la sensibilité minimale donnée dans la datasheet ([5], p.20) avec les RSSI mesurés pour différentes valeurs du SF. Pourquoi le RSSI diminue-t-il lorsque le SF augmente ?

5) Avant de partir

• formatez la Lopy4 :

import os 

os.fsformat('/flash')

• rangez la carte dans le carton en faisant attention au câble de l’antenne

Prochaine étape : mettre en place une communication via le réseau The Things Network

Mini-projet capteur météo et LoRaWAN avec la Lopy4

Références bibliographiques

[1] https://gitlab.imt-atlantique.fr/clanglai/tp-lora-cooc

[2] https://docs.pycom.io/firmwareapi/pycom/network/lora/

[3] https://www.mobilefish.com/developer/lorawan/lorawan_quickguide_tutorial.html

[4] https://loratools.nl/#/airtime

[5] https://docs.pycom.io/gitbook/assets/specsheets/Pycom_002_Specsheets_LoPy4_v2.pdf

[6] https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/

[7] « Fichier:ASCII-Table-wide.svg — Wikipédia ». https://commons.wikimedia.org/wiki/File:ASCII-Table-wide.svg(consulté le oct. 19, 2021).

[8] « LoRa Regional Parameters », The Things Network. https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/ (consulté le 26 septembre 2023).

[9] « 5.2.2.4 LoRa · Pycom Documentation ». https://alepycom.gitbooks.io/pycom-documentation/content/chapter/firmwareapi/pycom/network/lora.html (consulté le 26 septembre 2023).

Démarrer avec Lopy4 Pycom

Envoyé par Sylvie le 27 Sep 2021 dans Projets, Trucs & astuces, TAF COUAD | 0 commentaire

Un petit tutoriel pas à pas pour bien démarrer avec les cartes disponibles au fablab la Lopy4 de Pycom.
Plus d’infos  ici

et des tutos ici

Merci à Sylvain Montagny de l’Université Savoie Mont Blanc pour l’accès à son Mooc  LoRa et LoRaWAN pour l’internet des objets 

Etape 1 : installation des outils logiciels

Les PC du fablab sont déjà installés avec Visual Studio Code. L’extension Pymakr2 est également installée. NE FAITES PAS d’UPDATE de version. Si vous allez installer cet outil sur votre PC perso, suivez les indications ci-dessous.

https://docs.pycom.io/gettingstarted/software/vscode/

Installation de Visual Studio Code  et de l’extension Pymakr qui permet de reconnaitre la carte.

Il existe parfois des problèmes de compatibilité entre VSC et Pymakr notamment lors des sauts de version de VSC avec une mise à jour de Pymakr qui tarde un peu.  Dans ce cas, vous pouvez rétrograder la version de VSC pour garder la compatibilité.

Selon la distribution Linux, peut nécessiter l’installation de pyserial.  et de dialog.

python -m pip install pyserial (ou python3 -m pip install pyserial)
sudo apt-get install dialog

Nécessite également NodeJS (sur Linux, à installer à partir d’un dépôt, sinon ici from the NodeJS website.).

apt-get install -y nodejs

 Etape 2 : se connecter à la LoPy4 et lui donner quelques instructions 

Pour comprendre l’utilisation de Pymakr dans VS Code (qui n’est pas si simple …), il faut consulter le Get Started et le what’s new.

Suivre les instructions pour communiquer avec la carte et tester des instructions en micro python directement sur la LoPy4 via le port USB :

https://docs.pycom.io/gettingstarted/

Connecter le device

Connectez le device sur un port USB, Sélectionnez le device dans VSCode/Pymakr:Devices, puis cliquez sur connecter le device (éclair). Puis cliquez sur Create terminal. Une fenêtre terminal doit s’ouvrir avec l’invite de commande >>> qui vous permet d’envoyer des commandes au device.

Vous pouvez tester ces instructions :

import pycom

pycom.heartbeat(False)

pycom.rgbled(0x330033)

Modifiez le code RGB pour changer de couleur à la led.

Quelques raccourcis et commandes bien utiles …

REPL (Read Evaluate Print Loop) est le nom donné à l’invite interactive de MicroPython accessible sur les appareils Pycom. Il permet de lancer des commandes et de tester du code Micro Python.

Voici les raccourcis clavier les plus utiles :

Ctrl-C : interrompt le code actuel en cours d’exécution, pour récupérer l’invite REPL >>>

Ctrl-D : sur une ligne vide, soft reset (pour un Hard reset, bouton noir RST juste à côté de la led RGB du LoPy)

Ctrl-F  : effectue un « safe-boot » du périphérique sans relancer boot.py et main.py

Tab : auto-complétion

Vous pouvez les retrouver en cliquant sur l’onglet Extensions puis Pymakr > Details.

Vous pouvez également utiliser le menu contextuel de votre device (dans PYMAKR:DEVICES) : Stop script, Hard reset (pour lancer le code de la flash), Safeboot device (pour initialiser la carte sans lancer le code de la flash).

Si vous n’avez plus accès à l’invite de commandes REPL >>> parce que votre code a planté la carte, vous pouvez tout d’abord essayer le safe boot (menu contextuel du device, ou safe boot sur la carte voir ci-dessous).

Pour le safe boot sur la carte directement, appuyer en même temps sur le reset de la LoPy et le safe boot de l’expansion board (voir image ci-dessous) puis relâcher d’abord le reset de la LoPy (la led flashe orange).

Puis, une fois l’invite REPL récupérée,  vous pouvez ré-initialiser la mémoire flash [5] :

import os
os.fsformat('/flash')

L’appui sur le bouton reset de la LoPy ré-initialise la carte mais relance le code chargé sur la mémoire flash !

Etape 3 : tester des exemples

Maintenant vous allez créer un projet Pymakr et y placer le code à charger sur le device. Dans le dossier de votre projet, il y aura les fichiers suivants : main.py , boot.py, pymakr.conf, et un dossier lib.

My-project
|-lib
|  |- some_library.py
|-boot.py
|-main.py

Connecter le device

Sélectionnez le device dans VSCode/Pymakr, puis cliquez sur connecter le device. Une fenêtre terminal doit s’ouvrir avec l’invite de commande >>> qui vous permet d’envoyer des commandes au device (comme dans l’étape 2).

Créer le projet Pymakr

Dans VSCode/Pymakr, créez un nouveau projet Pymakr (Pymakr:Projects, create new project) et choisissez le dossier (ex : Documents) qui contiendra votre projet. Project name = nom du projet et nom du dossier qui contiendra les sources (ex : My-Project). Validez par entrée. Validez l’emplacement du projet (ex : Documents/My-Project) Choisissez le template empty project. remplacez empty project dans pymakr.conf par le nom de votre projet (ex : My-Project, utilisez le même nom que le dossier). Associez le device qui est branché sur l’ordinateur avec le projet (ADD DEVICES).

Compléter le main.py

Au moment de la création du projet, 3 fichiers ont été créés : main.py, boot.py et pymakr.conf.

Modifiez main.py en insérant le code que vous voulez tester (cf. 1er test ci-dessous avec le projet RGBLed)

Charger le device avec le code du projet (cf. 1er test ci-dessous)

Dans VSCode/Pymakr:Projects, sélectionnez le device associé au projet et cliquez sur sync project to device.

Une fois le code chargé, il faut faire un hard reset. 2 options : bouton à côté de la LED (reset de la Lopy), ou sur les … du device dans VSCode/Pymakr:Devices choisir Hard reset device.

Si le code est constitué d’une boucle infinie, alors vous n’avez plus accès à l’invite de commande. Le device est « occupé ». Pour retrouver la main, Ctrl+alt+C dans le terminal. Le code étant chargé dans le device, vous pouvez le relancer par un hard reset. De même si vous déconnectez le device de l’ordinateur, puis si vous le remettez sous tension, le code va se relancer automatiquement. Cela peut-être un problème si le code fait planter votre carte. Dans ce cas, il faut effectuer un safe boot dès que la mise sous tension de la carte (voir à l’étape 2).

1er test : utiliser la led RGB disponible pour vérifier que vous pouvez charger un programme sur la LoPy4

Le code est disponible ici [1].

2e test : récupérer l’adresse MAC LoRa du noeud

from network import LoRa

import binascii

lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868)

print(binascii.hexlify(lora.mac()).upper())

Vous en aurez besoin pour le TP2.

Etape 4 Constructeur et méthodes en lien avec LoRa pour la LoPy4

Sur cette page [4], on trouve des méthodes permettant d’initialiser les paramètres LoRa de la LoPy et de récupérer ou de modifier un certain nombre de paramètres.

1. à partir de la datasheet de la LoPy4 [6], cherchez :
   1. le nom du chip Semtech qui réalise la transmission LoRa ;
   2. la sensibilité pour les spreading factor de 6 à 12 pour la bande 125 kHz (LNA Boost for band 1 à 868 MHz) ;
2. à partir de la page [4], identifiez les paramètres que vous pouvez modifier en mode LoRa (dit LoRa RAW ou LoRa MAC).
3. Faites la même chose pour le mode LoRaWAN.

Etape 5 : Say Hello! et paramétrage du LoRa MAC

Nous allons maintenant tester une transmission (TX -> RX) dite LoRa MAC ou LoRa RAW parmi les LoPy de la salle.

Le code est disponible ici [2].

Toutes les LoPy vont émettre puis recevoir des trames. Il faut donc au moins 2 LoPy qui émettent et reçoivent en même temps. Une boucle while avec un délai aléatoire est utilisée pour minimiser les risques que les deux LoPy transmettent en même temps.

1. Insérez votre prénom dans le code. Exemple : ‘Hello I am Charlotte!’  Vérifiez qu’une ou plusieurs LoPy de la salle ont bien reçu votre message !
2. En utilisant la méthode lora.stats(), affichez les paramètres de la transmission LoRa MAC. Notez le RSSI, le spreading factor (tx et rx), le tx-power, et le time on air sur le TX et le RX. Comparez le RSSI avec la sensibilité récupérée dans la data sheet à l’étape 4.Pourquoi le RSSI est-il à 0 sur le TX ?
3. Il est possible de changer les paramètres de la transmission LoRa MAC en ajoutant des paramètres dans le constructeur de la classe LoRa. Changez par exemple le coding rate à LoRa.CODING_4_8. Observez la modification du tx_time_on_air. Il est possible que cela change également le RSSI sur le device RX. Cela dépend des conditions de transmission. Vérifiez.

Note : lorsque vous modifiez votre code,  et si votre carte est bloquée, effectuez un safe boot (cf. Etape 2) avant de faire upload.

Avant de partir

• formatez la Lopy4

import os

os.fsformat('/flash')

• rangez-la dans le carton en faisant attention au câble d’antenne

TP Pour aller plus loin dans l’utilisation de la Lopy4 et de la couche PHY LoRa

consultez l’article https://telefab.fr/2021/10/04/aller-plus-loin-avec-la-lopy4/

Références bibliographiques

[1]https://docs.pycom.io/tutorials/basic/rgbled/

[2] https://docs.pycom.io/tutorials/networks/lora/lora-mac/

[3] https://docs.pycom.io/tutorials/networks/lora/module-module/

[4] https://docs.pycom.io/firmwareapi/pycom/network/lora/

[5] https://docs.pycom.io/gettingstarted/programming/safeboot/

[6] https://docs.pycom.io/gitbook/assets/specsheets/Pycom_002_Specsheets_LoPy4_v2.pdf

Robot IA

Envoyé par a20didie le 10 Juin 2021 dans Portfolio, À la une, Blog | 0 commentaire

Robot IA – Synthèse du projet CodeV

I – Contexte/Projet/Equipe

Dans un monde où la robotique et l’intelligence artificielle sont en plein essor, il est intéressant et nécessaire d’envisager des projets de petite envergure afin d’acquérir les bases de ce domaine, tels que le machine learning. Ce projet consistant à équiper un petit robot motorisé (plateforme JetBot) d’une caméra et lui implanter un code lui permettant de mémoriser et parcourir différents circuits adaptés est alors parfait pour commencer son chemin dans le monde de la robotique et de l’implémentation robotique.

Les objectifs du projets sont donc essentiellement de prototyper à taille réduite ce qui pourra par la suite être adapté à taille réelle en voiture autonome, avec un robot capable de se déplacer d’un point A à un point B de manière totalement autonome, tout en analysant son environnement (les panneaux, le marquage au sol…).

L’équipe sur le projet est composée de 4 étudiants de FISE A1 : Arthur Didier, Aymen Kallala, Violette Castells et Marianne Bellery. Celle-ci a été guidée et encadrée par Sylvie Kerouedan et Nicolas Farrugia.

II – Réalisation

• Environnement

La création de l’environnement est passée par la conception et l’impression de panneaux. Les visuels ont tous été créés sur PhotoShop dans un style se rapprochant au maximum des panneaux de circulation réels à l’échelle du robot. Ils ont ensuite été imprimés sur du papier collant par les encadrants FabLab. La structure des panneaux a quant à elle été produite sur Tinkercad puis imprimée grâce aux imprimantes 3D du FabLab.

En parallèle le besoin d’avoir une route modulable étant évident, celle-ci à été conçue selon un système de pièces de puzzle. De même les visuels ont été réalisés sur PhotoShop de manière à évoquer clairement une route aux utilisateurs, puis imprimés par le FabLab sur des papiers épais selon un format 50cmx50cm.

• Code

Le code s’est divisé en deux parties distinctes : l’implémentation du suivi de la route et l’implémentation de la reconnaissance des obstacles et limitations. La première permettant au robot d’avancer sur la route en limitant le franchissement des lignes continues blanches. La seconde faisant en sorte que le robot reconnaisse son environnement et agisse en fonction des objets qu’il rencontre. Les types d’objets étant également en deux sous catégories : les obstacles et les panneaux de circulation.

L’implémentation du code est également passée par la collecte de données.

Quant aux obstacle l’architecture de décision finale est la suivante :

• Validation

Afin de valider les avancées du projet une liste de tests a été réalisée. Les résultats de celle-ci sont présentés dans le tableau ci-dessous :

III – Composants de l’ensemble environnement + robot

Pour le robot :

Le robot se basera sur la plate-forme Jetbot développée par Nvidia. Avec notamment comme composants ceux du kit JetBot Nano et une batterie.

Pour les pièces puzzles la structure générale est la suivante :

IV – Protocole d’utilisation et scénario

Scénario :

L’utilisateur souhaite que le robot se déplace d’un point A à un point B suivant une route avec des contraintes (marquage au sol, panneaux de signalisation…) appelé ici environnement.

• L’utilisateur pose le robot au sol dans cet environnement au point A. L’utilisateur allume ensuite le robot qui devra alors parcourir le circuit de manière autonome.
• Si le robot arrive dans une impasse il devra soit faire demi-tour s’il constate un espace suffisant pour l’effectuer ou reculer jusqu’à l’intersection précédente dont le choix a mené à l’impasse afin de prendre une nouvelle route.
• Lorsque le robot rencontrera un obstacle, si l’espace est suffisant pour passer alors le robot contournera l’obstacle en laissant une distance minimale d’1 cm entre lui et l’obstacle. Si l’espace restant est trop petit alors le robot devra soit faire demi-tour soit reculer jusqu’à l’ancienne intersection comme expliqué précédemment dans le cas de l’impasse.
• Lorsque le robot arrive au niveau d’un passage piéton il adoptera une vitesse d’avance réduite.
• Lorsqu’un piéton est sur le passage alors le robot devra s’arrêter à au moins 1 cm du passage piéton.
• Lorsque le robot rencontre un des 4 panneaux obligatoires, il suivra l’indication.
• Si un bug de reconnaissance d’obstacle ou de prise de décision par le robot est constaté par l’utilisateur, celui-ci doit l’arrêter et le repositionner 10 cm en amont sur le circuit. Puis il indique par la procédure qui sera développée et donnée dans le mode d’emploi, qu’il y a une erreur afin que l’algorithme d’apprentissage puisse le prendre en compte.
• Une fois arrivé au point B, le robot s’arrête et l’utilisateur éteint le robot.

V – Perspectives et pistes d’amélioration

Finalement, ce projet est voué à être transmis et amélioré par de futures équipes. Nous avons effectivement fait en sorte de rentre le code le plus clair possible avec une architecture intuitive pour les différentes parties.

Pour poursuivre ce projet, il faudrait mettre en commun l’ensemble du code (suivi de route et détection des objets), pour que le robot soit capable, sur un circuit complet, à la fois d’éviter les obstacles, de reconnaitre les panneaux et suivre la route. En effet, il est capable de tout faire mais chaque code fonctionne séparément des autres. Cela devra aussi être accompagné d’une amélioration de certains algorithmes afin de garantir un comportement plus robuste et plus juste dans les différents cas d’utilisation.

De plus, on pourrait tenter de remplir les fonctions complémentaires que nous avions évoquées dans le cahier des charges. En particulier, les fonctions liées à l’esthétique du robot, au bruitage ainsi qu’au rajout d’options secondaires vis-à-vis de la circulation du robot sur une route. On pourrait aussi rajouter dans la base de données de nouveaux obstacles et panneaux. Par exemple, on pourrait imaginer rajouter dans la base de données des bonhommes, de différentes tailles et formes modélisant les piétons. On pourrait aussi créer de nouveaux types de panneaux de circulation.

Enfin, il serait aussi intéressant d’améliorer les performances du robot, par exemple, son autonomie ou encore la puissance de ses moteurs.

Objet permettant la visualisation de l’état mer / météo

Envoyé par c20lerou le 9 Juin 2021 dans Portfolio, Projets, À la une | 1 commentaire

Nous sommes quatre étudiants en FISE A1 d’IMT Atlantique, et nous avons eu comme projet CODEV de réaliser un dispositif permettant de visualiser l’état de la mer et de la météo, au niveau de la plage du Mengam.

Pour cela, nous avons conçu une boîte qui retranscrit de manière imagée et facilement compréhensible les données météorologiques. Le boîte en bois est composée de quatre modules principaux. 

Le premier représente un drapeau qui traduit, par son orientation, la direction du vent, et par son dressage, l’intensité du vent. Pour ce faire, nous avons utilisé des moteurs pas-à-pas ainsi que du matériel fourni par le Téléfab. 

Le deuxième module modélise l’intensité de la houle grâce à un dispositif de 3 niveaux de vagues qui sont éclairées en bleu en fonction de la hauteur réelle de houle. Afin d’imprimer les vagues, nous avons utilisé le logiciel Core-idraw qui est directement lié à la découpe laser du Téléfab. Cette dernière nous a aussi servi à découper dans des planches de peuplier notre boite avec tous les détails souhaités. 

Le troisième module indique s’il fait beau ou s’il pleut, à l’aide d’un soleil et de gouttes de pluie rétro éclairés. Le Téléfab nous a à nouveau fourni les néo pixels et les cartes arduino nécessaires.

Enfin, le quatrième permet d’interpréter toutes les données récupérées depuis internet pour indiquer si l’on peut pratiquer, ou non, un sport nautique (voile, surf ou paddle).

Ce projet a été très enrichissant pour nous tous. D’une part, il nous a permis de travailler en groupe pour un client, et par conséquent de découvrir les notions de cahier des charges, de planning et de timing à respecter. D’autre part, nous avons appris à manipuler le matériel du TéléFab (imprimante laser, cartes arduino etc.) ce qui nous resservira pour des projets futurs.

Cyprien, William, Aurélien et Alexandra

Réalisation d’une Puzzle Box

Envoyé par p20coste le 9 Juin 2021 dans Portfolio, Projets, À la une | 0 commentaire

Alors que nous sommes de plus en plus amenés à nous occuper en intérieur, surtout ces derniers temps au vu du contexte sanitaire, les jeux de réflexion sont un excellent moyen de se divertir en intérieur en occupant son esprit. En tant qu’étudiants ingénieurs en première année de IMT Atlantique, nous voulions mettre à profit nos connaissances en mettant au point un projet de jeu d’énigme interactif et innovant, comportant une part d’électronique.

Dans le cadre de l’UE CODEV 2021 notre équipe de 4 étudiants FISE A1 à IMT Atlantique a  proposé son propre projet (Projet 53) consistant en la réalisation d’une Puzzle Box.

Photo de la puzzle box rendu final 1

Photo de la puzzle box rendu final 2

Une puzzle box est un jeu qui vient sous la forme d’une boîte qu’il convient d’ouvrir en résolvant différentes énigmes ou casses-têtes, la plupart du temps mécaniques.
Le projet de puzzle box présenté ici consiste en la réalisation d’une boîte à énigme s’adressant à un public d’étudiants scientifiques. La puzzle box réalisée comporte une particularité qui fait son originalité par rapport aux autres puzzle box du marché : elle comporte une partie électronique.

Les objectifs de notre projet étaient triple :

-Réaliser une puzzle box
-Intégrer à la puzzle box une partie électronique, ce qui permet notamment une certaine modulation de celle ci et lui insuffle son originalité
-Adapter notre puzzle box à un public cible (les étudiants de IMT Atlantique) afin de les divertir au mieux

L’intégralité de la réalisation de notre projet a eu lieu dans l’enceinte du FabLab de IMT Atlantique à Brest.

Nous avons dans un premier temps sélectionné les énigmes que nous souhaitions réaliser. Puis la boîte a été modélisée en 3D pour résoudre les problèmes d’incorporations et d’espace entre les énigmes avant de passer à la réalisation pratique avec les outils à notre disposition au FabLab.

Photo de la puzzle box avant l’assemblage de ses composants

Photo de l’intérieur de la puzzle box

La boîte a, tout au long de son processus de conception, fait l’objet de tests poussés, par les membres du projet ainsi que des personnes extérieures, afin de tester chaque ajout.

Finalement, la boîte comporte un jeu de mémoire interactif basé sur des boutons lumineux et sonores, un tiroir aimanté dissimulé, et un tiroir à débloquer par action mécanique.
Des indices sont disséminés à chaque étape de la résolution de la boîte. Ils permettent, une fois rassemblés, de résoudre l’ultime énigme permettant l’ouverture de la boîte qui laisse découvrir la récompense qu’elle contient….

La puzzle box ouverte et sa récompense

COSTE Paul, FOUREST Lucas, GOSSE Aurélien, LOYER Baptiste

Fabrication du Kit Archilab

Envoyé par mmenoret le 21 Jan 2021 dans Projets, À la une | 0 commentaire

Grâce à l’article détaillé du LabFab pour créer son propre kit Archilab, nous avons réalisé pour le centre d’Appui et de Ressources pour l’Apprentissage et l’Enseignement (CARÆ) d’IMT Atlantique deux jeux complets d‘Archilab, un outil pour réfléchir et co-construire des espaces.

La boîte de jeu n’ayant pas été encore conçue j’ai pu en créer une grâce à l’outil de conception de boîtes très complet: Boxes.py. La boîte a été faite en medium 6mm, mais le plus simple est d’adapter votre modèle en fonction de l’épaisseur de bois utilisée. Voici les paramètres utilisés, il suffit de cliquer sur le lien, puis cliquer sur « Générer » et d’enregistrer sous le fichier .stl qui s’affiche.