Стабилизация Активная - часть II

Non-conformist>

shadowjack ???

Да тут я, читаю как минимум раз в день. Что-то у меня занятость образовалась в связи с определенными событиями в России.
Конечно, постараюсь выкроить время.
По существу: считаю, что железо (плата) проверено -> нужно передавать плату Ckona для проведения тестов с клапанами на массово-габаритной модели ракеты.
Балансирующий робот - это хорошо. Я сам такого пробовал сделать еще на покупной плате с аналоговыми MEMS-гироскопами и arduino - уперся в механику (нужны хорошие редукторы с малыми люфтами), а потом и вообще интерес потерял. Есть хороший форум по любительскому роботостроению - roboforum.ru.

Как я вижу алгоритм работы платы:
Перед старотом подключается питание. Плата в "ждущем режиме". Длительным нажатием (или тремя нажатиями за время менее 2 сек) плата ставится на "боевой взвод". Начинается непрерывная калибровка гироскопа (предполагается, что угловая скорость = 0). При обнаружении по акселерометру момента старта начинается интегрирование углового отклонения. При привышении порога выдается управляющий импульс (длительность зависят от отклонения и скорости отклонения). Если нужно, при подходе к "0" дается дополнительный импульс обратной направленности для оставноки вращения.
Кстати, так как мы интергируем угол - можно осуществить и "минометный старт", с курсом, скажем, 45 градусов к вертикали.
Non-conformist, прогони пожалуйста последний тест со значением
#define PAGE_SIZE 16
вместо
#define PAGE_SIZE 256

shadowjack> Кстати, так как мы интергируем угол - можно осуществить и "минометный старт", с курсом, скажем, 45 градусов к вертикали.
Миномётный старт великолепно пишется на дешёвый оптический (солнечный) датчик направления. Почти уверен, что МЕМСы там вообще ни к чему, разве только если добавлять какие-то дополнительные непринципиальные возможности. Там есть готовое направление, там не нужно ничего вычислять и интегрировать. Самонаведение в своём простейшем случае. Основная сложность - ПИД-алгоритм для электромеханики.

МЕМСы - это именно вертикальная стабилизация. МЕДЛЕННЫЙ старт с торцевиком секунд на десять работы.

shadowjack> Non-conformist, прогони пожалуйста последний тест со значением
shadowjack> #define PAGE_SIZE 16
shadowjack> вместо
shadowjack> #define PAGE_SIZE 256
Прогнал, файл в аттаче (три ресета). Не работает.

Ckona> ... но по-прежнему невозможно управлять без понимания природы объектов управления.
Мой последний аргумент: применительно к МК, вся "природа" ПИД в виде дифуравнений и прочей математики брутально зашита в библиотеках компилятора. В сишном коде весь ПИД выглядит как несколько слов заголовочных файлов ".h" (ссылок на эти библиотеки). А сами операции с объявленными библиотеками занимают буквально несколько коротких строк текста.

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

Non-conformist> Прогнал, файл в аттаче (три ресета). Не работает.
Ну как не работает - только каждый 16-й байт криво пишется. Можно работать.
Давай задание - тут как минимум 2 режима работы - запись и выгрузка. Как переключаться?

Non-conformist> Мой последний аргумент: применительно к МК, вся "природа" ПИД в виде дифуравнений и прочей математики
ПИД это буквально несколько строчек на Си, какие тут диффуры? Ты почему-то думаешь, что если кто-то уже посчитал за тебя всю рутинную математику, так тебе теперь и не осталось ничего делать, так, пару коэффициентов подкрутить. Но крутить не понимая математики, ты их будешь весьма долго.

Кстати, о математике. Я наконец-то разобрался, как пересчитывать координаты при повороте декартовой системы по углам Эйлера - это позволяет до старта ракеты с помощью трехосного акселерометра определить вертикаль.
В связи с этим - вопрос (shadowjack'у и всем, кто разбирается): где можно узнать время выполнения АРДУИНом(контроллером) тех или иных математических операций, типа SIN(), COS(), TAN() ?

Non-conformist>> Мой последний аргумент: применительно к МК, вся "природа" ПИД в виде дифуравнений и прочей математики
GOGI> ПИД это буквально несколько строчек на Си, какие тут диффуры? Ты почему-то думаешь, что если кто-то уже посчитал за тебя всю рутинную математику, так тебе теперь и не осталось ничего делать, так, пару коэффициентов подкрутить. Но крутить не понимая математики, ты их будешь весьма долго.

Про дифуравнения мне писал проф. Константин Поляков. Хотя, похоже, тут я действительно не прав - их надо решать один раз и для того лишь, чтобы аналитическими методами определить примерный диапазон значений коэффициентов управления заданным объектом. А отнюдь не для того, чтобы программно отрабатывать ПИД-ШИМ в режиме реального времени... Признаю свою ошибку. Но.

GOGI, скажи честно - ты пробовал крутить эти три ручки? А то везде пишут, что крутят их чисто эмпирически, наблюдая ГЛАЗАМИ за ответной реакцией системы на внешние возмущения. Обманывают, наверное? У нас на кочегарке слесаря КИП третьего разряда не иначе как высшее техническое образование имеют все как один - крутят почём зря, заразы, эти три ###ые ручки на регуляторах задвижек... И ведь лихо получается, надо сказать!

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

shadowjack> Давай задание - тут как минимум 2 режима работы - запись и выгрузка.
Кому давать задание?

> Как переключаться?
Ты меня спрашиваешь? Если меня, то - кнопкой "MODE". Как именно? Как сделаешь, так и будет. Всё равно переделывать надо будет - я-то не хозяин. Ты только опиши словами интерфейс твоей программы, чтобы "кодовый замок" не получился.

shadowjack>> Давай задание - тут как минимум 2 режима работы - запись и выгрузка.
Non-conformist> Кому давать задание?
Мне, конечно. Ты же заказчик - хочешь программу с записью значений с частотой 100 Гц и без проводов. Правильно я понял?
Non-conformist> Ты меня спрашиваешь? Если меня, то - кнопкой "MODE". Как именно? Как сделаешь, так и будет.
Ну смотри - я-то сделаю, как мне удобно. Тебе ж потом придется корячиться при её использовании.
Давай так - короткое нажатие на MODE - пошла запись, светодиод зажегся. Следующее нажатие - запись остановлена, светодиод потух. Длительное нажатие (2 секунды) - сбпрос последнего сеанса на ком-порт.

Ckona> В связи с этим - вопрос (shadowjack'у и всем, кто разбирается): где можно узнать время выполнения АРДУИНом(контроллером) тех или иных математических операций, типа SIN(), COS(), TAN() ?
Проще всего - замерить в цикле время вычисления, скажем, 100000 вычислений интересующей функции.
Это зависит от того, флоаты или даблы используются. Если время критично, а точность - не очень, то можно использовать таблицы. В общем, есть моного вариантов компромисса скорость-точноть-используемая память. Стандартные функции, думаю, занимают сотни тактов контроллера.

shadowjack> Ты же заказчик - хочешь программу с записью значений с частотой 100 Гц и без проводов. Правильно я понял?
Совершенно верно! Только желательно, чтобы мне не пришлось выкидывать каждый шестнадцатый байт из Экселя вручную.

shadowjack> Ну смотри - я-то сделаю, как мне удобно. Тебе ж потом придется корячиться при её использовании.
Так я что, "чужой" какой-то, или типа некий biohazard? )) Будет удобно тебе - будет удобно и мне. Описанный интерфейс меня устраивает полностью. Только сигнал выводи на D13 - других светодиодов нет. Или всё-таки можно запаять светодиод на D1? Не будет ли он мешать работе?

Ckona> В связи с этим - вопрос (shadowjack'у и всем, кто разбирается): где можно узнать время выполнения АРДУИНом(контроллером) тех или иных математических операций, типа SIN(), COS(), TAN() ?
Набиваешь программу с этими операциями, компилируешь и файл загружаешь в АВР студио. В симуляторе шагаешь по программе и смотришь время выполнения каждой операции.

shadowjack> Длительное нажатие (2 секунды) - сбпрос последнего сеанса на ком-порт.
Подтверждение выполнения - три коротких вспышки светодиода (мало ли - кабель взглючнул, разъём расшатался - чтобы было видно, где проблема).

Non-conformist> Совершенно верно! Только желательно, чтобы мне не пришлось выкидывать каждый шестнадцатый байт из Экселя вручную.
Не-не, просто в структуре данных на этом месте будет неиспользуемый байт, ты его даже не увидишь. Смотри, 15 байт получается - 2*3 гироскоп, 1*3 аксель, время - 4 байта и 2 - номер сеанса. По-моему, как раз.
Non-conformist> Так я что, "чужой" какой-то, или типа некий biohazard? ))
Просто я-то не опробую её пока что - железа нет, среды нет, пишу с утюга.
Non-conformist> Или всё-таки можно запаять светодиод на D1? Не будет ли он мешать работе?
Да можно. Будет ли мешать - посмотрим, вроде не должен (если перегрузки по току не будет).

shadowjack> Не-не, просто в структуре данных на этом месте будет неиспользуемый байт, ты его даже не увидишь.
Это типа шутка? Или серьезно?

shadowjack> Смотри, 15 байт получается - 2*3 гироскоп, 1*3 аксель, время - 4 байта и 2 - номер сеанса. По-моему, как раз.
Формат выводимых данных должен имхо зависеть от того, какие данные предполагается использовать для обработки в цикле, чтобы в итоге получить балансирующую палку. Француз и англосакс в два голоса говорят одно и то же: для успешного одноосевого балансирования нужны показания одной оси гироскопа (Х) и двух осей акселя (XZ). У нас предполагается двухосевое балансирование, стало быть добавляется по одной оси туда и туда:

NUMB xx TIME xxxx GYRX xx GYRY xx ACCX xx ACCY xx ACCZ xx

Т.е. у меня получилось 16 байт. Но я не знаю точно, сколько байт нужно, чтобы без переполнения отобразить весь потребный диапазон значений гироскопа и акселерометра. Я взял по два байта.

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

***
Non-conformist> Т.е. у меня получилось 16 байт. Но я не знаю точно, сколько байт нужно, чтобы без переполнения отобразить весь потребный диапазон значений гироскопа и акселерометра. Я взял по два байта.
Согласно ДШ гироскоп выдаёт 16 бит по каждой из осей, акселерометр по 8 бит. Тогда получается:

NUMB xx TIME xxxx GYRX xx GYRY xx ACCX x ACCY x ACCZ x - тринадцать байт х сто герц.

Буквы, я думаю, лучше не выводить, а цифры разделять знаком табуляции - так удобнее для Экселя. И заодно попробуем исправленный ксанов монитор.

А вообще, я думаю, ГОГИ прав - надо писать данные с максимально возможной частотой. Т.е. 100 Гц - это как первый эксперимент. Если будет писать на четырёхстах - надо будет так и писать. Чем больше временное разрешение, тем лучше.

***
Напишешь программу, подкину сабж - и сразу будет видно, справляется ли трёхосевой акселерометр с задачей определения баллистического апогея. И если справляется, то насколько хорошо. ))

Non-conformist> исправленный ксанов монитор.
А это что за штука ?

Non-conformist>> исправленный ксанов монитор.
Ckona> А это что за штука ?

У меня непечатные байты в диапазоне 0x00...0x1F и 0xFF в файл писались в виде <XX>, чтоб если ошибки связи, то они были бы видны.
За исключением символов CR и LF, которые 0x0A и 0x0D.
А про табулятор — TAB = 0x09 — я забыл.
Но теперь вспомнил и исправил.

Ckona>
Приехал разъём PBD-14. Сегодня забираю, в понедельник паяю, и можно отправлять. Кабеля питания и клапанного блока сам сделаешь? А то я не знаю, какую ты длину хочешь. И вообще не представляю, как это всё будет выглядеть в собранном виде.

Xan> теперь исправил.
Если можно, выложи пожалуйста.

shadowjack>> Не-не, просто в структуре данных на этом месте будет неиспользуемый байт, ты его даже не увидишь.
GOGI> Это типа шутка? Или серьезно?
Нет, не шутка. Отлаживать нет возможности пока - у меня железки нет.
Почему-то бьется первый байт записываемой страницы.

Non-conformist> не представляю, как это всё будет выглядеть в собранном виде.
Кабели, конечно, сделаю.
Попробую за выходные оформить свое "видение" стенда для испытаний. Конкретное исполнение будет зависеть от корпусных железяк.