Overview

Lumyn Labs builds FRC-focused electronics centered on LED control and device configuration. I co-founded Lumyn Labs with Evan Rust, who designed the hardware and wrote most of the firmware. I built Lumyn Studio (the desktop configuration app), most of the SDKs and WPILib vendordep, handled marketing and support, and worked on the Shopify site.

My work focused on the software layer between the hardware and FRC teams: desktop configuration tools, SDK implementations across multiple languages, simulation support, and release automation. The goal was to reduce setup time and prevent configuration errors that teams hit when deploying hardware to robot controllers.

My Role

The configuration system cut setup time by about 40%. Teams could build configurations in code, load JSON from deploy, request the current device config, or apply a configuration to hardware or simulation. The device, Studio, robot code, and simulation all had to agree about what a configuration meant; this removed entire categories of setup errors we saw teams hit at competitions.

I worked on SDK parity across C, C++, Java, and Python: same API surface, same behavior. Test coverage went from around 60% to 95% as I added property-based tests and integration tests that ran against real hardware. The CI system synchronized artifacts across seven repositories, so a firmware change would trigger vendordep builds, SDK updates, and documentation deploys automatically.

Technical Context

ConnectorX combines LED control and general I/O in one board: QWIIC/STEMMA QT headers, UART/SPI/I2C, analog and digital I/O, SD card support, 6-16V input with 5V output. The 2026 software work covered Lumyn Studio, WPILib vendordeps, Python and C/C++ SDKs, LED buffer publishing, desktop simulation, matrix text rendering, and OTA firmware updates.

Release Work

The V2 software suite was the first major release. I rebuilt the vendordep around a faster communications stack (that Evan designed), redesigned the module architecture from callbacks to a push/pull model, and added a vendor simulation GUI inside WPILib's SimGUI. The simulation work mattered because teams could test code against the same firmware behavior they'd see on real hardware; LED zones, modules, connection state, fake sensor data, all without needing the physical board.

Firmware 4.0 added UART support so teams could connect ConnectorX through the RoboRIO MXP port instead of only USB. The new builder-style LED API cut boilerplate by about 60% through method chaining. Instead of passing a long parameter list into one call, teams could write: setAnimation().forZone(1).withColors(red, blue).inDirection(forward).

The configuration system was another major piece. Teams could build configurations in code, load JSON from deploy, request the current device config, or apply a configuration to hardware or simulation. I like this kind of feature because it's not flashy by itself, but it removes entire categories of setup pain. The device, Studio, robot code, and simulation all need to agree about what a configuration means.

import com.lumynlabs.modules.DigitalInputModule;

ConnectorX cx = new ConnectorX();
cx.Connect(USBPort.kUSB1);

cx.modules.RegisterModule("test-dio", entry -> {
    DigitalInputModule.Payload payload = new DigitalInputModule.Payload();
    try {
        ModuleHandler.ExtractData(payload, entry);
        System.out.println("State: " + payload.state);
    } catch (IllegalAccessException ex) {
        System.out.println("Parse error: " + ex.getMessage());
    }
});

Midseason Work

Once teams started using the 2026 stack, the work shifted toward polish and features that came from real use. Matrix Text 2.0 added multiple fonts, foreground/background colors, static text, ping-pong scrolling, smooth scrolling, and Y-offset control. That sounds like a pile of small features, but for FRC LEDs it matters; teams want text that's legible in a bright arena and flexible enough to communicate actual robot state.

The Python and C/C++ SDKs moved the platform beyond robot code. The Python SDK reached API parity with the WPILib vendordep, so you could control LEDs, read sensors, and manage configurations from desktop computers or Raspberry Pi environments. One demo was screen mirroring through the Python SDK: streaming desktop pixels to an 8x32 matrix at about 45 fps while a ConnectorX Animate drove hundreds of LEDs across multiple channels.

There was also real support work. A CANivore-related USB enumeration bug turned out not to be in our vendordep or firmware at all, but in WPILib HAL behavior around multiple USB devices. Vendordep 2026.2.0 shipped the fix. That kind of issue is frustrating because the symptom looks like your product failing, even when the root cause is lower in the stack. The only path forward is careful reproduction and a willingness to dig through layers you don't own.

Studio 4.3

The final 2026 release was firmware 4.3 and Lumyn Studio 4.3. I rebuilt Studio with a refreshed interface, dark mode first, and a much stronger animation workflow. The old image sequence editor became Motion Editor: layers, keyframes, GIF import/export, shapes, text tools. The goal was to make matrix animation feel like a real editor instead of a configuration chore.

LLA files came out of the same problem. Before that release, animations were tied to manually managed files on an SD card. LLA files made animations compressed, portable, previewable, and uploadable directly from Studio. That paired with OTA firmware updates; the update workflow went from BOOTSEL, download, copy, reboot to a one-click install inside Studio.

ConnectorX Animate also gained support for up to two I2C modules. That mattered because Animate started as the higher-capacity LED board, but teams still wanted sensor expansion without switching products. Supporting modules on Animate made the product line more consistent.

Outcomes

The result is a product ecosystem that's easier to evaluate, configure, and integrate into a robot project. Teams can test behavior in simulation, configure hardware from a desktop app, write robot code with a cleaner API, and use SDKs outside WPILib when the project calls for it.

The business side also grew around the software. ConnectorX and ConnectorX Animate became available through The Thrifty Bot, CAD models were published for case design, and a Lumyn Labs voucher was included in the FIRST Virtual Kit of Parts. Those details matter because software polish is most useful when teams can actually get the hardware, mount it, update it, and understand it quickly.

Reference Links

Demo

ConnectorX running on an FRC robot during testing.