Я скажу так: нельзя просто так взять и построить робота за исключением той ситуации, когда вы просто развлекаетесь, учитесь, экспериментируете, добавляете новые детали, пробуете, комбинируете по-разному и так далее. Но здесь есть существенный момент: вы не ставите цели и не планируете определенный результат. Когда же вы разрабатываете какой-то проект и ожидаете получить определенный результат, планирование неизбежно. Некоторые говорят: «Начнем, а там посмотрим». Но задумайтесь на секунду, как вы можете прийти к желаемому результату, когда вы не представляете, какие компоненты вам нужны, хватит ли вам вообще пинов на Arduino, например, достаточно ли будет питания вашей системе и так далее. Хотя бы из-за этого стоит задуматься. Приведу еще один пример, обратный: не так давно вернулся из лагеря, где подростки делали проекты на Arduino, и даже те ребята, которые немного подумали наперед, столкнулись с такими сложностями, как, например, в корпусе устройства мало места и на этапе отладки не получается доставать Arduino для заливки нового варианта скетча без полного разбора устройства. Естественно, когда такое множество манипуляций приходится осуществлять, на это уходит столько времени, что его в итоге не хватает. Или другой проект: парень строит отличного помощника сисадмина — робота-бубнера, который может научиться воспроизводить последовательность, которую вы ему прохлопаете, а также может в фоновом режиме звенеть с заданной амплитудой и частотой. Он построил корпус, он построил, реализовал один режим, он реализовал другой режим, и за день до того, когда результат нужно презентовать, он обнаружил, что два режима параллельно не стыкуются, и здесь нужно какое-то новое решение. Ну благо решение нашлось, но это происходило в режиме аврала. В мире существует множество подходов к проектированию, планированию. В каждой организации, которая занимается промышленным выпуском оборудования и программного обеспечения, приняты свои методологии и их комбинации. В разработке программного обеспечения многие придерживаются таких подходов, когда требования к конечному результату периодически уточняются, и за много проходов в итоге все реализуется. Мне больше импонирует подход, который проповедует мой знакомый, технический директор одной компании, которая занимается разработкой и внедрением очень масштабных аппаратно-программных систем. Этот подход заключается, в двух словах, в том, что к реализации системы они не приступают до тех пор, пока нету детального плана разработки. Детального настолько, что каждый исполнитель отчетливо представляет, каким образом реализуется его участок, то есть у него не уходит время на какие-то эксперименты, пробы, исследования, обучение — все это делается заранее. И стыковка этих участков опять же происходит успешно благодаря тому, что в плане это учтено и описано. Опыт этой компании показывает, что соотношение времени на планирование и разработку может соотноситься как, например, 3 к 1, то есть планирование занимает в 3 раза больше времени, чем непосредственно реализация. Но в итоге суммарно все время, затраченное на производство продукта, существенно, в том числе в разы, может быть меньше, чем в альтернативной ситуации, когда требования уточняются постепенно, и проект начинают реализовывать при наличии каких-то «белых» пятен. Когда вы дойдете до промышленной разработки в какой-то компании, вам нужно будет принять те обычаи и правила, которые в ней приняты. Но сейчас, когда мы учимся делать несложные устройства, я бы рекомендовал все равно воспользоваться как минимум двумя принципами из идеологии упомянутой мной компании. Первое: я считаю, что нельзя приступать к разработке, не сформулировав предельно конкретно результат, который должен быть достигнут. Иными словами, должно быть описано, каким образом мы проверим устройство и поймем, что оно выполняет те самые действия, ради которых оно было создано. Если у нас есть такое описание, на самом деле, нам не составит труда детализировать более мелкие фрагменты этого устройства: из общего описания будут следовать более частные до тех пор, пока это не будет описано настолько подробно, что можно просто взять и сделать. Второй момент, который, я считаю, важно иметь в виду — это то, что нельзя приступать к разработке, когда существуют какие-то «белые» пятна в том смысле, что мы можем не знать, какое решение мы применим для того или иного узла; или не знать, как именно он работает, каким образом его программировать, какое питание ему подавать — вот все нюансы, связанные с работой того или иного узла. Вообще, занимаясь с подростками в лагере, я каждый раз пропагандирую ценность планирования, и неизменно мы все убеждаемся в том, что тот, кто не поленился составить план, достигает результата быстрее, и результат обычно качественен. Давайте попробуем представить, что будет делать Поливалли, и что нам для этого потребуется. Я это буду зарисовывать на привычной нам схеме, но для начала нужна формулировка того, для чего проект реализуется.