A moment of inspiration
The project started months ago with something completely unrelated.
I once saw a video of someone building a 6-DOF robot arm controller, and one detail caught my attention: they were using a slip ring, which is a tool to prevent wires from getting tangled in rotating mechanisms. I had never heard of one before, so naturally on my next shopping spree, I bought a slip ring without any concrete plan for it.
When it arrived, I played around with it for a few hours, but soon after, it ended up doing what most impulsively bought electronics do: collecting dust in a box of random parts. I was convinced I would never actually need it.
That is, until last week.
While brainstorming ideas for this hackathon, I stumbled upon videos of rotating LED displays that render images using persistence of vision. Most implementations relied on wireless synchronization to communicate with the spinning part, which added significant complexity and costs to the project. That’s when I remembered the once forgotten slip ring.
Instead of fighting rotation with wireless timing tricks, we could embrace it by sending power and data directly through the rotating interface. The timing couldn’t have been better. What had once felt like a useless purchase suddenly became the core enabling component of the project.
With that realization, I pulled together a team, defined a minimal but ambitious goal, and we decided to hack something together: a spinning LED display that renders images, using wired communication through a slip ring.
That idea eventually became the Dynamic Polar Renderer.
The GRIND
We quickly split the project into two parts: hardware and software, and tried to structure things so we could work in parallel as much as possible.
While the hardware side focused on getting a quick prototype up and running, the software side started by building a simulation of the display. This let us test the core ideas early, even before the final hardware existed.
Once the basics were working, hardware moved on to a more refined build, improving the structure, wiring, and overall reliability. At the same time, software began translating the simulation onto the real system, which made integration far less painful than it could have been.
Toward the end, most of the hardware effort went into many small but important improvements like making everything more rigid, cleaning up connections, and fixing whatever broke at 3 a.m. Software focused on tuning timing and visuals until the image finally looked right.
This was an absolute grind and involved very little sleep, but working this way helped us move fast and avoid long stalls. In the end, seeing the display actually work made all of it worth it, and we’re really proud we pulled it off.
Bridging hardware and software
This was, by far, the hardest part.
Getting the hardware and software to actually agree with each other took a lot of trial & error, calibration, and head-scratching. On paper, everything made sense. In reality, there were countless non-ideal behaviors: encoder drift, mechanical wobble, and other things that only show up once the system is spinning.
A lot of the time felt like playing detective: spotting something that looked wrong, snooping for hints to figure out what the heck was going on, testing it, and then discovering the problem was somewhere completely different. Fixing the issue was only half the battle, figuring out what the issue even was often took much longer.
There was also plenty of very unglamorous work. We soldered hundreds of connections, reworked joints more times than we want to admit, and spent hours calibrating the software so it actually matched what the hardware was physically doing.
It was frustrating, slow, and occasionally painful, but it’s also where we learned the most. By the end, when the image finally locked in and looked the way it should, it felt incredibly rewarding.
All in all, this was an amazing experience. We made it work in the end and the grind was worth it. 10/10 would do again.
Log in or sign up for Devpost to join the conversation.