Перейти к содержанию
    

iiv

Свой
  • Постов

    2 771
  • Зарегистрирован

  • Посещение

  • Победитель дней

    2

iiv стал победителем дня 4 декабря 2023

iiv имел наиболее популярный контент!

Репутация

16 Хороший

3 Подписчика

Информация о iiv

Retained

  • Звание
    Array

Посетители профиля

17 168 просмотров профиля
  1. я про них тоже подумал, когда тему увидел. Но вспомнил тот гемор, с которым 67ГГц радар в Боше распознает встречную машину на расстоянии от 15 метров (я в команде разработчиков в 2022 году был) и решил не советовать - размер цели - существенно меньше, расстояние может быть существенно дальше, дешевые решения имеют существенно хуже чувствительность, чем то TI решение, что использовалось в Bosch, и смею предположить, что просто не получится. ИМХО, даже ультразвук будет надежнее, хотя, как я писал, по обычному звуку на микрофонной решетке. Из дешевых только однобитный узконаправленный датчик температуры на двухосевом гимбале просматривается или честный компьютер-вижн на esp32-дуинке, но, далеко не на ардуиноподобном софте, а лучше обе технологии в паре. А то, что коптеры 400км/ч летают - не смешите тапочки нашего форума. Да, коптеры тоже могут так летать, но не в контексте ТС. То, что в контексте ТС полетит с примерно 20м/с.
  2. ТС озвучил утопическую для реального поля боя задачу. Дрон-агрессор - обычно имеет самолетный тип и передвигается довольно быстро. Дрон-перехватчик, который тут обсуждается - это классический квадрокоптер, летящий на порядки медленнее. Единственный вариант, когда теоретически дрон-перехватчик еще может успеть перехватить, это если дрон-агрессор летит на тебя и ты бросаешь дрон-перехватчик на сближение. Но в реальности - ты всегда видишь только уже удаляющийся дрон, даже хотя бы из-за того, что когда он приближается, он обычно шумит существенно меньше, чем когда удаляется - этому уже научились обе стороны конфликта. Поэтому тут все эту тему и обсуждают, понимая, что она никогда не попадет туда, где идут реальные боевые действия.
  3. согласен, что цена списка компонент - не есть супер ключевое, что определяет разработку и как раз Ваш совет (спасибо!!!) и совет уважаемого _pv отговорили меня использовать ttl в витой паре. Но помех много, и надо что-то делать, а найти контроллер на 4 USB которые еще и хостом и девайсом могут прикидываться, получается очень не просто. Да и надежность нужна, вот и мечусь в поиске адекватного решения. это отладить - застрелиться, и схематику (из-за не предсказуемости витой пары у USВ), и на уровне верилога. На контроллерах, конкретно со внутренней 320КБайт памяти - имхо значительно проще будет, тем более, что у них ноги как у плиски переконфигурируемые, то есть если сейчас 1-вый шлет в 3-тий, то я выбираю между контроллерами те ноги, чтобы их по SPI скоммутировать и шлю между контроллерами по такой шине. Да, будет немного больше задержка, но по крайней мере впритык к 12МБит/с можно слать и как-то угадать по поводу конфигурационных сигналов, возможно поставив какую-то программную синхронизацию через эти USB.
  4. да, соединяю между собой свои блоки компьютер вижиона. А что кроме USB то еще можно попользовать? Делать длиннючие гибкие платы и на них гонять сигналы - не реально, они шумов наловят, надо что-то экранированное. Да и питание надо как-то протаскивать, звездой не удобно получается.
  5. Спасибо большое всем, что советуете. Похоже будет надежнее в каждый мой юнит поставить по 4 штуки самых дешевых esp32-c3 (это которые однопроцессорные с USB), в виде микросхем. По идее если от каждого к каждому прокинуть 4 пина и еще 4 пина прокинуть на головной модуль, то любая конфигурация будет реализуема, а все остальное разрулить софтвером и подбуферизовывая такие передачи внутренней памятью. При цене меньше бакса за микросхему это по идее дешевле любого twisted pair конвертера и полностью совместимо. забить на все эти премудрости с питанием и просто пустить по самому проводу 20V, не показывая этим esp32-c3 что там так много напряжения. Тогда как бы я не воткнул провода, у меня один бы становился хостом, а один - слейвом, но коммуникация шла бы по родному для USB протоколу. По крайней мере все передачи данных до 12МБит/с будут работать.
  6. Вы как-то писали (возможно даже уточняли мне в личку), что уже смогли сделать свой нанопоровый секвенатор, и, честно говоря, я очень за вас рад. Раз вы его сделали, зачем же вам завязываться на спартан, сейчас есть просто уйма других альтернатив плисок, а, раз софтвер у вас свой, так проще возьмите и перенесите, чем латать старые поры и старые плиски. Нет?
  7. то есть внутри провода штеккер по разному соединяется? Ведь в самом штеккере 5 пар, tx1+/tx1-, tx2+/tx2-, rx1+/rx1-, rx2+/rx2-, d+/d- да, у меня те же подозрения возникали. А если каждую витую пару объединить и по каждой из них свою ногу SPI посылать? у меня на обоих сторонах мое железо. Я как раз планировал забить на PD и только использовать сами провода, чтобы не мудрить со штекерами. Просто физически у меня много единиц модулей и я хочу между ними реализовать что-то на подобие Parallel Virtual Machine и иметь гарантированную латентность для передачи коротких (старт/стоп) сообщений. Причем одновременно попользовать питание этого USB, так как на одном-двух модулях у меня приходит внешнее питание, сами модули не прожорливые, но такая конструкция бы позволила бы и данные передавать и питание. То есть у меня конечная цель такова: есть 10-20 модулей, физически расположенных на 50-200см расстоянии друг от друга и я не могу проложить провода от одного ко всем. Модули не прожорливые (5 ватт примерно потребление), внутри каждого есть DC-DC. На один-два, а может три модуля приходит внешнее питание примерно 15-20В. Мне надо: 1. перераздать питание по всем модулям, 2. соединить все модули так, что всреднем каждый модуль был соединен с 2-4 другими и данные по каждому соединению идут дуплексно и синхронно с гарантированной латентностью управляющего сигнала (одного пина да/нет) около 100нс, и средней скоростью передачи точка-точка около 10МБит/с. Так как модули сидят не на одной плате, а на устройстве и межу ними есть только определенные маршруты расположения проводов, и окружение имеет много помех от электромоторов, а вес соединения очень важен, пытаюсь найти разумное решение. Много раз использовал обычные USB для передачи одного аналогового сигнала на разумные расстояния во всяких CNC, вот и предположил, что и для этой задачи можно воспользоваться USB проводами, чтобы не конфекционировать провода со штеккерами под эту задачу. Как я говорил, размер, вес и стоимость - играют роль. то, что USB гораздо лучше подходит для длинных (метровых) соединений - полностью с Вами соглашусь, но вот организовать по 4 соединения от каждого модуля на несколько их соседей по USB - та еще задача. Я даже МК не нашел, который бы поддержал бы 4 USB порта одновременно, а ставить USB - хабы в моем случае не вариант - у меня нет главного МК, все просто в сети. Причем какой-то из них может отвалиться, но работать все должно и дальше. Конечно чисто теоретически можно у каждого модуля внутри поставить 4 esp32, от каждого вытащить во внешний мир свой USB по D+/D-, а эти 4 штуки esp32 между собой и с самим модулем чем-то типа октал-spi соединить, но вроде это перебор.
  8. Добрый день, заметил, что часто в моих подделках мне надо передавать данные и питание с одного модуля на другой в синхроном виде на примерно метр-два и в хорошо заэкранированном кабеле. Конкретно надо 2-3А на 15-20В передавать и дуплексный SPI на скорости около 8-16МГц и хотя бы еще один сигнальный пин (то есть суммарно 5 сигнальных проводов). Обычный многожильный шлейф даже с промежуточными земельными жилами такую скорость на такое расстояние уже еле-еле тянет, а для питания приходится еще дополнительно пару проводов прокладывать. Число соединений в аппаратуре у меня большое, около 15 точка-точка соединений. Правильно ли я понимаю, что если на плате развести USB-C коннектор и в него соединить обычный кабель для данных USB-C 3.1 стандарта, то по VBUS / GND я могу проложить питание до 20В/5А, а на любые 4 провода из D+/D-/TR*/RX* проложить свои 5 сигнальных пина (4 SPI + еще один сигнальный)? Если да, то на какие из них правильнее? Да, я знаю, что в некоторых дешевых USB кабелях есть только D+/D-, но вот вопрос, как отличить дешевый от не дешевого, и какие еще три кроме D+/D- еще задействовать на сигнальные и стоит ли какие-то провода вместе соединять (TX1 c RX1 например) или какие-то из них дополнительно использовать для питания? Сами USB штекеры будут потайными и пользователь аппаратуры в них не сможет воткнуться. Спасибо!
  9. или по таймеру, или по заряду, что быстрее настанет. Нагрузка включается только в определенное время с очень хорошей точностью (плюс-минус пару наносекунд) и тактируется от очень хорошо стабилизированного кварца с единицами ppb (не ppm). Между стартами нагрузки тоже должны иметься паузы в работе на 3 микросекунды тоже в предопределенное время. То есть синхронный вариант как предложил Plain (спасибо огромное!!!) мне как раз идеально подходит. Скорей всего совсем правильнее будет работать на частоте например 100кГц, и делать паузы по одному периоду, то есть 9 периодов работы, потом пауза, и так 5 раз, а по окончании запуск нагрузки.
  10. влажные мечты, разбивающиеся о реальность: маленький отражатель толку никакого не даст, большой (20+ см в диаметре) - будет иметь большое сопротивление воздуха, не малый вес, и мешать полету антидрона, также его нужно будет посадить на двухосевой гимбал, а с такими габаритами это ой как не реально сложно, ну и питалово к нему тоже не совсем халявное, хотя, если не считать батарейки, оно будет самым легким из всего.
  11. Это с FPV такой сигнал идет, но это не означает, что других дронов без таких сигналов не бывает.
  12. у меня некоторые камеры с трансфокатором (5-60 градусов), но для ТС 60 подойдет
  13. Объектив: Рыбий глаз + Time-of-Flight-камера + Импульсная подсветка ИК диодами или лазерами. не согласен: рыбий глаз должен быть на очень много мегапикселей помноженных на приличный fps, иначе в нем ничего не видно, а это приводит к большим и дорогим железкам, типа AGX. TOF (если обычный Китай) видит максимум на 5 метров, подсветка ИК диодами и лазерами - я не спец, но у меня они есть и я их интенсивно использую, но тоже больше 2-3 метров от них толку нет. единственно, что приходит в голову и что у меня хоть как-то работает - пассивная микрофонная решетка. Но нужна рама над вашим дроном, и на раме с пару десятков микрофонов, и то я не гарантирую, что все поедет, но на микрофонах, ИМХО, довольно реально. Гуглить на Сидриополиса в начале 2000 и три-вей декомпозишн.
  14. на дешевых компонентах и с маленьким бюджетом - повеситесь от безысходности и от того, что ничего не будет работать.
  15. Позвольте набросить свой опыт на вентилятор дискуссии. Если взять достаточно быструю для ардуинок камеру (60фпс на 640х480) и в ней целевой дрон будет виден не только пикселом, но хотя бы на 2-3 пиксела размазанным объектом, то я бы поставил такую камеру, воткнул бы ее на любой по настроению esp32 или аналог, и средствами компьютерного зрения и 9DOF задачу бы решил бы. То есть фактически надо, чтобы антидрон своей камерой был направлен на цель, вы нажимаете на нем на кнопку старта, он далее сам летит и все время держит в поле зрения то, что ему надо. Цена вопроса такой камеры - 5-7 бакс с алиэкспресса, процессора 3 - бакса, 9DOF - с десяток бакс + плату надо разработать и софт написать, может пяток DC-DC поставить, ибо все это барахло на разные напряжения живет. У меня дроны большие - почти метр в размахе, на расстоянии 30 метров один дрон другого компьютер вижином видет идеально, причем у меня как раз такие простые камеры стоят, правда это - на фоне неба и не ночью. Ночью так не получится, также не получится на фоне деревьев. На фоне неподвижного ландшафта (стены, например) должно получиться. Облака мешать не будут, у них цветность от дрона будет сильно отличаться и движутся они не с той же скоростью как дрон-цель. Из используемых алгоритмов надо гуглить на оптикал флоу и лапласиан эмбеддинг (алгоритм такой к встраиваемым железкам не имеющий отношение). При желании на esp32 это все с трудом, но залезает, но надо реально приложить усилия. В Джетсон влезает проще, а в AGX Orin - совсем на раз из коробки, но он и стоит почти на три порядка дороже. EDIT: по радиоканалу получать трафик и на земле обрабатывать направление полета я бы не решился - когда трафик от такой камеры жмешь, то на сжатом контенте алгоритмы типа оптикал флоу плохо работают.
×
×
  • Создать...