Différences entre versions de « Projets:Magic Control 2021 »

De wikilab
(→‎Architecture hardware : ajout brochage rpi)
Ligne 125 : Ligne 125 :
  
 
[[File:schema_systeme_general_architecture_hardware.png|1200px|Schéma général d'architecture hardware]]
 
[[File:schema_systeme_general_architecture_hardware.png|1200px|Schéma général d'architecture hardware]]
 +
 +
[[File:brochage_rpi_magic_control.png|1200px|Utilisation des broches du Raspberry Pi 3]]
  
 
=== Architecture logicielle ===
 
=== Architecture logicielle ===

Version du 21 octobre 2021 à 10:29

Equipe

  • Porteurs du projet : Jonathan (MyHumanKit), accompagné par Romane et Marine.
  • Contribut/eur/rice/s : Christophe (INRIA), Fred (ArianeGroup), Gweltaz (Les portes logiques), Mathilde (ArianeGroup), Mélanie (ArianeGroup), Olivier (ArianeGroup), Tanguy (ArianeGroup).
  • Fabmanageuse référente : Delphine (MyHumanKit).
  • Documentation : Pierre (Flossmanuals FR).

Description du projet

Réaliser un contrôle d'environnement R-net pour fauteuil électrique s'interfaçant avec des périphériques R-net existants (JSM, système applicatif).

Génèse du projet

Ce projet a démarré au Fabrikarium 2019, organisé avec ArianeGroup sur le site des Mureaux. Cette première étape a permis de développer des premiers prototypes de joystick à faible force (minijoy) et de mettre au point la communication avec le fauteuil par le protocole R-net.
Au Fabrikarium 2020, le projet a été poursuivi en améliorant le joystick par deux prototypes, ainsi qu'en approfondissant l'analyse des trames de communication R-net.

État technique

Plusieurs prototypes existent pour le joystick à faible force. L'interface CAN/R-net est fonctionnelle sur carte raspberry pi.

Documentation des étapes précédentes sur le wiki :

Objectifs de cette 3e étape

Objectifs prioritaires

  • (groupe 1) Réglage de la calibration du mini-joystick (minijoy)
  • (groupe 1) Test de la séquence d'initialisation du fauteuil de Jonathan
  • (groupe 1) Ajout d'un bouton d'arrêt d'urgence
  • (groupe 2) Emulation de souris (pour androïd ou apple)
  • (groupe 3) Ajout d'un bouton pour donner le contrôle au Raspberry Pi
  • (groupe 3) Design / expérience utilisateur

Objectifs secondaires

  • Ajout d'un switch pour basculer entre JSM et minijoy : mode «passe-plat» ou mode «minijoy»
  • Reverse du protocole de contrôle des vérins
  • Ajout d'un contrôle de la vitesse maximum et des vérins
  • Contrôle d'environnement par application (androïd, ou par techno web, plus portable)
  • Ajout d'un écran de contrôle d'environnement
  • Ajout de fonctions domotiques

Réalisation des éléments par étape

Mise à jour du schéma du magic joystick

Magic joystick 2021 : réalisé par Christian à distance

schéma du magic joystick 2021

Fichiers kicad : fichiers kicad (zip)

Fichiers kicad

Fabrication des connecteurs

Fabrication des connecteurs du Magic Joystick 2021

Mise à jour du schéma du air joystick

Air joystick 2021 : réalisé par Christian à distance

schéma du air joystick 2021

Fichiers kicad : fichiers kicad (zip)

Groupe 1, capture des trames R-net

Mise en place d'une procédure de capture des trames d'initialisation du fauteuil de Jonathan.

  • Se connecter au Pi en SSH
  • Dans un terminal de commande
git clone https://github.com/myhumankit/MagicJoystick2020.git
cd ./MagicJoystick2020/
git branch -a
git checkout -b experimental origin/experimental
cd ./can2RNET/
python3 ./setup.py install
cd ..
cd ./RnetMitm/
python3 ./RnetIntercept.py --dual

Pourquoi cherche-t-on cette séquence d'initialisation ?

La séquence d'initialisation permet de simuler et remplacer un JSM par Magic Control, il faut donc pouvoir reproduire cette séquence.
L'étude d'un premier fauteuil avait permis d'enregistrer une séquence d'initialisation, mais un second fauteuil ne démarre pas avec cette séquence.
Donc les séquences varient selon les modèles, il faut pouvoir les enregistrer pour les rejouer ou chercher une méthode alternative.

Groupe 1, bouton d'arrêt d'urgence

Bouton installé en coupure sur le bus R-net : l'interruption des signaux du watchdog stoppe les commandes moteur. Interrupteur de type DPST utilisé en ON/OFF.

Voir Magic Joystick 2020 pour schéma, composants et fichiers de fabrication du boîtier.

Groupe 2, simuler une souris bluetooth

L'objectif est de permettre en appuyant sur un bouton d'utiliser le joystick du fauteuil comme pointeur de navigation dans l'interface du contrôle d'environnement. Le développement s'appuie sur le script d'émulation développé et documenté par Thanh, en l'adaptant au projet :

La procédure d'installation est décrite sur le dépôt github d'origine.

Groupe 3, calibration logicielle du magic joystick

TODO / Refonte du code

Groupe 3, design utilisateur du contrôle d'environnement

Schéma actuel de la navigation dans l'application de contrôle d'environnement (joystick : navigation, clic : sélection)

schéma actuel de l'application de contrôle d'environnement

Détails sur le fichier pdf : schéma de l'application de contrôle d'environnement (pdf)

Réalisation du prototype complet

Architecture hardware

Schéma général d'architecture hardware

Utilisation des broches du Raspberry Pi 3

Architecture logicielle

Après avoir examiné plusieurs scénarii, le choix de l'équipe se porte sur un broker MQTT, qui permet à chaque brique logicielle de publier ou de s'abonner à des flux de données.

Schéma général d'architecture logicielle

Composants et circuits électroniques utilisés

Carte Raspberry Pi 3 model B+

Pour ce projet, la carte est dotée d'un système Debian 10 Buster sur carte micro-SD 8 GO

https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus/

Carte PiCAN2 Duo

Carte électronique additionnelle pour Raspberry Pi 3/4 avec double interface pour bus CAN et transformateur d'alimentation (SMPS) capable de fournir 3A. Fabriquée par SK Pang.

https://www.skpang.co.uk/collections/hats/products/pican2-duo-can-bus-board-for-raspberry-pi-4-with-3a-smps

photo de la carte PiCAN2 Duo

Lexique

Broker MQTT : Le broker MQTT est un serveur qui reçoit tous les messages des clients et les aiguille vers les clients de destination appropriés.

CAN (Controller Area Network) : Bus de communication série utilisé en électronique, particulièrement dans l'industrie automobile. Il fonctionne sur le principe du multiplexage ou chaque équipement connecté communique avec tous les autres. https://fr.wikipedia.org/wiki/Bus_de_donn%C3%A9es_CAN

JSM (Joystick Module) (module électronique d'un fauteuil) joystick d'assistance à l'arrière du fauteuil, prioritaire sur le contrôle du déplacement.

MQTT (Message Queuing Telemetry Transport) : protocole de messagerie *publish-subscribe* basé sur TCP-IP (cf. MQTT sur wikipedia) + d'infos : https://mqtt.org/

PiCAN : carte additionnelle pour Raspberry Pi, permettant de s'interfacer à un bus CAN. Il en existe plusieurs variantes, celles utilisées pour ce fabrikarium est une PiCAN2 Duo.

R-net : Le protocole R-net définit des commandes qui passent sur un bus CAN. Il a été mis au point en 2011 par PGDT (PG Drives Technology) pour le contrôle des fauteuils électriques. Il s'agit d'un protocole propriétaire, en 2016 des informations sur ce protocole ont été trouvées par Stephen Chavez par ingénierie inverse pour le projet https://github.com/redragonx/can2RNET.

Raspberry Pi : nano-ordinateur sur carte électronique unique équipé d'un système linux Debian.

Trame CAN : série de bits envoyée sur le bus CAN et interprêtée par le JSM et le contrôleur de moteur.

Watchdog : trame périodique surveillée afin de détecter une éventuelle rupture de communication.

Journal du projet

Premier jour, matin

  • Présentation des étapes précédentes du projet.
  • Présentation de l'état technique actuel.
  • Définition des objectifs primaires et secondaires du fabrikarium.
  • Répartition en 3 groupes pour un premier passage en revue des solutions.

Premier jour, après-midi

Poursuites des pistes définies le matin pour les 3 groupes

Synthèse présentée à la présentation de fin de journée

Définition

Programme des 3 groupes de travail

Programme des 3 groupes

Jour 2, matin

  • Amélioration de l'algorithme de calibration (calculs de matrices).
  • Design graphique de l'interface utilisateur du nouveau contrôle d'environnement.
  • Essai (concluant!) d'une nouvelle méthode d'intégration sur le bus R-net.
  • Définition du système client-serveur pour le contrôle d'environnement.(point d'accès wifi, serveur flask).
  • Programmation de l'interface web de contrôle d'environnement.
  • Mise au point de l'architecture hardware.

Jour 2, après-midi

  • Réflexion sur l'architecture logicielle, plusieurs pistes sont esquissées.
  • Poursuite du design graphique du contrôle d'environnement.
  • Développement logiciel par itérations et POCs

Document de la restitution du jour 2 : présentation (pdf)

Jour 3, matin

  • Petit point : jusqu'où essaie-t-on d'aller aujourd'hui ?