OSD на ATmega1281
Получается ты ввел просто дополнительный датчик- показометр?
Ну не совсем… Хотя иметь именно простой показометр приборной скорости вроде бы все и просили… Действительно, не очень приятно видеть низкие цифры GPS-скорости, и нормальные значения приборной скорости позволят чуть меньше напрягаться в полете. Если сделать бороскорость основной, исключена блокировка двигателя в полете (как ты и хотел), и вообще определение состояния полета в некоторых случаях будет надежнее (правда в других случаях, о которых предупреждал, как раз наоборот…).
Если сделать баровысоту основной, во всех авто-режимах АП она будет использоваться как референсная (ты же и хотел в FBW использовать ее). RTH по ней по идее тоже должен приводить точнее. Практика покажет.
Не понимаю, что вы хотите получить от разности модулей скоростей GPS и баро… Только (!) в случае если направления их векторов совпадает, это даст скорость ветра. Но зачем эта скорость нужна вообще и тем более АП? Догадываюсь, что есть желание сделать газ как функцию не от тангажа а от этих скоростей… Цель достойная и тоже понятна- что бы в любой ураган самолет гарантировано возвращался. Напишите алгоритм хотя бы свободным текстом, обещаю подумать… Тк. в своих идеях на этот счет вижу больше потенциальных проблем, чем пользы.
у всех есть полет по точкам- почему бы и нам не попробовать?
Надо же хоть чем то отличаться… 😃
нельзя ли убрать управление пантильтом из АП.
Убрать несложно, сделаю (ломать не строить). Тем более что давно не пользуюсь. Но непонятно почему нельзя вытащить эти каналы прямо из приемника. Какие проблемы например со слоном?
По поводу использования бароскорости и скорочти ГПС автопилотом. Я выше писал как это можно использовать. Задается минимальный предел по скорости ГПС (например 20км/ч) и максимальный по бароскорости (наприемер 90км/ч). При уменьшении скорости ГПС ниже 20 км/ч включаем газ на круизный режим. Если скорость не выросла выше 20 км/ч даем три четверти газа и т.д. Это чтобы модель не летела хвостом вперед. Ну и наоборот при выходе за предел 90 км/ч (только по баро) - чтобы модель в воздухе не развалить. Выключение мотора на земле можно сделать при баровысоте ниже 3 метров плюс скрость гпс равна нулю.
ПС пишу с телефона - извеняюсь за возможные ошибки
ППС ненавижу сенсорные телефоны…
Тем более что давно не пользуюсь. Но непонятно почему нельзя вытащить эти каналы прямо из приемника.
Ну наконец то… Ими никто не пользуется.
А если приёмник в крыле как у меня? Я конечно вытащил из приёмника 2 аналоговых канала, это пропустив ещё два провода. Но это колхоз - пускать параллельно проводам I2C, где идут все эти же каналы, но в цифре. Было бы удобнее в плату АП воткнуть разъёмчик, если нужно использовать. А приёмник пусть живёт в крыле, только по I2C общается АП. Или сумм-ППМ, у кого как.
что бы в любой ураган самолет гарантировано возвращался.
Ну не то что бы в ураган, а в ветер, он всегда есть особенно на высоте. И бывает метров 200 от земли, достаточно сильный. Хотя на поверхности земли не очень.
Я в ураган не летаю. Всегда для полётов жду хорошую погоду.
Напишите алгоритм хотя бы свободным текстом, обещаю подумать…
Так вот и алгоритм:
По поводу использования бароскорости и скорочти ГПС автопилотом. Я выше писал как это можно использовать. Задается минимальный предел по скорости ГПС (например 20км/ч) и максимальный по бароскорости (наприемер 90км/ч). При уменьшении скорости ГПС ниже 20 км/ч включаем газ на круизный режим. Если скорость не выросла выше 20 км/ч даем три четверти газа и т.д. Это чтобы модель не летела хвостом вперед. Ну и наоборот при выходе за предел 90 км/ч (только по баро) - чтобы модель в воздухе не развалить.
Выключение мотора на земле можно сделать при баровысоте ниже 3 метров плюс скрость гпс равна нулю.
А если упал на горе +200м например как у меня однажды было?
Это тоже нужно всё учесть.
А если упал на горе +200м например как у меня однажды было?
У нас тоже рельеф интересный - шансов на нештатную посадку не в точке взлета с нулевой высотой практически нет… Ну в смысле высота однозначно будет не как на старте - либо выше либо ниже))) Сопки у нас кругом.
Как бы лучше батарейкой пожертвовать, чем на земле у своих ног по рукам винтом получить. Все ж падаем не каждый день.
Как бы лучше батарейкой пожертвовать, чем на земле у своих ног по рукам винтом получить.
Тут как раз противоречия нет… 😃 Если использовать на отключение баро-скорость, велик шанс будет и того, и другого ( да еще сломаный винт, сгоревший рег и двигатель)… А если по “И” еще ждать нулевую высоту (хоть баро хоть гпс) двигатель практически вообще никогда сам не отключится. С гпс-скоростью были случаи ложных кратковременных отключений в полете. В новой прошивке ожидает для отключения двига именно нулевая скорость (а не меньше минимальной) в течении 4 сек (а не мгновенно), поэтому случайные срабатывания почти исключены.
Задается минимальный предел по скорости ГПС (например 20км/ч) и максимальный по бароскорости (наприемер 90км/ч). При уменьшении скорости ГПС ниже 20 км/ч включаем газ на круизный режим. Если скорость не выросла выше 20 км/ч даем три четверти газа и т.д. Это чтобы модель не летела хвостом вперед.
Вся засада в деталях… Значение, полученные по этой логики, надо как-то (как?) увязать с тем, которое сейчас вычисляется по тангажу. (Регулировать газ просто по скорости, как у Тимофея, категорически несогласен). Ну и не могу же я дергать ступеньками газ. Значит надо менять с какой-то скоростью, не допускающей автоколебаний. Вообщем если все параметры и коэффициенты регулирующие эти и другие моменты вынести в конфигурацию, боюсь мало кто сможет настроить, да и сам через месяц забуду что с чем связано и на что влияет. Попробую что-нибудь придумать на эту тему, хоть и остаюсь в сомнении целесообразности форсажей против ветра…
(Кстати, Сергей ubd, обрати внимание, для этого нужно только гпс скорость и не непонятная разница с баро…)
Ну и наоборот при выходе за предел 90 км/ч (только по баро) - чтобы модель в воздухе не развалить.
В принципе проблемы те же. К тому же развалить мои носители можно только на выходе из крутого пике, когда газ и по существующему алгоритму будет установлен в минимальный. Ну тоже можно попробовать что-нибудь придумать…
надо как-то (как?)
Вот в том то и вопрос! )))
Вообщем если все параметры и коэффициенты регулирующие эти и другие моменты вынести в конфигурацию, боюсь мало кто сможет настроить, да и сам через месяц забуду что с чем связано и на что влияет.
Не знаю как объяснить… Скажем так, алгоритм который сейчас есть - он приоритетный, но если например бароскорость выходит за границу допустимого предустановленного, то газ нужно сбросить. Это понятно, что носитель развалить сложно. КМК, в случае очень тяжелого носителя (тот же Скай перегруженный аккумами) скорость набирает довольно быстро - АП начинает снижать самолет, скорость растет, при пикировании АП газ сбрасывает. Но после выравнивания скорость мгновенно не гаситься - инерция. И вот тут если снова газку поддать, да еще и по тангажу порулить (АП бывает не сразу занимает нужную высоту, немного промахивается) - появляется риск сложить крыло.
В новой прошивке ожидает для отключения двига именно нулевая скорость (а не меньше минимальной) в течении 4 сек (а не мгновенно), поэтому случайные срабатывания почти исключены.
Вот это мне уже нравиться… Об этом в первый раз слышу.
Вообщем если все параметры и коэффициенты регулирующие эти и другие моменты вынести в конфигурацию, боюсь мало кто сможет настроить, да и сам через месяц забуду что с чем связано и на что влияет.
Согласен!
Народ, а нельзя всю эту красивость заставить считывать данные с ардупилота ?
Можно всё, но этим никто не будет заниматься.
Наконец запустил серийную съемку фотика. Для этого слепил такой адаптер:
На своей старенькой мыльнице вывел на разъем необходимые цепи.
Работает… 😃
В конфигураторе для первого дискретного канала, выбирается канал и диапазон который будет включать съемку. Для каналов 2-4 можно задать только инверсию.
Логика такая:
Если значение в управляющий канал значение в заданном диапазоне-
- Включается питание фотика. Пауза 4 сек.
- На 1сек “нажимается” кнопка включения. Пауза 4 сек.
- На 2сек “нажимается” фокусировка.
- На 4сек “нажимается” спуск с удержанием фокусировки.
- Пауза 5сек.
- Если управляющий канал остается активным переход на п. 3.
Если нет: - На 1сек “нажимается” включение (в этом случае- отключение). Пауза 5сек.
- Отключается питание.
ЗЫ. Обдумываю новый алгоритм автопосадки. Как будет время, сформулирую для обсуждения…
Гениально!
Серега, не льсти… Зазнаюсь, перестану здороваться… 😃
Вообще-то неплохо было добавить транзисторный ключ (ОЭ) на управление 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 модемов популярных у ардушников.
По поводу перехода на новое железо ,считаю ,что вся прелесть текущей реализации в простоте повторяимости и потенциал далеко еще не исчерпан, да и желающих повторить это не прибавит, а только отпугнет не многочисленных уже имеющихся.
По мне так лучше стабильно работающая система с ограниченным функционалом, чем красивая с наворотами глючаящая и сложная в настройке (по типу ардупилота).
А вот полноценный двухсторонний канал и наземный софт с картой ,записью треков и логов это былобы круто!