Делаю OSD, автопилот и инерциалку...
Караул! Падаем!!!
Ну если цель системы в предсмертном крике, то конечно… 😃 А вот восстановить сбитый горизонт,а значит адекватно управлять самолетом, уже вряд ли получится…
уже вряд ли получится…
😢
Было очень печально услышать от вас, что вы принцип работы МЕМС ДУС-ов поняли лишь после постройки всей системы…
Не заморачивайтесь. 😃
Папка с материалами, которые были использованны уже на данный момент, по автопилоту уже сейчас перевалила за 2 гига. Одних даташитов и т.д. только на 300 МБт. Если я упустил такой пустяк как оффсет ADC то это просто мелочи.
Еще я на пример забыл подсоединить ресет TMSa куданибудь и он у меня болтался в воздухе. Но это ведь не значит что автопилота не будет. 😃
Короче, сделал я видео ОСД (мое первое видео на ютюбе). 😃
Хотел сделать еще несколько роликов о том как система работает, но оказалось что микрофон не работает, и создание роликов нереносится.
ОСД работает в тестовом режиме. Просто что-то выводит.
При этом пик, который это обсчитывает, может нормально принимать команды. Фактически софт на этот пик уже доделан.
Короче, вот:
Вверху бугут направления домой и на вейпоинт.
Да, забыл. ОСД работает полностью. Если ДСП будет посылать команды, то эти команды нормально будут отображатьося. Я проверял. 😃
Походу пора в полет уже!??😉
Угадайте, что это?
Микроскопом гвозди забиваем ?😃
Вчера прикол обнаружил.
Короче, когда стал испытывать все вместе вместе с сервами, то сервы у меня как-то странно дергались с очень большой задержкой. Я уже было про xBee плохо подумал, что типа это она вносит задержку.
Все оказалось гараздо проще. Оказывается сервы не понимают резкое изменение ширины импулься и думают что это ошибка, поэтому отрабатывают ее с ошибкой.
В итоге мне пришлось поставить что-то типа ФНЧ на обновление значений серв, чтобы сервы не сходили с ума. 😃
Сейчас все работает без задержек. 😃
Для джойстика осталось доделать писишный софт, тоторый будет отвечать за микширование серв, установку значений триммеров и всяких там экспонент. 😃
а что за сервы? и насколько резко импульсы менялись?
а что за сервы? и насколько резко импульсы менялись?
Сервы самые обычные, А импульсы менялись довольно резко, в половину всего диапазона за один раз. Был импульс 1 мс, а потом вдруг резко стал 1.5 или 2 мс. В итоге сервы начинала глючить и отрабатывать операцию с задержкой.
не жизненные какие то изменения
не жизненные какие то изменения
Почему?
Вот была связь, потом пропала, а потом снова появилась… 😃
Для цифровой связи, которая сейчас, вполне жизненные. 😃
не жизненные - в том смысле что самолет так не полетит … А про пропадание связи - да пожалуйста, обычное дело серва должна отрабатывать конечно …
В итоге сервы начинала глючить и отрабатывать операцию с задержкой.
А что, серва должна глючить, если к примеру канал управляется не джойстиком (плавно меняющим длительность) а тумблером? И импульс при этом- меняется как раз “вдруг”- время переключения контакта- меньше миллисекунды 😃
А РРМ , кроме того- и сам по себе 50 раз в секунду “меняется” 😦 ?
Что то ни у кого- не глючит?
думаю, автор имел виду что за секунду ппм мог поменяться в диапазоне раз 50, а если так то за счёт определюнной скорости самой сервы она и отрабатывала среденее “арифметическое” пощёлкайте тумблером раз 10 быстро - серва вообще может не двинуться:)
В итоге мне пришлось поставить что-то типа ФНЧ на обновление значений серв, чтобы сервы не сходили с ума.
Проблема точно не в этом. Обычные сервы не задумаются при сколь угодно резком изменении длительности управляющего импульса в пределах допустимых длительностей.
Какой то баг в коде - генерирует не те длительности импульсов.
Какой то баг в коде
По моему, дело не в коде 😦
Не удивлюсь, если автор нам поведает, что он не читал, как устроена РРМ кодировка 😂
А зачем ему PPM? А то, что не знает о PWM для сервы, признался в первом сообщении, ну так разобрался вроде… Но глючить серва при резких изменений управляющего сигнала конечно не должна…
Всем привет!
Данная версия еще не доделана, но есть вопросы по следующей. 😃
Короче, насколько будет востребована связь с моделью по средствам сотовой связи.
Поясню.
Все что нужно будет делать, это вставить симку в автопилот и вставить симку в наземную станцию (нодбук + коробочка, пульт или джойстик и еще что-то, или коробочка и пульт). Тариф желательно должен быть с GPRS, но можно и без него. 😃
В полете можно будет как управлять, так и менять параметры полета, т.е. waypoints и т.д.
Если самолет упадет, то на выбранный телефон (или на наземку), с помощью СМС будет слать свои координаты.
По деньгам, это будет стоить дешевле чем xBee и всякие там чайналинки, т.е. дешевле чем 50 баксов один девайс (их надо 2) но зато это будет даже дешевле чем брелок треккер (а может удасться и за 30 баксов сделать). 😃
Приимущество очивидно: область покрытия определяется областью оператора.
Недостатков два:
- Надо платить оператору
- Можно будет летать только с автопилотом, так как в GSM при переходе от станции к станции, или потере связи самолет не должен впадать в прострацию.
Идеи, предложения и пожелания с удовольствием выслушаю. 😃
PS. Текущее состояние такое. На этих выходных были запланированны полеты с целью сбора необработанной информации с сенсоров, но из-за того что я забыл флешку на работе и из-за дождя, полетов небыло. 😃
Сейчас сенсоры работают стабильно, плата грузится из файла с флешки, данные сенсоров записываются на флешку. Обработки я пока не вставлял, так как надо еше помоделировать.
Всем привет!
Данная версия еще не доделана, но есть вопросы по следующей. 😃
Короче, насколько будет востребована связь с моделью по средствам сотовой связи.
Я думаю будет очень постребовано. Тем более если подключение будет опциональным. т.е. без модуля сотовой связи все остальное работатает по прежнему.
И я бы взглянул не на GSM-GPRS - а на 3G (USB модем).
выше скорость - т.е. можно даже какое-нибудь видео с телеметрией передавать, и если с задержкой - слать картинки в высоком разрешении(было б очень удобно).
из минусов - наверно сложнее будет прицепить к вашей плате.
PS: Это желание, возможно не до конца хорошо продуманое в плане реализации.
Я думаю будет очень постребовано. Тем более если подключение будет опциональным. т.е. без модуля сотовой связи все остальное работатает по прежнему.
Спасибо.
Восприму это как требование: опциональное наличие канала управления через GSM.
И я бы взглянул не на GSM-GPRS - а на 3G (USB модем).
3G это точно не в этой версии. Это просто другой уровень сложности разработки. Скайп вон до сих пор с видео мучается. А скайп это не один разработчик, даже не средняя фирма. 😃
Канал передачи видео это отдельная тема.
Но, возможность летать по приборам и иметь отображение самолета на 3D карте - будет. 😃
Всем привет!
Давно меня небыло.
Вот тут математикой занимаюсь, решил спросить. 😃
Сейчас пытаюсь определить положение самолета по датчикам. Все датчики 3D. Есть аксель (вектор А), компас (вектор С) и гироскоп (скорости поворота G).
Q - положение самолета в пространстве.
Компас это вектор. Гироскоп - это матрица поворота.
Сейчас надо определить положение самолета по значениям гироскопа и компаса. Основная задача, это скорректировать ошибку показаний гироскопа с помощью компаса.
Пока все выглядет вот как: есть значение положения самолета полученные после интегрирования гироскопа. Из-за наличия постоянной составляющей в сигнале гироскопа, значение после интегрирования постоянно “плывет”, причем с разной скоростью.
Задача сейчас стоит в том, чтобы скорректировать этот уплыв.
Вот так сейчас выглядет процесс моделирования:
Итак, с гироскопа е меня есть данные положения самолета (вектора xyz). Эти данные надо как-то спроецировать на вектор компаса и скорректировать уплыв. Здесь не надо окорректоровать константу. Надо скорректировать только динамическую ошибку.
Итак, как это сделать? 😃