Проект Мегапират на самик!
надо лаком плату залить.
Только, кто будет заливать, учтите, дырку барометра заливать нельзя!!!
ВОт…Я тоже хотел про это спросить,имеется в наличии электроизоляционный акриловый PLSTIK- 71 называется.Все свои регули заливал а про ПИРАТА забыл,дырдочку баро конечно нет.
там около 12 вольт накачивается
Даже больше, 20-22.
При такой напруге пробой ещё более вероятен.
акриловый PLSTIK- 71 называется
Лак в засохшем виде должен оставаться эластичным, иначе при изменении температуры может сковырнуть детали с мест пайки. А так - пожалуйста.
Лак в засохшем виде должен оставаться эластичным, иначе при изменении температуры может сковырнуть детали с мест пайки. А так - пожалуйста.
Также недавно разжился пиратом 😃. Вы, как производитель, какой способ покрытия платы рекомендуете?
Надеть пенопластовые кубики на разъемы, а дырку баро залепить скотчем - и кисточкой его, окаянного, с обеих сторон…
Надеть пенопластовые кубики на разъемы, а дырку баро залепить скотчем - и кисточкой его, окаянного, с обеих сторон…
а что наносить? эпоксидку/цапон/пластик-71/… ?
Очень хорошие отзывы вот об этом URETHAN 71 , но плата становится одноразовой.
Т.е. после покрытия ремонтировать уже невозможно, если что.
ремонтировать уже невозможно
признайся, хоть одну плату вообще приходилось ремонтировать? 😁
😁 Да! Одну.😁 После хорошего удара😁
И всё. 😉 (Тьфу 3 раза😒)
URETHAN 71 , но плата становится одноразовой.
Т.е. после покрытия ремонтировать уже невозможно, если что.
Этот лак еще более-менее снимается на поверхности. Вернее, куда паяльничком (без фанатизма) будешь тыкать - наподобие канифоли, только не так сильно, расползется вокруг этого места. Изоляция от воды, конечно, суперская. Пленка не хрупкая, после дикого удара скорее пайки отпадут, но детальки “для отчетности” в пленке останутся. Вот если залезет под микруху - греть придется крепко.
===========
Промышленно применяют 730 эпоксидный лак, вот после него уже хуже.
Акрил тоже трудно снимать.
Вот если залезет под микруху
Именно про них и речь. Если понадобится поменять отказавший датчик, к примеру.
А вернуть на место оторванный электролит, конечно, особой проблемы не будет.
По разбору полетов:
если в КП тоже встроить КИ, чтобы скрипт на компе читал что говорит скрипт из платки и проверял не случилось ли чего плохого(напр. переполнение стека или зависание).
Скрипт в платке включает sys_trace и всячески переключает режимы -
получится система авто-тестирования ?
Бесполезно. Там вся система колом встает по аппаратному исключению. Типа di halt. Просто нельзя такое из контроля упускать на этапе разработки.
Бесполезно. Там вся система колом встает …
КП тоже встает колом при прблеммах на плате или мы про разное ?
(Ващето хорошо бы и режимы КП переключать из тестовых скриптов для проверки на глюки.)
А еще можно карту грузить скриптом.
А уж сколько хотелок можно само-реализовать если в интерпретатор в КП будут встроены ф-ии parse_xlog(uchar *) и send_ppm(ushort []) 😃
(ну и change_script(“скрипт_в_епром”) или даже send_script(“скрипт_из_КП”) до кучи)
Вопщем мне нравятся скрипты в КП 😃
КП тоже встает колом при прблеммах на плате или мы про разное ?
Смотря что вы поодразумеваете под словом КП. Есть СУ (плата) и НСУ (наземка на компе). НСУ “не встает”, это точно 😃 Но от платы-то данных все равно нет.
В полете как-то модифицировать скрипты (заливать проги целиком) - это надо иметь супер-надежный модемный линк, т.к. выпадение пары пакетов почти 100% вызовет ошибку интерпретации.
Гораздо надежнее будет сделать скрипт-драйвер на борту, который будет парсить коротенькие текстовые команды, передаваемые с земли в терминал. А в НСУ сделать еще один UDP-сокет, который будет эту текстовуху принимать-передавать на внешнюю прогу, можно даже на другом компутере. Написанную хоть на питоне или интерпретаторе бэйсика. Также можно изгаляться вызовом ScriptControl API прямо с земли безо всяких драйверов.
Смотря что вы поодразумеваете под словом КП. Есть СУ (плата) и НСУ (наземка на компе).
Стало быть НСУ.
Значит предложение по наземному авто-тестированию новых прошивок звучит так: в НСУ встроен интерпретатор скриптов, в нем запущен скрипт, который всячески переключает режимы борта(ОСД и др.), если ответы пропали или в них что-то подозрительное то пишет об этом на экран(или в файл). Если через n-часов все ОК, то можно лететь. (на борту включен sys_trace)
Переключать вручную все комбинации очень трудоемко (имхо).
Нсколько понимаю, так будет отловлен случай со стеком. Тест-скрипты у всех могут быть разные.
А в НСУ сделать еще один UDP-сокет, который будет эту текстовуху принимать-передавать на внешнюю прогу,
Из него можно будет читать строчки xlog’а с координатами(,ориентацией и др.) ?
А что и в каком формате в него можно будет писать ?
Задержка от события на борту до прихода на борт ответной реакции ~0.1сек ? (предположим внешния прога без задержки)
Также можно изгаляться вызовом ScriptControl API прямо с земли безо всяких драйверов.
А это что-то новое? (вроде в описании не встречалось и в сообщениях не помню)
вроде в описании не встречалось и в сообщениях не помню
а первоисточникъ(мануал на КИ) почетать? 😃
dl.dropboxusercontent.com/u/…/mpx_cli_rus.pdf
Пользователь вообще не должен проводить QA, он должен получить безбажную прошиву.
Меры на стороне разработчика приняты. Вовлекать каждого пользователя в процесс тестирования очевидно работающих вещей не вижу смысла.
Из него можно будет читать строчки xlog’а с координатами(,ориентацией и др.) ?
А что и в каком формате в него можно будет писать ?
Что КИ выведет, то и будет. И общаться тоже путем команд КИ. Вариант удаленного текстового терминала.
А по задержкам - читайте мануал по КИ.
а первоисточникъ(мануал на КИ) почетать?
Опять перепутал термины, сорри (называл это все(интерпретатор с либой и скрипт) “КИ” или “скрипты” на борту).
Вовлекать каждого пользователя в процесс тестирования очевидно работающих вещей не вижу смысла
Дело ваше.
Что КИ выведет, то и будет. И общаться тоже путем команд КИ. Вариант удаленного текстового терминала.
Это гуд:) Т.е. while(1){print(xyz,rpy);gets(t_point)} на борту и while(1){gets(xyz,rpy);calc(…);print(t_point)} в/из udp на земле (наземный,сишный,такой-же, только без udp уже есть).
А по задержкам - читайте мануал по КИ.
Вроде примерно так и написал 2*периодичность скрипта + период xlog’а + еще немного.
наземный,сишный,такой-же, только без udp уже есть
Интерпретатор у нас один - на борту. На земле - только его терминал. Т.е. если пишем в терминале printf(“%d,%d”,xyz,rpy) - эта команда голимым текстом передается по модему на борт, там интерпретируется, исполняется и мы видим в ответ что-то типа:
-128,1068
>
Также мы можем задать функцию “на лету” и потом ее же и вызвать, просто вводя ее текст в терминале.
Хотел предложить вам позапускать примеры, но у вас платы нет…
Вот эти самые примеры можно грузануть сразу из файла одной кнопкой. А можно сидеть и построчно вбивать в окошке терминала. Результат будет одинаковый.
Интерпретатор у нас один - на борту.
В НСУ открыт udp-сокет, к нему приконектил внешнюю прогу-интерпретатор, но не с VB, а сишный - это и есть второй(который уже есть).
В КИ на борту написал printf(“rpy %f f %f\n”,…); строчка прилетела в stdin наземного с-скрипта.
Он ее прочел и решил подрулить, сказал printf(“cmd”); строчка cmd прилетела на борт.
Вроде так?
Засада в том, что интерпретатор на борту думает, что это ему, а не передает как есть в stdin бортового скрипта.
Штатное поведение интерпретатора - передать свой вход прямиком в скрипт, проверял.
Можно ли разделить данные: из НСУ - в интерпретатор для обработки, а из udp - прямиком в stdin бортового скрипта ?
Или, м.б., сделать обертку: to_script(“str”), чтобы str прочесть fgets’ом на борту ?
(Т.е на земле говорить: printf(“to_script(\“str\”)”), to_script съест бортовой интерпретатор, а str пойдет в скрипт.)
…можно грузануть сразу из файла одной кнопкой. А можно сидеть и построчно вбивать в окошке терминала. Результат будет одинаковый.
Позапускал в своем, закоментировав ScriptControl_API, все ОК.
Но, если передавать только параметры для ф-ии без самого текста, то меньше трафик.
Или, м.б., сделать обертку: to_script(“str”), чтобы str прочесть fgets’ом на борту ?
Пургу написал 😃
Этот вариант и так уже есть. Все отлично, нет проблем.
Можно писать пилотажные скрипты 😁
Можно писать пилотажные скрипты
Вполне. Вывод серво от скриптов есть 4 канала прямо на микшер. Хоть подруливать, хоть самому рулить скриптом.
С таймингами нужно будет поизвращаться, примерно как на ZX-спектруме, когда на бордюре рисовали. Но время обработки одной инструкции - суть величина детерминированная. В мануале цифры есть.
Нарисовал немного скриптов на пробу.
//фото-змейка(план), фотик в автомате
void fzp(float hdg1, long dis1, float hdg2, long dis2, long dis3) {
AP_SetFlightMode(FM_ALT);
do {
AP_GotoHdgDisAltC(hdg1, dis1, 0);
AP_GotoHdgDisAltC(hdg2, dis2, 0);
AP_GotoHdgDisAltC(hdg1 + 180.0, dis1, 0);
AP_GotoHdgDisAltC(hdg2, dis2, 0);
} while (XPoint_home.dis < dis3);
AP_SetFlightMode(FM_RTH);
}
//фото-круговая панорама
void fkp(short k) { short az;
AP_SetFlightMode(FM_STAB );
az = XPoint_home.hdg;
AP_WSriteRC(CH_РНаправления, k);
while (az == XPoint_home.hdg);
delay_ms(1000); //если качнет ветром
while (az != XPoint_home.hdg);
AP_WSriteRC(CH_РНаправления, 0);
}
А это на тему “пилотажные скрипты”. К бочке еще бы надо приделать разновидность стабилизации но направлению.
//петля
void petlya(short k) { short pt;
AP_SetFlightMode(FM_MANUAL);
pt = X_pitch;
AP_WSriteRC(CH_Двиг, Двиг_max);
AP_WSriteRC(CH_РВысоты, k);
while (pt == X_pitch);
delay_ms(1000);
while (pt != X_pitch); //не застрять бы
AP_SetFlightMode(FM_STAB );
}
//бочка
void bochka(short k) { short rl;
AP_SetFlightMode(FM_MANUAL);
rl = X_roll;
AP_WSriteRC(CH_Элероны, k);
while (rl == X_roll);
delay_ms(500);
while (rl != X_roll); //
AP_SetFlightMode(FM_STAB );
}
//поворот по дуге
void ppdug(short ang) { short y;
AP_SetFlightMode(FM_STAB );
AP_WaitForCompletion(0);
for (y = (X_yaw + ang) % 3600; y != X_yaw;
AP_GotoHdgDisAltC(X_yaw + 30, 100, 0));
AP_WaitForCompletion(1);
}
Так ?
Когда авторежимы на коптеры ждать?
Вторая зима уж пошла, народ жаждет автоматические режимы!!!
Сам не знаю. В настоящее время не имею возможности заниматься коптерами.