cnc-club.ru

Похоже на следы от ракеля, которым маску наносят.

не, похоже это какая-то плавающая ошибка в ременном приводе на оси z. я ту картинку сканировал зигзагом - снизу вверх, шаг вправо, сверху вниз, шаг вправо и т.д. поменял направления - вертикальные полосы пропали, появились горизонтальные. но почему-то не в точности такие же. опять загадка но что-то я отвлекся... https://youtu.be/AVbiUh-vBU8

Сталкивался с похожим эффектом.
Если ШВП имеет биение, то ось может колебаться с шагом ШВП. На не жестких станках хорошо заметно.

Дык в том то и дело что у него "хребты" остаются неизменными при разном положении швп... Винт у него вдоль хребтов стоит... а поперек ось на ремне бегает...
А если сдвинуть плату буквально на пару-тройку мм - хребты там же останутся ? или уедут ??
Как вариант - концевую меру обмерять - будет ясно откуда ноги растут - механика или реальный рельеф...

Hanter писал(а):Как вариант - концевую меру обмерять

Или зеркало хотя бы, если КМД под рукой нет.

положил на плату предметное стекло, просканировал квадрат 15х15 с шагом 0.1, так же вертикальным зигзагом. почти уверен что это ремень. видно "высокочастотный" шум амплитудой примерно сотку и еще сотка "низкочастотного", который и дает эти полосы. макрорельеф на картинке, я думаю, из-за неплотного прилегания стекла к кривой плате с локальными неровностями. в общем, я выяснил для себя порядок величин неопределенности. этого, имхо, достаточно - ничего улучшать не буду...

первый блин
не вовремя перестал крутиться шаговик на правой головке. пока не понял - софт или железо
повыпрыгивали резисторы из одной ленты
не дотестировал зрение - некоторые детальки не распознались

https://youtu.be/kfpkvUIJ3UU

и второй блин. уже лучше, разложил до конца. но
- не прилип и перевернулся один резистор 1210
- 3 кондера все таки не распознались
- надо че-то делать с шаговиками/зрением. угловая точность отвратительная. сейчас DRV8825 с перемычками для какого-то-там-дикей. попробую другие драйверы. можно определять по камере угол, поворачивать, снова проверять, поворачивать и т.д. так сейчас центрируется TQFP144. но это слишком долго. видео с камеры с жуткой задержкой. надо попробовать переключить камеру с MJPG на YUV - вдруг уменьшится... вообще, очень хочется че-нить не USB. свою камеру чтоль спаять...
- ускорения сильно зажал - полка все равно трясется. надо сварить пару монструозных кронштейнов и [удалено] ее уже намертво к стене...
https://youtu.be/v-mSEl6G7rg

merkwurdigliebe писал(а):надо попробовать переключить камеру с MJPG на YUV - вдруг уменьшится...

Не уменьшится, я уже проверял разные варианты. Всё дело в USB, 2 или 3 - не важно. Заметно лучше будет RTSP, но не у всяких камер. Ещё лучше Firewire (могу подогнать парочку S-Video конверторв, если найду где лежат ). Ну и совсем хорошо PCI карта захвата, на несколько камер надо брать с соотв. суммарной кадровой скоростью.

merkwurdigliebe писал(а):...видео с камеры с жуткой задержкой. надо попробовать переключить камеру с MJPG на YUV - вдруг уменьшится...

Это уже проходили: в OpenCV задана последовательность определения режимов вебкамеры, она включается в первом подходящем: MJPG - самый последний, поэтому шансы, что используется именно он, довольно малы.
У меня в вебкамере при одинаковом разрешении в режиме MJPG выдается 30 кадров/сек, а в YUY2 - только 10.
Выход из этой ситуации найден один: поменять последовательность MEDIASUBTYPE (MEDIASUBTYPE_MJPG поднять выше MEDIASUBTYPE_YUY2) и перекомпилировать библиотеки.
USB (2,3) интерфейс тут, imho, ни при чем: его пропускной способности вполне достаточно для работы с одним видеопотоком.

IP камеры в OPenCV имеют другую проблему - часть кадра бывает размазана. Эта проблема известна давно, но не решается.

merkwurdigliebe писал(а):... угловая точность отвратительная...

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

merkwurdigliebe писал(а):... можно определять по камере угол, поворачивать, снова проверять, поворачивать и т.д. так сейчас центрируется TQFP144. но это слишком долго...

Это правильный алгоритм. Если почитать интеловские доки к OpenCV 1.0, то в них алгоритм - определение центра и угла поворота - выполняется в несколько итераций, после каждой коррекции положения/угла, пока не будет достигнута заданная точность.

merkwurdigliebe писал(а):DRV8825 с перемычками для какого-то-там-дикей

Попробуй TMC2100. Сильно лучше по качеству работы. Сам пользую, правда 8825 не пробовал, был A4988, тот вообще кака. Но 8825 вроде примерно похож... Жутко не одинаковые шаги у них, причем зависит от напряжения питания и индуктивности обмоток. С TMC2100 так же не все гладко, но лучше.

Читаю не первую тему по раскладчикам (облизываюсь...) и в каждой натыкаюсь на решение проблемы со скоростью работы камер.
Народ, не подскажете, в "идеальном" мире какая должна быть архитектура системы, чтобы решить вопрос и с кол-вом камер (их вечно всем не хватает) и со скоростью работы этих камер?

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

И второй момент:

N1X писал(а):С TMC2100 так же не все гладко, но лучше.

можно поподробнее о "не гладких" моментах? Ссылки приветствуются

Nonstopich писал(а):можно поподробнее о "не гладких" моментах? Ссылки приветствуются

Ссылок не будет, потому как это личный опыт. У меня стол на установке лазерной засветки ремнем приводится, а шаг растра там нужен небольшой и довольно четкий. Проблема вылазила как раз в том, что внутри одного электрического периода тока на двигатель шаги нифига не одинаковые. Т.е. он может шагать по 3-4 сотки, а потом влупить больше десятки сразу. Есть корявенькая осциллограмма тока в двигателе, флешка оказалась где-то там, поэтому снято было на телефон, чтобы не морочиться. Видно что в одной фазе ток ровный, а в другой со всплеском и асимметрией. Причем фазы менял, дело не в движке, а именно в драйвере. Предположение - особенности сборки платы драйвера китайцами. Возможно взаимное влияние фаз из-за кривого монтажа. Я просто добавил в проблемную фазу небольшой дроссель и сигнал стал более менее ровный. Но смысл от этого не меняется. Платка не "поставил-забыл", а как повезет в конкретных условиях. Но на общем уровне вещь стоящая, даже при возможных грабельках. Если брать микруху и собирать грамотно результат может быть более предсказуемый. Но этот вариант не для всех, естественно. Хотя я думаю автору темы это не проблема )
Ну и штыри на гребенке, отвечающие за конфигурацию у китайцев отпаяны технологическими мостиками. Т.е. хочешь переключения режимов - запаивай мосты на плате иначе на изменение состояния входных штырей драйверу побоку. Но это чисто технический момент, информация доступна.

Nonstopich писал(а):Читаю не первую тему по раскладчикам (облизываюсь...) и в каждой натыкаюсь на решение проблемы со скоростью работы камер.

Imho, "проблема скорости камер" преувеличена.
1. Оптимизацию следует начинать не с борьбы за fps, а c сокращения пустых переездов: от питателя к камере и от камеры к месту установки. Если камеру разместить между питателями и платой, пустые перемещения существенно сократятся.
2. По поводу fps. Пусть частота кадров 10 кадров/с, тогда в самом неудачном случае нам понадобился снимок, когда камера только что его выдала и нужно ждать 100 мс до следующего. Долго? Посмотрите на видео: сколько времени над камерой находится здоровенный Spartan? 2-3 секунды, т.е. 20 -30 кадров. Если все делать правильно, то после первого кадра вычисляюется смещение, поворот и микросхема двигается и поворачивается над камерой, потом снова захват и коррекция и т.д. Думаю, на эти мелкие движения уходит гораздо больше времени, чем на захват кадров и вычисления: послать команду контроллеру, дождаться подтверждения выполнения перемещения на самой малой скорости. Так что не думаю, что переход с 10 на 30 fps заметно ускорит процесс выравнивания Spartan-a.
3. Избегать избыточного разрешения кадра: для Spartan-a необходимо высокое разрешение, скажем 2592х1944, но такое разрешение совершенно не нужно для R, C и т .п., для них достаточно 640х480 или около того, и коррекцию положения можно считать/делать только по одному снимку - при пайке выровняет. А время работы алгоритма коррекции при небольшом размере кадра существенно сократится.
4. Для любительской упрощенной конструкции, как у ТС, все эти ухищрения, imho, вообще не особенно актуальны: питатели не автоматические и их зарядка будет занимать гораздо больше времени, чем будет потеряно на невысоком fps камер и неоптимальных перемещениях.

Так что, в данном случае не нужно ничего особенного городить с камерами. И даже две камеры (верхняя и нижняя) не будут мешать друг другу - они ведь не работают одновременно, всегда используется только одна.

Если, все же, обработка кадра занимает много времени (навороченный алгоритм, большой размер кадра), значит нужно от интерпретатора (python - как у ТС, java - как в OpenPnP) переходить к компилятору или, хотя бы, взять комп пошустрее.

bolek4321 писал(а):У меня в вебкамере при одинаковом разрешении в режиме MJPG выдается 30 кадров/сек, а в YUY2 - только 10.

Тут дело не в количестве кадров (в принципе достаточно и одного кадра), а в задержке доставки каждого кадра от камеры до анализатора.

https://youtu.be/iJe6Znqkc04

UAVpilot писал(а):а в задержке доставки каждого кадра от камеры до анализатора.

Там чуть ли не секунда на видео, как такой ад получается ?

кодирование, передача, декодирование...
Идеальные в этом плане аналоговые камеры с платами видеозахвата (PCI) - там каждый пиксель (вернее каждая строка) сразу может оказываться в памяти компа.

P.S. Все знают, что нынче нельзя сверять свои часы по часам на экране телевизора?..

UAVpilot писал(а):P.S. Все знают, что нынче нельзя сверять свои часы по часам на экране телевизора?..

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

А вот что камеры до сих пор такие тормозные странно. На первых вариантах фотоаппаратов были подобные проблемы, но вроде бы были довольно быстро решены и там это все в производительность вроде бы упиралось. Вероятно недорогие камеры не могут нормально кодировать...
А нет ли для них режима минимального сжатия ? Чтобы использовать их почти как аналоговые. (т.е. получать на выходе цифру но без постобработки)

Есть камеры, которые гонят сырой поток данных. Но это высокоскоростная шина нужна, явно не вебка