YORU is growing into a family of programs. YORU itself detects animal behaviours. Sister applications such as YORU Tracker build on YORU's detectors for work of their own, and trigger plugins act on what YORU detects while an experiment runs. This page shows how the parts fit together. New parts are added to it as they appear.
You launch each application on its own. Underneath, they share one Python package, yoru.
A sister application uses only the names in YORU's external API, and YORU never depends on a sister application,
so YORU starts, runs and passes its tests without any of them installed.
Detects animal behaviours as objects — in recorded videos and in real time, with closed-loop control of hardware.
python -m yoru
Gives every animal YORU detects a persistent ID, draws its trajectory, and exports per-animal tracks.
python -m yoru_tracker
More sister applications are planned. Each will be built on the same external API, and will appear on this page.
yoru package · external API
✕ One way only: nothing in yoru imports a sister application.
yoru.libs.plugins
Load any model YORU can load.
yoru.libs.detector_base
One detection, and the columns of YORU's CSV files.
yoru.libs.obb
Corners, conversions, point-in-box.
yoru.libs.camera
A camera opened the way Real-time Process opens it.
yoru.gui_base · yoru.gui_layout · yoru.libs.gui_error
Theme, window session, error pop-ups.
yoru.libs.user_paths
~/.yoru/ and the shared log folder.
used by YORU Tracker
best.pt
<video>.csv
*_detect.csv
*_tracks.csv
*_tracks.json
Logs of all of them: ~/.yoru/logs/
The columns are the steps of an experiment, and the rows are the systems. When one row writes a file and another row reads it, the file is a hand-off between them. Point at a file name to see where it comes from and where it goes.
best.pt stands for any trained model YORU can load (.pt, .pth or .onnx).
<video>.csv is the result file of Video Analysis, and *_detect.csv is the file that Real-time Process records.
Each part of the family is one of three kinds. The kind decides where its code lives, how it runs, and how it talks to YORU.
The YORU application and the yoru package that every other part is built on.
A Python file that YORU's Real-time Process loads, to act on what YORU detects while an experiment runs.
A separate program with its own repository, window and command, built on YORU's external API.
Sister applications depend on YORU. YORU never imports one, and its windows contain nothing that belongs to one.
A sister application builds its own windows from YORU's GUI primitives. It does not subclass or copy YORU's screens.
Changing one of its names breaks every sister application. Such a change needs a new major version of YORU, or a deprecation period. YORU's tests pin every name.
Each program writes its own log file into YORU's log folder, so a problem report needs only one folder.
Ask these questions in order. The first yes decides.
Is it about which animal is which: identities, trajectories, or state carried across many frames?
yes YORU Tracker
Does it act on a detection during an experiment, for example by switching hardware or showing a stimulus?
yes A trigger plugin
Does YORU need it to detect behaviours or run closed-loop experiments?
yes YORU
Is it a general building block (a detector, an oriented-box, camera or GUI utility) that more than one application needs?
yes YORU's external API
Is it optional, expensive or model-heavy, with a workflow of its own?
yes A sister application
A feature never goes into YORU only because a sister application could use it there. YORU keeps general, stable building blocks. Tracking logic, identity logic and tracking screens stay in YORU Tracker.