Bellenteller met webcam en Raspberry Pi

[Erwin]

Ik heb met interesse de topics gelezen over de verschillende bellentellers, en met name leuk om te lezen hoe complex het kan zijn.
Mijn oplossing is simpel.
Ik heb momenteel een IPA in mijn gistvat, die lekker aan het gisten is.
Gezien de minimale ruimte bovenin heb ik een blow-off geinstalleerd op het vat, ofwel, een slang die vanuit de stop in een waterfles loopt.
Hieruit ontsnapt nu 2 a 3 keer per seconde een luchtbel, en dat maakt geluid.
Nu ik een Raspberry Pi draaide heb, dacht ik, wat als ik nou eens een webcam aansluit en daarmee het geluid opneem, en dan probeer de pulsen te detecteren uit het audio-bestand.
En dat dan iedere minuut, zeg, 15 seconden opnemen, pulsen tellen, frequentie uitrekenen, en plotten op een grafiek.
Dat is in een paar uurtjes hacken gelukt, het resultaat zie je hier:
https://cosm.com/feeds/100000
Zie de onderste grafiek "Pulse Counter"

Het mooie is dat ik er geen extra hardware voor nodig had, de webcam had ik over, de raspberry was al in bedrijf.

[Erwin]

Te vroeg gejuicht.
De raspberry loopt vast, vage kernel dumps...
Ik ga het nog maar even niet aanzetten.
Wordt vervolgd.

[JanSt]

Erwin,

Ben wel benieuwt hoe je het doet...
Ik heb ook nog een raspberry liggen en heb nog een goed doel nodig.

[Erwin]

Ok, de applicatie is niet stabiel hier, maar dat kan misschien liggen aan mijn gepruts om de temperatuur-controller werkend te krijgen.
Ik wil het binnenkort testen op een verse RPi en zien waar het probleem ligt.

Wat ik heb gedaan:
1. Webcam aan RPi aansluiten, webcam tegen de blow-off waterfles leggen.
2. Op commandline intypen: arecord -L
Je ziet dan of er een microfoon gevonden is, in mijn geval was dat zo.
3. Geluid opnemen: arecord -D plughw:1,0 -d 15 -f U8 pulse.raw
Je krijgt als het goed is een bestand van 120kb (zie bijlage voor een voorbeeld)
4. Geluid analyseren, ik heb daar een php script voor geschreven, zie bijlage
Je hebt de volgende software nodig:
 apt-get install php5-common php5-cli
Analyse gebruikt een -standard deviation- functie, die zit in het script ingebakken maar is traag, je kan dat versnellen door de pecl module "stats" te linken. Dat is nogal een gedoe, maar niet onmogelijk. Ik kan desgewenst wel helpen als dat nodig is.
5. Als alles is gelukt, is er een bestandje geschreven: pulse.json
Dat wordt naar cosm gestuurd voor data-log

Waar het bij mij mis gaat:
Handmatig uitvoeren gaat prima, maar zodra ik er een cronjob van maak, loopt de RPi vast.
Ik denk dat het aan de SD kaart ligt, die heeft kuren.

That's all folks

[hansHalberstadt]

Het idee om geluid te gebruiken is heel leuk natuurlijk.
Vroeger kon je heel leuk direkt de poorten van een PC benaderen in het DOS tijdperk.

Er zijn tegenwoordig diverse programmeertalen, zoals Labview, Delphi, visual basec etc. waarmee je prachtige applicaties kunt maken om dit soort input te verwerken.
Een van de vervelende dingen met computers heb ik gemerkt is dat de problemen altijd ontstaan bij de IO.
Hoe lees je de data in en hoe stuur je data naar buiten. Vaak kan het allemaal wel maar is de documentatie niet toegankelijk of slecht gedocumenteerd of ergens begraven in Windows en slecht te achterhalen.
Wanneer zou dat eens opgelost worden?

Ik heb ooit een elektuur ideetje bekeken waarbij je via de audiokaart data kunt inlezen en weer naar buiten sturen (als audio signaal, maar daar kun je ook snel weer digitale signalen van maken) Dat werkt en lost voor mij het IO probleem in ieder geval op. Daarmee zou je ook blupjes kunnen tellen en daar allerlei grafieken van maken en meten en regelen, zoals Tcontrol elders op dit forum ook doet.   
HansH
   

[koffie]

Gaaf project!
'probleem' is natuurlijk wel dat dit alleen zal werken als je weet hoeveel CO2 elke blub bevat, en deze dus ook kunt sturen. Anders ben je alleen aan het tellen hoe vaak er een blub komt, of mis ik iets?

[Erwin]

Als je wilt weten hoeveel CO2 er geproduceerd is, zal je moeten calibreren inderdaad, en dan alle blups bij elkaar optellen.
Dat kan, maar is het een relevant gegeven? Wil je weten hoeveel CO2 er ontsnapt is?
Volgens mij kan je aan de hand van de blup-frequentie al genoeg zien hoe ver je vergisting is.
Dat zal een parabool zijn, denk ik?

[koffie]

Ik had begrepen van het product van henielma dat wanneer je de totale hoeveelheid CO2 weet, je direct het SG kan berekenen.

[seed7]

'probleem' is natuurlijk wel dat dit alleen zal werken als je weet hoeveel CO2 elke blub bevat, en deze dus ook kunt sturen. Anders ben je alleen aan het tellen hoe vaak er een blub komt, of mis ik iets?

Duur van de blub, luidheid van de blub.

Maar waarom een hele webcam, heeft de raspberry pi geen microfoon ingang? Aangezien Python de "moedertaal" van de pi is, daar zijn toch wel de nodige realtime audio analyse en processing bibliotheken beschikbaar.

s7.

[Erwin]

Wanneer zou dat eens opgelost worden?

De oplossing is imo om van het desktop pad (lees windows) af te wijken en de oplossing te zoeken in embedded devices zoals de RPi, welke op zich niet bijzonder is, voorheen had je de NSLU2 waarmee je hetzelfde kon doen, dat was alleen niet zo'n hype.
Labview etc is mooi, maar veel te veel overhead.
Mijn oplossing is klein, simpel en past op een creditcard.
De IO-problemen worden imo ondervangen dmv USB en de manier waarop het linux OS dit virtualiseert.

[Erwin]

Maar waarom een hele webcam, heeft de raspberry pi geen microfoon ingang?

Nee helaas, geen native audio input.
Webcam is maar een voorbeeld, je kan whatever gebruiken, als het maar een microfoon bevat. In mijn geval een webcam omdat die hier gewoon al lag.

Aangezien Python de "moedertaal" van de pi is, daar zijn toch wel de nodige realtime audio analyse en processing bibliotheken beschikbaar.

Pyhon moedertaal? Flauwe kul. Er draait linux op de RPi waar je alle linux talen in kan gebruiken. Python wordt vaak gebruikt omdat het schijnbaar makkelijk te leren valt.
Maargoed, wellicht zijn er bibliotheken beschikbaar, in python, perl, c++, java, ruby, ... of wat dan ook, kan allemaal.
Ik ben een php programmeur dus mijn keuze viel op php. Ik kon zo snel geen php bibliotheek vinden voor dit doel, dus heb zelf maar wat geschreven. Werkt prima.

[Erwin]

Ik had begrepen van het product van henielma dat wanneer je de totale hoeveelheid CO2 weet, je direct het SG kan berekenen.

In theorie klopt dat, maar hoe naukeurig kan je de CO2 meten? Ik denk dat ook de kiep-oplossing niet naukeurigheid genoeg is. Er zijn zoveel factoren, denk aan temperatuur, buitendruk, hoeveelheid water in de kiep-bak. Je zal het ding voortdurend moeten calibreren om er een naukeurige meting mee uit te kunnen voren.

[foz]

inderdaad, de moedertaal van Unix varianten is nog altijd goeie ouwe C van K&R.

[William]

In theorie klopt dat, maar hoe naukeurig kan je de CO2 meten? Ik denk dat ook de kiep-oplossing niet naukeurigheid genoeg is. Er zijn zoveel factoren, denk aan temperatuur, buitendruk, hoeveelheid water in de kiep-bak. Je zal het ding voortdurend moeten calibreren om er een naukeurige meting mee uit te kunnen voren.

De kiepoplossing is aardig nauwkeurig als je er altijd dezelfde hoeveelheid water in doet en het geheel bij kamertemperatuur staat.
Ik denk dat je binnen 5% svg nauwkeurig kunt meten, maar vooral de trend in de tijd is nuttig om te volgen.

Het voordeel van de kieper is dat je een heleboel bellen als één puls meet. Hierdoor ben je niet meer afhankelijk van het belvolume. Tijdens de vergisting heb je enkele bellen, bellentreinen, kleine bellen, grote bellen die allemaal een andere ijkfactor hebben. Ik denk dat je die niet met de vorm een audiosignaal kunt onderscheiden.

Bij het kiepmechanisme of de ballon heb je daar geen last meer van.

Maar wel leuk hoor, bellen tellen!

[Erwin]

maar vooral de trend in de tijd is nuttig om te volgen.

Inderdaad William, dat is mijn enige doel. Mijn methode is het aantal bellen tellen in 15 seconden, doordat dit een gemiddelde oplevert, wordt de variatie in belgrootte ondervangen. De frequentie wordt iedere minuut gemeten en geplot, zodat de trend zichtbaar wordt, zoals gezegd, ik verwacht een parabool, of meer een bult die langzaam afloopt. Ben de wiskundige naam even kwijt.

[Henielma]

In theorie klopt dat, maar hoe naukeurig kan je de CO2 meten? Ik denk dat ook de kiep-oplossing niet naukeurigheid genoeg is. Er zijn zoveel factoren, denk aan temperatuur, buitendruk, hoeveelheid water in de kiep-bak. Je zal het ding voortdurend moeten calibreren om er een naukeurige meting mee uit te kunnen voren.

Bij het bellenteller kiepmechanisme kan je na een paar brouwsels plusminus 2 SG punten het huidige SG bepalen. Het duurt wel een paar brouwsels voordat je de parameter liter koolzuur per puls redelijk nauwkeurig bepaald hebt.

De ballon koolzuurproductiemeter van mij is eigenlijk net zo nauwkeurig maar is beter reproduceerbaar omdat er gaandeweg geen water verdampt zoals bij de teller met het kiepmechanisme.

Er is een vrijwel lineair verband tussen de hoeveelheid geproduceerde koolzuur en het huidige SG. Je hoeft dan alleen het start SG te weten en het aantal liters wort in het gistvat.

Hier vind je meer info over de ballon koolzuurproductiesensor. http://www.hobbybrouwen.nl/forum/index.php/topic,21304.msg321087.html#msg321087
Deze sensor geeft een digitale puls af. Ongeveer 1 puls per 0,14 liter koolzuur. Deze puls is natuurlijk met de RPi ook goed en eenvoudig te tellen.

[William]

Inderdaad William, dat is mijn enige doel. Mijn methode is het aantal bellen tellen in 15 seconden, doordat dit een gemiddelde oplevert, wordt de variatie in belgrootte ondervangen. De frequentie wordt iedere minuut gemeten en geplot, zodat de trend zichtbaar wordt, zoals gezegd, ik verwacht een parabool, of meer een bult die langzaam afloopt. Ben de wiskundige naam even kwijt.

Als je de hoeveelheid koolzuur als functie van de tijd uitzet krijg je een sigmoide curve die niet-symmetrisch (skewed) is. De afgeleide naar de tijd lijkt meer op die van een normale verdeling maar dan ook skewed op langere tijden (niet log-normaal). Omdat je in jouw setup vooral in het middenstuk bij de hoogste activiteit pulsen gaat missen (denk ik hé ) zal de piek van de skewed normale verdeling afgevlakt zijn.

Laat maar eens zien!

[Erwin]

Ik heb de software aan de praat.
https://cosm.com/feeds/100000

Oplossing was geen arecord te gebruiken maar te streamen van /dev/dsp naar php.

Momenteel wordt er geluisterd naar een vergisting die bijna klaar is, dus weinig actie.
Over een week of 2 gaat het volgende brouwsel erin, dan zullen we zien of het werkt.

Deze sensor geeft een digitale puls af. Ongeveer 1 puls per 0,14 liter koolzuur. Deze puls is natuurlijk met de RPi ook goed en eenvoudig te tellen.

Dat zal prima gaan inderdaad, en erg eenvoudig. Ik heb echter geen ballon-opstelling, en via de webcam methode krijg ik voor mij voldoende info.

[Erwin]

Dit is trouwens de output van het script als je hem in een browser bekijkt. Handig, php!
De grafiek toont de sd per 200 samples (bij een samplerate van 8k is dat 25ms).
Alle sd uitschieters worden geteld als blup.

[Erwin]

Ik was nog niet helemaal tevreden met de audio-analyse methode. Ik berekende simpelweg de sd van sub-datasets, en telde uitschieters als blup.
Deze methode heeft veel last van achtergrond-geluiden zoals de wasmachine die in dezelfde ruimte staat.

Vandaag gestoeid met Fourier analyse van de audio.
Lang verhaal kort, dat was nog zo eenvoudig, ik heb uiteindelijk de C++ broncode van de tool "sndfile-spectrogram" omgebouwd, deze tool genereert een frequentie-spectum PNG adhv een audio-file. Dat zag er bruibaar uit, maar ik wilde geen files opslaan, maar streamen, en ik wil ook geen png als intermedium, ik wil de spectrum-data direct uitlezen.
Dus wat aanpassingen in de code van deze tool gemaakt, de input is een audio input stream geworden, de output een json stream. En dat was gelukt!
Hieronder een plaatje van de json die ik geplot heb in HTML



Die data vervolgens gefilterd op de juiste frequentie-band (daar waar je de streepjes ziet, dat zijn blups) en de gemiddelde tijd berekend tussen de pieken. Daar komt dus uiteindelijk de blup-frequentie, die weer naar cosm wordt gestuurd.
Bijgevoegd de complete project-software, met de omgebouwde sndfile-spectrogram binary (gecompileerd op mijn Raspberry!).

ps het mooie van de deze "fast fourier transform" is dat het rekenwerk wordt uitgevoerd door libfftw3, welke gebruik maakt van de GPU, die heeft doorgaans toch niks te doen, dus de CPU blijft mooi rustig. En hij is super snel!

[Henielma]

ps het mooie van de deze "fast fourier transform" is dat het rekenwerk wordt uitgevoerd door libfftw3, welke gebruik maakt van de GPU, die heeft doorgaans toch niks te doen, dus de CPU blijft mooi rustig. En hij is super snel!

Het is inderdaad mooi als je dat rekenintensieve werk op de GPU (Grafische processor) van de RPi kan laten draaien. Die is factoren sneller dan de processor zelf en heeft inderdaad niets anders te doen. Mooi gedaan.