Форум РадиоКот https://radiokot.ru/forum/ |
|
RSLK от TI (Robotic System Learning Kit) https://radiokot.ru/forum/viewtopic.php?f=62&t=161437 |
Страница 6 из 14 |
Автор: | uldemir [ Пн дек 23, 2019 08:06:29 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
С BLE у меня всё никак не срастается. Не говоря уж о сетях. На этих выходных и мой новый робот, думаю, впал в GPF. Это было после того как я попытался избавиться от потенциальной возможности получить деление на 0 в пропорционально-интегральном контроллере двигателя. Но в этот раз я искать ничего особо менять не стал. Сначала, попытался откатить изменения, затем, когда ничего не изменилось, просто увеличил размер стека с 0x200 до 0x800. У меня уже были подозрения на стек, но я уже всё константное, что было перетащил в ПЗУ. Ну во всяком случае, после увеличения стека, пока глюков нет. Эклипс наступает по всем фронтам. Вот только не понятно, 32 битный CCS отменили из-за эклипса или так? Не получится ли так, что мне всё же придётся покумать новый ноут, на который его можно будет поставить. А то в старый CCS не могу проимпортировать рабочий стол для RSLK-MAX. Он требует новый компилятор, который я на старый CCS никак поставить не могу. С Cypress я и продолжаю заниматься. Сейчас надо бы взяться за нового робота для LineFollower, что я собрал в конце лета. На выходных залил формы с колёсами для этого робота силиконом, через пару дней буду пытаться их оттуда выковырнуть. Так же получил толпу новых батареек - надо придумать как их закрепить на роботе. И, конечно, надо начать работать над программой, чтобы реализовать похожий ПИ контроллер двигателя. Причем, если я сделал тахометр аппаратно, детектор направления - тоже аппаратно, то измерение приода тоже хочется сделать аппаратно. |
Автор: | qwertyman6336 [ Пн дек 23, 2019 13:45:07 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
del |
Автор: | uldemir [ Ср дек 25, 2019 22:25:28 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Да вот я тоже думаю, пора его ликвидировать и обновить парк компьютерной техники. Ну я об этом года три-четыре уже думаю. Сегодня "пересадил" сенсор линии на туда, куда задумал: Напечатал вот такой хомутик. Надо будет из черной (хм, как этот 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 битной. Были три попытки, которые приводили контроллер к почти полной неработоспособности, но когда я разобрался со всеми ошибками - эта штука заработала. Вот этот код из лабораторных работ (он там был уже готовый) Код: void tachometerRightInt(uint16_t currenttime){ А я добавил еще один бит:Tachometer_FirstRightTime = Tachometer_SecondRightTime; Tachometer_SecondRightTime = currenttime; Код: void tachometerRightInt(uint16_t currenttime){ т.е. у меня всегда SecondRightTime больше чем FirstRightTime. Ну за исключением ситуации, когда таймер переполнился больше одного раза, но тогда я и интервал вообще не считаю, а возвращаю 65535 и статус STOPPED. А, и для этого финта, переменные из 16 битных сделал 32 битными (о, я теперь могу там большее число возвращать вместо 65535! сейчас попробуем) .Tachometer_FirstRightTime = Tachometer_SecondRightTime & 0xFFFF; Tachometer_SecondRightTime = currenttime + ((RollOverRight) ? 0x10000 : 0); Надумал, еще разок погуглить, может где в интернете есть решение этого контроллера. Естественно, ничего не нашел, зато нашел какую-то презентацию от Даниэла Валвано и ссылку где для этого робота приведена андроидная аппликация, которая управляет роботом через BLE. В робот надо загрузить проект, который есть в лабораторном воркплейсе под названием ASEE. Думал, а не загрузить ли в робот её на побаловаться? Главное не забыть слить текущий имидж памяти, а то, пытаясь делать некоторые лабы - стёр всю память вместе с конфигурационными параметрами. Или надо их где-то записать. Но для начала попытался залить программу в планшет. Разумеется, ничего не вышло. Скопировал *.apk на планшет, разрешил установку "левых" аппликаций, нажал - установить... оно через некоторое время выдало, что installation failed. Вообще-то для этой apk есть исходники под android studio, но я в них как свинья в апельсинах. И подумалось мне, что надо бы попытаться заполнить этот пробел. Начал рыть интернет и нарыл processing. Сначала подумал, что похоже на ардуину. Оказалось - наоборот! Это ардуина похожа на processing, так как сделана на его основе. Вчера весь день занимался "инсталляцией". Вобщет, процессинг инсталировать не нужно - распаковал куда-нибудь и просто запустил исполняемый файл. Но для того чтобы делать аппликации на андроид, надо поставить разные библиотеки и USB драйвера, чтобы у планшета был доступен USB-debug. С последним пришлось повозиться, но со второй попытки драйвер поставить всё же удалось. Теперь почитываю книжку и пытаюсь по ней делать некоторые примеры. Рисовать круги и квадраты на экране уже научился. И даже двигать и перекрашивать их. Надеюсь, когда дойду до седьмой главы про BT связь я не разочаруюсь. И еще до этого найду, как можно сделать удобный ввод значений конфигурационных параметров. Добавлено after 5 minutes: p.s. Ардритская гмазь, для тех кто не знает или уже не помнит - Станислав Лем. Звёздные дневники Йона Тихого. Там из неё всё делали, начиная от оперного театра, разрушенного в результате падения метеорита, до... впрочем, кто не читал , почитайте сами. С точки зрения современного человека, явно какой-то расходник для 3D печати. :)) |
Автор: | Ser60 [ Чт дек 26, 2019 22:38:36 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Похоже, Вы решили сразу 2 проблемы махом. Насчёт ASEE - это как раз где я с Вальвано познакомился, однако на этой его презентации я не был. Хотя, проводятся эти конференции каждый год, может эта и не та. Не знаю поеду-ли на них ещё. Одна регистрация порядка 1000 стоила, В тот раз ТИ был активно представлен, на след. год уже ST. А почему решили на Processing писать, а не на Java? Хотя, для Androida сейчас более актуален Kotlin, вроде планируют всю разработку под Андроид на него перевести с Java. |
Автор: | uldemir [ Вс дек 29, 2019 23:16:15 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Заинтересовался 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/ . |
Автор: | Ser60 [ Пн дек 30, 2019 02:18:58 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Интересная плата, у меня такой нет. Однако, на ней стоит 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 у Вас нет пока опыта? |
Автор: | Ser60 [ Ср янв 01, 2020 21:44:29 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
У меня с 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 раза и тем самым обрабатывать каждый второй его сигнал? С Новым Годом, и удачи на соревнованиях! |
Автор: | uldemir [ Сб янв 04, 2020 12:03:03 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Вот про типы корпусов для 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 Первое поле - время в секундах, второе поле - показания сенсора линии: "*" - черное, "." - белое, затем флаги найденных поворотов: левый, прямо, правый и в конце имя функции где программа находится: в главной Solve_Maze или в функциях Run_Segment или Turn. На показанном примере видно, что робот идёт по сегменту довольно ровно - линия под центральными датчиками, потом появляется что-то черное с правого края и когда это зафиксировано два отсчета подряд функция завершается и управление возвращается в главную функцию Solve_Maze на 17.23 секунде. Она начинает определять конфигурацию узла. на 17,2650 пропал сигнал с бокового датчика, но робот продолжает двигаться еще 10 отсчетов, чтобы выяснить, есть ход прямо или нет (хм, тут видно, что я могу быстрее отказаться от поиска, если это поворот, а не T-образный перекрёсток). И тогда, программа назначает номер этому узлу - 15. Правда, координаты тут указаны нулевые, потому как я это добавил позже и этой информации в лог-файле нет. Далее, робот движется еще некоторое время вперед, чтобы центр робота оказался над центром перекрёстка(поворота или тупика) и на 17,345 секунде управление отдаётся функции поворота, которая будет выполнять поворот.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 Лог пишется до, примерно, 20 секунды. я выделил на это дело 16К памяти. правда, в конце идёт какая-то белиберда и не могу понять откуда этот мусор взялся. Может, опять стек наезжает куда не надо? Собственно, причина в том, что оба робота у меня валились в GPF в том, что размер стека был больше, чем Кейл под него выделял. А выделяет он всего 512 байт. И самое обидное, что стек размещается не в конце ОЗУ (как обычно принято), а сразу за последней глобальной/статической переменной отсчитал 512 байт и поставил вершину стека. И плевать, что у меня в какой-то функции есть автоматический массив на килобайт, а то и на 4. Сделал, как рекомендовали, добавление в листинг информацию об использовании стека. Сейчас утоптал память и получил: Код: Maximum Stack Usage for __rt_entry_main 0x188 bytes. Т.е. теперь даже в дефолтные 0x200, возможно, укладываюсь, так как в этом репорте не показано, сколько стека отъедают вызовы прерываний. Да и компилятор не может этого сделать, так как во многих прерываниях используется CallBack. Так что никто не знает, куда оно по прерыванию дальше пойдёт.Call chain for maximum stack usage: __rt_entry_main => main => solveMaze => show_number => update_display => lcddatawrite Попутно узнал, что деление на 0 без специальных телодвижений GPF не вызывает. Но тем не менее, сделал маленький обработчик GPF, чтобы я знал, что робот туда ввалился - включает белый цвет на трёхцветном светодиоде и, главное, выключает двигатели. p.s. Еще поанализировал логи, робот сбился потому, что один из сегментовпо которому ехал "на восток" , измерил на 28мм длиннее, чем параллельный, по которому ехал "на запад". А границу допуска я поставил 26мм. Вот и таким образом образовался "новый" узел. Правда, я измерил линейкой - тот второй, на 10мм длиннее сам по себе. Но закономерность заметил, что если робот входит на участок после поворота, результат измерения сегмента оказывается на 20-24 мм больше, чем если он попадает на этот же сегмент продолжая прямолинейное движение. |
Автор: | Ser60 [ Ср янв 08, 2020 07:58:13 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Представил сегодня к публикации здесь первые 2 части статьи про Bluetooth, как обещал. В процессе написания третьей части (посвящена она разработке Bluetooth приложений под Micrium RTOS) явно ощутил, что прежде следует про саму эту RTOS статью написать, чтобы было всё понятно. В русско-язычном секторе неиболее популярна FreeRTOS, про которую куча статей, а про эту - не знаю, может тоже есть где-то. Ещё меня терзают смутные сомнения, что Вы может будете чуть-ли не единственным, кому это может быть интересно - сужу по активности на форуме в плане Bluetooth. Поэтому может будет лучше опубликовать третью (и RTOS) часть на другом ресурсе. Впрочем, посмотрим. |
Автор: | uldemir [ Чт янв 09, 2020 08:02:10 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
С нетерпением жду, когда Главный Кот отойдёт от праздников и нажмёт подтверждающую кнопку. То что нет активности, возможно, что многие не пишут, но читают. С другой стороны, должна набраться "критическая масса" знаний, чтобы начали появляться вопросы. Мне эту критическую массу дали вот эти лабораторные работы. Собственно, разбираясь с 19 работой, у меня и случился прорыв, что начал понимать и появились вопросы. А то этого: ну есть "черный ящик", который представляет компорт, пытающийся изобразить из себя старый телефонный модем. Сейчас борюсь с ПИ регулятором для LineFollower. Что-то ничего не получается. Или данные от таймера приходят некорректные, или... Поначалу пытался делать "на глаз" - вроде крутится, но звук несколько странный. Чуть позже, мне взбрело в голову, что я могу проверять стабильность оборотов стробоскопически. На вал надел колесо у которого есть 12 регулярных "структурных элементов". Посчитал, что при 100Гц мерцании ламп в комнате, для получения "картинки" мне нужно это колесо вращать 500 rpm. Увы - картинки нет. Следующий этап сделать журналирование - сделал массив на 5000 элементов и туда записываю показания таходатчика. Проблема как эти цифры посмотреть. Под дебаггером поставил Watch, но там показывает только 32 элемента. Нажал на кнопку "показать всё"... комп на целый вечер стал недоступен. Жаль, что у этого робота не предусмотрена инфраструктура для передачи данных. Есть только выход i2c и USB. Второй пока незадействовал и не помню, надо посмотреть по схеме, может ли он у меня работать разом с батарейкой. До соревнований осталось 2 недели и чувствую, придётся ехать по старой схеме. Попутно, решаю задачку поиска кратчайшего пути в лабиринте. Одну функцию уже написал - обрубание тупиковых ветвей. Правда для тестирования, нужен был бы какой-нибудь серъёзный лабиринт. Из ленты склеить врядли удастся. Поэтому нашел в интернете картинку с какой-то российской олимпиады по робототехнике аж 2004 года. Там лабиринт 16 на 16. Попробую его оцифровать и запихнуть в память роботу. |
Автор: | Ser60 [ Чт янв 09, 2020 08:36:47 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Насчёт кратчайшего пути в графе - алгоритм Дейкстры не подойдёт? |
Автор: | uldemir [ Чт янв 09, 2020 19:43:29 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
О! а я и не знал, что он так зовётся. Да, что-то наподобие я и пытаюсь реализовать. Только помимо веса ребра графа хочу ввести и вес прохода через вершину. Так как лабиринт ортогональный, то проход через вершину не меняя направление должен иметь один вес, а меняя - другой. Т.е. при некотором соотношении этих весов (я посмотрю сколько времени требует поворот) хочу получить маршрут с минимальным числом посещаемых узлов, затем - маневров, и, наконец, кратчайший по расстоянию. Т.е более длинный путь с меньшим числом манёвров может оказаться оптимальнее, чем наикратчайший по расстоянию. Ну и была мысль, те маршруты, которые оказываются заведомо длиннее - просто удалять. Хотя, надо еще подумать. Пока я когда начал писать заткнулся, что мне нужно еще учитывать направление, откуда я пришел, поэтому размышляю как иначе организовать структуру данных. Забил я в Exel "тестовый" лабиринт - буду на нём тренировать алгоритм. Правда, удаление тупиковых ветвей не сильно упрощает лабиринт. В нём 114 вершин, а тупиков всего где-то 4, не считая тупиками старт и финиш. |
Автор: | Ser60 [ Чт янв 09, 2020 20:15:02 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Для этого можно, например, модифицировать граф следующим образом везде где есть ветвление (на примере T-ветвления) как показано на картинке. Первоначально вес каждого чёрного ребра 1 (левая картинка). Введём на каждом ребре дополнительную красную вершину и уберём первоначальную чёрную (правая картинка). Положим вес каждого наклонного красного ребра =1, а вес горизонтального красного ребра равным 0. Таким образом, проход через вершину без изменения направления будет предпочтительнее в смысле минимального расстояния, т.к. проход по наклонному ребру при смене направления добавляет лишнюю 1 к расстоянию. Как-то так... Вложение:
|
Автор: | uldemir [ Пт янв 10, 2020 08:01:16 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Хм. тогда уж достаточно просто удлиннить примыкающее ребро. Но для полного X-образного перекрёстка чего-то так не получается. Похоже, проще ввести вместо одной вершины две: для меридианального и широтного направления и их соединить ребром имеющим вес поворота. Чем-то напомнило схему метро... с пересадками на разных уровнях. Провёл анализ "олимпиадного" лабиринта. тупиков - 9 (вместе с началом и концом), 71 поворот, 35 T-образных перекрёстка и ни одного X-образного. |
Автор: | Ser60 [ Пт янв 10, 2020 09:56:08 ] |
Заголовок сообщения: | Re: RSLK от TI (Robotic System Learning Kit) |
Получается - надо картинку отразить вниз и добавить ребро с нулевым весом, соединяющее верхнюю и нижнюю точки. Но Ваше решение действительно проще. |
Страница 6 из 14 | Часовой пояс: UTC + 3 часа |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |