These files were written by J. Steen Hoyer, Carrington lab. He used similar files for top-down timelapse imaging of the vegetative growth of hundreds of Arabidopsis thaliana plants in several multiweek experiments.
The scripts and cron tables here are presented as an example of a minimal imaging configuration and as research documentation. A protocol note published in 2018 provides step-by-step instructions for physical set-up and configuration of top-down and other imaging systems: https://doi.org/10.1002/aps3.1031
It is unlikely
that you will be able to use the files here
without substantial modification.
In particular,
the hostnames for the twelve RasPis
(e.g. ch129-pos01)
are hardcoded into the files.
We suggest
reading the cron table files
and shell scripts.
If they seem useful,
modify them to serve your purpose
(adjust hardcoded hostnames etc.)
and then use them to initiate photo capture
with some moderate number of Pi/Camera rigs
and (optionally) automate transfer of the files
to a remove server.
These files support a manuscript in preparation
by Hoyer et al.
We use standard GNU/Linux utilities
to keep things simple
and easy to modify,
in keeping with the Raspberry Pi spirit.
We encourage plant biologists
to experiment with cron and rsync—they are useful
in a wide variety of situations!
RaspiCam imaging
is a great setting
for developing and practicing command line skills.
Copyright © 2017 Donald Danforth Plant Science Center. See LICENSE.
Useful pages under RaspberryPi.org/documentation/:
- configuration/camera.md
- usage/camera/raspicam/timelapse.md
- hardware/camera/README.md
- raspbian/applications/camera.md
We recommend examining examples of similar approaches:
- http://phenotiki.com – includes tools for configuration via a web browser.
- Ansible-based configuration for ~10-fold larger imaging setups:
- https://github.com/calizarr/PhenoPiSight
- Simplified version for top-down RasPiCam imaging: https://github.com/maliagehan/gehan-bramble
- Gigavision (code, docs) – works with both RasPiCams and DSLRs. Requires ansible, OpenCV 3, and several python packages, including Flask.
The files in this repository are used for acquiring data. For processing and analysis of the resulting image files you may want to use PlantCV or one of the many other available software packages listed at plant-image-analysis.org
See TAIR page for some information on A. thaliana, including a timelapse video of rosette growth.
We install a cron table on each RasPi.
There are two variants of this cron table:
photograph-every-5min.crontab and
photograph-with-flips-every-5min.crontab.
These are nearly identical
but the second one does horizontal and vertical flips
(-vf -hf flags)
because five of our Pi/Camera rigs
are oriented 180° opposite the others.
Files get names like ‘2017-02-10_2230_ch129-pos01.jpg’,
where ‘2230’ is a UTC timestamp
indicating 4:30 PM CST (the last capture of the day)
and ‘ch129-pos01’ is the hostname
(chamber 129 position #1, above field-of-view #1).
We have imaged plants under short-day conditions
(8 hours of light, from 8:30 AM to 4:30 PM),
with capture throughout the light phase.
See also notes below.
Both cron table variants
turn off wireless connectivity (ifdown wlan0)
for most of the night,
to avoid exposing plants to blue LED light
from the USB WiPi dongles we use.
(This will not be an issue if you use
the built-in wifi module on a model 3 Raspberry Pi board.)
We additionally turn off the green and red indicator LEDs
on each RasPi board
by editing the /boot/config.txt file on each RasPi:
dtparam=act_led_trigger=none dtparam=act_led_activelow=off dtparam=pwr_led_trigger=none dtparam=pwr_led_activelow=off
With these parameters set, light from the red LED effectively becomes an indicator that a RasPi has crashed (but is still drawing sufficient power to function), as opposed to simply suffering from network connectivity problems.
We similarly use a pair of minimal cron tables to similarly avoid exposing plants to blue light in between imaging experiments (1, 2).
File transfer is scheduled with a separate cron table installed on a server: pull-images-from-raspis.crontab. Syncing photos to a cluster makes them easier to process/monitor, and lets us collect more photos than will fit on a single SD card.
Two shell scripts are provided to streamline starting and ending image capture on all twelve RasPis at once.
- The first script
is used at the start of an experiment
(or after adjusting a cron table).
This file copies the appropriate cron table
onto each of the twelve RasPis
(if necessary)
and then installs it.
The script is run without arguments:
./install-twelve-crontabs - A second script (install-twelve-mini-crontabs) is used at the end of an experiment (see below) to install the minimal cron tables described above and thereby suspend image capture.
The next section describes use of a third helper script for taking and viewing a single snapshot.
- Take snapshots to convince yourself
that plants are positioned appropriately.
This is an excellent time to photograph color standard cards,
to enable later assessment of sensor drift.
To take a snapshot with the RasPi in position #1,
run the script like so:
./take-one-picture-and-pull-it-with-rsync /path/on/cluster/ 1- You could run this command (and the next one) from your local computer, but things will be easier if you run them on a remote server.
- Install the correct cron table on each RasPi
(as mentioned above)
to start regular image capture:
./install-twelve-crontabs - Double check the server cron table. Is the correct (hardcoded) destination path on the server specified?
- Install the server cron table
to pull photos:
crontab pull-images-from-raspis.crontab
See also the note below on #monitoring.
- Stop image capture;
reinstall cron tables that just monitor lights
and cycle wifi on and off:
./install-twelve-mini-crontabs - If desired, photograph color standard cards,
as you remove plants
or shortly thereafter,
as above:
./take-one-picture-and-pull-it-with-rsync /path/on/cluster/ 1
Watch out for color drift
and consider including standards in your field of view.
By default, raspistill automatically picks
exposure and color balance settings
based on a five second video preview.
This has been sufficient for our purposes
and provides a starting point
for testing other settings,
but it means that the white balance and capture conditions
can vary over the course of an experiment.
In particular, the blue rubber mesh
often placed over soil
for image-based phenotyping experiments
(see e.g. Junker et al. 2014,
Figures 3 and 4)
can cause color balance “overcompensation”,
resulting in an orange tinge.
This tinge steadily recedes over the course of an experiment
(as plant leaves cover the mesh),
which further complicates image processing.
- We embed raw Bayer data
into JPEG file exif metadata
(
raspistill -rflag) to enable post-processing, but we only do this for the first and last capture of the day, to conserve disk space and network bandwidth. - The author of the python
picamerapackage recommends fixing shutter speed, analog gain, digital gain, white balance (red and blue) gains, and ISO. Exif metadata from a few autocaptured photos may help with selecting appropriate values for each of these variables. - Lots of room for improvement here!
The clock built into our growth chamber control board does not automatically recalibrate itself by synchronizing with a server, and so the clock steadily drifts, at a rate of ~3 seconds per day (~1 minute every three weeks). Unless the clock is manually corrected, the light schedule will eventually shift far enough that the first photo of the day will be captured before “sunrise” or after “sunset.
- The most reliable way to deal with this issue is to manually calibrate the chamber clock shortly before the start of every new experiment. Adjusting the clock in our growth chamber requires shutting it down, which in turn necessitates turning off each RasPi. (Our twelve RasPis use a GFCI-protected auxiliary power outlet built into the growth chamber, via an extension cord threaded through a port built into the exterior of the chamber.) We use a shell script to shut down our twelve RasPis, and they turn back on automatically after power is restored.
- Clock drift is one reason we do not try to “squeeze in” a photo capture at the very start of the day. Instead, we wait nearly nearly five minutes before taking the first photo (at 8:35 AM, for example).
- In our growth chamber, the lights take 1 minute to ramp up to full intensity (e.g. from 8:30 to 8:31 AM). The lights turn off promptly at the end of the light cycle (e.g. at 4:31 PM). A one minute margin of safety ensures that we have illumination for the very last photo capture each day.
We have used our local timezone in the past,
but now recommend using Universal Coordinated Time (UTC)
to avoid potential for confusion and/or loss of data
caused by the start and end of daylight saving time.
If you are not using UTC
(controlled via raspi-config internationalization settings),
the start and end of daylight saving time
may trigger an automatic clock shift on each RasPi,
which can result in the photo capture schedule
being offset by one hour
relative to the light cycle.
- We have imaged from 9:30 AM to 5:30 PM local time during DST (CDT is UTC -0500) and 8:30 PM to 4:30 PM for the rest of the year (CST is UTC -0600), These are both equivalent to 1430 to 2230 UTC.
- Some growth chamber controllers automatically shift the light cycle at the start and end of daylight saving time. This shift is arguably bad, because re-entrainment of plant circadian clocks to the new light schedule can alter growth. Shifting the start of zeitgeber (ZT) time also makes the experiment more difficult to describe.
- Switching the timezone on a RasPi
takes effect without requiring a reboot,
but this will not alter cron scheduling
until you
sudo service cron restart
Make sure your RasPis are drawing sufficient power! The camera boards draw extra power during photo capture, which can cause one or more RasPis sharing an inadequate power supply to crash. See https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md
If desired, one can add an email address (MAILTO variable) at the top of the server cron table. This contact address will then receive an email every time an rsync transfer fails. This measure is noisy: a failed transfer is usually caused by transient wifi interference, and merely delays transfer of the relevant files until the next cycle. Multiple failed transfers can indicate that a RasPi has crashed, especially when initial connection was the step that failed. (Interrupted transfers are a lagging indicator, because rsync processes persist for quite a while before they “give up.”)
We additionally use a Ganglia dashboard for monitoring. See http://ganglia.info
Researchers at the Danforth Center will likely continue using these scripts for imaging experiments. We plan to share any improvements we make, but it is also possible that we will supplant this code with something else entirely. To reiterate: we make these files public primarily as a learning aid and as documentation for related research papers.
Questions and feedback are welcome via GitHub issues or email (see file headers). Mirrors of this project are available on Bitbucket and GitLab.com. Numbered releases are archived on Zenodo.