Александр Петров

Отсутствуют как вид.
Из умеренно адекватных есть FreeCAD, но о десятках тысяч деталей и речи быть не может, потому что это явно промышленный уровень, который коммерческий, а значит можно содрать денег.
Потом, такие САПР обязаны иметь встроенную PDM хоть какого-то качества, иначе вы сами засыплетесь и запутаетесь раньше, даже если железо потянет такие дела на непонятно каком ядре. Open-source ядра банально не заточены под большие объёмы геометрии. Потому что, очевидно, для написания такого класса ПО нужна целая инфраструктура от грамотных специалистов до банального сотрудничества с венторами рабочих станций и комплектующий - на коленке не напишешь.Ага, драйвера для Solidworks разрабатываются совместно с DS, Open-source CADы не может себе такого позволить. Такой инфраструктурой обладает, например Siemens.. =) Т.е. всё что юзабельное (реально юзабельное промышленно) стоит денег. Остальное баловство или мучения, как больше нравится.

Из адекватных вариантов - покупка Компас. По текущим ценам - тысяч 200 за 3D + График и библиотеки крепежа и материалы. Вполне оправданно, учитывая что рабочая станция для таких сборок стоит ничуть не меньше. Стабильность и удобство работы не обещаю, но это реальный рабочий вариант за минимум денег. Несмотря на свои детские болячки Компас вполне работоспособен, можно даже реально вести промышленное производство + ЕСКД "из коробки".

Несколько раз прорабатывал варианты о внедрении фришного ПО на машиностроительных предприятиях разного размера и качества, но порог в 5-7к деталей даже не переходило. Доходило до идеи запустить Linux и воткнуть на него фришную САПР под него.. Я вам обещаю - это кошмар. Неработоспособный кошмар и очень дорогой по итогу - экономии на ПО там и не пахнет, она только только покрывает затраты на проектирование, если это частник, который не может себе позволить сидеть и чертить какую-нибудь гидромуфту месяц стараниями отдела техников.

Не..а вообще всегда есть кульман. Даже можно бесплатно их найти уже. То же самое будет, если на стоимость ПО нанять 3-4 человека старой закалки из КБ. Не вполне адекватно, но если совсем приперли к стенке по поводу лицензирования, то вполне законно.

А что думает его родной диагностический софт? Проверку всё проходит по железу?

Ну и есть там некоторая тонкость с драйверами на N-vidia, конечно. Надо искать сертифицированные, если они есть на эту карту, либо подбирать самый подходящий методом тыка.
Ставил я как-то на Quadro K620 (i5 6400, 16Gb DDR4) бета-драйвер с официального сайта N-vidia и словил сумасшедшие фризы, неработоспособный RealView и всякие глюки. Залез в раздел сертифицированных дров, откатил на них (они всегда на несколько версий ниже) и всё нормально стало.

             Спроектировать - в любой. Смоделировать до уровня работы упругого элемента - любая "средняя" и выше САПР, НО это будет фактически визуализация, т.е. вы сами всё считаете, просчитываете кинематику, пусть и с помощью некоторых встроенных инструментов, а потом строите анимацию по своим расчетам. Так, чтобы нарисовать, задать упругий элемент и менять её жесткость(сечение, материал) и чтобы крутилось всё "само" - это, к сожалению, нереально. В любом случае половину должен сделать проектировщик. САПР только покажет визуально и облегчит некоторые муторные моменты вроде расчета на усталостную прочность, напряжения и деформации.
             Реален и доступен вариант задания параметрической модели: задаём траекторию для построения в виде спирали с переменным параметром (диаметр внешний(внутренний)/число витков/шаг/направление) и привязываем к исходной точке. Тогда в модели можно будет менять переменную, которая поменяет форму спирали. Аналогичные действия с любыми кривыми заданными через уравнения. Поведение всяких цепей и тросов вполне успешно описываются уравнениями, поэтому в расчётах всегда берется упрощение по необходимому параметру. Один раз считаем на разрыв, либо задаем как стержень с шарнирным закреплением с двух сторон, а потом это просто виртуальная кривая заданной длины, чтобы тела не плодить без надобности.
          
             Вопрос моделирования намотки чего-либо (в основном кабеля, троса, цепи) неоднократно поднимался на всех тематических форумах - простого решения из коробки я так и не встретил. В конечном итоге все приходят к идее, что оно вообще не требуется, потому что с реальностью оно не стыкуется потом, а длину спирали по количеству витков и диаметру можно и так посчитать на пальцах. Остаётся только визуализация работы, которую успешно спихивают в отдел маркетинга, где в 3Ds или Blender дизайнер рисует работу этого всего "на глазок", чтобы просто выглядело как рабочее.

             Конкретно по САПР..ну правда любая. Даже Компас умеет параметрическое моделирование. Другое дело реализация - замучаетесь мануалы курить. Поэтому попсово и простенько - SolidWorks + Simulation + Motion из его же комплекта. Сопряжения типа "цепная/ременная передача" реализовано в 2015 точно. И вообще всяких плюшек по сопряжениям в SW хватает с головой - полный комплект кинематических пар (винт-гайка, кулачек, редуктор, кулиса и т.д.).
             Хардкорнее - T-Flex или PTC Creo (бывший ProE). Считается, что вот T-Flex во многом лучше всего для гибких элементов и подобного рода параметрических задач - лично не заметил, всё то же самое можно сделать в любой другой САПР - вопрос только в степени владения оной и понимания что делаешь.

Для этой задачи есть CAM-системы. Это такой зверь в который загоняется 3D-модель, настраивается система координат и строится технологический процесс. С допусками на обработку,, оптимизацией траектории инструмента, корректировками, указанием смены инструмента и т.д.
Но есть нюанс. Нюанс называется связка "станок+стойка", в рамках CAM имеющая вид конкретного препроцессора под конкретную стойку и типа станка - 4 оси бывают разные. Есть т.н. 3.5, которые тоже 4, да не очень. В частности поворотный стол на некоторых умеет крутиться только на 180, а не на 360, в итоге команда на поворот более 180 выдаст ошибку на железе, хотя симуляция отработала. Иными словами G-код для одной стойки может быть весьма непохож на код для другой стойки, особенно по части понятий стойки относительно положения осей. В своё время я плотно работал со SprutCAM, поскольку там были мои стойки и типы станков и модельки любой сложности корректно перелопачивались в код, который успешно отрабатывался стойкой.
Но систем гораздо больше. Можете ознакомиться с рынком, обычно в доках есть модели стоек и станков.

А вот по вопросу исходной модели.. ну CAD-файлы тот же Sprut ест любые. Кормил его sldprt, iges, step, m3d.. чем только не кормил, но насчет C4D ничего не скажу. "Не по феншую" оно точно, но экспорт в iges и stl там есть.

Так же многие CAM-системы, вроде MasterCAM или SurfCAM любят (во всяком случае могут) работать с облаком точек и даже парочка плотно связана с Rhino. Соответственно перегнать что-то из C4D в нужный формат не проблема. Вопрос требований точности. Импорт-Экспортные операции им явно не на пользу. Именно поэтому расчётный софт по гребным винтам часто даёт набор координат по которой CAM уже сама строит поверхность. Так нет проблем с кривизной поверхностей, переброшенных 10 раз из формата в формат.

Беговые дорожки с фиксаторами для этого уже есть и давно. С месяц назад читал статью про целую установку, где игрок одевается в своеобразный корсет, который в свою очередь цепляется к кронштейну, превращаясь в своеобразный игровой экзоскелет. Ногами можно шкрябать по поверхности, кронштейн будет держать и считывать повороты и развороты. Ну и свистелку в руку, конечно. Это компактно, это относительно копейки и это очень может быть японцы. =) Но главное - это изящно. Вращение огромного шара с хомяком внутри это избыточная поверхность. Это технически проигрышное решение - износ поверхности, изменения кривизны, много оборотов на датчиках (а значит выработка их ресурса), большая масса, сложность изготовления ровного шара (а иначе вибрация при движении, сбои датчиков, шум...) и стоимость. Это всё причины по которым такой вещи всё ещё нет в серийном виде...да и не в серийном только если народными умельцами от переизбыта
Далее, это всё уже изобретено. Лет эдак 5 назад, не меньше, читал про стенд-симулятор автомобиля, кажется собранный BMW или Audi. Это такой ангар, там трёхосевая станина и кабина, которая движением по направляющим имитирует движение автомобиля. Делали они это в рекламных целях, в порыве "а мы так можем". Очень круто, баснословно дорого, никто не пользуется теперь, ибо за глаза стационарных, которые только вибрируют и наклоняются. Аналогичная штука, но для симуляторов полета, теперь у немцев, собрана в MPI как побочный проект. Тоже носит игрока по всем углам комнаты без проблем, так же никому не нужна, кроме как для опытов.

А для остального, я открою тайну - Nintendo Wii или уже помирающие, но пока дышашие PS Move и MS Kinect. И вот глядя на то как гиганты с их многомиллионными продажами консолей и прочего добра, маркетинговыми отделами и взводом пиарщиков, не смогли убедить пользователей в крутости идеи, я лично пришел к выводу, что оно не надо никому от слова совсем. Кроме Wii. У неё есть фанаты попрыгать в теннис дома перед телевизором, но, прошу заметить, фанаты так же немногочисленные.

В России игровые платформы.. нет, вы что.. мы все дядьки серьёзные, умеем хорошо делать только то, что умеет хорошо убивать людей. Игровые у нас есть только инди-разработчики, которые, очевидно к такому не готовы.

А о какой точности идет речь? Десятки, сотки?

Я вижу два варианта конструкции, если говорить о многофункциональных машинах: обычный промышленный робот-манипулятор и трехосевая линейная система (с опциональной четвертой или пятой ось, уже вращательной). Второй вариант так же может быть реализован навыворот - трёхосевой стол, по аналогии с любым фрезерным станком.

А теперь самое интересное - изготовление в РФ. Ну..у нас можно сделать несущую раму, корпусные детали, кожуха. Будет долго, дорого и не сказать что третье, но реально. Если единичное или мелкосерийное, то подешевле. Однако самое важное - мозги и приводы придётся покупать за границей. Причём всё это будет ещё круче стоить (стоимость малогабаритных прецизионных приводов можно посмотреть - на карманные расходы не похоже). И от конструкции не зависит - есть приводы и вращательные и линейные. Доступность ограничена только вашими возможностями по торговле с той или иной компанией (некоторые с физ.лицами вообще не работают). Тут никак не получится сэкономить на конструкции. Приводы должны быть малогабаритными и точными. Вариант сгладить это дело хитрой передачей с муфтами и безумной коробкой передач, которая на точном позиционировании будет иметь сумасшедшее передаточное число, не стоит. Во-первых создание такого узла влетит в солидную сумму: надо найти конструктора, который придумает его малогабаритным, заплатить ему денег. Потом надо найти где сделать (а это серьёзно, это в гараже не сделают) и тоже заплатить им денег. И будет у вас уникальная КП с компонентами, которые нереально купить, если что-то сломалось, а занимать оно будет много места и весить тоже. Поэтому, единогласно - готовый привод позволительной точности.

Ну и не забываем о ПО, конечно. Прошивка для робота-манипулятора это задачка не из простых..от слова совсем. Там действительно серьёзная система управления, требующая хороших практических знаний в мехатронике. Нужно либо сообразительную команду разработчиков, либо уметь хорошо объяснять задачи и делегировать их.

Иными словами: Спроектировать и изготовить в РФ можно, с использованием некоторых покупных зарубежных узлов. Сложность напрямую связана во-первых с вашим кошельком (наличием хорошего инвестора) и во-вторых, но не менее важно - по какую часть тела вы погружены в отрасль. Есть ли у вас поставщики приводов, есть ли конструктора ,есть ли у вас контакты на производстве, есть ли программисты этого всего? И если чего-то нет, знаете ли где их взять?

1. Разумеется зависит от того что вы там напроектируете или уже напроектировали. Железо, метод индикации и сама разводка. Потребление вы можете примерно посчитать по тому что у вас будет использовано, собственно.
Если ничего не использовано, то давайте посмотрим статистику по готовым контроллерам и не будем далеко ходить, возьмем попсовую, но работоспособную Arduino и увидим, что у Mini Pro и Nano потребление где-то в пределах 100мW (токи порядка 20мА).. ну т.е. почти ничего и к такому же результату стоит стремиться (полистав схемки и спецификации по Freeduino, например). Так вот семисегментный индикатор у вас кушать будет, пожалуй, даже больше, чем сам контроллер. Есть мысль заменить его на ЖК с опциональной подсветкой в темное время суток. Причем подстветку можно заранее же привязать к часам. Фоторезистор тоже можно привязать к часам, чтобы он днем не "пялился" на свет просто так. Тогда и ночью, если вокруг горит свет, подсветка не включиться, а включиться в темноте. Тут опять можно воткнуть хитрость и поставить датчик звука, который включит подсветку только если темно и вы просите об этом, создавая шум (нечего ей гореть в темноте, если никому не надо). Включение же самого датчика так же завязать на время - ночью пусть слушает, днём не надо.
Ну и конечно есть же такая штука: https://openhomeautomation.net/arduino-battery/
Но вообще рекомендую от семисегментных и просто светодиодных индикаторов бежать. Просто с точки зрения логики - сколько раз вы смотрите на часы в день? Ну 5..ну 7 раз. А горят они постоянно и жруть энергию, фактически в пустую. Значит..вам надо придумать как вам будет удобно их высвечивать по необходимости. Тот же e-ink, который будет менять цифры только по требованию - вполне неплохо.

2. Ещё одна иная мысль. Долой корпуса - зашейте в стену, стол или дверной косяк. Любые внешние корпуса тесно связаны с вашими технологическими возможностями по части обработки резанием. Если у вас нет доступа к токарно-фрезерной обработке за копейку (не говоря уже о литье тонкостенных корпусов), то мучатся надо с тем что есть под рукой. Осмотрите полки на предмет маленьких коробочек. А потом уже привязывайтесь к ней.
Как вариант хорошего подхода к всё таки выносному корпусу - кусок алюминиевой трубы D30-35, тонкостенной. Внутри пластиковый ложемент для платы (которую, конечно, надо сразу проектировать под габарит), сделанную из подручного хлама типа кусков от принтера, а то и просто на монтажный пластик посадить. Индикатор вывести на цилиндрическую поверхность. Окно сделать можно дрелью и напильником. Ну.. если очень быстро эскизировать, то так:

Разъёмы и кнопки вывести либо назад, либо на торец. Снизу резиновую нашлепку на клею, чтобы не каталась и hi-tech во всей красе. Если не лень, то можно трубу из нержавейки - блестит лучше.. но сверлить вам её не понравиться.
Считать тут нечего особо. Тепловыделение тут никакое.. только габариты платы..которые берутся при проектировании и разводке. И отверстия крепежные на плате тоже ставятся заодно, где осталось место. А можно и без них, собственно.
Поэтому разводить плату и думать о корпусе надо параллельно и одновременно. Развели плату - не влезает: думаем как впихнуть и как будет проще - развести иначе или изменить корпус. Это всё вопросы к проектанту в процессе создания устройства, т.е. к вам в ближайшем будущем. Отработайте состав по компонентам на макетке, отработайте дизайн корпуса на бумаге.. а потом соедините вместе подпиливая то там, то там.

3. А вот тут есть сложности. Ну т.е. разрабатывать и разводить плату вы можете где удобно и где умеете. Мне вот удобен OrCAD с институтских времен. Я не занимаюсь этим, но если мне понадобиться что-то спроектировать по цепям и развести, то я возьму его. Просто потому что я с ним знаком. А вот с заказом сложно. Единичная и мелкая это в копейку влетит, если даже где-то в вашем городе это делают. Т.е. тут у вас выбор есть - взять готовый контроллер типа Pro Mini и не мудрить с платами, а заняться ПО, либо пытаться творить самому в целях овладеть "магией", либо искать частника. В последнем случае можно ломануться на форумы электронщиков и спрашивать в подходящих ветках кто может. При себе иметь достаточное представление о том что надо (габарит, ширина дорожек, метод монтажа), а в идеале готовую модель.

Дополненная или виртуальная? (дополненная это GoogleGlass и аналоги, покемоны эти несчастные, а VR - виртуальная (Virtual Reality). Не так чтобы было много отличий, но они есть. Хотя бы потому, что с проекциями поверх зрения у человечества пока технологии ещё детскими болезнями тяготятся.

А по функционалу.. Да просто всё, в целом. На валенок похоже. Нужно два экрана маленького размера и большого разрешения, трёхосный акселерометр (в идеале дополненный гироскопом), простенький контроллер и драйвер, который переведет смещения акселерометра в смещение поля зрения в виртуальном мире. А реакция на смещения вопрос уже к ПО.

Сложность опциональная. Есть картонные держатели, позволяющие сделать из смартфона очки виртуальной реальности. Т.е. сложность равна сложности смартфона в таком случае (там есть экран, акселерометр, процессор и драйвер). При желании можно паять своё, благо на рынке хватает готовых модулей с трехосными датчиками навигации (можно ведь туда и компас настоящий воткнуть).
Почему тогда есть Oculus, Vive и Ко? Ну во-первых ради денег, конечно. Простая и понятная аппаратная база, максимум ПО, стоимость разработки которого оценить очень сложно. Но, несмотря на это, ряд важных вопросов они всё же решают. Ну первое что приходит на ум - экран. Он обязан иметь максимально маленький размер пикселя, потому что глаз находится очень близко и зерно видно прекрасно. У Vive экран для одного глаза имеет разрешение 1080x1200.. и это в таком то размере! Производство таких вещей ещё надо организовать, а потом поставить так, чтобы глаза не разбегались.
Если проще, то вся сложность чисто инженерная - правильно и компактно скомпоновать это всё в шлем, чтобы он весил мало и не мешался. Ну и кусочек, связанный с опытными испытаниями, чтобы девайс корректно считывал своё положение, перемещение и понимал входящий сигнал. Это всё уже ПО-шные вопросы, но требующие решения.

Российского производства.. а зачем? Кому оно надо? Кто это купит? Аппаратная простота это она в мире простота, а у нас ничего из перечисленного нет. Тот кто возьмется за разработку будет вынужден покупать экраны, покупать контроллеры, покупать датчики..и покупать ПО для написания ПО. А потом ещё всё это как-то собирать. Получится золотое устройство в два, а то и в три раза дороже самого последнего Oculus Rift с уже готовым SDK и серьёзно развернутой компанией, которая не прекратит работу вот уже завтра, потому что деньги кончились.. И это при условии, что можно взять китайский смартфон за 15к, поставить его в картонный держатель, вырезанный из старой коробки от телевизора и сидеть смотреть порнографию котиков в виртуальном мире.
Теперь уже и зарубежных особо не появится. Вся фишка Oculus Rift была в том, что они были первые, кто выпустил массовый прототип. А потом подтянулись остальные. Gear неплохо ломанулся в игровую зону с расчетом на SteamVR. Производителей этих шлемов так мало, не потому что сложно, а потому что никому не надо, особенно за такие деньги. После появления вышеописанных картонных коробочек, выход на рынок с самостоятельным девайсом почти нереален, если вы не гигант типа Valve, которая знает куда эти очки прикрутить.

Читать всё про инерциальную навигацию в пространстве, контроллеры и видеотракты. Дополнительно стоит почитать биологию и анатомию по части зрения и восприятия, чтобы определиться с оптимальными параметрами. Ну и по эргономике хоть что-нибудь минимально, чтобы не получился кирпич на веревочках. Естественно, всё это повязано через ПО, поэтому параллельно читайте программирование всего это (инерциальная навигация требует не только понимания её самой, но и методов обработки в цифре)

Спрашивать форумы, статьи, тот же хабр. Не привязывайтесь жестко что это именно VR. Любой квадрокоптер использует абсолютно то же самое, только иначе. Даже где-то была статья, где мужик себе акселерометр прицепил на резинке к голове и управлял камерой в игре. Сделано на коленке, но полностью показывает сложность системы.

Вы уж извините, но специалисты этим не занимаются. Это хобби для гика. Любой вменяемый инженер-"мехатронщик" сделает такое не выходя из дома. Разве что экраны забрать у доставки, если на полке с хламом нет подходящих. Просто ставиться вопрос контента и идея собрать такое сразу пропадает. Контента нет. Т.е. есть демонстрационные ролики, какие-то небольшие софтинки. Всё очень скудно и не интересно, поиграться, разобрать на части и сделать что-то полезнее. Оказалось, что просто так взять готовую игру, например, созданную под плоский экран и просто показать на два глаза не катит. Надо смещать изображение на угол обзора, обеспечивающий бинокулярное зрение, а это не так просто сделать с готовым продуктом - получается похабно.
Поэтому сейчас все наборы этих шлемов идут фактически как "набор для разработчика"... разработчика приложений, разумеется. Потому что нужен рынок приложений, а их нет и писать хотят далеко не все. Вот тут сложности появились. Сложности с платформами, сложности с графикой, движками и ещё вагоном непоняток, которые никто пока не отрабатывал серьёзно.

А касательно всё таки дополненной, то всё то же самое, только проецировать сложно..а точнее некуда. Конечно, буквально неделю назад появилась статейка на GT, где из советского калькулятора сделали "аналог" GoogleGlass, но до серии там далеко, хоть и интересно. =)

Отвечаю на свой вопрос:
Разрешение указано для каждого вывода отдельно.
Два монитора 1920x1080 корректно подключились: один на DP, второй на DVI.