RTM is a Seoul-based industrial AI company. Its vision unit builds AI-powered safety monitoring for manufacturing sites: cameras already mounted on the factory floor are watched around the clock by Ultralytics YOLO26 models that detect people, falls, hazard-zone intrusions, and fire or smoke, running on whatever PC the customer already has, from integrated graphics up to a discrete GPU.
Watching cameras that nobody is watching#
Industrial accidents tend to happen in the gap nobody is covering. Factories already have cameras on every line, but no one can watch every feed, at all times. RTM built a system to do this continuously: each camera channel runs two Ultralytics YOLO26 models, one trained for person detection and one for fire and smoke, feeding a deterministic event layer that raises alarms for worker falls and hazard-zone intrusions.
Over the past six months, RTM's industrial safety AI solution has been deployed 24/7 or is under on-site evaluation at 21 manufacturing companies spanning steel, battery, chemical and plastics, food, and robotics manufacturing. Connected to existing CCTV, the system detects when a worker enters a hazardous zone or falls, and triggers alerts through internal systems or, via PLC integration, directly controls connected factory equipment.
Fig 1. RTM Fall detection live feed leveraging Ultralytics YOLO. (Image source RTM)
Solving for hardware nobody wants to buy#
Safety monitoring competes with the option of installing nothing. If a system requires new server hardware before it can watch a single camera, the evaluation often stops before it starts. The status quo for manufacturers has been a choice between expensive dedicated hardware and no automated monitoring at all.
RTM set out to remove that trade-off: one deployment that runs on whatever PC is already sitting in the control room, from Intel integrated graphics through an NVIDIA RTX 3090, with no separate build per site.
To get there, RTM exports both YOLO26 models to ONNX at a static shape and runs them through ONNX Runtime across five execution providers: TensorRT, CUDA, OpenVINO, DirectML, and CPU. At startup, the inference library detects the installed GPU vendor and automatically selects the right provider chain, so the same 36 MB file per model runs unmodified whether the target machine has no discrete GPU at all or a high-end card. There is no Python or PyTorch dependency in the deployed application and no per-vendor release track to maintain.
YOLO26's end-to-end detection head made that single-artifact approach practical: because the model outputs final detections directly, RTM's C++ inference layer only needs a confidence threshold and a letterbox inverse transform, with no NMS to reimplement and no parity gap to debug between the Python training path and the C++ deployment path, a class of bug that typically appears whenever a detector crosses language boundaries.
What a GPU buys, measured#
RTM benchmarked both YOLO26-small models (person and fire/smoke) at two input resolutions on an NVIDIA RTX 3090 (ONNX Runtime 1.26.0, CUDA execution provider, FP32, batch 1, forward pass only). At 640×640, the person model runs at 4.20 ms per frame and the fire/smoke model at 4.34 ms; at 1280×1280, both climb to roughly 12.5 ms, with GPU memory rising from 406 MB to 1,302 MB. That makes 640×640 about 2.9× cheaper per frame and 3.2× lighter on memory, while the larger input improves detection of small, distant objects. RTM ships 640×640 as the default and keeps the 1280×1280 export available for sites that have GPU headroom to spend on detection margin instead of channel count.
Moving from CUDA at FP32 to TensorRT at FP16 cut the combined per-frame cost for both models from 8.68 ms to 6.26 ms, a 28% reduction, worth roughly 39.9 FPS across four channels on a single GPU instead of 28.8 FPS. RTM verified that the FP16 conversion cost nothing in accuracy before shipping it: recall was unchanged across every object-size bucket and at the event level for both fire and smoke. In the deployed application, a recommended-spec machine (a 16-core-class Intel Core i7 or better, 32GB RAM, RTX 5060 8GB or higher) sustains 6 concurrent channels, while a low-tier machine with only integrated graphics still sustains 1, against a product ceiling of 10 channels per box.
Why leverage Ultralytics YOLO26?#
RTM trains its person detector and its fire/smoke detector through the same Ultralytics training codebase, and the two share 352 lines of code with no domain-specific branching at all. The only thing that changes between a detector watching for people and one watching for fire is a configuration file: input size, epochs, learning rate, and dataset composition. That's a direct product of how Ultralytics YOLO is built. A single, consistent architecture and training API across detection tasks means a new detection domain is a config change rather than a new pipeline, which is what let a small engineering team stand up two production-grade models without maintaining two codebases.
That same consistency made the move to YOLO26 itself low-risk. RTM adopted YOLO26 four days into the project, in May 2026, and the migration required zero lines of existing training code to be changed, only a different checkpoint. Because Ultralytics keeps the training interface stable across model generations, upgrading to the newest architecture didn't mean rewriting a pipeline RTM had already built and tested.
"Even on the same dataset, input size and augmentation change how well the model performs. With Ultralytics all of that lives in one config file, so we change a few values, run several variations side by side, and take the best one. We never touch code for any of it, so lining up ten runs is about as much work as running one." - AI Engineer, RTM
That stability paid off in accuracy, aswell. Consolidating a five-stage sequential training curriculum into a single joint run improved validation mAP50 from 0.672 to 0.689 at an unchanged operating threshold, a gain RTM could bank simply by retraining on the same YOLO26 architecture rather than redesigning the model. And because YOLO26 exports cleanly to a fixed-shape ONNX artifact with detection thresholds shipped as a sidecar file rather than compiled into the application, the field absorbed that accuracy gain by swapping one ONNX file, with no changes to the host application at all. That's what lets a small engineering team push model updates to every site without a coordinated release, and it's a direct consequence of building on YOLO26 rather than a bespoke architecture.
What sits above detection#
RTM's alarms aren't raw detections: a person in frame isn't an event, but a person who has fallen and stayed down is. A deterministic event layer sits above the two YOLO26 models, combining tracking, posture state, zone membership, and a sliding-window vote before any alarm fires. Keeping that logic separate from the model is what lets one person detector serve every site, despite camera height, angle, and lighting varying enormously from factory to factory. It also means new safety behaviors can reuse existing detections: RTM is now building PPE compliance monitoring on the same person-detection output, with no new model and no new hardware required on GPU-equipped sites.
The overall impact#
The impact shows up most clearly with RTM's collaborative-robot integration customers, who supply and install cobots across factories and had long dealt with workers colliding with robots despite physical or laser safety fencing. With RTM's system, hazard-zone intrusion is detected and immediately triggers a PLC-connected stop on the robot with no delay, and these integrators have since adopted it as their default safety device in place of physical fencing.
A steel manufacturing customer reported that Ultralytics YOLO’s ability to tailor detection scenarios to different sites let them reduce more than 100 safety-monitoring staff who previously patrolled the floor. More broadly, manufacturers describe RTM's solution as the easiest to install and most cost-effective among the safety monitoring options they evaluated, with danger-zone, fall, and fire/smoke detection covering what they need most.
Scaling further on the same models#
RTM's next step is PPE compliance detection, built entirely on its existing person-detection output. No new model to train, and on sites with GPU headroom, no new hardware to install. As rollout continues across additional manufacturing sites and hardware tiers, the same single ONNX export per model keeps carrying the load, from the lowest-spec integrated-graphics PC to the highest-end GPU server on the floor.
Interested in building Vision AI solutions of your own? Explore our Ultralytics YOLO models, see how they are used across industries, including computer vision in manufacturing, and check out licensing options to get started.
