Как стать автором
Обновить

Комментарии 11

НЛО прилетело и опубликовало эту надпись здесь
Идея действительно интересная.
Но есть моменты. Разработка это… вещь такая порой капризная. Грамотно выстроенная разработка — это тоже своего рода талант при наличии немалого опыта.
Если на первом этапе можно обойтись ТУ/ТЗ, то начиная со второго этапа могут быть проблемы. Я удалённо участвовал в разработках и надо сказать, если разработка большая, очень сложно сделать сразу и правильно, а если и сделаешь, то легко может оказаться, что в ТУ/ТЗ есть разночтения, неописанные моменты, которые потом вылазят боком, так как «всем всё очевидно» и т.д. и т.п. Тому, кто изготавливает контроллер уже на этапе изготовления очень желательно иметь какой-то макет механики, чтобы проверить свои соображения по управлению (легко может оказаться, что для питания привода шторки мало тока, так как оригинально сконструирована шестерёночная передача, которая «съедает» мощность привода и надо организовать отдельный канал питания). Справедливо и наоборот — для конструирования механики желательно понимать как её потом будут управлять и какие подводные камни такого управления могут всплыть (спец все неплохо рассчитал, но если движок для шторки это сервопривод, то оказывается что при подаче питания он «ставится на ноль» с дикой скоростью и что-нибудь ломает и тут оказывается, что вообще лучше использовать шаговик, который подороже, но, так как при включении непонятно как он стоит и где у него «ноль», для него нужно сделать контактные ограничители — конструкцию надо здорово менять). По сути, в вашей схеме, спецы 3 и 4, тесно взаимодеёствуя, должны изготовить макет, они же испытать его, как-то протестировать, скорректировать выявленные моменты и потом уже передать спецу 5, который на базе этого макета, не исключено, что несколько матерясь, готовит из него опытную серию в количестве несколько штук и проверяет. И если всё нормально — передаёт на внедрение.
Не исключаю, что может всё получиться хорошо и сразу. Но далеко не всегда так бывает. Поэтому в ТЗ и присутствуют фразы типа «определяется на этапе разработки».
Все верно, но шаговик, при прочих равных, таки дешевле сервопривода. Сервопривод — знает в каком он положении. Скорости его работы задаются таки программно, потому необходимости в изменении конструкции нет, во всяком случае если исключить вариант что по ТЗ должны быть высокие скорости/точности и т.д. и т.п.

Да я имел ввиду, если серву скрутить вбок и потом подать питание и управление на «ноль», то она к этому «нулю» и ломанётся со всей мочи. Это потом уже можно плавно крутить и делать всё что хочешь. А в момент включения что делать?
Ну… я это всё довольно условно написал, чтобы просто акцентировать внимание как пример. Возможно не самый удачный в данном случае.
Если честно, я не специалист в этих вопросах, но: чпу станки не испытывают проблем при включении, то есть сервы то стоят на месте, рывков не происходит, в том числе в случае аварийной остановки, отключения питания от драйверов серв и последующего включения системы.
В любом случае это чисто программный момент по управлению драйвером серводвигателя и механики касается несколько опосредованно, хотя и бывают случаи когда это не так.
Но мысль то ваша в любом случае абсолютно верна. Лично мне, например, будет казаться нереалистичной и нежизнеспособной любая схема, подобная иллюстрации в статье описывающая все же более линейный процесс, не смотря на обратные связи между «специалист 1» <-> «специалист 2». Исходя из моего практического опыта, схема скорее должна представлять скорее не то что замкнутое кольцо, но какую то систему где все точки связанны и система полностью замкнута сама на себя :) Порой уже просто руками разводишь с удивлением выясняя в каких моментах могут вылезти несостыковки, даже если механика — это, внимание, просто крепление(!) блока к устройству, казалось бы, тупого и примитивного, но таки связанного с чисто программными моментами теснее чем можно было вообразить.
В общем это уже вопрос, как мне кажется, из сферы инфографики, которая в таком виде как в статье, описывает, скорее, совершенно идеальный вариант, с которым в реальности едва ли кто сталкивался :)
Как разновидность фриланс-биржи — идея мертворожденая. Потому что слишком сложно наладить толковое взаимодействие между людьми, которых связывает только техзадание. А вот что-то типа краудсорсинговой сети для энтузиастов (любых сфер — хоть автомобиль построить, хоть ананасовую ферму, хоть какой-нибудь чудаковатый гаджет) с удобными инструментами взаимодействия, добавлением в друзья людей со схожими интересами/дополняющими ресурсами/смежными специальностями и облачными инструментами для организации прозрачного процесса разработки может стать прорывом, КМК.
Github
Да, github — отличный пример. Для разработки софта. А вот для хардварных проектов (в том числе не-IT) подобного я не встречал. Чтоб, например, мотоэнтузиасты и специалисты по электротранспорту могли разработать полноприводной электромотоцикл, например. Или архитекторы, дизайнеры и спецы по строительным технологиям могли разработать проект экономичного и экологичного дома и т. д. Да и IT-проектам, типа Neo900не помешала бы более удобная платформа для управления процессом разработки (например представители сообщества могут предлагать коммиты с идеями по улучшению продукта)
Да в принципе в Github можно и любую документацию грузить, схемы, чертежи. Но я согласен, чтобы это было удобно, нужно многое доработать
Мне кажется, такая платформа была бы интересна в связке с ЦМИТами, тут и совместная разработка, и обучениею
Штука интересная, если четко понимать откуда возьмутся заказчики. Поток заказчиков и проектов. Если у вас есть готовый работать по такой схеме заказчик — конечно приступайте.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории