Почему я не верю в бум беспилотных машин в ближайшие пять лет
Предисловие
Всё описанное далее, личное мнение, претендующее на единственно верное, но не факт, что являющееся таковым. Все лица, компании, метафоры — выдуманные и к реальности отношения не имеют.
Однажды, беседуя с коллегами по цеху о том, почему я не очень хочу заниматься именно беспилотными автомобилями, я сказал, что я не верю в них. А точнее я не верю в их коммерческий запуск в ближайшие пять лет, на что моя подруга позже дала ремарку, что это одно и то же, да и я не выгляжу как человек, который в это не верит. И я вдохновился это всё довольно чётко (хотя где-то почти везде в моём тексте будет включаться режим пьяного деда) обосновать. Так родилась идея лонгрида о том, почему я считаю, что в течение пяти лет если Full Self Driving и появится, то далеко не в коммерческом масштабе.
Хотя мысли все эти могут казаться непоследовательными, от того, что тесно взаимосвязаны, я постараюсь их изложить в порядке некоторой приоритетности проблем (на мой скромный взгляд, конечно), от наиболее поверхностных проблем, до наиболее фундаментальных.
Если с темой вы не знакомы — вот вещи, которые если погуглить, то можно знать часть информации, о которой можно подискутировать: SAE, DARPA, Tesla, Object detection, GPU for DNN, Lidar, ADAS, Perception, Planning, Control, Localization, YOLO, false positive/false negative, Apollo, Autoware, ROS.
Это даст толчок для общего минимального понимания большинства обсуждаемых вещей (по крайней мере автор подумал именно об этих ключевых словах).
И чтобы не застрять в tl; dr, где я буду описывать сказанные проблемы, вот вам содержание, которое отражает кратко их суть.
Проблемы лидарного подхода
Вопросы к вычислительному оборудованию
Отсутствие общего вектора исследований
Отсутствие объективных требований
Проблема вагонетки для беспилотников
Застой архитектур и смелых решений
Отсутствие хорошей школы
Но чтобы понять, что это не упаднический текст, что имеются реальные причины переживать, говорящие, что что-то не так в этой сфере (возможно не то, что приметил я), достаточно вспомнить, как за 7 лет один небезызвестный инноватор 7 раз говорил, что в следующем году появится беспилотник. И 7 лет никто особо ничего не спрашивал по этому поводу, да и вообще мы уже попривыкли.
Как минимум три устройства на памяти автора от одной зеленой компании, (которая бросает перспективные библиотеки на волне хайпа и уже пять лет не может сделать нормальный деб пакет) достаточны для того, чтобы выпустить SAE5. Ну как достаточны, они позиционировались с лозунгом «ну теперь точно поедет», но почему-то количество видеокарт в каждом пилотном проекте только увеличивается (ну я тут обобщил тенденцию, естественно).
Почему же так происходит? Скорее всего из-за больших разрывов в вертикальных цепочках, от мессий, до потребителей.
Визионер
Маркетолог
Инженер
Тестировщик
Но обо всём по порядку.
Лидарный подход и его проблемы
Добро пожаловать в холивар.
Сразу выскажу своё мнение, чтобы не возвращаться: достаточно только камер.
С точки зрения доказательства полноты данных: человек может управлять транспортным средством, получая только картинку (вспомните любые гонки на ПК или консолях). Человеку даже достаточно для этого 30 кадров в секунду c хорошим обзором и только лишь HD разрешением (вспомните PS3 и её 720p@30fps в GTA IV). Значит проблема сенсора в теории решена. Многие полагают, что так как проблема сенсора решена, то self-driving solution остаётся исключительно программным вопросом (я не помню кто так сказал, либо Маск, либо Джордж Хотц, либо автору приснился сон), но не стоит забывать, что пока ещё неизвестно, какая вычислительная мощность для этого нужна, а обещаниями enough for SAE5 лично я уже наелся.
Поэтому мы приходим к главному плюсу лидара — простота для разработчика алгоритмов и, как следствие, снижение требований к вычислениям. Так, если задача детекции, классификации и локализации препятствия по камере решается обычно минимум в два этапа, то для лидара в один, при этом мы получаем меньший объем данных (если сравнивать полученные от стерео или monocular depth estimation облака точек) с большей надежностью (минимум false positive, а уж тем более false negative) и меньшей погрешностью (зависимость погрешности определения дистанции от реальной дистанции для лидара вообще почти постоянна, когда у камер имеет геометрическую прогрессию). По причине этого плюса — лидарный подход является самым распространенным среди разработчиков беспилотных транспортных средств. Но вместе с тем отрасль двигается в направлении, когда из-за массовости этого подхода будет вынуждена сталкиваться с минусами лидара.
На мой взгляд их два. Первый уже хорошо известный — лидары все ещё дорогие. Большинство из них всё ещё не solid state, они хуже переносят неблагоприятный климат, чувствительны к вибрациям, а также у них гораздо меньший срок службы, чем у камер. А значит, помимо установки лидара, необходимо производить их гарантийное обслуживание, ремонт, замены и т. п., что также создаёт дополнительную нагрузку для промышленности и финансовую нагрузку для конечного потребителя.
Второй немаловажный фактор (а на взгляд автора ключевой), который ещё не нашёл широкой огласки: лидар — это активный сенсор. То есть лидар вынужден «вмешиваться» в окружающую среду путём использования лазерного компонента, отражения луча которого он и считывает. Это несёт в себе два важных недостатка (фракталы в студмю). Во-первых, во время массового (читай коммерческого) запуска беспилотников на дорогах может оказаться сразу очень много лидаров.
на секунду представьте, что хотя бы 20% траффика — беспилоты
А значит эти лидары могут оказывать помехи друг для друга. Хорошо известны в этом ключе радары в ADAS системах, я неоднократно слышал о проблемах, когда при встречном движении на разных полосах FCW (forward collision warning) системы ловили ложные срабатывания друг от друга на очень большой и фактически безопасной дистанции. К сожалению, то же самое я слышал о лидарах, когда один датчик создавал «ложные» точки для другого. А поскольку для разработчика алгоритма идеально наиболее плотное облако точек, то и шумы при таких раскладах могут напоминать ложные плотные объекты, по типу столбиков. При этом я также слышал от разработчиков несколько вариантов решения данной проблемы, но если мы говорим о массовых беспилотниках от разных компаний на общих дорогах, то и подход для устранения этой проблемы должен быть единым, однако пока ни в одном стандарте, да и на публичной сцене вообще, я не видел обсуждения данной проблемы. Заходя чуть дальше, многие лидары также работают в диапазоне, к которому чувствительны камеры с ближним инфракрасным спектром, коих много среди камер видеонаблюдения и среди камер, используемых в том числе и в автономном вождении. Как следствие в темное время суток паттерн лидара способен отображаться на камере, что в свою очередь может повлиять на качество работы нейронных сетей видимого диапазона, а датасета с подобными шумами или учтенной аугментации данных для такого рода помех я также не видел. Для примера — кадр лидара от яблочного устройства, но поверьте, впервые подобную проблему я обнаружил именно на данных беспилотника.
В ик спектре хорошо виден сканирующий паттерн лидара
Тотали: тут у нас два пути, либо решить проблемы лидарного подхода, что во многом зависит от промышленности и «железных инженеров», либо уйти в подход камера онли. Оба варианта развиваются сейчас параллельно, оба варианта ещё далеки от печати «высокая степень надёжности». Поскольку проблема активного сенсора ещё не всплыла (а по моему скромному мнению, она всё же встанет поперёк горла), а с учетом мировой бюрократии как только её обозначат, свод правил займёт не меньше года, я считаю, что как минимум в течение двух лет лидарный подход ещё не будет доступен для масштабной коммерческой эксплуатации.
Вопрос вычислительного оборудования
Его я уже немного поднял в предыдущем. Если разбить проблему на вопросы, то получится примерно следующий список:
Какое железо производить?
Сколько железа производить?
За сколько производить железо?
Кто железо будет производить?
Когда железо произведут в достаточных масштабах?
Не первый год я вижу специализированные для беспилотного автомобиля вычислители. Не первый год я не вижу беспилотного автомобиля. Ведь продать несколько итераций устройства, не соответствующего заявленным тезисам — это означает получить долговременную прибыль для своей компании.
Нам всё ещё непонятно, какой вычислительной мощности хватит для обеспечения вычислений беспилотного транспорта. На секундочку: количество используемых десктопных компьютеров в два раза меньше количества используемых автомобилей (по той аналитике, что дал мне гугл). А среднестатистический десктопный компьютер — это далеко не то устройство, которого в текущем (среднем по палате) понимании среди компаний и разработчиков хватит для беспилотника. Поэтому бум беспилотников — это ещё и бум производимых для него компонентов, сенсоров, процессоров, видеокарт.
На дворе 2022, мы недавно вышли из кризиса полупроводниокв, связанного с ковидом, на горизонте недавно подугасли новости, которые говорят о потенциальном кризисе, связанный с Тайванем, большинство фреймворков глубокого машинного обучения заточены на работу с проприетарной технологией одной зелёной компании.
Даже если мы говорим о 10% автомобилей, с текущими подходами, даже если мы начнем их штамповать immediately asap, я не верю, что процесс уложится в 5 лет (отрасль аппаратного обеспечения не беспилотниками едина). И тем более я не верю, что при текущих условиях возможно найти баланс между резким бумом производства, монополизацией отдельных компонентов, и доступной ценой. А без этого я не верю и в успешную масштабную коммерциализацию.
В идеале было бы здорово, чтобы беспилотник можно было запускать на очень скромных вычислительных мощностях, переоборудовать уже имеющиеся устройства, но тут возникает вопрос.
У нас до сих пор нет понимания минимума
Во всём.
Начну издалека, я уже 5 лет как занимаюсь беспилотным транспортом в разных сферах, и всё ещё слышу фразы по типу: «для работы системы необходимо обеспечить частоту не менее 10Гц», иногда 10Гц меняется на 30Гц, наверное потому что это тоже очень красивое число. На вопрос, почему 10Гц и что произойдёт при частоте 9.99Гц, как правило я либо получаю ответ «ничего», либо не получаю ничего, только пожимания плечами:). 9.98Гц, 9.97Гц, 9Гц, 8.99Гц. После этого, вспомнив как решать задачки методом математической индукции, можно понять, что частота в 0Гц вполне себе приемлемая для беспилотного транспорта. Критический кейс до сих пор не определён.
Очень хорошим контрпримером для обязательных от специалистов (таких же как и я) фраз »10Гц»,»30Гц»,»99.9%»,»4К камеры»,»8К камеры», «лидар, радар и камеры» я считаю марсоходы.
Эту пташку зовут Кьюриосити
Процессоры там всё ещё в мегагерцах, разрешение камер меньше FHD, время обработки данных стереопары занимают порой минуты, то есть частота меньше 0.017Гц. И он работает, вполне себе в беспилотном режиме. Потому что А — у него имеется возможность снижения скорости до 0 км/ч на подумать. Б — у него нет марсиан на пути (или цели не сбивать марсиан).
Требования к временным характеристикам должны складываться исходя из того, с какой скоростью едет твоё транспортное средство, с какой скоростью передвигаются динамические объекты по карте, какую дистанцию покрывает твой набор сенсоров и так далее. Но на сегодняшний день, я редко встречал попытки ответить на эти вопросы. Даже исследования по скорости передвижения человека, в основном, можно найти в учебниках институтов физической культуры за 80-ые года, такие важные для определения граничных значений величины до сих пор не исследуются статистами. Либо это всё не обсуждается и не выкладывается в открытый доступ, что вполне реалистично. В общем: вопрос требований к беспилотному транспорту все ещё открыт.
По пунктам — на сегодняшний день я не видел в общем доступе ни одной современной адекватной литературы, популярного выступления, признания проблемы или просто полноценной и качественной лекции по следующим вопросам:
Какая максимально допустимая скорость беспилотного автомобиля?
Какое время реакции должно быть у системы?
Какое время реакции у человека? (тут видел, но они уж очень старые)
Как изменяется реакция человека в зависимости от погодных условий?
Как меняется тормозной путь в зависимости от погодных условий и как отклонения определить заранее?
Какая минимальная частота для сенсоров необходима?
Какие могут быть допуски погрешности определения дистанции?
Какая минимально-допустимая вероятность определения препятствия?
Какая допустимая вероятность отказа компонентов? (применение SIL в этом вопросе всё же вызывает у меня споры)
Какие метрики нейронных сетей достатчны и необходимы? (прим.: нужно ли стремиться к mAP @0.95 > 0.5 или вполне достаточно mAP@0.5 > 0.4)
Сколько флопсов необходимо для работы системы распознавания?
Какое количество ложно-позитивных препятствий допустимо?
А самое главное — какие тесты должен проходить беспилотный автомобиль, чтобы покрыть 100% возможных кейсов в реальных условиях. Справедливости ради, инициативы вроде EuroNCAP существуют, но это совсем не про SAE5. И пожалуйста, кто-нибудь, добавьте в тесты ребёнка в маске коня и пешехода, перепрыгивающего зебру в мешке (соревнования по прыжкам в мешке всё ещё реальный кейс). Мне очень интересно, как справятся с этим испытаниям беспилотные автомобили.
Кстати, внимательные читатели заметят, что формулы для расчета времени остановки есть, но мало из них учитывают (а ещё и говорят, как рассчитать) такие параметры как давление шин, коэффициент трения покрытия, коэффициент трения шин, температуру шин, ширину шин, влажность, текущий угол поворота колёс, влияние ABS и многое другое. А мы ведь хотим, чтобы тяжелые грузовики максимально быстро и бесперебойно доставляли грузы из точки А в точку Б, а значит беспилотный автомобиль в каждый момент времени должен очень точно знать, как долго он будет тормозить до полной остановки и какую дистанцию перед впереди идущим автомобилем держать.
Кстати, если вы натыкались на кучу формул в интернете по расчёту торможения и думаете, что вопрос хорошо изучен, довольно прост, и чуть ли не решается линейным уравнением — посмотрите на график и параметры Магической формулы Пасейки, которая построена на полуэмпирических методах и применяется для симуляции разгона и торможения гоночных транспортных средств (то есть вполне себе неплохая аппроксимация реального торможения, а есть ещё много других). Вопрос действительно хорошо изучен в теории, но эта теория не слишком уж часто применяется в беспилотных автомобилях.
Почему графики именно такие? Ответить тяжело.
Для ответов на каждый из перечисленных выше вопросов необходимо как минимум одно из следующих условий:
статистика
замороженная архитектура (когда меняться будут только конфигурация системы, а не само ПО)
точные требования к физическим параметрам
Если статистика собирается со временем, точные требования к физическим параметром обуславливаются грамотным переводом ТЗ на язык инженеров, то с замороженной архитектурой больше всего проблем. Дело в том, что одну и ту же проблему можно решить множеством способов.
Так стабильность определения препятствия можно улучшить за счет улучшения методов детекции препятствия, либо за счет улучшения алгоритма трекинга препятствий. При том повышение качества любого из компонентов ведёт к повышению вычислительных затрат. И либо необходимо производить апгрейд железа, либо производить оптимизацию вычислений в другом компоненте системы. В итоге получается знаменитый whack-a-mole.
Так выглядит подготовка к новому релизу со стороны системных архитекторов беспилотников
В пример также приведу свою таблицу, где от требования к времени реакции необходимо было рассчитать параметры системы:
Очень схематичное очень приближение для расчетов очень предварительных характеристик
OA — время, необходимое системе на выполнение всех вычислений от момента фактического возникновения ситуации до начала оказания управляющего воздействия
OB — запас дистанции до объекта, деленное на максимальную скорость изменения координаты препятствия (коридор безопасности)
OC — период работы системы (обратная частоте величина)
OA + OB + OC <= T_breaking (distance * (1 + rel.error))
величины частоты кадров, запаса дистанции и времени работы системы на дистанции distance могут варьироваться при выполнении условия непревышения в сумме времени T_breaking, необходимого на остановку транспортного средства на максимальной скорости на дистанции distance с учетом возможной ошибки определения дистанции rel.error.
Авторское допущение: с точки зрения геометрии прямоугольник должен быть равносторонним, тогда точку можно перемещать внутри.
Авторскре допущение 2: мы не рассматриваем тут возможность маневрирования во время торможения.
Как видите, вопрос определения граничных значений не самый простой. И до его общедоступного решения я бы дал срок не меньше года.
Отсутствие общего вектора исследований
Пункт будет сумбурным, собственно, как и все остальные.
Если мы посмотрим на последние достижения компьютерного зрения, машинного обучения, алгоритмов беспилотного транспорта, то заметим, что все они идут в разнобой. И очень редко мы встречаем решения, специализированные для беспилотного автомобиля.
Современные детекторы сконцентрированы на общем решении задачи детекции, затем уже берутся датасеты от беспилотных автомобилей, сеть дообучается и используется в продакшне. То же самое с сегментацией, трекингом и другими задачами компьютерного зрения. Хайп прошел, задача решается в общем ключе, а затем применяется для отрасли. Но, как говорится в фундаментальных учебниках, специализированные решения всегда лучше универсальных, а их сейчас практически нет. И речь здесь даже не о том, что метрики качества оцениваются в первую очередь на общих датасетах вроде COCO, а в том, что сами метрики заточены под исследовательские цели. Большинство статей направлены на повышение точности (что несомненно важно), но мало из них обращают внимание на такие параметры, как размер, соотношение точности к производительности, простоту деплоя (безусловно, такие статьи есть, но на личный взгляд автора тренда в сферу real-time решений практически не наблюдается, кроме отдельных, пусть и особо хороший сетей). Даже если обратить внимание на переход YOLOv7 с YOLOv5 — заметно, что вопрос высокой скорости работы (а я очень радовался выходу yolov5n) отходит на второй план, что не очень хорошо говорит о развитии области роботизации в целом.
Иногда можно увидеть абсолютно абсурдные вещи, когда ради повышения качества на 1% время работы и занимаемую память увеличивают едва ли не в два раза. Пропасть между исследователями (которые занимаются теоретической частью) и инженерами (которые эти исследования затем применяют) до сих пор кажется огромной.
Но это всё Perception. Дальше хуже
Sensor fusion. Prediction. Planning.
Для несведущих: первое — объединить информацию от разных сенсоров воедино, второе — предсказать по имеющимся данным, что будет в ближайшем будущем, третье — по имеющимся данным спланировать маршрут и последовательность управляющих воздействий на автомобиль.
По неизвестной мне причине, хайп хорошо пришелся только на системы распознавания. Большинство статей посвящены именно Perception ответвлению. Там мы получили очень планомерное развитие: классика, Feature extraction and classification, Haar Cascades, Convolution Neural Networks, MobileNet, YOLO, Трансформеры и дальше по списку. А это только детекция объектов. Каждая подзадача модуля восприятия очень хорошо и в соответствии с временем развивалась. Но не указанные выше три темы.
Безусловно: появлялись статьи по sensor fusion, где в нейронку с трансформером запихивается куча данных, а на выходе ожидается полезная информация (но метафору с решением квадратного уравнения я приведу попозже), появлялись LSTM сети для предсказания последовательностей в будущее, но хорошего варианта я так и не увидел (хотя вроде бы у Теслы неплохо вышло), говоря про Planning, по правде, моих компетенций може не хватать, но смущает две вещи.
Во-первых, это очень важные темы для беспилотного автомобиля и они получают незаслуженно мало внимания. Во-вторых, между построением траектории маршрута полиномом второй степени и использованием end-to-end сетей с трансформерами внутри для определения необходимого в данный момент угла поворота руля, располагается огромная пропасть из математических достижений и развития программирования в целом, которую сообщество разработчиков беспилотников как-будто проигнорировало. У нас за это время появились такие вещи, как мягкие вычисления, байесовское программирование, теория катастроф, огромный пласт практического использования теории чисел в IT, но всё это обошло такие важные темы. Складывается ощущение, что в определенный момент всю славу забрал Perception и даже такие вещи, как нейронные сети, которые в сущности своей являются ничем иным, как аппроксимацией неизвестной функции, обошли эту часть науки стороной, потому что ею заниматься стало не модно. А ведь есть даже статьи, где нейронная сеть подбирает в реальном времени физические параметры камеры для улучшения качества системы распознавания. Есть изучение взаимосвязи Sensor <=> Perception, но так мало работ в отношении других взаимосвязей архитектуры беспилотного автомобиля.
Как итог: мы смотрим на визуализацию систем беспилотного вождения у компаний, которые заявляют о готовности к SAE5, вот мы едва двигаемся на дороге, а наша траектория движения болтается как воздушный манекен возле заправки из-за того, что в 40 метрах от нас стоит машина, которая мерцает и переопределяется с погрешностью в 20 сантиметров. Стал бы человек 26 раз в секунду перестраивать свой маршрут в голове, стоя на красном светофоре у перекрёстка? Скорее всего нет.
Хьюстон, вдалеке препятствие, съезжаем вправо
Хьюстон, отбой, продолжаем движение
Хьюстон, отставить поворот, только вперёд
Три соседних кадра. Справедливости ради — это еще они неплохо пофиксили smoothness, и я прямо искал этот баг, пару месяцев назад ситуация в их роликах была гораздо плачевнее.
На мой взгляд проблема того, что компоненты развиваются отдельно в рамках одной задачи, а некоммерческие исследования взаимодействия компонентов практически не проводятся, переходит в то, что мы очень старательно обходим стороной эффективные решения, которые могли бы быть предложены сфере.
Но при всей важности проблемы, когда останется только она, решат её не больше чем за год, когда клюнет в нужное место.
Проблема вагонетки для беспилотника?
Слыхали о проблеме вагонетки?
Мол едет беспилотник, а перед ним появляется (данные меняются в зависимости от рассказчика) бетонная плита, которую он почему-то не заметил. И вот он либо сбивает её, вредя пассажирам, либо сворачивает на соседнюю полосу, где вредит разной степени оценки для общества людям.
Не создавай себе проблему — не придётся её решать
Хотите открою секрет? Её нет. Проблемы вагонетки для беспилотников не существует, беспилотник (сделанный адекватными людьми, мои беспилотные гоночки во flatout не в счёт) не может в принципе попасть в ситуацию вагонетки, потому что он обязан снижать скорость до той, на которой у него хватает достоверной информации, чтобы при внезапном возникновении препятствия затормозить перед ним.
Проблемы тут на самом деле в другом: достаточно ли успешно провели тесты и испытания, чтобы быть уверенным, что там, где система считает, что она способна распознавать препятствие — препятствие будет распознано, и зададут ли инженеры/эксплуататоры/дистрибьюторы или любые другие материально ответственные люди это условие.
Ведь многие действительно не понимают, что безопасность движения, о которой говорят визионеры, она напрямую влияет на скорость. Даже в жизни, водители часто жертвуют потенциальной безопасностью ради «эффективности». Написать смс параллельно с вождением, превысить скорость, зачастую ограничиваемую не просто так, совершить обгон в неположенном месте из-за того, что фура перед тобой похожа на черепаху. Беспилотник так делать не должен. Беспилотник так делать не будет, если не научить его плохому. Когда человек видит справа по полосе автобус, припаркованный у обочины, он должен понимать, что из-за автобуса всегд может выбежать ребёнок. А значит он должен снижать скорость до той, при которой он сможет в последний момент затормозить, если этот самый ребенок выскочит. Человек иногда может это проигнорировать. Беспилотник это игнорировать не будет. Подобных примеров еще полно. И тут встает следующий камень преткновения: мы можем сделать безопасный беспилотник, который будет во многом похож на неуверенного водителя, но при этом действовать максимально объективно с точки зрения безопасности. Либо может задать условия, при которых возникновение аварийной ситуации будет иметь большую вероятность, но тем самым мы увеличим среднюю скорость транспортного средства. Мы можем ехать чуть быстрее, чем время полной остановки до границы работы системы распознавания, уменьшая тем самым, к примеру, время доставки груза. Мы можем сказать, что вероятность 1 к 1000 случаев этого самого ребёнка за автобусом достаточно мала, чтобы её игнорировать, не замедляя городской траффик. Но мы не можем представить себе ситуацию, где человек, принимая тот факт, что он будет виновен в случае инцидента, пожертвует своей потенциальной свободой и спокойными снами, ради той самой пресловутой эффективности и отбросит это условие. По крайней мере я не могу.
И это плавно перетекает в следующую проблему: кто виноват в аварии беспилотников? Кто окажется виноват по закону — тот и будет меньше всех хотеть использовать беспилотник. Разработчик? Удачи вам набрать штат сотрудников. Покупатель? Удачи вам найти себе потребителя. Никто? Удачи вам с пешеходами, активистами и принятием новых технологий в обществе. До тех пор, пока вероятность отказа беспилотника будет выше, чем вероятность срыва лифта в шахту — тяжело будет внедрить их в наше общество. После — да, у нас появится этап сертификации, на котором должны заранее быть проверены функции. У нас появится этап эксплуатации и гарантийного обслуживания, где периодически будет проверять, всё ли впорядке с беспилотником. Всё как у лифта (который, кстати, когда-то тоже не был беспилотным). Но для этого нужно заранее собрать огромную статистику, согласованную статистику, и не по отдельным транспортным компаниям, с двумя машинами на дороге, а именно с огромным автопарком, который наравне с обычными автомобилями будут заполнять городской траффик, а за рулем будет тот самый ключевой элемент безопасности — человек.
Иными словами, не будет мира с SAE5 повсюду до тех пор, пока не пройдёт этап с автомобилями SAE4 повсюду.
И вот на эту проблему я бы откровенно дал не меньше, чем 5 лет. Хотя с некоторой долей вероятности все дружно на это забьют и отправят в продакшн за месяц.
Архитектурные проблемы
Как менялись концептуально архитектуры беспилотного транспортного средства: никак.
С Darpa Challenge 2008-го года концепт остался примерно тем же.
Классическая абстракция архитектуры беспилотника выглядит так
Появились подмодули, появились методы, но суть осталась той же. Был ещё (и есть) end-to-end learning подход, но на мой взгляд это из серии я обучил нейронную сеть на 100500GFlops, чтобы решать квадратное уравнение, потому что я не знаю, как решать квадратное уравнение. Только в случае с беспилотным вождением — оно ещё и не работает.
Кстати, поделюсь мыслями из будущего поста, на мой взгляд всё должно выглядеть как минимум так:
Несколько иной подход к взаимодействию компонентов, что я немного задевал выше
Но об этом в следующем посте.
Этот пункт будет крайне коротким и таким же холиварным, как пункт о лидарах, а значительная часть из него перейдёт в следующий. У нас есть концептуальная архитектура того, как должен работать беспилотник. Но у нас нет работающего беспилотника. Но все (подавляющее большинство) верят в не подкрепленную промышленным использованием архитектуру с недоказанной эффективностью, и любой стартап в сфере беспилотников как правило берёт за основу её. Команд, которые бы предлагали свежие и смелые идеи становится всё меньше, а это как по мне напрямую отражает скорость прогресса.
Примерно по этой же причине я скептически отношусь к Apollo и Autoware, пока кто-то не сделал качественный беспилотник на одной из данных систем — вы не получаете гарантий, что это вообще рабочий вариант. Если (или как только) кто-то сделает беспилотник на одной из этих систем — все ваши старания окажутся бессмысленными, потому что появится лекало, по которому можно за один процент от вашего капитала и толику времени, от уже потраченного вами, сделать гораздо более качественный результат. (важно отметить, я говорю именно о полноценном беспилотнике, использования этих систем для более простых частных задач может быть вполне оправдано, но всё же я рекомендовал бы разработчикам не искать унификацию там, где её пока нет).
Из оптимистичных плюсов этого параграфа — как только у кого-то получится беспилот, все остальные сразу же сделают точно также. Из минусов — у нас сейчас нет понимания, а сработает ли это сегодня, завтра. Действительно ли с текущими сенсорами, вычислителями, алгоритмами, архитектурами и людьми можно сделать полноценно работающую систему беспилотного автомобиля, либо вся работа сейчас это до сих пор работа на перспективу, исследования и повышение компетенций. И в ближайший год в крупные изменения в этой сфере я не верю.
Все еще плохая школа
И, как я обещал ранее, плавный переход.
Вряд ли вы послушаете совета по плаванию от человека, который в жизни только пару раз заходил в море, да и то лишь по колено. Но вы послушаете курс о беспилотных автомобилях от людей, которые не сделали беспилотные автомобили. Вы послушаете заявление человека со сцены о том, какой сенсор бесполезен, а какой нет, для беспилотника, при том, что человек приведёт всё ещё неподкреплённые практикой псевдо-доказательства и станцует для вас пару танцев.
Описывая проблему более кратким тезисом: у нас нет нормальной школы, чтобы готовить разработчиков беспилотного транспорта. А те люди, что их готовят, имеют неоправданно завышенный авторитет.
Не поймите меня не правильно. Я настоящий хейтер системы образования в целом (не только в России, я о мировой. Открытые курсы топовых университетов, которые я видел, по теме беспилотного транспорта, вызывали у меня и смех и слёзы, а то, что проходил на Coursera и подобных сайтах, разбивало мои ожидания о светлом образовании в западных университетах).
Но при этом я высоко оцениваю значимость образования (в основном самообразования). Есть очень много хороших школ по фундаментальным наукам. Есть много людей, которые научат вас думать шире. Есть люди, которые в сфере
