Add a Raspberry Pi gateway between the computer and the components#11
Add a Raspberry Pi gateway between the computer and the components#11VIL-CIEL wants to merge 11 commits into
Conversation
… infra versioning
Sprint 1 de la fusion des plugins raspberrypi3 / raspberrypizero dans
pymodaq_plugins_raspberry.
Infrastructure
- Ajout de version.json (5.1.0), CHANGELOG.md et CONTRIBUTING.md
(numérotation SemVer, stratégie de branches/tags, plan des sprints).
Serveur Raspberry (src_raspberry/, non packagé)
- Topologie en couches, chaque maillon étant une classe interchangeable
derrière une interface, le main restant le seul assembleur :
- ITransport / ZmqServer : communication PyMoDAQ (ZeroMQ), réseau et
framing uniquement ;
- IRequestHandler / JsonRequestHandler : décodage et routage des
requêtes JSON, sans aucun accès matériel ;
- IHardwareBackend / HardwareBackend : communication avec les capteurs
et actionneurs ;
- main.py : boucle principale qui instancie et câble les trois couches.
- Sépare la gestion des requêtes de la communication matérielle,
auparavant mélangées dans CProtocolHandler.
- Isole le transport ZeroMQ de la logique de framing/décodage.
- Comportement fonctionnel identique au serveur Raspberry Pi 3 d'origine
(la fusion des bancs Pi 3 / Pi Zero arrive au Sprint 2).
Le plugin de base (src/, PiCamera, pyproject) n'est pas modifié.
…ilotés par config) Fusion des plugins raspberrypi3 / raspberrypizero — la différence entre bancs est désormais entièrement portée par la configuration. Ajouté - Pilote de capteur PT-100 (sonde via CAN ADS1115), enregistré dans SENSOR_DRIVER_REGISTRY (dépendance Adafruit importée localement). - Pilotes d'actionneurs interchangeables derrière l'interface CActuatorDriver, enregistrés dans ACTUATOR_DRIVER_REGISTRY et choisis par le champ 'driver' : - PWM : rapport cyclique (ex-banc Raspberry Pi 3) ; - DIGITAL : tout-ou-rien (ex-banc Raspberry Pi Zero). - config_examples/config_pizero.py : banc tout-ou-rien avec sonde PT100. Modifié - CActuatorManager instancie le pilote adapté à chaque actionneur au lieu d'un pilotage PWM codé en dur (modes mixables sur un même banc). - CActuatorConfig accepte un champ 'driver' (défaut PWM) ; pwm_frequency optionnel. - config.py documente le choix du pilote par actionneur. Supprimé - safety_monitor.py des plugins d'origine non repris (constantes de config inexistantes, jamais démarré par le main). Corrigé - Fonction morte build_sensor_map non reprise ; cartographie des capteurs unifiée dans HardwareBackend. - Indentation cassée et perte de pwm_frequency de l'ancien actuators.py Pi Zero résolues par le nouveau modèle de pilotes d'actionneurs.
…wer) Intègre côté package PyMoDAQ la partie client commune aux plugins raspberrypi3 / raspberrypizero, dans l'arborescence standard d'un plugin. Ajouté - hardware/Link_PMQ.py : client ZMQLink (lien ZeroMQ DEALER vers le serveur). - hardware/Config_Components.py : lecture des composants depuis la config TOML. - daq_move_plugins/daq_move_MoveRasp.py : plugin actionneur DAQ_Move_MoveRasp. - daq_viewer_plugins/plugins_0D/daq_0Dviewer_ViewRasp.py : plugin détecteur DAQ_0DViewer_ViewRasp. Modifié - resources/config_template.toml : section unifiée [Raspberry] (remplace [RaspPi3] / [RaspPiZero] des plugins d'origine). - pyproject.toml : ajout de la dépendance pyzmq (requise par ZMQLink). - Le plugin DAQ_2DViewer_PiCamera existant n'est pas modifié. Corrigé - f-strings à guillemets imbriqués identiques (Python 3.12+ uniquement) remplacés par une forme compatible Python 3.8+.
Première version « production » du plugin raspberry fusionné. Ajouté - README.rst : liste des instruments (MoveRasp, ViewRasp, picamera) et description du serveur Raspberry (src_raspberry/). Modifié - README.rst : auteurs, version PyMoDAQ requise (>= 5), cartes testées (Raspberry Pi 3 et Pi Zero). Vérifié - Conformité à tests/test_plugin_package_structure.py (conventions de nommage et méthodes obligatoires) ; aucune modification du test nécessaire. - Compilation de l'ensemble (serveur + package) et test d'intégration des deux bancs (PWM / DIGITAL) + lecture du template [Raspberry].
Les versions antérieures du dépôt (5.0.0, 5.0.1) sont taguées sans préfixe « v ». On aligne la documentation sur cette convention : les tags de production sont au format MAJEUR.MINEUR.CORRECTIF (ex. 5.4.1), sans préfixe « v ». - CONTRIBUTING.md : correction de la section Tags. - version.json : 5.4.1. - CHANGELOG.md : entrée [5.4.1].
Réécrit le README du point de vue d'un utilisateur du plugin (contrôle d'un dispositif expérimental / banc de test via un Raspberry), sans détailler l'historique interne du projet. Met en avant les trois axes d'adaptabilité : - communication PyMoDAQ <-> Raspberry (ZeroMQ par défaut, remplaçable) ; - communication Raspberry <-> composants (drivers capteurs/actionneurs par config) ; - ajout de nouvelles requêtes JSON côté PyMoDAQ et côté Raspberry. - version.json : 5.4.2. - CHANGELOG.md : entrée [5.4.2].
…spberry — version 5.4.3 picamera2 dépend de python-prctl (Linux-only), ce qui rendait `pip install` du plugin impossible sur la machine de contrôle Windows/macOS — pourtant nécessaire pour utiliser les plugins distants MoveRasp / ViewRasp via ZeroMQ. - pyproject.toml : picamera2 déclarée avec le marqueur `platform_system == "Linux"`. Le viewer PiCamera n'est alors disponible que sur le Raspberry ; l'auto-import PyMoDAQ ignore proprement son absence sur les autres systèmes. - version.json : 5.4.3. - CHANGELOG.md : entrée [5.4.3].
… version 5.4.4 - README.rst : ajout d'une note indiquant que le viewer PiCamera n'est disponible que sur Linux/Raspberry (dépendance picamera2), et que la machine de contrôle Windows/macOS installe le plugin sans ce viewer. - Nettoyage de la documentation et des commentaires : suppression des références internes peu compréhensibles hors contexte de développement (CHANGELOG, CONTRIBUTING, README serveur, docstrings). - version.json : 5.4.4 ; CHANGELOG.md : entrée [5.4.4].
|
This is really a nice and huge work! I see one flow though. You've built your raspberry plugins considering the raspberry as an external DAQ communicating with a computer while the plugins I developed so far are meant to run directly on the raspberry with pymodaq also on the raspberry. The Raspberry, especially the pi5 is powerful enough to run pymodaq and directly a workbench. I think it would be very good to be able to use your plugins also in this mode, I mean with pymodaq on the raspberry. This means the communication layer would be much simpler than the ZMQ. ot it could still be ZMQ but only with the IP being localhost or something. Do you think you could test this and update the doc and readme? |
seb5g
left a comment
seb5g
left a comment
There was a problem hiding this comment.
some modification to apply but overall it is very nicely written. I'm just quite afraid it will be tricky to maintain in the long run due to the use of the low level ZMQ. I'm wondering if this could be simplified by using the pyleco protocol we're already using in pymodaq (this is a communication protocol over ZMQ) but higher level!
|
|
||
| value = self.check_bound(value) | ||
| self.target_value = value | ||
| #value = self.set_position_with_scaling(value) |
There was a problem hiding this comment.
if you don't want people to use scaling/offset, make sure to hide the setting group in the ini_stage method, but I would recommend leaving the line
There was a problem hiding this comment.
thx to uncomment the line and to set the corresponding settings to unvisible
| self.controller: ZMQLink = None | ||
| self.selected_components = get_access_variables(config) # dict of all the selected components, sorted by address and pin | ||
|
|
||
| actuator_settings = self.settings.child('load_compo_group').child('load_actuator_group') |
There was a problem hiding this comment.
could be simplified as:
actuator_settings = self.settings.child('load_compo_group', 'load_actuator_group')
| except Exception as e: | ||
| logger.info(f"ERROR - NO ELEMENTS WITH NAME : {str(e)}") | ||
|
|
||
| detectors_settings = self.settings.child('load_compo_group').child('load_detector_group') |
|
By the way, would you be interested to come and present this work at the next PyMoDAQ days? They will be held from 7 to 9 october in Paris (orsay). It could be organised as a student work or something? I'm sure we can participate in terms of money if needed. Let me know but I find this project of your awesome and I'm glad someone is finally using pymodaq for studies! |
|
Ok, i will change some of this pieces of code The idea of presenting this plugin at PyMoDAQ Days strikes me as very interesting and exciting! But I think we could easily organise this for Saturday 8 October and Sunday 9 October, as it’s a weekend. Would I be on my own, or would my project colleagues be joining in as well (and/or my teacher) ? |
|
The majority of the requested changes have been made with the last commit, you can check my comments for the remaining changes that i didn't closed |
it's not during a weekend it's from wednesday to friday. And I'm not sure I understood, are you a student or a teacher? Could you give me your phone number to talk about this? |
|
I’m a student and I can send you my phone number by email, so as not to post it all over the internet. |
|
I think i resolved all of your requested changes ! let me know if there is some other problem in my code |
|
you didn't change the comment for the lines: #value = self.set_position_with_scaling(value) |
2 participants
A plugin that uses a Raspberry Pi as a gateway between PyMoDAQ and a test bench (or any other device).
We have named this gateway a DAP, which stands for Data Acquisition and Control Device.
This DAP can serve as a low-cost alternative to an NI-DAQmx box for low-cost set-ups and test benches.
The Raspberry Pi plugin uses ZMQ to connect to PyMoDAQ.
The connections between the microcontrollers, PyMoDAQ and the sensors are grouped into classes; this means that anyone can easily change the connection type by modifying the relevant class.
We have also set up a wiki via GitHub Pages to assist with the installation, use and maintenance of the plugins: wiki-plugins-dap-pymodaq.github.io