Это уклон по карте, это другое. IMU определяет ориентацию робота а этот расчёт уклон отсканированной поверхности, чем он круче тем выше его стоимость от 1 до 252 на карте. Таким образом планировщик при планировании пути по карте может понять на полоской 2д карте, что здесь есть уклон и на сколько он большой. IMU нужно что-бы робот непосредственно сам на этот уклон заехал и тогда по ориентации робота он сможет определить крутизну уклона.
Звучит как вопрос к Ublox. На NMEA помойму нет сообщений с DR, и вообще позиция Ublox по NMEA такая, что это текстовый протокол он человеко ориентированный старый это legacy, требует парсить строки текста что-бы переводить их в бинарный машинный код для устройства а UBX это бинарный протокол для общения машины с машиной сразу байтиками он более удобен и компактен (в бинарном виде данные предаются быстрее т.к. занимают меньше байт и могут загружаться сразу в ОЗУ без парсера) и потому развивают именно его!
А вы какие сообщения из протокола UBX парсите? Насколько мне известно для DR отдельные сообщения в UBX предусмотрены стандартные отдают стандарную GPS позицию и с корость без DR. Также на вашейм Ublox-то вообще imu распаян, вы видели? Или требуется внешний imu развести на плате, если да он есть на плате?
нужно решить гораздо более фундаментальную задачу — научить мобильную платформу нормально перемещаться между заданными точками.
Я давно решаю эту фундаментальную задачу, и, честно говоря, конца и края ей не видно. Если вкратце, то карты в ROS (в частности, costmap) оставляют желать лучшего. Карта представляет собой огромный массив данных, который хорошо параллелится, но в ROS он обрабатывается на CPU. Из-за этого карта обновляется медленно и на небольшом участке.
При этом на GPU можно легко в реальном времени (например, на частоте 60 Гц) обновлять кусок карты 800х800х100 с разрешением 10 см. Это примерно 6 400 кв. м., то есть 40 метров впереди робота. Для дешевого 3д лидара этого вполне достаточно, так как он видит не далее чем 40 метров тёмные предметы такие как дорога. В ROS же скользящее окно составляет всего 5х5 (25 кв. м) или 10х10 (100 кв. м.) метров, чего для улицы явно мало, ведь машины и пешеходы преодолевают это расстояние слишком быстро. В общем, построение карты нужно переносить на GPU, так как использовать для этого CPU — архаизм.Сам алгоритм построения карты в ROS тоже примитивный, или 2д срез или проекцию карты сверху вниз строит в costmap в которой роботу доступны далеко не все зоны где он может проехать.
Существующие планировщики (SmacPlanner Hybrid A*, State Lattice) работают медленно, поскольку тоже задействуют CPU. Пути они ищут плохо, особенно для ходовой Аккермана: робот порой заезжает в тупик, а выехать обратно задом по тому же пути уже не может. Примитивы приходится закладывать большие, с запасом, чтобы контроллеры могли по ним нормально идти. Однако тот же State Lattice не позволяет бесконечно увеличивать их размер — слишком большие примитивы не сходятся в сетке. Приходится балансировать на грани, ведь чем больше примитив, тем плавнее маршрут и тем легче контроллеру вести платформу.
Что касается контроллеров, то радует появление более современного решения с поддержкой CUDA mppi т.к. контроллеры прогностические с моделью едят много ресурсов и особенно MPPI. Но без обработки карты на CUDA его смысл частично теряется, контроллер работает быстро и прогнозирует далеко а карта маленькая, не раскрывает его потенциал. Тем не менее разработчикам всё равно спасибо. Правда, модель оставили примитивную — кинематическую. Хотя в MPPI Generic есть примеры моделей, поддерживающих динамику, моделирование сил инерции, трения и заноса. Это необходимо для того, чтобы базовая кинематика работала точнее, а MPPI понимал, что колёса при повороте плугуют и мог разворачиваться на месте с учётом ограничений ходовой, и парковаться правильно.
Одометрия во всех стандартных пакетах идет без детектирования планарных сцен, так что этот узел снова придётся собирать самостоятельно и настраивать переключение на резервный источник. Динамические препятствия тоже нужно детектировать своими силами. Всё начинается с поиска движущихся точек: большинство систем одометрии внутри себя их рассчитывают и фильтруют, но наружу не выдают. Они отдают очищенные облака, а сами подвижные точки — нет. А значит, опять придётся изобретать велосипед.
Примерно так выглядит RoadMap для решения задачи «научить мобильную платформу нормально перемещаться между заданными точками». И это уровень еще даже не Яндекс ровера (там нейросети распознают прохожих, тротуары, преграды на пути не геометрические, дорожные знаки, разметку и т.д. ), а просто базовой езды по координатам на улице.
Ок, я python не знаю( и никогда на нем ничего не кодил, только на C/C++. Робот похоже на самодельных серводвижках с as5600 не на китайских сервах, что хорошо значит по координатам будет работать плавно если грамотно всё сделать.
Вот скажите Владимир, этот код который вы выложили, вы хотя-бы в симуляторе проверили? Или на вашем самодельном манипуляторе? Если да, почему не добавить в статью gif анимации/видео как оно работает. Если нет и это просто сгенерированный LLM код, оторванный от реальности не выкладывайте его, LLM сочинят всякий бред который зачастую выглядит очень правдоподобно.
Плохо осоциируется с картой 5х5. Но за проделанную работу и написанный с 0ля код + ставлю. Надеюсь это не сплошной вайб кодинг и вы понимаете как это работает.
Я просто хоббист, потому перебирал всё подряд. У меня большой опыт использования/эксплуатации этих программ, как их завести на камере. А вот как исправить проблемы я не знаю(. Хотя решения однозначно есть:
Ну давайте более точно дадим определение D455 это RGB-D камера с imu где всё синхронизированно и откалиброванно на заводе зашито в EEPROM камеры. Она может работать с ИК проектором а может и без ИК проектора т.е. это kinect 360 что без ИК не работает, это стереокамера где ИК нужен что-бы работать ночью и на однородных поверхностях. Но речь не о камере, камера просто заводская а значит хорошая и там всё по уму. Речь о SLAM/VIO алгоритмах они работают по текстурам. Почему? Потому-что матрица камеры мерит только интенсивность точки т.е. силу отражёного света. Цветная камера фильтрует его через маску Байснера на матрице по 3м основным цветам но в основе тоже измерение силы света. Света откуда? От текстуры отражёного, значит в отличии от лидара камера именно, что по текстурам работает и причём вообще любая, а о дистанции физически вообще ничего не знает в отличии от лидара. ИК проектор лишь накладывает на бедные текстуры свой паттерн/текстуру но принцип работы не меняется сопастовление светящихся точек на матрице. Так вот, способ которым алгоритмы vio/vslam переводят точки на текстуре в координаты робота страдает теме-же балячками, что и у лидарных SLAM/LIO дегенерационные сцены. В одном из моих тестов на видео машина едет по полю, где точек очень много! Около 6000 нашли детекторы а одометрия упала и не поднимается пока машина не подезжает к лесополосе там одомитрия поднимается сама и работает ровно до тех пор пока лесополоса не кончится и снова не переходит в поле. Что получается? Точки есть? Есть. Их много? Много! Но работает только там где есть геометрия как и лидар, хотя… хотя ориентируется по текстурам и они некуда не делись. Мне кажется это главная беда т.к. камера не реализует своё главное преймущество ориентирование на плоскости где лидар в принципе не способен найти геометрию. И следовательно как-то сопаставить кадры т.к. они все абсолютно одинаковы точки на плоскости в разных местах. А вот в плане текстур в поле не полный текстурный ноль, наоборот их много с избытком! Машина едет прямо это линейное движение + едет медленно motion blure на globall shutter днем почти нет. Это всё наводит на мысль как-будто где-то внутри vio/vslam камеры используется тот-же ICP принцип как и у лидара но работающий через костыли в виде триангуляции точек и наследующий все болячки лидара а чего-то нового, что лидар не может не добавляет. Вот надеюсь уточнил.
Тестировал их как-то на своей камере D455 и вот такой вопрос возник. В сценах насыщеных геометрией лидар всем лучше в качестве источника одометрии или как SLAM, он точнее и надёжнее даёт одометрию, дальше видит и на 360 градусов сразу, + видит ночью. Едиственный нюанс что-бы лидар стал полностью надёжным это геметрически деградированные/планарные сцены в которых геометрии нет есть только текстуры. И вот казалось-бы есть камера, что на 100% ориентируется по текстурам но как так получилось, что ей тоже нужна геометрия и в планарных сценах она не работает, в чём тогда её смысл и всего этого vslam, vio? Быть худшим вариантом одометрии лидарной но при этом потребляя больше вычислительных ресурсов.
Магнитное поле, которое создали рельсы и сама дуга, начинает давить на эту самую дугу и с бешеной силой гнать ее вперед по стволу, как невидимый поршень. А дуга уже физически толкает перед собой любую болванку.
Ну знаете есть ещё такой опыт, берут медь замораживают и кладут на электромагнит она левитирует или берут 2 магнита между ними кидают медную болванку она замедляется, без всякой дуги в меди в момент движения наводятся токи и на них действуют магниты. Дуга-же насколько я помню явление паразитное и с ним долго пытались бороться разработчики рельсотронов что-бы увеличить их ресурс.
Я про такой реилган, что стреляет алюминием: https://www.youtube.com/watch?v=KMT97bqaOdM Тут в общем-то всё показано, в плазму снаряд не превращается тут. Я честно скажу рельсотроны не строил не знаю как вы и описание с моих слов + ИИ т.к. не силён в терминологии. Всё что я описал тут есть. Момент с извлечением алюминиевой болванки: https://youtu.be/KMT97bqaOdM?si=9xngcJLNaoF2u4pg&t=145
Моё уважение автору, что на деле достиг 4% КПД, как я ранее уже писал как награда автору я считаю это мало но, но на деле у серийной пушки Гаусса GR-1 ANVIL КПД всего 2,8% а это заводское изделие! Так-что хоть я и нуб понимаю реальную величину этих достижений. Я просто диванный эксперт подтвердить свои слова мне не получиться, извиняюсь за свой высер, был не прав(.
Также могу сказать и про робототехнику и рыбалку, и что угодно! Ну не бывает так что-бы хобби стало работой без последствий, везде где приходит бизнес человек в 1ю очередь превращается в обьект эксплуатации и разве-что собственники и начальничники могут реализовывать там свои амбиции как вас сильнее поэксплуатировать. В общем если вы творческий человек и вы думаете, что сможете заниматься своей фигней и вам будут платить за это бабки не будут, своя фигня отдельно а бабки отдельно и будет тогда у вас настоящий творческий полигон а так только отвращение как вы заметили.
Я вот уже несколько лет занимаюсь программированием на C++, cuda, OpenGL исключительно как хобби и одно удовольствие получаю решать интересные, творческие задачи и делать свой ровер. А ранее я работал на производстве с роботами промышленными и на агродронах так там из-за отвественности, рисков за дорогое не своё оборудование, сроков и обьёма работ было одно выгорание и желания заниматься железками никакого не было вообще смотреть на них не мог! Да даже у себя в ровере я бывает завязну в сложной задаче на месяц она меня достанет я брошу его. Могу полгода к нему не подходить, потом как-то сама идея, и желание что-то поделать приходит, ага получилось решил и пошло снова, стал двигаться дальше, кто-то из инвестров будет терпеть такие передышки по пол года или у меня щас нет настроения/желания делать? А это важно что-бы не выгореть! Это ведь от души а не за бабки или из-под палки делается! И делается да, то что ты хочешь и как ты хочешь а не то, что тебе сказали начальники наверху вчера надо, иначе это уже не творчество а наим. Так-что оплачивать все свои хотелки и отдых можно только из своего кармана. Работа должна-быть простой и что-бы было много свободного времени зарабатывать и финансировать ваше проживание и творчество.
Между рельсами должна-быть алюминевая болванка (которая служит подвижной перемычкой), что их замыкает, сама дуга т.е. электрический разряд вытолкнуть диэлектрический снаряд не сможет. Да и он не магнитный вообще с полем не взаимодействует… А как-же тогда вылетает? В снаряде/перемычке наводятся токи именно они взаимодействуют с магнитным полем рельсы т.е. сила Лоренца толкает снаряд через электроны, которые текут в перемычке и передают импульс кристаллической решетке металла. А главное что-бы вокруг рельсов возникло магнитное поле через них нужно пропустить огромный ток, во много раз больше сварочного, если вы варили сваркой то знаете если электрод не качественный и плохо закушен держателем электродов там может загорется дуга и тогда медь на нём сгорает от дуги очень быстро и электрод с 1-2х раз уже начинает болтаться т.к. форма пропилов в меди сразу плавится а края обгорают, а тут такое твориться каждый раз и это нормально вообще считается.
У меня другой проект, ровера что должен ездить outdoor, на который уходит всё свободное время и средства и не смотря на то что делается он уже не 1 год, конца и края этой работе не видно. Пушка Томпсона, безусловно интересна с технической точки зрения и как инженерный вызов… но практически бесполезна для меня (т.е. такое-же хобби) а вкладываться надо и вероятно не мало те-же кондёры щас стоят, магнитопровод на ней по хорошему надо делать он в 2-2.5 раза увеличивает силу катушек и может сфокусировать поле в одном месте для отталкивания, но его изготовление это материальное производство если есть к нему доступ хорошо а если нет, надо куда-то мататся искать, я за 3д печатью то мотаюсь в край нигде нет… В общем за прокаченую версию версию я-бы взялся но времени нет и средств, после ровера только, если доживём до этого вообще.
Тогда надо писать свой симулятор и всю пушку в симуляторе моделировать, что-бы точно подгонять катушки, конденсаторы и т.д.
Снаряд это алюминевое или медное кольцо в нем от резкого включения катушки должны появиться токи Фуко, что и будут его выталкивать di/dt в общем тут как-раз есть, что посчитать на МК время и позицию снаряда для включения катушки - задержки на переключение. Плюсом схемы на выталкивание является то, что в отличии от втягивания гвоздя, магнитное насыщение кольца наступает гораздо позже а значит теоритический КПД должен-быть выше.
Есть такой опыт кольцо Томсона или пушка Томсона там кольцо от резкого возникновения магнитного поля успешно вылетает.
О какой скорости речь? Если за переброс энергии то… возможно ну тогда остаётся слить её в кондёр через диод. А вообще stm32 h743 делают TOF датчики, что мерят время полёта света или радиоволн. Комутация на IGBT.
Рекуперация т.е. возвращение энергии возможно есть проекты где энергию сливают обратно в кондер.
Шины было-бы не плохо сделать и магнитопровод в симуляторе расчитать, сфокусировать его в узком кольце вокруг ствола в идеале конечно.
Она одноразавая, выстрел и рельсы сгорели + косая по обозжёным ресам если снаряд летит то как попало, а изготивить их трудно, чисто материальное производства для инженерии в домашних условиях минимум места. Но по эффектам, да выстрел с кучей искр и вспышкой света от дуги будет выглядеть круче.
Это уклон по карте, это другое. IMU определяет ориентацию робота а этот расчёт уклон отсканированной поверхности, чем он круче тем выше его стоимость от 1 до 252 на карте. Таким образом планировщик при планировании пути по карте может понять на полоской 2д карте, что здесь есть уклон и на сколько он большой. IMU нужно что-бы робот непосредственно сам на этот уклон заехал и тогда по ориентации робота он сможет определить крутизну уклона.
Звучит как вопрос к Ublox. На NMEA помойму нет сообщений с DR, и вообще позиция Ublox по NMEA такая, что это текстовый протокол он человеко ориентированный старый это legacy, требует парсить строки текста что-бы переводить их в бинарный машинный код для устройства а UBX это бинарный протокол для общения машины с машиной сразу байтиками он более удобен и компактен (в бинарном виде данные предаются быстрее т.к. занимают меньше байт и могут загружаться сразу в ОЗУ без парсера) и потому развивают именно его!
А вы какие сообщения из протокола UBX парсите? Насколько мне известно для DR отдельные сообщения в UBX предусмотрены стандартные отдают стандарную GPS позицию и с корость без DR. Также на вашейм Ublox-то вообще imu распаян, вы видели? Или требуется внешний imu развести на плате, если да он есть на плате?
Я давно решаю эту фундаментальную задачу, и, честно говоря, конца и края ей не видно. Если вкратце, то карты в ROS (в частности, costmap) оставляют желать лучшего. Карта представляет собой огромный массив данных, который хорошо параллелится, но в ROS он обрабатывается на CPU. Из-за этого карта обновляется медленно и на небольшом участке.
При этом на GPU можно легко в реальном времени (например, на частоте 60 Гц) обновлять кусок карты 800х800х100 с разрешением 10 см. Это примерно 6 400 кв. м., то есть 40 метров впереди робота. Для дешевого 3д лидара этого вполне достаточно, так как он видит не далее чем 40 метров тёмные предметы такие как дорога. В ROS же скользящее окно составляет всего 5х5 (25 кв. м) или 10х10 (100 кв. м.) метров, чего для улицы явно мало, ведь машины и пешеходы преодолевают это расстояние слишком быстро. В общем, построение карты нужно переносить на GPU, так как использовать для этого CPU — архаизм.Сам алгоритм построения карты в ROS тоже примитивный, или 2д срез или проекцию карты сверху вниз строит в costmap в которой роботу доступны далеко не все зоны где он может проехать.
Существующие планировщики (SmacPlanner Hybrid A*, State Lattice) работают медленно, поскольку тоже задействуют CPU. Пути они ищут плохо, особенно для ходовой Аккермана: робот порой заезжает в тупик, а выехать обратно задом по тому же пути уже не может. Примитивы приходится закладывать большие, с запасом, чтобы контроллеры могли по ним нормально идти. Однако тот же State Lattice не позволяет бесконечно увеличивать их размер — слишком большие примитивы не сходятся в сетке. Приходится балансировать на грани, ведь чем больше примитив, тем плавнее маршрут и тем легче контроллеру вести платформу.
Что касается контроллеров, то радует появление более современного решения с поддержкой CUDA mppi т.к. контроллеры прогностические с моделью едят много ресурсов и особенно MPPI. Но без обработки карты на CUDA его смысл частично теряется, контроллер работает быстро и прогнозирует далеко а карта маленькая, не раскрывает его потенциал. Тем не менее разработчикам всё равно спасибо. Правда, модель оставили примитивную — кинематическую. Хотя в MPPI Generic есть примеры моделей, поддерживающих динамику, моделирование сил инерции, трения и заноса. Это необходимо для того, чтобы базовая кинематика работала точнее, а MPPI понимал, что колёса при повороте плугуют и мог разворачиваться на месте с учётом ограничений ходовой, и парковаться правильно.
Одометрия во всех стандартных пакетах идет без детектирования планарных сцен, так что этот узел снова придётся собирать самостоятельно и настраивать переключение на резервный источник. Динамические препятствия тоже нужно детектировать своими силами. Всё начинается с поиска движущихся точек: большинство систем одометрии внутри себя их рассчитывают и фильтруют, но наружу не выдают. Они отдают очищенные облака, а сами подвижные точки — нет. А значит, опять придётся изобретать велосипед.
Примерно так выглядит RoadMap для решения задачи «научить мобильную платформу нормально перемещаться между заданными точками». И это уровень еще даже не Яндекс ровера (там нейросети распознают прохожих, тротуары, преграды на пути не геометрические, дорожные знаки, разметку и т.д. ), а просто базовой езды по координатам на улице.
Ок, я python не знаю( и никогда на нем ничего не кодил, только на C/C++. Робот похоже на самодельных серводвижках с as5600 не на китайских сервах, что хорошо значит по координатам будет работать плавно если грамотно всё сделать.
Хорошо, хотелось-бы видеть больше тестов на практике, особенно на настоящем манипуляторе.
Вот скажите Владимир, этот код который вы выложили, вы хотя-бы в симуляторе проверили? Или на вашем самодельном манипуляторе? Если да, почему не добавить в статью gif анимации/видео как оно работает. Если нет и это просто сгенерированный LLM код, оторванный от реальности не выкладывайте его, LLM сочинят всякий бред который зачастую выглядит очень правдоподобно.
И симулятору не плохо-бы добить визуализатор а то как-то:
Плохо осоциируется с картой 5х5. Но за проделанную работу и написанный с 0ля код + ставлю. Надеюсь это не сплошной вайб кодинг и вы понимаете как это работает.
Я просто хоббист, потому перебирал всё подряд. У меня большой опыт использования/эксплуатации этих программ, как их завести на камере. А вот как исправить проблемы я не знаю(. Хотя решения однозначно есть:
Ну давайте более точно дадим определение D455 это RGB-D камера с imu где всё синхронизированно и откалиброванно на заводе зашито в EEPROM камеры. Она может работать с ИК проектором а может и без ИК проектора т.е. это kinect 360 что без ИК не работает, это стереокамера где ИК нужен что-бы работать ночью и на однородных поверхностях. Но речь не о камере, камера просто заводская а значит хорошая и там всё по уму. Речь о SLAM/VIO алгоритмах они работают по текстурам. Почему? Потому-что матрица камеры мерит только интенсивность точки т.е. силу отражёного света. Цветная камера фильтрует его через маску Байснера на матрице по 3м основным цветам но в основе тоже измерение силы света. Света откуда? От текстуры отражёного, значит в отличии от лидара камера именно, что по текстурам работает и причём вообще любая, а о дистанции физически вообще ничего не знает в отличии от лидара. ИК проектор лишь накладывает на бедные текстуры свой паттерн/текстуру но принцип работы не меняется сопастовление светящихся точек на матрице. Так вот, способ которым алгоритмы vio/vslam переводят точки на текстуре в координаты робота страдает теме-же балячками, что и у лидарных SLAM/LIO дегенерационные сцены. В одном из моих тестов на видео машина едет по полю, где точек очень много! Около 6000 нашли детекторы а одометрия упала и не поднимается пока машина не подезжает к лесополосе там одомитрия поднимается сама и работает ровно до тех пор пока лесополоса не кончится и снова не переходит в поле. Что получается? Точки есть? Есть. Их много? Много! Но работает только там где есть геометрия как и лидар, хотя… хотя ориентируется по текстурам и они некуда не делись. Мне кажется это главная беда т.к. камера не реализует своё главное преймущество ориентирование на плоскости где лидар в принципе не способен найти геометрию. И следовательно как-то сопаставить кадры т.к. они все абсолютно одинаковы точки на плоскости в разных местах. А вот в плане текстур в поле не полный текстурный ноль, наоборот их много с избытком! Машина едет прямо это линейное движение + едет медленно motion blure на globall shutter днем почти нет. Это всё наводит на мысль как-будто где-то внутри vio/vslam камеры используется тот-же ICP принцип как и у лидара но работающий через костыли в виде триангуляции точек и наследующий все болячки лидара а чего-то нового, что лидар не может не добавляет. Вот надеюсь уточнил.
Тестировал их как-то на своей камере D455 и вот такой вопрос возник. В сценах насыщеных геометрией лидар всем лучше в качестве источника одометрии или как SLAM, он точнее и надёжнее даёт одометрию, дальше видит и на 360 градусов сразу, + видит ночью. Едиственный нюанс что-бы лидар стал полностью надёжным это геметрически деградированные/планарные сцены в которых геометрии нет есть только текстуры. И вот казалось-бы есть камера, что на 100% ориентируется по текстурам но как так получилось, что ей тоже нужна геометрия и в планарных сценах она не работает, в чём тогда её смысл и всего этого vslam, vio? Быть худшим вариантом одометрии лидарной но при этом потребляя больше вычислительных ресурсов.
Ну знаете есть ещё такой опыт, берут медь замораживают и кладут на электромагнит она левитирует или берут 2 магнита между ними кидают медную болванку она замедляется, без всякой дуги в меди в момент движения наводятся токи и на них действуют магниты. Дуга-же насколько я помню явление паразитное и с ним долго пытались бороться разработчики рельсотронов что-бы увеличить их ресурс.
Я про такой реилган, что стреляет алюминием: https://www.youtube.com/watch?v=KMT97bqaOdM Тут в общем-то всё показано, в плазму снаряд не превращается тут. Я честно скажу рельсотроны не строил не знаю как вы и описание с моих слов + ИИ т.к. не силён в терминологии. Всё что я описал тут есть. Момент с извлечением алюминиевой болванки: https://youtu.be/KMT97bqaOdM?si=9xngcJLNaoF2u4pg&t=145
Моё уважение автору, что на деле достиг 4% КПД, как я ранее уже писал как награда автору я считаю это мало но, но на деле у серийной пушки Гаусса GR-1 ANVIL КПД всего 2,8% а это заводское изделие! Так-что хоть я и нуб понимаю реальную величину этих достижений. Я просто диванный эксперт подтвердить свои слова мне не получиться, извиняюсь за свой высер, был не прав(.
Ну возможно я и не отрицаю, что нуб в ускорителях и цепляюсь за соломинки, что-бы придумать что-то, что повысит КПД.
Также могу сказать и про робототехнику и рыбалку, и что угодно! Ну не бывает так что-бы хобби стало работой без последствий, везде где приходит бизнес человек в 1ю очередь превращается в обьект эксплуатации и разве-что собственники и начальничники могут реализовывать там свои амбиции как вас сильнее поэксплуатировать. В общем если вы творческий человек и вы думаете, что сможете заниматься своей фигней и вам будут платить за это бабки не будут, своя фигня отдельно а бабки отдельно и будет тогда у вас настоящий творческий полигон а так только отвращение как вы заметили.
Я вот уже несколько лет занимаюсь программированием на C++, cuda, OpenGL исключительно как хобби и одно удовольствие получаю решать интересные, творческие задачи и делать свой ровер. А ранее я работал на производстве с роботами промышленными и на агродронах так там из-за отвественности, рисков за дорогое не своё оборудование, сроков и обьёма работ было одно выгорание и желания заниматься железками никакого не было вообще смотреть на них не мог! Да даже у себя в ровере я бывает завязну в сложной задаче на месяц она меня достанет я брошу его. Могу полгода к нему не подходить, потом как-то сама идея, и желание что-то поделать приходит, ага получилось решил и пошло снова, стал двигаться дальше, кто-то из инвестров будет терпеть такие передышки по пол года или у меня щас нет настроения/желания делать? А это важно что-бы не выгореть! Это ведь от души а не за бабки или из-под палки делается! И делается да, то что ты хочешь и как ты хочешь а не то, что тебе сказали начальники наверху вчера надо, иначе это уже не творчество а наим. Так-что оплачивать все свои хотелки и отдых можно только из своего кармана. Работа должна-быть простой и что-бы было много свободного времени зарабатывать и финансировать ваше проживание и творчество.
Между рельсами должна-быть алюминевая болванка (которая служит подвижной перемычкой), что их замыкает, сама дуга т.е. электрический разряд вытолкнуть диэлектрический снаряд не сможет. Да и он не магнитный вообще с полем не взаимодействует… А как-же тогда вылетает? В снаряде/перемычке наводятся токи именно они взаимодействуют с магнитным полем рельсы т.е. сила Лоренца толкает снаряд через электроны, которые текут в перемычке и передают импульс кристаллической решетке металла. А главное что-бы вокруг рельсов возникло магнитное поле через них нужно пропустить огромный ток, во много раз больше сварочного, если вы варили сваркой то знаете если электрод не качественный и плохо закушен держателем электродов там может загорется дуга и тогда медь на нём сгорает от дуги очень быстро и электрод с 1-2х раз уже начинает болтаться т.к. форма пропилов в меди сразу плавится а края обгорают, а тут такое твориться каждый раз и это нормально вообще считается.
У меня другой проект, ровера что должен ездить outdoor, на который уходит всё свободное время и средства и не смотря на то что делается он уже не 1 год, конца и края этой работе не видно. Пушка Томпсона, безусловно интересна с технической точки зрения и как инженерный вызов… но практически бесполезна для меня (т.е. такое-же хобби) а вкладываться надо и вероятно не мало те-же кондёры щас стоят, магнитопровод на ней по хорошему надо делать он в 2-2.5 раза увеличивает силу катушек и может сфокусировать поле в одном месте для отталкивания, но его изготовление это материальное производство если есть к нему доступ хорошо а если нет, надо куда-то мататся искать, я за 3д печатью то мотаюсь в край нигде нет… В общем за прокаченую версию версию я-бы взялся но времени нет и средств, после ровера только, если доживём до этого вообще.
Тогда надо писать свой симулятор и всю пушку в симуляторе моделировать, что-бы точно подгонять катушки, конденсаторы и т.д.
Снаряд это алюминевое или медное кольцо в нем от резкого включения катушки должны появиться токи Фуко, что и будут его выталкивать di/dt в общем тут как-раз есть, что посчитать на МК время и позицию снаряда для включения катушки - задержки на переключение. Плюсом схемы на выталкивание является то, что в отличии от втягивания гвоздя, магнитное насыщение кольца наступает гораздо позже а значит теоритический КПД должен-быть выше.
Есть такой опыт кольцо Томсона или пушка Томсона там кольцо от резкого возникновения магнитного поля успешно вылетает.
О какой скорости речь? Если за переброс энергии то… возможно ну тогда остаётся слить её в кондёр через диод. А вообще stm32 h743 делают TOF датчики, что мерят время полёта света или радиоволн. Комутация на IGBT.
Рекуперация т.е. возвращение энергии возможно есть проекты где энергию сливают обратно в кондер.
Шины было-бы не плохо сделать и магнитопровод в симуляторе расчитать, сфокусировать его в узком кольце вокруг ствола в идеале конечно.
Она одноразавая, выстрел и рельсы сгорели + косая по обозжёным ресам если снаряд летит то как попало, а изготивить их трудно, чисто материальное производства для инженерии в домашних условиях минимум места. Но по эффектам, да выстрел с кучей искр и вспышкой света от дуги будет выглядеть круче.