Bocce Tech Camera Hardware Considerations

Howdy 👋

Welcome to the 3 new subscribers this week!

This week I'm late to the punch. 

I didn't get this draft completed before the weekend. I didn't have my wife edit it. I played 2 bocce tournaments on Sunday (excuse). Now I'm sick and thus am missing league finals tonight where our team has a 9-1 record and potentially a chance at winning the league.

I haven't felt like writing. But then I remembered my very encouraging conversation with Milan 2 weeks ago. And I remembered countless other conversations since. Furthermore, I have some opportunities brewing beyond Chicago city limits with this project that have inspired today's write-up (more later on that front). I am one subscriber away from hitting 100 having only been publishing since mid-October. And a whopping 65% of the emails going out are being opened which is a pretty decent open-rate stat.

Those conversations and stats keep me 👉accountable👈.

Gotta keep going even if it is published late in the day!

📆 That said, I am taking a newsletter hiatus until January 10th. This will give me time to take a break, organize my thoughts, and spend more time coding and less time writing.

While I'll be away from the lab for part of the time (visiting family in NC), I'll have some video files from my cameras that I can work with to improve my algorithms. I have a backlog of features to integrate and a number of experiments to run that don't require me to physically move a ball under the camera while I debug. Or maybe I could train my Shark Vac Mop robot (like a Roomba) to drive around and push balls for me while I'm many miles away...kidding.

Getting on with it...or getting it on...

Last week, I wrote about recognizing/differentiating between bocce ball colors/patterns. It is still a work in progress.

For now, most testing avoids balls with similar color profiles just so I can keep making forward progress. I need some time to gather training data for an AI model for the ball differentiator and believe it or not, gathering the data is more time consuming than actually training the AI.

This week, let's shift gears and discuss hardware. I'd like to consider the following:

• Camera interfaces (cables, protocol, speed)

• Cameras (resolution, speed, lens)

• Networking

• Computational horsepower

• Broadcast

Design tradeoffs are interrelated while considering all of the above.

I'm not particularly a camera hardware expert, but here's what I've learned over the past couple years tinkering with this project and even consulting with some applications engineer/sales experts.

Camera placement and Cabling

Cameras need to be spaced about 15ft apart and about 12-16ft above the court in order to "see" the court and balls.

Interface Tradeoffs

These next few paragraphs consider:

• Cable Length

• Network Traffic

• Power

• Speed (Frames Per Second, FPS)

• Price

• Compatibility with Inexpensive Broadcast Software

USB webcams which are great for price/performance are immediately eliminated because their cable lengths are only good for about 3ft to 9ft. That is, unless we were to place a computer next to every camera (impractical but not impossible). USB is fast and provides power, but cable length is limited.

Now let's consider IP Cameras. Without signal degradation, Ethernet is good up to 300ft. Power over Ethernet (POE) is good up to 100ft. Power (48VDC) and signal run over the same cable. 100ft is a workable distance for a 90ft court (network switch or computer placed somewhere near the middle).

There are two types of IP Cameras: (1) Security and (2) Machine Vision.

Security Cameras are prevalent and cheap, but oftentimes they have significant lens distortion (wide-angle and fisheye) and rarely have interchangeable lenses. Depending on the model, that isn't a showstopper, it just isn't ideal. Another security camera benefit is that they support RTSP (Real Time Streaming Protocol) which uses efficient compression yielding a decent FPS (Frames Per Second).

IP Cameras that fall into the Machine Vision category are known as GigE or 10GigE (gigabit and 10x gigabit respectively). Cat6 grade Ethernet cable is required. The GigE protocol does not compress the video frames/signal. This is a huge disadvantage and increases network traffic and slows the FPS. To combat this, a Frame Grabber can be installed in the computer per camera. This is an alternative to using a POE Network Switch.

Another Machine Vision option is CoaXPress coaxial cable cameras have the huge benefit of being very high speed. These cameras are broadcast-ready operating at 100 FPS or more. Anything over 30 FPS is considered "broadcast ready" by TV standards. Ideally we'd operate a little bit above that. The main disadvantage is that these cameras, their cables, and computer interface cards are very pricey.

Summary of Camera and Interface Discussion

There's a tabular summary of the discussion above:

So what camera setup do I have for testing?

I talked to application engineers at Allied Vision, The Imaging Source, Edmund Optics, and MvTec before selecting cameras for testing. Given that all of these companies play ball in the Machine Vision / Computer Vision space, I landed on a GigE machine vision camera.

For me, the price and cable length were the biggest factors with also a need for a reasonable resolution.

Resolution isn't everything when it comes to machine vision — the more pixels, the more data to process. Oftentimes you end up reducing the size of an image for processing to process it faster. But resolution is very important for broadcast clarity (to date, broadcast has not been my focus).

Initially, I selected Allied Vision cameras that weren't high enough resolution; I quickly returned them, upgrading to a higher resolution (but lower FPS) model.

Currently, I have two Allied Vision Mako-G 507C cameras that are GigE, 5.1MP, and 23FPS. These are paired with varifocal lenses. These cameras are connected to my home network with Ubiquiti UniFi Gigabit POE Switches. Each camera was $1,420 and each lens was about $500.

Ideally, instead of sending the signal through a network switch, I'd have a dedicated frame grabber PCIe card in my computer for each camera. This direct link ensures that network collisions don't occur with the jumbo frames containing images on the same network I use for accessing the Internet.

I have a small form factor PC known as an Intel NUC that I use for this project (they are great and only about $600 on Amazon). Given it's compact size, it can't fit a frame grabbers PCIe card inside of it. Therefore, if I want to play with a frame grabber, I'll need to upgrade my computer.

Connecting my experimental setup to Broadcasting software

I mentioned that to date I haven't prioritized broadcast in my decision for buying camera hardware. That said, I have thought about how to integrate with a broadcast system. Let's explore!

While my camera configuration is not broadcast-ready (limited resolution and FPS). They are great for testing my machine vision algorithms.

There are two easy ways I see for integrating with broadcast equipment: (1) OBS Input, and (2) Switcher Studio Desktop Plugin.

The HDMI output from my Intel NUC computer could easily be piped into Open Broadcaster Software (OBS) as a video input the broadcast team/commentators can switch to at any time. If you're curious about OBS, friends at Bocce Broadcast Network and RecRec take advantage of OBS for their YouTube streaming for Bocce and Shuffleboard respectively. 

Alternatively I could install Switcher Studio's plugin on my computer to pipe my computer screen into their iPhone/iPad based broadcaster software. Switcher Studio is an iPad app that brings in camera feeds from iPhones on the same WiFi network. American Bocce Co has used this app a couple times from broadcasting Chop Shop league finals to the 2022 ABC Open on Facebook. The Bocce Bros have used this software as well.

Another option to explore

From the OBS forms I've learned that any OBS feed can be turned into an RTSP feed. This might be a good option for interfacing OBS camera feeds into my bocce software, but I haven't fully explored this yet. In a roundabout way, it would need to be piped back into OBS (see the previous section).

What are the next steps?

The setup I have right now is plenty for me to accomplish quite a lot of software development. There are a number of optimizations I can make in my software to increase FPS prior to breaking down and buying a faster computer.

If my system ever gets integrated with someone's broadcast, then we'll need to work together to select optimal cameras and cables for a quality stream.

Share Bocce Tech!

If you're reading this in your inbox, you'll see a URL below that is your personal referral link. Share the link with your bocce squad and you'll earn referral credits. I've got some rewards to share with you for your efforts!

Thanks for reading

I'm taking a writing hiatus, so I'll see you on 🌮 Taco Tuesday January 10th 2023!

Happy New Year!

~ Digital Dave