roboforum.ru

elmot писал(а):Можно взять мою прошивку и самому попробовать.
wiki/OR-WRT

Вы так настойчивы, что просто невозможно отвертеться Взял и попробовал

1) Мои моторы, понятное дело, от Вашей прошивки не работают - только видео.
2) В локальной сети задержка видео "на глазок" примерно одинаковая и у Вас, и у меня и составляет порядка 0.7 - 1.5 секунды в зависимости от освещения;
4) Экспериментировал с прошивками в I2P. Там пинг порядка 2 секунд. Видео как-то совсем не завелось. Покадровое худо-бедно показывало, если поставить разрешение поменьше, а интервал побольше
5) Ещё появилась мысль, возможно, имеет смысл не просто "вперёд", "назад", "вправо", "влево", а направление+длительность для "асинхронного" управления. Иными словами, при большом пинге точно повернуть и вовремя остановиться довольно затруднительно У себя я заметил, что не могу точно между ножками мебели проезжать и вынужден издалека начинать "прицеливаться", если пинг 2 секунды и больше. У Вас попробовать без управления моторами не могу, но, я смотрю, для того, чтобы передвинуться нужно два действия: передвижение и стоп, правильно? Буду экспериментировать в направлении задаваемого времени передвижения.

Angel71 писал(а):dr_livsey, вебкамеры обычно очень сильно тормозят при слабом освещении. копеечные гарантированно г-но, если применять не по прямому назначению. есть cctv камеры, чб особенно хорошо при слабом освещении работают. их можно подключить через юсб (тот же easycap или чтот на подобии) или через безпроводной передатчик.

Да, я понимаю, что дешёвые камеры обычно хуже дорогих и что специализированные лучше камер общего назнавения Я высказывал сомнение в целесообразности 30 ФПС-ов в интернете, поскольку 1000 / 30 = 33.333 мс. Такого пинга в жизни просто не бывает. По этой причине мне думалось, что иметь частоту кадров тольше, чем частота возможного отклика было бы излишне.

А вы на каком разрешении и fps пробовали? У меня на 320х240х25fps задержка порядка 0.2-0.3сек при работе в MJPEG-формате.

dr_livsey писал(а): Ещё появилась мысль, возможно, имеет смысл не просто "вперёд", "назад", "вправо", "влево", а направление+длительность для "асинхронного" управления. Иными словами, при большом пинге точно повернуть и вовремя остановиться довольно затруднительно У себя я заметил, что не могу точно между ножками мебели проезжать и вынужден издалека начинать "прицеливаться", если пинг 2 секунды и больше.

Я к этому выводу пришел почти год назад http://roboforum.ru/forum8/topic9215-75.html#p196495

=DeaD= писал(а):А вы на каком разрешении и fps пробовали? У меня на 320х240х25fps задержка порядка 0.2-0.3сек при работе в MJPEG-формате.

Кажется, 160х120. Но опять же, по-моему, это больше от камеры зависит, а не от прошивки и программы просмотра. У меня две разные камеры есть, задержка на них почти в два раза отличается. Но это визуально. Как её точно померить, понятия не имею. Причём, парадоксально, но та из них, что работает в M-JPG, даёт гораздо большую задержку, чем та, которая в YUYV. Поэтому пользуюсь второй.

yak-40 писал(а):Я к этому выводу пришел почти год назад http://roboforum.ru/forum8/topic9215-75.html#p196495

Большое Спасибо за подсказку! Сделаю примерно как у Вас, добавлю галочку, по которой движение будет начинаться не по нажатию, а по по отпусканию кнопки и длиться столько же, сколько кнопка была нажата. Думаю, должно помочь

dr_livsey писал(а):Кажется, 160х120. Но опять же, по-моему, это больше от камеры зависит, а не от прошивки и программы просмотра. У меня две разные камеры есть, задержка на них почти в два раза отличается. Но это визуально. Как её точно померить, понятия не имею. Причём, парадоксально, но та из них, что работает в M-JPG, даёт гораздо большую задержку, чем та, которая в YUYV. Поэтому пользуюсь второй.

Возможно у вас сама камера YUV, поэтому перекодировка в MJPEG только увеличивает задержку.

=DeaD= писал(а):Возможно у вас сама камера YUV, поэтому перекодировка в MJPEG только увеличивает задержку.

Вот такой код для одной выдаёт "YUYV", а для другой "M-JPG":

Код: Выделить всё • Развернуть

    v4l2_fmtdesc f;
    int v4l2_pal;
    
    v4l2_pal = 0;
    memset(&f, 0, sizeof(fmt));
    f.index = v4l2_pal;
    f.type  = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    
    while(ioctl( m_dev, VIDIOC_ENUM_FMT, &f) != -1)
    {
        std::ostringstream s;
        s << f.description;
        fmt.push_back( s.str() );
        
        fourcc.push_back( f.pixelformat );
        
        memset(&f, 0, sizeof(f));
        f.index = ++v4l2_pal;
        f.type  = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    }

FourCC коды тоже соответствуют

Это все операционные системы подтверждают: OpenWRT, Ubuntu, WindowsXP(для Виндовс через директ-плей). Даже если предположить, что для всех трёх драйвер писал один и тот же человек, который очень любит M-JPG и прям внутри драйвера перекодирует поток, то всё равно 3GHz настольного компьютера должны были эту задержку сделать близкой к нулю или сильно уменьшить. Разве нет?

А, это у вас 1сек задержка на настольном ПК?

А что за камера-то?

elmot писал(а):А что за камера-то?

С очень большой задержкой вот эта: http://www.ulmart.ru/goods/154937/.
А с меньшей найти не могу, в продаже уже нет. Производитель Logitech, а модель уже не вспомню.

=DeaD= писал(а):А, это у вас 1сек задержка на настольном ПК?

.
Ну да и поэтому скорее всего это камера, а не алгоритм А так, ясен пень, нужны только хорошая камера и канал с маленьким пингом Поэтому и сильно удивляюсь сообщениям, что у Вас на форуме задержки видео близки к 0. Видимо, нужна правильная камера

dr_livsey писал(а):С очень большой задержкой вот эта: http://www.ulmart.ru/goods/154937/.

Так это 400руб, чего вы хотели