Идея интересная, мы как бы сокращаем количество неизвестных за счёт попадания производных или значений. Но мне кажется, что будут проблемы с монотонностью.
Я попробовал придумать адекватное обоснование этому, но пока что не вышло. Поэтому излагаю только предположение.
Фреймворк собирается в набор серверов в deb-пакете, поэтому можно переписать клиенты под питон. В будущем планирую добавить клиенты и на python, и на java.
Собрать полноценный аналог библиотеки под питон я до Вашего вопроса не думал, но идея, на мой взгляд, хорошая. Добавлю в тасклист.
Если технология не подразумевает контроля с обратной связью, то можно определить вручную опорные промежуточные точки между стартовым положением рабочего инструмента и целевым. В общем случае может быть произвольное число целевых положений. Если между ними слишком длинные переходы, то можно с помощью планировщиков пути (например A*) составить промежуточные опорные точки.
Когда есть путь по точкам, остаётся только спланировать траекторию, т.е. из точек в пространстве сформировать склейку полиномов для каждого промежутка.
Если говорить о промышленности, то, на мой взгляд, нет необходимости точного попадания. Достаточно соблюсти некоторую точность тех. процесса.
В этом алгоритме самая важная часть - монотонность. По сути, нужно аппроксимировать не произвольным полиномом, а одним из монотонных.
Все алгоритмы именно монотонной инерполяции, которые я нашел, используют полиномы Эрмита, просто работают с разными степенями и по-разному назначают производные.
Алгоритм, который я разобрал, работает практически за линию. Один проход - назначение производных, второй - корректировка до монотонности.
Действительно, можно было бы попробовать решать задачу минимизации ошибки, меняя производные в точках. Но тут нужно определять производные функции ошибки, для метода Ньютона - ещё и вторые производные.
Если опорных точек будет много, то и размерность пространства оптимизации будет очень большой.
Оба довода не исключают направления, о котором Вы говорите, но, судя по всему, его разработка пока что ученым либо неинтересна, либо на нее нет времени.(либо слишком просто, либо слишком сложно)
Это не основной мой профиль, я - прикладник. Поэтому, как там в реальности - не знаю)
Согласен, адекватное планирование с учётом нештатных ситуаций просто необходимо. Без него ничего надежного не построишь. Думаю, даже сами по себе эффективные модели такого планирования для обычного "человеческого" производства будут очень полезными.
Переточенный инструмент можно измерить цифровыми средствами контроля и по мат. модели скорректировать программу. В крайнем случае, можно задействовать нейросети.
Речь не о том, что работа со станками ЧПУ проста, отнюдь. Автоматизация задач оператора требует серьёзных исследований (RND), участия многих специалистов, но она решаема в обозримые сроки. Если бы все было просто, это уже сделали бы.
Если говорить о системе планирования, то да, это очень сложная задача, но посильная для профессиональных математиков и программистов. Самая главная сложность в этом смысле, на мой взгляд, будет в том, чтобы перевести на язык математики и алгоритмов все события на производстве. Если всерьёз составлять модели, то примерно с Вашего описания всё и должно начинаться.
Складские задачи с точки зрения планирования тоже не так просты, как кажутся на первый взгляд, но они сейчас решаются, и многие уже решены.
Про веб-камеры: интерактивное исполнение заказа, конечно, не обязательно. Но как "фича", на мой взгляд, полезна. Я считаю, что работать с системой должно быть приятно и наглядно. Но это, конечно, вкусовщина.
Это всего лишь прототип) Думаю, знающие люди из многих из затронутых сфер могут хорошо его уточнить или дополнить. Он играет скорее иллюстративную роль.
По-хорошему, нужно параллельно развивать своё производство станков. Если загрузка будет стопроцентной, то износ оборудования может случиться и раньше. Мне кажется, что такой загрузки вообще ни одна ЧПУ станция не испытывала. Ведь простой оборудования будет минимизирован. Но если будет свой цикл разработки станков, то можно постепенно переводить слабые узлы с кооперации на внутреннее производство. Т.к. будет гарантированный внутрекорпоративный спрос, то за лет 5-10 упорного труда, думаю, можно выработать технологию производства гарантированно надёжных станков. А такие станки и на открытом рынке будут сильно востребованы.
Цель статьи и была узкой: показать, как развивается отрасль. Она сейчас является движущей силой шестого технологического уклада. Но для обоснования вывода я посчитал нужным ввести принципы, согласно которым я строю прогноз. Новый уклад внедряется постепенно. Говоря про сельское хозяйство, Вы имеете в виду беспилотные комбайны? Если да, то это частный случай беспилотников. Возможно, развитие отрасли пошло дальше, и есть какое-то логическое продолжение, но я о нём не знаю.
О нематериальной сфере шестого технологического уклада, я считаю, говорить ещё рано. Подавляющая часть нематериальной сферы построена на технологиях пятого технологического уклада (компьютеры и интернет).
Если Вы считаете, что уже можно выделить нематериальные сферы, в которые внедрён шестой технологический уклад, т.е. нематериальные сферы, в которых участие человека штатно не требуется, с удовольствием, с Вами это обсужу.
Станки с ЧПУ взяты не просто так. Идея не в том, чтобы автоматизировать всю отрасль обрабатывающей промышленности, а в том, чтобы выделить в этой сфере, как и в сфере хранения, ту область, которую можно дёшево перевести на стандарт индустрии 4.0, имея стек технологий автоматизированного склада.
Методология работы с ЧПУ полностью проработана, не хватает только объединить это в единый кластер, который штатно не будет требовать участия человека. Если Вы приведёте другие средства производства, которые также не требуют качественной перестройки под полностью автоматизированное управление, то буду рад добавить эту информацию в статью.
Замах не на уклад, а на описание первых этапов его становления и того, каким будет следующий. Об этом написано в первом предложении статьи.
Добавил в описание явное указание: Сначала будет приведён алгоритм поиска паттернов рекуррентным перебором, потом его быстрая модификация с минимальным отсечением.
"Вот это вот всё" тянет на статью в научном журнале, а не на хабре.
Цель статьи была не перевернуть мир, а показать, как пройти от тривиального алгоритма до более-менее быстрого.
Мне показалось, что в итоге мой алгоритм будет сравним по скорости, если Вы утверждаете, что это не так, то такое сравнение не было целью статьи. Сравнение времени работы было дано специально для того, чтобы показать, как сумма приёмов сократит время вычислений.
Представленного мною алгоритма я в интернете не нашёл, поэтому посчитал полезным его опубликовать.
Вопрос не в том, выполняется перебор с отсечениями или нет, а в том, какая именно часть отсекается, и какова вычислительная цена этого отсечения. Например, бинарный поиск тоже отсекает часть вариантов. Но т.к. число этих вариантов значительно, то такой поиск считается быстрым. Если Вы предложите реализацию на c++ или java алгоритма, который Вы прислали, с удовольствием сравню.
Насколько я понял, он является развитием алгоритма Ульмана, с ним и сравнивается. В нём составляется функция осуществимости feasibility function для упрощения перебора. По сути, она точно так же, как и мой алгоритм, отсекает неподходящие варианты, но с помощью предсоставленных подграфов (ветвей).
Моему алгоритму не нужно составлять такие подграфы, их аналог - это строка и столбец подматрицы. Мой код использует в качестве функции осуществимости в худшем случаем 2k проверок на равенство целочисленных значений по промежуточной перестановке, где k - шаг рекуррентного метода. Возможно, алгоритмы с предварительным обходом работают быстрее, но пока что я не вижу этому объективных обоснований.
Спасибо за замечание. Добавил уточнение в статью: На графиках по оси OX отложен индекс элемента в упорядоченном списке результатов тестов, по оси OY - затраченное на соответствующий тест время в микросекундах.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург и область, Россия
Зарегистрирован
Активность
Специализация
Бэкенд разработчик, Архитектор программного обеспечения
Класс! Пришлите, пожалуйста, ссылку как опубликуете)
Под монотонностью здесь я подразумеваю то, что значение пути на каждом этапе гарантированно не выйдет за граничные значения этого этапа.
Идея интересная, мы как бы сокращаем количество неизвестных за счёт попадания производных или значений. Но мне кажется, что будут проблемы с монотонностью.
Я попробовал придумать адекватное обоснование этому, но пока что не вышло. Поэтому излагаю только предположение.
Фреймворк собирается в набор серверов в deb-пакете, поэтому можно переписать клиенты под питон. В будущем планирую добавить клиенты и на python, и на java.
Собрать полноценный аналог библиотеки под питон я до Вашего вопроса не думал, но идея, на мой взгляд, хорошая. Добавлю в тасклист.
Если технология не подразумевает контроля с обратной связью, то можно определить вручную опорные промежуточные точки между стартовым положением рабочего инструмента и целевым. В общем случае может быть произвольное число целевых положений. Если между ними слишком длинные переходы, то можно с помощью планировщиков пути (например A*) составить промежуточные опорные точки.
Когда есть путь по точкам, остаётся только спланировать траекторию, т.е. из точек в пространстве сформировать склейку полиномов для каждого промежутка.
Если говорить о промышленности, то, на мой взгляд, нет необходимости точного попадания. Достаточно соблюсти некоторую точность тех. процесса.
В этом алгоритме самая важная часть - монотонность. По сути, нужно аппроксимировать не произвольным полиномом, а одним из монотонных.
Все алгоритмы именно монотонной инерполяции, которые я нашел, используют полиномы Эрмита, просто работают с разными степенями и по-разному назначают производные.
Алгоритм, который я разобрал, работает практически за линию. Один проход - назначение производных, второй - корректировка до монотонности.
Действительно, можно было бы попробовать решать задачу минимизации ошибки, меняя производные в точках. Но тут нужно определять производные функции ошибки, для метода Ньютона - ещё и вторые производные.
Если опорных точек будет много, то и размерность пространства оптимизации будет очень большой.
Оба довода не исключают направления, о котором Вы говорите, но, судя по всему, его разработка пока что ученым либо неинтересна, либо на нее нет времени.(либо слишком просто, либо слишком сложно)
Это не основной мой профиль, я - прикладник. Поэтому, как там в реальности - не знаю)
Согласен, адекватное планирование с учётом нештатных ситуаций просто необходимо. Без него ничего надежного не построишь. Думаю, даже сами по себе эффективные модели такого планирования для обычного "человеческого" производства будут очень полезными.
Переточенный инструмент можно измерить цифровыми средствами контроля и по мат. модели скорректировать программу. В крайнем случае, можно задействовать нейросети.
Речь не о том, что работа со станками ЧПУ проста, отнюдь. Автоматизация задач оператора требует серьёзных исследований (RND), участия многих специалистов, но она решаема в обозримые сроки. Если бы все было просто, это уже сделали бы.
Если говорить о системе планирования, то да, это очень сложная задача, но посильная для профессиональных математиков и программистов. Самая главная сложность в этом смысле, на мой взгляд, будет в том, чтобы перевести на язык математики и алгоритмов все события на производстве. Если всерьёз составлять модели, то примерно с Вашего описания всё и должно начинаться.
Складские задачи с точки зрения планирования тоже не так просты, как кажутся на первый взгляд, но они сейчас решаются, и многие уже решены.
Про веб-камеры: интерактивное исполнение заказа, конечно, не обязательно. Но как "фича", на мой взгляд, полезна. Я считаю, что работать с системой должно быть приятно и наглядно. Но это, конечно, вкусовщина.
Это всего лишь прототип) Думаю, знающие люди из многих из затронутых сфер могут хорошо его уточнить или дополнить. Он играет скорее иллюстративную роль.
По-хорошему, нужно параллельно развивать своё производство станков. Если загрузка будет стопроцентной, то износ оборудования может случиться и раньше. Мне кажется, что такой загрузки вообще ни одна ЧПУ станция не испытывала. Ведь простой оборудования будет минимизирован. Но если будет свой цикл разработки станков, то можно постепенно переводить слабые узлы с кооперации на внутреннее производство. Т.к. будет гарантированный внутрекорпоративный спрос, то за лет 5-10 упорного труда, думаю, можно выработать технологию производства гарантированно надёжных станков. А такие станки и на открытом рынке будут сильно востребованы.
Цель статьи и была узкой: показать, как развивается отрасль. Она сейчас является движущей силой шестого технологического уклада. Но для обоснования вывода я посчитал нужным ввести принципы, согласно которым я строю прогноз. Новый уклад внедряется постепенно. Говоря про сельское хозяйство, Вы имеете в виду беспилотные комбайны? Если да, то это частный случай беспилотников. Возможно, развитие отрасли пошло дальше, и есть какое-то логическое продолжение, но я о нём не знаю.
О нематериальной сфере шестого технологического уклада, я считаю, говорить ещё рано. Подавляющая часть нематериальной сферы построена на технологиях пятого технологического уклада (компьютеры и интернет).
Если Вы считаете, что уже можно выделить нематериальные сферы, в которые внедрён шестой технологический уклад, т.е. нематериальные сферы, в которых участие человека штатно не требуется, с удовольствием, с Вами это обсужу.
Станки с ЧПУ взяты не просто так. Идея не в том, чтобы автоматизировать всю отрасль обрабатывающей промышленности, а в том, чтобы выделить в этой сфере, как и в сфере хранения, ту область, которую можно дёшево перевести на стандарт индустрии 4.0, имея стек технологий автоматизированного склада.
Методология работы с ЧПУ полностью проработана, не хватает только объединить это в единый кластер, который штатно не будет требовать участия человека. Если Вы приведёте другие средства производства, которые также не требуют качественной перестройки под полностью автоматизированное управление, то буду рад добавить эту информацию в статью.
Замах не на уклад, а на описание первых этапов его становления и того, каким будет следующий. Об этом написано в первом предложении статьи.
Добавил в описание явное указание:
Сначала будет приведён алгоритм поиска паттернов рекуррентным перебором, потом его быстрая модификация с минимальным отсечением.
"Вот это вот всё" тянет на статью в научном журнале, а не на хабре.
Цель статьи была не перевернуть мир, а показать, как пройти от тривиального алгоритма до более-менее быстрого.
Мне показалось, что в итоге мой алгоритм будет сравним по скорости, если Вы утверждаете, что это не так, то такое сравнение не было целью статьи. Сравнение времени работы было дано специально для того, чтобы показать, как сумма приёмов сократит время вычислений.
Представленного мною алгоритма я в интернете не нашёл, поэтому посчитал полезным его опубликовать.
Вопрос не в том, выполняется перебор с отсечениями или нет, а в том, какая именно часть отсекается, и какова вычислительная цена этого отсечения. Например, бинарный поиск тоже отсекает часть вариантов. Но т.к. число этих вариантов значительно, то такой поиск считается быстрым. Если Вы предложите реализацию на c++ или java алгоритма, который Вы прислали, с удовольствием сравню.
Насколько я понял, он является развитием алгоритма Ульмана, с ним и сравнивается. В нём составляется функция осуществимости feasibility function для упрощения перебора. По сути, она точно так же, как и мой алгоритм, отсекает неподходящие варианты, но с помощью предсоставленных подграфов (ветвей).
Моему алгоритму не нужно составлять такие подграфы, их аналог - это строка и столбец подматрицы. Мой код использует в качестве функции осуществимости в худшем случаем 2k проверок на равенство целочисленных значений по промежуточной перестановке, где k - шаг рекуррентного метода. Возможно, алгоритмы с предварительным обходом работают быстрее, но пока что я не вижу этому объективных обоснований.
Спасибо за замечание.
Добавил уточнение в статью:
На графиках по оси OX отложен индекс элемента в упорядоченном списке результатов тестов, по оси OY - затраченное на соответствующий тест время в микросекундах.