Search in topic

Smalltim OSD and autopilot (часть 2)

А что платы выпускаете по старой разводке? поправили-же!

Пока идут текущие, но новые скоро уже надо будет сдавать в производство.

А имея достаточно огромный опыт работы в авиации (в т.ч. ряд исследований причин лётных проишествий, отказов и катастроф)

Хех, как-то я пропустил это. Моя дипломная работа в МАИ была что-то типа “Моделирование поведения человеко-машинных диссипативных систем в каких-то там условиях” на примере огромной статистики действий летчиков в экстремальных ситуациях и отработки механизмами этих действий, и поведения самолетов в результате этой отработки, собранной научруком за хрен знает сколько лет. Всё сам делал, даже сказали публиковаться, гыгы, но сейчас я оттуда ничего, кроме какой-то математики кусками, уже не помню 😦

Возвернул взад на автопилот недостающие шнурки каналов и даже добавил новых. Теперь на плате нет видеоразъемов, а есть только хвостики, прям как на нынешних. Удобно, блин.
Теперь на АП задействованы все шесть каналов (кто говорил: нафига их столько закладывать в конструктив?). Один из каналов сделал сквозным и замедлил для поворотки камеры - во всех режимах он подчиняется пульту и по пропадании сигнала выставляется в центр. Центр на пульте до калибровки выставлен из расчета комфортного прямолинейного полета.
Рудер в режиме АП замиксен на один из элеронов 😃, а именно, первый канал на 100%. Теперь Скай самостоятельно дрыгает всеми рулями. Интересно получается, если при этом канал рудера сделать сквозным! В режиме АП он дрыгается вместе со всеми рулями, но если перекинуть стик рудера на пульте в одно из крайних положений, то дрыги, не прекращаясь, смещаются в указанную половину хода. На сколько при этом реально ощутится подруливание - покажут полеты.

На сколько при этом реально ощутится подруливание - покажут полеты.

Реально, реально, не сомневайся!

Эх, пора уже продвинутые режимы стабилизации вводить.
Вижу такие варианты:

1. Удержание курса, высоты и скорости. Курс, высота и скорость задается качанием стиков крена тангажа и газа, наклон стика от нейтрали изменяет требуемый параметр на чуть-чуть, например, плюс-минус 3м/3кмч/3град в секунду. Целевые курс, высота и скорость вместе с текущими показываются на экране телеметрии дополнительными стрелочками на шкалах. Значения целевого курса, высоты и скорости берутся равными текущим значениям курса, высоты и скорости в момент активации режима.

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

3. Стабилизация простая или с удержанием курса/скорости/высоты с одновременным управлением пан-тилтом камеры, чтоб точка на земле по центру кадра камеры не сдвигалась или направление вида из камеры не менялось после активации режима. Без гиростабилизации камеры и самика кадр всё равно будет ползать чуток, но попробовать такое реализовать - интересно.

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

Поможем, конечно.

То есть в телеметрии не совсем все выгорает? Может и мою можно починить не сильно за дорого, тоже в АП воткнул перевернутую? Телеметрия мини из последних которые вручную собирались.

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

А можно вариант без скорости? То есть, что-б не АП удерживал скорость играя с газом, а пилот?
И динамику изменения курса-высоты я бы доверил пилоту, как вариант. То есть удержание курса и высоты включается, пока соответствующие стики в нейтрали (плюс/иинус допуск), а за пределами соответсвующей нейтрали - работает обычная стабилизация. Тут, мне кажется, мудрить с программированием скоростей изменения сложнее, чем простая работа РУ.

PS: Тимофей, а почему новая прошивка так долго инициализируется? Секунд 10 почти лампочками мигает. Лог сбрасывал - то-же самое. Просто, не дай Бог, рестартует в полете…

PS: Тимофей, а почему новая прошивка так долго инициализируется? Секунд 10 почти лампочками мигает. Лог сбрасывал - то-же самое. Просто, не дай Бог, рестартует в полете…

Всё точно так же, как и в старой прошивке. Долго инициализируется - ищет телеметрию. Не найдя с первой попытки, АП упорно продолжает долбить телеметрию 10 раз, пуская бегающий огонек после каждого раза по диагностичесским светодиодам, и потом сдается и работает без телеметрии.

У тебя ж плата телеметрии купалась в реке, она ж неживая.

А можно вариант без скорости? То есть, что-б не АП удерживал скорость играя с газом, а пилот? И динамику изменения курса-высоты я бы доверил пилоту, как вариант. То есть удержание курса и высоты включается, пока соответствующие стики в нейтрали (плюс/иинус допуск), а за пределами соответсвующей нейтрали - работает обычная стабилизация. Тут, мне кажется, мудрить с программированием скоростей изменения сложнее, чем простая работа РУ.

Коллеги, что скажете в дополнение к сказанному Александром? Мне-то просто, дописал немного кода и всё. Мне такая идея стабилизации нравится.

А что с полетом вокруг текущей точки? Надо?

Просто, не дай Бог, рестартует в полете…

Я ни разу в жизни не сталкивался с тем, что АП виснет или рестартует в полете. Но в уме я такую ситуацию держу, логику быстрого рестарта в полете как-нибудь вобью.

Может и мою можно починить не сильно за дорого, тоже в АП воткнул перевернутую?

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

А что с полетом вокруг текущей точки? Надо?

Угу

тебя ж плата телеметрии купалась в реке, она ж неживая.

Не. Это я про живую пишу. Ту что не купалась. Через 10 сек она нормально работает. Были проблеммы с синхронизацией, но удалось улучшить картинку.
Вроде перешивал. Кстати, пока АП не инициализировался, экране должнеа быть надпись “Ожидание данных от АП”?

А что с полетом вокруг текущей точки? Надо?

Да. Это очень полезно. Особенно хорошо антенны тестировать - отгнал на предел видимости и ищешь, что лучше добивает. 😃

Кстати, пока АП не инициализировался, экране должнеа быть надпись “Ожидание данных от АП”?

Ага.

Ага.

Надписи нема. Пустая картинка. А через 10 сек - нормальная телеметрия. Попробую еще раз перешить, только-б не сдохла…

А можно вариант без скорости? То есть, что-б не АП удерживал скорость играя с газом, а пилот?
И динамику изменения курса-высоты я бы доверил пилоту, как вариант.

Почему вы доверяете АП самое важное - возврат вашего барахлишка домой без видео и РУ? Но не можете доверить самое простое? Не давая АП контроль скорости - вы увеличиваете шанс завалить самолет при тех или иных условиях. Какова скорость реакции АП и Ваша? Что выше? Ап полюбому будет рулить газом адекватнее чем вы сами (конечно при правильном алгоритме удержания скорости). А это должно очень отразиться на экономии энергии.
Надо либо отдавать АП все бразды правления, либо рулить самому.

Тимофей, У нас на А320 (а это самолет fly by wire) режим удержания скорости (в том или ином виде) включается с момента начала разбега на взлете, а выключается на высоте выравнивания на посадке (перед касанием). Даже если пилотирование идет вручную, режим удержания скорости включен. Отключение autothrust’а это non standard procedure! А стабилизация у нас работает всегда, обеспечивая защиту от сваливания, превышения макс скорости, превышения макс допустимой перегрузки, макс крена, тангажа.
На посадке работает функция ground speed mini, которая при кратковременном увеличении скорости, вследствии порыва ветра, не убирает газ, а наоборот, добавляет его, сохраняя кинетическую энергию самолета (скорость относительно земли) постоянной.

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

А вот у тебя скоро появится аксель и гиры. надежная система (не то что пирометр). Почему бы не сделать защиту от превышения G, для дураков. например 3g.
Или при падении скорости ниже заданной в КП (в любом режиме, вплоть до ручного) добавлять газ, удерживая эту минимально разрешенную скорость. А если газ уже и так на максимуме, то уменьшать тангаж для удержания скорости. Опять таки это защита от дурака пилота, или от плохого, недопиленного алгоритма АП.

А что если сделать режим набора или снижения level change. тоесть ты выставил оптимальную воздушную поступательную скорость для набора или снижения. Выставил экономический режим двигателя для набора (для снижения это всегда малый газ). а АП сам подбирает тангаж, удерживая скорость и не меняя режим работы двигателя. (опять таки если чтото пойдет не так, и скорость упадет ниже Vls (V lowest selectable = 1,2*Vstall) то сработает защита, описанная выше).

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

Уже пора подумать о таких режимах, которые уменьшат потребление энергии и увеличат дальность и экономичность, обезопасят полет на различных этапах. Большая авиация уже лет 20 так летает. Чем мы хуже?

Не давая АП контроль скорости - вы увеличиваете шанс завалить самолет при тех или иных условиях.

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

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

Это полет по точкам называется. 😃

У нас на А320 (а это самолет fly by wire) режим удержания скорости (в том или ином виде) включается с момента начала разбега на взлете, а выключается на высоте выравнивания на посадке (перед касанием).

А у меня не копия A320 и мне не пассажиров возить.
Понимаете, Евгений, что-бы учесть все навороченные “хотелки”, включая контроль перегрузок, защиту от сваливания, экономичный набор высоты и посадку, надо во первых написать еще кучу кода (в АП и КП) - а это кроме Тимофея никто делать не будет, а во вторых количество настраиваемых параметров и так превышает порог восприятия части пользователей.
Давайте двигаться постепенно. То что предложено, делается относительно малой кровью и управляется только с помощью РУ: все ограничения на минимальный газ и завиисмости газа от тангажа - легко делаются микшерами нормальной аппы - без использования КП и ноутбука на поле.

Мы можем долго бодаться тут. у каждого свои нужды и фломастеры. Пусть Главный Конструктор решает что надо что нет. И как и что программить. Ему виднее. Я бы был не против, а только за, еслиб помимо моих хотелок были и ваши и его, и вон его… и чем больше галочек в настройках и пунктов, тем лучше. я со всем разбирусь =) Это тоже хобби

А на крайняк есть Вовы, Сережи и Саши с прочими ардупилотами для особо требовательных.
А для непродвинутых есть фишка!

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

у каждого свои нужды и фломастеры. Пусть Главный Конструктор решает что надо что нет.

Давно предлагал Тиму сделать круче всех - добавить пользовательский язык или скрипт - интерпретатор, для любых потребностей продвинутых пользователей. 😃

для любых потребностей продвинутых пользователей

Ага, тут и сейчас по любым непоняткам шишки сыпятся, а что будет если еще прибавится мильён всяких самопально-продвинутых версий?!
Некогда предлагал сделать на плате АП коммутационную площадку для питания камеры и перекидывать на нее нужное напряжение с питательного разъема автопилота. Очень удобно - к камере, так же как и к видеопередатчику идет только один шлейф в три жилы. На что был получен ответ, с которым нельзя не согласиться: “а в этот разъем пользователь обязательно воткнет пятивольтовую камеру и скажет, что я не прав”. как раз, несколькими постами выше, тема каснулась камер…

шишки сыпятся потому что нету нормального мануала.

Dronavt, вы какой-то противник прогресса. все вам не так, единственную кнопку “чтобы все летало” хотите?

С долгой инициализацией АП разобрался. Журнал был сброшен, но настройки журнала не были инициализированны, и он вообще не писался. Как я понимаю АП в начале пытался найти крайнюю запись в пустой FLASH-ке.

тут и сейчас по любым непоняткам шишки сыпятся, а что будет если еще прибавится мильён всяких самопально-продвинутых версий?!

За свои алгоритмы, пользователь сам отвечать должен. 😃

вы какой-то противник прогресса. все вам не так,

Э, нет! Я просто, прежде чем высказать хотелку, подставляю себя на место разработчика и проигрываю с каким гимором он при реализации столкнется. Причем под гимором подразумевается не процесс разработки, а дальнейшее общение с непродвинутыми пользователями. И ссылки на ненормальный мануал тут бесполезны. 90% юзеров считают себя продвинутыми и сначала включают питание, а потом по легкому дымку быстро определяют где именно они в этот раз ошиблись.
Ни в коей мере не против высказывания здесь пожеланий - таким образом АП и стал таким какой он на данный момент есть. Я против, когда начинаются требования ввести ту или иную фичу.

За свои алгоритмы, пользователь сам отвечать должен.

А как будет на самом деле? 😉

• нажимал?
• нет, не нажимал!
• а почему нажато?
• само нажалось…

На что был получен ответ, с которым нельзя не согласиться: “а в этот разъем пользователь обязательно воткнет пятивольтовую камеру и скажет, что я не прав”.

Абсолютно поддерживаю. Защиты от дурака в данном АП мало - плату телеметрии можно вставить как угодно, питание, по большому счету можно было все сделать 5-В, и брать от приемника, а не лезть на высокие напряжения и импульсные стабилизаторы. Единственное исключение - входа для контроля акков, но делитель силового акка можно было встроить в датчик тока, а дополнительные - сделать высокоомными и на спец разъемах - что-бы не перепутать. Но это мы все задним умом сильны. 😃

И простоту настройки начинаешь ценить с опытом. Меня до сих пор при необходимости перекалибровки РУ - в дрожь бросает, ибо вероятность благополучного исхода - процентов 30%. 😃

Меня до сих пор при необходимости перекалибровки РУ - в дрожь бросает, ибо вероятность благополучного исхода - процентов 30%.

Гы-гы, мне Тим, по секрету, подсказал как нужно двигать стики, чтобы не цеплять соседние каналы. Вероятность поднялась до 98% 😃
А если калибровку газа вынести на последнюю очередь, то до всех 100% доберемся!

Журнал был сброшен, но настройки журнала не были инициализированны, и он вообще не писался. Как я понимаю АП в начале пытался найти крайнюю запись в пустой FLASH-ке.

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

А если калибровку газа вынести на последнюю очередь, то до всех 100% доберемся!

В следующей КП сделаю.

Защиты от дурака в данном АП мало - плату телеметрии можно вставить как угодно, питание, по большому счету можно было все сделать 5-В, и брать от приемника, а не лезть на высокие напряжения и импульсные стабилизаторы.

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

Питать АП и ТМ от 5В BEC - не то чтобы смело, а безрассудно. Там такие шумы и такая стабильность напряжения, что можно сразу вешаться. Плюс, отдельное питание АП и ТМ может помочь спасти модель при просадке силового акка.

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

Проблема только в том, как обезопасить внутреннюю логику АП от действий пользователя, при этом не сильно ущемляя пользовательский код в возможностях. А задокументировать структуры данных, дать к ним доступ, API выставить наружу - не вопрос 😦
Можно решить вопрос кардинально. Разрешить пользователю ВСЁ. Подменять любую логику, математику и т.д. Но если пользователь подключает свои функции, то АП взводит пару флагов, сохраняет их там, где пользователь не сможет их выцарапать, и при любом конфликтном случае наличие взведенных флагов снимает с производителя ответственность за сохранность модели и за последствия использования АП.