Колибри в робототехнике: системотехнические проблемы.

Using Kolibri in embedded systems
  • "1) если в робототехнике - то почему на платформе x86 ?" - адекватный ассемблер с кучей документации имеет место быть
    "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 (от неё никуда не деться) и что можно действительно с этим НЕбогатством решить по сути и по факту, если опираться на сложившееся "сегодня".
    Выявление существенных проблем, является важным для правильного приложения сил в развитии любой оси.
    Ну как быстрый пример - видеозрение.
  • art_zh wrote:Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
    ну ладно, уболтал, немного пройдемся танковыми треками по твоему "самый важный" :mrgreen:

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

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

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

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

    Хватит в качестве преамбулы в пользу x86? :D
  • 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
  • XVilka wrote:SMM - глючный легаси набор костылей.
    Да и еще огромная дыра в безопасности:
    не-е-е-е-е-е-е... не туда! Штатный BIOS обработчик SMI нужно "гасить ногами" в нормальной ОСи! Имхо.
    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.
  • VaStaNi wrote:
    art_zh wrote:Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
    ну ладно, уболтал, немного пройдемся танковыми треками по твоему "самый важный" :mrgreen:

    - совместимость кода ПО, {...}. Сюда попадает и среда разработки и либы и отладка + отладчики и дальнейшее сопровождение и т.д.

    - специфические вещи, которые на x86 выполнены и решены успешно и альтернативы либо нет, либо дорого, либо неудобно, неперспективно на другом.

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

    Во всяком случае, качество и полнота имеющихся средств разработки, отладки и поддержки для 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 в своем последнем посте.
    Не разделяя на два отдельных пласта и две кучки проблем.
    "Сводить" их вместе это отдельное занятие, разговор...
    Надо как то "последовательно сливать их в кучу" что ли, раз уж написал порознь. Или сразу очертить одно и точка.

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

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

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

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

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

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

    "А не замахнуться ли нам на Вильяма....,
    на нашего...
    на Шекспира?..."
    (с) "Берегись автомобиля"
    :lol:
  • Ясно, сложные конструкции не воспринимаются, надо быть проще.
    VaStaNi, подтвердите чем-нибудь свои слова "мелкософты так ведь и навешивают при загрузке свой."
  • Все умничать пытаешься?

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

    Users browsing this forum: No registered users and 5 guests