[MIkler 0]

Не пробовали для ваших задачь Li-Fe вроде обещают не проседать на морозе и отдача у них выше чем у LiPo и ещё появляются компактные Li-tech с керамической мембраной, они более емкие и тоже не проседают?

 

По поводу сети - рекомендовал вам поставить всё таки MikroTik. Если будет интересно могу проконсультировать о комплектации, если есть схема сети. С LTE рекомендовал бы сделать минимум 2 модема на борту, не сложно организовать с помощью них общий канал. У телевизионщиков их обычно до 7, боевое решение 5. Гарантированно можно лить HD.

[desert 0]

Не пробовали для ваших задачь Li-Fe вроде обещают не проседать на морозе и отдача у них выше чем у LiPo и ещё появляются компактные Li-tech с керамической мембраной, они более емкие и тоже не проседают?

 

По поводу сети - рекомендовал вам поставить всё таки MikroTik. Если будет интересно могу проконсультировать о комплектации, если есть схема сети. С LTE рекомендовал бы сделать минимум 2 модема на борту, не сложно организовать с помощью них общий канал. У телевизионщиков их обычно до 7, боевое решение 5. Гарантированно можно лить HD.

 

Добрый день, Михаил.

Мы рассматривали разные акб, но так как корпус уже был проработан под определенные модели акб(ВхДхШ) и дроссели двигателей были рассчитаны на определенный вольтаж, то переработка борта заняла бы больше времени. В будущем проекте 2013 года мы уже заложили использование новой силовой шины и новые акб. все таки рассчитываю на LI-AIR, по таблице у них самая большая емкость. Может уже скоро будут в продаже по доступной цене! сообщу здесь. фасфатные батареи делает a123.

Li-fe отличные акб, у нас продаются только на 30в, меньше не видел с большой емкостью. заряжаются быстро очень! про LTE напишу вам в личку позже. есть ограничения провайдера по передаче информации(не прочитали то что мелким шрифтом в договоре)

 

Думаю, создам новую тему здесь, когда закончу заказ с телефоном и тогда скинем Вам наши наработки новые и обсудим новые сети и новые акб.

Впереди darpa и teamfly.

 

offtop:Ко мне обращались в личку за комплектухой из Германии, честно скажу... таможня Российская конечна... ужас! больше 3х плат уже не пропускают в личное пользование. поэтому прошу понять правильно. думайте другие пути покупок.

[x736C 0]

Не предназначен Wi-Fi для таких применений.

Вопрос, как ведет себя Wi-Fi система на границе чувствительности?

 

Использовали для пробы «пакетный» модем одной канадской фирмы.

Происходила проблема с повторной передачей. Приемный модем перезапрашивал битые пакеты, сводя на нет всю «реалтаймовость» процесса управления/контроля БПЛА.

Происходило переполнение приемного буфера модема, и он намертво зависал. То ли это говорит о качестве модемов этого производителя, то ли о том, что нельзя игнорировать сигналы контроля передачи по UART. Использовал только tx, rx, gnd. Но это так, к слову.

 

Повтор передачи битого пакета по Wi-Fi осуществляется на уровне TCP-IP? Или на MAC-уровне роутера?

 

UPD:

Выглядело это примерно так.

По оси абсцисс условное время в каких-то tic. По оси ординат удаление от передатчика. Синие маркеры -- принятые пакеты.

При равномерном удалении график должен представлять прямую, пусть и с пропусками пакетов.

 

Эта запись сделана при перемещении на ж/б полосе. В таких условиях затухание убьет любую связь, не использующую разнесенный прием или передачу.

Подобные затухания происходят при втором отраженном луче, обладающим очень малым углом <1-2° относительно основного луча. Поэтому использование направленных антенн, как тут советовали, может быть эффективно где-нибудь в городских джунглях, но на открытой местности давать незначительный эффект в борьбе с многолучевостью. Другое дело, конечно, горы. О работе в горах имею слабые представления.

 

В общем, вопрос использования Wi-Fi, LTE, gprs систем для мобильных роботов реального времени меня очень интересует. Буду рад выслушать ответы и замечания.

 

ИМХО, автор выбрал самое правильное решение (как советовали в ветке) использовать базовые станции LTE.

 

UPD2:

Кстати, еще мой коллега проводил исследование влияния ошибок в канале на видео, сжатое разными способами (h.264, mjpeg) с разными скоростями.

В итоге BER 10^-5 убивает сигнал ощутимо. Более высокие показатели вероятности ошибки не приемлемы для использования.

И это в выходном видео-потоке. То есть при 10^-5 входного потока (до валидации пакета по КС), выходной BER будет вообще за рамками.

 

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

Изменено 6 июля, 2012 пользователем x736C

[petrov 8]

...

 

Wi-Fi предназначен для других масштабов, найдите профили многолучёвости для Wi-fi и LTE.

 

Пакетность и прочие навороты протоколов здесь не нужны, требуется непрерывная передача с большой пропускной способностью в одну сторону.

 

 

На счёт LTE и другой сотовой связи, не годятся эти костыли

 

Сразу после землетрясения все три крупнейших японских оператора (NTT DoCoMo, KDDI, Softbank) заявили, что их сети пострадали, особенно в прибрежных районах. В некоторых районах связь не работала, и это было связано как с разрушением инфраструктуры, так и с отсутствием электричества. В крупных городах возникла повышенная нагрузка на сети мобильной связи, они не справлялись с пиковым количеством звонков, SMS-сообщений, запросов на доступ в сеть для чтения новостей, написания сообщений почты. Классический сценарий природной или техногенной катастрофы, когда отказывает мобильная связь, это один из самых хрупких элементов современной цивилизации.

 

 

Никаких сильно направленных антенн, отражённые лучи приходят со всех сторон и всю эту энергию можно и нужно собрать.

 

Статьи надо писать на тему MIMO, transmit beamforming, maximal ratio combining и прочие синхронизации, эквализации, кодирование и т. п.

 

 

[x736C 0]

Wi-Fi предназначен для других масштабов, найдите профили многолучёвости для Wi-fi и LTE.

С предназначением Wi-Fi понятно. Передача интернет-контента на расстояния 100м в пределах здания.

За наводку спасибо, обязательно посмотрю.

 

Пакетность и прочие навороты протоколов здесь не нужны, требуется непрерывная передача с большой пропускной способностью в одну сторону.

 

 

На счёт LTE и другой сотовой связи, не годятся эти костыли

Зависит, конечно, от задачи. Для более менее серьезных по радиусу работы и полезной нагрузке БПЛА такие системы, конечно, малопригодны.

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

 

 

Никаких сильно направленных антенн, отражённые лучи приходят со всех сторон и всю эту энергию можно и нужно собрать.

Согласитесь, это зависит от предназначения системы и условий ее эксплуатации. Для БПЛА нередкий случай, когда все лучи, включая отраженные, приходят с одной стороны, и отраженный луч зачастую приводит к сильному замиранию.

 

Статьи надо писать на тему MIMO, transmit beamforming, maximal ratio combining и прочие синхронизации, эквализации, кодирование и т. п.

Тема статьи выбрана. В системе связи мобильного робота меня интересует больше связь в контексте управления мобильным роботом, нежели просто связь и методы ее улучшения.

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

 

Мои вопросы по повторной передаче данных остались открыты. Кстати в LTE используется HARQ, что хорошо для интернета, но не всегда хорошо для систем реального времени.

 

 

 

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

Это потому, что строят их без учета катастроф. Дома же строят в соответствии с требованиями к сейсмической стойкости. Так же и сети, наверное, стоит оборудовать системами бесперебойного питания, резервированием и т.д. Что, по-моему, и так делается.

 

[Plain 227]

очень нужны замечания и комментарии

Почитайте про избыточное кодирование.

[x736C 0]

Почитайте про избыточное кодирование.

А конкретнее? В силу возможностей занимаюсь избыточным кодированием, реализовывал bch в hdl, и прочие не самые сложные виды помехозащиты.

 

[blackfin 32]

Кстати, еще мой коллега проводил исследование влияния ошибок в канале на видео, сжатое разными способами (h.264, mjpeg) с разными скоростями.

В итоге BER 10^-5 убивает сигнал ощутимо. Более высокие показатели вероятности ошибки не приемлемы для использования.

И это в выходном видео-потоке.

Пардон, а какой смысл Ваш коллега вкладывает в эту фразу: "убивает сигнал ощутимо"?

[x736C 0]

Пардон, а какой смысл Ваш коллега вкладывает в эту фразу: "убивает сигнал ощутимо"?

Нет, это я так обозначил свою субъективную оценку качества видео-ряда по количеству артефактов. Их количество при выбранной BER, конечно, очень сильно зависит от кодека и, что самое главное, от степени сжатия. Но я решил не расписывать подробно, ибо не о конкретных нюансах речь. Есть еще разные требования к самой видео информации. Если она требуется для перемещения по зданию — один вариант. Если же для идентификации объекта типа «танк» на подстилающей поверхности при опред. условиях наблюдения — то и требования выше. Суть не в конкретном значении (10^-5), а в том, что в случае использования Wi-Fi стоит говорить о проценте битых пакетов. Но и такие цифры есть в сети.

[blackfin 32]

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

IMHO, если при большом BER система - кодек+трансивер будет адаптивно выбирать более мелкие слайсы, а также NAL пакеты меньшего размера, скажем ~1 KB, не использовать кадры B-типа и не злоупотреблять кадрами P-типа, то субъективно, видео-ряд должен быть вполне качественным. Ваш кодек позволяет изменять эти параметры? Использует ли он SI и SP слайсы?

Изменено 6 июля, 2012 пользователем blackfin

[x736C 0]

IMHO, если при большом BER система - кодек+трансивер будет адаптивно выбирать более мелкие слайсы, а также NAL пакеты меньшего размера, скажем ~1 KB, не использовать кадры B-типа и не злоупотреблять кадрами P-типа, то субъективно, видео-ряд должен быть вполне качественным. Ваш кодек позволяет изменять эти параметры? Использует ли он SI и SP слайсы?

Я не специалист в этом. Но тем не менее, у меня есть полная уверенность, что этого всего не делается и даже не изучалось. Пока были проведены исследования разных стандартов кодирования в первом приближении при более-менее стандартных настройках кодеров. И был выбран mjpeg. Хотя на мой личный взгляд это неправильно. Практически все западные системы, включая военные ДПЛА, используют методы обработки видео с межкадровым сжатием.

Но вот именно то, что Вы обозначили, меня сейчас интересует — канал с высоким BER для передачи видео информации. Это не по основной работе, аспирантский интерес.

[blackfin 32]

Но вот именно то, что Вы обозначили, меня сейчас интересует — канал с высоким BER для передачи видео информации.

Тогда, возможно, есть смысл дождаться публикации нового стандарта - HEVC:

Согласно выступлению одного из докладчиков, новый стандарт может обеспечить уменьшение битрейта на 40-50% при схожем качестве изображения и сравнимой с H.264 High profile вычислительной сложностью.

Изменено 7 июля, 2012 пользователем blackfin

[Stepanov 9]

Чудес не бывает, может этот стандарт и сжимает на треть лучше Н264, но надо смотреть качество картинки, насколько страдают мелкие детали. И еще есть такой параметр как время задержки, телеуправлением мучительно заниматься если картинка на полсекунды отстает.

[des00 25]

Чудес не бывает, может этот стандарт и сжимает на треть лучше Н264, но надо смотреть качество картинки, насколько страдают мелкие детали. И еще есть такой параметр как время задержки, телеуправлением мучительно заниматься если картинка на полсекунды отстает.

+1, при этом мне не понятно вот что, высокие скорости сжатия -> арифметическое кодирование -> жесткая завязка на контекст -> при высоком BER кабак там такого на восстанавливает -> куча мусора в изображении(особенно на P/В фреймах, завязанных на соседние кадры). ИМХО mjpeg не так уж и плох при высоком BER.

 

ЗЫ. могу ошибаться сильно %)

 

Вот прикольно сделать адаптивную модуляцию с ос и натравить на это дело SVC реализацию 264. ну и рулить качеством адаптивно, будет мега тема %)

[x736C 0]

ИМХО mjpeg не так уж и плох при высоком BER.

Это как сравнить. При одинаковом битрейте качество mjpeg будет многократно ниже. То есть да — он хорош, но ценой толстого канала, для которого, условно, на тысячу бит приходится меньше информации.

 

Мне кажется, будущее систем телеуправления не за универсальными, а за контекстно ориентированными кодеками.

 

То есть Вы понимаете, какой выигрыш можно получить в ОСШ при увеличении сжатия в 10-20 раз при сохранении качества. Я об этом.

UPD: имею в виду фильтр ПЧ и, соотв., чувствительность приемника.

Изменено 9 июля, 2012 пользователем x736C