Smalltim OSD and autopilot (часть 1)
В поле зрения датчиков не должны попадать элементы модели (или попадать как можно меньше), особенно нагревающиеся.
Делается временное крепление и подбирается экспериментально место. В поле, поднимаем модель на вытянутой руке с работающим винтом и смотрим по видео каналу поведение пунктира горизонта при покачиваниях. Должно совпадать с природным горизонтом. Погода при этом должна быть хорошей (не тучи и не боковое солнце). Для каждой модели расположение очень индивидуально (если конечно хочется компактного и красивого монтажа).
У меня так.
Мысль насчет наземного трэкера на будущее:
берем 1-3 трэкеров лепим на один или на разные пару тройку антенн (видео патч, яга, RC патч), бытовую видеокамеру с хорошим зумом (в районе 20+) - все это следит за самолетом. Вслучае чего мона переключиться на управление со стороны по наземной камере 😃 (если вдруг невоорженным глазом не разглядеть).
Канечна нуна точно все калибровать и сревы использовать с хорошим разрешением. А в идеале хорошо б еще триммерами серв точнее ловить модель в кадр камеры и по данным триммеров (уточненный вектор на модель) коорректировать координаты жпс, ну или будут альтернативные координаты относительно точки установки камеры - локальная система позиционирования. Удаление только она не покажет… хотя, зная линейные размеры самолета и фокусное расстояние в текущий момент наверное и удаление как-то оценить можно если самолет идеально относительно объектива повернут.
P.S. Кстати по камере можно потестить и точность наведения трэкера - оценить ошибку
Это как с большого бодуна смотреть в морской бинокль 😃
Коллеги, после некоторых размышлений 😃 в режиме удержания скорости по GPS или меньшей из скоростей по GPS и бародатчику решено скорость по GPS заменить на скорость приближения к базе, посчитанную по данным от модуля GPS. Математически - это проекция вектора скорости по GPS на вектор от самика до базы.
Ибо в текущем варианте может случиться ситуация, когда при очень сильном ветре скорость по баро будет высокой и скорость по GPS будет высокой, но самик летит нифига не на базу, а в какой-то момент, например, из-за бокового ветра, скажем, вправо от базы на 70-80 градусов. При этом самик будет таки приближаться к базе, и защита от сноса ветром не выстрелит, но из-за того, что скорость по GPS и баро будет большой, самик будет шпарить на каком-то уменьшенном газу, рискуя быть снесенным ветром или впустую расходуя энергию на противодействие ветру.
В новом варианте скорость приближения к базе будет = скорость по ГПС * косинус (70…80 град), т.е., сильно меньше целевой, и в итоге самик будет повышать газ, увеличивая скорость приближения к базе и выводя вектор своего полета ближе к вектору на базу.
В общем, если кто не понял или не пожелал разбиратья - привод на базу в условиях сильного ветра будет надежнее.
Когда на самике появится компас, можно будет считать скорость ветра прямо в полете и делать поправки на ветер, но об этом, и о полноценной гирокурсовертикали на замену пирометрам - пока молчок 😉
Монтажке тока радоваться можно, а по схеме всегда есть что спросить и покритиковать.
Да схема то там тривиальная. Видеоусилитель, сепаратор, компаратор, процессор, 4 светодиода, 2 кнопки, пищалка, АЦП и 2 стабилизатора 😃
Коллеги, в новой прошивке задействую 2й управляющий канал АП. Поскольку сам АП его не нюхает, а передает 2й управляющий на плату телеметрии, та его оцифровывает и отдает обратно АП, на 2й управляющий будет заведено только переключение экранов телеметрии.
Логика 1го управляющего не меняется, кому не хватает каланов, может 2й управляющий не использовать.
Следующие данные предполагается отправлять с борта на наземную станцию по видеоканалу или через радиолинк Слона:
U32 second;
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;
S16 gps_curheading;
S16 bearing_to_base;
U16 voltage1;
U16 voltage2;
U16 voltage3;
U16 current;
U32 mah;
S16 temperature; //8.8 bit
U16 baro_curspeed;
S16 baro_curalt;
S16 pyro_curroll;
S16 pyro_curpitch;
S8 targetthrottle;
Вместе с идентификатором пачки и контрольной суммой получается ровно 64 байта.
По видеолинку обновление данных ожидается ~20 раз в секунду, по радиолинку Слона минимум ~5 раз в секунду.
В случае работы телеметрии без АП формат пачки другой, данных меньше, но обновление данных в каждом кадре, т.е. 50(PAL)/60(NTSC) раз в секунду.
лог можно будет на мониторе трекера посмотреть (полистать)?
//
Тим, если кому уж очень нужно отдай мой комплект АПиТ, мне он все равно раньше сентября не понадобится
>лог можно будет на мониторе трекера посмотреть (полистать)?
Нет, лог на ЖК экранчике нельзя будет просмотреть-пролистать.
Это тащит за собой наличие хорошего объема памяти, более мощный проц, больше кнопок, сложнее софт. Зачем, когда можно слить лог с пилота на компук или просто посмотреть всё в реальном времени через GE или Ozi?
>Тим, если кому уж очень нужно отдай мой комплект АПиТ, мне он все равно раньше сентября не понадобится
Не, твой комплект задрючен для минимального веса и объема, пусть лежит ждет тебя.
Коллеги, я тут, наконец, воспроизвел, нашел и уничтожил редкий баг с дергающимся индикатором горизонта.
Баг проявляется только на многоканальных приемниках со скоростным (>50Гц) синхронным выходом PPM, и только при подключении всех 7 каналов, и вызван структурой софта (для максимальной точности захвата PPM прерывания PPM имеют наивысший приоритет, могут перебивать любые другие и даже сами себя).
При приходе 7 прерываний одновременно в момент, когда обрабатывается прерывание АЦП, процессор отвлекается на обработку PPM. А когда выкарабкивается из глубин всех этих вложенных вызовов обратно в АЦП, настает время выполнять уже следующее прерывание АЦП, ибо АЦП молотит во free run режиме, и ему, в общем-то, пофигу, чем занимается проц. В итоге новое прерывание АЦП вызывается в тот момент когда из старого еще не вывалились. При этом процедуре вышибает мозги и она пишет мусор или нули вместо данных с АЦП. Что уж там конкретно ломается, стек или еще чего - подробно разбираться не стал, ибо понятна главная проблема.
Писать прерывание АЦП реентерабельным, как всё остальное - дорого и не нужно. Попытки притормозить АЦП или завести объект синхронизации и сразу вываливаться из нового прерывания АЦП, если не завершено старое, ни к чему не привели, АЦП слишком самостоятельная штука со всеми его дурацкими флагами, триггерами и автозапуском, да и очень хочется сохранить постоянные интервалы на АЦП для правильного интерирования-дифференцирования…
В общем, бронебойное решение было найдено. Скорость АЦП была понижена вдвое, с 250 кГц до 125 кГц, а для сохранения высокой скорости опроса (150 Гц - полный цикл по всем каналам АЦП с учетом суперсэмплинга) ровно вдвое было понижено и число замеров в каждом канале. В таком варианте проблема исключена даже теоретически, у автопилота нет 14 входных каналов, чтоб затормозить АЦП в новом варианте.
Это всё вам, в общем-то, мало интересно, просто хотел поделиться радостью - месяц эта трудновоспроизводимая глюка висела и настроение портила.
За обнаружение глюки спасибо baychi.
Тим, как там с пилотами?
Если всё ок, то в понедельник-вторник-среду забираю.
Тимофей! С Вами связаться все равно что с Путиным - ЛС переполнены, мыло внешнее как будто в спам сразу летит.
Пару месяцев назад я спрашивал про неверное отображение напряжения на 5S акке в большой(старой) версии телеметрии. Наверно забыли уж. Хотел вот прошивку все таки попросить сделать. Напомню - резики в делители измерителя напряжений впаял на 4.7К и версия прошивки была у меня под 150А датчик тока(тоже осенью специально Вы скомпилили прошивку на базе). Версия прошивки 2.54-150.
Очень жду ответа.
Александр, не надо меня с Великим и Ужасным сравнивать, куда уж Ему до дел наших грешных.
4.7К поставили в верхние плечи делителей, а внизу остались 1К? Получается 5.7:1. Ближе к утру сделаю.
Александр, не надо меня с Великим и Ужасным сравнивать, куда уж Ему до дел наших грешных.
4.7К поставили в верхние плечи делителей, а внизу остались 1К? Получается 5.7:1. Ближе к утру сделаю.
Да вместо тех что 2K(верхние), нижние остались 1К.
Спасибо!
Коллеги, есть желание и возможность сделать правильный, но недорогой трекер, как побочный продукт будущей гирокурсовертикали для автопилота.
Хочу поспрашивать, какие нужны возможности в части работы с PPM.
Насколько я понял, нужно уметь добавлять к существующей пачке PPM на входе еще два импульса PPM от трекера, или заменять любые 2 канала со входа по выбору. Так?
Какие разъемы, форматы, крепление к голове-шапке-бейсболке считается устоявшимся стандартом, чтоб устроило всех? Как бы вам было удобнее его настраивать?
Одна кнопочка - задание нейтрали - пойдет? Надо пищалку нейтрали?
Какие выбрать размеры, корпус-некорпус? Можно и замельчить, сделать 10х20х10 мм, можно и большую коробку, как лучше?
Продублирую в тему о трекерах, там, наверное, более к месту.
Тим а трекер чево именно имеется в виду?
И на маил ру загляни
Звиняй, не уточнил. Трекер головы.
Ну у трекера главная задача не плыть, с пищалкой это на любителя а с одной кнопкой, думаю лутше будет, крепление универсальная клипса хоть к бейсболке хоть к ремню очков ну и корпус поменьше конешно
Плыть не будет, гарантия 100%. На север-юг вставать не надо будет, гарантия 100% 😉
Встал как хочется, или сел в кресло как хочется, устремил взгляд прямо, нажал пымпу, и готово, трекер запомнил положение прямо, и поехали.
Ну я в этом плане в шарки XGY 1000 встроил там и температура не гуляет и всякая фигня на голове не висит и с пультом через разъём наушников соединил. Вопшем красота получилась. А в чём смысл трекер к пилоту привязывать пилот сам по себе рулит а камера от головы
А пилот тут ни причем вообще. Просто часть будущего железа, по зрелым размышлениям, будет отличным трекером.
Вот, уже первая идея - крепеж велкро петлей на очки.
По разъемам я думаю полюбому с фиксацией надо чтоб не выскочили при чрезмерном болтании головой а датчики какие планируеш использовать