///...Команда Транспорт ...Решаем внутренние расчётные задачи, делаем транспортные API...///
///... лучше километр по обычной дороге, чем метр по дороге с ограничением...///
С учетом двух фраз, приведенных выше, приходится беспилотному грузовику в южной части северо-американских штатов - иметь свой API, через который местный 2ГИС
не только выясняет (изменяыющиеся во времени) особенности cargoTransferObject (as struct: platformDynamic; operatorModel; cargoSet; energyForTransfer)
но и требует передать rawScanRouteData, где грузовик проехал за предыдущие сутки (обновление мета-данных графа дорог)
также пытается (с переменным успехом) спросить все виды местых autorities и ремонтников: "что же еще сегодня вы успели изменить и можно ли этому доверять"
И только после этого, предлагает маршруты и перестривает теккущий маршрут - по факту мониторинга cargoTransferObject. Ибо не везде будет возможность развернуться (и иное доступное / разрешенное), заправится, заменить колесо трейлера, поменять тягач, подъехать эвакуатору, итд ... чем живо интересуется местная roadAdministration, c богатой фантазией )))
Вопрос, что ваш маршрутный Алгоритм принимает на вход, для построения исходного графа всех вариантов ?
NB все виды погодных условий, учтены в operatorModel.
PS маршрут покупается за деньги и когда маршрут от местного 2ГИС, не позволяет завершить перевозку вообще или с перерасходом предложеных лимитов по маршруту, то транспортник получает компенсацию (чем без стеснения пользуется местный 2ГИС, ибо дешевле отозвать маршрут и выплатить транспортнику деньги, чем признаться что проехать данному транспорту по данному маршруту в принципе невозможно).
///... при использование автопилота (ветер не кто не отменял, дрон должен иметь возможность для экстренного манёвра =>
///... К счастью нам не понадобилось писать с нуля автопилот, так как у нашего дрона Geoscan Pioneer max, он есть встроенный =>
///...но не смотря на это нам всё равно понадобилось разработать алгоритм построения траектории движения!!!
-----
С чего-то нужно начинать, в том числе с изучения алгоритмов встроенного (в выбранную транспортную платформу) автопилота, для начала на уровне API.
Алгоритм построения траектории, учитывает какой-то перечень параметров - опубликуете (перечень) ? А возможно и структуру траекторного алгоритма, хоть бы и в stateFlow виде.
Верный и правильный подход - конструкция / идея - Тара и Замок, есть то что определяет виды применения и коммерциализацию..
Второе неотделимое друг от друга - Алгоритм автопилота и конструктивная идея Посадочной площадки. Буду ожидать второй заявленной публикации (Автпилот) - в надежде увидеть абстрактный Алгоритм, реализующий подходы к реализации Автопилота:
вне зависимости от среды движения, воздух, жидкость, твердые частицы-газо-жидкостная смесь капли струи пыль взвесь град;
отделение / приосоединение к качающейся площадке;
упрощение алгоритма Автопилота, за счет конструкции посадочной площадки
Реальная задача - обслуживание морских ветряков, с борта морского дрона-обслуживания или с автомобиля на береговой линии, поднять / вернуть капсулу с грузом на гондолу работающего ветряка. Вытекающая будущая задача - в корзине люди.
С Победой ! любое решение достигающее практической / поставленной цели - есть успех.
Вопрос, исходя из вытекающего действия, после остановки перед Целью: - появится ли новая параллельная ветвь и новые "concat"; в представленной вами структуре Алгоритма, - или же вы добавите только дополнительные блоки FC / LSTM ? - или возможно что-то более изящное;
- (суть дела) когда в ракурсе RGB-D_sensor, появится (рука)Манипулятор(ы), которым нужно дотянуться до ручки дверцы холодильника и открыть / закрыть такую дверцу; - иное подобное, когда в ракурсе сенсора, появляются движущиеся Объекты, которые нужно позиционироввать одновременно относительно Базы и относительно ЧастиОбъекта.
Георадар ! был рад прочитать что есть разработчики, понимающие всю "непредсказуемость" GNSS и вычисолительные затраты на рспознавание визуальных контуров окружающих зданий.
Делаю аналогичное сейчас для локализации относительно поверхности и придонного слоя подводного рельефа.
Интерсно к чему вы пришли в части кратности снижения вычислительных затрат, при рспознвании отклика георадара в сравнении с затратами на лидарное / визуальное распознавание.
'//... На семинаре будет показан подход к тестированию алгоритмов систем помощи водителю, позволяющий значительно сократить количество натурных испытаний за счёт использования виртуального полигона. ///
Алгоритм управления Тягой и Направлением движения (первый уровень абстракции над над комплектом приводов, кинематики и механических ообенностей объединяющей "рамы / кузова / шарнирно сочлененных рам",
напрямую зависит от степени достоверности Виртуального Полигона к реальной ситуации, вдоль маршрута(скмейства маршрутов)
и перечня вводных маркетинговых установок Разработчику, то есть что продается от лица Автопроизводиеля - Владельцу и Эксплуатанту (разное целеполагание) транспортного средсва.
Вопросы:
что из себя представляет ваш виртуальный полигон ? А именно какой набор мгновенных сигналов (локальная зона) и общей информации (весь маршрут(ы), можно считывать в адрес Алгоритма.
ваш виртуальный полигон имеет под собой основу (raw data), в виде сплошной записи данных (видеопокрытие трассы за сутки / неделю + 3D профилировка дорожной поверхности) ? или это идеализированная дорожная ситуация (AI moving agents over fiction or averaged test_tracks family).
что в итоге покупает (cruise feature cost & update service) Владелец, а что Эксплуатант транспортного средства ? помимо описанной в статье стандартной эргономики для Водителя / Удаленного Оператора / Автономного Робота.
.../// Вообще кортексы довольно быстрые, и оптимизация требуется только когда скорость обработки начинает доходить до сотни тысяч операций в секунду. ///...
.../// Обычно нам известно, какая точность нужна, и можно от fp отказаться. ///...
Именно так,
перед тем как заняться реализацией вычислительного процесса, для управления любым актуатором и измерителем:
нужно задаться требуемой (физической / кинематической) динамикой, которую нужно выдать или получить от актуатора и измерителя;
после чего перевести (конструктивная реализация с экономическими ограничениями, мотор + инвертор и выборка-хранение + АЦП) динамику в набор электрических последовательностей "фазных обмоток итп", наилучшей или выбранной формы + периодичности;
в итоге семейства электрических последовательностей, отражающие динамику, на 95% определяют как сам Алгоритм управления, так и его разрядность (5% фактические глюки конкретного чипа и аналогичное на всех этапах разработки и компиляции от кода до бинерника).
В портфолио компании (автора поста) - есть два проекта, реализованные в интересах логистической компании (оптимизация логистики, расчет стоимости перевозки) => проявляется необходимость анализа затрат на физическое перемещение груза (rolling_stock - traction - (re)fueling & loading - unloading - dispatch - receive) от полки до полки.
Исходя из текущей, доминирующей (в инвестиционном плане) идеологии (local - hub - intercity - hub - local) и оставляя за периметром анализа все операции по формированию / разборке грузовой партии и претензионные процедуры по факту порчи груза (за время intercity transportation);
было бы интересно узнать видение компании (автора поста) о следующем:
какой набор критериев для rolling stock + traction + (re)fueling && intercity only, требуется выставить Логистической компании в адрес Перевозчика (оператор Транспортнного Средства) ? Соответсвие критериям = = заключение контракта на перевозку(и);
кто платит за energy (топливо для перевозки в любом виде) & tollway(s) $ insurance ? Cargo || Carrier;
абстрагируясь от конкретной архитектуры и конструкции Транспортного Средства, чем выгодно владеть Логистической компании ? rolling stock || traction || energy_units (а для случая leading_tractor / energy_station + slave(s)_rolling_stock ?)
Ясное видение об этом гарантирует контракт как на создание Транспортного Средства, так и на операционную деятельность для парка таких Транспортных Средств. Будет ли это true_autonomous || remote_controlled_partial_autonomous - на сегодня, на практике это только стоимость риска ущерба для третьих лиц и инфраструктуры (по мнению законодателей Техаса, Флориды, Квебека как минимум).
Полная Задача (antiSway) - математически должна быть разделена на две части:
a) удержание Груза в заданной 3D области, бесконечно долгое время, без превышения лимита затрачиваемой энергии на такое удержание (maxEloop - прямая производная от доступной динамики "Приводов" + нелинейная реакция "кинематики" при одновременном воздействии Приводов и инерции Груза).
Если maxEloop < maxEexternal (внешние воздействия за тот же период), то решение по траектории удержаниея - существует и де факто сводится к вариациям бесконечной 3D восьмерке, образованной пересечением области удержания (сфера, эллипсоид, итп) и области движения кинематики (цилиндрическая область для боьшинства случаев), то есть включая перемещение Груза по вертикали (переход потенциальной энергии в кинетическую).https://ru.wikipedia.org/wiki/Кривая_Вивиани
б) удержание Груза на заданном удалении от расчетной траектории, за конечное время, без превышения лимита затрачиваемой энергии на компенсацию "инерционной оттяжки" (maxEtime - прямая производная от перемещения Массы по траектории с известной переменной скоростью).
Если maxEtime < maxEexternal + maxEdrive, то решение существует и траектория движения Груза, может быть описана для минимум трех участков, для кривых минимум трего порядка).
б1) для любого момента времени когда известна накопленная инерция Груза, возможно построение траектории подъема или опускания (половина 3D воьмерки), когда кинетическая энергия переходит в потенциальную - за минимальное время и далее переход к случаю а).
Итого. Если траектория не может быть выстроена заранее (задан лимит времени на перемещение, известны координаты начала и завершения), то требуется на каждом шаге решения знать накопленную инерцию Груза (subroutineCargoInertia) и выстраивать для каждого следующего шага решения компенсационную траекторию (subroutineSwayToZero).
Тогда время для трех шагов решения - есть минимальный цикл компенсации. Изменяя темп расчета (до пределов возможностей приводов и кинематки) - получается более длинный или более короткий "отлет" Груза в плане (начало и завершение фиолетового участка), аналогично для набора инерции Груза (синий участок).
То есть исходно необходимо иметь матмодель "подъемника" (включая прогиб ферм, растяжение тросов, проскальзывание итп) и захвата (свободно вращающийся крюк в простейщем варианте), после чего определить сколько возможно потратить на набор датчиков (precision / dataRate vs lifeCycleCost), достаточных для расчета инерции Груза (начните с пустого захвата, в качестве Груза).
Если решается обратная задача Cargo + Sway + environment => Crane/Lift design requirements, то исходно необходимо иметь набор траекторий и грузов (сценарии применения + статистика перемещений).
(Траектории) Синий (подъем) -> ::Желтый (перемещение) -> Фиолетовый (опускание) участки траекторий, представляют собой кубические сплайны, 3-ий порядок сплайна достаточен для всех видов тросовых подъемных систем. Большие порядки, спиральные формы применяются для жесткой кинематики и систем с электрической рекуперацией, где более важна гладкость второй и более производных (каждый разгон и торможение Груза = затраты энергии, F(t)=m*a(t) ).
Вращайте плоскости (показаны специально, угол вращения есть параметр; также как угол наклона сплошного Зеленого отрезка) на которых построены Синии и Фиолетовый сплайны, задавайте предельное отклонение Желтого сплайна от Зеленого отрезка => :Желтый сплайн будет иметь единственную наивыгоднейшую форму.
Синий сплайн имеет "экспоненциальную" форму (перед началом подъема, уже точно известо в какую сторону вести груз), Задавая/измеряя профиль скорости подъема и подъемную силу (энкодер и сила тока тягового двигателя, как минимальный вариант) -> получите массу Груза. Ваша цель - разогнать Груз в заданную сторону, чтобы Каретка на Стреле двигалась линейно (паралелельно и в плоскости сплошной Зеленой линии), тогда Груз отклониться и пойдет по Желтому сплайну (инерционная оттяжка).
Фиолетовый сплайн, имеет форму "гашения инерции" (контрольная точка обращение в ноль горизонтальной Скорости и Ускорения). При дальнейшем опускании, существует единственный профиль темпа перемещения Каретки и Стрелы, когда горизонтальный колебания Груза переходят во вращательные колебания относительно центра Масс Груза (де факто в прецессию вокруг Z оси). Нужно успеть опустить Груз на опору за время пока накопленная Инерция Груза переходит "из одного состояния в другое". При необходимости зависания Груза, профиль темпа перемщения Каретки и Стрелы имеет несколько вариантов для сохранения колебания/прецесии вокруг центра масс груза (собственные частоты колебаний систкмы Груз/Захват/Подвес), то есть минимальные отклонения в горизонтаьной плоскости.
(Алгоритм и математические преобразования) - пишите в личку.
для абсолютного большинства случаев, принцип расчета оптимальной траектории (картинка выше) - достаточен.
Стационарные положения в начале и на завершении траектории, плюс известные значения cargoMass, cargoVelocity, cargoWindDrag, windVelocityVector - jпозволяют однозначно рассчитать число Джоулей, для перемещения cargo из одной точки в другую по траектории с заданной динамикой.и ориентацией.
Правила безопасности при подъеме / перемещении грузов - требуют наложения ограничений на положение груза в каждой точке траектории. Управляющий (приводами) алгоритм, работает от обратного (на каждом шаге) - берет на вход текущие значения инерционных характеристик груза + будущую позицию и ориентацию груза, далее по классике высчитываем потребную для шага энергию, под заданную "кинематическую матрицу".
Все виды компенсаций от раскачивания, порывов ветра, смещения груза - сводятся к изменению шага "интегрирования", то есть темпу вычислений (до предела возможностей приводов и прочности конструкции).
\\\... Постановка задачи: прийти в заданную позицию за наименьшее количество времени, не превышая доступную скорость и без раскачивания груза. Все ограничения взяты из характеристик стенда, для которого производятся расчеты. ...///
(из практики) Постановка задачи (для разработки математического алгоритма решения и вытекающих электро-механических требований к приводным механизмам и кинематической конструкции):
Выполнить захват/перемещение/освобождение/возврат_пустого SingleCargoUnit из позиции LoadPoint в позицию ReleasePoint (аналогично для MultiCargoUnits = = план погрузки)
за время, менее заданного лимита, без превышения максимального ускорения для Груза;
с нахождением минимальной полной стоимости Погрузки (Энергия + Расход ресурса агрегатов => будут несколько оптимумов, для разных кобинаций приводных агрегатов и вариантов кинематики);
Что в итоге приводит к набору Траекторий и динамике по траектории, для перемещения Груза. После чего математический аппарат и алгоритм, будут существенно отличаться от предложенного выше, а с учетом "посадки на заданную вычислительную архитектуру" - измениться еще больше и поменяется до неузнаваемоти.когда опора крана, точка места взятия груза, точка места освобождения груза - будут подвижны + ветер + охлаждение/перегрев/изменение темпа работы агрегатов (в частности перегрузка судно-судно в открытом море).
Итого: рекомендую разрабатывать controlAlgorithm, когда на входе заданы для Груза: сплайн Траектории, сплайн(ом) Ориентации, сплайн(ом) Скорости, смещение точки захвата относительно центра масс (опционально).
На выходе алгоритма 2D экономайзер (то что видит Оператор или Робот), KWt*hr vs Money (расход ресурса агрегатов). Задача оператора или Робота управлять "джойстиком / api command", удерживая точку слежения экономайзера в заданной 2D области.
IT'шникам сие необходимо для разработки / совершенствования / документирования API, CAD программы, для автоматизированного выбора / построения / изменения подобных узлов, через работу внешнего алгоритма
Hey "CHAT GPT" ! спроектируй мне Ангар, ... и далее список пожеланий и ограничений к Ангару
Ибо некоторые CAD имеют столь неудобный API, что никакие python / wrappers / etc не помогают. Так что ждем jn bniybrjd (binary) API, сразу нативный для Chat / Voice / Gesture GPT. То есть с выходом не линейно-рекурсивных текстовых макрос(ов), а сразу несколько конкурирующих бинарных потоков, задающих и изменяющих элементы узла.
начните с Matlab / Simulink + SolidWorks + RecurDyn
совершенствуйтесь в VHDL, изучайте алгоритмы многопараметрической оптимизации, перед соблазном применить нейросеть "везде и всюду" в задаче управления группой Объектов - попробуйте "нейросетью" собрать фланцевое соединение (на поверхности лежат: два плоских фланца, кольцевая прокладка, шпильки, шайбы, гроверы, гайки - в режиме обучения спозиционируте фланцы и прокладку в простарнстве, выполните одно соединение на шпильку, в итоге ИИ должен сам собрать фланец с разным числом отверстий и их диаметром, то есть разные шпильки / гайки)
ваша цель - понять какое количество, вид и характеристики физически реализуемых датчиков обратной связи потребуется чтобы Цифровой Двойник, мог быть использован для прогнозирования поведения реальной машины и процессов взаимодействия машин между собой и окружающей средой
///...Краны позиционируются по QR кодам, всё верно. Единственное — на кранах нет весовых датчиков.../// ///...Логистика ковшей довольна сложна, это большая сеть жд путей....///
У вкас есть парметризованные моделиОбъектов, описывающие динамику / затраты ресурсов Крана и transferRoute(s) (ж/д путь его профиль и состояние + локомотив + платформы) ?
Ваша оптимизацимонная модельПроцесса, может выдавать требования к моделямОбъеков, для поиска глобального оптимума Процес + Объекты ?
В итоге задача сведется именно к возможностям Объектов (экономически обоснованным).
NB модельОбъекта, включает в себя и отказы и нестабильную работу и время на восстановление работоспособности (модельОператора, человека или Робота, входящая в модельОбъекта, сознательно исключена из контекста вопросов, заданных выше).
Стоимость подготовки объекта - пропорциональна количеству, объему и скорости сбора/передачи данных от субобъектов в Алгоритм обучения/ оптимизации/ (короткого) планирования.
может состоять только из затрат на совершенствование Алгоритма и содержание вычислительной мощности для Алгоритма;
при последовательном переносе функций сбора данных об объекте (рудник) и субобъекте (горная машина), в стоимость субобъекта ("умная" горная машина);
стоимость приобретения Алгоритма и Субобъектов, инвестиционная сосотавляющая.
необходимость сбора и передачи данных от субобъектов в реальном времени (темп пакетов менее 10мс, ограничен сверху временем реакции автопилота или водителя-человека), однозначно определяется требованиями горного надзора (успеть среагировать) и временем на ремонт субобъекта (уменьшение риска аварии, уменьшение темпа выработки механическоо/ электрического/ электронного ресурса).
Время построения/ перестроения/ поверки Цифрового Двойника Объекта, равно сроку развертывания Алгоритма и отладки каналов передачи данных от субобъектов в Алгоритм (потери, задержки, темп выборки):
к моменту начала устойчивой работы Алгоритма (синхронизация потоков входных и выходных данных, получаемых и отлаваемых без ошибок),
Цифровой Двойник уже имеет достаточно собранных данных, для функционироания Алгоритма с целевой эффективностью более 85% (ухудшение относительно исходного уровня управления объектом, 100%);
перебор гипотез/ обучение/ оптимизация/ отладка аварийных жестких сценариев реагирования, доводят эффективность до 150% и более;
где эффективность есть параметр деньги / тонна сырья на входе в ГОК.
На севере Швеции, Норвегии, в горах Колорадо, пустынях Чили
удорожание субобъектов от базового функционала 225%+ (контракт жизненного цикла);
время выхода Алгоритма на 100% эффективность +90 дней от даты поставки последнего из минимально-необходимого количества "умных" субобъектов: -минимальное количество, характеристики, требования и типовые наборы умных субобъектов, уже имеются в Алгоритме (для разных типов горной добычи).
Контроллер сервоприводов - не есть абстракция, схемотехническая или алгоритмическая исходно - это источник тока, работающий на комплексную нагрузку с нелинейным откликом и термо-механическими ограничениями (учет изменяющегося тогового момента и нагрева обмоток); и источник напряжения - работающий на датчик(и) обратной связи со своими передаточными характеристиками, для расчета сигнала(ов) обратной связи (учет изменения передаточной х-ки датчика от изменения амплитуды и формы питающего напряжения).
Создание или получение математической модели - полной электромеханической нагрузки (двигатель, редуктор, исполнительноый "рычаг", ребра охлаждения итп) и физикоэлектрического отклика от датчика(ов) обратной связи; в том числе для семейства нагрузок и датчиков (ограничения к применению)
есть первый шаг к проектированию сервоконтроллера.
Второй шаг - разработка API, то есть перечня функций которые реализуются для исполнительного объекта ("рычага"), для взаимодействия с внешне управляющей системой (от физических кнопок прямого действия до программируемых скриптов исполнения)..
После чего возможно получить диапазоны амплитуды и формы токов / напряжений, которые нужно сгенерировать для катушек и интерпретировать от датчиков ОС.
чтобы иметь возможность сравнить в итоге на стенде или в полевых условиях, сигналы прямого воздействия, плюс отклика датчиков ОС и механического отклика исполнительного объекта;
в том числе для автоматической коррекции параметров управляющего алгоритма.
Конструкторская, схемотехническая и экономическая задачи, генерации необходимых амплитуд и форм тока и напряжения и обработки электрических сигналов ОС
есть завершающая часть проектирования;
но не исходная (механическая нагрузка определяет двигатель, двигатель определяет привод).
Разумное желание автора >> монетизировать свои знания = = разработка и отладка mid-layer software для управления электро-пьезо-пневмо-гидро-механическими системами.
И монетизация достижима, когда представлен минимальный набор в виртуальном пространстве (для демонстрации превосходства собственных идей, над текущим уровнем рынка или исходными пожеланиями инвесторов):
3-5-7 years support plan for equipment and components;
mid-layer control software up to (integration)API + maintenance prediction;
(embedded) firmware, учитывающее физические особенности каждого исполнительного узла = актуатор + связянные механические компоненты;
FMI model << rigid-flexible multi-body model << full-flexible-model << electromagnetic, pneumatic, etc actuator's multi-physics models.
После чего стандартный набор технико-экономических действий, приведет к выпуску единичного образца как минимум, результаты испытаний которого предоставят автору выбор - в каком месте планеты земля: зарегестрировать IP + know-how, и где и чьими силами организовать production.
///... Но возникает вопрос: "а что считать оптимальным решением?" Работа по производству велосипедов закипела....///
Потому что производители радаров/лидаров/видео-стерео-пар/etc, изначально решают свои задачи "технического совершенства" и по готовности новой модели радара приходят к Разработчикам motion_control / track_planning / situational awareness c предложением интегрировать новые возможности по precision / scan_freq / delay ..... = = то есть применить новую модель Jetson / ZYNQ / S32 / etc, при том что и предыдущие чипы не загружаются решением боле чем на 70%, и на сельхоз технике и на шоссейных грузовиках.
При том что Разработчики motion_control / track_planning / situational awareness, исходно выдают конкреные требования что, в каком формате и с каким темпом требуется на выходе радара = = то есть решать целевую задачу в первую очередь (автоматическая парковка, как простейшая задача).
В итоге подобный оптимальный поход (набор целевых задач vs модель машины vs тираж) на сегодня практикуется у немецкого и шведского производителя грузовиков, на легковых автомобилях требуют применять "самое совершеннное" >> глюки неизбежны, safety_compliant_reqs - failed (взамен есть опция отключить фичу) .... но в рекламном буклете машины фича есть, ибо уже нужно продавать новый модельный ряд.
///...Команда Транспорт ...Решаем внутренние расчётные задачи, делаем транспортные API...///
///... лучше километр по обычной дороге, чем метр по дороге с ограничением...///
С учетом двух фраз, приведенных выше, приходится беспилотному грузовику в южной части северо-американских штатов - иметь свой API, через который местный 2ГИС
не только выясняет (изменяыющиеся во времени) особенности cargoTransferObject (as struct: platformDynamic; operatorModel; cargoSet; energyForTransfer)
но и требует передать rawScanRouteData, где грузовик проехал за предыдущие сутки (обновление мета-данных графа дорог)
также пытается (с переменным успехом) спросить все виды местых autorities и ремонтников: "что же еще сегодня вы успели изменить и можно ли этому доверять"
И только после этого, предлагает маршруты и перестривает теккущий маршрут - по факту мониторинга cargoTransferObject. Ибо не везде будет возможность развернуться (и иное доступное / разрешенное), заправится, заменить колесо трейлера, поменять тягач, подъехать эвакуатору, итд ... чем живо интересуется местная roadAdministration, c богатой фантазией )))
Вопрос, что ваш маршрутный Алгоритм принимает на вход, для построения исходного графа всех вариантов ?
NB все виды погодных условий, учтены в operatorModel.
PS маршрут покупается за деньги и когда маршрут от местного 2ГИС, не позволяет завершить перевозку вообще или с перерасходом предложеных лимитов по маршруту, то транспортник получает компенсацию (чем без стеснения пользуется местный 2ГИС, ибо дешевле отозвать маршрут и выплатить транспортнику деньги, чем признаться что проехать данному транспорту по данному маршруту в принципе невозможно).
///... при использование автопилота (ветер не кто не отменял, дрон должен иметь возможность для экстренного манёвра =>
///... К счастью нам не понадобилось писать с нуля автопилот, так как у нашего дрона Geoscan Pioneer max, он есть встроенный =>
///...но не смотря на это нам всё равно понадобилось разработать алгоритм построения траектории движения !!!
-----
С чего-то нужно начинать, в том числе с изучения алгоритмов встроенного (в выбранную транспортную платформу) автопилота, для начала на уровне API.
Алгоритм построения траектории, учитывает какой-то перечень параметров - опубликуете (перечень) ? А возможно и структуру траекторного алгоритма, хоть бы и в stateFlow виде.
Верный и правильный подход - конструкция / идея - Тара и Замок, есть то что определяет виды применения и коммерциализацию..
Второе неотделимое друг от друга - Алгоритм автопилота и конструктивная идея Посадочной площадки. Буду ожидать второй заявленной публикации (Автпилот) - в надежде увидеть абстрактный Алгоритм, реализующий подходы к реализации Автопилота:
вне зависимости от среды движения, воздух, жидкость, твердые частицы-газо-жидкостная смесь капли струи пыль взвесь град;
отделение / приосоединение к качающейся площадке;
упрощение алгоритма Автопилота, за счет конструкции посадочной площадки
Реальная задача - обслуживание морских ветряков, с борта морского дрона-обслуживания или с автомобиля на береговой линии, поднять / вернуть капсулу с грузом на гондолу работающего ветряка. Вытекающая будущая задача - в корзине люди.
С Победой !
любое решение достигающее практической / поставленной цели - есть успех.
Вопрос, исходя из вытекающего действия, после остановки перед Целью:
- появится ли новая параллельная ветвь и новые "concat"; в представленной вами структуре Алгоритма,
- или же вы добавите только дополнительные блоки FC / LSTM ?
- или возможно что-то более изящное;
- (суть дела) когда в ракурсе RGB-D_sensor, появится (рука)Манипулятор(ы), которым нужно дотянуться до ручки дверцы холодильника и открыть / закрыть такую дверцу;
- иное подобное, когда в ракурсе сенсора, появляются движущиеся Объекты, которые нужно позиционироввать одновременно относительно Базы и относительно ЧастиОбъекта.
Георадар !
был рад прочитать что есть разработчики, понимающие всю "непредсказуемость" GNSS и вычисолительные затраты на рспознавание визуальных контуров окружающих зданий.
Делаю аналогичное сейчас для локализации относительно поверхности и придонного слоя подводного рельефа.
Интерсно к чему вы пришли в части кратности снижения вычислительных затрат, при рспознвании отклика георадара в сравнении с затратами на лидарное / визуальное распознавание.
'//... На семинаре будет показан подход к тестированию алгоритмов систем помощи водителю, позволяющий значительно сократить количество натурных испытаний за счёт использования виртуального полигона. ///
Алгоритм управления Тягой и Направлением движения (первый уровень абстракции над над комплектом приводов, кинематики и механических ообенностей объединяющей "рамы / кузова / шарнирно сочлененных рам",
напрямую зависит от степени достоверности Виртуального Полигона к реальной ситуации, вдоль маршрута(скмейства маршрутов)
и перечня вводных маркетинговых установок Разработчику, то есть что продается от лица Автопроизводиеля - Владельцу и Эксплуатанту (разное целеполагание) транспортного средсва.
Вопросы:
что из себя представляет ваш виртуальный полигон ? А именно какой набор мгновенных сигналов (локальная зона) и общей информации (весь маршрут(ы), можно считывать в адрес Алгоритма.
ваш виртуальный полигон имеет под собой основу (raw data), в виде сплошной записи данных (видеопокрытие трассы за сутки / неделю + 3D профилировка дорожной поверхности) ? или это идеализированная дорожная ситуация (AI moving agents over fiction or averaged test_tracks family).
что в итоге покупает (cruise feature cost & update service) Владелец, а что Эксплуатант транспортного средства ? помимо описанной в статье стандартной эргономики для Водителя / Удаленного Оператора / Автономного Робота.
Спасибо.
.../// Вообще кортексы довольно быстрые, и оптимизация требуется только когда скорость обработки начинает доходить до сотни тысяч операций в секунду. ///...
.../// Обычно нам известно, какая точность нужна, и можно от fp отказаться. ///...
Именно так,
перед тем как заняться реализацией вычислительного процесса, для управления любым актуатором и измерителем:
нужно задаться требуемой (физической / кинематической) динамикой, которую нужно выдать или получить от актуатора и измерителя;
после чего перевести (конструктивная реализация с экономическими ограничениями, мотор + инвертор и выборка-хранение + АЦП) динамику в набор электрических последовательностей "фазных обмоток итп", наилучшей или выбранной формы + периодичности;
в итоге семейства электрических последовательностей, отражающие динамику, на 95% определяют как сам Алгоритм управления, так и его разрядность (5% фактические глюки конкретного чипа и аналогичное на всех этапах разработки и компиляции от кода до бинерника).
"RAHU" (производство Punane RET, Таллинн, Эстония)
- УКВ радиоприемник - таймер (включает в выключает радио), настройка частоты приема - вращение глобуса.
-NB до сих пор работает
В портфолио компании (автора поста) - есть два проекта, реализованные в интересах логистической компании (оптимизация логистики, расчет стоимости перевозки) => проявляется необходимость анализа затрат на физическое перемещение груза (rolling_stock - traction - (re)fueling & loading - unloading - dispatch - receive) от полки до полки.
Исходя из текущей, доминирующей (в инвестиционном плане) идеологии (local - hub - intercity - hub - local) и оставляя за периметром анализа все операции по формированию / разборке грузовой партии и претензионные процедуры по факту порчи груза (за время intercity transportation);
было бы интересно узнать видение компании (автора поста) о следующем:
какой набор критериев для rolling stock + traction + (re)fueling && intercity only, требуется выставить Логистической компании в адрес Перевозчика (оператор Транспортнного Средства) ? Соответсвие критериям = = заключение контракта на перевозку(и);
кто платит за energy (топливо для перевозки в любом виде) & tollway(s) $ insurance ? Cargo || Carrier;
абстрагируясь от конкретной архитектуры и конструкции Транспортного Средства, чем выгодно владеть Логистической компании ? rolling stock || traction || energy_units (а для случая leading_tractor / energy_station + slave(s)_rolling_stock ?)
Ясное видение об этом гарантирует контракт как на создание Транспортного Средства, так и на операционную деятельность для парка таких Транспортных Средств. Будет ли это true_autonomous || remote_controlled_partial_autonomous - на сегодня, на практике это только стоимость риска ущерба для третьих лиц и инфраструктуры (по мнению законодателей Техаса, Флориды, Квебека как минимум).
Полная Задача (antiSway) - математически должна быть разделена на две части:
a) удержание Груза в заданной 3D области, бесконечно долгое время, без превышения лимита затрачиваемой энергии на такое удержание (maxEloop - прямая производная от доступной динамики "Приводов" + нелинейная реакция "кинематики" при одновременном воздействии Приводов и инерции Груза).
Если maxEloop < maxEexternal (внешние воздействия за тот же период), то решение по траектории удержаниея - существует и де факто сводится к вариациям бесконечной 3D восьмерке, образованной пересечением области удержания (сфера, эллипсоид, итп) и области движения кинематики (цилиндрическая область для боьшинства случаев), то есть включая перемещение Груза по вертикали (переход потенциальной энергии в кинетическую).https://ru.wikipedia.org/wiki/Кривая_Вивиани
б) удержание Груза на заданном удалении от расчетной траектории, за конечное время, без превышения лимита затрачиваемой энергии на компенсацию "инерционной оттяжки" (maxEtime - прямая производная от перемещения Массы по траектории с известной переменной скоростью).
Если maxEtime < maxEexternal + maxEdrive, то решение существует и траектория движения Груза, может быть описана для минимум трех участков, для кривых минимум трего порядка).
б1) для любого момента времени когда известна накопленная инерция Груза, возможно построение траектории подъема или опускания (половина 3D воьмерки), когда кинетическая энергия переходит в потенциальную - за минимальное время и далее переход к случаю а).
Итого. Если траектория не может быть выстроена заранее (задан лимит времени на перемещение, известны координаты начала и завершения), то требуется на каждом шаге решения знать накопленную инерцию Груза (subroutineCargoInertia) и выстраивать для каждого следующего шага решения компенсационную траекторию (subroutineSwayToZero).
Тогда время для трех шагов решения - есть минимальный цикл компенсации. Изменяя темп расчета (до пределов возможностей приводов и кинематки) - получается более длинный или более короткий "отлет" Груза в плане (начало и завершение фиолетового участка), аналогично для набора инерции Груза (синий участок).
То есть исходно необходимо иметь матмодель "подъемника" (включая прогиб ферм, растяжение тросов, проскальзывание итп) и захвата (свободно вращающийся крюк в простейщем варианте), после чего определить сколько возможно потратить на набор датчиков (precision / dataRate vs lifeCycleCost), достаточных для расчета инерции Груза (начните с пустого захвата, в качестве Груза).
Если решается обратная задача Cargo + Sway + environment => Crane/Lift design requirements, то исходно необходимо иметь набор траекторий и грузов (сценарии применения + статистика перемещений).
(Траектории) Синий (подъем) -> ::Желтый (перемещение) -> Фиолетовый (опускание) участки траекторий, представляют собой кубические сплайны, 3-ий порядок сплайна достаточен для всех видов тросовых подъемных систем. Большие порядки, спиральные формы применяются для жесткой кинематики и систем с электрической рекуперацией, где более важна гладкость второй и более производных (каждый разгон и торможение Груза = затраты энергии, F(t)=m*a(t) ).
Вращайте плоскости (показаны специально, угол вращения есть параметр; также как угол наклона сплошного Зеленого отрезка) на которых построены Синии и Фиолетовый сплайны, задавайте предельное отклонение Желтого сплайна от Зеленого отрезка => :Желтый сплайн будет иметь единственную наивыгоднейшую форму.
Синий сплайн имеет "экспоненциальную" форму (перед началом подъема, уже точно известо в какую сторону вести груз), Задавая/измеряя профиль скорости подъема и подъемную силу (энкодер и сила тока тягового двигателя, как минимальный вариант) -> получите массу Груза. Ваша цель - разогнать Груз в заданную сторону, чтобы Каретка на Стреле двигалась линейно (паралелельно и в плоскости сплошной Зеленой линии), тогда Груз отклониться и пойдет по Желтому сплайну (инерционная оттяжка).
Фиолетовый сплайн, имеет форму "гашения инерции" (контрольная точка обращение в ноль горизонтальной Скорости и Ускорения). При дальнейшем опускании, существует единственный профиль темпа перемещения Каретки и Стрелы, когда горизонтальный колебания Груза переходят во вращательные колебания относительно центра Масс Груза (де факто в прецессию вокруг Z оси). Нужно успеть опустить Груз на опору за время пока накопленная Инерция Груза переходит "из одного состояния в другое". При необходимости зависания Груза, профиль темпа перемщения Каретки и Стрелы имеет несколько вариантов для сохранения колебания/прецесии вокруг центра масс груза (собственные частоты колебаний систкмы Груз/Захват/Подвес), то есть минимальные отклонения в горизонтаьной плоскости.
(Алгоритм и математические преобразования) - пишите в личку.
для абсолютного большинства случаев, принцип расчета оптимальной траектории (картинка выше) - достаточен.
Стационарные положения в начале и на завершении траектории, плюс известные значения cargoMass, cargoVelocity, cargoWindDrag, windVelocityVector - jпозволяют однозначно рассчитать число Джоулей, для перемещения cargo из одной точки в другую по траектории с заданной динамикой.и ориентацией.
Правила безопасности при подъеме / перемещении грузов - требуют наложения ограничений на положение груза в каждой точке траектории. Управляющий (приводами) алгоритм, работает от обратного (на каждом шаге) - берет на вход текущие значения инерционных характеристик груза + будущую позицию и ориентацию груза, далее по классике высчитываем потребную для шага энергию, под заданную "кинематическую матрицу".
Все виды компенсаций от раскачивания, порывов ветра, смещения груза - сводятся к изменению шага "интегрирования", то есть темпу вычислений (до предела возможностей приводов и прочности конструкции).
\\\... Постановка задачи: прийти в заданную позицию за наименьшее количество времени, не превышая доступную скорость и без раскачивания груза. Все ограничения взяты из характеристик стенда, для которого производятся расчеты. ...///
(из практики) Постановка задачи (для разработки математического алгоритма решения и вытекающих электро-механических требований к приводным механизмам и кинематической конструкции):
Выполнить захват/перемещение/освобождение/возврат_пустого SingleCargoUnit из позиции LoadPoint в позицию ReleasePoint (аналогично для MultiCargoUnits = = план погрузки)
за время, менее заданного лимита, без превышения максимального ускорения для Груза;
с нахождением минимальной полной стоимости Погрузки (Энергия + Расход ресурса агрегатов => будут несколько оптимумов, для разных кобинаций приводных агрегатов и вариантов кинематики);
Что в итоге приводит к набору Траекторий и динамике по траектории, для перемещения Груза. После чего математический аппарат и алгоритм, будут существенно отличаться от предложенного выше, а с учетом "посадки на заданную вычислительную архитектуру" - измениться еще больше и поменяется до неузнаваемоти.когда опора крана, точка места взятия груза, точка места освобождения груза - будут подвижны + ветер + охлаждение/перегрев/изменение темпа работы агрегатов (в частности перегрузка судно-судно в открытом море).
Итого: рекомендую разрабатывать controlAlgorithm, когда на входе заданы для Груза: сплайн Траектории, сплайн(ом) Ориентации, сплайн(ом) Скорости, смещение точки захвата относительно центра масс (опционально).
На выходе алгоритма 2D экономайзер (то что видит Оператор или Робот), KWt*hr vs Money (расход ресурса агрегатов). Задача оператора или Робота управлять "джойстиком / api command", удерживая точку слежения экономайзера в заданной 2D области.
IT'шникам сие необходимо для разработки / совершенствования / документирования API, CAD программы, для автоматизированного выбора / построения / изменения подобных узлов, через работу внешнего алгоритма
Hey "CHAT GPT" ! спроектируй мне Ангар, ... и далее список пожеланий и ограничений к Ангару
Ибо некоторые CAD имеют столь неудобный API, что никакие python / wrappers / etc не помогают. Так что ждем jn bniybrjd (binary) API, сразу нативный для Chat / Voice / Gesture GPT. То есть с выходом не линейно-рекурсивных текстовых макрос(ов), а сразу несколько конкурирующих бинарных потоков, задающих и изменяющих элементы узла.
начните с Matlab / Simulink + SolidWorks + RecurDyn
совершенствуйтесь в VHDL, изучайте алгоритмы многопараметрической оптимизации, перед соблазном применить нейросеть "везде и всюду" в задаче управления группой Объектов - попробуйте "нейросетью" собрать фланцевое соединение (на поверхности лежат: два плоских фланца, кольцевая прокладка, шпильки, шайбы, гроверы, гайки - в режиме обучения спозиционируте фланцы и прокладку в простарнстве, выполните одно соединение на шпильку, в итоге ИИ должен сам собрать фланец с разным числом отверстий и их диаметром, то есть разные шпильки / гайки)
ваша цель - понять какое количество, вид и характеристики физически реализуемых датчиков обратной связи потребуется чтобы Цифровой Двойник, мог быть использован для прогнозирования поведения реальной машины и процессов взаимодействия машин между собой и окружающей средой
///...Краны позиционируются по QR кодам, всё верно. Единственное — на кранах нет весовых датчиков...///
///...Логистика ковшей довольна сложна, это большая сеть жд путей....///
У вкас есть парметризованные моделиОбъектов, описывающие динамику / затраты ресурсов Крана и transferRoute(s) (ж/д путь его профиль и состояние + локомотив + платформы) ?
Ваша оптимизацимонная модельПроцесса, может выдавать требования к моделямОбъеков, для поиска глобального оптимума Процес + Объекты ?
В итоге задача сведется именно к возможностям Объектов (экономически обоснованным).
NB модельОбъекта, включает в себя и отказы и нестабильную работу и время на восстановление работоспособности (модельОператора, человека или Робота, входящая в модельОбъекта, сознательно исключена из контекста вопросов, заданных выше).
Стоимость подготовки объекта - пропорциональна количеству, объему и скорости сбора/передачи данных от субобъектов в Алгоритм обучения/ оптимизации/ (короткого) планирования.
может состоять только из затрат на совершенствование Алгоритма и содержание вычислительной мощности для Алгоритма;
при последовательном переносе функций сбора данных об объекте (рудник) и субобъекте (горная машина), в стоимость субобъекта ("умная" горная машина);
стоимость приобретения Алгоритма и Субобъектов, инвестиционная сосотавляющая.
необходимость сбора и передачи данных от субобъектов в реальном времени (темп пакетов менее 10мс, ограничен сверху временем реакции автопилота или водителя-человека), однозначно определяется требованиями горного надзора (успеть среагировать) и временем на ремонт субобъекта (уменьшение риска аварии, уменьшение темпа выработки механическоо/ электрического/ электронного ресурса).
Время построения/ перестроения/ поверки Цифрового Двойника Объекта, равно сроку развертывания Алгоритма и отладки каналов передачи данных от субобъектов в Алгоритм (потери, задержки, темп выборки):
к моменту начала устойчивой работы Алгоритма (синхронизация потоков входных и выходных данных, получаемых и отлаваемых без ошибок),
Цифровой Двойник уже имеет достаточно собранных данных, для функционироания Алгоритма с целевой эффективностью более 85% (ухудшение относительно исходного уровня управления объектом, 100%);
перебор гипотез/ обучение/ оптимизация/ отладка аварийных жестких сценариев реагирования, доводят эффективность до 150% и более;
где эффективность есть параметр деньги / тонна сырья на входе в ГОК.
На севере Швеции, Норвегии, в горах Колорадо, пустынях Чили
удорожание субобъектов от базового функционала 225%+ (контракт жизненного цикла);
время выхода Алгоритма на 100% эффективность +90 дней от даты поставки последнего из минимально-необходимого количества "умных" субобъектов: -минимальное количество, характеристики, требования и типовые наборы умных субобъектов, уже имеются в Алгоритме (для разных типов горной добычи).
Контроллер сервоприводов - не есть абстракция, схемотехническая или алгоритмическая
исходно - это источник тока, работающий на комплексную нагрузку с нелинейным откликом и термо-механическими ограничениями (учет изменяющегося тогового момента и нагрева обмоток);
и источник напряжения - работающий на датчик(и) обратной связи со своими передаточными характеристиками, для расчета сигнала(ов) обратной связи (учет изменения передаточной х-ки датчика от изменения амплитуды и формы питающего напряжения).
Создание или получение математической модели - полной электромеханической нагрузки (двигатель, редуктор, исполнительноый "рычаг", ребра охлаждения итп) и физикоэлектрического отклика от датчика(ов) обратной связи; в том числе для семейства нагрузок и датчиков (ограничения к применению)
есть первый шаг к проектированию сервоконтроллера.
Второй шаг - разработка API, то есть перечня функций которые реализуются для исполнительного объекта ("рычага"), для взаимодействия с внешне управляющей системой (от физических кнопок прямого действия до программируемых скриптов исполнения)..
После чего возможно получить диапазоны амплитуды и формы токов / напряжений, которые нужно сгенерировать для катушек и интерпретировать от датчиков ОС.
чтобы иметь возможность сравнить в итоге на стенде или в полевых условиях, сигналы прямого воздействия, плюс отклика датчиков ОС и механического отклика исполнительного объекта;
в том числе для автоматической коррекции параметров управляющего алгоритма.
Конструкторская, схемотехническая и экономическая задачи, генерации необходимых амплитуд и форм тока и напряжения и обработки электрических сигналов ОС
есть завершающая часть проектирования;
но не исходная (механическая нагрузка определяет двигатель, двигатель определяет привод).
Разумное желание автора >> монетизировать свои знания = = разработка и отладка mid-layer software для управления электро-пьезо-пневмо-гидро-механическими системами.
И монетизация достижима, когда представлен минимальный набор в виртуальном пространстве (для демонстрации превосходства собственных идей, над текущим уровнем рынка или исходными пожеланиями инвесторов):
3-5-7 years support plan for equipment and components;
mid-layer control software up to (integration)API + maintenance prediction;
(embedded) firmware, учитывающее физические особенности каждого исполнительного узла = актуатор + связянные механические компоненты;
FMI model << rigid-flexible multi-body model << full-flexible-model << electromagnetic, pneumatic, etc actuator's multi-physics models.
После чего стандартный набор технико-экономических действий, приведет к выпуску единичного образца как минимум, результаты испытаний которого предоставят автору выбор - в каком месте планеты земля: зарегестрировать IP + know-how, и где и чьими силами организовать production.
///... Но возникает вопрос: "а что считать оптимальным решением?"
Работа по производству велосипедов закипела....///Потому что производители радаров/лидаров/видео-стерео-пар/etc, изначально решают свои задачи "технического совершенства" и по готовности новой модели радара приходят к Разработчикам motion_control / track_planning / situational awareness c предложением интегрировать новые возможности по precision / scan_freq / delay ..... = = то есть применить новую модель Jetson / ZYNQ / S32 / etc, при том что и предыдущие чипы не загружаются решением боле чем на 70%, и на сельхоз технике и на шоссейных грузовиках.
При том что Разработчики motion_control / track_planning / situational awareness, исходно выдают конкреные требования что, в каком формате и с каким темпом требуется на выходе радара = = то есть решать целевую задачу в первую очередь (автоматическая парковка, как простейшая задача).
В итоге подобный оптимальный поход (набор целевых задач vs модель машины vs тираж) на сегодня практикуется у немецкого и шведского производителя грузовиков, на легковых автомобилях требуют применять "самое совершеннное" >> глюки неизбежны, safety_compliant_reqs - failed (взамен есть опция отключить фичу) .... но в рекламном буклете машины фича есть, ибо уже нужно продавать новый модельный ряд.