Smalltim OSD and autopilot (часть 1)
/////… Подозрения только на радиовысотомер вертолета с которого бросали паратрупперов, в самом аэропорту локаторы давно выключены, оборудование снято, на том борту (по словам знакомого диспетчера, работавшего в тот день) своего локатора нет. Но как грится против лома-радиовысотомера нет приема кроме автономного самолета (АП).
Подозрения скорее всего “не о том”- слишком мала мощность (около 500мвт) и частота сильно выше ( около 4Ггц стандартные)
А вот ответчик запросто мог гадить, мощность там в импульсе ватт 300.
Ну в общем-то и до и после леталось нормально и над тем же местом, на вертолет просто подозрение из-за его подвижности - так совпалом может, что он на секунду другую глянул в мою сторону. Ответчик на нем же стоит или где? Про локатор, который иногда ставится на верт, мне кто-то грил, что чуть ли не ионизацию воздуха вызывает, так что всем электронным устройствам хренова, кто попадается на пути 😃
RSSI тоже в какой-то мере дает возможность пощупать границы не доводя полет до отказа из-за дальности.
RSSI мало что дает в реальных условиях. Он показывет лишь уровень сигнала на входе приемника (причем часто любого в данном диапазоне, а не только своего передатчика. Не знаю как Томас, а FUTABA - сигналы не различает.), но вторая составляющая С/Ш в любом случае остается неизвестной. Вечером на той-же фотке, покажу где берется RSSI на R608FS, можете его тоже на телеметрию вынести.
Мда, вот тут-то я и несогласен. Когда пришел новый приемник Томаса, соответственно незабинденный на передатчик, я его решил проверить с целью выяснения устойчивости диверсити к перегрузке по выходу РССИ разными сопротивлениями. Новый (зеленый двуслойный) приемник с прошивкой 4.0 при включении передатчика показал 10% и прыгал в этом диапазоне, после бинда - 98-100%. Чудеса ? Действительно, непонятно на каком уровне идет оценка уровня самого сигнала, Томас например не писал, что РССИ как-то связано с битыми пакетами. Этот вопрос надо ему задать. Кстати, благодаря навороченности современных телеметрий, мы можем вручную установить нижний уровень отсечки РССИ (например, когда приемник начинает переходить в ФС и прихватить этот диапазон с запасом) То есть, вылетав до 5% РССИ, мы будем гарантированно в радиоконтакте. Повторю - система оценки РССИ в этом приемнике линейна и обвала РССИ за короткий промежуток времени не замечено. Мало того, система оценки РССИ на маленьком и большом приемниках разная. На мелком - происходит хаотичная скачка уровня сигнала ±10%, на большом же - она более стабильна. Советую внимательно изучить полеты на дальность зарубежных коллег и понаблюдать за этим параметром.
Далее. Система Томаса - это только чуть большая гарантия стабильности управления самолетом и отнюдь не исключает полноценный автопилот. Как показывает практика такие мусорные производители как спектрум не могут выпускать стабильных приемников, устойчивые к помехам от видео-ВЧ. И систему Томаса я приобрел не с целью полета на -надцать км, а лишь иметь гарантию, большую, чем предоставляет производитель радио, не заточенного под ФПВ.
насчет гайцев - не летайте над ними и не летайте у города. проблем меньше на порядок
приемник с прошивкой 4.0 при включении передатчика показал 10% и прыгал в этом диапазоне, после бинда - 98-100%. Чудеса ? Действительно, непонятно на каком уровне идет оценка уровня самого сигнала,
Я думаю способы измерения RSSI у Томаса и Futab-ы похожи. Вот по этим картинкам rcopen.com/forum/f4/topic146799/38 видно, что RSSI это лишь уровень ВЧ несущей (независимо от целостности данных) на том канале диапазона, который в данный момент слушает приемник. А он, как известно, прыгает по 72 каналам (у Футабы). Поэтому, когда я рядом с приемником ставлю WiFi устройство, занимающее небольшой участок диапазона, но передающее информацию большимим пачками, то при выключенном передатчике вижу эти пачки, как узкие импульсы (Image0) -то есть результат пересечения каналов и момента передачи, что при усреденении дает незначительный подъем RSSI. А когда приемник ловит сигнал своего передатчика и прыжки по каналам синхронизированны с ним, то RSSI на 90% показывает усредненный уровень своей связи (Image4 например).
особенно если видно ногу микрухи!
На фотке - два почти одинаковых приемника Futaba: еще недоработанный R6008HS (вверху) и доработанный R608FS (внизу). Стрелками показано, где взять RSSI и признак потери пакетов (сигнал красного индикатора) Я вывожу оба сигнала через разъем DATA (предназначен для перепрограммирования приемника), отключая его от родных цепей.
Вывод RSSI - высокоимендансный (десятки килоом). Кроме того он весьма чувствителен к нагрузке и помехам. Выводить его напрямую и подключать к телеметрии нельзя! Нужно ставить между ним и выходным разъемом резистор 100-200 кОм (это защитит микросхему ВЧ тракта от помех и перенапряжений), а на входе телеметрии желательно иметь входное сопротивление порядка 1 МОм. Для ТМ от Тимофея, я убираю резистор нижнего плеча делителя (1 кОм); вместо него ставлю керамичесчкий конденсатор 0.5-1 мкФ (для усреднения импульсов); а резистор верхнего плеча (2 кОм) увеличиваю до 1 МОм.
Вывод “потеря пакета” - напротив - идет от транзисторного ключа на землю и рассчитан на нагрузку в 10-20 мА. Родной светодиод подключен к нему через резистор в 1 кОм, а затем к +3.3 В. Я подключаю свой светодиод (повышеной яркости) через резистор в 2 кОм к + 5 В приемника и вывожу его в поле зрения камеры.
Коллеги, я сделал всё, что хотелось иметь в базовом функционале.
Что именно - распишу позже.
Осталась одна вещь, пришедшая в наследство от времен активного дебага. Логи. Сейчас в логи пишется буквально всё, что только можно. Я хочу больше половины утоптать/выкинуть нахрен.
Сразу скажу, что структуру логов, единожды определив для релиза, буду в дальнейшем менять крайне редко - не хочется иметь потом проблемы с просмотровщиком логов. Вот то, что пишется в энергонезависимую память сейчас, каждые 0.2/0.5/1/2/5/10 секунд.
По крайней мере входные и выходные ППМ я хочу сократить до 2 байт или до байта или вообще выкинуть, и кое-что еще сжать-сократить-урезать. Что скажете?
typedef struct
{
U32 samplenumber;
U32 gps_date;
float gps_time;
U8 gps_numsatellites;
U8 gps_fixmode;
U8 ap_status; // bits: ap_active:assist_active:rcsignal_lost etc
float gps_startlat;
float gps_startlon;
float gps_startalt;
float gps_curlat;
float gps_curlon;
float gps_curalt;
float gps_curspeed;
float gps_curheading;
float compass_curheading;
float bearing_to_base;
float turn_rate;
float voltage1;
float voltage2;
float voltage3;
float current;
float mah;
float temperature;
float baro_curspeed;
float baro_curalt;
float pyro_curroll;
float pyro_curpitch;
float pyro_targetroll;
float pyro_targetpitch;
float targetthrottle;
float in_ppm_curwidth[8];
float out_ppm_curwidth[6];
U8 controlbyte; // designates correct dump sample;
} dumpsample_type;
Сейчас эта структура занимает 168 байт, выкину ppm и начальные широту-долготу-высоту по гпс, будет 100 байт. Всё, кроме текущих широты-долготы-высоты ГПС заменю на 16- или 8-битные целые с фиксированной точкой, будет в итоге 63 байта. Будет выигрыш во времени записи в 2.6 раза, и теперь на самой высокой частоте записи логов, 5 раз в секунду, памяти хватит не на 40 минут полета, а на 106 минут полета - почти 2 часа. То есть, 2-3-4 крайних полета будут всегда лежать в памяти.
Запись в память постраничная, по 528 байт, сделано кэширование страниц, и с маленькими записями лога меньше память придется дергать. Тоже плюс.
выкину ppm и начальные широту-долготу-высоту по гпс, будет 100 байт. Всё, кроме текущих широты-долготы-высоты ГПС заменю на 16- или 8-битные целые с фиксированной точкой, будет в итоге 63 байта.
Было бы хорошо одну и ту-же структуру записи использовать для лога и для выдачи наружу через цифровой интерфейс типа UART (для GSM модема, дополнительного контроллера и т.п). Эти же данные можно и через видеотракт гнать для следящей антенны, как ты раньше хотел. Посему GPS координаты точки старта я бы оставил. 16 бит вместо float - поддерживаю (8 даже для PPM - маловато, не говоря об АЦП). Насчет ужимания вообще, - главное не переборщить. Лучше оставить запасные поля (например дополнить размер структуры до степени двойки), чем потом менять формат от версии к версии. Даже 128 байт размера вполне достаточно. Ведь 5 Гц запись лога нужна в основном для отладки самого АП, для обычного разбора полетов достаточно 1-2 Гц.
А зачем все время гнать нулевую точку ? или я понял чего-то не так…
А зачем все время гнать нулевую точку ?
Для следящей антенны, например. Что-бы знала, где она сама стоит. Или нужно ставить GPS на следящее устройство, или запоминать текущие координаты перед началом полета (это возможно, но потребует лишних действий от пилота идополнительного интелекта на станции слежения, например как не потерять цифры при случайном рестарте). Ну и на перспективу, дополнительная группа GPS координат может пригодится при полете по точкам.
В программировании я не силен, но ИМХО, имея записанную точку старта в логе, можно парировать ситуацию, рассмотренную некоторое время назад. А именно, аварийную перезагрузку АП в воздухе с потерей координат старта 😊?
имея записанную точку старта в логе, можно парировать ситуацию, расмотренную некоторое время назад. А именно, аварийную перезагрузку АП в воздухе с потерей координат старта
Самим АП? Можно, наверное, только как отличить рестарт от штатного отключения питания?
Кстати, вопрос к Тимофею, сторожевой таймер Меги задействован? И вообще алгоритм АП как нибудь самоконтролируется?
Например, я в своих железках (на базе DSP) делаю в фоновом цикле постоянный “контроль контекста”: проверяю маски прерываний, указатель стека и некоторые стратегические регистры. А при обнаружении нестыковок - делаю запись в лог ошибок и рестарт программы.
Ведь сбои процессора могут быть вызваны не только ошибками в программе, но и помехами по питанию или входам, и даже космическими лучами. 😃
А кто против стартовой точки в АП ? Ну и пусть она сидит где-то в регистре памяти, нафиг ее гнать-то в логе и вниз транслировать. У игла проблема решена элементарно. Кладем самолет у антенны, он стартует ГПС, фиксит. После этого включаем наземную станцию. При отсутствии движения станция запоминает точку старта. В Игле предусмотрен учет “диаметра пятна” в пределах которого не происходит слежения за самолетом. По умолчанию 5 метров. И проблемы я тут никакой не вижу, даже если рестарт АП. Какая связь между логами и рестартом ?
Какая связь между логами и рестартом ?
Дима, представь себе, что самолет в воздухе, а у твоего Игла пропало питание (акк сдох, ветром антенну уронило, бродячая собака разъем выдернула и т.п.). Питание помошник восстановил, а координаты где взять?
Для АП таже проблемма. Рестарт в воздухе - это потрея коодинат базы. А если они есть в логе,хотя бы в перспективе их можно восстановить.
И чего ? Вручную слабо уж если такой косяк проскочил ? Просто если вопрос встал об экономии места, я считаю эта инфа реально не нужна. Пишите в АП точку старта в энергонезависимую память (так же как и калибровку датчика тока например), если это реально организовать.
Вручную слабо уж если такой косяк проскочил
Вручную что? Координаты базы в следящую станцию вводить будешь? 😃
Просто если вопрос встал об экономии места, я считаю эта инфа реально не нужна.
Главное “с водой не выплеснуть ребенка”.
Вручную что? Координаты базы в следящую станцию вводить будешь? 😃
Неа, поднять свой зад и перезагрузить/заменить акк/поднять упавшую антенну/убить собаку и т.д. и ручками направить на зону улета самолета. Не хуже получится, если уж такое ЧП. А самолетка не упадет, она же на стабилизаторе лететь может !
>Кстати, вопрос к Тимофею, сторожевой таймер Меги задействован? И вообще алгоритм АП как нибудь самоконтролируется?
Нет, не задействован. Нет, каким-то специальным образом не контролируется. Нет проверок рантайм структур на целостность или на соответствие контрольных сумм. Рантайм структуры четко разделены на “те, которым доверяем” и “те, которым не доверяем”. “Те, которым не доверяем” - это данные , обновляемые из прерываний. Для математики Х раз в секунду делается копия этой структуры. Можно на этапе создания копии ввести какие-нибудь проверки.
Для структур, лежащих во внешней памяти или для данных, приходящих снаружи/уходящих наружу по каждому чиху делаются проверки контрольных сумм.
Логика пилота не сильно тяжелая, математики немного, все критические переменные контролируются на правдоподобность. Покуда в пилоте только мой код вертится, можно бояться разве что только космических лучей. Когда начнем гонять юзерский код, всё будет строже.
Но, насколько я понимаю, если кристалл в полете бьет статикой, космическими лучами, или еще чем, то тут может произойти вообще всё что угодно и все наши проверки как мертвому припарки. Что будем делать, если статика или там дождь/град, птичья какашка убивает внешнюю память?
В общем, думаю, сейчас я стартовые гпс координаты всё-таки из лога выкину, буду писать их в отдельное место памяти вместе с результатами самокалибровки датчиков телеметрии сразу после инициализации ГПСа и датчиков. Надо только сделать так, чтоб во внешней памяти дырки не протереть, а то там только 100000 циклов перезаписи гарантируется.
Взведу сторожевой таймер. Чтоб автопилот, проснувшись после ресета в полете, имел полную информацию для возврата домой.
Надо еще чтобы после штатного включения он не посчитал пропажу питания на неделю неожиданным ресетом в полете и не устремился возвращаться туда, где были полетушки неделю назад 😃. Как это надежно определять - сходу не могу придумать.
В общем, подумаем.
По времени с ГПС
может произойти вообще всё что угодно и все наши проверки как мертвому припарки. Что будем делать, если статика или там дождь/град, птичья какашка убивает внешнюю память?
Ну зачем же так сразу. Если Мега убивается статикой или пожаром на борту, то совесть программиста - чиста. О смерти внешней памяти достаточно знать, что она умерла и принять меры к минмизации последствий. WDT задействовать - это правильно. Раз в жизни и незаряженное ружье стреляет, а раз в месяц и самая выверенная программа виснет. 😃
стартовые гпс координаты всё-таки из лога выкину
Ох, зря! Помятуя что ты номер полета уже изжил, даже анализ лога это значительно затруднит. 😦
Как это надежно определять - сходу не могу придумать
По логу, периоду времени с момента последней записи и ненулевой GPS скорости, что-бы отличить от пользовательского ресета для более точной фиксации спутников.
>По логу, периоду времени с момента последней записи и ненулевой GPS скорости, что-бы отличить от пользовательского ресета для более точной фиксации спутников.
Гениально, спасибо. 3 секунды и 10кмч думаю, будет за глаза. Только вот тогда придется запретить отключение записи логов и сделать максимально долгий интервал между записями равным 1 сек. Думаю, никто не будет в обиде.
Если знать стартовые координаты ГПС, то нет необходимости вообще что-то постоянно сохранять в одно и тоже место и соответственно нет опасности протереть дырки в памяти, записывая состояние пилота ежесекундно во внешнюю память. Автокалибровочные константы датчиков можно писать в память один раз на старте автопилота, если не обнаружено состояние “ресета в полете”.
Кстати, стартовые координаты ГПС я почему выкидывать собираюсь? Потому что стартовые координаты ищутся легко по логу. Последовательным перебором записей в логе “взад” от самой поздней записи. Глядим текущие координаты и смоттрим статус автопилота.
О, по логу видно, что в записи номер Х флажок инициализации ГПС единичка, а в предыдущей записи еще не единичка. Ок, это и есть та запись, где текущие координаты стали стартовыми.