Announcing Gloworm: an inexpensive and open source vision module

Hi everyone, today I would like to announce Gloworm: an inexpensive and open source vision module.

While there are many awesome open source vision software projects for FRC (such as PhotonVision and OpenSight), the accompanying hardware solutions are often unreliable and hacky. Even if your team is capable of setting up open source software or writing your own vision code, you might shy away from duct taping a Raspberry Pi to your shooter. Gloworm aims to bridge this software-hardware gap and fully democratize vision tracking in FRC by providing a cheap and open source COTS hardware solution.

If you’re interested in purchasing a beta Gloworm, please fill out the interest check form, available here.

“People who are really serious about software should make their own hardware.” - Alan Kay


  • Raspberry Pi Compute Module 3+
  • OV5647 Wide Angle Camera Module (640x480 @ 90FPS video)
  • Dimmable 400 lumen green LED array (with constant brightness down to 7v)
  • 10/100 Ethernet
  • 12V Passive PoE (with reverse polarity protection and brownout tolerance)
  • USB C ports for flashing and peripherals (such as a USB camera)
  • WPILIB FRCVision-based image to kickstart your custom vision code
  • Compatible with PhotonVision
  • Completely open source (CERN Open Hardware License v2 - Permissive Variant)

Here’s where we’re at:

  • Functional hardware prototypes
  • Currently working on the last (or second to last if we get some great community feedback) hardware revision
  • Working WPILIB FRCVision fork
  • Still working on a 3D printed case design
  • Have received multiple turnkey PCB assembly quotes and have the funding to execute a medium run
  • Copperforge will be working with the project to make Gloworm available as a COTS item in their store

Based on the quotes we have received for PCBs, as well as our predicted cost for 3D printed cases and hardware, camera price quotes, and overhead costs, our target price is $125/unit. We are hoping to make fully assembled COTS units available by September, and we want to make beta units available ASAP.

Photos (renders are of latest revision):

Website: (should answer some questions, but don’t be shy asking here as well)



FRCVision fork:

Documentation source:

Interest check form:

If you’re interested in contributing to the project, we could really use some help with the following:

  • Hardware .STEP files are available here here
  • Schematic and PCB design review
  • Documentation feedback
  • Designing a logo or other art (banners, etc)
  • Software support (in addition to Photon and FRCVision)
  • (whatever cool idea popped into your head while reading this post goes here)



I love what you’re trying to do here. I’d guess our programmers would be interested in beta testing it. I’m definitely willing to take a crack at a printed case design, although I have no experience at designing electronics cases.

You said it takes 12v POE. Would you provide that by running an injector from a PDP slot? What brownout protection does it have? Is it simply a low min operating voltage or something active like the limelight? How much current does it draw while running?


A few questions I wanted to clarify:

What’s the deal with the case?

  • We are still working on a case (@dydx offered to help out with that actually!)
  • We do plan on shipping beta units with a case, no assembly required
  • They will almost certainly be 3D printed, because it’s unlikely that we’ll have enough demand to justify injection molding, plus 3D printing allows us to iterate really quickly without getting “locked in” to a mold.

What’s the deal with cooling?

We’ll be doing testing as to whether we need a fan, or some other heatsinking (e.g. physical heatsinks, thicker copper PCBs, metal core PCBs, etc). We’ve been running the existing hardware with just a 2oz copper PCB LEDboard and regular 1oz/.5oz 4-layer mainboard and it’s been fine, but a fan might still be a good idea for reliability and pushing the CM and LED board to their limits. Small fans can be relatively expensive and difficult to source quickly, though. The existing PCB has a 2 pin molex picoblade connector for a fan if we decide one is necessary.

What’s the deal with the camera cable?

We’ll probably just stick with the 15-pin 1mm FFC that comes with the camera modules. One of the things we figured out in the earlier revs is that we should use a top-mount FFC connector so the supplied cable doesn’t need to be twisted, this way we can just stuff the cable into the bottom of the case. That being said, if we can find an easy and quick source for custom length FFCs, that might be something we would look into.


Thank you! I would love to get feedback from 2471 given your experience with vision tracking & awesome swerve drivetrain. Also feel free to ping me about the case! Would be really cool if we had a bunch of different designs to try out.

Yep, a regular 12V passive PoE injector on a PDP slot is what I would recommend. Some WIP details on that here.


We’re using a TLV62130 buck regulator, so it operates just fine down to as low as 5V (and I’ve tested this). We also have 100uF of bulk electrolytic capacitance on the 12V rail, and quite a bit more bulk MLCC capacitance on the actual compute module power rails (see the schematic for details).


The LEDboard stays constant brightness down to ~7V, and there’s a lot of bulk capacitance on it’s power supply rails as well.

I don’t know exactly what the Limelight implements for brownout protection beyond that.

Current draw is about 1.5A with the LEDs fully on, 100% CPU utilization, and a USB port drawing 500mA. It’s hard to give an exact number since we’re still iterating on the hardware, but that will be made available eventually.

We’ll also be doing actual brownout testing on a robot instead of a bench once we have more finalized hardware and I can get access to a robot.


Here’s the first rev of the case design I did this morning.


What are the mounting hole pattern dimensions for this case?

Didn’t realize the onshape is linked. The answer is 3.75" X 1.875" which is just slightly larger than the mounting for the Limelight 2 at 3.5" X 1.875". It would be really nice if they were interchangeable!


We just made an update to set it as 3.75" x 1.875" #8 holes

1 Like

Can you move the internal screws down and shift the holes over to be 3.5" c-c on the width?

1 Like

Side note if anyone is worried about that capacitor getting in the way of the camera cable: fixed in Move +12V bulk cap to make way for camera cable · gloworm-vision/gloworm@22d61a6 · GitHub

Yeah, done. It looks like there was a lot of wasted space there.


A lot has been posted on the topic of bright LEDs for target illumination.
Was any consideration given to using IR LEDs in place of typical green LEDs?
Even IR does not necessarily make a product eye safe; however, given sufficient range IR might prove to be far less objectionable.


“typical” is why I picked green LEDs for the first LED board. Green LED ring setups are extremely common and proven. IR is rare in FRC.

I’m sure people have a bunch of ideas for different LED boards and I would love to see them, so please use the existing ledboard as a reference implementation and try them out! I would love to see an IR setup, a high power Cree setup, etc.

Edit: another reason is that IR leds are much more expensive than the high power green LEDs we’re using.

1 Like

Looks awesome! I’m going to show this to my team, since we’ve been looking for something like this for a while.

Are the beta units going to be the revision shown in your first image or the ones shown in the renders?

Awesome to hear :slight_smile:

The beta units will definitely be an iteration of the revision shown in the renders, not the photos. The photos are of revision 0.3.0 which was functional, we just wanted to make some changes to it (for example: switching to USB C). The renders are of revision 0.4.0 which we’re still working on and should be ordering prototype boards for soon (and eventually beta units).


I would tend to stay away from IR as it can be just as damaging to the eyes as visible light, but because you are not perceiving it, they are actually higher risk than colored LEDs.


Every radiation source has safe emission limits.
That was part of my post - clearly part of yours as well.
In the past I have worked around IR laser scanners that will never make it to FRC.
I am just wondering if people are thinking about all of the issues around vision systems when different products are introduced.

1 Like

Yeah but it doesn’t damage the LREyes at 10ft away.



  • Cameras are ordered (50PCS) - we went with the common OV5647 Raspberry Pi “Wide Angle” Camera module but with a custom JSD3922-A1 lens (62.7° horizontal FoV, 49.0° vertical, <-0.50% distortion) with a 650nm IR filter
  • Fans (50PCS) are ordered because we found a cheap source for factory customized 20mm fans
  • @dydx made a really sweet case design that we’ve printed and are testing, and @dirtbikerxz made some awesome renders of it. Some other neat case designs are being worked on too.
  • We have an amazing worm on a string logo thanks to @g10ria
  • v0.4.1 prototype boards are ordered, the main changes were related to the TLV62130 buck and switching to the TLV62569 for the 3.3v and 1.8v bucks (thanks Copperforge for the reviews)
  • So far we have 24 interest check responses, so we’re planning on a beta run of 50 units (please fill out the interest check if you’re planning on purchasing a beta Gloworm:


Got the latest boards assembled today. Everything seems to be working great, and it’s way more efficient than the last rev!

Current draw is ~0.62A @ 12.00V with the camera on and LEDs, CPU, and fan at 100% (no USB peripheral). (cc @Bryce2471 since you were curious about this)

After running stress-ng, streaming video, and leaving the LEDs at 100% for ~30 minutes the CPU temperature stabilized at around 57C (room temp was ~21C), which is pretty good considering the RPi can withstand 85C. The LED board sat around 40C (measured near the base of the LED w/ a laser thermometer through the fan vent).

Hope to have some on-robot testing videos soon.

edit: current draw is actually more like 0.785A and temp is more like 75C at 100% CPU load (4 matrix threads). I didn’t have stress-ng setup quite right. Still way better than the last revision and within acceptable temps though.