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

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

Пн янв 20, 2020 22:35:59

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

Для проверки, подумал, что если я задам стоимость поворота равной нулю, то должен получить предыдущий результат. Правда, тут я испугался. Если у меня четные-нечетные узлы все связаны нулевым ребром, то алгоритм генерирования пути может взять и там зациклиться, ведь 0 всегда 0. Но, я в структуре данных сделал так, что этот вариант проверяется последним. Т.е. пришли мы в узел 46 (четный - значит меридианальный и пришли мы в него с юга). Проверяем путь на север (там ничего нет), юг (мы оттуда пришли и там высота больше текущей) и раз уж ничего не осталось делаем "поворот" - переход на ячейку 47 (нечетную - широтного направления). И уже там снова проверяем восточное направление и западное. До третьей позиции нам надо уже уйти дальше (обычно так и происходит), иначе мы зациклимся - вернёмся на 46-ю ячейку. В общем, прошелся под отладчиком, пока ошибок не нашел. Сделал тестовый запуск - получил предыдущий результат. Тогда решил немного задрать стоимость прохода через узел и стоимость поворота. Хм, получился другой маршрут:
Изображение
Всего на 2 клеточки длиннее предыдущего, но поворотов на 4 меньше, так что робот потратит времени тоже меньше.

А! Стоимость прохода через узел я просто приплюсовываю к длине примыкающего к узлу ребра.

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

Ср янв 29, 2020 21:30:41

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

Конечно, тут я еще выяснил неприятную новость. У робота я делаю два параметра: минимальную скорость и максимальную. Минимальная - это скорость до какой скорость робота может снижаться, если отклонение от линии больше некоторого предела. Если отклонение меньше (робот стабилизирован), то робот ускоряется до максимальной. Поэтому я на заездах увеличиваю максимальную скорость, с каждым заездом, пока робот не начнёт "срываться" - когда скорость настолько большая, что робот уже не может "вписаться" в повороты. Однако, сделав первые два заезда, заметил, что второй заезд с увеличенной максимальной скоростью дал худшее время. И тут меня осенило. Оказывается, что робот идёт по трассе с минимальной скоростью, а условия для разгона, почему-то не возникает. Тогда, я следующие два заезда сделал с приподнятой минимальной скоростью, что позволило улучшить время с 15.6 до 13.9 сек, что, конечно, все равно было далеко до лучших результатов. Пятую попытку я не смог сделать, так как закончилось время соревнований. Тут надо бросить камешек в огород организаторов. Раз уж ограничили число попыток, то следовало бы обеспечить доступность трассы до тех пор, пока все не сделают свои пять попыток или больше не будет желающих.

По официальной статистике в этом году роботов прибавилось - в прошлом году было 350, в этом 390. Приехала сильная команда из Белоруссии. В LineFollower они хорошо потеснили литовские команды. (хотя среди школьников первое место осталось за литовцами, белорусы взяли второе и третье места). Что происходило с сумо-роботами - я не следил.

Попытался выяснить, почему такая засада получилась. Пока из идей только то, что интервал работы контроллера двигателя в 10 раз больше, чем интервал работы общего контроллера. Поэтому, пока для начала увеличил частоту PWM двигателей с 9.5мс до 5.461мс. Хотел еще увеличить диапазон и разрешающую способность таходатчиков... но наступил на какие-то грабли. Столкнулся со странным поведением компонента Timer (в PSoC5). если его, ничего не меняя, поменять с Fixed Function на UDB - среди захваченных значений начинают проскакивать совершенно дикие числа. Вот два графика сделанные в одинаковых условиях. Только в одном случае таймер FF, в другом UDB. Код тоже в обоих случаях один и тот же.
Изображение
код:
На графике отображается результат XprimeR = (Right.Period) ? (720000000/CPR)/Right.Period : (720000000/CPR)/65536; (CPR = 6)
О, а вот теперь я не понимаю, откуда у меня там могут быть нулевые значения. Потому как, если период равен 0, то всё-равно должно получиться 1831. В общем, надо опять думать.

p.s. Ага, "нули" из-за получившегося интервала в виде FFFFxxxx:
Всё-равно не понятно, откуда берутся такие числа.

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

Пн фев 03, 2020 08:00:06

Удалось побороть появление странных значений в регистре захвата. Оказалось, что причина в том, что импульс захвата шел прямо на компонент, а его следовало пропустить через "синхронизатор"
Изображение
Это компоненты Sync_4 и Sync_5. В результате, я поменял 16 битный счетчик на 32-х битный, тем самым избавившись от необходимости учитывать переполнение счетчиков, поднял тактовую в два раза и учитываю не только фронты, но спады. Состояние останова теперь отлавливаю путём контроля, было ли хоть одно событие от таходатчика между обращениями контроллера или нет. Если за 5.461мс не было - значит стоим.

Самое интересное, что PSoC Creator не выдавал никаких предупреждений, что в этом месте желательно входной асинхронный сигнал синхронизировать. Сначала я менял только схему и программу для правого колеса и сравнивал получаемые данные с левым - данные были боле-менее идентичные (графики имели похожие начертания) и только в конце переделал и левое колесо.

Конечно, в идеале, следовало бы сделать специальный компонент, который измеряет период самостоятельно, но пока мне не удаётся вспомнить где я видел описание или аппноту, как это делается.

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

Сб фев 15, 2020 13:05:43

Нашел аппноту по созданию компонентов AN82156. Там есть как создать счетчик, ШИМ, но нет про захват. Собственно, у меня есть мысль как сделать захват по уровню, но не могу сообразить, как сделать, по фронту и спаду. Хотя, это можно сделать внешними цепями. Но вникание в этот вопрос мне открыло глаза на другую проблему. В datapath получается, так, что результат попадает в четырёхуровневый FIFO. и вот вопрос, как из него вытащить самые свежие данные! Никак не могу понять строчку, куда попадают данные, если стек уже полный. Поэтому, пока отложил изучение этого вопроса - нужно еще этой затее по вариться. Зато, добавил проверку в драйвер, что из FIFO взяты последние свежие данные (на случай, если какое прерывание окажется пропущенным).

Так как с компонентом ничего не вышло, решил заняться получением данных. Для linefollower роботов пришла идея, что я могу на разъём куда подключаю конфигурационный пульт (i2c), на время прохода трассы насадить i2c EEPROM типа 24c512. У робота на PSoC я смог выделить 32 килобайта ОЗУ под буфер, которые по окончании прохода сбрасываются в эту микросхему. Которую я затем могу считать и заняться анализом. А вот для считывания в комп думал, приспособить самого робота. У него (у одного из двух собранных) есть USB разъём, вот я его и решил задействовать. Решил не напрягаться, а сделал USB-CDC. Правда не понял а какой PID у него должен быть? По умолчанию, если бросить в top design USB компонент, PID устанавливается равным 0xF232. Но виндовс драйвера с таким PID не находит. Даже скачанные с cypress.com не подходят. Там есть всякие PID, но такого нет. Подходят только те драйвера, что находятся в проекте в фолдере Generated Sources. Ну, пока поставил их.

Но как через этот UART общаться с роботом. Меня несколько впечатлило видео в 18-й лабе, где было сделано нечто на подобии форт-интерпретатора и решил, что сделаю себе тоже, что-то подобное. Конечно, у меня получился не чистый форт. Никакого шитого кода, никаких связных списков, даже длина слов ограничена. Ну и никаких возможностей построения новых слов на ходу. Впрочем, у Валвано этого тоже нет. Правда в видео подсмотрел как он сделал связанный список, но это проблему не решает - вне зависимости от длины слова в памяти у него выделяется 8 байт. Из арифметики пока реализовал только сложение (просто пока не вижу, зачем мне нужно что либо еще), но зато реализовал базовые фортовские конструкции работы со стеком и памятью: drop, dup, swap, @ и !. Вот вывод не сделал еще - сделал только вывод состояния стека в шестнадцатеричном виде. Зато сделал переключение системы счисления decimal, hex, bin. И завёл кучу переменных, которыми я конфигурирую робота. Вот пример:
Изображение
Первую команду что я ввёл, ввёл ошибочно, потому и получил от интерпретатора "Illegal command". Вторая "words" распечатывает все доступные команды (как в настоящем форте). Следующая, показывает ввод чисел в разных системах счисления и показывает состояние стека после выполнения этих команд - как цифирки "10" интерпретировались в зависимости от выбранной системы счисления. Далее словом "+" я взял два верхних (на экране - нижних) значения, просуммировал и результат положил на стек. Ну и последние команды показывают практическое применение: узнать значение переменной RunNumber и записать туда новое. Если я позднее выполню save_conf, то эти изменения сохранятся в eeprom. Ну и так я могу развивать словарь, постепенно вводя новые слова, которые будут делать то, что мне нужно. Кстати, на стеке видно число 0x20000858 - это адрес переменной RunNumber. Я его могу ввести и ручками. А вообще, ручками я могу ввести любой адрес и посмотреть что там и, даже, записать что-либо другое. Всё в соответствии с идеологией форт: полный доступ - никаких ограничений.

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

Но мне пока покоя не даёт мысль - как сливать данные с робота на stm32f051 - там, увы, озу всего 8 килобайт - буфер на 32к не сделаешь. И тут у меня возникла идея. А сколько времени надо, чтобы EEPROM записал страницу? может он успеет за 2.5мс записать? Хм, счастье было так близко - по даташиту время записи не превышает 5мс. Если бы успевал, я бы мог просто на каждый отсчет, раз в 2.5мс посылать один байт, а через каждые 128 посылок (размер страницы), посылать стоп для записи и в следующий отсчет продолжать писать следующую страницу. Но не выходит. И тут я подумал, а нельзя ли для stm32 сделать похожий драйвер i2c как я сделал в MSP432 - ведь тогда все действия будут проходить в прерываниях и не будет блокирующих циклов ожидания какого-либо флага. Сказано - сделано. Причем модуль в stm32f051 мне понравился больше, чем в msp432, наличием бита reload - благодаря этому можно передавать и принимать больше 255 байт за раз. правда, пока остался один неясный момент, который я не нашел в reference manual - нужно ли мне ручками передавать стоп, если при передаче адреса подчинённого устройства - его нет и, соответственно, нет бита подтверждения. Вопрос возник из-за того, что когда я отлаживал и у меня из-за того, что забыл прописать одну переменную, при рестарте передавался неправильный адрес и получал NAK - заметил, что выставлялся не только флаг NAKF, но и STOP. Ну с этим я разберусь позже.разобрался.

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

Вс фев 16, 2020 17:22:26

Шшшш. с последним вариантом получился облом. Так как у меня на борту там уже стоит одна EEPROM, где хранится конфигурация. Но у неё все "адресные" ноги сидят на земле, т.е. её адрес 0xA0. для журнального EEPROM, я напаял что адрес получился 0xA2. Всё было бы здорово... но в качестве конфигурационной ПЗУ напаял 24c16 - а она съела все 8 адресов.

Но за неделю до соревнований я ничего переделывать не буду.

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

Вс фев 16, 2020 22:07:07

Дааа, у Вас прогресс идёт семимильными шагами... Рад, что Вы вплотную приближаетесь к BGX. В последний месяц мне пришлось много поработать с модулем BG13 в совместном проекте с коллегой из другого универа. Также неделю назад представил к публикации на форуме статью по работе с RTOS. Сейчас в процессе работы над 3-й частью статьи по Bluetooth. К сожалению, BGX модули в ней не освещены, как и многое другое в плане Bluetooth, но зато будет показано портирование с демо-платы на модуль на примере несложного проекта. Не буду сковывать себя обещаниями написанием новых статей в обозримое время - в течении семестра времени на это у меня гораздо меньше.
Может Вам вместо 24с16 использовать FRAM память? У неё нет понятия постраничной записи, запись и чтение байта производятся быстрее, да и ресурс перезаписи гораздо выше.
Удачи на соревнованиях!

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

Пн фев 17, 2020 00:14:54

Прогресс не идёт, а ползёт. Вот, кстати, вопросы по которым у меня сейчас идут размышлизмы... и интересует мнение.

Про BGM я так понял, что я могу на её выход навесить i2c дисплей с кнопками и делать подключение к "клиенту" для его управления (вместо программирования андроида?) или это так же сложно как сделать USB хост.

Попутно есть вопрос, а BT протокол обеспечивает гарантию поступления пакетов и в правильной последовательности (как TCP в отличии от UDP) или нет? Это размышление на тему, если я хочу с робота на "пульт" передать карту могу ли я просто передать кучку блоков последовательно через одну характеристику или их надо "нумеровать"?

Ну и как опытные разработчики сделали бы модификацию конфигурационных переменных - для каждой переменной своя характеристика или просто две характеристики указатель на переменную(индекс)/значение.

Хе, почитал про FRAM - вкусно, но уж больно дорого.

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

Пн фев 17, 2020 06:03:24

Сделать Bluetooth Client несложно. Если никогда с Андроидом дел не имели, то однозначно проще. У меня в статье про разработку Клиента написано (Часть 1). В модуле имеется I2C драйвер и с этим проблем вообще никаких. Кнопки также не сложно, и про это тоже написано. Если я правильно понимаю, кнопками будет инициироваться передача комманд на сервер/робот, а приём от него информации отображаться на ЖКИ?
Bluetooth использует метод передачи stop-and-wait с подтверждением получения пакетов (если подтверждение заказано) и CRC, т.е. последовательность их гарантирована и нумеровать пакеты не нужно. Насчёт опытных не скажу, но объём передачи в каждой сессии ограничен. Я-бы передавал инфу на ЖКИ блоками с индексом первого байта в общем массиве (если речь идёт про передачу всего массива сразу, а не изолированных его значений) в одной характеристике. Если нет - уточните.

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

Вт фев 18, 2020 07:46:00

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

Ну эт тож чуть позже. Там надо плату придумать и еще припаять этот модуль. Я уже сейчас под впечатлением от припаивания BGX модуля.

Как-то припаял: залудил площадки, положил сверху модуль, а потом прехитером как-то прогрел. Ну во всяком случае TX-RX тестером с массой и питанием звонятся. Подавал питание - адвертисмент виден. Даже при помощи андроида на распберри проапгрейдил. Сейчас, снова штудирую сайты на предмет связывания обоих модулей. Правда, на робот буду ставить, только после соревнований, чтобы что-нибудь не поломать. p.s. Модули друг с другом связались без проблем. Теперь надо подумать насчет секьюрити.

Ха, литовцы сдержали обещание - их робот уже на соревнования заявлен. Так что не буду в гордом одиночестве.

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

Вт фев 18, 2020 22:12:59

Если приложение робота будет на MSP432 работать, а BGM модуль использоваться в качестве NCP, то придётся либо что-то типа SNP реализовывать на модуле или использовать на MSP библиотеку BGLib и задействовать UART для связи MSP432 с модулем BGM по протоколу BGAPI. В документации рассказано как это делать с картинками. Мне это пока не нужно было, но с удовольствием попробывал-бы.

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

Сб фев 22, 2020 21:07:55

Я планировал на роботе оставить для начала тексасовский бустерпак cc2560, потому как это я уже знаю и могу отладить. Чтобы хотя бы один конец работал. А вызывающую часть делать на BGM.

Ну вот, вернулся с еще одних соревнований. Роботов на лабиринт было заявлено 7, но утром, просмотрев список, заметил, что один робот исчез - так что в списке осталось 6 роботов: 3 робота из Литвы и 3 местных (позже посмотрел, что техинспекцию проходили только 5 роботов). Приехав и зарегистрировав участие роботов пошел посмотреть на трассу. В этот раз трасса была большая:
Изображение
По данным робота: 74 узла. Проверив, что сенсор линии видит линию нормально, цветовой - цвета различает, запустил робота на изучение лабиринта. По началу робот шел резво, дошел до красного квадратика, развернулся и пошел изучать все остальные проходы. Но в одном месте его "внезапно" развернуло. Начал изучать, что происходит. Оказалось, что на совершенно прямом участке робот опознаёт перекрёсток. А так как роботу была задана стратегия сначала выбирать прямой ход и только затем поворот при первом проходе робот просто проходил прямо и я не замечал проблемы. После локализации проблемного места начал изучать причины и варианты как решить проблему. Пытался регулировать яркость освещения, порог фотосенсора - ничего не помогало. Пока, спустя полтора с лишним часа не дошло, в чем суть проблемы. проблему вызывало то, что трасса имела "морщины". Если фотографию увеличить, то их можно увидеть. Но я же "привязал" фотосенсор к переднему шарику и он, вроде как должен "отслеживать" эти изменения рельефа и соответственно, поднимать или опускать сенсоры. Но оказалось всё иначе. Шарик "продавливал" эту морщину и центальные сенсоры линию видели отлично. А вот по краям, материал этой плёнки, наоборот, поднимался (наверное шарик его и выдавливал) и закрывал боковые фотосенсоры, давая ложную информацию. Еще некоторое время прошло, пока удалось найти решение, как обойти эту проблему и тогда робот смог пройти всю трассу и составить карту лабиринта в памяти:
Изображение
Однако, не у меня одного была проблема с этой трассой. Многие роботы пытались и многие роботы от борьбы отказались. В результате, участвовали два человека, с 3 роботами. У представителя шауляйской команды (телевизоры Шилялис все помнят? так вот их делали в этом городе) было два робота, один на АВР, второй на СТМ32. Вот АВРовский робот, что-то не пошел, поэтому результат дал только робот на stm32 микроконтроллере. Правда, там у него, как я понял, даже алгоритм прохода по правилу "левой руки" с удалением тупиков еще не был реализован, а просто в коде было записано со "срисованного" лабиринта последовательность поворотов. Но в правилах этот момент никак особо не оговорён. И так как это соревнование судила девочка, которой сказали фиксировать время и что робот должен пройти от туда до туда, то вопросов не возникало, как было у меня на соревнованиях в сентябре, когда нужно было показать, что маршрут выбрал робот а не я. Ну, результат оказался ожидаемым - литовский робот прошел трассу быстрее моего на две секунды (38,2 и 40,3). Так что у меня почетное второе (и последнее) место. Пока меня должна утешать мысль, что мой робот хоть и не быстрый, зато честный. Остальные роботы, хоть и прошли техинспекцию, трассу не проходили.

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

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

Сб фев 22, 2020 22:57:08

Про бустерпак понял, а с ним и Ваши намерения. Со своей стороны поставил BGM модуль на макетку с целью начать эксперименты с режимом NCP. Спасибо, что подвинули на это.
Про соревнования очень интересно пишите. Прямо роман. Читаю не отрываясь.
Ответить