ТРИЗ: Нам нужен повербанк-тамагочи!
TLDR спойлер:
Идея мобильного приложения, которое будет деликатно напоминать о необходимости зарядить повербанк и смартфон тогда и только тогда, когда это возможно и нужно. Остальной текст можно не читать, там тех-требования к прилжению, немножко про железо и всякие занудства около ТРИЗ.
Короче, есть проблема. В семье есть несколько повербанков, но я, почему-то, не могу приучить своих девчонок каждый раз их заряжать после использования и держать заряжанными.
Так и получается, что за пару использований в неделю или даже в месяц у них повербанки разряжаются практически в ноль, а потом, когда снова случается какая-то поездка и нужна зарядка, они идут ко мне и просят мой, который всегда заряжен.
И тут родилась нитересная идея как добиться постоянной заряженности гаджетов.
Важно, что они не нарочно забивают заряжать. Просто голова другим занята. Как помочь?
Просто постоянно напоминать и спрашивать заряжен ли у них повербанк?
Не годится. Во-первых, тогда я становлюсь виноватым, что не напомнил. Во-торых, они говорят "потом", и снова забывают. В-третьих, они ещё чаще начинают забывать свои гаджеты, если им помогать с напоминаниями! Это как протез памяти, к нему привыкаешь и теряешь остатки умения об этом помнить.
Встроить в повербанк пищалку, чтобы при низком заряде верещала?
Не получится. Такой повербанк будет мешать всем, особенно когда просто физически его нет возможности зарядить.
Сделать выключатель писка?
Он будет выключен, и, конечно же, его забудут включить точно так же, как забывают заряжать устройство.
Сделать выключатель кнопокой без фиксации, которая мьютит писк на несколько часов?
Несколько часов - это не понятно сколько. Если слишком много, то можно пропустить удобное время для зарядки. Если мьютить на пару часов, то девайс может начать верещать среди ночи и всех разбудит.
Решение по ТРИЗ.
Владельцу повербанка должно приходить напоминание о необходимости зарядки тогда и только тогда, когда:
зарядка действительно нужна или очень желательна;
есть возможность поставить повебранк на зарядку;
напоминание не помешает владельцу делать какие-то очень важные дела.
Первый пункт означает, что если повербанк заряжен на 98%, то беспокоить хозяина не стоит.
Второй пункт говорит о том, что нет смысла каждый раз напоминать о необходимости подзарядки когда такой возможности просто нет. Например, мы гуляем и повербанк валяется разряженный в рюкзаке, или спим в палатке, а розетки в лесу нет, или повербанк лежит разряженный в портфеое ребенка, и идёт урок.
В третьем пункте речь идет о том, что держать повербанк заряженным - это, конечно, важно, но трезвонить об этом каждые 5 минут, когда есть более важные дела - плохая идея. Это научит владельца не обращать внимания или выключать напоминания о необходимости зарядки.
Как же всего этого достичь?
Нужен повербанк со встоенным Bluetooth-модулем, который работает по принципу iBeacon. Собственно такой повербанк и будет iBeacon'ом с необычайно большим аккумулятором в качестве батарейки. Сама платка такого модуля совсем маленькая. Вот такая:
Она не сделает заметно более громоздким даже самый крохотный повербанк.
Зато "из коробки" мы получим:
способ быстро искать потерянный в квартире повербанк;
уровень заряда всегда можно видеть через смартфон;
уведомление о возможности поставить повербанк на зарядку будет подаваться смартфоном согласно геолокации и данных о дригаетельной активности владельца;
в утешествиях, когда владелец оставляет дозаряжаться повербанк в разных местах около розеток и в кафе, телефон забьёт тревогу, если вы начнете уходить от своего повербанка забыв его;
смартфон покажет на карте где в последний раз "видел" повербанкин блютус.
Что должно позволять приложение в смартфоне:
спариться с одним повербанком или сразу с несколькими;
указать в настройках локации, где возможна зарядка банки;
автоматически запоминать локации, которых нет в настройках, но в которых повербанк заряжался;
запоминать где в последний раз смартфон получил сигнал от повербанка и какой был уровень заряда его батареи;
послать на повербанк сигнал поиска, чтобы устройство запищало;
делать напоминания со звуком или вибрацией при необходимости заряда повербанка, если повербанк разряжен, а локация подходящая (ведь иногда лишние напоминалки совсем лишние);
откладывать напоминание о заряде на произвольный период времени, чтобы не беспокоить повторами владельца (такой пункт, в отличии от кейсов в начале статьи, будет гораздо реже приводить к забыванию благодаря всем прочим фичам);
делать всё перечисленное, однако не только касательно повербанка, но и самого смартфона.
Действительно, многие забывают заряжать при наличии возможности не только повербанк, но и собственный телефон.
Телефон же может понимать не только статическую локацию, но и тот факт, что находится внутри автомобиля, где раньше получал зарядку. Это можно определить по характеру и скорости движения, по сигнатуре (MAC-адресу) bluetooth гарнитуры автомобиля.
Это означает, что такое приложение будет ценно не только в комплекте с повербанком, но и само по себе.
Ищу простые макеты для Figma
Добрый день! Ищу простые макеты сайтов любой тематики в формате .fig. Перерыл кучу тематических сайтов и телеграм-каналов, макетов, конечно, много, но большинство из них слишком сложные и с большим количеством элементов. Нужны эти макеты для студентов, в качестве заданий для лабораторных работ - набить немного руку в вёрстке и прототипировании юзер интерфейсов.
Буду очень рад, если у кого-нибудь есть на примете сайты или группы в соц. сетях, где такое можно найти.
Если вы профи в своем деле — покажите!
Такую задачу поставил Little.Bit пикабушникам. И на его призыв откликнулись PILOTMISHA, MorGott и Lei Radna. Поэтому теперь вы знаете, как сделать игру, скрафтить косплей, написать историю и посадить самолет. А если еще не знаете, то смотрите и учитесь.
Вопрос по Figma - Как сделать панель вкладок с анимированным переключением и 5-6 вкладками в Figma?
Товарищи, подскажите, плиз.
Не получилось найти обучающее видео или текст, как сделать такую анимированную панель с вкладками в Figma.
Это как в ПлейМаркете... она прокручивается и при переключении открывается новая вкладка.
3d печать
Карательная электроника: Как нельзя разрабатывать интерфейс скоростной видеокамеры
Кратко в статье будет:
Что же не так в первой же картинке: хоть и выглядит вполне аккуратно, или сказ о наводках и СВЧ чёрной цифровой магии и почему так делать нельзя.
Немного об отладочной плате FPGA и особенностях разработки.
О модуле камеры, её сенсоре, MIPI интерфейсе и как его испортить.
Как сделать связь с ПК в сотни мегабит, менее 100мбит/сек, и как в том числе и тут словить кару.
Внимание: в статье несколько хайрез фоток и видео, много тех терминов и лютого DIY, возможен взрыв мозга!
Итак, начнём с пациента:
Что это на фото?
1. Белая плата - мозги: FPGA плата на базе Artix-7 от Xilinx, подключена к ПК по micro USB для прошивки и отладочных логов
2. Мини плата слева сверху - FTDI, обещала "скоростную" связь с компом...
3. Синяя плата справа сверху - сам модуль скоростной камеры с пимпкой "объектива" (извиняюсь за ругательство).
4. Куча проводков от ардуины.
Требовалось:
Захватить видеопоток с камеры и послать на ПК как есть, без сжатия но в RGB, при этом достичь максимального количества кадров в секунду (в идеале несколько сотен).
Что за зверь это, FPGA плата?
Это процессор или миникомп как "малинка"?
Нет!
Но, она, как и процессор, может исполнять алгоритм, считать и управлять чем-нибудь.
По сути FPGA - это набор блоков памяти, отдельных битов памяти и простых, проще сложения, логических элементов с управляемыми связями. А связями всего этого набора можно произвольно управлять софтом по своему желанию.
Стоп! А как же тогда оно считает? исполняет алгоритм и управляет?
А тем, что специальный софт разбивает алгоритм, написанный на Си подобном языке, на отдельные блоки:
массивы размещает в большие блоки памяти,
переменные разбивает на биты и размещает в отдельные аппаратные биты,
вычисления, даже такие простые как инкремент разбивает на сотни и тысячи логических функций, для сложных использует готовые аппаратные блоки.
И потом всё это соединяет вполне реальными физическими связями. И работает всё это на частотах в несколько сотен мегагерц.
По сути алгоритм превращается в реальную и очень комплексную электрическую схему. Это настолько низкоуровневое программирование, что даже "ниже" не только ассемблера, но и машинных кодов и чёрт побери перфокарт!
100-200 Мгц медленно? и зачем нужны такие заморочки? Если есть обычная малинка или одноплатные ПК х86 на которых винда крутится.
И нет, это не медленно и есть задачи, где не возможно обойтись без FPGA физически.
Первая фишка:
в том что это не проц, который исполняет алгоритм шаг за шагом. Это куча связанного "железа" которая исполняет весь алгоритм одновременно! Тотальное 100% распараллеливание алгоритма, даже если в нём несколько сотен тысяч строк кода!
Это даёт возможность такой магии, как сортировка массива за ноль тактов (например, в фильтре шума).
А ещё даёт возможность самому проектировать эмуляторы старых консолей и они будут работать в точности, нет, ТАК В ТАК, так-же как и их аппаратные дедушки, даже даёт возможность сэмулировать баги, и разные аппаратные нестабильности например в звуке чип-тюна ZX-Spectrum.
А ещё это и чудовищное быстродействие: делать расчёты на 66 Мгц быстрее чем Core i7 на 3700 МГц? запросто! Именно поэтому ASIC (некоторые их виды - FPGA с предзаказанными, не изменяемыми связями) так полюбились всеми майнерами.
Вторая принципиально непобедимая фишка:
время реакции - раз всё работает параллельно и можно реагировать с нереальной скоростью, в десятки а порой единицы наносекунд. Робототехника, автопрома и оружейка - без FPGA и ASIC (захардкоженный FPGA) никак.
Третья фишка:
можно реализовать любую периферию, любой интерфейс самому при помощи исходного кода, и если ты написал сам всё с нуля, включая интерфейсы, то это 100% переносимо, ну не мечта ли? Но с большими оговорками, и можно "отстрелить себе ногу", что я и сделал в интерфейсе камеры.
Модуль камеры:
Это плата модуля камеры: сверху чёрный цилиндр объектива, под ним чип сенсора который собственно и видит со всей логикой, который установлен на плате, два стабилизатора питания и разъём 40 контактный.
Характеристики этого модуля:
5 мегапикселей.
"Объектив" полное разочарование: мылит даже на VGA разрешении, света собирает мало, не настраивается фокус. Но для отладки пойдёт.
Чип сенсора выдаёт RAW формат как в профессиональных фотокамерах - в RGB придётся проявлять самому,
Интерфейс параллельный MIPI, он примитивный: каждый такт синхросигнала выдаёт 12 бит данных пикселя, с парой статусных сигналов "конец строки" и "конец кадра".
Для настройки юзает двух проводной последовательный I2C.
Коннектор - 40 пиновый, двухрядный с шагом 2.56мм, как в старых жестяках.
Казалось бы всё просто особенно для FPGA...
"Отстрел ноги"
Но чтоб достичь максимальной скорости надо выдать камере максимальную частоту в ~100Мгц (а с гармониками до гигагерца), от которой камера и тактируется, которая в свою очередь даёт ответный синхросигнал обратно в FPGA с сырыми данными изображения.
А это очень быстро, даже слишком быстро и было наивно с моей стороны надеется, что можно отдельными проводками соединить и ничего за это не будет...
Будет!
Во первых:
В стародавние времена, когда у жестяков был широченный ParallelATA 40 пиновый коннектор и такой-же шлейф, то этот 40 жильный шлейф работал только до частот 30-60МГц, а далее уже нужно было использовать особый магический 80 жильный шлейф с чередованием земель. И это не спроста: на таких частотах взаимные наводки очень сильно влияют и портят сигнал. Но в этой связке его использовать нельзя т.к. на основной FPGA плате нет такого же 40пинового разъёма, а негодяи из Xilinx ради маркетинга (ну и чтоб продавать только их доп платки по конской наценке) и несовместимости запилили 4 группы по 12 контактов в два ряда.
Во вторых:
Длинна ардуино-проводов разная да и на самой плате очень сильно различается длинна дорожек, а это критично на таких скоростях, и если даже не из за скорости света, то из за разной индуктивности - которая усиливает взимные наводки, разносит их по разным фазам ещё сильнее и превращает полезный сигнал в "кашу".
В третьих:
маркетологи посчитали что при помощи платы "всего" за 100 баксов нельзя давать заниматься серьёзными вещами. И поэтому два из четырёх 12 контактных коннекторов GPIO подключили через много килоомные резисторы тем самым зарезав частоту и "завалив форнты" (когда тактовая нарастает не слишком быстро чип камеры, из за шумов может не понять время переключение, это было одно или несколько).
Не делайте так! Не надо пытаться ардуино-проводками подключать такие быстрые (свыше 30 МГц и многобитные интерфейсы)
Попытки профиксить и прочие бесполезные трепыхания
1. Тактовая пикселей MIPI что выходит из камеры оказалась в разы шумнее: это тактовая из FPGA которая набрала по пути до камеры шумы, а потом вернулась из камеры в FPGA набрав ещё шумов на обратном пути. Пришлось затактироваться внутренней частотой внутри FPGA что генерится и выдаётся наружу и игнорировать синхронную с данными от камерами возвращающуюся обратно частоту самих данных.
Фейл: чип камеры при каждом старте настраивается чуток по разному и поэтому выходящая из него тактовая тоже на пару наносекунд то отстаёт то опережает.
Адский Костыль: Нужно вручную подстраивать каждый раз при каждом включении задержку.
2. Фейл: Взаимные шумы: так как лежит на первой картинке (плата связи рядом с платой камеры) не работает! В линке с ПК проскакивают лишние байты или он теряет байты.
Адский Костыль:
приходится буквально на пару сантиметров отгибать в сторону камеру вот так:
Чёртов бубновый шаманизм!
3. Мини Фейл: Ардуино проводки - они норовят отскачить при любом неосторожном движении любой платы! Это, просто, очень и очень не удобно, надо ОЧЕНЬ аккуратно всё двигать.
Костыль: расковырял иголкой разъём чтоб лучше держалось ... помогло мало но вроде помогло.
4. Связь с ПК при помощи модуля FTDI2232H оказалось не настолько крутой как её рекламировала фирма.
Фейл: скорость вместо 480 мегабит оказалась всего в 100 мегабит, т.к. внутри ФТДИхи два канала и они прибиты гвоздями, уже 240мегабит, USB не умеет в 100% пропускной, уже 200Мегабит, а чип не сразу видит такт записи а через пол дополнительного такта: вот тебе и 100 мегабит. Заморачиваться и собирать из двух каналов один не стал - драйвер фтди перемашивает рандомно пакеты и байты не говоря где начало пакета, а где конец.
5. Так-же производитель камеры обманул: вместо 150 фпс оказалось 128 фпс - только на такую скорость удалось настроить. Сам сенсор на такой скорости оказался очень тёмным, а чуствительность красного и синего канала настолько низкой что её пришлось домножать на х2 - х3 вместе с шумами и добавочно делать полноценное шумо-подавление.
Что дополнительно было разработано
Т.к. камера выдаёт сырой рав-поток как в проф камерах, то его надо обрабатывать как это делают тулзы цифровой проявки такие как Adobe Light room.
Для этого запилил на верилоге свой видеопроц:
в нём и MIPI приёмник, и свой i2c контроллер и такие страшные слова как:
- баланс белого,
- гамма-коррекция,
- коррекция дин. диапазона (после гаммы чёрный усиливается и становится серым - это надо фиксить),
- шумодав (где сортируется за 0 тактов в медианном фильтре),
- кроп и ресайз,
- усиление и коррекция цветов (синий и красный оказались очень слабыми).
схемка для пущего "устрашения" (to NN это выход в фтди, и спойлер темы будущей статьи ;):
Итог и что получилось сделать:
Оно заработало:
слева рендеринг на ПК при помощи OpenCV и С++ (на нём же писал и отлаживал RTL код для верилога и переносил как есть в верилог),
а справа отладочная консоль из FPGA в формате VT100 с цветами и свистелко-перделками (терминал с printf, текстом и преобразованием чисел в текст и пр. реализовано всё это аппаратно на FPGA при помощи той же логики и такой-то матери), да я люблю красиво, дорого и богато особенно в отладке.
Расшифровка видео:
В первую секунду видна первичная инициализация и пуск камеры с логом адресов и значений команд записи регистров настроек в камеру по I2C.
Далее я ручками, посылаю текстовые команды в FPGA (лексический интерпретатор команд тоже сам сделал, тоже на логике) и настраиваю яркость и чёртову фазу сигналов, видно что после подстройки фазы обильный "розовый снег" исчезает.
После я машу перед камерой древним смартом с настроечной таблицей цветов.
всплывшие косяки:
1. т.к. хоть камера и работает в режиме 128 фпс, но по скорости FTDI подвела и только 64 кадра в сек посылается в ПК, в среднем каждый второй кадр пропускается.
2. есть местами мусор в виде снега и цветных кластеров (показаны красными стрелочками)
3. сам модуль камеры на такой скорости оказалось полным разочарованием: мутная картинка, и шумов много т.к. ISO задран к небесам.
Использованные ресурсы чипа:
блочной BRAM памяти больше всего ушло на буфер для одного кадра.
Ушло примерно 200 часов моего времени на разработку, из них 150 на видео проц (raw --> rgb).
Вывод:
Не делайте так! Не надо пытаться ардуино-проводками подключать такие быстрые (свыше 30 МГц и многобитные интерфейсы). Именно поэтому профессионалы порой недолюбливают ардуинщиков за такие дикие сопли с ардуино-проводками.
А отладить камеру и ip-корку (аппаратная либа) видеопроца я всё-таки смог. Благо сам алгоритм разработал и верифицировал формально и математически, а на FPGA только проверил, что оно в принципе работает и понял что надо копать в сторону само синхронных синфазных LVDS гигабитных интерфейсов без тактовой и всего этого замороча с шумами.
На этом всё, вот в завершение фотка с топологией чипа (светлосиним заюзанные аппаратные ячейки), зачем? незнай, просто красивый город как из сим-сити вышел.
Как артист делал оптимальные лазерные лучи
Настало время оптимизации нашей иры-головоломки от первого лица. В посте будет много картинок, видео и НЕ БУДЕТ математики / программирования. Вся "математика" будет описана на пальцах, показаны только общие идеи. Итак, под оптимизацию попали лазерные лучи.
До этого в grayBox мы использовали юнитевский LineRendere.
Достоинства:
- берется из коробки
- гибкий, хорошо подходит для создания прототипа лазерного луча ну или чего вам заблагорассудится
Недостатки:
- работает неоптимально.
Неоптимальность незаметна на одном, 2-х и даже на десяти лучах. Но вот если у вас в игре лазер, который отражается от зеркал, делится на несколько лучей при прохождении через призму, имеет несколько цветов... то тут уже стоит прикинуть сколько +drawCalls накинут сверху только лучи. Ну, у нас могло набегать 4, 8 и даже 30 drawCalls.
Этот пост будет интересен, пожалуй, не программистам/разработчикам игр. Их этим не удивишь, а вот обычынм людям будет интересно посмотреть отдаленно на то, сколько усилий вбивается лишь для того, чтобы в игре были лазерные лучи.
До того как браться за луч, сделал наброски источника лазера и приемника. Свел их по дизайну между собой, ну и с другими элементами. Скетки источника лазера, надеюсь что-то будет понятно.
3/4, сбоку, вразрезе, чтобы моделлер лучше понял конструкцию:
Первые наброски:
Наброски приемника луча:
Работает в целом так: луч попадает в приемник и применик передает сигнал о том, что в него попали. На основе этого разворачивается одна из игровых механик.
Больше скетчей, если интересно, выкладываю сюда:
https://www.instagram.com/cgaleksey/
На https://vk.com/dronesgame пока ничего не выкладываю, но если добавятся больше 1.5 человека XD, то и туда начну скидывать.
По коду.
Почему не взял какой-то готовый плагин. Взял, результат не понравился. Пробовал Vectosity. Вот я, пишу несамый читабельный код. Но код мой и пишу так, что я могу его понять так как проект делаю для себя. А вот создатель Vectosity я бы сказал накрутил каких-то неральных сложностей. В его коде я так и не смог разобраться чтобы устранить баг, который мне мешал. Вот баг, тектсура как-то деформируется или хз что с ней:
Написал разработчику Vectosity чтобы узнать в чем проблема, когда исправит. С его слов это неисправимый косяк GPU. Короче нафиг-нафиг-нафиг... потом буду заикаться от него из-за того что будут вспоминать добрым словом.
Итак поехали. Что нужно:
- система рисования всех лучей на GPU за 1drawCall;
- возможность задавать разные текстуры и прочие параметры лучам.
Для решения этой задачи придется писать код не только на стороне процессора, но и на стороне GPU. Идея такая: рейкастим на пути луча все что видим, отражаем луч от предметов, которые отражаю. В итоге получаем набор координат. Этот набор координа - это начала и концы сегментов лазерного луча.
Этот набор параметров (array) мы подаем в шейдер при генерации меша на GPU.
Так же мы подаем на GPU набор параметров (тоже array): цвет, индек текстуры, толщина луча и всего чего вам еще вздумается.
И да, лучше чтобы эти параметры подавал какой-то менеджер. То есть в менеджер мы подаем какие лучи нарисовать, а он собирает данные и передает их на GPU.
Сам лазерный луч будем рисовать так:
1) на концах луч должен быть светлее так как это выглядит естественно. Используем grayscale-маск текстуру для этого;
2) переход от центра луча к перифирии (цвет и прозрачность) задаются grayscale-маской;
3) ну и добавим какой-нибудь шум, типа cloud и будем анимировать его, чтобы имитировать туман или движение воздуха.
И да, желательно склеить маски и все на свете в одну текстуру, не цари чтобы баиндами разбрасыватья.
Как по точкам на GPU нарисовать линию. Идея такая:
- в шейдере линия имеет вектор направления (начало-конец)
- есть доступ к позиции камеры.
Ну и все, делаем в шейдере сross(lineDir, camDir) и получаем направление вектора толщины линии. Передаем в шейдер параметром толщины и им можем регулировать толщину линии.
На словах все просто, на деле ушло много времени. Вот рисую линии на GPU по координатам:
Как видно, все ровненько и красиво и текстуру не колбасит как на предыдущем видео. И что там за проблемы с GPU у него были... Так можно отрисовать хз как много линий, зависит от того сколько вершин Unity разрешает использовать (если не ошибаюсь). Вроде 65к в последний раз было максималкой, а это куча линий, мне хватит :)
Версия сырого луча и приемника луча:
Это видео с грейбокс-тестов. Ну, бокс как видно, совсем не gray XD Еще здесь нет нормальной градиентной маски на луче. Луч сильно упрощен: (нет тумана, градиент подобран на скорую руку, концы луча не засветлены... короче, артист не занимался тогда еще этим)
Качество графики у нас не такое, на видосе часть прототипа с минимальной графикой и моделями, которые используются только в процессе разработки:
В итоге линия (лазерный луч) выглядит так. Здесь уже все:
- градиенты настроены
- туман пост-процессом наложен поверх полупрозрачного луча
- концы засветлены
- есть немного анимации тумана
- вся отрисовка на стороне GPU за 1 drawCall, красота :)
Надеюсь кому-то пост понравился и кто-то нашел что-то полезное для себя.
Еще раз ссылки на материалы по игре:
https://twitter.com/CGAleksey
https://www.instagram.com/cgaleksey/
Спасибо за внимание :)
Сотрудники НГТУ наладили выпуск учебно-производственного комплекса для печатного монтажа микросхем
Учебно-производственный комплекс «Инициатива» способен производить любое электронное оборудование, использующее технологию поверхностного монтажа. Комплекс может быть использован для прототипирования в различных отраслях, от бытовой электроники до космических аппаратов. Разработка способна обеспечить учебные заведения оборудованием, позволяющим студентам в течение нескольких часов создавать современные приборы для собственных научных проектов в телекоммуникациях, энергетике и других областях, вплоть до мобильных телефонов. Комплекс переводит производственный процесс с ручного монтажа на автоматизированный выпуск.
УПК состоит из автоматического установщика компонентов электронной схемы, трафаретного принтера и печи. Автоматический установщик используется для точного расположения микрокомпонентов на печатной плате, которая служит для соединения нескольких электронных деталей. Трафаретный принтер позволяет нанести на плату специальное вещество — паяльную пасту. Печь оплавляет пасту и тем самым соединяет электронные компоненты и печатную плату. Элементы комплекса «Инициатива» имеют планетарные названия. «Сатурн» — это сам станок, печь названа именем самой жаркой планеты – «Меркурий», «Феба» (спутник Сатурна) — это трафаретный принтер, необходимый станку для нанесения пасты.
По словам одного из разработчиков установки, доцента кафедры проектирования технологических машин НГТУ НЭТИ Алексея Александровича Цыгулина, набор оборудования УПК «Инициатива» позволит организовывать серийное, опытное и даже среднесерийное производство электроники.
«Сегодня, если студент придумал электронное устройство, он должен потратить несколько дней на его ручную сборку либо он должен найти где-то деньги на прототипирование и найти комплекс, подобный нашему, а он есть даже не в любом городе. Конечно, такие условия отбивают всякое стремление к инженерному творчеству и предпринимательству. Ведь, если студент в чем-то ошибся, ему надо еще раз вручную сделать новую деталь, а это еще несколько дней. Не у каждого есть столько времени и терпения. Наш комплекс позволяет делать деталь за несколько часов и с высоким качеством, аппарат исключает ошибки. За счет невысокой цены комплекс может позволить себе почти любой университет или колледж, что позволит сделать технологическое предпринимательство студентов в России доступным и массовым, в разы увеличив количество разработок. Кроме того, университеты и колледжи могут принимать заказы на прототипирование от предприятий своего города», — прокомментировал разработчик.
Важное преимущество УПК — специально разработанное программное обеспечение. ПО позволяет быстро настраивать станок на новую плату, быстро перенастраивать с одной на другую, принимать все доступные файлы из инженерных программ по разработке печатных плат и работать с любыми известными компонентами.
УПК «Инициатива» был полностью — от механических частей и электроники до программного обеспечения — создан выпускниками НГТУ НЭТИ. Индустриальными партнерами являются заводы, изготавливающие металлические и пластиковые элементы.
«Это уже работающий механизм. Мы сами используем это оборудование и достаточно много наработали на этом виде станка: более миллиона компонентов поставлено. Это некий рубеж, который мы перешли», — заявляют создатели комплекса.
https://www.nstu.ru/
Много всего интересного в нашей группе Вконтакте!