Как у нас с трихограммой?

[Perelesnik]

Давайте я немного иначе объясню для понимания:

 Задача трихограммницы - равномерно высыпать "манку" по гону вне зависимости от скорости полета.
То есть, хоть летим со скоростью 2 км/ч, хоть 102 км/ч, хоть каждые несколько секунд резко меняем скорость полета... во всех случаях на каждом гектаре (или на каждом километре, или на каждом метре) должно оказаться совершенно одинаковое количество "манки".

То есть, стоим - не сыплется, начинаем медленно ползти вперед - начинает чуть-чуть сыпаться, летим с максимальной скоростью - сыплется обильно и щедро. Но в каждом из таких вариантов движения на каждом метре гона будет одинаковое количество манки. Хоть против ветра летим, хоть по ветру... ну и так далее.

Значение скорости полета здесь не главное. Это такое, как бы сказать, вспомогательное, значение, по которому можно измерить пройденное расстояние за единицу времени (впрочем, это и есть определение скорости ) ... но для дела нам важно как раз расстояние, на которое нужно равномерно уложить "манку".
Отсюда и пропорция: чем быстрее летим, тем быстрее вращаем колесико.

И подстроечником устанавливается не скорость вращения шнека (!). Скорость вращения - это производная величина от скорости полета и некоего коэффициента "миллилитры на километр". Подстроечником задается именно этот коэффициент. Оперируем при настройке мы только миллилитрами и реальными километрами (метрами). А уже потом это все перекладывается (не нами перекладывается, а программой перекладывается без всякого нашего участия) на скорость полета, чтобы вычислить необходимую скорость вращения колесика в каждый определенный момент времени.
Еще раз: "крутилкой" мы устанавливаем миллилитры на километр обработки. И всё. Больше мы ничего не устанавливаем.

Оно нам и не нужно.

Для того, чтобы миллилитры соответствовали реальности, есть еще калибровка - еще один подстроечник, которым мы подстраиваем коэффициент "миллилитры/оборот колесика".
Для того, чтобы оперировать не километрами, а гектарами (так удобнее), мы имеем третий подстоечник - для установки ширины гона.
Вот и всё: всего 3 значения, которые оператор задает "руками".

Теперь "зачем эти 36 км/ч" нужны. Нужны они просто для того, чтобы при калибровке расходомера не приходилось ехать/лететь с какой-то скоростью, а можно было спокойно сидеть на стуле и никуда не двигаться физически. Без данных о скорости (или при данных от GPS, что скорость = 0) колесико вращаться не будет (что как бы естественно).

Если взять трихограммницу в руки и идти/бежать с ней по улице или ехать с ней в автомобиле, или лететь... будет тот же результат. Но это немного не удобно. Поэтому для настройки/калибровки реальное значение скорости от GPS подменяем каким-то "вымышленным" значением, чтобы создать у трихограммницы иллюзию того, что она движется с какой-то скоростью (что дистанция обработки увеличивается с течением времени), а не лежит спокойно на столе. Обманываем технику, так сказать.
Для принципиальных противников обмана техники всё так же доступен честный вариант с реальным перемещением трихограммницы по местности в процессе настройки/калибровки.

Второй важный момент: почему 36 км/ч , а не, допустим, 200 км/ч? И почему я интересуюсь у пользователей по поводу их реальных скоростей полета при обработке.
Дело в том, что двигатель на дозаторе имеет пределы скорости вращения. Нижний предел не существенный здесь, а вот верхний - имеет значение.
Если программа просчитает, что для обеспечения требуемой дозировки на какой-то скорости реального полета нужно 150 об/минуту, а сам двигатель физически способен выдать максимум 110 об/мин, то, естественно, он и будет вращаться на своих предельных 110 оборотах, и требуемой дозировки не обеспечит.
Если такое случается, то нужно просто поставить более "сыпучее" колесико дозатора из набора, чтобы обеспечить нужную дозировку при данной реальной скорости на оборотах двигателя менее 110 об/мин.

Но как это обнаружить? Как понять, что нужно подобрать именно вот такое колесико?
Можно, конечно, засыпать манку и летать на требуемой скорости, а потом посмотреть - высыпало оно сколько нужно было по расчетам или недосыпало. Если должно было высыпать литр, а высыпало 700 мл, значит, колесико нужно поставить чуток побольше.
Но это неудобно.
Удобнее все определить и настроить на земле, не вставая со стула.

Вот, больше никакой ценности у параметра "36 км/ч" не существует.
Это просто для удобства первоначальной настройки. В работе этот параметр никоим образом не используется и ни на что не влияет.

Для "Ская" и "Бекаса" ставлю 120-130 км/ч, для "Цессны" и "АН-2" (я сам в шоке, что до сих пор люди на АН-2 работают по трихограмме, но это факт) 150 км/ч и выше, для вертолетов тоже свое, для беспилотников - от 12 км/ч (и такое просили) до 60 км/ч...

Но это значение используют техники может раз, может, два раза... пока настройку сделают, а дальше оно годами работает, и больше никто и не вспоминает, что этот режим настройки в трихограммнице существует. И оно фактически никак не используется....

Нет, вру. Используют. Для того, чтобы после полета высыпать остаток манки из бункера. Так удобно, кстати.

[реношник]

Спасибо за такое пространное описание. Но я прекрасно понимаю как связан расход со скоростью и т.п..

Но всеравно ваше описание совершенно не дает (мне) понимания принципа расчета в вашей программе..

" То есть, стоим - не сыплется, начинаем медленно ползти вперед - начинает чуть-чуть сыпаться, летим с максимальной скоростью - сыплется обильно и щедро. Но в каждом из таких вариантов движения на каждом метре гона будет одинаковое количество манки. "

Вот именно тут я не понимаю.... 
Вы откалибровали расход (скорость вращения колесика/шнека) при скорости 36 км,час (или той, что указал заказчик). При полете с этой скоростью расход трихограммы будет соответствовать плану.
Теперь представляю, что коптер летит со скоростью 20 км/ч, понятно, что нужно уменьшить скорость вращения колесика (уменьшаем % заполнения ШИМ).
Но я не представляю как в программе рассчитывается с какой скоростью при этом должно вращаться колесико для новой (20км/ч) скорости ?!
У вас есть какая-то формула для такого расчета или просто есть какой-то СРЕДНИЙ коэффициент пропорциональности ?

[Kagor]

"зачем эти 36 км/ч" -плаваючий "0"

[Perelesnik]

Калибруется не скорость вращения колесика. Единственная калибровка здесь - это определение того, сколько реально высыплется манки за один оборот конкретного установленного в дозатор колеса ( не важно даже, за один оборот, за сто оборотов или за четверть оборота... но, для упрощения, пусть будет за один оборот).


 При этом совсем не важно, с какой скоростью это колесо вращается. Хоть 5 оборотов в минуту, хоть 100 оборотов в минуту - объём высыпанной за один оборот манки от этого никак не изменится. Соответственно, эта калибровка будет верной при любых скоростях вращения колеса, так как скорость здесь никак не учитывается - учитывается только объём за один оборот.
И калибровать можно на любой скорости вращения колеса - результат калибровки от этого никак не изменится.

Это единственная калибровка, предусмотренная в данном приборе. Других калибровок нет.

Дальше, зная точное соотношение между одним оборотом колеса и объёмом высыпающейся за этот оборот манки, мы можем из значения обороты в минуту вывести значение миллилитры в минуту ( или в секунду, или в миллисекунду). А также произвести обратную операцию: вычислить необходимые обороты колеса в минуту из значения миллилитры в минуту. А миллилитры в минуту у нас выводятся из установленной дозировки ( миллилитры на километр) и скорости полёта.

Миллилитры на километр ( или миллилитры на гектар при указании ширины гона) мы задаем подстроечником, и эта величина у нас является константой. А переменная величина - реальная скорость полёта.

Никаких средних, усредненных и приблизительных величин в формулах не используется. Только точные значения и точные зависимости этих значений. Благо, что практически все значения находятся в простой пропорциональной зависимости. Все, кроме управляющего сигнала, регулирующего напряжение, подающееся на двигатель. Здесь исключение по причине того, что нагрузка на колесо при работе варьируется непредсказуемым образом.

А в остальном тут простая математика. Примерную логику описал выше. Ну а в результате получаем, что если, допустим, при скорости полёта 20 км.ч. нужная дозировка достигается при оборотах колеса в 50 об.мин.,  то при скорости полёта 40 км.ч. колесо будет вращаться со скоростью 100 об.мин. и в обеих случаях будет одинаковая дозировка манки на единицу расстояния. Что, по сути, и требуется от трихограммницы. А если скорость будет 0, то и колесо будет иметь 0 оборотов в минуту.

[Perelesnik]

Поясню на примере, как работает программа, и как вычисляется необходимая скорость вращения колеса.

Итак, частота вычисления у нас 5 Герц, или раз в 0.2 секунды.

Допустим, в этот момент мы летим со скоростью 20 м/с ( то есть 72 км/ч).
Получаем данные от GPS об этом факте: 72 км/ч.

Ранее мы откалибровали расходомер, и теперь программа располагает коэффициентом "миллилитры на один оборот колеса". Допустим, мы получили 1.2 мл на 1 оборот.

Также мы установили необходимую дозировку внесения. Допустим, 20 мл на 1 гектар.

И еще мы указали ширину гона. Допустим, 50 метров.

Такие у нас исходные данные.

Теперь вычисления:

- Переводим мл/Га в мл/км.  При ширине гона 50 метров на 1 гектар получается 200 метров пути. То есть, 20 мл на 200 метров и, следовательно, 100 мл на 1 км.
Это значение никак от скорости полета не зависит.

- Сколько миллилитров манки нам нужно высыпать за 0.2 секунды при скорости полета 72 км/ч ?
За 0.2 секунды мы должны пролететь 4 метра (20 м/с * 0.2 с).  100 мл на 1 км - это 0.1 мл на 1 метр. Следовательно, 0.1 мл/метр * 4 метра = 0.4 мл.
Примечание: в реальных условиях работы программы никогда не бывает ровно 0.2 секунды по таймеру. Программа работает в цикле, цикл занимает некоторое время, поэтому достижение условия " > 200 миллисекунд" может наступить при значении и 201 миллисекунда, и 205 миллисекунд. Для вычислений берется реальное значение. То есть, не 200 миллисекунд, а сколько реально получилось.
Для упрощения здесь примем вариант, что промежуток времени составил ровно 200 миллисекунд, или 0.2 секунды.

- Итак, зная, что за 0.2 секунды мы должны внести 0.4 мл манки и зная, что 1 оборот колеса нам дает 1.2 мл этой манки, определяем, что за 0.2 секунды колесо должно провернуться на 1/3 оборота ( 0.4 / 1.2).

- Какие обороты в минуту должно иметь колесо в данный момент, чтобы за 0.2 секунды оно провернулось на 1/3 оборота? Считаем: 1/3 / 0.2 * 60 = 100 оборотов в минуту.

- Обращаемся к показаниям подпрограммы, вычисляющей реальные обороты двигателя на основании показаний энкодера, чтобы узнать, с какой реальной скоростью вращается колесо в данный момент. Допустим, что в предыдущие 0.2 секунды мы летели с меньшей скоростью, и у нас были другие расчеты, и потому сейчас колесо вращается со скоростью 95 об/мин.
Но теперь мы летим быстрее, и нам нужно уже 100 об/мин.

Поэтому, вносим поправку в PWM , который у нас управляет напряжением, подаваемым на двигатель. Увеличиваем его на (100-95) * коэффициант. Коэффициент этот был выведен опытным путем так, чтобы двигатель наиболее адекватно реагировал на вносимые поправки... и этот коэффициент по сути просто отражает специфику поведения конкретного вида двигателей. Я его вычислил уже давно, и просто использую в каждой программе, где применяется вот именно такие двигатели.
Ну, допустим, коэффициент этот равен "2".

Тогда поправка будет (100-95) * 2 = 10.

Смотрим, какой был PWM в предыдущем цикле. Допустим, он равнялся 120. Новое значение будет 120 + 10 = 130.

Даем поправку на двигатель и смотрим, что получилось. А получилось, допустим, 98 об/мин. Значит, вычисляем следующую поправку: (100-98) * 2 = 4.
Предыдущее значение PWM у нас теперь 130, поэтому новое будет 130+4 = 134.

Даем на двигатель это значение и смотрим результат. Допустим, он теперь стал 105 об/мин. Вычисляем новую поправку (100-105)*2 = -10. Вносим поправку: 134 - 10 = 124.

И снова проверяем... пока не получим 100=100 и поправка = 0.

Вот так и живем

Конечно, в реальности не бывает таких невероятных ускорений полета, как я взял для примера, поэтому в реальности все происходит гораздо-гораздо более плавно по поправкам. Но здесь взял такие данные просто для наглядности, чтобы не возиться с цифрами, отличающимися на несколько сотых или даже тысячных.

[Perelesnik]

Теперь "бонусом" об еще одном режиме работы дозатора.

Режим такой существует по той причине, что двигатели имеют не только верхний предел скорости вращения, но также не очень стабильно работают на слишком низких оборотах (получаем большой ампераж при малом подающемся напряжении, что может уменьшить ресурс работы двигателя - а это нам никак не нужно).

Данные двигатели хорошо себя чувствуют в диапазоне от 50 до 100 (110) об/мин. Больше 110 они физически не способны, это уже я писал выше, а вот что делать, когда нужно дать меньше 50 об/мин?
Допустим, мы работаем на вертолете или мультикоптере, и в какой-то момент работы у нас скорость оказывается такой, что двигателю трихограммницы нужно выдать всего 10 или 20 об/мин?

Или даже всего 5 об/мин...

Если мы поставим программе задачу обеспечить эти 5 об/мин по тому алгоритму, который я привел в посте выше, добра из этого не получится. Двигатель будет пытаться это сделать, но... фактически начнет просто мучительно гудеть и активно разогреваться, пока все возрастающая сила тока при почти неподвижном роторе не угробит обмотки этого ротора.

Поэтому, в данном случае программа переходит в импульсный режим работы.

Как это работает:

Когда программа обнаруживает, что нужна скорость вращения меньше 50 об/мин, отключается предыдущий алгоритм управления двигателем и включается другой алгоритм.

Новый алгоритм работает по таймеру. Период срабатывания таймера примерно 1 секунда (почему примерно - писал выше). Для вычислений берется реальное значение тайминга.

Снова разберем на примере. Для наглядности возьмем данные те же, что и раньше. Но только скорость полета у нас будет не 20 м/с, а 5 м/с.

- Итак, при скорости 5 м/с мы за 1 секунду пролетим именно 5 метров.

- Знаем по предыдущим вычислениям, что на 1 метр нам нужно высыпать 0.1 мл манки. Следовательно, на 5 метров нам нужно высыпать 5 * 0.1 = 0.5 мл.

- Зная, что за один полный оборот колеса мы высыпаем 1.2 мл манки, определяем, что на 0.5 мл нужно произвести 0.5 / 1.2 = 0.42 оборота.
На самом деле, программа для внутренних вычислений не использует значение "обороты в минуту". Вместо этого она оперирует данными энкодера, которые соотносятся как 870 шагов (сигналов с энкодера) на 1 полный оборот колеса.
То есть, для программы итог вычислений будет выглядеть не как 0.42 оборота, а как 365 шагов.

- Запускаем двигатель на оптимальной скорости вращения (хз на какой скорости, если честно, просто даем высокий уровень PWM, чтобы двигатель гарантированно начал вращаться).

- Отсчитываем требуемые 365 шагов и просто отключаем двигатель, обнуляя значение PWM.

- Так как двигатель и вся его трансмиссия имеет некоторый момент инерции, да еще и момент отключения может не очень точно совпасть с нужным моментом (программа работает в цикле, поэтому условие "> 365" может наступить и при значении 370, например), то до момента полной остановки колеса мы получим значение, большее, чем 365. Ну, допустим, энкодер насчитает нам аж 380 шагов вместо заданных 365.

Но нам же нужно получить точную дозировку на нашем поле. Так что делать?

А мы на следующем цикле просто вносим поправку на величину фактического расхождения, который имели в предыдущем цикле.

То есть, 380 - 365 = 15 (это то, что мы лишнего накрутили). Поэтому в следующем цикле задача будет уже не 365, а 365 - 15 = 350 шагов.

В результате, дебет с кредитом сойдутся   Мы внесем на 1 гектар именно столько, сколько и загадывали.

[реношник]

Ответ #50 : 19.12.2018, 10:26:13

Вот теперь стало понятно... Просто я не думал, что вы пошли таким не рациональным путем... Но каждое решение имеет право на существование...

[Perelesnik]

Ответ #50 : 19.12.2018, 10:26:13

Вот теперь стало понятно... Просто я не думал, что вы пошли таким не рациональным путем... Но каждое решение имеет право на существование...

А какой путь рациональный? А то я за эти годы уже много вариантов перепробовал и перепроверил, пока не остановился на вот таком. Он оказался самым точным.

[реношник]

Ответ #50 : 19.12.2018, 10:26:13

Вот теперь стало понятно... Просто я не думал, что вы пошли таким не рациональным путем... Но каждое решение имеет право на существование...

А какой путь рациональный? А то я за эти годы уже много вариантов перепробовал и перепроверил, пока не остановился на вот таком. Он оказался самым точным.

Чуть позже скомпоную материал и покажу, пока все разрознено ...

[реношник]

Как обещал, немного про ЖПС...

По моему мнению использовать 10Гц совершенно не оправдано...

1 . собрал такую конструкцию на Wemos XI (32MHz)

 

2 . набросал программку.
в ней идет чтение КАЖДОЙ посылки !!! парсинг БЕЗ костылей (библиотек). ЖПС модуль отправляет ТОЛЬКО ОДНУ строку, частота 5 Гц...



3 . результат в мониторе - между посылками "луп" проходит 5 (пять) итераций !!!  ВСЕГО ПЯТЬ, при том, что там ничего не выполняется !!!
Если добавить вывод еще пары строк, то количество пустых проходов уменьшится. Не говорю про, что что будет если напихать обработку энкодера, управление ШИМ, а если еще и парсинг с "костылями"...
Тут и UBX  не спасет ...

[Perelesnik]

Чуть позже скомпоную материал и покажу, пока все разрознено ...

Заранее благодарю!

Кстати, вчера пересмотрел архив - обнаружил, что накопилось уже более 20 вариантов прошивок для трихограммницы

Эх... когда-то они, эти прошивки, были совсем маленькими. Начинал вообще с простого параметрического управления PWM в зависимости от скорости полета, где соотношение между скоростью полета и PWM задавалось подстроечником - вот и вся дозировка )))

Грубо говоря, PWM = скорость * коэффициент, заданный подстроечником.

Но быстро понял, что ни разу оно так просто не решается. То есть, оно как-то работает, но с точностью большие проблемы.

Дальше ввел энкодер, стало полегче... А потом понеслось )))

[Perelesnik]

10 Герц я ввел ради навигационной программы на Андроиде.  При меньшей частоте, когда это все дело стоит на самолете, летящем со скоростью 130-150 км/ч, точность прорисовки гона и особенно прорисовка разворотов получалась неудовлетворительной.

150 км/ч - это 42 м/с.  Если работать на 5 Гц, то каждая точка получается через 8-10 метров, а это, особенно, когда нужно по программе точно зайти на новый гон, оказывается не очень удобно.

Вот когда сидишь за столом и пишешь программу, кажется: ну какая там разница, будет точка рисоваться через каждые 5 метров, или через 10 метров, или даже через 20 метров,  тем более, что 5 раз в секунду - это все равно пилот на такой скорости не способен даже воспринимать изменения...

А когда наблюдаешь работу программы, сидя в кабине самолета, впечатления от работы этой программы совсем другие. И таки понимаешь, что 10 Гц - это нагляднее.

С UBX удобно - там практически все нужные мне данные находятся в одной строке NAV-PVT ... ну, кроме какой-то необязательной мелочи. Но на единственной этой строчке все прекрасно и быстро работало с помощью простейшего парсера.

На NMEA ... В принципе, можно брать только одну строку: RMC
Ну, еще одну можно включить - GGA, если нужно количество спутников, высота над уровнем моря и HDOP.

Оно точно так же просто парсится, без "костылей". Хотя, и с "костылями" тоже неплохо работает (если повыключать Все остальные строки протокола, чтобы библиотека на них "стойку не делала" и не начинала обрабатывать).

Я от NMEA оставляю эти 2 строчки: по испытаниям получается, что 1 или 2 строчки - это на быстродействие особо никак не влияет. Так что пусть будет 2. Программа и так и так справляется.

Вообще, самые значительные "тормоза" в прошивке - это работа с экраном, как оказалось. Он у меня на I2C висит. Думал, прерывания от энкодера будут "просаживать" работу, а нет: не прерывания, а именно экран со своей массивной библиотекой.
Поэтому обновляю экран только раз в 800 миллисекунд - на глаз смотрящего воспринимается нормально, не напрягает. Но вот в момент этого обновления экрана - да, иногда происходит потеря одной-двух строчек с GPS.
То есть, реально иногда (!) получается уже не 10Гц, а 8-9 Гц... И на 5 Гц бывает потеря одной строки. Но и без экрана не удобно. Так что я согласился на такой вот компромисс.

Вообще, был полный кошмар с быстродействием и с потерей строк GPS, пока я не занялся оптимизацией и не поразносил процессы по таймерам.
Сначала "грешил" на то , что я, нуб-ленивец, использую для работы с GPS готовую библиотеку. Написал честный парсер - не помогло. Потом таки допёр, что дело не в этом. Поставил таймеры - заработало как надо.

В общем, было не скучно)

А что UBX, что NMEA - оно без разницы для скорости обработки. Строка - она и есть строка. Точно так же приходит в буфер, и точно так же оттуда берется парсером или библиотекой (тоже такой себе парсер, только изначально созданный как "универсальный" и с "дружественным интерфейсом", потому несколько избыточный).

Так что сам по себе UBX ни от чего не спасает. Спасает "много сидеть, писать, проверять, читать, снова писать и снова проверять..." Ну, как это всегда в программировании бывает

[Toris]

Мда, непоганий realtime Ви замутили...

А не думали посадити обробку екрана на окремий контролер, як у відеокартах? Щоби контролер екрану самостійно брав дані з пам'яті, коли йому буде зручно?

[реношник]

Вот как обещал, мой подход к этому вопросу.
Я пошел по пути моментальной реакции системы на внешний фактор (скорость, заклинивание) .

Вот набросал свой способ (теоретически) расчета крыльчатки.





цель - возможность конечному потребителю самостоятельно подбирать, менять узлы агрегата.
например может взять любой привод эл.мотора, откалибровать его в программе и подобрать крыльчатку.

https://youtu.be/qMg3ECAhz-k

а это ссылка на видео работы такой системы.
правда еще не закончено, пока настольный вариант, жду из Поднебесной посылку с необходимой мелочевкой...

[Perelesnik]

Так другого пути, как обеспечение "моментальной реакции" на внешний фактор, здесь изначально и не предвидится.

Конечно, понятие "моментально", как всегда, условно. "Моментальность" с одной стороны у нас определяется частотой обновления данных GPS, а с другой - частотой работы по энкодеру (кстати, с китайскими энкодерами нельзя ориентироваться на интервалы между двумя соседними импульсами - расхождение получается совершенно дикое, поэтому берется среднее арифметическое от нескольких таких интервалов). Ну и, конечно, сам двигатель физически не может обеспечить "моментальную" реакцию.

Впрочем, и такой "относительной моментальности" для наших целей более чем достаточно.

Сразу же дам совет отказаться от использования полной формулы ПИД-регулятора, так как основной принцип этой формулы предполагает наличие некой прогнозируемой динамики регулируемого процесса (для чего в формуле как раз и присутствует интегральная и дифференциальная составляющие).

То есть, этот классический способ управления через ПИД-регулятор оборотами коллекторного двигателя с энкодером, описанный во всех "букварях" по Ардуино, в нашем случае малопригоден. Причина в том, что нагрузка на двигатель у нас меняется хаотически и математически непредсказуемо (зависит от кондиции манки, оказавшейся в тот или иной момент на колесе).

Фактически, без манки на ПИД-регуляторе оно работает, как "букварь" пишет (динамика изменения нагрузки прогнозируемая - сам двигатель, редуктор и колесо в уплотнении), а вот с манкой...

Я в свое время вдоволь "наигрался" с ПИДами, протестировал на реальных дозаторах... и сделал только параметрическое управление. Как писал выше: величина поправки берется от разницы между реальными и заданными оборотами, + учитывается временнАя составляющая (так как реакция двигателя на изменения не мгновенна).

Предполагаю, что Вы придете к точно таким же практическим выводам.

Кстати, все мотор-редукторы, которые я когда-либо использовал в таких устройствах (как имеющие "родные" энкодеры (таких в продаже всего 3-4 вида подходящих размеров), так и без оных), имеют примерно одинаковую скорость реакции на изменение управляющего сигнала.

Ну и моторы можно использовать с разными номинальными оборотами. Даже код переписывать особо не придется - достаточно изменить одну переменную. Я вот выбрал номинал "100 rpm" просто потому, что мне так удобнее... ну и ресурс самого дозатора теоретически будет выше, нежели когда используется мотор-редуктор с вдвое-втрое большими оборотами.

Да, и еще, о нагрузке. Советую всё-таки не использовать коллекторный двигатель на очень малых оборотах под нагрузкой (без нагрузки оно будет работать). Сделайте или как у меня, импульсный режим для таких скоростей, или как-то еще исключите такое использование двигателя... Иначе реально придется выезжать на полевые работы с пригоршней запасных моторчиков в кармане.

Или вообще перейдите на другой тип двигателей (шаговые, например, нормально работают в очень большом диапазоне скоростей, включая самые минимальные обороты).

Кстати, когда-то один "матерый" программер мне говорил, что называть библиотеки "костылями" мы волшебным образом перестаем в тот самый момент, когда сами создаем свою первую библиотеку под конкретное задание... или хотя бы переписываем чужую библиотеку "под себя"

Ну... это такая эволюция, которую проходят все "ардуинщики": сначала абсолютно весь код пишется в "void loop()..." стройными рядами; затем кое-что разносится по отдельным функциям (подпрограммам); затем весь код состоит из обособленных подпрограмм, а в void loop остается пара строчек... ; а потом вообще вся программа состоит из одного-двух десятков строк, так как все остальное прописывается в библиотеках.

Мда, непоганий realtime Ви замутили...

А не думали посадити обробку екрана на окремий контролер, як у відеокартах? Щоби контролер екрану самостійно брав дані з пам'яті, коли йому буде зручно?

Це екстенсивний шлях розвитку) Все одно, як добудовувати ще одну кімнату тому, що в будинку нема де ступити через безлад і гори непотребу.
Завдання, які вирішуються за допомогою того екрану, не такі вже й складні (кіно там не показуємо, в тривимірні ігри не граємо), то звичайними засобами оптимізаціїї все й вирішилося.

Поставити окремий контролер з екраном (чи декілька таких контролерів) я можу й зовсім без зміни головного коду програми. Справа в тому, що контролер постійно передає всі дані, які відображуються на екрані (та ще деяку допоміжну інформацію) за допомогою специфічного протоколу, який я розробив для зв'язку з смартфоном (чи планшетом, чи ПК... байдуже). Тому "перехопити" цей протокол і вивести дані на екран - справа дуже проста. Чи по дротах перехопити, чи й по Блютузу... Але навіщо ускладнювати?

Доречі, контролер формує 2 окремих протоколи: один той, що оце казав вище, а другий - щоб керувати окремим контролером дозатора... чи двох дозаторів, чи чотирьох, чи більше.... якщо комусь таке заманеться (при цьому, на кожен дозатор можна передавати окреме завдання, тобто точно балансувати дозування між різними дозаторами).

Вимушений був зробити такий протокол, бо неможливо адекватно керувати мотором з контролера в кабіні пілота, коли сам двигун знаходиться у декількох метрах від цього контролера (енкодер має бути поруч з контролером, на коротких дротах, щоб не давав похибок).

То й є поважна причина, щоб ставити додатковий контролер в систему. А заради самого цього екрану мати окрему "відеокарту" - то вже занадто)

[Тэги:]

Украинский авиационный форум > Форум > Легкая авиация > Тема: Как у нас с трихограммой?