Если ваш вопрос не влез ни в одну из вышеперечисленных тем, вам сюда.
Ответить

Re: RSLK от TI (Robotic System Learning Kit)

Пн май 29, 2023 20:02:41

Вышло новое видео от Veritasium про мышиные бега:

Очень интересно и познавательно.

Добавлено after 10 minutes 53 seconds:
Начал запускать UKMARSBOT.
...коэффициенты ПИД регулировки...
...есть запись с конференции, где эта презентация была представлена и всё сразу прояснилось. Называется "Как кормить вашего робота".

Очень интересная лекция о принудительнои питании и пропорционально-дифференциальном регулировании. А так же "откуда берутся эти числа". И вот это принудительное питание (Feed Forward) и есть ответ на проблему плавного старта.

...К этой же презентации интересно посмотреть следующую (та была записана в сентябре прошлого года, а эта в декабре) о выборе коэффициентов ПИД регулятора "Как сделать достаточно хороший ПИД контроллер без метода проб и ошибок".


Не только на одном ПИД регуляторе сошлись все звёзды. Я у себя на работе успешно применяю правила нечёткой логики (fuzzy logic) для управления сельскохозяйственным трактором на поле. Я даже написал упрощённую библиотеку на целых числах.
Порог вхождения конечно есть, но гибкость выбора правил управления несравненно большая.

Re: RSLK от TI (Robotic System Learning Kit)

Сб июл 29, 2023 07:22:41

Видео отличное - все основные проблемы рассказаны. Ну и лица сплошь знакомые: Дэвид Оттен и Питер Харрисон. Хотя насчет "собрать робота в спальне" он немного покривил душой. Там и 3D печать, и у кого-то лазерный резак и еще много чего. Я подписался на их канал и посматриваю их видео, где они хвалятся своими инструментами, методами и технологиями.

С этим двигателем от RSLK у меня ничего путного не получается. У меня есть макетная плата - заменитель робота без механики, чтобы отлаживать код в поезде по пути на работу, так вот я её решил расширить - напаял драйвера двигателей. Подключил к ним двигатели - всё-равно есть ложные срабатывания. Так что плата дистрибуции, что стоит на шасси - не виновата. Пока могу обвинить только "эти двигатели". Тем более, что у них еще и люфт страшный. Надо было бы подарить эти комплекты каким-нибудь школьникам - пусть играются, но у меня есть тихая мечта, сделать этого робота таким быстрым, чтобы обогнать литовского конкурента. Думал как бы туда засунуть моторы micrometal. Прямо не получается - ось находится на уровне батарейного отсека, который и не позволяет там разместить двигатели. Но на алиэкспрессе нашел моторчики с перпендикулярным выходом оси. Но они тоже из серии маломощных (по данным: обороты на холостом ходу 450 rpm, редуктор 1:45, то сами моторчики дают всего 20 000 rpm). Попробовал подключить к лабораторному блоку питания - уж очень легко колесо пальцем останавливается. Нарисовал в CADе "адаптер", чтобы их можно было установить на шасси ROMI. Когда напечатаю - посмотрим, смогут ли они этого робота вообще сдвинуть.

А пока взялся за снятие характеристик робота на шасси Zumo:
Изображение
Графики выглядят страшненько. Но что еще хуже, передаточая характеристика не особо линейная на начальном участке. В общем, я её аппроксимировал как 0,5 м/с на 1 вольт, со смещением 2.4 вольта. Постоянная времени 215 миллисекунд.

Но почему графики такие "неровные"? Подумал, что возможно, из-за гусениц. Попробовал снять гусеницы - графики остались точно такими же, только постоянная времени стала меньше.
Ну и ладно, теперь посмотрим на параметры вращения. Выполню те же тесты, но на один мотор буду подавать отрицательную полярность. Хотя тут вылезла бага. В старом контроллере скорости, контроллер текущую скорость вычислял как обратную величину от периода импульсов и в зависимости от флага направления менял знак. Но флаг направления имел 3 значения - Forward, Reverse и... Stop. Так вот при низких оборотах, если за цикл итерации не было ни одного импульса от таходатчика, то статус принимал значение Stop. А скорость меняла знак только при Reverse. В результате, при реверсе на малых оборотах скорость скакала между положительными и отрицательными значениями, хотя колесо на самом деле крутилось только обратно. В общем, пришлось в этом месте сделать нечто, навроде триггера Шмитта. Ну теперь снимаем характеристики:
Изображение
График отображает скорость колеса по окружности, а сводный график скорость вращения в градусах в секунду. Можно заметить, что набираемая скорость в этом случае меньше, чем, если робот шел просто прямо. Т.е. видно, что даже при 6.5в на двигателях колеса не дают даже 1.5м/с. Так же, постоянная времени стала почти в два раза меньше. Была мысль, что батарейки сели или еще чего поломал, поэтому для сравнения сделал один прямолинейный тест и отобразил на этом же графике. Линия TestL (самая верхняя) - это прямолинейный ход при 6в питании. Видимо, это действительно так. Коэффициент усиления упал из-за бокового трения гусениц, а постоянная времени - из-за распределения массы?

Но такие скачки скорости всё-равно не дают покоя. Подумалось мне, а не поднять ли частоту ШИМ? Читал, конечно, что для двигателей частоту ШИМ особо увеличивать не стоит из-за увеличения индуктивного сопротивления. Задирать до 31кГц, как в UKMARSbot не стал, а повысил всего на порядок - до килогерца. Передаточная характеристика стала гораздо глаже, но коэффициент усиления упал с 0,5 м/с на вольт, до 0,38 м/с на вольт. Аналогично и скорость вращения.
Изображение Изображение
Вот исходя из этих данных на базе кода UKMARSbot сделал контроллер позиции. Конечно, пришлось переназначить ресурсы. TIMER0 и 1 - теперь стали счетчиками энкодеров, потому что они 32 разрядные, хотя не уверен, что это реально необходимо. TIMER2 - ШИМ двигателей. Правда его я не мог вывести на нужный порт - пришлось для этого использовать PRS. Ну а TIMER3-4 генераторы главной последовательности - запуск АЦП для снятия темновых отсчетов, затем, включение боковых светодиодов и чуть позже снова запуск АЦП, далее, включение фронтальных и опять после паузы - запуск АЦП, ну и наконец - защелкивание состояния энкодеров в регистры захвата и вызов прерывания. Так как событий очень много, трёх регистров сравнения одного таймера было недостаточно, поэтому пришлось поставить второй работать синхронно с ведущим. Светодиоды детекторов стен включаю триггерами, построенными с помощью PRS. Поначалу была затея сделать тристабильный триггер, но, похоже, это съело бы 6 каналов PRS. Поэтому сделал просто два RS триггера, которые устанавливаются таймерами, а сбрасываются сигналом завершения работы АЦП. Правда, на выводы сигналы еще не вывел и работу не проверял. Пока эти таймеры делают просто захват состояния энкодеров и вызывают прерывание для контроллера движения.

Вот и начал тестировать движение. Как обычно, первое - настройка энкодеров. Пытаясь рукой робота прокатить заданное расстояние, посмотреть сколько импульсов таходатчика придёт. Но почему-то результат не совпал с расчетным - получалось так, что на оборот колеса робот проходил большее расстояние. Видимо, гусеница деформируется и решение для зубчатых ремней тут не годится. С другой стороны - деформация зависит от силы с которой робот давит на гусеницу, а я рукой давил достаточно сильно, чтобы при измерении гусеница не проскальзывала по поверхности стола. Так что, возможно, когда робот начнет сам бегать - придётся снова корректировать коэффициент между импульсами и пройденными миллиметрами.

Следующий на очереди PID контроллер. Робот два раза проезжает участок 200мм туда и обратно с линейным разгоном и торможением.
Изображение
На графике представлена задаваемая скорость, напряжение подаваемое на моторы и позиция робота. Еще, попытался вычислить реальную скорость, но из-за большой дискретности таходатчиков и округления отбрасывания дробной части у чисел с плавающей точкой - выглядит не очень, но тенденция видна. Коэффициенты ПИД можно считать достаточно правильными, так как напряжение подаваемое на двигатели меняется "плавно", а не скачет из одного крайнего положения в другое (было и такое, когда я пробовал подбирать Kp и Kd). Единственное, заметно, что робот в начале начинает двигаться с запаздыванием. Это из-за того, что там не организован полный FeedForward. В видео Питер Харрисон сказал, что добавить его - это "домашнее задание". Ну вот я его и добавил:
Изображение
Несколько смущает, что при 4 вольтах напряжение перестаёт подниматься. Это напряжение не измеренное, а задаваемое. Но задаваемое относительно напряжения на выходе преобразователя, которое считается как неизменные 9 вольт. И у меня есть предположение, что на самом деле в момент старта напряжение на выходе преобразователя просаживается, поэтому в начальной фазе разгона вроде как подаётся чуть за высокое напряжение, а на самом деле несколько ниже.

Так как у этого робота расстояние, скорость и ускорение задаётся в миллиметрах и секундах, а напряжение в вольтах, то эти величины получаются дробными и приходится использовать плавующую точку. Для задания конфигурационных параметров, в интерпретатор добавил ввод чисел с плавающей точкой. Получилось довольно-таки просто. А вот как вывести эти числа... пока еще не придумал.
Код:
Zumo>3.14 3.1415 3.141592 3.14159265 3.141592653 3.1415926535
Number overflow: 3.1415926535
Zumo>show
40490FDA
40490FDB
40490FD8
40490E56
4048F5C3

Интерпретация сделана тупо - введённые цифры пихаются в 32 битное число, которое просто делится на основание счисления столько раз, сколько "цифр за запятой". Поэтому невозможно ввести слишком точное число или слишком большое. С маленькими проблем нет ;-).
Код:
Zumo>0.000000000066743 show
2E92C4F8


После чего начал тестировать, чтобы робот проезжал заданное расстояние. В результате чего выяснилось, что мой изначальный расчет импульсов на миллиметр был правильным, а измеренное, когда катал робота рукой - нет. А вот тест на вращение меня расстроил. Чтобы робот правильно поворачивал, необходимо знать, какого радиуса окружность описывают колёса, т.е. расстояние между точками касания. Введя значение измеренное штангенциркулем - давало на 1/8 меньше поворот, чем надо. Более того, поворот по часовой стрелке и против давал разные углы. И еще на разных поверхностях - разные. Но вот на оргалите - повороты были стабильные и я нашел, что расстояние между точками контакта равно 101мм. А 101мм - это максимальная ширина робота. Это не значит, что робот выполняет поворот касаясь внешними частями гусениц, а, скорее, то, что точки контакта образуют не прямой угол с осевой линией. И при поворотах на месте робот постоянно смещается влево. Еще предстоит посмотреть как робот будет выполнять плавный поворот, но из-за этой не повторяеиости поворотов начинаю думать, что надо делать другую кинематику.

Re: RSLK от TI (Robotic System Learning Kit)

Ср окт 04, 2023 06:59:13

Пожалуюсь на жизнь-жестянку. С поворотами: нашел у себя ошибку - неправильно расчитывалась дистанция торможения при отрицательных значениях перемещения. Закрывающую скобку не там поставил. Стало лучше, но далеко не идеально. Да, гусеничный привод отлично работает на прямолинейном ходе, но совершенно отвратительно на поворотах. Потому как "точки касания" предсказать невозможно. И они каждый раз меняются (пока не пойму от чего)? Собственно, думаю, похожая проблема должна быть и у четырёхколёсных роботов (у которых по паре колёс с каждой стороны, как у бобкатов). Наверное, поэтому у тех роботов очень важен расчет центра тяжести и обеспечение одинакового давления на все колёса. Потому как у этого гусеничного аппарата, заметил, что центр вращения находится не в геометрическом центре относительно гусениц, а скорее там, где центр тяжести (учитывая, что батареи сдвинуты назад - центр вращения тоже смещен назад).

Из-за проблем с поворотами, диагональными ходами пока заниматься не буду. Поэтому надо наилучшим образом решить лабиринт с учетом максимального числа прямолинейных ходов. Вообще-то стратегия определяется только правилами соревнований. Смотрел видео прохода топового робота Питера Харрисона на летних соревнованиях. Во время поиска, в тупиках, робот всё время прикладывается задом к стенке, чтобы выровняться. А в прошлом десятилетии у них (в UK), был wall touching penalty - штрафные секунды за касание стен роботом. С другой стороны, алгоритм заливки позволяет быстро найти финиш во время первого поиска, но это мало актуально с тех пор как перестали время поиска процентуально приплюсовывать к каждому результату заезда. И похоже, после того как в 17-м году Питера Харрисона обставила "красная комета" на более длинном маршруте (упоминалось в видео от веритазериума, а вот описание от Питера Харрисона), все стали искать "оптимальные маршруты". И в этом, "летнем", видео видно, что робот во время поиска навернул где-то 3 круга, чтобы выявить все "белые пятна" на карте лабиринта, прежде чем перейти к быстрому заезду. Поэтому, может, этот вариант с "оптимистичной" мышкой, всё же следует заменить "дотошной", которая исследует лабиринт по алгоритму Люка-Тремо? Тогда не придётся наворачивать круги, а за один раз будет изучен весь лабиринт и можно будет сразу сгенерить оптимальный маршрут.

Еще один момент я так толком еще и не понял - старт и финиш. Во всех этих международных соревнованиях старт всегда левый нижний угол. Но в фотографии на страничке роботекса явно видно, что стартуют с правого нижнего угла и в правилах нету ясности в этом вопросе. Впрочем, решение для этой проблемы нашлось. Мой робот считает, что старт всегда с левого нижнего угла, но старт может быть или на север, или на восток. При этом в первом заезде робот смотрит на первый свободный проход в сторону. Если он окажется справа, то все в порядке - мы едем на север и лабиринт в памяти ориентирован правильно. Если же отсутствующая стена окажется слева, то мы едем не на север, а на восток и в этом случае происходит транспонирование лабиринта, устанавливается новая координата робота и направление:
Изображение
Это в режиме симуляции с командной строки проверка работы функций. Так что к такому повороту событий я готов. Облом будет, если старт будет откуда-нибудь с середины.

Труднее с финишем. Решил просмотреть все упомянутые в видео лабиринты - всегда ли финиш ровно по центру? В стандартном я не обнаружил ни одного лабиринта с финишем не по центру. Правда, нашел один интересный лабиринт у которого финиш был "не стандартный" - нельзя так сразу сказать, что это квадрат 2х2. Но если присмотреться - он отвечает правилам финиша - 4 клетки окружающие один столбик к которому не присоединена ни одна стена. А вот в полуразмерных лабиринтах финиш был где угодно и совершенно разных размеров. Подумал, что тут роботу надо сильнее думать. Пришлось искать правила для этих соревнований. В них, оказалось, что думать не надо: координаты финиша всё же заранее известны - сообщаются координаты левого нижнего и правого верхнего угла финишной зоны. Так что пока я приму, что финиш будет всё же в центре.

Хотя, так как я решил, что буду исследовать лабиринт по алгоритму Люка-Тремо, о позиции финиша можно не беспокоиться, по окончании изучения просто в памяти просканировать лабиринт на предмет поиска финиша. Собственно написал такую функцию - поначалу она возвращала адрес левой нижней клетки финишной зоны. Адрес правой-верхней легко высчитывается и я без проблем могу установить зону финиша для расчета маршрута. Но тут подумалось о том, что маршрут будет генерироваться только до первой клетки финиша, которая находится сразу за створом финишных ворот. А это значит, что робот через створ будет проходить "на излёте". Поэтому, в качестве финиша, решил возвращать адрес следующей от створа клетки, так чтобы тормозной путь был на клетку больше - это позволит через финишный створ проходить на более высокой скорости и вырвать несколько сотых долей секунды. Хотя, для меня это еще не актуально - хорошо, если мой робот вообще доползёт до финиша.

Re: RSLK от TI (Robotic System Learning Kit)

Пт дек 15, 2023 07:46:37

Съездил посмотреть соревнования Robotex в Таллине. Сам я готов не был - в середине сентября решил отказаться от кинематики на гусеничном ходу и решил по-быстрому сделать двухколесного робота. Накидал платку, послал заказ. Конечно, в плате наделал пару плюх - не развёл питание от USB и нагрузочные резисторы фотосенсоров. Но всё это накидал навесным монтажем и большой проблемы не было. Еще и JLC немного косячнул - не сделал milling у 2 отврстий USBразъёма (в предыдущих разах всё было нормально). Рассверлил сам. Немного был застрявши на запуске АЦП. у BGM24 АЦП круче, чем у efm32gg12, но конфигурируя прямо через регистры запустить его не удалось - где-то чего-то не хватает, поэтому пришлось применить стандартный драйвер - с ним всё завелось без проблем. Но когда переносил код с гусеничного робота на колёсный, снова возникла проблема. В колёсном я решил выбор программы сделать так же как в UKMARSBOT - дип-свитчами через резистивную матрицу и оказалось, что АЦП считывает напряжение с этой матрицы с огромным шумом, что невозможно отличить соседние состояния переключателя. Оказалось, что у меня поменялись порты (в целях оптимизации разводки), а назначение аналоговых шин в bus allocation переправить забыл. Когда до меня это дошло - поправил и АЦП заработал как часики. Сканирование сенсоров сделал на полном автомате. Таймер зажигал по очереди светодиоды, сначала фронтальные, затем диагональные - делалось это через PRS - обычным RS триггером. Сигнал с таймера устанавливал триггер, а сигнал с АЦП об окончании преобразования - сбрасывал триггеры и гасил светодиоды подсветки. И также сигалы с таймера объединённые по ИЛИ трижды запускали сканирование АЦП - первый раз без светодиодов, затем с включенными фронтальными и, наконец, с диагональными. Тут уж понадобилось 5 каналов сравнения таймера, поэтому пришлось снова объединять два таймера, чтобы работали синхронно. Шестой канал давал сигнал на квадратурные счетчики для захвата состояния энкодеров колёс.

Следующее, надо было снять механические характеристики. Оказалось, что тот код я удалил и пришлось его писать по-новой. Характеристики примерно совпали, так как диаметры колёс близки, только постоянная времени гораздо меньше, так как этот робот получился значительно легче:
Km = 360 мм/с / вольт, смещение 0.1 вольт.
Tm = 0,08 сек
По графикам, при питании выше 2 вольт в момент разгона видна "ступенька" - это из-за того, что у робота задирается нос, а затем, когда ускорение падает, нос опускается. Два вольта, по расчетам, соответствуют ускорению 9 м/с², т.е. больше 1g ускорение давать не следует.

Но всё-равно, повороты были не очень стабильные. Дома был отстроивши робота, но когда вечером в гостинице начал проверять - обнаружил, что робот не дотягивает до нужного угла. Не понял в чем причина. Может колёса на оси сдвинулись? Потому как эти колёса на оси "фиксируются" только засчет трения и, возможно, пока таскал в сумке они там сдвинулись? Правда на соревнованиях я заметил, что робот на поворотах заворачивает сильнее чем надо. В принципе, сейчас думаю, что надо было попробовать сдвинуть колёса, но... я расстроился и отказался от дальнейших попыток. Робот прошел в два раза дальше, чем я мог его погонять на домашнем "лабиринтике", и не дотянул одной клетки, где была возможность выровняться, и этого было недостаточно, чтобы добраться до финиша.

Когда приехали, лабиринт был закрыт и недоступен
Изображение
Поэтому возможности проверить на лабиринте сцепление колёс и калибровку сенсоров возможности не было. Открыли его только перед самыми соревнованиями:
Изображение
Старт находится в правом верхнем углу снимка, т.е. старт был не так как принято из левого нижнего, а из правого нижнего угла. Хорошо, что своему роботу я этот вариант предусмотрел - хоть тут не было накладок. Финиш в стандартном месте - ровно в центре. Хотя с другой стороны, в организации соревнований не было логики. Роботы оставались на руках у участников и, увидя лабиринт, можно было втихаря по-быстрому поменять фирмварь под этот лабиринт. Так же, лабиринт не был оснащен старт-стопными воротами - всё измерялось простым секундомером.

Попутно посмотрел на другие соревнования. Интерес вызвал Enchanced Linefollowing - следование по линии с препятствиями.
Изображение
Из препятствий - горка, качели, предмет, который надо объехать. Так же и линия - утолщенная, утонченная, прерывистая и разветвление. Рекомендуемая ветка в разветвлении указывается боковым маркёром - с какой стороны маркёр, в ту сторону и надо сворачивать. Еще там есть участок с двойным маркёром (на фото не видно, закрыто горкой, так как фото сделано в момент подготовки, а на соревнованиях горку переместили в другое место), на котором действует ограничение скорости - его надо проехать на скорости 0.5 м/с, если проехать правильно - это время не учитывается, в противном случае - плюсуется к результату.

Оказывается, не все читают правила соревнований. В этом году внесли изменения в правила соревнований Folkrace
Изображение
Появилась возможность выяснить, что робот сбился и "наворачивает" круги в неправильную сторону. Пока трасса была "одноуровневая" в форме буквы "О" проблем не было - все повороты должны быть в одну сторону (или большинство поворотов), а у этой трассы правильность направления опознать гораздо труднее. Поэтому в стартовой зоне (на фото еще нет) были наклеены две полосы красного и зелёного цвета. Таким образом, если робот следует в правильном направлении он должен увидеть сначала красную полосу, а затем зелёную. Если наоборот - значит, робот развернулся и едет не в ту сторону и надо разворачивться (проезд в неправильном направлении уменьшает число проеханных кругов). Правда, я немного сомневаюсь - ширина линии 10 см - и если скорость робота высокая, он может не успеть распознать цвет.

А меня продолжают преследовать неудачи. Хотел для лабиринта из линий сделать робота на гусеницах, но проблемы начались сыпаться одна за другой. Припаял плату сенсора линий с датчиком цвета и выяснилось, что два сенсора линии дают показания сильно отличающиеся от соседних сенсоров. Думал, что при переносе кода, где-то забыл освободить порты PA7 и PD3 - это те, что давали неправильные показания. Долго мучился, пока не сообразил, что просто нет контакта. Вот только где? Прозвонка показала, что на плате всё в порядке и обрыв или между модулем BG24 и платой, или внутри модуля. Этот модуль я уже раза 3 перепаивал. Неужели придётся еще раз? Это очень проблематично - надо снова полностью разбирать робота, отпаивать моторы и, может, только что припаянный сенсор линии. Но пока решил попробовать налить олова на выступающий кусочек пада, в надежде, что олово затечет под модуль и соединится с площадкой (и при этом не устроит залипуху с соседними падами). В этом мне помог летом купленный припой. Купил проволоку 0,25мм ПОС60. Очень классная штука для пайки SMD 0603. Толстые (1мм) прутки обычно дают слишком большую каплю, а этим можно аккуратно дозировать. Вот я "залил" на эти пады олова и показания стали более адекватными. Правда, через день PD3 снова отвалился - пришлось еще налить олова.

А вот сенсор цвета VEML6040 у меня, почему-то, вообще не заработал. Я его на шине i2c вообще не вижу. Проверял монтаж - пока ничего не обнаружил. Сама шина i2c работает: EEPROM читается, OLED дисплей показывает. Правда, при опросе кнопок, подключенных к PCA9536 повисает (висит в цикле ожидания окончания транзакции), поэтому, пока отключил опрос клавиш и убрал с дисплея меню - всё конфигурирование произвожу через USB-UART терминал.

Pololu, оказалось, летом обрадовало пользователей - выпустило платы для роботов 3Pi и Zumo на RaspberryPI RP2040 контроллере. Чешу репу на тему хочу ли я такую или нет. Думал, купить для Zumo, но там питание для моторов слелано без повышающего преобразователя.

А тексас инструментс куда-то подевал информацию про RSLK. Теперь, эта ссылка http://ti.com/rslk выдаёт надпись:
Код:
Gone
The requested resource is no longer available on this server and there is no forwarding address. Please remove all references to this resource.
А жаль.

Re: RSLK от TI (Robotic System Learning Kit)

Вт янв 02, 2024 10:00:42

У нас начался очередной чемпионат. На первые соревнования, что были в начале декабря, не ездил, так как там были сплошные "Лего". А вот на вторые, в институте транспорта и связи, съездил. Правда, выложить "козырь" в лабиринт я не смог - из-за упомянутых проблем с сенсорами, поэтому повез старый "кирпич", который не дал никакого результата. просто формально поучаствовал. Лабиринт очень напоминал прошлогодний:
Изображение
Но так как у меня ничего принципиально нового там не было - ничего не снимал.

А всё внимание попытался направить на соревнование по следованию по линии. Хотя, тут тоже новизной нас не порадовали - трасса была точно такая же как в прошлом году и еще несколько лет до этого. Даже литовские участники высказались, что скучно это. Так что фотка, для иллюстрации - прошлогодняя:
Изображение
После соревнований прошлого сезона в linefollower вставил line regulation - коррекцию ширины ШИМ импульсов управления двигателями в зависимости от напряжения батареи. Правда, доказательства работы этой фичи так и не сделал, но робот по трассе ходил ничуть не хуже чем раньше - может эта фича и работает. Теперь решил "разметить" трассу - проехался по ней на небольшой скорости и пошел изучать лог-файл. В этом году направление движения было задано: от стартовых ворот в сторону наблюдателя. Поэтому я в трассе задал форсаж на стартовом участке, затем просто повышенная скорость на двух поворотах и снова форсаж на прямом участке, а затем снова повышенная скорость, а в самом конце, где трасса идёт змейкой - пониженную скорость, так как к этому месту робот уже на колёса успевает набрать пыли и сцепление с поверхностью катастрофически ухудшается. Ну и на финишной прямой снова максимальный рывок. Здесь, в качестве фиксатора использовался луч лазера или светодиода, поэтому проблемы с фиксацией проезда через ворота не было.

Когда же поехал по трассе, оказалось, что финишного рывка не было. Пошёл скачивать лог-файл и выяснять, что случилось. Оказалось, что все сегменты сдвинуты, по причине того, что не был опознан первый перекрёсток. Хм... Попытался сместить все сегменты, с учетом того, что первый перекрёсток не опознался. Проехал - без результатно. Пытался снизить скорость - тоже никакого результата. Причем, оказалось, что первые 4 перекрёстка могут быть не опознаны каждый раз по разному. Иногда не опознавался 1 перекрёсток из 4, а иногда 2. И каждый раз разные. Вот фрагмент журнала последнего заезда - второй и четвёртый перекрёстки не опознались.


Алгоритм опознания базируется на том, что сенсоры линии у моих роботов для следования по линии расположены не в линию, а по дуге. И боковые сенсоры "отстают от серединных чуть меньше чем на 5 мм. В результате прохода через перекрёсток получается картинка не в виде знака "+", а как схематическое обозначение антенны - боковые проходы направлены под острым углом к основной линии. Поэтому, в момент выезда из перекрёстка видны "пробелы" между основной линией и боковыми. Вот это является признаком перекрёстка. Конечно, чтобы такое опознание сработало, необходимо иметь достаточное число сэмплов. А тут получился облом. Если проанализхировать данные, получается, что уже на участке между 2 и 3 перекрёстками скорость робота достигает почти 2.5 м/с (там можно заметить, что участок в 25 сантиметров робот прошел за 1/10 секунды) и при такой скорости ширину линии в 15 мм робот проскакивает за 6 миллисекунд. А частота сэмплирования у меня была всего 400 раз в секунду, т.е. период всего 2.5 миллисекунды. Поэтому и получалось так, что на пересечение линии уходило только 2-3 сэмпла и вероятность, что сэмплирование произойдёт в том положении, когда средние сенсоры выехали из перекрёстка, а боковые еще нет была уже меньше 1.

Поэтому, единственное решение для устранения этой проблемы - поднять частоту сэмплирования. Правда, это вызовет другую проблему - памяти для записи журнала хватит на меньшее время. Объём FRAM у меня, вроде, 128К, за фрейм записывается 8 байт и получается, что при частоте сэмплирования 1000Гц получается всего 16.384 секунды. Маловато будет, но код я уже перекомпилировал под такой вариант - на следующих соревнованиях буду смотреть как оно пойдёт. Попутно, изменив частоту с которой будет работать ПИД удерживающий робота на линии, надо соответственно изменить коэффициент Kd. Но, подглюдел как это сделано в UKMARSBOT и сделал так же - число из установок делится на этот frame rate, в результате, оно становится неизменным, какой бы frame rate ни установить.

Конечно, после соревнований, на остывшую голову, мне пришла мысль, как следовало бы поступить. Надо было заблокировать обнаружение всех первых 4 перекрёстков, и разрешить опознание перекрёстка "4" после прохода петли, тогда скорость робота упала бы и он был бы достаточно хорошо опознан. Вообще, оказалось, что робот шёл на участках где планировалась скорость "fast" на скорости "max" и при этом почти без проблем. Проблема была бы на повороте с номером "5". Но благодаря бортику вокруг трассы, робот утыкался в него, терял линейную скорость, поворачивал и спокойно подхватывал линию и продолжал бежать дальше. Ну, это "хорошая мысля приходит опосля". Еще из мыслей "опосля" была в том, что я забыл, что у меня есть еще одна фича, которую я еще ни разу не попробовал применить - называется "подготовка к повороту" - переход робота в позицию "оптимизированную" для соответствующего поворота. Т.е. пред поворотом вправо, робот должен тоже сместиться вправо. Правда, так как число сенсоров небольшое, то это смещение будет очень маленькое миллиметров 10-20 - почти незаметное.

По результатам робот занял 4-е место. Первые три, естесственно, взяли шауляйские роботы. А мне до третьего не хватило 50 миллисекунд.

А с роботом на шасси Zumo у меня всё не вяжется - со временем всё равно отсыхают эти два сенсора. Надо было бы полностью пересобрать его, но решил всё же заказать новую плату, где устранены некоторые недочёты, которые выявились в первой версии.
Ответить