Как у нас с трихограммой?
Perelesnik:
Добра!
Небольшой апгрейд в связи с освоением нового вида материала - мягкого резино-силиконоподобного пластика для 3Д-печати.
По жесткости сразу после печати получается примерно как обычная "зимняя" резина, после обработки дихлорметаном еще мягче становится.
Такой мягкой материал уже не получится прямо насадить на вал двигателя - шлиц не поможет, просто провернется. Поэтому делаю вот такой адаптер из жесткого пластика:
На валу держится надежно, одевается-снимается легко:
Всего 5 типоразмеров, как и давал раньше в наборах.
Только самый большой дозатор не получается по причине наличия этой внутренней проставки на валу.
Но если уж сильно надо, то можно обычную, жесткую ставить.
А в остальном, то подготовка к следующему сезону идет своим чередом... люди потихоньку обращаются, я потихоньку делаю...
Perelesnik:
http://www.youtube.com/watch?v=jeL11CnC6BE
реношник:
Посмотрел видео и возникло ряд вопросов...
- Вы говорите, что трихограммница изменяет формат данных ЖПС модуля, в частности добавляет какие-то строки (видео 3:20).
Вы реально добавляете в протокол свои строки ?
- Как я понял из объяснения вы программируете ЖПС на частоту передачи данных 10Гц.
Ваша основная программа реально успевает обработать каждую посылку данных ? Судя по периферии часть посылок будет пропущена.
- В видео вы показываете настройку трихограммницы с привязкой к скорости 36 км/ч.
Так как калибровка проводится только по одной точке, соответственно все расчетные значения будут верными вблизи точки калибровки. То есть при скорости полета около 36 км/ч.
Или вы где-то учитываете нелинейность связи PWM/rpm и я пропустил этот момент ?
Спасибо за ответы !
Perelesnik:
Благодарю за внимание к проекту и отдельно благодарю за удовольствие отвечать на вопросы такого уровня.
Отвечу немного развернуто, чтобы было понятнее и людям, которые более далеки от нюансов программирования.
- GPS , с которыми мне приходится иметь дело (а это, как правило, устройства на основе разработок от Ublox), способны выдавать данные по двум протоколам: NMEA (способны все) и UBX (а некоторые не имеют такой возможности, как выяснилось к моему удивлению).
Каждый протокол состоит из строк, содержащих тот или иной набор данных. Эти данные дублируются (а то и по 3-4 раза повторяются) в строках протоколов. Особенно таким "грешит" протокол NMEA - он вообще довольно "кривой" и тяжеловесный... одно в нем хорошее - он традиционный, классический, и Все устройства с ним способны работать изначально.
Одно время я вообще отключал NMEA и работал только по UBX, через легенький парсер (это такой код в прошивке трихограммницы, способный "вытаскивать" из строки нужные данные и сортировать их в правильном порядке)... пока мне не попалась партия GPS приемников (NEO-6 ???), у которых UBX вообще не был предусмотрен в прошивке.
Вопрос вообще в чём... мне для работы нужны такие данные:
- Время
- Координаты
- Количество спутников
- Горизонтальная скорость
- Курс
- HDOP
... вроде и всё.
Это если предполагается работа с программой навигации на Андроиде.
А для дроновской трихограммницы мне достаточно только скорости и спутников (спутники даже не обязательны, но удобно).
Вот в UBX это всё добро находится в одной строке (или в двух (?)... лень в код сейчас заглядывать для уточнения), а у NMEA это разбросано по нескольким разным строкам. При этом, совсем не факт, что именно нужные строки по умолчанию подключены, зато факт, что куча не нужных мне строк по умолчанию как раз включены.
Сначала я решал вопрос просто: через U-center подключал нужные строки протокола, отключал ненужные, выставлял все параметры, как мне удобно... пока не получил очередной китайский сюрприз - в большой партии GPS NEO-8 напрочь отсутствовала маленькая микросхемка, где эти все настройки и можно было сохранять. Продавец в Китае божился, что наличие батарейки на плате компенсирует это неудобство... но это, естественно, оказалось совсем не так.
Такова предыстория.
В итоге мне пришлось сделать так, чтобы при каждой инициализации системы в GPS прописывались нужные мне настройки - отключались все лишние строки протоколов и включались только 2 нужные мне строчки NMEA (ибо он Точно должен работать в любом GPS), а частота обновления с предустановленной в 1 Гц переписывалась на 10 Гц (у Нео-6 на 5 Гц - быстрее он не умеет).
Теоретически (!) можно было бы создать собственный протокол, сформировать одну компактную строку со всеми нужными мне данными... это было бы вообще идеально, но это означало бы переписать саму прошивку GPS, что по многим причинам для меня не реально. Хотя... поживем - увидим.
А пока вот так. Отключаю всё, включаю нужные пару строчек (они не всегда "с магазина" включены). Поэтому, в видео слово "свои строчки" следует понимать как "нужные мне строчки".
- Для того, чтобы успевало обрабатывать, все остальные процессы включаются по таймерам, а не просто последовательно по реальному циклу программы. Например, экран обновляется только раз в 0,8 секунды, формирование строки и ее отправка через Блютуз только при факте изменения координат или скорости полета (а менее важная информация типа количества спутников, "часов" и показаний расходомера передается только 2 раза в секунду), и так далее. Ну и, как писал выше, GPS у меня не "грузит" контроллер избытком лишних строчек - это Очень влияет на скорость обработки данных.
- На PWM я вообще не ориентируюсь. Даже не знаю, какой он бывает в процессе работы устройства. PWM вычисляется ситуационно, динамически. Основное - rpm. То есть, самой программой(!) подбирается такой PWM, чтобы был необходимый rpm. Фактически, PWM в реальных условиях зависит от разницы между фактической скоростью вращения двигателя и требуемой скоростью этого вращения. Реализовано как простой пропорциональный регулятор оборотов: чем больше разница между заданной и фактической скоростью вращения, тем большая величина поправки в управляющий сигнал... до тех пор, пока фактическая скорость не будет примерно равной заданной. "Примерно" - это потому, что разрешение энкодера в несколько раз превышает "разрешение" управляющего сигнала.
Частота обновления PWM - примерно 5Гц (ставил и 10 Гц, но реальной пользы - разницы в работе от такого не увидел), а энкодер - он по прерыванию работает, то есть... при скорости 100rpm это 87000 прерываний в минуту, или 1450 в секунду.
Мы указываем только обороты, а как достичь этих оборотов (в зависимости от нагрузки на колесо дозатора, например) - это уже дело программы.
Вернее, мы и обороты не указываем, мы дозировку указываем, а программа уже сама высчитывает, какие должны быть обороты при фактической скорости полета.
Ну, вот как-то так пока что.
реношник:
Ок. по поводу модуля я чуть позже покажу свои результаты программы обработки данных.
Пока вопрос про калибровку...
Допустим вы откалибровали агрегат соответственно скорости полета 36 км/ч. Подстроечником задали скорость вращения шнека "Х об/сек", и получили какой то расход трихограммы "Y г/мин". Соответственно можно рассчитать получаемую плотность обработки "Z г/Га".
В этом случае (для меня) понятно, что на этой скорости 36км/ч будут заданные параметры внесения трихограммы.
Но если вдруг нужно будет вносить трихограмму на скорости 15 км/ч ... ту я не понимаю по какой формуле (какой пропорции) программа произведет расчет необходимой скорости вращения шнека !!!
Навигация