Привет. Мы полностью переписали мобильную версию Хабра. Теперь все работает быстрее и выглядит современнее.

Спасибо за статью!

Афтар, пешы исчо.
А где вы взяли диаграммы, и есть ли там же для Приуса третьего поколения?

Диаграммы? Осциллограммы снял со своего, будут в след. статье. В этой — фрагмент схемы из мана по обслуживанию и ремонту (есть бумажная книга). Но, наверняка, можно скачать и скан. Цветные — рисовал, чтобы показать суть изменений.

Хочу пожелать удачи в реализации!
Скажите, а протокол обмена по CAN у Вас уже есть? Или Вы планируете дампить и вылавливать нужные команды? В любом случае проект очень интересный и буду ждать продолжения.

Спасибо. Очень надеюсь, что хватит сил допилить.
Голова не подключена к CAN. Только AVC-LAN. Это гибрид, созданный злым умыслом компании (если правильно помню) NEC. Это тоже планирую в след. статью, но пока делаю снифер. В нете есть статьи по этой шине, но инфа скудная, хотя для начала помогла. Думаю, будет интересно добавить реальных данных в сеть.

Судя по фото голова послерестайловая, у меня просто был 20 приус и я заморачивался установкой камеры, как выяснилось существует 6 разных голов, 2 дорестайловые и 4 послерестайловые. И все они различаются, та что была у меня не могла получать видео напрямую с камеры, в систему пришлось добавлять штатный блок парковки, вот он то какраз конвертил видео картинку в формат для головы и по этому же каналу передавал сигнал о том что пора вывести изображение. Так что схемы то да есть, но от той ли они головы. А так удачи в проекте, как закончите к вам в очередь встанут владельцы всех гибридных лексусов и не только. А кстати блок парковки нашёлся на автосайтах буквально за 500р.

Да, голова послерестайловая. И видеоинтерфейс — это что-то кошмарное и пропиетарное. Со сменой головы, надеюсь, необходимость в нем отпадет.
Очень хочется помочь себе и братьям-приусоводам.
Я ж хочу не просто картинку. Я хочу снять оковы с рук, вставить открытую систему. А там и нави, и заметки, и плей-маркет.

Там, на сколько я помню с блока автопарковки ещё идут контакты на рулевую рейку с которой он берет информацию о её положении и скорее всего ею же и управляет, а информацию он берет что б нарисовать сверху картинки с камеры линии направления парковки, когда рулём вращаешь эти линии движутся и указывают направление, думаю для этого и нужен огород со своим стандартом, причём те провода должны быть экранированы и картинка там идёт в каком то подобии RGB потому если как во время работы отключить 1 из проводов картинка зеленеет или краснеет как при отключении одного канала цвета в фоторедакторе. соответственно без этого блока автопаркинг работать не будет, + тем кто хочет себе поставить атопаркинг, нужно проверить какая у него рулевая рейка по-тому, что их как минимум 2 вида с разным колличествлм контактов, и та что с меньшим не сможет парковать автомобиль. Не помню где именно встречал реализацию такой системы, ставили какой то пк в систему изображение с которого подавали на блок автопаркигна и соответственно в голову, на экран сверху накладывали ещё один тачскрин и соответсвенно ставили кнопку переключения на вывод изображения с камеры и отключение родного тачскрина. А управление с руля для сторонних пк для Тойоты давно уже реализовано.

Да, и если все это он способен делать сам — то пусть продолжает этим заниматься. Моей задачей будет просто отдать ему информацию, куда пользователь «ткнул пальцем».
А огород с тачскринами видел — тоже мне не понравился. Все-таки хочется чего-то, что пусть будет сложнее в разработке, но при этом избавит от бутербродов и наслоений.
Я убежден, что простота и надежность находятся в прямой зависимости.
Управление с руля реализовано даже в китайских шарманках. В этом сложностей нет — там цепочка резисторов, и АЦП на входе.
Задача — реализовать шататные ф-ции тойоты на китайце.

«Насколько я помню» — значит ли это, что можете помочь схемами подключения блока автопарковки?

Это было 2 года назад, конечно, но думаю посмотрев на разъёмы и схему, подскажу, что куда.

Нет, интересовали, скорее, подписи на контактах разъемов. Я дотянулся до того, чтобы посмотреть на них физически. К несчастью, линия GVIF, похоже, и в самом деле проходит блок автопарковки «насквозь». Т.е. с навигации через парк-ассист, и с него уже на голову.
Пока не знаю, как оставить работать парк-ассист при моей реализации. Возможно, придется искать до-рестайловый.

А, да, блоков парковки тоже 2, до и послерастаил, у меня был до.

А распиновки разъемов гуглятся все, по номеру головы.

Хорошая тема. Занимаюсь почти подобным, только на SUBARU. Только пока никак не созрею на написание статьи.

А что там с шинами? Тоже АВЦ-лан, или CAN-ом обошлись?

Там нет страшных гибридов. Я использовал К-линию и протокол Subaru. Если интересно — вот статья www.drive2.ru/l/499650795206082616. Пока в раздумьях: имеет ли смысл здесь выкладывать что то подобное и будет ли это интересно сообществу.

Созрейте на статью! Думаю, будет интересно не только мне!

Хорошо. Как выпадет свободное время, оформлю и опубликую Спасибо за Ваше мнение.
А AVC-LAN это не просто обычный CAN? На форуме Citroen парни занимаются ковырянием CAN-шины. Из достижений — сделали парктроник, который прикидывается штатным и, соответственно, данные показываются на штатном дисплее.
У себя в машине поставил китайскую ГУ и у неё есть модуль CAN, через который ГУ общается с шиной машины, выводятся сообщения, с кнопок руля управляется и т.д. Неужели для примуса китайцы не сделали такую интеграцию?

Нет. AVC-LAN — это отдельный мутант (см. коммент выше). В приусе три шины (CAN, BEAN, AVC LAN), и маршрутизатор между ними. Костыльно-велосипедный девелопмент. Впрочем, это ж — гибрид.

А как на стороне Андройда будете обрабатывать данные RAW из шины USB? Я делал связку USB-TTL + Android. Писал сервис, который получая сообщение по СОМ-порту выводить сервисное сообщение на экран. Данный способ мне не нравится, т.к. постоянно идёт запрос разрешения доступа к СОМ-порту.

Да, именно поэтому я начал с HID. Забегая вперед: пока разрешение нужно выдавать только при переподключении устройства (или при перезаливке ПО). Пока не понял, где андроид теряет его, но когда apk-шка не трогалась, и устр-во не отключалось — запускается тихо. RAW-HID остается hid-ом.
Идея использования COM порта сегодня мне тоже не нравится — слишком много "но".
Сейчас есть некоторые наработки по сниферу, все это будет в одной из двух след. статей. Пока не знаю, с какой начать: андроид-снифер или физическое поключение к avc-lan. В любом случае, с моим свободным временем, до след. статьи недели три пройдет.

А после перезагрузки тоже не требует разрешения?
Проверю в течение пары дней — напишу, хорошо? Пока просто этим не заморачивался, предполагая, что устройство все равно рутовать.
Хорошо. А Вы не могли бы ткнуть в инфу как на андройде с RAW-HID работать?
gist.github.com/archeg/8333021
Хороший пример, с пояснениями.
То, что там запрос делается при старте — андроид еще дает поставить галочку «всегда использовать программу для этого устройства». И, как я понял, при перезапуске автоматом выдает разрешение на этой строке:
_usbManager.requestPermission(_usbDevice, mPermissionIntent);
Не очень понятно, «многофункциональный экран» — это лишь средство отображения информации? Никакой нагрузки в обработке и управлении системами машины не несет? Все можно свести к отображению результатов, приходящих от других узлов авто и командам управления — типа нажатия кнопок или элементов на экране? Причем всего по одной шине?

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

Точно так. Управление климатом, отбражение состояния системы — именно это Андроид-приложение нужно написать. Здесь все более или менее понятно, осталось доделать снифер и разобрать команды. А голова подключена именно по штатной шине.
Таким образом, я пока не вижу, как еще может передаваться управление климатом (и усилителем, к слову), и полагаю, что все это идет по AVC.
А адаптер двунаправленный, т.е. может не только получать, но и передавать информацию.
В планах, соответственно, сделать некое climat.apk, которое запускается по внешней кнопке, открывает этот девайс, и общается с машиной через описанный в статье переходник.
По кнопке «инфо» на руле, соответственно, запускаем info.apk, и слушаем состояние машины на предмет информации о батарее.
Хотя, не исключаю, что это будет и Android-сервис, обрабатывающий устройство, а в систему отдающий уже некий API. Это все предстоит установить экспериментальным путем.
Сейчас ведется работа над, собственно, снифером, после — реверс шины, и уж тогда будет решение.
Конечно, можно было бы воткнуть BT-CAN (OBD2) переходник, и получать те же параметры, но я сторонник архитектурно-совместимых решений, а голова подключена в приусе _только_ к AVC-LAN. Т.е. вся эта информация передается по ней.
Что касается согласования камеры с линиями положения руля — да, это отдельная (возможно, достаточно масштабная) задача. Потому что я пока не знаю, кто именно рисует эти линии — голова или блок парковки. Если голова — то информация о положении руля тоже должна приходить по AVC. Если блок парковки — будет сложнее. Тогда придется и его функционал частично подменять/повторять.

Линии парковки рисуются с информации от рейки и рисуются в блоке автопарковки, выше уже написал.

Понял. Буду проверять. У меня просто нет схемы подключения блока автопарковки. Что там: тот же GVIF, будь он неладен, или обычный RGB или AV. Вроде, в голове и в нави — один GVIF. Т.е., только если он «пропущен» через парковочник. В противном случае сигнал должен идти по AV/RGB. Это упростит задачу.
Сегодня попробую посмотреть на разъемы.
А зачем нужна китайская Андроид-голова? Можно же взять отдельно экран с драйвером и ягоду. Я бы наверно так делал.
Да, и эти мысли тоже были. Дополнительно нужно будет:
  • распустить звук на 4 канала
  • прикрутить управление с руля (сервис)
  • AV-видеовход для камеры заднего вида
  • Корпус с креплением (желательно — металл)
  • GPS


Думаю, это не весь перечень, но я посчитал достаточным для того, чтобы не заморачиваться.
Впрочем, решенеие с адаптером позволит желающим пойти и этим путем. В моем случае это опасно тем, что проект уж слишком затянется.
Да, с этой точки зрения готовая бошка ускорит разработку. Что же касается всего перечисленного, то кар-писишники все это весьма успешно пилят для андроид-планшетов. Стало быть, задача решаемая.
Большая работа по изучению протокола AVC-LAN уже давно проведена, здесь
Спасибо, да, видел, и еще пара статей в гугле ищутся (1, 2). Ссылки дам, когда буду описывать сам AVC-LAN.
И все-же весьма скудно.
В основном, рассмотрены аудио-функции. А мне еще и климат, состояние батареи и, в перспективе, парк-ассист. Но для понимания, что за зверь AVC-LAN, помогло.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.