PCB Arts Blog

Lessons learned from running our own pick-and-place line

Yannik Wahl, Manufacturing Manager Electronics — Tue, 26 May 2026 12:48:47 GMT

We run our pick-and-place machine exclusively for PCB Arts projects and products – no external EMS service. Here's what's surprised me most in the first months of operation.

Key learnings

Component management is a much bigger topic than I expected. Keeping track of which parts are where, what's open, what's committed, what needs to be reordered – and doing it systematically – turns out to be central. Both to keep the overview, and to run the process efficiently.

80 % of the time goes into setup. The placement itself is a fraction: the machine places 400–500 components on a board in 10 minutes. Loading the right reels into the right feeders, calibrating pick positions, verifying parts – that's where the hours go.

The machine has no intelligence. A modern pick-and-place is mechanically and optically extraordinary, but it has effectively no AI. In my view, there's a clear technology gap especially in the teach-in of pick positions, compared to what's possible today with edge vision. That has made the relevance of our own edge technology more concrete to me than any whitepaper could.

Why setup costs barely apply to us

A typical EMS provider faces a new setup with every job – different feeder layouts, different parts, different programs. Because we only build our own products, the same reels stay loaded and the same programs sit ready. The 80 % setup overhead largely disappears in serial production. That's also why we don't open the line to external work: it would erase exactly that advantage.

My takeaway

The PnP is a major value gain for us, especially when you see boards with around 1,000 components, many of them 0402 and fine-pitch, populated with ease. That's when the potential of the machine really lands.

We've now completed our first complex production runs at industrial-level quality. The learning curve has been steep, and it will stay steep until we have a fully consolidated process for running small series efficiently and reliably.

Choosing the right lens for your vision application

Michael Gilge, Embedded Vision Expert — Wed, 13 May 2026 14:10:29 GMT

In nearly every vision project we work on at PCB Arts, the optics receive less engineering attention than the sensor or the inference pipeline – and yet the lens defines what your sensor can actually see. A 12 MP sensor behind a poorly matched lens delivers the same usable image as a 2 MP sensor. A correctly chosen lens, by contrast, can quietly carry a project across challenging lighting, motion, and environmental conditions without anyone noticing it was ever a risk.

This guide walks through the criteria we apply internally before specifying optics. Embedded vision, automotive ADAS, industrial inspection, and outdoor surveillance all draw from the same toolkit – even if the priorities differ. It is intentionally technical and intentionally ordered: most lens-selection mistakes come from picking a focal length first and only later discovering that the image circle is too small or the MTF cannot resolve the sensor.

1. Start at the Sensor: Image Circle and Sensor Format

Lenses project a circular image. Your sensor crops a rectangle from that circle. The first compatibility check is therefore not focal length, not aperture. It is whether the lens projects an image circle that fully covers the sensor diagonal.

Format	Diagonal	Typical Use
1/4"	4.0 mm	Compact embedded cameras
1/3"	6.0 mm	Automotive, surveillance
1/2.5"	7.2 mm	Embedded vision
1/2"	8.0 mm	Industrial cameras
1/1.8"	8.9 mm	Higher-end industrial
2/3"	11.0 mm	Industrial inspection
1"	16.0 mm	High-resolution industrial
4/3"	21.6 mm	Very high-res, large pixel pitch

The rule is simple: lens image circle must be ≥ sensor diagonal. Undersizing causes vignetting, a gradual darkening toward the corners of the image, or in severe cases a hard black ring. Vignetting is not always visible to the human eye in bright conditions, but it becomes a pipeline problem the moment you have a CNN or classical vision algorithm that expects uniform illumination across the frame. Oversizing (using a lens with a much larger image circle than needed) is generally safe, though it can be wasteful in size and cost since you only use the centre sweet spot of the optical design. If the image circle is not listed explicitly in the data sheet, treat that as a yellow flag in itself.

2. Mount Standards: S-Mount, C-Mount, CS-Mount

The mount determines the mechanical interface, the flange focal distance (FFD), and indirectly the size and weight class of the lens.

S-Mount (M12 × 0.5) is the standard for board-level and embedded cameras. The lens threads directly into a small holder, secured with a grub screw, and covers sensor formats up to about 1/1.8". The FFD is not rigidly standardised, focus is set by screwing in or out and locking in place. The S-Mount ecosystem is large due to automotive and security supply chains: compact, low cost, broad selection, and nearly all serious vendors offer day-and-night variants. This is the dominant mount for embedded edge AI cameras, automotive ADAS development cameras, and most GMSL2 sensor modules.

C-Mount (1"-32 UN, FFD 17.526 mm) is the industrial workhorse. Larger and heavier than S-Mount, but optical designs scale to 1" and 4/3" sensors and give access to the full machine-vision lens market: telecentric, fixed-focal, varifocal, and high-MTF lenses with calibrated distortion data. Choose C-Mount when you need precision, mechanical repeatability, or sensors above 1/1.8".

CS-Mount (1"-32 UN, FFD 12.5 mm) uses the same thread as C-Mount but a 5 mm shorter flange focal distance. A C-Mount lens can be adapted to CS-Mount with a 5 mm spacer ring; the reverse is not possible. Common in surveillance equipment, less so in modern industrial systems.

Rule of thumb: S-Mount for compact, cost-sensitive, embedded systems; C-Mount for industrial precision and larger sensors.

3. Focal Length and Field of View

Once the mount and image circle are settled, focal length determines the field of view (FoV) at a given working distance. The relationship follows a simple geometric formula:

FoV (horizontal) = 2 × arctan(sensor width / (2 × focal length))

For example: a 6 mm lens on a 1/3" sensor (4.8 mm horizontal) at 1 m working distance yields approximately 44° horizontal FoV – equivalent to a 12 mm lens on a 2/3" sensor (8.8 mm horizontal). Two implications worth pinning to your wall:

Sensor size affects FoV at the same focal length. Copying focal lengths from one project to the next without re-evaluating the sensor is a recurring source of bugs.
Working distance matters more than people think. In a fixed-mount installation – ADAS bracket, inspection station, traffic camera – replacing the lens after the mechanical design is frozen is expensive. Always validate FoV against actual installation geometry including tolerances, not a desk estimate.
Exposure time at a given illumination level. A one-stop-faster lens (f/1.4 vs f/2.0) doubles the light and halves the required exposure. For automotive cameras at 30+ fps in mixed lighting, this is often the difference between a sharp frame and motion blur.
Signal-to-noise ratio at a given frame rate. Critical for low-light surveillance and any AI pipeline whose accuracy degrades on noisy frames. SNR loss is rarely visible to the human eye until well after a CNN has started misclassifying.
Depth-of-field budget. A f/1.4 lens has a tight DoF, fine for a fixed inspection distance, problematic for objects moving in Z. DoF scales roughly with f-number; the trade-off between light and DoF is direct and often painful.
24/7 outdoor cameras – security, traffic enforcement, industrial perimeter monitoring – running with active NIR illumination at night and ambient visible light by day.
Automotive ADAS, surround-view, and driver-monitoring cameras, which operate across mixed lighting and often combine visible imaging with NIR functions.
Industrial inspection using NIR for material discrimination: moisture detection in food, plastic-type identification for sorting, inspection through certain inks and coatings, vein imaging in medtech.
Axial (longitudinal) chromatic aberration: different wavelengths focus at slightly different distances along the optical axis. Red and blue channels are in focus at marginally different Z positions. The result in a colour image is colour fringing at high-contrast edges – a red or cyan halo – and a loss of sharpness in at least one colour channel.
Lateral (transverse) chromatic aberration: different wavelengths arrive at slightly different heights on the sensor plane. This causes colour channels to be magnified differently, producing colour fringing that increases toward the corners and cannot be fixed by refocusing.
CNN-based pipelines: colour fringing at edges introduces spurious colour gradients that are not present in the scene. Depending on how the network was trained, these can generate false features and degrade classification accuracy, particularly at object boundaries.
Colour measurement and grading applications: lateral chromatic aberration shifts colour channels spatially, causing measured colour to depend on position in the frame. This is largely invisible to a human reviewer but corrupts quantitative colour analysis.
Stereo and multi-camera rigs: if chromatic aberration differs between lenses (even of the same type), colour-based matching across cameras becomes unreliable.
Sensor format → minimum image circle. Eliminates two-thirds of the catalogue immediately. Check for vignetting at corners.
Working distance + required FoV → focal length. Validate against actual mechanical installation with tolerances. Use the formula: FoV = 2 × arctan(sensor width / (2 × f)).
Pixel pitch → MTF requirement. Match the lens resolution rating to the sensor's Nyquist frequency, with margin. Do not rely on megapixel count alone.
Lighting conditions → f-number, T-number, day-and-night requirement. The worst-case low-light scenario drives this, not the typical case. Request transmission curves for noise-limited applications.
Colour sensor → chromatic aberration specification. For colour cameras and AI pipelines, check per-channel MTF curves and ask about APO correction. Monochrome sensors can skip this step.
Mechanical and environmental constraints → mount, size, locking screws, IP rating, temperature, vibration. For embedded and outdoor projects, this often inverts the priority list.
Distortion tolerance → standard, low-distortion, or telecentric. Telecentric lenses maintain constant magnification across the working distance range and are essential for dimensional measurement and gauging. Low-distortion machine-vision lenses suffice for most other metrology applications. Barcode reading and lane detection sit in between.
Cost and supply chain → final pass. Confirm the lens has a supply roadmap and a second source, especially for series production.

For wide-angle lenses (≤ 4 mm on a 1/3" sensor), geometric distortion becomes significant. If straight lines must stay straight – barcode reading, dimensional measurement, lane detection – you need either a low-distortion machine-vision lens or a software calibration step. The engineering time for calibration often exceeds the cost delta of the better lens.

4. Aperture, Light Gathering, and the T-Number

The f-number describes how wide a lens opens relative to its focal length: f/1.4 means a wide aperture with more light and shallower depth of field; f/8 means a narrow aperture with less light, more depth of field, and often better corner sharpness.

In machine-vision contexts, light-gathering capacity drives three things:

The f-number is purely geometric. It describes the aperture diameter relative to focal length. The actual transmitted light is described by the T-number (Transmission number), which accounts for internal reflections and coating losses. A nominally fast f/1.4 lens with poor anti-reflection coatings can transmit light equivalent to an f/1.8 or even f/2.0 lens. In low-light or noise-limited applications, ask the vendor for spectral transmission curves and T-number data rather than relying on the f-number alone.

Vignetting also worsens at extreme apertures, causing a measurable roll-off in corner brightness, typically expressed in EV or as a percentage of centre brightness. A lens that shows –2 EV at the corners wide open may be acceptable for surveillance but will corrupt any pipeline that relies on photometric uniformity across the frame.

5. Resolution: Matching MTF to Pixel Pitch

A "5MP-rated" lens is one whose Modulation Transfer Function (MTF) sustains acceptable contrast at the spatial frequency that a sensor's pixel pitch demands. MTF describes how faithfully a lens reproduces contrast at progressively finer spatial frequencies, measured in line pairs per millimetre (lp/mm). At the Nyquist limit of the sensor, a lens must still deliver sufficient contrast to feed pixel-level information into the silicon.

The rule of thumb: a lens needs to resolve detail at approximately half the pixel pitch to deliver pixel-level resolution. The smaller the pixels, the harder the optical job:

Sensor / Pixel	Pixel Pitch	Required Resolution
Sony IMX477	1.55 µm	~320 lp/mm
Sony IMX390 (automotive)	3.0 µm	~165 lp/mm
Typical 5.5 µm industrial	5.5 µm	~90 lp/mm
Typical 10 µm industrial	10.0 µm	~50 lp/mm

A lens whose MTF drops to near-zero contrast at the sensor's Nyquist frequency cannot deliver pixel-level resolution – your effective resolution is bounded by the optics, not the sensor. We have seen projects where replacing a generic S-Mount lens with a properly MTF-matched alternative recovered full sensor resolution with no other change.

Important: when a vendor specifies "X megapixels" on a lens, always verify what pixel pitch and sensor format that rating assumes. The same nominal "5 MP lens" can be excellent on a 1/2.5" sensor (2.0 µm pixels) and inadequate on a 1/1.8" sensor at the same megapixel count but smaller pixels and higher Nyquist frequency. Same count, harder problem.

6. Day-and-Night Lenses: Focus Stability Across Visible and NIR

Standard machine-vision lenses are designed for visible light (400–700 nm). Their refractive index varies with wavelength (chromatic dispersion), so when you remove the IR-cut filter – or use NIR illuminators at 850 nm or 940 nm – the focal point shifts along the optical axis. The result: an image that is sharp in daylight but soft at night, or vice versa, with no good mechanical solution short of refocusing.

Day-and-night lenses (also called IR-corrected lenses) use glass formulations and element designs that maintain a stable focal plane across visible and NIR wavelengths. This matters in three scenarios:

A frequent and costly confusion: pairing a day-and-night lens with a sensor that has an aggressive IR-cut filter integrated in the cover glass provides no advantage. The lens transmits NIR, but the sensor blocks it before it reaches the silicon. Always confirm both sides of the optical chain.

7. Chromatic Aberration: The Colour Camera Trap

This section is less commonly covered in lens-selection guides, but it matters the moment you move from monochrome to colour sensors or to multi-spectral pipelines.

Lenses exhibit two types of chromatic aberration:

For monochrome sensors, chromatic aberration is largely irrelevant – you're working with a single effective wavelength (or a narrow-band illumination). For colour cameras, both aberrations degrade sharpness and colour accuracy. The practical consequences:

High-quality machine-vision lenses correct for chromatic aberration using apochromatic (APO) or fluorite-element designs. These bring red, green, and blue into a common focal plane and minimise lateral shift. The performance difference between a consumer S-Mount lens and an APO-corrected industrial lens can be dramatic on small pixels, particularly at full aperture and toward the sensor corners.

When evaluating lenses for colour applications, ask the vendor for on-axis and off-axis MTF curves measured independently for red, green, and blue channels. A lens that shows good on-axis MTF but diverging R/G/B curves toward the corners is not suitable for demanding colour or AI applications.

8. Practical Decision Checklist

When specifying a lens, work through these steps in order. Doing them out of order is the most common cause of rework:

If any single step pushes the project into a different mount or sensor category, it is far better to discover that on day two than after a PCB has been routed around the wrong camera module.

A final thought. Optics behave like power supplies in electronic design: when they are right, nobody notices; when they are wrong, every engineering decision downstream suffers. A thirty-minute review of these eight points at the start of a project routinely saves days of debugging later.

If you would like a sanity check on a lens decision for a project you are working on, get in touch. We are happy to take a look.

Thorium 16x GMSL2: 40 Gbit/s for Multi-Camera Edge AI

Saber Kaygusuz, Teamlead Software — Wed, 13 May 2026 13:49:45 GMT

The number of customer projects we've taken on in the last two years that needed twelve, fourteen, or sixteen cameras feeding a single edge AI box has grown steadily. Autonomous robotics, industrial inspection lines with surround-view requirements, automotive sensor test rigs, large-area surveillance arrays – the use cases differ, but the underlying bottleneck is always the same: how do you get that many high-resolution, low-latency video streams into a single NVIDIA Jetson without compromising on either the camera selection or the AI workload running downstream?

Thorium 16x GMSL2 is our answer. Sixteen GMSL2 channels, 40 Gbit/s of useful payload bandwidth, built around an NVIDIA Jetson – and, just as importantly, around the camera-driver and BSP ecosystem that we've integrated and stabilized for industrial production use.

This article walks through the technical reasoning behind the platform: why GMSL2 over FPD-Link, what the 40 Gbit/s number actually means in practice, and the honest reality of the camera-driver ecosystem under JetPack 7. If you're sizing a multi-camera edge AI system, this is what we'd want you to know before you commit to a stack.

GMSL2 vs FPD-Link III: the SerDes choice that's not really about bandwidth

GMSL2 (originally Maxim Integrated, now Analog Devices) and FPD-Link III (Texas Instruments) are the two dominant serializer–deserializer (SerDes) interfaces in automotive and industrial vision. Both transport high-bandwidth video over a single coaxial cable, both deliver power-over-coax to remote cameras, and both have forward-compatibility paths to faster successors (GMSL3 at 12 Gbps, FPD-Link IV at 16 Gbps).

On paper, the per-link numbers are similar enough that bandwidth alone shouldn't decide most architectures:

GMSL2 delivers up to 6 Gbps per link forward, with an asymmetric back-channel for control and configuration
FPD-Link III delivers up to 4.16 Gbps per link, similarly asymmetric

The real differences, in our experience designing systems on both, are in the ecosystem around the chip, not the chip itself.

Camera availability. GMSL2 has a broader and more mature ecosystem of off-the-shelf cameras from automotive Tier-1 suppliers, embedded vision specialists, and Asian sensor module manufacturers. If you need a 2 MP HDR camera with a specific lens mount and a published GMSL2 interface, you typically have more choices, shorter lead times, and a clearer path to second sourcing. FPD-Link III camera availability has been improving, but the long tail still lags.

NVIDIA Jetson support. This is the practical decider for edge AI platforms. NVIDIA's reference designs for Jetson AGX Orin and Orin NX include strong support for the MAX9296 and MAX96712 family deserializers, and the major GMSL2 camera vendors ship kernel drivers and device-tree overlays that integrate cleanly. FPD-Link III integration on Jetson is possible – we've shipped systems with it – but the glue work is heavier and the vendor-side support is thinner.

Future-proofing. Both interfaces have credible roadmaps, but GMSL3 backward-compatibility with GMSL2 is already proven in shipping silicon. For a platform we expect to sell for the next five-plus years, that mattered.

We chose GMSL2 for Thorium because of those ecosystem advantages, not because of a 2 Gbps difference in raw per-link bandwidth. If FPD-Link III's ecosystem turned out stronger for a specific application – for example, because of a Tier-1 supplier you're locked into – that calculus could flip. We're happy to make that recommendation when it's the right fit. The technology choice isn't dogma.

What 40 Gbit/s actually means

The 40 Gbit/s figure on the Thorium 16x spec sheet is the aggregated useful payload bandwidth across all sixteen channels what you can realistically push into the Jetson's video-ingest path after protocol overhead, line-coding, alignment, and metadata. Theoretical peak is higher; sustained payload is the number we publish, because it's the one that matters when you build a real system.

In practical multi-camera configurations, 40 Gbit/s translates roughly to:

16 cameras at 2 MP / 30 fps – typical for surround-view automotive testing or industrial perimeter monitoring
8 cameras at 8 MP / 30 fps – high-resolution inspection systems, security arrays
4 cameras at 4K / 60 fps – autonomous robotics with stereo or trinocular vision
Mixed configurations – common in practice; e.g. eight forward-facing high-resolution channels plus eight lower-resolution side and rear channels

One reality worth flagging: in multi-camera edge AI systems, the SerDes link is rarely the actual bottleneck. More often, it's downstream – ISP throughput on the Jetson, GPU and DLA capacity for the AI workload, memory bandwidth on the SoC. We size the link generously precisely so that it never becomes the constraint. The 40 Gbit/s headroom buys you the freedom to swap cameras, push higher frame rates, or add channels without redesigning the platform.

The honest part: JetPack 7 and the camera-driver reality

Anyone who has shipped a Jetson-based multi-camera product knows the hardest engineering problem isn't the SerDes chip or even camera selection. It's keeping the camera drivers, device-tree overlays, and JetPack updates working together over the lifetime of the product.

The situation we navigate continuously goes roughly like this:

NVIDIA releases JetPack on its own cadence. Major versions bring new kernel revisions, new BSP layers, sometimes new userspace APIs – Argus changes, V4L2 stack shifts, ISP behaviour adjustments. Camera vendors ship drivers and device-tree overlays for their products, but they release on their own cadence, typically two to six months behind a major JetPack release. Some vendors are fast; some are slow; some never quite catch up.

When you build a product on a bare vendor driver, every JetPack update is a potential break. Your customers want security patches and new features. The vendor driver isn't ready. You're stuck mediating between three parties.

For Thorium 16x, we've built an integration layer between the camera-vendor drivers and the application stack. It abstracts the camera-specific driver and device-tree details so that:

Customers can swap or mix cameras from different vendors without rewriting userspace
JetPack updates can be applied with predictable effort – we maintain compatibility upward through JetPack 7 and forward, not just the version the platform shipped with
New camera support is added as a discrete, scoped project, not a system rewrite

This integration work is, in our honest opinion, the single most underestimated engineering burden in commercial multi-camera edge AI systems. You can buy a great deserializer and a great Jetson and great cameras and still spend twelve months in driver hell. Thorium ships with that work already done.

What Thorium 16x is for – and what it isn't

The platform earns its complexity when you have at least eight cameras (below that, simpler integration paths are more cost-effective), you need synchronized capture across channels, and you're running real AI workloads on the Jetson, not just routing video for storage.

Typical fits we see:

Industrial automation with multi-angle inspection on a single line
Autonomous robotics requiring 360° vision
Automotive sensor test rigs and ADAS development platforms
Large-area surveillance and perimeter monitoring with on-device AI inference
Medical and life-sciences imaging where multiple synchronized angles feed a downstream model

Where it's overkill: single-camera applications, projects that just need a Jetson dev-kit equivalent, or environments where cable runs and power-over-coax don't earn their cost.

If you're sizing a multi-camera edge AI system and want to talk through the architecture before committing to a stack, drop us a line. We're happy to share what we've learned from the projects we've built, including the ones where GMSL2 turned out not to be the right answer. Fit beats dogma.

EdgeKit: AI-driven coral reef research in the Maldives

Saber Kaygusuz, Teamlead Software — Wed, 13 May 2026 11:18:42 GMT

We are an ocean planet - 3 billion people depend on coastal and marine biodiversity [1]. One essential ecosystem of the sea, source of many medical researches [2] and protector from coastal erosion, are coral reefs. To help restore diversity in animals in these habitats and to accelerate ocean science, Swiss company „Stream Ocean“ is now deploying AI-driven camera modules at coral reefs in the Maldives.

A popular indicator for the health of a reef is its variety in species [3]. An AI identifying all animals passing by is therefore an efficient way to not only see if protection programs are succeeding in real time but also to better connect stakeholders their fundings.

Live monitoring of eco systems under individual conditions however is very costly with projects usually not swimming in funding. Furthermore working outside of human settlements trying to collect data can also generally be a challenging endeavor.

The hardware of the towers today mainly consists of a solar panel, a tripod-construction minimizing anchoring requirements, a micro-HD camera, a battery for power-storage and an internet router.

Due to scarcity of resources in the Maldives, the tower itself is often built from scrap metal.

The last thing that was lacking was a computer solution putting it all together with individually designed solutions unfortunately costing around 30.000$ for development alone, material in production adding another 10-12.000$ [4].

„We met at a fair and quickly noticed we’re on the same page“

Through our custom online configurator and professional support Stream Ocean was able to put together a perfect solution for their needs at minimum cost.

The NVIDIA-driven „EdgeKit“ became part of the project in 2022 and is today storing and processing all collected data. Its cloud-based dashboard called EdgeFleet makes it possible to watch hard drive usage and online status of all towers in real time as well as other important information. Helpers thereby know when to get ready to exchange disks or when something is wrong without having to actually visit towers out in the wild.

EdgeKit also comes with the benefit of using such small amounts of power that even if the weather was cloudy in the Maldives, the towers would practically never run out of power [5].

Thanks to EdgeKit's live online price calculation, expenses can also immediately be estimated without having to wait for an individual offer.

See Live Configurator

„We have just installed our first EdgeKit devices in the Maldives and we are very satisfied. Please enjoy this image of a black tip shark that we just viewed today.“ (David Lunsford, CEO of Stream Ocean)

On the first day of deployment, EdgeKit helped to immediately identify a black tip shark, a great sign of success for a coral reef-protection-program.

Usually, the process of acquiring a custom solution in this field involves a kick-off meeting and a contract holding all given information and needs of the customer, followed by conceptual work and development of the circuit boards. A prototype is built and design verification tests are done. It gets certified and production goes into planning. The cost and production of such concepts can be high as mentioned above.

Our process of development in this project was different:

In a first call the specific use case was discussed and different solutions were considered with the expertise of Stream Ocean and the technical know-how of PCB Arts combined. Topics discussed included where to place the computer (underwater in a tube or above the surface) and maximum size of a computer system
A configuration was chosen together
The micro computers were built within a few weeks not needing to depend on malfunctioning supply chains because we're keeping most of the parts in stock
The EdgeFleet system was initialized on all computers before sending them to Stream Ocean, including a change in EdgeFleet’s code as a free service

„It's important for us to provide reliable technology because the towers are installed and won't be touched by humans for months.“ (Saber Kaygusuz, CEO of PCB Arts)

Besides the possibility of customizing all EdgeKits in color and individual laser cut logos, all computers are running on NVIDIA Jetson technology. NVIDIA Jetson is the world's leading platform for autonomous machines and other embedded applications. It’s ideal for AI-based machine vision applications and to perform AI vision tasks such as image classification, image segmentation, object detection and more. It is compatible with open-source computer vision software and machine learning libraries like OpenCV or in this case the YOLO-algorithm.

Furthermore, EdgeKit specializes on edge computing or more specifically: edge AI. Edge is about processing data closer to where it's being generated, enabling processing at greater speeds and volumes, leading to greater action-led results in real time like in the project at hand.

Do you have any questions regarding this project or our technology? Send us an e-mail! We’ll reply asap: mail@pcb-arts.com

Sources

[1] „Biodiversity underpins all fishing and aquaculture activities, as well as other species harvested for food and medicines. Over three billion people depend on marine and coastal biodiversity for their livelihoods […]. Fish continues to be one of the most-traded food commodities worldwide. It is especially important for developing countries, sometimes worth half the total value of their traded commodities.“ - UNICEF’s Convention on Biological Diversity, https://www.cbd.int/article/food-2018-11-21-09-29-49

[2] „Coral reefs are some of the most diverse and valuable ecosystems on Earth. Coral reefs support more species per unit area than any other marine environment […]. Scientists estimate that there may be millions of undiscovered species of organisms living in and around reefs. This biodiversity is considered key to finding new medicines for the 21st century. Many drugs are now being developed from coral reef animals and plants as possible cures for cancer, arthritis, human bacterial infections, viruses, and other diseases.“ - US National Ocean Service, https://oceanservice.noaa.gov/education/tutorial_corals/coral07_importance.html

[3] “Scientists have long hypothesized that biodiversity is of critical importance to the stability of natural ecosystems and their abilities to provide positive benefits such as oxygen production, soil genesis, and water detoxification to plant and animal communities, as well as to human society. […] Although theoretical studies have supported this claim, scientists have struggled for the past half-century to clearly isolate such an effect in the real world. This new study does just that.“ - USGS, https://www.usgs.gov/news/biodiversity-critical-maintaining-healthy-ecosystems

[4] In this case of 10 EdgeKits for Stream Ocean’s project

[5] EdgeKit needs about 20 watt, depending on the configuration