Search in topic

OSD на ATmega1281

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

Тут как раз противоречия нет… 😃 Если использовать на отключение баро-скорость, велик шанс будет и того, и другого ( да еще сломаный винт, сгоревший рег и двигатель)… А если по “И” еще ждать нулевую высоту (хоть баро хоть гпс) двигатель практически вообще никогда сам не отключится. С гпс-скоростью были случаи ложных кратковременных отключений в полете. В новой прошивке ожидает для отключения двига именно нулевая скорость (а не меньше минимальной) в течении 4 сек (а не мгновенно), поэтому случайные срабатывания почти исключены.

Задается минимальный предел по скорости ГПС (например 20км/ч) и максимальный по бароскорости (наприемер 90км/ч). При уменьшении скорости ГПС ниже 20 км/ч включаем газ на круизный режим. Если скорость не выросла выше 20 км/ч даем три четверти газа и т.д. Это чтобы модель не летела хвостом вперед.

Вся засада в деталях… Значение, полученные по этой логики, надо как-то (как?) увязать с тем, которое сейчас вычисляется по тангажу. (Регулировать газ просто по скорости, как у Тимофея, категорически несогласен). Ну и не могу же я дергать ступеньками газ. Значит надо менять с какой-то скоростью, не допускающей автоколебаний. Вообщем если все параметры и коэффициенты регулирующие эти и другие моменты вынести в конфигурацию, боюсь мало кто сможет настроить, да и сам через месяц забуду что с чем связано и на что влияет. Попробую что-нибудь придумать на эту тему, хоть и остаюсь в сомнении целесообразности форсажей против ветра…
(Кстати, Сергей ubd, обрати внимание, для этого нужно только гпс скорость и не непонятная разница с баро…)

Ну и наоборот при выходе за предел 90 км/ч (только по баро) - чтобы модель в воздухе не развалить.

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

надо как-то (как?)

Вот в том то и вопрос! )))

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

Не знаю как объяснить… Скажем так, алгоритм который сейчас есть - он приоритетный, но если например бароскорость выходит за границу допустимого предустановленного, то газ нужно сбросить. Это понятно, что носитель развалить сложно. КМК, в случае очень тяжелого носителя (тот же Скай перегруженный аккумами) скорость набирает довольно быстро - АП начинает снижать самолет, скорость растет, при пикировании АП газ сбрасывает. Но после выравнивания скорость мгновенно не гаситься - инерция. И вот тут если снова газку поддать, да еще и по тангажу порулить (АП бывает не сразу занимает нужную высоту, немного промахивается) - появляется риск сложить крыло.

В новой прошивке ожидает для отключения двига именно нулевая скорость (а не меньше минимальной) в течении 4 сек (а не мгновенно), поэтому случайные срабатывания почти исключены.

Вот это мне уже нравиться… Об этом в первый раз слышу.

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

Согласен!

Народ, а нельзя всю эту красивость заставить считывать данные с ардупилота ?

Можно всё, но этим никто не будет заниматься.

Наконец запустил серийную съемку фотика. Для этого слепил такой адаптер:

На своей старенькой мыльнице вывел на разъем необходимые цепи.
Работает… 😃
В конфигураторе для первого дискретного канала, выбирается канал и диапазон который будет включать съемку. Для каналов 2-4 можно задать только инверсию.
Логика такая:
Если значение в управляющий канал значение в заданном диапазоне-

1. Включается питание фотика. Пауза 4 сек.
2. На 1сек “нажимается” кнопка включения. Пауза 4 сек.
3. На 2сек “нажимается” фокусировка.
4. На 4сек “нажимается” спуск с удержанием фокусировки.
5. Пауза 5сек.
6. Если управляющий канал остается активным переход на п. 3.
   Если нет:
7. На 1сек “нажимается” включение (в этом случае- отключение). Пауза 5сек.
8. Отключается питание.

ЗЫ. Обдумываю новый алгоритм автопосадки. Как будет время, сформулирую для обсуждения…

Гениально!

Серега, не льсти… Зазнаюсь, перестану здороваться… 😃
Вообще-то неплохо было добавить транзисторный ключ (ОЭ) на управление LM для четкого отключения преобразователя на время включения борта.
ЗЫ Забавно, но это оценили в высшей степени мои домочадцы… То что самолет сам прилетает домой фиг знает откуда, это не произвело впечатления. А вот то, что я щелкаю тумблером на пульте в одном углу комнаты, а фотик САМ (!) включается и начинает снимать с вспышкой… это показалось круто…😃

Обдумываю новый алгоритм автопосадки. Как будет время, сформулирую для обсуждения…

Очень интересно

Облетал на праздники свой свеже испеченый АП, не смотря на не летную погоду и многочисленные тех.накладки АП летает просто СУПЕР! Все настройки по умолчанию (кроме калибровок кончно же) .

Не оч. удобным показолось процедура настройки, а именно необходимость каждый раз отключать ГПС и подключать кабель, на мой взгляд интерфейс настройки логичней былобы перенести на порт с ЛРС.
Какие плюсы при этом появляются:
1 те кто пользуют ппмсум избавляются от процедуры каждый раз чтото отключать, достаточно просто воткнуть кабель в свободный разьем.
2 использующим ЛРС при соттветствующем его программном допиливании( обратный канал) можно менять настройки через нее прямо в воздухе,бонусом в обратный канал можно дублировать данные для наземки.

1 те кто пользуют ппмсум избавляются от процедуры каждый раз чтото отключать, достаточно просто воткнуть кабель в свободный разьем.
2 использующим ЛРС при соттветствующем его программном допиливании( обратный канал) можно менять настройки через нее прямо в воздухе,бонусом в обратный канал можно дублировать данные для наземки.

Серёга, это реально? Было бы удобно…

Для нашего передатчика LRS потребуется антенный коммутатор, а так… были такие мысли… Можно в принципе без обратного канала (без подтверждения) слать конфигурацию. Все параметры конечно нельзя давать менять, потенциально опасно. Ну и когда стал думать, а что бы хотелось иметь возможность менять на лету (в прямом смысле 😃) что-то ничего не придумал…
//-------------------
Мои мысли по посадке:

Самое сложное для определения логики посадки- простая и очевидная для пользователя привязка к точке старта и направлению старта (ВПП). ( Это посложнее “Бурана”, там все аэродромы уже были построены и зафиксированы…😃 ) При этом должна остаться возможность относительно гибкого конфигурирования этого процесса. Ну и хотелось бы по максимуму использовать текущий алгоритм, который проверен на практике и в принципе не так плох.
Вот что предлагаю:
Вектор посадки определяется вектором взлета OK.
Точка O определяется в момент получения готовности GPS, можно ее уточнить кнопкой (как и было). Дополнительно будет опционально автоуточнение- точка переопределяется координатами самолета в момент, когда GPS скорость впервые превысит “Общие->Мин. скорость”, если далее в течении 4 сек эта скорость не опустится ниже этого порога. Это автоуточнение будет происходить только один раз после включения АП (защита от переопределения позиции базы в полете).
Сама посадка осуществляется с круга ожидания, который по касательной находится на прямой, определяемой вектором взлета. Возможно 4 возможных положения этих кругов. C какого именно будет посадка, определяется в конфигураторе всего двумя очевидными параметрами-флагами: круг ожидания по/против часовой стрелки, посадка по/против направления взлета. Расстояние L определяется конфигурацией “Дополнительно->Удаление точки возврата”, центр круга находится на перпендикуляре к вектору старта/посадки на расстоянии “Дополнительно->Радиус кружения” (возможно плюс скажем 10м на компенсацию скольжения). Центр круга ожидания и собственно вектор посадки рассчитываются на основании позиции самолета в момент, когда самолет пролетел со скоростью “Общие->Мин. скорость” больше 4 сек и удалился от точки O на расстояние больше “Дополнительно->Удаление точки возврата”.
Теперь, когда круг ожидания определен, именно на него будет приводиться самолет в режиме RTH на высоту “Автопилот->Целевая высота”. В режиме LND аналогично в первую очередь самолет встанет на эту же высоту. После того, как целевая высота будет достигнута с точностью 20% и расстояние до центра круга ожидания с точностью 50%, будет выключен двигатель и самолет, удерживаясь на этом круге, будет снижаться с тангажем “Тангаж->Glide, макс. смещение”. (все почти как в текущей версии) Достигнув высоты “Дополнительно->Минимальная высота”, двигатель опять включится и будет вести самолет на этой минимальной высоте (очень надеюсь на баровысоту), пока его курс не совпадет ( не станет противоположен) с курсом взлета. После этого двигатель будет отключен, и самолет с нулевым тангажем (для сбрасывания скорости) будет планировать, выдерживая курс на точку старта. Конечно при попутном ветре будут перелеты, при встречном недолеты, но думаю все должно быть достаточно забавно…

.

но думаю все должно быть достаточно забавно…

😃 Будем пробовать…

В общем то логику посадки, я себе такую и представлял.
Гениально!

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

ПИДы, чутьё ,в общем то что нельзя настроить дома заранее.

Для нашего передатчика LRS потребуется антенный коммутатор

А если слегка доработать саму RFMку, разорвать связь между TX(2) и RXn(4),RFp(3) на платке модуля и вывести на прием вторую антенну, обойдясь таким образом без коммутатора, если я правильно понял на самом чипе это же разные ноги?

Может и так, честно говоря чип не изучал, но что то не хочется ковырять модуль… Ну и для организации полноценного обратного канала надо бы и на борту иметь ту же мощность, что на базе… Для конфигурации на лету в принципе в качестве обратного канала можно использовать сообщения OSD. Те. АП принял новую настройку, на пару сек вывел на OSD “Параметр: Значение”.

Давненько мучает мысля (уже озвучивал в этой теме), что по взрослому надо бы делать новый проект, в основе которого качественный двунаправленный канал. На борту только минимальная математика для работы АП, а на земле и любые дорасчеты, какие пилот пожелает, и виртуальная приборная панель, и OSD без ограничений, хоть во все цвета радуги, прозрачностью итп… Кстати по железу это пожалуй даже проще, чем сейчас сделано. На земле RFM-ка (BP), мега (для ее управления, управления трекером, и связь с ПК), ПК и джойстик. На борту таже RFM-ка, тоже мега (ну или STM, непринципиально) с минимальной обвязкой, кучка датчиков.
Увы, пока морально не готов… 😃

но что то не хочется ковырять модуль…

В это всё упирается…

С текущем функционалом АП полноценный обратный канал не требуется 200-300 м. достаточно для настроек, на врятли комуто придет в голову настраиват пиды на удалении 10 км. Хотя конечно можно обойтись и без него.Идея разделить антенны подсмотренна на некоторых 2.4ру модулях. там приемная антенна выполнена в виде дорожки на плате для оценки свободности каналов в эфире. Возможно и на RFMке достаточно будет перерезать одну дорожку и припаять кусок проволоки нужной длинны в качестве антены. В подтверждении полученных параметров настройки в виде сообщений на ОСД не вижу смысла, зачем? от записи ошибочных данных это не спасет, хотя если это не сильно усложнит программу то лишнем не будет.
В любом случае иметь возможность подключать к АП альтернативный двухсторонний линк былобы сдорово к примеру в виде 3DR модемов популярных у ардушников.
По поводу перехода на новое железо ,считаю ,что вся прелесть текущей реализации в простоте повторяимости и потенциал далеко еще не исчерпан, да и желающих повторить это не прибавит, а только отпугнет не многочисленных уже имеющихся.
По мне так лучше стабильно работающая система с ограниченным функционалом, чем красивая с наворотами глючаящая и сложная в настройке (по типу ардупилота).
А вот полноценный двухсторонний канал и наземный софт с картой ,записью треков и логов это былобы круто!

Ну сильно круто… И не к чему пока. Давайте этот проект до ума доведём…

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

Меня бы устроил существующий алгоритм (там все же точность посадки поменьше км 😃 ), если бы не наш холмистый рельеф местности, для которого важно предсказуемое направление посадки. Связываться с абсолютными координатами в модельном АП считаю идеологически неправильно… Все эти карты, полеты по точкам, указания целевых координат посадки… ИМХО Ну не должно этого быть в хоббийных самоделках с открытым кодом… Надеюсь поймете и простите… 😃

В подтверждении полученных параметров настройки в виде сообщений на ОСД не вижу смысла, зачем?

Так а в чем смысл обратного канала?

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

Сильно много хочется и сразу… Посмотрим как будет работать этот алгоритм посадки. А потом уже делать выводы.
Честно, старым алгоритмом посадки пробовал пользоваться всего один раз, и не понравилось, т.к. сильно не предсказуемо куда он сядет. А так всегда в ручную сажу, т.к. рельеф местности холмистый. Но теперь, когда точку посадки можно примерно определить и задать вектор взлёта, он же примерно вектор посадки, это уже интересно. Можно пользоваться.

Я то же мечтаю о полётах по точкам, и что? Проект постоянно развивается, всё не сразу…