Форум РадиоКот

Доброго времени суток. У меня такой вопрос...
Есть задумка поместить видио камеру(мобильного устройства или любую подходящую) на колесную платформу(самоходная тележка). Платформа сейчас работает на основе датчиков типа ИК-диод+ фототранзистор и успешно передвигается по черной линии на светлом фоне. Хотелось бы усовершенствовать платформу, а именно прикрепить к ней видеокамеру, но не просто чтоб висела и радовала глаз, а еще и передавала на ПК изображение.
У меня контроллер ATmega16. Подскажите пожалуйста схему подключения камеры и блютуз к данному мк. Если это возможно... Возможно вместо блютуза wi-fi соединения. Самое главное, чтобы была возможность дистанционного управления камерой через контроллер.

Заранее спасибо....

А вы прикиньте объём данных для относительно хренового полезного видеопотока с камеры и забейте на мегу16, не вытянет.
Тут нужно решение серьёзнее, платформы из wifi-точек люди делали, например.. Это из простого и дешёвого Сразу решаем проблему передачи данных и, имея нормальную точку, решаем проблему с видеопотоком, хоть по вебу смотрите

Хорошо, МК не принципиально можно и atmega128. Мне не понятно само подключение, физическая составляющая. Т.е. грубо говоря куда какой контакт подключать, та же проблема и с wi-fi...

Как мне кажется вам проще будет поставить аналоговую китайскую камеру.
А на другой тоже китайский приёмник.
и через видеовход в ПК.

Как вариант - применить wifi web-камеру. А управлять платформой можно и другим спсобом (ZigBee например). Можно поискать build tree к этой камере и дописать-вкомпилить туда интерфейс к платформе. Самое простое - посылка UDP пакетиков с командами внутри. Вариантов мульён

Софт на данном этапе не главное, главное физическое подключения и варианты этого подключения...т.е. я прошу посоветовать какую-нибудь камеру и вариант подключения ее к AVR устройству, корпус (МК) желательно DIP... Так же варианты подключения wi-fi либо блютуза... повторяю, НЕ СОФТ, НЕ КОД, а подключение...какой провод от камеры (которую вы надеюсь посоветуете мне ), подключить к МК (варианты МК приветствуются)... тоже самое и с блютузом или вай-фаем...
Цель всего этого:
Как было написано ранее у меня колесная платформа которая работает на датчиках (ИК-диод+ фототранзистор) и передвигается по черной линии на белом фоне. Это конечно все здорово, но столкнулся с проблемой. Если линия прерывается или ее нет то платформа начинает блуждать в "свободном полете". Какие либо логические действия для нахождения ее ни к чему стоящему не привели. Именно по этому хочу прикрепить камеру, чтобы последняя отслеживала и при необходимости находила линию (алгоритм слежения понятен: вычитание последовательных кадров с камеры, те что отличны от 0- там "граница" траектории,используется видио черно-белое, нахождение объектов черного цвета)... понятно что достаточно дешевый МК не справиться с потоковым видио по этому в помощь ему будет думать нормальный ПК подключенный к нему по средству wi-fi или блютуза... Варианты работы ПК и МК пока не продумывал.... если есть способ добиться задачи более простым путем буду признателен вашему совету .... самое главное физическое подключение камеры и МК...(которого я увы не знаю )...

Мега8 или мега128 - не принципиально, по своим вычислительным возможностям они находятся рядом. Вы хотите повесить туда и камеру, и bluetooth - да она надорвется.
Представьте себе, что для получения видео потока со сменой кадра 15fps Вам нужно "кормить" камеру от мобильного телефона (сейчас только о ней) клоком с частотой в 26МГц (это, как бы, стандарт).
Я бы делал на arm-контроллере, QVGA-камере от мобилки (выбор велик, тут уже конкретно нужно думать) и двух bluetooth-модулях (к примеру, второго класса мощности - до 30 метров), поддерживающих профиль SPP (беспроводной последовательный порт). Шпарим клок-сигнал на камеру, принимаем изображение, покадрово его аккумулируем, по сигналу кадровой синхронизации передаем его полностью на ПК (точнее, по падающему фронту сигнала - типа, кадр "считан").
Или приемо-передающую часть делал бы на китайских приемниках/передатчиках навроде HM-T868 и HM-R868. Тот же беспроводной последовательный порт, только подешевле в итоге выйдет (около 15-20$ в общей сумме против ~50$ в случае блютус-модулей).
Можно, конечно, сделать и на меге, народ и линух прикручивал к системе на этом МК, да производительность у этой системы на выпучившей глаза меги будет никакая. И скорость смены кадров, и реакция на команды...

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

Существуют камеры с встроенной JPEG компрессией, выдающие данные по RS232-му протоколу. У них название обычно там... C328, С628 и тд. Если заинтересует, покопаюсь в компе, вроде был такой проект.

Это тоже не вариант. Надо видео - это раз. Видео не склеишь из них, т.к. захлебнётся и канал, и такая камера - это два. И стоит оно как ведро "камер от мобилок" - это три.

Есть вариант: ПЛИСина + передача ей же куда-то, на SD-карту, например. Вряд ли осилите Да и смысла нет, ARM будет проще и лучше, имхо.

Скачай польский журнал Elektronice dla Wszystkich 7/2009, там есть описание тележки с камерой.
http://www.aldebarans.ru/jtexnic/21319- ... -2009.html

О-ё, я пока читал раздел, забыл с чего он начался. Так вам нужно камеру вместо оптосенсора для тележки или просто ходячий видеопередатчик? Если нужен просто оптосенсор, чтобы за линией следить, по КОТорой тележка бегает, так видеокамера- эт явный перебор. Траффик от нее микропроцу не прожевать, Не говоря уже о программе распознавания. Линейная ПЗС-матрица, типа тех что в сканере стоит, по- моему самое то. И даташиты очень подробные на них в наличие, и быстродействия вообще не треба. А для видеопередатчика-обычная аналоговая фигня за 2-3Крублей.

А камера собственно и может работать как линейная ПЗС-матрица, ей можно задать окно в несколько линий и сканировать только их. Но объемчик данных всеравно немаленький. Ведь вы как будете поступать, сначала считать данные с камеры потом передать? А вот фиг... где вы в дешевых контроллерах возьмете несколько килобайт RAM? одна строка - это 320(или 640?) точек по 2 байта(5 бит на каждый канал цветности) на пиксель. Это надо учитывать, либо передавать сразу же при поступлении - но надо следить чтобы процесс передачи данных не затормозил процесс получения данных с камеры, иначе в движении начнутся интересные стробоскопические эффекты - камеры, за редким исключением, не имеют собственной памяти даже для одной строки.

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

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

Собственно за счет изменения "окна" реализуется цифровой зум в фотиках использующих такие матрицы.

Даю безумную халявную идею. Специфическая камера, заточенная на обработку изображения стоит в каждом оптическом мыше. Её задача- зацепиться за точку на поверхности. Фокусное расстояние объектива - милиметров 7-8. Надо поставить объектив, который будет фокусировать картинку в фокус мыша. А от управления мышыным лазером забубенить внешнюю подсветку. Возможно это принципиально, а может нет. Если удастся найти мыш с RS232 интерфейсом, вообще лафа. Протокол мыша найти не проблема. Можно не благодарить, хотя...

Ну там камера - одно название : 16 : 16 пикселей.

Ну дык ему же тележкой управлять, а не фотки делать. Полосы на полу квачём (малярной кистью) рисуют, а не фломастером. Самое то для мыша.

Есть камеры от мобилок в частности MOTOROLA C-550 на ней распаян чип под названием OV528.
Этот чип выдаёт (по желанию) или JPEG или RS232 или SPI.
Минимальное разрешение 80\60.
Это всё хозяйство легко можно гонять по эфиру, например nRF24L01.
Думаю это то что надо.
В архиве кое что по этому делу.

Вы выше писали что надо 2 блютус модуля (это в лучшем случае 5,2Мбит/сек). я так прикинул и получилось что если сделать квадратурную амплитудную манипуляцию с созвездием на 64 (каждый сигнал квантуется на 8 уровней) точек то такой объем данных можно передавать на скорости около 80КГц. Служебную информацию я в расчет не брал, если с ней и еще какое нибудь кодирование замутить(а можно 2) то пусть будет 160КГц. А ведь такая частота вполне приемлема даже для просто PICа (если грубо то 60 команд он успеет обработать если кварц на 20МГц(и это на формирование одного пакета(хотя я уже запутался))) А теперь собственно вопрос где я не прав(а я чую пятой точкой что я не прав) и почему так делать нельзя особенно если делать все самому(ну и на доступных микрухах). Как работает камера, сразу признаюсь, не знаю но буду читать выложенный даташит, но если вы тут вкратце объясните буду очень признателен.