Board.KolibriOS.org

Всем доброго времени суток.
Я искренне надеюсь, что созданная в данный момент тема не станет элементом захламления сего форума, и что мне удастся довести начатое до конца. Честно признаться не всегда у меня это получается. Хотя так у большинства наверное.
Итак, собственно я уже некоторое время занимаюсь созданием для себя удалённо управляемого робота. Делают сейчас их многие, однако сложно спорить - штука интересная, область их актуального применения весьма широка и не освоена в полной мере. Есть что развивать, над чем работать.
Очевидно так же, что создаваемая людьми на этом ресурсе операционная система потенциально почти идеально подходит именно для роботизированных конструкций.

Чтобы не говорить о сферическом коне в вакууме, я его сейчас опишу по частям.
Условная схема работы прикреплена во вложении.

1. Имеется два устройства – робот и оператор. Связь осуществляется через 3G а если повезёт 4G модем, находящийся внутри робота, имеющий статический ip. По факту является сервером.
2. Серверное приложение, может принимать от оператора короткие текстовые команды. Производится сопоставление команд и выполняется соответствующее действие.
3. Физическое взаимодействие с миром осуществляется посредством 4 электродвигателей. Все электродвигатели могут производить вращение в обоих направлениях, поэтому питаются посредством H-мостов. H-мосты включаются управляющим сигналом с LPT порта, который опять же контролируется серверной программой.
4. Четыре электродвигателя отвечают за 4 вида физических действий: движение вперёд/назад, поворот вправо/влево, поворот головы, поднимание рук. Поворот головы в некоторой степени необходим для навигации и в несколько большей для «оживления» разработки, дабы она не являлась просто ведром на колёсах. Согласитесь, ведро на колёсах с поворачивающейся головой несравнимо круче. А с поднимающимися руками просто вершина человеческого прогресса. Так же поднимание рук требуется для стыковки с зарядным устройством. Зарядное устройство представляет собой хреновину похожую на рамку металлодетектора. Заезжая в неё робот поднимает руки, электромагниты на концах рук притягиваются к стенкам рамки и получают питание от них. Ориентировочное напряжение в стенках рамки – 14 вольт.
5. Робот производит постоянную видео съёмку и звукозапись. Потоком отправляет это оператору. Оператор на основе этого посылает свои команды. Круг замыкается.


Что готово.
Совсем недавнее состояние робота можно увидеть тут - http://www.youtube.com/watch?v=BJMJAf_Zn3A
Сейчас я частично обклеил его папье-маше и ему стыдно показываться на людях.
Есть черновые варианты управляющего софта под windows (c#.net) и linux (python 2.7 в altlinux`е). Но это не круто. Мне кажется использование KolibriOS само по себе будет интересным деянием.
Были готовы H-мосты. Они сгорели. Все. Я плакалъ. Дело в том, что были использованы геркониевые реле. А гадкий LPT при включении компьютера посылает включающий сигнал на все свои выходы. В общем всё замкнуло, а геркониды весьма чувствительны к большому току. Сейчас переделываю всё на биполярниках и ,там где нужны больше мощности, полевых транзисторах. В схему теперь будет добавлен ограничитель на одновременное включение обоих плеч моста.
Почти готова вся механика. Руки поднимаются (требуется немного доработать), голова поворачивается, робот гоняет по комнате. Готова общая структура – каркас.

Что ещё нужно.
Да много чего. Здесь и далее, прошу учесть моё отношение к данному делу – меня устраивает концепция «это приемлемо». Я не стремлюсь запилить идеальную вундервафлю. Хочется сделать её максимально хорошо, но не увязать в бесконечном стремлении к идеалу. Понимаю, что с этой концепцией не очень вяжется желание использовать Kolibri. Но тут меня просто охватило желание, и оно в некотором смысле иррационально. Однако одно дело когда твой робот движется под управлением чего-то давно кем-то сделанного и отлаженного, а другое, когда ты внёс свою малую лепту.
Итак, по пунктам.
1. Видео поток. Пользователь SoUrcerer говорил что есть возможность хватать отдельные картинки с веб камеры. Меня это более чем устроит. По каналу планирую передавать не сколько сами изображения, сколько результаты работы алгоритма межкадровой разницы, она же «компенсация движения». Должен будет получиться своеобразный аналог кодека MPEG-4. Конечное изображение будет собираться на стороне клиента и уже тогда выводится на экран. С некоторой периодичностью по каналу будет передаваться базовое изображение в нормальном качестве, чтобы сбрасывать накапливающуюся погрешность изображения. Однако пользователь art_zh рекомендовал мне использовать CMOS-сенсор. Насколько я понимаю он считает использование обычной вебкамеры неприемлемым по причине её низкой скорости снятия картинки с окружающего мира (art_zh, это так?). В результате это приведёт к тому, что в движении и тряске камера будет выдавать размытое смазанное изображение. Насколько понимаю CMOS-сенсор способен выдавать большую скорость считывания. Кроме того такая микруха даст разрешение выше 1Мп, контрастом 10-12 бит и скоростью потока >40Mп/с. Да да, это я нашёл обсуждение подобного момента в теме «Колибри в робототехнике». Не уверен, что мне требуется высокое качество изображения. В отличии от парня с кафедры Московского Энергетического Института мне не требуется распознавание образов. Видеопоток будет передаваться оператору и уже человек будет разбираться что там собственного говоря происходит. Поток, как уже упоминалось будет передаваться по беспроводному модему. По этой причине высокого качества съёмки нам не видать – изображение придётся жать настолько насколько совесть позволит. Думаю мне стоит сделать вот что – как соберу робота в боевое состояние (сейчас расковыренный на диване лежит) заставлю его поездить по комнате и запишу видео с его камеры. Посмотрим как оно получится и станет ясно, устроит такое качество съёмки или нет.
2. Запись звука. Хз, что с этим делать ещё даже не думал. Альтернатива – сенсорный экран. Удастся ли что-то из этого заставить работать и как - тема отдельного эксперимента и обсуждения.
3. Передача данных по TCP. Ну вроде как тривиально достаточно. Нужно правда будет 3G модем раскочегарить. Да и на «низком уровне» я сеть никогда не писал… Блин я вообще толком на низком уровне не писал, ну да ладно, лиха беда начала.
4. Управление H-мостами через LPT порт. Не думаю что возникнут особые сложности. Насколько я в курсе, ассемблер с портами разговаривает как с родными.
5. Воспроизведение заранее записанных сеплов-фраз. По-идее ничего сложного.
6. Корпус. Непосредственно KolibriOS это не касается, но думаю освещение процесса будет полезно данному форуму. Планирую делать из полимерного пластилина. Хз, как его доводить потом до температуры в 130 градусов. Один вариант гуляет в голове, но соседи за такое убьют. И жена. Но будет весело. Непосредственно пытаться лепить корпус думаю занятие бесперспективное, поэтому делаю сейчас формочки из папье-маше. Возможно это глупо, но хочется красивый и презентабельный корпус сделать, не хуже чем у японцев.

Ну как-то так. Мне понадобится некоторое время освоиться в новой операционной системе. Откомпилить и запустить пару ХеллоуВордов и всё такое.

KolibriOS - это раз.
Работать с сокетами просто - это два.
Успехов!

Аааа! Да что ж ты будешь делать... Исправил, спасибо)

lonely_warrior
Для Колибри есть fmpeg, но только декодеры. Скомпилировать нужный кодек тоже не проблема. Есть даже шанс подключить гпу под это дело.

1. Мостовые переключатели надо делать на полевиках:
а) они лучше держат индуктивную нагрузку,
б) у них лучше проводимость и время переключения,
в) у биполярников самое слабое место - положительный температурный коэффициент проводимости канала. Он легко приводит к локальному пробою на больших токах.

2. СОМ-порт слишком медленный для управления мостами, и ему десериализатор нужен.
Лучше работай через LPT: 8 бит как раз хватит на 4 ведущих движка (вперед/назад и вкл/выкл), и еще 4бита на руку и голову.

3. А слабо рукой в розетку попадать для подзарядки?

4. У вебкамеры два недостатка: CCD и USB.
На бегу CCD размазывает картинку, а USB вносит серьезную задержку при передаче.

Без обид, но уж очень напоминает:

Spoiler:

shelbottexaiscreengraboct2010.jpg (58.56 KiB)

Viewed 13016 times

На вскидку - не знаю как электрическая часть (схема принципиальная электрическая отсутствует), но механика на вскидку не очень хороша - низкая устойчивость, высокий центр тяжести. Также не понятно где размещается элементы питания для электроники и двигателей.

Итак, повозился кое с чем.
В плане программирования немного побаловался с FASM и TinyC. Пытался ещё сделать бинарник на GCC, G++ но как-то не получилось. Может и вернусь к этому, но вероятно хватит того, что есть. А ещё извращался - запускал старый добрый TP7 под DosBox. С тормозами но работает.

Так же сделал запись с веб-камеры встроенной в голову робота, во время его передвижения по комнате. На мой взгляд вполне сносное качество, достаточное для того, чтобы оператор мог ориентироваться в пространстве. art_zh, как показывали мои прошлые эксперименты передача видео по интернету даёт гораздо большую задержку - около 800 миллисекунд, при максимально возможном сжатии и подходящей фазе луны. Управлять не так удобно как хотелось бы, но других вариантов нет, и размениваться на те копейки, которые вносит задержка по usb смысла не вижу. Ну серьёзно.
Видюха вот - http://www.youtube.com/watch?v=yqL8auvib0E

Mario_r4, а что не так с Шелботом? Ну да, есть схожесть в построении, но вот я прикрепил к посту пару фото более приятного на вид экземпляра. А суть то та же.
С высоким центром тяжести я мало что могу сделать - мне нужен выской робот, он должен иметь элемент зрительного контакта с человеком. Нужно это для дела. Я бы рад поменьше да пониже смастерить, да не то будет.
Сегодня попробовал кстати его уронить пару раз, посмотреть что будет. Целый остаётся, только ось из переднего колеса вылетает и крутилка головы. Но они не закреплены пока вообще, так что ничего страшного. Он у меня не раз врезался в препятствия на полном ходу - не падал. В целом по ощущениям - если специально его не толкать - падать он не будет.
На платформе внизу забронированно место для двух 14В аккумуляторов литио-ионных. В общем это мелочёвка, не о том сейчас голова болит =)

lonely_warrior wrote:С высоким центром тяжести я мало что могу сделать - мне нужен выской робот, он должен иметь элемент зрительного контакта с человеком. Нужно это для дела. Я бы рад поменьше да пониже смастерить, да не то будет.

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

lonely_warrior wrote:Сегодня попробовал кстати его уронить пару раз, посмотреть что будет. Целый остаётся, только ось из переднего колеса вылетает и крутилка головы. Но они не закреплены пока вообще, так что ничего страшного. Он у меня не раз врезался в препятствия на полном ходу - не падал. В целом по ощущениям - если специально его не толкать - падать он не будет.
На платформе внизу забронированно место для двух 14В аккумуляторов литио-ионных. В общем это мелочёвка, не о том сейчас голова болит =)

Испытания на прочность нужно проводить для законченной конструкции.

Доброго, всем, кто следит за темой.
Я тут кой чего поднавоял. Где-то успешно, где-то нет.
Во-первых сделал один H-мост. На биполярниках. Да да, не спорю - остальные буду паять на полевиках. Просто детали уже купил, и там моторчик слабый - много мощности ему не нужно. Голову крутит.
Схема внешне напоминает куру гриль. Использовались транзисторы 2xVT837, 2xVT819, 4xKT315. Резисторы 10к и 1к расставлялись методом научного тыка.
В целом работает стабильно чотко, в отличие от прошлой более простой версии, которая сгорела да. Правда пока не получается пробросить инвертируемое соединение с одного плеча моста на другое дабы при одновременном включении не было замыкания, ну да ладно - поэкспериментирую ещё.
Пробовал писать на асме.
Суть в следующем. Сделав мост, мне захотелось его зажечь. К большому сожалению блок питания от бортового компьютера робота так же пал смертью храбрых в ходе одного эксперимента. Да да - я пытался запитать компьютер от аккумулятора. Оказалось это не так просто.
В общем LPT порта в наличии нет, купить новый БП смогу только со следующей зарплаты. А руки чешутся. Поэтому решил зажигать мост через RTS usb-2-com который валялся у меня с давних времён.
Удалось пробросить COM порт внутрь virtual-box. Если кто будет делать: нужно в диспетчере устройств винды обозвать порт вместо автоматически данного имени (COM14 у меня) в COM1 например. Затем в свойствах виртуальной машины просто отметить галочкой "Включить последовательный порт", номер порта: COM1, режим порта - Хост-устройство, путь к порту - COM1.
Написал сначала простую программку под винду, на FASM, которая зажигала мне этот RTS. Всё замечательно - пашет, в том числе изнутри виртуальной машины с winxp.
Программа: Потом попробовал сделать тот же фокус для Kolibri. Взял готовый исходник Example.asm из самого дистрибутива. Это тот который звуки должен проигрывать на нажатие клавиш. Модифицировал его соответствующим образом. Больше ничего в нём не менял. Доска отладки стала писать мне, что я ничего не понимаю в этой жизни, и всё такое. Текст был таким:

K : Process - forced terminate PID: 0000003E [Example]
K : General protection fault
K : EAX : 00000080 EBX : 00000002 ECX : 00000000
K : EDX : 00000088 ESI : 00000018 EDI : 000000D0
K : EBP : 00000000 EIP : 00000041 ESP : 00001000
K : Flags : 00011246 CS : 0000001B (application)

Вкладка "User" в доске молчала.
У меня есть стойкое ощущение что я делаю что-то не так. Подозреваю что это что-то с этими, как их... кольцами. Моя прелесть, блин.
В общем такие дела.
В ближайшее время планирую:
1. Допилить малость то что уже сделал
2. Поделать ещё мостов, уже на полевиках.
3. Поделаю какие-нибудь студенческие лабораторки по асму (а то ничо не помню)
4. Ну и попробую замахнуться на Шекспира передачу данных по сети. Вероятно попробую переделать какие-нибудь исходники сетевых программ, которые уже есть в Kolibri.
Буду признателен за намёк что я не так делаю с COM портом, ибо думаю с LPT будет такой же "успех". Ну и это, какие полевики порекомендуете? В среду пойду затариваться. Я правильно понимаю что принцип работы с полевиком будет несколько иной: по-умолчанию он включен? То есть в выключенном состоянии мотора полевик нужно будет держать под закрывающим напряжением, а чтобы включить двигатель, то напряжение убираем, так?

lonely_warrior wrote:У меня есть стойкое ощущение что я делаю что-то не так. Подозреваю что это что-то с этими, как их... кольцами. Моя прелесть, блин.
....
Буду признателен за намёк что я не так делаю с COM портом, ибо думаю с LPT будет такой же "успех".

Spoiler:

сделал-сам-песочница-нельзя-так-просто-Боромир-240289.jpeg (91.27 KiB)

Viewed 12821 times

Ты прав - колечко то волшебное.
Нельзя просто так взять и читать/писать в порт из Ring3.

В КолибриОС реализована защита для некоторых вещей, чтобы программа не творила чего ей вздумается и без очереди.
1) Нужно либо пользоваться соответсвующими функциями ядра:
Функция 46 - зарезервировать/освободить группу портов ввода/вывода.
Функция 43 - ввод/вывод в порт.
2) Либо использовать Функция 62 - пользовательский доступ к PCI. и поиметь головную боль.
3) Либо перекомпилировать ядро со снятой защитой. viewtopic.php?f=25&t=897&start=139
И вот тогда:

Spoiler:

Боромир-мост-Владивосток-песочница-158315.jpeg (277.93 KiB)

Viewed 12819 times

Попробовал запилить обращение к порту через функцию ядра. Для начала естественно через 46. Использовал компилятор TinyC.
Ошибка выдаваяемая доской оказалась аналогично прошлой K : General protection fault
Выглядело деяние примерно так (http://ru.wikipedia.org/wiki/AT%26T-синтаксис):
Наверное полную ересь пишу, да? Всё таки c#.net расслабляет.
А где кстати можно скачать KolibriA? Готовый к запуску образ, что-то я ссылки на это чудо не обнаружил.

Кстати, правильно ли я понимаю, что в данном случае IRQ4 (com1?) это по мою душу?
пробовал юзать _ksys_reserve_irq(4); из kolibrisys.h для ktcc. Выдаёт всё то же.

А где кстати можно скачать KolibriA?

ftp://ftp.kolibrios.org/users/art_zh/-A/
только ни на чем, кроме AMD Fusion она летать не будет.

lonely_warrior wrote:Попробовал запилить обращение к порту через функцию ядра. Для начала естественно через 46. Использовал компилятор TinyC.
Ошибка выдаваяемая доской оказалась аналогично прошлой K : General protection fault
Выглядело деяние примерно так (http://ru.wikipedia.org/wiki/AT%26T-синтаксис):

Code: Select all

void test_function()
{
   //asm("movl $0x46, %eax");
   asm("movl $0x0, %ebx");
   asm("movl $0x3f8, %ecx");
   asm("movl $0x3f9, %edx");
   asm("int 0x46");
}

Наверное полную ересь пишу, да? Всё таки c#.net расслабляет.
А где кстати можно скачать KolibriA? Готовый к запуску образ, что-то я ссылки на это чудо не обнаружил.

Кстати, правильно ли я понимаю, что в данном случае IRQ4 (com1?) это по мою душу?
пробовал юзать _ksys_reserve_irq(4); из kolibrisys.h для ktcc. Выдаёт всё то же.

int 0x46

int 0x40

А не подскажите с сетью? Новый этот api пытаюсь вкурить 75 функции, не выходит что-то.
Есть функция http_request, работает примерно таким макаром:

Spoiler:

Code: Select all

int32 global_socket_number = 0;

void write_socket(int32 handle, int32 sender_lenght, char* sender_data)
{
    int32 result;
    asm("movl $75, %%eax;
    movl $6, %%ebx;
    movl 8(%%esp), %%ecx;
    movl 12(%%esp), %%esi;
    movl 16(%%esp), %%edx;
    movl $1, %%edi;
    int $0x40;\n": "=&a"(result));
    //test_str = int32_to_str(result);
    return result;
}

void socket_thread()
{
    char* sender_data = "GET /index.php HTTP/1.1\r\nhost: synxronica.com\r\n\r\n";
    write_socket(global_socket_number, strlen(sender_data), sender_data);
}

typedef struct
{
    //word fm;
    word port;
    dword ip;
    //byte buffer[10];
} ServerAddress;
void http_request(char* server_ip, word server_port)
{
    asm("movl $75, %%eax;
    movl $0, %%ebx;
    movl $2, %%ecx;
    movl $1, %%edx;
    movl $0, %%esi;
    int $0x40;\n": "=&a"(global_socket_number));

    ServerAddress localAddress;
    localAddress.port = server_port;
    localAddress.ip = ip_to_dword(server_ip);

    //test_str = int32_to_str(global_socket_number);

    //12,16
    dword result_connect;
    asm("movl $75, %%eax;
    movl $4, %%ebx;
    movl $6, %%esi;
    int $0x40;\n"
    : "=&a"(result_connect)
    : "c"(global_socket_number), "d"(localAddress));

    test_str = int32_to_str(result_connect);

    /*

    asm("movl $40, %eax");
    asm("movl $7, %ebx");
    asm("int $0x40;");


    asm("movl $18, %eax");
    asm("movl $7, %ebx");
    asm("int $0x40;");
    asm("push %eax;");

    int thread_pid=-1;
    _ksys_start_thread(socket_thread, 2048, &thread_pid);

    asm("pop %ecx;");

    asm("movl $18, %eax");
    asm("movl $3, %ebx");
    asm("int $0x40;");
    */
}

Сокет вроде как создаётся, global_socket_number получает значение. А вот коннект к сокету не выходит, в eax засовывается -1. Мож кто окинет взглядом сие, да поймёт в чём дело?
Вообще я посмотрел, приложения связанные с сетью как-то не очень работают. Телнетился к серваку, продключение проходит. А вот пишу ему туда, и хоть бы чего. Потом отваливается по таймауту. Или вылетал. Пинг зависает на 3ей итерации.
Ещё из-за обращения к сокетам бывает зависание всего. То есть окна какбы отвечают, но ничего не делают. Не закрываются даже.
Я свои потуги, которые предствил в данном топике списывал с исходников телнета.
Соответственно возникает соблазн: вполне нормально пашет текстовый браузер. Но исходников "htmlv" я ни в одной ветке svn-на не нашёл. А где он лежит?

http://websvn.kolibrios.org/listing.php ... edc540f510
Сеть еще в стадии ранней разработки. Поскольку старый сетевой стек работал чуть лучше, чем совсем хреново - все решили, что хуже не будет, если автор нового стека зальет его в транк и таким образом это немного подстегнет разработку.