roboforum.ru

https://youtu.be/_xWuuY9n6EA
https://github.com/yrasik/Scratch2_and_ROBO
Проект напоминает ScratchDuino, но в отличие от оного имеет исходный код сервера (Написан на QT5) транслирующего команды из Scratch2 в последовательный порт. Делаю с целью заразить своих детишек робототехникой... Сейчас занимаюсь изготовлением роборуки (привинчу соответствующие команды управления в интерфейсную программу).

Добавляю модель роборуки (в папке 3D). Это скорректированная версия : лично распечатал на 3d принтере (ABS - пластик) - вроде юзабельна. Сделал коррекцию по резулютатам. Эта коррекция и выложена... Нужен шаговый двигатель '28BYJ-48 – 5V Stepper Motor' c платой драйвера ' ULN2003 Driver Board', сервоприводы 'Tower Pro 9g SG90'

Файл - RoboHand.STEP - степ-модель роборуки в сборке. Можно открыть, к примеру в САПР 'FreeCAD'.

Мозги этому всему ещё не вправлены. Буду теперь со Scratch2 это склеивать... Не знаю, позволяет ли S4A (https://www.youtube.com/watch?v=LxDhGAjQQ3U) управлять подобными вещами....

Здравствуйте, я тоже буквально на днях разбирался с этой темой, хотел сделать точно тоже самое что вы сделали
Очень полезный проект!

Расскажите пожалуйста по подробнее как у вас всё работает.
Насколько я понял, изначально scratch был на flash, потом была попытка переписать на html5
https://github.com/LLK/scratch-html5 но её забросили
ScratchDuino я тоже находил, но всё упёрлось в сервер, который только для винды и макоси а у меня линукс.

Забегая вперёд, от сервера можно отказаться если использовать wifi модули
там даже micropython можно запустить
http://docs.micropython.org/en/latest/e ... ckref.html
платы стоят недороже ардуино.

Но есть и более навороченные модули https://ru.aliexpress.com/item/WiFiMCU- ... 95787.html
тут с перефирией всё просто супер.

с такими wifi модулями можно плавно перейти от scratch к программам на python при обучении

Добавлено спустя 5 минут 43 секунды:
Вот как пример платформы (железо) тоже самое что у вас но работает по wifi http://www.rudiswiki.de/wiki9/WiFiCar-NodeMCU

Добавлено спустя 11 минут 43 секунды:
micropython или lua в таких модулях хороши тем что не нужен компилятор, программу можно писать прямо в браузере.

Я написал сервер (друзья помогли) на QT5 - это кроссплатформенные библиотеки C++ можете попытаться собрать под линухами - я чисто QT5 библиотеки использовал, никакой виндузятины, все исходники в гитхабовском репозитории по ссылке в теме). Сервер цепляет клиент Scratch2, принимает от него пакеты, парсит их, создает пакеты для последовательного порта COM и выдает в этот порт. В том числе последовательным портом может служить и блютус донгл и usb-rs перетяжка. Пакет попадает в плату (пока ардуинку) где разбирается команда. В обратку формируется пакет подтверждения выполнения и информация с сенсоров. Пакеты все пронумерованы, поэтому сбой сразу становится очевиден. Сервер в компе принимает этот пакет, анализирует на адекватность (я контрольные суммы пока не вводил), формирует из него пакет для скрэтча и отсылает его этому скрэтчу. Если с пакетами чуть что не так- выводится сообщение в консоль программы сервера. В самом скрэтче заложена возможность взаимодействия с подобными серверами, каковой я и воспользовался.. Например, в проекте S2A подобный сервер реализовали на питоне 2.7. Вообще я выложил сопроводительный документ к моему художеству. Лежит в гитхабовском репозитории..

нашёл файл, нужно сразу в readme На гитхабе ссылку на него давать https://github.com/yrasik/Scratch2_and_ ... /about.pdf =)

я смотрел как оригинальная связка работает, там firmata протокол используется.
с моей точки зрения далеко не идеальный протокол.

может вам будет интересно, я недавно написал свой, который доступен в том числе и для ардуино forum87/topic15337-225.html#p360661

он бинарный с чексуммой и подтверждением доставки.

Добавлено спустя 10 минут 9 секунд:
А во, вспомнил, кроме сервера, ещё не понравилось то что нужно качать Adobe AIR., спорная технология, на мой взгляд совершенно ненужная тут.
вроде
https://github.com/LLK/scratch-blocks и
https://github.com/LLK/scratch-vm
не требуют Adobe AIR.

может можно свою офлайн версию собрать?

Вот тут подробнее про Scratch 3 https://scratch.mit.edu/discuss/topic/1 ... st-1993799

кстати есть уже попытки скрестить esp8266 и scratch2 https://github.com/UNUMobile/wf8266r/tr ... js/Scratch
посмотрел ваш код, как я понял вы свой протокол реализовали между ардуино и сервером на qt5

Да. Свой протокол типа запрос-ответ. Была идея modbus сделать, но побоялся запутаться. Модбас бы мне не помог ничем (тотже запрос- ответ, только там пакеты не пронумерованы, наложены тайминги на принятие байт, crc16).
Я замутил было склейку с NRF24l01+ - даже работало, пока не начал периферию у робота активировать... а там все сдулось... Видимо ЭМС (т.к. узкополосная частотная манируляция...) Переехал на блютус. Ваши вайфаевские модульки лежат, ждут своего часа. Еще не игрался...

если развивать тему scratch + wifi то вот хорошие модули, недавно появились http://esp8266.ru/forum/threads/sravnen ... 467/page-3
http://www.amebaiot.com/en/ameba-sdk-boards/
на борту есть всё что нужно

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

блютуз это небольшое расстояние и очень медленно, сам протокол блютуз работает пачками с перерывами по 20мс (50гц) т.е. если делать запрос-ответ то и вовсе 25гц получается. т.е. лучшее что можно получить это 60 байт с частотой 25гц в одну и в другую сторону.
на мой взгляд это очень медленно, я от него отказался. лучше в сторону wifi идти.

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

>NRF24l01 а там все сдулось..
а в чём это выражалось ? я с таким модулями не работал, просто интересно.

Добавлено спустя 21 минуту 18 секунд:
Поскольку у меня пока мало примеров, я вам немножко порекламмирую на примере как могло бы быть если переписать ваш код.

У вас вот так

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

      case SCRATCH_TAG__move_right :
          Motor_Left(false, true);
          Motor_Right(true, true);     
          wait_command = 1;
          wait_id = ((unsigned int)(command_rx[1]) << 8) | (unsigned int)(command_rx[2]);
          delay_ms = ((unsigned long )(command_rx[3]) << 24) |
                     ((unsigned long )(command_rx[4]) << 16) |
                     ((unsigned long )(command_rx[5]) << 8) |
                      (unsigned long )(command_rx[6]);
          time_interval_finish = millis() + delay_ms;
         // printf("r\n");
       break;

А можно так:
со стороны контроллера напишем:

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

typedef struct {
  uint32_t delay_ms;
  uint16_t wait_id;
  uint8_t Direction;
}Move_msg;

const  SerialProtocolCmd_t SD_CMDS[] ={
  {0,NULL,NULL,NULL,0,NULL,NULL,NULL},
  {sizeof(Move_msg),&Move_msg,on_move_msg,NULL,sizeof(Move_msg),&Move_msg,NULL,NULL}
};


uint8_t on_move_msg(uint16_t data_size,uint8_t *data,void *arg){
Move_msg * msg = (Move_msg*) data;
switch(msg->direction){
      case SCRATCH_TAG__move_right :
          Motor_Left(false, true);
          Motor_Right(true, true);     
          wait_command = 1;
          time_interval_finish = millis() + msg->delay_ms;
         // printf("r\n");
       break;
}
}

Со стороны хоста

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

typedef struct {
  uint32_t delay_ms;
  uint16_t wait_id;
  uint8_t Direction;
}Move_msg;

const  SerialProtocolCmd_t SD_CMDS[] ={
  {0,NULL,NULL,NULL,0,NULL,NULL,NULL},
  {sizeof(Move_msg),&Move_msg,on_move_msg,NULL,sizeof(Move_msg),&Move_msg,NULL,NULL}
};

const MSG_MOVE = 1;

...
Move_msg.Direction=SCRATCH_TAG__move_right;
Move_msg.wait_id++;
Move_msg.delay_ms=500;
if(sprt_send(MSG_MOVE,SD_SYNC) <0){ //в контроллер улетит 13 байт, от него вернётся 6байт - подтверждение доставки.
  printf("error, connection");
}

Т.е. всё описание протокола сводится к тому чтобы структуры с обеих сторон были одинаковыми и одинаковый массив команд SerialProtocolCmd_t SD_CMDS[].

uint16, uint32 я в протоколах остерегаюсь применять т.к. есть понятие big endian и little endian. На разных машинах/микроконтроллерах по разному... Еще есть понятие в компиляторе: упаковка данных в стуктурах (кратность 4 байтам, к примеру на 32 рпзрядных машинах). Т.е. между первым uint8_t и вторым uint32_t реально в ОЗУ может образоваться промежуток в 3 байта...

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

uint16, uint32 я в протоколах остерегаюсь применять т.к. есть понятие big endian и little endian.

когда последний раз вы работали с big endian? я считаю что big endian мёртв, теже arm что могут работать в двух режимах работают всегда в little endian. Даже если вдруг появится необходимость в big endian скорее всего это будет на стороне хоста, так что пусть он и занимается конвертацией big endian в lettle endian.

Еще есть понятие в компиляторе: упаковка данных в стуктурах (кратность 4 байтам, к примеру на 32 рпзрядных машинах). Т.е. между первым uint8_t и вторым uint32_t реально в ОЗУ может образоваться промежуток в 3 байта...

вот это серъёзное замечание, однако давайте подумаем какие данные мы пересылаем по протоколу?
это простые типы int8_t, int16_t, int32_t , float, double , char[] - фиксированного размера.

все эти типы одинаковые на всех системах, единственное что может отличаться - поведение компилятора когда данные вперемешку.
вот тут нужно учитывать одно правило, сначала в структуре указываем самые жирные данные, float,int32_t затем более компактные и в самом конце char.
в таком случае любой компилятор будет выравнивать по самым жирным, и будет использовать одинаковые padding байты если потребуется.
Поскольку мы контролируем обе стороны, я считаю такой подход безопасным,
кроме того, в протоколе заложена проверка на размер структуры, которая определяется через sizeof() если вдруг где то произойдёт расхождение протокол будет ругаться на неверный размер.

Про упаковку структур можно почитать например тут http://www.catb.org/esr/structure-packing/

Повторю, я считаю такие выкрутасы безопасными, если придерживаться ряда правил, зато это существенно ускоряет работу протокола,
я из ардуино обмен пакетами на частоте 1кгц выжимал по последовательному порту.
при этом она ещё и складывала значения в структуре и кое чего печатала.

Кстати на стороне хоста со скоростью обработки пакетов дела обстоят даже хуже т.к. на хосте не риалтайм ОС, т.е если не жарить проц то очень быстро реагировать на приходящие пакеты не так уж и просто.

Я так заморочился с протоколом для ROS, но таже проблема и с Scratch поскольку ардуина фактически превращается в исполнителя команд, то количество команд и их частота больше зависят от протокола а нет от скорости контроллера.

Что такое частота команд? это максимальная скорость с которой может работать высокоуровневый алгоритм, такой как scratch.
Т.е. аналог скорости виртуального процессора.

Добавлено спустя 56 минут 14 секунд:
по железу.
вот тут неплохая подборка деталей http://www.ebay.com/itm/Arduino-Robot-e ... 2632857325

http://www.elabpeers.com/ebot-z.html

список для ориентировки
Features:
• Smart Car Robot With Chassis And Kit [Round] x 1
• eLab Peers Einsboard with USB cable x 1
• L298P 2A Motor Driver Arduino Shield x 1
• HC-SR04 Ultrasonic Sensor with Servo and Rack x 1
• 4-Channel Automatic Robot Tracking Sensor x 1
• BC417 Bluetooth to Serial [Arduino] x 1
• H206 Opto-coupler Speed Sensor x 2
• Speed Encoder x 2
• 9V Battery Box x 1
• AA x 4 Battery Box x 1
• 40pc DuPont Wires [Male to Female] x 1
• 40pc DuPont Wires [Male to Male] x 1
• 220 ohm Resistor x 2
• Electrolytic Capacitor x 1
• LED in Red x 1
• LED in Green x 1
• Small Breadboard x 1
• Swivel Caster x 2
• Switch x 1
• Tape in Black Color x 1
• Set of Metal Standoffs x 1
• Set of Screws and Nuts x 1




в жёлтых редукторах стоят моторы модели 130 Motor.
можно заменить на вот такие моторы "Mabuchi Dual Shaft Strong Magnetic Carbon Brush 130 Motor Toys DIY"

тогда энкодер можно будет прикрепить прямо к валу двигателя, это позволит более точно поддерживать скорость вращения.
что внутри http://www.averagemanvsraspberrypi.com/ ... otors.html

В продолжении роборуки - решил сделать, чтобы у меня отдельная ардуинка управляла сервами и шаговиком, а сама управлялась по SPI. Т.е. была в роли SPI - slave.
Как не странно, с этим у ардуинок проблемы. В общем, https://github.com/yrasik/Scratch2_and_ ... lave_servo - SPI - slave реализован через прерывания. Оно работало. Сильно долго не тестировал, но результат понравился....

а видео какое нибудь есть?
рукой управляете из scratch?

кстати lego mindstorm Не рассматривали в качестве платформы?

linvinus писал(а):а видео какое нибудь есть?
рукой управляете из scratch?

кстати lego mindstorm Не рассматривали в качестве платформы?

Ещё не из скрэтча. С другой ардуинки. Там проблема была - когда на вход SPi - slave пуступало не кратное 8 ко-во байт. Типа питание передёрнул на мастере - и пошли далее ошибки приёма. Вылечил ресет SPI из прерывания GPIO. Как видите, код я стараюсь строить на диаграммах состояний - очень удобно локализовывать на каком шаге косяк случается...

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

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