Проект Мегапират на самик!

dundel1
LaPart:

Вот если залезет под микруху

Именно про них и речь. Если понадобится поменять отказавший датчик, к примеру.
А вернуть на место оторванный электролит, конечно, особой проблемы не будет.

13 days later
Frr

По разбору полетов:
если в КП тоже встроить КИ, чтобы скрипт на компе читал что говорит скрипт из платки и проверял не случилось ли чего плохого(напр. переполнение стека или зависание).
Скрипт в платке включает sys_trace и всячески переключает режимы -
получится система авто-тестирования ?

Syberian

Бесполезно. Там вся система колом встает по аппаратному исключению. Типа di halt. Просто нельзя такое из контроля упускать на этапе разработки.

Frr
Syberian:

Бесполезно. Там вся система колом встает …

КП тоже встает колом при прблеммах на плате или мы про разное ?
(Ващето хорошо бы и режимы КП переключать из тестовых скриптов для проверки на глюки.)
А еще можно карту грузить скриптом.
А уж сколько хотелок можно само-реализовать если в интерпретатор в КП будут встроены ф-ии parse_xlog(uchar *) и send_ppm(ushort []) 😃
(ну и change_script(“скрипт_в_епром”) или даже send_script(“скрипт_из_КП”) до кучи)
Вопщем мне нравятся скрипты в КП 😃

Syberian
Frr:

КП тоже встает колом при прблеммах на плате или мы про разное ?

Смотря что вы поодразумеваете под словом КП. Есть СУ (плата) и НСУ (наземка на компе). НСУ “не встает”, это точно 😃 Но от платы-то данных все равно нет.
В полете как-то модифицировать скрипты (заливать проги целиком) - это надо иметь супер-надежный модемный линк, т.к. выпадение пары пакетов почти 100% вызовет ошибку интерпретации.
Гораздо надежнее будет сделать скрипт-драйвер на борту, который будет парсить коротенькие текстовые команды, передаваемые с земли в терминал. А в НСУ сделать еще один UDP-сокет, который будет эту текстовуху принимать-передавать на внешнюю прогу, можно даже на другом компутере. Написанную хоть на питоне или интерпретаторе бэйсика. Также можно изгаляться вызовом ScriptControl API прямо с земли безо всяких драйверов.

Frr
Syberian:

Смотря что вы поодразумеваете под словом КП. Есть СУ (плата) и НСУ (наземка на компе).

Стало быть НСУ.
Значит предложение по наземному авто-тестированию новых прошивок звучит так: в НСУ встроен интерпретатор скриптов, в нем запущен скрипт, который всячески переключает режимы борта(ОСД и др.), если ответы пропали или в них что-то подозрительное то пишет об этом на экран(или в файл). Если через n-часов все ОК, то можно лететь. (на борту включен sys_trace)
Переключать вручную все комбинации очень трудоемко (имхо).
Нсколько понимаю, так будет отловлен случай со стеком. Тест-скрипты у всех могут быть разные.

Syberian:

А в НСУ сделать еще один UDP-сокет, который будет эту текстовуху принимать-передавать на внешнюю прогу,

Из него можно будет читать строчки xlog’а с координатами(,ориентацией и др.) ?
А что и в каком формате в него можно будет писать ?
Задержка от события на борту до прихода на борт ответной реакции ~0.1сек ? (предположим внешния прога без задержки)

Syberian:

Также можно изгаляться вызовом ScriptControl API прямо с земли безо всяких драйверов.

А это что-то новое? (вроде в описании не встречалось и в сообщениях не помню)

Syberian
Frr:

вроде в описании не встречалось и в сообщениях не помню

а первоисточникъ(мануал на КИ) почетать? 😃
dl.dropboxusercontent.com/u/…/mpx_cli_rus.pdf

Пользователь вообще не должен проводить QA, он должен получить безбажную прошиву.
Меры на стороне разработчика приняты. Вовлекать каждого пользователя в процесс тестирования очевидно работающих вещей не вижу смысла.

Frr:

Из него можно будет читать строчки xlog’а с координатами(,ориентацией и др.) ?
А что и в каком формате в него можно будет писать ?

Что КИ выведет, то и будет. И общаться тоже путем команд КИ. Вариант удаленного текстового терминала.
А по задержкам - читайте мануал по КИ.

Frr
Syberian:

а первоисточникъ(мануал на КИ) почетать?

Опять перепутал термины, сорри (называл это все(интерпретатор с либой и скрипт) “КИ” или “скрипты” на борту).

Syberian:

Вовлекать каждого пользователя в процесс тестирования очевидно работающих вещей не вижу смысла

Дело ваше.

Syberian:

Что КИ выведет, то и будет. И общаться тоже путем команд КИ. Вариант удаленного текстового терминала.

Это гуд:) Т.е. while(1){print(xyz,rpy);gets(t_point)} на борту и while(1){gets(xyz,rpy);calc(…);print(t_point)} в/из udp на земле (наземный,сишный,такой-же, только без udp уже есть).

Syberian:

А по задержкам - читайте мануал по КИ.

Вроде примерно так и написал 2*периодичность скрипта + период xlog’а + еще немного.

Syberian
Frr:

наземный,сишный,такой-же, только без udp уже есть

Интерпретатор у нас один - на борту. На земле - только его терминал. Т.е. если пишем в терминале printf(“%d,%d”,xyz,rpy) - эта команда голимым текстом передается по модему на борт, там интерпретируется, исполняется и мы видим в ответ что-то типа:
-128,1068
>
Также мы можем задать функцию “на лету” и потом ее же и вызвать, просто вводя ее текст в терминале.

Хотел предложить вам позапускать примеры, но у вас платы нет…
Вот эти самые примеры можно грузануть сразу из файла одной кнопкой. А можно сидеть и построчно вбивать в окошке терминала. Результат будет одинаковый.

Frr
Syberian:

Интерпретатор у нас один - на борту.

В НСУ открыт 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 пойдет в скрипт.)

Syberian:

…можно грузануть сразу из файла одной кнопкой. А можно сидеть и построчно вбивать в окошке терминала. Результат будет одинаковый.

Позапускал в своем, закоментировав ScriptControl_API, все ОК.
Но, если передавать только параметры для ф-ии без самого текста, то меньше трафик.

Frr
Frr:

Или, м.б., сделать обертку: to_script(“str”), чтобы str прочесть fgets’ом на борту ?

Пургу написал 😃
Этот вариант и так уже есть. Все отлично, нет проблем.
Можно писать пилотажные скрипты 😁

Syberian
Frr:

Можно писать пилотажные скрипты

Вполне. Вывод серво от скриптов есть 4 канала прямо на микшер. Хоть подруливать, хоть самому рулить скриптом.
С таймингами нужно будет поизвращаться, примерно как на ZX-спектруме, когда на бордюре рисовали. Но время обработки одной инструкции - суть величина детерминированная. В мануале цифры есть.

Frr

Нарисовал немного скриптов на пробу.
//фото-змейка(план), фотик в автомате
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);
}
Так ?

frwind

Когда авторежимы на коптеры ждать?
Вторая зима уж пошла, народ жаждет автоматические режимы!!!

Syberian

Сам не знаю. В настоящее время не имею возможности заниматься коптерами.

BAU
frwind:

народ жаждет автоматические режимы!!!

А уже забил что либо ждать от Олега… Уже игловектора жду))
Правду говорят, проект который ведет один человек, чаще всего остается недоделанный и заброшенный…

LysvaSki
BAU:

Правду говорят, проект который ведет один человек, чаще всего остается недоделанный и заброшенный…

ничего себе недоделанный!
просто ап этот больше самолётный чем коптерный. ИМХО принять это как факт и успокоиться.
в дальнейшем да, придётся Олегу что-то придумывать чтобы вовлечь народ в разработку.
но ему это лучше видно

BAU
LysvaSki:

просто ап этот больше самолётный чем коптерный.

Олег обещал полную коптерную поддержку. Для этого и покупал… На самолетах у меня есть чему летать. А вот на коптер приличной ОСД за приемлемые деньги, еще не было.

frwind

На коптеры и я повелся.
Олег а есть вариант того же ардупилота портировать на твою плату?
Без авто режимов летает твой вариант изумительно, пофиг на вибрацию, чем страдают усякие ардупилоты.

Syberian

По поводу обещаний, “повелся” и т.п. Когда вы покупаете железку, у нее есть заявленный функционал и ему она должна соответствовать. И соответствует ведь.
Не устраивает функционал - в барахолку ее и ставьте то железо, где четко заявлено “у меня есть авторежимы для коптерофф” и т.п.

BAU:

недоделанный и заброшенный…

Текущая версия прошивы 2.0.5149 и наземка 87 (на русском). Давность- 23 февраля.
Такой вот заброшенный проект. А человеков в нем - два.

alex-ber

Олег, не парься - продолжай работать! А поболтать тут есть кому…