RSLK от TI (Robotic System Learning Kit)

uldemir

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

На лабиринт, думаю, пойдёт робот на EFM32GG12, если, конечно, не успею к тому времени изготовить и настроить робота на шасси Zumo. Вот с linefollower не знаю пока что делать - пускать старого или чуть по-новее. Здесь, ведь такая вещь, что в этих соревнованиях на одно соревнование один участник имеет право выставить только одного робота. Так что я не могу представить на лабиринт два робота: на MSP432 и на EFM32. Хотя глянул на правила соревнований - этого пункта больше не нахожу.

Zumo-робот стоит в ожидании. Основную плату я ему уже заказал, её изготовили и уже выслали. Детали под неё я тоже подобрал и заказал. Вот только Farnell что-то тормозит. Заказ уже стоит больше недели и... никакого движения. А когда-то я радовался, что сегодня заказал - на следующий день вечером уже получил. На маузере было бы быстрее. Вот только я себе заказал винтики (метрические) для изготовлния стен лабиринта, которых на маузере нет. Будет смешно, если из китая платы придут быстрее фарнеловских деталей.

Но пока нет плат и деталей, подумал, что нужно уже подготавливать фирмварь, что буду грузить в BGM240. Думал-думал и придумал, что так как референс мануал на EFR32bg24 и EFR32mg24 один и тот же, то можно начать прототипировать на платке BRD2601 с EFR32MG24 на борту. Как обычно, сначала сделал кнопочки и светодиодики, затем UART. Передача в компьютер идёт нормально. А вот как проверить обратное направление? Хм, можно подключить командную строку, чтобы с роботом поговорить как компьютер с компьютером. Но, командная строка потянула за собой кучу других модулей. Так что пришлось разбираться с таймерами, АЦП, SPI и I²C. С таймерами всё здорово - у прескалера появилась возможность указать оюбой коэффициент деления, а не только степени двойки. Так что даже тактовая частота 39 МГц проблем не создала. А вот в модуле profiler у меня случились сразу две проблемы. Как выяснилось, у этого кристалла нет BITBAND. С регистрами проблем нет - почти все регистры имеют помимо себя еще толпу _CLR, _SET, _TGL. А вот в ОЗУ так не залезешь. Пришлось один кусок, где программа проверяет биты в байте на непрерывность переписать с помощью масок. Но самый удар был, когда я захотел подцепить еще и блютус... В общем, прерывание PendSV, которое использует у меня профайлер, оказалось требуется блютус стеку. Так что мне нужно придумать как иначе запускать итерации профайлера.
Помимо этого обнаружил разницу в LE_Timer - нужно было добавить опрос бита синхронизации перед записью в некоторые регистры. И... счетчик в этом таймере стал на 8 бит длиннее. В результате, тестовая задержка в 2 с половиной секунды удлиннилась до десятка минут. Еще, особенности доступа к регистрам мне спутали планы у АЦП. Оно у меня инициализируется в двух разных местах - SCAN в сенсоре линии, а SINGLE в опросе напряжения батареи. Теперь так нельзя сделать - надо их будет в одну функцию слить вместе.

И всё это происходит на фоне того, что я приобрёл себе новый ноутбук. И взбрело мне на него попробовать поставить линукс. Так как эклипсные IDE, как правило есть под линукс. Так что я поставил себе и Simplicity Studio, и Code Compose Studio. Еще в планах и остальной софт поставить. Правда, если с CCS всё прошло легко и просто, то Simplicity Studio создал много головной боли. Поначалу не хотел опознавать подключенные платки - выдавал id:null. Но потом гуглом нашел решение. Оказалось, что в инсталяторе 5 версии куда-то подевался запуск скрипта который прописывал UDEV скрипты. Правда, иногда есть проблема, что SS не опознаёт свеже подключенные платы - приходится перезапускать SS. Потом был болезненный переход от SDK3 к SDK4, в результате которого из проектов исчезали app.c и main.c. Потом, при попытке создать проект BT SoC Empty, удавалось найти только Bluetooth Mesh - SoC Empty - вылечилось переустановкой SDK. Ну и еще есть какие-то непонятки с пользовательским интерфейсом - тыкаешь мышкой в поле ввода, а курсор не появляется. Особенно выражено в .slcp - Software Components. А с выпадающими списками - вообще ужос. Еле-еле удалось в Power Manager изменить Lowest Energy mode allowed с EM2 на EM1. Мышкой тыкаешь - ничего не происходит. Курсорными клавишами - тоже самое.

Так как я пытаюсь научиться пользоваться GitHub-ом немного удивляло то, что в CCS поддержка Git уже есть а в SS - нет. Причем те рецепты, которые описывают его установку - не работают. Пока не набрёл на одну тему, где специалиста наконец достали и он написал инструкцию и выложил ссылку на неё. Вот по этой инструкции у меня всё получилось под обоими операционными системами.

Есть еще толпа проблем с софтом под Линукс. Например, EAGLE CAD. Да, он есть под линукс. И даже, до пятой версии я его использовал под FreeBSD. Но, в своё время я был купивши Make лицензию... Ну там возникло недоразумение. У Olimex было какое-то странное предложение - очень выгодная цена за виндузную и линуксовскую лицензию разом. Я её купил, а когда пришел пакет -там оказалась только лицензия под виндовс. Оказалось, в списке продаж была ошибка и они за эти деньги не могут продать то что я хотел. Вот так я и стал обладателем виндузной лицензии. К тому времени я принял решение перейти на виндовс, так как под FreeBSD новые версии EAGLE больше не работали из-за проблем с эмуляцией новой версии ядра линукса. Вот, даже сейчас в портах стоит всё еще Eagle v5. Ну с Eagle пока поступаю так - запускаю под Wine и всё, вроде, работает.

Была мысль плюнуть и поставить 11-й виндовс, но меня удерживает пока то, что местный портал в бровзере под линуком не достаёт блокировкой из-за того что у меня установлен AdBlock.

Реклама

Ser60

Передача в компьютер идёт нормально. А вот как проверить обратное направление?

Не понял что мешает сделать на стороне робота UART с USB конвертером и передавать принятые данные в комп? Полагаю, что выводов модуля не хватает? Ну тогда можно организовать "эхо" - передавать по BT принятую роботом командную строку из компа обратно в комп для проверки. Или я не понял проблему?

LE_Timer - нужно было добавить опрос бита синхронизации перед записью в некоторые регистры

В РМ на МК имеется секция Memory and Bus System. В ней прописаны правила доступа к регистрам периферии, а в описании к самим регистрам следует обратить внимание на столбец Type. Но, полагаю, Вы это уже и сами знаете. Если у Вас используется куча аппаратных средств МК для приложения, может стоит подумать об использовании отдельного чипа для их обработки, а БТ модуль использовать исключительно для связи?

И взбрело мне на него попробовать поставить линукс.

Эх, Линух... Ностальгия. Помню, когда мы переехали в US, мне купили в оффис навороченный комп с самой современной на то время версией Windows - NT. До этого мы долгое время жили в Германии, где у каждого на столе стояла Sun Workstation с Unix. После него я на NT работать не смог и шок был велик настолько, что я попросил при наличии отсутствия поддержки универом Unix установить мне хотя-бы Linux вместо NT. Ещё раньше до отъезда в Германию в России на то время была лишь одна из первых версий Windows 3.1, которая была слишком тяжела для тогдашних компьютеров и все довольствовались Norton Commander-ом. Короче, Windows в работе я увидел в первый раз только здесь. Мы попробовали 3 версии Linux-a: Red Hat, Slackware, и SuSE (тогда Ubuntu ещё не было). Первые 2 не смогли работать с моей видеокартой, а SuSE подхватил её сразу и потом долгие годы я сидел на SuSE до тех пор пока мне не надоело каждый год перекомпилировать из исходников требуемые мне программы под новые версии ОС системы и заниматься самому апгрейдом. Сейчас, конечно, всё это упростилось, да и Windows стали намного лучше. При покупке нового компа наверняка получили лицензию для Windows.

Была мысль плюнуть и поставить 11-й виндовс

Я так и сделал-бы. Однако, интересно из каких соображений Вы поставили Linux на новый комп?

От себя добавлю, что в этом году мои проблемы с силлабовскими отладочными платами не кончились. В прошлом из-за сбоев с поставками комплектующих мне пришлось переделывать курсы под плату с PG22. В этом все платы были доступны и я перешёл на BG22, но оказалось, что у меня была старая версия её купленная пару лет назад, а студенты в сентябре купили новые. А в современных версиях платы под выводы сенсоров использованы другие выводы МК, и опять пришлось вносить переделки в проекты. Помню, в первых версиях плат BG22 была проблема нестабильной работы БТ при включении цифрового микрофона на плате и они (SL) сказали, что там дорожка от микрофона разведена плохо (слишком близко от кварца) и потребуется перетрассировка новых версий платы. Я об этом совсем забыл.

Реклама

uldemir

Ser60 писал(а):Ну тогда можно организовать "эхо" - передавать по BT принятую роботом командную строку из компа обратно в комп для проверки.

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

Ser60 писал(а):а БТ модуль использовать исключительно для связи?

Не, хочу всё упихнуть в один модуль. А аппаратура - куда же без неё! Впрочем, вот уже все таймеры у меня заняты:
- TIMER0 - как 32-разрядный - измерение периодов тахометра. И тактировать буду от 39МГц. Делимое будет 499200000 - тогда если это число поделить на период скорость получится в 0.1 мм/с.
- TIMER1 - ШИМ моторов
- TIMER2,3 - квадратурные счетчики тахометра
- TIMER4- управление подсветкой и запуск АЦП сенсора линии (через PRS).
- LE Timer0 - просто задержки, где нужно.
Просто надо быть осторожным, вот уже нарвался на PendSV. По крайней мере sleep timer не использует LE Timer. Надеюсь, SysTick тоже свободен.

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

Ser60 писал(а):Эх, Линух... Ностальгия.

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

Моя история как и у всех начиналась c DOS, а потом у меня был "windows, который лучше, чем windows" - OS/2 aka пополама. Хотя, так же из-за того, что не было средств купить (достать) VGA монитор (у меня была EGA и янтарный Геркулес, пока у него ТДКС не пробило) была большая проблема пользоваться графической средой - пользовался Tshell (консольный менеджер задач). Позже, разжившись VGA стал доступен графический PMshell. Но уже к тому времени стало ясно, что IBM забросила этот проект, так как к новому железу драйверов не было. И когда благодаря моим шаловливым ручкам я убил винт со всем, что у меня было, решил на новый винчестер поставить что-либо новое. Вот тогда мой взор остановился на FreeBSD. Я уже пробовал до этого линуксы и FreeBSD, так вот во FreeBSD мне понравился строгий порядок. рут - это рут, а usr - это usr. А не как в линуксе в /bin залинкованы и /usr/bin, и /usr/local/bin и еще варианты с xxx/sbin. И как я смотрю на убунту - ничего не поменялось. Во FreeBSD есть строгая система портов - все программы ставятся, апдейтятся и удаляются абсолютно одинаково - здесь же - кто во что горазд. SS и CCS вообще встали в мой домашний каталог с моими правами.

Ser60 писал(а):При покупке нового компа наверняка получили лицензию для Windows.

Увы. Деньги потратил совершенно бездарно. Комп совершенно голый и еще вдобавок без русской клавиатуры. Но, зато с 16G ОЗУ. Собирался купить клавиатуру отдельно и заменить... ну тут большое "спасибо" инженерам Леново - посадили клавиатуру на расплавляемые пластмассовые "заклёпки". Причем не на 1-2-3, а пара дюжин. Но в стационарном положении с подключенным монитором, клавиатурой и мышкой - вполне нормально работается.

uldemir

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

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

Принцип поиска финиша такой же как и в алгоритме Дейкстры - расчитываем минимальное расстояние от всех клеточек до финиша и "скатываемся вниз" - т.е. постоянно переходим на клеточку с более низким номером. Вот для примера - нам известно, что в лабиринте 16х16 финиш находится в центре (желтые клеточки) и этим клеточкам присваиваем расстояние 0. Затем всем прилежащим присваиваем 1 итд. Так как мы не знаем где стены - просто заполняем. Пока. Кстати, тут можно заметить какой величины должна быть очередь для заполнения. Вот в совершенно пустом лабиринте больше всего потребовалось число "7" - 32 штуки. Поэтому минимальное число элементов должно быть 32. Максимальное 256 врядли достижимо, так как не могут быть все ячейки на одном расстоянии.

Потом ставим робота на старт, где мы видим, что до финиша 14 клеточек и пытаемся переместиться на клеточку 13. По пути заполняя карту обнаруженными стенами. Вообще-то обнаружив какую-либо новую стену лабиринт следует пересчитать. Но как ни странно, пока мы можем переместиться на ячейку с меньшим номером, в пересчете нет необходимости. Так как те ячейки, через которые мы движемся к выходу значения не меняют (в других местах они могут измениться, но нас там нет и нам это не интересно). Таким образом, следуя по серым клеточкам мы довольно благополучно доходим до координаты x=6 y=8. Здесь мы не можем перейти к клеточке с расстоянием 1, так как впереди стена. А любой свободный ход ведет к клеточке с большим номером.

Поэтому в этой ситуации обязательно необходимо пересчитать лабиринт - сделать так называемый "reflooding". И что интересно, нет надобности пересчитывать весь лабиринт. На данный момент я нашел две техники перерасчета. Одна была озвучена в лекции на Youtube (искать по ключевым словам UCLA Micromouse Floodfill, Хотя одна из ссылок приведена выше). Там перерасчет ведётся от клетки где находится робот. Данная ячейка помещается в очередь и вынимается на обработку. При обработке её проверяется минимальное значение соседних клеток. И если значение обрабатываемой клетки меньше или равно этому минимуму, то ей присваивается значение на 1 больше этого минимума и адреса всех соседних ячеек кладутся в очередь. Т.е. если среди соседних клеток минимальное значение 2, а у этой клетки текущее значение 1, то этой клетке присваивается значение 3. Если же текущее значение было 4, то изменения не производятся и адреса соседних ячеек в очередь не попадают. Затем из очереди вынимается следующая клетка и действие повторяется. И так пока очередь не опустеет.

Другой алгоритм, был опубликован в 2010 году в материалах к соревнованиям MINOS Дэвидом Ханнафордом. Он подошел к этому вопросу проще. Есть несколько постулатов. Все ячейки по мере изучения лабиринта могут своё расстояние только изменить в большую сторону (или остаться неизменной) и никогда стать меньше. Все ячейки которые имеют номер меньше текущей ячейки - измениться не могут. Поэтому, в данном случае, Все ячейки меньше 2 остаются неизменными, а всем остальным присваивается максимальное значение - мне кажется 0xffffffff будет достаточно ;-). А затем от ячеек со значением 1 выполняем reflooding только до ячейки где в данный момент робот находится. Понятно, что текущая позиция станет равной 4, а все ячейки которые будут больше - нам не интересны и могут остаться в "максимальном значении". А мы передвигаемся на клетку со значением 3.

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

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

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

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

Реклама

uldemir

Начал сборку нового робота. Фарнелл меня окончательно расстроил. Платы в китае (или где их там делают?) сделали, выслали и они успели прийти не курьерской почтой, а фарнелл, который кичился, что "доставка на следующий день!" так мне ничего даже не выслал. Написал запрос "что за...?", на что получил ответ, что задержка получилась из-за того, что на модули BGM240 надо оформить какие-то особенные таможенные документы, чтобы из англии ввезти в европу.

Тут же статус поменялся на "Ждём". Начал смотреть, все позиции есть, кроме BGM240. Тому стоит срок 17 марта следующего года. Но тем не менее, если его положить в корчину - статус "зелёный" - есть в наличии! Второе, что меня откровенно возмутило - в разделе общей суммы - появилась строчка Дополнительная плата - 7 евро. За что? Я специально выбирал товары а) есть на месте и не нужно ждать, б) без дополнительных платежей как-то: сумма за намотку на катушки или доставка из США.

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

В пятницу накидал на плату детали, запёк в печке и в субботу начал пытаться оживлять плату.

Начал с USB питания. Что-то не шло. Прижав разъём, напряжение появлялось, но USB устройство не опознавалось. Оказалось, что разъём плохо пропаялся. Поставил на свой прехитер - отпаял разъём, залудил площадки, припаял. Заодно и USB конвертер CP2102 чуть "пошевелил". Хорошо, питание есть, USB устройство опозналось.

Будем пробовать опознать BGM240 модуль. Подключил программатор, вроде ничего. Отпаял, залудил, припаял. Тоже ничего. А, может там надо этому JLink поправить конфиг? Ой, там есть кнопка Detect Device - нажал, опозналось. Хорошо. Что бы загрузить для проверки? О, простой Blinky - кнопку сконфигурил на единственную кнопку, а светодиод на вывод включающий подсветку сенсора - там ничего нет, буду тестером уровни смотреть. Загрузил. Светодиод работает, даже UART работает (но светодиоды TX/RX не вспыхивают), кнопка - нет. Отпаял модуль, припаял - кнопка не работает. Отпаял кнопку, припаял - не работает. Подозрение было на то, что у моей кнопки нет подтяжки к питанию - я планировал использовать внутренние подтяжки. А этот "Simple Button", похоже их не включает. И в документации я не нашел где и как их включить. Попробовал в app_init() вставить конфигурирование порта - не помогло. Тогда вычистил из проекта всю эту кнопку, сконфигурировал на вывод и убедился, что уровни есть и на том пока успокоился.

Со светодиодами TX/RX надо было сконфигурировать CP2102. В том же SimplicityStudio поставил нужную поддержку, сконфигурировал - светодиоды заморгали. Но вот все проекты перестали собираться - Студио в PATH не может найти make (надо как-нибудь посмотреть где он должен быть). Гуглил-гуглил, никакого решения не нагуглил, всё предлагают делать Manage Configuration, но у меня там всё в порядке. Пришлось снова сносить SS и ставить по-новой.

Следующим на очереди был latching circuit для включения/выключения робота кнопкой без фиксации. Подал питание, нажал кнопку - робот включился. Заодно проверил преобразователь 9в - напряжение выдал. Нажимаю кнопку - робот не выключается. В общем, пришлось себя ругать, что поставил в проект не проверенную схему. Так она, вроде, рабочая, но номиналы надо было подобрать. Увеличил парочку сопротивлений - начало работать. В следующий раз буду пробовать другую схему - на полевых транзисторах.

Еще один скользкий момент в этой конструкции - датчики холла для тахометра. Уже писал, что захотел их разместить на плате, как это сделано у роботов 3Pi+ и Zumo32U4. Проблема в том, на каком расстоянии друг от друга они должны стоять? Изучая чертёжи плат роботов 3Pi+ и Zumo исходя из масштаба и известных размеров, у меня получилось 6,67мм. Но если подумать... Возьмём угол который образуют датчики холла и ось мотора - 90 градусов. Так как ось мотора находится на расстоянии 5мм от платы, то расстояние между датчиками должно быть 10мм. Не подходит. Попробуем угол 30 градусов: 2,68 мм. Тоже не то. Если посчитать arctan(6,67/2/5) - получится 33,7, что даст 67 градусов. Но это не тот угол. Или конфигурация магнитного поля диска несколько сложнее, чем я его представляю в "идеализированной" модели. В общем, так как у меня решение не получается решил делать так как написано в "ответе".

Припаял датчики, а так как снова пришлось ругать себя, что не додумался сделать контрольные точки, припаял еще к выходам 4 проводочка, чтобы подключиться к датчикам осциллографом и проверить получились ли импульсы или нет. Вроде, получились:

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

Теперь, можно убирать провода, припаивать двигатели и собирать всё в кучу:

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

Реклама

Ser60

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

Фарнелл... Раньше с него заказывал, точнее с местной площадки Element14 - newark.com. Сейчас посмотрел на чип, что долгое время ждал в продаже (акселерометер LIS2DW12), и он у них появился! Однако, всё портит ложка дёгтя - один из клиентов там описал проблему с заказом подобную Вашей. Да и пересылка от них несколько дороже чем везде. Кстати, недавно получил емайл от Arrow (arrow.com) с предложением бесплатной пересылки заказов в течении пары месяцев в плане акции поддержки университетов. У них меньше выбор чем на том-же Digikey, но оказалось там имеется "мой" акселерометр, который долгое время не было в продаже ни у кого, и я в отчаянии перестал его искать. Короче, связался с агентом Arrow и оказалось, что это вполне адекватная девушка из Украины. Я представился, мы перешли на русский и, несмотря на известные события, нормально пообщались. Так, о чём это я... Ах, да, сделал заказ, а потом оказалось, что этот акселерометер как и другие чипы, за которыми я охотился (например, MAX98357) уже появились и не только у них. Всё жду возобновления после ковидной "спячки" очных семинаров в местном оффисе Arrow. Силлабы, в частности, обещали вернуться к очным семинарам в след. году.

Плата нового робота выглядит красиво. Однако, не понял, что за проблема возникла с подтяжкой на пине модуля BGM240 и удалось-ли её разрешить. И какой это пин - хотя и вряд-ли, но может на нём и нет внутренней подтяжки? Хотя и использую многие драйверы в SSv5, но Simple Button и Simple LED посчитал уж слишком. Никогда их не использовал, всегда конфигурировал пины на вход/выход средствами Studio непосредственно и для работы с ними использовал функции из em_gpio.h. Помощь нужна с этим? Насчёт необходимости переустановки Studio - также с этим сталкивался. Без переустановки иногда не удавалось работать под Win10/11 после major апгрейдов SDK. Но это дело порядка лишь 15-20 минут, хотя и раздражает, конечно. Одно успокоение, что делать это приходится нечасто. Кстати, как поживает Ваш новый лаптоп?

Реклама

uldemir

Этот алгоритм не годится для наших лабиринтов из линий, так как местонахождение финиша у нас не дефинировано - поэтому пока только Люк-Тремо. А вот в micromouse - там, вроде, определено, что точно в центре. Я тут еще в одном видео (очень древнем, не то 2008 или даже 2004 года) еще одну аналогичную лекцию видел. Там был показан экселевский файл, который просчитывал эти расстояния и я тоже себе смеха для был сделавши и промоделировал решение роботом тестового лабиринта. К четвертому проходу робот уже ходил только по кратчайшему пути. при этом в верхней части остался большой неисследованный кусок. Но, этот алгоритм не даёт оптимизации по времени. У Дэвида Ханнафорда упоминается расчет с "переменным расстоянием", когда прямой ход имеет одно расстояние, а с поворотом другое. Но я не могу догадаться как он это считает - описания нет, только упоминание, что там нужны флаги указывающие направление, и мне мозги заслоняет моё решение с несколькими уровнями.

Есть еще более другой способ для расчета уже с учетом и поворотов, и диагональных ходов. В этом случае одна клеточка делится на 9 точек: 4 точки по углам (не используются - они всегда зааняты) 4 точки по середине каждой стороны - "занятость" определяется наличием стены и одна в центре клеточки. примерно так:

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

1 2 3
4 5 6
7 8 9

И чтобы пройти клетку насквозь горизонтально - идём через точки 4-5-6 или 6-5-4. Вверх: 8-5-2. А с поворотом типа 4-5-2 или по диагонали 4-2. при этом можно прямой ход: 4-5, 2-5 итп оценить в 2 единицы, а диагональные в 3 единицы. тогда "стоимость" прохода 4-5-2 будет равна 4, а по диагонали 4-2 - всего 3. И аналогично эту таблицу (она уже получается 31х31 или 33х33) заполнять и обрабатывать таким же алгоритмом.

По поводу расположения и количества сенсоров, я сам еще не определился. RSLK предполагает использование всего 3 сенсоров - один вперед и два в стороны под углом. Аналогичную конфигурацию даёт применение модуля pololu-3412 на ToF сенсоре OPT3101. Для него я предусмотрел на этой плате посадочное место. Была мысль собрать сразу 3 платы и детали я закупал расчитывая на такой вариант, но вот этих "больших керамических конденсаторов" (по два евро штука!) не смог докупить - нигде не было. И акселерометр, оказалось, я купил только одну штуку (в геометрическом центре робота стоит).

В лекциях/воркшопе UCLA, похоже, используют 4 сенсора - два вперед, и два перпендикулярно в стороны. Два сенсора смотрящие вперед позволяют выровнять робота в тупиках или на Т-образном перекрёстке по стенке впереди. У авторов сайта micromouseonline.com обычно 6 сенсоров - два вперед, два перпендикулярно в стороны и два в стороны диагонально. Где-то я на том сайте заметил упоминание, что вот эти две пары сенсоров - перпендикулярный и диагональный, позволяют определить не только положение относительно стен (как точно по середине находится робот), но и направление робота - соосно с "коридором" или есть небольшой угол. Себе я планировал делать тоже 6 сенсоров. И думал все разместить спереди, но сейчас крутится мысль, что 2 перпендикулярных стенам сенсора разместить между колёс, там где у меня сейчас стоит USB разъём. А спереди поставить 2 фронтальных и 2 диагональных.

Ser60 писал(а):Плата нового робота выглядит красиво. Однако, не понял, что за проблема возникла с подтяжкой на пине модуля BGM240 и удалось-ли её разрешить.

Разрешить её в плане применения как есть из "BT SoC Blinky" мне не удалось. Кнопка у меня сидит на порту PC03 (26-й контакт). PullUp у этого вывода есть. Когда я собирал этот проект, в Software Components эти двум компонентам Simple LED и Simple Button назначил порты - PC03 кнопка, PA00 - LED. И вот реакцию на кнопку я не видел. Измерял тестером напряжение на контакте кнопки - там было около 1 вольта - 0,8-1,1. Потому сначала подумал, что есть замыкание с соседними контактами. Но позже, сконфигурировав соседние контакты на вывод и выведя на них лог.1 (и я проверил, что там есть напряжение) и увидев, что на кнопке ничего не изменилось, понял, что на плате всё в порядке. Просто я не знаю, как у этого Simple Button включить подтяжку. Сейчас загружен мой код, в котором эта кнопка проинициализирована

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

void LaunchPad_Init(void) {
  CMU_ClockEnable(cmuClock_GPIO, 1);
  GPIO_PinModeSet(gpioPortC,  3, gpioModeInputPull, 1);
}

- на ней присутствует 3в, так что эта проблема перешла в разряд "просто интересно". Уж я то в своей конструкции этот компонент точно не буду использовать. Был посмотревши на первую попавшуюся схему одной из плат (даже не помню, bg22 или mg24) - там на кнопке есть внешний подтягивающий резистор в 1 Мегаом, поэтому на боардах этот пример работает, а на моей custom board - нет.

uldemir

Осталась неделя до соревнований. Смотрю как заполняется список участников. Уже 89 роботов заявлено. Письмо руководителю клуба послал - так что тоже буду участвовать, но наша команда еще не зарегистрировалась. Заодно, появилось объявление о 15 чемпионате (14-й так тихо и скончался из-за коронавируса). Пока сборной таблицы, где какие будут соревнования, нет, но есть график. Так что будет марафон - каждый месяц по одному соревнованию. Хотя лабиринт будет не во всех, наверное.

Пока что на лабиринт из линий уже заявлено 4 робота: два из Литвы (те же самые названия, что и тогда были) и два местных (мне кажется, что они в прошлый раз тоже были заявлены, но не участвовали). Ну за 3 года, возможно, они тоже улучшили свои конструкции - посмотрим. Мне тоже интересно, какие мои улучшения помогут справиться с трассой, а какие - нет. Но я тут подумал, что так как я "улучшил" способность видеть линию, то как робот отреагирует, если снова сквозь цветную прозрачную плёнку будет проглядывать черная линия. Будет видеть хорошо и до конца, или сразу не будет видеть, или будет старый вариант - то видно, то не видно. С одной стороны на это плевать, но с другой стороны - впереди стена. У меня по окончании подаётся команда проехать 10см вперед, чтобы робот стал на цветном поле полностью. Это в соответствии с правилами:

2.6. The countdown starts when any part of the robot crosses the start zone (starts moving along the track). The countdown ends when the robot stops at the finish area, while all wheels and other supports of the robot must also be in the finish area.

Но если робот будет видеть линию сквозь плёнку и доедет до конца неё, то сделав эти "10см вперед" он своей полукиллограммовой тушей к-а-а-а-а-к влепится в эту стену! У меня же у этого робота даже bump-сенсоров нет, чтобы его остановить. А сенсоров нет, потому что выводы у "контроллера" закончились.

И тут я начал размышлять на тему поставить ToF сенсор на OPT3101 (ну наконец-то!). Решил так, что найдя тупик на цветном поле, измерить сенсором расстояние до фронтальной стены и команду на выход из лабиринта давать с указанием как далеко можно выходить. Если же стены нет или она дальше некоторого предела - стандартный выход - 10 см.

Начал втыкать модуль. Хоть он и i²c, но ему надо еще один вывод для прерывания, означающего, что измерение выполнено. Где-же взять еще один вывод у контроллера у которого больше нет свободных выводов? О. у расширителя портов PCA9536 из 4 выводов использовано только 3 (кнопки). Но этот расширитель не имеет возможности отслеживать изменение уровня на входе, а постоянно опрашивать его через i²c - лениво. Поэтому на этот вывод я повесил самый медленный сигнал - включение спящего режима драйвера двигателей, а сигнал прерывания завел на высвободившийся вывод. Сделал изменения, провел испытания. Показания сенсора довольно-таки "шумные". Поэтому сделал Low Pass Filter на 32 отсчета и беру усреднённое значение. Правда из-за этого, время измерения стало довольно большим - по моим ощущениям, робот стоит и пялится в стену почти секунду. Еще заметил, что даже если нет препятствия, показания где-то 30-35 см - похоже это он видит на таком расстоянии впереди пол.

А как бы сделать так, чтобы не стоять и не пялиться в стену? Ну, можно измерять расстояние до стены на ходу. Стена то стоит на месте. Т.е. сделав отсчет, фиксируем позицию робота, сделав следующий отсчет, из предыдущего измерения отнимаем расстояние, что робот за это время проехал (а это мы знаем по таходатчикам) и усредняем с текущим. И так на каждой итерации. Так что по-идее, должно быть по накопленным данным довольно точное расстояние известно по мере приближения к стене. А для синхронизации измерения ToF и одометра, можно сигнал прерывания ToF сенсора с вывода контроллера завести в PRS, а уже PRS может делать захват состояния квадратурных счетчиков таймера (подключенных к таходатчикам) на тот момент. Благо таймеры имеют по 3 регистра захвата/сравнения. Эээх, вот только у этого робота квадратурные энкодеры подключены не к таймерам, а к PCNT - счетчикам импульсов, а у них регистров захвата нет. Можно было бы это сделать на новом роботе, на шасси Zumo, но там точно нет свободных выводов для этого. Уже подумываю о переделке.

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

С этим Zumo тоже возникла проблема. Что-то у меня не хотел робот ехать назад. Оказалось, что была залипуха между сигналом sleep драйвера двигателей и сигналом направления вращения правого мотора. Поэтому когда давал реверс, драйвер уходил в сон и двигатели не крутились. Залип оказался под модулем BGM240. Попытка же отпаять модуль не снимая припаянных клемм для батарей и моторов привела к тому, что я испортил колёса, что оставались на моторах. Хоть, они и с другого конца платы от того места где я грел, всё же им тоже досталось. Так что пришлось думать о приобретении новых колес. Купил новый набор гусениц с того же TME.EU, ну и для комплекта купил магнитые диски и еще пару моторов. Так что теперь у меня есть запасной комплект гусениц (можно будет на соревнованиях переобуваться между заездами), И еще пара shoulder screw с короткой и длинной резьбой (второго в комплекте шасси не полагалось).

uldemir

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

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

Поэтому для меня самое важное было попробовать своих роботов на новом, а не домашнем лабиринте. Хм, тут тоже не всё хорошо. Новый робот (на EFM32) не всегда мог до конца исследовать лабиринт. Но проблема, то возникала, то нет. Вот как выглядел лабиринт:

Сначала я запустил робота на изучение лабиринта установив "пьяную" стратегию...

Спойлер

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

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

const unsigned int turn_sequence[][3] = {
				{RIGHT_MASK, STRAIGHT_MASK, LEFT_MASK},
				{LEFT_MASK, STRAIGHT_MASK, RIGHT_MASK},
				{RIGHT_MASK, LEFT_MASK, STRAIGHT_MASK},
				{LEFT_MASK, RIGHT_MASK, STRAIGHT_MASK},
				{STRAIGHT_MASK, RIGHT_MASK, LEFT_MASK},
				{STRAIGHT_MASK, LEFT_MASK, RIGHT_MASK},
};

Еще есть седьмая стратегия - случайный выбор. На каждом узле генератор псевдослучайной последовательности выбирает одну из этих 6.

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

Пока же, сменил стратегию на "целенаправленную" и в таком виде исследовал лабиринт, получил маршрут и по этому маршруту и гонял робота. Тут два видео: исследование и решение:

Спойлер

Можно заметить, что в тупики робот въезжает на медленной скорости, а обратно выезжает с ускорением. Это и есть фича, что по известным участкам робот бегает уже зная расстояния и может разгоняться. Правда, на соревнованиях я убрал фичу плавного разгона и торможения при поворотах, а включил старый "агрессивный" режим, когда робот разгоняется чуть больше, чем надо и тормозит с гораздо большим ускорением, чем делает разгон.

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

Ну и чуть-чуть фото чужих linefollower-ов "случайно" попавших мне в кадр.

uldemir

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

Как бы сделать без прерываний? Тут было предложено[uquote="Мурик",url="/forum/viewtopic.php?p=3915853#p3915853"]Может лучше ШИМ захват?[/uquote]Начал потихоньку думать в этом направлении. Если один импульс завести на два регистра захвата так, чтобы один фиксировал время фронта, второй - спада, то прочитав оба этих регистра и взяв между ними разницу, получу период между этими импульсами. Остаётся одна проблема - а который из них в данный момент "крайний"? Можно просто смотреть на результат, если меньше 0, то надо наоборот. Правда, если робот простоит на месте полторы минуты, может случиться так, что этот метод даст ложную информацию, но можно, наверное, предусмотреть останов и сброс этого таймера, если драйвер двигателя переведён в спящий режим (а эти полторы минуты могут быть только в такой ситуации). Но есть одна проблема - у таймеров этих всего по 3 регистра захвата. Т.е. два колеса на один таймер посадить не удастся. Вообще-то у меня был один свободный 32 битный таймер, но я его применил под бенчмарк, чтобы измерять время прохода робота по лабиринту.

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

Попробовал, вроде, теперь трогается гораздо плавнее.

Вообще, я этому LDMA могу долго петь дифирамбы. Для робота на шасси Zumo делал журналирование в ОЗУ. Уже был одному роботу выделивши 120 000 байт в ОЗУ. А для обозначения конца журнала все поля записи будут 0xFFFF. Поэтому, перед записью журнала, всю эту память я хочу "проинициализировать". Ну и как это сделать, если LDMA может делать только 2048 трансферов. Пришлось научиться пользоваться полем loop. И теперь все 120 000 байт (на самом деле 60 тысяч 16-битных слов) прописываются используя DMA.

Спойлер

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

LDMA_TransferCfg_t xferCfg;
LDMA_Descriptor_t descriptor[2];

void fill_data32_dma(uint32_t data, uint32_t* dest, uint16_t count) {
  static uint32_t source[1];

    if ((count - 1) < 2048) {
        while (dma_flag) continue;
        xferCfg = (LDMA_TransferCfg_t) LDMA_TRANSFER_CFG_MEMORY();
        descriptor[0] = (LDMA_Descriptor_t) LDMA_DESCRIPTOR_SINGLE_M2M_WORD(source, dest, count);
        source[0] = data;
        descriptor[0].xfer.srcInc = ldmaCtrlSrcIncNone;
        dma_flag = 1;
        LDMA_StartTransfer(LDMA_MEM2MEM_CHANNEL, &xferCfg, &descriptor[0]);
    } else {
        while (dma_flag) continue;
        xferCfg      = (LDMA_TransferCfg_t) LDMA_TRANSFER_CFG_MEMORY_LOOP((count / 2048)-1);
        descriptor[0] = (LDMA_Descriptor_t) LDMA_DESCRIPTOR_LINKREL_M2M_WORD(source, dest, ((count-1) % 2048) + 1, 1);
        descriptor[1] = (LDMA_Descriptor_t) LDMA_DESCRIPTOR_LINKREL_M2M_WORD(source,    0, 2048, 0);

        source[0] = data;
        descriptor[0].xfer.srcInc = ldmaCtrlSrcIncNone;
        descriptor[1].xfer.srcInc = ldmaCtrlSrcIncNone;
        descriptor[1].xfer.dstAddrMode = ldmaCtrlDstAddrModeRel;
        descriptor[1].xfer.decLoopCnt = 1;
        descriptor[1].xfer.link = 0;          // Stop after looping
        descriptor[1].xfer.doneIfs = 1;

        dma_flag = 1;
        LDMA_StartTransfer(LDMA_MEM2MEM_CHANNEL, &xferCfg, &descriptor[0]);
    }
}

Аналогично, взбрело мне в голову применить дисплей на SH1106 контроллере. Как-то был купивши 1.3" дисплей. Но так как SH1106 гораздо "проще" чем SSD1306, я его не ставил. В 1306 чтобы обновить полностью экран надо дать 1 команду и можно заливать данные. В 1106 так не получится, там нужно каждую из 8 страниц указывать и заливать отдельно. Но поразмышляв и улучшив рецепт, что я описывал там (решил проблему с управлением сигнала D/C - при запуске устанавливаю уровень соответствующий команде, а затем просто прописываю лог.1 в регистр GPIO->P[].DOUTTGL). Портянка получилась довольно длинная, но она выполняется почти без участия процессора. Процессор только обрабатывает прерывания окончания SPI трансферов.

Спойлер

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

static unsigned char start_col[8][3] = {
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 0},
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 1},
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 2},
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 3},
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 4},
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 5},
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 6},
    {SH1106_SETLOWCOLUMN | 2, SH1106_SETHIGHCOLUMN, SH1106_PAGEADDR | 7},
};
LDMA_TransferCfg_t txferCfg = LDMA_TRANSFER_CFG_PERIPHERAL(ldmaPeripheralSignal_USART3_TXBL);

LDMA_Descriptor_t tx_descriptor[] = {
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x00, 0x00, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(USART_CMD_RXDIS, &USART3->CMD, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(USART_ROUTELOC0_CLKLOC_LOC0 | USART_ROUTELOC0_CSLOC_LOC0 |
                                  USART_ROUTELOC0_RXLOC_LOC0 | USART_ROUTELOC0_TXLOC_LOC0,
                                  &USART3->ROUTELOC0, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[0], &USART3->TXDATA, sizeof(start_col[0]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer, &USART3->TXDATA, 128, 1),
// 1
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[1], &USART3->TXDATA, sizeof(start_col[1]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer+1*128, &USART3->TXDATA, 128, 1),
// 2
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[2], &USART3->TXDATA, sizeof(start_col[2]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer+2*128, &USART3->TXDATA, 128, 1),
// 3
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[3], &USART3->TXDATA, sizeof(start_col[3]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer+3*128, &USART3->TXDATA, 128, 1),
// 4
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[4], &USART3->TXDATA, sizeof(start_col[4]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer+4*128, &USART3->TXDATA, 128, 1),
// 5
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[5], &USART3->TXDATA, sizeof(start_col[5]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer+5*128, &USART3->TXDATA, 128, 1),
// 6
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[6], &USART3->TXDATA, sizeof(start_col[6]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer+6*128, &USART3->TXDATA, 128, 1),
// 7
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(start_col[7], &USART3->TXDATA, sizeof(start_col[7]), 1),
    LDMA_DESCRIPTOR_LINKREL_SYNC(0, 0x80, 0x80, 0x80, 1),
    LDMA_DESCRIPTOR_LINKREL_WRITE(1 << 5, &GPIO->P[gpioPortA].DOUTTGL, 1),
    LDMA_DESCRIPTOR_LINKREL_M2P_BYTE_NOIRQ(buffer+7*128, &USART3->TXDATA, 128, 1),
//
    LDMA_DESCRIPTOR_SINGLE_WRITE(0, &tx_busy)
};

void update_display(void) {
    while (tx_busy) continue;
    tx_busy = 1;
    BUS_RegBitWrite(&GPIO->P[gpioPortA].DOUT, 5, lcdcommand);
    LDMA_StartTransfer(LDMA_USART_OLED_CHANNEL, &txferCfg, (void*)&tx_descriptor);
}

Изящнее было бы там применить Loop counter, но так как там надо делать трансферы из 2 разных мест, не уверен, что это возможно. Я такой возможности (пока) не вижу.

uldemir

Намедни рылся в библиотеке и нашел книжку известного автора Перельмана под названием "Лабиринты". Пол книжки занимал анализ лабиринта упомянутого в книге Джерома К. Джерома "Трое в лодке". Но, конечно, меня приколол в этой книжке один абзац:

Это явно про алгоритм Люка-Тремо (вообще-то это два француза - Люка опубликовал, но ссылался на Тремо). Это из второго издание книги 1931 года, а алгоритм был опубликован в 1882 году.

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

Стоимости диагональ - 3, а "полуклетка" - 2. Питер Харрисон по этому маршруту формирует цепочку символов, которые потом можно скормить управляющей движением программе. Например пройти полуклетку прямо - H, по диагонали - d, а поворот направо или на лево 45 градусов l или r, соответственно, на 90 - L R. Тогда маршрут будет выглядеть как:

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

HHHldlHHlddrHHHHldRdrHHHrddLdlHHH

Так же, эту строку можно пропустить через фильтр и выделять какие-то особые маневры. Вот первый поворот "ldl". Его не обязательно делать как два поворота - можно плавно повернуть на 90 градусов. А вот по какой траектории? Снова вспомнился Перельман. В его книге, вроде, "Занимательная физика", рассматривалось как должны быть проложены рельсы в повороте. И если просто после прямолинейного участка начнется сразу поворот с радиусом (для этого лабиринта радиус 15 сантиметров), то состав будет ощущать "толчок", так как вектор скорости должен будет резко измениться. Фактически вторая производная скорости будет иметь разрыв, так как ускорение будет нарастать не плавно, а скачком. Ну и там рассматривались варианты.

Мне в голову влез вариант с синусоидой. Впрочем, у Питера Харрисона тоже упоминалась такая траектория. Возьмём поворот и наклоним его на 45 градусов и сверху наложим график синусоиды:

Так как производная в точке пересечения оси равна 1 и -1, то касательные в этих точках взаимно перпендикулярны и накладываются на оси проходов. Вот только проблема, как перейти от декартовой системы координат к координатам относительным пройденному пути. Вот я пока думаю, как эту задачу решить.

Потом, еще нужно бы придумать как быть с S-образной траекторией "lddr" и с крутым поворотом (на трассе два таких куска в конце) "ldRdr", "rddLdl".

А тем временем, пробовал зашевелить робота на шасси Zumo и там возникла неприятная проблема.

Вот я попытался питать двигатели 25, 50 и 75% PWM. И, что обидно, скорость даже 1 м/с не набирается. Изучая, что происходит, заметил, что стоит включиться двигателям, как напряжение на выходе преобразователя с 9в падают до 5.4в (напряжение аккамуляторов). Начал испытывать преобразователь. Нагрузок у меня нет, но я на столе нашел кучку 39 омных МЛТ-2 резисторов и попытался преобразователь ими нагрузить. до 4 штук (ток около 0.9А) преобразователь работал нормально. Подключив 5 резистор преобразователя хватало на секунду-другую, а при подключенных 6 резисторах (1.35А) преобразователь сразу просаживался до входного напряжения. Как же так? я его в воркбенче на 2А считал?

Стал придумывать варианты как обойти проблему. Можно выкинуть преобразователь и поставить другой навесным монтажом. Как, например, у одного из лайнфолловеров (№264 справа синяя платка). Или вообще обойтись без преобразователя, а вместо NiMH поставить LiPo на 7.4в. Была даже мысль, что виной нагрузка на моторы создаваемая гусеницами - снял гусеницы - ничего не поменялось.

Чуть позже, возникла мысль, что при проверке, я щупал, кто сильно греется в таком режиме. И, помимо самого преобразователя TPS61089, еще грелся ключ включающий питание - DMP3085

Попытался его закоротить - преобразователь 1.35А держит без проблем (больше не нагружал, так как резисторы кончились). Так, оказывается при большом токе, слишком большое падение напряжения? Ну да, этот ключ где-то 95мОм, а два последовательно - еще больше. В каталоге присмотрел другой ключ DMP3028 - 35мОм. Когда закажу, попробую поменять на него. А если не поможет, то попробую включить впараллель. Если и это не получится, будем ставить простой механический переключатель. Эх, надо было ключ ставить в минусовый провод.

Или всё же LiPo? Кстати, когда робот бегал и стукался о плинтус - контроллер сбрасывался. Есть проблема в продольном расположении элементов питания. Может, поэтому pololu в более поздних шасси как 3Pi+ и Romi батарейки поставила перпендикулярно движению. Но, мой робот, в идеале, не должен ни обо что стукаться.

Ой, и с наступающим Новым Годом!

uldemir

не могу решить задачку. Хотел "синусоиду" аппроксимировать дугами, чтобы робот в повороте, какой-то участок ехал с некоторым радиусом закругления, следующий - с еще меньшим итд. А вот кстати - какой самый маленький радиус закругления будет в "вершине" поворота? Решил вычислить таким образом - проводим хорду и зная длину хорды и расстояние от хорды до вершины по формуле считаем. Скажем возьмём ±10° - длина будет 20 градусов (считаем, разумеется в радианах), а высота - разница между sin(90°) и sin(80°). И чем эти величины ближе к 0, тем точнее получается радиус. У меня получилось, что радиус равен единице.

Тут я решил "примерить" эту синусоиду к перекрёстку. Если сторона клетки 30см, то диагональ, между серединами сторон 21.213см. Тогда, если эта диагональ пропорциональна Pi, то радиус всего 6,75см. А так как ширина колеи 14см, то получается, что внутреннее колесо должно вращаться назад?

Можно поворот начать раньше (см рис.) - с середины предыдущей клетки - тогда диагональ 42см и радиус 13.5см. Но тогда на такой поворот можно подменять строку не "rdr" или "ldl", а "HrdrH" или "HldlH". А такой маневр на последней трассе был только один. Да и всё равно - таким методом у меня не получается рассчитать радиусы остальных дуг. Я разбил синусоиду по 10°. Длины хорд считаются на раз. А вот с вычислением высоты затык. Уравнение линии перпендикулярной хорде и проходящей через середину хорды я получил, а вот найти точку пересечения этой прямой с синусоидой - не могу решить эту систему уравнений.

Тогда переходим к плану Б. Мы легко можем выяснить какой азимут должен быть у робота в заданных точках. Скажем, в начале - 45°, в вершине - 0°, а в конце -45°. Этот азимут есть арктангенс коэффициента наклона касательной прямой в заданной точке, а коэффициент уравнения этой касательной прямой равен производной (так как у нас синус, то косинусу) в заданной точке. Для примера, возьмём 0° и 10°. Косинусы для этих точек 1 и 0,984. А арктангенсы 45° и 44,56°. Таким образом, за первые 10 градусов поворота робот должен повернуться всего на 0,44°. Как теперь зная эти углы узнать радиусы поворотов.

А это уже обратная задача одометрии. Вот немного теории под спойлером. Это из книги Валвано и файл приложен внутри https://www.ti.com/tool/TIRSLK-EVM-SW в каталоге inc и зовётся odometry.docx

Спойлер

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

Теперь осталось написать программу и пробовать на полигоне. Правда, такой большой поворот на моём полигоне не вмещается толком, но я попробую.

А как быть с поворотами на 45°? Пока из идей к уравнению y=sin(x), добавить коэфиициент, чтобы касательные в точках пересечения осей абсцисс составляли не 90, а 45 градусов. Это значит, что наклон должен быть 22.5°, а это можно получить при коэффициенте 0,414 (tan(22.5°)). Остаётся проблема где разместить на траектории точку начала поворота.

Попробовал сделать таблицу. Но почему-то она получилась не симметричная. Шаг решил сделать 1/16 от 180 (Pi). И вот если радиус первого участка получился 38, то радиус последнего - 18. Где же ошибка? Смотрю в таблицу и вижу, что коэффициенты наклона касательных симметричны, точки пересечений касательных - симметричны. И углы - тоже симметричны. А вот dz - не симметричны. dz - это расстояние от точки пересечения касательных то точки касания с синусоидой. А так как я считал расстояние от точки пересечения до предыдущей точки касания, то вот тут после 90° отметки, симметрия и нарушалась. Оказалось, что расстояние по предыдущей и следующей точки касания разное. Ну, это-то как раз и логично - ведь, у меня не окружность, а синусоида. Тогда я сделал расчет второй части dz и расчитал радиусы - таблица получилась симметричной:

k, a - параметры прямой касательной к синусоиде в заданной точке y=k*x + a
x, y - координаты точек пересечения текущей касательно со следующей
dz, dz2 - расстояние от точки пересечения касательных до точки касания синусоиды.
tan(t/2) - тангенс от половины угла поворота направления робота
R - радиусы закругления

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

Тем временем с шасси Zumo не удалось реализовать ни план Б, ни план В, ни все остальные. Пришли мне новые транзисторы для ключей выключателя. Вместо DMP3085 впаял DMP3028 - лучше стало, но всего чуть-чуть. При нагрузке в виде 39-омных резисторов - 5 резисторов тянет, а 6 - тянет пару секунд (с предыдущим транзистором было, что так происходило с 4 и 5 резисторами). Но в любом случае, моторы скорость выше 1 м/с скорость не набирали. Тогда, я из схемы вывел один транзистор - особо ничего не изменилось, а вот когда я выведенный транзистор подключил параллельно - случилось ужасное. При запуске двигателей напряжение после ключей стало проседать так, что начало проседать напряжение 3,3в и микроконтроллер стал просто сбрасываться. Причем, это всегда происходило, если гусеницы были надеты. Если колёса просто в холостую крутились, то сброс происходил не всегда. Поэтому, пришлось прибегнуть к последнему средству - поставил простой механический выключатель.

Вот странно. Я изучал схемы pololu-вских роботов. У них схемы включения аналогичные и, возможно, у них всё работает? Правда повышающий преобразователь на роботе Zumo моторы не питает - моторы питаются прямо от батарей, а повышающий делает только 5в для микроконтроллера и обвязки. Моторы повышающий преобразователь питает на роботе 3Pi - там нет гусениц, но и батарейки там стоят мелкие типа ААА. Конечно, Pololu не раскрывают типы транзисторов и схемы преобразователей. И я теперь опасаюсь, может даже 3 мОм -ные транзисторы не дадут работать преобразователю нормально?

Ну, теперь робот может развить скорость даже чуть больше, чем 2 м/с:

PWM задаётся от 0 до 15000 (100%), а скорость отображается в 0.1 мм/с. Т.е. 20000 - это 2 м/с (при 75% ШИМ). Правда, поначалу были "выбросы" в положительную и отрицательную сторону (отрицательный выброс виден был на старом графике). Как же так? Моё предположение, что эти "неправильные" интервалы были из-за просадок питания микроконтроллера и датчиков холла. Была мысль питать 3.3в стабилизатор не от батарей, а от 9в преобразователя, но это создало бы лишние потери энергии, поэтому для подавления этих просадок просто на вход LM1117 повесил еще большой электролит - 820uF на 6,3в (прощай возможность подключить LiPo). И вот после этих доработок, робот начал боле-менее нормально бегать. Теперь можно будет начать подбирать коэффициенты ПИД регулятора двигателя.

uldemir

Неделю назад был на соревнованиях, где снова провалился. Один робот никак не мог проехать перекрёсток - всё время выбирал левую ветвь, а не прямую, а второй робот терял линию на одном из поворотов. Тот робот, что неправильно проходил перекрёсток проблему вызывало то, что перекрёсток был сразу за поворотом и робот еще не был стабилизирован на линии, поэтому ему казалось прямым ходом боковая ветвь. К сожалению, мне не удалось записать журнал на этом роботе из-за склероза. Я подготовил EEPROM-ки для сохранения логов, но оказалось, что за время пандемии я забыл, что тому роботу надо было делать микросхемы с адресом 0xA2, а не 0xA8, как я сделал.

Стрелка показывает направление прохода траектории.

Зато второй робот мне дал информацию почему ошибка происходила на повороте. Ну тут снова, возможно, моя вина. Я перед соревнованиями решил роботу немного декапировать хвост, чтобы улучшить сцепление колёс при разгоне. В результате робот стал слишком сильно задирать нос и в этот момент переставал видеть линию. То что это происходило при старте - понятно. Там в течении 1/8 секунды от старта он два раза поднимал нос (наверно сначала задирал, потом опускал и второй раз нос просто подскакивал). Затем, на первом повороте вижу, что пропала линия, робот нашел линию и снова нос был задран (возможно, снова из-за разгона). Затем следовал плавный поворот, который робот прошел без проблем и после следующего левого поворота нос задирался так, что следующий за ним правый поворот робот не видел.

Спойлер

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

02.251,#.......
02.252,#.......
02.253,#.......
02.254,#.......
02.255,#.......
02.256,#.......
02.257,#.......
02.258,#.......
02.259,#.......
02.260,#.......
02.261,#.......
02.262,#.......
02.263,#.......
02.264,##......
02.265,##......
02.266,##......
02.267,##......
02.268,##......
02.269,##......
02.270,##......
02.271,##......
02.272,##......
02.273,##......
02.274,##......
02.275,##......
02.276,.#...##.
02.277,.##.####
02.278,.##.####
02.279,.##.####
02.280,.#######
02.281,.#######
02.282,.#######
02.283,.#######
02.284,.#######
02.285,.#######
02.286,.#######
02.287,.#######
02.288,.#######
02.289,..######
02.290,..######
02.291,..######
02.292,..######
02.293,..######
02.294,..######
02.295,..######
02.296,..######
02.297,..######
02.298,..######
02.299,..####..
02.300,..###...
02.301,..###...
02.302,..##....
02.303,..##....
02.304,..##....
02.305,..##....
02.306,..#.....
02.307,..#.....
02.308,..#.....
02.309,........
02.310,........
02.311,........

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

Конечно, этого можно было бы избежать, если бы я оставил "хвост" как есть или надо бы озаботиться о более широком диапазоне распознавания линии. Была затея организовать "вычитаение паразитной засветки", как сделал роботу на EFM32, благо у того робота (на PSoC5) есть возможность включать и выключать подсветку, но попытка реализовать это привела к сообщению, что UDB ресурсов не хватает.

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

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

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

					result = data.k_error*track_error + data.k_diff*de_dt + sigma_error;
					left_speed = speed+result;
					right_speed = speed-result;

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

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

      result = data.k_error*track_error + de_dt + ((sigma_error * data.k_integral) >> 10);
      left_speed = speed+(result*speed)/8192; // speed*(1+result/nom_speed)
      right_speed = speed-(result*speed)/8192;

Но теперь, другая крайность - при нулевой скорости робот даже не пытается выровняться (пока не разгонится). Вот и думаю - как правильно?

С аналитическим решением поворотов ничего толкового не получается, поэтому решил применить CAD для решения этой задачи. Вот во Fusion360 нарисовал 4 типа маневров: повороты на 90 градусов при прямых и диагональных ходах, 45 градусов и 135 градусов. Это покрывает 80% возможных маневров необходимых для прохода лабиринта. Для 100% нужно еще придумать как делать "разворот" - U - образный поворот на 180 градусов. Но там ничего умнее чем двигаться по дуге с радиусом 150мм, в голову не приходит.

Хуже всего получился 135 градусный поворот. В верхней точке траектории радиус поворота меньше половины ширины колеи - значит, внутреннее колесо должно вращаться назад. Еще опасение вызывает 90 градусный поворот при переходе с диагонального на диагональный ход - там расстояние между стенкой и траекторией всего 90мм (зазор получается всего 20мм). Ну и при помощи инструмента Inspect, я могу узнать какой радиус поворота и на каком участке мне следует применять.

Правда, сейчас в раздумьях что следовало бы делать в первую очередь. Ведь через 3 недели следующие соревнования. И вот смотрю программу... вчера был только LEGO лабиринт для школьников. Сегодня смотрю появился Просто лабиринт из линий, но тоже для школьников. Для любителей пока лабиринта нет. Хотя в TSI из школьников никого не было. Так что если лабиринта не будет, надо заниматься лайнфолловерами. Хотя честно, и без соревнований хочется взять своих роботов и испробовать на лабиринтах побольше.

uldemir

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

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

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

// Формула наклонной границы Y = Y_SLOPE * (X - X_OFFSET)
#define X_OFFSET  80
#define Y_SLOPE   8ul/10

поменял X_OFFSET сначала на 120, а затем на 160 и просто каждый раз перекомпилировал прошивку. Таким образом, получил вменяемое распознование линии.

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

Спойлер

То что робот в конце "въехал в стену", произошло из-за того, что во-первых, я не сделал чтобы робот опознал зелёное поле (там чуть порог срабатывания надо бы еще понизить или больше подсветку изготовить - слишком низкие уровни), поэтому расстояние до стенки робот не измерял, в отличии от "красного" тупика. А во вторых, он остановился, там, где увидел конец линии (не на границе зелёного поля, а дальше) и после того как определил, что лабиринт изучен, выполнил "дежурный" выход из лабиринта - 10 см вперед.

Но, вообще, я на соревнования поехал с linefollower. Поехал только с одним роботом на STM32F071, тем, что начал делать весной 2020 года и который еще ни в одних соревнованиях не участвовал. Второго робота я не заявлял, так как не сделал ему хвост, так как снова загремел в больницу и просто не успел. Правда, первого робота я тоже не успел до ума довести. У этого робота на борту два контроллера - stm32F071 и BGM13. Делая ревизию кода stm32 выцепил одну ошибку в выборе скорости после прохода перекрёстков. Но эта трасса, при заданном направлении обхода, мне не позволила воспользоватся фичами, что я заложил в этот робот, так как длинные прямые куски трассы оказались очень далеко от "перекрёстков", чтобы я мог запрограммировать на них "форсаж".

Пока готовился, сделал так, что при обычных параметрах скорости робот проходил трассу. Поставил время работы робота 23секунды и за это время он смог накрутить два полных круга и еще чуть-чуть. Поэтому я принял, что круг будет проходить за 12 секунд (время ограничил 13 секундами) и в таком виде пустил в первый заезд. Первый заезд был 10.2 секунды. Ну раз есть хоть один результат, начал повышать скорость. Но, повысив скорость, робот начал ошибаться на перекрёстке - вместо проезда прямо выбирал левую ветвь. Увы, я перед соревнованиями не успел сделать ревизию для прошивки BGM13, которая у меня предназначена для связи с компьютером и я не мог считать журнал. Но, я понимал, что проблема в ПИД-стабилизации робота на линии. Поэтому чуть увеличил Kd - не очень помогло, а затем Kp - тогда на четвёртом заезде робот дошел до финиша за 9.8 секунд. Попытка на пятом заезде еще поднять скорость (не трогая коэффициенты ПИД) - снова вызвала ошибку на перекрёстке. И на этом все попытки были исчерпаны. Но это хорошо, что последний заезд был "сбойный" - сейчас я не торопясь могу заняться прошивкой BGM13, чтобы из памяти вытащить журнал последнего заезда и проанализировать сущность проблемы. По результатам был шестым из двенадцати (мой под номером 402) и впереди меня были только роботы из Литвы. Результат ожидаемый, так как к соревнованиям я подошел безалаберно - может, следовало поставить свежие батареи, но я оставил те, что уже были до половины ссажены (перед заездом я измерил - было всего 7.7в, а свежие - 8.4в) и сразу при подготовке надо было начать поднимать скорость, чтобы сразу подстроить ПИД коэффициенты. Ну ничего, через месяц будут еще соревнования. Надеюсь, теперь мой робот появится в таблице чемпионата и попробую снова побороться за переходящий приз для команды.

uldemir

Новое приобретение. Увидел сенсор цвета TCS3472x в новом конструктиве и мне захотелось его приобрести. Вообще-то меня соблазнило то, что там на плате два светодиода подсветки.

Заказал, получил. Монтирую на робот - робот его не видит. По запуску, робот инициализирует все компоненты и если есть проблемы, выдаёт иногда сообщение. Сейчас он стабильно выдавал "Отсутствие цветового сенсора". Начал думать, что снова началась эпопея, что была полтора года назад. Даже написал небольшой тест "I²C сканер". Он просто посылает команду чтения по заданному адресу и смотрит на получение ACK после передачи адреса. На экране получил: 0x29, 0x41, 0x59. Самый первый и есть цветовой сенсор. Почему же робот его не признаёт? Пошел в отладчик посмотреть, где сбой. А тут оказалось, что наличие этого сенсора проверяется по ID коду. Т.е. считывается регистр 0x12 и сравнивается значение с 0x44. А этот сенсор возвращает 0x4D. Читаем даташит и узнаём, что вместо сенсора TSC34725, поставлен сенсор TCS34727. Они различаются тем, что первый имеет i²c интерфейс привязанный к Vdd, а второй к 1.8в. Не знаю, насколько это критично, но после расширения допустимых кодов устройства при проверке в инициализации, сенсор заработал. И, возможно, из-за того что тут установлены другие светодиоды, этот сенсор начал видеть и синие цвета. Немного покалибровал, чтобы он нормально различал цвета на моих образцах - получилось неплохо.

Второе моё приобретение - получил нарезанный MDF для пола лабиринта. Из-за ограничений размеров лазерной резки, на куске 760х380мм я мог разместить только фрагмент 2х4 клеточки. Заказал 6 панелей, так что я могу собрать из этого паззла лабиринт 6х8. Или 12х4. А вот 16х3 сделать не могу ;-). Одну панель разделил пополам, так что могу поставить на стол себе маленький 2х2 лабиринтик.

Конечно, пол - это всего половина дела. Даже не половина - треть. Еще нужны стены и стойки. На лабиринт 6х8 надо 63 стоечки и стены числом от 63 до 112. Минимальное количество 63 получается из правил соревнований - к каждой стойке должа примыкать хотябы одна стенка (кроме финишного квадрата - там должна быть стойка без стен). А максимальное число 112 - это полностью закрытый лабиринт, где все ячейки закрыты. Стоечки я сейчас печатаю на 3D принтере. Думаю, одной катушки 750 грамм мне хватит на 100 стоечек. Так как печатаю с почти 100% заполнением, на 4 стоечки уходит 3 с половиной часа - но дело движется вперед. Хуже со стенками. Попробовал из остатков красного филамента напечатать рамы, которые предполагалось оклеить белой бумагой - но на принтере оно очень долго печатается и очень много уходит филамента. Пока я для себя так сделал 8 стенок, хотя для лабиринта 2х2 надо бы 9. Но чтобы изготовить сотню стен - надо будет искать столярную мастерскую, которая мне нарежет 12мм фанеру и сделает 2мм пропил с каждой стороны, куда я мог бы вклеить направляющую из оргстекла (они тоже были заказаны в лазерной резке и пришли вместе с полом). Ну и еще покрасить - пол черным, стены белым, кантики - красным. Хотя, у меня мечта изготовить полноразмерный лабиринт 16х16, для которого надо 289 стоек и от 289 до 544 стен. Может, мне удастся популяризировать этот вид соревнований у нас.

Тут, на следующей неделе будут еще одни соревнования, но, похоже, не для меня. Там из 18 видов соревнований не будет никакого лабиринта и даже следование по линии будет только для ЛЕГО. Поэтому, я сейчас притормозил с написанием прошивки для BGM13, чтобы вытащить лог-файл из робота. Чтобы не повредить журнал, я отлаживаюсь на других кристаллах, а перенос на реальное железо буду делать только в конце.

uldemir

Многие знания - многие печали. Подключился к linefollower роботу через блютус и посмотрел, что он видел во время неудачного заезда. Впрочем, я догадывался. На тех перекрёстках, где робот сворачивает "не туда" - он перекрёстка, как такового не видит. Собственно, об этом давно знал - вот в этом сообщении есть видео, где видна эта проблема.

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

Спойлер

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

08.060,....#...,7,256,20000,18000
08.062,....#...,7,256,20000,19908
08.065,....#...,7,256,20000,19908
08.067,....#...,7,256,20000,19908
08.070,....#...,7,256,20000,19908
08.072,....#...,7,256,20000,19908
08.075,....#...,7,256,20000,19908
08.077,....#...,7,256,20000,19908
08.080,....##..,7,394,20000,18000
08.082,....####,7,894,20000,18000
08.085,....####,7,1033,20000,18000
08.087,.......#,7,1792,20000,18000
08.090,........,7,2100,20000,18000
08.092,........,7,2100,20000,18000
08.095,........,7,2100,20000,18000
08.097,........,7,2100,20000,18000
08.100,........,7,2100,20000,18000
08.102,........,7,2100,20000,18000
08.105,........,7,2100,20000,18000
08.107,........,7,2100,20000,18000
08.110,........,7,2100,20000,18000
08.112,........,7,2100,20000,18000
08.115,........,7,2100,20000,18000
08.117,........,7,2100,20000,18000
08.120,........,7,2100,20000,18000
08.122,........,7,2100,20000,18000
08.125,........,7,2100,20000,18000
08.127,........,7,2100,20000,18000
08.130,........,7,2100,20000,18000
08.132,........,7,2100,20000,18000
08.135,........,7,2100,20000,18000
08.137,........,7,2100,20000,18000
08.140,........,7,2100,20000,18000
08.142,........,7,2100,20000,18000
08.145,........,7,2100,20000,18000
08.147,........,7,2100,20000,18000
08.150,........,7,2100,20000,18000
08.152,........,7,2100,20000,18000
08.155,........,7,2100,20000,18000
08.157,........,7,2100,20000,18000
08.160,........,7,2100,20000,18000
08.162,........,7,2100,20000,18000
08.165,........,7,2100,20000,18000
08.167,........,7,2100,20000,18000
08.170,........,7,2100,20000,18000
08.172,........,7,2100,20000,18000
08.175,........,7,2100,20000,18000
08.177,........,7,2100,20000,18000
08.180,........,7,2100,20000,18000
08.182,........,7,2100,20000,18000
08.185,........,7,2100,20000,18000
08.187,........,7,2100,20000,18000
08.190,........,7,2100,20000,18000
08.192,........,7,2100,20000,18000
08.195,........,7,2100,20000,18000
08.197,........,7,2100,20000,18000
08.200,........,7,2100,20000,18000
08.202,........,7,2100,20000,18000
08.205,........,7,2100,20000,18000
08.207,........,7,2100,20000,18000
08.210,........,7,2100,20000,18000
08.212,........,7,2100,20000,18000
08.215,........,7,2100,20000,18000
08.217,........,7,2100,20000,18000
08.220,........,7,2100,20000,18000
08.222,........,7,2100,20000,18000
08.225,........,7,2100,20000,18000
08.227,........,7,2100,20000,18000
08.230,........,7,2100,20000,18000
08.232,........,7,2100,20000,18000
08.235,........,7,2100,20000,18000
08.237,........,7,2100,20000,18000
08.240,........,7,2100,20000,18000
08.242,........,7,2100,20000,18000
08.245,........,7,2100,20000,18000
08.247,........,7,2100,20000,18000
08.250,........,7,2100,20000,18000
08.252,........,7,2100,20000,18000
08.255,........,7,2100,20000,18000
08.257,........,7,2100,20000,18000
08.260,....####,7,1036,20000,18000
08.262,...#####,7,764,20000,18000
08.265,.#######,7,365,20000,18000
08.267,########,7,83,20000,18000
08.270,###.....,7,-1292,20000,18000
08.272,##......,7,-1578,20000,18000
08.275,#.......,7,-1792,20000,18000
08.277,........,7,-2100,20000,18000
08.280,........,7,-2100,20000,18000
08.282,........,7,-2100,20000,18000
08.285,........,7,-2100,20000,18000
08.287,........,7,-2100,20000,18000
08.290,........,7,-2100,20000,18000
08.292,........,7,-2100,20000,18000
08.295,........,7,-2100,20000,18000
08.297,........,7,-2100,20000,18000
08.300,........,7,-2100,20000,18000
08.302,........,7,-2100,20000,18000
08.305,........,7,-2100,20000,18000
08.307,........,7,-2100,20000,18000
08.310,........,7,-2100,20000,18000
08.312,........,7,-2100,20000,18000
08.315,........,7,-2100,20000,18000
08.317,........,7,-2100,20000,18000
08.320,........,7,-2100,20000,18000
08.322,........,7,-2100,20000,18000
08.325,........,7,-2100,20000,18000
08.327,........,7,-2100,20000,18000
08.330,........,7,-2100,20000,18000
08.332,........,7,-2100,20000,18000
08.335,........,7,-2100,20000,18000
08.337,........,7,-2100,20000,18000
08.340,........,7,-2100,20000,18000
08.342,........,7,-2100,20000,18000
08.345,........,7,-2100,20000,18000
08.347,........,7,-2100,20000,18000
08.350,........,7,-2100,20000,18000
08.352,........,7,-2100,20000,18000
08.355,........,7,-2100,20000,18000
08.357,........,7,-2100,20000,18000
08.360,........,7,-2100,20000,18000
08.362,........,7,-2100,20000,18000
08.365,........,7,-2100,20000,18000
08.367,........,7,-2100,20000,18000
08.370,........,7,-2100,20000,18000
08.372,........,7,-2100,20000,18000
08.375,........,7,-2100,20000,18000
08.377,........,7,-2100,20000,18000
08.380,........,7,-2100,20000,18000
08.382,........,7,-2100,20000,18000
08.385,........,7,-2100,20000,18000
08.387,........,7,-2100,20000,18000
08.390,........,7,-2100,20000,18000
08.392,........,7,-2100,20000,18000
08.395,........,7,-2100,20000,18000
08.397,........,7,-2100,20000,18000
08.400,........,7,-2100,20000,18000
08.402,........,7,-2100,20000,18000
08.405,........,7,-2100,20000,18000
08.407,........,7,-2100,20000,18000
08.410,........,7,-2100,20000,18000
08.412,........,7,-2100,20000,18000
08.415,........,7,-2100,20000,18000
08.417,........,7,-2100,20000,18000
08.420,........,7,-2100,20000,18000
08.422,........,7,-2100,20000,18000
08.425,........,7,-2100,20000,18000
08.427,........,7,-2100,20000,18000
08.430,........,7,-2100,20000,18000
08.432,........,7,-2100,20000,18000
08.435,........,7,-2100,20000,18000
08.437,........,7,-2100,20000,18000
08.440,........,7,-2100,20000,18000
08.442,........,7,-2100,20000,18000
08.445,........,7,-2100,20000,18000
08.447,........,7,-2100,20000,18000
08.450,........,7,-2100,20000,18000
08.452,........,7,-2100,20000,18000
08.455,........,7,-2100,20000,18000
08.457,........,7,-2100,20000,18000
08.460,........,7,-2100,20000,18000
08.462,........,7,-2100,20000,18000
08.465,........,7,-2100,20000,18000
08.467,........,7,-2100,20000,18000
08.470,........,7,-2100,20000,18000
08.472,........,7,-2100,20000,18000
08.475,........,7,-2100,20000,18000
08.477,........,7,-2100,20000,18000
08.480,#.......,7,-1792,20000,18000
08.482,#.......,7,-1792,20000,18000
08.485,##......,7,-1540,20000,18000
08.487,.#......,7,-1280,20000,18000
08.490,.##.....,7,-1106,20000,18000
08.492,..#.....,7,-768,20000,18000
08.495,..#.....,7,-768,20000,18000
08.497,...#....,7,-256,20000,18000
08.500,...#....,7,-256,20000,19908
08.502,...##...,7,-21,20000,18000
08.505,....#...,7,256,20000,18000
08.507,....#...,7,256,20000,19908
08.510,....#...,7,256,20000,19908
08.512,.....#..,7,768,20000,18000
08.515,.....#..,7,768,20000,18000

В 8.09 линия пропала в правой стороне, и значение ошибки достигло 2100 (4 поле) и робот продолжает двигаться вправо. В 8.26 - 8.275 робот видит перпендикулярную линию, которая ушла влево и значение ошибки стало отрицательное -2100 и робот начал двигаться влево. А затем в 8.48 он находит линию и начинает по ней выравниваться.

Можно было бы такие "огрызки" линии игнорировать, но, а если там не перекрёсток, а два поворота формирующие букву "Z"? и действительно, надо было поворачивать влево? Вот как на этой трассе после "петли" две ступеньки:

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

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

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

Правда с выкачиванием данных тоже не всё идеально. Первая ошибка в том, что не предусмотрел цепи rts/cts - уже не помню, может из-за того, что выводы у stm32f071 не мог назначить. И поэтому, в терминале, некоторые строки были "рваные". Чтобы от этого избавиться, сделал задержку 10мс между выдачей строк и получил красивый вывод. Но чуть позже обнаружил, что в экселе число строк не совпадает с временными метками. Сделал анализ - 6 выпадений по 2 строки из 5204 строк. Причем распределение этих "выпадений" не равномерное. Ну тут, вероятнее всего, уже bluetooth виноват - write without response.

А так как снова начал заниматься BT, то случайно наткнулся на app inventor и пытаюсь что-нибудь накропать, чтобы управлять роботом, через планшет. Соединение с роботом уже сделать получилось, теперь хочу реализовать получение уровня батареи и старт/стоп робота. Жаль только, что этот инвентор онлайновый и при моём стиле жизни, когда я часто нахожусь в оффлайне с ним не поработаешь. А если поработаешь, то при появлении интернет соединения - "вы теряете набранные очки и переходите на клетку 1".

uldemir

Тут некоторое время назад набрёл на один проект. Я об этом проекте уже давно читал, но не думал, что он лежит в открытом доступе. А оказалось, что всё доступно. Это проект робота для лабиринта начального уровня UKMARSBOT. (UKMARS is the United Kingdom Micromouse and Robotics Society). Там есть его описание конструкции и принципов работы, а на GitHub есть проект Питера Харрисона простенького решателя лабиринтов. Немного поизучал и решил попробовать перестроить управление своим роботом.

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

Спойлер

Мне очень понравился вывод из описания проблем, связанных с движением робота с сайта micromouseonline.com:

So, the whole of physics is conspiring against you. Your mouse doesn’t want to move, when it gets moving you have to keep at it or it will stop and yet when you want it to stop, it tries to keep going. Imperfections in everything means that the conditions change constantly and nothing seems to go where you pointed it. Turning corners is at least as bad as trying to go in a straight line.

- все физические законы сговорились против вас!

А это непременное условие, если хочется ехать по лабиринту без особых ориентиров, навроде линии на полу. В этом роботе, задаётся не скорость, а позиция, где в каждый момент времени должен находиться робот. Из-за этого вычисления в профайлере становятся довольно сложными. Ну не очень сложными - на уровне физики для 6 класса школы: S=v0t+at²/2, но так как нужно рассчитать эту позицию с шагом 2мс, при этом шаги энкодера с этим шагом получаются тоже далеко не целые числа, то... я не знаю, считать в нанометрах? В UKMARSBOT считают в метрах, но с использованием плавающей запятой (и это на восьмибитной ардуине). Но сколько я понимаю, самый критический момент в этом роботе обработка прерываний от энкодеров - шаги энкодера считаются программно, на каждый тик вызывается прерывание и каждое колесо может до десятка прерываний сгенерить за миллисекунду и они самые критичные куски по времени исполнения.

В этом плане, можно бы построить аналогичного робота на ERM/EFR32 - там полно квадратурных счетчиков, значение которых можно легко защелкнуть в регистрах захвата. Но пока, чтобы оценить как там всё это работает, я решил повторить этот проект для себя так как он есть. Сам проект задумывался как максимально простой для повторения - минимум компонентов и все детали выводные для облегчения монтажа. Но искать-покупать все необходимые номиналы резисторов мне как-то не хотелось. Для себя я купил на алиэкспрессе SampleBook с smd резисторами - там все номиналы, так что если понадобится - их оттуда можно взять, а те что перерасходуются, буду докупать по мере надобности. Поэтому, я переработал плату под детали поверхностного монтажа и под колёса какие у меня были. Ещё я старался уйти от толпы проводов к двигателям и энкодерам. Трухольные детали у меня всё же присутствуют - кнопки, свитчи и на плате сенсоров резисторы 33 Ом, транзистор и электролит. Драйвер двигателей запаял выпаянный из другого робота. В общем, пытался максимально использовать то, что есть под рукой. А того что нет - заказал на дигикее. Вот только тут я сделал большую ошибку. Поставил галочку, чтобы весь заказ пришел разом. Там были две позиции backordered. Но планируемый срок поставки был 11 апреля для драйверов двигателей (на будущее решил закупить) и 21 марта для парочки транзисторов. Так вот драйвера появились на месте раньше срока, а транзисторам срок передвинули с марта на июнь. И вот я остался без деталей. Пришлось часть купить по-быстрому на TME. Но светодиодов и фототранзисторов для сенсора стен там нет. Ну так как плата сенсоров у меня сменная, для начала спаял плату с излучателем и приёмником из демонтированного датчика дыма (где-то год назад у нас меняли на работе противопожарную систему и я из мусорника как раз три датчика прихватил на всякий случай). Когда придут кошерные светодиоды и фототранзисторы запаяю их в другую плату.

Вот как выглядит оно в сборе:

Даже логотип оригинальный оставил на месте :-)

Конечно, есть некоторые расхождения с "оригигальным" проектом. В оригинале, используются моторы с редуктором 1:20 (у pololu таких нет - я поставил 1:30), колёса стандартные от pololu 32мм, а я поставил свои с отлитыми "покрышками" из силикона диаметром около 39мм (шаг где-то 124-125мм). Разумеется, литиевый аккамулятор в формате "кроны" покупать не стал, а буду использовать тот, что у меня есть - надо только еще какой фиксатор для этой батарейки соорудить (хотя батарейка и так держится).

p.s. облом. Попытался включить - что-то не шло. заметил, что на линии +5в - 7 с лишним вольт. Кажется, на моей ардуиновской плате сдох стабилизатор напряжения. Выпаял. Смотрю, о, валяется похожая LDO из разобранного недавно робота. Запаял, включаю, меряю напряжение на линии +5в. А там только 3,3. Ой, черт! у меня же давно всё на 3,3 вольта переведено. И таких 5 вольтовых стабилизаторов у меня нет. Откладываем.

uldemir

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

Трасса имеет такую конфигурацию - старт слева у желтой полоски и вперед. Заявил на соревнования два робота - по задумке, одному (на stm32f071) полагалось занять первое место, а второму (на PSoC5), если будет возможность, потеснить конкурентов еще вниз :-). Поставил первого работа на трассу - он совершенно не видел линию, когда она была ровно между сенсорами. Но это не большая проблема - просто подогнул скобку, задающую расстояние сенсоров от поверхности - увеличил расстояние и всё стало в норме - трасса стала хорошо различима. Первый пуск (с параметрами оставшимися с предыдущего соревнваняи) был не удачный - на первом же повороте робота занесло и он улетел с трассы куда-то далеко. Поэтому пришлось снизить скорость с 20000 единиц до 15000 (эти единицы в ширине импульса PWM двигателя - максимальное 32768). Тогда робот прошел трассу и я пошел в класс, где нам было выделено место для подготовки, чтобы считать журнал и подумать что с этим можно сделать. Журнал считал, но не вижу показаний одометра робота. Подумал, что не уследил, где у меня меняются поля для массива журнала и решил задействовать для надёжности другие поля. Скомпилировал, беру JLink, подключаю к роботу, нажимаю "программировать", а в ответ сообщение об ошибке. Дёргался-дёргался, оказалось, не в тот разъём робота программатор воткнул - подключился к разъёму программирования BGM13 - блютуз модуля. Когда сообразил, переткнул кабель и всё записалось без проблем. Снова пошел на трассу, проехал, и пошел читать журнал. В этот раз данные считались нормально - значение позиции робота вижу. Начал в тетрадке размечать значение позиции в характерных местах. А тут смотрю, что номер индекса выбора скорости не верный. На участке до первого перекрёстка индекс может быть от 0 до 6, а вот уже "7"! Отмотал журнал назад - да, один из поворотов робот опознал как перекрёсток:

Спойлер

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

02.255,......#.,0,1280,2777,0
02.257,......##,0,1425,2778,0
02.260,......##,0,1460,2780,0
02.262,......##,0,1467,2781,0
02.265,....####,0,1114,2782,0
02.267,...#####,0,905,2785,0
02.270,...#####,0,759,2786,0
02.272,..######,0,513,2787,0
02.275,.#######,0,358,2788,0
02.277,.#######,0,226,2790,0
02.280,########,0,32,2791,0
02.282,########,0,-90,2793,0
02.285,#####..#,0,-922,2795,0
02.287,####....,7,-1187,0,0
02.290,###.....,7,-1357,1,0
02.292,###.....,7,-1425,2,0
02.295,##......,7,-1578,3,0
02.297,##......,7,-1603,4,0
02.300,##......,7,-1651,6,0
02.302,#.......,7,-1792,6,0
02.305,#.......,7,-1792,8,0

Так как было несколько отсчетов, где сработали все сенсоры - алгоритм воспринял это как перекрёсток. Но, я пока решил ничего по этому поводу не предпринимать, так как надо пользоваться заложенными фичами моего "секретного оружия". Т.е. я могу роботу дефинировать "ожидаемый перекрёсток" или нет. Так как реальный перекрёсток находится от начала трассы на расстоянии 7.3 метра, А этот "казус" произошел на расстоянии 2.79 метра (предпоследнее поле лога). Правда, для выяснения правильного расстояни до перекрёстка мне пришлось к показаниям лог-файла добавлять "2795", так как после "перекрёстков" расстояние обнуляется. Поэтому я объявил первые 7 метров первым участком на котором перекрёстки не возможны, а далее определил участок длиной 65,535 метров - на котором уже перекрёсток ожидаем. На следующим участке за перекрёстком определил один участок, где можно было бы разогнаться - там есть 1 метр прямой линии, но пока скорость оставил такую же как и на всех остальных участках. Так же и в самом конце где "финишная прямая" тоже объявил участок, но пока не объявлял, что там нужно включить форсаж. Это я оставил на случай, если у кого-то из участников окажется лучшее время, чем у меня и мне придётся вытаскивать из рукава козырной туз.

Пока бегал, "консоль программирования" - печатная плата с OLED дисплеем и 3 кнопками, засунул в задний карман штанов и когда садился, чувствую, что-то тама хрустнуло. Вытаскиваю из кармана, да - треснул кусочек стекла OLED дисплея. Ну ничего, на худой конец, можно роботов и с командной строки конфигурировать. Но я был взявши с собой старую "консоль". Хоть и на старой консоли для кнопок стоит другой расширитель портов i²c, все роботы умеющие работать с новой, могут работать и со старой консолью. Так что отделался лёгким испугом.

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

Спойлер

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

>dump_log
00.000,...##...
00.001,...##...
00.002,...##...
00.003,...##...
00.004,...##...
00.005,...##...
00.006,...##...
00.007,...##...
00.008,...##...
00.009,...##...
00.010,...##...
00.011,...##...
00.012,#..##...
00.013,##.##...
00.014,##.##...
00.015,##.##...
00.016,##.##...
00.017,#####..#
00.018,#####..#
00.019,#####..#
00.020,#####..#
00.021,#####..#
00.022,#####..#
00.023,########
00.024,########
00.025,########
00.026,########
00.027,########
00.028,########
00.029,########
00.030,########
00.031,########
00.032,#####.##
00.033,#####..#
00.034,#####..#
00.035,#####..#
00.036,#####..#
00.037,#####..#
00.038,#####...
00.039,##.##...
00.040,##.##...
00.041,#..##...
00.042,...##...
00.043,...##...
00.044,...##...
00.045,...##...
00.046,...##...
00.047,...##...
00.048,...##...
00.049,...##...
00.050,...##...
00.051,...##...
00.052,...##...
00.053,#..##...
00.054,##.##...
00.055,##.##...
00.056,#####..#
00.057,########
00.058,########
00.059,########
00.060,########
00.061,########
00.062,########
00.063,########
00.064,########
00.065,########
00.066,########
00.067,########
00.068,########
00.069,########
00.070,########
00.071,########
00.072,########
00.073,########
00.074,########
00.075,########
00.076,########
00.077,########
00.078,########
00.079,##.#####
00.080,##.###..
00.081,#...##..
00.082,....##..
00.083,....##..
00.084,....##..
00.085,....##..
00.086,....##..
00.087,....##..
00.088,....##..
00.089,....##..
00.090,....##..
00.091,....##..
00.092,....##..
00.093,#...##..
00.094,##..##..
00.095,##..##.#
00.096,##..##.#
00.097,##..##..
00.098,##.###.#
00.099,##.#####
00.100,########
00.101,########
00.102,########
00.103,########
00.104,########
00.105,########
00.106,########
00.107,########
00.108,########
00.109,########
00.110,########
00.111,########
00.112,##.###.#
00.113,##.###..
00.114,#...##..
00.115,....##..
00.116,....##..
00.117,....##..
00.118,....##..
00.119,....##..
00.120,....##..

Робот 3 раза задирает нос, так что ничего не видит. Но. Эта комбинация программой определяется как перекрёсток (или даже несколько перекрёстков, так после первого перекрёстка на несколько фреймов или 5 см блокируется распознавание, чтобы один перекрёсток не "размножился"). А еще в программе определено, что после превышения максимального числа перекрёстков (вроде 8), считается, что трасса закончилась и пора остановиться. Поэтому пришлось выкручивать винт хвоста по максимуму, чтобы робот нос не задирал.

Когда начались соревнования, пошел зарегистрировался и пустил роботов по трассе. Один прошел нормально, а второй, как уже упоминал - остановился через пару метров. Судья, сказал, что я могу повторить попытку, но я отказался, сказав, что это было запланировано и пошел в класс считывать логи, чтобы выяснить вышенаписанное. По пути, разбирался как можно подключиться к странице с результатами, чтобы быть в курсе, у кого какие результаты. А тут встречаю гулбенского коллегу/соперника, который заявляет, что я его обогнал на целую секунду и он идёт делать еще попытку (но ему так и не удалось обогнать моего робота). Ну я посмотрел таблицу, увидел, что робот пока стоит на первом месте и решил его больше не пускать на трассу - надо оставить попытки про запас и стал разбираться со вторым роботом. После того как выкрутил упорный винт - робот смог пройти всю трассу, правда, результат был 20 секунд и он оказался на 4 месте. До третьего места мне нужно было бы вытянуть 5 с лишним секунд, но решил этого не делать, так как на третьем месте был школьник и решил пусть ему достанется приз хотя бы за 3 место как небольшая мотивация. Фотка на награждении получилась классная - один маленький мальчик в окружении двух дядек. Ничего - ему предстоит строить лучшее будущее.

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

Это в категории iRobot.

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

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

uldemir

Прошло последнее соревнование этого чемпионата. В соревновании следования по линии у школьников победитель чемпионата уже был определён и результат этих соревнований на то, кому достанется переходной кубок уже не влиял. Наверное, поэтому там было всего 5 участников. А вот в нашей группе (без ограничений на возраст) эти соревнования уже решали, кто в этот раз возьмёт кубок с собой. Правда, я не знаю, как бы судьи приняли бы решение, если бы гулбенский соперник занял бы первое место, а я второе - тогда по сумме трёх лучших результатов у нас было бы одинаковое количество очков. Интрига. Хотя из этих 7 роботов они принадлежали 4 командам: 2 из Гулбене, 3 прейльскому клубу роботики, один из Шауляя (тот кто меня "сделал" в декабре в лабиринте из линий) и один из Норвегии.

Если в 2019 году эти соревнования проходили в Рижском Техническом Университете в здании радиофакультета, то в этот раз нас направили в свежепостроенное здание факультета информатики (втиснули между радиофакультетом и химфаком. На месте бывшего полигона военной кафедры). Соревнования проходили на 3 этаже в помещении типа спортзала. Так что, первое что сделал, пошел посмотреть на трассу. Трасса такая же как и раньше была в РТУ:

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

Когда начались соревнования, сделал первые заезды и стал смотреть, какие результаты будут у других участников. В первом заезде гулбенский соперник не смог получить превосходство, но у него, оказалось, тоже был припрятан туз в рукаве. Несмотря, на то, что робот был сделан на скромном 8 битном атмеле 32U4, его робот в памяти тоже составлял образ трассы и мог менять скорость в зависимости от ожидаемой кривизны линии. Правда, была проблема, что из-за проскальзывания, пропадала синхронизация положения робота с таблицей и все хорошие задумки рушились. Поэтому он подстроил своего робота и второй результат его был хуже моего всего на 50 миллисекунд (7.5 против 7.454). Но его третья попытка побила мой результат. Теперь уже мне пришлось заняться разгоном робота. Шауляйский и норвежские роботы в это время всё никак не могли дойти до финиша.

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

У гулбенского соперника осталось всего две попытки, поэтому я просто стоял и смотрел, как он их потратит. Ему результат улучшить удалось, но обогнать моего робота он так и не смог. Так что я смог вздохнуть с облегчением - в этом году кубок достанется нам. Конечно, от других участников были "претензии", почему я ставлю своего робота на старт за полтора метра до стартовых ворот, но судья ответил, что правилами это не запрещено, но, возможно, в дальнейшем правила изменят, касательно этого пункта. Так как я уже ничего не терял, решил еще попробовать погонять своего робота. В тех заездах, где удавалось зафиксировать результат, удалось его улучшить еще на две десятых секунды. Правда, чтобы система на мой робот могла сработать, пришлось уменьшить величину "форсажа" до 75% мощности. Поговорил на эту тему с судьями и организаторами и тогда мне вспомнилась аналогичная ситуация с micromouse роботами, что я читал на micromouseonline.com. Там тоже один из роботов был настолько быстрым, что во время квалификации очень быстро пролетал финишный створ. Поэтому, они решили, что на самом соревновании лабиринт сделают так, что вход в финишную клетку будет после поворота, чтобы робот был вынужден в том месте сбавить скорость. Поэтому, я тоже сказал, что можно было бы ворота поставить с другой стороны от прямого участка.... но так как трасса полность симметричная, я сказал, а давайте я попробую проехать в обратном направлении. Правда, когда до этого дошло, я уже был разобравши робота и упаковал его в транспортное положение. Поэтому, когда я его вытащил у него уже не было "флажка" и он так и так для сенсора был не видим и результат зафиксирован не был (хотя у меня оставалась еще одна попытка). Но я заметил, что мой конкурент заснял этот проезд и я попросил его поделиться видео, а то мне никак не удаётся заснять проход роботом трассы. Ну и вот результат:

Спойлер

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

p.s. добавил одну фотку.

uldemir

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

Так вот насчет оживления. Для проверки функционирования узлов, там же на GIThub-е есть проект ukmarsbot-examples. Там 10 скетчей с которыми можно проверить робота покомпонентно . Вот первый тест и открыл мне глаза на то, что стабилизатор дохлый, как раз измерение напряжения батареи. Когда разобрался со стабилизатором - всё пришло в норму. Следующий тест - переключатели. Они включены в резистивную матрицу и так же опрашиваются АЦП. Хм, помогло выявить один резистор не правильного номинала - впаял 47 ом вместо 470. Правда и в скетчах нашел ошибку - один из тестов мотора выполнялся не правильно - в программе пропущен был знак минуса. Оформил issue. А вот с энкодерами я накосячил. Сделал две грубейшие ошибки - не развёл резисторы подтяжки и цепь питания оставил под названием Vdd и она, естессно, с цепью +5v не соединилась. Пришлось на ноги напаивать резисторы (0603 как раз умещаются между ногами sot23) и бросать проводок питания.

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

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

Спойлер

Собственно у меня было так же: в Сигулде с разряженными батарейками и скрости "20000", робот нормально шел по трассе, а в Даугавпилсе, когда поставил свежие батарейки, робот, при тех же установках, улетел с трассы. Так что если бы я в Сигулде сменил батареи перед заездом на результат - был бы большой облом.

p.s. Вообще-то, это не совсем так. Тут скорее сыграла роль поверхность трассы: разные трассы - разные материалы. Тут уже как у профессионалов надо делить на "быстрые трассы" и "медленные". Вот в Сигулде и RTU - там быстрые трассы, так как у них хорошее сцепление с колёсами.

Тем не менее, пора мне тоже вводить line regulation для моторов, чтобы не быть зависимым от состояния батареи. Во всяком случае, я начал это реализовывать у RSLK робота и лайнфолловера. Роботу на шасси Zumo это делать нет смысла, так как там двигатели питаются от стабилизированного напряжения.

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

Для всего этого достаточно знать два параметра двигательной системы - коэффициент усиления (какая скорость устанавливается в зависимости от поданного напряжения) и постоянная времени (когда достигается 63% от установившейся скорости). Из этих двух параметров можно вычислить третий - производную в нулевой точке и этого уже достаточно для реализации Feed Forward. Нет, там есть еще третий параметр - смещение. Какое напряжение еще не вызывает движение. А затем выбрав еще два параметра damping ratio и settling time - можно рассчитать пропорциональный и дифференциальный коэффициенты ПИД контроллера.

Конечно же снова попробовал эту технику применить на RSLK роботе, но опять упёрся в то, что с таходатчика начинают приходить ложные срабатывания. Причем, на этот раз заметил уже такую закономерность, что до 3 вольт, подаваемых на двигатели, ложных срабатываний нет. А вот 3 и выше - появляются. Т.е. пока робот движется медленно - всё в порядке. И никак не могу понять, кто вызывает эту проблему! Если снять магнитный диск - нет ни одного отсчета. Т.е. с обмоток ротора на датчики холла прямого влияния нет. Выносил мотор на длинных проводах - особых изменений нет. Уменьшил сопротивление резисторов подтяжки датчиков холла - не помогло. Если вместо родного подключить на эти же длинные провода мотор micrometal с энкодером - сбоев нет. Если крутить колесо руками - сбоев нет. И не понимаю, почему проблема только на правом двигателе. Еще порылся по интернету и выяснилось, что у этого двигателя номинальное напряжение 4.5в (у micrometal - 6в, но они нормально идут и при 6.75 вольтах). Очень похоже на сумму каких-то факторов, которые не могу идентифицировать. Но, пока во всех случаях присутствует этот мотор.

Еще для идентификации проблемы сделал второго такого же робота (у меня есть два комплекта шасси и два ланчпада. Нужно было добавить модуль с FRAM для записи журнала) - симптомы такие же, но работает чуть получше. Ну вот снял характеристики (это на втором роботе и видно, что при питании 3,5в зафиксирован 1 "всплеск", на 4в нет, а на 4.5 - целая толпа):

Коэффициент усиления 160 мм/с на вольт, со смещением в полвольта. Постоянная времени около 100 миллисекунд.

Попутно готовлюсь так же снять характеристики и с остальных роботов.