Comments 19
Вы забыли отнормировать результат осреднения (wCos /= hypot(wCos, wSin)).
Но лучше просто использовать atan2(wSin, wCos) — тогда не надо ни нормировать, ни разбирать варианты по знаку wSin.
Спасибо, однако. Про atan2 я без вас бы и не вспомнил, конечно, его удобнее применять.
Было бы интересно увидеть графически как было «случайные выборки из непрерывного процесса болтания флюгера туда-сюда с частотой намного большей, чем раз в 8 и тем более 16 секунд» и как стало.
Да не было это, конечно, зафиксировано, нет такой нужды что-то тут точно мерить, так что оценка на глаз. Разброс показаний (любых) вообще очень хорошо на глаз оценивается — если разница очень заметна и необъяснима, то все плохо, надо сглаживать. На примере направления — был север, через 8 секунд стал юго-запад, потом северо-восток и сразу запад — уже видно, что никуда не годится. Потому что на этих данных заключения о том, куда же дует ветер, сделать нельзя. После исправления подобные метания сократились до пределов примерно одного квадранта, что уже гораздо лучше.
Обычные флюгеры достаточно массивны, чтобы не колыхаться как флаг. Может надо было увеличить инерцию конструкции, добавив «маховик» на ось.
Можно, конечно. Было бы у меня время и ресурсы, я бы поэкспериментировал, чтобы знать, какова оптимальная масса флюгера. Потому что слишком большая — понятно, что это тоже плохо, увеличится трение и он перестанет реагировать на хоть и постоянный, но слабый ветерок. Значит, нужно будет еще и дорабатывать опоры и в конце концов полностью менять всю конструкцию. И, возможно, не один раз до получения нужного соотношения масса/трение. А пока возможности приобретения такого опыта нет, проще все-таки вносить поправки электронным методом, а не делать это трудноисправляемой механической доработкой.
ЗЫ: между прочим, есть еще одна теоретическая возможность сделать оптимальный по инерции флюгер. Для этого нужна смазка, обладающая эффектом, противоположным тиксотропии: то есть, имеющая малую вязкость при слабом сдвигающем усилии и резко увеличивающем ее при увеличении усилия. С такой смазкой флюгер перестал бы болтаться при резких порывах и стал бы двигаться более плавно. Но про такую смазку я только слышал, и не уверен, что она работает в нужном мне диапазоне сдвигающих усилий. Так что это тоже требует экспериментов, и как бы даже не поболее чистой механики.
ЗЫ: между прочим, есть еще одна теоретическая возможность сделать оптимальный по инерции флюгер. Для этого нужна смазка, обладающая эффектом, противоположным тиксотропии: то есть, имеющая малую вязкость при слабом сдвигающем усилии и резко увеличивающем ее при увеличении усилия. С такой смазкой флюгер перестал бы болтаться при резких порывах и стал бы двигаться более плавно. Но про такую смазку я только слышал, и не уверен, что она работает в нужном мне диапазоне сдвигающих усилий. Так что это тоже требует экспериментов, и как бы даже не поболее чистой механики.
Без этой смазки этот эффект был давно реализован для стрелочных приборов — применяли торможение токами Фуко. У стрелки был металлический флажок, движущийся в разрезе магнита. При резком ускорении возникают большие тормозящие токи. При медленном движении стрелки торможение отсутствует.
Т.е. в данной конструкции надо диск (край диска) поместить в разрез подковообразного магнита.
P.S. для читателей комментария, не знакомых с токами Фуко www.youtube.com/watch?v=01JCZgpy7tw
Т.е. в данной конструкции надо диск (край диска) поместить в разрез подковообразного магнита.
P.S. для читателей комментария, не знакомых с токами Фуко www.youtube.com/watch?v=01JCZgpy7tw
Вот видите, вы еще и третий путь мне напомнили (я о нем просто забыл, а ведь когда-то в институте проходил устройство стрелочных приборов. Посыпаю голову пеплом). И все требуют механической доработки без гарантии, что это поможет (магниты тоже бывают очень разные и я лично вот не на раз соображу, как тут и чего посчитать заранее).
Так что проще все-таки с программой поэкспериментировать.
Так что проще все-таки с программой поэкспериментировать.
В случае магнитов нужна механическая точность изделия. Я бы строил на основе блока головок неисправного жесткого диска.
В общем случае действительно программа проще, если сам флюгер не разворачивается в произвольном направлении, генерируя заметное количество ложных данных.
В общем случае действительно программа проще, если сам флюгер не разворачивается в произвольном направлении, генерируя заметное количество ложных данных.
Отсутствие ложных данных обеспечивается при трех условиях: а)флюгер хорошо отбалансирован и самостоятельно не разворачивается в преимущественную сторону при отсутствии ветра; б)его не тормозит существенно трение в опорах и в)не заносит при резких порывах. Первое и второе обеспечить несложно продуманной конструкцией, аккуратным изготовлением и сборкой (у меня для балансировки имеется передвижной груз в передней части), а третьего не происходит при достаточной массе (флюгер из латуни, а груз свинцовый, общим весом около 200-300 грамм), и тем, что порывы ветра не имеют формы строго прямоугольного импульса.
Вдогонку: электронный метод в теории позволяет сымитировать любое поведение флюгера. Не поможет простое осреднение за цикл — пойдем дальше, будем подбирать период осреднения, выдумывать скользящие средние. В принципе нужно просто привлечь теорию: построить динамическую модель поведения флюгера, и наложить на нее желаемый частотный фильтр. Беда тут только в том, что не очень хорошо известно, какой именно фильтр «желаемый». Потому и проще поэкспериментировать, подобрав параметры фильтра вручную.
Какой результат вернёт алгоритм, если набор данных для усреднения состоит из равного количества значений с азимутами X и X+180° и одинаковыми амлитудами?
Беру свой легкомысленный ответ (см. ниже) назад. Ошибка действительно теоретически возможна. Написал по этому поводу UPD в статье.
atan2 не поможет — в таких условиях результат будет определяться ошибками округления и может быть любым. А математически тут и вовсе неопределенность.
Я не о неопределенности, с ней все ясно, в изначальном ответе я все сказал. Ошибки округления тут роли не играют, ибо код (16 градаций) грубее любых ошибок. Речь идет о том, что два значения вблизи 90 и 270 градусов, например cos(89°)=0.017 и cos(269°)=-0.017, в среднем дадут ноль, т.е. arccos даст 90° (или 270°, без разницы), а должно быть 179. atan2 эту проблему снимает, специально проверял. Другое дело, что у меня arccos потому и работал без видимых сбоев, что в реальности разброс на 180 градусов (на четыре значения притом) не встречается.
Чисто умозрительное построение, конечно, в реальности вероятность такого совпадения практически равна нулю (особенно, если учесть амплитуды, которые у меня не учитываются). Но если все таки случится, то какая разница, какое? 90 или 270 — оба ответа будут правильными. Можно просчитать по алгоритму, какое именно (или смоделировать на контроллере), но мне лень.
Sign up to leave a comment.
Метод векторного осреднения при измерении направления ветра