Рисунок на колесе
-
Alecs_2000
- Первый раз сказал Мяу!
- Сообщения: 27
- Зарегистрирован: Пн дек 15, 2008 10:06:55
Вот все сижу, слежу за темой, и решил выдать такое - А что если вместо ваших датчиков холла и не дай бог герконов вверху колеса, там где спицы крепяццо к ободу... Короче на ентой высоте на вилку с одной стороны прикотячить дешевую лазерную указку, естессно доработать корпус, а с другой стороны оптодатчик. Таким образом измерение скорости колеса бутет намного точнее - Т.К. луч лазера будет прерываццо о каждую спицу...
Мозг человека запоминает абсолютно все, кроме того - куда он это все запомнил...
Тогда несколько датчиков на самом колесе, скажем, штук 8, они же вроде не дорогие. Семь датчиков параллелльно через определенный угол, а один отдельно для считывания верхнего положения колеса, что-бы рисунок в случае остановки не перевернуло...
Мозг человека запоминает абсолютно все, кроме того - куда он это все запомнил...
Геркон отпадает - дребезжит и залипает
Другие датчики - Холл, индуктивный - все равно, лишь бы побольше. Чем больше датчиков - тем стабильнее картинка.
Вообще на низких оборотах трудно получать стабильную картинку.
Меня иногда подмывает использовать спицы колеса в датчике, если получится их использовать - выйдет лучше всего.
Другие датчики - Холл, индуктивный - все равно, лишь бы побольше. Чем больше датчиков - тем стабильнее картинка.
Вообще на низких оборотах трудно получать стабильную картинку.
Меня иногда подмывает использовать спицы колеса в датчике, если получится их использовать - выйдет лучше всего.
-
8434163
- Открыл глаза
- Сообщения: 47
- Зарегистрирован: Ср дек 02, 2009 15:06:55
- Откуда: Украина
- Контактная информация:
Для высокочастотного датчика холла нужен маленький зазор (2мм макс.) я нашел в нете герконы с высокой частотой срабатываний (до 500 кГц)
наработка на отказ у них 1000000 срабатываний стоит около 30 гривен.
А по поводу стабильной картинки программист сказал что увеличением датчиков стабильности не добьешься надо ето делать программно как-то (программист оооочень серьезный)
наработка на отказ у них 1000000 срабатываний стоит около 30 гривен.
А по поводу стабильной картинки программист сказал что увеличением датчиков стабильности не добьешься надо ето делать программно как-то (программист оооочень серьезный)
Да хрень он несет, Ваш программист, надувает с умным видом щеки, нихрена не понимая в процессе.
Поясняю на пальцах процесс работы с одним датчиком:
1. замер начального периода вращения колеса T0
2. вычисление начального периода вывода одного вращающегося столбца как T0/N, где N - количество столбцов (на 1 оборот).
3. в бесконечном цикле:
- вывод картинки,
- замер текущего периода вращения колеса Tn
- вычисление текущего периода вывода столбца
Причины нестабильности картинки:
1. недостаточная точность замера периода вращения колеса
2. ошибка за счет целочисленной арифметики, которая приведет в вращению картинки по или против направления вращения колеса
3. изменение периода вращения колеса - расчет был сделан для прошедшего оборота, а картинка выводится в следующем обороте
Как с этим бороться:
1. поставить кварц и максимально повысить частоту МК, разрядность счетчика периода должна быть не меньше 24 бит
2. реализация п.1 сгладит эту проблему
3. максимально увеличить количество датчиков, это вместе с п.1 даст возможность "на лету" - многократно (по количеству датчиков) в течение текущего оборота - считать период вывода столбца, не будет задержки на оборот.
И еще одно, про "хитрые" алгоритмы, на которые наверняка будет намекать ваш "программист":
- в свое время я опробовал пару алгоритмов вычислений с предсказанием, результат был стабильно хуже, чем у алгоритма без предсказаний;
- многократное усреднение периода тоже не помогает.
P.S. Все это было написано на ассемблере, так что на неоптимальный код компилятора (С или Basic) не свалишь.
Поясняю на пальцах процесс работы с одним датчиком:
1. замер начального периода вращения колеса T0
2. вычисление начального периода вывода одного вращающегося столбца как T0/N, где N - количество столбцов (на 1 оборот).
3. в бесконечном цикле:
- вывод картинки,
- замер текущего периода вращения колеса Tn
- вычисление текущего периода вывода столбца
Причины нестабильности картинки:
1. недостаточная точность замера периода вращения колеса
2. ошибка за счет целочисленной арифметики, которая приведет в вращению картинки по или против направления вращения колеса
3. изменение периода вращения колеса - расчет был сделан для прошедшего оборота, а картинка выводится в следующем обороте
Как с этим бороться:
1. поставить кварц и максимально повысить частоту МК, разрядность счетчика периода должна быть не меньше 24 бит
2. реализация п.1 сгладит эту проблему
3. максимально увеличить количество датчиков, это вместе с п.1 даст возможность "на лету" - многократно (по количеству датчиков) в течение текущего оборота - считать период вывода столбца, не будет задержки на оборот.
И еще одно, про "хитрые" алгоритмы, на которые наверняка будет намекать ваш "программист":
- в свое время я опробовал пару алгоритмов вычислений с предсказанием, результат был стабильно хуже, чем у алгоритма без предсказаний;
- многократное усреднение периода тоже не помогает.
P.S. Все это было написано на ассемблере, так что на неоптимальный код компилятора (С или Basic) не свалишь.
Последний раз редактировалось bolek Чт дек 03, 2009 17:14:38, всего редактировалось 1 раз.

