Если не это не секретная информация, то какие камеры вы используете на этих роботах? Правильно ли я понимаю, что глубина определяется по лидару, что будет если на него попадет снег или пыль?
Нет, не смущает. Если на автомобиль будут ставить камеры со спутника или БПЛА - тогда я с вами соглашусь. Но пока картинка с камер автомобилей, которую я вижу в статьях и презентациях, на порядок хуже картинки даже со среднего телефона, особенно когда в кадре появляется солнце и погодные эффекты.
В перспективе - да, возможно автомобили будут видеть и действовать лучше людей, и даже лидары не понадобятся. Но то, что я вижу на данный момент - попытки несовершенства восприятия компенсировать количеством и вычислительной мощностью. Опять же - это мое ИМХО, может в действительности не все так плохо и видят автомобили как спутники, просто в статьях приводят пережатые картинки.
Пусть так. Но ясно вижу разницу, между хорошей фотографией с HDR и картинкой приведенной в статье на одном и том же мониторе. Если разница в интерпретации, почему картинки на одном и том же устройстве, в одних и тех же условиях дают такую разницу в восприятии? На мой взгляд реальность в этом плане ни чем не отличается, эту же картинку с автомобиля я могу рассмотреть, например в VR очках, и так же увижу разницу с приведенными в статье изображениями.
Да, мозг дорисовывает и закрашивает слепое пятно благодаря второй камере. Однако даже с этой дорисовкой мы очень хорошо распознаем объекты в том числе благодаря тому, что глаза передают картинку лучше камер. Тут роль играет не только нейросеть, но и качество картинки на которой она работает. Аналогичная разница будет если обучать нейросети на видео 320x240 с древнего телефона и на 1080p с последнего iPhone. Не уверен на 100%, но вряд ли на автомобили ставят камеры в половину цены самого автомобиля.
Добавление лидара и десятка камер - способ компенсировать их недостатки по сравнению с человеческим зрением. Под спойлером я привел картинку из поста как камеры видят мир. Сравните ее с тем, что вы видите своими глазами. С такими шумными данными, как на картинке, даже человеку водить будет сложно, не говоря о нейросети. Отсюда и сложности в распознавании и обучении у автомобилей.
Картинка из поста
Уточню, что это мое лично мнение. Автономными автомобилями я не занимаюсь поэтому как они видят в реальности могу судить только по картинкам из статей.
Я не совсем понял пункт про конфиденциальность. Он же весь код в любом случае должен в интернет отправить, чтобы по нему получить подсказки. Почему они утверждают что код не покидает компьютера?
Обученный человек с двумя глазами пока справляется лучше, чем лидары и камеры, особенно если нужно проехать по лесу или разбитой деревенской дороге. Да и распознает объекты человек лучше чем нейросети, как минимум на майку со знаком stop он не остановится, под фуру не заедет и рекламу с людьми не перепутает.
У человека не просто две камеры. Они могут перемещаться и смотреть в любом направлении, и имеют очень большой динамический диапазон. Более того человек имеет миллионы примеров разных ракурсов машин, велосипедов, знаков, других людей из-за чего ему проще ориентироваться на местности и определять препятствия.
На сколько я знаю энтузиасты пытаются делать CUDA-подобные интерфейсы к другим картам (например ZLUDA). Где-то даже был проект по трансляции вызовов CUDA в OpenCL для старых карт. У AMD есть HIP, который позволяет компилировать CUDA под их карты. Но NVidia активно сопротивляется мимикрии под их API, чтобы сохранить рынок.
Я накидал простой скрипт, чтобы это проверить. На большинстве диапазонов до 1000000 средняя длина общей цепочки (N, N + 1) равна половине средней длины цепочки для N. Для двух и трех последних чисел скорее всего охват будет до 90%, но нужно проверить.
Мне кажется вполне логичным предположить, что на больших числах эта тенденция не будет меняться.
Функция расчета
function mean_length(from, to)
local diff_length = [];
local curr_length = [];
local result = [];
local pred = Set();
for i = from:to
local curr = Set();
local t = i;
push!(curr, t)
while t > 1
if t % 2 == 0
t = div(t, 2)
else
t = t * 3 + 1
end
push!(curr, t)
end
push!(curr_length, length(curr))
push!(diff_length, length(intersect(pred, curr)))
pred = curr
end
mean(curr_length), mean(diff_length)
end
Да, с 1002 и 1003 на 10% совпадают, а 1001 и 1002 на 90%. В среднем может оказаться что программа с таким подходом отработает за 10 минут вместо 7, но памяти потребует на порядок меньше. На больших числах это вполне может сработать, особенно если хранить 2-3 предыдущих цепочки.
Если я правильно понял, то хвост рекурсии для большинства пар (N, N + 1) совпадает. Из-за чего хранить все значения от 2 до N - 1 в кеше очень расточительно по памяти. Достаточно хранить те, которые присутствовали на последнем шаге (на M последних шагах).
Если нужно совсем просто, можете мою поделку попробовать. Работает как простой SOCKS5 прокси, в браузере нужно только proxy.pac прописать (пример файла есть в репке).
Технически - да, такая возможность есть. Скорее всего можно без изменений скомпилировать под нужную архитектуру. Физически я вряд ли буду этим заниматься из-за отсутствия нужного оборудования.
В поле setup script нужно указывать URL, а не относительный путь к файлу на диске. URL будет выглядеть примерно так: file:///D:/my-path/proxy.pac. В начале префикс file:///, дальше полный путь к файлу через / (можно из проводника скопировать и заменить слеши). Альтернативно можете прокси в ручную указать без URL: host -127.0.0.1; port -1080; protocol - SOCKS5.
В окошке нет информации потому что по умолчанию логи отключены, нужно добавить переменную окружения RUST_LOG=no_dpi_socks=debug. Тогда программа будет обо всех событиях писать, но пока прокси не указан правильно там будет только информация на каком порту он запущен.
PS: если не получится настроить лучше напишите в личку или в Телеграм.
Получаем запрос на соединение от браузера, обрабатываем его как обычный SOCK5 до установки соединения;
Вычитываем первые 1024 байта от браузера и передаем по одному байту на пакет (пассивный DPI не может склеить эти пакеты и найти в них имя хоста);
После первых 1024 байт остальной трафик идет как есть что получили то и отправляем;
Обратный трафик от сервера в браузер передаем как есть, без разбиения на маленькие пакетики.
Если интересно посмотреть код - вот репка (написано на Rust). Реализация находится в src/main.rs, логики там строчек на 50, остальное: протокол SOCK5 и обработка ошибок.
У меня он уже больше недели работает на двух компьютерах с Linux и Windows, за это время ни каких проблем с YouTube не заметил.
Физически он у меня на компе на localhost:1080 висит, при подключении немного меняет исходящий поток к провайдеру. Фактически провайдер ни какого SOCKS не видит. Я выбрал SOCKS только из-за удобства перенаправления в него трафика с разных сайтов средствами браузера.
У меня все локально на компьютере работает, без сторонних серверов. Принцип такой: после соединения, первый пакет отправляем по одному байту на пакет, остаток идет как есть. По сути упрощенная версия локальных программ для обхода, без изменения порядка и содержимого пакетов.
В первый день, когда YouTube перестал открываться, я написал себе простой SOCKS прокси и proxy.pac, который только YouTube в него заворачивает (что интересно medium тоже через него заработал). Сейчас сижу через него, и пока он работает работает ставить что-то другое не планирую, тем более лезть в роутер с риском без интернета остаться.
Если не это не секретная информация, то какие камеры вы используете на этих роботах? Правильно ли я понимаю, что глубина определяется по лидару, что будет если на него попадет снег или пыль?
Нет, не смущает. Если на автомобиль будут ставить камеры со спутника или БПЛА - тогда я с вами соглашусь. Но пока картинка с камер автомобилей, которую я вижу в статьях и презентациях, на порядок хуже картинки даже со среднего телефона, особенно когда в кадре появляется солнце и погодные эффекты.
В перспективе - да, возможно автомобили будут видеть и действовать лучше людей, и даже лидары не понадобятся. Но то, что я вижу на данный момент - попытки несовершенства восприятия компенсировать количеством и вычислительной мощностью. Опять же - это мое ИМХО, может в действительности не все так плохо и видят автомобили как спутники, просто в статьях приводят пережатые картинки.
Пусть так. Но ясно вижу разницу, между хорошей фотографией с HDR и картинкой приведенной в статье на одном и том же мониторе. Если разница в интерпретации, почему картинки на одном и том же устройстве, в одних и тех же условиях дают такую разницу в восприятии? На мой взгляд реальность в этом плане ни чем не отличается, эту же картинку с автомобиля я могу рассмотреть, например в VR очках, и так же увижу разницу с приведенными в статье изображениями.
Да, мозг дорисовывает и закрашивает слепое пятно благодаря второй камере. Однако даже с этой дорисовкой мы очень хорошо распознаем объекты в том числе благодаря тому, что глаза передают картинку лучше камер. Тут роль играет не только нейросеть, но и качество картинки на которой она работает. Аналогичная разница будет если обучать нейросети на видео 320x240 с древнего телефона и на 1080p с последнего iPhone. Не уверен на 100%, но вряд ли на автомобили ставят камеры в половину цены самого автомобиля.
Добавление лидара и десятка камер - способ компенсировать их недостатки по сравнению с человеческим зрением. Под спойлером я привел картинку из поста как камеры видят мир. Сравните ее с тем, что вы видите своими глазами. С такими шумными данными, как на картинке, даже человеку водить будет сложно, не говоря о нейросети. Отсюда и сложности в распознавании и обучении у автомобилей.
Картинка из поста
Уточню, что это мое лично мнение. Автономными автомобилями я не занимаюсь поэтому как они видят в реальности могу судить только по картинкам из статей.
Я не совсем понял пункт про конфиденциальность. Он же весь код в любом случае должен в интернет отправить, чтобы по нему получить подсказки. Почему они утверждают что код не покидает компьютера?
Обученный человек с двумя глазами пока справляется лучше, чем лидары и камеры, особенно если нужно проехать по лесу или разбитой деревенской дороге. Да и распознает объекты человек лучше чем нейросети, как минимум на майку со знаком stop он не остановится, под фуру не заедет и рекламу с людьми не перепутает.
Присоединяюсь к предыдущему комментатору, почему нельзя ввести локацию в ручную, как минимум город?
Я в телеграмме сижу с компа. На нем вообще GPS нет, максимум что я могу сделать - открыть приложение в обычном браузере и поставить фейковую локацию.
У человека не просто две камеры. Они могут перемещаться и смотреть в любом направлении, и имеют очень большой динамический диапазон. Более того человек имеет миллионы примеров разных ракурсов машин, велосипедов, знаков, других людей из-за чего ему проще ориентироваться на местности и определять препятствия.
Есть компилятор C. С ним можно использовать разные редакторы графики и музыки в зависимости от платформы. Например, вот список утилит для NES.
На сколько я знаю энтузиасты пытаются делать CUDA-подобные интерфейсы к другим картам (например ZLUDA). Где-то даже был проект по трансляции вызовов CUDA в OpenCL для старых карт. У AMD есть HIP, который позволяет компилировать CUDA под их карты. Но NVidia активно сопротивляется мимикрии под их API, чтобы сохранить рынок.
Я накидал простой скрипт, чтобы это проверить. На большинстве диапазонов до 1000000 средняя длина общей цепочки (N, N + 1) равна половине средней длины цепочки для N. Для двух и трех последних чисел скорее всего охват будет до 90%, но нужно проверить.
Мне кажется вполне логичным предположить, что на больших числах эта тенденция не будет меняться.
Функция расчета
Вывод для разных диапазонов
Да, с 1002 и 1003 на 10% совпадают, а 1001 и 1002 на 90%. В среднем может оказаться что программа с таким подходом отработает за 10 минут вместо 7, но памяти потребует на порядок меньше. На больших числах это вполне может сработать, особенно если хранить 2-3 предыдущих цепочки.
Если я правильно понял, то хвост рекурсии для большинства пар (N, N + 1) совпадает. Из-за чего хранить все значения от 2 до N - 1 в кеше очень расточительно по памяти. Достаточно хранить те, которые присутствовали на последнем шаге (на M последних шагах).
Пример
1000 -> 500 -> 250 -> 125 -> 376 -> 188 -> 94 -> 47 -> 142 -> 71 -> 214 -> 107 -> 322 -> 161 -> 484 -> 242 -> 121 -> 364 -> 182 -> 91 -> 274 -> 137 -> 412 -> 206 -> 103 -> 310 -> 155 -> 466 -> 233 -> 700 -> 350 -> 175 -> 526 -> 263 -> 790 -> 395 -> 1186 -> 593 -> 1780 -> 890 -> 445 -> 1336 -> 668 -> 334 -> 167 -> 502 -> 251 -> 754 -> 377 -> 1132 -> 566 -> 283 -> 850 -> 425 -> 1276 -> 638 -> 319 -> 958 -> 479 -> 1438 -> 719 -> 2158 -> 1079 -> 3238 -> 1619 -> 4858 -> 2429 -> 7288 -> 3644 -> 1822 -> 911 -> 2734 -> 1367 -> 4102 -> 2051 -> 6154 -> 3077 -> 9232 -> 4616 -> 2308 -> 1154 -> 577 -> 1732 -> 866 -> 433 -> 1300 -> 650 -> 325 -> 976 -> 488 -> 244 -> 122 -> 61 -> 184 -> 92 -> 46 -> 23 -> 70 -> 35 -> 106 -> 53 -> 160 -> 80 -> 40 -> 20 -> 10 -> 5 -> 16 -> 8 -> 4 -> 2 -> 1
1001 -> 3004 -> 1502 -> 751 -> 2254 -> 1127 -> 3382 -> 1691 -> 5074 -> 2537 -> 7612 -> 3806 -> 1903 -> 5710 -> 2855 -> 8566 -> 4283 -> 12850 -> 6425 -> 19276 -> 9638 -> 4819 -> 14458 -> 7229 -> 21688 -> 10844 -> 5422 -> 2711 -> 8134 -> 4067 -> 12202 -> 6101 -> 18304 -> 9152 -> 4576 -> 2288 -> 1144 -> 572 -> 286 -> 143 -> 430 -> 215 -> 646 -> 323 -> 970 -> 485 -> 1456 -> 728 -> 364 -> 182 -> 91 -> 274 -> 137 -> 412 -> 206 -> 103 -> 310 -> 155 -> 466 -> 233 -> 700 -> 350 -> 175 -> 526 -> 263 -> 790 -> 395 -> 1186 -> 593 -> 1780 -> 890 -> 445 -> 1336 -> 668 -> 334 -> 167 -> 502 -> 251 -> 754 -> 377 -> 1132 -> 566 -> 283 -> 850 -> 425 -> 1276 -> 638 -> 319 -> 958 -> 479 -> 1438 -> 719 -> 2158 -> 1079 -> 3238 -> 1619 -> 4858 -> 2429 -> 7288 -> 3644 -> 1822 -> 911 -> 2734 -> 1367 -> 4102 -> 2051 -> 6154 -> 3077 -> 9232 -> 4616 -> 2308 -> 1154 -> 577 -> 1732 -> 866 -> 433 -> 1300 -> 650 -> 325 -> 976 -> 488 -> 244 -> 122 -> 61 -> 184 -> 92 -> 46 -> 23 -> 70 -> 35 -> 106 -> 53 -> 160 -> 80 -> 40 -> 20 -> 10 -> 5 -> 16 -> 8 -> 4 -> 2 -> 1
1002 -> 501 -> 1504 -> 752 -> 376 -> 188 -> 94 -> 47 -> 142 -> 71 -> 214 -> 107 -> 322 -> 161 -> 484 -> 242 -> 121 -> 364 -> 182 -> 91 -> 274 -> 137 -> 412 -> 206 -> 103 -> 310 -> 155 -> 466 -> 233 -> 700 -> 350 -> 175 -> 526 -> 263 -> 790 -> 395 -> 1186 -> 593 -> 1780 -> 890 -> 445 -> 1336 -> 668 -> 334 -> 167 -> 502 -> 251 -> 754 -> 377 -> 1132 -> 566 -> 283 -> 850 -> 425 -> 1276 -> 638 -> 319 -> 958 -> 479 -> 1438 -> 719 -> 2158 -> 1079 -> 3238 -> 1619 -> 4858 -> 2429 -> 7288 -> 3644 -> 1822 -> 911 -> 2734 -> 1367 -> 4102 -> 2051 -> 6154 -> 3077 -> 9232 -> 4616 -> 2308 -> 1154 -> 577 -> 1732 -> 866 -> 433 -> 1300 -> 650 -> 325 -> 976 -> 488 -> 244 -> 122 -> 61 -> 184 -> 92 -> 46 -> 23 -> 70 -> 35 -> 106 -> 53 -> 160 -> 80 -> 40 -> 20 -> 10 -> 5 -> 16 -> 8 -> 4 -> 2 -> 1
1003 -> 3010 -> 1505 -> 4516 -> 2258 -> 1129 -> 3388 -> 1694 -> 847 -> 2542 -> 1271 -> 3814 -> 1907 -> 5722 -> 2861 -> 8584 -> 4292 -> 2146 -> 1073 -> 3220 -> 1610 -> 805 -> 2416 -> 1208 -> 604 -> 302 -> 151 -> 454 -> 227 -> 682 -> 341 -> 1024 -> 512 -> 256 -> 128 -> 64 -> 32 -> 16 -> 8 -> 4 -> 2 -> 1
Жирным выделены значения, совпавшие с предыдущим вычислением.
Если нужно совсем просто, можете мою поделку попробовать. Работает как простой SOCKS5 прокси, в браузере нужно только
proxy.pacпрописать (пример файла есть в репке).Технически - да, такая возможность есть. Скорее всего можно без изменений скомпилировать под нужную архитектуру. Физически я вряд ли буду этим заниматься из-за отсутствия нужного оборудования.
В поле setup script нужно указывать URL, а не относительный путь к файлу на диске. URL будет выглядеть примерно так:
file:///D:/my-path/proxy.pac. В начале префиксfile:///, дальше полный путь к файлу через/(можно из проводника скопировать и заменить слеши). Альтернативно можете прокси в ручную указать без URL: host -127.0.0.1; port -1080; protocol - SOCKS5.В окошке нет информации потому что по умолчанию логи отключены, нужно добавить переменную окружения
RUST_LOG=no_dpi_socks=debug. Тогда программа будет обо всех событиях писать, но пока прокси не указан правильно там будет только информация на каком порту он запущен.PS: если не получится настроить лучше напишите в личку или в Телеграм.
Если совсем кратко, то алгоритм такой:
Получаем запрос на соединение от браузера, обрабатываем его как обычный SOCK5 до установки соединения;
Вычитываем первые 1024 байта от браузера и передаем по одному байту на пакет (пассивный DPI не может склеить эти пакеты и найти в них имя хоста);
После первых 1024 байт остальной трафик идет как есть что получили то и отправляем;
Обратный трафик от сервера в браузер передаем как есть, без разбиения на маленькие пакетики.
Если интересно посмотреть код - вот репка (написано на Rust). Реализация находится в
src/main.rs, логики там строчек на 50, остальное: протокол SOCK5 и обработка ошибок.У меня он уже больше недели работает на двух компьютерах с Linux и Windows, за это время ни каких проблем с YouTube не заметил.
Физически он у меня на компе на
localhost:1080висит, при подключении немного меняет исходящий поток к провайдеру. Фактически провайдер ни какого SOCKS не видит. Я выбрал SOCKS только из-за удобства перенаправления в него трафика с разных сайтов средствами браузера.У меня все локально на компьютере работает, без сторонних серверов. Принцип такой: после соединения, первый пакет отправляем по одному байту на пакет, остаток идет как есть. По сути упрощенная версия локальных программ для обхода, без изменения порядка и содержимого пакетов.
В первый день, когда YouTube перестал открываться, я написал себе простой SOCKS прокси и
proxy.pac, который только YouTube в него заворачивает (что интересно medium тоже через него заработал). Сейчас сижу через него, и пока он работает работает ставить что-то другое не планирую, тем более лезть в роутер с риском без интернета остаться.