Author: Sarva

Over the days, we have made a kit that can fit the gyro sensor in. The kit would be attached to the dancer so that it could sense and control the LED strip lighting on the dancer. For the next step, we are going to work on the different design of LED lightings and how each movement corresponds to different LED lighting.

We are testing a gyro/accel sensor (mpu5060) on our currently MQTT based system. It works relatively well and latency doesn’t seem to be an issue, though we can not be sure until we have prepared better peripherals to test the system. While latency doesn’t seem to be an issue, there is an issue with the lighting when we rapidly send consecutive signals over the current setup. While my first instinct was to blame the MQTT protocol, the actual problem could be the code and how we process incoming signals. Though it may cause an incredibly small amount of latency, we probably want to store all incoming signals temporarily to avoid losing signals. We hope to have a sleeve that holds a gyro sensor and wirelessly controls an led strip by next week. We have the bare minimum technical work to make the prototype done, sewing and other handiwork are about to be a bottleneck.

Also, I was thinking about adding detachable physical connectors between sensors and outputs so that there is an option to connect the two wirelessly or remotely. However, this may just add needless complexity so this is just a thought.

During the summer, we created a generic library for asynchronously controlling the LED strips with sensors.

https://github.com/dutchhagelslag/twinkleToes

While the library is incompatible with our revised vision of a wireless system of sensors and outputs for dancers, the ideas and large parts of the code can be copied and revised as the core operations haven’t changed. We’ll just need to incorporate a wireless protocol.

For no particular reason, we have decided to start with testing the MQTT protocol. The current test setup look like this: LED Strip D1Mini my router RPI MQTTool (iPhone). While the subscriber publisher model is good for scalability and uniform deployment, the current setup has some latency which is probably no good for dancing. We will try setting up a shorter network cutting out the router by making the RPI the wireless access point like so: LED Strip D1Mini RPI MQTTool (iPhone). Depending on how much this reduces latency, we will consider moving to a UDP based system which might introduce packet loss idk, but TCP is probably fine. We’ll be working on it.

We have finally decided to break the code into smaller more manageable pieces. The all in one go thing wasn’t really working. So the first piece we tackled involved controlling asynchronous LED movement with a button de-bouncer and a global storage array to store the index of the LED’s current location. There were problems with the number of moving lights, random LEDs triggering, and the last few LEDs of a motion getting choppy. The biggest issue (or at-least most identifiable) was the number as we expected 10 simultaneous LEDs, not 7. Thanks to Professor Kayla, we found that the issue was due to the de-bounce interval being too short. The random LED’s triggering and choppy end motion was not very consistent and hard to reproduce. We’ll be trying to identify the problem. Along with troubleshooting, the next objective will be to have LED’s reactive to analog signals.