Любой технически сложный hardware-проект — всегда уравнение с множеством неизвестных: платформа, компоненты, технологии, производство, функциональность, реализуемость. «Пощупать», что получается, можно, когда пройдены дорогостоящие этапы: R&D, выбор комплектующих, разработка программ и поиск фабрики для производства.
Сегодня хочется сосредоточиться на том, что мы узнали при создании прототипа этого устройства, как при помощи прототипов быстро проверять гипотезы и какие платформы и компоненты лучше для этого использовать. Я уже подробно рассказывал на Хабре, как мы делали камеру для определения усталости водителя.
Я бы хотел частично поделиться нашим опытом, рассказать, что и как мы делали. — Когда мы шли к разработке этого продукта, нам пришлось сделать много прототипов. Многие из вас, скорее всего, проходили эти этапы и тоже имеют свои наработки. Возможно, кому-то многое из рассказа покажется банальным. Я не претендую на последнюю инстанцию истины, но это будет интересно.
Это абстрактный проект, он не привязан к каким-то конкретным обстоятельствам, я привожу его просто для примера. Давайте посмотрим, как же делаются устройства, прежде чем дойти до прототипов, потому что это многое определяет.
Обычно это для вас делает сторонняя компания, а может быть, вы сами. Сначала вы подготавливаете вводные данные и подходите к R&D. На данном этапе делают плату, подбирают электронные компоненты, и устройство обретает материальное воплощение. Но в любом случае, это достаточно длительный процесс, минимальный срок — три-восемь недель.
Его цель — дать вам понять, похоже это на то, что вы хотите получить, или нет, нужно ли что-то менять. Далее производится EVT-образец, тестовое устройство, которое уже расположено на нужной вам плате примерно таких габаритов, примерно из таких комплектующих. У вас появляется возможность это протестировать.
Это design verification test, когда все найденные в EVT недостатки или большинство из них устраняются. Затем производятся DVT-образцы. После этого устройство помещается в финальный корпус, в финальный дизайн, чтобы вы понимали, как оно ощущается в руках, как вы его будете дальше использовать.
Это может быть сто или тысяча штук, в зависимости от того, как у вас все идет. Следующий этап — вы выпускаете пробную партию PVT. И потом начинается mass production.
Это довольно долго, и всегда возникают риски. Главный вывод из всей этой истории в том, что пока вы получите первый прототип, я имею в виду EVT, пройдет минимум два-три месяца. Может быть, вы неудачно подберете компоненты, и вам придется возвращаться в изначальную стадию R&D. Может быть, не все функции будут реализованы. Может быть, вокруг жарко, холодно, вибрация, грязь, пыль, вода. Может быть, вы не учли какие-то условия работы этого устройства. Все что угодно.
Вы хотели сделать устройство, которое помещается в некий ценовой диапазон, но не вышло, оно оказалось дороже. Еще вы могли переоценить свои возможности. Так бывает. А еще может случиться банальное — пока вы полгода разрабатывали устройство, требования поменялись, и вам нужно идти и делать заново.
Все идет по кругу, короткими итерациями. С учетом предыдущей схемы это приводит нас к тому, что сейчас в разработке софта люди обычно используют какой-нибудь agile-подход. В hardware-разработке это не подходит. На каждом этапе есть работающий прототип, и все нормально, итеративно. Именно поэтому вы не можете сделать какой-то minimum available-продукт, а когда-нибудь потом его доработать. Если вы меняете требования, то возвращаетесь не первый этап, у вас опять семь-восемь недель, и вы производите новый EVT. Вы, может быть, сможете что-то улучшить программно, но если вы сделали плохо, значит, ваш продукт получится плохим. Нельзя сделать плохо.
Вы просто сидите и ждете результата. Каждая такая ситуация — потеря времени, потому что на заказанные вами новые исследования, доработки и производство нового EVT-образца тратится время.
Поэтому давайте к этой схеме, где я рассказал о производстве устройства, добавим то, как это мэпится к разработке софта.
Есть development-версия. Как обычно происходит эта разработка? В идеальном мире все происходит, как на этой схеме. В рамках R&D вы выпускаете альфа-версию, к первому EVT-образцу у вас должна быть готова бета, затем появляется вторая бета и вы итеративно готовитесь к релизу.
А бета-первая может вообще не запуститься на том, что вам произвели. На самом деле реальность такова, что альфа-версию вам не на чем тестировать, поэтому вы сильно рискуете. Сроки и планы срываются, и ничего хорошего не получится. В этот момент вы потеряли время.
Можно на ранних этапах сделать прототип. Однако есть маленький чит, вы все о нем знаете. Он вообще может быть другим, сделанным из чего-то другого. Он не обязан быть полностью соответствующим финальному устройству, не обязан обладать его габаритами. Но он поможет вам понять, что именно вы делаете, как вы это делаете и с чем вы столкнетесь.
Сможете проверить свою идею в реальных условиях, потому что пока она у вас в голове, вам кажется, что она работает. Вы сможете быстрее определиться с тем, какое железо вам нужно. В реальном мире другие потребности.
Устройство может казаться вам хорошим, но когда вы его поместите в реальные условия — на стекло автомобиля или на руль велосипеда — оно не будет работать так, как вам надо. То же самое касается дизайна. Так что проверка дизайна — тоже очень важный аспект.
Хорошо, если они еще где-то в это время эксплуатируются. Еще вы можете быстро писать ПО, потому что каждое ваше действие вы проверяете на живом образце или на серии образцов.
Они прибегают и говорят вам: «А мы еще вот так хотим и вот так». Кроме того, мы все знаем, что миром рулят маркетологи и продуктологи. Когда у вас что-то есть, вы можете их применить, можете попробовать и рассказать им: вот эти ваши сценарии будут работать, а эти — нет. Эти требования сложно уточнить, когда у вас ничего нет в руках.
Если вам нужно привлекать инвестора, то приходить к нему с бумажками, проектами, чертежами и рассказами — классно и нужно. Когда вы делаете устройство, чаще всего вы делаете его для каких-то бизнес-задач. Но когда вы приходите и говорите: «Смотрите, мы придумали вот это, а вот это — работающий прототип», то инвестор сразу больше заинтересован.
Если вы, как и мы, делаете устройство с камерой, вам может не прийти в голову, что питание в машине не такое хорошее, как, например, у вас в домашней розетке. У вас есть множество рисков, о которых вы можете не подумать. Таких рисков может быть миллион, и они всплывут только тогда, когда вы возьмете устройство и поместите его в реальную среду.
Одно дело, когда вы ставите камеру перед собой и записываете себя. Также это вам позволит собрать реальные данные. Все это нам позволяет предъявить новые технические требования и ограничения к hardware, минимизирует риски. Другое — когда камера стоит перед мотоциклистом, водителем автомобиля, механиком.
Я их хотел бы сгруппировать в три части. Теперь давайте посмотрим, какие могут быть случаи с рисками. У вас нет понимания, какое нужно железо, у вас нет понимания, как писать софт. Либо вы не уверены вообще ни в чем. Либо вы уверены в железе и не уверены в ПО, тогда все силы тратятся на ПО, а железо вы отдаете стороннему подрядчику, пусть он его делает в штатном режиме. В этом случае все грустно, и, на мой взгляд, лучше всего сделать какой-то proof of concept, а потом скатиться к одной из методик слева. Вы на этом прототипе будете примерять ваше ПО. Либо вы полностью уверены в программном обеспечении, но в железе не уверены, тогда вам срочно нужен прототип. Возможно, его придется адаптировать, но у вас тоже все получится.
Здесь мое мнение, может быть, оно не совпадет с вашим мнением, — всегда надо выбирать платформу, которая может больше, чем вы хотите. И тут мы приходим к тому, из чего прототипы делать. Если вам нужна ограниченная производительность, — берите что-то, что дает большую. Если вам нужно малое расширение, берите про запас больше. Если вам нужно что-нибудь, работающее исключительно в вашем скопе задач, возьмите что-нибудь еще более расширенное, с каким-то максимальным инструментарием, это вам всегда поможет. Если вам нужно чуть-чуть памяти, — берите в два раза больше. Потому что, когда вы будете делать это прототипирование, придут те же самые продуктологи, маркетологи, и скажут: «А вот, смотрите, здесь бы еще вот так сделать, и вот это подключить». Почему? И что получится?
Из чего можно это делать? Давайте чуть-чуть ближе к реальности. Давайте делать на Arduino, все любят Arduino. Напрашивается очевидная платформа — Arduino. На Arduino можно делать, на мой взгляд, очень простые штуки. На самом деле да и нет. Вам нужно сделать манипулятор? То есть Arduino скорее подходит для каких-то узлов. Вам нужно сделать термометр? Отлично, берите Arduino и делайте. Другое дело, если вам нужно сделать что-то сложное, требующее вычислительной мощности, computer vision, machine learning. Отлично, их миллион.
Вы можете сделать колесо, радиоуправляемую машинку, и Arduino для этого подойдет. Arduino — это узел. Но если в эту вашу машинку понадобится установить камеру — уже как-то не очень.
Все его любят. Тут напрашивается другой вариант — Raspberry PI. И, на самом деле, может быть и да, может быть и нет. Маленький, хороший, популярный, продается сотнями миллионов штук в мире. У него довольно стандартный уже сорокапиновый разъем. С одной стороны, он недорого стоит, он производительный, у него много модулей, которые на него можно прицепить. Но есть проблемы.
И если вы посмотрите на картинку, процессор окружен кучей периферии, и очень сложно придумать к нему такой радиатор, который крутил бы его нормально, потому что вы будете упираться в HDMI порт, USB, в сорокапиновое расширение, и у вас площадь радиатора будет, может быть, четыре на четыре сантиметра максимум. Во-первых, он греется, особенно последняя модель, четвертая.
Есть какие-то вариации на тему, но некоторые проекты, они нуждаются в Android. А еще там нет Android, там только Linux. И здесь как-то Raspberry PI вам не очень помощник. Например, вы делаете какое-то устройство, которое вы изначально нацелили на платформу Android.
Вы используете SD-карту, соответственно, минус, все автомобильные и прочие варианты использования. И следующая проблема, на мой взгляд, это операционные системы на сменном носителе. Если у вас мороз, еще что-то, будет конденсат, в общем, будут проблемы. У вас машина трясется, SD-карта ненадежна, она может вывалиться, она будет вибрировать.
Есть бананопай. На самом деле, есть очень много всяких штук, я их вам могу показать, мы их разные перепробовали. Он нормальный, он работает, он совместим с ним по разъемам. Он примерно то же самое, что Raspberry Pi. Есть решение чуть-чуть получше, например, Khadas Vim на процессоре Amlogic. Не самая плохая платформа Allwinner. Можно будет после моего рассказа подойти ко мне потом в перерыве, я это все буду готов рассказать, показать.
Я, на самом деле, сюда не железяки рекламировать пришел, но, тем не менее, остановлюсь. У всех этих штук есть свои недостатки. Есть устройство, которое нам подошло в наших целях намного лучше.
У них несколько названий. Это NanoPi, китайский производитель, называется FriendlyElec, FriendlyARM. И так случилось, что он лишен недостатков Raspberry Pi, при этом у него множество преимуществ.
Есть eMMC-модуль, то есть вы отделяете операционную систему от внешнего носителя, и он работает в хорошем температурном режиме. Там есть и Linux, и Android, все это с исходниками, все это можно собирать на ходу. Больше экспериментов проводить мы не стали. Мы пробовали морозить Raspberry Pi и получилось не очень хорошо, при запуске третья модель у нас просто лопнула, процессор развалился. Никаких проблем не было. А вот эту штуку мы пробовали и замораживать, и в духовке разогревать.
Его можно и охладить, у него процессор расположен с обратной стороны, я вам сейчас покажу, у меня тоже есть. При этом тут есть полноценный еще PCI Express шина, причем 2x, и в целом все нормально. Процессор снизу. Вот так он выглядит, все то же самое, что у вас. На него надевается жирный радиатор, и этот радиатор прекрасно рассеивает все это тепло.
Что там есть? Чуть-чуть подробнее. Я с ней последние полгода прототипирую все, что есть, поэтому и делюсь с вами. На самом деле, мне эта платформа очень понравилась. Он очень мощный, он греется. Там шестиядерный процессор. Но там нормальная видеокарта, аппаратное сжатие видео, и, самое главное, все это хорошо расширяется и стоит примерно как Raspberry Pi. Он в пике может потреблять 15 ватт, иногда даже больше. Это 50 долларов, плюс чуть-чуть за eMMC и радиатор.
Точно такого же размера, малюсенький. У него есть младший брат. Они полностью hardware-совместимы. Хорошая новость: если вы этот eMMC-модуль возьмете отсюда и воткнете вот в этот, то вам не нужно пересобирать прошивку, менять софт. То есть если вы делаете устройство и вам внезапно понадобилось переехать на маленький форм-фактор, то электрически оно у вас будет примерно совместимо. Даже вот этот маленький сорокапиновый разъем сверху — он по пинам полностью совместим с большим устройством. Да, меньше USB, их не четыре, а два, но зато все хорошо. Да, чуть меньше памяти.
На мой взгляд, прототипировать лучше всего на большом толстом дистрибутиве Linux. Что еще вам понадобится? И да, там это будет работать хорошо. Понятно, что в финальном устройстве у вас, скорее всего, будет либо проприетарная операционная система, либо очень маленький Embedded Linux, какой-нибудь Linaro или еще что-нибудь меньше.
Что-нибудь на Debian, или еще что-то, с пакетами, куда вы можете в две команды поставить все, что вам нужно и запускать большие-большие штуки. Но пока вы пишете прототип, вам нужен гибкий инструментарий, поэтому большой Linux — это ваш выбор.
Да, он у вас будет четыре гигабайта. На стадии прототипирования размер дистрибутива на самом деле не имеет значения. Вот здесь eMMC-модуль на 16 гигабайт. Ну и хорошо. Еще вам нужен хороший блок питания, и, самое главное, хороший кабель. Я залил сюда этот Linux, все у меня прекрасно.
Так случилось, что хороших Type-C-кабелей довольно мало, а хороших блоков питания еще меньше. Мы сейчас говорим про устройство типа такого, или типа Raspberry Pi, которое питается от Type-C. Кабель подобрать будет тоже сложно, не игнорируйте это. И если вы возьмете даже не серийный блок питания, а что-нибудь, например, для светодиодных лент и запитаете этим напрямую устройство, вам будет намного лучше.
Мы искали проблемы в софте и в периферии, а она состояла в том, что питание внезапно проседало. У нас в начале экспериментов что плохое питание и плохой кабель приводили к тому, что устройство внезапно зависало.
Когда вы придете к более-менее серийному прототипу, вы всегда сможете заказать PCB, и на нее уже напаять ваши компоненты. Очевидно, что если у вас будут сенсоры, то вы будете использовать плату вроде такой, с кучей маленьких проводочков, потому что паять на коленке целую кучу всего и подключать в такую мешанину из проводов — не очень удобно. Но пока вы экспериментируете, так удобнее.
Скорее всего, в плате, на которой вы прототипируете, и так будет выход для монитора. Следующая вещь, которая вам нужна, — USB-UART. Надо сразу учиться жить нормально. Но если по-взрослому, лучше сразу переходить к решению, в котором вы работаете с этим в консоли, потому что когда вы будете собирать EVT-образцы, никто вам никаких видеовыходов, HDMI и прочего напаивать не будет.
Это LCD-экран, как ни странно, с USB-интерфейсом. Есть еще одна полезная штука, я вам ее покажу. Но в прототипировании и разработке — отлично. Я, на самом деле, считаю, что USB в industrial — это не очень хорошо, даже плохо. Это обычный стандартный привычный всем двухстрочный экран с конвертором в USB и еще с двумя кнопочками. На USB есть тонны периферии, этот экран — частный случай. Этого достаточно. Его можно подключить к любому устройству, выводить на него отладочную информацию. В большинстве случаев вам больше ничего и не нужно.
Можно, конечно, вырезать ножом из пенопласта, лепить из глины, из пластилина, еще из чего-то. Вам понадобится еще одна вещь — 3D-принтер. Но невозможно представить себе, как это будет работать в реальных условиях. Но в конечном итоге вы всегда придете к ситуации, когда вот моя электроника, вот я понял, чего я от нее хочу. Поэтому в какой-то момент мы закупили несколько принтеров, и все идеи, которые у нас появлялись, мы печатали.
Придумали новый корпус — печатаем. Придумали новый держатель — печатаем. Так проще понимать реальность. У нас целая галерея из двух-трех десятков разных держателей, кнопочек, подставок.
Я не сторонник чего-либо, я считаю, что все это отличные языки программирования. Сейчас будет немножко холивара, на чем разрабатывать. Потому что ядро Linux, потому что все модули, потому что там все просто, понятно и сложнее себе выстрелить в ногу. Но так случилось, что все железо, как правило, лучше всего пишется на C. На C++ выстрелить себе в ногу чуть-чуть проще, на Python вообще не надо заморачиваться ни с памятью, ни с чем.
Оно легко переносится, куда вам понадобится, и все будет работать. Поэтому, на мой взгляд, здесь правило такое: если вы сразу нацелены на финальное mass production-решение, пишите на C. Это быстро, легкий порог вхождения, вы подключили всю периферию, написали, скопипастили даже откуда-то набор скриптов, у вас все заработало. Если вам все нужно здесь и сейчас, если вам нужен computer vision, работа с изображениями, нейронные сети и вот эта вся история, то проще начать с Python. Это всегда можно параллельно переписать на C, можно сделать как-то еще. Вы можете с этим жить. Но вот мое субъективное мнение: C хорош для production, а Python хорош для прототипирования.
Я считаю, что прототипы не надо аутсорсить. Теперь следующий момент. Вот у вас есть железка, и вы точно хотите с этой железкой реализовать определенные функции. Есть один случай, когда надо их аутсорсить, — это когда вы полностью уверены в железе. Тогда все просто: нашли аутсорсера, они написали вам код, вы применили его на железку, у вас все заработало.
Вы уже договорились, у вас уже есть договор, скоуп работ, и аутсорсер уже придерживается этого скоупа. На самом деле, во время работы с аутсорсом вам сложнее менять требования на ходу. Он получит деньги по факту договора, а не по факту ваших желаний.
Вы находитесь в стадии, когда же нам покажут что-нибудь следующее. Пока вам делают ваши прототипы, вы просто ждете. Они испытывают весь этот фан, они играют с железом, они играют с софтом, и учатся, и получают удовольствие. И самое главное, за ваши деньги аутсорсер учится. А вы получаете примерно ничего, то есть ваша экспертиза в этом месте не растет.
Они вам задают вопросы, а вы не знаете, что отвечать, потому что за вас все эти этапы проходил аутсорсер. И когда вы приходите к производству финального устройства или к какому-то массовому заказу, вы общаетесь с фабрикой, исполнителем, с design-house и так далее, и вы им рассказываете какие-то свои требования. Они за вас думали про инженерную часть, про электрическую, еще про что-нибудь. Они за вас думали. Хорошо, когда экспертиза копится у себя. И, на мой взгляд, это очень нехорошо.
А еще, когда вы разделяете экспертизу hardware и экспертизу software в разных компаниях, в разных географических местах, это сложно, потому что здесь нужна плотная коммуникация, и обязательно что-то может получиться не так.
Вы с ними договорились, они сделали. А еще у аутсорсеров есть свои планы, свои ресурсы. А вся экспертиза у них. Вам надо доработать, они могут сказать: «Ну, вставайте в очередь, у нас тут новый заказчик, простите». Они уже все знают, как делать, а вы не знаете ничего.
Вам надо где-то что-то оптимизировать, потому что это деньги, процесс. Дальше, у вас есть hard и soft. Вы можете взять ноутбук, приклеить к нему изолентой камеру, GPS, обмотать это все в пенопласт и пустить в тестовую эксплуатацию. Если вам нужно сделать просто proof of concept, то на самом деле железо вообще не очень имеет значение. Это proof of concept, не имеет значения, из чего он сделан.
Если речь идет об оптимизации BOM, то есть из чего будете собирать устройство, то мой совет, — лучше сначала оптимизировать программное обеспечение, потому что это позволит вам сильно ужаться по деньгам и по устройствам.
Давайте делайте из самого дешевого железа. В то же время, если у вас цель прямо деньги-деньги-деньги, это, извините, китайский подход. Если речь идет про сбор данных, например, когда мы делали наши камеры, нам нужно было собрать как можно видео и фотографий уставших водителей, водителей, которые провели весь день за рулем, и для этого нам было нужно что-то собрать. Тут сильно альтернативы нет. У вас другая задача. В этом месте сложно вообще что-то оптимизировать. У вас цель — собрать данные, поэтому делайте из того, что есть и собирайте.
Она ездит в машинах и собирает данные. Например, вот эта камера юисбишная, напечатанная на принтере, соединенная вот с таким нашим NanoPi. Работает. Работает? Не очень. По деньгам это выгодно? Но это работает, все хорошо.
Поэтому, прежде чем играться с дизайном, зафиксируйте железо. Если вам нужно проверить механику, проверить дизайн, то оптимизируйте железо, потому что когда вы финализируете дизайн, финализируете механику, покажете вашему заказчику, руководству, инвестору, а потом придете к выбору железа, и вам скажут: «Извините, в это не помещается», то вы окажетесь в глупой ситуации.
После этого подбирайте под него компоненты. Во всех остальных случаях пишите программное обеспечение, делайте, чтобы оно работало быстро и стабильно.
Вот оно, нормальное, красивое, закрыто снаружи специальным инфракрасным стеклом-фильтром. Пример — наше устройство Signal Q1, которое отслеживает поведение водителя. А начиналось все вот с такого: Внутри модем, GPS — оно достаточно неплохо нафаршировано электронной начинкой.
Прототип, который мы делали, дал нам осознать очень много важных моментов. Присоска, камера, крепеж, кабель, NanoPi.
Какое физическое расстояние от водителя до стекла. В первую очередь, мы поняли, какая нам нужна камера, какой нужен сенсор, какая нужна оптика. Семьдесят сантиметров. Вот кто может навскидку сказать, сколько расстояние между стеклом лобовым и лицом водителя, если в параллель? Вы в нее попадаете. Это такой обман, легкая ловушка. Это 70 сантиметров, 45 — это до зеркала заднего вида.
Мы оптимизировали этот код, чтобы все работало еще лучше. Кроме того, что камера и оптика, мы подобрали платформу, на которой может исполняться наш код. Когда человек сидит, просто в обычном режиме работает с ноутбуком, эти данные не релевантны. Мы собрали бесценные данные для machine learning, потому что, не собирая эти данные, сидя в офисе, невозможно ничего сделать. Это не поведение шофера. Он смотрит вверх, вниз, вбок. Поэтому без устройства деваться было совершенно некуда. А нам нужно было поведение шофера.
Присоски — плохая идея. Опять же, я показывал присоску. Мы даже их мазали сахарным сиропом, чтобы они держались лучше. Они отваливаются на морозе и на жаре. Это смешно, забавно, но пока вы не прошли перечисленный этапы, вы ничего не будете знать наверняка. Все это нужно было пройти. Но если вы собираете устройство, которое будет ездить в сотнях, в тысячах, в сотнях тысяч автомобилей, у вас нет права на такую ошибку. Вам кажется — это же присоска, все держатели для телефона на них делают. Вы не сможете поехать и в ста тысячах машин заменить одни присоски на другие.
Нельзя было узнать это, пока мы не попробовали поставить наш реальный прототип в реальные машины. Еще мы подобрали место установки, где я и рассказал, — 70 сантиметров на уровне глаз. Там много всяких чудес с питанием, не тривиально протаскивать эти кабели. Дальше мы научились подключаться к самой машине. Нужно было найти место, куда это все монтировать, куда подключать, куда вешать устройство.
Казалось бы, чего там обновлять? И еще мы научились обновлять программное обеспечение. Но нет. Пошел на сервер, чего-то забрал. Это нам дало понимание того, с чем мы столкнемся в будущем, а также фидбек с обратной стороны — о том, как наши устройства воспринимаются в машине. Это тоже длинная история, и только сделав какое-то количество прототипов и запустив их в реальное плавание, вы получаете возможность потренироваться.
Как я уже сказал, бояться USB-интерфейса надо в production, в индустриальных вещах. Несколько советов. У вас есть возможность подключить кучу модемов, камер, GPS, Wi-Fi. Когда вы прототипируете, USB — это классно и хорошо.
Сколько вариантов камер можно найти для того же Raspberry? Вот например, камера. А когда мы подбирали камеру для нашего устройства, мы просто пошли на AliExpress, простите, и купили там 50 разных камер на разных сенсорах, с разными линзами, на разных PCV. Две, три, четыре. Это нам не стоило примерно ничего, я имею в виду — в масштабах проекта. Все они были USB, и мы их все попробовали. Поэтому USB — хорошее решение, в том числе на примере этого отладочного экрана. Мы быстро убедились, что если бы мы сейчас пошли на несколько заводов и заказали разместить вот такие сенсоры Sony, OmniVision, с такими-то линзами, то мы потратили бы месяцев пять-шесть только на это производство и к нынешней точке пришли бы только спустя полгода.
Например, когда вы думаете про корпус, возьмите и сами соберите его отверткой. Когда вы делаете что-то, прототипируете — сразу думайте, как это будет производиться на заводе. Вв не сможете научить такой длинной процедуре людей, которые находятся на заводе и могут быть без специального образования. Если на сборку ваших плат отверткой и закрытие корпуса у вас уйдет полчаса — это не вариант. Это одна из причин, почему вам нужен прототип. Значит, вам надо что-то упрощать.
Все, что вам пришло в голову, вы нарисовали, начертили, напечатали, подержали в руках. Еще, как я уже говорил, 3D-принтер — наше все. Если плохо — исправьте. Если получилось хорошо — прекрасно.
Делайте все руками. Следующий пункт очень важен. Это помогает накопить ценные знания, позволяет вам попробовать много всего разного. Даже если этого вы не любите, даже если это не ваш профиль. А еще это весело, потому что вы погружаетесь в какой-то новый параллельный мир.
Вы работаете на стыке между computer vision и железом. Предположим, вы делали такую-то разновидность hardware, а теперь перешли на что-то другое. Это всегда полезно, и команда чувствует подъем, когда все происходит внутри, когда это бурлит, когда есть много устройств, много прототипов. Или вы усиливаете свои навыки в разработке ПО какими-то хардварными навыками. Самое главное — это копит у вас внутри опыт.
Вы ни за какие деньги не сможете найти себе консультанта, который все знает и умеет. Когда вы переходите к следующему этапу, к mass production, этот опыт оказывается бесценным. Поэтому прототипируйте, делайте, и все получится. На мой взгляд, это правильно. Спасибо.
