Да, таймеров у EFM32 меньше, чем, например, у ST. Однако, если нужет синхронный захват, то его легко организовать с помощью модуля PRS. Киты их стоят дорого, наверное, потому, что на них установлена уникальная система измерения тока. Вместо Китов дешевле просто распаять МК на своей плате.

По общим параметрам, EFM почти совпадает с MSP432. Тоже 4 таймера, толпа UART/USART, 48МГц тактовая... Но, у тех кристаллов, на которые я нацеливался (Giant Gecko в легкопаябельном корпусе и по-дешевле) у таймеров всего по 2 канала захвата (и отсутствие PRS). Зато есть модуль AES. Так что пока не нашел, чего-нибудь, что меня бы в них привлекло.

Кстати, что меня привлекает в MSP - регистры xxxIV - interrupt vector. Очень облегчают работу в прерываниях. Это я прочувствовал, когда переписывал драйвер под STM - там мне его очень не хватало.

А тут сбылась мечта. Всё время мучался вопросом, как не допустить переразряда батареи. Известно, что LiPo аккамуляторы очень не любят этого. Но вот когда делал плату для нового Linefollower, думал, что надо бы... да вот только все входы АЦП уже были заняты. Зато у робота на MSP432 (хоть там не LiPo, а NiMH) для лабиринта АЦП всё еще не занято, и почему бы не сделать измерение напряжения на батарее? Конечно, со свободными выводами у RSLK-MAX уже становится напряжно, но, пока для облегчения жизни, я решил нагло воспользоваться входом обратной связи предназначенной для "руки" (потому как не вижу, чтобы в curriculum появились бы лекции посвященные этой теме). Так как напряжение батареи 7-8-9 вольт, а максимальное напряжение подаваемое на вход АЦП - 3.3в (в качестве опоры буду использовать напряжение питания), то необходим делитель. Делитель решено было применить 1:3 - тогда верхняя граница будет 10в. А вот из каких номиналов делать этот делитель? Т.е. какое выходние сопротивление этого делителя должно быть? Опыта у меня в таких делах особо нет. Как-то раз делал фирмварь для одного устройства. Там нужно было контролировать напряжение резервной батареи cr2032. Она подключалась через 1 Мом и повторитель на ОУ к АЦП. А тут из параметров АЦП есть только 15пФ и 300 ом. Ну, смеха для решил для начала взять 100 и 200 килоом. Но такой пары не нашел - пришлось напаять 1 мегаом и 470 килоом. Измерил тестером делитель: 7.50в после делителя дали 2.32 - примерно похоже.

Теперь, думаю, надо заняться программной частью. С АЦП уже работал, когда делал 15-ю лабораторную работу "Data acquisition". Там при помощи АЦП считывалась информация с сенсоров дистанции. Начал изучать, что там был понаписавши. Оказалось, для периодичного запуска АЦП использовалось прерывание от таймера... в котором "вручную" делался запуск преобразования и в цикле ожидалось появление результата преобразования. Какой ужос! Т.е. реально - без прерываний. Для лабы это сойдёт, но для серьёзной работы - никуда не годится. Разумеется, я планировал делать не один отсчет, а несколько, с каким-либо периодом и еще пропускать результат через ФНЧ, поэтому меня интересовало, как запускать периодически преобразование и как потом по прерыванию считывать показания. Проблема в том, что свободных таймеров больше нет, поэтому надо бы привязаться к какому-нибудь периодическому процессу. Посмотрел, откуда можно запускать преобразование. Это нужно смотреть в даташите на конкретный контроллер. В MSP432p401r мне показалось удобным использовать TA2.2 (Timer_A2, CCR2). Так что период опроса получился 2.5мс - 400 раз в секнду. При этом, недостаточно просто запустить таймер и загрузить число в CCR, надо еще и задать режим вывода (Set/reset, toggle итп. - потом будет ясно почему). На порт его выводить не нужно, но можно для контроля. После чего сделал еще обработчик прерывания АЦП: так как у меня пока всего один канал, я его написал элементарно - просто считывание буфера, которое уже само по себе снимает запрос прерывания. Итак, делаем запуск - показывает всего 5.4в, вместо 7.5в. Что-то не то.

Начал ломать голову на тему, а не воткнуть ли мне после делителя повторитель на ОУ (благо на плате RSLK-MAX есть один лишний). Но пока собирался это сделать, продолжал размышлять. Похоже, что из-за высокого выходного сопротивления делителя постоянная времени получается выше, чем время, выделенное на длительность sampling-а. Можно увеличить время этого самплинга (сейчас есть 32tclk, но можно увеличить до 192). И тут я вспомнил, что у этого АЦП есть такой режим, как Extended Sampling (в отличии от Pulse sampling). Вот не могу вспомнить, встечал ли я такой режим у других микроконтроллеров (или просто не обращал внимание)? Так вот pulse sampling - это когда фронт импульса запускает череду процессов - накопление заряда на измерительном конденсаторе и следом сам процесс преобразования. Extended Sampling, в свою очередь делает так, что всё время пока длится запускающий импульс - накопительный конденсатор подключен к входной цепи (т.е. постоянно сэмплируется), а по окончании импульса запускается процесс преобразования. Поэтому, я могу его растянуть аж до 2.4мс! В общем, поменял этот битик в конфиге (с pulse на extended) и сразу показания стали 7.6в. Потом, немного по подбирал коэффициенты, так как они были расчиты исходя из номиналов делителя и опоры 3.3в, которые на самом деле не являются точными, пока не получил показаний совпадающих с показаниями тестера.

Подключил к лабораторному БП и проехался в диапазоне 6.2в - 10.0в - показания примерно совпадают (минус 0.1в). Эта погрешность возникает из-за того,что я измеряю напряжение после ключа , подающего питание на схему и на котором тоже немного падает напряжение. Это я вижу замеряя тестером напряжение на батарее и после ключа - напряжения различаются как раз примерно на 0.1в. Подключался после ключа а не до, чтобы при выключенном питании этот делитель не разряжал батареи. Мммм, подключать к калибратору, я пожалуй не буду - для моих целей показометр получился достаточно хорош. В противном случае, надо бы использовать в качестве опоры внутренний опорник REF_A и делитель делать на более низкое напряжение, так как этот модуль может выдавать 1.2, 1.45 и 2.5в.

Смотрел на днях вебинар от ST про Machine Learning Core. Толком ничего не понял, видимо, это еще не про меня. Да и пример, где приводилось обучение, был слишком тривиальный - его вполне можно сделать простым алгоритмом, без искусственного интеллекта. Но, там рассматривались варианты размещения вычислительных мощностей. И для систем требующих быстрого принятия решений указывалось, что лучше если этот MLC находится у сенсоре, а не где-то вдали, куда требуются каналы связи, которые могут иметь низкую пропускную способность или надёжность. А так как в этом вебинаре для прмера использовался датчик ускорения, я начал снова думать на тему, которая меня уже пол-года мучает.

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

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

Но у меня же есть плата Thunder Sense 2 - а там есть акселерометр с магнитометром. И вычисление координат можно было бы делать на процессоре EFM, что стоит на той плате, а роботу просто передавать готовый результат. Проблема еще, конечно, с размещением. Лучше, было бы чтобы сенсор находился по середине колёсной оси. иначе, придётся делать коррекцию от положения сенсора к центру робота (смещение с учетом направления, куда повернут робот). Но там находится шасси. Ближайшее место получается прямо под платой LaunchPad. Еще вопрос, удастся ли туда этот Thunder Sense засунуть.

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Акселерометры пока не прониклись... зато, получил новый модуль для детектирования цвета. Встречайте модуль VEML6040 производства Vishay. У меня нет большого опыта, но из трёх сенсоров цвета, котрые я подержал в руках - этот самый простой, пожалуй. Общается по i2c имеет всего один конфигурационный регистр и 4 регистра для считывания результата. Всё. Нет даже статуса, сообщающего, что измерения выполнены и результаты доступны. В конфигурационном регистре можно выставить время интегрирования от 40мс до 1280мс, ручной или автоматический режим запуска, бит для ручного запуска и бит выключающий сенсор. Поэтому, чтобы им пользоваться достаточно записать 0 в конфиг и сенсор начнёт работать в автоматическом режиме с временем интеграции 40мс. Хм, для проверки валидности данных (что они взяты из одного цикла интегрирования), пожалуй, надо сделать повторное считывание и сравнение. Ну и принимать данные как валидные, если оба раза считались одинаковые данные.

Ну а теперь, надо бы заняться реальным определением цвета. Изначальный, мною реализованный алгоритм был крайне туп: превышение некоего порога указывает на наличие соответсвующего цвета. Но это меня не очень устраивало - хотелось подвести какую-нибудь математическую базу. Поэтому попытался для начала попытаться разместить показания сенсоров в трёхмерном пространстве RGB и вычислять расстояния до координат точек, соответствующим ожидаемым цветам. Например красный: 255,0,0; зелёный 0,255,0 итд.

Ну и то расстояние, которое в этом пространстве окажется меньше (и меньше определенного порога) - и является требуемым результатом. Да вот с порогом у меня как-то не сошлось. Если интенсивность освещения мала - цвет не определяется, если большая - начинает видеть цвета и на "белом" фоне. Поэтому ничего глупее не придумал, как провести нормализацию уровней:
Rнорм = R/(R+G+B)
Gнорм = G/(R+G+B) итд. Вот это был fail. Функция стала возвращать почти всегда один результат - черный цвет. Проведя моделирование в Excel понял, что в этом случае все контрольные точки имеют среди кратчйших расстояний и расстояния до "черной координаты" (0,0,0). А так как проверка начинается именно с неё, то на этом варианте всё и заканчивается. Короче, я понял что это не решает мою задачу.

Ну для определения цвета существует еще куча возможностей.. Есть CIELAB, CIELUV, HSI. Ну, первые два очень крутые способы описания цветового пространства, поэтому решил воспользоваться обычным ширпотребным HSI - Hue, Saturation, Intensity. Вот этот Hue и есть искомая вещь. Жаль только, что она выражается в виде угла круга. Ну и для выяснения, нужно ли выделять цвет, можно воспользоваться параметром насыщенности: если насыщенность недостаточна - цвет белый (оттенки не волнуют).

I = (R+G+B)/3 - интенсивность
S = 1 - min(R,G,B)/I - насыщенность.

Так как сама по себе интенсивность мне не нужна, формулу для насыщенности сделал такой:
inv_saturation = 3 * min(R,G,B) / (R+G+B);
вычитание из единицы тоже выкинул - мне без разницы какое сравнение делать.

Это была самая лёгкая часть. А вот формула для вычисления Hue (ой, мне лень вырисовывать корни и дроби, потому вставлю всю картинку):


Вот этот арктангенс и есть небольшой камень преткновения. Если тупо считать дробь, то ничего не получится. Потому как простой арктангенс может вернуть результат только от -90 до +90 градусов. Т.е. первый и четвёртый квадрант. После вычисления дроби информация о втором и третьем квадранте теряются. Поэтому, проще оказалось эту дробь рассматривать как координату в плоскости XY:
X = 2*R - G - B, Y= sqrt(3)*(G - B). И вот знаки X и Y указывают на квадрант в котором находится точка.


Если нарисовать этот круг, получается, что красный находится на 0 градусе, желтый на 60, зелёный - 120, светлоголубой 180, синий -120, фиолетовый - -60. Кстати, если взять синус и косинус от каждой координаты, то выяснится, что координата X принимает значения плюс-минус 1 и 0.5, а координата Y - 0 и плюс-минус корень из 3 пополам. Поэтому, вычислять углы нет особого смысла. И можно из формулы для координаты Y выбросить этот "корень из 3". Тогда если Y близок к нулю цвет или красный, или голубой (в зависимости от знака X), а если Y примерно равен X, то остальные 4 цвета (и тоже определются знаками X и Y). Причем, это "близко к нулю" можно поставить на границе в 30 градусов. А синус 30 есть 0.5 - поэтому "порог" можно ставить как раз на этом уровне - если Y находится в диапазоне от -0.5 до +0.5 - это близко к 0, иначе - всё остальное.

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

====

На позапрошлой неделе задумался о том, что хорошо, что сделал плавный разгон, а вот как быть с плавным торможением? Проблема в том, как вычислить с какого расстояния надо начинать тормозить. И пока я кручу эту мысль в голове, вдруг вывалилась мысль, что у меня еще одно из самых тормозных мест - поворот робота. При этом, я всегда знаю, на сколько я хочу повернуться и всегда примерно знаю, на сколько уже повернулся. Поэтому в функцию поворота вставил код разгона. Сначала, сделал так, что робот половину поворота разгоняется, а вторую половину - тормозит. Но, оказалось, что делать разгон с минимума до указанной в конфиге скорости поворота, а после 45 градусов (если поворот на 90) делать торможение до минимума, выходит, что почти половину поворота робот выполняет на минимальной скорости. Поэтому, решил, что задаваемая в конфигурации скорость поворота будет минимальной скоростью, до которой робот будет при торможении сбавлять скорость. При разгоне, решил разрешить разгоняться до максимальной скорости. Погоняв робота по трассе, так же решил сместить точку начала торможения на 60 градусов (тоже для 90 градусного поворота). Но, похоже, просто введу в конфиг еще парочку параметров, чтобы при необходимости я мог быстро изменить эти углы в любую сторону в зависимости от обстоятельств.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

Летнее затишье. Пока купаемся, развлекаемся - не до роботов. Хотя небольшие безрезультатные подвижки есть. Поначалу взбрелось мне сделать полный функциональный аналог робота на PSoC5. Попытался сделать 8 каналов захвата (в результате получилось 8 таймеров с захватом синхронно работающих от отдного ведущего таймера) для сенсора линии. Правда это съело все ресурсы, так что даже дисплей OLED через SPI уже не мог подключить. Поэтому эту затею отбросил. Зато, решил подключить ПЗС линейку. Сделал схему генерящую необходимые сигналы - на осциллографе проверил. Но саму ПЗС не подключал, так как нужно было бы сделать стенд: камера, мишень итп. И сначала посмотреть, что выдаёт матрица на выходе, и заняться АЦП. Вернее, с DMA который будет с АЦП данные складывать в буфер. Но это подождёт, так как пока я снова не вижу, где эту ПЗС разместить в удобном месте на роботе.

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

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

Мне тут полтора месяца назад презентовали ноутбук с дохлым винчестером. А так как у меня завалялся лишний SSD диск, я вставил его и пытаюсь пересесть на него - сделать "походным" компьютером. Занялся инсталяцией Keil и CCS. CCS ставил сразу свеженький - уже 10-й. И снова проблемы с программатором. Keil-у поставил какую-то поддержку XDS110. Да вот Кейл её не видит. Если ставить 32-битную - работает, ставлю 64-битную - говорит, что нет какого-то файла (хотя файл на самом деле есть и именно там где оно ищет). В гугле нашел описание похожей проблемы - там TI послал в Keil. Зато нашел, что вместо XDS110 можно пользоваться каким-то CMSIS-DAP - включил его и пока успокоился.

Тут же решил проверить, а как всё работает в CCS? Скачал лабораторные работы, проимпортировал их, быстренько накидал решение для 3-й лабораторной работы (на ассембелере функция вычисляющая 119сколькототам/(x-1058)) и попытался загрузить под отладку. А отладка не идёт. Говорит, что нет соединения. Снова полез в гугл. Выгуглил, что "у вас в проекте не стоит галочка Connect to target on debugger startup". Смотрю, и вправду, галочки нет. Но ведь была... ааааааа. И тут я начинаю припоминать, что когда скачивал там мелькнула цифирка 1 на конце. Значил, это уже новая версия лабораторных работ. В версии 1.00.00 галочка стояла, а в 1.00.01 - пропала. Проверил еще несколько проектов из этого пакета, галочку не нашел.

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

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Спасибо, что не перестаёте публиковать свои приключения. Очень интересно, читаю как детектив, пожалуйста не бросайте по возможности. С подобными проблемами никогда не сталкивался, поэтому решение предложить не могу.
В плане Robotics - у меня этим летом был проект со студентом - он решил сделать шагающего робота. Сам он из Вьетнама, впрочем это неважно, а важно лишь то, что несмотря на вирус остался на лето жить в общаге и домой не поехал. Короче, из-за ограничений доступа к ресурсaм на кампусе (также из-за вируса) он под это дело даже купил себе из проектных денег 3Д принтер для выпечки деталей. Вот видео первых шагов робота. Мы его сразу задумывали сделать на силлабовском Bluetooth модуле, чтобы можно было управлять роботом с телефона. Вот схема:

Спойлер

Модуль генерирует 8 аппаратных ШИМ каналов для серв. Выводы со стрелками зарезервированы на будущее. Акселерометр на плате протестировали, но пока не задействовали, также как и кнопки, которые предлагалось закрепить на концах ног для определения момента касания земли. Для простых шагов как на видео это не нужно, но мы хотели что-то типа танцев реализовать, хотя и не успели. Модуль повёл себя идеально, похоже, это было правильное решение делать всё на нём. Написал идеально, потому что, несмотря на корявый код студента, он весьма лихо справлялся с вычислением триг и обратных триг функций для серв в реальном времени (с дефолтными библиотеками), и всё это даже не мешало функционированию Bluetooth стека. Передатчик управления реализовали на Thunderboard-2 демо-плате, планировали написать Android приложение, но тоже не успели пока. Однако, кое-как управлять можно с телефона и сейчас, записывая команды в характеристику профиля, например, через стандартное приложение EFR Connect. Лоханулись мы сильно лишь с 6.4В батареей и размерами. Из-за последних (точнее веса) энергии батареи на сколь-нибудь продолжительное шагание не хватает, сервы жрут непомерно, поэтому пока питаем робота через сетевой адаптер. Надо будет более мощную и литиевую батарею поставить. Удивительно, что несмотря на работу студента без присмотра на удалёнке и небольшой его опыт, на плате ничего не сгорело (стучу по дереву).

Ещё этим летом работал с новыми (для меня) Bluetooth модулями BL652 (Nordic), BlueNRG (ST), и DA14531 (Dialog). Последние новые не только для меня, а про первые написал статью здесь. Почему-то половине проголосовавших она не понравилась, хотя мне модули понравились очень. После статьи занимался программированием их на С в среде Segger Embedded Studio. В общем, ничего, жить с ними можно. По потреблению они лучше BGM13, но после выпуска BGM22 особого смысла в них в этом плане не вижу. Однако, они меньше по размерам и несколько дешевле силлабовских, особенно если достаточно BL651. Упомянутые модули от ST, похоже, скоро сгинут в лету из-за потребления, несмотря на очень логичные API (пробовал их под Keil, даже где-то понравилось). Однако, такого удобства с разработкой Bluetooth как у силлабов нет ни у кого. Впрочем, они обрадовали, что с выпуском в сентябре релиза версии 5 Студио, предыдущие проекты под неё следует адаптировать руками, автоматически это не делается. Я уже начинаю уставать от этого. С Диалоговскими модулями разговор не окончен. Я долгое время общался с их службой поддержки, пытаясь убедить их о баге в их стеке. Наконец, мне это удалось, но пока исправленной версии нет. Эти модули идеально подходят для малых проектов, имеют замечательные параметры по потреблению и минимальное число ног и программируются в собственной среде, даже сразу под RTOS, но, к сожалению, под какой-то неведомой. Впрочем, фирма предлагает решения на основе упрощённого их программирования "без написания кода" (codeless), посмотрим, может напишу статью про них. Последнее - наш с сыном проект часов на сайпровском PSoC-4 BLE модуле с автоматической установкой времени со смартфона. Уже сделал несколько таких для друзей, надо будет про корпус подумать.

Шагоход интересный. Еще интересней, как он будет поворачивать. Вроде как стоя на 3 точках он может выполнить небольшой поворот корпуса. Но это надо углубляться в проблему. Пока в проблему не углубился, всё кажется простым.

Я тут вместо новых модулей осваивал старые. Коллега тут, не изучив вопроса закупил BT модули HC-06 (это еще Basic Rate) и просил помочь их связать. Выяснилось, что HC-06 разных есть вагон и еще одна тележка. И пока подобрали, на какой синтаксис команд оно отвечает, потратили много времени. И оказалось, что "новые" HC-06 мастером работать не могут, надо НС-05. Зато, я вытащил из своих закромов старый модуль, купленный более 10 лет назад. Опознавательных знаков на нём нет, на синтаксис тех HC-06 не реагирует... но удалось кое как подобрать к нему подход. Оказалось, это старый HC-06, которому всё же можно изменить роль на мастер и тогда удалось сцепить старый HC-06, как мастер с новым HC-06, как ведомым.

Хотел было пожаловаться, что строить безцельно роботы пропадает интерес, так как соревнований, может, больше не будет... Однако, только что заметил, что появилась информация о следующем чемпионате. Снова будет проходить в 6 этапов, и первый этап, как и в прошлом году, будет в первую субботу сентября. Снова многие школы будут недовольны. Правда, выяснилось, что я не на ту лошадку поставил. В этом году в Елгаве не будет лабиринта. Будут только базовые соревнования: Sumo, Folkrace, LineFollower. Ну, может, информация еще изменится, потому как таблица скорее пустая, чем полная. Из 6 этапов есть информация только про 2 (и ни в одном пока нет лабиринта). Остальные столбики пока пустые.

Так что нужно бросать лабиринт и начинать серьёзно заниматься LineFollower-ом.

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

Ударим соревнованиями роботов по пандемии. Или: "вопреки covid-19 соревнования всё же прошли". Даже не знаю, какой заголовок лучше.

Позанимался я тут Linefollower-ом. Решил расширить своё "секретное оружие". Так как у робота на PSoC5 есть таходатчики, то решил их задействовать для учета пройденного расстояния. А для того, чтобы ошибка не накапливалась к концу трассы, решил, что таходатчиками я буду измерять расстояния от последнего пересечения. Таким образом ошибка может накапливаться только в пределах одного "участка". Вот только проблема как выделить под это дело память? Пока что подумал, глядя на фото прошлогодней трассы, что достаточно один "участок" разбивать на 4 под-участка. Т.е. мне нужно фиксировать до трёх расстояний. Для участков решил выделить место для 10 (пока трасса имеющая наибольшее число пересечений в TSI - 4, что даёт 9 участков). Каждый под-участок я кодирую двумя битами: стоп, маленькая скорость, большая скорость и максимальная скорость. Этим я надеюсь вычленить длинные прямые участки, чтобы их проходить на максимальной скорости.

А тут организаторы подбросили нововведение. Этап в Сигулде разбили на две части. Одна часть будет уже в октябре и будут участвовать только роботы в категории "электроника", а в феврале - роботы категории "Лего". И Так же разбили этап в Прейли: В начале октября будет один этап для "Лего" в "Карандаше" в городе Резекне, а в январе "электроника" в Прейли. Я, естественно, на "Лего" этапы не поеду. Это сделано, чтобы выполнять требования законов о количестве участников массовых мероприятий в условиях пандемии.

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

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

Ну вот, приехал я с утра пораньше на соревнования. Смотрю, пусто. Правда уже стоят столы с рингами для мини-сумо и две очень пыльные трассы для LineFollower. Для начала взял мерную ленту и промерял почти всю трассу. В робота я эти данные ввести не мог, так как еще не было известно где будет старт и в каком направлении нужно будет роботам бежать. Решил, тогда попробовать запустить старого робота (без энкодера). А он оказывается трассу не видит. Во-первых туда хоть и сквозь облака, но светит солнце. А во-вторых, снова сенсоры линию видят недостаточно контрастно. Вернее, так: если сенсор стоит точно над линией - он её видит прекрасно. Но, проблема в том, что ширина линии 15мм и шаг между сенсорами тоже 15мм. Поэтому, если линия находится ровно по середине, сенсор оказывается на границе линия - белое поле. И вот в этом месте белое всё же преобладает. Но настроил порог, так что робот все же линию разглядеть может, если солнце не светит прямо. Сенсоры, которые я поставил на робота с PSoC5, линию видят гораздо лучше. GP2S60 от Шарп против Кингбрайтовских KTIR0711S. К началу соревнований солнце ушло, так что мне оно проблем не создавало.

В этом году в связи с эпидемиологической обстановкой, решено гостей из соседних стран не приглашать, поэтому сегодня литовцев не было. Было как-то тихо, спокойно, без особой толпы. Правда, трасса была доступна всего один час. Но роботов (в категории "электроника"), тоже было всего 5 штук в категории студенты/любители и 3 у школьников. В категории "Лего" - 6. Хотя, опять, очень много школ не принимали участие сегодня. Я со своими роботами сделал по 3 заезда, а потом, посмотрел результаты. Оказалось, что у моего робота пока самый лучший результат. Поэтому я решил его больше на трассу не выпускать, а напрягаться, только, если кто-нибудь переплюнет моё время. И, ирония судьбы, самым быстрым оказался не тот робот с которым я тут возился почти две недели, а старый робот, который провалялся в коробке с февральских соревнований и которому я даже прошивку не менял (И у которого наверняка еще и бага в i2c драйвере).


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

А робот на PSoC5 с каждым заездом всё улучшал результат. Начал с 15 секунд. На втором заезде робот "сорвался" - потерял линию. Я говорил, что трасса была грязная? Конечно, перед соревнованиями её помыли, но всё равно после заезда колёса у робота были в пыли. А у меня дома как назло, когда собирался на соревнования, не нашлось малярного скотча. Обычно по клейкой стороне колесом проедешь и вся пыль с колеса переходит на скотч. Поэтому, решил, что надо после каждого заезда снимать с роботов колёса и нести к умывальнику и мыть колёса. Так что время стало улучшаться и пятый заезд вытянул этого робота с последнего места на предпоследнее (четвёртое) место.

Ну и немного фотографий Лего-сумо, мини-сумо и iRobot-сумо:

трасса для folkrace:

Видео демонстрационного заезда. Рекомендую выключить звук (я не знаю как удалить звук из видео) и извините, что руки трясутся - трудно всё делать одному.

Спойлер

Похоже, Вас можно поздравить с первым местом в соревнованиях(?) Заслуженно!
Я правильно понимаю, что робот на видео собран на основе PSOc-5? А есть фото робота-победителя?

Да, спасибо за поздравление, хотя тут опять просто "повезло", что не было команд из Литвы.

Увы, на видео, как раз победитель. Робота на PSoC я снимал, но дома просмотрев, из-за плохого качества съёмки, видео решил не выкладывать. Вот фото обоих, чтобы сравнить их размеры:

Ближний: на stm32f051, а тот что подальше - на PSoC5. Вот его вид сверху и снизу.

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

Вот так выглядит старый робот с подключенным пультом для его конфигурирования. То что держатель батареи не прикручен - не беда. Держится нормально и батарейка во время заезда не теряется. Был на этих соревнованиях случай у одного робота из категории школьников, что во время заезда батарея выскочила и из-за этого робота занесло и он потерял линию. А потом, когда я смотрел как его "ремонтировали", выяснил, что батарея была просто прилеплена на скотч. Просто прилеплена, а не "примотана скотчем". Рама соединяющая основную плату с платой сенсоров у меня есть двух видов. Эта длинная, а есть покороче. Собственно они соответствуют двум FPC шлейфам. Короткий шлейф, возможно будет нужен на трассе с мелкими поворотами как на трассе в TSI:

С длинным "носом" пройти "улитку" (или инь-янь, называйте как хотите) довольно проблематично. В предыдущие разы я заметил у многих в том месте были проблемы и роботы вылетали с трассы.

Немного поболтал с конкурентом. Его заинтересовали колёсики на моём роботе:

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

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

Ну что ж, теперь надо готовиться к следующим соревнованиям 24 октября в Сигулде и 19 декабря в TSI. Там помимо Linefollower будет еще и лабиринт.

Очень интересно! А есть фотки роботов конкурентов - те, что для следования по линии?

Конкурентов я не фотографировал. Это смахивало бы на промышленный шпионаж. Хотя, как мне рассказывали, что на больших международных соревнованиях это процветает - все хотят узнать что там у конкурентов, ведь там уже крутятся реальные деньги. Поэтому там роботов вытаскивают из коробки перед заездом и сразу прячут обратно на финише. Правда ничто не мешает просто смотреть, когда роботы идут по трассе. Но кинематическая схема у всех почти одинакова. Различаются нюансы. Причем некоторые конструкции выглядят довольно хлипко и бывали случаи, что когда робот вылетает с трассы и ударяется о что-нибудь - он просто разваливается. У меня плата является несущей рамой, а у других или кусок оргстекла, или напечатанная на 3D принтере. У кого-то сделана печатная плата, а кого-то ардуиновские модули приклеенные термоклеем. Сенсоры тоже, у меня стоят они полукругом, а кого-то в прямую линию. Шаг, кстати, тоже различается. У моего конкурента, вроде тоже 8 сенсоров, но расположены с меньшим шагом. За счет этого у него сенсоры, может, лучше видят линию, но рабочий диапазон сенсоров за счет этого меньше. У одного из школьников линейка сенсоров была шире. Думал, что там больше сенсоров, но приглядевшись, заметил, что тоже 8, только они стоят с большим шагом, т.е. показания сенсоров иногда пропадают. В результате принятие решения должно запаздывать, ведь если только что линия была под третьим сенсором и исчезла, то некоторое время неизвестно, куда она делась и надо ждать срабатывание 2 или 4 сенсора. И когда я одним глазом поглядывал что творится на трассе, то заметил, что его робот постоянно зацикливался в "той петле".

У многих видел торчащий или "болтающийся" блютус модуль. Или HC-05/06, или HM-15 и запуск и останов робота проводили со смартфона. Один из нашего клуба показывал, что он для управления сделал свою аппликацию. Но, как я поглядел, там было очень мало настоечных параметров. Остальные, наверное, параметры меняют прямо в программе и пере заливают прошивку после каждого изменения. Не могу утверждать, что это именно моё влияние, но когда я начал участвовать в соревнованиях у моего робота сверху стоял OLED дисплей (теперь я его сделал съемным, чтобы уменьшить вес робота), через который я смотрел гистограммы сенсоров, конфигурировал параметры и во время заезда показывал номер участника, а у других, скажем сумо-роботов и folkrace роботов были дип-свитчи которыми участники задавали "стратегии" роботам. Через некоторое время, заметил, что на сумо-роботах стали появляться маленькие дисплейчики 128х32, а на одном folkrace видел даже 1,3" TFT с тачскрином. Так что идеи перенимаются и развиваются.

===

Собственно, вернусь к RSLK. Так как я уже сделал измерение напряжения батареи и тем самым задействовал АЦП, задался вопросом, как это же АЦП использовать для дальномерных сенсоров. Переконфигурировать каждый раз мне лень, поэтому задумался, как всё оцифровывать разом и батареку, и дальномеры. Поэтому я отказался от растянутого сэмплинга и делитель напряжения батареи завёл на повторитель на ОУ (благо на плате один есть свободный) и прикрутил и подсоединил шарповские дальномеры. проблема, конечно, с запуском преобразования. Таймеров у меня нет свободных, а для дальномеров рекомендуется их семплировать с периодом 500мкс, а не 2.5мс, как у меня сейчас. Поэтому пришлось перенастроить SysTick таймер и запуск на преобразование запускать оттуда. При этом, размышляю на тему а не установить ли мне пороги на АЦП, чтобы возникало прерывание, если при работе напряжение батареи просядет ниже критического или показания дальномеров покажут опасное приближение к преграде. Технически такая возможность есть.

Посмотрев, что есть каталог с проектом, который шевелит рукой, решил посмотреть какие есть еще проекты. И нашел, что там с незапамятных времен есть два каталога/проекта Competition_Distance и Competition_BLE. Попробовал собрать первый, не получилось. Хидер-файл Tachometr.h не соответствует вызову функции из tachometr.obj. Я так понял, что там вызывается функция еще старого типа, когда в качестве параметров в функцию передавались 6 ссылок на переменные направление вращения, число шагов и текущие обороты колес, а в новой там передаются две ссылки на структуры, содержащие эти же параметры. Думал-думал, а потом начал сравнивать разные версии и оказалось, что в новой версии это несоответствие уже устранено. Скомпилировал. запустил. Ну да, работает: при приближении к препятствию поворачивается и катится в другую сторону. Но как-то примитивно. Скомпилировал второй проект, там надо еще подключиться через bluetooth, но даже без подключения на дисплее эта программа выдаёт "диагностику": состояние bump-сенсоров и показание сенсоров-дальномеров. Ну, хотя бы убедился, что дальномеры работают.

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

Сегодня заметил, что выложили одноминутное видео о соревнованиях. Правда, linefollower-ы туда не попали. Наверное, не такие зрелищные:

Спойлер

Наконец-то закончилась сумасшедшая неделя и моду ответить. Что будет если робот вылетит с трассы? Зачит-ли это, что он автоматически проиграл заезд или он всё-таки пытается найти линию, чтобы закончить пробег?

Давно подвигаю Вас на установку Bluetooth модуля в робот стационарно как ко-процессор. Тогда появятся дополнительные линии АЦП помимо удобства дистанционного конфигурирования и управления. Мы с сыном в августе делали проект сбора данных с нескольких датчиков, записи их во внешнюю флеш и загрузку потом в смартфон для просмотра. Даже под версией Bluetooth 4.2 и с её ограничением на длину пакета, передать порядка 1МБ данных порциями по 240 байт не представляет труда. Скорость у нас в простом приложении без использованиия DMA (которого в сайпровских PSoC-4 BLE модулях нет) получилась порядка 60 kbps и это не предел и может быть увеличена раз в 5 на силлабовских модулях, а то и более если использовать Bluetooth 5.

Интересное видео! Похоже, с ношением масок народ решил не заморачивася, или они уже у вас неактуальны?

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

По поводу BT, я уже жалею, что в начале лета не заказал платы для пульта управления на BGM13 - даже с медленной почтой уже бы приехали. Всё ждал, когда появится новая идея, чтобы объединить заказ и доставку сделать курьером. Но, это тоже идёт медленно, потому как придётся разрываться на две части: писать хост и писать клиента. И каждого надо отлаживать.

На соревнованиях у коллег заметил на роботах для folkrace гнездышко для микроSD карточки. Похоже, они там тоже пишут журнал. Я в феврале был заказавши модуль с OpenLog, но из-за короновируса с Китая они так и не пришли. Но мне сказали, что у них в роботе стоит что-то другое, на stm32, которая тоже по UART принимает информацию и пишет на SD используя quadSPI, а не просто SPI. И сказали, что с очень большой скоростью. Вот только, я не могу найти в интернете, этот проект.

Размышлял, почему старый робот, оказался на первом месте. Изучал отснятые видео и заметил, что в начале (предварительный заезд), робот довольно сильно заносило на поворотах, а в последнем (демонстрационный) робота не заносило, но и к линии сенсор возвращался позднее. Возможно, это из-за того, что я "выравнивал" максимальную скорость робота с максимальными оборотами двигателя. Т.е. при повороте, колесо на внешней колее не ускорялось, а только тормозилось на внутренней. Правда, есть еще один момент. Я не знаю, что за прошивка находилась внутри робота. Как уже писал, этот робот провалялся в коробке без изменений с февральских соревнований, но исходники я корректировал (и отлаживал, только на другой плате - у меня их две). Поэтому я не помню, какие я изменения тогда в феврале сделал. А я что-то делал. Одна из "нестыковок" в том, что на видео (да и по результатам соревнований) я вижу, что робот бежит по трассе 14 секунд и выключается. А в конфигурации, я вижу, что этот параметр у меня установлен 35 секунд! Т.е. разница в 2.5 раза. И эта разница как раз и есть между частотой сэмплирования линии у разных роботов: у stm32 - 400 раз в секунду, а у PSoC5 - 1000 раз в секунду. Вроде как у меня была мысль и у робота на stm32 повысить частоту, вот только не помню, сделал я это или нет. В текущих исходниках стоит 400. Думал, подключиться дебаггером и посмотреть что за значения грузятся в таймеры, но дебаггер стёр прошивку и загрузил свою. Наверное, надо было где-то в настройках снять какую галочку, чтобы пройтись под отладчиком не перезагружая прошивку. Но так как я таким (взломом) никогда не занимался, всё запорол. Ну на следующих соревнованиях надо будет это иметь в виду и быстренько перекомпилировать прошивку.

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

У нас - неактуально. Похоже из всей Европы, у нас самый низкий процент заболеваемости. Тут каждую пятницу правительство рассматривает сколько в какой стране число заболевших и если превышается порог 16 человек на 100 тысяч населения, то такая страна попадает в желтый список и приехавшим (или вернувшимся) из той страны необходимо соблюдать двухнедельный карантин. Буквально за день перед соревнованиями, прошла информация, что Литва переступила этот порог, но правительство, тем не менее, решило пока Литву не включать в этот список. Зато в эту пятницу Эстония попала в список. Почему у нас такой низкий процент заболеваемости? А ХЕЗ. Может у нас населения реально гораздо меньше, чем считается "официально". Может у нас тестов проводится мало. В самом начале тест стоил 80 с лишним евро, а категорий людей, кто мог сдать тест бесплатно было очень мало. Сейчас, конечно бесплатно, но по предварительной записи. А кому охота добровольно сесть на карантин. Может тут многие уже втихаря переболели. А может, мы уже давно им переболели. Когда был на соревнованиях в феврале (ЧС объявили только 12 марта), меня поразило, что почти все поголовно школьники шмыгали носами и кашляли. А может, у нас выше устойчивость к этой заразе - так как у нас грипп, это нормальная сезонная болезнь. Даже, начинаю беспокоиться, если за зиму не переболею. Поэтому, у нас большинство, возможно и не заметило, что переболело. Повязки было одно время обязательны к ношению в общественном транспорте, но так как не требовалось именно маска, а достаточно, чтобы любой тряпкой был прикрыт нос и рот - тоже большинство быстро начало игнорировать это требование. Сейчас это только рекомендация и обязательно нужно носить, только если есть явные признаки заболевания верхних дыхательных путей (что тоже всеми игнорируется).

Кстати, у нас ходит анекдот, что когда правительство объявило, что все должны соблюдать дистанцию в 2 метра, жители возмутились, почему они должны стоять так тесно!

Почему не SDIO? Во многих STM32 есть этот модуль и он предназначен специально для SD карт памяти.

Это называется hot plug connection. Кратко об методе и условиях подключения в МК написано здесь. http://purebasic.mybb.ru/viewtopic.php?id=564#p7600

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

Разве вы не пишите код для робота? Используете готовый?
В первом случае если МК имеет модуль SDIO, модифицируйте драйвер чтобы библиотека FatFS (или что вы там используете) производила обмен с картой через SDIO.
Во втором случае, наверно сложно добиться хороших результатов если не можете написать код, заточенный под конкретную задачу (трассу, датчики и т. д.). Универсальный не всегда эффективный и маловероятно призовое место.

uldemir - если я правильно понял по поводу плат, у Вас уже сложился в голове проект приёмника на BT, точнее схема. Не поделитесь деталями, хотя-бы крупноблочно что помимо модуля планируется в приёмнике?
Насчёт SDIO, хорошо-бы для определённости обнародовать детали какое предполагаемое количество байт в посылке, период посылок, и их количество за пробег. Может и скорости обычного SPI хватит.