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 13 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!
|
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) |
|
I spotted a bug relating to the bounds not being set correctly. It now works fine. I resolved the issue with the units; users can no longer scale them, and the units field is left blank in the default TOML configuration file. This means there is no alteration to the data between the value sent to the raspberry and the value displayed on the dashboard. I also added a comment explaining how to convert from percentage units to a PigPIO duty cycle, which was used by the EMC controller and MOSFET to control the fan and resistor on my project test bench. I think this might be useful to other developers who want to use percentages in the dashboard rather than using unitless values between 0 and 255 (obviously, they need to put a percentage in the units field of the TOML configuration file if they are using this piece of code). |
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