И в дополнение к предыдущему комментарию - это промпт для нейросети, который вам поможет понять, что и как давать ребенку, в какой последовательности.
Вот текст для нейросети:
Ты эксперт и учитель в области электроники, электрики, радиоэлектроники и микроэлектроники. Порекомендуй программу обучения ребёнка электронике и электротехнике в возрасте от 7 до 10 лет. Я хочу что бы ребёнок освоил базу и основу электроники, электричества, имел понимание основ и постепенно начал переходить к изучению микроконтроллеров, но не сразу. Разбей программу обучения на этапы (домашнее, самостоятельное обучение). Предложи варианты радиоконструкторов для каждого этапа с набором элементной базы, а так же инструменты для работы.Имей ввиду, что ребёнок должен постепенно, но не очень долго идти от основ радио электроники до программирования микроконтроллеров. Имей ввиду, что диапазон от 7 до 10 лет - это не период обучения, а начальный возраст ребёнка. Разбей программу обучения на 1 год. Не предлагай для ребёнка использования примитивных методов программирования микроконтроллеров. Используй сразу нормальные инструменты и среды программирования на базе C и C++. Напиши все максимально детально. Дополнительно для каждого этапа порекомендуй книги или разделы книг. Был совет использовать книгу “Юный радиолюбитель”
И после этого, вы увидите очень подробный документ, который даст полную информацию о программе обучения.
Я делал запрос в Google.com в режиме ИИ. Это один из самых удобных методов поиска не задействуя какую либо отдельную нейросеть. Но можно использовать любую нейросеть, а то и несколько сразу и получить очень интересные результаты.
Для начала, что бы это было реально полезным - книга, "Юный радиолюбитель", В.Г.Борисов. Это основы, и там все рассказано доступно и грамотно. Как раз для тех, кто очень юный.
И параллельно с этим радиоконструктор, любой на базе Arduino, но начинать не с микроконтроллера, а с основ электричества, изучения сопротивления и емкостей (не тары для жидкостей, а конденсаторов), понимать, что такое ток и напряжение, как работают транзисторы и прочие аналоговые элементы и компоненты.
И дополнительно приобретите паяльник, припой, канифоль и макетные печатные платы. Пусть учится паять сразу. Отдайте ему старые блоки питания от телефонов, в качестве источников питания и с озона или с алиэкспресса купите много резисторов, светодиодов и прочей мелосевки, включая наборы транзисторов, конденсаторов, диодов и всего остального.
Обязательно купите мультиметр и тестер компонентов (тоже с алиэкспресса).
Самое главное: сначала основы, потом микроконтроллеры, иначе будет недопонимание и потом кривые проекты, недовольство тем, что что-то не получается и не целевое использование ресурсов.
Есть много примеров, когда дети начинают делать проекты, сразу на микроконтроллерах, в примитивных программах и когда что-то не получается, уже не могут приступить к более сложным освоениям. Изучать основы, после того, как уже бегает робот (криво, косо и неправильно, но бегает) считают чем-то ненужным и "кринжовым", хотя, если бы сразу изучили основы и базу - то получили бы лучший результат.
Современные дети хотят видеть результат быстро, прям незамедлительно, поэтому им нужно разбивать программы обучения с видимым результатом на каждом этапе. Но это, я так думаю, больше нужно понимать преподавателям, чем родителю.
И ещё, вариант: напишите запрос для нейросети, что вы хотите видеть и как хотите дать ребенку информацию. И узнаете много интересного. Это конечно не истина в последней инстанции, но как дополнение - очень будет классно.
А такой момент: даёт ли каждый новый каскад ускорения эффект?
Вы проверяли установку на 1, 2-х, 3-х и так далее катушках, с наращиванием каскадов/ступеней ускорения.
И ещё, у вас в схеме нет диодов, гасящих обратную эдс катушек. Эта обратная эдс может сильно тормозить снаряд, когда он находится в центре или уже на выходе. И каждую катушку нужно рассчитать так, что бы ток в каждой катушке падал в тот момент, когда снаряд находится в центре каждой катушки.
Каюдая последующая катушка должна быть короче предыдущей и туда нужно подавать все короче и короче импульсы (меньше емкость и толще провод)
Просто лет 15 назад, я собирал гаусс пушку на 1 и на 2-х касакадах и 1 каскад давал основной импульс почти такой-же скорости как у вас указан на 5 касакадах. Вот мне и интересно, а на сколько эффективна установка на 5 каскадах?
Когда я настраивал 2-й каскад, то мне приходилось двигать и оптопары запуска катушки 2 и саму катушку 2, ну и расстояние там было больше чем у вас на фото. Сейчас не вспомню конечно, но визуально было больше, катушки наматывал округлой формы, а не прямоугольной (в боковом сечении) и каждая последующая катушка (у меня вторая и последняя, потому что я не смог найти больше тиристоров для коммутации) была проводом бОльшего сечения, чем предыдущая.
Но даже при этом, скорость выросла на какие-то жалкие 1,5-2 м/с, от энергии 2-й катушки. Её КПД был настолько низким, что можно было не использовать.
Сейчас возможно что-то и поменялось, может расчёты стали лучше и качественнее. Тогда мы все в Excel считали и очень долго. Тестили, записывали и анализировали.
А проект интересный, простая реализация и подача материала! Автору спасибо!
Решение найдено, но не совсем понятно, а что сделали вы?
Нашли готовое решение, настроили и установили? Реально не понято....
Есть множество таких решений и старые Невод-5, и новые китайские модули. Хоть бы аналитику сделали под ваши условия и ТЗ, а то получается, что вы нашли и установили. Все!
Все отлично, и книга и наборы, не радует только Scratch. К сожалению, дети, научившись на простом и примитивном инструменте "программировать" (это можно только в кавычки взять) не желают потом переходить на сложные программные решения. Стараются делать все на аналогичном уровне не развиваются. И процент таких очень высокий. Из 10 только 1-2 продолжают совершенствовать свои навыки. А те, которые сразу изучают на C и C++, из 10 минимум 5-6 детей развиваются и потом делают реальные вещи.
Раньше, нам давали сначала сложные инструменты (это кстати позволяет понять, кто способен идти дальше, а кто нет) а потом мы изучали все остальное. Сейчас же, с вот этими кубиками, есть мнимое представление о том, что кто угодно может сделать что угодно. Но дальше вот этих конструкторов дело не двигается, а человек считает себя гением автоматизации и электроники.
Цели браться за C/C++ у меня нет, даже если это стандарт
Понимаю вас, потому как сам программист, это сложно, но если хотите делать взаимодействие между низкоуровневым железом, то стоит именно изучать и C и C++, потому что это то самое, которое позволяет организовать работу, а не имитацию работы. На остальных ЯП вы сможете сделать что-то подобное, но вам нужны будут аппаратным возможности железа преаышающие базовые требования, иными словами, что бы сделать простой вывод данных вам нужен будет микроконтроллер вмещающий как минимум все библиотеки GO или трпнслятоо Python, а это уже не меньше ESP32-S3, А если делать систему реального времени вам нужен будет RP или что-то серьёзнее.
Вот и начинается избыточность, удорожание, но программистам зато удобно, писать легко и быстро.
Самое печальное, что здесь должна падать стоимость программного кода ввиду того, что это стало быстро и просто, но этого не происходит, потому что программисты верхнего уровня считают что они вкладывают много сил и их код не может стоить дёшево. А потом и код раздувается и требования к железу растут, а итог не меняется, только цена лезет вверх.
На днях наткнулся на статью про датчик температуры, влажности и качества воздуха, которому оптимизировали память, из за сборщика мусора, потому что было переполнение, а объем памяти там был 128 Килобайт. У меня аж челюсть отвисла, когда я прочитал, как и куда там используется память. Это как раз один из примеров, когда используется мощное железо и прикладное ПО. Датчик получается измеряет банальные вещи, по минимальным объемам, а его задействовали как полноценный процессор и пытаются на высокоуровневом языке получить и передать 10 байт банальной информации. Итог - для датчика, стоимостью 2 доллара применяется архитектура за 30 долларов, высокоуровневое ПО, загрузка ядра и памяти на 100%. Чего не должно происходить в принципе, для простых систем.
Получается, что вы используете микроскоп что бы им заколачивать гвозди. Дорого, но эффект есть....
Если это разделить, то нет проблем, но когда прикладные программисты начинают лезть на системный уровень со своим языком (а это сейчас вполне возможно), то чаще всего происходит именно такой диссонанс.
Разделяйте системное и прикладное!
Управление, датчики, автономный системы - это системный уровень, почитайте теорию автоматического управления, протоколы, сигналы, изучите электронику и прочее.
Камера для контроля - это уже прикладной уровень, там творите что хотите, но учтите что от железа, протоколов, сигналов, зависит как быстро получите картинку.
Ну и из этого уже можно сделать симбиоз, качественный и корректный.
Удачи в проектах и не стесняйтесь изучать новое, хоть это и сильно старое...
Ооочень странные датчики. Откуда там такие объёмы памяти? Даже если предположить что на температуру нужен float, на влажность - тоже float, на качество воздуха (хрен с ним, 4 float значений) то получается - 24 байта! Там в 128 килобайтах можно ещё пол года хранить архив! И сетевой стек на килобайт - вы его из чего делаете? Из АТ команд? Даже если предположить, что запаковка данных идёт в json и передача по MQTT то наксребсти такой объем пэто постараться нужно! Или вы инфу в виде JPG или GIF картинки передаете?
Напишите производителя и модель этих датчиков, буду понимать что не стоит приобретать.
Автор, изучай С и С++, если хочешь писать такие приложения на микроконтроллерах.
А Go или Python можешь использовать для написания Web приложений (даже для микроконтроллеров, если располагаешь их не многочисленным ресурсами) ну или на очень мощных микроконтроллерах, если делаешь высоконагруженную систему с нейросетью, или с самостоятельным принятием решений. Один хрен нижний уровень нужно делать не на RP2040, на C и C++.
В ходе предыдущих попыток, сжег два Pico и решил перейти на что-то подешевле
Расскажи, как? Как можно сжечь микроконтроллер такой банальщиной?
Проект для запуска на одноплатнике, в задачи которого входит отправка AT-команд
Т.е. вместо нормальной кодировки одним байтом нескольких команд, ты перешёл на AT команды с тупым парсингом? Бред! И ты на этом хочешь сделать управление по сети?
Так как в планах иметь возможность подключать LiDAR к проекту, у меня есть подозрения, что для такой сборки лучше иметь два аппаратных UART. Те LiDAR'ы, которые я видел, отдают данные на скорости 230400, а у меня основная работа идет на скорости 115200. Есть ощущение, что, работая по одному каналу, придется либо иметь небольшой лаг в данных с LiDAR, либо будут проблемы с ответами от основных команд.
С таким подходом ты лидар увидишь после того, как твоя машинка прилетит в стену.
Ощущение такое, что автор прикладной начинающий программист и пока ещё не понимает принципов обмена информацией на уровне микроконтроллеров и датчиков.
Для динамично системы нужно использовать не меньше чем SPI (желательно самый быстрый), а не UART.
Вычитав в сети о том, что UDP не имеет встроенных механизмов защиты, а заниматься реализацией по этой теме мне показалось не лучшей идеей для MVP проекта, было решено искать другой вариант коммуникации. В качестве способа решил использовать gRPC, где Backend работает с Unary процедурами, а Proxy со Stream.
Нет слов...
Вы вообще что делаете? Машинку с дистанционным управлением по сети или клиент-северное приложение? Хоть немного понимаете или пытаетесь понимать о том, что такое скорость передачи данных, отклик устройства и реакция?
Если собрать всю картину воедино, получается катастрофическая цепочка:
Видеопоток и команды пакуются в тяжелый gRPC (TCP).
Прокси-сервер разрывает поток на Unary-запросы и пинает Бэкенд.
Команды управления превращаются в длинные текстовые AT-строки.
Эти строки летят на слабый чип RP2040.
Программа на Go судорожно пытается распарсить тонны текста, постоянно спотыкаясь о сборщик мусора.
Предполагаемый итог: Это не MVP, это технический мазохизм. Проект соберет комбо из всех возможных видов задержек: сетевых (из-за TCP), серверных (из-за прокси) и вычислительных (из-за парсинга текста в Go на слабом чипе). Машинка будет реагировать на пульт с грацией и скоростью лунохода.
Ну, во первых, я это предложил и в этом вижу рациональное зерно. Как вы сказали из 5 камней - это исключительно для безопасности контроллера. Периферию можно сжечь а мозг останется и поменять 15 центовую периферию проще. Для этого же оптопары и ставят... С вашей логикой можно и битовую логику поставить ТТЛ или КМОП, но я же не обсираю atmega128, я просто высказал свое мнение и увидел, что дискретные входы изолированы оптопарами, а аналоговые - нет.
И потом, никто не отменяет прогресс, я вроде разумно все свои доводы объяснил, не обсирая решения автора, даже наоборот, с уважением к ним, в отличии от десятков комментариев "не в тему" и только автору решать, нужны ему мои советы или нет.
Автор мне ответил и я услышал его мнение! Он вполне красиво и корректно ответил на мои вопросы (а не претензии). Вы же начали критиковать моё мнение и мои предложения... Зачем?
Вот как раз потому. В атмеге уже есть более-менее нормальный АЦП, флеш-память на борту, можно подобрать мк сразу с нужным количеством ног. И бывает, что на 5 В какие-то вещи делать удобнее, чем на 3,3 В.
Вот сейчас не понял.... Почему поэтому?
Вы считаете что 4х канальный 16 разрядный АЦП на Ads1115, который спокойно работает на 5 Вольтах, который можно отвязать I2C изолятором хуже чем 10 разрядный АЦП на меге? И не забывайте, что мега самостоятельно должна измерить аналоговый сигнал, а во внешнем АЦП, чип это делает постоянно и независимо.
И если выгорает АЦП, то это выгорает АЦП, а не контроллер. Изолировать аналоговый сигнал - проблематично, поэтому лучше использовать такие решения. А автор при этом изолирует дискретный сигнал, но не изолирует аналоговый. Вот прилетит потенциал 230В и куда потом полетит этот контроллер?
Какие 3.3В? Откуда они взялись?
Я специально указал чипы, которые работают на 5 Вольтах.
Специально указал на чипы, которые можно изолировать и они применяются в промышленности.
Откуда взялась flash память? И она вообще каким боком здесь?
Все, что было написано относится к улучшению проекта в виде рекомендации и огромного опыта использования сторонних компонентов, элементов и решений.
Между прочим, mcp23017 позволяет сделать и входы и выходы одновременно на одном чипе и микроконтроллер не будет тратить свои входы-выходы на банальщину. Все на интерфейсы, а периферия отдана на сторону
Никто не унижает мегу 128, просто она реально устарела и решение на esp32-s3 + расширители - вполне себе надёжное решение.
Если вы с этим еще не имели дела, то и не стоит говорить что это плохо. Я же не предлагаю перейти на Python и использовать Raspberry PI.
Конечные автоматы (FSM) сложно забыть. В программировании микроконтроллеров FSM - это золотой шаблон проектирования.
Возможно, но если мы их делали ещё на битовой логике и дальше чем И, И-НЕ, ИЛИ, ИЛИ-НЕ, 2И, 3И ну и так далее, дело не доходило, контроллеры в то время были Ремиконты и Ломиконты и более выглядели как логические шкафы. Микроконтроллеров не было в принципе для домашнего или универского использования.
Всё просто. Подергал подтяжку, измерил напряжения на ADC, проанализировал два числа, сделал вывод.
Да, я то понял, судя по комментариям не всем это было понятно. Подал VCC через резистор, измерил, понял что там осталась земля, решил что там лампочка на месте. Если висит VCC в чистом виде, значит "сперли" лампочку.
Да, здесь в статье не совсем понятен механизм контроля, а конечные автоматы - это отдельная тема для понимания, это как давать примеры на Ассемблере человеку, который его не понимает, но при этом отлично программирует на С и С++.
Я мысль понял, но не совсем принцип и как будто бы не законченная статья... Ну вот что-то мы выяснили, а потом...? Какие-то микросхемы, что-то могут, подтягивают к земле, к питанию, ну а дальше? Что измеряют? Короткое замыкание - это токовый замер, обрыв - тоже токовый... Видимо стоит немного уточнить и дораскрыть тему.
Я не так давно делал что-то похожее, но на большее расстояние. Мне необходимо было соединить 2 узла по питанию и первый узел отдаёт питание на второй, но не просто так отдаёт, он должен определить, что отдаёт питание такому же узлу, а не кому-то другому. А питание - 230В и вот тут как раз и получается такая схема с определением того, что на втором конце привязано.
Сначала необходимо посмотреть, не пристегнули ли туда 230В внешних и
если не пристегнули, то нужно проверить, что там висит на конце, подав туда 5В и проверить ток в линии;
если ток в пределах 5-10мА, то поморгать в линию напряжением 5В (на второй стороне стоит схема индикации, что бы человек, подключивший конечный узел понимал, что устройство опознано и сейчас сюда прилетит 230В);
если ток меньше 5 и больше 2мА, отправить проверить линию, есть обрыв,
если более 10мА и менее 30мА, то тоже проверить линию, возможно есть повреждения
Если более 30мА, то считаем что там короткое замыкание или левая нагрузка
И вот когда мы поморгали 4 секунды, то подаём в линию 230В, отключив от линии всю диагностику. И в конечный узел приходит полное напряжение питания 230В, отключая схему низковольтного токового контроля.
Я не расписал ещё логику контроля тока при напряжении 230В, но это уже не важно.
Вот в этой схеме есть логика, есть порядок и да, нет конечного автомата, но есть результаты работы. А что происходит у вас? Подключается или не подключается нагрузка (фара, фонарь, насос и так далее, диагностируется ошибка и выдаётся в виде кода ошибки или просто ничего не происходит?
Я так предполагаю, что подтяжками там дело не заканчивается и какой-то результат должен быть. Возможно я не понимаю суть конечного автомата в данной интерпретации (давно, сильно давно мы их в универе проходили). Попробуйте пожалуйста объяснить проще и доступнее...
Ну я делаю не целевым контроллером свои решения, а как раз более универсальный. По 8 - 16 дискретных входов и выходов, по 4-8 аналоговых 4-20мА входов и выходов, ну и прочие сменные, специальные модули, которые нужны редко. И в формате промышленного ПЛК.
Обычно после прочтения, интересно посмотреть комментарии, вопросы, предложения и прочее, но тут же все увязло в пластике, трубах и в горячей воде, хотя изначально статья описывает контроллер и его особенности, схема, нюансы и прочее, а "трубная тема", как мне показалось, просто подсказывает читатели, чем управляет тот самый контроллер, но к сожалению акцент сместился не туда...
Ну и ладно, у меня есть пара вопросов:
1 - почему именно atmega128? Вроде бы не самый современный представитель микроконтроллеров. Он не плох, просто устарел...
2 - Схема электрическая принципиальная датчика утечки. Там первая половина операционника как то сама на себя работает. Это специально что бы второй каскад не шумел или оЧепятка? И ещё, касательно датчика утечки - а зачем схема с компаратором? Не проще было поставить полевик и отвязать оптопарой. А каскад полевика простым DC-DC отвязать. Там и токи в микроамперах будут и срабатывания не хуже чем на компараторе, просто маленькую задержку на дребезг ставим и все. Я такую схему использую для датчиков уровня в дренаже. Операционнику питание побольше нужно, а это дополнительный геммор. Да его решили при помощи доп обмотки, но DC5-DC5 на 1 Вт решает эту задачу не хуже.
3 - кто у вас пользуется rs-232? Очень интересно! Я не встречал его уже лет 10 в проектах.
Ну и пара рекомендаций:
Поставить нормальный цветной SPI дисплей, и разгрузить кучу проводов, отоисовать небольшую мнемосхему и там отображать информацию. Некое подобие SCADA системы.
Заменить 128 мегу на esp32-s3, для входов-выходов использовать расширитель портов i2c типа mcp23017 и для аналоговых ads1115
Скорости там не особо нужны, поэтому это все легко может висеть на одной шине.
Схема станет проще, обработка аналоговых сигналов уйдёт на сторону внешнего АЦП, дтскретизация будет выше.
В целом, проект интересный, особенно приятно было читать схему в стиле СССР, номинал резюков в резюке, классно!
Контроллер получился целевым, нежели универсальным, но это не про его минусы, это больше про плюсы, акцент сделан на надёжность.
А в чем недоумение? Роботы не видят и не слышат того, что происходит в горном массив и как правило, куда лезут геологи и маркшейдеры там нет ничего, ни света, ни электричества ни связи.
Да, так происходит уже сотни лет. Человека заменить во многих сферах - невозможно.
Мужики, давайте не будем фантазировать, такие ситуации случаются, да но настолько редко, что вы даже представить себе не можете. Уровень безопасности в шахтах настолько высокий (если компания это поддерживает) что в опасное место не поедут. Туда пока геологи и маркшейдеры не сходят и не скажут, что там безопасно, туда ни технику не отправят ни людей, что бы вести работы. А геологи и маркшейдеры в опасные выработки сами не полезут.
И у машин нет пиропатронов для отстрела манипуляторов. Если даже и упал булыжник, машину там оставляют и валят оттуда.
В шахтах, опасных по метану и водороду спокойно применяется дизельная техника, но при условии: если он имеет специальное взрывозащищенное исполнение (рудничное взрывобезопасное — РВ)
А также все они оснащены газоанализаторами и если ПДК превышает определённую норму, при которой можно использовать дизельную технику, то техника глушится до дегазации.
К счастью, таких шахт в процентом соотношении порядка 20% к общему объёму (из подземных рудников в Казахстане, а я могу говорить именно про Казахстан)
А так, в основном вы правы, применяют аккумуляторную технику и стационарные системы (конвейерное оборудование)
Есть воздухоподающие и воздуховыдающие установки. Дизельная техника безопасная для людей, а электротранспорт на аккумуляторах не выдерживает смену. Необходимо менять аккумуляторы. Откаточный транспорт (самосвалы) вообще могут ехать очень протяженные маршруты и в гору. Там ни одна аккумуляторная система не выдержит. Тролли ставит в шахте - тот ещё гемморой и троллеевозы изготавливается только одна компания. Поэтому старый добрый дизель, мощный, надёжный, выносливый.
Электрическая техника стоит дороже, везёт меньше, требует обслуживания больше (замена аккумуляторов) и на ней постоянно нужно ездить на пункт замены акб. А это потеря времени.
И кожаные мешки тоже требуют воздух, + необходимо проветривание шахты после взрывов. Полностью роботизированных или шахт с дистанционным управлением нет и не будет. Человеческий фактор там важен и необходим.
Мне казалось, что если все сам конфигурируешь, можно и без них, а прямо устройство авторизовать. Работает же аварийный вызов в телефонах без SIM.
Если сеть поддерживает eSIM и если оборудование (телефоны, планшеты, модемы, датчики и так далее, но в 80% в основном не поддерживают.
Аварийный вызов - это GSM голосовой и это исключение. Там слишком много проблем, что бы это сделать иначе. Авторизация нужна в любом случае, а без уникального идентификатора это сделать невозможно.
Почему не разделяется общение с сотрудниками, разная низкоскоростная телеметрия и удаленное управление этой самой техникой?
По сути это все единый поток, который можно разделить (вроде бы можно, но я не уверен, как это будет работать в шахте).
На уровне wi-fi это можно сделать, разделить на VLAN и нарезать трафик и все, в сотовых сетях - даже не знаю. Ни разу не видел, что бы было разделение.
Для общения - вроде как вообще воз и маленькая тележка обычных сравнительно радио решений должно быть.
В LTE это базовое, сотовая связь + есть режим "push to talk", остальное всё на уровне приложений Android и iOS, а сеть - просто среда передачи.
Для медленной телеметрии - аналогично.
Тут тоже, сеть - это транспорт. И в LTE я не знаю, выделяют это или нет, но дя сети, телеметрия, датчики и прочие устройства с низким трафиком - это устройства с SIM картой.
Для управления техникой - а эта техника на чем работает? Неужели на двигателях внутреннего сгорания? В шахте? Или там кабель питания есть? Тогда почему вдоль или совместно с этим кабелем питания не протянуть линию данных для этого самого управления? Точек отказа, вроде, это существенно увеличить не должно - если ломаться будет, то сразу с питанием.
Ну техника бывает разной, в основном на ДВС (только дизельный), иногда на электродвигателях с аккумулятора и, и уж совсем редко на троллеях.
У техники с ДВС - управление очень простое, там все гидравлическое, даже двигатели привода колёс, не говоря уже про гидроцилиндры поворотов. Вся гидравлика управляется электроклапанами и электпозадвижками, с редукторами. А ещё, вся техника в шахте - это как К-700, с ломающейся рамой.
Техника, которой управляют дистанционно, чаще всего ходит на закрытом и очень небольшим участке (от погрузочной камеры до рудоспуска или пункта перегрузки).
Это не так, что техника управляется с поверхности и там по всей шахте гоняют))) такого вообще нет!
Как правило, на этих участках, где ходит самоходная техника, меньше всего коммуникаций, практически нет кабелей питания, в основном сетевая беспроводная инфраструктура.
И ещё, очень важный момент: чаще всего, эта самоходная техника и едет самостоятельно, на датчиках, лидарах, на ней стоят камеры, а операторы за эти просто наблюдают и включаются только в местах погрузки и разгрузки!
Поэтому отклик здесь тоже максимально не важен и переключение между ножами тоже, потому как место погрузки - одна точка, место разгрузки - другая точка. Машина самостоятельно доезжает из точки А в точку Б и когда в точке Б стабильное соединение, оператор начинает с ней работать. Так же и с точкой А.
Есть места, где техника разворачивается (разминовочные ниши) там тоже работают лидары и датчики и она это делает в автоматическое режиме.
Самое главное, что этот участок полностью закрыт от доступа персонала. Если в зону зашёл человек - вся работа останавливается.
Что касается прокладки коммуникаций, то кабель и точки доступа или ноды ставят под кровлей (потолок выработки), прокладывают кабель и силовой и интерфейсный (оптику или ethernet) тоже под кровлей (что бы не сносить его техникой с бортов)
Если участок прямой, то узлов не много, если кривой или транспортный уклон, то ставят чаще. В местах погрузки - разгрузки делают максимальную зону покрытия той сетью, которую выбрали.
Но, дистанционное управление техникой делается не с бухты-барахты, а с определённой целью:
Экономия времени, средств и так далее. Например, в Канаде, на руднике, добираться до места работы оператору самоходной тезники, в шахте - почти 2 часа, если 2 часа одна смена выходит и вторая заходит, то времени на работу остаётся немного, а стоимость часа работы сотрудника и 2-4 часа простоя техники - это огромные деньги.
Поэтому операторы меняются на поверхности, а персонал для заправки, обслуживания техники приходит в шахту, на смену на 2 часа раньше.
И в дополнение к предыдущему комментарию - это промпт для нейросети, который вам поможет понять, что и как давать ребенку, в какой последовательности.
Вот текст для нейросети:
И после этого, вы увидите очень подробный документ, который даст полную информацию о программе обучения.
Я делал запрос в Google.com в режиме ИИ. Это один из самых удобных методов поиска не задействуя какую либо отдельную нейросеть. Но можно использовать любую нейросеть, а то и несколько сразу и получить очень интересные результаты.
Удачи и успехов в обучении вашего ребёнка!
Для начала, что бы это было реально полезным - книга, "Юный радиолюбитель", В.Г.Борисов. Это основы, и там все рассказано доступно и грамотно. Как раз для тех, кто очень юный.
И параллельно с этим радиоконструктор, любой на базе Arduino, но начинать не с микроконтроллера, а с основ электричества, изучения сопротивления и емкостей (не тары для жидкостей, а конденсаторов), понимать, что такое ток и напряжение, как работают транзисторы и прочие аналоговые элементы и компоненты.
И дополнительно приобретите паяльник, припой, канифоль и макетные печатные платы. Пусть учится паять сразу. Отдайте ему старые блоки питания от телефонов, в качестве источников питания и с озона или с алиэкспресса купите много резисторов, светодиодов и прочей мелосевки, включая наборы транзисторов, конденсаторов, диодов и всего остального.
Обязательно купите мультиметр и тестер компонентов (тоже с алиэкспресса).
Самое главное: сначала основы, потом микроконтроллеры, иначе будет недопонимание и потом кривые проекты, недовольство тем, что что-то не получается и не целевое использование ресурсов.
Есть много примеров, когда дети начинают делать проекты, сразу на микроконтроллерах, в примитивных программах и когда что-то не получается, уже не могут приступить к более сложным освоениям. Изучать основы, после того, как уже бегает робот (криво, косо и неправильно, но бегает) считают чем-то ненужным и "кринжовым", хотя, если бы сразу изучили основы и базу - то получили бы лучший результат.
Современные дети хотят видеть результат быстро, прям незамедлительно, поэтому им нужно разбивать программы обучения с видимым результатом на каждом этапе. Но это, я так думаю, больше нужно понимать преподавателям, чем родителю.
И ещё, вариант: напишите запрос для нейросети, что вы хотите видеть и как хотите дать ребенку информацию. И узнаете много интересного. Это конечно не истина в последней инстанции, но как дополнение - очень будет классно.
А такой момент: даёт ли каждый новый каскад ускорения эффект?
Вы проверяли установку на 1, 2-х, 3-х и так далее катушках, с наращиванием каскадов/ступеней ускорения.
И ещё, у вас в схеме нет диодов, гасящих обратную эдс катушек. Эта обратная эдс может сильно тормозить снаряд, когда он находится в центре или уже на выходе. И каждую катушку нужно рассчитать так, что бы ток в каждой катушке падал в тот момент, когда снаряд находится в центре каждой катушки.
Каюдая последующая катушка должна быть короче предыдущей и туда нужно подавать все короче и короче импульсы (меньше емкость и толще провод)
Просто лет 15 назад, я собирал гаусс пушку на 1 и на 2-х касакадах и 1 каскад давал основной импульс почти такой-же скорости как у вас указан на 5 касакадах. Вот мне и интересно, а на сколько эффективна установка на 5 каскадах?
Когда я настраивал 2-й каскад, то мне приходилось двигать и оптопары запуска катушки 2 и саму катушку 2, ну и расстояние там было больше чем у вас на фото. Сейчас не вспомню конечно, но визуально было больше, катушки наматывал округлой формы, а не прямоугольной (в боковом сечении) и каждая последующая катушка (у меня вторая и последняя, потому что я не смог найти больше тиристоров для коммутации) была проводом бОльшего сечения, чем предыдущая.
Но даже при этом, скорость выросла на какие-то жалкие 1,5-2 м/с, от энергии 2-й катушки. Её КПД был настолько низким, что можно было не использовать.
Сейчас возможно что-то и поменялось, может расчёты стали лучше и качественнее. Тогда мы все в Excel считали и очень долго. Тестили, записывали и анализировали.
А проект интересный, простая реализация и подача материала! Автору спасибо!
Решение найдено, но не совсем понятно, а что сделали вы?
Нашли готовое решение, настроили и установили? Реально не понято....
Есть множество таких решений и старые Невод-5, и новые китайские модули. Хоть бы аналитику сделали под ваши условия и ТЗ, а то получается, что вы нашли и установили. Все!
Поясните пожалуйста, может я что-то не понял....
Все отлично, и книга и наборы, не радует только Scratch. К сожалению, дети, научившись на простом и примитивном инструменте "программировать" (это можно только в кавычки взять) не желают потом переходить на сложные программные решения. Стараются делать все на аналогичном уровне не развиваются. И процент таких очень высокий. Из 10 только 1-2 продолжают совершенствовать свои навыки. А те, которые сразу изучают на C и C++, из 10 минимум 5-6 детей развиваются и потом делают реальные вещи.
Раньше, нам давали сначала сложные инструменты (это кстати позволяет понять, кто способен идти дальше, а кто нет) а потом мы изучали все остальное. Сейчас же, с вот этими кубиками, есть мнимое представление о том, что кто угодно может сделать что угодно. Но дальше вот этих конструкторов дело не двигается, а человек считает себя гением автоматизации и электроники.
Понимаю вас, потому как сам программист, это сложно, но если хотите делать взаимодействие между низкоуровневым железом, то стоит именно изучать и C и C++, потому что это то самое, которое позволяет организовать работу, а не имитацию работы. На остальных ЯП вы сможете сделать что-то подобное, но вам нужны будут аппаратным возможности железа преаышающие базовые требования, иными словами, что бы сделать простой вывод данных вам нужен будет микроконтроллер вмещающий как минимум все библиотеки GO или трпнслятоо Python, а это уже не меньше ESP32-S3, А если делать систему реального времени вам нужен будет RP или что-то серьёзнее.
Вот и начинается избыточность, удорожание, но программистам зато удобно, писать легко и быстро.
Самое печальное, что здесь должна падать стоимость программного кода ввиду того, что это стало быстро и просто, но этого не происходит, потому что программисты верхнего уровня считают что они вкладывают много сил и их код не может стоить дёшево. А потом и код раздувается и требования к железу растут, а итог не меняется, только цена лезет вверх.
На днях наткнулся на статью про датчик температуры, влажности и качества воздуха, которому оптимизировали память, из за сборщика мусора, потому что было переполнение, а объем памяти там был 128 Килобайт. У меня аж челюсть отвисла, когда я прочитал, как и куда там используется память. Это как раз один из примеров, когда используется мощное железо и прикладное ПО. Датчик получается измеряет банальные вещи, по минимальным объемам, а его задействовали как полноценный процессор и пытаются на высокоуровневом языке получить и передать 10 байт банальной информации. Итог - для датчика, стоимостью 2 доллара применяется архитектура за 30 долларов, высокоуровневое ПО, загрузка ядра и памяти на 100%. Чего не должно происходить в принципе, для простых систем.
Получается, что вы используете микроскоп что бы им заколачивать гвозди. Дорого, но эффект есть....
Если это разделить, то нет проблем, но когда прикладные программисты начинают лезть на системный уровень со своим языком (а это сейчас вполне возможно), то чаще всего происходит именно такой диссонанс.
Разделяйте системное и прикладное!
Управление, датчики, автономный системы - это системный уровень, почитайте теорию автоматического управления, протоколы, сигналы, изучите электронику и прочее.
Камера для контроля - это уже прикладной уровень, там творите что хотите, но учтите что от железа, протоколов, сигналов, зависит как быстро получите картинку.
Ну и из этого уже можно сделать симбиоз, качественный и корректный.
Удачи в проектах и не стесняйтесь изучать новое, хоть это и сильно старое...
Ооочень странные датчики. Откуда там такие объёмы памяти? Даже если предположить что на температуру нужен float, на влажность - тоже float, на качество воздуха (хрен с ним, 4 float значений) то получается - 24 байта! Там в 128 килобайтах можно ещё пол года хранить архив! И сетевой стек на килобайт - вы его из чего делаете? Из АТ команд? Даже если предположить, что запаковка данных идёт в json и передача по MQTT то наксребсти такой объем пэто постараться нужно! Или вы инфу в виде JPG или GIF картинки передаете?
Напишите производителя и модель этих датчиков, буду понимать что не стоит приобретать.
Автор, изучай С и С++, если хочешь писать такие приложения на микроконтроллерах.
А Go или Python можешь использовать для написания Web приложений (даже для микроконтроллеров, если располагаешь их не многочисленным ресурсами) ну или на очень мощных микроконтроллерах, если делаешь высоконагруженную систему с нейросетью, или с самостоятельным принятием решений. Один хрен нижний уровень нужно делать не на RP2040, на C и C++.
Расскажи, как? Как можно сжечь микроконтроллер такой банальщиной?
Т.е. вместо нормальной кодировки одним байтом нескольких команд, ты перешёл на AT команды с тупым парсингом? Бред! И ты на этом хочешь сделать управление по сети?
С таким подходом ты лидар увидишь после того, как твоя машинка прилетит в стену.
Ощущение такое, что автор прикладной начинающий программист и пока ещё не понимает принципов обмена информацией на уровне микроконтроллеров и датчиков.
Для динамично системы нужно использовать не меньше чем SPI (желательно самый быстрый), а не UART.
Нет слов...
Вы вообще что делаете? Машинку с дистанционным управлением по сети или клиент-северное приложение? Хоть немного понимаете или пытаетесь понимать о том, что такое скорость передачи данных, отклик устройства и реакция?
Если собрать всю картину воедино, получается катастрофическая цепочка:
Видеопоток и команды пакуются в тяжелый gRPC (TCP).
Прокси-сервер разрывает поток на Unary-запросы и пинает Бэкенд.
Команды управления превращаются в длинные текстовые AT-строки.
Эти строки летят на слабый чип RP2040.
Программа на Go судорожно пытается распарсить тонны текста, постоянно спотыкаясь о сборщик мусора.
Предполагаемый итог: Это не MVP, это технический мазохизм. Проект соберет комбо из всех возможных видов задержек: сетевых (из-за TCP), серверных (из-за прокси) и вычислительных (из-за парсинга текста в Go на слабом чипе). Машинка будет реагировать на пульт с грацией и скоростью лунохода.
Для RP2040 стандарт — это C/C++
Ну, во первых, я это предложил и в этом вижу рациональное зерно. Как вы сказали из 5 камней - это исключительно для безопасности контроллера. Периферию можно сжечь а мозг останется и поменять 15 центовую периферию проще. Для этого же оптопары и ставят... С вашей логикой можно и битовую логику поставить ТТЛ или КМОП, но я же не обсираю atmega128, я просто высказал свое мнение и увидел, что дискретные входы изолированы оптопарами, а аналоговые - нет.
И потом, никто не отменяет прогресс, я вроде разумно все свои доводы объяснил, не обсирая решения автора, даже наоборот, с уважением к ним, в отличии от десятков комментариев "не в тему" и только автору решать, нужны ему мои советы или нет.
Автор мне ответил и я услышал его мнение! Он вполне красиво и корректно ответил на мои вопросы (а не претензии). Вы же начали критиковать моё мнение и мои предложения... Зачем?
Вот сейчас не понял.... Почему поэтому?
Вы считаете что 4х канальный 16 разрядный АЦП на Ads1115, который спокойно работает на 5 Вольтах, который можно отвязать I2C изолятором хуже чем 10 разрядный АЦП на меге? И не забывайте, что мега самостоятельно должна измерить аналоговый сигнал, а во внешнем АЦП, чип это делает постоянно и независимо.
И если выгорает АЦП, то это выгорает АЦП, а не контроллер. Изолировать аналоговый сигнал - проблематично, поэтому лучше использовать такие решения. А автор при этом изолирует дискретный сигнал, но не изолирует аналоговый. Вот прилетит потенциал 230В и куда потом полетит этот контроллер?
Какие 3.3В? Откуда они взялись?
Я специально указал чипы, которые работают на 5 Вольтах.
Специально указал на чипы, которые можно изолировать и они применяются в промышленности.
Откуда взялась flash память? И она вообще каким боком здесь?
Все, что было написано относится к улучшению проекта в виде рекомендации и огромного опыта использования сторонних компонентов, элементов и решений.
Между прочим, mcp23017 позволяет сделать и входы и выходы одновременно на одном чипе и микроконтроллер не будет тратить свои входы-выходы на банальщину. Все на интерфейсы, а периферия отдана на сторону
Никто не унижает мегу 128, просто она реально устарела и решение на esp32-s3 + расширители - вполне себе надёжное решение.
Если вы с этим еще не имели дела, то и не стоит говорить что это плохо. Я же не предлагаю перейти на Python и использовать Raspberry PI.
Возможно, но если мы их делали ещё на битовой логике и дальше чем И, И-НЕ, ИЛИ, ИЛИ-НЕ, 2И, 3И ну и так далее, дело не доходило, контроллеры в то время были Ремиконты и Ломиконты и более выглядели как логические шкафы. Микроконтроллеров не было в принципе для домашнего или универского использования.
Да, я то понял, судя по комментариям не всем это было понятно. Подал VCC через резистор, измерил, понял что там осталась земля, решил что там лампочка на месте. Если висит VCC в чистом виде, значит "сперли" лампочку.
Да, здесь в статье не совсем понятен механизм контроля, а конечные автоматы - это отдельная тема для понимания, это как давать примеры на Ассемблере человеку, который его не понимает, но при этом отлично программирует на С и С++.
Я мысль понял, но не совсем принцип и как будто бы не законченная статья... Ну вот что-то мы выяснили, а потом...? Какие-то микросхемы, что-то могут, подтягивают к земле, к питанию, ну а дальше? Что измеряют? Короткое замыкание - это токовый замер, обрыв - тоже токовый... Видимо стоит немного уточнить и дораскрыть тему.
Я не так давно делал что-то похожее, но на большее расстояние. Мне необходимо было соединить 2 узла по питанию и первый узел отдаёт питание на второй, но не просто так отдаёт, он должен определить, что отдаёт питание такому же узлу, а не кому-то другому. А питание - 230В и вот тут как раз и получается такая схема с определением того, что на втором конце привязано.
Сначала необходимо посмотреть, не пристегнули ли туда 230В внешних и
если не пристегнули, то нужно проверить, что там висит на конце, подав туда 5В и проверить ток в линии;
если ток в пределах 5-10мА, то поморгать в линию напряжением 5В (на второй стороне стоит схема индикации, что бы человек, подключивший конечный узел понимал, что устройство опознано и сейчас сюда прилетит 230В);
если ток меньше 5 и больше 2мА, отправить проверить линию, есть обрыв,
если более 10мА и менее 30мА, то тоже проверить линию, возможно есть повреждения
Если более 30мА, то считаем что там короткое замыкание или левая нагрузка
И вот когда мы поморгали 4 секунды, то подаём в линию 230В, отключив от линии всю диагностику. И в конечный узел приходит полное напряжение питания 230В, отключая схему низковольтного токового контроля.
Я не расписал ещё логику контроля тока при напряжении 230В, но это уже не важно.
Вот в этой схеме есть логика, есть порядок и да, нет конечного автомата, но есть результаты работы. А что происходит у вас? Подключается или не подключается нагрузка (фара, фонарь, насос и так далее, диагностируется ошибка и выдаётся в виде кода ошибки или просто ничего не происходит?
Я так предполагаю, что подтяжками там дело не заканчивается и какой-то результат должен быть. Возможно я не понимаю суть конечного автомата в данной интерпретации (давно, сильно давно мы их в универе проходили). Попробуйте пожалуйста объяснить проще и доступнее...
Ну я делаю не целевым контроллером свои решения, а как раз более универсальный. По 8 - 16 дискретных входов и выходов, по 4-8 аналоговых 4-20мА входов и выходов, ну и прочие сменные, специальные модули, которые нужны редко. И в формате промышленного ПЛК.
Статья интересная, комментарии - я не понял...
Обычно после прочтения, интересно посмотреть комментарии, вопросы, предложения и прочее, но тут же все увязло в пластике, трубах и в горячей воде, хотя изначально статья описывает контроллер и его особенности, схема, нюансы и прочее, а "трубная тема", как мне показалось, просто подсказывает читатели, чем управляет тот самый контроллер, но к сожалению акцент сместился не туда...
Ну и ладно, у меня есть пара вопросов:
1 - почему именно atmega128? Вроде бы не самый современный представитель микроконтроллеров. Он не плох, просто устарел...
2 - Схема электрическая принципиальная датчика утечки. Там первая половина операционника как то сама на себя работает. Это специально что бы второй каскад не шумел или оЧепятка? И ещё, касательно датчика утечки - а зачем схема с компаратором? Не проще было поставить полевик и отвязать оптопарой. А каскад полевика простым DC-DC отвязать. Там и токи в микроамперах будут и срабатывания не хуже чем на компараторе, просто маленькую задержку на дребезг ставим и все. Я такую схему использую для датчиков уровня в дренаже. Операционнику питание побольше нужно, а это дополнительный геммор. Да его решили при помощи доп обмотки, но DC5-DC5 на 1 Вт решает эту задачу не хуже.
3 - кто у вас пользуется rs-232? Очень интересно! Я не встречал его уже лет 10 в проектах.
Ну и пара рекомендаций:
Поставить нормальный цветной SPI дисплей, и разгрузить кучу проводов, отоисовать небольшую мнемосхему и там отображать информацию. Некое подобие SCADA системы.
Заменить 128 мегу на esp32-s3, для входов-выходов использовать расширитель портов i2c типа mcp23017 и для аналоговых ads1115
Скорости там не особо нужны, поэтому это все легко может висеть на одной шине.
Схема станет проще, обработка аналоговых сигналов уйдёт на сторону внешнего АЦП, дтскретизация будет выше.
В целом, проект интересный, особенно приятно было читать схему в стиле СССР, номинал резюков в резюке, классно!
Контроллер получился целевым, нежели универсальным, но это не про его минусы, это больше про плюсы, акцент сделан на надёжность.
А в чем недоумение? Роботы не видят и не слышат того, что происходит в горном массив и как правило, куда лезут геологи и маркшейдеры там нет ничего, ни света, ни электричества ни связи.
Да, так происходит уже сотни лет. Человека заменить во многих сферах - невозможно.
Мужики, давайте не будем фантазировать, такие ситуации случаются, да но настолько редко, что вы даже представить себе не можете. Уровень безопасности в шахтах настолько высокий (если компания это поддерживает) что в опасное место не поедут. Туда пока геологи и маркшейдеры не сходят и не скажут, что там безопасно, туда ни технику не отправят ни людей, что бы вести работы. А геологи и маркшейдеры в опасные выработки сами не полезут.
И у машин нет пиропатронов для отстрела манипуляторов. Если даже и упал булыжник, машину там оставляют и валят оттуда.
В шахтах, опасных по метану и водороду спокойно применяется дизельная техника, но при условии: если он имеет специальное взрывозащищенное исполнение (рудничное взрывобезопасное — РВ)
А также все они оснащены газоанализаторами и если ПДК превышает определённую норму, при которой можно использовать дизельную технику, то техника глушится до дегазации.
К счастью, таких шахт в процентом соотношении порядка 20% к общему объёму (из подземных рудников в Казахстане, а я могу говорить именно про Казахстан)
А так, в основном вы правы, применяют аккумуляторную технику и стационарные системы (конвейерное оборудование)
Да, так и есть.
Есть воздухоподающие и воздуховыдающие установки. Дизельная техника безопасная для людей, а электротранспорт на аккумуляторах не выдерживает смену. Необходимо менять аккумуляторы. Откаточный транспорт (самосвалы) вообще могут ехать очень протяженные маршруты и в гору. Там ни одна аккумуляторная система не выдержит. Тролли ставит в шахте - тот ещё гемморой и троллеевозы изготавливается только одна компания. Поэтому старый добрый дизель, мощный, надёжный, выносливый.
Электрическая техника стоит дороже, везёт меньше, требует обслуживания больше (замена аккумуляторов) и на ней постоянно нужно ездить на пункт замены акб. А это потеря времени.
И кожаные мешки тоже требуют воздух, + необходимо проветривание шахты после взрывов. Полностью роботизированных или шахт с дистанционным управлением нет и не будет. Человеческий фактор там важен и необходим.
Если сеть поддерживает eSIM и если оборудование (телефоны, планшеты, модемы, датчики и так далее, но в 80% в основном не поддерживают.
Аварийный вызов - это GSM голосовой и это исключение. Там слишком много проблем, что бы это сделать иначе. Авторизация нужна в любом случае, а без уникального идентификатора это сделать невозможно.
По сути это все единый поток, который можно разделить (вроде бы можно, но я не уверен, как это будет работать в шахте).
На уровне wi-fi это можно сделать, разделить на VLAN и нарезать трафик и все, в сотовых сетях - даже не знаю. Ни разу не видел, что бы было разделение.
В LTE это базовое, сотовая связь + есть режим "push to talk", остальное всё на уровне приложений Android и iOS, а сеть - просто среда передачи.
Тут тоже, сеть - это транспорт. И в LTE я не знаю, выделяют это или нет, но дя сети, телеметрия, датчики и прочие устройства с низким трафиком - это устройства с SIM картой.
Ну техника бывает разной, в основном на ДВС (только дизельный), иногда на электродвигателях с аккумулятора и, и уж совсем редко на троллеях.
У техники с ДВС - управление очень простое, там все гидравлическое, даже двигатели привода колёс, не говоря уже про гидроцилиндры поворотов. Вся гидравлика управляется электроклапанами и электпозадвижками, с редукторами. А ещё, вся техника в шахте - это как К-700, с ломающейся рамой.
Техника, которой управляют дистанционно, чаще всего ходит на закрытом и очень небольшим участке (от погрузочной камеры до рудоспуска или пункта перегрузки).
Это не так, что техника управляется с поверхности и там по всей шахте гоняют))) такого вообще нет!
Как правило, на этих участках, где ходит самоходная техника, меньше всего коммуникаций, практически нет кабелей питания, в основном сетевая беспроводная инфраструктура.
И ещё, очень важный момент: чаще всего, эта самоходная техника и едет самостоятельно, на датчиках, лидарах, на ней стоят камеры, а операторы за эти просто наблюдают и включаются только в местах погрузки и разгрузки!
Поэтому отклик здесь тоже максимально не важен и переключение между ножами тоже, потому как место погрузки - одна точка, место разгрузки - другая точка. Машина самостоятельно доезжает из точки А в точку Б и когда в точке Б стабильное соединение, оператор начинает с ней работать. Так же и с точкой А.
Есть места, где техника разворачивается (разминовочные ниши) там тоже работают лидары и датчики и она это делает в автоматическое режиме.
Самое главное, что этот участок полностью закрыт от доступа персонала. Если в зону зашёл человек - вся работа останавливается.
Что касается прокладки коммуникаций, то кабель и точки доступа или ноды ставят под кровлей (потолок выработки), прокладывают кабель и силовой и интерфейсный (оптику или ethernet) тоже под кровлей (что бы не сносить его техникой с бортов)
Если участок прямой, то узлов не много, если кривой или транспортный уклон, то ставят чаще. В местах погрузки - разгрузки делают максимальную зону покрытия той сетью, которую выбрали.
Но, дистанционное управление техникой делается не с бухты-барахты, а с определённой целью:
Экономия времени, средств и так далее. Например, в Канаде, на руднике, добираться до места работы оператору самоходной тезники, в шахте - почти 2 часа, если 2 часа одна смена выходит и вторая заходит, то времени на работу остаётся немного, а стоимость часа работы сотрудника и 2-4 часа простоя техники - это огромные деньги.
Поэтому операторы меняются на поверхности, а персонал для заправки, обслуживания техники приходит в шахту, на смену на 2 часа раньше.