Самодельный передатчик (часть 2)
…Вот уж точно согласен, если добавить- при выборе сервы.
Я тебя уверяю - ВСЕГО, ЧЕГО УГОДНО!
Это основополагающий принцип при построении любых комплексов.
Да вот хоть такой пример: я просто меняю настройки копиллятора CVAVR в программе для работы с энкодером AS5043 и компилирую программу. Для настроек printf типа “int,width” результат “Program size: 1419 words (2838 bytes), 34,6% of FLASH”, а для настроек “float,width,precision” уже “Program size: 3135 words (6270 bytes), 76,5% of FLASH”. Я не поменял ни одной буквы в тексте программы, а от меня уже хотят в два раза больше ресурсов. Я на ровном месте попадаю при прочих равных на вдвое более мощный камень. За желание выводить числа с плавающей точкой. У меня вообще нет таких чисел. Не нужны. Зачем вводить избыточность?
Не нужна 14-ти канальная аппа тому, кто летает на тренере, не имеющем даже РН. Но, может быть она просто необходима, если человек без такой аппы чувствует себя несчастным вплоть до суицида…
Потому, что это тоже комплекс: “модель+аппа+человек”…
Мы можем подарить ему 12-ти канальную аппу, и какую-нибудь модельку от <имярек> за $20000, а он все равно в петлю полезет - двух каналов не хватило…
“то имеет место неверно сконструированный канал…” - абсолютно согласен!
Не буду “спорить о вкусе ананасов с теми, кто их ел!”(с)…
Придется все же собрать этот кодер, чтобы говорить с присутствующими на одном языке, а пока, чувствую, мне не удается правильно изложить свое ИМХО… Ну да, фиг с ним…
Крайнее уточнение:
Это цитата из меня 😉:
“Если же машинка отказывается подчиняться еще не достигшим “упора” органам управления (разумеется тем, которым обязана подчиняться) - то имеет место ошибка в программе…”
Это ответ на нее от автора программы:
Если Ваша задача недопустить ограничения, а оно есть, то имеет место неверно сконструированный канал…
Это полное согласие с автором программы от участника форума:
“то имеет место неверно сконструированный канал…” - абсолютно согласен!
Но фраза именно этого участника и ввергла меня в дискуссию:
А то, что ручка продолжает двигаться, а машинка уже стоит - это нормально, не беспокойтесь!
Поэтому вопрос к Denn (и я удаляюсь паять кодер):
Так все же, тот факт, “что ручка продолжает двигаться, а машинка уже стоит” - это нормально или “имеет место неверно сконструированный канал”?!
P.S. Ничего личного!
Ты, главное, сам ни на кого не обижайся…
Я вот тут повыступал - так и понял, что не было (и нету?!) вовнутри меня однозначного понимания логики масшатбирования по EPA. 😊
То мне кажется, что масштабирование должно быть по всему диапазону от одной EPA до другой, то вот вроде как должен быть все же запас по краям для триммирования и микширования. Но не за пределы EPA, это точно!
Может быть так: EPА поставили, внутрь диапазона процентов так по 20 от края отступили, и по этим пределам отмасштабировались? А?
…Авось сообразим сообща, как оно следует быть.
P.S. Ну так не зря выступал. По крайней мере мне самому стало немножко яснее… 😁
P.P.S. Надо будет сделать шкалу, стрелочку длинную на РМ-ку повесить и поисследовать как на моей “Футабе” дело обстоит.
Так все же, тот факт, “что ручка продолжает двигаться, а машинка уже стоит” - это нормально или “имеет место неверно сконструированный канал”?!
У Denn нет противоречия, он только недостаточно точно процитировал мою фразу, обрезав - “Если Ваша задача недопустить ограничения, а оно есть,…”. Все зависит от того, что Вы хотите получить. Посмотрите на диаграмму обработки сигналов, сколько звеньев там участвует в определении конечных точек… Не забудте, что есть еще три режима полета не показанных на диаграмме. Если программа возьмется умничать и менять расходы по своей логике, вряд ли это будет для пользователя удобно и даже предсказуемо… На всякий случай уточню, программу пишет программист, канал конструирует пользователь. Поэтому на Ваше “программист- дурак!”, ответил “кто как обзывается, тот сам так называется!”. 😃
Я тебя уверяю - ВСЕГО, ЧЕГО УГОДНО!
Это основополагающий принцип при построении любых комплексов.
В абстарктном смысле - конечно! Речь о выборе путей и методов решения проблемы. Утрировано- Вы предлагаете поставить 10кг-вую высокопрецензионную серву и ограничить ее ход до 10%. Я намекаю что ту же точность и усилие можно получить от ширпотребовской 1кг-вой всего лишь правильно оценив длину плеч качалки и кабанчика.
ЗЫ Для меня полемика тоже оказалась полезной. Как в анекдоте- “объяснил раз, объяснил два… Сам уже понял…”. А какого фига для масштабирования внутри EPA мне нужно было конечные точки функции??.. Можно обрезать значения перед EPA до фиксированных ±120%, (напомню ±100% полный ход стика, ±120% соответствует границам допустимой ширины канального импульса), как и было до введения EPA, и затем масштабировать значение по EPA, считая крайними точками функции именно допустимую ширину канального импульса. Вроде бы все логично- EPA однозначно определяет крайние углы отклонения и нет обратной зависимости EPA->начало ограничения.
Всем привет!
Народ! Сильно не давите на программера! Разработку то наверное имеете на халяву, что он смог от своих щедрот ВАМ подарить, оторвав от семьи, то и получаете. Либо пишите прогу сами, через пол года как минимум, может и получиться что-то и у вас.
А вот с ограничением свободы рульки это зря, когда сигнал будет слабым, а дешифратор в приемнике дешмански-простецкий - то броски могут быть за пределы желаемого, и пульт тут СОВСЕМ не помошник, золомаете радёмую, лучше в разрыв преобразователь расхода с ограничителем воткнуть (простая игрушка на одном smd PIC-e, или циф рульку, а мовсем даром ->но с гарантией, это с тягой лишние минут десять повозиться .
И нервы, и сервы в по_ряд_ке !!!
Отчасти сам задумываюсь, функция ЭКСПАНДЕРА в наворотах пультов – СПОРНАЯ!
Физику процесса - сигнал / шум / ошибка - не рассматриваю, *серенькое* напрягайте сами.
Да никто меня тут не обижает… 😃 Вы же понимаете хорошая постановка задачи - это 80% программы… А остальное- кодирование, документирование, сопровождение итп… это уже так… по мелочи… ремесло… Вот в постановке то народ и помогает активно, за что я, конечно, благодарен…
Поэтому на Ваше “программист- дурак!”
Ну, если Вы так трактуете мое " - то имеет место ошибка в программе…", то…
неудивительно, что мы говорим на разных языках…
“кто как обзывается, тот сам так называется!”.
Учитывая, что я никого не обзывал (достаточно воспитан), то пока буду себя считать достаточно умным для участия в подобных дискуссиях… Признаю себя “ошибающимся писателем разных программулек” 😉… Это действительно так - у меня есть небольшой опыт сочинения программ как для микроконтроллеров (PIC, asm), так и под Винду (BorlandC++Builder)… И всегда испытывал трудности с математикой из-за весьма слабых познаний в оной… И всегда в моих программах были ошибки, и никогда мне не приходило в голову обижаться, если мне на них указывали, напротив - просил пользователей внимательнее тестировать программу и сообщать мне о глюках и недоработках…
Пожалуй, сделаю еще попытку пояснить, почему считаю неприемлемой ситуацию, когда “ручка продолжает двигаться, а машинка уже стоит”… Попробую на примере… Думаю, большинство из присутствующих сидели за рулем автомобиля… Представьте теперь, что один оборот рулевого колеса поворачивает колеса, а второй оборот уже не влияет на их положение 😮… Причем, колес не видно, и о том моменте, когда они начинают реагировать на руль можно только догадываться… Представили? Вы будете ездить на таком авто? Я - нет! Хотя приспособиться можно, но не лучше ли починить рулевое?😉
Так и в случае с кодером… если при его настройке возникает такая ситуация и причиной тому недоработка в программе - программу надо попытаться исправить…
Если причиной тому неправильное “конструирование канала” пользователем - надо объяснить пользователю, как сконструировать канал правильно, а не говорить “…это нормально, не беспокойтесь!”…
Вот и все!
P.S. Если бы мои познания в арифметике позволяли, то я бы конкретно написал, как надо сделать, но… увы 😊!
P.P.S. По прежнему - ничего личного! И в мыслях нет кого-то обидеть, а, тем паче - обозвать 😛!
Да и сам - не “красна девица”! Надеюсь на взаимопонимание!
Вот уж не ожидал, что моя шутка так будет воспринята… Ведь даже смайлик поставил… Прошу прощения, постараюсь аккуратнее шутить… Не обижен, и даже не думал обидеть…
Вы же понимаете хорошая постановка задачи - это 80% программы
Ы! Я, кажется, в личке писал - я 7 лет оттрубил в софтверной фирме, аналитиком-постановщиком задач… 😒
Потому иногда буквоедствую не по делу. Привычка. Профессиональная деформация. Сорри глубокое…
Давайте рисовать (ссылка на файл с рисунком):
За основу взята “Футаба 6EX” - больше мне опереться не на что.
Считаем минимальное и максимальное время канального импульса 1mS и 2 mS (ось “А”), закладываемся в то, что это по 140% отклонения качалки в каждую сторону (как 100 канального стика + 40% от триммирования и микширования). Если EPA установлены в -100%…+100% (ось “B”), и расходы стика в -100%…+100% (ось “C”), то по зеленым стрелкам рассчитываем -100% и +100% канального импульса и масштабируем -100% стика в -100% канального импульса, а +100% стика - в +100% канального импульса. В процессе эксплуатации от значения стика по красным стрелкам получаем потребное время канального импульса. 100% стика дадут 100% импульса, 40% могут добавить микшеры, итого получим 140%. Если микшеры или неизвестно кто еще в сумме со стиком дадут более 140% - отклонение качалки будет все равно 140%, лишнее просто отрежем “исходящим контролем”.
Теперь посмотрим на работу при установке EPA в -100%…+100% (ось “D”) и расходах -80%…+140% (ось “E”).
Сначала “-80%”. Расчет по зеленым стрелкам. Зная, что -140% EPA равно 1mS, определяем время канального импульса для -80% (значение расхода). Масштабируем -100% расхода в это канальное время. В процессе эксплуатации от значения стика по красным стрелкам получаем потребное время канального импульса. 100% стика дадут 80% импульса, 40% могут добавить микшеры, итого получим 120%. Если микшеры или неизвестно кто еще в сумме со стиком дадут более 140% - отклонение качалки будет все равно 140%, лишнее просто отрежем “исходящим контролем”.
Теперь “+140%”. Расчет по зеленым стрелкам. Зная, что +140% EPA равно 2mS, определяем время канального импульса для +140% (значение расхода). Масштабируем +100% расхода в это канальное время. В процессе эксплуатации от значения стика по красным стрелкам получаем потребное время канального импульса. 71% стика дадут 100% импульса, 40% могут добавить микшеры, итого получим 140%. А 100% стика дадут 140% импульса если микшеры или кто-то еще что-то добавит получится больше, но все, что свыше 140 отрежется “исходящим контролем”.
Все так?
Еще чего-нибудь нарисовать?
Думаю, большинство из присутствующих сидели за рулем автомобиля… Представьте теперь, что один оборот рулевого колеса поворачивает колеса, а второй оборот уже не влияет на их положение 😮…
Не совсем корректное сравнение, КМК. У вас, скорее, не автомобиль с рулем, а корабль с одним рулем и тремя румпелями. Вы держите один румпель, а два других - у помощников, которые вам даже и не очень сильно подчинены. У вас задача - держать курс по компасу, у первого помощника - парировать, скажем, порывы ветра, а у второго - обеспечивать красивую синусоиду кильватерного следа. Вам надо срочно курс поменять. Вы свой румпель на упор положили - а лопасть всего на 70% отклонилась. Порыв ветра идет, и все нарастает. Второй помощник компенсирует, значить, в меру своего разумения…
И, заметьте, каждый помошник имеет право обидеться, что его руль уже на упоре, а лопасть недоотклонена. Или что его румпелю до упора еще далеко, а лопасть все, уперлась в корпус. Вы им мешаете ничуть не меньше, чем они вам.
Вариантов решения примерно два:
- Вы объявляете немножко более главным, и говорите, что угол ±70 - чисто ваш. Большего обязуетесь не требовать. Но максимального угла отклонения (±100) Вы своим румпелем никогда не достигнете. Какие права будут у помощников - уже не ваше дело. Может быть они вообще на вахте никогда не появятся.
- Вы объявляете себя самым главным и работаете во всем диапазоне отклонения, от минимума до максимума (±100). Но тогда не обижайтесь, что Вы еще не добрали 20 градусов, а руль уже на упоре - один из помощников добавил +30 (да еще этот урод и сердится, что он хотел добавить 30, а добавилось всего 20).
Еще варианты?
Мне кажется, некоторая путаница возникает из-за двух понятий - “расходы” и “конечные точки”!
“Конечные точки” - это те положения, за которые серва не имеет права заходить ни при каких условиях, ибо сломает себя или модель… “Расходы” - это установленные пользователем пределы отклонения рулевых поверхностей для комфортного управления… За пределы “расходов” (но не далее “крайних точек”) машинка , мне думается, может отклоняться при микшировании нескольких каналов…
Для “умных” серв установка “крайних точек” возможна программированием самой сервы, для обычных серв это надо делать в передатчике… В имеющихся у меня передатчиках для этого предусмотрена общая функция - EPA! Именно потому, что в EPA объеденены понятия “крайних точек” и “расходов” - возникают некоторые затруднения с их установками 😦… Хотя, пока микшеры не подключаешь, проблем особых нет…
Но если возникает необходимость микшировать каналы, то с “процентами” надо разобраться 😠… А тем более, если самому писать программу, высчитывающую эти самые “проценты”…
Не уверен, что я до конца “въехал” в диаграмму, предложенную EagleB3, но, мое мнение, ход стика всегда должен оставаться полным для любых установок “расходов” и “крайних точек”…
Счас попробую тоже графически изобразить свое видение (если получится) 😵…
Для EagleB3:
Вы невнимательно читали мои посты 😃!
Я ж не против того, что “стик уперся, а руль еще не дошел до нужного положения”! Я согласен поделить права на румпель с помощниками или даже совсем отдать их (пусть другие работают 😉)…
Я возражаю против ситуации, когда у меня или у моих помощников еще есть, куда двигать руппеля, а руль уже “встал колом”… мол, “хватит- наработался!”😁
P.S. Запутался с румпелями и рулями!
Не моряк, однако…
Я возражаю против ситуации, когда у меня или у моих помощников еще есть, куда двигать румпеля, а руль уже “встал колом”… мол, “хватит- наработался!”
Это значит, что вы видите правильное решение проблемы по первому варианту, но с маленькой оговоркой: требуете так настроить управление, чтобы руль лег на борт ровно тогда, когда все три румпеля лягут на упоры в нужном направлении. Не раньше и не позже. И каждому румпелю Вы при этом обязаны назначить предел, в которых он может влиять на руль.
В приведенном мной рисунке это значит, что “запас в 40%” использоваться не должен; EPA используются как предельные точки отклонения.
Далее необходимо разобраться с вариантами построения алгоритма. Например, вот вариантик для начала. Управляем первым каналом (“Первый румпель”):
- первый канал считаем “главным”. Задаем для него расход. Расход более 100% в этом случае теряет какой-либо смысл. (Но надо еще про это подумать! Помогайте!..)
- для “второго румпеля” задается % микширования (допустим, 40%), он достигается всегда при 100 отклонении ручки стика второго канала - без учета установленного для второго канала расходов;
- для “третьего румпеля” задается % микширования (допустим, 30%), он достигается всегда при 100 отклонении ручки стика третьего канала- без учета установленного для третьего канала расходов;
- главный канал берется с учетом расходов. Все эти проценты становятся весовыми коэффициентами (долями):
– a) для расхода главного канала 100% получается 100+40+30 = 170 долей
– б) для расхода главного канала 25% получается 25+40+30 = 95 долей - EPA машинки первого канала пересчитывается по полученному коэффициенту в “тики сервы” (миллисекунда/доля),
- При эксплуатации виртуальное положение стика главного (первого) канала (0…100% для примера “а” и 0…25 для примера “б”) пересчитывается через “тики сервы” в значение времени для машинки первого канала;
- При эксплуатации абсолютное положение стиков микшируемых (второго и третьего) каналов (0…100%) пересчитывается через “тики сервы” в добавку времени для машинки первого канала.
- Делаем проверку (“обрезание”) на невыход за минимальное/максимальное время канала и посылаем посчитанное время на машинку.
Но еще надо продумать как быть с возможным возникновением закольцовок. Типа “первый канал микшируется на второй, второй канал микшируется на третий, третий канал микшируется на первый”.
Нормальный алгоритм, не плохой и не хороший, он просто вот такой.
При рализации этого алгоритма потенциальные грабли, вывихивающие мозг:
- проценты микширования (устанавливаемые во втором и третьем канале) делаются чистой абстракцией. Пилот сам должен помнить (и считать… ощущать…), что реально он оперирует вот теми самыми весовыми коэффициентами. Почему? Потому, что % микширования нельзя взять в качестве % от EPA, так как положение стика главного канала с учетом расходов не может быть % EPA. В приведенном примере 25+40+30 = 95, а вовсе не 100. Можно держать эту сумму в голове, можно сделать калькулятор в программе кодера, можно делать контроль при сохранении настроек на то, что сумма расхода главного канала и всех микшеров, завязанных в первый канал равна точно 100%…
Вот мои “художества” 😊…
Зеленым нарисован микшируемый канал (один пока) и его процент влияние на максимальные “расходы”…
Понятно, что другим может быть совсем непонятно, что я тут изобразил 😃 (так же, как и с объяснениями на словах)… но… как умеею 😉…
Знаю, что любую геометрию можно описать формулами, но проделать это для мною же нарисованного - не в силах 😵!
А вот случай “перекрестного” микширования (“первый канал микшируется на второй, второй канал микшируется на третий, третий канал микшируется на первый”) совсем не представляю, ни зачем это надо, ни как сделать 😃…
А вот случай “перекрестного” микширования (“первый канал микшируется на второй, второй канал микшируется на третий, третий канал микшируется на первый”) совсем не представляю, ни зачем это надо, ни как сделать 😃…
Зачем - не важно. Как сделать - микшеры назначить.
Но если такое перекрестное или кольцевое микширование возможно, значит:
- либо такое миширование должно быть запрещено идеологически и программа кодера должна препятствовать организации таких завязок;
- либо алгоритм управления должен корректно его реализовывать.
Я тему читал всю (но давно) и, мне кажется, здесь уже была эта ссылка rconline.ru/modules/smartsection/item.php?itemid=6…
Если да, и уважаемые авторы программы это читали, то можно коротко пояснить… обработка каких функций, использованных в обсуждаемом кодере не рассмотрена в статье по ссылке?
Просто, я статью бегло читал и ранее, и сейчас просмотрел… Вроде бы, в ней рассмотрены и конечные точки, и микширование, и экспоненты 😃…
Чего не хватает для математики кодера?
"Поэтому вопрос к Denn (и я удаляюсь паять кодер):
Так все же, тот факт, “что ручка продолжает двигаться, а машинка уже стоит” - это нормально или “имеет место неверно сконструированный канал”?! "
Ещё раз попробую объяснить: ручка продолжает двигаться, а машинка уже стоит - это нормально при работе микшера. Это значит, что все ручки поставлены в такое положение , что модель должна лететь ( или ехать … ) с таким положением руля.
Если миксеров в канале нет, то , конечно, это не совсем правильно, хотя при желании можно оправдать и такой режим. Всё зависит от необходимости управления.
Лично меня такое положение вещей вполне устраивает, как и JR , и Hitec.
И особенно приятно использование аналоговой крутилки для настройки этих положений!
Ещё раз попробую объяснить:
Спасибо за попытку!
К сожалению, по причине моего ничтожного опыта обращения с микшерами, я опять ничего не понял 😊…
А может, у меня с Вами логика не совпадает?
К примеру, такой логический ход мои мозги не переваривают:
ручка продолжает двигаться… Это значит, что все ручки поставлены
Как может двигаться то, что уже поставлено (остановлено, то есть) 😃?
Предлагаю прекратить дискуссию, тем более, что вот такой аргумент
Лично меня такое положение вещей вполне устраивает…
для меня абсолютно бесспорен! Ибо каждый имеет право на личные предпочтения!❗
А вот в том, что такое положение вещей устраивает
как и JR , и Hitec.
у меня есть определенные сомнения, но они требуют проверки, поэтому возражать пока не буду… Пойду читать инструкции ☕… Хайтек у меня есть, ДжиЭр есть у товарища…
Разбрался кажись.
void LCD_clear (void)
{
unsigned char x, y;
for (y=1; y<7; y++)
for (x=0; x<84; x++) buff[y][x]=0;
void LCD_refresh (void) // Обновление дисплея (отображение буффера)
{
unsigned char i,j;
LCD_DC=0 ;
spi(64);
LCD_DC=1;
for(i=1; i<7; i++)
{
LCD_DC=0 ;
spi(64+i);
spi(128);
LCD_DC=1;
for (j=0; j<84; j++) spi(buff[i][j]);
}
}
void LCD_pixel (unsigned char x, unsigned char y, unsigned char color)
{ // Рисуем пиксель. Все остальные процедуры работают через нее
unsigned char i, bt;
//x=83-x;
//y=47-y;
y=y+8;
i=y>>3;
bt=1<<(y & 0x7);
if(color) buff[i][x]|=bt;
else buff[i][x]&=(~bt);
}
По мотивам msv1.8 3310 upsidedown
Можно, я чуть выскажу свое видение микширования и ЕРА? 😃
Для микширования можно применять два метода.
1 - как сделано у Фокуса. Просто складываем каналы умноженные на их весовые (процентные) коеффициенты.
2 - с пересчетом весовых коеффициентов. Для этого сначала расчитываем новые коеф (К2) пропорционально установленным пользователем, но так, чтобы их сумма давала 100% (или ЕРА). Т.е. если пользователь установил смешивание 3 каналов с коеф. 50, 40 и 30, то расчетные К2 будут 50/(50+40+30)*100=42, 40/(50+40+30)*100=33 и 30/(50+40+30)*100=25. В этом расчете 100 - это ЕРА. Такой расчет гарантирует, что при максимальных отклонениях стиков всех микшируемых каналов не даст машинке выйти за ЕРА. И если мы изменим ЕРА, то соотношение влияния стиков на результат не изменится. Даже если пользователь установит для всех трех каналов 100% микширования, то каждый из каналов получит только по 33% и равную долю влияния на результат. Не будет ситуации, что стик еще движется, а машинка уже уперлась. И функция двойных расходов в таком случае решается как изменение ЕРА в зависимости от какого-либо переключателя или даже крутилки.
Сорри за многабукафф 😃
2 - с пересчетом весовых коеффициентов
Вот этот алгоритм и описан в посте #2698. Неужели настолько неузнаваемо? 😊
А вот идея менять расходы движением EPA мне кажется не хорошей. Потому, что в одном месте приходится оперировать весовыми коэффициентами каналов (процентами), а в другом - градусами или миллиметрами.
Гораздо более юзефульно, КМК, определять общий коэффициент канала “одинарные/двойные” из установленных значений расходов и использовать этот коэффициент. На примере sslobodyan’а:
Двойные расходы = 100, одинарные = 60. Считаем коэффициент 60/100 = 0,6.
Веса установлены 50, 40 и 30 (сумма=120); веса, приведенные к 100% составят 0.42, 0.33 и 0,25 соответственно (в сумме = 1).
Полное (100%) отклонение главного стика канала даст:
- на двойных расходах 100*0,42=42%
- на одинарных расходах 100*0,42*0,6=25%
Полное (100%) отклонение стика второго канала даст: - на двойных расходах 100*0,33=33%
- на одинарных расходах 100*0,42*0,6=20%
Полное (100%) отклонение стика третьего канала даст: - на двойных расходах 100*0,25=25%
- на одинарных расходах 100*0,25*0,6=15%
Сумма полного отклонения трех стиков: - на двойных расходах 42%+33%+25%=100% (А)
- на одинарных расходах 25%+20+15%=60%. Как просили. (Б)
И при этом не надо никуда EPA перестраивать. EPA как параметр геометрии самолета или… Не знаю как лучше сказать… “На первый вылет - расходы поменьше”. Смысл не в расходах поменьше, а в уменьшении предельно допустимых углов отклонений рулей. Вот это - в чистом виде работа для EPA. КМК.
Проценты (А) и (Б), которые мы получили - это проценты от длительности канального импульса, установленного через EPA. Осталось добавить (вычесть) триммирование - и все, можно грузить длительность в таймер.
Триммирование, КМК, просится в процентах от установленного EPA, ибо тоже имеет прямое отношение к геометрии самолета. Получим простое смещение нуля рулевой машинки (на графике из поста #2696 вертикальная ось, от которой откладываются + и - рулевой машинки двигается триммированием влево-вправо).