Hello everyone, my name is Vito Kortbeek, and I will be presenting our paper
"BFree: Enabling Battery-free Sensor Prototyping with Python"
We want to ditch the batteries. Batteries are expensive, bad for the environment,
and they are very inconvenient to replace, but removing batteries is not that simple
because we need to replace the energy source with something.
We want to replace it with harvested energy, but harvested energy
is sporadically available. It's not always there, and even if it's always there,
it does not necessarily mean that there is enough of it that enables our system to run continuously.
So, we use a small buffer capacitor which is charged by the harvested energy,
and whenever it reaches a certain threshold, that energy will be used to execute.
This is intermittent execution, and to make sure that everything runs smoothly and can
continue where you leave off, so where the system dies, it's intermittent computing.
As I kind of alluded to, the system might run out of energy at any point in time.
And if you look on the right, it would depict a normal system where
the system is running...running, and the system is reset, due to a power failure.
And after a while, the capacitor is charged enough, and the system will boot again, but it
will start at the total beginning of the program. This is not what we want, because that
would be very inconvenient. What we do want is to continue
approximately where we left off. So intermittent computing aims to
continue computation after a power failure close to the point where the power failed.
Existing intermittent computing works on small embedded devices, usually programmed either in C
or in a domain-specific language (DSL) created specifically for intermittent computing.
Well, this is fine for a lot of applications, but it does make it quite difficult for the
general person or the general hobbyist to get involved with intermittent computing.
We wanted to change that.
We took a standard hobbyist microcontroller running
an embedded version of python called CirtuitPython,
which is the "Adafruit Metro M0 Express," and it's known for very plug-and-play development.
You can edit code straight on the board. It mounts as a USB drive with
the Python code on there. You can modify it, plug-in sensors,
use libraries, and off you go. You can just keep on developing.
So, we wanted to make this system intermittent.
We developed a custom shield with all kinds of electronics on there, but most prominently,
it has a piece of non-volatile memory
in the form of Ferroelectric RAM (FRAM).
We created this shield,
and we changed the existing (Circuit)Python interpreter running on the Metro M0 board
to be able to communicate with this shield, and set power thresholds, etc.
And create checkpoints of the current state of the system,
so we can easily revert back to that point in time after a power failure.
And detect power failures, set different checkpoint strategies, etc.
We also changed the interpreter in a way that it would also restore the peripheral state whenever
the system boots and needs a certain peripheral. And during all this, we had the main focus of not
changing any of the existing features of the Metro board.
Even after did all this, and it works intermittently,
you can still connect it through USB, edit your Python files, disconnect it,
and you can still run everything you are used to. Most notably, everything in terms
of the intermittent part is invisible to the actual user.
The user wouldn't see any difference in terms of their Python program or how they use it.
It would just somehow, magically, work whenever you disconnect power and reconnect power.
We did add optional fine-grained control through the use of libraries,
where you can change different checkpoint strategies,
how often it checkpoints, etc.
So on the top right, you can see a demonstration of our system.
In this case, using a solar panel and some sensors.
And a big thing to note here, if you look on the left,
is the energy trace for two different light intensities.
A 1000 and 3000 lux.
And this might seem as a big difference, but this can be as small as a cloud floating by.
And you can see a big difference in how long the system is "on",
which is depicted as the light blue blocks.
If you look on the right, we zoom in on one of these blocks.
And here (the light blue is), the blue, in general, is executing.
Light blue is when it's normally executing,
and dark blue means that it reached a certain voltage threshold.
So it's close to having a power failure.
And this is all configurable in the software, but optional.
And the top one is a "periodic (checkpoint) mode,"
and you can see it is very over-provisioned with checkpoints.
There are a lot of checkpoints there which might not necessarily be needed.
And then below that is a "hybrid (checkpoint) mode",
which can be dynamically changed to at any point in time through the Python code. If you want to.
Here you can see that during the light blue operations,
(which is) normal operation, there are not that many checkpoints.
And when it's close to a power failure,
suddenly more and more checkpoints come in (are created).
This is just one example of how you can change the system on the fly.
So, just to conclude.
We instrument the first interpreted language to have intermittent computing support.
It is very easy to use, which can also be seen in
some of our user studies we did, for which you can see the paper.
And we transformed an existing complex system
to be intermittent without compromising on functionality.
For more details, please check out the paper with the link below.
And another thing is that everything is open source,
so we have a GitHub page where you can find the hardware,
the software, all the changes we did,
and how to build it. Online.
Thank you for listening.