roboforum.ru

При подаче питания у меня сервы дергаются, причем импульс достаточно длительный, манипулятор приседает и бьет себе по мозгам Как бороться ?

Хороший вопрос, у меня сейчас так же паук норовит пальцы прищемить, когда я его включаю
Пока ответа нет, думаю

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

- запоминать положения перед выключением и при включении отправлять эти положения
- перед выключением перемещать сервы в определённое положение, которое будет удобно при включении или в отключенном состоянии

Да хотя бы причину понять бы. Вроде БП хороший, импульсов быть не должно, чтобы они при старте во всех цепях помехи навели. Или, быть может, я ошибаюсь. Но сервы после дергания становятся на холостой ход, значит отсутствие ШИМ-сигнала не воспринимается сервой как левое (правое) положение.

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

это происходит еще до выдачи управления на сервы. это чисто электротехнический побочный эффект

тогда понятия не имею, что у вас твориться. а без этого никак. у меня сервы тоже немного дёргаются, но это 1, ну максимум 2-3 пара градуса. это sg90, на которых я сейчас в основном ставлю эксперементы. mg995 вообще еле-еле дёргаются, достаточно, чтоб считать, что они не дёргаются при подаче питания

кондеры помогли, погрешность положения серв теперь в пределах погрешности измерения
также я поставил SRAM, и теперь захватываю кадр целиком в нее, и разом отправляю на комп. получается цельный кадр (динамическую сцену теперь можно лицезреть), и мнгновенно передается
насчет отладки на компе... даже не знаю насчет QT, время поджимает, придется, наверно, на борланд билдере писать. а еще меня посетила такая идея, что удобнее было бы оттачивать трекинг не на подготовленных фотках, а прямо сразу живое видео принимать по уарту (конечно, fps будет по приблизительным оценкам не более 2), и на нем же визуализировать трекинг. в билдере канвас тормозной, по своему опыту знаю, что попиксельная отрисовка на нем изображения приводит к 100% загрузке проца и комп жутко тормозит. не знаю, как это дело обстоит в QT, так что как бы с DirectShow не пришлось работать...

написал монитор на Qt, теперь смотрю живую трансляцию видео... с частотой ~1.5 fps... визуализирую колортрекинг, очень удобно а сам код колортрекинга я даже не переношу между проектами, они оба один и тот же файл юзают: я оттачиваю колортрекинг в Qt-проекте для ПК, а потом просто делаю ребилд проекта для МК, и робот с новым зрением прям кросспроектное кроссплатформенное (кросспроектоплатформенное) программирование только вот не получится так же закросспроектить коррекциию изображения...

проще на робота сразу ПК поставить и не мучицца.
И писать удобнее и вычислительные возможности
высокие.
По поводу попиксельной отрисовки,
я делаю так:
Bitmap как структура в памяти -> массив Byte[,] для моего алгоритма ->
работаю с массивом чисел
Потом: Byte[,] для моего алгоритма -> Bitmap как структура в памяти -> Рисуем на picturebox средствами c#

ЗЫ.. Чего c# не используешь? Быстро и нет особых тормозов, тем более 1.5 fps

эта тема уже обсуждалась, вопрос закрыт
точно по такому же принципу и я в Qt делаю. получаю массив байтов в буфер, на котором QImage построен и его средствами (или QPainter'ом) работаю с изображением
потому что каждый горазд свое советовать, DeaD тебя опередил да мне и понравилась Qt, там гцц, к которому я уже привык, а к мелкософтовому .NET я даже близко подходить не хочу.
колортрекинг и отрисовка происходят в мнгновение, низкий фпс из-за медленной передачи кадра по уарту: кадр 160х120х3байтаRGB, скорость уарта 1 Мбит/с (разогнал USB-UART до предела), посчитай . я вообще об этом умалчиваю в среде прикладных программистов, им не понять, и они засмеют человека, принимающего поток видео через COM-порт, да еще и несжатый поток

у меня была почти аналогичная задача,
принять от surveyor поток 160x120.
Там тоже было uart,
но я через USB-FIFO гоняю теперь,
60 кадров 160x120
Кстати 160x120xRGB это 19200*3,
гоняй 160x120xYUYV это 19200*2
Изображение ничем не хуже будет, а в 1.5 раза быстрее



Ну это ты зря, .net сейчас мейнстрим для windows RAD,
а это потенциально новые заказы.
А Qt? Я даж не помню чтобы хоть один был... так, бесполезные развлекушечки только

да мне уже не шибко интересно прикладное программирование, я вот в электронику и микропроцессорную технику ударился
с чего это вдруг ? у них одинаковая глубина, так что YUYV это 4, и я ее сократил до RGB - 3. меньше - это уже как раз хуже и будет.

YUYV это 4 байта на два пикселя, то есть 2 байта на пиксель

qt конечно подкупает своей кроссплатформенностью и наличием *gpl лицензий. но если нужен софт под винду, учитывая сколько стоят лицензии, очень бедные билиотеки (временами еще и не глючными),... ещё немного поизучаю, но скорей всего поставлю жирнючий крест на этом qt. чтот мне эта среда нравится всё меньше и меньше.

Добавлено спустя 9 минут 13 секунд:
чтот я запутался, у вас TCM8230MD или нет? в даташите на TCM8230MD чётко написано, что данные выводятся или в 8bit YUV422 или RGB565. и если я совсем не запамятовал, это получается 2 байта на пиксель. в общем непонятно от куда появлеятся лишний байт и тем более непонятно какие искажения цвета он привносит.

да, YUYV весьма темный и скользкий формат из-за "двухпиксельности", и это создает жуткую путаницу. кстати, возможно, из-за этого у меня непонятки с разрешением, потому что я получаю разрешения, не соответсвующее настройкам. в любом случае, я интерепретирую YUYV как 1 пиксель (беру арифметическое среднее Y из двух значений), чтобы он там не означал, так что лично у меня YUYV(4) соответствует RGB(3)
вы, видимо, пропустили момент, когда я заменил камеру на OV9650 у нее точно такие же форматы, да и вообще у всех камер, я думаю, в этом отношении все одинаково и стандартно. мне тоже не понятно, я пробовал гуглить, но мне не удалось найти объяснения, есть куча всяких статей, где эти форматы освещаются в свете прикладного программирвоания на ПК, а все потому, что никто кроме системщиков не работает на столь низком уровне, чтобы четко разобрать каждый формат детально от бита до бита. остается только читать оффициальные огроменные спецификации.

там всё-равно 2 байта на пиксель, как ни крути. как вы преобразуете "YUYV(4)" в "RGB(3)" страшно подумать. и тем более нафига вообще это делать, когда камера может выплёвывать данные в RGB565 формате.
немного основ тут
http://www.fourcc.org/yuv.php#Packed%20YUV%20Formats
http://msdn.microsoft.com/en-us/library/dd206750(VS.85).aspx#YUV422formats16bitsperpixel