Добавлено спустя 18 минут 53 секунды: Первая штука меня реально заинтересовала, вот более подробное описание:
Если коротко - можно подцепить к этому точку доступа, пару вебкамер, на ней же есть порт RS-232 для управления всяким добром (т.е. например, модулями Open Robotics )
Или вообще подцепить не точку доступа, а WiFi USB Dongle, обещают что будет беспроводной доступ тогда.
Добавлено спустя 12 минут 44 секунды: Вышел на еще более детальное описание и похоже сайт реально авторов
Короче можно к этому девайсу подцепить USB-Hub, в него впихнуть пару веб-камер, wireless-usb-dongle и получить WiFi-шлюз на 2 вебкамеры и UART (там еще RS-232 порт есть).
Правда осталось понять насколько всё это легко потом будет заполучить с ПК
основной вопрос сколько девайс стоит, потому что то что я вижу ничем не отличается от прекрасно изученной и массово выпускаемой wifi точки доступа ASUS WL500gp там внутри ARM , полноценный линукс , ну и пара портов USB работает с любыми USB девайсами - хочешь флешку пихай хочешь видео , хочешь WimMax модем (у меня кстати так дома)
Добавлено спустя 4 минуты 41 секунду: ага, цену увидел - asus WL500gp дешевле и доступнее
идеи по использованию одной из точек доступа с линухом на форуме достаточно давно. пока только все заканчивалось вопросом "а зачем это нужно?". Как говорит Snable в соседней теме вполне можно использовать ffmpeg и кодировать программно видео на стороне робота, паковать его и слать по сети (это все умеет тот самый vlc, который на ffmpeg построен и работает и есть и под винду и под линукс), а на виндовой стороне тем же vlc можно как кодировать так и писать так и куча других вариантов есть. вопрос только в цене, имхо. ну и производительность камня в точке, конечно
В общем я о том же , только с уточнением что для кодирования vlc не нужен (несмотря на то что он это умеет это всё же плеер и достаточно тяжеловесное для ARM приложение)
для кодирования, наверное, не нужнен, а на принимающей стороне - почему нет? относительно его тяжеловесности - не знаю. когда он работает как стриммер и только разруливает потоки, так ничего лишнего не делает, вроде.
шо правда то правда. не работал вот если бы аппаратно кодировать видео, а программно уже только паковать, то было бы попроще. но аппаратный кодек еще та затея...
Добавлено спустя 19 минут 29 секунд:
Правда осталось понять насколько всё это легко потом будет заполучить с ПК
там Motion-JPEG судя по описанию, а VLC с ним дружит.
открою секрет : 90% процентов того что называют сейчас аппаратным кодированием это по сути програмное, но реализованное в прошивке выделенного девайса и на его вычислительных ресурсах. поэтому если сжатие потока будет на отдельном OR устройстве - смело можно назвать его аппаратным
>хочешь WimMax модем (у меня кстати так дома) А мы скайлинк модем к нему через USB подключали. Отлично работал Роутер просто чудо(благодаря альтернативным linux прошивкам), его единственный минус низкая скорость. У нас на сети он успевает через ВПН канал(не шифрованный) маршрутизировать только 6мбит. Не понятно успеет ли он обработать поток в 25 кадров на разрешении 640х480(не говоря про два таких потока).
Без сжатия 640х480, 24 бита и 25 кадров - это 184.32Мбита Нефиговый поток одна надежда - что веб-камеры его гонят уже сжатый Раз через USB1.1 как-то проходил он (12Мбит)
возможно имеет смысл производить некоторую предобработку видео на стороне робота для снижения потока? тупо гнать весь поток на стационарный комп, потом там обрабатывать как-то не красиво, чтоли.. нет возможности отфильтровать часть незначимых кадров? или это сложнее чем тупо кодировать и передавать?
Добавлено спустя 1 минуту 34 секунды:
одна надежда - что веб-камеры его гонят уже сжатый
ну если через 12 Мбит USB его прогоняли, то определенно был сжат. Хотя 12 мбит это все равно много. надо сильнее жать.
2frig: Там процик 266Мгц вроде всего, какая еще предобработка, да и нафиг не надо разработчику СТЗ иметь проблемы с программированием предобработки для своей задачи еще и на ARM'е.
Даже ч/б в 320x240 это уже 15мбит. Веб камеры ес-но умееют сжимать. Там обычно есть даже несколько вариантов кодеков, этим действительно грех не воспользоваться.
Добавлено спустя 5 минут 16 секунд: Правда нужно понимать, чем сильнее сжатие, тем больше информации мы несомненно теряем. Но я согласен, без сжатия это вообще не целесообразно. Поэтому лично я буду придерживаться стратегии обработки видео прямо на борту нетбука. И буду надеятся, что Intel сдержит своё обещание по поводу их стратегии "тик-так" в отношении Atom'a и каждые два года, будет увеличивать их мощность(число транзисторов) в два раза. Тогда лет через 10 у меня всё будет замечательно.
сразу видно ты не работал с embedded устройствами, там борьба за каждый килобайт места в памяти и процент загрузки процессора
