Это да, но при их конкретно потребностях (10т товаров суммарно) — не то что 10, там даже 1 сканер избыточен на порядок по пропускной способности. Нанять ещё одного работника со штангенциркулем перемерять весь ассортимент и перепроверить, что не совпадет со старой базой, обойдется ну в 200 т.р. с запасом. Займет полгода от силы, рисков ноль, затрат времени руководства и программистов ноль.
Заказчик сделал всё правильно. Если их профиль — дистрибуция бытовой химии, они не близко к Amazon по масштабу, и не собираются сами входить на рынок таких устройств, то либо затраты денег и времени на разработку не окупятся, либо окупился бы тот же CubiScan/Сенсотек, и проще было бы взять его. Заметно дешевле 1 млн с нуля они все равно ничего «промышленного качества» (железо + софт достаточно точное, надежное, ремонтопригодное и простое для эксплуатации неквалифицированными рабочими) не сделают.
А, если это с учетом беготни по складу, тогда понятно. Но в таком случае действительно гораздо проще оптимизировать процесс. Типа оставить одного измеряльщика, задачи принеси-унеси перебросить на имеющихся кладовщиков.
А по точности — чем сейчас меряют, если не секрет? Если линейками-рулетками, то есть очевидный шаг апгрейда. Если уже что-то приличное, и всё равно есть заметный резерв по точности, то я пас.
Но будет круто если доведёте 3D сканер, желаю успеха!
Спасибо за цифры! Прошу прощения за «скептицизм с обочины», сам такое очень не люблю, но похоже чего-то не понимаю до сих пор. Снять 3 габаритных измерения и занести в базу — ну на 5 минут дел, с огромным запасом. Получаем по порядку величины 1 человеко-день (8 часов) х (12 измерений в час) = (~100 измерений). На несколько сотен (т.е. меньше 1000) позиций в месяц получается ну 2 человеко-недели от силы. Откуда там 2 человеко-месяца вылезает? Они весь ассортимент могут ежемесячно перемеривать… Разве что на перемещение образцов в лабораторию, но от этого прибор не спасет.
Если только сейчас вручную что-то типа грубой 3Д модели строится, то да, там легко поверить в любые затраты времени на единицу :)
Было бы интересно раскрыть, как от определения габаритов в итоге пришли к ТЗ на аналог CubiScan, который НЯП ближе к полноценному 3D сканеру и для просто замера габаритов явно избыточен. По-моему гораздо проще было бы сделать что-то типа «штангенциркуля в 3D» — открытый прямоугольный уголок, куда кладем объект, и возможность зажимать плоскостями по трем направлениям с замером расстояния. Наверняка что-то уже есть такое.
Логика заказчика тоже ясна — замер габаритов работа тупая, квалификация нужна нулевая, следовательно при номенклатуре в 10к товаров разработка чего-либо сложнее рулетки выглядит нерентабельным занятием. Там даже единичное устройство за 100 к.р. — сомнительная инвестиция, проще взять несколько человек на месяц, чтобы каждую деталь замерило несколько из них независимо, и перепроверить те, где результаты не сходятся. Или «габаритами» вы замаскировали более конфиденциальные хотелки?
Ясно, успеха! Единственное по многопоточности — glog НЯП синхронизирован на уровне каждого LOG вызова. То есть логать можно из нескольких потоков спокойно, и строчки перемешиваться не будут (в отличие от cout). Про порядок на 100% не уверен, но в пределах одного потока я бы очень удивился, если он может нарушиться. А между разными потоками в любом случае гарантий нет.
Не очень понял, как в вашем примере значения вместо %s будут подставляться. Если бы можно было
logger.warn("Unexpected blah: %s instead of %s", blah, expected_blah);
то конечно да. Но это же надо как-то через varargs (или как оно в c++ называется) blah и expected_blah внутрь логгера форвардить, а внутри там опять snprintf (?) и ещё веселее с выделением буфера, т.к. заранее размер строк мы теперь не знаем…
Сам ненавижу любую возню с перегрузкой операторов, но когда кто-то добрый уже всё сделал, то пользоваться удобно.
А с logger.warn() надо же сначала сформировать строку, то есть либо stringstream с теми же операторами, либо snprintf() и пляски с выделением буфера нужного размера.
Отдача соответственно в повышении читаемости клиентского кода.
«Интеграция с CAN шиной, чтение оттуда текущего угла поворота» — не вижу в существующей системе датчика положения РУ, который мог бы этот угол выдать. Ну хорошо, его можно присобачить.
Датчик есть, жгут проводов у него общий с датчиком момента (сами провода другие естественно). Я даже не стал разбираться, как он работает, т.к. ЭБУ его оцифровывает и с достаточно высокой частотой выдает текущий угол поворота в CAN (см. «Воспроизведение записи шины на стенде» в статье, первые 2 байта пакетов 2B0 и есть угол (в десятых долях градуса вроде бы).
Но с точки зрения ТАУ, регулируемый параметр у вас — угол поворота, а в качестве уставки вы имеете возможность использовать лишь усилие, приложенное между рулевым валом и карданом к рулевой рейке. Передаточная функция между двумя этими величинами вряд ли тривиальна; даже её детерминированность, в реальных условиях, вызывает большие сомнения.
Придётся немного повозиться, да, но вряд ли потребует сверхусилий. В первом приближении можно просто покататься на разных скоростях, записать логи углов и усилий и по ним интерполировать. Дальше для повышения точности прикрутить обратную связь. Ну и вообще, подозреваю, что для более-менее владеющих теорией оптимального управления (к коим не отношусь) задача будет банальной.
Думаю, для решения конечной задачи следовало бы построить желаемый в теории контур регулирования, определить требуемые для него характеристики, а затем понять, можно ли доработать имеющееся железо и как это сделать. Навскидку, куда правильнее было бы подменять не сигнал от аналогового датчика, а целиком «мозги» усилителя, чтобы было возможно напрямую рулить его двигателем. Кроме того, могут потребоваться дополнительные датчики ( например, очень полезно было бы знать реальный момент на кардане к рулевой рейке).
Так тоже можно конечно, но это в разы больше работы. На данный момент надо было минимальными усилиями разблокировать следующие шаги по интеграции с софтом машинного зрения итд; если дальше вылезут явные косяки, можно будет вернуться и те части более тщательно сделать.
Да, так должно быть надёжнее. Единственное нужно будет ещё как-то сделать, чтобы при зависании напряжение к нулю возвращалось относительно плавно, т.к. в усилителе есть детектор резких скачков напряжения на датчиках, и он просто отключается по нему. Вообще по надёжности тут просто конь не валялся, у меня опыта ноль в электронике и голова сейчас больше болит в направлении «нейросеть хочет уехать в канаву». А по уму конечно надо будет перепроектировать это всё.
Там есть пара разных индексов рулевых колонок, но вроде разница только в наличии кнопки старт-стоп вместо ключа и подсветки руля (видимо разница по проводке и механизму блокировки без ключа), надеюсь по собственно приводу разницы нет.
Это конечно фактор, надо держать в голове, но больше в контексте разработки — сырая или недообученная система управления может «шуметь» и пытаться интенсивно дергать руль туда-обратно. В этом её надо ограничивать, иначе усилитель действительно можно убить. Что касаемо эксплуатации, когда и если до неё дойдет дело — то на асфальте современные усилители вполне справляются. Насколько я знаю, та же Udacity ездит на ЭУР вполне себе, Polysync, ещё пара компаний точно. Просёлки же по весне в деревне Гадюкино думаю не покорятся роботам ещё долго :)
В общем если совсем глупостей не творить, нагрузка на эур в обычном городском режиме не должна быть проблемой.
Да, будет аналоговое. Функции возможно есть (на каких-то сидах вроде бы есть система удержания в полосе, значит как-то она с ЭУРом в состоянии общаться). Но во-первых все протоколы закрытые, т.е. их пришлось бы тоже разбирать с нуля с дампов шины на реальном авто, это сложно. А во-вторых там часто ограничения по режимам (например, система удержания в полосе поворачивает руль не более, чем на 5 градусов; автопарковщик крутит рулём только на задней передаче, итд). В illmatics.com/car_hacking.pdf можно почитать примеры проблем с рулением по CAN. Через датчики получается сильно проще, хотя свою систему управления простенькую на удержание нужного угла придется писать.
Это понятно в качестве мотивации априори, но на их графике я не увидел «сильно быстрее», поэтому и спросил.
Синий график, где явно криво настроен learning rate, игнорируем, смотрим на их красный график. Там видно, что каждый раз, когда LR увеличивается (т.е. каждый период косинуса) training loss прыгает вверх до ~5e-1. По первому сегменту видно, что с нуля этот loss достигается за ~10 эпох при периоде косинуса в 50. То есть получаем от силы 30% ускорение, что на сильно быстрее на мой взгляд не тянет, особенно учитывая резервы по настройке learning rate.
Поэтому вопрос, что лучше (и главное почему) — их схема или, например, взять их LR schedule за первые 50 эпох, обучить 6 моделей по 50 эпох с нуля с разными инициализациями и сделать ансамбль из них, — остался открытым. Во втором случае индивидуальные модели будут похуже, но если за счет разных инициализаций они окажутся более разнообразными, то их ансамбль может сработать лучше.
А по точности — чем сейчас меряют, если не секрет? Если линейками-рулетками, то есть очевидный шаг апгрейда. Если уже что-то приличное, и всё равно есть заметный резерв по точности, то я пас.
Но будет круто если доведёте 3D сканер, желаю успеха!
Если только сейчас вручную что-то типа грубой 3Д модели строится, то да, там легко поверить в любые затраты времени на единицу :)
Было бы интересно раскрыть, как от определения габаритов в итоге пришли к ТЗ на аналог CubiScan, который НЯП ближе к полноценному 3D сканеру и для просто замера габаритов явно избыточен. По-моему гораздо проще было бы сделать что-то типа «штангенциркуля в 3D» — открытый прямоугольный уголок, куда кладем объект, и возможность зажимать плоскостями по трем направлениям с замером расстояния. Наверняка что-то уже есть такое.
Логика заказчика тоже ясна — замер габаритов работа тупая, квалификация нужна нулевая, следовательно при номенклатуре в 10к товаров разработка чего-либо сложнее рулетки выглядит нерентабельным занятием. Там даже единичное устройство за 100 к.р. — сомнительная инвестиция, проще взять несколько человек на месяц, чтобы каждую деталь замерило несколько из них независимо, и перепроверить те, где результаты не сходятся. Или «габаритами» вы замаскировали более конфиденциальные хотелки?
logger.warn("Unexpected blah: %s instead of %s", blah, expected_blah);то конечно да. Но это же надо как-то через varargs (или как оно в c++ называется) blah и expected_blah внутрь логгера форвардить, а внутри там опять snprintf (?) и ещё веселее с выделением буфера, т.к. заранее размер строк мы теперь не знаем…
Сам ненавижу любую возню с перегрузкой операторов, но когда кто-то добрый уже всё сделал, то пользоваться удобно.
LOG(WARN) << «Unexpected blah: » << blah << " instead of " << expected_blah;
А с logger.warn() надо же сначала сформировать строку, то есть либо stringstream с теми же операторами, либо snprintf() и пляски с выделением буфера нужного размера.
Отдача соответственно в повышении читаемости клиентского кода.
Посмотрите на glog, вполне возможно не придётся писать свой велосипед. Там как раз через << всё сделано.
Датчик есть, жгут проводов у него общий с датчиком момента (сами провода другие естественно). Я даже не стал разбираться, как он работает, т.к. ЭБУ его оцифровывает и с достаточно высокой частотой выдает текущий угол поворота в CAN (см. «Воспроизведение записи шины на стенде» в статье, первые 2 байта пакетов 2B0 и есть угол (в десятых долях градуса вроде бы).
Придётся немного повозиться, да, но вряд ли потребует сверхусилий. В первом приближении можно просто покататься на разных скоростях, записать логи углов и усилий и по ним интерполировать. Дальше для повышения точности прикрутить обратную связь. Ну и вообще, подозреваю, что для более-менее владеющих теорией оптимального управления (к коим не отношусь) задача будет банальной.
Так тоже можно конечно, но это в разы больше работы. На данный момент надо было минимальными усилиями разблокировать следующие шаги по интеграции с софтом машинного зрения итд; если дальше вылезут явные косяки, можно будет вернуться и те части более тщательно сделать.
Там есть пара разных индексов рулевых колонок, но вроде разница только в наличии кнопки старт-стоп вместо ключа и подсветки руля (видимо разница по проводке и механизму блокировки без ключа), надеюсь по собственно приводу разницы нет.
А вообще будем решать проблемы по мере возникновения :)
В общем если совсем глупостей не творить, нагрузка на эур в обычном городском режиме не должна быть проблемой.
Синий график, где явно криво настроен learning rate, игнорируем, смотрим на их красный график. Там видно, что каждый раз, когда LR увеличивается (т.е. каждый период косинуса) training loss прыгает вверх до ~5e-1. По первому сегменту видно, что с нуля этот loss достигается за ~10 эпох при периоде косинуса в 50. То есть получаем от силы 30% ускорение, что на сильно быстрее на мой взгляд не тянет, особенно учитывая резервы по настройке learning rate.
Поэтому вопрос, что лучше (и главное почему) — их схема или, например, взять их LR schedule за первые 50 эпох, обучить 6 моделей по 50 эпох с нуля с разными инициализациями и сделать ансамбль из них, — остался открытым. Во втором случае индивидуальные модели будут похуже, но если за счет разных инициализаций они окажутся более разнообразными, то их ансамбль может сработать лучше.