The Snake Eyes Bonnet is a Raspberry Pi accessory for driving two 128x128 pixel OLED or TFT LCD displays, and also provides four analog inputs for sensors.

It's perfect for making cosplay masks, props, spooky sculptures for halloween, animatronics, robots...anything where you want to add a pair of animated eyes!

It’s a follow-on of sorts to another project: Electronic Animated Eyes Using Teensy 3.2. The Teensy 3.2 is a very capable microcontroller, and the code for that project squeezed every bit of space and performance from it. I had been experimenting with the Raspberry Pi as an alternative…while it’s still very experimental, why not make that work available to others?

The Raspberry Pi offers some potential benefits:

  • Hardware-accelerated 3D graphics (OpenGL), including antialiasing.
  • A faster CPU, ample RAM and dual SPI buses could yield faster frame rates.
  • Standard graphics formats like JPEG, PNG and SVG can be decoded on the fly; no preprocessing step.
  • The eye rendering code is written in a high-level language — Python — making it easier to customize.

And some possible downsides to the Pi:

  • Raspberry Pi takes time to boot an operating system off an SD card, whereas Teensy is instant-on with all code in flash memory, . The Pi also requires an explicit shutoff procedure (usually).
  • The Raspberry Pi is not as suitable for wearable applications…it’s larger, uses more power, and the SD card makes it less rugged.

This is a somewhat technical and not-inexpensive project. Please read through everything first before commiting. If it seems daunting, the original Teensy Eyes are more “Arduino-like” to build and customize, or other guides like Animating Multiple LED Backpacks provide a more approachable introduction to code and electronics with less of an investment.

A Raspberry Pi 3 or Pi 2 is highly recommended. The code will run on a Pi Zero or other single-core Raspberry Pi boards, but performance lags greatly. We’re working on this and hope to have solid support for the smallest Pi boards in the future.

Hardware Assembly

Don't forget, our Bonnet only comes with the PCB that lets you connect two displays. The two displays are not included and must be purchased separately!
Some situations don’t require the screens or Bonnet at all! See the “Using Just the Software” page if planning a single, non-interactive HDMI eye.

Compatible Devices

  • The code for this project works only with our 128x128 pixel OLED and TFT displays. Other displays such as our 160x128 TFT or various PiTFT displays ARE NOT SUPPORTED AT ALL, period, not even sorta.
  • Any recent Raspberry Pi board with the 40-pin GPIO header should work. The very earliest Pi boards — Model A and B, with the 26-pin GPIO header — are not compatible. But…
  • A Raspberry Pi 3 or Pi 2 is highly recommended. The code will run on a Pi Zero or other single-core Raspberry Pi boards, but performance lags greatly. We’re working on this and hope to have solid support for the smallest Pi boards in the future.

Plan a Head

Before committing to any particular hardware, think your project through. There are some decisions to be made…

  • One display or two? You don’t have to connect two displays…some of the most creative variants of the “Teensy eyes” had only a single eye.
  • OLED or TFT LCD displays? OLEDs have a wide viewing angle and excellent contrast and color saturation, but they’re somewhat pricey. TFTs make good economy displays if you’re okay with the slightly washed-out appearance.
  • What model of Raspberry Pi to drive it? The latest multi-core boards (like the Pi 3) have ample performance for smooth animation…but their size and power draw might make them best for stationary displays, like maybe a Halloween window prop. Costume and portable installations may fare better with the diminutive Pi Zero, though the animation will be much less smooth.
  • Will the animation be running autonomously, or do you plan to control the eyes with a joystick and buttons? Will the pupils react to light? These require additional components.

There’s one more factor to consider: how do you want everything connected? Think about your intended installation. Is it temporary or permanent? Is space at a premium or do you have ample working room? These can influence your choice of wiring and connectors.

The breakout pins along the edge of each display board are wired up to matching pins on the bonnet boards. But you need the correct row for each display type…

If using OLED display(s): use the “upper” rows (with the word “OLED” between them).

There are 11 pins on the OLED breakout boards, which map directly to the 11 pins on the bonnet board.

Make absolutely certain the wires are in the same order. “SI” and “G” on the display board should go to “SI” and “G” on the bonnet, and each pin in-between…no wires should cross.

If using TFT display(s): use the “lower” rows (with the word “TFT” between them).

There are 11 pins on the TFT breakout boards, which map directly to the 11 pins on the bonnet board.

Make absolutely certain the wires are in the same order. “Vin” and “Lite” on the display board should go to “Vin” and “Lite” on the bonnet, and each pin in-between…no wires should cross.

There’s a common trope in science fiction stories: that there is no “up” or “down” in space. Wiring these displays is a little like that…it doesn’t matter if the wires or headers come out the front or back of the display breakout board, use straight or right-angle pins…as long as those wires get from the display to the bonnet in the same positions and order, everything’s good.

(As for up and down: right now the software assumes the displays are oriented with the breakout pins along the top edge; other rotations are not currently handled.)

Here’s a probable layout for a non-portable installation. Straight header pins have been soldered to the bonnet board and the displays, projecting “up” and “back,” respectively. Two 11-pin female-to-female ribbon cables then join everything.

This might be easiest to assemble (and disassemble), and the straight header pins on the displays make them easy to re-use in breadboard projects later.

…but that’s not the only option.

This TFT display has right-angle hader pins on the front of the board (front, back, doesn’t matter as long as the wires connect in the same order). This makes it very slim, but also a fair bit taller.

And this OLED has an 11-pin ribbon cable directly soldered to the board, no header pins at all. Again…front or back, ribbon could go straight out or can double back across the board…it all depends on your construction and space needs, as long as the pin order is followed. This is the most space-efficient, but requires patience and ace soldering skills, and isn’t easily re-used in other projects.

If using “rainbow” ribbon cables: these have 10 colors, while the displays use 11 wires…this means the cables will have the same color wire along both edges. Therefore, DO NOT rely on a visual mnemonic like “black wire is ground” or “red wire is Vin,” because your cable may have two black wires, or two reds, or two anything. Instead, make sure to manually follow the first wire all the way from the bonnet to the display, make sure they line up right, then install the remaining wires in order.

If you’re really economizing for space, here’s a secret: only 7 wires are really needed…it’s just easier and less error-prone to solder a header at each end and plug all 11 wires straight through. If using the OLED display, the SC, SD, CD and 3V pins can optionally be skipped. If using TFT, the 3v3 SO, CCS and Lite pins can be skipped. Make certain the exact same pins are skipped at the bonnet end, don’t mix them up!

To ensure a clean signal from bonnet to displays, aim to keep your wiring short and tidy. Electrical interference can lead to animation glitches…we’ll explain on the next page how to dial that back if needed. It’s possible to use long ribbon cables (even a couple meters), but it invites problems with interference or signal reliability.

For optional features like joysticks, light sensors, blink and halt buttons, see the “Customizing the Hardware” page.

When finished soldering, you can peel the clear plastic covering off the displays. It’s meant to protect them in shipping and during soldering. But unlike the screen protector on a phone or tablet, it’s not optically pure and makes the display look cloudy.

Software Installation

Start by downloading the current version of the Raspbian Lite operating system from the Raspberry Pi web site, then write this to a 2GB or larger micro SD card using Etcher or similar software.

Use Raspbian “Lite” for this project. Full-featured Raspbian is weighted down with things we don’t need here.

If your target system is a Raspberry Pi Zero, you may find the setup process easier with a spare full-size Raspberry Pi board such as a Pi 3, Pi 2 or Model B+, then move the card over to the Pi Zero when finished. If this is not an option, see this guide for steps to make the Pi Zero act as a “USB Ethernet gadget,” and also create a file called “ssh” in the boot volume to enable ssh login.

Setup will require:

  • USB keyboard
  • HDMI monitor
  • Network, one of:

Insert the micro SD card, connect monitor and USB keyboard (and Ethernet cable, if using a wired network) and power up the board. The system will reboot once shortly after the first boot; this is normal as it readies the SD card. Then, on second boot…

Log in as user pi, with password raspberry. Then run the raspi-config tool for some initial setup…

sudo raspi-config

The following options are recommended:

  • Change User Password.
  • Under “Internationalisation Options,” select “Change Keyboard Layout.” If you’re getting unexpected characters from the keyboard, this is usually why.
  • Under “Advanced Options,” select “SSH” and enable it. This lets you log into the system using a terminal program across the network, so you won’t need the keyboard and monitor in the future.

Next step is to get the Pi on the network. If using wired Ethernet, it’s usually a simple matter of plugging it in. For WiFi, this tutorial can offer some guidance…specifically the “Setting Up WiFi on the Command Line” page.

You may need to reboot once or twice during the above setup procedures; this is normal. Do not continue until the Pi is networked. You can test with “ping adafruit.com” or similar.

The next part may be easiest if you log in remotely using ssh; this allows you to copy-and-paste from this browser window into a terminal. If not, that’s okay, log in using keyboard and monitor and type in this next part very carefully…

curl -O https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/pi-eyes.sh
sudo bash pi-eyes.sh

This downloads and runs a script which installs all the prerequisite software and does some system configuration. It will ask a few questions along the way…

  • Will you be connecting OLED or TFT LCD displays? Can’t mix and match; must be one or the other. (There’s also an HDMI option — see the “Using Just the Software” page for guidance.)
  • Do you want to install the gpio-halt utility? With a button wired between a GPIO pin and ground, this initiates an orderly shutdown (Linux systems hate it when you just pull the plug).
  • Do you plan to use the ADC (analog-to-digital converter) pins on the bonnet? This is for extras light joysticks or light sensors.
  • If your target system is a Pi Zero, do you want to enable USB Ethernet gadget support? This lets the Pi Zero share a host computer’s network connection over a USB cable…you can also log into the Pi using ssh. Or you may have already enabled this with directions above.

After a confirmation step, the script goes about its business, which may take 20 minutes or more…some parts of the software are pretty complicated to install!

You’ll see some compiler warnings as the script runs. This is normal.

When it finishes, you’ll be asked if you want to reboot the system. Enter “Y” to reboot or “N” if there’s further work you want to do first (wrap up later with “sudo reboot” or “sudo shutdown”).

If the bonnet and displays are attached, you should see animated eyes (or something close to it) following the reboot. It may take about a minute to start up, depending on the Pi model and SD card speed. If using the HDMI option, you’ll see a single animated eye and can disregard the steps below.

IT’S NORMAL THAT THE EYES MAY EXHIBIT “GLITCHES” ON THE FIRST TRY. We’ll fine-tune some parameters to get them working right.

If everything seems to be working well, you can skip ahead to the next page and ignore the steps below.

If the eyes are experiencing glitches (video snow, tearing, dropped frames or weird inverted colors), here’s what to do…

Log into the Pi remotely using ssh. Then type the following commands:

cd /boot/Pi_Eyes
sudo killall fbx2

The displays will stop updating. This is normal.

Then, if you have OLED displays, type the following:

sudo ./fbx2 -o -b 12000000

Or, for TFT displays, try:

sudo ./fbx2 -t -b 20000000

The first argument (-o or -t) sets the display type in use; OLED or TFT, respectively. Second argument (-b) sets the maximum bitrate for the displays. The higher the bitrate, the smoother the animation…but…there’s a limit to how fast this can go, and it can vary with wire lengths, connections, environment (such as interference from other nearby devices) and even slight manufacturing variances from one display to the next.

For OLED displays, the default bitrate is 14000000 (14 MHz). For TFT displays, default is 24000000 (24 MHz). But if there’s trouble, we have to dial these back.

Try a lower value, like the 12 MHz or 20 MHz examples above. Watch the output for a minute…does it seem to have stabilized now? If only one of the two displays glitches, you’ll still need to work the speed down until both run reliably.

Press Control+C to kill the program and test again with a different bitrate…maybe work down 4 MHz at a time, then up 1 MHz at a time until you find the “sweet spot” between speed and reliability. Once you find it, Control+C again and let’s make the change permanent…

sudo nano /etc/rc.local

A couple lines from the bottom you’ll find this:

/boot/Pi_Eyes/fbx2 -o &

(or “-t” if using TFT displays)

Insert the additional -b and bitrate value before the & character:

/boot/Pi_Eyes/fbx2 -o -b 12000000 &

Save changes and exit the editor. Then:

sudo reboot

After a minute or so the eyes should come up again, glitch-free this time. If not, repeat these steps again, trying a lower bitrate until you find a setting that works reliably.

Another way to reduce glitches is to solder ribbon cables directly between the bonnet and displays, with no headers or plugs in-between; every intermediary part is an opportunity for noise or connection problems. Consider this if you plan on permanent installation.

Customizing the Hardware

By default the eyes will animate on their own, looking around randomly. With some minor additional hardware (and enabling corresponding lines in the code), the eyes’ direction, blinks and pupil dilation can be controlled manually or with sensors…

At the bottom-right of the bonnet are a few extra connection points for 5 Volts3.3 Volts and ground, if you have a circuit that needs them. These are OK for small loads like ICs or a few LEDs, but not for big things like servos, which will need their own power source.

To the left are four analog input pins (along with four more 3.3V and ground points). You can use these to interface analog circuits such as a joystick to steer the eyes, photocell to make the pupils react to light, or perhaps to monitor battery voltage (use a voltage divider in this case, since the analog input must be 0 to 3.3 Volts).

Woops, we swapped SDA and SCL on the silkscreen - apologies! SCL is the left-most pin, and SDA is the pin to the right of it!

Additionally, most of the GPIO pins are broken out in a single row across the bonnet. Some of these serve special purposes and should be avoided, but technical users still have access to them if really needed…

  • TX and RX are available as GPIO14 and 15 if the serial console is disabled with raspi-config.
  • SPI0 (SPI bus used for the right eye) uses GPIO8-11 (CE0, MISO, MOSI and SCLK, respectively). Steer clear!
  • SPI1 (second SPI bus used for left eye) uses GPIO16 (CE2) and 19-21 (MISO, MOSI, SCLK). Avoid! Also, I2S audio devices can’t be used because the pins overlap.
  • GPIO5 and 6 connect to the DC and RESET pins of both displays, so these too should be avoided unless you have some special situation.

Analog Controls

Any analog controls that are added should include connections to the 3.3V and GND pins. Do not use the 5V pins or there will be…trouble.

XOUT and YOUT from a joystick can connect to analog pins A0 and A1.

The eyes move autonomously by default — settings in the code enable the joystick instead.

If you need to mount the joystick in a different orientation, there are also settings to invert each axis. Swap the X and Y pins in the code to use the joystick sideways.

This thumb stick has a click feature, which could be used to control eye blinks if desired. The smaller “mini” stick doesn’t have this, but is extra tiny for working into a costume or puppet.

To have the pupils contract or expand in response to light, connect a photocell and 10K resistor in series. The midpoint connects to analog pin A2.

Analog input for the pupils (either photocell or the dial below) are enabled in the code by default. You can comment out IRIS_PIN in the code to have this move autonomously.

For manual control of pupil dilation (instead of responding to light) a 10K potentiometer can be used. The center leg connects to analog pin A2 (same input as the photocell, just substituting a different analog control).


The eyes normally blink autonomously, but you can also add one or more buttons to make them blink (or even wink individually) on command.

For all buttons, connect one leg of each to GND, and the opposite leg to a digital pin:

  • GPIO Pin 22 is the left eye wink.
  • GPIO Pin 23 blinks both eyes.
  • GPIO Pin 24 winks the right eye.

If using our analog joystick breakout board, that stick includes a clicky button when you press down on it (on the SEL pin). This can optionally be used for manual blink control, or you can use a separate button for this (I find the joystick button a bit hamfisted).

Software Changes

Adjustments to the code must be made to use any of the above features. You’ll find the code in /boot/Pi_Eyes/eyes.py. It’s located in /boot to simplify “offline” editing on another system…if editing on the same Pi where it runs, you may need to edit as root (e.g. “sudo nano /boot/Pi_Eyes/eyes.py”).

After making changes, you could hunt down the background Python process that was run at startup, kill and restart…but it’s usually easiest just to reboot.

Hardware config settings can be found near the top of the code:

# INPUT CONFIG for eye motion ----------------------------------------------

JOYSTICK_X_IN   = -1    # Analog input for eye horiz pos (-1 = auto)
JOYSTICK_Y_IN   = -1    # Analog input for eye vert position (")
PUPIL_IN        = -1    # Analog input for pupil control (-1 = auto)
JOYSTICK_X_FLIP = False # If True, reverse stick X axis
JOYSTICK_Y_FLIP = False # If True, reverse stick Y axis
PUPIL_IN_FLIP   = False # If True, reverse reading from PUPIL_IN
TRACKING        = True  # If True, eyelid tracks pupil
PUPIL_SMOOTH    = 16    # If > 0, filter input from PUPIL_IN
PUPIL_MIN       = 0.0   # Lower analog range from PUPIL_IN
PUPIL_MAX       = 1.0   # Upper "
WINK_L_PIN      = 22    # GPIO pin for LEFT eye wink button
BLINK_PIN       = 23    # GPIO pin for blink button (BOTH eyes)
WINK_R_PIN      = 24    # GPIO pin for RIGHT eye wink button
AUTOBLINK       = True  # If True, eyes blink autonomously

For example, to enable analog joystick input and a photocell, set JOYSTICK_X_IN, JOYSTICK_Y_IN and/or PUPIL_IN to analog channel numbers (0 to 3). If the response from the stick or sensor is backwards, set JOYSTICK_X_FLIP, JOYSTICK_Y_FLIP and/or PUPIL_IN_FLIP to “True” as needed.

Customizing the Look

Changing the Python Code

The installer script places the code and data in the directory /boot/Pi_Eyes. If you’re not familiar with Linux text editors and so forth, you can move the SD card over to a regular Windows or Mac system, where the “boot” partition appears as a drive and you can edit these files with your text editor of choice.

If using TFT or OLED screens on a Snake Eyes Bonnet board, the Python script of interest is eyes.py. If using HDMI output (with or without the bonnet), look for cyclops.py (so named because it only renders one eye).

After making changes to the code, rather than tracking down and killing processes, it’s often easier just to reboot the Pi. After a minute or so, the revised code will run on startup.

This section near the top of the code (previously mentioned on the Hardware page) includes a couple of items that are relevant to the appearance of the eyes:

# INPUT CONFIG for eye motion ----------------------------------------------

JOYSTICK_X_IN   = -1    # Analog input for eye horiz pos (-1 = auto)
JOYSTICK_Y_IN   = -1    # Analog input for eye vert position (")
PUPIL_IN        = -1    # Analog input for pupil control (-1 = auto)
JOYSTICK_X_FLIP = False # If True, reverse stick X axis
JOYSTICK_Y_FLIP = False # If True, reverse stick Y axis
PUPIL_IN_FLIP   = False # If True, reverse reading from PUPIL_IN
TRACKING        = True  # If True, eyelid tracks pupil
PUPIL_SMOOTH    = 16    # If > 0, filter input from PUPIL_IN
PUPIL_MIN       = 0.0   # Lower analog range from PUPIL_IN
PUPIL_MAX       = 1.0   # Upper "
WINK_L_PIN      = 22    # GPIO pin for LEFT eye wink button
BLINK_PIN       = 23    # GPIO pin for blink button (BOTH eyes)
WINK_R_PIN      = 24    # GPIO pin for RIGHT eye wink button
AUTOBLINK       = True  # If True, eyes blink autonomously

Most relevant here are AUTOBLINK and TRACKING. If AUTOBLINK is changed to False, the eyes will stop their automatic blinking (responding only to button presses, if you have something like that wired up). If TRACKING is changed to False, the eyelids will no longer follow the pupils as they move around (this is an interesting thing that real eyes actually do, but sometimes you want a continuous wide-eyed stare).

Sometimes you may want no eyelids at all…just a full unblinking hemisphere. You can achieve this by simply commenting out the two lines that render the eyelids (put a “#” character at the start of each line). This is much later in the code, near line 430:


The other settings above are mostly related to hardware stuff.

Changing Graphics

Certain aspects (such as iris color) can be changed by substituting different graphics files. These are in the directory /boot/Pi_Eyes/graphics. One could just overwrite the files that are there, but I prefer to keep the originals around for reference and assign new names to the changed files. To make the code load these changed files, look for this section starting around line 122:

# Load texture maps --------------------------------------------------------

irisMap   = pi3d.Texture("graphics/iris.jpg"  , mipmap=False,
scleraMap = pi3d.Texture("graphics/sclera.png", mipmap=False,
              filter=pi3d.GL_LINEAR, blend=True)

Most common graphics formats (JPG, GIF, PNG — the latter with or without transparency) are supported. The images are square to make the OpenGL library happy.

The graphics are stored flat and unrolled, like a map projection. The horizontal (X) axis works like the longitude, or angle around the eye, while the vertical (Y) axis is the latitude.

The iris (file iris.jpg) is what we think of as the “color” of the eye and is most often what you’ll want to edit. Sometimes you just need to edit the hue & saturation in a program like Photoshop, or you can make something totally custom if you’re after a particular look.

The sclera (file sclera.png) is the “white” of the eye…which really isn’t that white at all. There’s veins and blotches and gross stuff!

This file is a transparent PNG to simulate the transition where the sclera meets the lens…it’s not an abrupt transition, there’s a slight “fuzziness” to it. When editing, try to preserve that transparency (and note the couple of transparent rows at the bottom, necessary because of the way OpenGL interpolates these images).

(The third file, lidMap, probably shouldn’t be changed. It’s complicated.)

Around line 79 in the code is this:

# Load SVG file, extract paths & convert to point lists --------------------

dom               = parse("graphics/eye.svg")

eye.svg (or cyclops-eye.svg for the single-eye code) is a Scalable Vector Graphics (SVG) file that determines the size and shape of various elements. Suppose you want Krampus eyes, with that freaky horizontal goat pupil? Or dragon eyes with a vertical slit pupil? (In fact there’s an example file there for that — dragon-eye.svg.)

InkScape and Adobe Illustrator (among others) can both load and save SVG files. But…editing / substituting this file is fairly tricky, as the names of individual paths are used in the Python code. If your graphics editor of choice does not maintain these element names exactly when changing or saving the file, the Python code will fail to run.

In Illustrator, you can see the path names by toggling “Layer 1” open:

The largest blue circle there, which extends to the edges of the document, can mostly be ignored…it’s there for reference and represents the outer bounds of the eye ball (which can’t be changed).

The iris path (which needs to remain a circle, though you can change its size) determines the size of the outer edge of the iris relative to the whole eye.

pupilMin and pupilMax are the size and shape of the pupil in its most contracted and most dilated positions, as it responds to light. This doesn’t need to be a circle! Have a look at dragon-eye.svg for example.

Two additional blue circles — scleraFront and scleraBack — are used in determining the “sweep” of the white of the eye. Notice it overlaps the outer edge of the iris slightly, and is open at the back (we have no need for the back of the eye, so it’s not modeled or rendered).

Red paths are used for animating the eyelids. upperLidOpen and upperLidClosed are the shape of the upper eyelid in its fully-open and fully-closed positions. lowerLidOpen and lowerLidClosed are the same for the lower eyelid. upperLidEdge and lowerLidEdge are used by the software to generate the other edge of the eyelid mesh geometry, which is really a 2D polygon that occludes the eye behind it.

You’ll notice the default eye is not symmetrical. Eyes are interesting things and have a unique shape left and right! Looking at the SVG graphics, the other eye (and nose, if we had one) would be to the left. cyclops-eye.svg is left/right symmetrical…it’s designed for the Pi’s single HDMI output, which might be split to two identical displays…the asymmetrical eye would look weird and lopsided in that case, so we go for the naïve “football shape.”

(At some point I hope to add a translucent nictitating membrane to the dragon eye, but this hasn’t happened yet.)

Replacing Everything

Well, almost everything.

Our Python code generates OpenGL animation that goes to the Pi’s normal HDMI video framebuffer, whether or not there’s actually an HDMI display attached. A separate program — fbx2 — continuously copies two sections of the framebuffer to the TFT or OLED displays attached to the Snake Eyes Bonnet.

This means, if you really want, the entire eye-animating program could be replaced with code of your own design in whatever language you like. As long as your code positions graphics in the right places, fbx2 will present that on the TFT/OLED screens. (I’ve even tried installing fbx2 over RetroPie — yes, you can play Doom on these eyes!)

The pi-eyes.sh installer script configures the Pi’s video output resolution to 640x480 pixels. It could actually be any supported resolution, but 640x480 was chosen for a reason, explained in a moment…

Picture two squares, side-by-side, that span the full width of the screen. On a 640x480 screen, that would be two 320x320 squares, with some unused space above and below. Within each square, picture another square inset, 80% the size. Or at this resolution, 256x256 pixels, with upper-left corners at…well, you can do the math. These two squares are what fbx2 copies to the TFT/OLED screens.

  • The 20% inset allows some “slop” off the edges of each eye, rather than butting them up right against each other. We use that extra space when generating the eyelid geometry. There’s stuff out there!
  • 256x256 pixels is exactly twice the resolution of the TFT/OLED displays, and the GPU provides us a fast and high-quality 2:1 downsampling in fbx2, so the images look super extra smooth. Any more or less and things wouldn’t look quite as good.

Using Just the Software

The pair of TFT displays or OLEDs are great for life-size props or costumes. If you’re looking for something larger than life, you can use the Raspberry Pi’s video output to feed an HDMI monitor, video projector…or we’ve been having fun with the Gakken WorldEye, a 10 inch hemispherical display from Japan…

Using HDMI video out doesn’t require the Bonnet board, unless you want analog inputs for a joystick control or a light sensor.

Follow the steps on the “Software Installation” page — start with Raspbian Lite, do some first-time configuration and get the system on your network.

Download and run the pi-eyes.sh installer script as explained there.

  • When prompted for a screen type, select HDMI.
  • Install GPIO-halt if you want a single-button shutdown option. This requires wiring up a button between one of the GPIO header pins and ground. I like to use GPIO21…this and ground are the last two pins on the header, nearest the USB ports.
  • Install ADC support only if you have the Snake Eyes Bonnet and want analog inputs for a joystick or light sensor.
  • Install USB Ethernet gadget support only if using a Raspberry Pi Zero (or Zero W) and want a direct USB connection from your main computer. It’s explained a bit in this guide.

After rebooting (about 30 seconds to one minute), you’ll be greeted with a single large eye centered on the screen.

Use an HDMI splitter to feed the same image to multiple screens…

In order to work with the WorldEye display (or other HDMI devices), the code and graphics for this version are slightly different. The TFT/OLED code (eyes.py), designed for two separate physically-wired screens, provides a distinct shape for the left and right eyes to approximate the caruncle (the inner corner of the eyes). The HDMI code (cyclops.py) generates a single symmetrical eye (no carnucle), so it can be fed to an HDMI splitter and not look lopsided on two screens.

If using something other than a WorldEye display, and if the eye image looks oddly stretched and not round, this probably has to do with the screen aspect ratio. We can adjust the Pi’s video output resolution to match your display’s native HDMI resolution:

sudo nano /boot/config.txt

(Or substitute your editor of choice for “nano”)

Look for this line near the end of the file:

hdmi_cvt=640 480 60 1 0 0 0

Change the first two numbers — 640 and 480 — to the desired resolution. Save the changes and then reboot.