[MicroDiP 1]

Приветствую. Понимаю, что слишком длинные вопросы чаще всего игнорируются. Поэтому постараюсь в максимально сжатой и простой форме описать суть вопроса.

Есть плата, контролирующая 12 оптических сеносоров измерения расстояния до объекта (VL53L1X, ToF-сенсор от ST, на I2C): детектирование проходивших или останавливающихся людей возле стола/стойки с товаром. Помимо дистанции сенсор предоставляет информацию о качестве отражённого сигнала (Range Status). В зависимости от положения объекта в луче сенсора, дальности до него, цвета его поверхности и структуры поверхности (например, глянцевый или матовый) уровень отражённого сигнала может меняться от устойчивого до слабого. Всего библиотека предоставляет 5 значений для этого параметра:

• 0 - нет ошибки
• 1 - низкое соотношение сигнал/шум
• 2 - отражённый сигнал слишком слабый. Может означать как расстояние до объекта слишком далёкое (больше 4 метров - это максимальное рабочее расстояние сенсора), так и то, что поверхность объекта не достаточно отражает свет. Или объект слишком маленький.
• 4 - объект отсутствует
• 7 - Radar Aliasing (наложение локационных сигналов). Если объект имеет сильно отражающую поверхность и располагается на расстоянии большем, чем рабочее расстояние сенсора.

В реальных условиях сенсор возвращает либо 0, либо 2, либо 4. По крайней мере 1 и 7 я ниразу не получал в разных условиях.

Теперь собственно суть вопроса. Если объект находится в пределах рабочего расстояния (< 4m, скажем на расстоянии 1-2м), но располагается на границе луча, сенсор постоянно шлёт разные репорты о статусе диапазона. Иногда 2, иногда 0 (стабильный сигнал), иногда 4. Соответственно и значения расстояния  всегда разные и при таком положении объекта получаю случайные репорты о наличии объекта в зоне видимости сенсора. Но значения 2 и 4 могут также быть получены при наличии объектов в самом луче, а не на его границе: если объект маленький или поверхность матовая серая/чёрная. Кроме того, сенсор имеет свойство устреднять расстояние, если в луче находится больше одного объекта. Например, сенсор направлен на стену, расстояние до которой 2м. Если я начну сбоку на рясстоянии 1м медленно вводить другой объект, то на границе луча и длаьше при продвижении объекта в глубь луча, сенсор начнёт слать репорты о расстоянии 1.9, 1.8, 1.5 и т.д до того момента, пока объект не появится в зоне устойчивого отражения. И тогда сенсор отчитается об 1м.

Попробовал динамически уменьшать угол луча при получении нестабильных репортов (уменьшение активной матрицы, ROI (Region Of Interest) с 16х16 пикселей до 4х4). В целом концепция работает неплохо, но для детектирования этой самой нестабильности нужно какое-то время на сбор данных (репортов) и принятия решения. А проблема заключается в том, что клиент категорически против всяких задержек. Ему нужно получать результат о нахождении человека в зоне сенсора практически мгновенно и он не хочет терять полезную информацию. Т.е я не могу использовать никакие фильтры. В тоже самое время он не согласен и на ложные репорты. По крайней мере в больших количествах. Допустимое значение ложных сработок до 3-5% от общего количества репортов. Минимальное время измерения сенсора (Time Budget) 100мс. 

Мне почему-то кажется, что задача без применения фильтров практически не реализуемая. Даже с фильтрами "дребезга" около 3 сек я находил такое положение объектов в луче сенсора, когда сенсор слал переменные репорты, выходящие за пределы филтра дребезга и, соответственно, я получал ложные сработки. При этом в целом результат был довольно стабильный. Но опять же, на такие задержки клиент категорически не согласен.

Использую Ultra Light Driver (ULD-библиотеку). Микроконтроллер STM32F030. Буду рад любым идеям. Или может кто-то боролся уже с подобными задачами и они не являются комерческой тайной.

Заранее благодарю.

[iamnot 0]

12 датчиков на один объект или каждая зона один датчик?
Если 12 датчиков на 1 объект, то усреднять ничего и не надо, нужно просто анализировать что несколько датчиков видят объект

 

[MicroDiP 1]

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

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

[Aner 1]

А чуть дороже но с камерой не устраивает? Пару лет как применять начали такое.

[MicroDiP 1]

Какие именно решения с камерой вы имеете ввиду? Мы прорабатывали этот вопрос: это либо одноплатный компьютер, либо Джетсан от Нвидии. И главный вопрос: какое максимальное количество камер (потоков) может поддерживать один компьютер (библиотека детектирования объектов) с приемлемым откликом. Потому что если это 1-2 камеры, то получается что, например, для 100 различных зон нужно покупать как минмум 50 компьютеров. При цене одного компа в районе 100-150$ (а Джетсан в районе 300$), это получается дороговато.

[Aner 1]

А кендрай, рокчип, кхадос разве не устроят?

[MicroDiP 1]

Ну они медленные достаточно.. Сейчас поговорил с инженером с нашим, он делает другой проект как раз на Джетсане. Подключена одна камера. Скорость обработки 15 кдаров/сек. При этом детектирует довольно шустро. Задержка еле заметна. На вскидку может пару десятков мс.  Но про несколько камер пока неясно. Нужно экспериментировать. Я просто к тому, что если Джетсан со своими CUDA-ядрами выдаёт заметную задержку, то Рокчипы и иже с ними будет подавно тормозить... И тем более с несколькими камерами. Но в любом случае, спасибо за идеи.

[blackfin 14]

FYI: ADI EagleEye

[Plain 165]

3 часа назад, blackfin сказал:

FYI: ADI EagleEye

У автора жучок под прилавком — ему нужно что-то, умеющее считать ноги.

[Aner 1]

6 часов назад, MicroDiP сказал:

Ну они медленные достаточно.. Сейчас поговорил с инженером с нашим, он делает другой проект как раз на Джетсане. Подключена одна камера. Скорость обработки 15 кдаров/сек. При этом детектирует довольно шустро. Задержка еле заметна. На вскидку может пару десятков мс.  Но про несколько камер пока неясно. Нужно экспериментировать. Я просто к тому, что если Джетсан со своими CUDA-ядрами выдаёт заметную задержку, то Рокчипы и иже с ними будет подавно тормозить... И тем более с несколькими камерами. Но в любом случае, спасибо за идеи.

Джетсан со своими CUDA-ядрами заточен под другие задачи. Поэтому там все медленно. У тех вся обработка в реалтайме с сенсора, читайте доки, примеры тоже есть, к тому же нейро проц задействован. Еще можете взглянуть на хайсиликон, но это вчерашний день, хотя вас может устроить. В правильной формулировке задания половина ответа, думается вам нужно озадачится формулировкой задания для того вашего решения через видео обработку.