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

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. Спасибо, что подвинули на это.
Про соревнования очень интересно пишите. Прямо роман. Читаю не отрываясь.

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

Пт мар 06, 2020 17:20:39

Ну у меня с макетками тяжко, если буду делать, то сразу готовое. Проблема сейчас - как сделать питание. На батарейках - разорюсь. На аккамуляторах - они будут дохнуть из-за редкого использования. Думал сделать SEPIC чтобы можно было воткнуть что угодно, но тут появилась мысль, что если использовать LiFePo аккамуляторы, то никаких стабилизаторов/регуляторов не нужно - они и так дают 3.2-3.3 вольта. Хотя на плате надо будет предусмотреть место для sepic.

Сейчас плотно взялся за блютус модули. Параллельно играюсь с HM-11 и BGX13. С BGX есть проблема. Всё работает хорошо, пока есть соединение. А вот пока его нет... Сделал так, что всё что BGX принимает идёт на командный интепретатор. И тут я заметил, что после установления соединения, мне на экран вываливается куча мусора и после этого всё работает нормально. Причиной оказалось то, что по включению модуль выдаёт строку [COMMAND_MODE], которую интерпретатор повторяет эхом. После чего мой интерпретатор говорит, что это Illegal command, а BGX - Unknown command. на что они начинают друг на друга ругаться, так как и эти команды они не понимают. Перед этим я периферийному модулю уже попытался все сообщения отключить командами set sy p 0 и set sy c p 0. Но как отключить это певое сообщение так и не нашел. Перед этим пытался не давать поток на интерпретатор, пока не придёт строка STREAM_MODE, но проблемы начинались после отключения (тогда еще надо вылавливать COMMAND_MODE?). Хотя я могу вылавливать теперь эту строчку, а остальное пускать на интерпретатор.

p.s. почесал тут репу и понял, что самое лучшее было бы вывести на порт состояние command/stream командой gfu 1 str_active и опрашивать его. Так как я собирался при запуске других задач кидать телеметрию в порт, а если в этот момент связь оборвётся? Тогда вся эта телеметрия начнёт забивать буфер BGXа. Так что надо будет как нибудь подпаяться проводком к площадке под BGX-ом.

p.p.s. Удалось подпаяться. Правда, по началу не шло, так как перепутал, который BGX конфигурировал и удивлялся, почему ничего не работает.



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

Про эти соревнования мало написал, так как всё время потратил на решение проблем. А так как в этот раз нас разделили по трём разным помещениям: свободные конструкции были в актовом зале, Лего - в спортзале, а дроны были в ангаре, то я так и не сходил до участников других типов роботов. Даже толком не увидел как проходят соревнования folkrace (в том же зале). Там немного поменяли правила. Перед соревнованиями роботы должны были совершить квалификационный заезд. Т.е. в одиночку без помех со стороны других участников сделать один круг по трассе. Если этот круг выполнить не могли - дисквалификация. Затем, с учетом затраченного времени на заезд роботы делились по группам и начинались соревнования в группах, а затем победители этих групп уже соревновались между собой. Кстати, время урезали - было 3 минуты, теперь на наворачивание кругов даётся всего 2 минуты из которых первые пять секунд роботы должны стоять (хм, где логика?).

Еще не писал, но я всё же попытался снять данные с робота бегущего по линии. Первый заезд сделал без журналирования, а потом я про него вспомнил и нацепил EEPROM на робота. После каждого заезда перетыкал эту EEPROM на робота с USB гнездом и считывал через putty с включенной записью. Правда, когда приехал домой и стал искать эти файлы... файлы не нашел. В Recent Items они есть - т.е. мне это не приснилось, но на диске их нет. Наверное, в торопях, что-то не правильно делал с putty. Поэтому доступным остался только лог самого последнего заезда. Сейчас вот думал, а не применить ли какое другое средство для просто считывания EEPROM. Помнится, у JDM программатора была такая способность.... но где сейчас JDM и где 12 вольтовые COM-порты? Поэтому, порылся на предмет PICkit3. Вроде, такая возможность есть. Надо только найти куда я этот программатор засунул - уже сто лет с ним не работал.

Рассматривание log-файла ничего особо не дало. заметил, что пересекаемую линию робот видит 11мс (ширина линии 15мм, значит скорость меньше 1.5 м/с), при старте нос "задирается" вверх и какое-то время робот видит только черноту и при этом ложно воспринимает перекрёсток, ну и на поворотах его заносит так, что линия не видна совсем некоторое время.

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

Вс мар 08, 2020 22:40:15

Как отменить выдачу в терминал режима работы я тоже не знаю. Однако, можно сконфигурировать какой-либо пин на установку лог. 1 при соединении и мониторить его из МК. Именно так дефолтно работают мои BGX модули на демо-платах - при соединении загорается LED0 (жёлтый на снимке).

Попробовал модуль в режиме NCP. Оказалось ничего сложного и всё даже очень логично, в доках всё рассказано. Simplicity Studio предлагает проект Empty Target. Портировал на BGM111 модуль, управляемый вмешним МК. Его тоже взял силлабовский (мне так сейчас быстрее, но это необязательно, может даже и не с ARM сработает), но приложение сделал в Keil для чистоты эксперимента. Там нужно лишь подцепить BGLIB библиотеку и настроить UART. В примерах также есть приложение для NCP-Host. При этом можно даже распределить обязанности МК и модуля, чтобы минимизировать занятость МК и UART траффик между ними. Сейчас модуль (для примера взял имеющийся на монтажке BGM111A) запрограммированным в него приложением конфигурирует BLE профиль и отвечает за посылку оповещений и соединение с мобильником и не отвлекает на это МК. С другой стороны МК в моём примере отвечает за соединение с сенсором SI7021 и посылает в модуль команды передачи нотификаций с данными среды по своему таймеру, а также производит измерение данных среды и передачу этих данных модулю по запросу мобильника. В общем, просто реализовать любое распределление обязанностей между МК и модулем, если в проекте необходим внешний МК.

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

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

Пн мар 09, 2020 08:24:22

С BGX я так в конце-концов и сделал: назначил на вывод str_active и просто его считываю перед тем как послать на командный интерпретатор и посылать сообщения журналирования на компьютер.

С HM-11 нашел неплохую аппликацию RoboRemo. Просто настраиваемая программа, которая по событию посылает текстовые сообщения, которые через множество последовательных каналов BT, BLE, TCP, UDB, USB может быть доставлено для исполнения роботу. Вот BLE у меня номально соединяется с HM-11, но, увы, не работает с BGX. Сейчас думаю какой функционал и протокол организовать. Ну, по минимуму, я могу теперь хотя бы робота остановить после финиша, а не гоняться за ним следом по всей трассе.

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

Сейчас думаю о постройке следующего linefollower-а. Хочу сделать шире полосу сенсоров: не из 8, а из 16 сенсоров, что должно расширить "рабочую зону". Только пока не могу придумать на каком микроконтроллере делать. Самое простое делать на пятом PSoC - можно впоследствии изменить периферию, если в процессе изготовления возникнут другие идеи. Ну и прикинул, для нового мне уже QFN68 корпуса не хватает - надо 53 вывода, так что только TQFP100 корпус может мне такое количество обеспечить (не считая BGA-подобные). С другой стороны, мне сейчас очень нравятся STM микроконтроллеры. Для записи журнала в EEPROM я сделал драйвер i2c, который работает не только по прерываниям, но и по DMA. Получилось очень красиво и изящно. Надо только еще организовать систему флагов, чтобы какой процесс не влез внутрь другой передачи данных. Сделал для HM-11 UART с FIFO буфером на приём. Теперь, надо бы еще и на передачу сделать FIFO.

Прикупил одну микросхему FRAM - буду пробовать туда log скидывать. А кстати, она не сотрётся, если к ней поднести магнит?

На MSP432 для работы с BGX взял готовый код UART1.c от Valvano. Там тоже приём через прерывания и FIFO, а передача по ожиданию. Но я дописал этот файл, чтобы и передача была буферизированной и по прерываниям. Ничего сложного. Сложность возникла тогда, когда я весь этот проект перекопировал дома на большой компьютер и при сборке снова превысил ограничение 32к. А стоило включить оптимизацию - как всё перестало работать. Я ж уже подозревал, что в коде он не ставит волшебное слово volatile. И пока оптимизация выключена - всё хорошо, а стоит включить - всё перестаёт работать. Добавил этот признак к переменным указателям FIFO буфера - теперь всё работает.

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

Пн мар 09, 2020 16:16:54

она не сотрётся, если к ней поднести магнит?
Не сотрётся. Термин ферроэлектричество не имеет ничего общего с магнетизмом.

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

Ср апр 29, 2020 16:53:36

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

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

У робота решающего лабиринт сделал, для развлечения, простой режим: ехать вперед, пока не упрётся в препятствие bump сенсором (в просторечье - концевиком). Тогда сделать откат, повернуться в сторону противоположную от препятствия и продолжить прямолинейное движение. Так вот тут выявилась проблема - в некоторых случаях робот поворачивал в неправильную сторону. Использовался алгоритм из лабораторной работы Nr14. Там программировалось прерывание по изменению уровня на GPIO, а следом, в прерывании, считывался порт и эти данные передавались программе. Оказалось, что из-за дребезга контактов, в прерывании из порта считывались нули, так как уровень успевал вернуться в исходное состояние. А так как в программе, я проверял только сенсоры с одной стороны, то предполагал, что если было прерывание и с этой стороны ни один из сенсоров не активирован, значит, наверняка сработал кто-то с противоположной стороны. Проблему решил тем, что считывал не состояние порта, а состояние регистра прерываний, т.е. считывал, кто на самом деле вызвал прерывание, а не то, что происходит потом.

Немного поработал на тему плавного разгона робота. До этого, у меня был параметр acceleration, значение которого я прибавлял к задаваемым RPM (оборотам в минуту колеса). Но, вообще-то это не правильно. потому как если к 30 RPM прибавить некое число, ускорение будет не такое же, как если это же число прибавить к 70 RPM. Правильнее было бы его умножать. Хорошо, сделал умножение. Но как теперь сдвинуть робота с места, если его RPM=0. Что на него не умножай, ноль как был, так и останется нулём. Поэтому, сделал так, что если скорость равна 0, то первый шаг просто устанавливает некий RPM. Пока сделал 768 (7.68 rpm). Наверное, надо будет это число увеличить, так как минимально регистрируемые обороты начинаются от 16 до 30 rpm. И из-за того, что обороты установлены меньше регистрируемых, робот в самом начале откатывается назад. Это понятно. Если пришел тахоимпульс, то система может указать что текущая скорость 15 rpm, но так как заданная скорость меньше этих 15, то на двигатели подаётся отрицательная полярность (типа сбавить скорость, так как начали за быстро двигаться). Выглядит это, конечно, эффектно! робот подходит к перекрёстку, поворачивает, затем чуть отступает назад и разгоняется вперед. Как человек, который отступает назад, чтобы сделать рывок и перепрыгнуть лужу. Пока думаю, как решить эту проблему. Как возможный вариант, установлю минимальную скорость не 7.68 rpm, а 15 или 30.

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

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

Сейчас, когда все лабораторные работы из curriculum сделаны (ну кроме 20-й - там нужен WiFi модуль), задумался, а где и что дальше? Что-то не видно продолжения. Но, оказалось, что на главной странице - ti.com/rslk, кой-что новое появилось. Появился (совершенно бесполезный) файл с картинкой выводов launchpad-а. А вчера заметил что появился какой-то облачный tool для диагностики робота. Попробовал его проинсталлировать. Там потребовалось поставить какое-то дополнение к Chrome и еще одну программу. Правда, пока ставил, испугался. Этот tool для диагностирования будет загружать свою программу в робот. А что если он сотрёт и ту часть флеш-памяти, где у меня хранятся конфигурационные параметры подобранные с таким трудом? Но до проверки дело так и не дошло. Аппликация пыталась поставить драйвер для доступа к роботу через USB и XDS debugger и... ей это не удалось. Потому как та часть была от CCS (code compose studio), а он 64-битный, а я пытался его поставить на 32-битный нетбук. Какая-то дискриминация...

Начал делать нового робота для следования по линии с 16 сенсорами. Поначалу думал, делать на "кипарисе" (или теперь надо его называть инфинионом?), но так как был вдохновлён тем, как здорово мне удался i2c драйвер для stm32f051, решил делать на stm. Выбрал кристалл в lqfp64 корпусе из серии stm32f405. Но как оказалось, у него другой i2c, не такой как в 051-м. Железо собрал. А вот с фирмварью пока дело идёт с большим скрипом. Так как расположение выводов планировал в Stm Cube, решил им же и создать проект. Увы, с этим HAL, просто пустая программа с инициализацией заняла почти 10 килобайт. Добавил только дисплей с конфигуратором - размер программы уже превысил размер программы робота для лабиринта. При этом у робота для лабиринта компиляция идёт с уровнем оптимизации -O1, а у этого робота -O3. Боюсь, что всё остальное в 32к не влезет. Придётся либо перелазить на бесплатную среду/компилятор на эклипсе, который еле шеволится (хотя кейл тоже этот проект компилирует очень долго) или писать всё вручную.

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

Ср апр 29, 2020 18:18:41

Для увеличения трения между колёсами и поверхностью можно-ли поставить по 2 колеса в параллель (как задние колёся у грузовика) или использовать более широкие колёса?

Не понял насчёт удачи с I2C на F051 - STM ведь предлагает I2C драйвер в составе своей SPL - в чём загвоздка? Да, странно как-то, что Infinion поглотил Cypress, не понимаю чем первые лучше, что они более удачливы в бизнесе. Может последние устали бороться с продвижением своих PSoC(?) А не рассматривали сделать робота на силлабовских EFM32? Там и среда бесплатная без ограничений, работающая и под Линуксом. Кстати, как идут дела с Bluetooth? У меня наконец-то снялись все вопросы/претензии к новому стеку и RTOS после последнего апгрейда Studio.

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

Чт апр 30, 2020 15:50:27

Pololu не предлагает более широкие колёса на это шасси. Конечно, для linefollower-вских роботов я сам колёса отливаю из силикона, но там маленькие колёсики - до 30мм в диаметре. А этому надо чуть больше 70мм - это почти предел для моего DLP 3D принтера. А FFF принтер такую мелкую фактуру не сможет сделать. С другой стороны, колёса у этого робота - гдавный элемент в определении положения робота. Диаметр колеса учитывается в пройденном пути, а ширина колеи - угол на сколько робот повернулся. Другой, возможный вариант с уменьшением "резких движений" - увеличить разрешающую способность сенсора линии. Но тут встаёт проблема в недостаточносм количестве каналов захвата или входов АЦП.

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

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

Для робота на stm32f051 я переписал "драйвер" i2c, так, чтобы он работал через DMA и требовал минимум процессорного времени. Это для того, чтобы в FRAM писать журнал на ходу. Когда же я начал оживлять робота на stm32f405 - мне было лениво писать драйвер и я воспользовался библиотекой HAL. Да, оказалось, что в этой библиотеке всё уже есть. И обмен просто так, и обмен по прерываниям, и обмен через DMA, и даже запись фрагмента (это когда в конце стоп не передаётся, чтобы следующий пакет просто продолжал дальше запись) - правда только по прерываниям, без DMA. Всё здорово, но эта библиотека съела треть халявной (32К) памяти. Ну и компиляция идёт страшно долго (на "быстром" компьютере). Поэтому, я опасаюсь, что буду делать, если я достигну предела бесплатных 32к - менять IDE на более тормознутую, но без ограничений, или всё же переписывать весь код без применения этих тяжеловесных библиотек.

И хотя библиотеки облегчают жизнь, они не дают стимула углубиться в микроконтроллер. Вот вроде уже пару месяцев ковыряюсь с EFM32, что стоит на плате Thunderboard sense 2, но я даже до сих пор в них особо не вник. Потребовался SPI - воспользовался SPIDRV. Потребовалась задержка - воспользовался USTIMER. Потребовался UART - начал мучать UARTDRV. Вот только с последним у меня что-то не получилось сделать то что хотел. Потому, пока я не увидел в EFM того, что могло бы меня сподвигнуть на переход на них. Да и нет у них дешевых evaluation board, как Launchpad, или Discovery, или Cypress-вские cy8ckit-xxx.

Блютус на роботе продолжает экстенсивно развиваться на BGX модуле - расширяю командный словарь и увеличиваю диагностические сообщения, которые робот передаёт во время работы. BGM модуль, ждёт, когда изготовлю для него плату. Плату развёл, но заказ на изготовление еще не разместил. Всё из-за вируса. Почтовые отправления из Китая, как я вычитал, с марта не идут к нам. А пропорция: 2$ плата и 24$ курьерская доставка, как-то не вызывает оптимизма. Надо бы еще за раз что-то заказать, но в данный момент ничего наготове нет.

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

Пт май 08, 2020 14:57:47

Посмотрел на EFM32... запутался в названиях Tini, Wonder, Leopard, Zero итд. Самое обидное, что их Starter Kit-ы стоят 92€ плюс НДС - дороговато. Вообще-то предыдущее сообщение я писал два раза. Просто первый раз потерялся - нажал отправить, выскочило окошко с логином, а потом... снова открылся редактор, только уже без текста. Так вот в первом варианте был написавши мысль, что если бы у EFM есть что-то такое принципиально отличающее его от других МК - я бы за них сразу же взялся. Например, таймер с количеством каналов захвата 6 или 8. Но, рассматривая описания что-то не заметил такой feature у них.

Зато вспомнил, что с тех пор как в качестве цветового сенсора стал использовать модули с i2c интерфейсом, у меня простаивает один таймер без дела. И подумалось, а не "запараллелить" ли их, чтобы получить 8 каналов захвата, для сенсора линии? Но, потом подумал, что мне не удастся перераспределить ресурсы так, чтобы сенсоры подключить ко входам захвата TIMER_A2. Увы, он портмапперу не поддаётся. Но, зато, я могу пару прерываний, которые генерят регистры сравнений TIMER_A1 перенести на A2, и тогда я могу сделать хотя бы 4 канала захвата. Для чего это нужно, я писал в самом начале. Так вот, сначала была проблема как счетчики засинхронизировать. Идеально засинхронизировать пока не придумал как. Можно, их запустить "почти" одновременно - разбег в 3 команды процессора получился. Т.е. в худшем случае, разница будет в 1 такт, я думаю (частота процессора 48Мгц, а на таймер приходит 12 МГц). Но, потом, я подумл, что мне на самом деле в данном случае надо отмерять время с момента окончания заряда конденсаторов, до момента разряда. Поэтому просто логично, таймер с захватами запускать именно в момент когда происходить это переключение внутри прерывания таймера A2. Так что в данном случае синхронность совершенно не нужна. Так что я вчера прошелся по всем вариантам и с синхронной работой счетчиков и с отдельным запуском - во всех случаях работа была удовлетворительной - т.е. функционал не нарушался.

В результате теперь не 2 , а 4 центральных датчика дают мне пропорциональный сигнал.

Так же, немного поразмышлял насчет Bump-сенсоров в режиме Free Run. Я тут коллег критиковал, когда они пытались выстроить алгоритм перебором показаний сенсоров, а оказалось, что я сам сделал такой режим в данном случае - просто проверял по маске одну сторону и игнорировал проверку второй стороны. Поэтому этим сенсорам сделал параметр, который они возвращают - угол столкновения. Если сработал крайний боковой датчик, то угол 45 градусов (плюс или минус зависит от справа или слева). Так как сенсоров 6, то получается, что они отстоят друг от друга на 18 градусов. Поэтому, от комбинации срабатываний, получаю ряд 0, 9, 18, 27, 36 или 45 градусов. После чего, робот после отката назад от препятствия поворачивается так, чтобы направление движения составило прямой угол с углом столкновения. Т.е. после удара о прямую стену, робот повернётся так, чтобы дальше ехать параллельно (ну почти) стене.

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