Как у нас с трихограммой?
Perelesnik:
Цитата: реношник от 20.12.2018, 09:24:12 am
Чуть позже скомпоную материал и покажу, пока все разрознено ...
Заранее благодарю!
Кстати, вчера пересмотрел архив - обнаружил, что накопилось уже более 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 остается пара строчек... ; а потом вообще вся программа состоит из одного-двух десятков строк, так как все остальное прописывается в библиотеках.
Цитата: Toris от 20.12.2018, 12:16:55 pm
Мда, непоганий realtime Ви замутили...
А не думали посадити обробку екрана на окремий контролер, як у відеокартах? Щоби контролер екрану самостійно брав дані з пам'яті, коли йому буде зручно?
Це екстенсивний шлях розвитку) Все одно, як добудовувати ще одну кімнату тому, що в будинку нема де ступити через безлад і гори непотребу.
Завдання, які вирішуються за допомогою того екрану, не такі вже й складні (кіно там не показуємо, в тривимірні ігри не граємо), то звичайними засобами оптимізаціїї все й вирішилося.
Поставити окремий контролер з екраном (чи декілька таких контролерів) я можу й зовсім без зміни головного коду програми. Справа в тому, що контролер постійно передає всі дані, які відображуються на екрані (та ще деяку допоміжну інформацію) за допомогою специфічного протоколу, який я розробив для зв'язку з смартфоном (чи планшетом, чи ПК... байдуже). Тому "перехопити" цей протокол і вивести дані на екран - справа дуже проста. Чи по дротах перехопити, чи й по Блютузу... Але навіщо ускладнювати?
Доречі, контролер формує 2 окремих протоколи: один той, що оце казав вище, а другий - щоб керувати окремим контролером дозатора... чи двох дозаторів, чи чотирьох, чи більше.... якщо комусь таке заманеться (при цьому, на кожен дозатор можна передавати окреме завдання, тобто точно балансувати дозування між різними дозаторами).
Вимушений був зробити такий протокол, бо неможливо адекватно керувати мотором з контролера в кабіні пілота, коли сам двигун знаходиться у декількох метрах від цього контролера (енкодер має бути поруч з контролером, на коротких дротах, щоб не давав похибок).
То й є поважна причина, щоб ставити додатковий контролер в систему. А заради самого цього екрану мати окрему "відеокарту" - то вже занадто)
Навигация