Полетные режимы вашего квадрика и направление на экране аппы
Для размышления: и WiFi и Bluetooth работают в одном частотном диапазоне 2,4 Ггц
Вы правы, но используя один и тот же частотный диапазон, в ВТ предусмотрено применение технологии расширения спектра сигнала путем скачкообразной перестройки рабочей частоты (Frequency-Hopping Spread Spectrum — FHSS) или более новая AFH (Adaptive Frequency Hopping). Поэтому соответствующие устройства работают не на отдельных частотных каналах, а во всем ISM-диапазоне 2,4 ГГц. Вместо того чтобы все время передавать и принимать сигнал на какой-либо определенной частоте, устройство Bluetooth “скачет” по разным частотам примерно 1600 раз в секунду (FHSS), что делает оборудование помехоустойчивым. Таким образом, соответствующие этой спецификации устройства могут мирно “сосуществовать” с другим радиооборудованием диапазона 2,4 ГГц.
Ну а плюс WIFi, конечно, в большей дальнобойности, которая в данном случае не нужна.
WiFi работает по схожему принципу: OFDM (мультиплексирование с ортогональным делением частот) 802.11ag и DSSS (прямая последовательность с разнесением сигнала по широкому диапазону) на 802.11bg
Так что тут вопрос скорее не в том, какой стандарт более помехоустойчив, а в том что реально будет надежно работать рядом с мощным FrSky передатчиком. Bluetooth вроде как проверили уже - работает. Вполне может оказаться, что и WiFi так же стабильно будет работать. Этого особо никто раньше не делал исключительно из-за отсутствия на рынке недорогих WiFi решений. А у WiFi все таки потенциал больше, хотя бы потому, что он есть во всех современных устройствах (телефоны, планшеты, ноутбуки), а блютус встречается все реже реже.
Тут уж Вам решать как руководителю проекта 😃
C какой стороны яйцо разбивать — не сильно важно. По сути проекта может завести в несущественные обсуждения. Как-то сложилось, что BT используется для коннектов в шаговой доступности и с большей персонализацией, а WIFI все же подальше и пообщественней. У них разные зоны комфорта. И в булочную мы же на танке не ездим 😎.
Блютус проще спарить. Для WiFi шаги уже значительно сложнее. Кто-то должен быть точкой доступа, кто-то DHCP сервером (не руками же адреса назначать), ну и т.д.
Тут уж Вам решать как руководителю проекта 😃
Да, ну, здесь все равны. Вернее так: побеждает здесь аргументация.
Если про меня, то себе я уже заказал пару eps8266, так что куда-нить их все равно пристрою. Пока вижу два варианта: wifi термометр с реле на обогреватель в теплицу, а второй в турнигу.
Блютус проще спарить. Для WiFi шаги уже значительно сложнее. Кто-то должен быть точкой доступа, кто-то DHCP сервером (не руками же адреса назначать), ну и т.д.
Вижу это даже гораздо сложнее: нужен вариант WiFi Direct для поля и коннект через роутер, когда дома.
Кто-нибудь сможет потестить такой вариант?
Конвертировать mavlink->FrSky не в воздухе, а на земле.
APM -> 3DR radio AIR -> 3DR radio ground -> Arduino -> 9X
D6 можно не подключать. Но на будущее может пригодится.
Нашу ардуину ставим не на квадрике, а в аппу. Принимаем mavlink по радиоканалу и конвертируем в FrSky протокол уже на земле. Аппе отдаем FrSky поток. Аппа будет думать, что данные ей шлет телеметрийный модуль FrSky и будет все отображать на экране.
Прошивка аппы - наша, прошивка ардуины тоже. Никаких модификаций в прошивках не требуется вроде. Единственный подводный камень: правильно подключить 3DR radio ground module - нужно взять TX и RX до USB. Возможно придется физически отключить FTDI на 3DR (наверное можно убрать пару резисторов)
Питание и землю я не нарисовал, они подразумеваются. Вопрос только в энергопотреблении: выдержит ли стабилизатор питания на аппе такую нагрузку? Можно запитать 3DR пока отдельно. Ардуину лучше запитать прямо от акка, чтобы она не мешала при перепрошивки аппы.
Преимущества такого решения: не требуются модули с телеметрией FrSky.
Недостатки: нужен hardware mod 3DR и аппы.
Обсудим?
А если на земле использовать такой же модуль что и в воздухе, то и отпаивать ничего не надо.
APM -> 3DR radio AIR -> 3DR radio ground -> Arduino -> 9X
Интересная идея,правда все равно прийдется еще модем покупать,а если все время дергать с компа на пульт,то идея плохая.
Обсудим?
По-мне так нет необходимости.
К тому же с дополнительными потребителями придется на пульте и питание переделать на импульсное.
Если есть 3DR телеметрия, тогда уж проще на ноутбуке смотреть. А то схема больно сложная получается.
Поддержка S.Port гораздо важнее, нежели внедрение 3DR в пульт
Тут мне еще маленькую идею подали.
А что если на наземную ардуинку добавить, какой то дешевенький жпс модуль.
И на радаре уже точно знать,где ты и где квад.
Плюс можно создать доп экран для поиска.Где стрелка на радаре будет показывать куда направлятся.😒
Жду 128…😦
Тут мне еще маленькую идею подали.
А что если на наземную ардуинку добавить, какой то дешевенький жпс модуль.
И на радаре уже точно знать,где ты и где квад.
Плюс можно создать доп экран для поиска.Где стрелка на радаре будет показывать куда направлятся.😒
Жду 128…😦
Для схемы с WiFi (или Bluetooth) в аппе планировалось использовать cмартфон и его экран для поиска аппарата. В этом случае дополнительный наземный GPS не нужен. Кроме того на смартфоне можно подключить GoogleMap и видеть в реалтайме где летит квадрик (ну или упал) как в MissionPlaner по данным бортового GPS. При наличии встроенного GPS в смартфоне можно выводить обе точки (местоположение квадрика и пилота) ну и направление, разумеется. Так что вариантов масса.
правильно ругалось. нужно в настройках 128 прошивки на первой странице поставить “FrSky mod done ON”.
а что делать если нет такого пункта и THR и AIL всегда включены, стики как будто не откалиброваны и THR начинает жутко мигать когда копетр включаю (данные вроде как должны начать сыпаться)?
брал 128 прошивку с форума и черех svn (чип 128A), все настройки поменялись, подсветки нет, при включении после прошивки пишет что EEPROM плохой и форматирует (не смотря на то что заливал прошлый eeprom, как в инструкции)
а что делать если нет такого пункта и THR и AIL всегда включены, стики как будто не откалиброваны и THR начинает жутко мигать когда копетр включаю (данные вроде как должны начать сыпаться)?
брал 128 прошивку с форума и черех svn (чип 128A), все настройки поменялись, подсветки нет, при включении после прошивки пишет что EEPROM плохой и форматирует (не смотря на то что заливал прошлый eeprom, как в инструкции)
- Если честно, то что-то не сходится. Если вы прошили эту прошивку для меги128 то настройка “FrSky mod done ON” точно должна быть. Причем эта фича не моя - эта настройка из обычной r812-128.
- Какая была версия прошивки раньше? И настройки от er9x? Настройки с r813 не проверял. И в какой версии формата ранее были настройки? (там есть варианты v2 и v3 в eePe на вкладке настройка, последняя строка) Если у вас v2, то такое возможно - я проверял только на v3. Попробуйте залить мои настройки (в аттаче к этому посту)
- FrSky Hardware Mod у вас точно сделан? На обычной r812-128 телеметрия (аналоговый датчик напряжения) работает?
- Если честно, то что-то не сходится. Если вы прошили эту прошивку для меги128 то настройка “FrSky mod done ON” точно должна быть. Причем эта фича не моя - эта настройка из обычной r812-128.
У меня последний пункт что-то про переключалку звука, я думаю что прошивка именно та что надо, экран mavlink-овый имеется
- Какая была версия прошивки раньше? И настройки от er9x? Настройки с r813 не проверял. И в какой версии формата ранее были настройки? (там есть варианты v2 и v3 в eePe на вкладке настройка, последняя строка) Если у вас v2, то такое возможно - я проверял только на v3. Попробуйте залить мои настройки (в аттаче к этому посту)
раньше была стоковая прошивка для 9xr, наверное я неправильно понял и старая версия eeprom просто не подходит
завтра попробую залить
- FrSky Hardware Mod у вас точно сделан? На обычной r812-128 телеметрия (аналоговый датчик напряжения) работает?
сделан с одной лишь разницей - резюка на 470 не нашел, поставил 2 по 220, т.е. 440ом
У меня последний пункт что-то про переключалку звука, я думаю что прошивка именно та что надо, экран mavlink-овый имеется
очень похоже, что вы залили 64 прошивку. Как раз настройки между 128 и 64 действительно несовместимы и в 64 версии нет настройки про FrSky
очень похоже, что вы залили 64 прошивку.
заливал вот с таким хешем через mega-isp
efaa5b9c4e6af8ed77c1dc5a00a206b9 er9x-128.hex
попробую завтра на свежую голову разобраться где мог косяк возникнуть
кстати в прошивке не может быть какой то чудо-проверки на сопротивление резюка внутри переделанного приемника, а то мало ли сопротивление не то и он пункты скрыват?
UPD: похоже надо еще инструкию от er9x почитать openrcforums.com/wiki/index.php/Er9x_user_guide - не в том меню ищу кажется
Всё, вопрос снимаю, надо было просто внимательно прочитать инструкцию от прошивки er9x, сразу всё что надо нашел и данные увидел на экране. Спасибо за мод =)
Спасибо за отличный проект!
Но у меня не получается одновременное подключение Bluetooth модуля + Ардуино.
Если не подключать TX ардуины, то без активного соединения с Mission Planner на пульте не обновляется статус GPS. Пульт все показывает только с Mission Planner, т.к. если подключиться с планшета, то опять не отображает статус GPS на пульте. Вероятно, в таком подключении, пульт будет показывать корректно только при активном обмене телеметрией с Mission Planner (думаю, FrSky победит BT в соревновании на дальность, потом телеметрия на пульте “остановится”)
Есть ли возможность подключить Ардуино к другому порту APM, включая TX на Ардуино?
Или возможность настроить APM, чтобы он отправлял достаточно параметров по MavLink?
Возможно этот баг уже исправлен? ))
Пока вижу только один путь: переключатель TX-ов ардуино и BT-модуля. Но это означает, что либо телеметрия на планшете(компе), либо на пульте.
P.S. Пробовал даже странное одновременное подключение TX от BT и TX ардуино: APM не может подключиться к Mission Planner, но пульт корректно отображает параметры ))
Но у меня не получается одновременное подключение Bluetooth модуля + Ардуино.
Arducopter, как это ни парадоксально, по умолчанию не шлет телеметрию в порт телеметрии. Поэтому, любым телеметрийным устройствам (все OSD и ардуина с моей прошивкой) необходимо сначала изменить параметры по умолчанию ардукоптера - подключение TX нужно только для этого. После старта ардуина ждет около минуты пока загрузится ардукоптер, после этого шлет команду, которая заставляет ардукоптер выдавать различные данные телеметрии с определенной частотой. Позднее никакие данные и команды от ардуины в ардукоптер не передаются (если телеметрия приходит), а идет только прием. В случае, если в течение 5 секунд нет телеметрии (например, какое-то устройство изменило наши настройки, что очень маловероятно), то снова шлем команду на передачу телеметрии. Исходя из этого предлагаю два решения:
-
Подключать линию TX ардуины только на период старта и после того, как начнете уверенно получать все данные на пульте - TX ардуины можно отключить (блютус все время остается подключенным)
-
Изменить параметры по умолчанию ардукоптера и не подключать TX ардуины вообще.
В MissionPlanner: Config/Tuning - Full Parameter List - Find - SR1
SR1_RAW_SENS=2 ( 2hz for raw imu sensor data )
SR1_EXT_STAT=2 ( 2hz for waypoints, GPS raw, fence data, current waypoint, etc)
SR1_RC_CHAN=2 ( 2hz for radio input or radio output data )
SR1_POSITION=2 ( 2hz for location data )
SR1_EXTRA1=5 ( 5hz for attitude)
SR1_EXTRA2=5 ( 5hz for VFR_Hud data )
SR1_EXTRA3=2 ( 2hz for AHRS, Hardware Status, Wind )
Остальные SR1_ оставить как были (у меня 0)
Это должно сработать на ардуино с моей прошивкой и на всех OSD.
Т.е. от OSD тоже можно не подключать TX.
Параметры SE1_ у разных OSD могут немного отличаться - смотрите исходный код (ищите поиском MAV_DATA_STREAM_EXTENDED_STATUS)
Единственный подводный камень с одновременным использованием блютус, это то, что MP выставляет свои параметры на период сеанса (он же тоже принимает телеметрию). Попробуйте и отпишитесь - я думаю, что ваш опыт будет интересен многим.
А использование второго порта под телеметрию возможно, но настоятельно не рекомендуется по причине высокой загрузки процессора. Но можете попробовать (в полете контролируйте cpu_load!)
Using UART2 port
This way you dont have to connect with the 3dr radio to get the mavlink data going. The Arduino will make a mavlink rate request to the APM. This is done by modifying system.pde around line 149 to look like this(AC 3.1RC7).//#if CONFIG_HAL_BOARD != HAL_BOARD_APM2 // we have a 2nd serial port for telemetry on all boards except // APM2. We actually do have one on APM2 but it isn't necessary as // a MUX is used hal.uartC->begin(map_baudrate(g.serial3_baud, SERIAL3_BAUD), 128, 128); gcs3.init(hal.uartC); //#endifBe 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!