Fail-Safe - Автопилот для полетов по камере
если раскручивать горизонтальную спираль
Это алгоритм определения собственного положения для собаки - но её не сносит ветром.
Если самолет не пилотажный и летит сам, как планер у Вовика, то наверное хватит только ГПС приемника. И Вовик вроде как игрался на енту тему какое-то время - хотя не исключено что он готовые юниты пользует.
А если енто неустойчивая пилотажка - тогда первой задачей станет стабилизация полета. А потом уже - куда ентот полет направить.
И ента тема близка Сержу. Интересно, как у него дела с его Ториком/прочим ?
Если самолет не пилотажный и летит сам, как планер у Вовика, то наверное хватит только ГПС приемника. И Вовик вроде как игрался на енту тему какое-то время - хотя не исключено что он готовые юниты пользует.
Самодельный я использую. Разработанный в Канаде: rcpilot.sourceforge.net/modules/rcap/index.php
Проблема в одном, эта штука требует размещения на борту навигатора. У меня летает eTrex. Это плохо. Он большой и помещается только на большом планере, да и работать с ним не очень удобно.
Было желание модифицировать программу, чтобы девайс работал с миниатюрным GPS приемником безо всяких навигаторов. Но пока не осилил программу расчета азимута по географическим координатам. Просто мало навыков писать расчетные программы для PICов. Один арктангенс чего стоил, да и с разрядностью траблы. Пока вопрос отложен на зиму. Если есть желающие помочь - велкам.
А сама идея возврата планера на базу по информации GPS - отлично работает, и спасает планер при полном выключении передатчика - если, конечно, у планера достаточно высоты.
Формул для определения расстояния и направления между двумя точками полнО в справочниках и инете. В данных целях можно использовать простейшие формулы, например, отсюда
mathforum.org/library/drmath/view/55417.html
Реализовать всю математику на готовых библиотеках или самопальном арифметическом пакете тоже не так сложно. Что касается алгоритмов, по-моему, достаточно просто постоянно доворачивать курс так, чтобы он был близок к азимуту на базу. При боковом ветре модель пойдет к базе по дуге, но это, наверное, не принципиально. При подходе к базе на заданное расстояние, наверное, имеет смысл отключать эту систему или менять алгоритм, иначе при прохождении над базовой точкой могут быть неопределенности в вычислениях.
Вообще, тема очень интересная. Я бы поучаствовал, но на текущий момент я подобными моделями не занимаюсь и GPS модуля у меня нет.
Формул для определения расстояния и направления между двумя точками полнО в справочниках и инете. В данных целях можно использовать простейшие формулы, например, отсюда
mathforum.org/library/drmath/view/55417.html
Реализовать всю математику на готовых библиотеках или самопальном арифметическом пакете тоже не так сложно. Что касается алгоритмов, по-моему, достаточно просто постоянно доворачивать курс так, чтобы он был близок к азимуту на базу. При боковом ветре модель пойдет к базе по дуге, но это, наверное, не принципиально. При подходе к базе на заданное расстояние, наверное, имеет смысл отключать эту систему или менять алгоритм, иначе при прохождении над базовой точкой могут быть неопределенности в вычислениях.Вообще, тема очень интересная. Я бы поучаствовал, но на текущий момент я подобными моделями не занимаюсь и GPS модуля у меня нет.
😃
Формул и не надо - арктангенс от отношения разности координат по долготе и широте. Проблема не в формулах и библиотеках. Проблема в том, что есть PIC16F876 и на нем надо написать эту формулу оперируя с разрядностью в 24 двоичных разряда. Причем корректно отрабатывать особые точки - т.е. когда долгота или широта модели совпадает с точкой возврата.
Чта касается алгоритмов - то автомат просто минимизирует разность курсов реального и на цель. Причем, GPS дает реальный курс, а не направление оси самолета. Поэтому при боковом ветре модель все равно летит точно на цель по прямой, а не по дуге, вне зависимости от ветра.
Перед достижением точки возврата не надо менять алгоритм, - модель будет летать над точкой восьмерками и кругами в перемешку - то что надо.
Жаль, что нет желания помоч. Для написания программы не надо иметь ни модели, ни GPS-приемника. Все исходные данные готов предоставить в любой момент, как и испытать софт в реале.
У меня уже есть прога на компиляторе PICC для PIC16F688 которая вычисляет азимут и расстояние на базу. RCCAP-алгоритм позволит по ней доворачивать одной сервой. Надо сделать определение момента, когда переходить от мягкого Fail-Safe, который повторяет последний пришеший импульс приемника, к жесткому, который включает автопилот. Может надо еще сделать алгоритм, который будет позволит газом и рулем высоты для поддержания высоты, смотря еще на напряжение батареи (уже меряется моей программой).
У меня уже есть прога на компиляторе PICC для PIC16F688 которая вычисляет азимут и расстояние на базу. RCCAP-алгоритм позволит по ней доворачивать одной сервой.
Как бы взглянуть на исходники?
😃
> арктангенс от отношения разности координат по долготе и широте
Это не вполне корректно. В зависимости от широты вклад градуса долготы разный.
> оперируя с разрядностью в 24 двоичных разряда
Зачем такие точности? Азимут на базу нам нужен с точностью в проценты. Абсолютные координаты - да, имеют большую разрядность. Но их надо только вычесть друг из друга, а дальше точность особой роли не играет. Я бы поступил так: по знакам дельт широты и долготы, а также по сравнению их модулей определил бы октант угла, а также вырожденные точки 0, 90, 180 и 270. Дальше просто поделить меньшее на большее (fractional деление). Если точка не вырожденная, то определить угол внутри октанта просто по таблице. Окончательно угол вычислить с учетом октанта.
Если непременно хочется посчитать, то можно использовать Си с math библиотекой. Обычно там есть float и double. Про PIC компиляторы, правда, не знаю.
> арктангенс от отношения разности координат по долготе и широте
Это не вполне корректно. В зависимости от широты вклад градуса долготы разный.> оперируя с разрядностью в 24 двоичных разряда
Зачем такие точности? Азимут на базу нам нужен с точностью в проценты. Абсолютные координаты - да, имеют большую разрядность. Но их надо только вычесть друг из друга, а дальше точность особой роли не играет.
Да я знаю про широту - она в моих широтах особой роли не игает(фиксированный множитель 1,3).
А вычитать просто так с малой разряднотью нельзя. Может оказаться долгота модели 29 градусов 59,999 минут, а точки возврата 30 градусов 00,001 минут. Поэтому до вычитания нужна полная разрядность координат, а это 7 десятичных разрядов. Вблизи точки возврата нужна высокая точность - до 0,001 угловой минуты географических координат, тогда точка будет отрабатываться восьмерками виражей. Это очень удобно, если проблема с дальностью канала - когда какой-нибудь злыдень включит передатчик на вашем канале. Тогда планер сам прилетит на точку старта и будет восьмерками постепенно снижаться, пока не попадет в зону уверенного приема вашего передатчика.
В теме rcopen.com/forum/f37/topic42591
есть записи реальных полетов моих планеров. Если запись открыть в Exelе , то последний столбик - высота планера в дециметрах, а два предыдущих столбца - географические координаты в формате ХХ градусов YY,YYY минут по долготе и широте. Можете посмотреть как реально меняются эти данные в полете модели. Там видна и целесообразная точность вычислений.
А вычитать просто так с малой разряднотью нельзя.
Вычитать - конечно, нельзя! Еще раз повторю свою мысль: точность абсолютных координат важна. Но над ними делается только простая операция (вычитание). Дальше такая высокая точность не нужна, поскольку результат арктангенса нам нужен с точностью в проценты и его можно вполне брать по таблице. Причем выгодно бить круг именно на октанты, тогда результат деления дельт всегда будет в диапазоне от 0 до 1. Если одна из дельт близка к нулю (или гораздо меньше другой дельты по абсолютному значению), то это можно считать вырожденной точкой. Таким образом, имеем точное вычитание, точное сравнение абсолютных значений и знаков, неточное деление, поиск по таблице длиной в несколько десятков значений и коррекция по октанту. Т.е. все довольно просто.
Т.е. все довольно просто.
Просто программисту, но не мне. 😦
Мне уже помогли надыбать кусочек готового кода кусочно-линейной аппроксимации:
www.dattalo.com/technical/software/…/arctan.asm
Как раз для октетов.
Но у меня опыта не хватает все это вместе объединить и встроить в уже готовую программу RCAP.
Как бы взглянуть на исходники?
Извините, только в 4 часа прошлой ночи заработало. Понятность кода соответствующая 😕
А реально ли, скажем, в Москве купить в розницу какой-нибудь OEM GPS модуль с документированной системой команд и форматом данных? Если да, то где, как и сколько это ориентировочно будет стоить?
Извините, только в 4 часа прошлой ночи заработало. Понятность кода соответствующая 😕
Спасибо, поразбираюсь. Для начала вопрос, а зачем Вы читаете два NMEA-сообщения, если в GPRMC есть и координаты и текущий курс? Разве не проще и короче читать одно сообщение?
А реально ли, скажем, в Москве купить в розницу какой-нибудь OEM GPS модуль с документированной системой команд и форматом данных? Если да, то где, как и сколько это ориентировочно будет стоить?
Для наших приложений лучше всего использовать стандарт интерфейса NMEA. Для целей навигации автопилота лучше всего подходит строка $GPRMC. Ее поддерживают практически все GPS-приемники любых фирм.
Спецификаця стандарта есть в сети www.navgeocom.ru/support/nmea/index.htm
Если есть интерес - могу прокоментировать его.
Купить OEM GPS в Москве - как за хлебом сходить.
Во, Андрей уже автопилот строит 😃
Я даже предполагаю их будет два- по числу работающих на данный момент приемников 😃😃
на дельтаплане, на котором ты летаешь- очень плохо получится 😃 а вот на планере , как у Володи- вполне. надо что- нибудь большое, самолетящее, желательно ушастое- тогда и через атлантику перелететь можно. 😃
P.S а чего это у тебя в конце файла nmea мои координаты указаны? 😃 это явно неспростааа… 😃😃
А реально ли, скажем, в Москве купить в розницу какой-нибудь OEM GPS модуль с документированной системой команд и форматом данных? Если да, то где, как и сколько это ориентировочно будет стоить?
Конечно - 1500 р.
Во, Андрей уже автопилот строит 😃
Я даже предполагаю их будет два- по числу работающих на данный момент приемников 😃😃на дельтаплане, на котором ты летаешь- очень плохо получится 😃 а вот на планере , как у Володи- вполне. надо что- нибудь большое, самолетящее, желательно ушастое- тогда и через атлантику перелететь можно. 😃
P.S а чего это у тебя в конце файла nmea мои координаты указаны? 😃 это явно неспростааа… 😃😃
почему два ? 😁
почему плохо получится ? Из-за ветра ?
координаты - это я добивал память до 4k - у меня программатор глючил на неполной прошивке 😃
если у тебя нету инерциалки, самолет должен лететь сам, если бросить ручки, и не завалиться в спираль,если имеет место небольшой крен, или еще куда нибудь- 😃. и скорость желательно поболе, а то против ветра не улетит…
Во время поворота самолета на заданный курс нужно будет знать текущий курс в реалтайме. Иначе, придется подбирать коэффициенты для конкретного дрынолета при конкретной скорости в конкретную погоду 😕 . Для быстрого определения текущего курса может помочь трехосевой магнитометр.
Почитать про магнитометры можно здесь . Так же имеется довольно приличное описание проекта автопилота с магнитометрами HMC1022+HMC1021. Правда, весит этот проектец под 8 метров и проц там ARM7-TDMI. Пока выкладываю фрагмент исходничка для магнитометра и навигации. Если будет интерес, выложу все остальное.
Вот тут - www.maxxprod.com/mpi/mpi-16.html кое что на эту тему.
Тема живая - что не может меня не радовать.
Купить OEM GPS в Москве - как за хлебом сходить.
А я вот чего-то не нашёл в Москве ОЕМ Sirf Star-III приемничка, по ентому пришлось прикупить парочку в корпусах:
Голубозубый и USB версии. Ну у голубозубого на контактах мини-USB разъёма похоже асинхронный сигнал сидит - потому как с обычным USB кабелем девайс то появляется то пропадает и ничего не определяется, а для USB идет только фирменный шнурок с конвертором посередине. А вот с USB версией у меня прокол - разобрал, а там - хрен чего разберёшь/отличишь, где там USB конвертер, а где - собственно GPS приемник. (Быть может Серж подскажет по фоткам, чего там надо от чего раздраконить) По ентому при необходимости подключать по USART придётся пользовать голубозубый, хотя он и дороже. Зато возможен дистанционный контроль на старте - наверное.
если у тебя нету инерциалки, самолет должен лететь сам, если бросить ручки, и не завалиться в спираль,если имеет место небольшой крен, или еще куда нибудь- 😃. и скорость желательно поболе, а то против ветра не улетит…
Я других самолетов и не держу, только те, что летают с брошенными ручками. Пилотаж и фанфлай не для меня 😃 Так что рулить можно и хвостом.
А в сильный ветер я не пускаю.
Тема живая - что не может меня не радовать.
А вот с USB версией у меня прокол - разобрал, а там - хрен чего разберёшь/отличишь, где там USB конвертер, а где - собственно GPS приемник. (
Тема не так чтобы живая, к сожалению… 😦
USB там и не отделишь от финишной части приемника, расчитывающей координаты. На чип-сете АНТАРЕС, к примеру, USB - это просто один из периферийных интерфейсов микроконтроллера, занимающегося расчетами.
Только нафига вам USB? На борту самолета хост USB организовывать - не приведи Господи, такой геморрой! Надо брать стандартный выход СОМ-порта в NMEA-формате. Тогда ваши наработки будут взаимозаменяемыми с другими GPS-девайсами. А если затянет под конкретный фирменный интерфейс одного производителя - можно попасть в лужу, - не факт что через год данный девайс будет на рынке, так что распространение наработки и даже тривиальный ремонт после краша может оказаться в тупике. А уж тем более блю-тус - не стоит заморочек.
Извините, только в 4 часа прошлой ночи заработало. Понятность кода соответствующая 😕
Андрей, я повторю вопрос - зачем читать два сообщения NMEA: GPGGA и GPVTG, если координаты и курс есть в одном - GPRMC?
И второй вопрос - софт уже отлажен и проверен в работе? Или тока поезд в пути?