Как сделать на машине автопилот
Автопилот своими силами. Часть 1 — набираем обучающие данные
Привет, Хабр. Это пост-отчет-тьюториал про беспилотные автомобили — как (начать) делать свой без расходов на оборудование. Весь код доступен на github, и помимо прочего вы научитесь легко генерить такие класные картинки:
Вкратце
Краткое содержание для знакомых с темой: традиционно для набора обучающей выборки для автопилота на основе машинного обучения нужен был специально оборудованный автомобиль с достаточно информативной CAN шиной и интерфейсом к ней, что дорого. Мы поступим проще и бесплатно — будем набирать такие же по сути данные просто со смартфона на лобовом стекле. Подходит любой авто, никаких модификаций оборудования. В этой серии — вычисляем поворот руля в каждый момент времени по видео. Если в этом абзаце всё понятно, можно перепрыгивать через введение сразу к сути подхода.
Что-зачем-почему более подробно
Итак, ещё пару лет назад без серьёзных ресурсов большой корпорации в тему автопилотов было не сунуться — один только LIDAR сенсор стоил десятки тысяч долларов, но недавняя революция в нейросетях всё изменила. Стартапы из нескольких человек с простейшими наборами сенсоров из пары вебкамер на равных конкурируют по качеству результата со знаменитыми брендами. Почему бы не попробовать и нам, тем более столько качественных компонентов уже в открытом доступе.
Автопилот преобразует данные сенсоров в управляющие воздействия — поворот руля и требуемое ускорение/замедление. В системе с лазерными дальномерами, как у Google, это может выглядеть так:
Простейший же вариант сенсора — видеокамера, «смотрящая» через лобовое стекло. С ним и будем работать, ведь камера на телефоне уже есть у каждого.
Для вычисления управляющих сигналов из «сырого» видео хорошо работают сверточные нейросети, но, как и любой другой подход машинного обучения, предсказывать правильный результат их нужно научить. Для обучения нужно (а) выбрать архитектуру модели и (б) сформировать обучающую выборку, которая будет демонстрировать модели различные входные ситуации и «правильные ответы» (например, угол поворота руля и положение педали газа) на каждую из них. Данные для обучающей выборки обычно записывают с заездов, где машиной управляет человек. То есть водитель демонстрирует роботу, как надо управлять машиной.
Хороших архитектур нейросетей хватает в открытом доступе, а вот с данными ситуация более печальная: во-первых данных просто мало, во-вторых почти все выборки — из США, а у нас на дорогах много от тех мест отличий.
Дефицит открытых данных легко объясним. Во-первых данные — не менее ценный актив, чем экспертиза в алгоритмах и моделях, поэтому делиться никто не торопится:
The rocket engine is the models and the fuel is the data.
Andrew Ng
Во-вторых, процесс сбора данных недёшев, особенно если действовать «в лоб». Хороший пример — Udacity. Они специально подобрали модель автомобиля, где рулевое управление и газ/тормоз завязаны на цифровую шину, сделали интерфейс к шине и считывают оттуда данные напрямую. Плюс подхода — высокое качество данных. Минус — серьезная стоимость, отсекающая подавляющее большинство непрофессионалов. Ведь далеко не каждый даже современный авто пишет в CAN всю нужную нам информацию, да и с интерфейсом придется повозиться.
Мы поступим проще. Записываем «сырые» данные (пока что это будет просто видео) смартфоном на лобовом стекле как видеорегистратором, затем софтом «выжимаем» оттуда нужную информацию — скорость движения и поворотов, на которых уже можно будет обучать автопилот. В результате получаем почти бесплатное решение — если есть держалка для телефона на лобовое стекло, достаточно нажать кнопку, чтобы набирать обучающие данные по дороге на работу.
В этой серии — «выжималка» угла поворота из видео. Все шаги легко повторить своими силами с помощью кода на github.
Задача
Сразу чуть упростим — вместо угла поворота руля будем вычислять угловую скорость в горизонтальной плоскости. Это примерно эквивалентная информация если знать поступательную скорость, которой мы займемся в следующей серии.
Решение
Решение можно собрать из общедоступных компонент, немного их доработав:
Восстанавливаем траекторию камеры
Первый шаг — восстановление траекториии камеры в трехмерном пространстве с помощью библиотеки SLAM по видео (simultaneous localization and mapping, одновременная локализация и построение карты). На выходе для каждого (почти, см. нюансы) кадра получаем 6 параметров положения: 3D смещение и 3 угла ориентации.
В коде за эту часть отвечает модуль optical_trajectories
Определяем плоскость дороги
Траектория камеры в трехмерном пространстве — это хорошо, но напрямую еще не дает ответа на конечный вопрос — поворачивать налево или направо, и насколько быстро. Ведь у системы SLAM нет понятий «плоскость дороги», «верх-низ», и т.д. Эту информацию тоже надо добывать из «сырой» 3D траектории.
Здесь поможет простое наблюдение: автомобильные дороги обычно протягиваются гораздо дальше по горизонтали, чем по вертикали. Бывают конечно исключения, ими придется пренебречь. А раз так, можно принять ближайшую плоскость (т.е. плоскость, проекция на которую дает минимальную ошибку реконструкции) нашей траектории за горизонтальную плоскость дороги.
Горизонтальную плоскость выделяем прекрасным методом главных компонент по всем 3D точкам траектории — убираем направление с наименьшим собственным числом, и оставшиеся два дадут оптимальную плоскость.
За логику выделения плоскости также отвечает модуль optical_trajectories
Из сути главных компонент понятно, что кроме горных дорог выделение главной плоскости будет плохо работать если машина всё время ехала по прямой, — ведь тогда только одно направление настоящей горизонтальной плоскости будет иметь большой диапазон значений, а диапазон по оставшемуся перпендикулярному горизонтальному направлению и по вертикали будут сопоставимы.
Чтобы не загрязнять данные большими погрешностями с таких траекторий, проверяем, что разброс по последнему главному компоненту значительно (в 100 раз) меньше, чем по предпоследнему. Не прошедшие траектории просто выкидываем.
Вычисляем угол поворота
Зная базисные векторы горизонтальной плоскости v1 и v2 (два главных компонента с наибольшими собственными значениями из предыдущей части), проецируем на горизонтальную плоскость оптическую ось камеры:
Таким образом из трехмерной ориентации камеры получаем курсовой угол автомобиля (с точностью до неизвестной константы, т.к. ось камеры и ось автомобиля в общем случае не совпадает). Поскольку нас интересует только интенсивность поворота (т.е. угловая скорость), эта константа и не нужна.
Угол поворота между соседними кадрами дает школьная тригонометрия (первый множитель — абсолютная величина поворота, второй — знак, определяющий направление налево/направо). Здесь под at понимаем вектор проекции ahorizontal в момент времени t:
Убираем шум
Мы почти у цели, но остается еще проблема. Посмотрим на получившийся (пока что) график угловой скорости:
Визуализируем на видео:
Видно, что в общем направление поворота определяется правильно, но очень много высокочастотного шума. Убираем его Гауссовским размытием, которое является низкочастотным фильтром.
Сглаживание в коде производится модулем smooth_heading_directions
Результат после фильтра:
Это уже можно «скормить» обучаемой модели и рассчитывать на адекватные результаты.
Визуализация
Также легко построить покадровый график. Например, в IPython ноутбуке с установленным matplotlib:
На этом пока всё. В следующей серии — определяем поступательную скорость, чтобы обучить еще и управление скоростью, а пока что приветствуются pull-request’ы.
Самодельный автопилот на одноплатном компьютере (SBC) Tinker board и Arduino DUE
Идея постройки автопилота появилась примерно 2 года назад. Хотелось создать полностью автономный аппарат способный добраться из точки А в точку Б с возможностью ухода от столкновений и облёта преград, способного преодолевать зоны глушения или отсутствия спутникового сигнала. Также хотелось иметь удобное и простое управление с помощью мышки как это реализовано в играх (стратегии) управляя движением ЛА с помощью точек. Начинать всё пришлось с нуля, как и эту статью поэтому если есть ошибки напишите об этом в комментариях. Начну по порядку.
Аппаратное обеспечение
Изначально я не знал какое железо лучше использовать для этого проекта, но в итоге пришёл к выводу, что оптимальным вариантом будет связка микроконтроллер (МК) + одноплатный компьютер. Где МК решает задачу стабилизации летательного аппарата (ЛА), его движению по заданному курсу и высоте, а одноплатный компьютер решает задачу навигации и движения по маршруту. Поскольку в планах был уход от столкновений компьютер должен был быть достаточно мощным чтобы обрабатывать информацию от датчиков обнаружения препятствий, компактным и не слишком дорогим на том момент под это описание наиболее подходил TinkerBoard, Raspbery тогда это была 3B+ и сильно уступала по характеристикам. В качестве МК хотелось иметь arduino совместимый контроллер т.к. на arduino имелась огромная база готовых скетчей и поэтому выбор пал на DUE 84 МГц, 32bit ARM Cortex-M3 т.к. он был наиболее мощным и должен был компенсировать прямоту моих рук)).
В качестве датчиков ориентации изначально я планировал использовать MPU 9250 с фильтром Маджевика, результаты его работы были отличными. Главным преимуществом этого варианта было то, что все расчёты, включая калибровки датчиков (акселерометра, гироскопа и магнитометра), находились на МК. Но возникла проблема, фильтр плохо компенсировал линейное ускорение, которое постоянно возникает при толчках или резкой смене курса. Выражается это в показаниях тангажа и крена, в момент ускорения они начинают уплывать, а проходя через пропорционально дифференциальный (ПД) регулятор и особенно дифференциальную часть, уплывание создавало проблемы. Поэтому пришлось использовать датчик с уже реализованным фильтром BNO 055.
BNO в отличии MPU 9250 имеет на борту встроенный МК Cortex M0 который сразу рассчитывает ориентацию в углах Эйлера, кватернине абсолютной ориентации и рассчитывает линейное ускорение хотя этот датчик тоже имеет ряд недостатков. Основной проблемой данного датчика является автокалибровка а точнее то что её нельзя выключить это такая «фитча» этого датчика и есть у этой калибровки неприятное свойство пропадать, иногда абсолютно внезапно даже просто находясь на одном месте без движения. Отражается это в основном на рысканье которое в данном датчике привязано к магнитометру и должно показывать направление на магнитный северный полюс (курс) но иногда оно показывает на 100 градусов в строну, а потом ещё покалибровавшись может вернутся обратно))). В прочем проблему курса ещё можно решить с помощью синхронизации с GPS. В остальном датчик работает отлично, тангаж и крен он всегда определяет правильно, и линейные ускорения не сильно сказываются на его работе, если, конечно, ускорение не превышает 2G, т.к. этот порог используется для измерения вектора гравитации и компенсации дрейфа гироскопов.
Остальной набор железа выглядит следующим образом: GPS Ublox Neo M8N с USB выходом,
барометр BMP 280, сонар HSCR 04 для получении данных о наличии земли и более точной вертикальной скорости, EEPROM 24c16 для хранения данных калибровки и настроек ПИД, GSM модуль Neoway M509E для отправки сообщений о координатах ЛА на случай аварии.
Функциональная схема показана на рисунке 1:
Рисунок 1 — Функциональная схема Автопилота.
Программное обеспечение
Для разработки ПО я использую QT вместе с IDE QT Creator т.к. он наиболее мне знаком, а также благодаря кроссплатформенности я могу запускать свои программы как на одноплатном ПК с Debian так, и десктопе с Windows, что очень удобно. Для разработки ПО микроконтроллера используется Arduino IDE. Для наглядности постараюсь представить все разделы на рисунке 2.
Рисунок 2. — Архитектура АП (BNO 080 добавлен на будущее).
1) Графический интерфейс управления — представляет из-себя спутниковую карту с помощью которой осуществляется управление ЛА. Сама программа отображения спутниковых снимков не моя, она была украдена мной тут (её автор тоже пытался сделать что-то подобное).
Управлять ЛА можно с помощью точек (маркеров) либо кнопок WADS. Для управления по точкам, необходимо проложить маршрут полёта зелёными маркерами они ставятся мышью (ПКМ), и нажать загрузить маршрут, либо использовать (красный) маркер мгновенного перемещения (ЛКМ) и тогда ЛА с текущей позиции полетит к этой точке, для его работы необходимо установить галку в чекбокс «Ручное» от случайных нажатий.
Рисунок 3 — Графический интерфейс управления.
2) Ядро автопилота это та часть ПО которая вычисляется на одноплатном компьютере TinkerBoard. Ядро отвечает за навигацию и движение по маршруту. Для этого к компьютеру подключен датчик GPS. С его помощью можно получить текущее положение ЛА (широту и долготу) и сравнить это положение с тем, что имеется в маршруте полёта. В результате этой операции получается азимут на цель, который отправляется на микроконтроллер вместе с остальными параметрами полёта. В дальнейшем ядро можно оснастить своим IMU датчиком, чтобы реализовать ИНС. Например, можно использовать BNO 080 проинтегрировать, ускорение и получить скорость, а проинтегрировав скорость получить расстояние. Расстояние, полученное от ИНС, необходимо будет перевести в систему координат GPS (широту и долготу) для её использования в расчёте азимута.
Такую ИНС можно использовать в связке с GPS датчиком на случай временной потери связи со спутником, чтобы ЛА не пропустил «поворот» на точку. В момент работы от GPS ИНС будет постоянно корректироваться его показаниями и заполнять промежутки между периодами обновления GPS датчика. Таким же образом должен вносить поправки алгоритм машинного зрения или SLAM изменяя высоту точки и создавая смещения рассчитанного азимута. После окончания расчёта маршрута ядро отправляет по UART данные: азимут, высоту, угол атаки, тип точки, а также необходимо ли выполнять вращение вокруг этой точки.
3) Команды ядра выполняет микроконтроллер, основная задача МК следовать по заданному курсу на заданной высоте. Для этого на МК установлен IMU датчик BNO 055, барометр bmp 280 и сонар. Для движения по курсу используется азимут полученный от ядра он, сравнивается с текущим курсом и полученное рассогласование передаётся в ПД регуляторы управления рысканьем и креном. Управление тангажом осуществляется 2мя ПД регуляторами: 1-й определяет рассогласование текущей и заданной высоты, которое поступает на вход 2-го регулятора, при этом выход регулятора высоты ограничен текущим углом атаки, чтобы контролировать её набор. В случае, если в графическом интерфейсе тип точки выбран взлёт или посадка, для определения высоты используется сонар. Его показания комплексируются с данными барометра, чтобы наиболее точно определить расстояние до земли и вертикальную скорость. Помимо основных функций МК также собирает телеметрию о работе IMU датчиков, текущем направлении и высоте, передаёт их в ядро, где эти данные дополняются данными от GPS и поступают в графический интерфейс.
Заключение
На данный момент автопилот ещё находится на стадии полётных испытаний и полностью не настроен. Впрочем я провёл только два запуска и пока не подобрал коэффициенты для регуляторов.
Вообще ПД регуляторы мне кажутся не стабильными и хочется заменить их чем-то более надёжным, тем более они уже устарели. Также необходимо заменить расчёты с углами Эйлера на расчёты в кватернионах, т.к. последние более стабильно себя ведут при развороте ЛА на углы больше 120 градусов и полётах во время ветра.
Автопилот своими рукам. Добавляем электронное управление steer-by-wire на обычный автомобиль
Всем привет. Любому автопилоту, очевидно, нужно не только принимать решения по управлению, но и заставлять автомобиль этим решениям подчиняться. Сегодня увидим, как весьма доступными средствами доработать обычный автомобиль полностью электронным рулевым управлением (steer-by-wire). Оказывается, сам авто для разработки не очень и нужен, а большинство функционала можно с комфортом отлаживать дома или в офисе. В главных ролях всем известные компоненты из хобби-магазинов электроники.
Задумаемся на секунду, что нужно для системы электронного управления? Сервопривод, который может поворачивать колёса, и контроллер, чтобы сервоприводом управлять. Внезапно, всё это в большинстве современных автомобилей уже есть, и называется «усилитель рулевого управления». Традиционные чисто механические (как правило, гидравлические) усилители стремительно исчезают с рынка, уступая место узлам с электронным блоком управления (ЭБУ). А значит, задача сразу упрощается: нам остается только «уговорить» имеющийся ЭБУ усилителя выдать нужные команды на сервопривод.
Очень удобным для доработки оказался KIA Cee’d начиная с 2015 модельного года (скорее всего аналогично и его соплатформенники от KIA/Hyundai). Сошлись одновременно несколько факторов:
Итак, получена в распоряжение рулевая колонка в сборе:
Будем заставлять её крутиться. Для этого нужно создать у блока управления впечатление, что
Симуляция автомобиля
Нужно понять интерфейс между электронным блоком управления (ЭБУ) усилителя и остальным автомобилем. Нагуглив электрическую схему видим картинку:
Из схемы видно, что физически интерфейс очень прост:
Внешний вид и распиновки разъемов находим на том же сайте.
С питанием и зажиганием всё просто, берем 12V с обычного компьютерного блока питания. Но если просто подать питание и зажигание, усилитель полноценно не включится, и усиливать не будет. Дополнительно нужна информация от других блоков автомобиля: работает ли двигатель (чтобы не тратить энергию аккумулятора при выключенном), текущая скорость (чтобы делать руль «тяжелее» на скорости), наверняка что-то ещё.
Обмен данными между электронными блоками в современных автомобилях организован по шинам CAN (Controller Area Network). Это широковещательная (у пакетов нет адресов назначения) локальная сеть на витой паре, где каждый блок может публиковать свои данные. У каждого типа данных свой идентификатор. Например, в нашем случае усилитель руля рассылает значения угла поворота руля с ID 0x2B0. Часто бывает несколько физически разделенных шин, чтобы второстепенные блоки типа контроллеров стеклоподъемников не мешались обмену между критически важными компонентами. В Cee’d используется две шины: C-CAN и B-CAN (схема здесь, в части «Информация о канале передачи данных»). На C-CAN «висят» почти все блоки с ней и будем работать.
Выбор адаптера CAN-шины
Первым делом понадобится CAN интерфейс для компьютера. Детальный обзор возможных решений есть например здесь, цены варьируются от десятков до сотен долларов. По устройствам у нас относительно доступны:
Софта разного тоже много (за обзором опять сюда). Самый простой вариант — Linux c can-utils из SocketCAN, за который спасибо инженерам Volkswagen. Большой плюс SocketCAN в стандартизации — любое USB устройство с поддержкой протокола LAWICEL (pdf) видится системой как обычный сетевой интерфейс. Таким образом избегаем привязки к вендор-специфическому софту конкретного устройства. У текущей версии CANHacker есть небольшая несовместимость со стоковыми can-utils по работе с USB, поэтому берём патченную версию отсюда. Raspberry Pi с CAN шилдом работает со стоковым пакетом can-utils из Raspbian OS без проблем.
Подключение к шине, запись пакетов
С подключением к индивидуальному узлу на стенде всё просто: соединяем контакт CAN-High адаптера с CAN-High автомобильного узла, CAN-Low — c CAN-Low. По стандарту между CAN-High и CAN-Low должно быть 2 замыкающих резистора по 120 Ом, на практике обычно всё работает на довольно широком интервале сопротивлений, у меня например одно на 110 Ом.
На автомобиле замыкающий резистор не нужен (они там уже стоят, чтобы шина сама по себе работала). В зависимости от модели авто, возможно придется повозиться с физическим доступом к проводке шины. Самый удобный вариант — разъём OBD-II (on-board diagnostic), он обязателен на всех легковых автомобилях, выпущенных в Европе с начиная 2001-2004 года и находится не дальше 60 см от рулевого колеса. На Cee’d разъём слева под рулём, за пластмасовой крышкой блока предохранителей.
Распиновка OBD-II стандартизована и включает шину CAN (CANH на 6 контакте, CANL на 14). Нам повезло, корейцы пошли по пути наименьшего сопротивления и вывели C-CAN, на которой висят все важные узлы, прямо на диагностический разъём:
В результате на Cee’d можно прослушать весь внутренний трафик, ничего в авто не разбирая. Когда машина не твоя, а знакомые пустили повозиться — большой плюс. Но такая халява не везде. У Volkswagen например служебная CAN изолирована от OBD шлюзом, поэтому подключаться пришлось бы примерно так:
Подключив все контакты, поднимаем сетевой интерфейс:
Проверяем, что сеть работает и данные принимаются (включив зажигание):
И наконец, если всё нормально, можно записывать лог:
Здесь нужно запустить двигатель, т.к. усилитель руля включается на собственно усиление только при работающем двигателе, а нам на стенде надо, чтобы он усиливал.
Воспроизведение записи шины на стенде
С записанным логом с авто можно возвращаться на стенд и приступать к обману нашего одинокого усилителя. Первым делом вспомним, что в автомобиле стоит свой собственный усилитель, он тоже шлёт данные в CAN шину, и эти пакеты есть и в нашем логе. Отфильтруем их, чтобы избежать конфликтов. Подключаемся к усилителю на стенде, смотрим, что он выдает:
Видим, что рассылаются пакеты 2B0 (текущий угол поворота руля) и, реже, 5E4 (какой-то общий статус усилителя). Отфильтровываем их из общего лога:
Фильтрованный лог можно подавать на воспроизведение:
Если всё сработало успешно, усилитель заработает, крутить рукой рулевой вал станет гораздо легче. Итак, работать в штатном режиме мы узел заставили, можно переходить к симуляции усилий на руле.
Эмуляция усилия на руле
Крутящий момент на рулевом валу и угол поворота измеряются встроенным блоком датчиков, от которого идет жгут проводов к блоку управления усилителем:
Блок управления обрабатывает сигналы датчиков и выдаёт команды сервоприводу на создание дополнительного усилия на поворот рулевого вала.
Проверка формата сигнала датчиков
По информации PolySync, на Soul, у которого с Cee’d общая платформа, два аналоговых датчика крутящего момента. Cигнал каждого — отклонение уровня постоянного напряжения от базовых 2.5V, провода в жгуте — зеленый и синий. Проверим, что у нас то же самое:
Эмуляция сигнала датчиков
Переходим к эмуляции сигнала датчиков. Для этого поставим свой модуль в разрыв цепи между датиком и ЭБУ, будем транслировать настоящий сигнал с датчика и по команде сдвигать его на фиксированный уровень (изображая приложенное к рулевой колонке усилие). Силами одной arduino это не получится: там нет полноценного цифро-аналогового преобразователя, который мог бы выдавать постоянное напряжение. Аналоговые входы arduino нам тоже не очень подходят — хотя пинов для них целых 6, канал АЦП в контроллере только один, и его переключение между пинами занимает заметное время.
Нужно добавить к arduino внешние ЦАП/АЦП. Мне попались модули YL-40 (описание в pdf) на основе чипа PCF8591 — на каждой по 4 канала 8-бит АЦП и 1 8-бит ЦАП. Модуль может общаться с arduino по протоколу I2C. Потребуется небольшое допиливание (в буквальном смысле): китайские товарищи поставили на плату светодиод индикации напряжения на выходе ЦАП — его обязательно надо отсоединить. Иначе утекающий через диод ток не даст ЦАП поднять напряжение на выходе больше 4.2V (вместо штатных 5V). Диод отсоединяем, отковыривая резистор R4 с обратной стороны платы.
Также на входы распаяны игрушечные нагрузки (терморезистор, фоторезистор, ещё что-то), отсоединяем их, убирая перемычки, чтобы не мешались.
С интерфейсом к arduino есть нюанс — нам нужно 2 канала ЦАП, соотвественно 2 модуля, но у них одинаковые адреса I2C (зашиты в чип). Хотя чип позволяет менять свой I2C адрес, замыкая определенные ноги на +5V вместо земли, на плате эти перемычки не разведены. Вместо перепайки возьмем костыль — две разные библиотеки I2C на arduino (стандартная Wire и SoftI2CMaster), каждая на свою пару пинов. Получаем модули на разных шинах, конфликт пропадает.
Остальное прямолинейно — ставим модули в разрыв цепи от датчиков, соединяем с arduino, загружаем скетч. Подробности по распиновке подключения есть в комментариях в скетче. Остается включить всё в сборе, здесь важна последовательность:
На сегодня всё, на очереди доработка софта (интеграция с CAN шиной, чтение оттуда текущего угла поворота и динамическое управление крутящим усилием, чтобы внешний контроллер мог задать фиксированный угол поворота руля и система его выдерживала), отработка на автомобиле (на стенде не смоделируешь сопротивление от колёс). Возможно замена 8-битных ЦАП/АЦП на 10 или 12 бит (взял первое, что под руку попалось). Рулящая нейросеть тоже в процессе, надеюсь скоро сделать пост.
Спасибо Artemka86 за ценные консультации по работе с CAN и помощь с оборудованием.
Ресурсы для дальнейшего погружения
Бонус. Совмещаем Raspberry Pi и Arduino CAN shield
Прежде всего, внимание, CAN шилд и raspberry pi нельзя соединять напрямую, они не совместимы по напряжению. На Arduino UNO-совместимых платах напряжение логики 5V, а на raspberry pi только 3.3V, поэтому прямое соединение только сожжет задействованные пины.
Нужно завести на CAN шилд питание (5V), соединения интерфейса данных SPI (4 пина: MOSI, MISO, SCLK, CS) и 1 пин сигнала прерывания. Всё, кроме питания, идет через преобразователь уровня, который в свою очередь тоже надо запитать.
На схемах ищем нужные пины.
Соединяем через преобразователь, заводим нужные напряжения питания на каждую сторону преобразователя, получается такая лапша:
Всё, кроме 5V питания и земли на шилд идёт через преобразователь:
Переходим к настройке софта (стандартный Raspbian).
Включаем поддержку SPI и CAN модуля. В /boot/config.txt добавляем
Перезагружаем raspberry pi, проверяем соединение с шилдом:
Запускаем виртуальный сетевой интерфейс:
Вторая команда важна при воспроизведении большого количества данных с raspberry pi, то есть когда записанный на автомобиле полный лог CAN шины воспоизводим для изолированного узла на стенде. Без увеличения буфера он скорее всего переполнится, когда в логе встретится несколько CAN пакетов с маленькими интервалами, и тогда соединение зависнет.