Feedback Kiosk Using Raspberry Pi Pico W

Have you ever seen those kiosks at airports with smiley-faces on them? As you walk by, you hit a big button to express how you feel at the time. Well I was looking for a reason to play around with the Raspberry Pi Pico W, and thought that trying to recreate my own version of one of these would be a fun project.

The whole system is split into two parts: the physical kiosk, and the server backend/frontend. The physical kiosk connects to WiFi, logging all button presses both locally and sending them to the server backend. There's also a nice little web frontend to see some daily statistics on which buttons are being pressed.

The Kiosk

The Feedback Kiosk box and its internal wiring.

The brains, and main component, of the kiosk is a Raspberry Pi Pico W but to get all the features I wanted, I also included the Adafruit Adalogger. The Adalogger is a combo real-time clock and SD card adapter for the Pico essentially built for logging, exactly what is needed for the kiosk. Aside from those, I also picked up a few large push buttons off Amazon and a small wooden box from Walmart. I think the push buttons are targeted at people wanting to make their own Pop'n Music controller, but they worked well for this project.

The basic operation of the kiosk is pretty straightforward. It constantly waits for button presses and, when it detects a press, logs it locally to the SD card and uses WiFi to send it to the server for safer keeping. One of the cool features of the Pico is that it is multi-core. So, one core can constantly check for button presses while the other can handle the logging and HTTP requests. This has the advantage of the main loop never getting blocked by slow WiFi and we never miss a button press.

Another interesting feature I built into the kiosk is a simple webserver that allow users to change the WiFi connection settings. If the kiosk can't connect to a WiFi hotspot, it starts itself as its own access point. Connecting to this access point from a smartphone takes the user to simple webpage where they can supply an SSID and password. Pretty handy when moving it between different locations.

Alternatively, the kiosk can be started in offline mode by holding down the red button on boot. This will only log to the SD card and not try to use any wireless features.

The Server

Screenshot of the Svelte webpage to view daily button presses.

For the server backend, I wanted to try programming something new decided to try writing it in Rust using the Actix web framework. I don't think this project was really large enough to get a good grasp on Rust, but it was a nice learning experience for sure. Normally, I would have used C and bittyhttp for a small project like this.

One thing I liked with Rust was its great package manager and compiler. It made it very easy to get whatever libraries I needed and statically cross-compile the whole application into a single executable. Then I could simply copy it over to the server actually running it. I know this is possible with other languages as well but Rust's package manager and compiler just made it so easy I really appreciated that.

Currently, there are only a few endpoints built into the backend: one to receive button presses, one to send back all button press data (for the frontend), and another to send the current time information to kiosk which is handy for setting the RTC.

As for the frontend, I stuck with Svelte, which I have use for several projects in the past. For simple cases like this one, I find that it makes things very easy and quick to get the behaviour that I want. My favorite feature of Svelte though is the ability to compile everything to static pages, meaning I don't need any other server components running aside from the backend.

Closing

Although this whole thing is very much a prototype, I think it would be really fun to deploy the feedback kiosk somewhere that is busy enough to get a lot of data. I'd really like to see how people's mood changes throughout the day, or even throughout a week.

Code for this project is also available on GitHub: https://github.com/cluoma/big_button

Thanks for reading!


Tags:


Detecting Northern Lights using Raspberry Pi and Convolutional Neural Network - Part 1

Pi Camera and a Northern Lights image with prediction.

At the moment, I'm fortunate to live in a part of the world where visible Northern Lights are fairly common. The problem is though, they may only show up for a few minutes during the night so you have to either be a real night-owl or get lucky. I wanted to build something to help me catch the Northern Lights more often.

The idea mostly came after seeing the recent release of the Raspberry Pi camera module 3 and wanting an excuse to do something with it.

In this blog post I'll go over the proof of concept of the idea and how I hope to develop the project into something a little nicer.

I already had a bit of a head-start on the some of the infrastructure from a previous project of mine, a Raspberry Pi baby monitor. It's a two-part setup a camera-equipped Pi Zero W and a separate server component running on my home server. The Pi Zero is a 'dumb' piece that only takes pictures every few seconds and sends it via http, while all the business logic of collecting, storing, and displaying pictures sits on my server. This makes it easy to unplug and move the camera around without causing too much trouble to the whole system's operation.

For this particular project, my Pi Zero got a camera 3 upgrade and was pointed straight at the sky out my north-facing, upstairs window. It captures a picture every 5 seconds and sends it to my home server where it's stored for later; most nights capturing about 7000 images. Each image is stored in a folder and metadata about the image is written to a small sqlite3 database. To label the images, I was able to use my computer's image previewer to quickly scrub through a nights worth of images and mark them in the database as either containing Northern Lights or not. It only took about 30 minutes per night but it was pretty boring work none-the-less.

With labelled images, I could sort them into a proper training dataset of 'aurora' and 'sky' pictures. I then trained a large convolutional neural network built using the Keras Python package to classify the pictures. The Keras documentation has a nice article called 'Image Classification from Scratch' which was a good starting point for this task. It shows how to build a model to classify pictures as either dogs or cats, so it was fairly straightforward to adapt it to the task of classifying 'Aurora' or 'No Aurora'.

Below is a YouTube video showing a full night of particularly active Northern Lights. The 3rd number in the top-left of each image is the prediction from the trained neural network, the closer to 1 the number is the more confident the model is that the picture contains Northern Lights. None of the pictures in this timelapse were used in training the model. Skip ahead to 0:50 to see the Northern Lights in action!


With the concept proven, I'd like to build the whole project out a little bit more. The step 2 is to build a proper webapp that can receive pictures from the Pi, classify them, and display them. The best pictures (according the model) will get saved, and on really good nights it should send me a text message or some other notification. It will probably be a bit tricky to come up with a good heuristic for this, as sometimes Northern Lights will be gone within a few minutes.

Step 3 is to build a better enclosure for the Raspberry Pi so that I can move it outside to a more permanent location. I'm more of a software person so I haven't thought too much about this. If anybody has any god suggestions please let me know.

That's it for now. Thanks for reading. I'll try to put the code and training pictures on GitHub soon.

Update

I've been playing a bit with Google Colab and thought it would be a good way to share the training code and data for this project.

Python Notebook: https://colab.research.google.com/drive/1CFNfKZH_WyrGN71t4Jx4NU-FzBTAeZP5?usp=sharing

Training Images (1.4GB): https://drive.google.com/file/d/1N8uuIMo6AzM6SGoTBQh7iWK_SGIOyh6n/view?usp=sharing


Tags:


Interactive Digit Classification Using Neural Network Trained on MNIST Data

Several years ago, I created a fully connected neural network from scratch in C as a learning exercise. I followed the first few chapters of Michael Nielson's book 'Neural Networks and Deep Learning' that I highly recommend.

The network was designed to train on the MNIST number dataset, which is a well-known dataset used in many machine learning examples. The goal is to identify hand-written digits as any number between 0 and 9. The final network performed quite well and achieved 97.14% accuracy on the test dataset. Not bad for a bit of matrix algebra wrapped up in some C code.

Anyways, ever since then I've had the idea to create a little browser widget to let people use the model I trained in an interactive way. Of course, I was beaten to the punch once, twice, and many more times I'm sure. But even still I wanted to see how well my model would perform at this task.

Homemode Fully Connected Neural Network

Before starting to work on the widget, I beefed up my neural network a little bit and was able to train one with a 98.2% accuracy on the test MNIST data. I then used a web framework called Svelte to create a drawing and predicting widget. Since my model is all simple linear algebra, exporting the weights from C and hard-coding them into Javascript was not too much work. Libraries like Math.js made it pretty easy to recreate everything. The final product is the widget you see below. It runs entirely client side in the browser using my trained neural network.

* does not run on iOS Safari, possible macOS Safari as well *

If you tried a few numbers, you probably noticed that the predictions can often be rather poor. I found that it has a really difficult time with '1's , '0's, and '9's. It was a bit disappointing, even with a 98.2% accuracy on test data, it still has a lot of trouble with new numbers. My guess is that, due to the fully-connectedness of the network, it has a difficult time generalizing new data. Like, if a '1' is off to the side or at a wrong angle that isn't present in the training data then it will predict incorrectly.

Keras/Tensorflow Convolutional Neural Network

Another type of network often used on the MNIST data is a convolutional network. I won't go into the topic here but this explanation was pretty helpful for my understanding. Convolutional networks work so well on MNIST that it's actually one of the 'getting started' examples for Keras.

I wanted to see how much the widget would improve with a convolutional network instead of my fully-connected version. So, I followed the Keras example and trained one in Python that reached an accuracy of 99.3% on the test data. Crucially though, I believe that it generalizes much better and is therefore more tolerant to digits that may not be presented in exactly the same way as in the training data. And the results definitely show, in my testing it seems to predict the correct digit much more often then my homemade model.

Again, the widget below is running entirely in the browser using the the Tensorflow.js library. Tenforflow.js allowed me to export the model from Python and import it directly into the Svelte widget.

* does not run on iOS Safari, possible macOS Safari as well *

Embedding Widgets

Because the widgets run entirely client-side, feel free to embed them anywhere on your own site using the code snippets below. They are web components that use a shadow DOM so should always look the same no matter where they are embedded. Kind of like frame, but for the modern age.

<script src="https://www.cluoma.com/js/mnist_widget.js"></script>
<div><mnist-checker-widget /></div>
<script src="https://www.cluoma.com/js/mnist_convolution_widget.js"></script>
<div><mnist-convolution-checker-widget /></div>

Full source code for this project is posted on my GitHub.


Tags:


More Threading Possibilities in bittyhttp

bittyhttp is a C library that I've been working on that aims to make building web services in C as easy as possible. Check out my last post for a better description and to see some examples.

One use-case that I see for bittyhttp is adding HTTP functionality to existing C applications. For example, if there is a long-running process somewhere on a server, it would be easy to expose some of its configuration over a web interface using bittyhttp. So to target this use-case there are a few changes to bittyhttp to make this particular situation easier.

Users can now start the server in its own thread. For example:

int
main(int argc, char **argv)
{
    bhttp_server *server = bhttp_server_new();
    /* setup server, add handlers, etc. */
    bhttp_server_start(server, 1);
   
    /* continue with normal application execution */

    bhttp_server_stop(server);
    bhttp_server_free(server);
    return 0;
}

This starts bittyhttp in a separate thread and returns immediately. So one could insert this at the appropriate place in an application to easily spin off an HTTP server. Then, when needed, a simple call to bhttp_server_stop and bhttp_server_free will shut down the server and free resources.

In this mode it is also possible to register new callback handlers while the server is running, adding even more flexibility. Overall, this is a small update but I think it makes it much easier to use and incorporate into other applications.

In other developments, I've also been experimenting with some sort of Lua interface to allow writing callbacks in Lua. I've actually used this in another project of mine but I'm not particularly happy with the implementation. So it's still squarely in the experimental category.

bittyhttp is distributed under GPLv3. However, if you're interested in incorporating it into your project, and need another license, feel free to reach out.

Thanks for reading!


Tags:


bittyhttp - A Threaded Library for Building REST Services in C

bittyhttp is a new library that I've been working on that aims to make building web services in C as easy as possible. Microservices and HTTP APIs are very common these days and bittyhttp offers the ability to implement these in C without much hassle. It takes care of running the server so all the user needs to do is implement their callbacks.

When using bittyhttp, the user registers handlers to URLs with a callback function pointer. If an HTTP request is received that matches the handler URL, the callback is executed. Inside the callback, information about the HTTP request is exposed and allows the user to decide how they would like to handle the request. If no handler is found, bittyhttp defaults to acting like a standard webserver.

Check out the full project on GitHub.

A Quick Example

For instance, we can register a simple handler like this:

bhttp_add_simple_handler(server,
                            BHTTP_GET | BHTTP_POST,  // http methods
                            "/helloworld",           // pattern to match
                            helloworld_handler);     // callback function

And then implement whatever logic we need in the callback like this:

int helloworld_handler(bhttp_request *req, bhttp_response *res)
{
    /* business logic */
    bstr bs;
    bstr_init(&bs);
    bstr_append_printf(&bs, "<html><p>Hello, world! from URL: %s</p><p>%s</p><p>%s</p></html>",
                      bstr_cstring(&req->uri),
                      bstr_cstring(&req->uri_path),
                      bstr_cstring(&req->uri_query));
    bhttp_res_set_body_text(res, bstr_cstring(&bs));
    bstr_free_contents(&bs);
    
    /* add custom headers and response code */
    bhttp_res_add_header(res, "content-type", "text/html");
    res->response_code = BHTTP_200_OK;
    return 0;
}

Because bittyhttp uses a separate thread to handle each request, some care needs to be taken in the callbacks to prevent race conditions. Changing data that is not allocated inside of a callback will often require the use of mutexes or similar data structures. A database connection pool, for example, would need to be properly managed.

Use Cases

I see bittyhttp having 2 primary use cases. The first being to implement often-used API endpoints in C, for performance reasons. Perhaps authentication endpoints get hit a lot and you want to speed these up.

The second is adding HTTP support to an existing C application. Maybe you have an existing long-running application on a server somewhere and you want to expose some of its configurations via HTTP. In that case, bittyhttp would be an excellent option.

bittyhttp is GPLv3 licensed, and available on GitHub, but I would be open to relicensing it for specific cases. If you are interested in using it in your application, feel free to get in contact with me at [email protected].

squid poll

As a fun, little proof-of-concept, I created a site called squid poll. It's basically a Straw Poll clone that uses bittyhttp as its API backend. Feel free to visit the site to create your own poll, or fill out the one below:


Tags: