Announcing Gloworm: an inexpensive and open source vision module

The quick start says “Run an Ethernet cable from the passive PoE injector output to Gloworm’s Ethernet port,” but that might need some more clarification. The PoE injector works like this:

  • The barrel jack receptacle supplies DC + on pins 4 and 5, and DC - on pins 7 and 8
  • The RJ45 connector gets plugged into your robot router for the four data lines (pins 1, 2, 3, and 6)
  • You run an Ethernet cable from the female Ethernet port on the PoE injector to Gloworm, which supplies both power and data

I suggest checking out the Passive & Pinouts section on Wikipedia Power over Ethernet - Wikipedia.

Thanks. That makes more since than how I was thinking it would be hooked up.

1 Like

With the release of the Compute Module 4 (Raspberry Pi Compute Module 4 on sale now from $25 - Raspberry Pi)
Should we expect to see a new version/revision in the near future?

The version that I foresee being the upgrade of choice is either the 1GB/8GB version (same price as the 3+ of the same ram/storage specs), or the 2GB/8GB version, which only adds $5

My thoughts:

  • It’s neat (high density connectors + designed with KiCAD :smiley: )
  • It would maybe allow us to shrink Gloworm a bit
  • Processor performance really isn’t that impressive compared to the CM3+. Not even sure if we could take advantage of the 1.5GHz clock within our thermal budget. The A72 is cool in other ways (OoO, two-level branch prediction, bigger L1/L2 caches), but meh
  • I don’t know too much about GPU accel, but @pietroglyph (who has been working on GPU accel for PhotonVision) didn’t sound too excited about the VideoCore VI. Would love for them to weigh in here. I do know that VC4CL doesn’t work on the Pi 4 GPU
  • We’re not too constrained by memory right now
  • The other new features aren’t incredibly useful for our application (wireless, gigabit ethernet PHY, PCIE)
  • It would require a significant redesign of the PCB, any testing of the existing hardware would basically be thrown away
  • We don’t even know if there will be a proper season next year

I’m inclined to say not yet, but I would love to hear from others.


I’d love to see somebody try benchmarking a current gloworm/CM3+ vs a RPi4 vs CM4 on some representative vision programs (like PhotonVision). That way we would have definitive data on just how much faster it would be for our usage case.

I’ll try to post some numbers later to compare (it’s very possible that the Pi 3 with GPU accel is still faster than the Pi 4 CPU-only), but the summary of the GPU situation is that the Pi 3 supports the EGL_IMAGE_BRCM_VCSM and GL_TEXTURE_EXTERNAL_OES OpenGL extensions, while the Pi 4 supports neither. On the Pi 3 with PhotonVision we use these extensions to get a “GPU pointer” to the frame as it comes off the camera and is processed by the adjacent ISP block. We can pass this GPU pointer to our OpenGL shader and then map the image processed by our shader directly into the Arm memory (the VideoCore and Arm share the same memory), which means that we can basically avoid copying and get really good performance on a relatively limited device. Because the Pi 4 doesn’t support these extensions, we’d have to resort to either using the CPU only or copying off of the GPU, copying the frame back to the GPU, and then copying the processed result off again (although there is a really hacky way to make that last copy way faster by directly mapping the memory without VCSM.)


I’ve been doing a lot with the Pi 4 recently and this is the right answer. Give it about 6months to a year.


Aaand the numbers are here. Here’s a comparison between PhotonVision running CPU-only on the Pi 4, and PhotonVision running GPU-accelerated on the Pi 3:

Resolution Pi 3/Gloworm with PhotonVision (GPU Accel) Pi 4 with PhotonVision (CPU Only)
320x240 90 90
640x480 85 72
1280x720 30 23
1920x1080 15 10

You’re reading that right! PhotonVision on the Pi 3 can beat the Pi 4 (and other comparable vision software running on the Pi 3.) If you’re interested in more info about these numbers then don’t worry—we’re planning on doing a larger announcement with more detailed testing methodology and tech details about GPU-acceleration sometime around when we do the public release of PhotonVision.


I’ve got my VMX-pi & Gloworm hooked into an unmanaged switch (Netgear FS105, VMX on 1 & Gloworm on 2), connected to my VMX-pi on wifi, and have not successfully been able to connect to the Gloworm configuration page.

When I pull out AngryIP, I only see (raspberrypi.local, my VMXpi controller) and (Desktop, the programming/driver station laptop) in the range.

(No alive ports across the range (I got bored of scanning and cut it off), outside which i believe is the local programming station laptop again. It’s running again right now cuz why not…)

I imaged the Gloworm immediately prior to this with the latest production release of PhotonVision… no complaints in Balena Etcher.

Is there something about having two raspberry pis going that would make this fundamentally not work?

@slibert did your team test VMX-pi with Limelight in the past?

Absolutely no means an expert here, but are you able to set a static IP on the gloworm pi? While probably unlikely, could it be that for some reason the gloworm is setting itself to an already claimed IP? Also, can you ping any of the other devices on the network from the gloworm?

…I have no guarantee that raspberrypi.local host at is actually my VMXpi controller. Could be either one. Know a good way to check?
EDIT: See below, ssh logs me into the vmxpi

I can’t see anything that’s positively the gloworm on the network, so I don’t know how I would get into it to ping from it? That said I can probably ssh into the Pi I can see and check the filesystem to figure out which one I ssh’d into…
EDIT: ssh from my laptop to pi@ gets me into the VMXpi, not the Gloworm

1 Like

Having two Pis going shouldn’t be a problem, especially if they have different hostnames for mDNS (which they should in this case.) Here are a couple of things to try:

  1. Make sure that you’re not powering the Gloworm off of the USB-C port with a download icon that you used for flashing. Plugging things into that port or powering off of it (instead of POE) keeps the Gloworm in a special flashing mode which you don’t want.
  2. Try to connect to http://gloworm.local:5800 (sorry if this seems obvious; you didn’t mention this in your reply so I thought I’d throw it out there.)
  3. Make sure that the ethernet lights and the small red light at the top of the case are on.

@pietroglyph pretty much covered everything but I’ll also add that if you continue to have issues I recommend connecting your Gloworm to a managed switch so you can go to it’s control panel and find Gloworm via the DHCP leases it’s handed out (or try AngryIP again). That would allow you to rule out any issues with Gloworm itself.

Also happy to help debug in real-time in the Gloworm Discord as not to spam this thread, but no pressure if you’re not a Discord person.

1 Like

Correct, the Ethernet is the only thing that’s plugged in

No internet error? (connecting using Chrome, has another browser gotten more stable?)
(If I try it while my ethernet cord is plugged in to my programming laptop so I can see CD, I get This Site Can’t Be Reached, and without it I get No Internet)

Always the correct approach on the internet, especially with a customer as thick as I am :slight_smile:

So, this is weird - I only have the green Ethernet light lit consistently. On startup, I got bits of orange on and off, but the steady state after a couple seconds is only the green. On the PI port, the orange light is lit. My unmanaged network switch only has green lights, which are all lit.

EDIT: Reflashed, swapped POE injector, swapped ethernet cable, behavior is repeatable link above

There’s a tool called arp-scan that is sometimes helpful in such situations. Here’s a how-to I found just now.

I ended up finding & using that separate from your post, and established that the issue appears to actually be that my VMX-pi / Raspberry Pi WLAN does not seem to be accessible by default through the Pi ethernet port the way it is on a roboRIO. So the “normal” architecture of using an unmanaged switch to bridge from the master controller (roboRIO) out to the router & vision system Pi isn’t working out of the box.

When I plug the programming laptop into that unmanaged switch, I can’t see the 10.8.41.X subnet anymore, but the PhotonVision interface comes up just fine.

I have an email in with @slibert and his Kauai Labs team to look at solutions from the VMXpi side, but it might have gotten lost in the aether and I’ll try again tomorrow…


I have an email in with @slibert and his Kauai Labs team to look at solutions from the VMXpi side, but it might have gotten lost in the aether and I’ll try again tomorrow…

Somehow I missed the email, but here are some initial thoughts.

I’m assuming on the VMX-pi, networking was configured via the script. This configures both the RPI’s Wifi and also eth0 ports to issue DHCP addresses to any other device requesting DHCP addresses. You can see the configuration information for this in the /etc/dnsmasq.conf configuration file.

We took this approach as a fallback, so that someone with a PC could directly connect ethernet to the RPI, and as long as the PC had DHCP enabled, the two could communicate easily.

Based upon that, it is likely that whatever DHCP-enabled ethernet devices are connected to the same the ethernet network are having their DHCP addresses assigned by the Raspberry Pi. These will be in the 172.22.11.X subnet.

If that’s not the desired behavior, one option would be to disable the RPI eth0 DHCP by editing the etc/dnsmasq.conf file, and then issuing a restart to the dnsmasq service. We don’t currently include a script that does exactly what I’m describing, so it’d require manual editing of the dnsmasq.conf file.

  • scott

Yes, this is what’s happening. If I go look at 172.22.11.X I have the VMX at *.2, gloworm at *.19, and the computer at *.20.

What I don’t have is the Robot Communication w/ driver station in parallel to this. The Driver Station is sitting at for whatever reason, and since I’m not attached to the wifi it’s not connecting through 10.8.41.X.

Can I force the Driver Station to look at 172.22.11.X somehow?

(Is that path easier to understand than changing ethernet settings on the VMXpi host board? Changing my own ethernet settings under the hood will definitely be the Most Hacker Thing I’ve ever done, though the beauty of RPi is I can always just reimage the SD card if I mess something up too badly…)

Can I force the Driver Station to look at 172.22.11.X somehow?

Yes, that’s doable, take a look at the docs on this page for a discussion and an example:

Thank you! It works now. :heart: :dancer: :heart:

…Opened a github issue at to include the undocumented IP address override feature in the WPI docs, because I feel like that is where that information belongs… Driver Station undocumented feature - override robot IP address · Issue #986 · wpilibsuite/frc-docs · GitHub

1 Like