How to Install Google Coral USB Accelerator on Linux

If you’re running object detection on camera feeds or doing any kind of local AI inference, you’ve probably noticed your CPU sweating through the workload. Google Coral is a small USB device—or PCIe module if you want to get fancy—that handles inference offloading, leaving your main processor alone. This walkthrough covers getting Coral running on Linux, configuring it properly, and the mistakes I made so you don’t have to repeat them.

Why Google Coral for Your Homelab

The pitch is straightforward: dedicated hardware for AI inference means you run real-time object detection without tanking your CPU. The USB Accelerator costs about $100, draws almost nothing, and processes images fast enough that Frigate—the self-hosted NVR most people run—barely notices it’s there.

I spent three months running detection on a GTX 1080 before switching to Coral. The GPU still does other work, power consumption dropped, and latency on object detection went down. The tradeoff is that Coral only handles inference, not training. You still need to bring your own model, though Google hosts a bunch of pre-converted ones for common tasks.

The thing that surprised me: the USB Accelerator is genuinely robust. I’ve had the same one sitting in a drawer for two years, powered it back on last month, and it just worked. No driver drama, no firmware nonsense. That alone makes it worth keeping around.

Prerequisites and Hardware

You need a Linux host. I’ve tested this on Ubuntu 22.04 and Debian 12. Raspberry Pi works, but if you’re using a Pi 4, you’re already CPU-constrained, so Coral helps more than it hurts—though I’d warn that you’re still fighting against shared USB bandwidth.

Hardware checklist:

• Google Coral USB Accelerator (the one that looks like a thick USB stick)
• A USB 3.0 port (USB 2.0 technically works but defeats the point)
• Linux host with kernel 5.10 or later
• At least 2GB RAM for Docker, more if you’re running Frigate
• Docker and Docker Compose installed

If you’re running this headless, SSH access is fine. You don’t need a GUI. The Coral driver is tiny and self-contained—total footprint including runtime is under 200MB.

Installing the Google Coral Driver and Runtime

Start by checking that your system recognizes the device. Plug in the USB Accelerator and run:

lsusb | grep Google

You should see something like Bus 001 Device 005: ID 1a6e:089a Google Inc. Coral. If you don’t see it, try a different USB port or a different cable. I’ve had flaky cables before.

Now add Google’s apt repository and install the runtime:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://packages.cloud.google.com/apt coral-edgetpu-stable main" | sudo tee /etc/apt/sources.list.d/coral.list
sudo apt-get update
sudo apt-get install -y libedgetpu1-std python3-pycoral

The libedgetpu1-std package is the key piece. The -std variant runs at standard clock speed; there’s also a -max version that overclocks the device slightly for faster inference at the cost of more heat and power. I use -std and haven’t hit any performance walls yet. If you install -max later, you need to uninstall -std first—they conflict.

After installation, verify the driver loaded:

cat /etc/udev/rules.d/99-edgetpu-accelerator.rules

If that file exists and contains rules for the Coral device, you’re set. If not, add these rules manually:

sudo bash -c 'cat > /etc/udev/rules.d/99-edgetpu-accelerator.rules << EOF
SUBSYSTEM=="usb", ATTRS{idVendor}=="1a6e", MODE="0666"
SUBSYSTEM=="apex", MODE="0666"
EOF'

Reload udev and restart the driver daemon:

sudo udevadm control --reload-rules
sudo systemctl restart apex

Test that the runtime sees the device:

python3 -c "from pycoral.utils.edgetpu import list_edgetpu_devices; print(list_edgetpu_devices())"

If that returns something like [('/dev/apex_0', 'usb')], you’re done here. If it returns an empty list or an error, the device isn’t being detected yet. Nine times out of ten, it’s a permission issue or the device needs another rescan. Try unplugging and replugging the USB accelerator.

Docker Compose Setup for Frigate or Inference

At this point, the Coral hardware is ready, but running inference directly from the host CLI isn’t how most people use it. You want it available inside Docker containers, which means exposing the device and installing the runtime inside the container too.

Here’s a working Docker Compose setup for Frigate with Coral support:

version: '3.8'

services:
  frigate:
    image: ghcr.io/blakeblackshear/frigate:0.14.0
    container_name: frigate
    privileged: true
    restart: unless-stopped
    devices:
      - /dev/bus/usb:/dev/bus/usb
      - /dev/apex_0:/dev/apex_0
    shm_size: '256mb'
    ports:
      - "5000:5000"
      - "8554:8554"
      - "8555:8555/udp"
    environment:
      - LIBEDGETPU_EDGE_TPU_STATE_DEFAULT=enabled
    volumes:
      - ./config:/config
      - ./storage:/media/frigate
      - /etc/localtime:/etc/localtime:ro
    cap_add:
      - IPC_LOCK

The key parts: /dev/apex_0 is the Coral device; /dev/bus/usb is needed for USB communication; shm_size matters for Frigate with multiple cameras. I set mine to 256MB and it works fine with three 1080p streams. If you go higher, adjust accordingly. The LIBEDGETPU_EDGE_TPU_STATE_DEFAULT=enabled variable tells the Coral library to expect the device to be present.

Before you bring Frigate up, create the config directory and add a basic frigate.yml:

mkdir -p config storage
cat > config/config.yml << 'EOF'
general:
  time_zone: America/Chicago

logger:
  level: debug

detectors:
  coral:
    type: edgetpu
    device: usb

video:
  telemetry:
    scale: 320

recording:
  enabled: true
  retain:
    default: 7
EOF

Then bring Frigate up:

docker-compose up -d

Check the logs to make sure Coral was detected:

docker-compose logs frigate | grep -i coral

You should see something like [INFO] Using 1 edge TPU device. If you see [WARNING] No edge TPU detected, the device mapping failed. Most common reason: the device file doesn’t exist or has the wrong permissions. Run ls -la /dev/apex_0 on the host and make sure it’s readable.

First-Run Configuration and Tuning

Once Frigate detects the Coral, you need to actually configure detection. The default Frigate config above is bare-bones. You’ll want to add your cameras and detection zones.

Here’s the thing that tripped me up: Coral models are quantized and optimized, which means they’re fast but less accurate than their full-precision cousins. For most object detection tasks—people, cars, dogs—Google’s pretrained models are excellent. But if you’re trying to detect something obscure, accuracy will suffer. Accept this upfront or you’ll spend hours tweaking config.

Add a camera block to your config:

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://192.168.1.100:554/stream
          roles:
            - detect
            - record
    detect:
      width: 320
      height: 320
      fps: 5

The detect resolution (320×320) is important. Coral models are typically trained on small inputs, and larger resolution doesn’t buy you much—just eats power. Frigate will resize frames automatically. Start at 320 and only go higher if you need better accuracy.

After updating the config, restart Frigate:

docker-compose restart frigate

Give it 30 seconds to initialize, then open the Frigate web UI at http://localhost:5000. You should see your camera feed and detection happening in real-time. Watch the system stats tab—CPU usage should be low, and the Coral device should show some utilization.

Common Gotchas and Fixes

I’ve hit most of these at least once, so here they are:

Device disappears after reboot. The udev rules aren’t persisting or the apex service isn’t starting. Run sudo systemctl status apex and sudo systemctl enable apex to make sure it starts on boot. If the device still doesn’t appear, manually reload rules: sudo udevadm control --reload-rules && sudo udevadm trigger.

Container can’t find /dev/apex_0. The device exists on the host but not in Docker. This usually means you’re using an old Docker image that doesn’t have the Coral runtime installed, or the device mapping syntax is wrong. Double-check the devices: section in your compose file. Also, make sure you’re using a recent Frigate image—pre-0.13 builds didn’t include Coral support by default.

High latency or dropped frames. If your USB bus is shared with other high-bandwidth devices (external drives, other accelerators), Coral might get starved. Try moving it to a different USB port or using a powered USB hub. Also, if you’re running on a Raspberry Pi with Ethernet over USB, you’re fighting for bandwidth—consider moving to Pi 5 with dedicated USB 3.0 if this is critical.

Model compilation errors. If you’re using a custom model that isn’t pre-compiled for Coral, you need to convert it first. Google provides a conversion tool, but it’s a separate step. For now, stick with their prebuilt models (available at coral.ai/models). Debugging custom model conversion is its own rabbit hole.

What to Do Next

Once Coral is stable and detecting objects, the next step depends on what you’re trying to do. If you’re running Frigate, you probably want to tune detection zones and confidence thresholds so you’re not drowning in false positives. If you’re building something else—a custom inference pipeline, an alerting system—you now have the hardware to do it without hammering your CPU.

One thing worth exploring: Coral has an Edge TPU Compiler for converting your own TensorFlow Lite models. If you have a model trained elsewhere and want to run it on the device, that’s the path forward. The learning curve is real, but the result—local, fast, power-efficient inference—is worth the effort.

I keep the USB Accelerator plugged in permanently now. It’s reliable enough that I don’t think about it, which is exactly what you want from infrastructure.

FAQ

Can Google Coral run on a Raspberry Pi?

Yes, the USB Accelerator works on any Linux system with a USB port, including Raspberry Pi. However, Pi’s USB bus is shared with Ethernet on models 4 and earlier, so bandwidth can be a bottleneck if you’re also transferring a lot of data. Pi 5 has dedicated USB 3.0, which is better.

Do I need to install anything else for Coral to work in Docker?

The container needs the Coral runtime installed (libedgetpu), and you need to map the device file (/dev/apex_0) into the container. Most pre-built images like Frigate already include the runtime. If you’re building a custom Docker image, add libedgetpu1-std to your RUN statement.

How much does Google Coral cost?

The USB Accelerator typically costs $100–150 depending on where you buy it. The PCIe M.2 module is more expensive (around $200–300) but offers higher throughput and lower latency. For most homelab use cases, the USB version is sufficient.

Can I run multiple Coral devices on one host?

Yes, you can connect up to four USB Accelerators to a single host. Each device gets its own /dev/apex_X file. You can map all of them into containers or distribute them across different services. In Frigate, you’d reference them by device ID in the detector config.

What’s the difference between libedgetpu1-std and libedgetpu1-max?

The -std version runs at standard clock speed and draws less power. The -max version overclocks the chip for slightly faster inference (maybe 10–15% depending on the model) but runs hotter and uses more power. For most use cases, -std is fine. Install only one—they conflict if both are present.

Explore Google Coral in our AI Homelab Toolkit.