roboforum.ru

Medtech писал(а):осталось поставить более маломощный БЛДС двигатель на рояльное колесо вместо датчика угла поворота и считывать по нему, за одно будет подпружинен а угол считать по мощности подаваемой на обмотки. Косинунсосинусный вращающийся трансформатор, сельсин, такие на станках с магнитной лентой стояли, прямое управление по записанным аналоговым сигналам. сигналам

это уже было в симпсонах https://www.youtube.com/watch?v=HtvWJJo ... Z6pIKEoGI9
три аналоговых датчика считывают "синусоиду" по ним определяю положение ротора далее как обычно

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

Полезные ссылки по ПИД регуляторам
https://habrahabr.ru/post/143388/
https://habrahabr.ru/post/145991/
http://www.bookasutp.ru/Chapter5_3_4.aspx

Обычно для загрузки прошивки в контроллеры STM32 я использовал stlink https://github.com/texane/stlink
но с ней бывают разного рода глюки, не всегда ресетит контроллер, а в последнее время вообще отказывалась прошивать, спотыкалась на каком то секторе, пока вручную кнопку ресет на контроллере не нажмёшь не прошивала.

в общем мне это надоело решил попробовать OpenOCD, когда то очень давно пробовал его использовать но требовались патчи и что то оно не взлетело у меня.
поставил версию OpenOCD 0.9 в ubuntu 14.04 пакет взял из репозитория 16.04
но с ресетом по прежнему были проблемы, потом на просторах интернета нашёл совет, в общем ставим пакет openocd

далее копируем /usr/share/openocd/scripts/board/stm32f4discovery.cfg (у меня STM32F405RGT6) в домашнюю директорию и заменяем в нём

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

reset_config srst_only
на
reset_config none separate

это заставит использовать ресет через SWD а не отдельной ножкой (у меня она не подключена, от программатора st-link v2 идёт три провода SWCLK,SWDIO,GND).

запускаем командой

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

sudo openocd -f /путь/до/нового/файла/stm32f4discovery.cfg

И жизнь снова прекрасна!

ps
эклипсом не пользуюсь, прошивку я загружаю через дебаггер
gdb-arm-none-eabi -ex "tar ext 3333" /путь/до/файлапрошивки.elf
в нём командой load загружаем прошивку
после перекомпиляции перезапускать дебаггер не нужно,
он увидит если прошивка изменилась и по команде load загрузит новую прошивку.

поставил на кинект дополнительную оптику


Так было


так стало, расстояние до ближайшего предмета 35см. до двери 60см


вердикт - не годится.сильные искажения по краям из за этого сильно уменьшается угол обзора у depth камеры.
выигрыш 15-20см в ближней зоне того не стоит
пробовал оставить линзу только на лазере, не работает, и хотя визуально картинка нормальная сенсор не может определить расстояние.

удалённо подключаюсь через xrdp , OpenGL работает через VirtualGL
как поставить virtualgl написано тут https://devtalk.nvidia.com/default/topi ... ?offset=15

Пока я изучаю smid команды сопроцессора ARM - neon решил передохнуть, наткнулся на довольно забавный видеоблог https://www.youtube.com/watch?v=2c4DJ8Y ... bLgo8H-5bl
Мне понравилось насколько креативно автор из хлама (за копейки) выжимаете вполне рабочие экземпляры.


Ну а если вам интересно что такое neon вот несколько ссылок
быстрый старт http://www.add.ece.ufl.edu/4924/docs/ar ... opment.pdf
более детально http://people.xiph.org/~tterribe/daala/ ... torial.pdf
пример реального использования http://nullprogram.com/blog/2015/07/10/

если кто не в курсе neon это аналог SSE для ARM. позволяет получить существенный прирост производительности при обработке больших объёмов данных, например картинок или видео, для того чтобы начать использовать на СИ с gcc достаточно подключить заголовочный файл #include <arm_neon.h>

linvinus писал(а):Пока я изучаю smid команды сопроцессора ARM - neon

linvinus писал(а):Ну а если вам интересно что такое neon вот несколько ссылок

linvinus писал(а):если кто не в курсе neon это аналог SSE для ARM. позволяет получить существенный прирост производительности

Манагер ARM, перелогиньтесь

Та то у него просто хвостик виляет

Чего не понравилось? сначала много писать не хотел, потом дополнил для любителей ардуины.

Вот кстати кое что подобное даже в STM32F429 и выше есть http://www.st.com/resource/en/applicati ... 273990.pdf

блин, меня запутали, модель E10C пишет видео только на карту .

модель E10W с wifi http://www.banggood.com/Eachine-E10W-Mi ... 48676.html
или Cheerson CX-10W

Решил я тоже в вертолётики поиграть
выбрал Eachine E10C Mini with 2MP Camera (1700р)
http://www.banggood.com/Eachine-E10C-Mi ... 39741.html

сравнение камеры http://www.areresearch.net/2016/04/each ... x-10c.html
протокол частично рассмотрен тут
https://dronegarageblog.wordpress.com/2 ... fpv-drone/
модуль камеры выглядит примерно так http://www.parkflyer.ru/ru/product/2294 ... n=26746116
скорее всего чип FH8620 Fullhan Microelectronics где бы нарыть SDK?

в похожем квадрике стоит STM32F050K4 http://we.easyelectronics.ru/igorp/the- ... ience.html
что тут я не знаю пока.
есть фотка верха платы http://www.banggood.com/Eachine-E10C-Mi ... 59295.html

проект открытого трансмиттера https://github.com/goebish/nrf24_multipro
альтернативная прошивка http://sirdomsen.diskstation.me/dokuwik ... =openmicro
Играться можно как то так

Тут я уже упоминал про использование нейронных сетей для распознавания общих образов post346191.html#p346191

вот ещё интересные проекты
https://github.com/jetpacapp/DeepBelief ... berry-pi-1

https://github.com/teradeep/demo-apps (закрытый проект но позволяет слинковать бинарную библиотеку в свой проект и есть готовая база образов)


Не обязательно быть гениальным художником, для написания шедевра достаточно взять знаменитую картину и попросить нейронную сеть нарисовать похожее на основе фотографии
https://github.com/jcjohnson/neural-style
потом выбрать понравившуюся https://youtu.be/3AnXiDksblA?t=270

Очень интересный проект torch (http://torch.ch/) это что то типа opencv только для написания своих сетей, высокоуровневый интерфейс на базе lua также прост как и opencv на python-е.
есть видео курсы https://youtu.be/mQn1QmN7fsY?t=572


Пример как можно написать сложное поведение робота http://www.pirobot.org/blog/0030/

Ухты, chibios На arduino https://github.com/greiman/ChibiOS-Ardu ... hBlink.ino

на втором месте после bldc по интересности, для меня, стоят протоколы взаимодействия между контроллерами.

тему я поднимал давно тут forum40/topic10112.html?style=8
Сергей сразу ответил что вопрос не в скорости а в протоколе.
С тех пор я много чего перепробовал, после того как освоил USB мне он кажется наиболее оптимальным в качестве связки между компом(ROS) и роботом (железом).
если есть возможность то лучше использовать USB (CONTROL message), просто, понятно быстро и надёжно.
Я выделяю структуры через которые происходит управление, например

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

struct BASE_CFG{
  //in mm
  float WHEEL_BASE_mm;
  float WHEEL_L_D_mm;
  float WHEEL_R_D_mm;

  float WHEEL_C_r_m; //caster wheel radius (m)
  float AF_m;         //caster pivot to axle distance (m)
  float FC_m;         //caster pivot to axle distance (m)

  float    LEFT_CLICKS_PER_mm;
  float    RIGHT_CLICKS_PER_mm;
  bool WHEEL_L_INVERSE_ROTATION;
  bool WHEEL_R_INVERSE_ROTATION;
  uint16_t usb_timeout_millis;

  float p_gain;
  float i_gain;
  float d_gain;
  float ff_gain; //ff gain


  //must be lastone
  bool configured;
};


struct ODOMETRY_MSG{
  float transform_x; //m
  float transform_y; //m
  float transform_orientation; //rad
  float linear_vel; // m/s
  float angular_vel; // rad/s
  float batt;    //battery voltage v
};

struct USB_CMD_VEL{
  float linear;
  float angular;
}target_velocity;

Далее в коде после того как успешно подключаюсь к устройству начинаю обмен данными (пересылка структур) например

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

          libusb_send(
                CONTROL_REQUEST_TYPE_OUT , /*bmRequestType*/
                ETERM_OUT_BASE_CFG, /*bRequest*/
                0x00, /*wValue*/
                16, /*wIndex*/
                ( unsigned char*)&basecfg,  /*data*/
                sizeof(BASE_CFG) /*wLength*/
                );

здесь ETERM_OUT_BASE_CFG это команда а basecfg это структура которую я заполнил и передаю в МК.
Таким образом и на хосте и в МК одинаковые структуры с одинаково заполненными полями.
Т.е. с точки знерия программирования я не задумываясь работаю с одинаковой конфигурацией и на хосте и в МК.

Вот так например получаю состояние одометрии

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

int eterm_get_odometry(libusb_device_handle *devh)
{
  if (!device_ready) return 1;
  
         if ( libusb_send(
                                CONTROL_REQUEST_TYPE_IN ,
                                ETERM_IN_ODOMETRY_MSG,
                                0x00,
                                0,
                                (unsigned char*)&odometrymsg,
                                sizeof(odometrymsg)
                                ) )
                {
      ROS_DEBUG( "recieve odometry x,y,th,V,A=%f,%f,%f,%f,%f",
            odometrymsg.transform_x,
            odometrymsg.transform_y,
            odometrymsg.transform_orientation,
            odometrymsg.linear_vel,
            odometrymsg.angular_vel );
                }
        return 0;
}
  

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


Ещё одно преимущество, можно взять стандартный класс, например CDC и дополнить его своими командами,
при этом одновременно (параллельно) будут работать
1) терминал (usb uart) minicom (там отладочные сообщения и shell)
2) команды управления (нода ROS)
3) мониторинг состояния батареии по cron.

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

В роботе пылесосе forum90/topic16676.html?style=8
к сожалению USB недоступен, поэтому я реализовал похожий протокол поверх UART.
но конечно накладных расходов больше чем при работе по USB.
Более подробно расскажу когда доделаю этот протокол и робота.

Дописал протокол, пока ещё в стадии тестирование но основное написано и скорее всего меняться не будет.
Протокол доступен тут https://github.com/linvinus/sprt

Вкратце
1) протокол бинарный

2) для того чтобы разделять команды между собой используется COBS кодирование , я о нём упоминал тут post326658.html#p326658

3) есть поддержка уведомления о доставке

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

5) есть возможность задавать команды как фиксированного размера так и произвольного размера.

6) простая стандартизация команд

7) синхронный и асинхронный режим работы

8 ) возможность вызывать callback при получении и доставке, ответ (uint8_t) от callback функции доставленного сообщения будет отправлен в уведомлении о доставке, это можно использовать для простого и быстрого RPC.

9) достаточно лекгопортируется, основной алгоритм не привязан к ОС.

10) уже есть реализация для chibios,arduino и linux.

Кодирование примечательно тем что на каждые 255 байт произвольных данных даёт лишь один байт накладных расходов, это реально круто (правда у меня ограничен размер 246 байтами).
Но есть и недостаток, нельзя в один проход кодировать данные и отправлять в последовательный порт, поскольку суть кодирования в том что после каждого экранируемоего символа ставится число сколько не экранируемых байт до следующего экранируемого байта, а пока не вычислишь сколько байт до следующего, текущий передавать нельзя.

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

Для того чтобы стандартизировать протокол между разными сторонами, все команды должный быть описаны в одном массиве который выделен в отдельный заголовочный файл и должен быть подключен и на хосте и на МК.

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

Производительность:
переслать 16 байт данных с уведомлением по usb uart на 115200 бод занимает 3ms.
Это 22 байта в одну сторону и 6 байт обратно.
по bluetooth 2 этаже операция занимаем 35-40ms.

портировал протокол в виде библиотеки для ардуино.

Обмен 16 полезных байт в одну сторону,
инкремент значений,
16 передача обратно.
ардуино ->usb_serial это занимает 5мс при скорости 115200 бод.

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

<6589 6589 13178 19767
cmd=1 seq=4
>6590 6590 13180 19770
transaction time: 5ms 
<6590 6590 13180 19770
cmd=1 seq=5
>6591 6591 13182 19773
transaction time: 5ms 
<6591 6591 13182 19773
cmd=1 seq=6
>6592 6592 13184 19776
transaction time: 5ms

даа, синхронизировать потоки в линуксе оказалось нетривиально.
сначала использовал posix condition variable , но оказалось что послать сигнал вовсе не означает что процесс тут же очнётся и начнёт работать,
у шедулера своё понимание кто в данный момент должен работать.

кроме того выяснил что функции usleep и nanosleep усыпляют поток минимум на 10ms.
в общем никакие sleep использовать нельзя для синхронизации.

пока выкрутился через pipe, но это решение годится только для двух потоков, если будет больше потоков то непонятно как быть.

по скорости получил следующее:
передача 22байт в одну и в обратную сторону на raspberry pi 3 по uart 921600бод - 900us, но иногда контроллер не успевает и пропускает байты.
если вставлять паузы по 1ms то нормально.

более стабильно на 460800бод, та же операция занимает 1200us (833 Гц), что вполне тянет на замену USB.