Линейные Актуаторы - или "управление по проводам"

Даже при наличии пилота надежность должна быть приемлемой.
Вот тот блок гироскопа-приемника GPS классическое (правильное) решение поставленной задачки. Поставили необходимые сенсоры и прикрутили к ним решалку DSP. Затем организовали интерфейс на улицу и пользуйтесь на здоровье. Ящик для меня здороват, но тем, кто хочет на Линуксе самое то. Добавьте ещё десяток таких коробок, установив их в стандартную 19 дюймовую стойку и всё будет работать  ;D. Ну а потом мы попробуем взлететь со всей этой ерундой на борту  😉
 
admin сказал(а):
Даже при наличии пилота надежность должна быть приемлемой.
Вот тот блок гироскопа-приемника GPS классическое (правильное) решение поставленной задачки. Поставили необходимые сенсоры и прикрутили к ним решалку DSP. Затем организовали интерфейс на улицу и пользуйтесь на здоровье. Ящик для меня здороват, но тем, кто хочет на Линуксе самое то. Добавьте ещё десяток таких коробок, установив их в стандартную 19 дюймовую стойку и всё будет работать  ;D. Ну а потом мы попробуем взлететь со всей этой ерундой на борту  😉
Нажмите, чтобы раскрыть...
Админ, не горячитесь - это все примеры, дискусия...

Смотрим глубже - я хочу модернизировать мой ЕФИС каждые два года например - как софт так хард, сегодня летаем 2Д завтра 3Д.
Сегодня барометр, завта ВЧ альтиметр и т.д. У нас Експерементальная авиация !


Выходя из таких позицый я бы делал все это модульным как у большинства Дронов:

Оборудование с дублированием и надежностью 200%:
     - контроллер сервоприводов-автопилот - надежный, легкий, дубовый микроконтроллер - от 19 грамм (голая плата) до 200 грамм (с блоком питания, защитой от вибрацый и выходных каскадов) c подключенным джойстиком, который является всегда приоритетным управлением - при его касании автопилот вырубывается автоматически;
     - сервоприводы - подключаемые напрямую к управляющим поверхностям или к кочерге-педалям, как кому нравится;

Оборудование без дублирования и надежностью 90%-100%:
     - внешние сенсоры (как НАВ440й - удобно розместить и заменить при случае на НАВ500й - без замены всего остального);
     - промышленный PC c юнихом-линухом на борту встроенный в бортовую панель с сенсорным тоуч-скрином с 2Д или 3Д или чем еще душа пожелает (для себя я бы поставил ПЗ наземной станции Дрона).


И еще - при отсутствии механического управления, не составляет труда герметизировать кабину….или я не прав ?
 
Ну для начала зачем кабину герметизировать? Вы нырять собрались? До 7 км можно летать с компактным кислородным оборудованием, но только там холодно и туда никто пока не пускает. Двигателю на больших высотах даже наддувному будет не совсем хорошо, воздуха не хватает там для поршневого.

Герметизацию кабины можно решить и при обычном управлении.

Если хочется сделать игрушку и писать софт самому для неё, это можно. Берите хоть Линукс, хоть Windows, дело Ваше. Причины, по которым этого делать не стоит я описал выше довольно подробно. Вы всегда вправе принимать свои самостоятельные решения в любом случае, я только выражал своё мнение. Я не стал бы использовать подобные вещи даже в случае наличия open source кода и бесплатного софта, полностью покрывающего мои потребности.

Производители стандартных ЭФИСов обновляют софт периодически и можно его загрузить по инету и прокачать свою ляльку. Самодельный софт всегда придется доводить самому. Если это нравится - вперед и с песней. Мне нравится ковыряться со своими железками, чем собственно и занимаюсь.
 
admin сказал(а):
Если хочется сделать игрушку и писать софт самому для неё, это можно. Берите хоть Линукс, хоть Windows, дело Ваше. Причины, по которым этого делать не стоит я описал выше довольно подробно. Вы всегда вправе принимать свои самостоятельные решения в любом случае, я только выражал своё мнение. Я не стал бы использовать подобные вещи даже в случае наличия open source кода и бесплатного софта, полностью покрывающего мои потребности.

Мне нравится ковыряться со своими железками, чем собственно и занимаюсь.
Нажмите, чтобы раскрыть...
Админ, никто ничего не собирается писать 🙂

Я уже выложил идею - брем комплект "наземная станция-автопилот-сенсоры" от продвинутого безпилотника (Дрона или UAV) стоимостью в 1000-1500 долларов (максимум а то и опен сорс - если найдете интересный) отсекаем модем-приемник и имеем ОТЛИЧНЫЙ ЕФИС который по навигационной функциональности в разы, а то и десятки разов лучше и удобнее рынковых несертифицированных ЕФИСОВ и автопилот в разы а то и десятки разов понадежнее тех же автопилотов - потому, как автопилот реализован для дрона на монокристале с десятками функцый страховочных, в том числе анти вибрационных, антистатических и т.д. и т.п. (жызненно важных для безпилотника) а все громоздкое и глючное (графика, карты, логи) унесено на вне - на линуховую бездисковую станцию (для визуализации на земле, програмирования, анализа полетов...с красивым графическим интерфейсом, визуализацией маршрута, детальными цветными картами или снимками спутниковыми и при желании 3Д полнофункциональным - с детальной 3Д картой НьюЙорских кварталов 🙂 ) Есть желание - наздоровье две наземных станции, три наземных станции на панели размести - на одной панелька инструментов, на другой карта, на третьей логи и статистика, перегружай любую станцию (время бута 12-20 секунд в зависимости от проца и флешек установленных), есть желание - оставь модем и порадуй друзей на земле своими онлайн видео и логами, дай порулить "большой моделькой на секундочку"...чудеса !

Админ, к чертям формальности ... авиация у нас ЕКСПЕРИМЕНТАЛЬНАЯ !  😱

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

PS: к примеру 3Д навигатор плохонький на том же планшетнике стоит от 6-7 тысяч в США, для аналогии безпилотный комплект с большей функцыональностью и монокристальнім автопилотом 3-4 тысячи...

А то что комерческие 3Д (как и некоторые 2Д) графические навигаторы построены НЕ НА том или ином юнихе-линухе - неповерю - уж больно дорого ОС писать .... даже ядро от опен сорс симуляторов сомнительного качества нестесняясь используют.

А летать по Гугловских картах хорошей детализации закачав перед полетом на флешку с 15ти дюймовым екраном приносит очень много удовольствия в сравнении с созерцанием 16ти цветного винигрета на 10ти дюймовом ЭФИСЕ...

...басни все это о супернадежности и суперфункциональности...это только представить за два линуха с двюмя мониторами навом и автопилотом драть 30-40тисяч зеленых, когда тоже (если не лучше по функционалу) максимум в 10 вкладывается с теми же (!) бездисковыми промышленными писюхами и Дроновским линуховым ПЗ...

вот мысли вслух на не совсем трезвую голову...С РОЖДЕСТВОМ Авиаторы !

(в том числе новых идей  😱 )
не те времена Админ - в мире свободной информации - русского человека не надуть !
 
второй поднятый вопрос в даной теме - чем не основа для рулевой машинки (серво) - http://en.nanotec.com/planetary_gear_gple40.html

Промышленный планетарные редукторы к шаговым моторам.

В комплекте с мотором http://en.nanotec.com/plug_drive_motors.html  с встроенным контроллером - готовое цифровое серво с моментом в 1000-2000 Ньютон.

Или опять "грабли" ?  😉
 
чем не готовая "цифровая тяга" елерона ? http://en.nanotec.com/downloads/pdf/1933/LK4218L1806%20Layout1%20(1).pdf

быстродействие 100мм-сек и 800Ньютон сила удержания - мало ?

помедленнеее 50мм-сек но пожалуйста на 1800Ньютон - http://en.nanotec.com/downloads/pdf/1934/LK5718L3008%20Layout1%20(1).pdf

нужен контроллер - вот он: http://en.nanotec.com/steppermotor_driver_smc11g.html

все конечно стоит приличных денег, но "голден серво" тоже не даром...
 
ВАУ админ, даже такой спецыалист как Миран который сконструировал самую надёжную дистанцыоную систему управления камерой, при разговоре о подключение к самолёту(а у него есть Лонг Изи и незаконченый Беркут....качает головой в несогласии.
Его система самая плавная и точная в Холливуде...(а это значить в Мире) платы-схемы и системы установленые наего управление устанавливаються на Спэс штле и новом Ф-18Е...и всёровно он несогласен ставить такое управлени на малый самолёт..так как прийдётся делать двойную а мож тройную отдельные системы...и финансово это совершенно не целисообразно...и даже после этого такой надёжности небудет как уже существует сейчас на Лонг Изи.
Кому интересно можете почитать о его систме Hot Gears
http://www.hotgears.com/page2.htm
 
N38MK сказал(а):
ВАУ админ, даже такой спецыалист как Миран который сконструировал самую надёжную дистанцыоную систему управления камерой, при разговоре о подключение к самолёту(а у него есть Лонг Изи и незаконченый Беркут....качает головой в несогласии.
Его система самая плавная и точная в Холливуде...(а это значить в Мире) платы-схемы и системы установленые наего управление устанавливаються на Спэс штле и новом Ф-18Е...и всёровно он несогласен ставить такое управлени на малый самолёт..так как прийдётся делать двойную а мож тройную отдельные системы...и финансово это совершенно не целисообразно...и даже после этого такой надёжности небудет как уже существует сейчас на Лонг Изи.
Кому интересно можете почитать о его систме Hot Gears
http://www.hotgears.com/page2.htm
Нажмите, чтобы раскрыть...

N38MK - платформа показаная Вами, извините, не более чем типичная американская мыльница - всем в этом глобальном мире давно известно, что нет ничего точнее Швейцарской механики, а все остальное - жалкая реплика 🙂)
...любой мало-мальски точный современный трехосевой промышленный манипулятор швейцарского производства может быть с легкостью модифицирован под "триногу" вашей камеры…все остальное (голова, гиростабилизаторы, управление, питание) как говорится - дело фантазии, времени и терпения…. :-X

Но не об этом тут тема, напоминаю тема о: актуаторах, управлении "по проводам" и использования богатого опыта и наработак в области дронов в малой авиации - как програмного так аппаратного.
 
TNVD сказал(а):
admin сказал(а):
Если хочется сделать игрушку и писать софт самому для неё, это можно. Берите хоть Линукс, хоть Windows, дело Ваше. Причины, по которым этого делать не стоит я описал выше довольно подробно. Вы всегда вправе принимать свои самостоятельные решения в любом случае, я только выражал своё мнение. Я не стал бы использовать подобные вещи даже в случае наличия open source кода и бесплатного софта, полностью покрывающего мои потребности.

Мне нравится ковыряться со своими железками, чем собственно и занимаюсь.
Нажмите, чтобы раскрыть...
Админ, никто ничего не собирается писать 🙂

Я уже выложил идею - брем комплект "наземная станция-автопилот-сенсоры" от продвинутого безпилотника (Дрона или UAV) стоимостью в 1000-1500 долларов (максимум а то и опен сорс - если найдете интересный) отсекаем модем-приемник и имеем ОТЛИЧНЫЙ ЕФИС который по навигационной функциональности в разы, а то и десятки разов лучше и удобнее рынковых несертифицированных ЕФИСОВ и автопилот в разы а то и десятки разов понадежнее тех же автопилотов - потому, как автопилот реализован для дрона на монокристале с десятками функцый страховочных, в том числе анти вибрационных, антистатических и т.д. и т.п. (жызненно важных для безпилотника) а все громоздкое и глючное (графика, карты, логи) унесено на вне - на линуховую бездисковую станцию (для визуализации на земле, програмирования, анализа полетов...с красивым графическим интерфейсом, визуализацией маршрута, детальными цветными картами или снимками спутниковыми и при желании 3Д полнофункциональным - с детальной 3Д картой НьюЙорских кварталов 🙂 ) Есть желание - наздоровье две наземных станции, три наземных станции на панели размести - на одной панелька инструментов, на другой карта, на третьей логи и статистика, перегружай любую станцию (время бута 12-20 секунд в зависимости от проца и флешек установленных), есть желание - оставь модем и порадуй друзей на земле своими онлайн видео и логами, дай порулить "большой моделькой на секундочку"...чудеса !

Админ, к чертям формальности ... авиация у нас ЕКСПЕРИМЕНТАЛЬНАЯ !  😱

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

PS: к примеру 3Д навигатор плохонький на том же планшетнике стоит от 6-7 тысяч в США, для аналогии безпилотный комплект с большей функцыональностью и монокристальнім автопилотом 3-4 тысячи...

А то что комерческие 3Д (как и некоторые 2Д) графические навигаторы построены НЕ НА том или ином юнихе-линухе - неповерю - уж больно дорого ОС писать .... даже ядро от опен сорс симуляторов сомнительного качества нестесняясь используют.

А летать по Гугловских картах хорошей детализации закачав перед полетом на флешку с 15ти дюймовым екраном приносит очень много удовольствия в сравнении с созерцанием 16ти цветного винигрета на 10ти дюймовом ЭФИСЕ...

...басни все это о супернадежности и суперфункциональности...это только представить за два линуха с двюмя мониторами навом и автопилотом драть 30-40тисяч зеленых, когда тоже (если не лучше по функционалу) максимум в 10 вкладывается с теми же (!) бездисковыми промышленными писюхами и Дроновским линуховым ПЗ...

вот мысли вслух на не совсем трезвую голову...С РОЖДЕСТВОМ Авиаторы !

(в том числе новых идей  😱 )
не те времена Админ - в мире свободной информации - русского человека не надуть !
Нажмите, чтобы раскрыть...

Немного разовью тему.


pbp1-12151.jpg


Это, так сказать, другой конец управления по проводам.

/me
 
Не буду с Вами спорить. Я привел аргументы про надежность уже не один раз. ЭФИСы выполненные по проекту с нуля и специально заточенные быть не универсальным компьютером, а именно ЭФИСом от рождения ВСЕГДА будут правильнее универсальных компов "ящика с огурцами".
Перезагрузка в течении 20 секунд может в полете и жизни стоить. Она должна производиться молниеносно.

Что такое ОС в Вашем понимании? Зачем она Вам нужна в ЭФИСе, в котором все устройства ввода вывода ВСЕГДА будут одни и те же? Драйвер под конкретный датчик или для дисплея/клавиатуры это небольшой кусок кода, который остается от ОС в случае не универсальности системы. Всё сразу упрощается в разы.

Я уже выложил идею - брем комплект "наземная станция-автопилот-сенсоры" от продвинутого безпилотника (Дрона или UAV) стоимостью в 1000-1500 долларов (максимум а то и опен сорс - если найдете интересный) отсекаем модем-приемник и имеем ОТЛИЧНЫЙ ЕФИС который по навигационной функциональности в разы, а то и десятки разов лучше и удобнее рынковых несертифицированных ЕФИСОВ и автопилот в разы а то и десятки разов понадежнее тех же автопилотов
Нажмите, чтобы раскрыть...

Я предпочту пользоваться Гармином с плохим дисплеем, чем наладонником или ПК для навигации и многие со мной согласяться. Не нужно мне в полете всякой красивой лабуды, а только та инфа, которая НЕОБХОДИМА.

Мы переливаем одни и те же аргументы уже несколько раз, не убедив друг друга. Самое простое в этом случае это построить реальную систему и показать её. Тогда будут видны её размеры, цена и прочие параметры  😉.
 
admin сказал(а):
Не буду с Вами спорить. Я привел аргументы про надежность уже не один раз. ЭФИСы выполненные по проекту с нуля и специально заточенные быть не универсальным компьютером, а именно ЭФИСом от рождения ВСЕГДА будут правильнее универсальных компов "ящика с огурцами".
Перезагрузка в течении 20 секунд может в полете и жизни стоить. Она должна производиться молниеносно.

Что такое ОС в Вашем понимании? Зачем она Вам нужна в ЭФИСе, в котором все устройства ввода вывода ВСЕГДА будут одни и те же? Драйвер под конкретный датчик или для дисплея/клавиатуры это небольшой кусок кода, который остается от ОС в случае не универсальности системы. Всё сразу упрощается в разы.
Нажмите, чтобы раскрыть...

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

/me
 
Commodore сказал(а):
admin сказал(а):
Не буду с Вами спорить. Я привел аргументы про надежность уже не один раз. ЭФИСы выполненные по проекту с нуля и специально заточенные быть не универсальным компьютером, а именно ЭФИСом от рождения ВСЕГДА будут правильнее универсальных компов "ящика с огурцами".
Перезагрузка в течении 20 секунд может в полете и жизни стоить. Она должна производиться молниеносно.

Что такое ОС в Вашем понимании? Зачем она Вам нужна в ЭФИСе, в котором все устройства ввода вывода ВСЕГДА будут одни и те же? Драйвер под конкретный датчик или для дисплея/клавиатуры это небольшой кусок кода, который остается от ОС в случае не универсальности системы. Всё сразу упрощается в разы.
Нажмите, чтобы раскрыть...

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

/me
Нажмите, чтобы раскрыть...

ты представляешь какой уровень програмиста должен обладать пилот чтобы заниматься в полёте перезапуском системы ?Меня эта тема просто поулыбала )))
 
Gennadij сказал(а):
Commodore сказал(а):
admin сказал(а):
Не буду с Вами спорить. Я привел аргументы про надежность уже не один раз. ЭФИСы выполненные по проекту с нуля и специально заточенные быть не универсальным компьютером, а именно ЭФИСом от рождения ВСЕГДА будут правильнее универсальных компов "ящика с огурцами".
Перезагрузка в течении 20 секунд может в полете и жизни стоить. Она должна производиться молниеносно.

Что такое ОС в Вашем понимании? Зачем она Вам нужна в ЭФИСе, в котором все устройства ввода вывода ВСЕГДА будут одни и те же? Драйвер под конкретный датчик или для дисплея/клавиатуры это небольшой кусок кода, который остается от ОС в случае не универсальности системы. Всё сразу упрощается в разы.
Нажмите, чтобы раскрыть...

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

/me
Нажмите, чтобы раскрыть...

ты представляешь какой уровень програмиста должен обладать пилот чтобы заниматься в полёте перезапуском системы ?Меня эта тема просто поулыбала )))
Нажмите, чтобы раскрыть...

Настоятельно рекомендую и дальше сохранять оптимизм.  🙂

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

Тут вот заумная ссылка.  🙂

/me
 
Не ребята, Вы чё науку разводите в том, где её практически нету. Какая нафих многозадачность  ;D какое ядро  ;D.

Есть однокристаллка, которая выполняет задачу. К ней зацеплено ещё несколько однокристаллок. Они контролируют жизнеспособность друг друга. Критические данные обрабатываются на 2-х схемах при необходимости. Каждая однокристаллка при помощи встроенных таймеров может сама понять - "а не подвисла ли я?" и перезапуститься МГНОВЕННО. Перезапустить можно с другого чипа при необходимости. НО ЭТО ВООБЩЕ КРАЙНИЕ ВАРИАНТЫ Т.К. Я НЕ ОЧЕНЬ ПОНИМАЮ КАК МОЖНО ПОДВЕСИТЬ ОДНОКРИСТАЛКУ ЕСЛИ СОФТ НАПИСАН ПРАВИЛЬНО. Конечно если писать кривой софт, который не имеет выходов из протокола обмена между устройствами (по времени или количеству попыток обмена), которые не отвечают (отключены/сдохли), тогда да, может и подвиснуть, но если делать всё правильно, то и виснуть не должно принципиально. Если Вы только разберетесь, что такое "подвис", то станет понятно где это может произойти и как этого избежать в принципе  😉. В сложных системах, которые кэшат куски памяти, выделяют страницы памяти неопределенных размеров, запускают несколько (не известно сколько) приложений и делают прочие неопределенные функции на момент написания софта это возможно, но это не наша тема т.к. процессы, которые нам необходимо запрограммировать гораздо тривиальнее. Процессы наши довольно убоги и их можно описать очень четко, а в случае применения ОС это сделать намного тяжелее. Любой драйвер лежащий до поры до времени на внешнем устройстве при неудачной попытке загрузки принесет Вам массу приятных ощущений, я не говорю о внезапном переполнении хранилища данных (диска/флешки).

Ребята, Вы просто роете в сторону утяжеления (и как правило удорожания) системы. Многозадачные системы реализуются для намного более сложных вещей. У меня где-то есть фотки где мы разбирали Дайноновский ЭФИС. Там всё делает одна однокристаллка. Она обслуживает графический дисплей, клаву и 11 приборов авионики!!! Вся авионика всего самолета решена на 1 чипе. С этой штукой SpaceShipOne летал в космос без нареканий. Все приборы двигателя (нескольких двигателей) тоже решается на 1 чипе. Сколько можно об этом говорить??? Себестоимость подобной железки очень небольшая по сравнению с готовым девайсом, а вот продажная цена немаленькая т.к. покупатели ХОТЯТ такой прибор за такие деньги. На многие приборы стоит очередь на несколько месяцев вперед. Есть конечно и более дорогие девайсы, но часто из-за сертификации. В ней основная часть цены.
Вы можете хотя бы виртуально построить ЭФИС на базе собранных готовых узлов и сравнить полученную стоимость с Дайноном например (2000$ = 11 приборов авионики). Попробуйте и напишите по строчкам со ссылками, что у Вас получается.
 
admin сказал(а):
Не ребята, Вы чё науку разводите в том, где её практически нету. Какая нафих многозадачность  ;D какое ядро  ;D.

Есть однокристаллка, которая выполняет задачу. К ней зацеплено ещё несколько однокристаллок. Они контролируют жизнеспособность друг друга. Критические данные обрабатываются на 2-х схемах при необходимости. Каждая однокристаллка при помощи встроенных таймеров может сама понять - "а не подвисла ли я?" и перезапуститься МГНОВЕННО. Перезапустить можно с другого чипа при необходимости. НО ЭТО ВООБЩЕ КРАЙНИЕ ВАРИАНТЫ Т.К. Я НЕ ОЧЕНЬ ПОНИМАЮ КАК МОЖНО ПОДВЕСИТЬ ОДНОКРИСТАЛКУ ЕСЛИ СОФТ НАПИСАН ПРАВИЛЬНО. Конечно если писать кривой софт, который не имеет выходов из протокола обмена между устройствами (по времени или количеству попыток обмена), которые не отвечают (отключены/сдохли), тогда да, может и подвиснуть, но если делать всё правильно, то и виснуть не должно принципиально. Если Вы только разберетесь, что такое "подвис", то станет понятно где это может произойти и как этого избежать в принципе  😉. В сложных системах, которые кэшат куски памяти, выделяют страницы памяти неопределенных размеров, запускают несколько (не известно сколько) приложений и делают прочие неопределенные функции на момент написания софта это возможно, но это не наша тема т.к. процессы, которые нам необходимо запрограммировать гораздо тривиальнее. Процессы наши довольно убоги и их можно описать очень четко, а в случае применения ОС это сделать намного тяжелее. Любой драйвер лежащий до поры до времени на внешнем устройстве при неудачной попытке загрузки принесет Вам массу приятных ощущений, я не говорю о внезапном переполнении хранилища данных (диска/флешки).

Ребята, Вы просто роете в сторону утяжеления (и как правило удорожания) системы. Многозадачные системы реализуются для намного более сложных вещей. У меня где-то есть фотки где мы разбирали Дайноновский ЭФИС. Там всё делает одна однокристаллка. Она обслуживает графический дисплей, клаву и 11 приборов авионики!!! Вся авионика всего самолета решена на 1 чипе. С этой штукой SpaceShipOne летал в космос без нареканий. Все приборы двигателя (нескольких двигателей) тоже решается на 1 чипе. Сколько можно об этом говорить??? Себестоимость подобной железки очень небольшая по сравнению с готовым девайсом, а вот продажная цена немаленькая т.к. покупатели ХОТЯТ такой прибор за такие деньги. На многие приборы стоит очередь на несколько месяцев вперед. Есть конечно и более дорогие девайсы, но часто из-за сертификации. В ней основная часть цены.
Вы можете хотя бы виртуально построить ЭФИС на базе собранных готовых узлов и сравнить полученную стоимость с Дайноном например (2000$ = 11 приборов авионики). Попробуйте и напишите по строчкам со ссылками, что у Вас получается.
Нажмите, чтобы раскрыть...

Админ,
Ну кто спорит на счет одно-двух или трех кристалок.
Все по пунктам:

1) апаратура управления "кочерга-тяга" (гарантия работоспособности нужна 200 процентов).
Джойстик делается из однокристального энкнкодера генерирующего импульсы и сигнал направление в ТТЛ формате, и енкодер напрямую (!) или через умножитель импульсов (мелкая логика - одна микросхема) на 2 или 4 подключается к контроллеру шагового мотора - ВСЕ, никаких микроконтроллеров, никаких программ !!!
Повторяю: два анологичных контура - енкодер+шаговый мотор с контроллером встроенным в исполнении IP65 и блок питания с аккумулятором - ВСЕ.
2) автопилот (гарантия работоспособности нужна 100 процентов) - две однокристалки - и вход и выход на "кочерга-тяга", два корпуса, две цепи питания - ВСЕ. В случае его полной смерти есть "кочерга-тяга"
3) сенсоры (гарантия работоспособности нужна 100 процентов) (гироскопы, ГПС) - две штуки - готовый НАВ 440 (см. Выше) на одном ДСП - уходит на автопилот (каждый сенсор на комутаторы с возможностью перенаправления сигнала на свою однокристалку) - ВСЕ
4) общая шина куда "дышат" автопилоты
6) контроллер впрыска мотора и сенсоры мотора (гарантия работоспособности нужна 200 процентов)- две однокристалки похожай архитектура на автопилот - виход на общую шыну
7) ЕФИС (гарантия работоспособности нужна 99.9 процентов)- Линух (три штуки + три экрана) - в случае смерти одного все то же на другом и третьем подключены к общей шыне

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

1) апаратура управления "кочерга-тяга" (гарантия работоспособности нужна 200 процентов).
Джойстик делается из однокристального энкнкодера генерирующего импульсы и сигнал направление в ТТЛ формате, и енкодер напрямую (!) или через умножитель импульсов (мелкая логика - одна микросхема) на 2 или 4 подключается к контроллеру шагового мотора - ВСЕ, никаких микроконтроллеров, никаких программ !!!
Повторяю: два анологичных контура - енкодер+шаговый мотор с контроллером встроенным в исполнении IP65 и блок питания с аккумулятором - ВСЕ.
Нажмите, чтобы раскрыть...

что такое однокристальный энкодер? Есть датчик положения линейный или оборотный не суть важно. Из него можно получить или аналоговый сигнал (тупо напряжение) или положение в парралельном коде (например в коде Грея). энкодеры с последовательным выходом (импульсы по двум каналам со сдвигом) не годятся т.к. при перезапуске нулевая точка джойстика становится неизвестной. Итак, на аналоговый нужно навесить АЦП (его иногда ещё нужно сконфигурировать для работы) в случае с паралельным выходом его нужно перевести в удобоваримый двоичный код например из "Грея" (это наиболее часто встречаемый код) в паралельных датчиках. Итак, коды положения джойстика мы получили. Контроллер управления шаговыми моторами стоит метрах в нескольких и нужно организовать поток передачи данных к контроллеру серво (мы же не будем тащить 40 проводов  ;D). Если берем стандартный контроллер, нужно преобразовать имеющиеся данные, пересчитанные на необходимую "чувствительность" джойстика в те данные, которые понимает стандартный привод (не помножить на 2, а используя большое разрешение датчиков и сервоконтроллера положения привести их в соответствие нужного угла отклонения джойстика к нужному углу отклонения рулевой поверхности). Если делаем свой поток, то например можно организовать CAN BUS интерфейс и передавать данные на все серво по паре проводов на любое необходимое расстояние, соединив все устройства в последовательную шину. В итоге, парой м/с мы не обойдемся, если это не однокристаллка поддерживающая протокол работы с серво контроллером и работающая с АЦП (там программку протокола нужно писать) или имеющая 2х10 входов для подключения 2-х паралельных энкодеров (и всё равно программку писать придется). Я уже не говорю что протокол связи придется делать по нормальному, чтобы случайно серво не уехали в ненужную сторону  😉.

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

2) автопилот (гарантия работоспособности нужна 100 процентов) - две однокристалки - и вход и выход на "кочерга-тяга", два корпуса, две цепи питания - ВСЕ. В случае его полной смерти есть "кочерга-тяга"
Нажмите, чтобы раскрыть...
всё будет похуже. Там нужно поставить несколько датчиков (перегрузка/скорость/высота/положение рулей/пространственное положение ВС и т.д.) нужно организовать протокол обмена с GPS ведущей по маршруту и много ещё всякой лабуды типа дисплея/кнопок и др.

3) сенсоры (гарантия работоспособности нужна 100 процентов) (гироскопы, ГПС) - две штуки - готовый НАВ 440 (см. Выше) на одном ДСП - уходит на автопилот (каждый сенсор на комутаторы с возможностью перенаправления сигнала на свою однокристалку) - ВСЕ
Нажмите, чтобы раскрыть...
Сенсоры ДОЛЖНЫ постоянно работать с конкретным устройством. Там при переключении у гироскопов теряется положение например!

4) общая шина куда "дышат" автопилоты
Нажмите, чтобы раскрыть...
А что это за шина, куда они должны "дышать"?

6) контроллер впрыска мотора и сенсоры мотора (гарантия работоспособности нужна 200 процентов)- две однокристалки похожай архитектура на автопилот - виход на общую шыну
Нажмите, чтобы раскрыть...
Это вообще отдельный девайс и нафига его на шину сажать, хотя если хочется то шина будет что то типа CAN BUS.

7) ЕФИС (гарантия работоспособности нужна 99.9 процентов)- Линух (три штуки + три экрана) - в случае смерти одного все то же на другом и третьем подключены к общей шыне
Нажмите, чтобы раскрыть...
А где тут куча датчиков для ЭФИСа? И зачем их ТРИ? Обычно хватает двух. Блин, да что Вы пристали к графическому Линуксу? Стрелки и приборы можно и в Ассемблере нарисовать (минут 10 занимает  😉 там синус-косинус функции и всего делов  ;D). Линух и графика это ДВЕ РАЗНЫЕ ВЕЩИ!!! ОБЪЯСНИТЕ МНЕ ЗАЧЕМ ВАМ ЛИНУХ??? ЧТО ИМЕННО ОН ВАМ ДАЕТ? ВОЗМОЖНОСТЬ ИСПОЛЬЗОВАНИЯ ЧУЖОГО СОФТА БЕСПЛАТНОГО ВИДИМО??? ТАК ЭТО ИГРУШКИ  :IMHO ЭТО РЕБЯТА САМОВЫРАЖАЮТСЯ.

Если Вы не знаете программирование на приличном уровне, то разобраться в любом Open Source для Вас будет сверхзадачей, а изменения делать придется. Обычно отдельные проекты поддерживаются весьма слабо и знатокам этого продукта Вы надоедите через 10 сообщений с вопросами и придется самому разбираться с софтом.

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

Я вот чего не понимаю - если РУС связан с поверхностями управления жестко, то как связанный РУС может быть джойстиком, положение которого заставляет отклоняться рули? Если автопилот САМ двигает РУС, то причем здесь джойстик? Или Вы хотите поставить 2 ручки?

ЗЫ. На Вашем джойстике Вы теряете обратную связь, а это катастрофически плохо  🙁....

Давайте сделаем так - Вы построите систему и выложите своё решение для обсуждения. Пока это всё разговоры на уровне вождения пальцем в небе. Давайте "железо" и может я смогу что-то по нему сказать, но говорить лучше в режиме - Вот схема подключения/драйвер/устройство с его документацией и тогда можно будет предмет обсудить, иначе непонятно о чём мы с Вами говорим.
 
admin сказал(а):
Админ,
Ну кто спорит на счет одно-двух или трех кристалок.
Все по пунктам:

1) апаратура управления "кочерга-тяга" (гарантия работоспособности нужна 200 процентов).
Джойстик делается из однокристального энкнкодера генерирующего импульсы и сигнал направление в ТТЛ формате, и енкодер напрямую (!) или через умножитель импульсов (мелкая логика - одна микросхема) на 2 или 4 подключается к контроллеру шагового мотора - ВСЕ, никаких микроконтроллеров, никаких программ !!!
Повторяю: два анологичных контура - енкодер+шаговый мотор с контроллером встроенным в исполнении IP65 и блок питания с аккумулятором - ВСЕ.
Нажмите, чтобы раскрыть...

что такое однокристальный энкодер? Есть датчик положения линейный или оборотный не суть важно. Из него можно получить или аналоговый сигнал (тупо напряжение) или положение в парралельном коде (например в коде Грея). энкодеры с последовательным выходом (импульсы по двум каналам со сдвигом) не годятся т.к. при перезапуске нулевая точка джойстика становится неизвестной. Итак, на аналоговый нужно навесить АЦП (его иногда ещё нужно сконфигурировать для работы) в случае с паралельным выходом его нужно перевести в удобоваримый двоичный код например из "Грея" (это наиболее часто встречаемый код) в паралельных датчиках. Итак, коды положения джойстика мы получили. Контроллер управления шаговыми моторами стоит метрах в нескольких и нужно организовать поток передачи данных к контроллеру серво (мы же не будем тащить 40 проводов  ;D). Если берем стандартный контроллер, нужно преобразовать имеющиеся данные, пересчитанные на необходимую "чувствительность" джойстика в те данные, которые понимает стандартный привод (не помножить на 2, а используя большое разрешение датчиков и сервоконтроллера положения привести их в соответствие нужного угла отклонения джойстика к нужному углу отклонения рулевой поверхности). Если делаем свой поток, то например можно организовать CAN BUS интерфейс и передавать данные на все серво по паре проводов на любое необходимое расстояние, соединив все устройства в последовательную шину. В итоге, парой м/с мы не обойдемся, если это не однокристаллка поддерживающая протокол работы с серво контроллером и работающая с АЦП (там программку протокола нужно писать) или имеющая 2х10 входов для подключения 2-х паралельных энкодеров (и всё равно программку писать придется). Я уже не говорю что протокол связи придется делать по нормальному, чтобы случайно серво не уехали в ненужную сторону  😉.

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

Ну Админ поулыбали Вы меня, батюшка !

За програмированием вообще закостынели и забыли курс "схемотехника" институтский 🙂 поправимо...

начну действовать - тогда станет понятно ( мне самому тоже 🙂 я дальше "спектрума" самодельного не залазил, надо паяльник отрыть... 🙂

вот (кому интересно для ликбеза) про роботу инкрементного энкодера http://www.megasensor.com/product_info.php/products_id/122
 
Батенька да Вы не понимаете о чём я Вам тут трындю уже давно! С таким пониманием глубины траблов Вам радиомодельки тяжелее 20 грамм опасно в руки давать!

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

ИНКРЕМЕНТНЫЕ ЭНКОДЕРЫ НЕДОПУСТИМО ИСПОЛЬЗОВАТЬ В ПОДОБНЫХ СИСТЕМАХ, ПОВТОРЯЮ В ТРЕТИЙ РАЗ Н-Е-Д-О-П-У-С-Т-И-М-О!!!!!

СИСТЕМА НЕ ДАЕТ ТЕКУЩЕГО ПОЛОЖЕНИЯ В СЛУЧАЕ ПЕРЕЗАГРУЗКИ! КАК ВЫ БУДЕТЕ ОПРЕДЕЛЯТЬ ПОЛОЖЕНИЕ РУЧКИ?

Я С ТАКИМИ ЭНКОДЕРАМИ РАБОТАЛ В ПРОШЛОМ ВЕКЕ ИСЧО. ОНИ ПРЕДНАЗНАЧЕНЫ ГЛАВНЫМ ОБРАЗОМ ДЛЯ СТАБИЛИЗАЦИИ СКОРОСТИ ВРАЩЕНИЯ ИЛИ ИЗМЕРЕНИЯ ТЕКУЩЕГО ПОЛОЖЕНИЯ (ДЛИНЫ), ГДЕ ИНИЦИАЛИЗАЦИЯ НУЛЕВОЙ ОТМЕТКИ ПРОИСХОДИТ ПЕРИОДИЧЕСКИ, НАПРИМЕР СИСТЕМА НАРЕЗКИ ПРОФИЛЯ У НАС НА ЗАВОДЕ. ПРОИЗВОДИТСЯ НЕПРЕРЫВНАЯ ПАЛКА И МЫ ЕЁ РЕЖЕМ НА ОДИНАКОВЫЕ ЗАДАННЫЕ КУСКИ И ЕСЛИ ПРОИЗОЙДЕТ СБОЙ ОТРЕЖЕТСЯ ВСЕГО НАВСЕГО ПАЛКА МЕНЬШЕЙ ИЛИ БОЛЬШЕЙ ДЛИНЫ, НО САМОЛЕТ НЕ УПАДЕТ  ;D. ТАКИЕ СБОИ В ПОДОБНОЙ СИСТЕМЕ ДОПУСКАЮТСЯ И ПРОИСХОДЯТ ОНИ В МОМЕНТ НЕОЖИДАННОГО ЗАПУСКА/ОСТАНОВА ЛИНИИ КОГДА ИДЕТ НЕКОНДИЦИЯ И ОПЕРАТОР МОЖЕТ СНЯТЬ ПИТАНИЕ С ЧАСТИ ЛИНИИ И ЗАТЕМ ЕГО СНОВА ПОДАТЬ. СЧЕТЧИКИ ДЛИНЫ СБРОСЯТСЯ В "0" И ПОЙДЕТ НОВЫЙ ОТСЧЕТ.

В ВАШЕМ СЛУЧАЕ ТОЛЬКО ДАТЧИК ТОЧНОГО ПОЛОЖЕНИЯ ИЛИ ПАРАЛЕЛЬНЫЙ ИЛИ АНАЛОГОВЫЙ, ДРУГИХ ВАРИАНТОВ НЕТУ!!!! УЧИТЕ МАТЧАСТЬ САМИ И ВНИМАТЕЛЬНО!!!!

В радиоуправляемых модельках это допустимо т.к. при первоначальном включении рычажки управления под действием пружин стоят в нулевом положении и сервопривода аналогично устанавливаются на 0, но у Вас настоящее ВС и ручка может быть случайно отклонена пилотом при начальном включении и тогда он труп ещё на взлете  :~~)
 
Более того. Автопилоты и интегрированные с DSP инерциалки (те что выдают уже углы, а не "чистые" сигналы ускорений и угловых скоростей) от БПЛА на самолет не подойдут. По двум причинам:

1.В калмановском фильтре внутри контроллера/dsp УЖЕ заложены некие коэффициенты, рассчитанные под конкретный летательный аппарат вполне конкретных размеров.

Да, есть например Micropilot. Если отбросить проблемы с ввозом его в Россию (есть методы) - кажется, вполне подходящая вещь. Коэффициенты фильтров инерциалки и PID-регуляторов настраиваются, но - как показывают эксперименты - девайс все равно показывает фигню, а не реальное положение самолета. Да, он управляет моделькой... но - как! Постоянная "раскачка" по осям. Если любопытно - могу поискать в своих архивах запись с борта модели с таким автопилотом. Но это будет порядка 100-200mb.

Подборы коэффициентов в данном случае ничего не дают. Так как основные параметры производитель ПО сделал не регулируемыми, к тому же - не известными. Ноу-хау, так сказать. Да, можно узнать методом Reverse-engineering - но стоит ли...

2.Один из методов коррекции накопившихся ошибок у БПЛАшных автопилотов - целенаправленное изменение пространственного положения ЛА. Грубо говоря - например, создается некоторое скольжение и по GPS'у измеряется отклонение от курса - так можно выполнить коррекцию Z-оси инерциалки.  Все это очень упрощенно. Для ЛА размером более нескольких метров это, опять таки - не подойдет.

Там нужна "честная" инерциалка с качественными датчиками и очень не дешевым математическим программным обеспечением.

Можно поступить как MGL Avionics со своими SP-3, SP4. По сути та же инерциалка от беспилотника, только коэффициенты подобраны для больших ЛА. Но показывает оно все равно ерунду (SP3 по крайней мере, SP4 не изучал). Ошибку сбрасывает простым усреднением данных с акселерометров, в момент когда угловая скорость по гироскопу близка к 0. По понятным причинам тоже не лучшее решение для "большого" самолета. Но, если выбирать между SPx-xx и датчиком от БПЛА - лучше SP3/4. К тому же, дешевле.

http://www.trioavionics.com/ez_pilot.htm и ему подобные - хорошая вещь. Но работает только на статически устойчивом ЛА в спокойной атмосфере.
 
Подборы коэффициентов в данном случае ничего не дают. Так как основные параметры производитель ПО сделал не регулируемыми, к тому же - не известными. Ноу-хау, так сказать. Да, можно узнать методом Reverse-engineering - но стоит ли...
Нажмите, чтобы раскрыть...

Я бы не горячился. Сломать защиту, а в чипах 100% стоит защита от чтения вряд ли возможно. Покрутить на тестовом приборе и посмотреть на реакцию девайса возможно, но можно снять только очень ограниченный объем его данных. Можно понять частоту управляющих воздействий или их силу в различных режимах, но этого мало для понимания всех настроек алгоритма.

Вы совершенно ПРАВИЛЬНО сказали, что система зависит -

1.В калмановском фильтре внутри контроллера/dsp УЖЕ заложены некие коэффициенты, рассчитанные под конкретный летательный аппарат вполне конкретных размеров.
Нажмите, чтобы раскрыть...

Важно -
1. инерционность объекта.
2. сила влияния стабилизирующих воздействий (с учетом ограничений по безопасности в управляемом процессе).
3. возможная сила влияния дестабилизирующих воздействий.

У меня была подобная задачка, хоть и из другой оперы -
необходимо точно держать заданную оператором температуру формообразующей металлической головки, оснащенной несколькими нагревателями и вентиляторами.
От размера головки зависит её инерционность,
от мощности нагревателей и вентиляторов зависит сила управляющих воздействий. При работе вентилятора шаги изменения мощности (мощность задается ШИМ) больше, а при управлении нагревателями меньше (система автонастраивается в процессе работы не расшатывая температуру).
Система анализировала поведение управляемого процесса и модифицировала как сам алгоритм, так и переменные, подстраиваясь под процесс и прогнозируя поведение объекта в будущем. Звучит научно, но сам алгоритм довольно простой ПИД с небольшими доделками  😉. 16 канальное независимое управление процессами занимает около 50 строчек на Си  ;D Мне удалось зажать температурный диапазон в стабильном окне +/- 0.2 градуса, хотя вражеское оборудование держало только +/-2 т.е. в 10 раз хуже. Это оборудование уже лет 5-6 исправно работает на заводе и можно даже посмотреть  😎.

Раскачка у Вас была скорее всего из-за большого влияния "П" и очень малого "И". Додавливается до полного сглаживания, при правильном "П" и "И", в стабильной среде добавлением "Д", но с нарастанием нестабильности коэффициены должны меняться, иначе  :~~). Многие алгоритны этого не учитывают и получается  :~~).
 
Вам необходимо войти или зарегистрироваться, чтобы здесь отвечать.
Назад
Вверх