Броненосец Duilio
155 фт деталей с общим количеством 939 шт.
Великолепно.
Дорисовал, наконец всё фтд и остальные детали.
Шаг винта неестественно большой , это же не гоночный катер .
Шаг винта неестественно большой
шаг винта что на моей картинке, что на приведенном вами фото близок. Поэтому что имелось в виду - не понятно.
В любом случае заплывы покажут. Переделать и поменять винты не проблема.
Электроника для модели
А зачем столько Nano вместо одной Mega?
Можно было бы заливать прошивку за один раз, а не в каждый контроллер, да и в принципе проще.
А зачем столько Nano вместо одной Mega?
Вообще-то Nano там одна 😉 Она управляет основными функциями, как-то обмен по радиоканалу, управление двигателями и серво, освещение и т.д.
А две Pro mini управляют работой башен, каждая своей - шаговый двигатель поворота и пускание дыма при выстреле. Соединены они с Nano по шине I2C - всего два провода.
Mega в данном случае не удобна. Во-первых, она большая (я имею в виду Mega 2560 PRO), а места мало. Во-вторых, она избыточна. В-третьих, от неё надо разводить во все стороны кучу линий, а места мало 😉
Поэтому применено именно такое схемное решение.
Во-первых, она большая
Судя по картинкам, Mega-Pro не критически больше (для сравнения Mega pro и Nano):
Линий до устройств разводить всё равно столько же, а вот I2C исчезнет…
Ну и в данном случае, с программистской точки зрения, одна железка эффективнее.
Хотя конечно это хобби и каждый художник рисует так как видит и хочет 😃
Проект, в любом случае, очень достойный 😃
Mega-Pro не критически больше
Ну да, всего в 2 с лишним раза больше, чё там 😁. И на пространстве, занимаемом не нужными мне портами Меги, я размещу нужные мне элементы и они впишутся в заданный габарит платы. Где ж удобство от Меги?
И лучше провести между контроллерами две линии интерфейса, чем тащить от одной Меги 8 проводников на каждую башню.
Так что в данном конкретном случае Мега избыточна и громоздка, не давая при этом видимых преимуществ.
Да и я не художник, а инженер 😁 Не рисую, а разрабатываю. Поэтому данное устройство с разделением функций между контроллерами и модульной конструкцией более оптимально.
с разделением функций между контроллерами
3 точки отказа (или больше?)… Каждая из точек прошивается отдельно и некоторые разными способами - где-то FTDI, где-то нет…
И программные связи править в большинстве случаев проще, чем аппаратные.
Будь система еще больше - такой зоопарк превращается в кошмар (видел не раз) проблемы с несовместимостью протоколов, версиями и прочее веселье…
И не те тут масштабы, чтобы выигрывать от сетей и параллелизма.
В IT так стараются не строить. Это не промышленный поход.
с программистской точки зрения, одна железка эффективнее.
Но еще раз - тут хобби и творчество и у каждого свое право 😉
😁
Будь система еще больше - такой зоопарк превращается в кошмар
Я привел аргументы, почему данная система реализована так.
Вы куда-то не туда нагнетаете и совершенно напрасно.
Распределенная система всегда живучей централизованной, раз на то пошло.
Проблемы с прошивкой Ардуины нет никакой, если вы это делали, то знаете. И способ прошивки один. 😁
Один контроллер прошить или три, разница в минуту.
Грамотно сделанные аппаратные связи не требуют правки.
“В IT так стараются не строить. Это не промышленный поход.”
Да что вы говорите? Все IT-сети централизованные, распределенных нет? Все промышленные сети централизованные - один огромный контроллер на весь завод, распределенных сетей промышленных контроллеров нет?? Как интересно…
Не знаю, что такое программистский подход, видимо, чем меньше строчек писать, тем больше времени на танчики остается 😁
Да что вы говорите? Все IT-сети централизованные, распределенных нет?
А по вашему существуют только микросервисы? 😃
Распределенная система всегда живучей централизованной, раз на то пошло.
Это не так однозначно.
Предположим один сервис принимает оплату, второй реагирует на проход пассажира и открывает дверь… (гипотетическая система, только что придумал)
Будет ли работать система при отказе одного из сервисов?
А бывают ситуации, что если часть системы живет, а часть нет - то лучше бы умерло все.
Не говорю, что монолит лучше распределенной системы - всё очень по разному может быть.
Я могу много рассказать о плюсах и минусах что разделения, что монолитных архитектур. Но это точно уход от темы.
Вы куда-то не туда нагнетаете и совершенно напрасно.
Я совершенно не нагнетаю. Наоборот утверждаю, что в хобби каждый может все строить так как видит.
Хотите распределенную систему в микро-обьеме - стройте.
Просто меня несколько удивил такой подход.
Не знаю, что такое программистский подход, видимо, чем меньше строчек писать, тем больше времени на танчики остается
Примерно так 😃 Но код обычно еще и сопровождается и дорабатывается, а потому чем он проще при прочих равных - тем лучше.
Желаю Вам не столкнуться с необходимостью перепрошивки, например через год-другой, ну или чтобы весь необходимый код быстро нашелся.
А по вашему существуют только микросервисы? 😃
Это не так однозначно.
Предположим один сервис принимает оплату, второй реагирует на проход пассажира и открывает дверь… (гипотетическая система, только что придумал)
Будет ли работать система при отказе одного из сервисов?
А бывают ситуации, что если часть системы живет, а часть нет - то лучше бы умерло все.
Не говорю, что монолит лучше распределенной системы - всё очень по разному может быть.
Я могу много рассказать о плюсах и минусах что разделения, что монолитных архитектур. Но это точно уход от темы.Я совершенно не нагнетаю. Наоборот утверждаю, что в хобби каждый может все строить так как видит.
Хотите распределенную систему в микро-обьеме - стройте.
Просто меня несколько удивил такой подход.Примерно так 😃 Но код обычно еще и сопровождается и дорабатывается, а потому чем он проще при прочих равных - тем лучше.
Желаю Вам не столкнуться с необходимостью перепрошивки, например через год-другой, ну или чтобы весь необходимый код быстро нашелся.
Я смотрю и читаю,как человек делает МОДЕЛЬ-КОПИЮ БРОНЕНСЦА ,а весь этот с …ь который Вы развели по поводу процессоров мне лично , да и другим неинтересен.Здесь раздел Копий Судо,а не обсуждения ардуино.