Поскольку дискуссия по теме "Колибри в робототехнике" становится всё более нервной,
предлагаю обсуждать аппаратные, кинематические и электромеханические проблемы в этой ветке.
Напоминаю, что для облегчения анализа, дополнения и критического осмысления
некоторые дискуссионные материалы вынесены на Вики для совместного редактирования:
http://wiki.kolibrios.org/wiki/Embedded_Platforms/ru
(список будет дополняться)
Чтобы сильно не растекаться мыслью по сабжу, советую время от времени сверяться с двумя центральными вопросами:
1) если в робототехнике - то почему на платформе x86 ?
2) если х86 - то почему именно в Колибри ?
Серьёзые ответы на эти вопросы позволяют сразу же очертить (очень узкий) круг перспективных применений Колибри в робототехнике и не отвлекаться на другие темы.
Колибри в робототехнике: системотехнические проблемы.
"1) если в робототехнике - то почему на платформе x86 ?" - адекватный ассемблер с кучей документации имеет место быть
"2) если х86 - то почему именно в Колибри ?" - ну хотя бы вот тут, много причин
"2) если х86 - то почему именно в Колибри ?" - ну хотя бы вот тут, много причин
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Очень неглубокие ответы. Особенно улыбнуло насчет адекватного ассемблера.Gluk wrote:"1) если в робототехнике - то почему на платформе x86 ?" - адекватный ассемблер с кучей документации имеет место быть
"2) если х86 - то почему именно в Колибри ?" - ну хотя бы вот тут, много причин
И вообще причем тут ассемблер? Выбор платформы определяется требованиями ТЗ, причём решение принимает не программист после детального анализа всех возможных вариантов.
Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
Да еще в робототехнике, где не должно быть ничего лишнего, избыточного ?
разумных вариантов ответов немного:
а) промышленные роботы.
Здесь нет ограничений по стоимости, массе и энергопотреблению, да и по габаритам они не очень жёсткие. Важна производительность и надёжность, простота наладки и апгрейда. Однако для Колибри в этом секторе ниши нет и не будет.
б) автопилоты и системы дистанционного управления транспортными средствами.
Интересная и весьма перспективная область применения для (х86 + Колибри), только с робототехникой как-то слабо связана.
в) быстрые колёсные и плавающие роботы
с достаточными бортовыми энергоресурсами. Несмотря на некоторые массогабаритные ограничения, перспективы здесь очень заманчивы.
г) машины с динамической поддержкой равновесия (шагающие роботы, скутеры и т.п).
- ?
д) дроны
проблемы с массой и габаритами.
е) (добавлено по совету VaStaNi) если существующие схемы управления требуют наличия в системе отлаженных на х86-архитектуре специфических аппаратных ресурсов (устройств, контроллеров, мостов и системных шин), причем эффективной поддержки этих ресурсов в других системах нет.
ё) и кое-что ещё
Last edited by art_zh on Tue Apr 26, 2011 5:57 pm, edited 1 time in total.
Тема мутная, какая то. Считаю, что возникла на эмоциях.
Либо название нужно другое, более конкретное...
Либо "рамки" ее нужно, как то более прорисовать...
У Колибри вообще исторически-архитектурно многие проблемы...
Роботы и иже с ними, например АСУ ТП, и т.д. это вообще частный случай совокупности проблем. Об этом надо сразу оговорить наверное.
Очертить типа "тематический круг проблем" хотя бы. Системотехнические проблемы, как то это вообще типа.
x86 я бы оставил в покое, как де факто.
Мне видится важным, например, тут сконцентрировать взгряд на аппаратную ограниченность платформы PC (от неё никуда не деться) и что можно действительно с этим НЕбогатством решить по сути и по факту, если опираться на сложившееся "сегодня".
Выявление существенных проблем, является важным для правильного приложения сил в развитии любой оси.
Ну как быстрый пример - видеозрение.
Либо название нужно другое, более конкретное...
Либо "рамки" ее нужно, как то более прорисовать...
У Колибри вообще исторически-архитектурно многие проблемы...
Роботы и иже с ними, например АСУ ТП, и т.д. это вообще частный случай совокупности проблем. Об этом надо сразу оговорить наверное.
Очертить типа "тематический круг проблем" хотя бы. Системотехнические проблемы, как то это вообще типа.
x86 я бы оставил в покое, как де факто.
Мне видится важным, например, тут сконцентрировать взгряд на аппаратную ограниченность платформы PC (от неё никуда не деться) и что можно действительно с этим НЕбогатством решить по сути и по факту, если опираться на сложившееся "сегодня".
Выявление существенных проблем, является важным для правильного приложения сил в развитии любой оси.
Ну как быстрый пример - видеозрение.
ну ладно, уболтал, немного пройдемся танковыми треками по твоему "самый важный"art_zh wrote:Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
- совместимость кода ПО, как такового, как до проектирования, так и после. И все что из этого вытекает в плюсах выбора. Собствненно тут, как бы известная классика предпроектного анализа и выбора.
Сюда попадает и среда разработки и либы и отладка + отладчики и дальнейшее сопровождение и т.д. Т.е. все аналогично ТЗ на "обычное ПО" на РС платформе
- специфические вещи, которые на 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
Да и еще огромная дыра в безопасности:
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 нужно "гасить ногами" в нормальной ОСи! Имхо.XVilka wrote:SMM - глючный легаси набор костылей.
Да и еще огромная дыра в безопасности:
ACPI и прочая "идиотическая виртуальность", мониторинг платы и типа USBклавки и мыши соответственно автоматически идут "лесом".
А свой обработчик SMI в своей ОСи это норма. похоже мелкософты так ведь и навешивают при загрузке свой.
В настоящее же время это да, дыра, причем на аппаратном уровне! Если можно так выразиться.
Доки рулят, статьи тоже...
Для спецов по ОСРВ, ОСЖРВ, робототехники, АСУ ТП... SMM в виде уродского SMI нафиг не нать, об этом очень хорошо и откровенно, для думающих челов пишут, например, здесь
Собственно наличие работающего SMI из BIOSа после загрузки ОСи - зло в виде непроизводительного убиения процессорного времени, причем хаотическим, непредсказуемым почти, образом!
Как кто то на ромбае сказал, кажись ,что ваш двухголовый супер-пупер проц запросто в i286 превращается...
Реальные замеры потери тактов CPU ужасают и заставляют думать, размышлать.
Last edited by VaStaNi on Thu May 05, 2011 8:37 am, edited 1 time in total.
Угу. А теперь попробуй прогнать эти два (вполне резонных) соображения через вопрос №2 - и окажется, что Колибри тут стоит даже не в стороне, а вообще где-то за углом.VaStaNi wrote:ну ладно, уболтал, немного пройдемся танковыми треками по твоему "самый важный"art_zh wrote:Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
- совместимость кода ПО, {...}. Сюда попадает и среда разработки и либы и отладка + отладчики и дальнейшее сопровождение и т.д.
- специфические вещи, которые на x86 выполнены и решены успешно и альтернативы либо нет, либо дорого, либо неудобно, неперспективно на другом.
Вот на чём можно решить сейчас? Я думаю мысли почти автоматически "поплывут" в x86 сторону и в готовые или полуготовые либы, исходники.....
Во всяком случае, качество и полнота имеющихся средств разработки, отладки и поддержки для ARM и PowerPC гораздо выше, чем Колибри может предложить в ближайшей перспективе. А про х86 - и говорить нечего.
И если есть код, готовый к прошивке в робота - то не разумнее ли делать это в родной операционной системе?
Согласен полностью. Предложенные выше варианты б)-д) относятся именно к этой категории.VaStaNi wrote:- производительность, которая требуется для решения задачи...
С этим можно долго и нудно спорить, но я не буду. Считай, что согласен. Попробую вставить этот пункт перед буквой ё)VaStaNi wrote: Современные шины PC архитектур. Все это тоже в x86 укажет. Несмотря на то, что гонка за PC, например со стороны все того же ARM происходит, но в ряде условий выбор в сторону x86, будет гарантирован
Сюда же можно отнести и грамотное использование многоядерности, распределительных механизмов эффективных вычислений, требование по "гарячему резервированию" вычислительного процесса(ов) другими ядрами на аппаратном уровне, 100% дублирование, троирование и т.д.
Опять же, причем тут Колибри? Кто вообще сейчас с этим делом готов экспериментировать (не говоря уже о реальных применениях)?VaStaNi wrote:- наличие в x86 4 кольцевого защищенного режима, потенциально позволяет делать очень надежные системы.
Просто не надо тупить и преврашать проц и ОСь в полное полено, используя только ринг 0 и ринг 3!
Я давно против этого. Лично мои планы давно "простираются" на все 4-ре уровня защиты. Неубиенная ОСь пока не создана никем.
Не вижу проблем, чтобы ядро работало на уровне 1, а на уровне 0 работал супервизор! Не забываем и про SMM!!!
(тут полезно вспомнить для наглядности, например, как оживал терминатор, оценивая и "подымая" подсистемы, которые еще что то могут делать, будучи "совсем убитым", растерзанным на куски...)
вот потому и "мутное", что разночтение получается...
Получается ты написал (я это читаю, понимаю так), что п.1. НЕ касается Колибри, а именно поставлено под вопрос соответствие робототехника и x86 и все. Безотносительная констатация только этих двух вещей.
А уж п.2 это типа если п.1 имеет место, то что с Колибри тогда?
Может хотел сформулировать иначе, не знаю.
Ты же их смешиваешь и п.1 и п.2 в своем последнем посте.
Не разделяя на два отдельных пласта и две кучки проблем.
"Сводить" их вместе это отдельное занятие, разговор...
Надо как то "последовательно сливать их в кучу" что ли, раз уж написал порознь. Или сразу очертить одно и точка.
Ну ладно.
Колибри к роботам не готова. Это факт.
Речь может идти о направлениях в работе по данному вопросу, как и куда ее доделывать, адаптировать, а может и переделывать ядро!
Вот для чего, зачем и обосновано ли - это другое дело. Но направления "куда" двигать и как это может быть востребовано можно попытался сказать, порассуждать.
Опять же чего можно достичь в качестве результата.
Часть из этого, я попытался приблизить к пониманию ранее в той ветке.
ОС, ОСью, а механику и приводы, равно, как и их интерфейсы отрицать, опускать неверно. И думаю, это лишь частичка перечня основных вопросов.
Получается ты написал (я это читаю, понимаю так), что п.1. НЕ касается Колибри, а именно поставлено под вопрос соответствие робототехника и x86 и все. Безотносительная констатация только этих двух вещей.
А уж п.2 это типа если п.1 имеет место, то что с Колибри тогда?
Может хотел сформулировать иначе, не знаю.
Ты же их смешиваешь и п.1 и п.2 в своем последнем посте.
Не разделяя на два отдельных пласта и две кучки проблем.
"Сводить" их вместе это отдельное занятие, разговор...
Надо как то "последовательно сливать их в кучу" что ли, раз уж написал порознь. Или сразу очертить одно и точка.
Ну ладно.
Колибри к роботам не готова. Это факт.
Речь может идти о направлениях в работе по данному вопросу, как и куда ее доделывать, адаптировать, а может и переделывать ядро!
Вот для чего, зачем и обосновано ли - это другое дело. Но направления "куда" двигать и как это может быть востребовано можно попытался сказать, порассуждать.
Опять же чего можно достичь в качестве результата.
Часть из этого, я попытался приблизить к пониманию ранее в той ветке.
ОС, ОСью, а механику и приводы, равно, как и их интерфейсы отрицать, опускать неверно. И думаю, это лишь частичка перечня основных вопросов.