В общем, все соревнования пролетают на неопределённый срок. Сейчас пандемия, а не то легкое заболевание, что было весной. Потому все мероприятия отменены. Думаю, что 19 декабря в TSI тоже никаких соревнований не будет. Ладно, посмотрим. А пока я получил платку BASSENSORSMKII - но как файлов для 21 лабораторной работы как не было - так нет. Хотел уже было написать на форум 2e2 или e2e, как он там на тексасовском сайте... обломился - нужен валидный университетский е-майл. Людям третьего сорта писать нельзя. Ладно - будем ждать. Правда, просмотрел лекции и прочитал план лабораторных - оказывается, всё очень плохо. Датчики дальномеры результаты дают хорошо, если 10 раз в секунду. Акселерометры используются для определения столкновения (а я тут губу раскатил, что координаты будем определять).
Короче, с горя вытащил плату робота на stm32f405, который будет бегать по линии, и у которого будет 16 сенсоров. Решил продолжать оживлять. А так как я его начал делать с CubeMX и библиотеками HAL - задача состояла в разбирательстве с этими библиотеками. Чтение конфигурации сделал, дисплей с кнопками - работают, коммуникация через BT HM11 идёт, моторы уже крутятся. Ну, следующий этап - тахометры. Пока, чтобы просто путь считал. Мучил-мучил, считать не хочет. Топчется плюс-минус один, а дальше не идёт... Причину то нашел - оказывается, я сконфигурировал делать захват (и прерывание) и по фронту, и по спаду, а в обработчике про это забыл и писал, как будто прерывания идут только по фронту. Потом, выяснилось, что силабс и куб по разному интепретирует определение типа XXXX_Pin. В Simplicity Studio это номер пина порта, а куб как (1ul << Pin). Из-за этого у меня никак не работал правильно макрос BITBAND_PERI и не определялось правильно направление вращения. Для прерывания по фронту определение направления выполняется так:
Код: Выделить всё
if (Enc_Left_B) {
// Идём назад
} else {
// Идём вперед
}
А для фронта и спада надо так:
Код: Выделить всё
if (Enc_Left_B ^ Enc_Left_A) {
// Идём вперед
} else {
// Идём назад
}
Ну а как сделать исключающее ИЛИ для двух бит которые могут находиться в разных портах и в разных разрядах? Приводить к 0 и 1 через маски? Когда под рукой есть такая удобная штука. Вот только, почему ST этот макрос не включает в свои хидеры?
А вот, пока разбирался с этими таходатчиками, немного по-анализировал об их погрешностях. Вот простые картинки:
Так выглядят "идеализированные" сигналы с таходатчиков (инкрементального энкодера). Ну, я немного скривил, рисовал всё же малярной кистью (ms painbrush). Но в идеале, длительность импульсов и пауз между ними должна быть одинаковой и фронт (и спад) второй фазы должен быть ровно по середине первой фазы. Так что все вертикальные линии находятся на одинаковом расстоянии. Это в идеале. Теперь посмотрим на конструкцию энкодера. Это плата с двумя датчиками холла, над которым крутится магнитный диск с 6 полюсами - 3 северных и 3 южных. Допустим, что диск идеален - полюса не перекошены и между ними ровно 60 градусов. В этом случае, вариант 1х - один импульс на (допустим) северный полюс - будет работать идеально - никакого джиттера возникать не должно. Хотя, нет - может возникать, если этот диск на вал будет посажен криво или с эксцентриситетом. Тогда интервал между прерываниями будет плавать.
Если же мы захотим увеличить "разрядность" - измерять период не только по фронту, но и по спаду - вариант 2х - в дело начинает вмешиваться и то какой зазор между диском и датчиком холла:
При увеличении дистанции импульс может сужаться. Этот эффект можно ликвидировать, если построить триггер, который при определённой магнитной напряженности северного полюса устанавливал триггер в 1 и при такой же напряженности южного - сбрасывал... не знаю, есть ли такие сенсоры?
Ну и самый проблемный вариант, если мы хотим учитывать еще и вторую фазу. Как писал, в идеале, вторая фаза должна быть сдвинута ровно на половину. Вроде как конструктивно это делается - магнитный диск: полюса повторяются с периодом 120 градусов, датчики стоят под углом друг к другу по дуге 90 градусов (что составляет -30°). Но оказывается, малейшая не соосность и эти углы поплыли:
Вот для примера я сдвинул сенсоры в направлении стрелки и по отношению к диску они стоят уже не на 90°, а на все 120°. Ну, это я так грубо нарисовал, но тем не менее - энкодеры, что продаются pololu для моторчиков "с micrometal gear" они не "садятся" на кольцо на корпусе, а просто напаиваются на выводы моторчика. Ну можно, конечно, постараться напаять по-точнее... но выводы то - гибкие и при нагрузке на соединительные провода, плату ни что не удерживает от съезжания в сторону.
Вот и резюме 21-й лабораторной работы - все датчики шумят. Ну об этом буду думать, когда буду настраивать PI регулятор оборотов двигателей.
А вот кстати, пока я искал как правильно написать макрос BITBAND_PERI, гугл меня вывел на сайт
http://www.micromouseonline.com/. Ух, почитал, и понял, что мне еще далеко до решения настоящего лабиринта. Вот, даже и не знаю с какого конца подступиться, чтобы робота научить ходить по-диагонали. Когда в прошлом году смотрел на youtube соревнования Robotex в Таллине, мне показалось, что там тоже один робот по лабиринту ходил в таких местах по-диагонали. Теперь, я убедился, что это так и есть. Напал на одну статью - там тоже участники в своих неудачах винят трассу: стенки имеют не тот коэффициент отражения.
Так, таходатчик я оживил, теперь надо бы оживить АЦП и ПДП. Сконфигурировал, написал, компилирую - облом. Халява закончилась - ваши 32К исчерпаны. А я еще не начал самого робота писать - только подготавливал инфраструктуру. С другой стороны, у кристалла с 1 мегабайтом флеша ютиться на 32 килобайтах... Так что, долой кейл, ставим CubeIDE.
А люди посмотрят и скажут: "Собаки летят. Вот и осень."
