zachgoldstein/heavy-meta-lights

A light control system for heavy meta, an art car headed to burning man

Hi 👋 I'm Zach Goldstein!

• ⚡ I'm currently on a professional sabbatical and exploring new opportunities.
• 🛠️ Previously I led the engineering for Bramble, a virtual meetings platform, building the team and product.
• ⚙️ I love making things and have worked across the stack on frontend, backend and infrastructure.
• 🌱 At the moment I'm exploring distributed systems, embedded programming, mechanical and electrical design.
• 📫 How to reach me: [email protected]

heavy-meta-lights's Issues

Raspberry pi message sending too slow

Yesterday in testing the strips Simon and I found that sending messages (specifically set_zone_color()) from the raspi to the lifx strips is about 10x times slower than from a mac (era 2013). The "sparkle" mode will not look great without the ability to really quickly send messages, so we'll need to find a way to make this quicker somehow.

We did some testing, and it looks like the CPU gets pegged at 100% when api.py is running. We're not exactly sure what about the lifx API's set_zone_color() mode is slow, so we should do some profiling to isolate in more detail. We should generate a flame graph both on the pi and on the mac (https://github.com/uber/pyflame) to find the bottleneck.

Digging into the root issue feels like it could be a rabbit hole. It could be slow file I/O to the SD card because of file descriptor allocation required to send UDP messages. It could just that the base library is unable to reuse sockets. We should learn alot from the flamegraph

I think the likely solution here is just buying a faster machine, as we're so time-constrained. One option is the rasp v4, another is a beagle board (http://beagleboard.org/black-wireless). If we're shipping something we should do it soon.

Scope out what type of light controls we want

What type of light controls are needed?

• Do we want per-light control? On/off? Manually setting of the lights?
• I think one thing mentioned was grouping sets of lights together and controlling them all at once.

Where is the app not good enough?

Make app start at startup on raspi

Set lighting modes on multiple strips simultaneously

We should ditch threading for asyncio as well here
With this we can just yield control back in the loop and run loops for each strip at the same time. Much easier than threading it.

Excessive calls to `get_color_zones()` return errors

get_color_zones() is a req/resp call under the covers instead of a fire and forget UDP message. The strips don't seem to be able to handle frequent calls to this method, and instead return errors. We should avoid this by caching or something similar

Create pressure-sensitive lighting mode

How would this work?

• A softly glowing lighting effect continuously runs
• When a pressure spike is detected from the bmp280 sensor (ala fireball),
• All lights would ramp up to some brightness/ color and then fall back to the original effect
  • The brightness would be scaled by the spike magnitude
• Scale brightness of light based on lta - sta magnitude

What's done:

• We hooked up a bmp280 sensor to the raspi and could pull pressure/temp readings
• We wrote a simple LTA/STA snippet that could detect pretty faint pressure changes
• There is code for soft background lights in the lifx samples that we can pull in.

Todos

• Write a new lighting mode that will react to pressure spikes
• Pull in code snippet that runs soft background lighting and combine with pressure spikes
• Setup a way for us to customise the sensitivity for the smallest detection via the UI
• Find the max magnitude pressure change that occurs when shooting fire

Nice-to-haves that probably won't happen:

• Set brightness on specific light groups

Add more interesting light modes

Simon had some ideas here:

• An infrared mode that would look at the heat of the dragon and change the colours accordingly
• Some sort of accelerometer mode that would change color based on which compass direction the dragon is pointed in.

Both of these would require sensors plugged into the GPIO ports of the pi.

At the moment I think the focus is on getting the network and basic light modes nailed down, so these may be deferred.

Add audio-based light control

A microphone needs to get hooked up to the raspi here. Ideally a wireless mic setup that can be placed strategically. We'll need some sort of UBS audio input dongle like this: https://shop.pimoroni.com/products/usb-soundcard. Raspberry pi's only have audio out.

Need to flesh out what the goals are here. Some ideas:

• Use audio level peaks to determine light intensity
• Use audio levels to set the frequency of some custom light modes. A sparkle mode was mentioned that just strobes random lights at some time interval.

See audio_test.py as an example of driving the lifx lights using audio input.

Add DNS endpoint for interface

Need to setup the raspi as some sort of DNS server.
Here's some info: https://www.ionos.ca/digitalguide/server/configuration/how-to-make-your-raspberry-pi-into-a-dns-server/

Expand control interface

The control interface is extremely simple at the moment, with a couple buttons to demonstrate things working end-to-end.

It would be fantastic to expand this. Some ideas:

• A image of the dragon with buttons overlaid for more specific controls
• Add a control for the colors used by the light modes

Figure out deployment process (raspi? scp? etc)

How are we going to deploy changes to the running system?

• Use pex https://pex.readthedocs.io/en/stable/index.html to build an executable bundle we can just scp onto the raspis for changes.
• ssh into the machine to restart service with new changes:

sudo systemctl stop myscript.service
sudo systemctl start myscript.service

• tail logs of the service to see it working

Test changes locally on a laptop connected to the same network. The lifxlan API should be equally accessible on a laptop vs raspi

With #1 done, we should have a good idea here.

Get router setup with mobile modem and setup lots of light strips

Simon Plashkes and I ran into some challenges getting the router setup sorted out and working for a few testing strips.

Yesterday we were trying to get two light strips setup with the cisco access point (dragonLAN) going with the dragon. The access point was setup so the POE port was hooked up to the shop's existing router. Setting up the lights requires a network that's hooked up to the internet unfortunately, so we needed to hook the dragon's network up to some sort of network access. During the light setup process, we saw a bunch of odd behaviour, from strips taking too long to setup and failing half way to strips dropping the connection after being setup. I think some of this might be because of pins not being connected securely, as mentioned here: #3 (comment)

Instead of mucking with the two routers, I think we should try to get the mobile modem hooked up to the dragon's cisco router and just focus on getting as many strips as possible working there. With that in place we can start to do cool stuff.

Add sequencing for light race mode

The light race mode will look much more interesting if multiple strips are controlled in sequence. Right now we just call all strips without any considered order. We should add a list of the addressable light strips that has some more meaning. We'll need to make sure this survives whatever order the discovery mechanism spits out.

Sort out light strip installation

afaik kevin bracken is leading efforts here to cnc a custom fit enclosure for the light strips using special light diffusing plexiglass.

Get basic end-to-end system hanging together

High level:

• A control process runs and expose an endpoint over the network
• A python process runs and controls lights based on endpoint
• Both processes run on a raspi

Each process should:

• Start at startup as a daemonised or otherwise long-running process
• Restart itself if it crashes
• Write logs to file

Quick tests in ./audio_test.py show how to quickly find lights on the network and control them based on audio input.