synkronicity...

[the-butterfry]

So.. i was just scratching my chin this morning wondering if i could make our bikes communicate an LED pattern this year out on the playa. I thought to myself, i bet somebody has already done this. I've seen stuff out there in past years that seems like that is what was going on.. about 2 minutes here and i found your project. Then i saw your Arduino IDE filename.

So here i am, and i'd love to know what RGBlinky was intended for exactly. Did you guys put this on your bikes or did this go across Mutant Vehicles? I haven't really gone through the code to map out what exactly you're doing and what kind of LED array you used (doing that next). Just thought i'd reach out and get a high level overview as to what the intention here was in a bit more detail than the readme. Looks awesome BTW, and i hope i can get something similar working on 4-5 nodes this year myself!

EDIT: Ok, I've got the picture. Looks like you have some sort of webapp headend component too? We were discussing it, and we also want to use RGBlinky to communicate with a piece of Playa Art that is going out there this year (https://www.facebook.com/thestarfield). The idea is to write a plugin that senses any RGBLinky node approaching and interacts. The code/project/node would be open, so anyone can build an ESP based node and get in on the interactivity.

[Marcus10110]

Awesome to hear! This project is largely build on top of painless mesh (https://gitlab.com/painlessMesh/painlessMesh). It runs on the ESP8266 modules, as far as I know it can't be easily ported to other devices.

This repo is an ongoing project (which we haven't worked on in a while) so It's not really "done". Feel free to fork or just use it as a reference for creating your own! I'm working on my own side project similar to this here: https://github.com/Marcus10110/MeshLights However that project stalled out when I realized the mesh isn't TCP/IP, and that each node does not get it's own IP address. The goal was to support the functionality here, but also allow the user to connect their iPhone and run LED LAB to control all of the LEDs, and have a web interface for configuration. It's maybe ~30% done though. I do need to get the project finished before the burn this year though. We built 12 of these modules last year and didn't end up using them, but I want to get it finished up this year.

Awesome project by the way! That's something I've always thought would be cool. If you're ever in the bay area let me know, and I'll be looking for the starfield out there this year!

[the-butterfry]

Thanks for the updates.. well, hummm.. Lets loop @aaronbronow in here. He's one of the main folks on Starfield. So @Marcus10110 it sounds like you've got some code to complete before too long. And what I'm hearing is your focus is going to be on RGBLinky instead of the MeshLights (which i really like the idea of in my quick look). In my discussion with Aaron yesterday, and as I mentioned above we'd love to integrate this into Starfield. Maybe we can take some load off you and contribute here? Aaron?

As for the physical layout, I wasn't able to glean from the code how you planned on implementing the lights onto bicycles. What was the idea, just onto the bike frames? How were you planning on sequencing them. I'm assuming all the bikes have to be laid out equally, so a single pixel map applies to all.

[Marcus10110]

@the-butterfry, Personally, I'm working on MeshLights now, which I started after RGBlinky, taking away the lessons learned. The operation of both projects are pretty simple. It does not have support for mapping an animation across multiple modules, it's more primitive than that. The modules take advantage of the network synchronized time to play the same animation on all the units in sync with each other - that's pretty much it. On top of that, each unit has a button which can be pressed to change all units on the mesh to the next animation. There is also a feature to hold down the button to cause a single node to stop synchronizing with the mesh, so it can play an independant animation.

That's pretty much how RGBlinky works. MeshLights is very similar, with a few extra features. Each node can be assigned to a specific group index, so that groups of nodes on the mesh can stay in sync with each other, but not force nodes outside of the group onto their animation. That way the bikes can be on one group while an art car can be on another group.

There are a few other modes too that never were finished, mainly the LED Lab mode, which opens a UDP socket server to receive Open Pixel Control packets from the LED Lab app (or any OPC server).

A third mode drives the serial port output instead of an LED strip for a separate project, mesh synchronized individually dimmable edison bulbs.

MeshLights has a functioning web server with a web interface to control properties of the node, however it's not possible to edit the settings for every node on the mesh yet, it can only edit whichever node happens to be assigned as the AP in the mesh, which is handled by painlessMesh.

The main TODO items on MeshLights is to:

1. add support for LED Lab, by getting the UDP server setup and forwarding OPC packets through the mesh
2. add support for configuring each node on the mesh individually through the web interface, by forwarding commands from the HTTP server node to the other nodes.

I also have never tested the system with more than 3 nodes at a time, but we built and tested 12 modules. I don't know how high this can scale, but I'm worried it might not scale well (fingers crossed).

The ESP8266 modules are a pain to work with, unfortunately.

[the-butterfry]

ahh, got it. So RGBLinky has given way to MeshLights completely.

ESPs can be painful, the wifi is pretty finicky. Rumor has it the ESP32 stuff has solved alot of that. Also, maybe the scale-ability problem might be solved with the faster ESP32 (not sure the dual core part would even help here). My guess is what you're worried about is wireless saturation? But since you're working with 12 8266's, probably best to stick with that.

So the animation doesn't map between nodes. I'm cool with that, it would still work with Starfield. We can build a detection module so when a node(s) approaches, Starfield can play it's proximity animation, and the nodes can play a totally separate but sync'd one.

If adding our help to the project, is it something you want to continue with? If so, i'll build out a few and hand them off to Aaron so he can play. I've got all the parts here already, save maybe a power supply and the mode switch button. Maybe we can get something working in 2m 14d 9h 34m