fenrir

Во-первых, оформи код, нечитаемо. Кнопка </> в помощь.
Во-вторых, matchTemplate(), насколько я знаю, не-инвариантна к поворотам и масштабу. Иными словами, поворот или изменение размера целевого объекта сломают сопоставление.
В-третьих, на показанном кадре более одного экземпляра целевого объекта. Так предполагается или нет? Если предполагается, сколько экземпляров ожидается? Потому что разница очень большая с точки зрения методики.

Варианта тут три.
1. пытаться обучать под задачу нейронку. А лучше дообучить существующую, скажем, YOLOv5. Но тебе потребуется минимум несколько сотен размеченных изображений объекта в разных комбинациях, плюс в 2-3 раза больше похожих изображений без целевого объекта. Готовить такую базу будет утомительно, да и само обучение требует понимания что ты делаешь.
2. попробовать зафиксировать угол поворота или масштаб (т.е. допустить, что он всегда одинаков). Тогда другой параметр можно будет подбирать. Например, мы фиксируем масштаб и делаем 16 изображений объекта в разных поворотах, а потом поочерёдно ищем каждый вариант на кадре. Потом анализируем силу откликов - сколько их, насколько они сильные и т.д. Скорее всего, будет медленно
3. взять за основу поиск по локальным особенностям. Он справляется с масштабом и поворотом, но не справляется с несколькими экземплярами объекта. Это можно забороть, если использовать скользящее окно. Иными словами, находим на кадре узнаваемые точки - локальные особенности (желательно достаточно много и достаточно плотно), используя алгоритмы вроде ORB или SIFT. Затем выбираем те из них, которые попадают в прямоугольную рамку-окно. Затем сверяем эти особенности с особенностями объекта, используя RANSAC или подобный метод. Если получилось хороше совпадение - значит, в этой рамке есть объект или значительная его часть, и мы можем оценить его позицию в кадре в целом. Повторяем процесс, сдвигая рамку, пока оно не "обойдёт" всё изображение. Тоже может быть небыстро, так как нам требуется неоднократный поиск по картинке.

В хроме запрещен JavaScript или какое-то расширение его режет. Проверка на двусторонний пинг осуществляется примерно так: вы заходите на 2ip с адреса vps, 1) 2ip пингует адрес vps и засекает время ответа. 2) код страницы 2ip в вашем браузере на домашнем компе дергает пустую страницу с сайта 2ip. Пишут, что с помощью XMLHttpRequest, но я бы на это не полагался. Время ответа опять засекается. Так как ваш домашний комп объективно дальше от сервера 2ip, чем vps из-за туннеля ( t(browser -> vps -> 2ip) больше, чем t(vps -> 2ip)), вы палитесь на этом тесте. Глобально можно просто дропать ICMP Echo Request на vps, чтобы 2ip не мог выполнить п. 1)

Не скажу ничего про алгоритм и корректность замеров, но время t01 и t02 ты точно измеряешь неправильно

subsec_nanos
Returns the fractional part of this Duration, in nanoseconds.

This method does not return the length of the duration when represented by nanoseconds. The returned number always represents a fractional portion of a second (i.e., it is less than one billion).
https://doc.rust-lang.org/std/time/struct.Duration...

У структуры Duration есть операторы для сравнения, так что тебе не обязательно знать конкретное число, пока ты не выводишь его в консоль

let mut t01 = Duration::MIN;
let mut t02 = Duration::MAX;
if duration> t01 {
      t01 = duration; // здесь
   }
   if duration< t02 {
      t02 = duration; // и здесь
   }

UPD:

Комп 6 ядер 12 потоков ничем не нагружен. Если не накосячил с кодом, а так
захватывается периодически ресурс потоков компа, то как такое решить
и получать расхождение в пределах 20%?

1. Такой разброс, как у тебя показан - это норма. Нужно смотреть не на минимум/максимум, а на распределение (в комментах скинул график - там тоже минимум и максимум сильно различаются, но прогонов с таким временем мало)
2. Я не увидел в вопросе описания того, как происходит запуск. Хотябы в --release компилировал?
3. У тебя данные вполне статичные, так что компилятор при желании мог очень много наоптимизировать, что даст тебе некорректные результаты, но на распределение это влиять не должно.

http и https можно поднимать на любом порту, просто его придется явно указывать в отличие от дефолтных. Самое просто это делать через проксирование в нормальные веб-серверы, nginx и подобные.

Я бы вообще изобрёл велосипед, если честно.
У тебя есть список или база активных (неслучившихся) событий. Пусть это будет пара ID-метка времени, остальная инфа нам без надобности.
При запуске бота выбираем из списка ближайшее событие, и вычисляем время ожидания (с небольшим запасом) и спим в корутине. В случае, если ожидание прервано раньше - повторяем то же самое, чтобы либо "доспать", либо переключиться на ожидание более близкого события.
Если же ожидание закончилось успешно, обрабатываем событие и снова повторяем поиск ближайшего события.
Если список событий изменился, прерываем текущее ожидание, чтобы корутина ожидания могла адаптироваться к изменениям.

Кода - строк на пятьдесят, не больше, и выносится в отдельный класс на ура. Как мне кажется, если бот не супер-нагружен (в том смысл, что список хранимых событий изменяется не каждую минуту, и событтия тоже срабатывают не так часто), то этого будет вполне достаточно.
А когда он будет так нагружен - проще будет раз в минуту выбирать то, что должно сработать сейчас.

# install poetry - respects $POETRY_VERSION & $POETRY_HOME
RUN curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python

# copy project requirement files here to ensure they will be cached.
WORKDIR $PYSETUP_PATH
COPY poetry.lock pyproject.toml ./

RUN poetry install --no-dev

Подробнее.