roboforum.ru

Да я никак не могу собраться и прочитать этот поток неструктурированного текста

Для всего этого надо неплохой МК с неплохим же объемом оперативки.

Плюс - очень многие из этих идей скорее всего будут работать только при специальном освещении. Например яркие конусы выделять при ярком освещении - то еще занятие. Скорее наоборот черные конусы есть смысл ставить - в обычной домашней обстановке редко есть абсолютно черные предметы

Самый большой секрет – истинный автор проекта.
А алгоритм там простой:
картинка поступает в РС,
РС анализирует массив и выхватывает пиксели по уровню,
прикидывает положения пятна относительно центра,
дает команду боту на поворот и ход.
На МК тоже так сделать можно, особенно с небольшим сенсором типа мышиного.
А самый простой вариант с парой диодов недавно демонстрировали в достижениях.

а можно вместо анектодов ответы на поставленные еще в феврале вопросы?

Не-а, самые большие секреты - это:

1. Создать мир, который легко обсчитывается, а не решать задачи в общем виде.
-----------------------------------------------------------------------------
(например расстояние до препятствия можно определить чисто геометрически, зная,
что оно стоит на полу, плоскость которого заранее известна и задана).

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

3. Оптимизировать скорость выполнения кода, а не процесс программирования.
--------------------------------------------------------------------------
При оценке сложности алгоритмов, часто забывают об операциях пересылки данных,
вызова функций и т.д. На микроконтроллере об этом забывать нельзя: сравним для Хmega
MUL+ADD = 3 такта, LDS+STS = 4 такта, RCALL+RET = 6 тактов. Вывод -
перекладывать в буфер, доставать оттуда, делать всякие "перестановки бабочкой",
вызывать функции - это операции, которых по возможности нужно избегать.
Поэтому я - за обработку на лету, развернутые циклы, сосчитанные такты и т.п.
Это не очень весело писать и отлаживать, зато это весело работает.

4. Использовать дополнительные возможности робота (движение, подсветка)
-----------------------------------------------------------------------
Пример с подсветкой привел с картинками - по-моему, показательно.
В конце концов подсветку препятствий используют традиционно с TSOPами - это вроде
ни у кого бурных протестов не вызывает... Тут мы делаем то же самое, только
направление можно определить точнее (в конце концов камера - это просто куча
хорошо сфокусированных фотосенсоров )).

5. По возможности уменьшать области интересов за счет оптимизации построения
мира и предсказания на основе предыдущих кадров.
-----------------------------------------------------------------------
Ну, вроде очевидно.

2. Вот уж не поверю я, что на компе нету библиотек под частные случаи матриц
3. Это всё хорошо звучит, вот только надо бы цель поставить, потом МК под это выбрать, а потом дальше уже двигаться
4. Из поставленной задачи будет ясно - что есть, а чего нет.
5. Это высший пилотаж, хотя безусловно даёт огромный выигрыш по производительности.

Подсветка плоха по нескольким причинам:
1. В движении мы получим 2 разных кадра, которые нет смысла накладывать.
2. На ярком солнце один фиг ничего хорошего не получить.
Т.е. работать будет только в затененном помещении и только после остановки.

Добавлено спустя 44 секунды:
XMega не будет проигрывать ARM7 по производительности?

Michael_K полностью тебея поддерживаю!
но вот если бы ты на ARM7 делал, цены тебе небыло бы!!!

wanderer ты всё пропустил, у Michael_K обычная мега успевает
кури поиск