Не знаю, мне почему то кажется что в вики указана гарантированная дальность (другие дальности с точки зрения ТТХ интереса для обывателя и вояк не представляют). Кроме того 7400 это для какой полезной нагрузки? Фиг знает чем был загружен первый трайдент пулявшийся в рамках испытаний, вполне возможно что вес не соответствовал штатной (или штатным? вдруг там несколько вариантов?) загрузке.
Фотограф должен находиться рядом со столом и контролировать процесс, а обмен при этом должен быть двусторонним, если мы хотим отрисовывать прогресс так же красиво, как в мобильном приложении.
Что значит двухсторонний обмен? Отображение от девайса угла поворота стола и прием от пользователя команд на поворот? Так html с этим вполне справится. Насчет красивостей ввиде секторов круга - не знаю но думаю поковыряв js тоже можно что то приличное изобразить. Вобщем ничего не мешает это красивое приложение сделать на html + js.
ПИД-регулятор служит для поддержания заданного параметра, способного к изменениям. Как его использовать для перемещения стола на нужное расстояние?
Угол поворота стола - это величина? И не просто величина, а регулируемая. Ее собственно и контролируем, дальше от этого и пляшем:
PWMмотора = ПИД(ошибки по углу);
ошибка по углу = заданный угол поворота - угол поворота с энкодера.
PWMмотора - ограничить (допустимой макс. скоростью), углы - после окончания движения приводить к диапазону +/-360град.
Чую что в поворотных столах все таки главное механика. А в остальном:
... мы что-то делали не так.
С точки зрения электроники, и возможно организации софта, по моему мнению сделано "не так" многое, как раз по причине:
... Ардуино.
Т.к. то к чему в конечном итоге пришли - автономный девайс управляемый через беспроводной интерфейс с телефона вполне себе реализуется на одной esp32 (драйвер движка для бесколлекторника - не нужен) и без дополнительного ПМО на телефоне. А вышло в итоге: связка кортекс и та же esp32 + еще дополнительный софт надо на телефон ставить.
Собственно как бы я реализовал:
Аппаратная часть - один контроллер esp32 + енкодер с согласованием уровней подключенный через pcnt + бесколлекторник с встроенным регулятором.
Программная часть:
Управление положением стола - через ПИД по положению + внутренний пропорциональный (или ПД) контур по скорости.
На esp32 запускается HTML сервер + WiFi точка доступа, при коннекте телефона - редирект на html станицу управления. Все управление столом производится из встроенного в телефон браузера.
Да, с разработкой программной части придется немного повозится, но это хоть как то будет похоже на проф. электронику а не на поделку студента 3-го курса.
Первое, что мы попробовали, – это ESP32, но она нам не зашла. То ли плата была левая, то ли делали мы что-то неправильно, но нам никак не удавалось заставить работать энкодер.
Вероятнее всего - второе. У есп32 есть Pulse Counter (PCNT), который можно сконфигурировать для работы с энкодером:
Вот почему бы один раз не сесть и не написать фреймворк на шарпе для описания, кодогенерации и сборки фирмвари из общих, протестированных компонент.
Кодогенерация для stm32 есть, скелет с инициализацией переферии накидает.
А до остального - чего мелочиться, может сразу генератор документации? На входе скан ТЗ, на выходе эл. схемы, прошивки, спецификации, герберы печатных плат :))
Но если у вас от грани далеко, то хоть выжимай, хоть не выжимай, результата вы не достигнете.
Если я правильно понимаю то нужная производительность достигнута применением 4-х МК, и при этом главный пожиратель процессорного времени - работа с матрицами 28х28, которую можно ускорить минимум в два раза.
Т.е. "выжав из камня все" число МК можно сократить вдвое, и вместо двух "двухядреных" поставить один двухядреный, а это вполне себе достижимая такая грань и смысл, глядишь и межпроцессорная логика взаимодействия упростится.
Но из вот этого:
Работает и ладно. :)
Напрашивается нерадостный вывод о том что сделано в стиле "и так сойдет", даже не задумываясь об оптимизации. А че тут мучаться, дайте мне 1.5ГГц х 4 ядер и 4ГБ вот тогда точно заработает.
Во внешнем подключённом ОЗУ (1 Мб) они лежат, если не память не подводит.
Из внутреннего в два раза быстрее читается/пишется.
Да, все операции делаются на Си (делал бы на С++, но компилятора-то нет).
А причем тут плюсы? Код писаный что на плюсах, что на Си врятли выдаст на выходе специфичные инструкции, которые могут выполнятся параллельно (MPYF3 || ADDF3). Для реализации подобных вещей пригоден только асм, благо писать на нем немного - несколько библиотечных функций.
Пардон, наврал. Не 40 бит, а 32. 40 — это long double.
Во, вот это уже похоже на правду.
Когда у вас частота обработки десятки Гц и матрицы 28x28 это уже не так просто реализуется.
Перемножение матриц типа float/double 28х28 при их размещении во внутреннем ОЗУ и функции размещенной во внутреннем ПЗУ займет примерно 1мс (для тактовой 20 МГц), если на асм-е наваять соответствующую функцию (умножение с накоплением+повтор 28 раз). Если множить типы long double то производительность упадет в разы, так как требуется двойная загрузка каждого множителя, если long long double (48 бит на мантиссу) то все станет еще печальнее, т.к. там добавятся потери на вызов библиотечной функции арифметики расширенной точности. Отсюда вопрос, а тип у матриц какой? Где лежат? И как Вы их множите? Через функцию написанную на Си?
Всегда интересовало, как можно подобное утверждать, не зная специфики задачи? :)
Ну собственно об этом и речь. Что то вполне реализуется на "привете из 80-х".
40 битными типами данных (да, char — 40 бит) и своей собственной системой хранения float и double.
Насколько помню 40 бит - внутреннее представление числа с ПЗ (32-мантисса, 8-порядок, формат отличается от IEEE754), но разрядность ШД - 32 бита и при сохранении/чтении в/из ОЗУ 40 бит конвертируются в 32 (мантисса обстригается до 24). Про 40 битный чар - не знаю (до си не добрался, кодил это чудо на асме), но что то мне подсказывает что с такой организацией памяти это не так.
То есть, в наших реалиях приходится то, что должно бы работать на ПК уровня Raspberry реализовывать на отечественных МК со всеми недостатками и проблемами.
Примеры "наших реалий" можно? А то недавно ковырял "забугорную железку", так там на удивление:
Это сложная автоматика и куча вычислений. Она ещё и будет размазана по нескольким процессорам, объединённых каким-либо способом.
Т.е. куча "убогих" МК висящих на шине типа arinc/1533, каждая что то считает и чем то управляет.
Ну и, например, убожество типа 1867ВЦ6Ф есть.
Это ж tms320c3x, вполне нормальный камень. Собсно на нем вполне себе реализуется:
Списывать показания каких-то датчиков и обрабатывать некую математическую модель (там дофига математики с матрицами и фильтрами Калмана), а так же управлять оборудованием, выполнять команды извне, выполнять купирование неисправностей.
О, да это же "моя любимая" фиксированная запятая. В свое время работал с 32 битным значением с ценой мл. разряда 360/2^32 ну или PI/2^31 (кому как больше нравится).
Из впечатлений - для ЦОС очень хорошо, для чего то другого, где требуется большой (или не известный заранее) динамический диапазон значений - лютые проблемы.
Скорее всего ассемблер.
Вариации в апогее траектории? Так ее и не будет если работать все время из одной и той же точки в другую постоянную точку.
Возможно вики "врет" и 7400 действительности не соответствует, или работали с облегченной полезной нагрузкой.
Не знаю, мне почему то кажется что в вики указана гарантированная дальность (другие дальности с точки зрения ТТХ интереса для обывателя и вояк не представляют). Кроме того 7400 это для какой полезной нагрузки? Фиг знает чем был загружен первый трайдент пулявшийся в рамках испытаний, вполне возможно что вес не соответствовал штатной (или штатным? вдруг там несколько вариантов?) загрузке.
а это какая дальность? гарантированная? или максимальная энергетическая? или "номинал"?
Чем то напоминает формулу Мейсона.
Сейчас на али 8266 - 100р, 32 - 140р, вобщем то не принципиально.
Но! у 32 периферия гораздо богаче (есть например тот же "аппаратный" энкодер который тут очень кстати) и есть блюпуп.
В ТАУ это называется перегулирование, в данном случае оно успешно лечится подбором коэффициентов ПИД регулятора.
Зато браузер всегда есть на любом телефоне и под любой осью :) Вобще некоторые девайсы имеют оба интерфейса и блюпуп и веб.
Что значит двухсторонний обмен? Отображение от девайса угла поворота стола и прием от пользователя команд на поворот? Так html с этим вполне справится. Насчет красивостей ввиде секторов круга - не знаю но думаю поковыряв js тоже можно что то приличное изобразить. Вобщем ничего не мешает это красивое приложение сделать на html + js.
Угол поворота стола - это величина? И не просто величина, а регулируемая. Ее собственно и контролируем, дальше от этого и пляшем:
PWMмотора = ПИД(ошибки по углу);
ошибка по углу = заданный угол поворота - угол поворота с энкодера.
PWMмотора - ограничить (допустимой макс. скоростью), углы - после окончания движения приводить к диапазону +/-360град.
Чую что в поворотных столах все таки главное механика. А в остальном:
С точки зрения электроники, и возможно организации софта, по моему мнению сделано "не так" многое, как раз по причине:
Т.к. то к чему в конечном итоге пришли - автономный девайс управляемый через беспроводной интерфейс с телефона вполне себе реализуется на одной esp32 (драйвер движка для бесколлекторника - не нужен) и без дополнительного ПМО на телефоне. А вышло в итоге: связка кортекс и та же esp32 + еще дополнительный софт надо на телефон ставить.
Собственно как бы я реализовал:
Аппаратная часть - один контроллер esp32 + енкодер с согласованием уровней подключенный через pcnt + бесколлекторник с встроенным регулятором.
Программная часть:
Управление положением стола - через ПИД по положению + внутренний пропорциональный (или ПД) контур по скорости.
На esp32 запускается HTML сервер + WiFi точка доступа, при коннекте телефона - редирект на html станицу управления. Все управление столом производится из встроенного в телефон браузера.
Да, с разработкой программной части придется немного повозится, но это хоть как то будет похоже на проф. электронику а не на поделку студента 3-го курса.
Вероятнее всего - второе. У есп32 есть Pulse Counter (PCNT), который можно сконфигурировать для работы с энкодером:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/pcnt.html
Кодогенерация для stm32 есть, скелет с инициализацией переферии накидает.
А до остального - чего мелочиться, может сразу генератор документации? На входе скан ТЗ, на выходе эл. схемы, прошивки, спецификации, герберы печатных плат :))
При размещении матриц во внутреннем озу - должно увеличится, к нему доступ дважды за такт.
Нужны еще исходники, а так мало ли как чего написано. Шмат сгенереного кода перемножения матриц на асме я бы глянул с удовольствием :)
Нафига? 20-30%, не больше. Иначе получается что второй двухпроцессорный летает пассажиром.
Плюсом алгоритмика и математика после выхода на опытные образцы существенно уже не меняется, и куда девать этот "запас" в половину мощности?
Если я правильно понимаю то нужная производительность достигнута применением 4-х МК, и при этом главный пожиратель процессорного времени - работа с матрицами 28х28, которую можно ускорить минимум в два раза.
Т.е. "выжав из камня все" число МК можно сократить вдвое, и вместо двух "двухядреных" поставить один двухядреный, а это вполне себе достижимая такая грань и смысл, глядишь и межпроцессорная логика взаимодействия упростится.
Но из вот этого:
Напрашивается нерадостный вывод о том что сделано в стиле "и так сойдет", даже не задумываясь об оптимизации. А че тут мучаться, дайте мне 1.5ГГц х 4 ядер и 4ГБ вот тогда точно заработает.
Ага, только чего ж Вы жалуетесь на низкое быстродействие? По мне погромист МК как раз и занимается тем что выжимает из железяки максимум.
Это уже вкусовщина. Мне вот лично больше нравится Си :)
Из внутреннего в два раза быстрее читается/пишется.
А причем тут плюсы? Код писаный что на плюсах, что на Си врятли выдаст на выходе специфичные инструкции, которые могут выполнятся параллельно (MPYF3 || ADDF3). Для реализации подобных вещей пригоден только асм, благо писать на нем немного - несколько библиотечных функций.
Во, вот это уже похоже на правду.
Перемножение матриц типа float/double 28х28 при их размещении во внутреннем ОЗУ и функции размещенной во внутреннем ПЗУ займет примерно 1мс (для тактовой 20 МГц), если на асм-е наваять соответствующую функцию (умножение с накоплением+повтор 28 раз). Если множить типы long double то производительность упадет в разы, так как требуется двойная загрузка каждого множителя, если long long double (48 бит на мантиссу) то все станет еще печальнее, т.к. там добавятся потери на вызов библиотечной функции арифметики расширенной точности. Отсюда вопрос, а тип у матриц какой? Где лежат? И как Вы их множите? Через функцию написанную на Си?
Ну собственно об этом и речь. Что то вполне реализуется на "привете из 80-х".
Насколько помню 40 бит - внутреннее представление числа с ПЗ (32-мантисса, 8-порядок, формат отличается от IEEE754), но разрядность ШД - 32 бита и при сохранении/чтении в/из ОЗУ 40 бит конвертируются в 32 (мантисса обстригается до 24). Про 40 битный чар - не знаю (до си не добрался, кодил это чудо на асме), но что то мне подсказывает что с такой организацией памяти это не так.
Примеры "наших реалий" можно? А то недавно ковырял "забугорную железку", так там на удивление:
Т.е. куча "убогих" МК висящих на шине типа arinc/1533, каждая что то считает и чем то управляет.
Это ж tms320c3x, вполне нормальный камень. Собсно на нем вполне себе реализуется:
Охрана в аэропортах при виде ноута стойку не делает?
О, да это же "моя любимая" фиксированная запятая. В свое время работал с 32 битным значением с ценой мл. разряда 360/2^32 ну или PI/2^31 (кому как больше нравится).
Из впечатлений - для ЦОС очень хорошо, для чего то другого, где требуется большой (или не известный заранее) динамический диапазон значений - лютые проблемы.