EdgeYOLO: an anchor-free detector that ships its own deployment path to RKNN, MNN and TensorRT
an edge-real-time anchor-free object detector with decent performance
At a glance
- What is it?
- EdgeYOLO is a PyTorch object detector aimed at embedded boards, with published COCO and VisDrone weights, a torch2trt export route and C++ inference samples for RK3588, MNN and Ascend. The interesting part is not the accuracy table but how much of the deployment work is already in the repository.
- Who is it for?
- Adopt EdgeYOLO if you are targeting an RK3588, an Ascend 310, a Jetson or an MNN runtime and you want the export scripts, the int8 calibration code and the C++ samples in the same tree as the training code. Do not adopt it if you need instance segmentation or pose estimation today, or if a maintained pip package with a stable API matters more than platform coverage.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 149 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What EdgeYOLO is for, and the constraint it was written against
Most object detectors are trained on a workstation and then handed to someone else to make run on a board. EdgeYOLO is organised around the opposite order. The repository describes it as an edge-real-time anchor-free detector, and the numbers in the README are quoted for an Nvidia Jetson AGX Xavier at batch size 16 with post-processing included, not for a desktop GPU. The base EdgeYOLO model is listed at 50.6 percent AP on COCO2017 at 640x640 and 34 FPS on that board; EdgeYOLO-S is listed at 44.1 percent AP and 63.3 percent AP at IoU 0.5, at 53 FPS. Those are the author's figures, taken from the README table, and they are the ones you should treat as the starting point for your own measurement.
The target user is someone who has already picked a board and now needs a detector that fits it. The repository carries weights for five COCO models and five VisDrone models, the latter trained for small-object aerial imagery. VisDrone accuracy is much lower than COCO accuracy (25.9 percent AP for the full model), which is normal for that dataset and worth noting before anyone reads the COCO column as a general promise.
The anchor-free head, the RH loss and the augmentation pipeline
The detector is anchor-free, which removes the anchor box priors that normally have to be re-tuned when you change dataset or input resolution. The README also names two training-side choices. The first is an augmentation pipeline the authors describe as stronger than the default, intended for datasets with sparse labels. The second is the RH loss function applied at the end of training, which the README says improves detection for small and medium models. The paper is on arXiv (2302.07483) if you want the definitions rather than the claim.
What the repository does not do in the README is explain how the anchor-free assignment works, what the RH loss actually changes, or how the augmentation is composed. The params directory and the training code are where that lives. Treat the README as a pointer, not as a specification. If you plan to modify the head or the loss, you will be reading Python, not documentation.
Training and inference from the command line
Installation is a clone plus a requirements file:
git clone https://github.com/LSH9832/edgeyolo.git cd edgeyolo pip install -r requirements.txt
Inference runs through detect.py. The README gives this example:
python detect.py --weights edgeyolo_coco.pth --source XXX.mp4 --fp16
The documented flags include --conf-thres (default 0.25), --nms-thres (0.5), --input-size (640 640), --batch, --save-dir, --topic for rosbag or ROS topic input, and --fp16. The source argument accepts a video file, a network stream address, a folder of images, or a rosbag. Weights are downloaded from the v0.0.0 release tag rather than from a package index.
Datasets are configured through YAML files in params/dataset. The README notes that YOLO-format datasets are supported through params/dataset/yolo.yaml, alongside the COCO and VisDrone configurations. Docker is offered as an alternative: the image is distributed as a 14.3 GB archive on Baidu Netdisk, imported with docker import edgeyolo_deploy.tar.gz edgeyolo:latest and run with the --runtime=nvidia flags shown in the README. Inside that image, docker_export.py replaces export.py for model export.
The export path is the actual product
The reason to look at this repository rather than another YOLO variant is the deployment directory tree. The README documents C++ inference samples for MNN (added November 2023), for RKNN on RK3588 only (December 2023), and for Ascend, with demo/amct_onnx2om.py converting an ONNX model into the .om format used by Ascend 310 class devices (March 2024). There is also a TensorRT C++ console demo requiring OpenCV and Qt5, and TensorRT int8 export code that includes a calibration training procedure. TensorRT model evaluation is supported as of February 2023.
The Ascend route carries an explicit constraint: the README states you must obtain the corresponding dependency libraries and tools from Huawei, and that some dependencies are only downloadable by users who have purchased the hardware. That is not a packaging inconvenience, it is an access gate. Budget for it before you plan an Ascend deployment.
The multi-platform unified deployment project is the most recent piece of work. The August 2025 release note says it moved to the deployment branch, was refactored, and gained OpenVINO support. The earlier December 2024 entry that announced it on the main tree is struck through in the README, which tells you the layout changed. If you are following a tutorial written before August 2025, the paths it uses may no longer be on main.
Where EdgeYOLO is the wrong choice
The README's own roadmap lists instance segmentation (an EdgeYOLO-mask model), additional model variants and a pretraining method as things that are coming. None of them are here yet. If your task is segmentation or pose estimation, this repository does not cover it, and the roadmap entry is a statement of intent rather than a schedule.
Platform coverage is narrower than the topic list suggests. The RKNN C++ code is labelled for RK3588 chips only. The Ascend path depends on vendor libraries behind a purchase gate. The published FPS figures are for one Jetson board, so they say nothing about your board. And the repository has no homepage and no pip package: you get the source tree, the release assets and the docker archive. There is no versioned API to pin against, which matters if more than one team depends on the training code.
Finally, the documentation is uneven. The README is a changelog plus a command reference. Mechanisms such as the RH loss and the augmentation pipeline are named but not explained in it. Expect to read source for anything beyond running the supplied scripts.
How it differs from Ultralytics YOLOv8
The obvious comparison is Ultralytics YOLOv8, which is also anchor-free and also targets edge hardware. The difference is in where each project puts its effort. Ultralytics ships a pip-installable package with a stable Python and CLI surface, a documented training API, and its own export command covering ONNX, TensorRT, OpenVINO and other formats. EdgeYOLO ships a source tree with export scripts, int8 calibration code and hand-written C++ inference samples for specific chips, and it distributes weights as release downloads rather than through a package index.
That trade shows up in day-to-day use. With Ultralytics you get a supported interface and you accept whatever export coverage the package provides at that version. With EdgeYOLO you get sample code that already speaks to RKNN or MNN, and you accept that upgrading means reading the changelog and possibly switching branches, as the deployment move in August 2025 demonstrates. Neither is strictly better; they optimise for different failure modes. EdgeYOLO optimises for the last mile onto a specific board. Ultralytics optimises for not having to think about the last mile until later.
Maintenance, licence and what to check before you commit
The repository is not archived and the last push recorded is April 2026, with releases in August 2025, December 2024 and December 2023. The cadence is irregular but the project is alive. The licence is Apache-2.0, which permits commercial use and modification and includes a patent grant; it also requires that you preserve the licence and notice files and state significant changes. That is a summary of the licence text, not legal advice, and the arXiv paper may carry its own terms separate from the code.
Upgrade cost is the practical concern. The deployment tooling moved from main to a separate branch, so an upgrade can mean more than pulling new commits. The torch2trt dependency is installed from source (python setup.py install) and the README notes a compatibility issue with TensorRT 7.x exports, so a TensorRT upgrade is a real risk to your build. The docker image is 14.3 GB and hosted on Baidu Netdisk, which is slow or unavailable from some networks.
Before adopting, verify three things: that the C++ sample for your board exists on the branch you are cloning, that torch2trt builds against your installed TensorRT version, and that the export path you need (RKNN, MNN, Ascend .om, TensorRT int8) is the one that has been maintained most recently. The Ascend path in particular has not been mentioned in the changelog since March 2024.
Editorial conclusion
Adopt EdgeYOLO if you are targeting an RK3588, an Ascend 310, a Jetson or an MNN runtime and you want the export scripts, the int8 calibration code and the C++ samples in the same tree as the training code. Do not adopt it if you need instance segmentation or pose estimation today, or if a maintained pip package with a stable API matters more than platform coverage. Before committing, verify that torch2trt still builds against your TensorRT version (the README warns about 7.x), confirm your board appears in the cpp directory you intend to use, and check whether your target platform is on main or on the deployment branch, since the multi-platform tooling moved there in August 2025.
Community notes