Продолжая излагать, в популярной форме, нюансы устройства железнодорожного тормоза, я, на протяжении пяти статей старательно увиливал от, с моей точки зрения, наиболее сложной и интересной темы - устройства грузовых приборов торможения. В силу специфики грузового движения, устройства торможения на грузовых вагонах и локомотивах являют собой достаточно хитроумные приборы. Подходить к изложению принципов их работы следует с пониманием дела и особой осторожностью, дабы не ввести в читателя в заблуждения. Тем более, что к этому обязывает фабула данного цикла статей. Разобраться в данном вопросе и написать таки долгожданную публикацию меня побудили причины сугубо личные. И как всегда, поймав истину за хвост, спешу поделиться с читателями.
Пользователь
Запуск ОСРВ Embox на Banana Pi M1
Об этой операционной системе я узнал на данном ресурсе, из многочисленных публикаций её разработчиков. Для тех кто не в курсе - это отечественная операционная система реального времени для встраиваемых устройств с открытым исходным кодом. Её официальный репозиторий расположен тут. Возникло желание опробовать этот проект в деле. Благодаря документации к проекту на виртуальной машине qemu удалось запустить конфигурации для разных платформ. Однако, виртуальная машина - это не для настоящих джедаев).
Тщательно изучив список поддерживаемых одноплатников, остановил свой выбор на Banana Pi M1 с ARM-процессором Allwinner A20. Плата была заказана на Aliexpress, и когда она прибыла, настало время экспериментов. Но всё, как и ожидалось, оказалось не так просто...
VulkanSceneGraph: Введение в графическую библиотеку
Возможно, кто-то из читателей помнит мою серию публикаций о графической библиотеке OpenSceneGraph. Уже на тот момент, в общем-то было понятно, что использование OpenSceneGraph в 2018 году мало оправдано из-за того, что OpenGL, на котором основан OpenSceneGraph потихоньку сдает свои позиции. В феврале 2016 года орган по стандартизации OpenGL Khronos group, выпускают приемника OpenGL - Vulkan API версии 1.0. Производители оборудования в общем-то почти сразу стали добавлять в драйверы своей аппаратуры поддержку нового API. По крайней мере, актуальная на тот момент GeForce GTX 970 уже имела таковую поддержку (про более старые серии аппаратуры ничего сказать не могу).
Не смотря на то, что OpenSceneGraph таки получил поддержку OpenGL 3.x (и ваш покорный слуга собирал его с таковой поддержкой), разработчикам этой библиотеки стало понятно, что огромное количество внутренних проблем OpenGL делает его поддержку бесперспективной. Поэтому, в конце мая 2018 года стартовала разработка новой графической библиотеки VulkanSceneGraph, ориентированной исключительной на Vulkan API. 13 ноября 2022 года состоялся официальный релиз VulkanSceneGraph-1.0, а совсем недавно, 31 августа 2023 выпустили VulkanSceneGraph-1.0.9.
Подробно эта юная графическая библиотека здесь на хабре не освещалась. Но я думаю пришло время сделать как минимум обзор её возможностей, а может и серию публикаций по архитектуре и приемам работы с ней. В общем, заинтригованных читателей прошу под кат.
Вторая жизнь для Elo Serial Touchscreen
Старая техника вызывает теплую ностальгию. Конечно, в большинстве ситуаций, несмотря на то, что раньше оно вот как — и деревья были выше и трава зеленее — на текущем уровне развития техники для решения практических задач лучше и правильнее применять актуальное оборудование.
Однако иногда бывают примеры оборудования, которое, являясь устаревшим, тем не менее вполне пригодно для применения и в современных условиях. Тем более, если речь идет об использовании его под управлением возмужавшего за более чем 30 лет своего существования ядра Linux.
Речь в статье как раз и пойдет об одном из недавних примеров подобной реинкарнации старого железа, прямиком из моей практики. Так что, кому интересно — прошу под кат.
Правда о железнодорожных тормозах: часть 5 — тормоза локомотивов
В предыдущих статьях данного цикла мы поговорили подробно об истории развития железнодорожного тормоза, о приборах управления тормозами, приборах торможения и об особенностях реализации тормозов железнодорожных вагонов. Но, кроме вагонов существует еще и локомотивный парк, тормозные системы которого имеют очень существенные особенности реализации. О них и пойдет речь в данной публикации.
Ретроспектива развития тягового привода железнодорожных экипажей
Формальной причиной появления этой статьи стала недавняя замечательная публикация "Электрический путь в век скоростей" в которой автор изложил исторические факты о первых, весьма не робких, шагах в развитии высокоскоростного железнодорожного сообщения, предпринятых в Германии в конце XIX начале XX века. Мне, как человеку некоторым образом связанному с железнодорожным транспортом, упомянутая статья понравилась тем, что она осветила, пусть и в публицистической форме, историю первого применения асинхронного двигателя в качестве тягового двигателя железнодорожного экипажа. Впечатляет и масштаб рекорда скорости, достигнутого электровагоном AEG - ведь, на минуточку, дело было в 1903 году! Такой успех технически во многом обусловлен применением именно бесколлекторного двигателя переменного тока.
Возникает вопрос - почему, показав столь впечатляющий результат, асинхронный тяговый двигатель исчез со сцены почти на столетие, уступив место коллекторному двигателю постоянного тока? Причин этому много, и главная из них - отнюдь не тройной токоприемник, как могло бы показаться. На этот вопрос я и постараюсь ответить в этой статье.
Неизвестный «Сапсан»: часть 1 — общий обзор конструкции электропоезда
Для начала скажу, что речь не пойдет о дороговизне билетов, расписании этого поезда, о его уместности в инфраструктуре Октябрьской железной дороги. Пройдем мимо хайповых тем. Речь пойдет сугубо о технической стороне вопроса, затрагивающей в частности и тормоза. Но не только их.
1. Немного общих цифр
Электропоезд «Сапсан» является локализованной версией семейства высокоскоростных поездов Velaro, на базе которого Siemens производит высокоскоростные поезда как для Deutsche Bahn (немецких железных дорог), так и много ещё для кого. У нас поезду дали обозначение ЭВС — Электропоезд Высокоскоростной Сименс. Дорога эксплуатирует два его варианта: ЭВС1 для участков, работающих на постоянном токе 3 кВ и ЭВС2 — двухсистемый электропоезд для сетей постоянного тока 3 кВ и переменного тока 25 кВ.
Правда о железнодорожных тормозах: часть 4 — приборы торможения пассажирского типа
Надпись видна даже если поезд стоит у высокой платформы, так что не пропустите.
На этом вагоне — «Аммендорф», прошедшем капитально восстановительный ремонт (КВР), установлен воздухораспределитель (ВР) усл. №242 пассажирского типа. Он теперь устанавливается на все новые и «откавээреные» вагоны, взамен более раннего 292-го ВР. Вот об этих приборах, относящихся к семейству приборов торможения мы и поговорим сегодня.
Правда о железнодорожных тормозах: часть 3 — приборы управления
Старый-добрый золотниковый кран 394 до сих пор используется на подвижном составе
Правда о железнодорожных тормозах: часть 2
Высокоскоростные поезда, вроде TGV уже не обходятся пневматическим торможением
Сегодня мы поговорим о современности, а именно о том, какие подходы к созданию тормозных систем подвижного состава используются в XXI веке, буквально через месяц разменяющему свой третий десяток.
Правда о железнодорожных тормозах: часть 1
Было дело, просили меня поподробнее раскрыть эту тему именно здесь, на Хабре. Здесь публикуется довольно много обзорных статей на железнодорожную тематику, однако данная тема еще не освещалась подробно. Думаю, что было бы довольно интересно написать об этом статью, а возможно и не одну. Поэтому прошу под кат тех, кому интересно как устроены тормозные системы железнодорожного транспорта, и по каким причинам они устроены именно так.
Russian Railway Simulator (RRS): первый публичный релиз
Пассажирский поезд на станции Ростов Главный (кликабельно)
Что такое RRS? Это открытый кроссплатформенный симулятор подвижного состава колеи 1520 мм. Читатель закономерно задаст вопрос: «Позвольте, а для чего нужен этот проект, если симуляторов железнодорожной тематики, как коммерческих, так и открытых, достаточное количество?» За ответом на этот вопрос я и предлагаю заглянуть под кат
OpenSceneGraph: Интеграция с фреймворком Qt
Введение
С одной стороны движок OpenSceneGraph и сам по себе обладает развитой подсистемой управления окнами, обработки событий пользовательского ввода, отправки и приема пользовательских сообщений. Об этом мы довольно подробно поговорили в предыдущих статьях этого цикла. В общем, в сумме с возможностями C++/STL этого вполне достаточно для разработки сколь угодно сложных приложений.
Пример интеграции OSG в приложение, разработанной в QtDesigner. Этот пример будет подробно разобран ниже
С другой стороны, для ускорения разработки на C++ применяются как сторонние библиотеки, расширяющие возможности этого языка (вроде boost), так и целые фреймворки, позволяющие легко и непринужденно разрабатывать кроссплатформенные приложения широкого функционального назначения. Одним из таких фреймворков является ультра популярный Qt. Как бы не ругали Qt за его метаобъектный компилятор и прочие недостатки и неудобства, сила Qt в обширной библиотеке классов, решающей все мыслимые задачи кроссплатформенной разработки, а так же в концепции "сигналы — слоты", реализующей подсистему обмена сообщениями между классами. На сигналах и слотах основаны так же методы взаимодействия приложения с операционной системой, а так же межпроцессное взаимодействие.
И, черт возьми, было бы весьма интересно совместить две технологии: Qt и OSG. Подобную задачу пришлось решать моему коллективу, о чем я уже писал в одной из своих публикаций. Однако, этот вопрос хотелось бы раскрыть немного шире, и данная статья будет как раз на эту тему.
OpenSceneGraph: Уровни детализации (LOD) и фоновая загрузка объектов
Введение
Одной из интереснейших задач, решаемых посредством трехмерной графики является создание «больших миров» — протяженных сцен, содержащих большое число объектов с возможностью неограниченного перемещения по сцене. Решение этой задачи упирается в понятные ограничения, присущие аппаратному обеспечению компьютера.
Типичный пример: «большой мир» при визуализации железной дороги на движке OSG. Не хватает только лангольеров, пожирающих мир за поездом...
В этой связи возникает необходимость управления ресурсами приложения, сводящаяся к очевидному решению: загрузке только тех ресурсов (моделей, текстур и так далее), которые необходимы для формирования сцены в текущий момент времени при текущем положении наблюдателя; уменьшении уровней детализации удаленных объектов; выгрузке не нужных более объектов из памяти системы. В большинстве своем графические и игровые движки предоставляют некоторый набор инструментов для решения подобных задач. Сегодня мы рассмотрим, какие из них имеются в OpenSceneGraph.
OpenSceneGraph: Система плагинов
Введение
Где-то в предыдущих уроках уже говорилось о том, что OSG поддерживает загрузку разного рода ресурсов типа растровых изображений, 3D-моделей различных форматов, или, например, шрифтов через собственную систему плагинов. Плагин OSG является отдельным компонентом, расширяющим функционал движка и обладающий интерфейсом, стандартизированным в пределах OSG. Плагин реализуется как динамическая разделяемая библиотека (dll в Windows, so в Linux и т.д). Имена библиотек плагинов соответствуют определенному соглашению
osgdb_<расширение файла>.dll
то есть в имени плагина всегда присутствует префикс osgdb_. Расширение файла указывает движку какой плагин следует использовать для загрузки файла с данным расширением. Например, когда мы пишем в коде функцию
osg::ref_ptr<osg::Node> model = osgDB::readNodeFile("cessna.osg");
движок видит расширение osg и загружает плагин с именем osgdb_osg.dll (или osgdb_osg.so в случает Linux). Код плагина выполняет всю черную работу, возвращая нам указатель на ноду, описывающую модель цессны. Аналогичным образом, попытка загрузки изображения формата PNG
osg::ref_ptr<osg:Image> image = osgDB::readImageFile("picture.png");
приведет к тому, что будет загружен плагин osgdb_png.dll, в котором реализован алгоритм чтения данных из картинки в формате PNG и помещение этих данных в объект типа osg::Image.
OpenSceneGraph: Обработка событий
Введение
Одной из особенностей языка C++, за которую его часто критикуют — отсутствие в стандарте механизма обработки событий. Между тем данный механизм это один из основных путей взаимодействия одних программных компонентов с другими программными компонентами и аппаратным обеспечением, и реализуется он на уровне конкретной ОС. Естественно, что каждая из платформ имеет свои нюансы реализации описанного механизма.
В связи со всем вышеперечисленным, при разработке на C++, возникает потребность в реализации обработки событий тем или иным способом, решаемая за счет использования сторонних библиотек и фреймворков. Всем известный фреймворк Qt предоставляет механизм сигналов и слотов, позволяющий организовать взаимодействие классов, наследуемых от QObject. Реализация событий присутствует и в библиотеке boost. И конечно же в движке OpenSceneGraph не обошлось без собственного «велосипеда», о применении которого и пойдет речь в статье.
OpenSceneGraph: Управление окнами и режимами отображения
Введение
Мы уже говорили о том, что класс osg::Camera управляет связанным с ним графическим контекстом OpenGL. Графический контекст инкапсулирует информацию о том, как и куда происходит отрисовка объектов и какие атрибуты состояния к ним применяются. Под контекстом понимают графическое окно, вернее его клиентскую область, или пиксельный буфер OpenGL, который хранит данные пикселей без передачи их в кадровый буфер.
OSG использует класс osg::GraphicsContext для представления абстрактного графического контекста, и класс osg::GraphicsWindow, для представления абстрактного графического окна. Последний имеет метод getEventQueue() для управления событиями от элементов GUI. Вообще говоря графический контекст есть платформоспецифичное понятие, поэтому большую часть работы по созданию окна и связыванию его контекста с контекстом OpenGL, OSG берет на себя. При вызове метода createGraphicsContext() класса osg::GraphicsContext() требуемый код (а его не мало, поверьте!) будет сгенерирован препроцессором автоматически, в зависимости от платформы. От нас лишь требуется передать этому методу аргумент типа osg::GraphicsContex::Traits, содержащий описание того, какое окно мы хотим получить.
OpenSceneGraph: Процедурная анимация геометрии и атрибутов состояния
Введение
Говоря о приемах программирования, специфичных для OSG в прошлый раз мы говорили о механизме обратных вызовов (Callback) и его реализации в движке. Настало время посмотреть на то, какие возможности дает нам применение этого механизма для управления содержимым трехмерной сцены.
Если говорить об анимации объектов, то OSG предоставляет разработчику две возможности её реализации:
- Процедурная анимация, реализуемая программным способом через трансформацию объектов и их атрибутов
- Экспорт анимации из 3D-редактора и управление ею из кода приложения
Для начала рассмотрим первую возможность, как наиболее очевидную. О второй мы обязательно поговорим чуть позже.
OpenSceneGraph: Основные приемы программирования
Введение
В этой статье речь пойдет не столько о графике, сколько о том, каким образом должно быть организовано приложение, её использующее, учитывая специфику движка OpenSceneGraph и предоставляемые им программные средства.
Не секрет, что залогом успешности любого программного продукта является грамотно спроектированная архитектура, предусматривающая возможности сопровождения и расширения написанного кода. В этом смысле рассматриваемый нами движок находится на достаточно высоком уровне, предоставляя разработчику весьма широкий инструментарий, обеспечивающий построение гибкой модульной архитектуры.
Данная статья является довольно длинной и включает в себя обзорное описание разнообразных инструментов и техник (паттернов проектирования, если хотите), предоставляемых разработчику движком. Все разделы статьи снабжены примерами, код которых можно взять в моем репозитории.
OpenSceneGraph: Основы работы с текстурами
Введение
Мы уже рассматривали пример, где раскрашивали квадрат во все цвета радуги. Тем не менее существует и другая технология, а именно применение к трехмерной геометрии так называемой текстурной карты или просто текстуры — растрового двухмерного изображения. При этом воздействие оказывается не на вершины геометрии, а изменяются данные всех пикселей, получаемых при растеризации сцены. Такой прием позволяет существенно увеличить реалистичность и детальность конечного изображения.
OSG поддерживает несколько текстурных атрибутов и режимов текстурирования. Но, перед тем как говорить о текстурах, поговорим о том, как в OSG оперируют с растровыми изображениями. Для работы с растровыми изображениями предусмотрен специальный класс — osg::Image, хранящий внутри себя данные изображения, предназначенных, в конечном итоге, для текстурирования объекта.
Information
- Rating
- 3,625-th
- Location
- Ростов-на-Дону, Ростовская обл., Россия
- Date of birth
- Registered
- Activity