REDIZDED : l'irrigation de vessie par RPi

Vous souhaitez développer un projet mais vous manquez de temps, de compétences ? Présentez votre projet ici pour trouver des participants...

Modérateur : Francois

destroyedlolo
Raspinaute
Messages : 1232
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: REDIZDED : l'irrigation de vessie par RPi

Message par destroyedlolo » jeu. 5 avr. 2018 15:27

spourre a écrit :
jeu. 5 avr. 2018 14:26
Ces écrans, qu'ils soit natifs ou standards, ont un coût,
Oui, comme tu le dis, attendons les specs finales pour voir si le jeux en vaut la chandelle :)
spourre a écrit :
jeu. 5 avr. 2018 14:26
augmentent la consommation du Raspberry qui est déjà gourmand (2.5A sur un B+, 3A sur le dernier)
Si un *PI est choisie (et je suis d'accord avec toi, c'est TRES largement surdimensionné mais a aussi l'avantage visiblement pour notre ami de rester en terrain connu), je ne suis pas sur qu'un quadri-core soit vraiment nécessaire. Un rPI-0 voir meme un C.H.I.P serait très largement suffisant.
spourre a écrit :
jeu. 5 avr. 2018 14:26
et compliquent la programmation car on va passer plus de temps à faire une zolie interface qu'à programmer l'automate .
Heu non. C'est normalement à la charge du framework (dans mon cas, je ne vais évidement pas m'amuser à recoder chaque courbe que j'ai sur mon dashboard ... surtout qu'il y en a au moins une bonne 20e).
En clair et en décodé, ca se résume à déclaré une collection, déclarré une zone graphique, à nourrir la collection puis genGFX(). Il n'y a pas non plus de couche intermédiaire pour répondre à ce que tu disais plus loin : ni wayland, ni X, ni GTK, ni quoi que ce soit, juste du DirectFB.
Mais bon, la aussi je suis d'accord avec toi : il faut que le coeur du projet fonctionne avant, tout ceci n'est qu'accessoire et peut etre mis après ... si vraiment le besoin s'en fait sentir.
spourre a écrit :
jeu. 5 avr. 2018 14:26
Leur mise en œuvre repose sur 2 bibliothèques: la fbtft (driver frame buffer) et la tslib (touch screen lib). Comme tu l'as expérimenté avec ta banane, soit tu restes sur l'image système fournie avec l'écran, soit tu galères à tout recompiler et recréer les scripts :twisted:
C'est justement parce que c'est un écran natif (voir réponse suivante) ...
spourre a écrit :
jeu. 5 avr. 2018 14:26
Même le HDMI qui te semble si simple pose de nombreux problèmes, il suffit de parcourir le forum pour s'en convaincre.
Mouai, sans vouloir etre désobligeant envers qui que ce soit (car on a tous débuté), vu le niveau, je ne suis pas sur que ce soit vraiment une référence quand aux pbs potentiel, généralement, le pb est plus du coté humain qu'autre chose :twisted: . Non, les écrans HDMI sont pris en charge par le module "framebuffer" standards, inclus dans tous les kernel généralistes. Et vu qu'en plus, on va ni y jouer des vidéo 4K, ni faire de la 3D de la mort qui tue, le VESA des familles sera très largement suffisant.
Donc hormis les rpi-config pour activer le HDMI (s'il n'est pas actif par défaut), y'a rien d'autres a tripoter.

PS: il me semble me souvenir que le connecteur HDMI n'est pas soudé sur un rPI-0 mais que les signaux sont présent (de mémoire, hein). Sinon, il y a des modele de la meme game que le rPI-0 avec HDMI présent chez les OrangePI par exemple ... mais ils sont encore plus surdimentionnés qu'une framboise.
[edit]Non, il y est, c'est le composite qui n'est pas cablé[/edit]
Modifié en dernier par destroyedlolo le ven. 6 avr. 2018 12:19, modifié 1 fois.
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: REDIZDED : l'irrigation de vessie par RPi

Message par spourre » ven. 6 avr. 2018 10:57

@François

H1 étant quasi validée, il reste encore 2 paramètres à connaître pour en commencer l'étude mécanique.
Si on souhaite un servo moteur un peu plus costaud que ceux utilisés pour la radiocommande des modèles réduits et pour assurer une certaine fiabilité, il faut cherché un modèle plus musclé, en général équipé de pignons métalliques et d'un roulement à billes. Le prix s'en ressent mais c'est un gage de fiabilité (on est tout de même sur un dispositif médical).
En voici un exemple mais le choix final dépendra de la résistance à l'écrasement de la tubulure, en prenant un coefficient:
http://www.centralmedia.fr/lycee/moteur ... 44480.html
Ces servos ont, souvent, une plage de débattement de 60 °.
Il faut donc définir:
- le débit minimum (on ferme ou on laisse couler un mince filet de sérum pour "garder la voie", même si ce n'est pas une IV)
- le pas et la loi de progression des paliers de débit (linéaire, géométrique...).

Sylvain

orchidoclaste
Messages : 20
Enregistré le : dim. 1 avr. 2018 17:34

Re: REDIZDED : l'irrigation de vessie par RPi

Message par orchidoclaste » sam. 7 avr. 2018 10:21

spourre a écrit :
jeu. 5 avr. 2018 00:30

Quelle devrait être l'ouverture par défaut de l'actionneur de contrôle du débit (panne batterie, reset de l'ensemble ..). Je pense qu'il faut l'ouvrir au maximum afin de permettre, en mode dégradé, le réglage manuel par l'IDE avec le dispositif en amont de la chambre compte-gouttes.

Oui! C.est ça

Il ne faut pas oublier que la mesure de turbidité se fera en analogique, avec une marge d'erreur et une dispersion entre 2 mesures. Je vous propose de retenir votre proposition de 5 mesures (1 par minute). Ensuite, on enlève la valeur la plus basse et la valeur la plus élevée et on fait la moyenne des 3 mesures conservées. C'est cette valeur que l'on peut stocker et qui sert à prendre la décision d'ouvrir ou de fermer davantage le robinet et/ou de déclencher une alarme..

OK!

Même ce qui est évolutif doit être planifié :twisted:
Il faut définir les variables qui doivent être facilement modifiables via l'Interface Homme Machine (IHM) et celles qui peuvent nécessiter de modifier le programme (ou un fichier de configuration) et qui doivent donc être réalisées avec l'outil de développement retenu, par un personnel compétent
...
AVce des boitiers ayant la mémoire de leurs actions, on devrait pouvoir en tirer des stats, donc évoluer vers quelque chose de plus ressemblant à la réalité.

...
[/quote]
Si vous souhaitez un archivage des valeurs (turbidité par exemple), il faut définir la période d'archivage (souvent 24H), le mode de présentation et la manière de recueillir ces données.
Sur le boîtier lui-même, compte tenu de l'absence prévue d'un écran LCD au profit d'un simple afficheur (comme sur une vraie pompe ou un pousse seringue), il ne sera pas possible d'afficher une courbe mais on pourra faire défiler ces valeurs avec un bouton "up" et un bouton "down". Pour réaliser une courbe sur le boîtier, il faut passer à un écran LCD (éventuellement tactile) nettement plus coûteux et plus difficile à mettre en œuvre.
De plus, pour être exploitables, ces échantillons doivent être horodatés ce qui implique de prévoir un circuit RTC (Real Time Clock) peu coûteux mais qui n'existe pas en standard sur le Raspberry ou sur l'ESP (heureusement peu coûteux et simple à mettre en œuvre). Si vous voulez les récupérer pour importer dans excel par exemple, il faut définir le moyen ou le support de transfert (clef USB, liaison USB, ...).

Vous souhaitez ajouter 2 boutons. Techniquement, ce n'est pas un problème mais quelle doit être l'action déclenchée par chacun de ces boutons ? un simple enregistrement horodaté de l’éventement ? Vous avez éliminé, pour des raisons médico-légales (que je ne discute pas) la pesée des entrées/sorties. Le boîtier ne dispose donc d'aucun moyen (capteur) pour détecter ces anomalie (poche sérum vide, sonde colmatée).

Vous ne rêvez pas et tout (ou presque) est possible si c'est bien défini dans le cahier des charges.
Pour le moment, ça ne se présente pas trop mal et je vous suggère, par copier/coller des parties déjà actées, d'en préparer la version β.

Sylvain
[/quote]

orchidoclaste
Messages : 20
Enregistré le : dim. 1 avr. 2018 17:34

Re: REDIZDED : l'irrigation de vessie par RPi

Message par orchidoclaste » sam. 7 avr. 2018 10:26

Bonjour.

Le servo devra pouvoir fermer complètement l’irrigation.

Comment puis-je mesurer la force nécessaire? J’ai les tubulures, mais quel outil de mesure?

Autre chose, le LCD suffit bien. Seule chose, si on extrait des data, quel format de sortie aura t on?

Si vous permettez, je vais rédiger au propre un cahier des charges précis et vous l.adresser.

Bien à vous.

François.

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: REDIZDED : l'irrigation de vessie par RPi

Message par spourre » sam. 7 avr. 2018 13:07

orchidoclaste a écrit :
sam. 7 avr. 2018 10:26
Bonjour.

Le servo devra pouvoir fermer complètement l’irrigation.

Comment puis-je mesurer la force nécessaire? J’ai les tubulures, mais quel outil de mesure?

Autre chose, le LCD suffit bien. Seule chose, si on extrait des data, quel format de sortie aura t on?

Si vous permettez, je vais rédiger au propre un cahier des charges précis et vous l.adresser.

Bien à vous.
...
.
Bonjour,

Pour mesurer la force d'écrasement, je vous propose la manip suivante. Pour cela, il faut disposer:
- d'une balance de ménage ou d'un pèse-personne (dépendra de la force nécessaire).
- d'un tronçon de tubulure, rempli d'eau (ou de sérum) mais permettant au liquide d' s'échapper (sinon, mesure impossible car liquide incompressible).
- un objet à bout arrondi, de faible surface (bout gomme d'un crayon ou porte-mine par exemple).

Fixer la tubulure par un morceau de scotch afin qu'elle ne s'échappe pas. Appuyez sur le crayon jusqu'à obtenir l'écrasement (un peu de liquide devrait s'échapper.
Si la force nécessaire dépasse la capacité de la balance de ménage (en général dans les 5 kg, prendre le pèse-personne. L'avantage de la balance ménagère est sa plus grande sensibilité. Ne pas hésiter à faire plusieurs mesures pour vérifier la reproductibilité (il faut remplir la tubulure avant chaque essais)..
Si vous avez une tubulure complète avec une poche de sérum, le contrôleur de débit et la chambre compte-gouttes, c'est encore mieux et encore plus proche de la réalité.

Pouvez-vous profiter de ces essais pour noyus donner le diamètre de la tubulure (je suppose que c'est normalisé) et l'épaisseur de la tubulure complètement écrasée (pour le calcul du profil de la came).

Pour l'export des données, je suppose qu'un format texte, avec une virgule comme séparateur de champ et un retour de ligne comme séparateur d'enregistrement devrait convenir. C'est ce que l'on nomme le format CSV et permet un import très simple vers d'autres programmes dont les tableurs Excel ou calc de LibreOffice):
https://fr.wikipedia.org/wiki/Comma-separated_values
On peut envisager une écriture au fil de l'eau, sur une clef USB, sans rien stocker dans le boîtier de contrôle.

Pour le cahier des charges, vous pouvez le préparer "hors ligne", sur votre ordinateur puis le copier/coller dans un message afin qu'il soit lisible par tous en privilégiant le mode texte. . Sinon, je n’ai rien contre le fait d'en recevoir un exemplaire en mail. Vous pouvez me contacter par message perso, si cette fonctionnalité ne vous est pas encore ouverte, signalez-le moi dans un prochain message.

Nota: SVP, pourriez-vous éditer votre avant-dernier message et ajouter les balises cd début et fin de cotation. Il semble qu'il en manque. Ce n'est pas grave mais ça nuit à la lisibilité.

Cordialement

Sylvain

orchidoclaste
Messages : 20
Enregistré le : dim. 1 avr. 2018 17:34

Re: REDIZDED : l'irrigation de vessie par RPi

Message par orchidoclaste » lun. 9 avr. 2018 19:23

Bonsoir.

Je suis en congés cette semaine. Je ne pourrai faire les mesures.

Cependant, je peux rédiger mon cahier des charges précis, et vous le livrerai d’ici quelques jours si tout va bien.

À bientôt, donc.

François

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: REDIZDED : l'irrigation de vessie par RPi

Message par spourre » mar. 10 avr. 2018 00:16

Bonsoir,
Pas de problème, j'espère seulement que vos congés ne seront pas trop perturbés par les grèves.
Pour le cahier des charges, essayez de profiter de la pluie pour le rédiger :twisted:

Pour les tests du ou des prototypes, il serait bien de définir des mélanges inoffensifs (eau + sirop grenadine par exemple) qui correspondent aux niveaux de turbidité que vous souhaitez discriminer.
Sylvain

orchidoclaste
Messages : 20
Enregistré le : dim. 1 avr. 2018 17:34

Re: REDIZDED : l'irrigation de vessie par RPi

Message par orchidoclaste » mar. 10 avr. 2018 21:47

Merci.

A l’abri des grèves. Ouf!

Je propose de faire le dispositif de contrôle, et d’enregistrer des data sur tous mes prochains patients. On devrait ainsi pouvoir avoir une base de réflexion, non?

Une idée comme ça.

Bonne soirée .

François

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: REDIZDED : l'irrigation de vessie par RPi

Message par spourre » mer. 11 avr. 2018 00:13

orchidoclaste a écrit :
mar. 10 avr. 2018 21:47
...
Je propose de faire le dispositif de contrôle, et d’enregistrer des data sur tous mes prochains patients. On devrait ainsi pouvoir avoir une base de réflexion, non?
...
Comment évaluez-vous visuellement (ou l'IDE) la turbidité de l'urine en cas d'hématurie macroscopique ?
Avez-vous une échelle (du style, à peine rose, rose foncé, rouge clair...) ?
De toute manière, il faudra bien prévoir une procédure d’étalonnage du capteur compte tenu de la dispersion et des tolérances des composants électroniques et de la grande variabilité de la couleur/transparence des urines (y compris pour un même patient).

Si on arrive au stade du prototype, il faudra pouvoir réaliser un banc de test, sans recourir à un patient sondé en effet, peu d'entre nous, en ont un à domicile :evil:
Je pense que l'on peut modéliser un patient avec 3 poches à sérum et un peu de tubulure à perfusion.
La première poche ne contiendrait que le sérum physiologique et sa tubulure passerait par le boîtier de contrôle.
La 2 ème poche contiendrait du sérum mais, sur un Y, on pourrait injecter un produit inoffensif (sirop citron, sirop grenadine) pour simuler l'urine et ses changements de teinte.
Chacune de ces 2 tubulure serait équipée de son régulateur de débit et de sa chambre compte-gouttes pour régler les débits selon vos instructions.
La 3 ème poche simulerait la vessie et recevrait les 2 tubulures précitées plus la tubulure de sortie qui passerait à travers la sonde.

Une bouteille pourrait recueillir le flux sortant.

Sylvain

Bud Spencer
Raspinaute
Messages : 416
Enregistré le : lun. 15 août 2016 21:38

Re: REDIZDED : l'irrigation de vessie par RPi

Message par Bud Spencer » mer. 11 avr. 2018 14:43

Je viens de lire tout ça (projet bien intéressant) et je suis tombé là-dessus :
spourre a écrit :
jeu. 5 avr. 2018 14:26
...
Il reste encore une alternative, c'est de s'inspirer (avec son aide) du tuto de Bud . Après tout, il y a déjà 2 canaux analogiques à surveiller et afficher (turbidité et batterie).. Ça ne dispensera pas de toute la quincaillerie liée à un écran LCD mais ça peut simplifier considérablement la conception de l'IHM (et le stockage des données récemment demandée par François.
..
Si tu fais allusion au tuto sur les appli web dynamique, c’est effectivement tout à fait envisageable avec ces méthodes et cela pourrait même être plutôt bien adapté. Sans vouloir interagir avec vos idées, je vous en soumets quelques une à titre de réflexion.

Un PI Zero W avec le petit montage pour l’acquisition et la gestion de la robinetterie pourrait former les modules embarqués pour chaque patient. Au niveau du programme cela peut se résumer à peu de chose puisqu’il suffirait de faire l’acquisition toutes les X minutes et transférer les données sur un socket vers un serveur de supervision qui lui retournerait le paramètre adapté pour ‘l’ouverture du robinet’. Pour consolider le procédé, on pourrait aussi envisager un ACK pour informer le serveur de la bonne prise en compte du paramètre et même envisager le transfert d’autres infos que le serveur pourrait interpréter (force du signal, niveau de batterie …).

Pour le serveur de supervision, un Pi 3 pourrait parfaitement faire l’affaire. Il n’aurait qu’à recevoir les infos des modules clients et les traiter suivant les règles définies pour retourner à chacun d’eux le paramètre ‘robinet’ adapté et générer les alertes. En plus de traiter les données, le code serveur pourrait facilement être capable de les transférer sur un système de stockage disposant d’une bonne garanti de fiabilité, de détecter les éventuelles pertes de connexion avec les modules clients mais aussi servir d’IHM de supervision centrale. Bien sur cette IHM serait servie par le même script serveur, ce qui permettrait aux infirmières ou autres hommes de science de le consulter en temps réel depuis n’importe quel appareil connecté (tablette, smartphone ...) ou tout simplement de l’avoir en temps réel sur un écran de leur desktop.
Pour les options d’ergonomie, tout est envisageable avec ces méthodes. Ça peut aller de la simple détection automatique des clients par le serveur sans aucune intervention (juste mettre le bouton du client sur on) jusqu’à de l’analyse statistique en temps réel pour mieux gérer les débits de sérum.

Synthétisé vite fait, voilà les premiers avantages que je vois dans cette méthode :

- Un seul langage de programmation pour les modules clients, le serveur et la GUI. Du code simple à entretenir sans besoin d’aucun outil de développement spécifique et ne nécessitant aucun compilateur. Aucune lib spécifique hormis celle qui permet l’accès au GPIO sur les PI Zéro.

- En cas de panne du PI3, le code serveur pourrait très facilement être provisoirement exécuté sur n’importe quel autre ordinateur existant quel que soit son os (en tous cas les plus usuels). On pourrait même envisager des modules hybrides embarquant tous le même programme et étant configurable soit en mode client soit en mode serveur par la simple position d’un jump (ce qui en plus simplifierait les déploiements)

- GUI riche et supervision centralisée disponible en simultané et en temps réel depuis des sources multiples ne nécessitant aucune programmation ni aucun paramétrage.

- Aucun paramétrage spécifique des clients puisque tous les paramètres peuvent être centralisé et distribuer automatiquement à la connexion par le serveur

- Aucune donnée stockée en dur sur les clients ou sur le serveur.

- Pas besoin d’écran du côté des embarqués. C’est un des points les plus important ça. Si on regarde bien, se déplacer pour aller visualiser un écran ou contrôler le bon fonctionnement d’un système revient au même que de se déplacer pour aller visualiser la transparence d’un fluide dans un tuyau, donc c’est à mon sens à côté de l’idée de base du cahier des charges. Dans l’extrême du luxe, ils pourraient disposer juste d’un petit lcd 2x16 pour faire plus geek et user un peu plus vite les batteries. Ce serait très largement suffisant pour afficher quelques infos inutiles puisque tout serait déjà centralisés.

- Dans l’absolu, le serveur peut lui aussi se passer d’un écran dédié et être lui-même administrer à distance sans rien programmer de plus.

- Possibilité d’imposer des règles spécifiques à chaque client depuis le serveur.


Voilà, c’est juste quelques idées qui me viennent comme ça et je ne vois là-dedans aucune contrainte particulière qui empêcherait la prise en charge intégrale de la partie software par le seul modèle cité.

ps : pour la partie dosage, il ni aurait pas moyens de trouver des petits robinets 1/4 de tours qui fasse l'affaire ? Mécaniquement parlant gérer un angle d'ouverture serait plus simple que de gérer l'écrasement d'un tuyau ?
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).

Répondre

Retourner vers « Projets »