Кресло самолета своими руками

Содержание

Как мы строили авиатренажер: бесценный опыт
Предыстория
Грабли
Выводы
Апдейт
Update #2

Как мы строили авиатренажер: бесценный опыт

Чуть менее года назад я включился в процесс строительства устройства, которое находится где-то между авиасимулятором и профессиональным авиатренажером. Это был не первый опыт — в 2009 году мы уже решали такую задачу, поэтому приступая к реализации весьма амбициозной мечты мы постарались не наступить на все возможные грабли. Тут я опишу предысторию с «первым блином», и как она повлияла на второй. Если будет интересно, напишу подробно про наш второй тренажер.

Пост в «DIY» потому, что ни у кого из нас раньше не было опыта строительства самолётов или профессиональных тренажеров. Более того, как выяснилось позднее, подходы при конструировании низкобюджетного авиатренажера кардинально отличаются от подходов в профессиональной области. В общем, и первый и второй тренажер был построен любителями, правда, с техническим бэкграундом.

Осторожно, много картинок, вызывающих нервный тик у любителей авиации и инженеров.
Итак…

Предыстория

В июле 2009 года один из моих знакомых позвонил и сказал, что мол в Москве некий бизнесмен строит для себя тренажер самолёта Boeing 737-800, и что у него не все получается, и, дескать, не хотел ли бы я поучаствовать в проекте. Я захотел, приехал к этому бизнесмену, обалдел, и сразу включился в работу.

Надо сказать, что в результате тренажер построился, пожалуй, максимально дорого и с максимальным количеством граблей. Это было связано и с отсутствием опыта у нас, в очень значительной степени — с крайней малоразвитостью рынка низкобюджетных авиатренажеров и их компонентов, и, самое главное — мы не планировали. Это была чистая лабораторщина, наколенщина и экспромт: мы были крайне ограничены во времени.

В результате, худо-бедно наша штуковина ожила, показалась на МАКСе, и мы стали катать на ней всех желающих.

Вскоре после завершения постройки Боинга я ушел из компании, и вернулся к ней летом 2012 года. Меня позвали назад, поскольку тот чудный бизнесмен решился на постройку второго тренажера. На этот раз им стал Airbus A320.

В этот раз мы решили подойти к вопросу более проактивно: было принято совместное решение потратить время и силы для планирования. Кроме этого, я настоял на том, чтобы вначале появлялись бумаги и картинки, и лишь потом происходили закупки многочисленных компонентов.

Конечно, одной из главных задач была сократить совокупную стоимость владения, а для этого нам нужно было проанализировать и обдумать грабли, на которые мы наступили с Боингом.

Грабли

Для начала я решил проанализировать грабли. В конечном итоге, эти самые грабли на этапе проектирования и конструирования приводили к неожиданным простоям тренажера, что выливалось в весьма ощутимые финансовые и имиджевые потери для компании. Нужно было не пробакланить их по второму кругу.

Отсутствие ИТ-инфраструктуры

По сути, когда появлялся на свет Боинг, предполагалось, что «все заработает само». Поставщиков было всего три: кабина со всей электроникой, подвижная платформа и видеосистема. Софт (Project Magenta если кому-то что-то это говорит) был поставлен поставщиком кабины, соответственно и инфраструктура была «дана нам свыше». Как показала эксплуатация, нужно было по крайней мере правильно раскидать компоненты по компьютерам, но даже этого не было сделано.

В дальнейшем постоянные изменения (о которых я расскажу отдельно) привели к тому, что система зажила своей собственной жизнью. Каждый раз когда происходил какой-то сбой или отказ, приходилось распутывать узел из множества компонентов, чтобы в конечном итоге обнаружить, что один из них перестает работать, если лог-файл достиг определенного размера.
Ни о каком сколько-нибудь регулярном резервном копировании, контроле версий компонентов и речи не шло.

Что касается производительности, то по мере установки новых сценариев, производительность симулятора падала весьма существенно, что в результате потребовало замены MSFS на X-Plane. Почему именно такой выборы был сделан — я не знаю, я не принимал в нем участия, однако факт остается фактом.

Даже после замены монолитного MSFS на масштабируемый X-Plane, производительность графической подсистемы не была просчитана, в результате чего аппаратное обеспечение этих серверов дважды подвергалось апгрейду.

Из этого дизастера я сделал вывод, что просто необходимо нарисовать архитектуру всего тренажера, расписать какой компонент будет работать на каком компьютере, предусмотреть возможные расширения, расписать требования к производительности железа, оценить загрузку сети и сделать небольшой запас на дальнейшее развитие. В конечном итоге, целью существования тренажера является не постоянная отработка новых технологий, а улыбки на лицах клиентов.

Постоянные изменения и мультивендорность

О, это просто праздник.
Пока в качестве симулятора использовался MSFS, все было более или менее стабильно: поставил кривой сценарий — получи сходу отвал симулятора. Просто и без изысков.

Когда перешли на X-Plane и масштабировали систему установкой четырех экземпляров (один считает динамику, и каждый рисует свою картинку на свой проектор) выяснилось, что распространить один и тот-же сценарий на четыре экземпляра без ошибок гораздо сложнее. Особенно если учесть, что один из них работает под Виндой, а три — под Линуксом. Начались ошибки и проблемы, вылетания сценариев на одном из проекторов (самое неприятное). В какой-то момент контроль над сценариями был полностью утерян, и было принято волевое решение полностью синхронизировать все инсталляции с какой-то одной. Это позволило почти полностью избавиться от проблем с визуалкой, но корень проблемы остался — у нас четыре разные инсталляции симуляторов, три из которых формируют изображение на одном экране.

Иногда железо (контроллеры) выходили из строя. Вместо того чтобы смириться и покупать то-же самое, покупались контроллеры других производителей. В результате через три года в Боинге стояло оборудование аж 5 вендоров, и у каждого из них свой интерфейсный софт со своими особенностями. Конечно, это работает вместе, но в случае каких-то неизведанных проблем, диагностика превращается в сущий ад.

Опять-таки новые контроллеры — это новые кабели на борту, и в какой-то момент мы пришли к осознанию, что мы уже не знаем, что это за провод, куда он идет и для чего он нужен. Пришлось остановить работу тренажера на несколько дней, и сделать почти полный re-wiring.

Из этих граблей я сделал вывод, что тренажер должен строиться если и не на века, то по крайней мере на годы. Нужно заранее оценить направления возможного развития, зафиксировать их и строить систему исходя из этих направлений. Если в какой-то момент возникнет желание улучшить что-то в другом направлении — ну что-ж, от чего-то придется отказаться в пользу эксплуатационной надежности.

Эксплуатация

Эксплуатация тренажера не была похожа на таковую вообще.

Инструкций по эксплуатации не было, ограничений на изменения не было, плана резервного копирования, планового техобслуживания, да и много чего еще не было.

Разные руки лезли в один и тот-же тренажер, меняли настройки, наскоро проверяли и уходили, а на следующее утро тренажер не заводился.

Лампы в проекторах перегорали в самый неподходящий момент, а запасные были в магазине где-нибудь в Видном, и в пятницу вечером наш курьер несся через всю Москву дабы купить последнюю в Москве (кроме шуток) лампу.

Масло в цилиндрах приводов подвижной платформы незаметно вытекало, и мы обнаружили что оно течет только когда на полу образовалась лужа. И, конечно, масла этой марки было не купить.

Обобщая: тренажер работал, а не эксплуатировался. Ломается — чиним. Не ломается — летаем.

В новом проекте было очень важно предусмотреть и описать процесс эксплуатации: какой ЗИП в каком объеме нам нужен, как часто мы делаем диагностику, что делаем если сломается то-то и то-то, какие обновления мы устанавливаем и как, как мы их тестируем, как часто мы делаем бэкапы и т.д. Забегая вперед скажу, что такой подход здорово помог. Оказалось, что если договориться хотя бы о регулярных бэкапах и не вносить изменения когда попало, то система живет гораздо дольше и лучше.

Электрические проблемы

Казалось бы, в таком технически сложном устройстве электрические проблемы не должны занимать много места.
Ан-нет! Когда я только приобщился к Боингу, обнаружились спонтанные отключения контроллеров, которые мы долго не могли диагностировать. В какой-то момент я догадался померить разность потенциалов между «землей» USB контроллеров и компьютера, в который этот разъем был включен: там было много, слишком много как для контроллеров, так и для USB-хабов на материнских платах компьютеров. Оказалось, что каким-то неведомым образом наши поставщики умудрились развязать «земли» кабины и стойки с компьютерами. Сделали энергоснабжение из одной точки, с правильной разводкой «земли» и нейтрали — количество отваливаний резко сократилось.
В другой раз у нас вышибло одну из фаз, и вскрытие показало, что балансировки нагрузки нету. После этого я проанализировал схему электроснабжения всех компонентов тренажера и переделал ее, проблема ушла.

Выводом стала необходимость схемы электроснабжения с расчетом и балансировкой нагрузок, распределением их по бесперебойникам, и, конечно, с защитой как от КЗ, так и от поражения током. Сначала — на бумаге, с проверками «а что будет если этот проводок оторвется», с расчетом сечений проводов, номиналов автоматов и тому подобных электротехнических вещей. И лишь после того, как схема не изменялась — закупка компонентов и сборка электрического щита.

Мы никогда точно не считали, сколько в кабине лампочек и кнопочек, но количество контроллеров ввода-вывода переваливает за полтора десятка. И каждый из них заканчивается USB, а он должен включиться в компьютер.
Я уже написал про проблемы с отсутствием общей «земли», ее мы успешно решили, но когда на три разных компьютера идет три пучка кабелей — проблем не обойти.
Мы перепробовали несколько разных USB-удлиннителей, пробовали ставить хабы разных производителей, пробовали собирать все устройства на один компьютер, в общем, много чего пробовали, но проблема с «отваливанием» USB-устройства в самый неподходящий момент хоть и редка, но остается и по сей день.

Очевидным выводом был отказ от использования USB, однако как я уже сказал, в наш просвещенный век рынок малобюджетных тренажеров (т.е. тех, которые могут позволить себе частные лица, стоимостью до $50k) крайне малоразвит, и там царит USB. Более того, никто из поставщиков компонентов не держит в голове, что кабина может двигаться — почти все (за исключением единиц) таких вот тренажеров — неподвижны. Мы же строили тренажер на подвижной платформе, а отсюда возникала и необходимость длинных кабелей, и проблемы с вибрацией.

Ну что-ж, раз так, то никуда от него не деться, а значит нужно делать кабели максимально короткими, не тащить USB через удлинители на 10 метров, а ставить компьютеры на борту. Забегая вперед: это означало, что на борту должны стоять бездисковые компьютеры. Это отдельная прекрасная задача, о которой я расскажу в одной из следующих частей.

Механические проблемы

Подвижность + люди в кабине = разнообразные проблемы с механикой.
От вибрации раскручиваются резьбовые соединения, выпадают саморезы, со временем начинает рассыпаться пластик.
Клиенты наши — не профессиональные пилоты, а обычные люди, иногда даже не очень и увлеченные авиацией. Они не знают, что можно делать, а чего делать нельзя.
Обычный среднестатистический мужчина в самом расцвете сил может по незнанию оторвать рукоятку от настоящего авиационного прибора, и даже не заметить этого. Впрочем, по рассказам наших друзей-инженеров из «взрослых» тренажерных центров, настоящие пилоты иногда делают то-же самое.

В новом тренажере мы победили эти грабли процентов на 95%: все кабели должны быть зафиксированы, все резьбовые соединения — законтрены. Никаких саморезов. Стяжки, стяжки, стяжки. Оставшиеся 5 процентов — это по-прежнему наши клиенты. Увы, тут — только ласковым, но настойчивым словом. Это я отношу к организационным выводам.

Выводы

Планировать, проектировать, писать, думать, анализировать.
«С листа» можно, наверное, за пару вечеров смастерить самокат, но мясорубку — уже нет. А авиатренажер — и подавно.
Анализ прошлых неудач сыграл важную, если не решающую роль. Именно благодаря систематизации «выученных уроков» стала очевидной необходимость сначала думать и рисовать, а потом — делать.

Конечно, избежав части старых граблей, мы нашли новые, но полугодовой опыт показал, что эксплуатационная надежность нового тренажера гораздо выше. Гораздо меньше вынужденных простоев, сбоев и отказов. Гораздо больше счастливых клиентов, а ведь именно в этом и цель.

В следующих постах я опишу процесс постройки A320 в подробностях.

Апдейт

Я нашел фотографии с постройки Боинга, выкладываю.

Основание кабины со штурвалами. Первоначально использовались компьютерные БП, что оказалось большим злом. Сейчас MeanWell

Прибыла подвижная платформа из Италии. Масса самой подвижной платформы — около 800 кг, шкаф управления — еще 800.

У нас была возможность использовать погрузчик (с Аирбасом — уже нет, не было места). Слева — первая версия стойки с серверами. Справа — металлоконструкции, на которые будет натянут проекционный экран.

Сборка кокпита. MIP (Main instrument panel) уже почти собрана.

Кокпит с основанием и рамой.

Вид сквозь окна на открытую потолочную панель. Впоследствии стало понятно, что избранный способ прокладки кабелей был неверным.

Наши канадские специалисты настраивают интерфейсный софт — прослойку между FSUIPC и контроллерами. Каждая кнопка-тумблер-лампа-индикатор «привязываются» к переменной FSUIPC. Один раз мы эту конфигурацию потеряли — было весело.

Начало сборки основания, по которому будет ездить трап.

Кабина, платформа, шкаф управления платформой. «Сердце» шкафа управления — ПЛК Siemens. Драйверы приводов — Baumuller. Драйверы вместе с двигателями заслуживают отдельной статьи. К примеру, драйвер внутри считает температуру обмоток двигателя в зависимости от нагрузки на мотор. Кроме этого есть несколько температурных датчиков в обмотке, которые, конечно, тоже подключены к контроллеру. Что, впрочем, не мешает ему выдать аварийный сигнал и остановить всю подвижность, если расчетная температура выскочила за допустимый предел. А расчет ведется на основе уникальных параметров двигателя, которые снимаются в процессе тестирования на заводе. Когда мы столкнулись с этой трудностью (с расчетной температурой), пришлось выходить на связь с заводом.

Шкаф управления платформой и стойка с серверами, какими они были 4 года назад.

А теперь — ррраз, и мы погрузчиком водрузили кабину на платформу.

Блок РУДов (рукоятки управления двигателями, Throttle Quadrant по-английски). Собственно, причина моего появления в проекте. Оно не работало совсем. Блок сделан из настоящего блока с Боинга 737-300 немецким умельцем. К сожалению, умелец выкинул большую часть кондовой боинговской механики, и заменил ее смешными тягами, и, местами, (без шуток) крышкой от зажигалки. А винтовой клеммник решил залить припоем. Используемые контроллеры — Phidgets. Всего их на один этот блок — 6 штук.

Если я правильно помню, тут мы пытаемся разобраться, как распределяется питание (их там два — 12 и 5) внутри блока. Это питание используется для привода моторов (от стеклоочистителей), которые эмулируют работу автомата тяги, когда ручки ездят «сами по себе».

Вид в основание кабины. Обратите внимание на количество USB-удлинителей. Это были первые, после них были еще, и еще, и еще. Кабели не закреплены, это было одной из причин выхода из строя удлинителей.

Натянули проекционный экран и сводим изображение. В качестве делителя изображения использовался TrippleHead2Go, в качестве софта для искривления изображения под цилиндрический экран — Sol7.