The serial number is available at /sys/firmware/devicetree/base/serial-number.

This could be used to track unique PlanktoScope builds in a database and their scientific contributions.

Commit 20e07a1 introduced a bug where the adafruit HAT is not working anymore.

Describe the bug
Few metadata used in Node-Red can't be processed by EcoTaxa since their names doesn't start by either of the following classes of metadata :

• object_*** - metadata relative to one object to be classified, usually one organism.
• acq_*** - metadata relative to the image acquisition
• process_*** - metadata relative to the processing of the raw images
• sample_*** - metadata relative to a collection event

Expected behavior

• Rename custom_nb_frame by acq_nb_frame
• Don't store custom_nb_step, custom_sleep_before, focus_nb_step, pump_flowrate and pump_manual_volume as metadata

Screenshots

We need to improve steps precision and speed, eventually acceleration/deceleration for the pump.
Also, we need to have control over the maximum current draw (today, there is no limit and it happened that a stepper hat was fried due to an overcurrent)

https://www.waveshare.com/stepper-motor-hat.htm
https://www.st.com/en/evaluation-tools/evalsp820-xs.html#

Describe the bug
The archive created by MorphoCut has a fix name export_ecotaxa.zip and is being overwritten during each segmentation.

Expected behavior
Rename export_ecotaxa.zip by a unique identifier including project_name, datetime and sample_id.

Parameters for the segmentation are hardcoded. However, some objects require different settings. There should be a way to change the parameters of a standard pipeline run.

Sometimes, during an imaging session, the camera will simply not capture and will wait forever the capture to happen.

This happened two times, once on the third picture taken, the second after ~800/1000 pictures.

Maybe we should stop the streaming server before starting the capture?

We should list the metadata we want to save during a sampling and during an image analysis.

Top of my head:

• gps position
• date and time of sampling
• sampling volume
• sampling duration
• sampling speed
• sampling device

I'm probably missing a lot, please add to the list!

Allows for a better traceability of metadata solely based on the image file.

Tag details are at https://www.exiv2.org/tags.html

The direction is hardcoded in the python script, at imager.py line 377.

There should be a way to decide beforehand which way the pump is running.

This issue is closely linked to #44 .

Right now, we have a semi-automatic system in place of management of ids.
sample_id is a number incremented by one on startup, the rest is static and user configured.
However, users commented that sample_id could also be a name, date, etc...
So this field should not be a number only that is incremented automatically.

acq_id and process_id on the other hand could be incremented automatically, that is if a capture of a particular sample already exists, the acq_id could change. Or better yet, we should ask the user what to do.

Same goes for process_id even if for now we don't have a way to change the segmentation settings in the UI (this is tracked by #60).

If the movement of the focus stage is too low, the flow cell crash against the bottom of the lens.
This could lead to a cracked and leaking flow cell, or in the worst case scenario a Rapid Unplanned Disassembly of the flow cell leading to water potentially leaking towards the electronics.

We thus need a way to limit the focus stage movement. It could be implemented in software, but it should also exist in hardware, to prevent malfunction linked to a bug or a crash.

For now, master images are created using the golden record method (we create and setup a new raspberry, set everything up by hand and once it works, we pull the image from the sd card and share it).

While this method works, it's not very efficient, quite time-consuming, error prone and leads to big images to be shared with no opportunity for first time setup and such. Setting up pi-gen could be a good way to streamline the image creation process, to allow for reproducible builds and make released easier and faster.

The current dashboard is a one page document. The elements are grouped by functionality, but to improve usage and readability, we should separate the different logic elements to different tabs, with logical navigation between tabs.

Maybe something @AurelieLabarre would like to have a look at?

A main BOM exists that can be used in the US. Several european suppliers BOM were created by people reproducing the build. These BOM should be unified and listed in the documentation to help people source the various components.

After assembly and setup of the Planktoscope, it is not clear the steps that should be followed.

We need to write a guide to cover those steps:

• full tests
• first pictures
• calibration of the machine
• plankton collection with nets
• basic and advanced workflow for data and image creation

We need to make sure the chosen LED is bright enough and its lifetime is satisfactory.

When using the PlanktoScope in a very bright environment, stray light degrades contrast of the pictures.

Simple cover elements could be used to protect the sample chamber and keep it dark.

We need to stabilize the node-red flows and python script to make them both more robust and more modular. This should improve on-boarding and code understanding by new users, but also make it simpler to have the system evolve over time.
Also, setting this up will allow us to remove all the hard-coded values and addresses from the code (for example in the python code or in the node-red flows).

If the machine has no access to an NTP server and no GPS signal, timekeeping is not being done.
On a reboot, you expect that the clock will at least start up from where it left. This is not the case today.

After a successful time synchronization, either through GPS reception or through a NTP server, the time is saved on shutdown. On startup, the clock is restored to this state and runs normally (you know the way, one second per second). However, on this subsequent shutdown, the time is not being saved, meaning when we start up the machine a second time, it will go back in time (way more efficient than with a Delorean).

Anyway, this should be fixed.

In the readme, RPI_Cam_Web_Interface is set to launch automatically and it shouldn't.

We have to make sure the configuration has been set before we start the imaging session

On plugging an external drive with a directory named PlanktoScope Data, a copy of the local data should be triggered.

Right now, the optical path is kind of hard to clean. We need to find a way to clean it, especially the slides that are very exposed.

Maybe so isopropanol with a non-woven tissue would do the trick and not leave anything trace behind.

The GPS coordinates are not saved in the metadata. We need to properly manage this.

We need a way to update automatically the onboard files to get the latest version of the software (mainly configuration files, flows, etc).

This could be a simple bash script launched from the UI that pulls and update the local repository.

The imaging plate is only maintained in position by the two nuts on the stepper focus screws. This is clearly not rigid enough since small movement can happen back and forth. This could lead to a premature failure of the plastic nuts leading to a complete replacement of the stepper assembly.

A proposed low tech alternative is to only have manual control of the focus stage. If we reduce the different flow cells number (see #21) and lens disparity (#36), the interest in having a motorized focus stage is reduced a lot. The stepper assembly could then be replaced by a simple screw/nut assembly with two sliding rods on the side for guiding.

Raw output format of the PlanktonScope needs to be “fit for archive”, meaning we need a zip file with the images and an according txt file with the metadata (Lat, Lon, Datetime, Depth, Instrument set up, Segmentation algorithm details) that we can submit to a recognised data archive (zenodo, seanoe, pangaea or the like) in an almost automatic fashion. That way, we can submit it, get a DOI and then build the tools to analyse the data on the archived raw material (e.g. import to EcoTaxa and sort it there, but also other data processing will then be enabled). As datasets get a DOI, it will be easy to follow the data.

PlanktonScope should have a 'play' mode and a 'fit for archive' mode. Fit for archive mode will require all metadata set properly (including automatic tests; e.g. lat lon format correct, time correct, e-mail address of data provider, ...)

• need to decide on an archive where to put the data

• need an agreement in the PlanktonScope user group that data is first submitted to archive

• data processing should follow the fair principles: https://www.go-fair.org/fair-principles/

Plankton can easily sink in the sample chamber. A gentle agitation could be provided by bubbles.

We need to source an appropriate peristaltic pump, with consistent quality and availability.
Kamoer pumps seems to be appropriate candidates (see the catalog at http://kamoer.com/upload/file/201910/1571712939838489.pdf ).

We need to choose one or two models, get them to run 24/7 and see their lifetime (in terms of total volume pumped or something similar).

Right now, there is a delay at the very beginning of the imaging session.
The delay should happen right before taking every picture, so the flow can stabilize before we capture the image.

The led color messages are not listed. It is thus difficult to know the state of the Planktoscope.
Transforming the planktoscope.light module into a class would allow us to define clear color states and actions linked to those states.

If we have a dirty shutdown of the imager script (via a sudo killall -9 python3 for example), the script sometimes doesn't start and fails silently on the camera instantiation. The only way to salvage the situation is to do a full restart of the machine.
So yeah, not good.

One way to manage this could be to capture signals in all the sub-scripts. Another way could be to wrap the camera api calls in try ... except wrappers.

Using glue for mounting make things permanent and the part assembled in this way cannot be unmounted or adjusted after setup.

Specifically a new way to fix the focus motors should be found.

Changing the flow cell necessitate to operate in the region of the lens, and neodymium magnets of the lens are interacting with the one blocking the flowcell (plus often need to loose the focus zone because the space is not large enough)

Could be solved by inverting the design between the fixed flowcell holder and the amovible flowcell holder (which would Then be on the side of the led light)

When the PlanktonScope folder is bloated (for example with thousands of pictures), node-red becomes super slow on deploy (i.e. when deploying the flows from the interface, node-red becomes unresponsive for several minutes).

This is fixed by moving the img and export folders to /home/pi/data.

Ibidi flow cells are expensive, hard to find and quite fragile.

A proposed inexpensive alternative is to use a flat capillary glass tube. Suppliers are still being searched.
A 3D printed support for this tube could be used to mount it in place of the ibidi flow cell.

The bottom stepper motor for focus can block (dust on it?). A gentle manual help unblock it

We should get a protection to this to avoid mist and dust on the focus structure

We should also have an image dataset to compare and intercalibrate different versions and parameters of the image processing pipeline. Preferably with manual measurements of the original physical sample.

I guess it would be impractical to run one specific wet sample through the machine again and again, as the sample will decay over time. I'm only talking about image processing after capture: Different image image enhancement methods, segmentation methods, ... We need to compare different pipelines among each other in terms of the numbers that are relevant in downstream analyses (biovolume/biomass estimates, abundance estimates, what else?).

What measures are needed here? Please complete the list.

• Biovolume
• Biomass
• Abundance

Right now, we don't have a good way to know the real imaged volume and how much the pump should be running inbetween two pictures.

We need to find a way to waterproof the electronics. Doesn't need to be IP69, but at least resistant to spray.

A good way to do this would be to use a waterproofing spray (some kind of water repellent spray). A simple very low cost and widely available solution could be to use a fine mist of WD40 (this doesn't dry, so it will leave the electronics kind of moist to the touch).

We need to improve on two fields:

• depth of field
• field size

To that end, we need to have a systematic approach to test lens combination and decide on the best compromise.
Fabien reports having tested with a simple macro lens for smartphone as the reverse lens and to have great results, however we currently have no way of measuring the field size.

Ideally, the lens combination is fixed before Tara's test

Have you experimented with strobing the LED to increase image clarity and/or capture rate?

It's not possible to have a simultaneous movement of the focus stage when the pump is running and vice versa.

This functionality could be useful when doing focus for example as it helps to see the particle movement in the imaging chamber.

We have no guide on how to assemble the kit, only the Google Slides. This is not enough and more information and guidance is needed.

The lens thread are sometimes fragile. We need a way to improve the lens mount, make sure they are perpendicular to their support and make sure the thread is not biased.

It is easy to play with settings, but we should add way to return to « recommended » settings

Bonus: if the settings could be saved in an easy configuration files, users could save their preferred settings (and we could provide several preferred depending on the lens)

We need to find a way to extract the collected pictures other than having to connect through ssh/ftp to the planktoscope.

I'm thinking about setting up a basic webserver that would list the directory where the zip files generated are located.

This basic webserver could eventually also host the streaming flux from the camera.