Рубрика «оптимизация» - 11

image
Ячейка пикинга на первом этаже стеллажа

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

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

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

Сложность в том, что паллета — это довольно много смесителей. А в магазин нужно привезти 50 штук, скажем. Не везти же её целиком? И вот появляется процесс пикинга, когда паллета снимается с ячейки, кладётся вниз, а потом из неё достаётся вложенная тара. Это может быть транспортный короб, иннер и штука. Штуками распределительный центр почти никогда не оперирует, за исключением редкого и дорогого оборудования. Для единиц нужны фулфилмент-центры, но это уже немного другая часть логистики, и в этом посте про них не будет.
Читать полностью »

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

Дилемма: пойти в проверенную столовую или попробовать новую? - 1

Читать полностью »

Сегодня мы хотим рассказать о направлении, с которого мы, Cognitive Pilot, исторически начали свои разработки в области создания беспилотных технологий, а именно отрасли automotive. Вообще эта сфера ставит перед разработчиками беспилотных систем наиболее интересные задачи: на дорогах общего пользования сцены намного сложнее и динамичнее, чем в сельском хозяйстве или на рельсах, а поведение объектов часто почти невозможно предугадать. Для создания беспилотных автомобилей используются технологии глубокого обучения, наиболее сложные нейронные сети и объемные датасеты. 

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

Взгляд на ADAS изнутри: когда поедет робот? - 1
Читать полностью »

Как разработчику научного ПО мне приходится много программировать. И большинство людей из других научных областей склонны думать, что программирование — это «просто» набросать код и запустить его. У меня хорошие рабочие отношения со многими коллегами, в том числе из других стран… Физика, климатология, биология и т. д. Но когда дело доходит до разработки ПО, то складывается отчётливое впечатление, что они думают: «Эй, что тут может быть сложного?! Мы просто записываем несколько инструкций о том, что должен сделать компьютер, нажимаем кнопку „Выполнить” и готово — получаем ответ!»

Проблема в том, что невероятно легко написать инструкции, которые означают не то, что вы думаете. Например, программа может совершенно не поддаваться интерпретации компьютером. Кроме того, нет буквально никакого способа определить, завершится ли программа вообще, не выполнив её. И есть много, очень много способов сильно замедлить выполнение программы. В смысле… реально замедлить. Так замедлить, что выполнение займёт всю вашу жизнь или больше. Это чаще всего происходит с программами, которые написаны людьми без компьютерного образования, то есть учёными из других областей. Моя работа — исправлять такие программы.

Люди не понимают, что информатика учит вас теории вычислений, сложности алгоритмов, вычислимости (то есть можем ли мы действительно что-то вычислить? Слишком часто мы считаем само собой разумеющимся, что можем!) Информатика даёт знания, логику и методы анализа, помогающие написать код, который выполнится за минимальное количество времени или с минимальным использованием ресурсов.
Читать полностью »

Современное SEO: качество страниц - 1

В конце мая с. г. в Google сообщили, что теперь они намерены в алгоритм ранжирования сайтов ввести понятие "качества страницы" (page experienceЧитать полностью »

image

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

Я несколько лет пользуюсь серверным telegram клиентом на php. И как многие пользователи — устал от постоянного роста потребления памяти. Некоторые сессии могут занимать от 1 до 8 гигабайт RAM! Поддержка баз данных была уже давно обещана, но подвижек в этом направлении не было. Пришлось решать проблему самому :) Популярность open source проекта, накладывала интересные требования на pull request:

  1. Обратная совместимость. Все существующие сессии должны продолжить работать в новой версии (сессия — это сериализованный инстанс приложения в файле);
  2. Свобода выбора БД. Возможность менять тип хранилища без потери данных и в любой момент, так как у пользователей разные конфигурации окружения;
  3. Расширяемость. Простота добавления новых типов баз данных;
  4. Сохранить интерфейс. Код приложения, работающий с данными, не должен меняться;
  5. Асинхронность. Проект использует amphp, поэтому все операции с базами должны быть неблокирующими;

За подробностями приглашаю всех под кат.
Читать полностью »

Недавно мой коллега рассказал как мы роботизируем зерноуборочные комбайны и чему научились за этот сезон.

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

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

Как мы первыми в мире роботизируем кормоуборочные комбайны - 1

Фактически один комбайнёр работает за троих, следит за процессом уборки кукурузы (одно рабочее место), ведёт технику (второе рабочее место), загружает силосовоз (третье рабочее место). В итоге что-то страдает. Если плохо вести, можно сломать дорогую технику (минимальная цена кормоуборочного комбайна 16 млн рублей, есть модели и по 50 миллионов), поэтому обычно ухудшается качество уборки и загрузки.

Большую часть работы мы автоматизируем, сейчас расскажу какие сложности мы преодолеваем и что делаем.
Читать полностью »

image

Привет! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.

Базовая проблема следующая. Вот вы производите установку для крекинга нефти, либо станок для машиностроения, либо какое-то другое устройство для завода. Как правило, продажа сама по себе крайне редко возможна: обычно это контракт на поставку и обслуживание. То есть вы гарантируете, что железяка будет работать лет 10 без перебоев, а за перебои отвечаете либо финансово, либо обеспечиваете жёсткие SLA, либо что-то подобное.

По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.

Установка мониторинга требует модификации железа устройством передачи данных, самой передачи, какого-то озера данных для их накопления, разбора протоколов и среды обработки с возможностью всё посмотреть и сопоставить. Ну и с этим всем есть нюансы.
Читать полностью »

image
А ведь в прошлом году это делали senior-разработчики.

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

image

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

Более того, они справились лучше, чем мы ждали. Кроме того, в релиз вошли далеко не все фичи. В релизе осталось, по сути, ядро, но одно только это позволило получить очень заметный экономический эффект.

Конечно, обошлось не без сюрпризов. Но давайте расскажу более конкретно, с числами и примерами.
Читать полностью »

image
Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки).

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

Каждая сэкономленная секунда в процессах приёмки, сборки или отправки товара в таких масштабах — это возможность сберечь время на операции. А ещё это огромная экономия.

Именно поэтому два главных множителя эффективности — это продуманный алгоритм действий (процесс) и настроенные ИТ-системы. Желательно «как часы», но «работающие чуть менее, чем идеально» тоже вполне подойдёт. Всё же мы в реальном мире.

История началась шесть лет назад, когда мы присмотрелись к тому, как именно поставщики разгружают фуры у нас на складе. Это было настолько нелогично, но привычно, что сотрудники даже не замечали неоптимальности процесса. Более того, в тот момент у нас не было промышленной системы управления складом, и в основном логистические операции мы доверяли 3PL-операторам, которые использовали свой софт и опыт в построении процессов.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js