Форум РадиоКот

С BLE у меня всё никак не срастается. Не говоря уж о сетях. На этих выходных и мой новый робот, думаю, впал в GPF. Это было после того как я попытался избавиться от потенциальной возможности получить деление на 0 в пропорционально-интегральном контроллере двигателя. Но в этот раз я искать ничего особо менять не стал. Сначала, попытался откатить изменения, затем, когда ничего не изменилось, просто увеличил размер стека с 0x200 до 0x800. У меня уже были подозрения на стек, но я уже всё константное, что было перетащил в ПЗУ. Ну во всяком случае, после увеличения стека, пока глюков нет.

Эклипс наступает по всем фронтам. Вот только не понятно, 32 битный CCS отменили из-за эклипса или так? Не получится ли так, что мне всё же придётся покумать новый ноут, на который его можно будет поставить. А то в старый CCS не могу проимпортировать рабочий стол для RSLK-MAX. Он требует новый компилятор, который я на старый CCS никак поставить не могу.

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

del

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

Сегодня "пересадил" сенсор линии на туда, куда задумал:

Напечатал вот такой хомутик. Надо будет из черной (хм, как этот resin называется по-русски? ладно, пусть будет -) гмази (хоть и не ардритской) напечатать. Правда черная у меня обычная, а вот эта серая считается tough (ABS like). Я так понял, что она упругая. Ну посмотрим. надоест с этой возиться - налью, наконец, черную в принтер. Зато теперь, сенсоры находятся на расстоянии 3-4-5 мм от поверхности. Почему разброс? А потому что шарик этот в гнезде этом тоже "люфтует" где-то с миллиметр. Ну, посмотрим, что покажут заезды по трассам. По моей трассе робот пошел даже без перенастройки. сейчас стабильно 27.9 секунды.

Немного попытался побороться с делением на 0. Ситуация такая, что для измерения периода вращения колес, измеряется интервал между импульсами таходатчика. Для этого используется регистр захвата 16 битного таймера, который крутится по кругу. Т.е. если первое захваченное значение было 0x6000, а второе 0xE000, то период получается 0x8000. затем следующее 0x7000 - то по 16 битной без знаковой арифметике всё-равно будет 0x9000 (7000-E000=FFFF9000, если в 32 битах). Т.е. всё красиво. но до тех пор пока измеренный интервал не становится равным 65536 - потому как разность оказывается равной 0. И тогда для вычисления RPM приходится делить на этот 0. И тут я подумал, так как я контролирую число переполнений таймера (если между двумя событиями захвата таймер переполнился более одного раза, то я считаю, что мы стоим на месте), то почему бы считать не в 16 битной арифметике, а в 17 битной. Были три попытки, которые приводили контроллер к почти полной неработоспособности, но когда я разобрался со всеми ошибками - эта штука заработала.

Вот этот код из лабораторных работ (он там был уже готовый) А я добавил еще один бит: т.е. у меня всегда SecondRightTime больше чем FirstRightTime. Ну за исключением ситуации, когда таймер переполнился больше одного раза, но тогда я и интервал вообще не считаю, а возвращаю 65535 и статус STOPPED. А, и для этого финта, переменные из 16 битных сделал 32 битными (о, я теперь могу там большее число возвращать вместо 65535! сейчас попробуем) .

Надумал, еще разок погуглить, может где в интернете есть решение этого контроллера. Естественно, ничего не нашел, зато нашел какую-то презентацию от Даниэла Валвано и ссылку где для этого робота приведена андроидная аппликация, которая управляет роботом через BLE. В робот надо загрузить проект, который есть в лабораторном воркплейсе под названием ASEE. Думал, а не загрузить ли в робот её на побаловаться? Главное не забыть слить текущий имидж памяти, а то, пытаясь делать некоторые лабы - стёр всю память вместе с конфигурационными параметрами. Или надо их где-то записать. Но для начала попытался залить программу в планшет. Разумеется, ничего не вышло. Скопировал *.apk на планшет, разрешил установку "левых" аппликаций, нажал - установить... оно через некоторое время выдало, что installation failed. Вообще-то для этой apk есть исходники под android studio, но я в них как свинья в апельсинах.

И подумалось мне, что надо бы попытаться заполнить этот пробел. Начал рыть интернет и нарыл processing. Сначала подумал, что похоже на ардуину. Оказалось - наоборот! Это ардуина похожа на processing, так как сделана на его основе. Вчера весь день занимался "инсталляцией". Вобщет, процессинг инсталировать не нужно - распаковал куда-нибудь и просто запустил исполняемый файл. Но для того чтобы делать аппликации на андроид, надо поставить разные библиотеки и USB драйвера, чтобы у планшета был доступен USB-debug. С последним пришлось повозиться, но со второй попытки драйвер поставить всё же удалось. Теперь почитываю книжку и пытаюсь по ней делать некоторые примеры. Рисовать круги и квадраты на экране уже научился. И даже двигать и перекрашивать их. Надеюсь, когда дойду до седьмой главы про BT связь я не разочаруюсь. И еще до этого найду, как можно сделать удобный ввод значений конфигурационных параметров.

Добавлено after 5 minutes:
p.s. Ардритская гмазь, для тех кто не знает или уже не помнит - Станислав Лем. Звёздные дневники Йона Тихого. Там из неё всё делали, начиная от оперного театра, разрушенного в результате падения метеорита, до... впрочем, кто не читал , почитайте сами. С точки зрения современного человека, явно какой-то расходник для 3D печати. :))

Похоже, Вы решили сразу 2 проблемы махом. Насчёт ASEE - это как раз где я с Вальвано познакомился, однако на этой его презентации я не был. Хотя, проводятся эти конференции каждый год, может эта и не та. Не знаю поеду-ли на них ещё. Одна регистрация порядка 1000 стоила, В тот раз ТИ был активно представлен, на след. год уже ST. А почему решили на Processing писать, а не на Java? Хотя, для Androida сейчас более актуален Kotlin, вроде планируют всю разработку под Андроид на него перевести с Java.

Заинтересовался PSoC6. Картинка интересная - два процессора в одном корпусе?! Правда, не понял или не заметил из-за беглого просмотра, UDP в них нет? Ну, чтобы углубиться слегка, бросил в корзинку Cy8Cproto-062 платку - посмотрим что такое. Там еще какой-то микромодуль на борту BLE и WiFi разом? Не знаю, сейчас заказать или после НГ. Всё-равно придёт только после НГ. В описании упоминается только Модус.

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

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

На радостях, от того, что RSLK-MAX по своим характеристикам сравнялся с классическим RSLK, последнего я разобрал и таргет из проекта удалил. На базе этого шасси хочу сделать другого робота. Бегущего по линии с TSL1401CL ПЗС линейкой, которую пол-года назад вы порекомендовали. Строить планирую на PSoC5. Да вот только покрутил макетку, да так и не нашел, куда её на это шасси прикрутить.

Эти выходные с Андроидом проленился - ничего не изучал. Почему Process? Потому, что слова Котлин, Джава - для меня чужие. И я просто понадеялся, что хотя бы общие принципы начну понимать, чтобы можно было бы перейти к AndroidStudio.

Эти буквы ASEE нашел на домашней страничке Валвано http://users.ece.utexas.edu/~valvano/ И вот эта аппликация - это ASEE 2018 года. В самой последней части страницы на голубеньком фоне. В CSSовском воркплейсе исходного текста проекта ASEE нет - одни только скомпилированные .obj файлы и main.c. Ну ничего, может со временем созрею поковырять и эту аппликацию.

Переклеил трассу лабиринта. И теперь, чувствую, что надо бы для полного комплекта (для этих соревнований пока еще не актуально) написать решение лабиринта для поиска кратчайшего (и оптимального, с минимумом маневров) маршрута. Сейчас робот, конечно удаляет тупиковые ветви, но маршрут не всегда получается наикратчайшим. Конечно, задавая стратегию, я могу заставить робота получить наикратчайший маршрут (пока этот лабиринт я могу окинуть взглядом и оценить), но задачка так и просится, чтобы её решили. Есть идея как сделать, чтобы не требовалось очень много памяти, правда, потребуется несколько итераций. Для вдохновения есть интересная статья https://habr.com/ru/post/445378/ .

Интересная плата, у меня такой нет. Однако, на ней стоит PSoC-6 процессор без всякой connectivity. Последняя достигается с помощью Мюратовского модуля, основанного на Броадкомовском BT/WiFi чипе CYW4343W. Вообще, у PSoC-6 чипов на борту из безпроводки только BLE (модели 63/64). До этого программировать WiFi на Mudus не пробовал. Обычно для этого служит Wicked (a она и BLE может). На последнем семинаре мне сказали, что если хочу программировать Сайпровские WiFi, то Wicked следует оставить наряду с Modus. Поддерживается-ли сейчас WiFi на Модусе - не знаю. Из семинара я так понял, что пока нет, но могу ошибаться. Всё-таки семинар был про BT-mesh. Кстати, CYW4343W чип поддерживает только BLE 4.1. Странно, что в документации упоминается только Modus. Может лучше CY8CPROTO-063-BLE купить, или WiFi нужен? У Силлабов разработка WiFi и BT интегрирована в Studio. Правда, у них нет WiFi+BLE устройств.

Насчёт болтов, я рад, что нашёл фирму (это, правда, было уже давно), где заказывать мелкие болты/гайки и пр (Fastenal). У них есть отделение в нашем городе и туда доставка бесплатная. Иначе такую мелочь в широком выборе купить негде здесь. Во всех своих устройствах использую M2 или #2-56. Платы у меня в основном маленькие и туда M3 хуже вписывается. Думаю, и для Ваших роботов М2 будет лучше в плане места(?)

Закончил вторую часть статьи про BLE security. На след. неделе думаю осилить третью и тогда как раз после зимней спячки публикации возобновятся. Уверен, что при Вашей квалификации осилить Java и Android Studio с нуля будет несложно. Кстати, я правильно понял, что с Java у Вас нет пока опыта?

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

Вообще, эти блоки помогают упростить программу. Если в MSP432 для определения пройденного пути и контроля вращения колёс используются прерывания, которые вызываются тем чаще, чем быстрее вращаются колёса, то в PSoC5 я этот модуль нарисовал полностью аппаратным. Сказал бы без прерываний... но там есть скрытое прерывание в модуле QuadDec, так как 16 бит там считаются аппаратно, а остальные 16 - программно. Вот при переполнении аппаратных 16 бит прерывание и вызывается.

Это я вытащил один канал в тестовую конструкцию, чтобы проследить за поведением модуля. Вместо EncRightA был просто повесивши сначала кнопку, а позже генератор, чтобы убедиться что всё работает, как задумывалось. Пока что, система считает интервалы между фронтами импульсов на EncRightA. А EncRightB используется только для определения направления вращения. Если во время фронта импульса на этом входе была лог1, то в единицу устанавливается один триггер, если лог0, то второй. Timer_Right отмеряет время между фронтами импульсов. Он запрограммирован как OneShot таймер, и по приходу фронта импульса значение Counter таймера записывается в Capture регистр. Тут же счетчик "обнуляется" и начинает отсчет следующего интервала. Вот тут читал-читал даташит на таймер и в описании говорилось, что сигнал ресет сбрасывает много чего, но про регистр захвата ничего не говорилось. Вот и хотелось проверить, действительно ли сигнал сброса не тронет регистр захвата. Вообще, про регистр захвата в даташите какая-то не полная информация. Но мне повезло - действительно, ресет не влияет на регистр захвата, поэтому я его могу считать тогда когда мне это удобно без использования прерывания по событию Capture. Если же импульсов долго нет (обороты очень низкие), то счетчик может досчитать до своего предела (65535) и на один такт выставить активный уровень на выходе TC. Этот сигнал сбросит оба триггера показывающих направление вращения, что означает, что двигатель не крутится ни вперед, ни назад, а стоит на месте. А вот тут есть нюанс, который тоже в даташите не описан (или я этот момент не нашел). Если таймер Fixed Function, то регистр захвата "обнуляется", а если UDB, то остаётся неизменным. Собственно, меня устраивают оба поведения. Но, работа таймера в режиме FF мне понравилась больше, чем UDB. Стабильнее. Хотя FF даёт большую задержку при сбросе (2 такта, против 1 такта UDB). Но эта задержка детерминированная и её можно компенсировать. Вообще, в системе задержка 3 такта. Еще один такт задержки даёт EdgeDetect. Поэтому в данной тестовой схеме на дисплее показывает 0F9D, вместо 0FA0 (4000 = 12000000/3000). Но так как это при максимальных оборотах мотора 30000rpm, даже если не компенсировать, ошибка получается менее 0.1% - джиттер двигателя/энкодера гораздо больше.

Ммм, почему "обнуляется" я пишу в кавычках? Очень просто - все таймеры тут реализованы как count down, и вместо 0 там 0xFFFF. Поэтому приходится при считывании все биты переворачивать.

Почему пришлось строить тестовую конструкцию? А потому что не нашел, как в отладчике посмотреть содержимое регистра захвата. Хотя, может, причиной то, что отладчик показывал содержимое counter. А в даташите, написано, что при "чтении" значения счетчика оно принудительно захватывается (и портит регистр захвата, надо полагать). Тут и Creator меня тоже порадовал своими нерешенными глюками. Когда я летом на своём нетбуке работал с PSoC Creator, заметил, что в статусной строке не удаляются ошибки от предыдущих компиляций. Т.е. сделал сборку проекта - оказалось, что есть 2 ошибки. Внизу появились красные цифры 2 Errors. Я исправляю, пересобираю, Сборка без ошибок. Но в статусной строке ошибки как стояли так и стоят. И хуже того, в окошке Notice List они тоже стоят. А тут на стационарном компьютере наблюдаю такую же проблему. причем, не нужно даже делать сборку. Достаточно в TopDesign отсоединить одну цепь, чтобы изменить соединения, как появляются красные ошибки, что вывод такой-то, если он есть, то обязательно должен быть подключен. И после того, как я сделал необходимые соединения - оно не исчезает. Попытался выгуглить проблему. Да, проблема есть и известна. Нашел топик, от 2017 года. Там человек жаловался на проблему в версии 4.1. Его послали в Knowledge Base - там оно описано для версии 4.0 с обещанием исправить в 4.1. А тут уже 4.2 на дворе и 4.3 в бета стадии (может, в 4.3 это победили?). А как workaround предложили перезапустить PSoC Creator, для сброса старых ошибок. Ну хорошо, еще что Creator перезапускается быстрее, чем поделия на базе Эклипса. CCS даже на стационарном компьютере запускается очень долго. Если это будет в Модусе - я не переживу. Смеха для поставил Модус. Увы, перетащить существующие проекты из Creator не предлагает и в импорте такой фичи не нашел. Ок, пусть постоит, подождёт платки с PSoC6.

Крепежом я раньше затаривался в Wurth (у нас в городе есть магазинчик). Цены довольно высокие, но зато нет проблем с качеством. Вот только время работы у них как у офисов и суббота-воскресенье - выходные. Так что теперь я туда не попадаю. Вот и приходится покупать в интернетах, так как в других магазинах или нет того что нужно, или качество... Вон в прошлый раз, когда фотографировал роботов и извинялся что гаечки не прикрученные. Они были не прикрученные, потому что гайки купленные на базаре - треть брак. И когда мне надоело искать в этом барахле нормальные гайки, бросил я эту затею и пошел заказывать на фарнеле нормальные гайки М2.5. Сам я закладываюсь на М3 - у меня их наиболее широкий ассортимент по типам, по длинам. Меньшие - их гораздо меньше. А не метричские, типа #2-56 - стараюсь избегать. Хотя, куда от них денешься, если Pololu комплектует всё такими винтиками.

Ну и конечно, С новым годом!

У меня с PSoC-6 та-же проблема, что и с MSP432 - корпуса. У PSoC в этом отношении ещё хуже, т.к. они выпускаются только в BGA-подобных с миллионом выводов. Остаётся надеятьяся лишь на распаянные на платах чипы. В робот такую плату поставить, наверное, проблем нет, но в поделку как-то не очень. Есть, правда, вариант использовать BLE модули на основе PSoC-6. У них всего 43 вывода по периферии с шагом 0.9мм и их можно и на свою плату в поделку поставить, даже если Bluetooth не нужен. Там и обвязка вся уже имеется. Однако, стоят они 15-16$. Можно и применить, если двойное ядро нужно. Для моих целей двойное ядро имеет смысл только для беспроводки - на одном из них стек протокола, на другом всё остальное. ST тоже по такому пути пошли, да и другие фирмы тоже. Иначе со сколь-нибудь сложным приложением + стек приходится ставить RTOS, и, в общем, пока так можно жить. Может Вам в плане производительности посмотреть на трёх-ядерные изделия в линейке LPC от NXP или просто какие-нибуть быстрые из серии STM32F4/F7? Помню для этой камеры на машинках с успехом использовались не слишком шустрые платы МК от Freescale.

Как не странно, #2-56 примерно в 2 раза дешевле здесь, чем М2. По диаметру болты примерно одинаковые, но гайки у дюймовых более "мясистые". Думаю попробовать М1.6 или даже #0-80. Они заметно дороже, но зато на целый мм по диаметру меньше. Иногда имеет смысл.

А 30000rpm мотор - это не для робота, наверное(?) Наверняка Вы уже всё просчитали, но неужели для отработки сигналов от датчиков колёс робота, следующего по линии, не хватает 16-бит таймера? Может можно снизить частоту тактирования таймера без потери точности определения положения колёс и вписаться в 16 бит без переполнений? Или может можно поделить частоту сигнала от датчика в 2 раза и тем самым обрабатывать каждый второй его сигнал?

С Новым Годом, и удачи на соревнованиях!

Вот про типы корпусов для PSoC6 я и не посмотрел. Ну это просто для интереса. Пока с ним ничего не планирую (как было и с MSP432). Хочу только подстраховаться. А то попытался экстраполировать обработку 8 фото сенсоров на 128 сенсоров ПЗС линейки и, возникло странное предчувствие. Ожидаю большую проблему в различии освещенности "кадра". Надо будет, вероятно, через первые производные картинку анализировать. Но это позже.

30 000 rpm - это именно мотор робота. Что в RSLK, что в LineFollower. Ну, может, в RSLK чуть по медленнее. Когда делал 17 лаб.работу и двигатель бесконтрольно разгонялся, у меня показывало более 220 rpm (колеса), что с учетом редуктора 1:120 даёт 26000 rpm мотора. В LineFollower использую моторы Pololu micro metal gear и, если посмотреть на параметры, то мощные моторы (HP - High Power) имеют от 31000 до 33000 rpm. Но в данном случае проблему вызывает нижняя граница. По книжке Валвано получается (и у меня получились похожие результаты), что постоянная времени двигателя (с редуктором и колесом) около 100мс. Следовательно, частота вызова ПИ контроллера должна быть раз в 10 больше - выбираем около 10мс. Далее время измерения периода следования импульсов таходатчика. Желательно, обеспечить ПИ контроллер свежими данными, поэтому 12МГц и 16 бит обеспечивают 5.461мс - вполне приемлемый вариант. Уменьшать разрядность нельзя, так как rpm к периоду - обратная функция и при малых значениях шаги будут очень грубыми. Вот и сейчас получается диапазон от 8000 до 65535. В предыдущем сообщении я не верно выбрал частоту. 3 Кгц там не будет. Оказалось, что несмотря на то что магнитный диск 6-полюсный, датчики дают только 3 импульса на оборот. Наверное, срабатывают только на одно направление магнитных линий, а на противоположное - не срабатывают. Ну так вот, что происходит со значением - 65535. Это 5.461 мс - период следования импульсов. Так как на оборот двигателя приходится 3 импульса, значит один оборот выполняется за 16.384 мс. Ну и делим 60 секунд на 16.384 = 3662 оборота в минуту. Это минимальные обороты. У робота для Line Follower двигатель имеет редуктор 1:10 - значит минимальные обороты 366 rpm, что при длине окружности колеса в 66 мм соответствует скорости около 40 см/с. Многовато. (у RSLK эти же обороты двигателя при редукторе 1:120 и окружности колеса 220 мм дают, соответственно, 31 rpm и 10 см/с (грубо)). Для опускания нижней границы, надо или увеличивать время измерения, что приведет к увеличению времени реакции двигателя, или увеличить число событий на один оборот. Второй вариант для RSLK тоже не особо приемлем, так как каждое событие должно обрабатывать прерывание - а это время! И вот если сейчас у меня прерывания могут вызываться с максимальной частотой 1.5 кГц, то при увеличении - эта частота соответственно увеличится. В PSoC, так как всё это происходит аппаратно, проблем никаких не должно вызвать. Проблему вызывает то, что для увеличения числа импульсов, можно последовательно выполнить следующие мероприятия: детектировать не только фронт, но и спад; использовать второй канал тоже. Но тут я прикинул, что если эти оба сигнала с энкодера объединить через исключающее ИЛИ, я могу использовать полученные фронты для измерения интервала между фронтом и спадом одного канала или если контролировать еще и спады, то получить всю максимальную разрешающую способность энкодера - 12 cpr (импульсов на оборот). Правда, с отлавливанием спадов есть проблема. Если EdgeDetect без проблем этот режим включается, то у таймера в режиме Fixed Function такой возможности нет. Она есть только у таймера в режиме UDB. Ну что ж, попробую на пробной платке проверить как этот режим пойдёт.

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

Спойлер

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

   17.2125,...**...,   ,Segment
   17.2150,...**...,   ,Segment
   17.2175,...**...,   ,Segment
   17.2200,...**...,   ,Segment
   17.2225,...**...,   ,Segment
   17.2250,...**.**,   ,Segment
   17.2275,...*****,   ,Segment
   17.2300,...*****,  R,Solve
   17.2325,...*****,  R,Solve
   17.2350,...*****,  R,Solve
   17.2375,...*****,  R,Solve
   17.2400,...*****,  R,Solve
   17.2425,...*****,  R,Solve
   17.2450,...*****,  R,Solve
   17.2475,...*****,  R,Solve
   17.2500,...*****,  R,Solve
   17.2525,...*****,  R,Solve
   17.2550,...*****,  R,Solve
   17.2575,...*****,  R,Solve
   17.2600,....****,  R,Solve
   17.2625,.....*.*,  R,Solve
   17.2650,........,  R,Solve
   17.2675,........,  R,Solve
   17.2700,........,  R,Solve
   17.2725,........,  R,Solve
   17.2750,........,  R,Solve
   17.2775,........,  R,Solve
   17.2800,........,  R,Solve
   17.2825,........,  R,Solve
   17.2850,........,  R,Solve
   17.2875,........,  R,Solve
   17.2900,........,  R,Solve
Current index = 15 , Coord X = 0 , Coord Y = 0
   17.2925,........,  R,Solve
   17.2950,........,  R,Solve
   17.2975,........,  R,Solve
   17.3000,........,  R,Solve
   17.3025,........,  R,Solve
   17.3050,........,  R,Solve
   17.3075,........,  R,Solve
   17.3100,........,  R,Solve
   17.3125,........,  R,Solve
   17.3150,........,  R,Solve
   17.3175,........,  R,Solve
   17.3200,........,  R,Solve
   17.3225,........,  R,Solve
   17.3250,........,  R,Solve
   17.3275,........,  R,Solve
   17.3300,........,  R,Solve
   17.3325,........,  R,Solve
   17.3350,........,  R,Solve
   17.3375,........,  R,Solve
   17.3400,........,  R,Solve
   17.3425,........,  R,Solve
   17.3450,........,   ,Turn

Первое поле - время в секундах, второе поле - показания сенсора линии: "*" - черное, "." - белое, затем флаги найденных поворотов: левый, прямо, правый и в конце имя функции где программа находится: в главной Solve_Maze или в функциях Run_Segment или Turn. На показанном примере видно, что робот идёт по сегменту довольно ровно - линия под центральными датчиками, потом появляется что-то черное с правого края и когда это зафиксировано два отсчета подряд функция завершается и управление возвращается в главную функцию Solve_Maze на 17.23 секунде. Она начинает определять конфигурацию узла. на 17,2650 пропал сигнал с бокового датчика, но робот продолжает двигаться еще 10 отсчетов, чтобы выяснить, есть ход прямо или нет (хм, тут видно, что я могу быстрее отказаться от поиска, если это поворот, а не T-образный перекрёсток). И тогда, программа назначает номер этому узлу - 15. Правда, координаты тут указаны нулевые, потому как я это добавил позже и этой информации в лог-файле нет. Далее, робот движется еще некоторое время вперед, чтобы центр робота оказался над центром перекрёстка(поворота или тупика) и на 17,345 секунде управление отдаётся функции поворота, которая будет выполнять поворот.

Этот лог-файл показал, что всё работает верно, а "заблудовка" случилась потому, что робот не опознал возврат на узел 3, а присвоил новый номер - 10 (на трассе сейчас всего 9 узлов). Поэтому, еще сделал чтобы в лог-файл писались и координаты узлов и , думаю, надо сделать запись длин пройденных сегментов. Если с геометрией сейчас должно быть боле-менее нормально, то теперь причина в "непопадании" координат может быть проскальзывание колёс при старте. Всё же этот ПИ контроллер старается выполнить "заявку сверху" максимально быстро и точно. Поэтому если ему задано крутиться 110 rpm, он с места и пытается на все 110 рвануть. Так что теперь надо озаботиться более плавным разгоном. Хотя, у меня уже есть параметр acceleration. Сейчас, он позволяет увеличивать скорость на 1.28 rpm за 2.5 миллисекунды. Но толку от этого мало, так как ПИ контроллер реально что-то сможет делать только тогда, когда значение превысит 30.5 rpm - до этого момента поведение будет совершенно неадекватным. Надо еще думать.

Лог пишется до, примерно, 20 секунды. я выделил на это дело 16К памяти. правда, в конце идёт какая-то белиберда и не могу понять откуда этот мусор взялся. Может, опять стек наезжает куда не надо? Собственно, причина в том, что оба робота у меня валились в GPF в том, что размер стека был больше, чем Кейл под него выделял. А выделяет он всего 512 байт. И самое обидное, что стек размещается не в конце ОЗУ (как обычно принято), а сразу за последней глобальной/статической переменной отсчитал 512 байт и поставил вершину стека. И плевать, что у меня в какой-то функции есть автоматический массив на килобайт, а то и на 4. Сделал, как рекомендовали, добавление в листинг информацию об использовании стека. Сейчас утоптал память и получил:Т.е. теперь даже в дефолтные 0x200, возможно, укладываюсь, так как в этом репорте не показано, сколько стека отъедают вызовы прерываний. Да и компилятор не может этого сделать, так как во многих прерываниях используется CallBack. Так что никто не знает, куда оно по прерыванию дальше пойдёт.

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

p.s. Еще поанализировал логи, робот сбился потому, что один из сегментовпо которому ехал "на восток" , измерил на 28мм длиннее, чем параллельный, по которому ехал "на запад". А границу допуска я поставил 26мм. Вот и таким образом образовался "новый" узел. Правда, я измерил линейкой - тот второй, на 10мм длиннее сам по себе. Но закономерность заметил, что если робот входит на участок после поворота, результат измерения сегмента оказывается на 20-24 мм больше, чем если он попадает на этот же сегмент продолжая прямолинейное движение.

Представил сегодня к публикации здесь первые 2 части статьи про Bluetooth, как обещал. В процессе написания третьей части (посвящена она разработке Bluetooth приложений под Micrium RTOS) явно ощутил, что прежде следует про саму эту RTOS статью написать, чтобы было всё понятно. В русско-язычном секторе неиболее популярна FreeRTOS, про которую куча статей, а про эту - не знаю, может тоже есть где-то. Ещё меня терзают смутные сомнения, что Вы может будете чуть-ли не единственным, кому это может быть интересно - сужу по активности на форуме в плане Bluetooth. Поэтому может будет лучше опубликовать третью (и RTOS) часть на другом ресурсе. Впрочем, посмотрим.

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

Сейчас борюсь с ПИ регулятором для LineFollower. Что-то ничего не получается. Или данные от таймера приходят некорректные, или... Поначалу пытался делать "на глаз" - вроде крутится, но звук несколько странный. Чуть позже, мне взбрело в голову, что я могу проверять стабильность оборотов стробоскопически. На вал надел колесо у которого есть 12 регулярных "структурных элементов". Посчитал, что при 100Гц мерцании ламп в комнате, для получения "картинки" мне нужно это колесо вращать 500 rpm. Увы - картинки нет. Следующий этап сделать журналирование - сделал массив на 5000 элементов и туда записываю показания таходатчика. Проблема как эти цифры посмотреть. Под дебаггером поставил Watch, но там показывает только 32 элемента. Нажал на кнопку "показать всё"... комп на целый вечер стал недоступен. Жаль, что у этого робота не предусмотрена инфраструктура для передачи данных. Есть только выход i2c и USB. Второй пока незадействовал и не помню, надо посмотреть по схеме, может ли он у меня работать разом с батарейкой. До соревнований осталось 2 недели и чувствую, придётся ехать по старой схеме.

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

Насчёт кратчайшего пути в графе - алгоритм Дейкстры не подойдёт?

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

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

Забил я в Exel "тестовый" лабиринт - буду на нём тренировать алгоритм. Правда, удаление тупиковых ветвей не сильно упрощает лабиринт. В нём 114 вершин, а тупиков всего где-то 4, не считая тупиками старт и финиш.

Для этого можно, например, модифицировать граф следующим образом везде где есть ветвление (на примере T-ветвления) как показано на картинке. Первоначально вес каждого чёрного ребра 1 (левая картинка). Введём на каждом ребре дополнительную красную вершину и уберём первоначальную чёрную (правая картинка). Положим вес каждого наклонного красного ребра =1, а вес горизонтального красного ребра равным 0. Таким образом, проход через вершину без изменения направления будет предпочтительнее в смысле минимального расстояния, т.к. проход по наклонному ребру при смене направления добавляет лишнюю 1 к расстоянию. Как-то так...

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

Провёл анализ "олимпиадного" лабиринта. тупиков - 9 (вместе с началом и концом), 71 поворот, 35 T-образных перекрёстка и ни одного X-образного.

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

Продолжение борьбы с ПИ контроллером у робота на PSoC. Всю задуманную схему для измерения периода следования импульсов разобрал. Потому как она не работает как надо. Разбираться в чем причина нет времени, поэтому пошел по проторенной дорожке: свободно бегущий таймер и прерывания по захвату и переполнению. Причина, почему у меня PSoC Creator "заклинивало" - моя жадность. Для журналирования данных создал массив из 5000 элементов и вставил их в Watch. Креатор просто не мог быстро переварить такую толпу чисел. Но так как тест у меня идёт 3 секунды, контроллер вызывается раз в 10мс (т.е. 100 раз в секунду), то реально нужно всего 300 отсчетов. Ну, ладно - 313, так как контроллер вызывается чуть чаще - раз в 9.54 мс. Взять этот массив в клипбоард удобней всего оказалось из закладки Memory, а потом просто бросал в электронную таблицу:

Красная линия это результат работы ПИ контроллера удерживающего 1000 rpm. Синяя линия - свободное вращение мотора при, примерно, трети подаваемой мощности. Первые значения 1831 и 915 - это минимальный rpm - колесо или стоит на месте или вращается медленнее фиксируемых оборотов(хм, почему 1831 - сейчас исправлю). Можно заметить как различается время реакции с регулятором и без.

p.s. Написал еще и усреднение:

Красная линия - это те же старые данные, что и на предыдущей картинке, а синяя линия - результат работы "усреднителя". Правда, пришлось уменьшить коэффициенты интегральной и пропорциональной составляющей, иначе после изменения оборотов - они долго колебались с большой амплитудой, пока устанавливались заданные значения. Ну и я немного разнообразил тест - теперь мотор крутит колесо с оборотами 1000, 500, 1500 и 1000 rpm по 0.75 секунд.

Быстро прочитал Вашу статью про силабовский Bluetooth. Теперь некоторые моменты с секюрностью стали понятны. Но, чтобы повторить на попробовать - страшно дорогие эти комплекты. Хотя сам по себе модуль BGM13P достаточно дешёв. Вот есть мысль, если у меня получится получить приемлемую скорость роботу на следовании линии, то следующий надо будет сделать уже с управлением полностью через bluetooth.

Время проводимое в поезде потратил на адаптацию OLED дисплея на контроллере SH1106. Да, кой-какие команды совпадают с SSD1306, но некоторые моменты не совпадают. Далее оцифрованный лабиринт записал в память микроконтроллера:

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

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

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

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

Вот результат работы программы - найденный кратчайший путь. Справа, на нескольких узлах я написал значение расстояний для примера. И вот, скажем я добрался до узла помеченного 5320. От него есть две дороги "вниз": на точку 4200 и 5040. Программа выбрала 5040, а не более низкую 4200. Так как 4200 всего на 4 клеточки ниже (так как я сделал длину одной клеточки 280), но до неё надо идти целых 6 клеточек. В то время как 5040 ниже на одну клеточку и идти до неё тоже только одну клеточку (не забываем, что картинка растянута по горизонтали. Aspect ratio 2:1). В общем, я пока результатом доволен. Теперь надо в этот код встроить вес прохода через узел прямо и с поворотом. Тогда увидим, что оптимальным может оказаться другой маршрут.