Опыт работы: видеорегистраторы полетной информации для Сухих и других крутых КБ
Разработка средств доставки и диагностики бесконтактным методом ЭМА и другими...
Роботы были разные, все внутритрубной диагностики. В этом проекте команда побывала в головном офисе заказчика в Куала-Лумпур
Робот умел жить от блоков АКБ, построенных на 18650 и имеющих системы контроля заряда\разряда и токов, защиту от расбалансировки и каждый такой бочонок состоял из 60 18650. В блоке батарейки была прошивка и начальник отдела всегда над этим угарал.
Еще один блок робота - модуль перемещения. Сопровождал механику опытный конструктор с которым было комфортно работать и потому по механической части все было на высшем уровне. Электрическая часть после отладки работала довольно сносно, но до боевых испытаний было не понятно, что защита драйверов MAXON при сдергивании робота - генерировала слишком мозные импульсы с бескколекторника той же марки. И потому в какой то момент схема с транзистором и нагрузочными резисторами загоняла себя же в активный режим, в котором выгорал полупроводник от постоянной статично токовой нагрузки. Была еще сомнительная схемотехника с нормально заторможенным электро тормозом, разблокировка которого осуществлялась подачей управлябщего напряжения в два этапа: Сначала 24В отпирающий импульс, далее пониженное напряжение определяемое толи средним током толи просто напряжением в 12-15 вольт. Управление ими было первоначально обеспечено нормально замкнутыми твердотельными реле и с ними тоже возникла проблема. Замкнулись толи от нагрузки толи от вибрации, хотя казалось бы реле все же твердотельное, судя по PDF. Но самый острый вопрос встал, когда обозначилась проблема измерений, ведь робот измерял по методу ЭМА (Запатентованному). И фоновый уровень шума в движении модуля перемещения без изоляции металла мотора пластиком не давал возможности получить достойный сигнал/шум. В целом все проблемы были эффективно решены.
С блоком управления все было окей! В нем пришлось сделать лишь некоторые оптимизации и доработки по месту.
Блок измерения - сложная часть и автором изначально был не автор статьи. Но пощупать блок пришлось и удалось. Что очень приятно. Разработчик блока на тот момент просто покарила своими амбициями и для меня, как для человека с 10 летним стажем в схемотехнике в какой-то момент стала эталоном подхода. Чистый Agile, все итеративно и без излишеств.
К концу разработки я побывал внутри каждого блока и "подкрутил там все что можно было оптимизировать"! Мне казалось, что это средство доставки было гениальным, когда уходил было множество идей как оптимизировать наше творение. Например, в некоторых блоках просились врубные платы, потому как проектирование ECAD\MCAD уже было освоено.
Еще на одном месте мы реверсили известные бренды типо Livox и FARO и делали русский продукт по образу и подобию в департаменте Перспективных разработок.
далее в Сколково в здании Сколтеха. Это было лучшее место работы с точки зрения эмоций, отвечаю! В Сколтехе каждый день как вечеринка. В Лаундже всегда был улыбчивый и немного сатиристический бариста, скучно не было точно!
Работа над лидарами, запуск продуктовой линейки, разработка системы хранения проектов и повышения культуры разработки в предприятии. На момент приема меня в штат статус компании был StartUP, на момент ухода из штата уже SpinOff...
Разработка системы хранения зашла в тупик. Были предложения применять решения от Союза PLM как в прошлом месте работы, но они разбились об бюджеты.
Нужна была система, достаточно простая, чтобы люди старой закалки интуитивно могли понять. А людям новой закалки плевать, гибкость наше все!
Родилась давно вынашиваемая система AltiumDBE на основе SQL базы данных и с интерфейсом на Retool как дешевый и простой вариант из "говна и палок" не требующий вливания денег, сделанный на энтузиазме. Было понимание, что можно прикрутить AI агентов, потому что я давно изучал эту технологию и мечтал её применить. Поначалу заполнением SQL таблиц и столбцов я нагружал DeepSeek, он выдирал промтом из известного русского стока параметры компонентов (на тот момент были только конденсаторы и резисторы) и помещал их данные прямо в нужные столбцы и колонки SQL базы...
Так я впервые заполнил 14 компонентов одним промтом за 17 секунд, получив SQL код для админки PG Admin4 чтобы внести все эти строки в таблицы компонентов...
Чтобы понимать, вручную формировать базу компонентов на предприятии это ДОЛГО!
14 компонентов в нормальном режиме можно час заполнять!
Мой Нарратив по форме работы на предприятии и ценности легкой простой структуры для хранения данных: В идеале общей для всего РФ сектора, кто работает по ГОСТ и может\хочет настроить защищенный канал для доступа к сервисам на хостинге типо Selectel. И тех, кто против интегрированных библиотек, против локальных библиотек проекта (потому что это зло и никто ими никогда не делится при передаче проектов)
Вывод, на прошлом месте работы был единственный крепкий УМ - это Лазарев Андрей Александрович и его виденье идеалов разработки мне очень откликается!
Что ценно в работе разработчика?!
плата, которую он сделал?
Каков конечный продукт разработчика электронных плат?
В каком виде должен быть результат работы?
Вот эти вопросы я считаю были важными на наших технических совещаниях.
Так каков же конечный продукт?
Это отнюдь не плата!) Как думают многие...
Конечный продукт отдела разработки это КД, оформленное по требованиям ГОСТ и ЕСКД, ЕСПД.
В чем ценность специалиста?
- Умение разработать это КД, в кратчайшие сроки и с достаточной для выполнения всех дальнейших бизнес-процессов формализацией!
Вот, что я вынес за рамки работы в том месте. Это понимание! И веру в то, что так правильно.
Но Москвичи реалисты!) Они делают в дюймах, потому что так быстрее, ведь бабки решают!
Делаешь в дюймах - делай в США! В РФ есть законы, и плевать на них не корректно...
Итак, у нас 2 лагеря... реалисты и идеалисты. Отбросив перфекционизм можем получить вполне рабочий вариант для обоих этих лагерей, как мне кажется. Но должно быть финансово оправдано и удобно. И для меня удобно это важно. Так как я стремлюсь в верхние уровни City.
Как же сделать, чтобы не нужно было тратить много сил на переработку скаченных УГО и посадочных а к тому же еще на сбор в единую локальную базу компонентов?
Да и в 2025 году НЕ применять базу компонентов это моветон! Пришел к этому выводу после просмотра ролика с конференции Altium в главных ролях Роберт Ферраник. Хоть он и пришел к выводу, что общего идеала нет. Каждому своё!
Продукт на мой взгляд должен быть ориентирован на RND команды. Но может быть применим и коллективам из большого числа сотрудников.
Итак, зафиксируем в сознании: Ценность специалиста, в том, насколько грамотное КД и в кратчайшие сроки он способен создать, а не в том, как он офигенно допаял компоненты, которые забыл указать в схеме после отладки! Не платка отдельная ценна и не схемка, а ценно КД по которой можно масштабировать производство по принципу FABLES.
Возможно мне следует изучить новые продукты Altium для актуализации знаний. Но даже в этом случае Altium DBE концепт выглядит конкурентно...
