REDIZDED : l'irrigation de vessie par RPi

[spourre]

....
Je ne suis pas aussi catégorique sur le PI : après tout, y'en a qui mette des rPI-0 pour arroser une plante ou des windowseries dans des auto-radio ... qui plantent (véridique, j'en ai eu un, cadeau bien empoisonné).
C'est sur qu'un PIC ou un AVR ferait aussi bien l'affaire mais bon, un PI sera largement surdimensionné mais fera aussi bien l'affaire

Sylvain, je continue à ne pas être d'accord sur les supposés faiblesses des SD. Correctement configuré (c'est a dire sans écriture inutile), une SD n'a rien d'un maillon faible.
...

C'est le monde à l'envers, c'est toi qui défend le Raspberry
Heureusement que nous ne sommes pas toujours d'accord, ça serait lassant et enlèverait beaucoup d'intérêt à ces discussions.

Dans ce cas précis, je suis contre le Raspberry pour les raisons déjà listées.. Le reproche du manque de fiabilité de la carte SD n'est pas lié qu'à sa capacité à les détruire. Je sais parfaitement que l'on peut limiter les écritures (je ne développe pas davantage ce point mais tu connais la technique).
Je lui reproche aussi, surtout sur les Raspberry où il n'y a plus encliquetage de la carte, un manque de fiabilité mécanique. Il faut tout de même prendre conscience qu'on ne parle pas de la domotique d'un geek mais d'un dispositif médical (même si le risque est minime en cas de dysfonctionnement). Dispositif mis en œuvre dans un milieu agressif (déplacements, chocs..) par des personnels n'ayant absolument pas de temps à perdre pour attendre un boot qui ne vient pas. Le fonctionnement doit être immédiat, dès l'appareil activé.

J'espère que d'autres contributeurs vont se manifester mais le titre n'est pas trop sexy
Je me demande s'il ne faudrait pas battre le rappel des troupes MP à Bud et signalement aux modos. Je sais que François est surbookée (je parle du François, maître de ces lieux) mais il est modo de cette rubrique et ses contacts à l'IUT pourraient se révéler très précieux pour réaliser un prototype (de plus, il touche son caramel en électronique).

Sylvain

[spourre]

...
L’irrigation passe par gravité, donc pas besoin de pompe.
...

Pour moi, c'est clair depuis le 2 ème message d'où ma proposition de remplacer "votre pince" par unne came (un excentrique) qui comprime plus ou moins (selon sa position) la tubulure contre un galet presseur d'où ma proposition de récupérer ou de s'inspirer d'un boîtier de pompe. Le geste technique de l'IDE serait quasi standard:
- disposer le boîtier principal sur la potence (comme n'importe quelle pompe ou pousse seringue).
- placer la sonde de turbidité sur la tubulure de sortie de la sonde (certainement un capteur sous forme de pince.
- ouvrir le couvercle du boîtier pur y faire cheminer la tubulure d'alimentation en sérum.refermer le couvercle.
- mettre en route
- programmer le seuil d'alerte.

Il faut encore définir:
- la périodicité de la mesure de turbidité ( dizaine de secondes, minutes ?)
- le nombre de mesures consécutives à la même valeur pour augmenter ou diminuer le débit (pour éviter un phénomène d'oscillation autour d'une valeur moyenne (en jargon d'automaticien on parle de pompage).

Sylvain

[destroyedlolo]

C'est le monde à l'envers, c'est toi qui défend le Raspberry

Il a suffisamment de défauts sans en rajouter

Je lui reproche aussi, surtout sur les Raspberry où il n'y a plus encliquetage de la carte, un manque de fiabilité mécanique.

??? NNNNNaaaannnnnnn ???? Et be, je ne savais mais, mais franchement, ca leur couterait moins d'un centime, c'est vraiment ridicule du coup !

Mais je reviens sur ce que tu disais, partir peut etre sur un ESP : il faut faire gaffe, car même si les réglementations se sont dé-rigidifiées ... il n’empêche quand même que nombre de models ne respectent ni les règles Européennes, ni US. Et comme de plus la plus la puissance d"émission est réglable, je n'aurai vraiment pas confiance quant aux rayonnements qui peuvent mettre la grouille dans les appareils de monitoring. Et la ...
C'est entre autre le cas de l'ESP-201 qui me sert à quasiment tout mes projets.

[spourre]

Mais je reviens sur ce que tu disais, partir peut etre sur un ESP : il faut faire gaffe, car même si les réglementations se sont dé-rigidifiées ... il n’empêche quand même que nombre de models ne respectent ni les règles Européennes, ni US. Et comme de plus la plus la puissance d"émission est réglable, je n'aurai vraiment pas confiance quant aux rayonnements qui peuvent mettre la grouille dans les appareils de monitoring. Et la ...
C'est entre autre le cas de l'ESP-201 qui me sert à quasiment tout mes projets.

Objection pertinente même si le BT ou le WIFI présentent un niveau de puissance bien moindre qu'un GSM qui hurle pour maintenir le contact avec sa Base Station
Ceci dit, je ne vois pas pourquoi, en l'absence d'activation logicielel du fonctionnement en AP, l'ESP devrait émettre si on ne lui demande pas de se connecter à un réseau.
Je vais repasser sous Windows, activer mon SDR avec une clef TNT et vérifier ce point.
Dans le pire des cas, vu le faible volume d'un ESP, on pourrait très bien le mettre dans un boîtier métallique et ne laisser sortir que les fils de connexion (en les découplant par un condensateur bypass).
Pour ne pas bloquer sur ce point, il faut avancer sur le capteur de turbidité et sur l'actionneur.
Pour le capteur, j'avais envisagé de partir d'un capteur de lave vaisselle ou de lave linge (qui incluent de + en + cette fonction pour réduire l'usage des produits et la durée du cycle) mais ils sont chers (plusieurs dizaine d'euros) et peu adaptés (gros diamètre de la durite). Il faut donc s'orienter vers un dispositif ouvrant (sur le principe d'une pince à linge ) et composé de 2 demi-cylindres . Un destiné à recevoir la LED d'émission et l'autre au contrôleur I2C et à la LDR de réceprion (je retiens une LDR et non une photodiode pour avoir facilement une lecture analogique de la turbidité et une meiilleure réponse). A ce niveau, il faut envisager l'emploi de composants SMD, même si le prototype est réalisé avec des composants traversants.

Pour l'actionneur, j'hésite entre 2 orientations et le choix final dépendra d'une réponse de François (le casse-couilles ) sur la force nécessaire pour écraser et fermer la tubulure peine de serum.
H1) Un servo-moteur qui entraîne une came (ou un excentrique qui vient écraser la tubulure retenue sur un point fixe (galet presseur). Le gros avantage de cette solution est que l'on reste dans un domaine bien connu de commande dun servo-moteur en PWM.
H2) Un moteur CC piloté par un CI double pont H. Ce moteur, par une vis sans fin (éventuellement avec un train de pignons réducteur) pousse un piston qui vient comprimer la tubulure.
Cette solution est un peu plus complexe mécaniquement surtout qu'il faudra prévoir un détecteur de position (absolu ou relatif) et un auto-étalonage. Cette auto étalonnage consiste à mesurer le courant consommé par le moteur et à détecter sa brusque augmentation quand il est bloqué en fin de course. C'est le principe des têtes thermostatiques électronique dont on pourrait récupérer la mécanique:
http://www.conrad.fr/ce/fr/overview/081 ... ostatiques

Sylvain

[orchidoclaste]

Sylvain, j’aime bien H1, au vu de la résistance de nos tubulures.

Pour la périodicité de mesure... toutes les 5 minutes ce serait correct.

Pour éviter le pompage, une idée , c'est d'avoir des intervalles larges, non ??

Diode Led + mesureur= concept intéressant, surtout si 2 couples led-mesureur, avec un témoin et un mesurant à travers la tubulure.., histoire de s’affranchir de variations de l’alimentation, et détecter panne de batterie!!

À vous..!
Merci encore.

François.

[spourre]

Sylvain, j’aime bien H1, au vu de la résistance de nos tubulures.
...

H1 me plaît bien aussi pour sa relative simplicité mécanique et parce qu’il n'y aura pas besoin d'interface compliquée.
Il existe des servos de puissance variable dont certains très costauds.

...
Pour la périodicité de mesure... toutes les 5 minutes ce serait correct.

Pour éviter le pompage, une idée , c'est d'avoir des intervalles larges, non ??
...

On peut jouer sur 2 paramètres:
- la périodicité de la mesure.
- le nombre de mesures nécessaires pour confirmer une tendance.
Si on prend un délais trop important entre 2 mesures ET que l'on attend trop pour réagir, on risque de ne pas traiter/signaler à temps une situation hémorragique.

...
Diode Led + mesureur= concept intéressant, surtout si 2 couples led-mesureur, avec un témoin et un mesurant à travers la tubulure.., histoire de s’affranchir de variations de l’alimentation, et détecter panne de batterie!!

La panne batterie (ou sa limite de décharge) fera l'objet d'une mesure , d'un affichage (sous forme classique de barres) et d'une alarme.
En effet, même si vous ne l'avez pas précisé, je suppose que le patient SUR son lit peut être amené à quitter sa chambre pour aller dans un autre service (RÉA, examens ...).
Ces déplacements, sous responsabilité des brancardiers, s'effectuent sans disposer du secteur (ascenseur, couloirs..).

Cordialement

Sylvain

[orchidoclaste]

Bonsoir et merci.

H1 , OK.

Pour la batterie, en effet quelques déplacements auront lieu et ce sont des moments critiques, donc une batterie est nécessaire.

Pour les mesures, si on dit 1/Minute, ça ne consomme pas trop, et on dit qu'on juge de deux façons:


1 - par intervalles de 5 minutes :tendance à l'augmentation de la turbidité confirmée sur 3 des 5 dernières mesures
2 - turbidité > à un seuil au delà duquel on demande à la commande de libérer le maximum d'irrigations...

ET si pas d'amélioration :

Dans le cas 1 : ouvrir les irrigations d'un cran supplémentaire 5 minutes plus tard (comparaison des échantillons des deux dernières paires de 5 minutes). ET si on était déjà au maximum : Alarme
Dans le cas 2 : si turbidité maximum encore 10 minutes plus tard : alarme.

Mais a mon sens , tout cela devra être évolutif...
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é.

Dans ce cas je me demande si l'on peut mettre deux boutons de plus sur le boitier : 1 = changement de poche d'irrigation . 2 = Caillottage (sonde bouchée).... Si les IDE sont sympa, ca devrait renseigner...

Mais je rêve peut être...

Bien à vous.

François

[spourre]

Bonsoir et merci.

H1 , OK.

Pour la batterie, en effet quelques déplacements auront lieu et ce sont des moments critiques, donc une batterie est nécessaire.
...

Bonsoir et de rien
Pour valider définitivement H1, il faudra quantifier la résistance à l'écrasement de la tubulure d'alimentation remplie de sérum (est-ce une solution genre ecoflac 0.9% NaCl ?) . Il faut aussi que la surface sur laquelle on exercera cette force soit suffisante pour éviter de poinçonner la tubulure. Je devrais pouvoir en récupérer une avant la fin du mois à moins que vous ne connaissiez déjà cette valeur.
OK pour la batterie qui est actée.
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.

...
Pour les mesures, si on dit 1/Minute, ça ne consomme pas trop, et on dit qu'on juge de deux façons:

1 - par intervalles de 5 minutes :tendance à l'augmentation de la turbidité confirmée sur 3 des 5 dernières mesures
2 - turbidité > à un seuil au delà duquel on demande à la commande de libérer le maximum d'irrigations...

ET si pas d'amélioration :

Dans le cas 1 : ouvrir les irrigations d'un cran supplémentaire 5 minutes plus tard (comparaison des échantillons des deux dernières paires de 5 minutes). ET si on était déjà au maximum : Alarme
Dans le cas 2 : si turbidité maximum encore 10 minutes plus tard : alarme.

Mais a mon sens , tout cela devra être évolutif...
...

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..

Même ce qui est évolutif doit être planifié
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é.

Dans ce cas je me demande si l'on peut mettre deux boutons de plus sur le boitier : 1 = changement de poche d'irrigation . 2 = Caillottage (sonde bouchée).... Si les IDE sont sympa, ca devrait renseigner...

Mais je rêve peut être...
...

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

[destroyedlolo]

Salut,

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.

Si un *PI quelconque est choisi, il existe des LCD HDMI à une 30e d'Euro : l'HDMI a l'avantage être standard et ne posera donc pas de pb lors de la mise à jour de l'OS, contrairement aux écrans natifs (j'en ai un sur mon Banana ... qui reste bloqué à l'antique kernel 3 car son driver n'a pas été porté aux DTB ).
J'ai fait un framework qui permet de dessiner en Lua sur l'écran sans passer par une interface X lourdingue si vous etes intéressé.

Je n'ai pas encore essayé la partie tactile par manque de temps : j'imagine (conditionnel) que ca sera traité comme un evenement Linux classique, dans ce cas, pas plus compliqué à intégrer qu'un bouton par GPIO ou les touches Vol+/- des téléphones

Sur un ESP, il y a de petits écrans encore moins cher (moins de 10€) en SPI ou I2C : pas encore essayé mais je sais qu'il y a des librairies qui existent et il y a sur YT des vidéos qui montrent que ca fonctionne pas mal.

[spourre]

...
Si un *PI quelconque est choisi, il existe des LCD HDMI à une 30e d'Euro : l'HDMI a l'avantage être standard et ne posera donc pas de pb lors de la mise à jour de l'OS, contrairement aux écrans natifs (j'en ai un sur mon Banana ... qui reste bloqué à l'antique kernel 3 car son driver n'a pas été porté aux DTB ).
J'ai fait un framework qui permet de dessiner en Lua sur l'écran sans passer par une interface X lourdingue si vous etes intéressé.

Je n'ai pas encore essayé la partie tactile par manque de temps : j'imagine (conditionnel) que ca sera traité comme un evenement Linux classique, dans ce cas, pas plus compliqué à intégrer qu'un bouton par GPIO ou les touches Vol+/- des téléphones
...

Ces écrans, qu'ils soit natifs ou standards, ont un coût, augmentent la consommation du Raspberry qui est déjà gourmand (2.5A sur un B+, 3A sur le dernier) et compliquent la programmation car on va passer plus de temps à faire une zolie interface qu'à programmer l'automate .
A part celui de la fondation qui utilise le l'interface dédiée, ils utilisent une liaison série, en général le SPI et très rarement I2C à cause du débit. 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
Même le HDMI qui te semble si simple pose de nombreux problèmes, il suffit de parcourir le forum pour s'en convaincre.

...
J'ai fait un framework qui permet de dessiner en Lua sur l'écran sans passer par une interface X lourdingue si vous etes intéressé.
...
Sur un ESP, il y a de petits écrans encore moins cher (moins de 10€) en SPI ou I2C : pas encore essayé mais je sais qu'il y a des librairies qui existent et il y a sur YT des vidéos qui montrent que ca fonctionne pas mal.

On peut garder ton idée de framework pour plus tard, quand on en sera rendu aux choix d'architecture. Ceci dit, il est possible de développer une GUI graphique avec GTK en mono fenêtre. Dans ce cas , on échappe aux monstres comme Wayland.
Les petits écrans que tu mentionnes sont des OLED, très lumineux, sous forme de matrice (128x64 par exemple):
https://bsfrance.fr/ecrans-afficheurs-o ... D1306.html

Que l'on retienne un Raspberry ou un ESP, j'ai bien envie d'essayer ce genre d'écran qui réduit considérablement le temps de développement consacré à 'IHM et décharge le contrôleur:
https://bsfrance.fr/120-lcd-hmi-nextion
Il y a eu un article dans un récent Hackable Magazine mais tu peux aussi regarder la présentation chez le constructeur:
https://nextion.itead.cc/
Il y a cependant un gros hic: l'IDE est propriétaire et ne fonctionne que sous Windows

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.

Je remarque cependant que TOUTES les pompes et pousse-seringues que j'ai vues (et tu peux me croire, j'en ai vu un paquet), ne comportent pas d'écran graphique mais un affichage LCD. Il faut taper dans les monitors, de cardio par exemple, pour trouver un graphe. Attendons la confirmation du besoin avant de nous prendre la tête.

Sylvain