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
breaks: false
Abstract - Menna
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
Copyright and licensing
FIXME: this section cannot be a subsection of Abstract:
Abstract must be a standalone section
(which comes before table of contents,
which will happen automatically
when we drop "Menna" from the title)
TODO: suggested alternative location for above section:
last subsection of section "Project Planning and theoretical framework"
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.
Introduction - amal
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 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's 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 - amal og menna
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 the 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 did early prototyping and pseudocoding
for about three weeks.
During this phase, we worked on the sensor setups
and 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.
From these notes, we learned
that API works as a standardized "messenger",
that allows different software applications to communicate
through defined rules and protocols.
API enables seamless integration between the systems.
We decided to use a combination of bluetooth and API,
to connect the sensor-data to the voting program.
Bluetooth handles the connection
between the sensors and our computer/phone,
whilst the API is being used to send/retrieve data
and trigger an output.
A further explanation of this process
will be displayed in @sec-user-guide.
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.
User Guide (product use) - Tanishka {#sec-user-guide}
TODO
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: Used to indicate
FIXME: above paragraph is unfinished
Coding approach - Tanishka
In this paragraph we want to highligt t
FIXME: above paragraph is unfinished
The goal of the system is to replicate
the behavioral response of mussels under stress,
and translate that into a form of output.
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 two major components,
the sensor ... the mussels behavior
and the vote handling system that collects readings
from all mussel instances, evaluates their state
and triggers output.
*FIXME: in above paragraph, some text is missing at the ellipsis (...).
TODO: not sure this text passage belongs here,
as it's the program that is interesting in this section
TODO: here we need to introduce the source we know this from,
and to give a little insight
into why there's different roles to choose from
TODO
!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.
!include Arduino/vote/vote.puml
TODO
Testing - tanishka
TODO
Discussion and reflections- jonas
TODO: discussion about our project
e.g. what could have been included, what we couldn't make
SUGGESTION: reflection/discussion about,
whether used the guide from role 3 archetype
(see course curriculum),
and if it was helpful/right/wrong
We have chosen not to use AI in our project.
This is mainly for imitation of the current technology
and for scope purposes.
Although, we have reflected upon how AI could be useful
in an expansion of our prototype
or hypothetically in an existing system.
For an instance, in the future --
when scientists have analysed and interpreted enough data
to feed to a MLM --
ai could be used for detecting subtle behavioral changes,
that humans would otherwise miss,
or spot patterns that further indicates pollution
or predicts contamination or enviromental stress.
FIXME: the abbreviations AI and MLM must be introduced before used,
and then used consistently (e.g. all caps or no caps)
It could also be put into perspective of surrounding cases,
and through datacentric AI,
it could be visualized like a weatherforecast on a dashboard.
It could be based on patterns
like "When x conditions rise, contamination tends to follow."
TODO: in above paragraph, "cases" intents to refer to ANT
This hypothesis would come at the cost of a lot of x,
which would be a research question in itself.
FIXME: in above paragraph, "x" should say something
about consuming a lot of space and resources
Conclusion - menna
TODO
Bibliography {.appendix}
\begingroup
\raggedright
::: {#refs}
:::
\endgroup
\appendix
Code
P5.js sketch light.js {.appendix}
Arduino sketch sensor.js {.appendix}
Arduino sketch vote.js {.appendix}
