[Глобальные системы позиционирования, Программирование, Компиляторы, Lua, Робототехника] Umka и трактор: первый опыт практического применения нового языка

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
09-Дек-2020 15:31

Цитировать

С весны нынешнего года я разрабатываю статически типизированный встраиваемый скриптовый язык Umka, о концепции которого в своё время была статья на Хабре. При этом по своей основной профессии я занимаюсь алгоритмами систем автоматического руления тракторами — о некоторых подходах к комплексированию датчиков в этих системах я тоже писал. Теперь эти два направления деятельности причудливо пересеклись.Для исследования поведения трактора в некоторых специфических сценариях (например, на склонах при наличии бокового проскальзывания) понадобился программный симулятор трактора, который верно моделировал бы не только кинематику, но и динамику машины. При этом алгоритм контроллера руления предполагалось постоянно видоизменять и немедленно наблюдать эффект этих изменений. Для такой задачи тандем C++ и Umka выглядел вполне органичным: основной код симулятора, требующий высокого быстродействия, был реализован на C++, а логика контроллера была вынесена в скрипт на Umka.Вероятно, читатель уже заподозрил во мне нездоровую тягу к изобретению велосипедов. Попробую объясниться и заодно рассказать, что вышло из этой немного странной затеи.Зачем свой симулятор?Действительно, почему бы не взять готовый симулятор? Их масса: и Gazebo, и Project Chrono, да хоть игрушечный Farming Simulator со скриптами на Lua! Не стоит ожидать, что самостоятельно написанный симулятор сможет сравниться с ними по гибкости и мощи. Однако от инструмента для быстрого прототипирования контроллера руления вовсе не требовалось, например, достоверного моделирования нюансов работы трансмиссии трактора. Требовалось одно: быть готовым "уже вчера", и времени на освоение чрезвычайно громоздких проектов типа Project Chrono не оставалось. Было и ещё одно обстоятельство, о котором часто забывают, рассуждая о достоверности моделирования. Нет никакого смысла вводить дополнительные степени свободы в модель, дополнительные члены в уравнения, если нет возможности экспериментально оценить входящие туда новые численные параметры. Хочется смоделировать качку кабины относительно рамы трактора? Похвальное стремление, однако оно обречено на провал, если мы не в состоянии измерить упругость и коэффициент демпфирования тех амортизаторов, на которых установлена кабина. Хочется максимально реалистично смоделировать контакт колеса с грунтом? Отлично, к нашим услугам "волшебная формула" Пацейки. Однако вправду ли мы знаем те десятки параметров, которые входят в эту формулу и которые тотчас же изменятся, как только твёрдый грунт поля размякнет под дождём? Так не стоит ли ограничиться моделированием лишь тех эффектов, которые действительно представляют интерес и для которых мы способны измерить все параметры?Таким образом, оказался предпочтительным самый незамысловатый симулятор:

Уравнения динамики твёрдого тела с шестью степенями свободы;
Модель контакта шины с грунтом (4 параметра);
Модель круиз-контроля (2 параметра);
Модель рулевого привода (4 параметра);
Модели датчиков GNSS и IMU (5 параметров);
Простейшая графика на основе библиотеки raylib.

Скриншот симулятораЗачем свой язык?Сейчас в нише встраиваемых скриптовых языков почти безраздельно господствует Lua. Почему бы не взять её? Или, быть может, Python? Да и вообще, стоило ли выносить логику контроллера в скрипт, если сам симулятор настолько прост? Не следовало ли сделать контроллер частью симулятора? Что ж, даже с небольшим симулятором мы бы потеряли много времени, если бы вынуждены были перекомпилировать его всякий раз, когда вздумается попробовать ещё какой-нибудь алгоритмический трюк в контроллере. После десятка модификаций алгоритма выигрыш времени от использования внешнего скрипта ещё совершенно незаметен, после пары сотен — уже весьма ощутим. Пусть так, но почему не Lua или Python? Полагаю, субъективный фактор здесь очевиден: если симулятор предстояло разрабатывать мне и под рукой был собственный язык, который я знал намного лучше, чем Lua и даже Python, то грех было не воспользоваться своими наработками. Одновременно проект симулятора послужил и отличной проверкой возможностей языка "в боевых условиях". Кроме того, скрипт, разумеется, никогда не предназначался для непосредственного запуска в реальном контроллере трактора: там весь код написан на C++, поэтому никаких рисков для пользователей эти эксперименты со скриптами заведомо не несли. Что же касается Python, то сам по себе он вряд ли годится в качестве встраиваемого языка. Взаимодействие с Python, скорее всего, потребовало бы инфраструктуры ROS — громоздкой и несовместимой с Windows 7, что сразу затруднило бы работу с симулятором. Однако была и вполне объективная причина предпочесть Umka — его статическая типизация. Во-первых, не приходилось сначала запускать симулятор, прокладывать путь, включать контроллер — и лишь тогда обнаруживать несовместимость типов данных. Во-вторых, удалось легко и безо всяких дополнительных преобразований обмениваться структурами данных между кодом симулятора на C++ и скриптом на Umka. Вот, например, вызов функции расчёта управляющего воздействия — угла поворота рулевых колёс:

// C++
UmkaStackSlot param[] = {{.realVal = simOutput.was.steerAngle},
{.ptrVal = (int64_t)&simOutput.omega},
{.ptrVal = (int64_t)&simOutput.att},
{.ptrVal = (int64_t)&simOutput.vel},
{.ptrVal = (int64_t)&simOutput.pos},
{.realVal = t}};
UmkaStackSlot result = {0};
if (!umkaCall(umka, umkaGetFunc(umka, NULL, "update"),
sizeof(param) / sizeof(param[0]), param, &result))
{
UmkaError error;
umkaGetError(umka, &error);
printf("\nUmka runtime error %s (%d): %s\n",
error.fileName, error.line, error.msg);
break;
}
simInput.steerAngle = result.realVal;

// Umka
fn update(t: real, pos, vel, att, omega: ^mat.Vec, was: real): real {
// ...
}

Какие впечатления?Здесь читатель вправе усомниться в моей беспристрастности, однако первый практический опыт работы с Umka оказался в общем позитивным. Код на Umka оказывается чуть многословным из-за объявлений типов, но читается и пишется легко — во всяком случае для тех, кто испытывает хоть небольшую симпатию к Go. Впрочем, даже и тем моим коллегам, кто вовсе незнаком с Go, было нетрудно прочесть написанное. Полиморфизм (построенный на понятии интерфейса в духе того же Go) оказался полезен для унифицированного вычисления отклонения трактора от заданного пути, в качестве которого может выступать прямая, окружность, произвольная кривая. Сборщик мусора тоже не подвёл.Главное неудобство работы заключалось в отсутствии необходимых библиотек, что было весьма ожидаемым. Специально для этого проекта была написана простейшая векторно-матричная библиотека, которая удовлетворила минимальные потребности геометрических расчётов.В целом благодаря экспериментам с Umka удалось выявить и изучить два-три непредвиденных физических эффекта в контуре управления трактором — на сегодня это и есть основной полезный результат экспериментов с симулятором.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_globalnye_sistemy_pozitsionirovanija (Глобальные системы позиционирования), #_programmirovanie (Программирование), #_kompiljatory (Компиляторы), #_lua, #_robototehnika (Робототехника), #_embedded_languages, #_scripting_language, #_vstraivaemye_jazyki (встраиваемые языки), #_skriptovye_jazyki (скриптовые языки), #_interpretatory (интерпретаторы), #_kompiljatory (компиляторы), #_avtomaticheskoe_upravlenie (автоматическое управление), #_gnss, #_imu, #_globalnye_sistemy_pozitsionirovanija (
Глобальные системы позиционирования
), #_programmirovanie (
Программирование
), #_kompiljatory (
Компиляторы
), #_lua, #_robototehnika (
Робототехника
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 14:25
Часовой пояс: UTC + 5