Board.KolibriOS.org

Поскольку дискуссия по теме "Колибри в робототехнике" становится всё более нервной,
предлагаю обсуждать аппаратные, кинематические и электромеханические проблемы в этой ветке.

Напоминаю, что для облегчения анализа, дополнения и критического осмысления
некоторые дискуссионные материалы вынесены на Вики для совместного редактирования:

http://wiki.kolibrios.org/wiki/Embedded_Platforms/ru
(список будет дополняться)

Чтобы сильно не растекаться мыслью по сабжу, советую время от времени сверяться с двумя центральными вопросами:

1) если в робототехнике - то почему на платформе x86 ?
2) если х86 - то почему именно в Колибри ?

Серьёзые ответы на эти вопросы позволяют сразу же очертить (очень узкий) круг перспективных применений Колибри в робототехнике и не отвлекаться на другие темы.

"1) если в робототехнике - то почему на платформе x86 ?" - адекватный ассемблер с кучей документации имеет место быть
"2) если х86 - то почему именно в Колибри ?" - ну хотя бы вот тут, много причин

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Очень неглубокие ответы. Особенно улыбнуло насчет адекватного ассемблера.
И вообще причем тут ассемблер? Выбор платформы определяется требованиями ТЗ, причём решение принимает не программист после детального анализа всех возможных вариантов.

Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
Да еще в робототехнике, где не должно быть ничего лишнего, избыточного ?

разумных вариантов ответов немного:
а) промышленные роботы.
Здесь нет ограничений по стоимости, массе и энергопотреблению, да и по габаритам они не очень жёсткие. Важна производительность и надёжность, простота наладки и апгрейда. Однако для Колибри в этом секторе ниши нет и не будет.

б) автопилоты и системы дистанционного управления транспортными средствами.
Интересная и весьма перспективная область применения для (х86 + Колибри), только с робототехникой как-то слабо связана.

в) быстрые колёсные и плавающие роботы
с достаточными бортовыми энергоресурсами. Несмотря на некоторые массогабаритные ограничения, перспективы здесь очень заманчивы.

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

д) дроны
проблемы с массой и габаритами.

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

ё) и кое-что ещё

Тема мутная, какая то. Считаю, что возникла на эмоциях.
Либо название нужно другое, более конкретное...
Либо "рамки" ее нужно, как то более прорисовать...
У Колибри вообще исторически-архитектурно многие проблемы...

Роботы и иже с ними, например АСУ ТП, и т.д. это вообще частный случай совокупности проблем. Об этом надо сразу оговорить наверное.
Очертить типа "тематический круг проблем" хотя бы. Системотехнические проблемы, как то это вообще типа.
x86 я бы оставил в покое, как де факто.
Мне видится важным, например, тут сконцентрировать взгряд на аппаратную ограниченность платформы PC (от неё никуда не деться) и что можно действительно с этим НЕбогатством решить по сути и по факту, если опираться на сложившееся "сегодня".
Выявление существенных проблем, является важным для правильного приложения сил в развитии любой оси.
Ну как быстрый пример - видеозрение.

ну ладно, уболтал, немного пройдемся танковыми треками по твоему "самый важный"

- совместимость кода ПО, как такового, как до проектирования, так и после. И все что из этого вытекает в плюсах выбора. Собствненно тут, как бы известная классика предпроектного анализа и выбора.
Сюда попадает и среда разработки и либы и отладка + отладчики и дальнейшее сопровождение и т.д. Т.е. все аналогично ТЗ на "обычное ПО" на РС платформе

- специфические вещи, которые на x86 выполнены и решены успешно и альтернативы либо нет, либо дорого, либо неудобно, неперспективно на другом. Пусть, как пример видеозахват 16 камер видеонаблюдения (MPEG потоков) их реальный скан на движение, "складирование" и сигналы тревога, опасность, с учетом категорийности опасности присвоенные по факту видеоанализа картинки типа.
Вот на чём можно решить сейчас? Я думаю мысли почти автоматически "поплывут" в x86 сторону и в готовые или полуготовые либы, исходники.....

- производительность, которая требуется для решения задачи. Современные шины PC архитектур. Все это тоже в x86 укажет. Несмотря на то, что гонка за PC, например со стороны все того же ARM происходит, но в ряде условий выбор в сторону x86, будет гарантирован
Сюда же можно отнести и грамотное использование многоядерности, распределительных механизмов эффективных вычислений, требование по "гарячему резервированию" вычислительного процесса(ов) другими ядрами на аппаратном уровне, 100% дублирование, троирование и т.д.

- наличие в x86 4 кольцевого защищенного режима, потенциально позволяет делать очень надежные системы.
Просто не надо тупить и преврашать проц и ОСь в полное полено, используя только ринг 0 и ринг 3!
Я давно против этого. Лично мои планы давно "простираются" на все 4-ре уровня защиты. Неубиенная ОСь пока не создана никем.
Не вижу проблем, чтобы ядро работало на уровне 1, а на уровне 0 работал супервизор! Не забываем и про SMM!!!
(тут полезно вспомнить для наглядности, например, как оживал терминатор, оценивая и "подымая" подсистемы, которые еще что то могут делать, будучи "совсем убитым", растерзанным на куски...)

Хватит в качестве преамбулы в пользу x86?

SMM - глючный легаси набор костылей.
Да и еще огромная дыра в безопасности:

http://tracker.coreboot.org/trac/coreboot/ticket/42
http://www.ssi.gouv.fr/fr/sciences/fich ... duflot.pdf
http://www.securityfocus.com/columnists/402

не-е-е-е-е-е-е... не туда! Штатный BIOS обработчик SMI нужно "гасить ногами" в нормальной ОСи! Имхо.
ACPI и прочая "идиотическая виртуальность", мониторинг платы и типа USBклавки и мыши соответственно автоматически идут "лесом".
А свой обработчик SMI в своей ОСи это норма. похоже мелкософты так ведь и навешивают при загрузке свой.
В настоящее же время это да, дыра, причем на аппаратном уровне! Если можно так выразиться.
Доки рулят, статьи тоже...

Для спецов по ОСРВ, ОСЖРВ, робототехники, АСУ ТП... SMM в виде уродского SMI нафиг не нать, об этом очень хорошо и откровенно, для думающих челов пишут, например, здесь

Собственно наличие работающего SMI из BIOSа после загрузки ОСи - зло в виде непроизводительного убиения процессорного времени, причем хаотическим, непредсказуемым почти, образом!
Как кто то на ромбае сказал, кажись ,что ваш двухголовый супер-пупер проц запросто в i286 превращается...
Реальные замеры потери тактов CPU ужасают и заставляют думать, размышлать.

Угу. А теперь попробуй прогнать эти два (вполне резонных) соображения через вопрос №2 - и окажется, что Колибри тут стоит даже не в стороне, а вообще где-то за углом.

Во всяком случае, качество и полнота имеющихся средств разработки, отладки и поддержки для ARM и PowerPC гораздо выше, чем Колибри может предложить в ближайшей перспективе. А про х86 - и говорить нечего.
И если есть код, готовый к прошивке в робота - то не разумнее ли делать это в родной операционной системе?


Согласен полностью. Предложенные выше варианты б)-д) относятся именно к этой категории.

С этим можно долго и нудно спорить, но я не буду. Считай, что согласен. Попробую вставить этот пункт перед буквой ё)


Опять же, причем тут Колибри? Кто вообще сейчас с этим делом готов экспериментировать (не говоря уже о реальных применениях)?

вот потому и "мутное", что разночтение получается...

Получается ты написал (я это читаю, понимаю так), что п.1. НЕ касается Колибри, а именно поставлено под вопрос соответствие робототехника и x86 и все. Безотносительная констатация только этих двух вещей.
А уж п.2 это типа если п.1 имеет место, то что с Колибри тогда?
Может хотел сформулировать иначе, не знаю.

Ты же их смешиваешь и п.1 и п.2 в своем последнем посте.
Не разделяя на два отдельных пласта и две кучки проблем.
"Сводить" их вместе это отдельное занятие, разговор...
Надо как то "последовательно сливать их в кучу" что ли, раз уж написал порознь. Или сразу очертить одно и точка.

Ну ладно.
Колибри к роботам не готова. Это факт.
Речь может идти о направлениях в работе по данному вопросу, как и куда ее доделывать, адаптировать, а может и переделывать ядро!
Вот для чего, зачем и обосновано ли - это другое дело. Но направления "куда" двигать и как это может быть востребовано можно попытался сказать, порассуждать.
Опять же чего можно достичь в качестве результата.
Часть из этого, я попытался приблизить к пониманию ранее в той ветке.
ОС, ОСью, а механику и приводы, равно, как и их интерфейсы отрицать, опускать неверно. И думаю, это лишь частичка перечня основных вопросов.

Я, конечно, в курсе, что это оффтоп, но не могу удержаться.
VaStaNi, "А свой обработчик SMI в своей ОСи это норма. мелкософты так ведь и навешивают при загрузке свой." - не соблаговолите сообщить, что вы курили откуда информация? Возможность проникнуть в SMM после BIOSовской инициализации - это дыра, которая когда-то была, но которую уже несколько лет старательно закрывают в новых BIOSах и обновлениях BIOS.

_________________
Сделаем мир лучше!

курили многие, и я в том числе практическими исследованиями занимался... маны и чипсеты юзабельные под эту тему.

Фраза не про дыру, собственно+контекст осдева.

ссылался выше где и еще на паре точек где то видел, но давно... может ][akep...

art_zh, а как быть с системами АСУ ТП разного масштаба, тем и возможностей?
Не затрагивать вообще, или интегрировать в твой перечень?

Ну вот навеяло тут понимаешь..., кумекаю типа "умный дом" (чем не АСУ?) взаться ли и забабахать или ну его нафиг.
Хотябы пока стартово-рекламно, как: простейшие охранные датчики, логистика + отправка по мобиле SMSок хозяину(COM порт+ATкоманды), это же типа тоже "под робот косит", как направление?

Пункт б) или ё) ?
Вроде если взять Колибри, то можно по быстрячку и просто и нагладно и логировать события тоже вроде... Можно и по тырнету слать че нить тоже, рулить процессами дома.
Тут реалтайм не нать по сути, замороки с этим не будет.
Тут типа "пощелкать релюхами" удаленно и в комнатах загорается/тухнет свет (эффект присутствия)...
Датчики присутствия завести типа "сухой контакт" вообще пустяки...
Много чего выдумать можно.
Че то фильмец "Один дома" вспоминается... попутно.

Думаю, что как раз на базе GPIO очень просто получается во всех аспектах включая схемотехнику периферий. В принципе это "конструкция одного выходного дня" если все в масть покатит. Ну а повторить сие в описанном виде + готовая прога, то это вообще дело просто "правильно растущих рук" наверное.
Вполне даже дешево думаю тоже.Сравнить провда мне не с чем.
Если взять из той таблицы базовую плату типа VDX-DIP-ISA
то даже на аккумуляторе (типа ТЗ, реальность случаев) она протянет весьма долго (аварийные ситуации + сознательные обесточивания при проникновении на объект...). Ну емкость тут определиться надо, конечно.
А вот на других платформах (контроллерного типа) все очень туманно в плане визуализации объекта + датчики ну и сроков реализации, и вообще перспектив развития и усовершенствования...

"А не замахнуться ли нам на Вильяма....,
на нашего...
на Шекспира?..."
(с) "Берегись автомобиля"

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

Все умничать пытаешься?

Если сказать, что то для пользы дела хочешь - так скажи, вдруг мы поймем.

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