RSLK от TI (Robotic System Learning Kit)

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

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

Добавлено after 10 minutes 53 seconds:

uldemir писал(а):

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

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

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

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

Видео отличное - все основные проблемы рассказаны. Ну и лица сплошь знакомые: Дэвид Оттен и Питер Харрисон. Хотя насчет "собрать робота в спальне" он немного покривил душой. Там и 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мм - это максимальная ширина робота. Это не значит, что робот выполняет поворот касаясь внешними частями гусениц, а, скорее, то, что точки контакта образуют не прямой угол с осевой линией. И при поворотах на месте робот постоянно смещается влево. Еще предстоит посмотреть как робот будет выполнять плавный поворот, но из-за этой не повторяеиости поворотов начинаю думать, что надо делать другую кинематику.

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

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

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

Это в режиме симуляции с командной строки проверка работы функций. Так что к такому повороту событий я готов. Облом будет, если старт будет откуда-нибудь с середины.

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

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

Съездил посмотреть соревнования 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.

А жаль.

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

Но так как у меня ничего принципиально нового там не было - ничего не снимал.

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

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

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

Спойлер

Код:: время, сенсоры, сегмент, ошибка, макс.скорость, расстояние 01.560,...##...,4,-36,12000,2198 01.562,...##...,4,-40,12000,2200 01.565,...##...,4,-39,12000,2205 01.567,...##...,4,-26,12000,2209 01.570,...##...,4,-4,12000,2213 01.572,...##...,4,11,12000,2217 01.575,.######.,4,37,12000,2221 01.577,########,4,-18,12000,2225 01.580,########,4,-19,12000,2230 01.582,##.##.##,4,9,12000,2233 01.585,...##...,7,35,12000,0 01.587,...##...,7,60,12000,4 01.590,...##...,7,80,12000,9 01.592,...##...,7,80,12000,11 .... 01.710,...##...,8,-63,25000,233 01.712,...##...,8,-54,25000,240 01.715,...##...,8,-39,25000,245 01.717,...##...,8,-28,25000,252 01.720,..####..,8,19,25000,256 01.722,########,8,-12,25000,263 01.725,########,8,-23,25000,270 01.727,...##...,8,0,25000,275 01.730,...##...,8,7,25000,281 01.732,...##...,8,10,25000,288 01.735,...##...,8,-11,25000,295 01.737,...##...,8,-23,25000,299 .... 01.810,...##...,8,30,25000,484 01.812,...##...,8,29,25000,491 01.815,...##...,8,26,25000,498 01.817,...##...,8,29,25000,505 01.820,...##...,8,32,25000,511 01.822,...##...,8,23,25000,518 01.825,#######.,8,-91,25000,525 01.827,########,8,-1,25000,532 01.830,#..##..#,8,0,25000,538 01.832,...##...,14,12,25000,0 01.835,...##...,14,25,25000,7 01.837,...##...,14,46,25000,14 01.840,...##...,14,37,25000,20 01.842,...##...,14,19,25000,26 01.845,...##...,14,45,25000,32 01.847,...##...,14,45,25000,39 .... 01.930,...##...,15,-13,25000,269 01.932,...##...,15,-16,25000,276 01.935,...##...,15,-16,25000,283 01.937,...##...,15,-13,25000,291 01.940,...##...,15,-9,25000,298 01.942,...##...,15,-15,25000,306 01.945,...##...,15,-2,25000,312 01.947,########,15,-45,25000,320 01.950,########,15,-18,25000,327 01.952,...##...,15,-21,25000,334 01.955,...##...,15,-30,25000,342 01.957,...##...,15,-24,25000,350 01.960,...##...,15,-16,25000,357 01.962,...##...,15,-11,25000,363 01.965,...##...,15,-4,25000,370 01.967,...##...,15,-9,25000,378 01.970,...##...,15,3,25000,386 01.972,...##...,15,8,25000,393 01.975,...##...,15,20,25000,400 01.977,...##...,15,27,25000,408

Алгоритм опознания базируется на том, что сенсоры линии у моих роботов для следования по линии расположены не в линию, а по дуге. И боковые сенсоры "отстают от серединных чуть меньше чем на 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 у меня всё не вяжется - со временем всё равно отсыхают эти два сенсора. Надо было бы полностью пересобрать его, но решил всё же заказать новую плату, где устранены некоторые недочёты, которые выявились в первой версии.

Ну, что ж, rest in peace, RSLK. Похоже, что тексасовцы про его забили. И пололовцы тоже, на все продукты прямо связанные с RSLK статус поставлен End-of-Life Rationing:

Спойлер

This designation is used for products that will be discontinued due to circumstances beyond our control, including discontinuation of key components or discontinuation of a product by the manufacturer if it is not Pololu. EOL rationing is done for products that are popular or have been in production for a long time and for which we expect the remaining available stock to be insufficient to meet historical demand. Methods for rationing include (but are not limited to) order quantity restrictions, raised prices, and reverse quantity breaks (i.e. unit prices go up with quantity). Coupons and sales will typically not apply to rationed products.

За это время поучаствовал на 3 соревнованиях в дисциплине следования по линии. Всюду, были те же трассы, что и в прошлом году, кроме Прейли - там трасса была очень простая - почти такая же как для Лего роботов, только на одну фигуру больше:

Поэтому на этой трассе я не программировал маршрут, а гнал просто с константными параметрами. И результат был плохой. Мало того, что литовские роботы заняли призовые места, еще и уступил роботу из Гулбене две десятых секунды (7.404 и 7.202 до третьего места не хватало целой секунды).

На сигулдской трассе лидировали литовцы у меня только седьмое место, а коллега из Гулбене заболел и не смог приехать. Зато выяснил, третьего конкурента из команды "jaunība" - это из города Даугавпилс. У их роботов стоит больше, чем 8 сенсоров для линии. А контроллер, вроде, всё та же ардуино нано. Поинтересовался, как они опрашивают такую толпу сенсоров - оказалось, что там на плате стоит еще один модуль - аналоговый мультиплексор. Ну и расположение сенсоров интересное: центральные в линию, а боковые - под углом - образуют что-то вроде симметричной трапеции. У меня сенсоры выложены по дуге, с центром примерно в центре робота между осями колёс.

Вот после двух неудачных соревнований, стал думать, что еще сделать для улучшения положения. И одно из - решил повысить напряжение подаваемое на двигатели. К этому сезону, я добавил line regulation - чтобы моторы не зависели от напряжения на батарее. Т.е. если я в функцию, передаю число соотвествующее некоему напряжению на двигатели (числа мистические, так у этого процессора сплошь целочисленка - у него нет плавучки), то в регистр ШИМ записывается число пропорциональное напряжению на батарее, измеренное в данном цикле. А максимальное напряжение было установлено 6.4в, т.е. если в функцию передать максимальное число 32767, то на двигатели будет сформирован ШИМ, соответствующий этому напряжению и не выше. Так вот к следующим соревнованиям (последним на данный момент и предпоследним в этом сезоне) я повысил это напряжение до 7 вольт. Сделал еще несколько "улучшений" и когда приехал на соревнования, выяснил, что у меня не работает журналирование. Так как после первых соревнований в TSI мне показалось, что делать 400 сэмплов в секунду мало, решил поменять эту частоту. В прейли и Сигулде робот бегал делая 1000 сэмплов в секунду. Но это имело помимо плюсов так же и минусы. В памяти умещалось всего 16 секунд бега, но и эти 16 секунд, чтобы скачать их, просили очень много времени. Ну и по этим "картинкам" стало гораздо труднее распознавать повороты. Поэтому, всё ж "урезал осетра" до 500 сэмплов в секунду. Так же поправил программу, чтобы она была более толерантной к этим изменениям "частоты кадров" (добавил в заголовок журнала информацию об этой частоте). Но вот делая эти изменения, что-то поломал и в Даугавпилсе на соревнованиях выяснил, что журнал или не пишется, или пишется, но не туда, так как вижу часть мусорных данных, а часть явно от Сигулдской трассы. Поэтому, снова пришлось ехать на постоянной скорости. Пока готовился, нашел "неторопливую" скорость, при которой робот нормально проходит повороты без заносов. Установл значение 15000, что соотвествует 3.2в на моторах. Но когда начались заезды - робот всё никак не мог доехать до финиша. В одном заезде, даже, возможно, контроллер был зависши - на кнопку старт/стоп не реагировал. Возможно, батарейка уже была подсевши (начал мигать красный светодиод - еще одно "улучшение" что я сделал, предупреждение, что напряжение батареи упало до 7.4в) или так проявляется проблема с журналированием. Поменял батарейку, заблокировал журналирование и еще подкорректировал высоту сенсоров над трассой, чтобы она была лучше видна и не было ложных данных. Тогда-то, на четвёртом заезде, робот доковылял до финиша. И результат оказался самым лучшим. Ах ну да, литовцев не было! Пятую попытку, решил придержать, потому как гулбенские и даугавпилские роботы еще свои попытки не исчерпали и решил подождать, как у них пойдут дела. А! в нашей категории участвовало 5 роботов - по 2 из Гулбене и Даугавпилса, а я решил не распыляться и выставил только одного. Благополучно дождался, когда конкуренты исчерпали свои попытки и решил, что пятый заезд делать не буду.

Таблицы результатов: Прейли, Сигулда, Даугавпилс. Мой робот "Noname".

Можно даже сказать, что чемпионат для меня закончился - у меня в нашей таблице уже есть три первых места, а у конкурентов, даже с учетом последних соревнований, что еще будут в мае, такой возможности нет, так что переходной кубок останется в нашем клубе, вне зависимости, от результатов на последних соревнованиях.

На соревнованиях в Прейли, мне было предложено, для популяризации лабиринта, притащить его и немного погонять по нему своего робота. Поэтому я мало уделили внимания соревнованиям следования по линии. Так что возникла возможность собрать то что у меня есть полностью. Конечно, еще не 16х16, а всего 6х8:

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

Погонял своего робота и вскрыл некоторые проблемы.Одна из проблем с сенсорами - при сильном внешнем освещении сенсоры заходят в насыщение и перестают видеть. Надо изменить схему питания сенсоров и, возможно, попробовать сделать их с инфракрасными светодиодами и фототранзисторами.

Так то робот используя алгоритм заполнения нашел финиш, а на обратном пути и кратчайший путь (не оптимальный!):

Спойлер

Вот карта в составленная в памяти робота. Как видно, он не посетил левый верхний и правый нижний углы лабиринта.

Код:: Griever>init_target Griever>print_maze_plain o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o | | ... o o o o o o o o o o o o o o o o o | | o o o o---o---o---o---o---o o o o o o o o o | | | o o o o o---o---o---o o o o o o o o o o | | | F F | | | o o o---o---o o o o o o o o o o o o o | | F F | | | o o---o---o---o---o o---o o o o o o o o o o | | | | | o o---o o---o o---o---o o o o o o o o o o | | | | | o o o---o o---o o o---o o o o o o o o o | | | | o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o Griever>print_maze_closed o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o | | | | | | | | | | | | | | | | | ... o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o | | | | | | | | | | | | | | | | | o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o | | | | | | | | | | | | o---o---o---o o---o---o---o o---o---o---o---o---o---o---o---o | | | | | F | F | | | | | | | | | | o o o---o---o o o---o o---o---o---o---o---o---o---o---o | | F F | | | | | | | | | | o o---o---o---o---o o---o o---o---o---o---o---o---o---o---o | | | | | | | | | | | | | | | o o---o o---o---o---o---o o---o---o---o---o---o---o---o---o | | | | | | | | | | | | | o o o---o o---o o o---o---o---o---o---o---o---o---o---o | | | | | | | | | | | | | o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o

Ну и маршрут из нулевой (стартовой) клетки до финиша выглядит так:

Код:: Griever>0 make_path Griever>show_path BFRFFRLFFLRLLFRS Griever>make_commands Griever>show_commands BHHRHHHHHHRHHLHHHHHHLHHRHHLHHLHHHHRHHS

B - начало
S - конец
F - на клетку прямо
H - на полклетки прямо
L - налево
R - направо

Так же пытаюсь продумать как сделать "управление" роботом, чтобы указывать какой тип прохода использовать и как бы стимулировать изменять скорость движения при помощи этого ДИП-свитча. Но это потом.

На соревнованиях в Сигулде был запланирован лабиринт из линий. Но потом эту дисциплину убрали. Мне очень хотелось запустить по линии робота на гусеницах, но проблема с "отваливанием" двух сенсоров линии постоянно возвращалась, несмотря на то, что регулярно пытался "подпаять" те два вывода. Для кардинального решения, надо бы перепаять модуль BGM240 полностью. Но я решил заказать и собрать новую плату с исправленными ошибками, которые я сделал в первой версии.

Эта плата завелась сразу - ничего перепаивать не нужно было. И цепи включения- выключения работали как часики, и ключ на полевом транзисторе не ссаживал напряжение. Одна только проблема - заметил, что у этих роботов (на BGM24) повисает i2c шина. На старом роботе панель с дисплеем и кнопками, работающими через i2c, была смонтирована на роботе, там я заметил, что зависает на опросе кнопок, когда идёт считывание расширителя портов pca9536. В новом, я панель не ставил, А посто надевал OLED дисплей и заметил что и там происходит зависание. Для BGM24 я не писал драйвер мастера i2c, как это делал для MSP432, efm32g12, так как запутался с этими "двойными" регистрами с FIFO. Поэтому использовал драйвер "из коробки" (силиконлабовский), а просто написал несложную "обёртку":

Спойлер

Код:: I2C_TransferReturn_TypeDef i2c_rd(uint8_t address, unsigned char * data, unsigned int length) { while (i2c_state == i2cTransferInProgress) continue; wr_seq.addr = address; wr_seq.flags = I2C_FLAG_READ; wr_seq.buf[0].data = data; wr_seq.buf[0].len = length; if (i2cTransferInProgress != (i2c_state = I2C_TransferInit(I2C_DEV, &wr_seq))) return i2c_state; while (i2c_state == i2cTransferInProgress) continue; return i2c_state; }

В прерывание засунул

Код:: void I2C_IRQHandler(void) { i2c_state = I2C_Transfer(I2C_DEV); }

Зависает в цикле while потому что статус так и стоит i2cTransferInProgress и всё. Пока еще не разбирался, в чем там проблема.

вместо

Код:: if (i2cTransferInProgress != (i2c_state = I2C_TransferInit(I2C_DEV, &wr_seq))) return i2c_state; while (i2c_state == i2cTransferInProgress) continue;

вероятно, надо

Код:: do { i2c_state = I2C_TransferInit(I2C_DEV, &wr_seq))); }while (i2c_state == i2cTransferInProgress);

Если, конечно, i2c_state не глобальна и не может измениться где-то ещё в другом потоке. Если нет - из цикла нет выхода.
Притом, число попыток инициализации я бы тоже ограничил. Или время.

P.S. Почему-то именно с i2c примеры от производителей наиболее грешат попаданием в бесконечные циклы.

Продолжение с i2c: тама в инструкции приведен пример, когда I2C_Transfer(I2C_DEV) вызывается в цикле, но упомянуто, что можно вызывать и в прерывании. Я вызывал в прерывании с целью, впоследствии сделать так, чтобы не сидеть в цикле ожидания трансфера. Но пока этот вариант не дошел до реализации, решил вставить вызов этой функции и в цикл ожидания. Поломалось всё. Оказалось, что эта функция не реентерабельная и разом её пользовать в поллинге и в прерывании нельзя (а в документации об этом ни слова).

Попробовал сделать чистый поллинг. Для проверки запустил на дисплей анимашку - несколько часов нет зависаний... Для проверки вернул прерывания - тоже всё работает. Хм, возможно, драйвер починили при одном из апгрейдов SDK? Но кто же читает эти релизноты?!

То что дисплей заработал - хорошо. Несмотря на то что большинство тестов перевёл в текстовый вид и могу использовать с командной строки, тест сенсоров линии в таком виде не могу представить. А настройку на трассу всё же надо делать, что показали последние соревнования. На них я заявил обоих роботов. Для этого робота на гусеницах, решил сделать движение на основе драйвера профайлера. К сожалению, его поведение отличается от "нормальных" лайнфолловеров. Чтобы сделать "нормальный" надо бы отключить профайлер, а я решил сделать именно на его базе. Алгоритм простой: сначала делается тренировочный заезд - робот идёт по трассе, но потеряв линию экстренно тормозится. После остановки откатывается назад до позиции где была потеряна линия. Затем робот поворачивает в ту сторону (на 90 градусов - увы, не придумал, как измерить угол), куда, по его мнению, ушла линия и цикл повторяется. Этот алгоритм хорош был бы если трасса состояла бы из прямых участков и "ломаных" поворотов. А при втором заезде, робот проезжает трассу пользуясь информацией, о длине участка, до потери линии - т.е. гонит участок, а в конце сбавляет скорость так, чтобы при потере линии сразу повернуть и двинуть следующий участок. Конечно, это не позволяет обрабатывать плавные повороты. Но для плавных поворотов предполагалось пользоваться опцией steering профайлера. Эта "рулёжка" предназначена делать небольшие коррекции, чтобы робот в лабиринте не утыкался в стены, а не для того, чтобы выписывать сложные траектории. Но я расширил ограничения. Правда я не рассчитывал, какой минимальный радиус поворота способен робот взять в зависимости от значения линейной скоростии - планировал это выяснить на трассе экспериментально.

Да, я держал в голове прошлогоднюю трассу - думал, что будет снова та же самая. Но, случился облом. Трассы были типа freehand и страшно короткие. Когда готовились, я был как-то ляпнувши, что трасса на 5 секунд - так потом и оказалось, что большинство результатов было около пяти секунд плюс-минус секунда.

Конечно, по такой трассе гусеничый робот мог пройти только на минимальной скорости, поэтому я ему сделал "круг почета" на скорости 10 см/с, на что ему потребовалось 75 секунд.

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

p.s. дальше должны были следовать рассуждения на тему как трудно без "оруженосца" проводить считывание журнала и внесение изменений в конфигурацию роботов. Но пока лень писать.

Всё всегда происходит в последний момент. Вроде, уже пол-года назад было известно когда будут соревнования Robotex в Таллине, а план мероприятий опубликовали всего за неделю до него. Думал, что соревнования по лабиринту будут, как в прошлом году во второй день, в субботу, купил билеты на субботу, а тут выясняется, что всё же в пятницу. Билеты поменял, но не знаю, смогу ли с работы отпроситься.

Так и с нашим чемпионатом. Вроде, примерно знал, что в декабре будет в институте транспорта и связи соревнования, но тут вдруг выясняется, что там будут только для школьников. Зато внезапно выяснилось, что 30 ноября назначены соревнования для роботов свободной конструкции в Сигулде. Съездил туда. Выглядело, как небольшая тусовка. Довольно мало участников. Соревнования следования по линии прошли за 40 минут! Правда, снова давалось всего 3 попытки.

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

Спойлер

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

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

(на фото VEX IQ робот - они использовали для своих соревнований это же поле)
Вот этот лабиринт 7х14 и я его могу разместить внутри по разному, так чтобы, например, два или один край лабиринта был уже предопределён или вообще, "подвесить" в середине чтобы робот не знал о внешних границах, пока сам не увидит. Это даёт возможность отказаться от "стратегий" - какой ход в узле предпочесть, при прочих равных условиях. Раньше у меня были 6 стратегий, про которые я писал в этом сообщении под спойлером. Теперь же, в лабиринте объявляю финишную зону - прямоугольную территорию от которой ведётся расчет "расстояний" по алгоритму заполнения и направление выбирается в сторону ячейки с меньшей стоимостью. Таким образом, если я хочу, чтобы робот стремился в правый верхний угол лабиринта, то финишная зона назначается в квадрате [15:15], если в левый верхний - [0:15]. Если просто в левую сторону, то могу объявить всю сторону от [0:0] до [0:15]. Ну и после каждого посещенного узла, заполнение пересчитывается. Для примера как выглядит заполнение в случаях: если стремимся в правый верхний угол или просто вверх:

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

Но ключевым моментом успеха на соревновании, является быстрый проход по лабиринту. Хотя этот робот и способен развить скорость 2 м/с на прямых участках, с поворотами тоже надо что-то делать. Поэтому решил заняться "плавными поворотами" (smooth corners). Вот ссылка на статью Питера Харрисона: тут. Если её почитать, то получается, навроде, что траектория почти круговая. Переход от прямолинейного движения к круговому всего 5-6мм (с обоих концов). Ну я подумал и решил, что раз у меня шаг клетки 180мм, то радиус поворота - 90мм. Вычислил длину дуги (90*π/4 = 141.37мм) - по этой дуге робот должен двигаться с константной линейной скоростью (пока выбрал 25см/с). при указанных данных это займёт 0.565 секунды. Из этого можно легко вычислить, что скорость поворота робота в это время должна быть 159 градусов в секунду. Однако, при попытке проехать по трассе с такими параметрами робот на повороте проезжал мимо линии выходящей из узла.

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

простое квадратное уравнение. Но попробовал его решить - дискриминант получился отрицательным. Оказалось, что ускорения, что я использовал, 720 градусов на секунду в квадрате не достаточно, чтобы робот набрал эти 159 градусов в секунду. Т.е. Робот даже не вышел на круговую траекторию (и вообще не успевал повернуться до конца). Когда в экселе помоделировал с числами, оказалось, что 1800 градусов на секунду в квадрате достаточно для моего случая. Вообще то, у квадратного уравнения два корня. Думал, что один корень будет отрицательным и его нужно будет просто отбросить, но оба оказались положительными (при моих исходных данных). Для робота я выбирал меньший корень, чтобы угловая скорость была не большой и быстрее набиралась, чтобы участок "не круговой" траектории был минимальный для уменьшения погрешности. Потому как реально, длина "дуги" теперь должна быть другой! Может, теперь исходя из максимальной угловой скорости вычислить радиус, вычислить длину этой дуги, прибавить длину потраченную на "разгон/торможение", получить новую длину и сделать следующую итерацию? Хм. буду еще думать, но пока даже с этим результатом робот на моём полигоне повернулся вполне внятно.

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

Ну до февраля надо бы с этими проблемами разобраться.

p.s. Добавил видео

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

Спойлер

Пришлось сделать несколько неалгоритмических ухищрений. Собственно, всё связано со стартовой клеткой. Пришлось её исключить из тупиков тоже, иначе, когда алгоритм его объявляет тупиком, робот не возвращается на старт, а останавливается на последней исследованной клетке.

Долго возился с алгоритмом детектирования перекрёстков. Хотелось, чтобы поскорее было бы известно, нужно продолжать движение прямо или надо тормозить, для того, чтобы выполнить маневр. И это (вкупе с заданным ускорением) ограничивает скорость на какой можно выполнять поиск. Пока, ускорение установлено 2м/с^2, скорость поиска всего 36 см/с.

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

Вот сделал журналирование напряжения на батарее:

Левая картинка с транзисторным ключом, правая - с механическим. И вот почему происходит такая просадка при механическом ключе, пока не выяснил - батарейки или контакты? И что делать?

Пока размышляю на тему перейти на 12в питание (4 батареи LiFePo по 3.3в) и отказаться от повышающего проебразователя. Только не могу решить, ставить 12в моторы или оставить 6в. Так же надо бы поменять подключение оптических сенсоров - поднять им питание, а то при 3.3в они быстро заходят в насыщение и ограничивают динамический диапазон.

Решил чуть поиграться с Bluetooth. Сделал так, что робот при поиске в лабиринте опознав ячейку, через блютус шлёт notification (если запрошен) с координатами ячейки, её стенами и цветом тупика. Ну и написал несложную аппликушку на смартфон, которая принимает эту информацию и отображает на экране:

Кнопка list выдаёт список спаренных устройств для выбора с кем соединяться кнопкой "Connect". Если доступна характеристика данных лабиринта появляется поле лабиринта и запрашивается notification этой характеристики. По старту поле очищается и прописываются те клетки, где в данный момент находится робот. На скриншоте видно, что в правый верхний угол робот не ходил и те клетки не прописал, так как алгоритм распознал там тупик. Кнопка Stop у этого робота пока не действуют (она думана для Linefollower-ов). Ну и в самом низу указатель уровня напряжения на батарее. Аппликация раз в секунду запрашивает эту информацию и отображает. Уровень 0%, так как сейчас робот стоит на столе и питается от USB.

Съездил на одни соревнования. Предыдущие пропустил из-за болезни. Но снова поменялись правила чемпионата. Если раньше все соревнования давали очки по которым распределялись места, то теперь результатом чемпионата будет только последнее состязание в мае в RTU (рижском техническом университете). Но, на это соревнование кто угодно поехать не может. Туда попадут только те, кто хоть раз за сезон получил призовое место (с первого по четвёртое) хоть в одних соревнованиях. Ну что ж, одно второе место у меня уже есть - так что: вхож.

Эти соревнования проходили в городе Валмиера. Основные соревнования в спортивном зале

а дроноводы - в бассейне

без воды. Я предпочел бы, чтобы там была вода и можно было бы понырять с "вышки".

Трасса для следования по линии была такая, по которой еще не ездил:

По плану это соревнование должно было проходить с 12:30 до 14:30, но приехал пораньше, чтобы было время настроить робота. Робота особо настраивать не пришлось, так как на этой трассе нет больших прямых кусков (самые большие меньше полтора метра через перекрёстки и метровая "финишная прямая"), никаких рывков роботу не задавал. Выставил чувствительность сенсоров, проехал трассу. В роботе стояло время работы 26 секунд и за это время робот навернул почти три круга. Поэтому посчитал, что на круг 9 секунд и надбавил еще пару секунд сверху. Т.е. время работы установил 11 секунд.

В профессиональной группе участвовало снова 5 роботов: по два из Гулбене (от моего основного соперника ;-) ) из самой Валмиеры и мой робот. Валмиерские роботы были из "воркшопа". В этот раз соревнования проходили два дня, так как помимо соревнований чемпионата по робототехнике проходил еще FLL (first lego league). Там командам школьников надо было выполнить какие-то миссии. И помимо этого FLL, был "воркшоп" для лайнфолловеров. Участие платное: 35 евро. Когда увидел, зашел на регистрацию, но оказалось, что все места уже заняты ;-). Эта "мастерская" проходила в субботу. Участникам были выданы шасси из оргстекла, на которое крепились моторы, плата с сенсорами QTR8, ардуино нано и драйвер моторов TB6612. Колёса к моторам были специальные с отлитыми из силикона шинами (очень хорошие!). Ну и так как школьники с субботы на воскресенье ночевали в классах в школе, они могли весь вечер и всю ночь настраивать и программировать их, чтобы на следующий день с этими роботами участвовать в соревнованиях. Один из таких роботов (RED_DEVIL), по трассе шёл очень даже неплохо, хотя его автор сказал, что "там у него 11 if-ов и никаких PID" и что он с ним возился всю ночь. Результат был вполне конкурентный - 11.2 секунды!

Соревнования начались раньше. По графику сначала должны были выступать школьники, а потом любители/профессионалы, но реально всё проходило вперемешку. Однако, когда я поставил робота на трассу и нажал кнопку старт - робот с места не сдвинулся. Сразу отказался от попытки. Оказалось, что робот не видит линию. За время прошедшее с момента подготовки, на улице прояснилось и выглянуло солнце. И хоть на трассу солнечный свет не попадал, в зале стало так светло, что сенсоры были засвечены и линию не видели вообще. Пришлось снова провести регулировку чтобы робот видел линию. Видеть-то он видел, но это было "на грани". Тем не менее, первый же заезд оказался сразу лучшим (8.299 сек.). А вот у конкурента из Гулбене дела не очень шли. Один робот шел стабильно, но отставал от моего почти на секунду, а второй, который был реальный конкурент, почему-то сбрасывался. Этот конкурент был сделан на ESP32. Судья предложил и я согласился, что этому роботу не будем считать попытки пока он не сможет доехать до финиша и стали выяснять, что же с ним не так. Поведениие его было странным. Ставим на трассу, запускаем, он проезжает какой кусок и сбрасывается. У него на борту стоял OLED дисплей и по показаниям дисплея это и определяли. Была мысль, что напряжение на батарее проседает, но замена батареи не помогла. Робот сбрасывался даже тогда когда просто его ставили на трассу. Тогда предположили, что виновата электростатика - кто-то электризуется или робот, или трасса. Тогда, вход сброса контроллера жёстко посадили на массу и помыли трассу влажной тряпкой. И вот после этого робот прошел трассу. Правда, результат отставал от моего больше чем на полсекунды. Пока был успокоившись, но подумал, надо бы слегка поднять моему роботу скорость и проехать еще разок. Повысил все параметры на "2000" и пошел становиться в очередь. В этот момент робот конкурента делая четвёртую попытку показал 8.104 секунды, потеснив моего робота на второе место. Но это было не надолго. сразу же следом я пустил своего робота и побил этот результат: 8.074 секунды. Последнюю попытку робот конкурента провалил - на одном из поворотов свернул "не туда". Ну я подумал, а не попытаться ли перешагнуть 8-секундную границу и повысил все параметры скорости еще на "2000". Вот запись этого заезда: (утюб поместил его в шорты и я его в форум встроить не могу - только линк)

https://www.youtube.com/shorts/P8MX0Pdw ... ture=share

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

Но соревнования вскрыли в полный рост проблему с сенсорами - надо что-то делать. Либо сомбреро (по испански, вроде, маленькая тень), либо делать как у робота для лабиринта - два считывания с подсветкой и без. Еще надо, наверное, поменять положение нагрузочного резистора сенсора. Пока все сенсоры имеют такую схему:

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

правда, для этого надо делать полностью нового робота. Начал приглядываться на каком бы контроллере. Мне очень заманчивым показался новый Pearl Gecko EFM32PG26. Но оказалось, что его еще толком не выпускают - купить его нельзя. А другие PG23, PG28 - имеют всего по одному 32-битному таймеру, а хотелось, на каждое колесо иметь свой счетчик.

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

Трасса FolkRace - вроде, не сложная, но очень длинная

Antweight - брутальный спорт. Надо или загнать противника в яму в углу или иным способом его обездвижить (вплоть до его разрушения). Некоторые роботы после соревнования собирают с поля с помощью метлы и совочка. Но эти соревнования не чисто роботов - это, скорее, как и у дроноводов на мастерство операторов дистанционного управления.

Vex IQ тоже роботы с дистанционным управлением, должны таскать с поля фигуры и складывать в определённых местах

Еще были соревнования для самых маленьких участников (до 8 лет включительно) - Spike race. типа драгрейса - надо проехать как можно быстрее пятиметровый участок. Робот должен быть собран прямо на месте соревнований, взрослые там помогать не могут. Собираться должен из комплекта LEGO Education SPIKE Essential. Допустимо было только иметь планшет с заготовленной программой.

Лабиринта не было, но трасса была расстелена и, наверное, на ней проходили еще какие-то соревнования VEX IQ. Наверное, в то же время когда я занимался своими соревнованиями, поэтому не заметил. Но на всякий случай взял своего робота, чтобы погонять по трассе. Робот трассу изучил и составил карту. Можно заметить, сколько тупиков, робот "спрогнозировал" и не посетил. Правда, не понял почему не посещены ячейки x=14-15 y=6-7. Похоже на ошибку в алгоритме

После чего попробовал прогнать робота по маршруту. С плавными поворотами ничего не получилось - робот после поворота не выходил на линию и не мог выровняться. Правда, радиус поворота при 300мм клетке лабиринта установлен всего 90мм. А с поворотами на месте - робот прошел без проблем за 38 секунд (маршевая скорость установлена всего 800мм/с). Чуть позже, я попытался сделать видео, как робот идёт по лабиринту и как это отображается на смартфоне. Разумеется, снималось не разом двумя камерами, сначала экран, а потом реальное передвижение, а в видео я примерно попытался совместить:

Спойлер

Финишная зона установлена была в левом нижнем углу. Поэтому его так тянуло влево.

Но главное моё участие было, разумеется, в соревнованиях следования по линии. Трасса всё та же самая. Но в этот раз направление движения было в другую сторону, чем на первом этапе. На соревнования ехал без надежды, так как среди участников было 2 робота из Литвы, которые наверняка отхватят призовые места, а нам ничего не останется. Правда, когда начались соревнования, оказалось 3 робота из Литвы, и 4 местных: 2 из Гулбене, однин из Даугавпилса и мой. Вместе со школьниками, было 26 роботов, но 6 не проходили техинспекцию. Так что всего бегало 20 роботов и было дано по 4 попытки.

Готовясь, проехал трассу, в тетрадке сделал разметку, где гнать, а где тормозить. Запрограммировал робота и пустил - проехал нормально. А когда начались соревнования, на первой попытке робот "улетел". В самом начале, после старта следуют два поворота и прямой кусок до перекрёстка. Вот его я задал гнать на максимальной скорости, а за перекрёстком резко тормознуть. Так вот робот не тормознул. И первая попытка: DNF. Лог-файл не считывал, и так было ясно, что на такой скорости опознание перекрёстка может не произойти - зависит от того, попадёт считывание, так, что центральные сенсоры будут за перекрёстком, а боковые еще на перекрёстке или нет. Вообще, приходит мысль, что не нужно сенсоры располагать по дуге, а может надо в виде параболы? На второй попытке, убрал этот разгон и робот прошел трассу. Результат был не ахти - литовский робот и соперника из Гулбене были впереди меня. Гулбенский на 0.2с, а литовский на полторы секунды быстрее. После чего попытался поднять скорость на обычных участках. Ну тут мне свезло! Мне удалось получить лишнюю попытку. Дело в том, что во время третьего заезда робот потерял линию в том месте где начинается разгон на прямом участке, но на старте таймерные ворота не сработали, так что попытка не засчитывается. Поэтому я перепрограммировал позицию начала разгона на чуть позже. Вторая "третья попытка", тоже оказалась не удачной - ворота сработали, но робот после прямого участка не успел затормозить и снова вылетел с трассы. Пришлось теперь с другого конца укоротить участок с максимальной скоростью. Ну и последняя, четвертая попытка дала результат который вырвал полсекунды и удалось опередить гулбенский робот. Про то чтобы обогнать литовский - даже и не мечтал. Кстати, остальные два литовских робота, что-то не блистали и по результатам заняли последние места. Пошел искать своего соперника, чтобы сказать, что теперь дело за ним - я свои попытки исчерпал, а у него оставалось еще 2 попытки. Но всё же мой результат побить не удалось, так что мне досталось второе место, а гулбенскому роботу - третье. И хотя даугавпилский робот оказался на 5 месте, он, чувствую, начинает нам наступать на пятки. По крайней мере среди школьников даугавпилсские роботы заняли первое и второе место.

Интересовался у гулбенского коллеги, удалось ли разобраться с проблемой "электризации" робота. Говорит, что видимо причина была в том, что рама была напечатана из PETG материала и она электризовалась. Сейчас рама напечата из PLA-CF (PLA with Carbon Fiber), которая не электризуется. Во всяком случае, на этих соревнованиях сброс контроллера не был зафиксирован.

RSLK от TI (Robotic System Learning Kit)

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

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

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

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

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

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

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

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

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

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

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

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