A High-Performance Apriltag Solution: Beelink Mini PC + Photonvision Guide

I’m tired of linking back to the increasingly sprawling raw testing results, so I have condensed the information here in this guide: Mini PC Photonvision Guide - Google Docs

This guide explains how to set up a Beelink Mini PC for Apriltag detection using Photonvision. For someone as Linux-averse as me, this was fairly easy, and I have tested everything in the guide except setting a static IP (added as an issue to PV here) because that looked like it would take an hour and would be fixed before the season anyway.

For under $200 total including cameras, you can create a very high performance vision system that far outperforms Raspberry Pi-based solutions. My favorite configuration at this time is a combo of:
  1. AR0144 localizing tags at 1280x720p at 15fps, 57ms latency, detecting tags 27ft away
  2. OV2710 at 320x240 at 60fps, 9ms latency, detecting tags 11ft away for game piece scoring
  3. Lifecam-3000 at 320x240 used as a driver camera at 30fps

Many other configurations are possible if you have other USB webcams available. The PS3 Eye worked well, for example, albeit with a limited FOV. Single-camera performance is excellent, with the OV9281 achieving 20fps, 42ms latency with a 29ft detection distance at 1280x800 - far enough to localize the 2022 high goal from anywhere on the field. Plus, all distance tests were done with 36h11 tags, so the official 16h5 tags should yield ~21% more detection range than what’s in the guide. This means that you could have multiple 640x480 cameras each doing 60fps detection of tags up to 28ft away.

With no more need for green LEDs blasting the target, and with such an excellent open-source resource in Photonvision, these types of mini PCs represent excellent value. I am convinced that higher performance will only lead to very marginal competitive gains. Hopefully the use of more powerful coprocessors such as these catches on - Raspberry Pi’s are great, but the sky’s the limit with mini desktop computers.


In the other thread you mentioned having issues with multiple cameras and a OV9281 on the same system. Can you describe the problems, was it only multiple OV9281 or was it any other camera and a OV9281 ? Did it only happen when adding a camera and if the system comes up with 2 it is ok?

I haven’t done as much testing as you with the Beelink and OV9281 but I did notice some issues when changing things while having a OV9281 and AR0144 on the system but not if I was just running it.

Also do we know if the issues can be fixed in photon or if they are camera firmware?


My experience was that having ANY camera other than the OV9281 plugged in and processing, then changing ANY setting on the OV9281, would brick the OV9281 output. This brick would persist across power cycles and only went away if I reinstalled Photonvision from scratch. It could sometimes be cleared by moving the OV9281 to another port. If you are getting the AR0144 and OV9281 to play nice, that means the problem is on my end - possibly a bugged camera module.

This should be fixable in Photonvision, but I don’t know who is free to do so. Kind of a shame, given how cheap and high performance the OV9281 can be.

1 Like

You should be quoting the camera lens on the board cameras for everything you do. For instance, you talk a lot about the 3.8mm lens on the AR0144 but say people should get the 100deg lens. I probably would agree, but changing the lens will strongly affect the max distance for the tag detection.


Be warned that Beelink mini pcs are not rugged and I would be cautious running them on an FRC robot. I’ve had issues with internal components/cables coming loose while relocating one.


What do you recommend for a power supply? Do we need to get any extra hardware or can we just do grab 12V straight out of the PDP? Is a battery pack any good for ensuring a graceful shutdown?

1 Like

Rule R602 would prohibit using a battery pack for 12V output.

I would guess that you don’t want to connect it directly to the PDP, since it will not produce enough voltage when the motor load drags down the whole system. You want a buck converter to try to make sure to have 12V, independent of the “battery” voltage, but I don’t have a Beelink and don’t know how sensitive they are to the supply voltage.

1 Like

You really want a buck/boost converter to provide a steady 12V regardless of the battery voltages seen during a match. They automatically switch between buck and boost function as needed. There are a ton of them on Amazon but many of the descriptions are wrong. The simplest buck/boost designs will have 2 inductors on the PCB, like those marked in yellow below:

The converter shown is from Amazon and I’ve run them at 12V and 3A out. They claim it’s a 4 ampere converter but those diodes marked SS34 are 3A diodes, so you probably don’t want to go there. The PCB is 1.8" long. If you see one inductor on the PCB, it very likely isn’t a buck/boost converter. I’m not counting the puny one marked 2R2, which is probably to knock down the output ripple.


All tests were done with the 100deg. I can make this more clear, thanks!

Do you think opening one up to glue down connections would be worthwhile?

Battery pack isn’t FRC legal, unfortunately. I link a good buck boost converter and barrel jack on the second page. The PDP has far too many voltage swings from the battery to be useable without damaging the mini PC.

I saw the comment about the Beelink’s not being rugged enough & looked for alternative mini PC’s (like this one) and noticed there are some (maybe a bit more expensive) with the Celeron N5105, and then I searched and found this, which says “the faster Celeron N5105 is notable for being more energy efficient (10 W TDP vs N5095’s 15 W) yet featuring a faster iGPU model (24 EU UHD Graphics versus 16 EU UHD Graphics, with a higher clock rate to boot).” Maybe worth investigating.

What about the PC’s-on-a-stick like this that take 5V USB-C?

1 Like

The J4125 in your second link will be fairly underpowered unfortunately, 30-50% slower. It’ll be about the same as a Pi4 probably.

N5105 is a good choice if you want to try it out. I expect it would get similar performance. I don’t think GPU acceleration is currently supported for these in Photonvision.

I opened one up to see what could fail and documented my findings in a new section:

I think a few dabs of hotglue on connectors and some loctite on the screws should go a long way. I didn’t see any major failure points, and disassembly took about 5 minutes.


I don’t think GPU acceleration is currently supported for these in Photonvision.

That’s correct.
The GPU acceleration we use on the Raspberry Pi is made viable due to the CPU and GPU being on the same physical die (the SoC), their memory being shared, and the CSI camera being connected directly to the GPU.
This lets us do some initial work on the GPU, which is much better at certain tasks, and then make that pre-processed image available to the CPU without copying (which is slow).

That said, I believe @mdurrani834 is working on (or has already finished) getting Intel TBB, a parallelization framework, integrated in to the WPILib OpenCV (which we use). This won’t give the same kinds of accelerations we get from a GPU, rather making the CPU-specific tasks faster. This will work on more than just Intel CPUs as well, including the Raspberry Pi.


Unfortunately, this won’t be happening for the 2023 wpilib opencv. To do it in a manner that will Just Work will require some additional infrastructure and work to make it play nicely with the current tooling.

OpenCVs build system links libtbb as a shared library which would require we package and distribute it for each platform in a way that guarantees that it is always present without any setup or extra installation, or we would have to modify the opencv build configuration to link statically to a custom build of TBB.

*R602 Other batteries for cameras or computers only. COTS USB battery packs with a capacity of
100Wh or less (20000mAh at 5V) and 5V, 2.5 Amp max output per port, or batteries integral to
and part of a COTS computing device or self-contained camera (e.g. laptop batteries, GoPro style
camera, etc.) may be used to power COTS computing devices and any peripheral COTS input or
output devices connected to the COTS computing device provided they are:
A. securely fastened to the ROBOT,
B. connected only using unmodified COTS cables, and
C. charged according to manufacturer recommendations

The beelink requires a 12v input capable of at least 1.5 amps… not something that can be supplied by a legal battery pack.


I was thinking of making a shock-proof case for the Open Mesh radio. I’d be interested in your design and what kind of padding you choose and still have adequate ventilation. Maybe something like this would be useful padding

Some teams stress test the robots and smash them into walls. Any temptation to drop the computer on all 6 sides?


Weather stripping looks like a good idea. Most likely I’ll have some kind of basic box with holes and foam like that on all sides, not blocking the vents. Plus a barrel jack retainer. Once I do that I’ll drop it a few times and see when I breaks.

1 Like

My favorite way to help shock proof the radio is to attach power redundantly from the VRM via the barrel jack and POE.


While this is nice, the RPM isn’t compatible with this method. Obviously neither is the Beelink PC…

1 Like