Здравствуйте, cppguard, Вы писали: >Поэтому ABS это пример real-time system, но не real-time подхода к разработке. А меня, как разработчика, в первую очередь интеруют именно инструменты предоставления гарантии real-time.
Это вряд ли тот пример, на котором вся сложность реалтайма с т.з. софта и планирования возникает во всей красе, а здесь больше про автоматическое управление, обратную связь и всё такое. На входе поступает инфа от фиксированного количества датчиков, решается оптимизационная задача, где каждая итерация вычисления занимает фиксированное время. В результате управляющий сигнал подаётся на выход. С т.з. софта это, например, тот же бизи луп и поллинг, и основная сложность в хардовой архитектуре и выборе конкретных МК и шин данных, чтобы уложиться в максимальные величины длительности В/В и вычисления целевой функции. Если абсолютные величины (например, по шине ходят ещё какие-то данные от других подсистем) не фиксированы, может потребоваться контроль джиттера В/В, но хрен знает, нужно ли это для ABS.
И ABS'у связь с приборной панелью и остальным инфотейнментом нужна разве чтобы отправить "я сработал" или "я неисправен" в журнал событий или на приборную панель, но отправка этого всего тоже включается в расчет итерации бизи лупа.
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности".
Под этим термином могут пониматься разные вещи. Но в самом общем виде, это когда для работы программы имеет значение реальное (физическое) время, которое мы измеряем с помошью реальных (физических) часов.
Например, компьютерные игры бывают пошаговые, а бывают реального времени. В пошаговых играх время тоже может идти, например в Цивилизации за каждый ход проходит некоторое количество лет, но к физическим часам это отношения не имеет. В игре же реального времени, игровое время соответствует физическому, при этом гарантии, что игра не будет ингода притормаживать тебе никто не дает.
C>Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time?
Допустим у тебя есть обыкновенный видеофайл. В нем есть обычное видео, записанное с частотой 25 кадров в секунду и длиной 10 секунд. Тебе надо проиграть этот файл в реальном времени. У тебя мощное железо и хороший софт, который позволяет обработать и показать кадр 10 раза быстрее. То есть ты можешь проиграть 10 секундное видео за 1 секунду. По идее, если ты проиграешь видео за 1 секунду, ты в 10 секунд укладываешься, даже с большим запасом. Но это не real-time! Чтоб проиграть видео в реальном времени, время на видео должно идти с той же скоростью, что и физическое.
Если же у тебя слабое железо, и ты не успеваешь обрабатывать кадр за нужное время, ты можешь начать выкидывать какие-то кадры, ухудшить качество видео и тд и тп, но все равно проиграть его за те же 10 секунд.
C>Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Я специально ничего не стал писать про ОС реального времени. Это уже более узкое понятие. Если запущенный тобой процесс вообще не имеет никакого отношения к физическому времени, а просто что-то вычисляет, то он не будет real-time, даже если ты его запустишь на QNХ.
Здравствуйте, cppguard, Вы писали:
C>The Robot Operating System без гарантии real-time это какая-то нелепица.
Нелепица — это неумение прочитать первый абзац Википедии:
Robot Operating System (ROS or ros) is an open-source robotics middleware suite. Although ROS is not an operating system (OS) but a set of software frameworks for robot software development, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management.
говорят что MS DOS досихпор летает в космосе одно из упоминаний
В конце 1993 года российская компания Физтех-софт выпускает первую коммерческую версию PTS-DOS v6.4 (номер версии следует системе версий MS-DOS — Microsoft выпустила MS-DOS v6.2 в ноябре 1993 года).
Некоторые программисты, покинувшие Физтех-софт в 1995 году и основавшие Paragon Software выпустили собственную версию PTS-DOS v6.51CD с поддержкой приводов CD-ROM.
Физтех-софт продолжила разработку своего кода, выпустила PTS-DOS v6.6 и показала PTS-DOS v6.65 на выставке CeBIT в 1997 году[1]. Следующая версия от Физтех-софт, PTS/DOS Extended Version 6.70, выпускалась под названием PTS-DOS 2000 и продается до сих пор (начало 2009 года), как последний 16-битный PTS-DOS. Система ДОС Багет, основанная на PTS-DOS 2000, сертифицирована Министерством обороны Российской Федерации.
Paragon продолжил разработку линии PTS-DOS и выпустил Paragon DOS Pro 2000 (также известный как PTS/DOS Pro 2000) с поддержкой файловой системы FAT-32 и жёстких дисков более 8 гигабайт. Согласно сообщениям Paragon, это была последняя версия и вся разработка с тех пор была прекращена. Эта версия поставлялась с исходным кодом более старого PTS-DOS v6.51.
В 2002 году Физтех-софт выпустил 32-битную версию PTS-DOS — PTS-DOS 32 (известный как PTS-DOS v7.0[2]) с поддержкой файловой системы FAT-32, жёстких дисков более 8 гигабайт и памяти до 4 гигабайт.
Здравствуйте, sergey2b, Вы писали:
S>говорят что MS DOS досихпор летает в космосе одно из упоминаний
Так и Вояджеры до сих пор летают. Типа, кто там их из этого космоса достанет.
С другой стороны, в космосе, как и в автомобилях, всегда был очень длинный жизненный цикл железа: пока спроектируют, потом в серию выведут, потом эту серию надо годами поддерживать.
Здравствуйте, Nuzhny, Вы писали:
N>Нелепица — это неумение прочитать первый абзац Википедии: N>
N>Robot Operating System (ROS or ros) is an open-source robotics middleware suite. Although ROS is not an operating system (OS) but a set of software frameworks for robot software development, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management.
Robot Operating System is not an operating system — не вижу подвоха. Я прексрасно знал и до этого, что ROS не реализует какие-то реальные вещи из мира роботов, а является по сути скоплением алгоритмов кинематики, управления и т.д. Но в реального робото всё это не воткнуть.
Здравствуйте, cppguard, Вы писали:
C>Но в реального робото всё это не воткнуть.
Зависит от робота. ROS — это же наполовину образовательный проект Стэнфорда, где студент может взять какой-то узкий алгоритм, реализовать только его с правильным интерфейсом и весь пайплайн будет работать. Например, SLAM — классический пример использования. На модельках или даже в симуляторе, без проблем.
В Боинг ROS не засунут, на конвейер тоже, военные использовать его не станут, Тесла к себе не поставит. Но штука хорошая для своей ниши.
Здравствуйте, cppguard, Вы писали:
C>Может есть алгоритмы? Или методы верификаии?". И правильный ответ — да, методы есть, их много, они разные. И про них никто тебе не расскажет, нужно самому копать.
А что про них рассказывать-то в общем случае? Это как про таблицу умножения монографию писать. Оно ж и так понятно: нужно убедиться, что по всем путям выполнения сумма всех возможных задержек не превышает некоторых разумных величин, определяемых или интуитивно, или статистически. Если делается программа для голого процессора — учитываем его внутренние задержки и задержки самой программы. Если используются внешние устройства — добавляем задержки шин и устройств. Используется ОС — добавляем задержки ядра, драйверов и приоритетных служб. Используются библиотеки — добавляем их задержки.
А о том, как устранить лишние задержки в тех или иных устройствах и системах, написано до хренища. Просто оно не стоит на одной полке.