Activity
нет там никакого шаманства с тренер портом, достаточно назначить миксы (пустить сигналы на передатчик) сразу пойдет PPM c тренерского разъема.
С разъема-то, допустим, пойдет. Интересен вопрос, как заставить этот разъем принимать чужой PPM ? Задача - подключить хеадтрекер, чтоб аппа “видела” его положение.
Для вертов помоему как раз ничего сложного. Нужно просто немного понимать геометрию происходящего, т.е. понимать как должны работать сервы на тарелке. Если покажете свой вертолет и обрисуете или сфотаете, как у него подвешена тарелка, я бы даже оформил вам миксы.
Расскажете, как тут с тренерпортом работать?
Да я разобрался. Прошивка не дружит с тренерпортом. Пришлось отказаться… Хотя за время пользования буквально влюбился в ее функционал и главным образом в мощнейший механизм микширования 😃
Подскажите, возможно ли в этой прошивке работать с тренер портом? Интересует подключение хеадтрекера.
ЗЫ: Возможно это где-то написано, но я пропустил…
Ну раз решили, значит решили. Только в качестве некоторого увеличения точности надо взять пошире диапазон. Хотябы 800-2200, или еще больше, до максимального. Сервам этот диапазон отрабатывать все равно не придется.
Не думаю, что это наиболее подходящий. Просто один из вариантов. Под разные задачи будет подходить разное. Точность это и так параметр меняющийся от расстояния и качества передачи, если его еще понижать, каналы начнут попросту самопроизвольно “плавать”. Скажем, тот же поворот камеры на “плавающий” канал я б вешать не стал, усугубляет головокружение 😃 Хотя опять же все зависит от уплотнения, если пару канало запихнуть в 1, то наверно это будет даже не заметно, но без канала-счетчика эта величина будет константой, и врядле равной 2 😃
Этот канал-счетчик, кстати, тоже можно обыграть. Его можно сделать общим на все дешифраторы, а можно для отдельных дешифраторов организовывать отдельные счетчики. Тогда можно оптимальнее организовывать быстродействие.
Сетап для примера: 4 канала на органы самолета(без мульти), еще 2 на поворотку камеры, и еще пару тем, которые не должны работать сильно медленно (мультиканал и счетчик 1…4), и остальные 8 каналов вешаем на оставшиеся 2 (мультиканал и счетчик 1…8. Такими каналами вполне можно менять настройки/режимы автопилота, крутить закрылки/шасси, открывать щитки, створки, и т.д. и т.п.).
по поводу кодирования сигнала при уплотнении с аппаратуры на дешифратор - наверное еще раз поменяю формат…
причина достаточно интересна: приемник при получении сигнала с передатчика может запросто пропустить например один пакет (!) и поэтому по каналам повторяет последние полученные верные данные…(! 😦 )
А что если кординально поменять протокол?
Мое предложение: задействовать еще 1 канал для передачи в явном виде (не то чтобы совсем в явном, но в виде ШИМ, конечно) номера текущей последовательности. Это, само собой, минус канал, но что получаем?
- избавляемся от таймеров(читай, догадок о номере текущей последовательности)
- можно будет менять количество каналов в мультиканале (соответственно и быстродействие этих суб-каналов). Т.е. дешифратор можно сделать хоть на 5(да хоть на 10 каналов), но если нужно некое, не самое низкое быстродействие, то используем из него только ограниченное число каналов, и аппа, соответственно, генерирует нам только небольшое количество переключений. В итоге, имея несколько дешифраторов, можно играться с компромисом по быстродействию и числу каналов.
- наверно можно будет вообще избавиться от меги, составным компоратором обойтись. Хотя тут не утверждаю, наверно, мега попросту будет более гибкой.
Это готовая плата дешифратора на 8-й меге.
А не поделитесь схемой и прошивкой?
Скажу больше. Достаточно даже одной кривой. Т.е. один движек на линейном отклике, а второй на кривой, равной разнице Ваших двух кривых. Помоему все это очень не сложно. Вопрос только в отображении, для последующего анализа и сохранения, значений газа движков, при которых обороты равны. Дальше аппроксимируем по этим точкам и получаем свою конфетку.
Правда для ДВС это может потребоваться делать при каждом выходе на поле 😃 Т.к. постоянные перерегулировки практически неизбежны.
В железе передатчика, помоему, полностью сей процесс не автоматизируешь, т.к. требуется в каждый момент времени знать как положения стиков, так и показания тахометров(по которым и подгонять стики). А с участием человека с листочком и ручкой это вполне реально, причем из кодирования нужно только вывод цифр положения стиков на экран.
Т.е. к примеру, хотим получить отклик по 5 точкам(2 крайние, одна центровая, и две промежуточные):
На первый движек каждый раз накидываем 25% тяги, а второй подгоняем по оборотам и записываем значение на листочек. После теста создаем кривую для второго движка, в которую и забиваем значения с листочка.
Единственное, что тут можно сделать Виталию, это исключить бумагу “из оборота” 😃 Но ИМХО, это такие мелочи, что и не стоит напрягаться.
Видимо требуется синхронизировать тягу движков на всем отрезке хода газа. Только я тоже не понял что именно товарищ предлагет реализовать. Видимо для этого нужно минимум два стика задействовать. Один на один двиг, другой - на другой. И в итоге добавляя газа первому, подстраиваясь вторым, и запоминая эти точки равенста тяги, можно выстроить равномерный отклик по тяге. Но это сущий гемор в плане программирования… Да и хорошо, если 2 движка, а если 4? а если 6? 😃
Возможный простой (для программирования) вариант решения, выводить просто значения стиков на экран (именно в цифрах, для точности), и по ним уже “химичить” свой нелинейный отклик на все движки(записав циферки на бумаге, и потом забив их в кривые откликов). Думаю того количеста точек, которое заложено в программе сейчас, вполне для этого будет достаточно.
Кстати, в какой-то прошивке видел смену значений(и выбор вариантов) поворотом крутилки - ацки удобно.
Нет. не правильно… триммер это фактически отклонение ручки управления ! и ничего больше !!
тянет самоль вниз - триммером фактически прижимаем ручку чуть на себя… ни о каких других точках в триммере речи нет и не может быть!
Извиняюсь, оговорился, речь шла про сабтрим. С триммером вопросов нет, это просто смещение стика.
- По поводу словаря, честно сказать, я так и не понял, но раз утверждаете, что работает, то не вижу повода не верить 😃
Прокомментировал бы только вот эту вашу фразу:
но сам словарь у меня слабый… я как то очень давно (лет 8 назад!) находил словарь из буквенных токенов… вот там действительно компрессия была!! текст объемом в килобайт сжимался в среднем байт до 300… эхх… знал бы сохранил тот словарь… а тогда просто запомнил алгоритм и сейчас вот его реализовал…
Любой универсальный словарь - это избыточность. По хорошему нужно по окончании оформления менюшек или возможно даже ближе к завершению вообще всего написания кода, взять выписать все фразы, да провести анализ частот буквосочетаний, и уже на основании этого сделать свой словарь, под конкретно эту программу. Фраз то по идее не так и много…
-
По поводу триммеров (проскакивало по тексту). Триммер всегда должен влиять на крайние точки расходов, иначе если двигать только нулевую точку, мы нарушим пропорциональность отклонения рулей. Единственное, что тут стоит оговорить: расходы конечных каналов(что подается на сервы) и расходы результатов микширования для этих каналов - должны быть(как бы это выразиться? 😃 ) разными ячейками памяти, т.е. это разные понятия. Триммер должен контроллировать центровку результатов микширования(т.е. он должен смещать как mid, так и min, max, но именно микса). А расходы канала должны накладываться на расходы конечного микса для этого канала, и на пропорциональность хода влиять не должны, их цель - только защитить рули модели от выламывания путем сильно большого отклонения мощной сервой и по идее они задаются в самом начале настройки модели, еще на земле, и в дальнейшем не трогаются.
-
По поводу OFS. Что-то вы жестокое мутите 😃 Применить его в качестве триммирования выхода миксов - идея не плохая… Но почему бы не глянуть, как сделано это же самое OFS в какой-нибудь футабе?
-
Возникла еще идея по поводу функционала миксов: может быть можно сделать так, чтобы процент микширования можно было изменять динамически в зависимости от значений каналов? Т.е. сейчас он задается жестко в настройках, и в принципе, учитывая наличие большого числа миксов, мою идею можно реализовать просто задействовав несколько миксов поочередно включаемых по мере движения стика, но это не совсем комильфо, т.к. будет ступенчатость, да и если что-то захочешь поправить, придется лазить во все эти миксы.
К примеру, применить динамический микс можно в такой ситуации: всем известно, что при увеличении угла атаки уменьшается эффективность элеронов, а руль направления все больше начинает выполнять функции как раз элеронов. Имея динамический микс, значение которого зависело бы от РВ, я могу при сильном отклонении последнего управлять креном модели уже не только элеронами, но и помогая РН. Т.е. в прямом полете РН будеть, просто как РН, а в глубоких виражах он будет помогать элеронам. В общем может не самый востребованый пример, актуален больше на тяжелых свистках, а на пилотажке только помешает, но применения можно придумать тьму…
Написал вчера компрессор текстового вывода…
пока в словаре всего несколько слов :
…U11_LCH_EDIT_CAPTION: .DB 0 , 0 , 0x63, "И ЛОГ. ", 0x61, "ОВ " , 0 , 0 ; НАСТРОЙК ; КАНАЛ ; заголовок для редактора mn_edit_rec.asm U11_LCH_EDIT_STR_CAP: .DB 0 , 0 , "ЛОГИЧЕСКИЙ ", 0x61, " ", 0 ; КАНАЛ U11_LCH_EDIT_REV_STR: .DB "РЕВЕРС ", 0x61 ,"А ", 0 ; КАНАЛ
Честно говоря не уловил, что вы пытаетесь пожать, сам текст программы или программу (результат компилляции) ?
Если первое, то зачем, вы его храните внутри памяти аппы? 😃
Если второе, то помоему при таком коде сборку делает только асм(компиллятор), и после сборки у вас в области данных будут собранные слова(занимающие полный объем).
Я конечно не бог весть какой знаток асма (только для оптимизации С-шных функций пользовал, внутри С-ного же компиллятора), но чтоб собирать слова нужно использовать отдельную функцию, типа strcat к примеру. Хотя strcat каждый раз будет искать конец первой строки, а это процессорное время. Если у вас все длинны строк заранее известны, то оптимальнее просто strcpy.
На мой взгляд оптимальным решением было бы выделить некий буфер длинной в максимальную длинну используемых строчек, и каждый раз в нем вручную собирать строчки, после сборки выводить содержимое на экран. Это реально пожмет область данных (правда в ущерб области кода, т.к. вызов функции с параметрами - это как минимум адрес функции и все ее параметры).
На C код бы выглядел примерно так(используя словарь из вашего примера):
char StrBuf[50]; //50 - к примеру
strcpy(&StrBuf, 0x63, 8);
strcpy(&StrBuf+8, "И ЛОГ.", 6); //8 - длина текста в 0х63 (НАСТРОЙК)
strcpy(&StrBuf+14, 0x61, 5);
strcpy(&StrBuf+19, "ОВ ", 4); //3+1 "/0"
print(StrBuf)
Хотя пока писал код уже сам понял, что тут апсолютно ничего не экономится, потомучто вызов подобной функции это минимум пяток байт в области кода, итого +20 байт +9 байт на добавочных фразах, которые вне словаря, а сэкономить то пытались на фразе НАСТРОЙКИ ЛОГ.КАНАЛОВ - длиной в 21 байт 😃
В общем, резать и собирать то, что и без того не длинно - идея так себе 😃 Не заморачивали бы вы себе этим голову.
Единственное полезное, что приходит на ум - найти в компилляторе галочку, что-то типа “искать одинаковые строки”, тогда можно не бояться писать прямо в коде кучями одинаковые строки - после компилляции на их местах будет один и тот же адрес, и соответственно фраза в памяти данных будет один раз, но это все равно не относится к отдельным словам внутри фраз.
Дмитрий, не поверишь ! тоже ношусь с этой идеей ! хотел это сделать еще с VCoder’ом но тогда не додумал до конца модель пересчета…
здесь хочу сделать подобное вашему описанию
Дак, собственно, что там думать… У нас есть набор каналов, и набор функций, которые формируют значения на этих каналах. Подаем на вход этих всех функций все наши триммы, получаем сабтриммы. Это фактически то, что делает аппа 50 раз в секунду (или сколько там точно) во время управления моделью.
Единственная здесь загвоздка, которую я вижу - это условные функции, но супер-гемороем то заниматься(делать триммирование под все возможные условия) ни кто не заставляет, каждый должен понимать, что модель триммируется под один конкретный режим (один набор условий), как правило прямолинейный полет без всякой выпущеной механизации. Соответственно на мой взгляд интуитивнее всего, да и проще, сделать чтоб функция брала текущие значения для всех условий.
Как я вижу применение такой функции:
- Оттриммировал самолет, сел.
- Если у меня есть условия на миксах, зависящие от РУДа, то отключил двигатель.
- Установил все тумблеры в режим обычного полета, все стики в нейтраль, газ в положение, при котором триммировал(в этом пункте слово все означает все, на которых висят условия. Т.е. если от движка ничего не зависит, то и по боку положение РУДа).
- Жмакнул кнопочку с функцией.
В простейшем случае ее можно жмакнуть даже прям в полете, т.к. практически она на него не повлияет.
С интересом начал следить за вашей темой. Не так давно обзовелся сабжевым передатчиком (Turnigy V2).
Есть одно небольшое пожелание по триммерам.
Сперва объясню, что меня не устраивает: тримммер в большинстве случаев служит для настройки самолета на ровный горизонтальный полет, без скольжений и наростающих кренов(в случае с вертолетами или планерами все примерно по той же теме), т.е. фактически это такая величина, которую хотелось бы раз настроить (во время облета модели) и забыть. Но в текущей реализации, если я оттриммировал модель, а после этого внес изменения скажем в расходы стиков, или задействовал экспанентный отклик(функции сами по себе нулевую точку не трогающие), то я теряю свои настройки триммера, т.к. они теперь начинают считаться через ту же экспаненту и следовательно “съезжают”.
Спасают здесь саб-тримы, т.к. их значения никогда и ни куда не “съезжают”. Я для некоторых самолетов прямо так и сделал, после облетки и триммирования, взял и пересчитал на листочке все триммера в их соотвествующие значения сабтримов (с учетом всех миксов и градиентов). После этого доводить настройку модели гораздо легче, т.к. триммеры уже в нуле(перешли в сабтримы) и соответственно все экспаненты и примочки работают симметрично относительно моего ровного полета.
Предложение: Добавить функцию (либо на кнопочку, либо на менюшку в настройках модели), которая бы пересчитывала текущие значения триммеров в соотвествующие значения сабтримов и суммировала их к уже существующим значениям, а триммера после этого сбрасывала в ноль. Т.е. технически эта функция должна пробежать по всем миксам пользователя, получая на вход отклонения стиков, равные соответствующим триммам, а на выходе значения для отклонения соответствующих серв, но сервы отклонять, конечно, не надо, а просто добавляем эти значения к сабтримам.