Machine Vision Camera Customization and Design Services

Edge AI, high-speed, and multi-camera systems — processing at the point of capture

A modern industrial camera can capture 40 to 100 Gbps of data and thousands of frames per second. For that data to be useful, it needs to be converted in real time into actionable intelligence. Buffer the frame, move it across a bus, process it on a CPU, and send a decision back. By the time a decision arrives, the imaged part has moved, the laser has drifted, the window has closed. As cameras ramp up data capture, processing that data needs to move closer to the point of capture.

Most engineers confronting that challenge face two unsatisfying options: settle for a closed off-the-shelf smart camera that will not run your algorithm or invest the time and money to develop a fully custom imaging system that will.

Concurrent EDA works in between. We take custom, high-complexity algorithms for machine vision, tracking, or measurement out of software and put them into FPGAs and GPUs, whether they’re embedded or external to your camera. We are systems engineers rather than chip specialists, which means we take on the whole imaging chain: light source and lensing, sensor selection, in-camera compute, and beyond. For a camera buyer, that means you are not forced to choose between a camera that fits your application and an algorithm that solves it. We sell and customize the cameras, and we write the code that runs on them.

 

Where Intelligence Should Live: FPGA, GPU, or Host PC

The most consequential decision in advanced vision system design is often whether the camera’s data gets processed inside the camera or somewhere downstream. Get that answer wrong and no amount of algorithm work will recover the lost latency.

A traditional pipeline moves data through discrete stages. The image sensor converts photons to pixels. The camera interface turns pixels into packets. A frame grabber assembles packets into frames and writes them into system memory. A CPU or GPU turns frames into knowledge, and the resulting control signal travels back out through an I/O card, often crossing the bus twice. Every stage buffers, and every buffer costs time. End-to-end latency in this architecture can run from tens to hundreds of milliseconds.

Moving the processing into the camera removes these stages. With the image sensor paired to an onboard FPGA, pixels are processed as they arrive, before a full frame exists. Work that takes 1 to 10 ms in a typical machine vision system takes 4 to 20 µs in an FPGA-equipped smart camera, translating into 50 to 250 times lower latency.

Traditional camera, frame grabber, and PC pipeline compared with an FPGA-equipped smart camera

Not every application demands such sophistication. A Jetson-class GPU will typically return a processed first frame in tens of milliseconds, at frame rates in the range of 20 to 50 per second. For inspection, code reading, and sorting, it is the easier and more cost-effective answer. If software can do the job, favor software. The threshold for more advanced solutions is a control loop that has to close in under a millisecond, or a frame rate above 1,000 fps. Past either line, software cannot keep up and processing work belongs on the pixel stream.

What In-Camera Processing Buys You

  • Your own algorithm embedded in the camera instead of a vendor’s fixed feature set
  • Deterministic real-time response measured in microseconds, not milliseconds
  • One device in place of a camera, a frame grabber, and an industrial PC
  • Lower size, weight, and power — less heat to move and a smaller enclosure
  • Reduced integration cost and a shorter path to deployment

Twenty Years of Custom Machine Vision Cameras and FPGA Design

Concurrent EDA is an AMD Elite–certified design partner. We both sell and customize the hardware — high-speed cameras, open smart cameras, FPGA modules, and frame grabbers — and we develop the custom FPGAs and vision systems that run on it. For 20 years we have transformed custom algorithms into FPGAs and systems-on-chips for customers in defense, industrial automation, commercial products, and professional sports.

Three camera platforms cover most of what those customers need: a smart camera running your algorithm at the edge, a high-speed camera that computes at the sensor’s peak rate, and a multi-camera system feeding a single compute environment.

Alecs: An Edge AI Smart Camera That Runs Your Algorithm

Allied Vision Alecs edge AI smart camera

Allied Vision’s Alecs smart camera puts the compute inside the camera housing. It pairs Allied Vision’s Alvium camera platform with an NVIDIA Jetson Orin system-on-module behind 5 MP or 12 MP Sony global shutter sensors in mono or color. It replaces camera, frame grabber, and PC with a single device that performs capture, real-time compute, and storage or cloud upload.

Because the platform is open and Linux-based, it will run whatever algorithm you put on it. Concurrent can develop the algorithm and customize the camera around it.

Our work starts on your line, not on our bench. We deploy Alecs to capture images from your actual process, under your actual lighting, and at your actual line speed. We develop the algorithm from that real data and then redeploy it on the same camera. That sequence makes the evaluation the deployment: You learn whether the measurement is achievable — and whether your illumination supports it — before committing to a design.

Typical Applications

  • Barcode detection and OCR across a full 12 MP frame
  • Surface inspection and defect detection
  • Dimensional measurement and gauging
  • Fiducial detection for alignment and pose
  • Object, position, and people detection for robotics and material handling

Alecs also makes economic sense at volumes that could never justify a custom vision program. The long tail of applications — a few dozen cameras, one specific measurement, a process few others run — is where an open camera plus a custom algorithm excels.

GigaSens High-Speed Machine Vision Cameras

Open the case on nearly any machine vision camera and you will find an FPGA next to the image sensor. In most cameras it is sized for exactly one job: moving pixels to the host. There is no room left to compute.

GigaSens cameras provide that room. The FPGA inside runs your algorithm on the pixel stream at the sensor’s peak rate, finishing before the next frame arrives. The GigaSens HS 2-2247, for example, delivers 2,247 fps at full 1920 x 1080 resolution and more than 170,000 fps when the region of interest is reduced to a narrow band.

That matters wherever the camera sits inside a control loop:

  • Additive manufacturing melt pool monitoring. A laser melts metal powder, forming a pool that must stay within a narrow size window. Too small and the layer will not fuse; too large and it spatters. The camera monitors the pool to enable the system to tune laser power in real time.
  • Laser tracking. Scientific and defense positioning systems shine a laser on a target and derive position from where the spot lands in the image. Find the spot, compute the offset, correct the mechanism.
  • Laser line 3D metrology. The offset of a projected laser line gives the height of the object. Each frame contributes a single line to the finished scan at sub-pixel accuracy, which makes the scan rate the frame rate.
  • Semiconductor positioning feedback. A positioning table has to report where it is and be corrected inside the interval between frames. This is a current inbound requirement at Concurrent.

Bring us your model in MATLAB, Python, or OpenCV and we’ll convert it into FPGA logic inside a GigaSens camera. What ships back is a custom OEM camera running your algorithm at the sensor’s full frame rate.

Multi-Camera Systems: Synchronized Capture, One Compute Environment

Some machine vision problems require capturing a scene from multiple angles at once. Multiple high-speed cameras, distributed across a space that can range from a tight robot cell to a stadium, stream to a single server that records and compresses data in real time while holding every camera synchronized to within one frame. Operators drive the system from a web interface. We can support the system remotely while it runs.

Synchronization is the hardest part, and it is a networking problem. Standard Ethernet, by design, is permitted to drop packets when a switch gets congested. Time-sensitive networking instead guarantees delivery through defined streams: scheduled bandwidth, tight time synchronization, no dropped packets. On the camera side, our UDP IP core lets FPGA logic write straight to the network and land in a Python socket at the other end, which is roughly 4x more efficient than pushing the same data through the Linux network stack.

Applications reach well past professional sports venues, where these systems started, to include factory floor process capture, experimental test cells, robotics development, and multi-sensor fusion — anywhere you need every angle, tightly synchronized, in one compute environment.

Custom Camera Modules, Image Signal Processing, and FPGA Acceleration

When none of these three cameras fit your application, we build one.

Custom Camera Modules: MIPI, USB, and GMSL

Concurrent can integrate MIPI, USB, and GMSL modules into whatever processor architecture you are running — CPU, GPU, or FPGA. We can even engineer mixed systems that combine a 3D depth camera, USB cameras, and a custom MIPI module in one design. Because the Alvium platform supports a wide range of sensors, building the Alecs concept around a different device is a straightforward customization rather than a new design.

Image Signal Processing

Measurement and detection are only as reliable as the pixels underneath them, and an artifact that shifts from frame to frame looks exactly like a defect. Raw sensor output is not an image. Generating a usable image from raw data involves bad-pixel correction, debayering, color correction, white balance, and flat-field correction. Our engineers can ensure that correction occurs quickly and accurately, either on an FPGA or a GPU.

FPGA Algorithm Acceleration

If you can prototype an algorithm in OpenCV or Python cv2, we can put it on the chip. Concurrent ports standard vision building blocks into FPGA blocks, so the path from your working prototype to a hardware reality is a translation rather than a rewrite. And producing that prototype is easier than it used to be: Describe the problem to an AI assistant, get Python to prove the concept against your own data, and bring it to us. You supply the proof that the measurement is possible; we make it run inside a camera, on a board measured in centimeters, within a power budget you can keep cool. Learn more about our vision design services.

How We Start

Your answers to three lines of inquiry will tell us most of what we need to begin:

  • Where does your data come from? What sensor, how many pixels, how many frames per second, and how many Gbps?
  • What knowledge are you extracting? What does the algorithm need to find, measure, or decide?
  • Where does the result go? Back into a control system? Up to a machine vision host? Out to a warehouse management system?

Then we just need to spec two constraints: your latency budget — seconds, milliseconds, or sub-millisecond — and your size, weight, and power envelope.

 

Let’s Talk About Your Machine Vision Application

Whether the input is a single frame, a 170,000 fps stream, or multiple synchronized cameras, the job is the same: Process it faster and closer to the source, in a smaller package, running your algorithm.

Initial conversations are free and are with the engineers who do the work. If we are not the right people to solve your problem, we will tell you that.

If your application depends on real-time vision processing, Concurrent EDA can help you build it.