惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Threatpost
Recorded Future
Recorded Future
Microsoft Azure Blog
Microsoft Azure Blog
M
MIT News - Artificial intelligence
酷 壳 – CoolShell
酷 壳 – CoolShell
I
InfoQ
博客园 - 司徒正美
Stack Overflow Blog
Stack Overflow Blog
Simon Willison's Weblog
Simon Willison's Weblog
爱范儿
爱范儿
D
Darknet – Hacking Tools, Hacker News & Cyber Security
V
Visual Studio Blog
H
Help Net Security
博客园_首页
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
B
Blog RSS Feed
美团技术团队
G
GRAHAM CLULEY
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
Cyber Attacks, Cyber Crime and Cyber Security
腾讯CDC
G
Google Developers Blog
Cyberwarzone
Cyberwarzone
T
Tenable Blog
A
About on SuperTechFans
WordPress大学
WordPress大学
Engineering at Meta
Engineering at Meta
L
Lohrmann on Cybersecurity
C
Cisco Blogs
K
Kaspersky official blog
Recent Announcements
Recent Announcements
Vercel News
Vercel News
C
Cybersecurity and Infrastructure Security Agency CISA
有赞技术团队
有赞技术团队
P
Privacy & Cybersecurity Law Blog
Hugging Face - Blog
Hugging Face - Blog
S
Schneier on Security
Apple Machine Learning Research
Apple Machine Learning Research
Cloudbric
Cloudbric
Scott Helme
Scott Helme
Google Online Security Blog
Google Online Security Blog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
MyScale Blog
MyScale Blog
Cisco Talos Blog
Cisco Talos Blog
Attack and Defense Labs
Attack and Defense Labs
Google DeepMind News
Google DeepMind News
N
News and Events Feed by Topic
D
Docker
U
Unit 42
S
Security @ Cisco Blogs

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Smart Timber: измеряем лес смартфоном. Часть 2: Технические решения для полевых условий
compvisionsy · 2026-05-12 · via Все публикации подряд на Хабре

Уровень сложностиПростой

Время на прочтение10 мин

Охват и читатели19

Кейс

В первой части мы рассказали о пилоте и первых версиях системы Smart Timber для измерения и учета объемов древесины, внедрении продукта у клиента и переходе от технического наполнения к продуктовой составляющей решения. 

Сегодня в блоге ЛАНИТ мы подробно остановимся именно на технических решениях, которые сделали возможной работу системы в полевых условиях. 

Зачем нужен оффлайн-режим

Зачастую решения на базе машинного обучения (особенно сейчас — с расцветом трансформеров, VLM и LLM) строятся по принципу централизованной обработки данных: мобильное приложение делает снимок, отсылает его на высокопроизводительный сервер и за секунды получает ответ с результатом. Но на делянке в лесу или на сплаве часто нет мобильного интернета — это факт, с которым нам пришлось смириться сразу. Поэтому в архитектуру мы заложили работу мобильного приложения полностью оффлайн, а отправку данных на сервер реализовали через синхронизацию. При появлении связи приложение выгружает накопленные данные (снимки, разметку и расчёты) и обновляет справочники.

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

Как работает технология

Решение работает на базе компьютерного зрения и машинного обучения. В его основе — классический фотограмметрический метод, основанный на измерениях по фотографии с использованием эталонного предмета (его еще называют «метод масштабов»).

  1. Поскольку камера является угломерным инструментом, она позволяет сопоставить (например, через модель камеры и матрицы калибровки) каждому пикселю направление (луч) в пространстве.

2. Между лучами (т.е. между двумя интересующими нас точками) можно определить угол (α = atan(y_a/f)-atan(y_b/f)), но при этом для определения метрического размера видимого объекта (h1 или h2) нам не хватает расстояния до него (x1 или x2).

3. Чтобы определить масштаб, делаются следующие предположения:

a. все измеряемые точки лежат в одной плоскости (в среднем);

b. мы можем задать в этой плоскости объект известного размера, т.е. эталон: линейку или какой-нибудь еще известный предмет. Другие участники рынка пытались использовать треугольный знак аварийной остановки или номерной знак прицепа, но где-то просчитались — всего 1 см ошибки на метровом эталоне приводит к погрешности в 3% в объеме. Поэтому для достижения требуемой точности нам важно иметь эталон достаточно длинный (1 м — OK) и с точно определенными границами. А номерной знак ещё и не лежит в нужной плоскости.

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

В оригинальном методе масштабов делается еще одно важное допущение: плоскости сенсора камеры и бревен строго параллельны, что бывает трудно реализовать на практике — часто штабель имеет высоту 5-10 м (да, нельзя, но очень хочется), а если мы будем держать смартфон строго вертикально на высоте 1,5-1,7 м, почти половину кадра будет занимать земля и штабель просто не поместится в кадре. Поэтому мы скорректировали предположение: по-прежнему считаем, что торцы образуют вертикальную плоскость, а положение камеры относительно горизонта определяем по датчикам устройства (интегрируя их показания за пару секунд и проверяя стабильность). Это позволяет наклонять телефон как угодно.

4. Дальше нужна разметка изображения – вручную или автоматически обнаруживаются бревна. Торцы мы отлично детектируем автоматически, а бревна сбоку оператор размечает вручную – так проще и в среднем точнее. Описанным выше методом пиксельные размеры переводятся в метрические, то есть мы получаем диаметры (точнее, полуоси эллипса) всех бревен.

Поскольку мы ограничены только Edge-вычислениями, мы сразу задали себе планку: весь расчет не может занимать больше 30 секунд на типовом мобильном устройстве среднего диапазона. Это довольно сильно ограничило выбор архитектур детектора. В нескольких последних  поколениях мы используем легковесные архитектуры с нашими доработками, в сравнительных экспериментах участвовали и разные поколения YOLO, и модные сейчас реал-тайм трансформеры — прежде всего для того, чтобы понимать, какое качество достижимо на наших данных state-of-the-art моделями.

Первые испытания, клиенты и, как следствие, первые версии датасета включали в основном древесину с достаточно тонкой корой: ель, сосну, березу, и мы не задумывались о том, что вообще-то учет должен вестись «без коры». После поездки на один из крупнейших ЦБК в Братске мы поняли, почему это важно — толщина коры лиственницы может запросто достигать нескольких сантиметров. Пришлось значительно расширять разнообразие пород и переразмечать весь датасет, чтобы гарантировать обнаружение торцов именно внутри коры.

5. Дальнейшие шаги зависят от метода, а методы, в свою очередь, принципиально делятся на поштучные и групповые.

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

b. В групповых методах мы определяем геометрию пачки или штабеля как целого. После этого применяем так называемый коэффициент полнодревесности, чтобы перейти от складского объема (занимаемого штабелем) к плотному объему (т.е. объему собственно бревен).

Большинство методов определения плотного объема древесины являются стандартизованными (описанными в российских ГОСТ 32594-2013, ОСТ 13-43-79, белорусском СТБ 1667-2012) и принятыми при ручном замере. Мы реализуем все основные стандартные методы, а также со временем смогли добавить несколько своих, призванных повысить точность измерения.

Планшет, смартфон, защищенное устройство?

Изначально в разработке мы ориентировались на смартфоны, считая, что более мобильное устройство упростит работу, а качество камер и производительность большинства планшетов намного хуже, чем даже у недорогих смартфонов. Но практика показала, что планшеты намного удобнее и вообще большой экран — это хорошо. Особенно когда на улице -30С, и на тебе соответствующие перчатки.

Если вы работаете в таком климате, как в Питере зимой, то кажется, что вам нужен максимально защищенный планшет. Да, у таких моделей, как Samsung Galaxy Active Tab, есть несомненные достоинства — их можно ронять с метровой высоты на бетон, класть в снег на всю ночь, они поддерживают работу в перчатках. Но обратной стороной является цена таких планшетов, кратно превышающая стоимость бытовых моделей. При этом платишь ты в таком случае именно за защиту, а вот производительность остается средней. 

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

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

Большие штабели — как снять то, что не влезает в кадр?

Круглая древесина хранится в виде штабелей, объем которых может быть от единиц кубометров до тысяч, а длина – до сотен метров. При стандартном угле зрения камеры около 60° для того, чтобы захватить 10 м штабеля в кадр, нам нужно отойти на те же 10 м. Тут становится понятным, что снять одним кадром штабель длиной в 50-100 м так, чтобы все брёвна были видны и различимы, практически невозможно. Есть два подхода к решению этой задачи.

Первый — использовать панорамный снимок: эталон вешается с одного края штабеля, а дальше оператор начинает съёмку и движется вдоль всего штабеля. При этом формируется такой «длинный кадр», который содержит весь штабель. Такой метод реализован у наших конкурентов, но работает он на практике плохо — по мере движения камеры расстояние до брёвен сложно выдерживать постоянным, и набегает заметная ошибка.

Второй подход, который мы и применяем —  оператор делает несколько снимков, частично пересекающихся краями. На каждом кадре должен быть эталон. А для исключения двойного учёта брёвен на краях кадров разрабатывается алгоритм, который эти дубликаты находит и удаляет из расчета.

Серые — брёвна, отмеченные алгоритмом как дубликаты

Серые — брёвна, отмеченные алгоритмом как дубликаты

Что такое «погрешность 3%», и зачем она нужна

«Погрешность измерений составляет не более 3% и рассчитывается в соответствии с регламентом приемо-сдаточных испытаний»
(из технического задания)

На практике это один из самых тонких моментов при определении плотного объема древесины. Единственный реально точный метод — гидростатический: погрузить бревна без коры в воду и измерить объем вытесненной жидкости. Но в реальных условиях в России так (почти?) не делают — это  сложно, а значит, дорого. Обычно применяют ручные методы измерения бревен: групповые (быстрые) или поштучные (очень долгие — невозможно применить ко всему объему).

Стоит отметить, что на некоторых предприятиях используют поштучные сканеры древесины: бревно движется по конвейеру через устройство, которое определяет один или два диаметра с помощью световой завесы, либо — более точно — с помощью лазерного сканера/профилометра. Сравнительно точными также считаются ручные поштучные методы: «точковка» или «раскатка» имеют достаточно говорящие названия — нужно выложить брёвна в ряд на земле и провести измерение диаметра (а лучше — двух) каждого из них. Такой процесс может занять от десятков минут нескольких часов для одного штабеля или лесовоза в зависимости от объема и навыков персонала. Чаще всего такой метод применяют при возникновении споров, расхождений в учёте или при сборе статистики для расчета коэффициентов.

Компромиссный вариант измерения небольших штабелей — замер диаметра каждого бревна с одного торца (с вершины!). Обычно один человек замеряет и диктует, второй — записывает.

Компромиссный вариант измерения небольших штабелей — замер диаметра каждого бревна с одного торца (с вершины!). Обычно один человек замеряет и диктует, второй — записывает.

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

Наконец, когда бревна уложены в лесовозе или штабеле, измерять каждое по отдельности невозможно. Всё это приводит к тому, что на практике применяют групповые методы: считают объем, занятый штабелем, и пересчитывают его в плотный объем древесины через статистически выведенные коэффициенты полнодревесности.

Тут важно учитывать, что статистика хорошо работает только на больших выборках. Например, если у вас штабель всего из 10 бревен, то ошибка даже в одно бревно даст порядка 10 % погрешности. А если общий объем — 1000 м³, то даже пропуск нескольких брёвен почти не повлияет на результат (1–2%).

В стандартах это тоже учтено. Например, в Приложении 1 к «Правилам определения характеристик и учета древесины» (Постановление Правительства РФ от 30.11.21 №2128 «О порядке определения характеристик древесины и учета древесины») задана допустимая погрешность: она зависит и от метода, и от общего объема. Для объемов 30–60 м³ (типичный лесовоз) допустимы ±12%. Это естественный результат разной укладки и накопления мелких ошибок. А для объёма 600 м³ (и неважно — один это штабель или 15 лесовозов) — уже только ±3 %.

Конечно, покупатели мечтают, чтобы погрешность всегда уходила вниз, а продавцы — вверх. Но так делать нельзя: совесть не позволяет смещенная оценка нарушает саму идею статистической компенсации ошибок, которая позволяет на больших объемах получать точные результаты — те самые 3%, которые неоднократно подтверждены испытаниями. При этом нет никакой необходимости требовать 3% на каждом отдельном измерении.

Как еще можно измерять древесину?

Мобильные приложения — это не единственный способ автоматизировать учёт. Если говорить о технологически продвинутых альтернативах, то рынок предлагает несколько классов решений.

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

Групповые сканеры («фоторамки») работают с лесовозом целиком: комбинация камер и лазерных сканеров строит 3D-модель пачки, определяет складочный объем и коэффициент полнодревесности — по торцам или по боковым бревнам. Точность ниже, чем у поштучных, поскольку внутренность пачки системе недоступна, а коэффициент нередко корректируется оператором. Существуют и мобильные версии таких комплексов на прицепе, которые можно оперативно развернуть прямо у делянки.

Объединяет оба класса одно — высокая стоимость и привязка к инфраструктуре. Экономика сходится на крупных стационарных производствах с постоянным и плотным потоком древесины через точку контроля.

Решение Smart Timber позволяет создать единую прослеживаемую цепочку данных. Фотофиксация и сохранение измерений позволяют подтвердить объемы лесовозов и штабелей даже спустя длительное время. Цифровая «линейка» становится эффективной тогда, когда на её основе меняются процессы учета и управления.

Интеграция: от боли к гибкости

Первая интеграция с другой системой — АСД «Сегежа Лес» — стала достаточно сложным вызовом для нас. Из-за того, что основной сценарий использования обеих систем — работа в оффлайн-режиме, было необходимо обеспечить двустороннюю синхронизацию данных между приложениями двух систем на Android-планшете без связи с сервером. Решением стало межпроцессное взаимодействие на базе Intent и файлового обмена (изображениями, справочниками и данными замеров). Серверы тоже обменивались данными между собой на регулярной основе с использованием API друг друга.

Список измерений в мобильном приложении

Список измерений в мобильном приложении

Список измерений на сервере Smart Timber

Список измерений на сервере Smart Timber

Со временем мы выделили отдельный API для подключения сторонних систем, что позволило нам быстро решать задачи интеграции с системами других компаний (например, 1С). Именно такой вариант сейчас является для нас типовым сценарием — измерения и фотофиксация производятся Smart Timber, данные аккумулируются на нашем сервере, а система предприятия забирает их. API помогает получить или задать справочники, список измерений, забрать данные каждого измерения (с расчётами, выполненными сразу несколькими методами) и фотографии.

В какой-то момент внезапно для нас сервер Smart Timber со средствами интеграции обрел собственную ценность — мы стали получать запросы на интеграцию с нашим сервером сторонних приложений. Например, клиент уже проводит фотофиксацию своим приложением, но хотел бы делать замеры. Мы реализовали сценарий, при котором система клиента присылает в наш API фотографии (а также данные о породе, сортименте и другие метаданные). Их оператор в нашем веб-интерфейсе проводит измерение, после чего уже данные расчетов загружаются обратно в систему клиента. Также мы получаем запросы на интеграцию в наш сервер данных стационарных систем (например, поштучных сканеров древесины).

Что дальше

Несмотря на то, что в какой-то момент мы ушли от активной постоянной разработки технической части Smart Timber, у нас есть команда, которая занимается поддержкой и планомерным улучшением системы. Мы развиваем инфраструктуру, чтобы она соответствовала возрастающей нагрузке, следим за её надежностью, обеспечиваем безопасность.

Мы регулярно получаем обратную связь от наших клиентов и выполняем доработки (иногда за свой счет, если это полезно многим нашим пользователям, иногда по отдельному договору). Много работаем с тем, чтобы привлечь новых клиентов в России и за рубежом. Сейчас это, возможно, самая большая часть нашей работы, потому что именно так Smart Timber окупается и может привлечь средства на развитие.

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

  • Smart Storage — распознавание и подсчет труб, металлоконструкций, алюминиевых профилей

  • Smart Timber 3D — принципиально новый портативный прибор для более точного автоматического замера древесины (уже с включением в реестр средств измерения, отсутствием эталона, но и с другой ценовой политикой). В основе — калиброванная комбинация ToF (времяпролетной) и RGB-камер, наши отработанные алгоритмы и вся серверная инфраструктура Smart Timber.

Испытания Smart Timber 3D на ЦБК в Ленинградской области

Испытания Smart Timber 3D на ЦБК в Ленинградской области

  • Модуль для определения объемов пиломатериалов.

  • Работа со стационарными камерами – бюджетная замена лазерным сканирующим рамкам.

  • Линейка стационарных недорогих сканеров для лесопильных и фанерных заводов. 

Сегодня Smart Timber — это не просто приложение. Это пример того, как идея благодаря акселератору ЛАНИТ Product Manager (подробнее здесь и здесь) стала техническим решением, а затем, пройдя испытания рынком, столкнувшись с болью реальных клиентов, превратилась в зрелый продукт.

Статья написана в соавторстве с @m_n_smirnov