RSLK от TI (Robotic System Learning Kit)

[GARMIN]

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

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

Добавлено after 10 minutes 53 seconds:
[uquote="uldemir",url="/forum/viewtopic.php?p=4422552#p4422552"]Начал запускать UKMARSBOT.
...коэффициенты ПИД регулировки...
...есть запись с конференции, где эта презентация была представлена и всё сразу прояснилось. Называется "Как кормить вашего робота".

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

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

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

[uldemir]

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

[uldemir]

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

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

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

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

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

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

[uldemir]

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

А жаль.

[uldemir]

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

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

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

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

[uldemir]

Ну, что ж, 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 и всё. Пока еще не разбирался, в чем там проблема.

[Martian]

вместо

Код: Выделить всё

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 примеры от производителей наиболее грешат попаданием в бесконечные циклы.

[uldemir]

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

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

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

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



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

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

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

[uldemir]

Всё всегда происходит в последний момент. Вроде, уже пол-года назад было известно когда будут соревнования 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. Добавил видео

[uldemir]

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

Спойлер

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

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

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

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

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

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

[uldemir]

Решил чуть поиграться с 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-битному таймеру, а хотелось, на каждое колесо иметь свой счетчик.

[uldemir]

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

Трасса 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), которая не электризуется. Во всяком случае, на этих соревнованиях сброс контроллера не был зафиксирован.

[uldemir]

Больше полугода прошло. Были всякие еще соревнования, но про них много писать было нечего. Были впервые соревнования в городе Вентспилс, в Вентспилсском университете прикладных наук. Вообще-т помещения для таких мероприятий не ососбо приспособлены. Фактически тусовались в коридорах. Вот идут соревнования по folkrace, а трасса для следования по линии за кадром правее:

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


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

Как и предсказывал, даугавпилсский коллега, хоть и плёлся в хвосте, но постоянно наступал на пятки - теперь он вырвался вперёд. И первое соревнование уже этого сезона подтвердило - результат остался таким же.

Ну тут сам виноват - проволынил. Решил, что после чемпионата надо строить новый робот и я его построил. Кинематически выглядит как старый, только на BGM240 модуле. Фактически, соотвествует моему роботу на гусеничном ходу. Единственное отличие - построение сенсора линии, об этом писал два сообщения назад. Питание сенсоров сделал 5 вольт, сопротивление нагрузки 10 килоом. Но, кажется, надо было бы поставить еще меньше... и на этом роботов забросил. Надо было бы еще заняться роботом для лабиринта, но я весной не выдержал и, наконец, купил себе каяк. Всегда мечтал о байдарке, но с ней проблема где держать, как транспортировать. А тут начал смотреть, есть каяк, что я могу просто засунуть в салон своей маленькой машинки. Правда, тогда для пассажиров мест уже больше нет. И вместо дрессировки роботов всё лето учился на этом каяке делать эскимосский переворот.

В сентябре меня, конечно, совесть начала грызть, что надо бы готовиться к соревнованиям в Таллине Robotex. Были разработаны и изготовлены новые платы. Всё практически как у старого робота, только с нюансами. В первую очередь мне нужно было выровнять зад. Решил отказаться от плавных поворотов при поиске - пусть будет медленно, но уверенно. Робот доходит до узла, поворачивается на месте и если сзади оказывается стена, делает откат назад, так, чтобы прижимаясь задом к стенке, выровняться соосно коридору, ну и позиция тоже становится гарантированно известной. У предыдущего робота не мог этого сделать из-за торчащего разъёма USB - притопил. Сенсоры сделал на основе осрамовсих светодиодов SFH4545 и даю в них ток 100ма. Это чтобы внешнюю засветку надёжнее перебить. Можно было и больше, но поскромничал. Ну и сенсоры монтировал не на отдельной плате, а сразу же на этой. Опять же, в качестве контроллера - BGM240, так что эти три робота имеют один и тот же "движок". Единственное отличие в этом роботе от предыдущего, отказался от i2c памяти, а поставил SPI EEPROM.

Причём, на борт поставил "первую попавшуюся" современную микросхему от ST m95p32. Судя по названию, 32 Мбит, т.е. 4МБ. Интересной она оказалась в том, что при использовании команды записи страницы "0x02", память предварительно стирать не нужно. Правда, время записи страницы при этом до 2.5мс, но зато страница 512 байт, а не 256, как у "простых" микросхем. Ну, если хочется писать побыстрее, то есть режим записи "0x0a". Причем, если при этом включить режим буферизации, можно заполнять следующую страницу, пока пишется предыдущая. В общем, эта микросхема даёт такие возможности, что можно каждый фрейм записывать по 512 байт (правда, память при этом закончится за 16 секунд). Но, как слышал в одном из докладов в MINOS, один из разработчиков говорил, что его робот пишет в журнал по 60 байт каждый фрейм. Но это будущие возможности. Пока работа с этой памятью идёт по-старому. Потому как за основу взят код от робота на гусеницах, а там журнал сначала пишется в ОЗУ, а только затем перекидывается в FRAM (здесь в EEPROM).

Сборка, зато оказалась весёлой. Если у linefollower робота модуль BGM240 припаялся сразу и без проблем (как и драйвера моторов DRV8838), то тут перепаивал несколько раз. После первого запуска проверил коммуникацию (rx/tx -> CH330 -> USB) - работает. Проверяю контроль напряжения батареи - нет контакта. Отпаял, припаял. Коммуникация работает, батарея работает, переключатель программ - нет. Отпаял-припаял. Коммуникация работает, батарея работает, переключатель программ - работает. Запускаю моторы - кртутят, но всегда в разные сторононы - ага, короткое замыкание сигналов направления вращения. Снова отпаиваем, убираем всё олово, лудим по-новой и припаиваем. Наконец-то всё работает.

Этому роботу решил для поиска сделать алгоритм Люка-Тремо как у робота для лабиринта из линий. Подумалось, что робот у меня медленный и на найденном кратчайшем маршруте преимущества иметь не будет. Надо искать оптимальный маршрут. Написал и начал тестировать на маленьком домашнем лабиринтике (всего 30 клеточек). Но всплыла проблема: по алгоритму робот должен вернуться к старту, а он у меня останавливался в одном месте, даже не изучив лабиринт до конца. Пришлось выяснять в чем дело. Сделал вывод толпы данных в текстовый журнал (информация, что идёт из контроллера в USB параллельно пишется в microSD карточку в OpenLog модуле). Потому как надо было выяснить, чтобы этот баг не всплыл на соревновании. На соревновании баг не вспллыл бы, потому как причиной остановки было то, что когда робот находил последнюю стену, которая закрывает лабиринтик от финиша, находящегося в центре, стоимость всех клеток внутри становится MAX_COST (255) и функция выбора доступной клетки с минимальной стоимостью не могла вернуть доступную, а возвращала значение по умолчанию - назад. Пришлось сделать workaround.

Правда, когда занимался с этой проблемой, заметил, что мои 30 клеток робот изучает порядка 50 секунд. Вопрос, а сколько будет нужно времени, чтобы изучить полный лабиринт? И понял, что, скорее всего не успею уложиться в 300 секунд. Но если в этот раз робот сможет хотя бы добраться до финиша - уже будет не плохо. Но скорость робота при поиске поднял до 45 см/с. Еще из вопросов был, какие параметры менять на соревнованиях. Решил, что при поиске буду уменьшать число поворотов перед необходимостью выравнивания. Потому как ввёл параметр, что робот не на каждом повороте будет пытаться прижиматься задом к стенке, а через заданное число. Но когда робот оказывается в тупике - счетчик принудительно сбрасывется, так что в тупике выравнивание происходит всегда. Для начала установил число 4. Но если робот будет сбиваться, то можно это число уменьшить в 2 раза: 2, 1, 0. Это выбирается тем, какой рукой запускать робота - правой или левой. Если перед стартом поставить руку перед правыми сенсорами, то работают параметры из EEPROM, если левыми - происходит модификация. По убиранию руки - старт через полсекунды.

Вот в таком виде и поехал на соревнования. В этом году решил ехать на поезде, так как наконец-то было организовано железнодорожное сообщение Вильнюс - Рига - Таллин. Билеты продавал эстонский оператор Elron. Конечно ехал с пересадками. Суммарно 3 поезда. До Риги на местном, с Риги до Валги был литовский и с Валги до Таллина на эстонском. Но пересадки были быстрыми - между поездами всего 20 минут. Так что в 10 утра выехал, а около шести вечера был в Таллине. Немного обиделся на организаторов. В прошлые годы был доступен бесплатный билет на городской общественный транспорт. Насчет четверга точно не помню, а то что он еще действовал в воскресенье - помню. Соревнования проходят пятницу-субботу. В этот раз бесплатный билет был только на эти два дня. Но так как гостиницу взял где-то на полпути между станцией и UnibetArena, где проходили соревнования, то обошелся без их автобусов. 3.5 км я могу протопать ножками без проблем.

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

Вот как в этот раз выглядел лабиринт. Старт в дальнем левом углу. Когда начались соревнования, пошел выступать первым. Поставил робота на старт. И пустил. Судьи хотели чтобы я его запустил на раз-два-три... хм, не представляю как это сделать. Ну ладно, робот дошел до финиша и без остановки начал исследовать финишную зону. Вроде, робот уже был на 4 клетке финиша, когда одна судья другой сказала, что "время!". Может они думали, что робот радостно остановится на первой клетке финиша? Но в правилах такого требования не было и робот без остановки продолжил изучение лабиринта. Спустя некоторое время, ошибки накопились и робот таки въехал в стену. Пришлось его взять и хотел запустить в лабиринт снова, но судьи начали меня вопрошать, что я действительно желаю делать "second try?". Говорю, какой секондтрай, если пять минут первой попытки еще не кончились? Перед соревнованиями выяснилось, что тут даются 2 или три пятиминутных попытки и уговорились на числе 3. Они мне начали тыкать в правила соревнований, я хотел им показать... но время то идёт! моё время, кстати. Короче плюнул и ушел. Результат хоть какой-то есть и на том спасибо. Пошел выяснять где робот ошибся и почему.

Оказалось, что робот не увидел (вернее даже снял ранее установленную) фронтальную стену. Т.е. получалось, что в момент детектирования стены робот не был еще в той позиции откуда надо было бы смотреть стены. Ну для улучшения ситуации решил понизить скорость поиска до 35см/с и сделать чаще выравнивание. Тем временем пришла судья и сказала, что моя претензия была правильной, что действительно, надо использовать 2 секундомера, один для 5 минут и один для измерения времени прохода и что этот результат засчитывают, но попытка не считается. Т.е. я могу иметь еще 3 попытки.

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

Спойлер

Код: Выделить всё

5.256 Start LucTremaux explore
13.958 Right front sensor detected
14.458 Location: 0x00, Heading: North
14.458 Move forward +180mm, Adjustment: -47.0
14.908 Sensing walls: ---- ----- Right
14.908 Update Map Error!  Code 08 
14.910 LucTremaux unavailable mask 0x06
14.910 Next Move: straight SkipLevel 1 lucTremaux
14.910 Location: 0x10, Heading: North

В нормальной ситуации должны были быть такие строчки:

Код: Выделить всё

3.792 Start LucTremaux explore
11.482 Left front sensor detected
11.482 TurnCount set to 1       
11.982 Location: 0x00, Heading: North
11.983 Move forward +180mm, Adjustment: -47.0
12.434 Maze Transposed
12.434 Sensing walls: ---- ----- Right
12.436 LucTremaux unavailable mask 0x06
12.436 Next Move: straight SkipLevel 1 lucTremaux
12.436 Location: 0x01, Heading: East

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

Пошел спросить судью должен ли я между попытками очищать память робота, судья сказала, что не нужно, поэтому третью попытку я сразу начал с быстрых проходов. Сначала установил режим прохода с поворотами на месте, это значит, что робот идёт, останавливается, поворачивает на месте и опять идёт прямо. Тут у меня ничего не получилось. На трассе между клетками 0x17 и 0x18 (первый ряд и 7-8 клетки) был стык на котором моего робота подкидывало, из-за чего терялась правильная позиция и робот в конце останавливался не в центре клетки, а со смещением и после поворота на месте въезжал в стену. Сделал три попытки - безрезультатно. Ну да, поленился и не успел сделать коррекцию позиции робота. От безысходности включил другой режим - с плавными поворотами. И тут была приятная неожиданность - робот прошел маршрут до финиша. Попытался манипулированием запуска через левый сенсор повысить максимальную скорость (каждая итерация увеличивала макс.скорость на 0.3 м/с) - но результат не изменился. Поэтому после трёх попыток я решил, что лучшего результата не получу и больше попыток не делал. Т.е. получается, что на этих 5 клеточках прямого хода робот не набирал заданную скорость в 1.5 м/с. (дома посчитал, что до этой скорости разогнался, если было бы 6 клеточек). Надо было всё же менять ускорение, а не скорость. Опять же, анализируя полученные данные, если бы наращивал ускорение, то при максимальной скорости 2 м/с, подняв ускорение до 6 м/с² проход трассы был бы 14 секунд. Но выше 9 м/с² ускорение поднимать нельзя - робот начинает задирать нос. Почему с плавными поворотами робот прошел, а с поворотами на месте - нет? Потому что через "стык" робот проходил на скорости всего 25 см/с, так как там был конец плавного поворота, а плавный поворот у меня выполнялся именно с такой скоростью. А при повороте на месте, после поворота робот начинал разгоняться с ускорением 2 м/с² и за 90мм (расстояние от центра клетки до края, где был стык) набирал скорость уже 60см/с и продолжал ускоряться. Есть разница.

Вообще то, эти стыки не только мне крови попортили. На фото видно, что с одной стороны даже бетонный блок поставили, чтобы придавить края так, чтобы роботы могли пройти ступеньку, которая там возникала. Конечно, поглядывал на другие роботы. Но несмотря на то что были роботы с турбинами, адекватно робот двигался только у одного человека. Когда я слышал, что он с кем-то разговаривал, мне показалось, что говорит по-польски. Так потом и оказалось. У него было два робота которые заняли первые два места, а мне досталось третье. Информационная система как-то странно не работала, показывала "Evaluation Copy" и только ранг участников. Польский робот (или роботы - сначала я не понял), никак не могли пройти один из стыков. Ступенька на стыке была больше просвета у робота. В результате его робот быстрый проход был вынужден идти по тому маршруту, по которому проходил поиск. Но и в таком режиме его робот меня опережал. А во время одной из следующих попыток удалось взять карту оптимального маршрута, ну тогда результат был около 4 секунд. Куда мне со своими 20. Результаты стали доступны через неделю и... похоже, что кроме наших роботов до финиша больше никто не добрался.

[uldemir]

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

Ещё эти 35 градусов создают проблему коррекции позиции робота. Можно было бы корректировать позицию робота при обнаружении какого-либо бокового прохода. Например, отдетектировав пропадание стены с какой-либо стороны, значит, что робот находится в 10мм от центра клетки. Но! Это в том случае, если робот находится на оси коридора. Если же робот смещен, то и смещается позиция на тангенс 35 градусов (0.7). Пытаться учитывать это смещение по ошибке центровки (cross_track_error)? А оно линейное? а не зависит ли еще и от "тангажа"? Неплохим решением этой проблемы было бы добавление еще и перпендикулрных сенсоров стены. Но у выбранного в данный момент контроллера, для этого не хватает ног.

Правда эта проблема переходит в категорию малоактуальных. Потому как соревнований Robotex в Таллине больше не будет. В конце лета они сделали на ютубе "Huge Announcement" (искать по фразе "Robotex Huge Announcement"), из которого следует, что с этого года соревнования начнут путешествовать по разным городам мира. В этом году будет в Азии, потом на ближнем востоке, затем в Африке и, наконец, в европе. И снова по-кругу. Вот на этот год планируется проводить в Сеуле. Не думаю, что туда поеду. Одно дело за 200 евро съездить в Таллин (ну чуть больше: 60 участие, 52 дорога, 115 гостиница), опозориться и вернуться, другое дело 2000 евро (предварительная прикидка расходов - одна дорога где-то 1500).

Поэтому, пока концентрируюсь на местных соревнованиях следование по линии. Нового робота так еще и не запустил. Поэтому разные идеи пробую пока на старом роботе. Одни соревнования пропустил, так как лежал с температурой. На следующие соревнования в городе Валмиера съездил, но там участников было мало. Буквально за день до соревнований объявили об ожидаемом сильном снегопаде и многие сразу отказались. Не приехала команда из Даугавпилса - мои нынешние конкуренты. Даже наш клуб отказался от автобуса. Но четверо, всё же на легковой машине приехали. Сам, большую часть дороги тащился на 50-60км/ч. Так что у меня в конкурентах оказался один студент местного техникума, которого мой робот обогнал со второй попытки (первая была DNF). Потом еще покатал робота. Так как трасса была та же, что и в прошлом году - удалось улучшить прошлогодний рекорд (8.074 ->7.874). Главная проблема была проезд роботом перекрёстка после поворота. Т.е. после поворота, когда робот еще не выровнялся на линии, подъезжает к перекрёстку под углом и как сделать алгоритм, чтобы выяснить, какой выход из перекрёстка правильный - левый или правый?

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

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

Трасса была новенькая и... она превышала по числу перекрёстков ресурсы моего робота. Мой робот расчитывался всего на 8 перекрёстков, здесь же их 12. Одно успокаивает, что мне необходимо распознавать только первые два, так как там начинается двухметровый прямой участок, где можно разогнаться. Но это не особо помогло. Разгон был какой-то вялый и результат хороший получить не удалось, так как робот в петлях начинал путаться и уходить на "второй" круг. Предположил, что виной мои "нововведения" по выбору ветви после перекрёстка - заблокировал, но не особенно помогло. Так что получил только 4 место.

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

Спойлер

Код: Выделить всё

09.480,...#....,70,-256,18000,1037
09.481,...#....,70,-256,18000,1040
09.482,...#....,70,-256,18000,1041
09.483,...##...,70,-123,18000,1042
09.484,...##...,70,-83,18000,1043
09.485,...##...,70,-40,18000,1045
09.486,...##...,70,5,18000,1046
09.487,...##...,70,49,18000,1048
09.488,...##...,70,94,18000,1049
09.489,...#####,70,729,18000,1050
09.490,...#####,70,886,18000,1052
09.491,....####,70,995,18000,1053
09.492,....####,70,1015,18000,1054
09.493,....####,70,1024,18000,1055
09.494,....####,70,1029,18000,1058
09.495,....####,70,1031,18000,1058
09.496,....####,70,1036,18000,1060
09.497,....####,70,1037,18000,1061
09.498,....####,70,1032,18000,1062
09.499,....####,70,1018,18000,1063
09.500,....#...,70,256,18000,1066
09.501,........,70,256,18000,1066
09.502,........,70,256,18000,1068
09.503,........,70,256,18000,1068

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

Спойлер

Код: Выделить всё

06.066,..#.....,35,-768,16000,729
06.068,..#.....,35,-768,16000,730
06.070,..#.....,35,-768,16000,732
06.072,..#.....,35,-768,16000,736
06.074,..#.....,35,-768,16000,737
06.076,..#.###.,35,-768,16000,739
06.078,.#######,35,371,16000,742
06.080,.#######,35,374,16000,743
06.082,.#######,35,359,16000,745
06.084,.#######,35,346,16000,748
06.086,.#######,35,323,16000,750
06.088,.####.##,35,272,16000,752
06.090,.##.....,35,-1021,16000,754
06.092,.#......,35,-1280,16000,756
06.094,........,35,2100,16000,759
06.096,........,35,2100,16000,760

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

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

Следующие соревнования в городе Вентспилс. Как и в прошлом году туда едет очень мало участников. Даже мне до туда надо пилить 4 часа. Заявлено было всего 39 роботов на все соревнования. На следование по линии 3 робота - один попал в группу для школьников, а в про-группе 2 робота, мой и местного студента. Но приехав и увидев трассу, получил ощущение "нежданчика".

Не то трасса, не то лабиринт... Выяснилось, что ехать можно по любой траектории, главное сделать один круг. Ну тут я вспомнил про фишку "выбора поворота на перекрёстке". Старт находится слева у "черной коробочки" и движение по часовой стрелке. Решил, что пусть робот первые 3 перекрёстка выбирает левую ветвь, на 4 и 5 перекрёстках правую и дальше, только левые. Запрограммировал, запустил - робот свернул вправо на 3 перекрёстке. Хм... начал думать, может робот какой поворот воспринял за перекрёсток? расставил участки блокирующие распознование перекрёстков. Запустил, снова свернул на 3 перекрёстке. Начал думать, может, я не помню, как у меня сделана нумерация перекрёстков? сдвинул, чтобы правые повороты были 5 и 6. Проехал прямо и 3 перекрёсток, и 4-й. Дрыгался-дрыгался, понял, что-то не того и решил скатиться на простой вариант - пусть все перекрёстки идёт налево. Маршрут будет чуть длиннее, но надёжнее. Начались соревнования. Робот студента застрял в "петле" -начал ходить по кругу, но судья сказал - это ничего, если он за 3 минуты (сколько может длиться заезд) выйдет из петли и доедет до конца - такой результат засчитывается. Ну я побежал своему роботу устанавливать время работы 180 секунд, так как мой робот тоже может застрять в петле. проблема в том, что робот может определить Y-образный перекрёсток, а вот Т-образный он не опознаёт и повернёт туда, куда будет последняя ошибка в последнем считывании где он еще видит линию - лоторея. Робот студента на 3 или 4 круге всё же вырвался из петли и добрался до финиша. Потом я запустил своего. Мне повезло - робот четко прошел по внешней траектории маршрута за 7 с половиной секунд (почти в два раза быстрее студента). Потом студент делал свои попытки, но результат не улучшился. Когда его робот исчерпал попытки, судья спросил, буду ли я еще пытаться? Сначала сказал, что нет смысла - у мего робота и так лучше результат, но так как вокруг были зрители и они хотели зрелищ, задал роботу побольше скорость и запустил. Результат был двойственный - во-первых таймерные ворота не сработали, т.е. результат не может быть зафиксирован, а во-вторых, робот на одном из перекрёстков свернул не туда и поехал назад - чистый DNF. Тогда я сказал, что хватит. А потом лог-файл этого неудачного заезда дома анализировал. И выяснил, почему робот сворачивал "не туда".

Спойлер

Код: Выделить всё

47.D01,....#...,36,256,13510,652
47.D02,...##...,36,38,13170,655
47.D03,...##...,36,-111,13170,656
47.D04,...#....,36,-256,13340,658
47.D05,..##....,36,-393,13170,660
47.D06,..##....,36,-527,13170,663
47.D07,..##....,36,-639,13170,664
47.D08,..#.....,36,-768,13170,666
47.D09,.##.....,36,-903,13170,667
47.D10,.###....,36,-851,13170,669
47.D11,.####...,36,-704,13170,672
47.D12,.####...,36,-599,13510,673
47.D13,#####...,36,-681,13170,676
47.D14,######..,36,-672,13340,679
47.D15,######..,36,-575,13680,680
47.D16,######..,36,-543,13170,682
47.D17,#######.,36,-428,13170,684
47.D18,##.####.,36,-1650,13000,685
47.D19,#...###.,42,-1792,13000,0
47.D20,#...####,42,-1792,13000,2
47.D21,#....###,42,-1792,13000,4
47.D22,#....###,42,-1792,13000,5
47.D23,#....###,42,-1792,13000,8
47.D24,#.....##,42,-1792,13000,10
47.D25,#.....##,42,-1792,13000,12
47.D26,......##,42,1722,13000,14
47.D27,.......#,42,1792,13000,15
47.D28,.......#,42,1792,13000,18
47.D29,........,42,2100,13000,19
47.D30,........,42,2100,13000,21
47.D31,........,42,2100,13000,23
47.D32,........,42,2100,13000,25
47.D33,........,42,2100,13000,27

Вот это место, где робот должен был поехать прямо, выбрав левую ветвь, а поехал направо. Извиняюсь, что метки времени невменяемые, это из-за того, что я робота остановил выключением питания и робот не прописал в журнале его размер и частоту кадров, поэтому репорт выдал странные метки, но я вручную прописал, чтобы указать на ключевые моменты. Так вот перекрёсток был отдетектирован на метке "47.D18". Можно заметить, что сменился номер участка с 36 на 42. И робот выбрал правильно левую ветвь, так как значение ошибки отрицательное, несмотря на то, что для правой ветви значение ошибки было бы ближе к нулю. И робот продолжал двигаться влево, но на позиции "47.D26" левая ветвь пропала с поля зрения, но правая еще была видна. Ну и робот в результате подхватил ту линию, что видна и дальше следовал по ней. Надо, наверное, сделать более агрессивную фильтрацию линий.

Но на этих соревнованиях хотел попробовать поучаствовать в соревнованиях по драгрейсу. Трасса ничего особенного не представляет - просто две прямые линии, для двух участников. На фото можно разглядеть, на первом плане трасса для следования по линии для Лего роботов и школьников, дальше трасса для фолкрейса и за дверью в коридоре трасса для драгрейса. На драгрейс хотел поставить робота на гусеничном ходу, а то зря его что ли делал? По правилам, роботы запускаются по двое. Заезд выигрывает тот робот который первый остановится в финишной зоне. Т.е. линия заканчивается поперечной широкой линией и робот должен остановиться не далее чем в 60 см за ней. Если пролетел мимо - проиграл. Раунд длится до двух побед одного из участников. Как там дальше определяется победитель не узнавал. Всего на эти соревнования заявку дали 3 робота: один школьник (тот же что и в следовании по линии), из рижского института транспорта и связи (сам руководитель запускал) и мой. В правилах указано: длина трассы 10 метров. Но старт находился в метре от начала линии, так что я робота запрограммировал ехать 8.7 метров и он точно останавливался посередине финишной зоны. Но возникала проблема у этого робота. Как уже писал, питание у него 4 NiMH пальчиковых элемента, напряжение которого бустером поднимается до 9 вольт и это напряжение подаётся на моторы. И при разгоне потребляемый ток от батарей вырастает настолько, что напряжение просаживается. Я уж и навесил на него электролитов - ничего не помогает. Поэтому, чтобы робот номально двигался, пришлось уменьшить ускорение разгона до 2 м/с². Потому как если напряжение падает, гаснут светодиоды подсветки линии и программа "детектирует" финишную черту и робот начинает тормозить.

Да, я извлёк урок с соревнований роботекса, что надо роботу не менять максимальную скорость движения, а просто её выставить по максимуму и манипулировать ускорением. Максимальная скорость при тесте была зафиксирована при 75% ШИМ 2.2м/с, поэтому выставил 2.5м/с и, похоже, робот мог двигаться с такой скоростью.

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

Поэтому сейчас нарисовал новую схему, развёл плату и послал заказ на изготовление. Новая структура питания робота будет такая: 4 LiPo элемента 14500 дадут макс 4.2*4 = 16.8в. Моторы буду использовать, как и раньше, шестивольтовые и для их питания эти 16 вольт буду понижать до 9 вольт импульсным преобразователем. Так же импульсным преобразователем из этих 16 вольт буду делать 5 вольт, а из них уже LDO будет делать 3.3в для питания микроконтроллера и всей периферии.

[uldemir]

Sauron: Build me an army...

В общем, решил себе построить армию роботов. Пока состоящую из двух роботов. Это потребовалось, так как у нас появился новый вид соревнований. Называется эстафета. Два робота должны перенести эстафетную палочку от старта до финиша, передав её от одного робота другому. Как примерно это должно выглядеть, можно посмотреть в этом видео: https://youtu.be/47yQWKFPC98?si=OqWWgfdbwumVsDZV.

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


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

Таким образом встали две задачи: собрать ещё одного робота и придумать "клешню". С роботом проблемы нет - платы есть, трафарет есть, надо только докупить недостающие детали. Правда, плату сенсоров решил сделать новую - с нагрузкой фототранзисторов в эмиттерах, а не коллекторах. Нарисовал платы и послал заказ на изготовление. С клешнёй было сложнее. Сначала вспомнил, что для шасси ROMI был манипулятор - пошел смотреть. Но он оказался маленьким - хорошо, если он сможет взять шарик для настольного тенниса. Эстафетная палочка крупнее - 7-8см в диаметре. Поискал что предлагает али-экспресс - ничего интересного. Понял, что придётся делать самому. Поэтому сделал чертёжик в CAD и напечатал на 3д-принтере.

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

Вот только, как сервами управлять? Свободных выводов у микроконтроллера давно уже нет. На али-экспрессе нашел модули для управления 16-ю сервами по i2c. Но с ними непонятно. Как оно согласуется с трёхвольтовой логикой и 5-вольтовыми сервами. Да и слишком оно крупное для 2 серв. Поэтому решил пожертвовать 2 боковыми сенсорами линии - пусть будет не 8 фототранзисторов, а 6. А чтобы не переделывать программу, в АЦП сконфигурировал, чтобы вместо крайнего сенсора, опрашивался соседний. Примерно так: "2 2 3 4 5 6 7 7". Высвободил один таймер и применил его на генерацию ШИМ для серв. Осталось согласовать уровни - взял драйвер MIC4427 и он с этой задачей справился.

Пока всё это строил, прошли соревнования в Вентспилсе, где этот робот участвовал в драгрейсе и указал на проблему с питанием. Когда моторы разгонялись, питание просаживалось. А если питание просело, то не зажигаются светодиоды сенсора линии. Они по два соединены последовательно и на каждую пару стоит ccr (constant current regulator) на 10ма и на котором должно падать минимум 1.8в. Т.е. если напряжение проседает ниже чем 1.2+1.2+1.8=4.2в светодиоды не светят с номинальной яркостью. И сенсор, соответственно, линию толком не видит. Пробовал на питание навесить электролитических конденсаторов - не помогло. Тогда, повесил конденсаторы на светодиоды и отвязал от преобразователя моторов диодом. Повесил два конденсатора по 820мкФ - вроде недолгие просадки питания должен вытянуть. Точно так же и у нового робота порезал дорожку и впаял диод на всякий случай. Конденсаторов под рукой не было, поэтому пока оставил так.

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

Код: Выделить всё

get_fram_id  show_time    vl6180_setAddr            bonding_count
bonding_data bonding_list bonding_handle            erase_bonding
erase_all_bondings        connect_to_slave          bt_write
send_passkey servo0       servo1       list         data
help         maze_init    words

Zumo>bonding_list
0 B4:3A:31:04:73:4E Public 16 (0x3) Authenticated Secure Connections pairing with encryption using a 128-bit strength encryption key
1 CC:73:15:1C:2D:0E Public 16 (0x3) Authenticated Secure Connections pairing with encryption using a 128-bit strength encryption key
2 2C:6D:C1:98:10:BA Public 16 (0x3) Authenticated Secure Connections pairing with encryption using a 128-bit strength encryption key
3 18:3B:D2:B1:F8:3B Public 16 (0x2) Authenticated pairing with encryption
4 B4:3A:31:04:77:8F Public 16 (0x3) Authenticated Secure Connections pairing with encryption using a 128-bit strength encryption key

Zumo>bonding_count hex . sp .
5 1F
Zumo>help bonding_count
Get BT bonded device count, mask and put on stack
 Usage example: bonding_count . sp .
 shows <count> <mask>

Тем временем, пришли платы для нового фотосенсора. Собрал и начал тестировать. Конечно если солнце прямо светит - робот ничего не видит. Но если солнце чуть прикрыто облаком - робот уже может разглядеть линию. Это при сопротивлении нагрузочных резисторов 4.7кΩ и опоре 2.42в. Это уже на новом роботе. Когда его собирал нашел очередную плюху: оказывается в выключателе питания применил неправильный транзистор с Vgs th = 4 вольта, а не logic level. Взял из коробочки с транзисторами, который мне показался подходящим, а параметры не проверил. Поэтому он давал такую просадку напряжения. Поискал и купил другой транзистор - si4630 - 3mΩ logic level. Стоит, конечно, 3 евро штука! Поэтому на новом роботе не ставил параллельно ему механический выключатель (на плате предусмотрено место). Попробовал его погонять в режиме драгрейса без линии - задрал порог, чтобы всё вокруг казалось белым, задал дистанцию 2 метра и пускал с разными ускорениями. Заметил одну неприятную штуку. Ускорение разгона и торможения задаётся одинаковое, но при торможении робот поднимал зад, а при разгоне, нос не поднимался. Хотя у робота зад тяжелее - батарейки смещены назад. Это значит, что разгон не происходил с заданным ускорением. Или моторы не тянут, или не тянут, потому что напряжение на выходе бустера просаживается. А его на ходу не могу контролировать.

Потихоньку набросал черновик программы. Программу представлял так, что она будет "управляться" таблицей расстояний. Первое расстояние - сколько должен проехать робот со стартовой позиции до хватания палочки. Так как второй робот манипулятор имеет сзади - у него расстояние отрицательное. Второе расстояние сколько робот должен проехать "вслепую" после того как взял эстафетную палочку. Это особенно актуально для второго робота, так как ему нужно пересечь жёлтую площадку и чтобы чёрная кайма вокруг этой площадки не сбивала робота. Вот в чем прелесть этих гусеничных роботов, в том, что прямо они идут довольно точно, как поставил - так и идут. Ну а дальше должны быть участки где робот может разгоняться и тормозить перед поворотом. Поворот робот должен проходить на небольшой скорости (пока не знаю какой). После завершения поворота снова разгон на следующую длину. Ну и последний участок дефинируется нулевой длиной - значит едем на небольшой скорости и ждём конца линии. Следующая длина - коррекция позиции с точки где обнаружен конец линии и позиция робота, чтобы положить токен на пол. Для первого это значит чуть отъехать назад, а второму, наоборот, проехать вперёд, чтобы оказаться на финишном поле. Для "обмена данными" решил пока не вводить специальный БТ сервис и характеристику. Фактически ведущий робот использует характеристику старт/стоп - т.е. просто удалённо нажимает второму роботу кнопку "пуск". Еще собирался сделать, чтобы через характеристику устанавливать номер программы, но решил не делать, чтобы во время отладки первого робота, второму поставить какую безобидную программу, чтобы он никуда не убежал. Первому роботу требуется наличие второго, так как если нет соединения - программа не выполняется. У меня же нет никакой индикации, что соединение установлено. Поэтому по нажатию кнопки старт делается запрос на соединение, и если по истечении таймаута (после нажатия кнопки робот должен стоять на месте 5 секунд, чтобы участники успели освободить поле) если есть соединение - побежали, если нет - выключаемся. Вообще, коммуникационная часть была сделана максимально тупо - соединение без анализа принятых адвертисментов, а прямо по заранее прошитому адресу и не делался разбор сервисов и поиск хендлов характеристик, так как прошивки в обоих роботах одинаковые и хендлы у обоих совпадают:

Код: Выделить всё

              if (data.length[step] < 0.0) {
                  start(&forward, data.length[step], data.runspeed, 0.0f, data.acceleration);
#if VARIANT == GREEN
                  write_bt_characteristic(gattdb_start_stop, 1);
#endif
                  release_stage = 0;
              }
              state = wait_for_stop;

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

На соревнованиях увидев трассу, сразу её промерил и сохранил чертёж себе для истории. Потом взял первого робота и начал калибровать сенсоры линии. Затем стал тестировать, какая скорость допустима, чтобы робот мог пройти поворот. Повороты, похоже были с радиусом 15см. Поначалу была установлена скорость 25см/с - поворот прошел без проблем. Увеличил до 50 см/с - прошел. 1 м/с - улетел. В общем, на 80 см/с поворот брал, но всё равно уменьшил до 50 см/с. Участки с разгоном не делал, так как детектирование что поворот выполнен или нет - не оттестировал, поэтому всю трассу робот проходил в ожидании конца линии.

Теперь берёмся за новый робот. Проверяем сенсоры - вроде видят нормально. запускаю по линии - на повороте поехал прямо. Ай, оказывается забыл в конфигурации прописать коэффициенты Steering_KP, Steering_KD (коэффициенты PID удержания на линии - пропорциональный и дифференциальный). Запускаю, на повороте вроде дёрнулся, но не повернул. Что за... Прыгал-прыгал, сравнивал конфигурации роботов - почему один идёт, а второй нет. Пока не пришло прозрение - у нового робота нет конденсаторов на питании светодиодов сенсора линии. Я же тогда не припаял. Пока робот стоит - всё в порядке, а если робот разгоняется или поворачивает - потребление тока вырастает, напряжение проседает, светодиоды не светят и робот линию просто не видит. Хорошо, что старому роботу напаял два конденсатора, решил, пусть он поделится со вторым роботом. Побежал искать паяльник, чтобы перепаять конденсатор (можно заметить, что на фотке робота у меня на столе - два конденсатора, а на фотке робота на трассе - уже только один). После припаивания конденсатора, робот стал нормально себя вести. Тогда прикрутил обоим роботам платформу с клешнёй - до этого она быля снята, чтобы можно было подключить дисплей и оперативнее менять параметы. И попробовал уже сделать заезд "в комплексе". Выяснилось, что "хватка" у роботов ослабевает и палочка, бывает, падает. Но самое расстройство было в том, что второй робот по приезду на финиш никак не хотел поставить её на пол и раскрыть свои клешни. Смотрел, смотрел программу - не вижу ошибки. Причем иногда он открывает, иногда нет. И тут приходит понимание - напряжение! Открываю батарейный отсек, меняю батарейки на свежие - всё отрабатывает как по часам. Так и оставили. Правда, пока разбирались, второму роботу снизили скорость по линии до 40 см/с и интервал между командами сжать клешню и поднять - увеличил до секунды, но решили не менять, пусть один заезд сделают до финиша, а потом, если нужно будет - поднимем скорость.

Вот график напряжения питания второго робота в первые 6 с половиной секунд (между 0.67 и 2.67 - робот стоит хватая эстафетную палочку) - на большее памяти не хватает. Красная линия показывает номер этапа: 1 - едем назад, 2 - едем вперед вслепую, 3 - этапа нет, он для разгона-торможения, 4 - едем медленно в ожидании конца линии. Вот в тех местах четвёртого этапа, где видны просадки напряжения - робот поворачивает, идёт по дуге.

Пока готовились, конкурентов что-то не видели. На соревнование были подавши заявку 4 команды, но техинспекцию проходили всего 2 команды, так что второе место гарантировано, если роботы хоть чуть-чуть смогут двигаться. Так и получилось. Пришел судья, мы поставили роботов на трассу, запустили и роботы чистенько отработали. Время было 35 секунд. Надо ждать вторую команду, какой она покажет результат. Но пока ничего не происходило, решили сходить в столовую пообедать. Возвращаемся, оказалось, пока нас не было, вторая команда тоже "проехала". Смотрю на листок судьи, а там 24 секунды! Но, оказалось, это только время первого участка, палочку передать им не удалось. Так что мы со своими 35 секундами заняли предпоследнее (из двух) место.


Но факт тот, что с низковольтным питанием - не жизнь! Сенсоры не работают, сервы тоже. уже писал, что послал заказ на платы нового робота, который будет питаться от 4 LiPo элементов в корпусе 14500. Скажу, что заказ уже получил и собрал. Но возникли проблемы. Во-первых эти 14500 элементы не контачат в батарейном отсеке, а во вторых у меня сгорает преобразователь на 5 вольт и следом вышибает переключатель питания TPS2113A. Причина не понятна. Когда придут детали на замену сгоревшим - продолжу выяснять.

[uldemir]

Собрал 3 платы для "высоковольтных" роботов и начал их запускать. Обычно первая проверка, подача на USB разъём 5в от лабораторного БП с ограничением тока. Если КЗ не наблюдается - подключаем к компьютеру и проверяем, что USB-CDC опознался. Теоретически, уже можно в микроконтроллер залить программу. Затем проверял автономное питание. На клеммы для батарей подключил лабораторный БП, установил напряжение 16в, ограничение - 1А. Подаю питание и проверяю напряжения на выходе преобразователей - 9в для моторов и 5в для логики и серв. Вроде, есть. Теперь надо бы проверить, как работает система включения/выключения питания (при подаче питания схема установилатсь во включенние состояние). Давлю кнопку - выключилось. Давлю снова... опа! у БП включается ограничение тока и напряжение падает до 3.4вольта. И больше не работает. Начинаю прозванивать омметром - на выходе преобразователя 5в вижу КЗ.

Спойлер

Вот схема питания робота. Транзисторы VT1-VT4 - выключатель питания, образуют Latching circuit с коммутирующим транзистором. Далее эти 16в с батареи идут на 2 преобразователя: на DA2 делающего 9в для моторов и DA3 дающего 5в. Эти пять вольт через коммутатор DA4 идут на простой LDO LM1117 DA5, который из 5в делает 3.3в которыми питается микроконтроллер и его периферия. DD11 - одногейтовый коммутатор типа 4053 - 74LVC1G53DP. Используется для того, чтобы контролировать напряжение батареи и мотора. В прошлой версии контролировал только батарею, а тут подумал, что у меня в список сканирования АЦП помимо фотодатчиков включено еще напряжение батареи и резистивная матрица кнопок. А так как фотодатчики сканируются 2 раза: без подсветки и с подсветкой, то получалось, что напряжение батареи и кнопки сканировались тоже два раза. И вот решил поставить мультиплексор на напряжение - теперь контролирую не одно, а два. Кнопки пока не под мультиплексором. Трудно придумать что бы еще добавить, тем более, если для всех остальных используется внутренняя опора, то для кнопок - Vdd.

Кстати, с этим мультиплексором на плате накосячил. Посмотрел в даташите, что корпус TSOP8, ну и взял в библиотеке ref-packages такой корпус. А оказалось, что в библиотеке корпус широкий, а у этой микросхемы - узкий. Но повезло, что выводы 2-4 сидят на массе, а от первого идёт дорожка под корпус к переходному отверстию - соскрёб маску и припаял: 5-8 выводы на родные пады, а 1-4 на то место где маску соскрёб. Выкрутился.

Так вот, возникло подозрение, что при выключении пробивает TPS563201, после чего, она пропускает 16 вольт дальше на TPS2113, которая от этого напряжения тоже улетает (возможно, в момент следующего включения). В общем, за пару дней у меня улетели все TPS563201 (был купивши 5 штук) и TPS2113 (3 штуки), потом нашел у себя еще 2 штуки TPS563200. Пришлось делать заказ на следующий комплект. Во время последнего "сжигания", попытался даже осциллографом глянуть, что там на шине питания происходит. К тому времени все 2113 были убиты, так что преобразователь был изолирован от нагрузки. Нагрузкой был резистор на 24Ω со светодиодом для индикации. Выставил на БП 14.7в и попробовал включать-выключать - вроде не сгорает. Тогда ткнулся осциллографом, собирался настроить порог синхронизации, но при первом же выключении-включении - опять пробило. Синхронизации не было, но на экране заметил какой-то всплеск, но оценить его величину не могу. Есть, подозрение, что виноват БП, что у него при снятии нагрузки "подскакивает" напряжение. И много не надо. К сожалению у TPS563201 абсолютный максимум всего 19 вольт. Т.е. запас меньше 2.5 вольт. Потом стал думать, что если виноват БП то, может, при питании от батарей такой проблемы не будет?

Хорошо, будем вставлять батарейки. Они как раз и пришли через недельку после описанных событий. Заряжаю, вставляю в батарейный отсек, измеряю напряжение - 0 вольт. Все показывают 0 вольт. Вытаскиваю и измеряю на самой батарейке - 4.2в. Начинаю внимательно смотреть, а они плюсовым выводом не касаются контакта. Ну да, купил аккамуляторы у которых нет выступа на плюсовом контакте. Думал-думал, как выйти из этой ситуации и решил модифицировать контактики в батарейном отсеке. При помощи пуансона и молотка выдавил углублённую часть контакта. Вот фото, что у меня получилось - по середине, оригинальный, еще не модифицированный контакт.


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

Правда, был подстраховавшись. Помимо нового комплекта TPS563201 заказал и готовые импульсные стабилизаторы n7805 - на случай, если и от батарей будет гореть, то снесу все детали и на проводках и клее поставлю этот "запасной" вариант.

Когда увидел, что преобразователи работают нормально, решил собрать одного робота. Было у меня свободное шасси, моторы и плата сенсоров. Когда платы тестировал с питанием, программа загружена еще не была, и заметил, что у одной платы не зажигается светодиод означающий включение драйвера двигателя. Решил начать именно с этой платы. Стал разбираться со светодиодом. Нашел, что сигнал sleep драйвера двигателя и включения светодиодов сенсора линии соединены вместе. Похоже, снова BGM240 припаялся не удачно. Отпаивал-припаивал - коротыша нет, а светодиод не зажигается. Оказалось, была еще капелька олова закорачивающая этот сигнал на массу под микросхемой драйвера двигателя. Устранил. Припаял моторы - не крутятся. Начал дальше искать - теперь уж точно BGM240 - оба сигнала ШИМ двигателей не контачат. Устранил. Дальше всё пошло как по маслу.

Теперь стоит вопрос где взять шасси, моторы и сенсоры для второго робота. Единственный вариант - разобрать одного из уже сделанных. Решил, что буду разбирать тот, что с "новыми" сенсорами линии, чтобы "высоковольтные" роботы были с одинаковыми сенсорами (да и на плате нагрузочные резисторы я уже накидал 4.7кΩ, для старого варианта надо 47кΩ). Взял одну из плат, припаял двигатели. Делаю тест - двигатели идут страшными рывками. Начал разбираться - проблема в измерении напряжения батареи и напряжения поступающего на моторы. Программа видит низкое напряжение, даёт 100% ШИМ, потом контроллер видит, что по таходатчикам колесо "убежало" вперед, тормозит, итд. Подумал, что опять придётся возиться с пайкой BGM240 и решил собирать другую плату. Собрал, но она как-то странно себя вела, так что и не понять причину. Искал-искал, и понял, что легче разобраться с предыдущей платой. Тем более, что подключив её и проведя тесты, заметил, что BGM240 нормально контачит - когда тестером в режиме проверки диодов тыкался в выход мультиплексора "4053", значения "подскакивали". Но при тыкании на входы 4053 - нет. Оказалось, что там где-то не контакт. Отпаял, зачистил маску побольше (это тот кристалл, которому пады не соответствуют) припаял по-новой, напряжение начал показывать нормально. Осталось, собрать. Вот только был уже вечер пятницы перед субботними соревнованиями. Ну ничего, просидел до позднего вечера и собрал. Так что поехал на соревнования с 2 "высоковольтными" роботами. Но как запасной вариант был - использовать одного низковольтного, если что не пойдёт.

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

Главное внимание было эстафете. Трасса была сложнее. Как сказал судья: "похожая на ту, что была в видео". Но на этой трассе было одно заковыристое место для моего робота, и еще одно для других роботов. Для моего робота (ну и других) проблему создавал один очень крутой поворот. Мой робот его проходил, но так как он выскакивал на белое поле - считал, что конец линии и выполнял завершающую процедуру. Вообще-то у меня было предусмотрено, но тот кусок был закомментирован, что конец линии считается только если линия пропала, когда была по середине сенсоров, а не с краю, т.е. чтобы потеря линии на повороте не считалась бы за конец трассы. Пока думал, влючить эту фишку или нет, случайно был ляпнувши, что "вообще-то трасса не соответсвует правилам соревнований". Потому как было указано, что минимальный диаметр поворота 10см, а там даже эстафетная палочка диаметром 7см в поворот не вписывается. Другие тут же отметили, что и минимальное расстояние между соседними линиями не соблюдено и из-за этого на повороте подхватывают неправильную линию. Ну и устроили "революцию". Вызвали судью, высказали претензию и для удовлетворения наших запросов постелили запасную трассу, такую же как была на предыдущих соревнованиях.

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


Это ищется по ключевому слову "mantis gripper". У второго робота клешня была попроще, но тоже на шестерёнках, а не на проволочках, как у меня. Правда, он палочку от пола не поднимал - только одна серва. Хотя проволочки проволочками, а так как теперь у меня питание мощное, решил, что полностью сжимать клешни для захвата палочки не следует - может быть излишне повышенное потребление тока. Поэтому, ввёл конфигурационные параметры для позиций открыть/закрыть и подбирал позицию, при которой палочка схвачена достаточно хорошо, но не слишком крепко. Во всяком случае, в этот раз случая, чтобы робот уронил палочку не было.

На соревновании запустил робота на небольшой скорости 50 см/с, прошел за 25 секунд. Судья думал что никто не переплюнет. Но, я опасался, так как при подготовке видел, как ходят другие роботы. Так и получилось, что лего робот нашего одноклубника (тоже из PRK) прошел за 21 секунду. Ну что сказать, он собаку съел на лего лайнфоловерах (даже на соревнованиях Robotex призовые места получал) и ехал по "родной" трассе. Попробовал увеличить скорость до 70 см/с - результат улучшился всего на секунду. При следующем увеличении скорости не вписался в поворот и трасса была выполнена всего на 75%. Так что второй. Второй "не лего" робот занял третье место. Вот не спрашивал как на лего роботах делалась передача палочки, а автор этого робота поначалу хотел тоже организовать "передачу информации", но по инфракрасному каналу. Но что-то не получалось, поэтому на соревновании сделал просто таймер - второй робот просто ждал указанное время и начинал двигаться. В первом и во втором заезде синхронизация не получилась, второй робот поехал слишком рано, а в третьем заезде всё получилось как надо. Из остальных команд только еще одна смогла выполнить трассу, но время было полторы минуты.

А у меня с блютусом получилось не очень хорошо. Побаивался, что может быть проблема с "радиообстановкой". Так и оказалось, роботы не успевали соединиться друг с другом за 5 секунд. Приходилось по 3 раза нажимать кнопку "старт", пока робот начинал двигаться. Теперь, изменил программу, так, чтобы по истечении 5 сек, робот проверял наличие соединения и если его нет - просто ждал его появления и тогда бежал, а не отменял задачу совсем. Потому что в этих соревнованиях точность этих "5 секунд" не обязательна (в отличии от драгрейса). Ну постоит на старте 10-15 секунд...

После соревнований решил посмотреть, работает ли фишка с разгоном на прямой и детектированием поворотов. Оказалось, что нет. Вот график начала заезда.

Красная линия "stage" показывает номер "этапа": 1 - выход на позицию для забирания токена, 2 - езда "вслепую" (игнорируются ошибки смещения), 3 - разгон-торможение на прямом участке, детектирование поворота, снова разгон-торможение и т.д. Видно, что робот разогнался до 1 м/с затем сбавил скорость до 0.5 м/с и ждёт поворот. И ни первый поворот на 90°, ни второй на 180° он не опознал. Опознавание сделал так, что если ошибка становится выше некоего порога, взводится триггер, а когда ошибка уменьшается ниже некоего порога - считаем поворот завершенным и можно снова разгоняться. По данным предыдущих соревнований порог был поставлен "14", но в этот раз ошибка достигла только 9.7, поэтому триггер не сработал. Дело в том, что на величину ошибки влияет скорость робота, радиус поворота и... коэффициенты PID. Конкретно, на предыдущих соревнованиях Steering_KP был 0.04, а на этих поставил 0.05. Можно было бы "подогнать" пороги, но это на этой трассе - тут все повороты с одинаковым радиусом, а если другая трасса? В общем, стоит вопрос, как распознать поворот. На профайлер надежды нет - он рапортует 0°, так как steering для него это просто "выравнивание". Снимать информацию с таходатчиков и делать расчеты параллельно профайлеру? Но с другой стороны, все эти коррекции подчиняются переменной g_steering_adjustment (на графике названа steering - сиреневого цвета) и там особо ничего не видно (пока из-за порядка величин - они очень маленькие, если не считать всплесков из-за дифференциальной составляющей). Надо еще думать.

Можно бы напрячь под это дело гироскоп, но пока не знаю как с ним справиться. Когда рисовал плату хотел туда поставить такой же гироскоп как и на Pololu роботах LSM6D33. Это чтобы в случае чего воспользоваться ихней библиотекой. Но на тот момент их в продаже уже не было и напаял замену, что предложил DigiKey LSM6DSR. Но библиотека её не признаёт, так как значение считываемое из регистра WHO_AM_I ожидается 0x69, а LSM6DSR выдаёт 0x6B. И вот не знаю, насколько они "совместимы" и можно ли просто подменить идентификационный код.

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

Кстати, про "всплески". Они возникают из-за того что передаточная характеристика смещение от линии/значение ошибки - ступенчатая. "Пропорциональность" сразу не делал, так как решение от предыдущего робота не годится. Все данные здесь верх ногами. Там было: чем больше значение АЦП - тем темнее, а здесь, наоборот, светлее. Но теперь решил этим заняться. Понятно, что чтобы считать "чёрную пропорциональность" значения АЦП надо из чего-то вычесть. Пробовал от 4095 (макс. значение), но отношение получалось не очень внятным, поэтому, решил вычитать от значения порога (граница между черным и белым). У моего робота это 350-400. То что значения для белого поля при этом получатся отрицательные - не волнует, так как в расчетах участвуют только те сенсоры, которые над чёрным полем.

Попутно, так как этим занимался солнечным утром, потестировал, как распознаётся линия при засветке солнцем. И заметил очень интересную вещь:

Код: Выделить всё

60501,4095,4895, 4095,4895, 4095,4895, 1555,1762, 788,1002, 4095,4895, 4095,4895, 4095,4895
60531,4095,4895, 4095,4895, 4095,4895, 1556,1765, 793,1007, 4095,4895, 4095,4895, 4095,4895
60563,4095,4895, 4095,4895, 4095,4895, 1561,1767, 798,1012, 4095,4895, 4095,4895, 4095,4895
60593,4095,4895, 4095,4895, 4095,4895, 1561,1766, 800,1014, 4095,4895, 4095,4895, 4095,4895
60623,4095,4895, 4095,4895, 4095,4895, 1563,1767, 803,1016, 4095,4895, 4095,4895, 4095,4895
60653,4095,4895, 4095,4895, 4095,4895, 1567,1769, 808,1020, 4095,4895, 4095,4895, 4095,4895
60683,4095,4895, 4095,4895, 4095,4895, 1570,1774, 812,1025, 4095,4895, 4095,4895, 4095,4895
60713,4095,4895, 4095,4895, 4095,4895, 1578,1778, 819,1032, 4095,4895, 4095,4895, 4095,4895

Первый столбец время, а дальше сенсоры по парам: темновой и светловой отсчеты. Так вот можно заметить, что помимо двух центральных сенсоров, остальные находятся в насыщении - 4095, т.е. те что на белом поле уже "ослепли", а центральные два над черным полем, еще дают вменяемые показания. Поэтому сделал небольшой хак: если освещенный сенсор даёт значение близкое 4095, к нему прибавляется двойной порог (2 * 400 = 800), чтобы разница была однозначно выше порога и поле считалось бы белым (значения 4895 в распечатке). Поэтому пока черное поле не зашло в насыщение - робот черную линию еще способен распознать, несмотря на то, что "белые" сенсоры уже ослепли. Так удалось еще расширить рабочий диапазон сенсоров линии.

Возникла еще одна заковыка. Когда еще тестировал сенсоры на "низковольтном" роботе и строил графики в экселе, линии выглядели несколько ровнее. А у этого робота выглядят "пушистыми". Ну да, преобразователь 5в несколько шумный, а именно его я завёл на коллекторы фототранзисторов. Поэтому напаял на разъём 78L05, пусть питается через линейный стабилизатор. А вот что подать на вход этого стабилизатора? С батарей нельзя - слишком большая будет рассеиваемая мощность. Там помимо фототранзисторов еще 10ма ест белый светодиод для цветового сенсора и 4 по 10ма светодиоды подсветки фототранзисторов (правда, короткими импульсами). Поэтому соединил с выходом 9в стабилизатора. Линии стали гораздо глаже. Но в схеме был предусмотревши перемычку, которая выключает этот преобразователь, если драйвер двигателя переводится в режим сна. Ну, значит, не придётся воспользоваться этой перемычкой.

Спойлер