Стенд и оборудование для испытаний и измерений VIII

GOGI> Все, кажется я закончил свою версию графикочитающей программы.

Мои поздравления! Можно попытать релиз?


GOGI> ... накладывает коллаж из видео фоном к графику, для визульного контроля правильности работы.

Да, это правильно. Я думал озадачить товарища такой фишечкой, но решил отложить на потом, не валить всё в кучу. Он всё-таки хочет, чтобы прога считала площадь на месте, в дополнение к экспорту в Эксель. Прислал вариант - сильные глюки, я отправил его на доработку, вместе со списком замечаний. После второй попытки попробую убедить его отказаться от этой затеи. Мне она тоже кажется излишеством.


GOGI> Работает с обрезанным видео с горизонтальной или вертикальной шкалой.

И коллаж из видео сама делает? Хотелось бы пощупать вживую.

Как у тебя организована калибровка?

Идёт отработка технологии препарирования указок - превращения их из предмета детских забав в точный измерительный инструмент. Испытывал определённые трудности; но сейчас, похоже, бОльшая их часть уже позади.

ГОГИ, а ты ДВА пятна распознаёшь? Реперное и измерительное?

GOGI> Завтра если доберусь до интернета, отправлю.
GOGI> Калибровку я не делал. Моя программа извлекает график положения луча из видео, больше ничего.

А как ты в Экселе посчитаешь импульс, если твоя программа только извлекает график, и больше ничего? Если не от чего отталкиваться, нет масштаба?


> ... определение частоты кадров ...

Это та же калибровка, только по оси "Х". А нам калибровка нужна по двум осям - по нагрузке и по времени.


GOGI> ... изчезнет последняя неопределенность: сейчас программа не знает, где начало шкалы ...

Это не последняя неопределённость. Я не понял, как инверсия позволит определить нуль шкалы (последняя совпадающая координата "Y" перед расхождением кривых?), но имхо программе с нулём определиться и так легко - показал ей ВРУЧНУЮ кадр с нулевым пятном, вот и готова тебе нулевая координата "Y".

А вот ЗНАЧЕНИЕ МАКСИМУМА "Y" так просто проге ты не покажешь, потому как для этого калибровочный кадр надо иметь - кадр с пятном, которое смещено калибровочным ГРУЗОМ. Никакой Эксель тебе эту координату не рассчитает; по крайней мере из тех данных, что есть у тебя на видео.


GOGI> Второй луч добавить не сложно, в общем это даже чем-то полезно будет ...

Да я вообще, гхм, РАССЧИТЫВАЮ на то, что это будет как минимум НЕ ВРЕДНЫМ, учитывая полную механическую незалежность датчика от стенда. Без реперного пятна на шкале это будет не оптический измерительный стенд, а надёжное и простое устройство типа шнурка, натёртого мелом; примерно такой же точности.

Non-conformist> А как ты в Экселе посчитаешь импульс,
Импульс чего? Пятна лазерного луча? Программа по видео находит функцию положения лазерного луча от времени в пикселях. Тут нет понятия импульс. расчетный лист Экселя, который по табличным данным тяги от времени считает характеристики двигателя это совсем другое.

Non-conformist> Это не последняя неопределённость. Я не понял, как инверсия позволит определить нуль шкалы
Она никак. Программа не знает, где у шкалы ноль а где максимум. Поэтому график может построить перевернутый. Инверсия делает его нормальным. Неправильность графика видно визуально.
Non-conformist> Да я вообще, гхм, РАССЧИТЫВАЮ на то, что это будет как минимум НЕ ВРЕДНЫМ
Я рассуждаю только с точки зрения правильного построения графика положения пятна. Физический смысл пока не интересен.

GOGI> расчетный лист Экселя, который по табличным данным тяги от времени считает характеристики двигателя это совсем другое.

Откуда Эксель получит данные тяги, если у тебя есть только голое положение пятна в пикселах относительно нуля? Как ты узнаешь, сколько ньютон приходится на один пиксел?


GOGI> Физический смысл пока не интересен.

Такое разбиение задачи мне в данный момент представляется искусственным. Алгоритм нахождения геометрического центра пятна с размытыми границами - это одно, но игнорирование физического смысла конечной задачи на том этапе, где ты сейчас находишься... Хоть я и не программист, но тут я уже совсем логику потерял.

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

Попутно второй луч выдаёт КОЛИЧЕСТВЕННУЮ информацию о качестве крепления стенда на грунте, т.е. о классе точности каждого конкретного прожига. Моноблочный стенд такой информации дать не может.

Non-conformist> Такое разбиение задачи мне в данный момент представляется искусственным. Алгоритм нахождения геометрического центра пятна с размытыми границами - это одно, но игнорирование физического смысла конечной задачи на том этапе, где ты сейчас находишься... Хоть я и не программист, но тут я уже совсем логику потерял.
Потому что это совершенно не связанные задачи. Нахождение координат пятна, или расстояния между двух пятен это отдельная задача анализа изображения, нахождение графика тяги совсем другая нахождения правильной логики и интерфейса взаимодействия с пользователем. Я не говорю что не собираюсь её решать, буду, но только после того как к первому этапу мне будет нечего добавить.

Испытать альфу смогу только в понедельник. Этот magic используется ВМЕСТО Virtual Dub, или это уже ЧЕТВЁРТАЯ программа в пакете, который необходим для работы со стендом?



***

Каждая дельта "Y" реперного пятна должна ВЫЧИТАТЬСЯ программой из каждой координаты "Y" пятна измерительного. В этом случае получатся данные, как если бы это был традиционный моноблочный стенд.

Величина дельты "Y" реперного пятна будет показывать, сколько процентов тяги мотора "утекло в землю" помимо УЭ, т.е. сколько тяги было израсходовано на микроподвижки основания стенда по вертикали (вдавливание его в землю - если стенд вертикальный).

Использовать вертикальное паразитное перемещение основания стенда относительно грунта в расчётах суммарного импульса (т.е. суммировать это паразитное перемещение с показаниями УЭ) имхо не представляется возможным ввиду нестабильности механических свойств грунта, как "паразитного УЭ".

Non-conformist> Испытать альфу смогу только в понедельник. Этот magic используется ВМЕСТО Virtual Dub, или это уже ЧЕТВЁРТАЯ программа в пакете, который необходим для работы со стендом?
Это третья. видео захватывается и обрезается дубом, открывается в расчетном листе excel. Программы из набора imagemagick запускаются автоматически где нужно. Пользователь с ними не взаимодействует.
Non-conformist> Каждая дельта "Y" реперного пятна должна ВЫЧИТАТЬСЯ программой из каждой координаты "Y" пятна измерительного.
А что так длинно? Измеряем расстояния между пятнами. Все.

GOGI> А что так длинно? Измеряем расстояния между пятнами.

Тогда не будет видно максимальной дельты репера, а хочется в чём-то переплюнуть моноблочник. Моноблочный стенд не даёт количественной информациия о том, насколько качественно (жёстко) он закреплён на грунте. Можно только на видео наблюдать, что "вроде дёрнулся". А двухкомпонентный оптический стенд позволяет просто и естественно оценить этот момент. Это ведь практически тот же лазерный нивелир... С угломерным акцентом.

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

Размах шкалы 120 мм
Диаметр пятна 3 мм

Для ВИЗУАЛЬНОГО определения центра пятна я принимал дискретность (чётко фиксируемое глазом расстояние между двумя соседними положениями пятна) в 1/3 диаметра пятна; т.е. дискретность получалась чуть меньше одного процента.

Какую разрешающую способность обеспечивает ПРОГРАММНЫЙ анализ картинки?

Non-conformist>Моноблочный стенд не даёт количественной информациия о том, насколько качественно (жёстко) он закреплён на грунте.
А к чему эта информация? Какой в ней практический смысл?

Non-conformist> Андрей, для поднятия боевого духа - заяви, какой класс точности получается у комплекса?
Я не знаю Мне б видео с оригинальным разрешением и частотой кадров.
Тот алгоритм который программа применяет сейчас отлично работает на круглом пятне. То есть в статике. Тут я бы 1-2 пикселя разрешающей способности дал. В динамике, когда пятно представляет собой полоску, он может посчитать центром её любую точку внутри неё, с вероятностью уменьшающейся от начала полосы к концу.
Более сложные алгоритмы нахождения пятна имеет смысл пробовать только с более качественным видео.
Если шкала не будет отдавать краснотой, как на том видео что у меня сейчас получится другой весьма быстрый и простой способ, дающий большую точность в динамике.

Non-conformist>>Моноблочный стенд не даёт количественной информациия о том, насколько качественно (жёстко) он закреплён на грунте.
GOGI> А к чему эта информация? Какой в ней практический смысл?

Практический смысл этой информации состоит в том, чтобы иметь представление о достоверности данных конкретного прожига. Если подвижка стенда относительно грунта (камеры) превысила бы, к примеру, процентов пять от максимальной тяги, зафиксированной УЭ, то я бы признал прожиг недействительным.

Подвижки станины будут имхо происходить главным образом в момент резкого выхода мотора на режим, искажая динамику профиля тяги (в сторону ухудшения).

GOGI> Тут я бы 1-2 пикселя разрешающей способности дал.

Сколько это будет в миллиметрах? Для стандартного разрешения DV?


GOGI> В динамике, когда пятно представляет собой полоску, он может посчитать центром её любую точку внутри неё, с вероятностью уменьшающейся от начала полосы к концу.

Ну, это никуда не годится. Алгоритм должен уверенно искать СЕРЕДИНУ трека (середину слабосветящегося отрезка, в виде которого предстаёт размазанное динамикой пятно).

Пусть алгоритм будет считать триста картинок не за десять секунд, а за минуту, но находить середины тусклых отрезков он просто обязан.


GOGI> Более сложные алгоритмы нахождения пятна имеет смысл пробовать только с более качественным видео.

БУДЕТ качественное видео, никуда оно не денется. И на шкалах разного цвета, и с разными условиями освещённости. Терпение!

Non-conformist> Ну, это никуда не годится. Алгоритм должен уверенно искать СЕРЕДИНУ трека.
Ты думаешь алгоритм программы товарища делает это?
Судя по его вопросам он ищет просто самую яркую точку.
Впрочем, когда я вижу как моя программа рисует график тяги точно поверх нарисованного на коллаже, особого смысла в улучшениях я не вижу. Все равно точность в динамике измерить и оценить нечем

Non-conformist>> Ну, это никуда не годится. Алгоритм должен уверенно искать СЕРЕДИНУ трека.
GOGI> Ты думаешь алгоритм программы товарища делает это?

Буду требовать, чтобы было именно так. В смысле - высказывать настойчивые пожелания.


GOGI> Судя по его вопросам он ищет просто самую яркую точку.

Я так понимаю, что это пока пристрелка. За которой последует огонь на поражение. Ты ему писал?


GOGI> Все равно точность в динамике измерить и оценить нечем.

"Нет предела совершенству", но есть плавные, однако явно ощущаемые изгибы "диаграммы совершенствования". Довести динамическую точность указочного стенда до этого почти последнего изгиба перед практически горизонтальной полкой "диаграммы совершенства" - наша сверхзадача.

А проверить динамику как раз есть чем - ничто не мешает (теоретически) снабдить УЭ указочного стенда маленьким магнитиком, а на станине укрепить датчик Холла. И получится самое что ни на есть измерение - прямое сравнение двух методов регистрации одного профиля тяги.

GOGI> Тут я бы 1-2 пикселя разрешающей способности дал.

Сколько это будет в миллиметрах? Для стандартного разрешения DV?

Non-conformist> Сколько это будет в миллиметрах? Для стандартного разрешения DV?
длина шкалы / разрешение (при условии что шкала на весь экран)
Non-conformist> Пусть алгоритм будет считать триста картинок не за десять секунд, а за минуту, но находить середины тусклых отрезков он просто обязан.
Проблема не в том, что он долго будет считать, а в том, что нужно написать программу которую он будет долго считать. Глаз легко выделяет пятно на любом фоне, но в программе для этого придется городить алгоритм распознования образов что для меня явно непосильная задача.
Поэтому приходится работать с более формализованными вещами: поканальными яркостями каждой отдельной точки. А для этого нужно одно простое условие: не красная шкала. Самый простой способ добиться этого для солнечного освещения: сделать шкалу серой и правильно выставить баланс белого, например выбрать освещение лампами накаливания в предустановках. Тогда выделить пятно можно будет по простому условию: яркость по красному больше яркости по зеленому и голубому.

GOGI> ... Тогда выделить пятно можно будет по простому условию: яркость по красному больше яркости по зеленому и голубому.

Попробуй сделать так:
Посчитай среднее по всему полю , и найди максимум по яркости по всем или только по красному каналу. Для данного алгоритма единственное требование - лазер должен быть лазером

Если не получается "всё и сразу", тогда прога должна предоставлять возможность ручного редактирования размазанных точек: пусть алгоритм игнорирует эти вертикали, предоставляя "расстановку точек над ё" пользователю - ПОСЛЕ построения графика.

Для этого нужно иметь кнопку наблюдения построенного графика на фоне коллажа. Размазанных точек будет немного - для нормального профиля всего несколько штук, так что пользовательские качества от этого практически не пострадают. А там будет видно - может подтянется кто-то, кто сможет написать распознавание середины трека.