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