Полетные режимы вашего квадрика и направление на экране аппы
Лучше с исходников тогда заливать (во вложениях и исходники и hex)
- Качаем Arduino IDE
- Разворачиваем архив с исходниками из этого поста
- Заходим в IDE выбираем “Скетч” - “Импортировать библиотеку” - “Add library”
- Выбираем папку mavlink-driver\libraries\AP_Common\ из развернутого архива и далее повторяем с каждой папкой из mavlink-driver\libraries
- Далее “Файл” - “Открыть” - “APM_Mavlink_to_FrSky.ino”
- “Сервис” - “Плата” Выбираем ардуину и “Сервис” - “Порт” - выбираем порт
- Компилим и заливаем.
Либо берем XLoader и шьем hex без второй ардуины, как обычно через USB
Еще можете почитать это - вчера у человека долго не заводилось, а причина оказалась просто в плохом кабеле… Ну я это не к тому привел, что у Вас так же, а к тому, что там я почти все причины расписал, почему может не работать и как выяснить где проблема, также там описано как сделать отладку в в терминале.
Все получилось через Arduino IDE на старой турниге с атмега 64 и мегапирате на Crius v1.
Индикатор режимов полета работает, указатель носа крутится, спутники считает.
В полете буду пробовать на неделе, если погода и время позволит.
Виктор, большое спасибо за прошивки и подробнейшие разъяснения.
Крайне похвально, что у нас не только умеют скачивать и прошивать, но и думать, изобретать и делать свое.
Можно немного хотелок?
- Скетч арудины не лезет в атмегу 168. Только в 328. Чуть уменьшить возможно? 168 дешевле.
- Возможно ли сделать скетч для так сказать ардуино-в-одной-атмеге. Т.е. тупо взять атмегу8, сконфигурировать ее на внутренний RC, припаять к ножкам пять проводов и все - ардуина без обвеса готова. Для народа это было бы самым простым и доступным вариантом.
- Возможно ли на пятом экране телеметрии вывести высоту и удаление от старта? Для полетов “по приборам” на коптере было бы полезно, если далеко отлетаешь, так что не видно куда нос, то возвращаясь по индикатору направления носа, неплохо бы знать - как высоко и далеко еще лететь.
- А что с таранисом?
Еще раз спасибо!
- Скетч арудины не лезет в атмегу 168. Только в 328. Чуть уменьшить возможно? 168 дешевле.
Arduino Pro Mini 328P 5v за 124 рубля с бесплатной доставкой. Куда уж дешевле
Возможно ли сделать скетч для так сказать ардуино-в-одной-атмеге. Т.е. тупо взять атмегу8, сконфигурировать ее на внутренний RC, припаять к ножкам пять проводов и все - ардуина без обвеса готова. Для народа это было бы самым простым и доступным вариантом.
Да, конечно. Но смысл? Потерянное время ради сомнительной экономии. Готовый девайс с обвесом стоит 124 рубля 😃 А лучше пачкой по 10шт брать - еще дешевле выйдет и море применений.
Возможно ли на пятом экране телеметрии вывести высоту
да, это можно, только не нашел куда впихать - экран маленький. Там есть еще место где arm/disarm, но туда в планах вывести PreArm check и сообщения Critical
и удаление от старта
А вот это сложнее. Пока не разобрался в прошивке ардукоптера - есть ли вообще такое рассчитанное значение. Похоже это на стороне ground station высчитывается по координатам GPS, а такими сложными вычислениями Turnigy лучше не нагружать, а то процессорного времени на что-то другое не хватит. Да и для кода места уже нет для меги64. Мне вот пришлось функции синуса и косинуса делать свои табличные, чтобы не подключать стандартную библиотеку, чтобы на atmega64 код влез, но поразбираться можно. Нужно тщательнее разобрать код ардупилота.
А что с таранисом?
Ну во-первых у меня тараниса нет - без отладки такое не получится сходу написать, а во-вторых, я не видел готового реверс-инженеринга протокола SPort. Хотя, признаюсь, особо и не искал. Таранис к приобретению не планирую, так что это не в ближайших планах точно.
Виктор,
прежде всего - спасибо за отличную разработку. Давно такую искал.
Вопрос : а не думали вместо переходника на Ардуине поправить код Ардупилота и выводить на свободный Serial данные сразу в нужном виде ? Там, правда, беда в том, что приемник требует инвертированного Serial (в паузе - 0, старт-бит - 1). Но это лечится выкидыванием из приемника инвертирующего каскада на одном транзисторе.
Вопрос
Это было в мегапирате 2.хх версий и вроде как в мультивие.
Сам пользовался - работало отлично. Но с 3.х версий - увы…
а не думали вместо переходника на Ардуине поправить код Ардупилота и выводить на свободный Serial данные сразу в нужном виде ?
Есть еще проблема загруженности atmega. Пустить телеметрию в формате FrSky на UART2 можно, но рискованно:
Be aware that enabeling uart2 on the APM will add more processor load to the already cogged CPU. Alt hold and auto modes can be affected by this hack. As of AC 3.1 a lot of improvements has been made to lower the load on the APM by the dev team. Running a extra mavlink port should work but do this at your own risk!
Сейчас есть возможность выводить CPU_load и тогда можно посмотреть как там с запасом мощности. Возможно, выведу куда-нибудь на экран CPU_load в следующей версии - тогда можно будет просто включить UART2 на дублирование данных телеметрии Mavlink и посмотреть что будет.
Вкусную плюшку вы придумали, было бы не плохо добавить на экране отображение Hdop GPS . Без этого параметра GPS 3D Fix не о чём не говорит.
Пожеланий и хотелок уже много, поэтому предлагаю сообществу совместно разработать дизайн и состав отображаемых параметров. Все желаемые параметры на одну страницу не войдут, поэтому давайте сделаем еще одну страницу № 6. Для владельцев atmega64 шестая страница, скорее всего, будет отключена. Вот список того, что можно отобразитьpixhawk.ethz.ch/mavlink/#HEARTBEAT (смотрите MAVLink Messages с #0 по #254)
Пожеланий и хотелок
Hdrop и 3D Fix это одини из главных параметров и к хотелкам типа здоровья сенсоров отношения не имеет.
Hdrop и 3D Fix это одини из главных параметров и к хотелкам типа здоровья сенсоров отношения не имеет.
но, насколько я понимаю, они нужны только в предстартовое время, т.к. когда поймали спутники и взлетели, GPS прием уже не должен ухудшится (предполагается полет на открытом пространстве), ухудшение приема GPS после взлета возможно только в случае каких-либо неисправностей (отломилась антенна и висит на проводке, сдох GPS и т.д.)
или у Вас бывает как то по другому?
Я задумывал изначально один экран предстартовый - там все предполетные проверки и один полетный, где отображаются важные для полета параметры.
но, насколько я понимаю, они нужны только в предстартовое время, т.к. когда поймали спутники и взлетели, GPS прием уже не должен ухудшится
Вот тут Вы сильно ошибаетесь, сигнал этот не всегда стабилен. Да и при старте получается это значение на АПЕ не посмотришь.
При высоком Hdop возможен улёт аппарата в Китай (из личного опыта) и не только у меня.
Ну ок, можно сделать и hdop. Вопрос только в том, как все это уместить на нашем маленьком экранчике
Вопрос только в том, как все это уместить на нашем маленьком экранчике
Конечно как Вы и сказали выше было бы не плохо чтобы высказался народ ( у кого какие хателки).
На первой странице экрана отображать самые жизненно необходимые параметры чтобы это было доступно и для atmega 64 и для 128 ,ну а на второй странице отображать все второстепенные параметры без которых можно и прожить, доступно будет только для atmega 128.
Хотелка.
Вид экрана:
12 0v 0A 12.5V 99% ]]]]*
.___
*
20 / 150 A.HOLD 3D 2,5м
где верхняя строка как у Вас,
далее положение точки взлета в середине, коптера и направления его носа относительно взлета - думаю по координатам это не так сложно посчитать, а координаты текущие и во время арма известны. Пусть грубо и упрощенно.
нижняя строка - высота/удаление от старта - режим полета - состояние GPS и HDOP
Положение газа и состояние датчиков - мне лично фиолтеово. Ручку я и так вижу, а датчики подразумеваются исправными, иначе летать идти не стоит.
Ручку я и так вижу
ThrOut показывает не тот уровень, что от аппы, а тот, что от ардупилота. Поясняю: даем газ на полную, переключаемся в режим LAND - газ будет убывать по факту так, как считает нужным ардупилот, вплоть до самого минимума и посадки, независимо от положения стика газа. Также и в других режимах. У меня был случай когда коптер взмывал вверх на минимальном газе (включился geo fence, потому что взял старую home position). Вообще этот параметр один из тех, которые помогут увидеть, быстро сообразить в чем проблема и предотвратить ситуацию, когда ваш коптер полетел в Китай ). А то, обычно в таких случаях, мы понимаем причину уже после потери/краша, потому что в воздухе нужно быстро принимать решения и иногда они бывают неверны. Ну, я пилот неопытный - поэтому пишу свои личные ощущения. У кого рука набита, тому вообще, наверно, никой телеметрии не надо )
То же и со здоровьем датчиков. Попала вода, например, на контроллер или холодная пайка, или еще миллион причин и коптер полетел куда-то неизвестно почему. А если увидел что mag health bad или gps health bad, то уже понятно почему и что делать. Также если здоровье не очень, то и не полетишь. А не зная этого полетишь и потеряешься. В этом же параметре отображается и включение FAILSAFE - поэтому и throut и health я бы оставил на экране.
Удаление от старта пока под вопросом. Отпишусь когда разберусь с этим.
Про направление носа: если квадрат сделать в центре, то по краям остается место, которое можно использовать. Предлагайте, что туда впихать.
Еще вопрос о слабовидящих. Не зря почти вся стандартная телеметрия FrSky сделана крупным шрифтом на страницах 1-4, потому что даже человек со 100% зрением в поле с трудом разглядывает мелкий шрифт. Если проблемы со зрением, то еще сложнее. Давайте подумаем, что сделать крупным шрифтом, а что мелким.
Кстати, для владельцев atmega64, положение носа отображается кратно 15 градусам, для остальных версий отображается более точно (округляется второй знак после запятой в значениях синуса и косинуса)
А если увидел что mag health bad или gps health bad, то уже понятно почему и что делать. Также если здоровье не очень, то и не полетишь. А не зная этого полетишь и потеряешься
Дело в том что в АРМ есть функция (приарм чек) если она включена и вы делаете с пульта арминг при не исправных или не калиброванных датчиках АРМ выдаст сообщение на экран о проблеме и не даст заармить.
Надо изучить детально функции Мишен Планера касающихся режимов управления АРМ
Про PreArm check я, разумеется, в курсе.
Удаление от старта пока под вопросом. Отпишусь когда разберусь с этим.
Посмотрел, как это сделано в коде MinimOSD-extra. Действительно, считается отдельно, но не бог весть как. См. code.google.com/p/minimosd-extra/…/OSD_Func.h , строка 44 //------------------ Home Distance and Direction Calculation ----------------------------------
UPD : откровенно не понял, зачем они пересчитывают длину градуса долготы в каждом цикле :
// shrinking factor for longitude going to poles direction
float rads = fabs(osd_home_lat) * 0.0174532925;
double scaleLongDown = cos(rads);
double scaleLongUp = 1.0f/cos(rads);
Здравствуйте.
Не нашел у нас дешевых ардуин, сделал сам.
Т.к. я использую приемник D8R-II без корпуса, жестко воткнутый в разъемы полетной платы (минус провода, минус разъмы, минус SPPM/SBUS = выше надежность, имхо), то сделал переходник, сразу втыкаемый в приемник.
Вот что получилось 😃
Скомпилировал прошивку (для тараниса), прошил, все работает.
Но есть вопросы.
- Время от включения APM до отображения параметров телеметрии на пульте очень велико - минут 10. Причем полетный режим, напряжение, какой-то Vfas отображаются мгновенно. Спутники ловит тоже почти сразу, так что дело в не спутниках 100%.Иногда вообще так и не начинает показывать телеметрию, кроме режима полета. С чем может быть связано?
- В чем измеряется высота? Загнал квадрик чуть-ли не в тучу - на экране 1,1. 1,1 чего? На уровне 3 этажа дома показывает 0,1.
- Что за параметр Dist? Изменяется от 2700 до 2850. Реагирует на поворот.
- Можно ли как-то увеличить скрость обновления данных телеметрии, хочется четко выдерживать углы поворота коптера, а т.к. задержка большая, смысла в этом не наблюдается.
Да, это все на экране тараниса, на турниге не пробовал еще. Но, думаю, разницы быть не должно - телеметрию же дает переходник в приемник, а не пульт.
Скорее всего что не хватает скорости быстродействия atmega. Какая у вас частота? От контроллера данные приходят со скоростью 57600 (несколько разных параметров примерно 2 раза в секунду, другая часть параметров 5 раз в секунду) по прерыванию. Отправка на frsky со скоростью 9600 происходит “в свободное время”, поэтому может просто не успевает все отправить, т.к. идет активный прием телеметрии от контроллера. В моей версии прошивки это немного оптимизировано, но требования к быстродействию ардуины тоже высоки.
Частота отдачи телеметрии с контроллера на ардуину задается (!) в прошивке ардуины
в файле github.com/vizual54/…/Mavlink.cpp
строка MAVRates[maxStreams] = {0x02, 0x02, 0x05, 0x02, 0x05, 0x02}
где 0x02 - частота 2 Гц, где 0x05 - частота 5 Гц. Что именно отдается долго объяснять (параметры отдаются группами) подробнее смотрите в файлах прошивки контроллера.
Также вам пригодится частота отдачи телеметрии от ардуины к frsky
смотрите github.com/vizual54/…/FrSky.cpp
там есть функции sendFrSky5Hz, sendFrSky1Hz - параметры, которые отдаются с частотой 5Гц и 1Гц соответственно.
Как можете там увидеть курс передается с частотой 1Гц, поэтому да, он бесполезен. Перенесите строку “bufferLength += addBufferData(COURSE, dataProvider);” из функции sendFrSky1Hz в функцию sendFrSky5Hz, еще в функции sendFrSky5Hz уберите строчки про ACCX, ACCY, ACCZ.
Это должно помочь и с быстродействием и с курсом.
Частоту выставил фьюзами как в обычной ардуино -осциллятор на 16 Мгц.
Правда сейчас не помню, убрал ли галочку “делить частоту на 8” - надо проверить.