Нужен скетч для отправки REST запросов
- Войдите на сайт для отправки комментариев
Вс, 26/07/2020 - 11:37
Разрабатываем систему управления роботом. Взаимодействие с роботом осуществляется отправкой REST запросов для активации заранее запрограммированных заданий, и для считывания состояний внутренних регистров робота. Реализация проекта предполагается на Arduino-совместимом промышленном контроллере. Робот имеет REST API. Связь с роботом по Ethernet.
На первом этапе хотим смоделировать взаимодействие Arduino и робота.
Схема работы следующая: К Arduino UNO с Ethernet шилдом подключены 12 кнопок и 12 светодиодов.
Каждая кнопка соответствует отдельному заданию робота. Каждый светодиод отражает состояние соответствующего регистра робота.
При нажатии на кнопку роботу отправляется REST запрос установленного формата, который является триггером для запуска задания соответствующего номеру кнопки. В процессе выполнения задания робот меняет статус задания отражая это изменением соответствующего регистра. Светодиод соответствующий регистру, в зависимости от состояния регистра индицирует его статус. Опрос состояния регистров также производится путем отправки REST запросов роботу. На данном этапе предусмотрено 4 статуса: "Ожидание задания" - светодиод не горит, "Задание в очереди" - симметричное мигание(1сек-горит/1сек-пауза), "задание выполняется" - светодиод горит постоянно, "Ошибка" - несимметричное мигание (3 коротких вспышки/пауза)
При удачном результате первого этапа планируем перенести проект на ПЛК, потребуется интеграция с внешними устройствами (модули ввода/вывода, панель оператора, ПЛК, датчики и т.п.) через Ethernet Modbus TCP/ Также планируется графический интуитивно понятный интерфейс для мониторинга и изменения параметров системы оператором.
Василий indekko@gmail.com
Где вы находитесь?
Москва
Запросы к REST API я бы не рекомендовал делать на "худых" ардуино, хотя делать приходилось, и оно даже работало.
Запросы к REST API я бы не рекомендовал делать на "худых" ардуино, хотя делать приходилось, и оно даже работало.
Прошу вас уточнить для непосвященных, что такое "худые" Ардуино.
Мы хотим протестировать прототип на Ародуино Уно.
Реализовывать будем на базе ардуино-совместимого ПЛК
https://www.automationdirect.com/open-source/home
Мы хотим протестировать прототип на Ародуино Уно.
Реализовывать будем на базе ардуино-совместимого ПЛК
Потестировать можно и на уно, хотя он и "худой".
А вот ПЛК вполне себе "жирный", но с ним есть вопросы по ethernet. Вроде бы как "железо" заявлено, но что с библиотеками. А то порой "железо" есть, а с программной частью сами разбирайтесь. Разобраться то можно, вопрос времени и, соответственно - денег.
На первом этапе хотим смоделировать взаимодействие Arduino и робота.
Схема работы следующая: К Arduino UNO с Ethernet шилдом подключены 12 кнопок и 12 светодиодов.
При удачном результате первого этапа планируем перенести проект на ПЛК, потребуется интеграция с внешними устройствами (модули ввода/вывода, панель оператора, ПЛК, датчики и т.п.) через Ethernet Modbus TCP/ Также планируется графический интуитивно понятный интерфейс для мониторинга и изменения параметров системы оператором.
Может лучше сразу на другой базе делать?
Может лучше сразу на другой базе делать?
Предложите другую базу, обсудим.
Задача изменена!
Необходимо разработать скетч для отправки POST и GET запросов на вебсервер (REST API).
В наличии Arduino UNO + Ethernet Shield Амперка + Breadbord + тактовые кнопки + светодиоды + компьютер с вебсервером управляющий процессом.
Есть тело запроса, проверенное и отлаженное на Postman.
Принцип работы:
Нажатие кнопки №1 инициирует отправку POST запроса на вебсервер, который запускает выполнение процесса.
Светодиод №1 подтверждает успешную отправку запроса, свечением в течение 5 сек.
При выполнении процесса в регистре сервера отражается статус процесса.
Периодически, 5 раз в секунду, отправляется GET запрос, который опрашивает состояние регистра.
Светодиод №2 отражает состояние регистра: "0" - не горит; "1" - горит постоянно; "2" - мигает.
Макет для тестирования соберем самостоятельно.
Задача изменена!
Периодически, 5 раз в секунду, отправляется GET запрос, который опрашивает состояние регистра.
В зависимости от задач, может есть смысл сменить протокол, или даже физический интерфейс, ну или хотя бы логику работы.
Если нужен совсем реалтайм, то ИМХО, нужно уходить от TCP/UDP. Оно всё же не для того разрабатывалось. А REST API вообще больше для внутри или меж серверного обмена, асинхронно.
Вы бы уж хотя бы дали ссылки на управляемый девайс с описанием протоколов обмена, а тут есть очень бывалые, может чего путнего и посоветуют.
А если сервер не может ответить 5 раз секунду? По опыту, не факт что раз в 5 секунд ответ будет. Да и не факт, что вообще соединение можно будет установить.
В зависимости от задач, может есть смысл сменить протокол, или даже физический интерфейс, ну или хотя бы логику работы.
Если нужен совсем реалтайм, то ИМХО, нужно уходить от TCP/UDP. Оно всё же не для того разрабатывалось. А REST API вообще больше для внутри или меж серверного обмена, асинхронно.
Вы бы уж хотя бы дали ссылки на управляемый девайс с описанием протоколов обмена, а тут есть очень бывалые, может чего путнего и посоветуют.
При тестовых отправках запросов через Postman, проблем с откликом не было при частоте 1 раз в секунду.
Объясните пожалуйста в чем не устраивает протокол и интерфейс, и на что предлагаете менять.
Управляемый девайс - логистический робот MiR
https://www.mobile-industrial-robots.com/en/solutions/robots/mir100/
Описание REST API:
https://drive.google.com/file/d/1f-8gt76m_yYQcWAIaw65hqPGqM6ibCRa/view?u...
Непосредственно rest в полном объеме на 328-й МК смысла нет, но что-то похожее для сервера можно изобразить.
Скиньте пример обмена на wrk.sadman@gmail.com - гляну что куда.
При тестовых отправках запросов через Postman, проблем с откликом не было при частоте 1 раз в секунду.
Объясните пожалуйста в чем не устраивает протокол и интерфейс, и на что предлагаете менять.
Управляемый девайс - логистический робот MiR
https://www.mobile-industrial-robots.com/en/solutions/robots/mir100/
Описание REST API:
https://drive.google.com/file/d/1f-8gt76m_yYQcWAIaw65hqPGqM6ibCRa/view?u...
Я протокол и интерфейс в этом роботе не поменяю. Просто предупреждаю, что ожидаемого гарантированного доступа 5 раз в секунду Вы можете не получить, и в последствии предъявить это программисту адруино, хотя он будет не при чем.
Документ с REST API не открывается - доступ закрыт. Сделал запрос, интересно глянуть, может и впишусь в проект.
Куче устройств это никак не мешает работать в реалтайме по TCP/UDP. Дело как всегда - в прокладке между стулом и клавиатурой. Если никак не работает - меняем прокладку на такую, с которой работает. И всех делов ;)