Проект Мегапират на самик!
Бесполезно. Там вся система колом встает по аппаратному исключению. Типа 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);
}
Так ?
Когда авторежимы на коптеры ждать?
Вторая зима уж пошла, народ жаждет автоматические режимы!!!
Сам не знаю. В настоящее время не имею возможности заниматься коптерами.
народ жаждет автоматические режимы!!!
А уже забил что либо ждать от Олега… Уже игловектора жду))
Правду говорят, проект который ведет один человек, чаще всего остается недоделанный и заброшенный…
Правду говорят, проект который ведет один человек, чаще всего остается недоделанный и заброшенный…
ничего себе недоделанный!
просто ап этот больше самолётный чем коптерный. ИМХО принять это как факт и успокоиться.
в дальнейшем да, придётся Олегу что-то придумывать чтобы вовлечь народ в разработку.
но ему это лучше видно
просто ап этот больше самолётный чем коптерный.
Олег обещал полную коптерную поддержку. Для этого и покупал… На самолетах у меня есть чему летать. А вот на коптер приличной ОСД за приемлемые деньги, еще не было.
На коптеры и я повелся.
Олег а есть вариант того же ардупилота портировать на твою плату?
Без авто режимов летает твой вариант изумительно, пофиг на вибрацию, чем страдают усякие ардупилоты.
По поводу обещаний, “повелся” и т.п. Когда вы покупаете железку, у нее есть заявленный функционал и ему она должна соответствовать. И соответствует ведь.
Не устраивает функционал - в барахолку ее и ставьте то железо, где четко заявлено “у меня есть авторежимы для коптерофф” и т.п.
недоделанный и заброшенный…
Текущая версия прошивы 2.0.5149 и наземка 87 (на русском). Давность- 23 февраля.
Такой вот заброшенный проект. А человеков в нем - два.
Олег, не парься - продолжай работать! А поболтать тут есть кому…
И соответствует ведь.
Понятно.
Если вы считаете что правы пусть так и будет. Значит это я себе на фантазировал лишнего…
А поболтать тут есть кому…
Умолкаю…
Умолкаю…
Алекс без обид…
Я имел ввиду что Олег и так очень оперативно прошивки меняет и обновляет. если какой косяк вылезает - то и в течении суток поправляет!
А на счет коптерных режимов… Думаю, что и к ним придет черед, просто не надо сразу с плеча!
прости если мои слова задели…