Проект SimpleRov
Уф, много работы, но потихоньку подбираюсь к заветной цели:).
Сделал на ЧПУ Full close loop и начинаю в плотную подходить к выпуску деталек, надеюсь через неделю другую, появятся первые комплектующие. Начну с хвоста, а там все пойдет веселей.
В программном обеспечении уперся в возможности Atmega32u4 (не хватило таймеров), пришлось перейти на Atmega2560. Сейчас завершаю переход, подправляю мелкие недочеты и на этой недели доберусь до ориентации. Увы там много тригонометрии, которая была благополучно забыта.
Всем удачи в проектах, терпения и упорства!
А зачем 4 двигателя? И почему не сделать на apm и по ppm Отправлять сигналы управлению.
А зачем 4 двигателя?
2 ходовых, 1 для плавного погружения, 1 для плавного горизонтального движения.
И почему не сделать на apm
Вы говорите о контролерах ARM, к примеру STM32F, они избыточны, а потребляют больше. Во вторых, многие боятся ARM (хотя мне, очень понравилась серия STM32F), хотелось бы, чтобы кто-то кроме меня смог воспользоваться кодом (он открытый).
ppm Отправлять сигналы управлению.
Как я понял управление с обычного пульта радиолюбителя. Можно и так, но возможностей меньше и много нюансов.
К примеру вопрос как передать PPM или PPM Sum, к примеру надо RS-485\RS-422, сеть и т.д., ставить какой-то контролер для разбора или просто отправки, перевода сигнала в бинарные данные для RS-ов или по протоколам UDP, TCP (или на их основе). Можно конечно просто выход PPM Sum завести в RS-485, но тут другая проблем у пульта мало каналов или они дорогие, можно конечно выкинуть все из пульта и поставить какой нибудь контролер и сделать 10-ки каналов PPM.
Но зачем городить огород, когда проще отправлять по сети и данные и видео, иметь простой и не дорогой пульт с любым кол-вом каналов?
Фото хвоста в сборе с соплами для маршевых двигателей.
В ближайшее время должен выйти блок камеры.
Пульт стоит около 100$, Апм 2.6 баксов 30. Каналов минимум 10. К Апм можно подрубить и 4 мотора и кучу всякой хрени. По тх рх можно гнать телеметрию.
В начале не понял Вас.
Да смотрел в сторону ARM 2.6, но для моих задач его сложнее переписать, чем сделать с 0-ля.
Минусы для меня, аналоговое видео, как следствие бесполезный OSD. Работа по радио каналам, передача данных и их протокол у меня провод, а радио можно только мечтать, как далеко пробъет сигнал, хотя бы на 10 метров под водой получится?
Работа с IMU, его можно выпилить из ARM или из других проектов. А вот алгоритмы удержания на глубине и т.д., уже пиши с нуля. Как и алгоритм управления моторами опять с 0-ля. Интерфейс пользователя, другие протоколы, пакеты, другое видео опять 0-ля. Позиционирование на местности, не будет работать как и GPS.
Что остается в сухом остатке, работа с ESC и Servo, так это не сложно. Вот примеры - github.com/SimpleRov/AVR/tree/master/Servo. Есть другие решения, на один таймер пару десятков серв, но они более затратные по производительности и тут ни к чему. Возможно подключение каких-то датчиков, что то же не сложно.
Да и для меня это в кайф:).
Пробьет и больше 10 метров по проводу, радио с водой не совместимо. Как минимум Апм решает проблему управления под водой, ну и видео тоже пускать по проводам. А стабилизацию по глубине можно реализовать на земле имея данные телеметрии.
Управление моторами легко можно смикшировать в аппаратуре.
Пробьет и больше 10 метров по проводу, радио с водой не совместимо. Как минимум Апм решает проблему управления под водой, ну и видео тоже пускать по проводам. А стабилизацию по глубине можно реализовать на земле имея данные телеметрии.
Если реализовывать пульт без контролера, то мы получаем максимум 8 каналов в PPM Sum, но как отправить без контролера с сохранением схемы - RS-485, а это дополнительных 2 провода. С контролером, чтобы передать по сети, дополнительных проводов мы не получаем, но ломается схема ARM 2.6 в частности получения команд.
По управлению, ни одна из существующих схем мне не подходит.
По стабилизации да, но тоже ПИД регулирование, на земле не проверить. И оно иное, из-за разной среды, все таки вода имеет плотность в 800 раз больше, другая инерция, торможение, есть течения и т.д.
И так, цепляется одно, за другим. не в коем случае не хочу сказать, что проект ARM 2.6 мне не понравился, сделан он очень достойно (для их задач, у них разные контролеры с разной архитектурой AVR и ARM поэтому им пришлось делать прослойку), говорю о коде. Просто он мне не подходит, много всего переписывать. Поэтому пишу с 0-ля, хотя как с нуля, тягаю из существующих проектов модули, что-то дописываю.
Что касается стоимости Вы сказали пульт стоит 100$, мой в РБ максимум 20$, в Китае можно купить за 5$. Если говорить о контролере, то мне из-за габаритов, он не подходит, заказал микро мегу. Для более просторного можно купить обычную мегу + датчики ориентации из Китая, будет стоить, точно не дороже 30$.
Вот поэтому, пока не ARM.
У ARM колоссальный плюс - сообщество, возможно потом перейду на ARM, но сейчас это потребует значительно больше времени.
Ну если так хочется с 0. ТО ардуино мини стики тумблеры-вот и пульт за пару баксов. На самой модели дешефратор ппм (апм являлся этим дешефратором который ппм в шим переводил кроме того на него можно навешать кучу датчиков и получать их параметры на землю). Советы эти не с теории а с уже готового проекта практически такого как ваш тока реализованного. RS-485-для чего это тут я так и не понял.
Ну если так хочется с 0.
Не совсем так, конечно хочется готовое решение. Но вот когда начинается беглое изучения проекта, приходит понимание, что готового решения нет. Потребуется глубокое изучение и не мало времени на переделки.
Потом начинается изучение, а что можно взять из существующих проектов, что из AVR Appnote. Вот так и собираю проект, из кусочков других проектов и из AVR Appnote.
ТО ардуино мини стики тумблеры-вот и пульт за пару баксов. На самой модели дешефратор ппм (апм являлся этим дешефратором который ппм в шим переводил кроме того на него можно навешать кучу датчиков и получать их параметры на землю).
Да, схему понимаю, делал дешифратор PPM для одного знакомого, формирование сигнала, то же делал не раз, когда-то разобрал проект Multiwii, сейчас буду изучать Ardupilot, вдруг там есть, что-то вкусненькое (хорошие решения, возможно какие-то модули, решения перекачуют в мой проект).
Советы эти не с теории а с уже готового проекта практически такого как ваш тока реализованного.
Вот тут беда, далеко не то, что мне нужно, иначе нашего с Вами разговора на эту тему не было:).
RS-485-для чего это тут я так и не понял.
Он нужен, как самое простое решение, если не использовать контролер сверху, просто загнать PPM Sum в RS-485. Тогда переработка таких проектов как Ardupilot или Multiwii минимальная и можно использовать их практически без изменения.
Еще пару деталей от блока камеры.
Вместе.
Отдельно.
Сделал раньше, но добавить смог только сейчас, много работы.
Здравствуйте, 100 лет не заходил на форум, а тут такая тема 😃
Тоже за лето начал собирать по кусочкам всё для ROVа, опишу свой подход, для обмена опытом. Не очень Вы подробно описываете свою концепцию, по гитхабу не особо разберешься в принципе.
Базовую концепцию я честно стырил у OpenROV Т.е. сверху любой компьютер с ethernet+usb и браузером, линк по длинному проводу передается с помощью пары powerline адаптеров и приходит внизу в OrangePI за 15 долларов(вместо дорогущего BeagleboneBlack)
В PI стоит mjpg-streamer для вещания вебкамеры(logitech C270 всем хороша, но угол обзора надо как то увеличивать) и связка websocketd+socat для транслирования потока сообщений вебсокета прямиком в UART на ардуинку.
Т.е. JS на страничке формирует пакеты управлющих команд, шлёт вебсокетом и они попадают прямиком в код ардуины, ардуина формирует ответ(я сразу JSON формирую) и он отправляется сразу в JS странички, таким образом избегаю миллиона кода на NodeJS которую ваяют ОпенРОВовцы
Сейчас имею рабочую связку ардуина(пока для разработки Мега, но планирую поменять на сторублевую Нано, её хватает вроде, может быть на Micro) + OrangePI PC
Работает mjpg-streamer но великовата задержка на 720p, чуть меньше 200мс, за ардуину зацеплен вот такой IMU, с него данные отправлются в браузер 10 раз в секунду и поверх изображения с камеры накладывается компас и горизонт, это сделано пока просто для проверки концепции.
Трансляция вебсокета в UART сделана при помощи websocketd(качается готовый бинарник дял ARM) + socat(ставится из пакетного менеджера) ( ./websocketd --port=8081 socat - /dev/ttyS3,raw,echo=0,crnl,b115200 ) Секрет успеха в данном вопросе - не открывать 2 странички и закрывать вебсокет перед перезагрузкой страницы 😃 Либо надо морочиться с блокировкой UARTa а это лень пока.
Отправляю из браузера в ардуину пока только тестовое сообщение, но это уже дело техники. Джойстик планирую цеплять сразу к JS странички как вот тут и сразу на основе этих данных формировать команды для ардуины, это собственно следующий этап, который и завешает мой “proof of a concept”, после чего я приступаю к проектированию платы управления увязывающей всю подводную периферию с адуриной и PI.
P.S. Глядя на папку AVR на гитхабе рискну предложить Вашему вниманию помимо FastIO еще и библиотеку CyberLib Вдруг вы её не видели, а она на мой личный взгляд куда как проще.
День добрый, приятно видеть единомышленника.
Сам не часто бываю на форумах.
опишу свой подход, для обмена опытом. Не очень Вы подробно описываете свою концепцию, по гитхабу не особо разберешься в принципе.
Подход действительно не описан, причина в том, что в начале электронная часть не была утверждена. Да и ни кто не интересовался.
Базовую концепцию я честно стырил у OpenROV Т.е. сверху любой компьютер с ethernet+usb и браузером, линк по длинному проводу передается с помощью пары powerline адаптеров и приходит внизу в
Сам пришел к аналогичному решению:).
Так же буду использовать передачу данных по витой паре, через Powerline адаптеры, наверху ноутбук с Ethernet и управление через браузер.
OrangePI за 15 долларов(вместо дорогущего BeagleboneBlack) В PI стоит mjpg-streamer для вещания вебкамеры(logitech C270 всем хороша, но угол обзора надо как то увеличивать)
У меня сейчас Raspberry PI 2 с родной видео камерой Raspberry PI Camera V1.3, меня подкупило не плохое качество, малые габариты, что касается объективов, то выбор огромный, к примеру: 
Передача видео в браузер, пока так же реализована с помощью mjpg-streamer.
связка websocketd+socat для транслирования потока сообщений вебсокета прямиком в UART на ардуинку.
Сам еще не решил, о том как буду передавать данные. Скорее всего с помощью Node.js, команда попадает в Node.js, там формируется необходимая структура и оправляется по UART.
Т.е. JS на страничке формирует пакеты управлющих команд, шлёт вебсокетом и они попадают прямиком в код ардуины, ардуина формирует ответ(я сразу JSON формирую) и он отправляется сразу в JS странички, таким образом избегаю миллиона кода на NodeJS которую ваяют ОпенРОВовцы
Не очень понятно как это работает. Вам все равно нужен какой-то аппаратный/программный мост, чтобы пробрасывать данные из Websocketd (HTTP) в UART.
Сейчас имею рабочую связку ардуина(пока для разработки Мега, но планирую поменять на сторублевую Нано, её хватает вроде, может быть на Micro)
Все зависит, от требуемых аппаратных ресурсов и периферии. Если у Вас нет каких-то требований по кол-ву таймеров, кол-ву UART-тов, объему памяти и т.д., то Вам вполне подойдет Nano или Micro.
Работает mjpg-streamer но великовата задержка на 720p, чуть меньше 200мс
Качество аналогичное, как и задержка, тут много составляющих в том числе и браузер.
за ардуину зацеплен вот такой IMU
Не плохой модуль, с датчиками от компании STM, хотя сама реализация мне не понравилась. На плате не реализовано поддержки прерываний, хотя у самих датчиков они есть.
Сейчас MPU-6050 и какой-то компас (в модуле MPU-9150/9250 он хуже HMC5883L). Причина в наличии DMP + поддержки прерываний. Но мне еще предстоит изучить алгоритмы работы этих устройств.
Трансляция вебсокета в UART сделана при помощи websocketd(качается готовый бинарник дял ARM) + socat(ставится из пакетного менеджера) ( ./websocketd --port=8081 socat - /dev/ttyS3,raw,echo=0,crnl,b115200 ) Секрет успеха в данном вопросе - не открывать 2 странички и закрывать вебсокет перед перезагрузкой страницы Либо надо морочиться с блокировкой UARTa а это лень пока.
Не работал с websocket и socat, надо будет почитать, возможно это лучшее решение.
с него данные отправлются в браузер 10 раз в секунду и поверх изображения с камеры накладывается компас и горизонт, это сделано пока просто для проверки концепции.
Мне хотелось бы сохранять часть данных в видео поток, часть отображать в браузере. В остальном подход аналогичный.
Отправляю из браузера в ардуину пока только тестовое сообщение, но это уже дело техники. Джойстик планирую цеплять сразу к JS странички как вот тут и сразу на основе этих данных формировать команды для ардуины, это собственно следующий этап, который и завешает мой “proof of a concept”, после чего я приступаю к проектированию платы управления увязывающей всю подводную периферию с адуриной и PI.
Аналогично, тоже через Gamepad API.
P.S. Глядя на папку AVR на гитхабе рискну предложить Вашему вниманию помимо FastIO еще и библиотеку CyberLib Вдруг вы её не видели, а она на мой личный взгляд куда как проще.
Папка AVR, это просто примеры, которые мне понравились. Что-то нашел, что-то сделал.
Когда-то давно смотрел, спасибо, что напомнили. Хорошая библиотека, если у Вас нет опыта работы с AVR.
По своей сути, если говорить о FastIO и CyberLib (работа с цифровыми портами) они почти аналогичны (по плюсам и минусам) и это не библиотеки. Это просто макросы и макроподстановки. Мы получаем максимальную скорость, но отсутствие проверок как и гибкости.
Что касается ADC, он без прерываний, как и UART, TWI и т.д. Да и мне проще написать самому:).
Пока был вынужден прерваться со своим проектом, увы раньше чем через 1-2 недели к нему не вернусь.