roboforum.ru

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

PS: Пересоздал тему, а то неудачно её почистил от оффтопа

для начала предлагаю стандартизировать протокол управления,
дабы одна программа могла управлять разными ботами :roll:

мои идеи:
последовательная шина,
для маршрутизации используется нетсукуку,
имеется деление устройств на классы
(например шим контроллер, серва, сонар)
при этом физическая их реализация безразлична ( одна плата на 18 шимов или 3 платы по 6
- неважно)
устройство может получать и посылать сообщения( пакет данных в одну сторону),
например контроллер сервы получает команду(завернутую в сообщение) положение 30 градусов,
он получает собщение от датчика положения - положение 20 град,
и посылает команду шиму - 100%
так можно будет обьединить программы,
написанные на разных языках программирования,
исполняющиеся на разном железе :roll:

2Lebaon: Предлагается для начала быть на порядок проще

Шаг 1. Считаем что у нас есть шлюз uart<=>i2c.
Шаг 2. Считаем что по адресу 255 располагается устройство интегрированное в шлюз.
Шаг 3. Всё общение с такой сетью устройств ведём как с i2c сетью.

Это позволяет:
1. Автоматически спокойно юзать всю i2c периферию (наиболее яркий пример - сонары);
2. Не заморачиваясь, единым образом адресовать устройства, как интегрированные в шлюз, так и висящие на шине i2c;

Далее у меня уже есть решение для такого шлюз-контроллера с интегрированным набором аналогово-цифровых портов:
[[Шлюз-контроллер GATE-8A16D]]

Единственное чего там нет - контроллер двигателей, но и то потому что мои интересы простираются намного дальше, чем выдать "ШИМ 95%", мне видите ли сразу обратную связь подавай от энкодеров и ПИД-регулятор, а так же очередь команд на перемещение...

А так всё готово. Причем из шлюз-контроллера легко сделать подчиненный контроллер на i2c шину, у меня в прошивке для этого уже всё подготовлено, нужно только из другой процедуры обработку запроса вызывать - не по приходу данных с uart'а, а по приходу данных с i2c.

Предлагается для начала быть на порядок проще

простота не должна мешать расширяемости!
Шаг 1. Считаем что у нас есть шлюз uart<=>i2c.
в принципе, до физического уровня нам и не надо опускаться :wink:

вот например робот грома - там вообще поток данных пойдет по тсп-айпи, через вайфайку :crazy:

и так далее, имеется в виду логический протокол, который можно завернуть во что угодно :roll:

Шаг 2. Считаем что по адресу 255 располагается устройство интегрированное в шлюз.

как быть тем, у кого нет шлюза? или несколько девайсов цепочкой?
кроме того, у вас ф-ии разных типов в одну кучу будут :bad:

1. Автоматически спокойно юзать всю i2c периферию (наиболее яркий пример - сонары);

раз у нас есть шлюз, пусть он и транслирует протокол :roll:

Единственное чего там нет - контроллер двигателей, но и то потому что мои интересы простираются намного дальше, чем выдать "ШИМ 95%", мне видите ли сразу обратную связь подавай от энкодеров и ПИД-регулятор, а так же очередь команд на перемещение..

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

при этом нам глубоко пофиг, как именно реализован модуль, или что одна плата содержит несколько
их, или что какие-то части вообще на компе програмно реализованны :wink:

lebaon писал(а):простота не должна мешать расширяемости!
Шаг 1. Считаем что у нас есть шлюз uart<=>i2c.
в принципе, до физического уровня нам и не надо опускаться
вот например робот грома - там вообще поток данных пойдет по тсп-айпи, через вайфайку
и так далее, имеется в виду логический протокол, который можно завернуть во что угодно

1. Что значит до физического уровня не надо опускаться? У вас уже всё готово?
2. А что вы хотите от логического протокола? Какую задачу вы хотите решить так, чтобы каждый её не перерешивал?
3. Введя логический протокол отличающийся от физического вы обречёте себя на прописывание драйвера к каждому устройству на уровне шлюза, а у меня это решено одним махом

lebaon писал(а):
Шаг 2. Считаем что по адресу 255 располагается устройство интегрированное в шлюз.
как быть тем, у кого нет шлюза? или несколько девайсов цепочкой?
кроме того, у вас ф-ии разных типов в одну кучу будут

Что такое "функции разных типов" в кучу? Что где в этом плохого то? А у вас будет бесконечное прописывание функций, которые никогда ни у кого друг с другом не совпадут

чем лучше?

lebaon писал(а):
1. Автоматически спокойно юзать всю i2c периферию (наиболее яркий пример - сонары);

раз у нас есть шлюз, пусть он и транслирует протокол

Что имеется в виду? Куда кого транслирует? Вы что собрались писать обертку для каждого i2c устройства? Да сонаров одних только несколько типов...

lebaon писал(а):
Единственное чего там нет - контроллер двигателей, но и то потому что мои интересы простираются намного дальше, чем выдать "ШИМ 95%", мне видите ли сразу обратную связь подавай от энкодеров и ПИД-регулятор, а так же очередь команд на перемещение..

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

Во-первых на компе их не реализуешь (скорости обмена не те), да и трафик это сожрет махом;
Во-вторых у меня тоже пофиг что их несколько на плате или на шине;

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

1. Что значит до физического уровня не надо опускаться? У вас уже всё готово?
2. А что вы хотите от логического протокола? Какую задачу вы хотите решить так, чтобы каждый её не перерешивал?
3. Введя логический протокол отличающийся от физического вы обречёте себя на прописывание драйвера к каждому устройству на уровне шлюза, а у меня это решено одним махом

1. согласен, нет пока
2. единый сетевой протокол для всех модулей
3. вам тоже писать придется , но у меня писать приется небольшую обертку, а у вас все связанное :wink:

Что такое "функции разных типов" в кучу? Что где в этом плохого то? А у вас будет бесконечное прописывание функций, которые никогда ни у кого друг с другом не совпадут чем лучше?

не бесконечное, и совпадут!
вон, у всех (почти) есть код шима, или обратной связи по положению( сервы), и тд.
и их есть смысл стандартизировать :roll:

Что имеется в виду? Куда кого транслирует? Вы что собрались писать обертку для каждого i2c устройства? Да сонаров одних только несколько типов..

да, обертку, зато если надо сменить тип сонаров надо менять только ее, а не полкода
а вам фактически тоже придется писать обертку :wink:

Во-первых на компе их не реализуешь (скорости обмена не те), да и трафик это сожрет махом;

это для управленцев шаговиками через lpt :wink:

Во-вторых у меня тоже пофиг что их несколько на плате или на шине;

то есть три ваших шлюза можно соединить цепочкой, и все будет работать?

Не хотелось бы уйти в разработку USB с профилями устройств для робота

с усб тут лишь идеология немного похожа, а вообще я от qnet пляшу :crazy:

lebaon писал(а):2. единый сетевой протокол для всех модулей
3. вам тоже писать придется , но у меня писать приется небольшую обертку, а у вас все связанное

2. Единый сетевой протокол - мифическая вещь реально никому не нужная в том виде в котором сможете реализовать, а в том котором может быть нужно - сил не хватит.
3. Мне не придется - придётся тому, кто пользуется i2c устройством. А если человек по образцу не способен накидать 10 строк кода на ПК, где он собирается писать основную управляющую программу - это клиника, а не робототехника.

lebaon писал(а):
Что такое "функции разных типов" в кучу? Что где в этом плохого то? А у вас будет бесконечное прописывание функций, которые никогда ни у кого друг с другом не совпадут чем лучше?

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

Во-первых при чем тут код ШИМа? Я говорю об обертках разных устройств типа контроллер двигателей? Вы с чего взяли что они все на вход могут ШИМ только брать?

lebaon писал(а):
Что имеется в виду? Куда кого транслирует? Вы что собрались писать обертку для каждого i2c устройства? Да сонаров одних только несколько типов..

да, обертку, зато если надо сменить тип сонаров надо менять только ее, а не полкода
а вам фактически тоже придется писать обертку

Но я то обертку пишу для каждого из имеющихся устройств за 5 минут. Итого за полчаса - 6 устройств, а вы что предлагаете? Сэкономить эти 5 минут на устройство заморочившись на заранее готовые обертки?

lebaon писал(а):
Во-вторых у меня тоже пофиг что их несколько на плате или на шине;

то есть три ваших шлюза можно соединить цепочкой, и все будет работать?

Да, по i2c, просто два дочерних шлюза надо пока перепрошить (хотя позже можно сделать автодетект) и простно надо будет в запросе указать адрес шлюза к которому обращаемся.

lebaon писал(а):
Не хотелось бы уйти в разработку USB с профилями устройств для робота

с усб тут лишь идеология немного похожа, а вообще я от qnet пляшу

Главное тут - если вы собираетесь писать на ПК обертку под каждый девайс и придумывать хитровыдуманный универсальный логический протокол для уровней от интернета до i2c, - тогда мне с вами 100% не по пути.

Во-первых при чем тут код ШИМа? Я говорю об обертках разных устройств типа контроллер двигателей? Вы с чего взяли что они все на вход могут ШИМ только брать?

1. потому что один из самых распространенных
2. может быть реализован как аппаратно так и программно
3. как раз контроллеры двигателей берут на вход достаточно однотипный набор запросов,
которые они и транслируют в запросы к шиму, энкодерам, драйверам шаговиков, етс
при этом контроллеру двигателей глубоко пофиг, как там шим реализован - программно, аппаратно,
на той же меге, или на другом конце системы

3. Мне не придется - придётся тому, кто пользуется i2c устройством. А если человек по образцу не способен накидать 10 строк кода на ПК, где он собирается писать основную управляющую программу - это клиника, а не робототехника

а когда сотни людей изобретаю велосипед это не клиника?

о я то обертку пишу для каждого из имеющихся устройств за 5 минут. Итого за полчаса - 6 устройств, а вы что предлагаете? Сэкономить эти 5 минут на устройство заморочившись на заранее готовые обертки?

угу, это конкретно ты за 5 минут, а менее опытный и час будет трахаться,
и еще сюда вопросы писать

Да, по i2c, просто два дочерних шлюза надо пока перепрошить (хотя позже можно сделать автодетект) и простно надо будет в запросе указать адрес шлюза к которому обращаемся.

хорошо, а указание номера шлюза - это тоже надо заложить в стандарт тогда

Главное тут - если вы собираетесь писать на ПК обертку под каждый девайс и придумывать хитровыдуманный универсальный логический протокол для уровней от интернета до i2c, - тогда мне с вами 100% не по пути.

вспомним дос, где каждая прога имела свои драйвера - ведь что бы добавить еще один,
главному программеру нужно было всего 5 минут :wink:

lebaon писал(а):
Во-первых при чем тут код ШИМа? Я говорю об обертках разных устройств типа контроллер двигателей? Вы с чего взяли что они все на вход могут ШИМ только брать?

1. потому что один из самых распространенных
2. может быть реализован как аппаратно так и программно
3. как раз контроллеры двигателей берут на вход достаточно однотипный набор запросов,
которые они и транслируют в запросы к шиму, энкодерам, драйверам шаговиков, етс
при этом контроллеру двигателей глубоко пофиг, как там шим реализован - программно, аппаратно,
на той же меге, или на другом конце системы

У вас большой опыт разве по драйверам двигателей? Вы вообще спецификации к разным продвинутым драйверам двигателей читали?

Про мой подход читали?

lebaon писал(а):
3. Мне не придется - придётся тому, кто пользуется i2c устройством. А если человек по образцу не способен накидать 10 строк кода на ПК, где он собирается писать основную управляющую программу - это клиника, а не робототехника

а когда сотни людей изобретаю велосипед это не клиника?

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

lebaon писал(а):
о я то обертку пишу для каждого из имеющихся устройств за 5 минут. Итого за полчаса - 6 устройств, а вы что предлагаете? Сэкономить эти 5 минут на устройство заморочившись на заранее готовые обертки?

угу, это конкретно ты за 5 минут, а менее опытный и час будет трахаться,
и еще сюда вопросы писать

Я уже сказал - никто не мешает туториал написать.

lebaon писал(а):
Да, по i2c, просто два дочерних шлюза надо пока перепрошить (хотя позже можно сделать автодетект) и простно надо будет в запросе указать адрес шлюза к которому обращаемся.

хорошо, а указание номера шлюза - это тоже надо заложить в стандарт тогда

У меня в стандарте это адрес устройства на i2c шине. Я уже указал это выше.

lebaon писал(а):
Главное тут - если вы собираетесь писать на ПК обертку под каждый девайс и придумывать хитровыдуманный универсальный логический протокол для уровней от интернета до i2c, - тогда мне с вами 100% не по пути.

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

А вы не задумывались никогда, что при том уровне распространения технологий это было экономически-правильное решение?

Давайте дождемся сотен и тысяч пользователей и тогда будем экономить эти 100-1000 часов занимаясь стандартизацией и написанием кучи драйверов. А пока у нас нет и 20 пользователей - я не собираюсь тратить 160 часов, чтобы сэкономить 20 чужих часов. Это неэффективно.

Интересная беседа. Разбавлю вот своим проектом. Так как на роботе использую Линукс, то и пишу соответственно под него. Идея, впринципе, заключается в том, что есть некий сервис, автоматически подключающий разного рода модули(к примеру, модуль шасси, модуль датчиков, причем датчики могут быть разных типов,то есть разделены на подклассы), а управление всем идет либо через сокет либо ручное управление. Можно подключать любое количество следящих портов usart, twi, spi, при этом просто написав файлы конфигурации(xml). Подключил некое устройство, оно определилось, подключилось, и теперь можно посмотреть что за устройство и посылать команды(управление шасси и датчиками пока точно не определено). Также предполагается собрать модуль wireless, для конфигурации некоторого беспроводного модуля и управление роботом на расстоянии. Делаю для того, чтобы при написании какихлибо алгоритмов не было проблем, связанных с "механикой". Ну вот впринципе и все, свое дело сделал)

ЗЫ: весь софт работающий на роботе также работоспособен и на Windows(cygwin), где и отлаживаеца в основном, и в обычных дистрибах Линя. Так что компьютер тоже может выступать в роли своеобразного "робота". Ну по крайней мере, COM порт есть.

Сергей писал(а):Интересная беседа. Разбавлю вот своим проектом.

Если честно почти ничего не понял

а хотелось бы, посему вопросы:

Сергей писал(а):Идея, впринципе, заключается в том, что есть некий сервис, автоматически подключающий разного рода модули(к примеру, модуль шасси, модуль датчиков, причем датчики могут быть разных типов,то есть разделены на подклассы), а управление всем идет либо через сокет либо ручное управление. Можно подключать любое количество следящих портов usart, twi, spi, при этом просто написав файлы конфигурации(xml).

Как можно универсальным образом работать скажем с i2c и с uart'ом? Они же приниципиально разные - адресации во втором нету.

Сергей писал(а):Подключил некое устройство, оно определилось, подключилось, и теперь можно посмотреть что за устройство и посылать команды(управление шасси и датчиками пока точно не определено).

Грабли в том, что у вас должен быть весь спектр устройств и универсальные команды подходящие ко всему спектру устройств, а у вас этого принципиально быть не может, как вы это решаете?

Сергей писал(а):Также предполагается собрать модуль wireless, для конфигурации некоторого беспроводного модуля и управление роботом на расстоянии. Делаю для того, чтобы при написании какихлибо алгоритмов не было проблем, связанных с "механикой". Ну вот впринципе и все, свое дело сделал)

Какие успехи имеются на этом пути и сколько это заняло времени, если не секрет?

=DeaD= писал(а):Если честно почти ничего не понял а хотелось бы, посему вопросы:

Да, действительно, объясняю я плохо, посему отвечаю на вопросы

=DeaD= писал(а):Как можно универсальным образом работать скажем с i2c и с uart'ом? Они же приниципиально разные - адресации во втором нету.

Ну тут я допускаю, что у usart есть только один адрес 0. Использование i2c предполагает, что перед использованием порта будет назначен адрес.
Также хочу отметить, что twi еще не прошел окончательных тестов. Как только будет отлажен и будет стабильно работать - я уже точно определюсь с "универсальностью".

Вот приведу пару грубых примеров работы с портом:

Код: Выделить всё • Развернуть

   ///////////
   // USART //
   ///////////
   GUsart usart;
   std::string buffer;
   
   usart.Open("/dev/ttyS0", "configure.xml");
   usart << "Hello, world! Say something: ";
   usart >> buffer;
   
   usart.Close();
   
   /////////
   // TWI //
   /////////
   GTwi twi;
   std::string buffer;
   
   twi.SetSlaveAddress(0x1F);   
   twi.Open("/dev/i2c-0", "configure.xml");
   twi << "Hello, world! Say something: ";
   twi >> buffer;
      
   twi.SetSlaveAddress(...);
   twi << "Hello, world again! Say something: ";
   ...
   
   twi.Close();
   
   /////////////////////
   // CHASSIS & USART //
   /////////////////////
   ...
   GChassis<GUsart> chassis(usart);
   
   chassis.Configure();
   chassis.Launch();
   
   chassis.Move(...);

=DeaD= писал(а):Грабли в том, что у вас должен быть весь спектр устройств и универсальные команды подходящие ко всему спектру устройств, а у вас этого принципиально быть не может, как вы это решаете?

А я это не решаю. Библиотеку я делаю только ради удовольствия, и только в своих целях. Мне необходимо, чтобы можно было динамически подключать разные шасси, подключать имеющиеся типы датчиков, использовать в алгоритмах. Устройства я буду делать сам, но скорее всего буду делать один многофункциональный модуль на имеющемся ARM7.

=DeaD= писал(а):Какие успехи имеются на этом пути и сколько это заняло времени, если не секрет?

В разработке. Пока ничего не могу сказать.

сергей, а не могли бы вы выложить ваши разработки?
это, думаю, решило бы проблему в корне :roll:

Выкладывать пока не собираюсь, все очень сырое. Да и к томуже я просто рассказал о своей идее, не вдаваясь в проблемы реализации :wink:

Сергей писал(а):
=DeaD= писал(а):Как можно универсальным образом работать скажем с i2c и с uart'ом? Они же приниципиально разные - адресации во втором нету.

Ну тут я допускаю, что у usart есть только один адрес 0. Использование i2c предполагает, что перед использованием порта будет назначен адрес.
Также хочу отметить, что twi еще не прошел окончательных тестов. Как только будет отлажен и будет стабильно работать - я уже точно определюсь с "универсальностью".

Почему-то мне кажется, что на этому пути "универсальности" при практическом использовании вы столкнётесь с недетскими проблемами. У вас опыт использования в практических конструкциях i2c какой? Как быть с хитрыми синхронизированными запросами "команда+ответ"? С точки зрения UART'а это вообще полный бред

Сергей писал(а):Вот приведу пару грубых примеров работы с портом:

Всё красиво, вот только вы работали с i2c как с uart'ом, особенно на чтение, а там всё по другому делается.

Сергей писал(а):
=DeaD= писал(а):Грабли в том, что у вас должен быть весь спектр устройств и универсальные команды подходящие ко всему спектру устройств, а у вас этого принципиально быть не может, как вы это решаете?

А я это не решаю. Библиотеку я делаю только ради удовольствия, и только в своих целях. Мне необходимо, чтобы можно было динамически подключать разные шасси, подключать имеющиеся типы датчиков, использовать в алгоритмах. Устройства я буду делать сам, но скорее всего буду делать один многофункциональный модуль на имеющемся ARM7.

Тогда давайте говорить об этом модуле, а не о типовом протоколе для всего-всего-всего

раз у вас будут драйвера только для вашей платы

А я то предлагаю как раз универсальный подход для любых устройств, когда их сможет использовать каждый школьник владеющий C++ Builder'ом не вникая в программирование МК.

Сергей писал(а):
=DeaD= писал(а):Какие успехи имеются на этом пути и сколько это заняло времени, если не секрет?

В разработке. Пока ничего не могу сказать.

Вооот!

А у меня готовое решение уже есть кроме драйвера двигателей

Сейчас, кстати, развожу платку на которой оставил 16 портов (8 аналоговых+8цифровых), снес COM-интерфейс, зато поставил регулятор напряжения, и драйвер двигателей. Должно получиться универсальное решение на котором можно делать компактных автономных роботов (контроллер ATMega16/32/644 выбираем по вкусу с нужным нам объемом памяти) или роботов с управлением по Bluetooth (цепляем сверху модуль на разъем TTL-UART и вперед).

roboforum.ru

Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)

Re: Типовые решения для робота на базе ПК(в т.ч. на радиоканале)