Inspire-подобная рама своими руками с нуля
В данном случае космофен был цианакрилатный.
Внимательнее с космофеном, - дает хрупкое соединение
Конечно средство аварийное, но и сам материал шарниров “не фонтан”.
я стянул одно из мест склейки черной изолентой, но не по всем таким местам это было возможно сделать.
Напечатать эти детали лазерным спеканием полиамида было бы идеально. Или хотябы сделать на нем мастер-модели и отлить в силикон, но это уже дело следующего основательного этапа. Для которого собрался уже целый списочек апгрейдов.
Вчера и сегодня занимался настройками. Еще раз спасибо Сергею за развернутые рекомендации.
Перекалибровал Назу, выставив по цифровому уровню.
Перекалибровал стики на аппе и в ассистенте. Некоторые бегунки получили на 2 - 4 пункта в тороне от центра. Поправил тримерами и перекалибровал еще раз.
Перестало вести коптер в сторону. Правда в эти дни было ветрено и в благоприятных условиях я пока не проверял, но изменения разительны.
Потом занялся гейнами. Basic Pitch убрал до минимума - улучшился звук моторов и они перестали колебаться.
Все остальные настройки тоже не выше середины. Поведение довольно вальяжное, но пока мне это подходит. Тем более, что сравнить не с чем. По мере наработки опыта еще подправлю.
yadi.sk/i/J5f8vyQh3a282T
GPS вывел на стойку, но пока эффект не супер впечатляющий. Толи деревья мешают, толи что, но время от времени теряются спутники и коптер начинает плавать.
Хотя тоже странно - обычно одно красное мигание (6 спутников) и мне казалось что это должно быть вполне себе достаточное количество для удержания.
Толи деревья мешают, толи что, но время от времени теряются спутники и коптер начинает плавать.
А это нормально.
У меня не так давно работа была по съемке здания с инспайра.
Приходилось взлетать из узкого, метров 15-20 диаметром колодца образованного высоким сталинским зданием осаженном густыми тополями.
Внизу при взлете инспайр унитазило метра на два с 9 спутниками, по мере подьема до крыши и выше их добралось до 17, с 11 всякий унитазинг прекратился.
(6 спутников) и мне казалось что это должно быть вполне себе достаточное количество для удержания.
Нет, это крайне мало, меньше 7 на назе/вуконге лучше вообще не летать чуть далече, ибо мало ли ли какой сбой, и с пяти дрон уже начнет неконтролируемо сдувать ветром.
Внизу при взлете инспайр унитазило метра на два с 9 спутниками
Да, похожая ситуация. В парке облюбовал полянку между высокими деревьями. С одной стороны там удобно, с другой вот ньюанс вылез.
Заказал для пробы приводной винт Т6 с шагом 12 мм. Хочется ускорить подъем/спуск лучей и интересно потянет ли такой шаг серва.
На случай если потянет, есть желание сделать автоматический режим для шасси, вернувшись к теме с ультразвуковым дальномером и ардуиной. Возможность пользоваться транспортным положением тоже нравится, поэтому его надо сохранить. Для этого думаю сделать небольшую кнопку (с фиксацией) на корпусе, чтобы переводить в транспортное положение после полетов.
Логику работы вижу так:
yadi.sk/i/O5E5oRYu3a42MR
На одном из трехпозиционных тумблеров получатся режимы: “Авто”, ручной “Полет”, ручной “Приземление”
А автоматическом режиме нужно будет всегда летать выше пороговой высоты, а то получится - “лучи вверх”-“лучи вниз”-“лучи вверх”-“лучи вниз”-“лучи вверх”-“лучи вниз”-“лучи вверх”.
В идеале -вывести информирование о приближении к пороговой высоте, о достижении пороговой высоты и о полете ниже пороговой высоты на пульт.
а то получится
У инспайра же не “получается”
Кстати у меня сейчас хоть и не инспайр, а мозг даже поумнее будет, но ноги тоже автоматом поднимаются-опускаются самим мозгом.
При этом делают это похоже с помощью двух систем - по баро, и по команде “посадка”. По команде “посадка” ноги опускаются автоматом даже на высоте метров 50
И тоже ноги самопроизвольно никуда не бегают
PS. Кстати когда то брал для колхоза с автоподьемом ног такую вот штучку - goodluckbuy.com/ultrasonic-wave-ranging-module-led…
Работает до 4м, настраиваются пороги. Но не пригодилось
Я просто проанализировал блок-схему.
А автоматическом режиме нужно будет всегда летать выше пороговой высоты, а то получится - “лучи вверх”-“лучи вниз”…
Да, по логике так оно и будет. Но если вариант с новым винтом (шаг 12 мм) сработает, то опускание шасси будет происходить за секунды и я смогу выставить пороговую высоту небольшой, около 1 - 1.5 м. На такой высоте не планирую много летать, а в исключительных случаях можно будет перейти в ручной режим.
Если же на старом винте придется остаться, то метра 2.5. придется поставить. Но опять же в отдельных случаях ручным попользуюсь.
На сколько я понимаю, чтобы вывести на пульт информацию надо будет одним каналом пожертвовать. Жалко) Хотя за идею спасибо, возможно в будущем к ней добавятся еще какие-то показания для передачи.
Кстати когда то брал для колхоза с автоподьемом ног такую вот штучку
Любопытная штуковина. Разброс цен на них какой-то странный.
Накрапал скетч для ардуины:
#include <Servo.h>
Servo myservo;
int button = 6; // кнопка перевода в транспортное положение
int pin = 2; // вход с приемника
unsigned long duration; // длинна сигнала
unsigned int dist = 1200; // пороговое расстояние до земли
unsigned int HighLen = 0;
unsigned int LowLen = 0;
unsigned int Len_mm = 0;
void setup()
{
myservo.attach(3);
pinMode(5, OUTPUT);
pinMode(button, INPUT);
pinMode(pin, INPUT);
digitalWrite(5, HIGH);
Serial.begin(9600);
}
void loop()
{
if (digitalRead(button) == HIGH) // если кнопка транспортного положения нажата
myservo.write(90); // лучи в среднем положении
duration = pulseIn(pin, HIGH); // считывается длинна сигнала
if (duration > 1800) // если тумблер в нижнем положении
myservo.write(0); // лучи опускаются вниз
if ((duration > 1200) & (duration < 1800)) // если тумблер посередине
myservo.write(180); // лучи поднимаются вверх
if (duration <= 1000) // если тумблер в верхнем положении
// замеряется расстояние до земли:
{
Serial.flush();
Serial.write(0x55);
delay(10);
if (Serial.available() >= 2)
{
HighLen = Serial.read();
LowLen = Serial.read();
Len_mm = HighLen * 256 + LowLen;
Serial.print(Len_mm, DEC);
Serial.println(“mm”);
}
if (Len_mm <= dist) // если расстояние ниже, равно пороговому
myservo.write(0); // лучи лучи опускаются вниз
if (Len_mm > dist) // если расстояние выше порогового
myservo.write(180); // лучи поднимаются вверх
}
}
На счет его работоспособности пока утвердительного мнения нет. Вроди бы все работает (и кнопка и управление с пульта и автомат). Но в транспортном положении серва периодически подергивается, а должна тико стоять.
Ну и в одну сторону крутится ровно, а в другую с дерганьями (то ровно, то дергается, то встанет, то опять раскрутится). Хотя вне схемы крутится как надо.
Затрудняюсь предполагать в чем может быть дело. Для меня ардуиновская тематика, это почти как шаманизм. Заморочился с ней для удобства, но если не получится достичь стабильной работы, то опять откажусь.
myservo.write(0); // лучи опускаются вниз
myservo.write(90); // лучи в среднем положении
myservo.write(180); // лучи поднимаются вверх
Нужно ли эти значения постоянно записывать в серву в цикле или достаточно записать один раз, чтобы серва приняла нужное положение и удерживала его?
Нужно ли эти значения постоянно записывать в серву в цикле или достаточно записать один раз, чтобы серва приняла нужное положение и удерживала его?
Мои познания в программировании ограничиваются универским курсом и гуглом, но на сколько я понимаю, если записать что-то окончательно, то потом программа перестанет обновлять переменную и схема перестанет реагировать на новые команды. Такой вариант как прямое управление с пульта тут не сработает - все тело программы это цикл.
Хе-хе…) Вот Вы неугомонный…) То у Вас автопилот интеллектуал, хоть в “ЧтоГдеКогда” играй, теперь в серву что то можно записать…)
Серва просто поворачивается на угол, соответствующий ширине сервоимпулься на выходе ардуины…) Ширина 1000 микросекунд равна углу 0 градусов, ширина 1500 - 90 градусов, ширина 2000=180 градусов. До тех пор пока на выходе ардуины эта ширина не изменится, мотор сервы не сдвинется с места.
В данном случае, команда write(90) заставляет МК выставить на заранее определенном пине импульсы длительностью 1500 и частотой 50 герц. И эта хрень будет там присутствовать до тех пор, пока не поступит команда с другой длительностью…
теперь в серву что то можно записать
Я имел ввиду перезапись и обновление переменных на ардуине в соответствии с управляющими командами.
Считывал ширину входящего сигнала ардуиной, получилось что значения немного плавают, поэтому ставил граничные условия вроде “if ((duration > 1200) & (duration < 1800))” вместо четчих чисел. Чтобы сигнал с приемника точно попал в пределы.
Я имел ввиду перезапись и обновление переменных на ардуине в соответствии с управляющими командами.
Попробуйте не писать в цикле одни и те же значения.
А сделать следующим образом:
до цикла:
int servo_mode = -1;
if (digitalRead(button) == HIGH) // если кнопка транспортного положения нажата myservo.write(90); // лучи в среднем положении
меняем на:
if (digitalRead(button) == HIGH) { // если кнопка транспортного положения нажата
if (servo_mode != 90) {
myservo.write(90); // лучи в среднем положении
servo_mode = 90;
}
}
и аналогично для других режимов.
в результате значения будут писаться только один раз при смене режима.
возможно, это повлияет на подергивания сервы.
Попробуйте не писать в цикле одни и те же значения.
А сделать следующим образом:
О! Круто! не знал про такой прием. Испробую!
Стесняюсь спросить - а что означает восклицательный знак после имени переменной?) “servo_mode != 90”
а что означает восклицательный знак
== это равно
!= это не равно
== это равно
!= это не равно
А, блин, точно, он же к логическому оператору относится, а не к имени))… программист из меня еще тот
Да, и еще.
Допустим, у вас нажата кнопка.
Тогда срабатывает
myservo.write(90); // лучи в среднем положении
Но вслед за этим проверяется длина сигнала и может сработать что-то еще.
Т.е. если нажата кнопка, то в цикле у вас получится так, что сначала всегда пишется 90, а затем пишется что-то еще в зависимости от длины сигнала.
Но вслед за этим проверяется длина сигнала и может сработать что-то еще.
А может тогда дописать еще одно условие после проверки кнопки?
if (digitalRead(button) != HIGH)
{
… и пошло дальше
Вот такой оптимизированный цикл:
int last_servo_mode = -1;
int servo_mode = -1;
void loop() {
if (digitalRead(button) == HIGH) {
// если кнопка транспортного положения нажата
servo_mode = 90; // лучи в среднем положении
}
duration = pulseIn(pin, HIGH); // считывается длинна сигнала
if (duration > 1800) {
// если тумблер в нижнем положении
servo_mode = 0; // лучи опускаются вниз
} else if (duration > 1200) {
// если тумблер посередине
servo_mode = 180; // лучи поднимаются вверх
} else {
// если тумблер в верхнем положении
// замеряется расстояние до земли:
Serial.flush();
Serial.write(0x55);
delay(10);
if (Serial.available() >= 2) {
HighLen = Serial.read();
LowLen = Serial.read();
Len_mm = HighLen << 8 + LowLen;
Serial.print(Len_mm, DEC);
Serial.println(“mm”);
}
if (Len_mm <= dist) {
// если расстояние ниже, равно пороговому
servo_mode = 0; // лучи лучи опускаются вниз
} else {
// если расстояние выше порогового
servo_mode = 180; // лучи поднимаются вверх
}
}
if (servo_mode != last_servo_mode) {
myservo.write(servo_mode);
last_servo_mode = servo_mode;
}
}
А может тогда дописать еще одно условие после проверки кнопки?
А у вас кнопка или переключатель имеет приоритет? Если кнопка, то после обработки кнопки надо пропустить остальную часть (поместить ее в else), если переключатель, то оставить как есть. (Но писать все равно один раз за цикл, как я запостил выше).
А у вас кнопка или переключатель имеет приоритет?
Кнопка в приоритете. Так как нажимается только при подготовке к полету и при завершении.
я тут пока испробовал код по первой рекомендации - в транспортном положении стоит ровно, не гудит и не дергается. А в остальных режимах дергает.
Сейчас разберусь в коде второй рекомендации. Благодарю, что потратили время на написание.
Тогда обработку кнопки достаточно перенести вниз после обработки переключателя и до записи окончательного значения в серву. Она будет выполняться последней и переустановит любое значение, которое было установлено до этого.