flybrain. передатчик + приемник + автопилот. powered by stm32
У меня получилось так:
Нажал включил - держу горят все. Отпустил выключил - нажал включил мигает красный. Настройки на месте. Сообщить результат не могу - в результате неудачного коротыша на столе АП и пискнуть неуспел…😦 со снятыми лдо 3.3 шина питания 1.6 ом.
Дмитрий, у меня сильно плохие дела?
со снятыми лдо 3.3 шина питания 1.6 ом.
Скорее всего проц под замену. Я Дмитрию менял на его плате АП с такими же симптомами. Все подряд выпаивал и мерял сопротивление. В конце оставались только датчики (баро, аксель и гиро) и проц. Выпаял проц и КЗ с шины питания ушло. Впаял новый и все заработало.
Алексей, проверил, всё сбрасываться как по инструкции 😃 Красный мигнуть не успел а все настройки сброшены, проверял несколько раз, ошибки быть не может 😃 Все делал только с USB и СТДАПП был подключен… Попробуй у себя еще раз, а то действительно странное поведении… может после того как “ожило” теперь все корректно сбрасывается…
Дмитрий, у меня сильно плохие дела?
Тут я вам не помогу, попробуйте с Алексеем пообщаться по этому вопросу, пока глав. врача нет 😃 У меня один раз на шину серв 12 вольт от балансировочного разъема акка попало при посадке. Результат 2 проца на АП и на СТДАПП.
Выпаял проц и КЗ с шины питания ушло.
Снял бусину R2. На стороне проца кз нет… коротыш случился со стороны разъема видеосигнала…
Снял бусину R2. На стороне проца кз нет…
Бусина отключает не все пины процессора от шины +3.3. КЗ может быть по другим.
Ндя… оно и есть. Это был проц. 😦 Бедняга, он так хотел летать…
Вывод. Не допускать нештатного касания выводов.
Почем оно ныне?
Ндя… оно и есть. Это был проц.
Вы уже выпаяли? Без него КЗ нет?
Почем оно ныне?
В Элитане 290 рублей.
В Элитане 290 рублей.
Да выпаять -то… Да тихо. Около 3к.
Грабли… где я и где Элитан…
Грабли… где я и где Элитан…
Можно по почте, но это +300 руб и неделя (в лучшем случае) ожидания.
Есть рац. предложение. Кто что имеет против, высказывайтесь. 😃
В общем сейчас автовозврат конечно хорош, но мне кажется, можно сделать еще лучше… )
Сейчас АП от точки возврата идет до высоты возврата, планируя и экономя энергию, а потом, заняв высоту дома, движется дальше, удерживая ее (если конечно я все правильно понял). Это не очень хорошо например при полетах на дальние дистанции, получается АП относительно быстро занимает высоту дома и если она 50 метров то он будет следовать придерживаясь ее, соответственно ни о каком видео и РУ на дистанции например 20 км. и речи быть не может (если только у вас антенны не на 50 метрах от земли).
Предлагаю, чтоб АП от точки возврата (например, с высоты 1км и удаление 10км.) плавно шел к дому, как бы спускался с горки, рассчитывая необходимую скорость спуска, чтоб выйти на заданную высоту дома только в точки дома. Получиться, что он должен будет снижаться по 100 метров на 1 км. Как то так…
планируя и экономя энергию
А если его будет сносить ветром?
плавно шел к дому, как бы спускался с горки, рассчитывая необходимую скорость спуска
Кстати, в таком режиме с заданной скоростью АП все равно будет экономить энергию. Мысль дельная. Это же автовозврат, по сути аварийный режим. Не нравится спуск, ну лети сам если можешь…
Это же автовозврат, по сути аварийный режим
Совершенно верно, я точно так и мыслю. Нужно дождаться Алекса в общем. ) Я вот пытаюсь найти минусы в такой схеме, пока не получается, помогайте! )
А если его будет сносить ветром?
Это я несколько не правильно выразился (для простоты понимания так сказать), у нас АП умный и если ветер есть он это учитывает и все корректирует ) В общем, АП стремиться планировать в сторону базы если есть запас по высоте, а если не получается то он все делает красиво, проверенно 😃
В программе есть указания на критические углы. тангаж, крен. А если борт в 2 км по дальности и 3км высоты? РУ как всегда пропало не вовремя - разряд батареи, порыв ветра и прочие трудности стоящие в очереди на событие.
Соболезную по поводу потери носителя. Сам собирал из 3-х частей скай, когда хотел сделать мертвую петлю 😃 Высоты не было на 20 секунде… для АП она была 0. Не понятно реагировал на управление в конце или нет…
В программе есть указания на критические углы. тангаж, крен. А если борт в 2 км по дальности и 3км высоты? РУ как всегда пропало не вовремя - разряд батареи, порыв ветра и прочие трудности стоящие в очереди на событие.
Одно другому не мешает, в описанном мной алгоритме всего лишь должно выполнятся одно дополнительное условие - АП не должен давать снижаться самолету больше расчетного по траектории. Если он “бесплатно” получит подъем за счет термиков или еще чего то пусть на здоровье поднимается(ограничивая высоту заданным потолком) и рассчитывает снижение уже с учетом текущей высоты и расстояния до базы. Ограничение на углуы по крену и тангажу ни кто не отменяет. Если вы прилетели и у вас высота над базой 3 км. пусть он спокойно планирует по спирали или зигзагами(как по моему сейчас происходит) с разрешенным креном и тангажом. По сути все остается так как есть только добавляться одно условие…
Соболезную по поводу потери носителя. Сам собирал из 3-х частей скай, когда хотел сделать мертвую петлю Высоты не было на 20 секунде… для АП она была 0. Не понятно реагировал на управление в конце или нет…
Я так понял, непосредственная причина падения - отрыв крыльев из-за перегрузки при переходе с авто режима на стаб и ручной. Что произошло с датчиком высоты так и не понял. Может вибрация, может помеха, а может и плохой контакт на питании АП/приемника.
Я так понял, непосредственная причина падения - отрыв крыльев из-за перегрузки при переходе с авто режима на стаб и ручной. Что произошло с датчиком высоты так и не понял. Может вибрация, может помеха, а может и плохой контакт на питании АП/приемника.
Алексей, у меня есть крыло, предлагаю поставить твой АП туда и поэкспериментировать… Если что, то крыло не жалко 😃 поставим только АП с РУ без видео для начала, посмотрим как основные режимы отрабатывает твой экземпляр…
Алексей, у меня есть крыло, предлагаю поставить твой АП туда и поэкспериментировать… Если что, то крыло не жалко поставим только АП с РУ без видео для начала, посмотрим как основные режимы отрабатывает твой экземпляр…
Можно. Попробую в выходные вырваться из дома. 😃
Я в дороге домой. Буду в воскресенье.
Алексей, Петр, сколько раз напоминал про сброс в дефолт кнопкой при переходе с древних прошивок на новые? Полно новых параметров появляется. Они без начальных установок - кривые.
Алексей, ну ты же видел, что горизонт в противоположную сторону работает, нафига судьбу испытывать? Высота нулевая,АП в панике. Он хочет набрать высоту хотя бы10 метров, Дима правильно объяснил.
Задолбался я в телефон пальцем тыкать, в воскоесенье подробнее отпишусь.
Без правильно работающего высотомера летать нельзя!
Алексей, ну ты же видел, что горизонт в противоположную сторону работает, нафига судьбу испытывать?
Алексей, я был в полной уверенности, что так и должно быть (думал это типа положение самолета а не горизонта). И плюс ко всему, в мониторе IMU, положение объекта на экране в точности соответствовало положению платы в пространстве. И это окончательно убедило меня в правильности работы IMU. Более того, я настроил все реверсы таким образом, что в реальности стаб рулил в правильном направлении. То есть фактически проблема была только с отображением горизонта в OSD.
А вот проблема с высотой - до сих пор загадка. Я так и не понял, почему она отвалилась через несколько секунд после взлета.
Вообщем мистика. Надо будет попросить Алексея добавить возможность полного сброса содержимого микросхемы флеш памяти (она кстати это умеет сама аппаратно делать), что бы в совсем тяжелых случаях можно было бы начинать с нуля.
Алексей? Что это было? Можно подробней? Кнопка это…? То есть сбросить в дефолт все настройки всего? И снова прописать свой же конфиг?
Жмем кнопку, подаем питание. Как начнет мигать светодиод с интервалом в 1 сек, отпускаем кнопку. После этого входим в консоль и даем команду save config
Данные действия загружают начальные значения конфига в память в обход флешки. Чтобы сохранить их надо давать команду save config в КП. Нет гарантий, что начальные значения всем подойдут, но они гарантируют отсутствие глючных, изначально не заданных значений каких-либо переменных. В частности настройку ИМУ и компаса придется задать заново. Но там все быстро, и вроде как параметры налётаны.
информация обновляется ровно через каждые 12 секунд. Если например в терминале набрать “mon on baro” (или любой другой датчик), то строчки будут появляться по одной через каждые 12 сек.
Пинцип работы с ЮСБ со стороны АП- накидка данных в выходной внутренний буфер. По протоколу ЮСБ хост сам присылает прерывания выгребает этот буфер. Далее все прерывания ЮСБ и события по выдачи чего-либо в консоль находятся в самых низких приоритетах. То есть, есть вероятность, что какое-то частое событие с более высоком приоритетом не дает другим событиям отрабатываться.
Короче, похожий симптом с задержкой вывода в консоль может наступить из за сбоя I2C шины. Помониторь тестером напряжение питание, которое приходит на датчики. У меня на самой первой макетке питание приходило 3,1В. Так вот этого не хватало, и некоторые датчики вешали I2C.
Далее, если ОСД показывается на экране, то это явно не проблема кварца. Если кварц не запускается, то никакой картинки не будет.
Другим источником высокоприоритетных прерываний является СТДАПП. UART канал с ним работает на частоте 115200. Соответственно с ним или без него такой глюк произошел? Если с ним, выдернуть его, либо приемник.
Еще могу предположить, что поскольку глюк пропал после перезаписи дефолтных параметров, то скорее всего какой-то элемент ОСД с кривыми координатами мог гадить в жизненно-важное пространство ОЗУ. У меня нет в коде 100% защиты, от рисования ОСД чисто в видеобуфер. Если координаты выставить за пределы экрана, то может накрыть какие-то данные. Сброс параметров по кнопке гарантирует начальные координаты в пределах разрешенной видеопамяти. Дима с таким глюком никогда не сталкивался, так как я всегда давал ему платы с уже предустановленным конфигом. А у тебя и у Петра были прошивки, которые работали со старым ОСД версии 1. На вторую версию вы переключили конечно, а вот ресетили ли в дефолт все параметры, это вопрос…
Из моих объяснений не стоит делать вывод о том, что каждый раз на новой прошиве надо делат ресет в дефолт. Я всегда пишу, какая новая переменная появилась и какое начальное значение ей надо задать в КП. Адресное расположение старых переменных внутри страниц флешки я не меняю, а только с низу дописываю новые. Поэтому старые значения остаются без изменений.
Их там три… красный, желтый, зеленый. (подозрительно…) Алексей, тот крайний, он красный…
Крайний красный светодиод показывает либо связь по ЮСБ, если кабель подключен (мигает), либо (без ЮСБ) показывает состояние связи с СТДАПП или приемником. Если горит - нет связи, если не горит, то связь есть.
Как ведет себя объект (параллелепипед) в окне монитора IMU (в КП) в зависимости от наклона/поворота платы АП если изначально держать плату лицевой стороной (на которой стоит проц) вверх и USB разъемом к себе (аудио/видео разъемом к экрану).
Показометр горизонта в КП - это игрушка. Она может себя по всякому вести в зависимости от того как галочки на экране потыкать. Более того OpenGL своих глюков добавляет, особенно, когда YAW разрешено отслеживать.
Ставишь камеру на смолет, выводишь на телек с камеры. ОСД должно отслеживать горизонт при наклоне. Это единственно правильный вариант. А у тебя на видео оно с точностью до наоборот работает. Соответственно ты интуитивно параметрами реверса по рулям скомпенсировал. И всё бы ничего, но высотомер почему-то перестал работать. Не могу сказать почему, очень странное поведение. Не могло в дырку что-то попасть? Или может поток воздуха из какой-то щели туда задул? Не могло возникнуть давление избыточное в отсеке, где АП расположен, из за набегающего потока воздуха? Температура. Нет ли поблизости от BMP085 источников высокой температуры? По началу вроде работало, а потом резко переглючило. Закачай сюда лог чергного ящика этого полета, давай посмотрим на поведение высоты из лога.
по поводу алгоритмов снижения…
На этой неделе соберу все в кучу по новым фичам и испытаю на самолете. В принципе снижение сейчас должно быть более плавным. Дима правильно заметил, сейчас высота быстро падает, хотя попытки дифференцированного подхода к высоте в зависимости от расстояния у меня были заложены. Только это не срабатывает из-за задержки вариометра. У него лаг почти 2 сек. Соответственно оно как бы играет тангажом в результате. Здесь я тоже доработал, надо посмотреть как будет теперь.
Проблема то ведь в чем основная? А в том, что показание тангажа, не соответствуют реальному набору или сбросу высоты. В этом смысле меня радует оптимизм Тимофея, где он в своей теме недавно описывал алгоритм автовзлета с подбором тангажа. Конечно для того крыла, что у него на видео, на полном газу тангаж глубоко по фиг, оно и так ракетой в небо. А Скай в этом смысле очень тухлый аппарат. Он на небольшые углы тангажа начинает реагировать с задержкой до 2-3 секунд. И в Скае показания тангажа уж точно не отражают реальной ситуации с набором и сбросом. У меня была уже завязка на тангаж, так я на малой высоте в тестах, чуть в землю самолет не загнал, так как тангаж показывал +10, а самолет все равно еще снижался. Можно конечно требовать от пользователя добиться с помощью триммеровки тангажа именно реальной картины, но насколько это вообще разумное требование? А вот если не успели еще этот момент настроить, или не знаете как это сделать. И как быть в этом случае? Вообщем сейчас протестим, как поменялось поведение сброса высоты на автовозврате, перестало ли качать. Еще раз сопоставим показания тангажа и вариометра, там примем решение, на сколько доверять показаниям тангажа. Собственно самое гланое - малые высоты. Там решение надо принимать быстро и нет времени ждать, когда вариометр соизволит предоставить правильные показания.
И вопрос возник, еще . АП рулит рудером или нет? Его самому надо подмиксовывать ?
Сейчас рудер работает только на стадии удержания курса до определенных малых углов ошибки. Поэтому, рудер надо подмиксировать к элеронам для крыла.