title: Mussel-driven voting system
date: 2025-04-23
toc-depth: 2
format:
stylish-report-pdf:
pdfversion: "2.0"
pdfstandard: [A-4f, UA-2]
pdftestphase: latest
metadata-files:
- _actors.yml
keywords:
- voting
- bioindicator
- Arduino
- drinking water
breaks: false
Abstract
TODO: Menna is in charge of this section
(not written in section title itself
since this section must have specific name for layout to work)
This project explores the development of a prototype voting system
inspired by the natural behavior of freshwater mussels
detected and examined by biomonitoring.
We have defined the prototype as a "research archetype 3",
meaning that the driving force for this project
is illustration and demostration purposes.
TODO: come back and write about each step,
OUR THREE REQUIRED COMPONENTS,and a conclusion
Introduction
In Poland, several waterworks use biomonitoring systems
that rely on freshwater mussels to detect water contamination
by measuring and analysing the mussels' gaping behavior
[@FerreiraRodriguez2023 p. 3732]
Our project aims to simulate a similar system.
We will be using Arduino-based hardware and software to do so,
and have additionally made a p5.js program to simulate night and day,
which influences the pseudomussels' behaviour (reaction).
We have defined a research question to work around:
How do we simulate and visualise an existing biomonitoring technology
for its core purpose
Our simulation is inspired by SYMBIO --
a biomonitoring system --
developed by the company PROTE
[@Prote2024].
The SYMBIO system measures the opening angle of the mussel
once per second,
by using magnets attached to their shells.
Superficially, if the mussels gape is closed, it is a bad sign,
and if it is open, they are happy
and there is no sign of water contamination.
There is a wire from each mussel/magnet that connects to a computer.
The computer then processes the data in following phases:
collect, align, qualify (and analyse) the gaping data,
and then --
in our understanding of the process --
treats the now normalized data as votes
[@Prote2024].
The threshold we are inspired by for these votes
will be defined in a a later paragraph.
To be more in depth about the mussels behavior,
the gapes are not as simple
as just opening/closing their gap to signal happy/unhappy,
but is more of a behavioural spectrum.
Therefore, if either half of the mussel closes rapidly,
or if a mussel remains closed for a long time,
it indicates contaminated water.
An alarm will then be triggered
and further laboratory tests are done
[@Nazaruk2016].
To meet this question,
we will be using touch and light sensors
to represent our virtual models on Arduino --
also referred to as pseudomussels --
and they should mimic somewhere close to real mussel responses
such as normal behavior or stressed behavior.
Although our coding logic is inspired
by an existing study and implemenation,
we wish to delineate ourselves from the real-world criterias
that concerns this technology and actual authentic mussel behaviour.
Project Planning and theoretical framework
Use of course curriculum
The beggining of our work process
consisted of researching bioindication as a concept
and the associated technology.
Then we tried to define the purpose of our prototype.
Were we interested in the UI/UX design?
or perhaps we wanted to prototype a fitting reaction
that leads to a dramatic output? Should the prototype be useful or
spark reflection? is it merely a state of the art prototype?
Concurrently, we learned about the roles
artefacts can play in a research process,
and used that framework to help define the aim of our project.
The following framework, as introduced in @Wensveen2014,
explains how prototypes can serve different purposes
depending on the type of knowledge a project aims to produce.
A "role" consists of characteristics
that helps guide the design process
and scope of the prototype.
There are four roles to choose from,
and we chose to work from the perspective of role number three,
which views the prototype as a research archetype
and tool for critical reflection,
in both a physical and abstract sense
[@Wensveen2014 p. 8-9].
Next we each had an early prototyping and pseudocoding phase,
were we worked on the sensor behaviour,
on the logic behind the voting mechanism
and the possible communication-methods between them.
Our project group has received a brief introduction
to APIs during a lecture session
and through additional notes on the topic,
that are available on the lecture slides for week 5,
but it is explicitly stated as "Not a part of the curicculum".
Hence we have searched for external sources on API knowledge.
We decided to implement a loosely coupled network design
as described e.g. in @GeeksforGeeks2024,
to connect the different components
and allow each of them to operate independently,
whilst still being able to exchange data.
We chose to use the BLE Beacon API --
specifically the Eddystone protocol
as described e.g. in @AccentSystems2021 --
and focused on TLM (telementry) frame type.
The original purpose of of TLM
is to transmit temperature and battery level,
but we repurposed it
to make the temperature show the gape angle data instead.
The sensors appear in the debug interface
of one of our android phones,
indicating that any system supporting this API
could interact with our sensors.
Detecting stressful mussel behavior
We wish to expound some of the ways
that freshwater mussels behave and how the detection works,
in real-life implementation.
The thresholds and logic for our sensors and voting-mechanism
are mostly based upon the following.
The use of a mussel as biodetector requires distinction
between slow-paced valve gaping change (normal),
paused valve gaping at the closed position (resting or starved)
and rapid valve gaping change (stressed)
[@Miller2022 p. 1097; @Robson2006 p. 1200].
Detecting behavioural change to a rapid gaping pace,
measurements are needed at a much higher sampling rate
than that of the normal gaping pace.
E.g. one mussel with normal gaping pace of about 1 minute
required a sample rate of 5 seconds to detect its normal pace,
and another mussel with normal gaping pace of 3-4 minutes
required a sample rate of 0.5 seconds to detect more rapid cycles
[@Robson2009 p. 195].
Another measurement of both normal and stressed behaviour,
assuming that x-axis is in seconds (not hours as indicated),
similarly shows a need for fast sampling rate
to detect a normal pace of about 1.2 minutes
and a stressed pace faster than the visualized resolution
of about 1 second
[@FerreiraRodriguez2023 fig. 2].
One concrete approach used in @Robson2009 and @Robson2010
is to collect data at a sample rate of 0.5 seconds, i.e. 2 Hz,
and convert that into gape angle per second (CHIGA)
to then monitor gape movement instead of gape position.
Additionally, we wish to refer to the bachelor thesis @GarciaHuertes2016
that covers some of the same themes as our report
but are prototyping with real mussels.
The report covers mussel behaviour and stress,
the SYMBIO system and biomonitoring more in depth,
and has added to our understanding of the subject
[@GarciaHuertes2016 pp. 11-15].
Copyright and licensing
To encourage collaboration and stimulate a circular gift economy
as introduced by @Mikkelsen2000,
this project is copyleft licensed:
Code parts are licensed
under the GNU Public Licence version 3 or newer,
and non-code parts are licensed
under the Creative Commons crediting share-alike 4.0.
Analysis and Design (physical components) - Menna
The physical setup of our prototype consists
of a simple Arduino-based circuit.
The following components were used:
ESP 32: Runs the core program that simulates mussel behavior,
reads sensor data and outputs voting signals.
The logical parts of the ESP32 used in our setup
include Bluetooth, a touch sensor input, LEDC (LED control)
and a logging system for tracking behavior and communication.
Breadboard: Used to easily connect all components.
Jumper Wires: Connect the ESP32
to the sensors, LED and power/ground rails on the breadboard.
One wire is repurposed as a touch sensor,
detecting when it is touched
and triggering a behavioral change in the simulated mussel.
LED pins: Light up to indicate
if the water quality is good or not.
Light Sensor: Detects environmental input
and triggers a behavioral change in the simulated mussel.
P5.js: Used to indicate
FIXME: above paragraph is unfinished
Coding approach - Tanishka
The coding approach for this project is centered
around simulating behavioral response of mussels
under stress, using sensors
and translate these responses into votes that indicate water quality.
Real-world use of mussels as biosensors relies
on monitoring their behavior to detect environmental stress.
In our project, we simulate this behavior using programmable hardware.
The system is composed of three major components:
- p5.js Interface --
Simulating environmental changes like day and night.
Allows the user to control the light conditions using a button.
- Sensor (Arduino) --
Each sensor simulates a mussel.
It reads light and touch input,
changes internal "stress" levels accordingly,
and outputs a "gape angle" via BLE
using the Eddystone TLM protocol.
- Voting System (Arduino) --
This unit scans BLE beacons sent by sensor mussels.
Each beacon includes a simulated gape angle.
The latest measurements per mussel are stored and evaluated,
if the data is recent and valid.
It determines whether the water is drinkable using a voting rule.
TODO: here we need to introduce the source we know this from,
and to give a little insight
into why there is different roles to choose from
!include components.puml
TODO: if the plantUML is here,
we should have a text section that explains it also,
and show snippets
of our most important/difficult code for each-ish file.
The p5.js code shows a button
where, when you press it, it changes from day to night.
This change helps the mussel to know how to think?
The p5.js code is connected to the sensor system.
Here it reads the data from the the p5.js and normalizes it.
FIXME: above paragraph need revisiting:
It seems wrong that the sun affects mussels' ability to think,
and the p5.js code does not normalize anything --
probably an interesting and valid point was intended,
but it is unclear with current phrasing what that is.
TODO
Sensor system
!include Arduino/sensor/sensor.puml
Voting system
The voting system is the client that scans after network
to find "is there any beacons here?".
The sensor system is our beacon and it works like a lighthouse.
It sends signals out to say "im here, i exist".
Then Boom! a bluetooth connection is made.
TODO: "... connection is made" can mislead the reader
into expecting a two-way connection
which is not the case in our deliberately loose coupling.
Probably better to phrase it like
"...nearby Bluetooth receivers can capture the beacon message" --
smooth and quiet, no "Boom!"
!include Arduino/vote/vote.puml
TODO
Testing - Tanishka
TODO
Product Use - Tanishka
TODO
Discussion and reflections
This project does not involve generative artificial intelligence (AI)
due to its scope of data collecting and processing
from a source of simple simulations of living organisms.
Related but different projects might sensibly involve AI,
e.g. training an AI with sensor data from real living mussels,
either unsupervised to aid in discovering behavioural patterns
like CHIGA,
Or in a future
where a (non-AI) domain model for mussel behaviours is established,
an AI could be trained supervised,
i.e. generate an AI model supervised with the use of such domain model,
e.g. to help calibrate sensors.
This project succesfully demonstrates
that a loosely coupled set of systems can mimic the systems in Poland
where the behaviour of 8 mussels "vote" about the quality of water.
The concrete output, however,
do not reasonably reflect the logic of the Polish systems,
because the mussel simulation is too simplistic in that
a) mussel gape rhythm is simulated as simple linear movements
whereas real mussel gape rhythm is closer to a sigmoid curve,
and consequently b) voting is based on "is gape closed"
rather than the more telling "what is the CHIGA pattern"
requiring a more realistic rhythm,
leading to our setup concluding "bad water quality" fairly randomly.
That said, the code is structured so that it should only require
minimal changes to change the evaluation logic
given more realistic sensor data,
mainly by rewriting the function alignVotes()
(see code listing lines 154-176 in @sec-vote of Appendix).
Conclusion - Menna
TODO
Bibliography {.appendix}
\begingroup
\raggedright
::: {#refs}
:::
\endgroup
\appendix
P5.js sketch light.js {.appendix}
Arduino sketch sensor.js {.appendix}
Arduino sketch vote.js {#sec-vote .appendix}
