Как мы превратили настоящий автомобиль в контроллер для Mario Kart с помощью перехвата данных CAN

Интервью с лидерами отрасли Инвестиционная стратегия

Современные технологии все активнее интегрируются в повседневную жизнь, меняя привычные форматы взаимодействия как с техникой, так и с развлечениями. В рамках недавнего проекта была реализована необычная идея: превратить настоящий автомобиль в контроллер для игры в Mario Kart-подобную гоночную игру. Основа реализации — перехват и анализ данных с автомобильной шины CAN (Controller Area Network), что позволило использовать сигналы руля, педалей газа и тормоза для управления виртуальным транспортом. Основная задача состояла в том, чтобы создать по-настоящему живой и уникальный опыт для участников демонстрации, объединяющий реальные механические действия и цифровое развлечение. Идея не нова — подобные эксперименты уже проводились исследователями и энтузиастами, например, команда из университета Дармштадта успешно реализовала похожий проект с автомобилем Volkswagen ID.

3. Однако подход и техническая реализация с использованием относительно дешевогo оборудования и открытого программного обеспечения оказались доступны и воспроизводимы для многих. Автомобиль, который использовался для проекта, представлял собой вторичный Renault Clio 2016 года выпуска. Выбор пал именно на этот автомобиль, поскольку он обладал необходимыми современными функциями, такими как интегрированный телематический модуль «eCall», а также отличался удобными габаритами и локальной доступностью для испытаний. Несмотря на некоторые технические ограничения, включая необходимость снятия воздушного фильтра для доступа к блоку управления двигателем, автомобиль оставался полностью функционирующим и маневренным.

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

При этом пришлось учитывать, что официальная терминология и документация нередко приводят к путанице — например, «accelerator» и «throttle» обозначают одно и то же, но разные источники используют разные термины. Анализ существующего открытого программного кода и исследование влияния реальных действий приводили к выявлению идентификаторов сообщений (Arbitration IDs) и конкретных битов данных для каждого элемента управления. CAN протокол предполагает небольшие пакеты длиной восемь октетов и 11-битный идентификатор приоритета сообщения. Сообщения со «меньшим» идентификатором имеют больший приоритет на шине, а полезные данные иногда кодируются не по целым байтам, а по битам в этих байтах. Для руля, тормоза и акселератора значения содержались в различных позициях данных, что требовало тщательной работы и точных замеров для декодирования сигналов.

После того как данные успешно считывались, возникала задача передачи этих сигналов в игру. Модификация исходного кода гоночной игры для прямого приема CAN-сообщений могла бы стать громоздкой, поэтому был выбран альтернативный путь — использование Python-библиотеки pynput. Она позволила симулировать нажатия клавиш клавиатуры, такие как стрелки направления, в ответ на состояние автомобиля, что обеспечивало работу игры без необходимости глубокого погружения в ее код. Одной из интересных проблем стала высокая частота сообщений в сети автомобиля, что приводило к многочисленным повторяющимся нажатиям клавиш, вызывая задержки и сбои в игре. Для решения ситуации была реализована архитектура с использованием потоков в Python.

Один поток отвечал за получение и обработку данных с CAN, обновляя текущее состояние управления в виде простого состояния (dataclass с показателями руля, ускорения и тормоза), а второй — опрашивал это состояние с заданной периодичностью и инициировал соответствующие нажатия клавиш. Разработка критериев распознавания состояния управления потребовала дополнительного внимания. Тормоз определялся проще всего, будучи в основном бинарным состоянием — нажата/не нажата. Ускорение учитывалось через введение порога давления педали, что было достаточно для цифрового управления. Наиболее сложным оказалось определение направления руля.

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

Это добавило интерактивности к демонстрации и углубило понимание технических аспектов проекта. Тем не менее, проект не был лишен технических трудностей. Программа периодически аварийно завершалась из-за гонок потоков из-за отсутствия потокобезопасного доступа к считываемым данным. После изучения документации в python-can удалось исправить ситуацию с использованием потоко-безопасного варианта чтения шины, что стабилизировало работу приложения. Кроме того, без запуска двигателя автомобиль отключал некоторые электронные системы питания через определенное время, что вызывало необходимость постоянного перезапуска системы с помощью ключа зажигания.

Поддержание заряда батареи также представляло проблему в условиях постоянной демонстрации, требуя внешнего зарядного устройства и занимая дополнительное пространство. Проект продемонстрировал, насколько возможно соединение реального механического управления и цифровых игровых систем. Такой эксперимент не только привлек внимание к новым методам взаимодействия с технологиями, но и послужил отличным образовательным материалом для понимания работы автомобильных сетей, принципов протокола CAN и создания адаптивных интерфейсов. В будущем планируется использовать более компактные транспортные средства или даже мотоциклы, чтобы сделать процесс более мобильным и практичным, сохранив при этом весь смысл и увлекательность подхода. Этот опыт открывает новые горизонты для использования реального транспорта в области развлечений, обучения и тестирования умных транспортных систем.

Таким образом проект показывает, что при умении правильно применять современные инструменты работы с данными, можно превратить любое устройство с цифровым контроллером в нестандартный интерфейс для взаимодействия с компьютером и цифровыми приложениями. Перехват интерфейсов CAN предоставляет неисчерпаемые возможности для тестирования, интеграции и развлечений в области автомобильных технологий и игр.