roboforum.ru

Технический форум по робототехнике.

Управление роботом с компьютера. Новый подход.

Программирование микроконтроллеров AVR, PIC, ARM.
Разработка и изготовление печатных плат для модулей.

Re: Управление роботом с компьютера. Новый подход.

Сообщение Scorpio » 30 авг 2010, 19:46

Я понял утилита собственно "пишет" свой протокол обмена с ПК, автоматически его расширяя при добавлении новых функций. С классом на ПК все понятно, а ответную (ответственную за обмен) часть кода для Адруино кто делает и в виде чего?
Аватара пользователя
Scorpio
 
Сообщения: 2669
Зарегистрирован: 30 сен 2008, 18:49
Откуда: Где-то в Латинской Америке

Re: Управление роботом с компьютера. Новый подход.

Сообщение Виталий » 30 авг 2010, 19:50

Скачайте, откройте готовый пример и все увидите сами. Файл Sketch.pde
Все новости о моих проектах http://savethebest.ru
Аватара пользователя
Виталий
 
Сообщения: 2114
Зарегистрирован: 08 окт 2004, 16:43
Откуда: St. Petersburg
Skype: quark-bot
ФИО: Клебан Виталий

Re: Управление роботом с компьютера. Новый подход.

Сообщение mgalemin » 31 авг 2010, 15:59

Преимущества данного "нового подхода":

1. Быстрота имплементации обмена между PC и одним микроконтроллером;

2. Хороший уровень абстракции (для программиста всё прозрачно и не надо думать - нажал кнопку и всё готово);

Недостатки:

1. Накладные расходы на нижележащий протокол обмена (обычно tcp/udp, в данном случае неожиданный UART), как следствие возможна перегрузка канала при передаче потоковых данных (звук/видео);

2. Накладные расходы на обработку ошибочных ситуаций (потеря запроса/ответа, перезапросы, ожидание ответа, разрыв канала связи);

3. Невозможность multicast обмена с несколькими контроллерами одновременно;

4. Клиент-серверная архитектура, причём микроконтроллер всегда выступает в роли сервера (или я не прав?), что может негативно влиять на потребление;


Наверно по этим причинам и не прижился RPC в embedded. :pardon: Хотя свои ниши у этого решения есть.
Аватара пользователя
mgalemin
 
Сообщения: 66
Зарегистрирован: 07 авг 2010, 06:36
Откуда: Sydney, Australia
прог. языки: C/C++

Re: Управление роботом с компьютера. Новый подход.

Сообщение Сергей » 31 авг 2010, 16:04

Про недостатки:
1) UART + видео? :lol: Сделать это все на мосту через TCP\UDP не составит труда, я думаю
2) Это всегда и везде есть
3) Даже на UART это можно сделать
Сергей
 
Сообщения: 3744
Зарегистрирован: 29 дек 2004, 23:15
Откуда: Санкт-Петербург
прог. языки: C, C++, C#, Asm
ФИО: Кашликов Сергей

Re: Управление роботом с компьютера. Новый подход.

Сообщение mgalemin » 31 авг 2010, 16:10

2 Сергей:

1. Разговор не про UART, а про RPC;
2. Где-то больше, где-то меньше, в данном случае больше;
3. Разговор не про UART, а про RPC;
Аватара пользователя
mgalemin
 
Сообщения: 66
Зарегистрирован: 07 авг 2010, 06:36
Откуда: Sydney, Australia
прог. языки: C/C++

Re: Управление роботом с компьютера. Новый подход.

Сообщение Виталий » 31 авг 2010, 16:24

1. Накладные расходы на нижележащий протокол обмена (обычно tcp/udp, в данном случае неожиданный UART), как следствие возможна перегрузка канала при передаче потоковых данных (звук/видео);

Я не согласен. Дело в том, что перегрузка будет связана с низкой пропускной способностью канала, а не с накладными расходами на передачу. Реализация той же функциональности через UDP или TCP - не представляет сложности.

...неожиданный UART...

Помоему вполне ожидаемый...

2. Накладные расходы на обработку ошибочных ситуаций (потеря запроса/ответа, перезапросы, ожидание ответа, разрыв канала связи);
...
2. Где-то больше, где-то меньше, в данном случае больше;

Больше по сравнению с чем?

3. Невозможность multicast обмена с несколькими контроллерами одновременно;

Сейчас невозможно, но мы исправим это к вечеру. =)

4. Клиент-серверная архитектура, причём микроконтроллер всегда выступает в роли сервера (или я не прав?), что может негативно влиять на потребление;

Микроконтроллер может просыпаться по прерыванию от UART или другого канала связи.
Все новости о моих проектах http://savethebest.ru
Аватара пользователя
Виталий
 
Сообщения: 2114
Зарегистрирован: 08 окт 2004, 16:43
Откуда: St. Petersburg
Skype: quark-bot
ФИО: Клебан Виталий

Re: Управление роботом с компьютера. Новый подход.

Сообщение mgalemin » 31 авг 2010, 16:44

Для упражнения можно посчитать стандартную задачу - передачу кодированного звука (пакеты 160 байт каждые 10 мс, допустим по UDP). С учётом потери пакетов, перезапросов и обработки с использованием RPC более чем уверен, что обычный подход с распарсиванием UDP пакетов будет намного устойчивее и быстрее. Хотя для описанной Вами в самом начале задачи (есть датчик температуры, берём из него данные, т.е. быстродействие не критично) данное решение очень даже подходит.

P.S. Спорить не хочу, Вы спросили почему данное решение не нашло применение во втраиваемых системах - я высказал своё мнение.
Аватара пользователя
mgalemin
 
Сообщения: 66
Зарегистрирован: 07 авг 2010, 06:36
Откуда: Sydney, Australia
прог. языки: C/C++

Re: Управление роботом с компьютера. Новый подход.

Сообщение Michael_K » 31 авг 2010, 18:05

В UDP на каждый пакет передается восемь служебных байтов. в UDP/IP - 28.
Я не уверен, что реализация TinyRPC сильно хуже (скорее всего даже лучше).

А вот "почему данное решение не нашло применение во втраиваемых системах" - это другой вопрос.

И причин, по-моему, несколько:

Прежде всего, встраиваемые системы, даже если они имеют возможность общаться с "хостом" - это все-таки обычно системы автономные. То есть контроллер лифта, например, может предоставлять информацию диспетчеру или данные диагностики, но все-таки основная его задача - автономная,
чтобы закрывать двери, опрашивать этажи, управлять движками, ему не нужен ни диспетчер, ни мониторинг (и это правильно!).

Второе. Встраиваемые системы - это совсем не "отладочные платы", на которых каждый день меняется концепция железа и софта. Большинство встраиваемых систем вообще никогда не перепрограммируются за всю жизнь с момента выпуска и/или установки (тот же контроллер лифта). Набор функций и железных и программных строго задан, заранее определен и не меняется. (И это тоже правильно.)

Третье. Во встраиваемых системах (в том числе распределенных) используются многие разные интерфейсы связи и протоколы передачи, разные типы данных, различные способы организации памяти. Это затрудняет выработку "стандарта RPC". Насколько я знаю, общепринятого стандарта нет также и в "компьютерном" мире, хотя технология используется (может быть я тут не прав).
Отсутствие "стандарта" означает отсутствие удобных инструментов (тех же библиотек или генераторов шаблонов).
Аватара пользователя
Michael_K
 
Сообщения: 6028
Зарегистрирован: 07 окт 2009, 00:29
Откуда: СПб

Re: Управление роботом с компьютера. Новый подход.

Сообщение Виталий » 31 авг 2010, 22:44

Если честно мы не планировали передавать потоковое видео или аудио. Для этого есть свои алгоритмы, протоколы...

Я согласен с доводами о том, что системы автономные, маленькие и не подвержены частым переделкам.
Но(!) я считаю, что это не причина, а следствие отсутствия стандартных систем которые бы позволили развивать сервис-ориентированную архитектуру на встраиваемой технике.

Насколько я знаю, общепринятого стандарта нет также и в "компьютерном" мире, хотя технология используется (может быть я тут не прав).

Есть реализации претендующие на стандарт.
Все новости о моих проектах http://savethebest.ru
Аватара пользователя
Виталий
 
Сообщения: 2114
Зарегистрирован: 08 окт 2004, 16:43
Откуда: St. Petersburg
Skype: quark-bot
ФИО: Клебан Виталий

Re: Управление роботом с компьютера. Новый подход.

Сообщение =DeaD= » 31 авг 2010, 22:54

Виталий писал(а):Я согласен с доводами о том, что системы автономные, маленькие и не подвержены частым переделкам.
Но(!) я считаю, что это не причина, а следствие отсутствия стандартных систем которые бы позволили развивать сервис-ориентированную архитектуру на встраиваемой технике.

Я думаю, что не совсем такая связь причины и следствия.

1. Дело еще в том, что встраиваемые системы должны отличаться надежностью. А надежность и частые изменения в программном обеспечении низкого уровня - вещи слабо совместимые, как минимум исходя из принципа "почему солнце каждое утро встает на востоке, а садится на западе? ... ТЫ НИЧЕГО НЕ ТРОГАЛ? - Нет. - И не трогай. Так надо"

А отсюда и отсутствие необходимости в частых пересмотрах протокола, и как следствие отсутствие жесткой необходимости в фреймворке.

2. Далеко не всегда все компоненты системы (а особенно прикладной софт ПК и низкоуровневые устройства на МК) разрабатывает один и тот же человек\фирма, а значит скорее всего разработчик железа не всегда знает из какой среды разработки будут вызывать его функции, поэтому самый простой выход для него - обеспечить какой-то классический (интерфейс + протокол) типа CANBUS, RS485, 1-wire или тому подобный + прописать спецификацию команд\запросов в терминах этого протокола.

Вот из всего этого и получается, что относительно редко нужно в таком прямом виде RPC.

PS: Всё это не умаляя его полезности, удобства и нужности в существенном классе случаев.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Управление роботом с компьютера. Новый подход.

Сообщение Виталий » 31 авг 2010, 23:46

А надежность и частые изменения в программном обеспечении низкого уровня - вещи слабо совместимые...

Во время разработки изменения неизбежны. При этом если мы говорим о действительно надежных системах, то автоматически синтезированный непосредственно по требованиям протокол как для клиента, так и для сервера лучше, чем такой же протокол написанный вручную.

Но наша задача существенно проще, нам надоело писать протоколы руками, они постоянно меняются у нас, возникают рассогласования в передающей и приемной части. Нам нужен удобный инструмент. Мы его делаем. А для того чтобы было полезно и другим - делаем для Ардуино.

Концепции пока нет, но она появиться... со временем.
Все новости о моих проектах http://savethebest.ru
Аватара пользователя
Виталий
 
Сообщения: 2114
Зарегистрирован: 08 окт 2004, 16:43
Откуда: St. Petersburg
Skype: quark-bot
ФИО: Клебан Виталий

Re: Управление роботом с компьютера. Новый подход.

Сообщение Michael_K » 01 сен 2010, 01:14

Ребят, а давайте уже не будем про сферических в вакууме... Это бессмысленно - нужен ли тачскрин "сферическому роботу", нужен ли RPC "сферическому эмбеддеру"...
Давайте говорить "роботу-пылесосу нужен тачскрин", "контрорллеру стиральной машинки нужен RPC".


Протокол ведь специфицируют по многим разным причинам - и из-за того, что разные компоненты могут разрабатываться разными людьми, и из-за того, что отдельные компоненты, например, отдельно тестируются, имеют отдельную документацию, и с прицелами на последующие апгрейды (в том числе это может быть переход на другое железо, ось, язык программирования). Случаи-то разные. Часто, например, и вовсе требуется чтобы контроллер был инициатором обмена или роли могут быть нежесткими.

RPC, уверен, имеет право на жизнь точно так же как любое другое решение. И наверняка есть специфические (или не очень специфические) проекты, для которых такое решение будет оптимальным,
как и проекты, для которых оно не подойдет никогда. "Жизнь разнообразна в своих проявлениях"(с)

Подумалось, что может быть имеет смысл расширить (или сузить?) идею "чистого RPC" до генератора парсеров? Но это все равно оффтопик!

Добавлено спустя 3 минуты 21 секунду:
Виталий писал(а):Нам нужен удобный инструмент. Мы его делаем. А для того чтобы было полезно и другим - делаем для Ардуино.


Весь смысл работы в этой фразе - ни к чему эти теоретизирования.
Люди делают инструменты для себя. Да еще и о других не забывают.
Молодцы, что еще сказать.
Аватара пользователя
Michael_K
 
Сообщения: 6028
Зарегистрирован: 07 окт 2009, 00:29
Откуда: СПб

Re: Управление роботом с компьютера. Новый подход.

Сообщение Виталий » 01 сен 2010, 01:29

Протокол ведь специфицируют по многим разным причинам - и из-за того, что разные компоненты могут разрабатываться разными людьми, и из-за того, что отдельные компоненты, например, отдельно тестируются, имеют отдельную документацию, и с прицелами на последующие апгрейды (в том числе это может быть переход на другое железо, ось, язык программирования).

Да, но ведь скажите же, что во многих случаях удобнее задавать протокол неявно - в виде списка вызываемых функций.
Все новости о моих проектах http://savethebest.ru
Аватара пользователя
Виталий
 
Сообщения: 2114
Зарегистрирован: 08 окт 2004, 16:43
Откуда: St. Petersburg
Skype: quark-bot
ФИО: Клебан Виталий

Re: Управление роботом с компьютера. Новый подход.

Сообщение Michael_K » 01 сен 2010, 01:43

Конечно, здорово, если парсер сгенерируется автоматически, а вот из чего его генерять и как - это уже вопрос реализации.

Ну вот я выпустил следующую версию контроллера лифта не на пике, а на арме - что делать?
порядок аргументов другой, инты теперь 32-х битные, и вообще жава...

Или независимый пользователь решил написать свою программку для управления купленным лифтом (скажем вынтегрировать его в свою систему контроля доступа) - и что?

Я вообще не думаю, что "универсальное" решение существует, или даже если оно возможно, то будет широко востребовано. Но в каждом конкретном случае - "универсальное" и не нужно!
Аватара пользователя
Michael_K
 
Сообщения: 6028
Зарегистрирован: 07 окт 2009, 00:29
Откуда: СПб

Re: Управление роботом с компьютера. Новый подход.

Сообщение Виталий » 01 сен 2010, 02:00

Ну вот я выпустил следующую версию контроллера лифта не на пике, а на арме - что делать?

Перекомпилировать код. Код TinyRpc системонезависимый. Написан на Си.

порядок аргументов другой, инты теперь 32-х битные, и вообще жава...

Если изменился порядок - ничего страшного. Если состав аргументов - то это плохо. Разрядность и язык не имеют значения.

Или независимый пользователь решил написать свою программку для управления купленным лифтом (скажем вынтегрировать его в свою систему контроля доступа) - и что?

Дело в том, что TinyRpc - подкласс протокола JSON-RPC. Так что это как раз для нас.
- Мы можем отдать ему C# класс для доступа.
- Мы можем сгенерировать ему класс доступа для любого другого языка.
- Мы можем сгенерировать описание протокола в виде XML, а он при помощи XSLT преобразует его в необходимый код.
- Мы можем сгенерировать описание протокола в виде JSON объектов.
Все новости о моих проектах http://savethebest.ru
Аватара пользователя
Виталий
 
Сообщения: 2114
Зарегистрирован: 08 окт 2004, 16:43
Откуда: St. Petersburg
Skype: quark-bot
ФИО: Клебан Виталий

Пред.След.

Вернуться в Микроконтроллеры

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0

cron