Оказывается я заблуждался. На сайте Pololu комплект стоит дешевле, потому что туда не входит сам LaunchPad. При этом ланчпада недостаточно - требуется еще 2х19 гнездо и желательно с удлиннёнными выводами, если будет желание подключиться "сверху".
Ну это так - лирика. На выходных я взялся за тахометр... и разочаровался. Метод захвата времени по срабатыванию таходатчика никуда не годится. Сделав первую часть (собственно я давно её был сделавши, но не запускал на железе) упёрся в проблему: как включить мотор и при этом остаться под отладчиком. Пока думал, решил для начала потыкаться осциллографом и картинку он показал удручающую. Робот крутил колёсами в воздухе, а картинка на осциллографе дрожала. Т.е. длительность между фронтами постоянно колебалась. Отчего это так, или неравномерность вращения двигателя, или неравномерно распределены полюса на магнитном диске (или диск немного косит) пока не понял. Но факт остаётся такой, что все измеренные интервалы из-за этого разные. Что и подтвердили дальнейшие действия.
Чуть позже, разобравшись, что нужно включить и что - отключить, получл конструкцию, которую я могу разом и двигать, и отлаживать. Начал выполнять лабу, где производится сбор данных при разных скоростях вращения колёс. Сначала получил дикие результаты. Функция сбора данных раз в 10мс записывает в буфер значение периода, скорости (скорость = 2000000/период - странно, что период на 0 не проверяется, можно спокойно в GPF влететь) и потом добавил еще один параметр. Так вот сразу после включения когда двигатель переходил из состояния покоя к 25% мощности были "всплески". Причем всплески были как вверх - значит что за период опроса не было ни одного срабатывания захвата, так и вниз! Со вторым моментом понятно. Так как там период вычислятся "циклически", то если предыдущее состояние было 0xFFFF, а следующее 0x0001, то получается, что период - 2. Но это в том случае, что за время срабатывания захвата счетчик только один раз прошел через 0. А если два и более? Так и было. Колесо вращалось ещё настолько медленно, что период был больше 5.64мс и счетчик успевал два раза перейти через 0, а простая разница показывала скорость, даже выше, чем при 75% мощности (в тесте двигатель крутился по 1 секунде на 25%, 50%, 75%, 50%, 25% и останавливался). Т.е. получается, что нужно обработчик усложнять? С первой проблемой оказалось так, что её не должно было случиться - при сборе данных с интервалом в 10мс, а период при тех оборотоах - порядка 1мс. Но оказалось, что когда я начал писать робота для лабиринта, я начал переделывать эти функции под себя, а они, на самом деле общие во всём рабочем поле проектов. И следующие лабы у меня "поломались". Поэтому я решил робота утащить прочь из CCS. Ну и оказалось, что возвращая на место, не всё исправил в исходное состояние. Так что опрос оказался гораздо чаще, чем 10мс. После того как все хвосты нашел и вернул на место - эти "выпады" вверх исчезли.
Далее, я решил сделать учет пройденного расстояния. Это просто. На каждый импульс надо прибавлять или убавлять дистанцию, в зависимости от направления вращения. В задании сказано было прибавлять 1, но мне подумалось, что практичнее сразу считать в нормальных единицах. Энкодер даёт 360 импульсов на оборот колеса, с учетом редуктора. Диаметр колеса где-то 69.5-70мм. Ну я тут попытся округлить, самое близкое получилось считать, что на 1 импульс робот проходит 0.61мм. Запустил этот пятисекундный тест - отчет показал, что робот должен был проехать 4 метра. Но поставив на пол, он явно столько не проезжал. Взял рулетку - всего 2 метра. Где-то я ошибся. Оказалось всё очень просто. Копируя этот код для второго колеса, порт опрашиваемый поменял, а переменную - нет. Вот и получилось, что насчитало в два раза больше.
Мне вот почему-то думается, что измерять период - не правильно. Правильно считать расстояние и из него можно легко получить скорость. Причем без риска сделать деление на 0. И для усреднения не нужно заниматься фильтрованием, усреднением, так как если пройденное расстояние поделить на время мы так и так получим среднюю скорость. А если так, то применение счетчика в таком виде для работы этого энкодера совершенно не нужно. А возможности использовать счетчик как квадратурный, как в STM32 здесь нет возможности. Для учета именно расстояния, достаточно порты запрограммировать на прерывание по изменению. Думаю, в роботе так и сделаю. А пока надо еще поиграться с этой лабой и перейти к 17 - там уже на основе этого энкодера будет ПИД-регулирование.
Ну это так - лирика. На выходных я взялся за тахометр... и разочаровался. Метод захвата времени по срабатыванию таходатчика никуда не годится. Сделав первую часть (собственно я давно её был сделавши, но не запускал на железе) упёрся в проблему: как включить мотор и при этом остаться под отладчиком. Пока думал, решил для начала потыкаться осциллографом и картинку он показал удручающую. Робот крутил колёсами в воздухе, а картинка на осциллографе дрожала. Т.е. длительность между фронтами постоянно колебалась. Отчего это так, или неравномерность вращения двигателя, или неравномерно распределены полюса на магнитном диске (или диск немного косит) пока не понял. Но факт остаётся такой, что все измеренные интервалы из-за этого разные. Что и подтвердили дальнейшие действия.
Чуть позже, разобравшись, что нужно включить и что - отключить, получл конструкцию, которую я могу разом и двигать, и отлаживать. Начал выполнять лабу, где производится сбор данных при разных скоростях вращения колёс. Сначала получил дикие результаты. Функция сбора данных раз в 10мс записывает в буфер значение периода, скорости (скорость = 2000000/период - странно, что период на 0 не проверяется, можно спокойно в GPF влететь) и потом добавил еще один параметр. Так вот сразу после включения когда двигатель переходил из состояния покоя к 25% мощности были "всплески". Причем всплески были как вверх - значит что за период опроса не было ни одного срабатывания захвата, так и вниз! Со вторым моментом понятно. Так как там период вычислятся "циклически", то если предыдущее состояние было 0xFFFF, а следующее 0x0001, то получается, что период - 2. Но это в том случае, что за время срабатывания захвата счетчик только один раз прошел через 0. А если два и более? Так и было. Колесо вращалось ещё настолько медленно, что период был больше 5.64мс и счетчик успевал два раза перейти через 0, а простая разница показывала скорость, даже выше, чем при 75% мощности (в тесте двигатель крутился по 1 секунде на 25%, 50%, 75%, 50%, 25% и останавливался). Т.е. получается, что нужно обработчик усложнять? С первой проблемой оказалось так, что её не должно было случиться - при сборе данных с интервалом в 10мс, а период при тех оборотоах - порядка 1мс. Но оказалось, что когда я начал писать робота для лабиринта, я начал переделывать эти функции под себя, а они, на самом деле общие во всём рабочем поле проектов. И следующие лабы у меня "поломались". Поэтому я решил робота утащить прочь из CCS. Ну и оказалось, что возвращая на место, не всё исправил в исходное состояние. Так что опрос оказался гораздо чаще, чем 10мс. После того как все хвосты нашел и вернул на место - эти "выпады" вверх исчезли.
Далее, я решил сделать учет пройденного расстояния. Это просто. На каждый импульс надо прибавлять или убавлять дистанцию, в зависимости от направления вращения. В задании сказано было прибавлять 1, но мне подумалось, что практичнее сразу считать в нормальных единицах. Энкодер даёт 360 импульсов на оборот колеса, с учетом редуктора. Диаметр колеса где-то 69.5-70мм. Ну я тут попытся округлить, самое близкое получилось считать, что на 1 импульс робот проходит 0.61мм. Запустил этот пятисекундный тест - отчет показал, что робот должен был проехать 4 метра. Но поставив на пол, он явно столько не проезжал. Взял рулетку - всего 2 метра. Где-то я ошибся. Оказалось всё очень просто. Копируя этот код для второго колеса, порт опрашиваемый поменял, а переменную - нет. Вот и получилось, что насчитало в два раза больше.
Мне вот почему-то думается, что измерять период - не правильно. Правильно считать расстояние и из него можно легко получить скорость. Причем без риска сделать деление на 0. И для усреднения не нужно заниматься фильтрованием, усреднением, так как если пройденное расстояние поделить на время мы так и так получим среднюю скорость. А если так, то применение счетчика в таком виде для работы этого энкодера совершенно не нужно. А возможности использовать счетчик как квадратурный, как в STM32 здесь нет возможности. Для учета именно расстояния, достаточно порты запрограммировать на прерывание по изменению. Думаю, в роботе так и сделаю. А пока надо еще поиграться с этой лабой и перейти к 17 - там уже на основе этого энкодера будет ПИД-регулирование.
А люди посмотрят и скажут: "Собаки летят. Вот и осень."
