roboforum.ru

ИМХО:

Утверждение: в нынешнем виде проекта не выживет и не будет развиваться.

Что нужно сделать, чтобы проект начал развиваться:
1. Перейти на нормальные человеческие парсеры;
2. Обеспечить совместимость с Arduino, в т.ч. с ORduino Nano;
3. Возможно надо делать загрузчик свежей прошивки с GUI, который будет сам скачивать новую версию прошивки, в него же можно будет интегрировать демонстрационную программу для руления пинами\серво, чтения АЦП\пинов, управления моторами; ORFA-терминал нынешний надо будет отделить от этой темы, т.к. его мы создаём для мобильных роботов уже.
4. Обеспечить ему нормальный как минимум под-сайт с кучей инструкций, примеров и т.п., возможно вынести в независимый репозитарий, типа sourceforge.

Кто что думает?

4. Однозначно. Причем примеры должны показывать именно отличие ОРФЫ от например ДУИН,
раскрывать преимущества и показывать целевое применение.
Если вы выставляете модульность и централизованное управление с компа в качестве преимущества,
то на это и сделать упор.
3. Тоже нужно. Максимально автоматизировать процесс старта. Запустил ГУЙ - он сам чего-то нашел.
Может быть и обновил по запросу (а может и не надо)
И выдал сколько надо кнопок - порулить руками, посмотреть на датчики. АПИ со стороны компа
нужен, если система позиционируется как управляемая с компа...
2. Эмм... тогда не понимаю, что есть ОРФА?
1. Скрыть их вообще, ИМХО.

Добавлено спустя 5 минут 52 секунды:
Я бы вообще, с точки зрения "компьютеризованности" провел бы аналогию с
железом NI.

Там в поставке, помимо разнообразного железа, есть АПИ с готовыми примерами (причем под кучу ЯП),
а также "конртол-панель", которая показывает, что куда подключено - можно руками поуправлять,
поизмерять, откалибровать и т.п. То есть вообще, еще ни строчки кода не написав, уже
настроить под конкретное применение - проверить, что все "живет".

4. ORFA (Open Robotics Firmware Architecture) - это открытая архитектура прошивок никак не привязанная конкретно к каким-то контроллерам Open Robotics - т.е. можно сделать драйвера под Arduino и всё.

2. См. выше
1. Это еще как? Парсеры будут всегда пока мы общаемся с модулями по UART, в этом вообще смысл ORFA

PS: Будем иметь бюджеты как у NI - будем делать сразу API под кучу ЯП

ну у дуин-то вообше "прошивок" штатных "кагбе" нету - о совместимости в каком смысле вы тогда говорите? О поддержке в их среде программирования? О железной совместимости? или о чем?

Я считал, что орфа - это прошивки которые работают совместно
и позволяют управлять железками (в идеале несколькими и разнородными) через единый интерфейс...
Это не так?

куча ЯП или не куча, но ДЛЛ-ки как минимум, по-моему, просятся...

Я говорил о совместимости в смысле возможности собрать ORFA под ардуину и рулить её ногами так же унифицировано, как нашими контроллерами.

DLL-ки это пока слишком - надо сначала нормальный UART-интерфейс, потом всякие DLL-ки, а то за DLL-ками пойдут библиотеки под линух, потом под КПК, потом еще всякие шняги и весь этот зоопарк надо будет поддерживать.

Может виртуальную машину JAVA лучше поддерживать ? Эта машина наверно на всех платформах бывает.

в пунктах 1, 3 не согласен, всё решает хорошая инструкция, а зачем гуй? даже в той инструкции что сейчас есть, отлично написано как загружать прошивку.

Добавлено спустя 3 минуты 28 секунд:
тем более эти ''нечеловеческие'' команды мало кто вручную пишет

Пункт 1 связан не только с тем, что это тяжко писать вручную. Очень хочется получить совместимую с SSC-32 прошивку, чтобы не поддерживать сразу два программных продукта + очень тяжко новичкам объяснять какие куда команды надо отправить не зная их версию прошивки и номера регистров.

Мне кажется, что нужно упрощать именно кик-старт и именно для "новичков".

Совсем простого чего-то, имхо, не хватает.
На начальных этапах нужно понять, провода перепутаны, или прошивка не прошилась,
или в софте ошибка, или буковки в команде перепутал.

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

Можно бы и заведомо рабочее железо (да хоть светодиодики на все ноги повесить) для отладки софта - но это уже за рамками темы.

Обеспечивать совместимость с гексаподами - это уже очень далеко от "старта" и для этого УЖЕ
нужно с типовыми - совсем простыми элементарными действиями хорошо обращаться.

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

Но распаковав плату, он не начнет прикручивать ее на спину готовому пауку, правда?
Наверное сначала, он ее положит на стол. Подключит стационарное питание, посмотрит на зеленый светодиод... Так? Потом попробует подключить одну серву... и???

И покрутит ею с LynxTerm. У нас просто есть два варианта - мы пишем всё сами и делаем вид, как будто у нас в запасе 5 лет и 5M$, или мы не выпендриваемся, делаем свои продукты совместимыми с кучей уже готового ПО и не тратим эти 5 лет и 5M$

Нет, Антон, дело не в этом.
Совместимость нужна и полезна, кто же спорит.

Просто должен быть полный комплект удобный для запуска, тестирования, программирования,
чтобы не надо было гуглить, форумить, бегать в магазин "за светодиодиком" и "пятью проводками"
и т.п.
Такие кик-старты очень помогают в освоении... Первые шаги - они самые трудные и отнимают
относительно много времени - вот их и нужно максимально облегчить...
Эти, казалось бы, мелочи и делают продукт... Как вот появились флеш и ISP в МК, остальные
сдулись НА ГЛАЗАХ... даже несмотря на то, что технология дорогая была поначалу,
и несмотря на то, что у всех уже были УФ-лампочки и высоковольтные программаторы.

Ну вот вы посмотрите, какие тут вопросы задают: "как прошить ARM", например.
Чел застрял на самом старте.

Никто не спорит. Вот с унификацией SSC-32 протокола в ORFA масса проблем будет снята, т.к. для управления SSC-32 в части серв есть уже куча софта

Антон, если надо, могу на джаве наваять "прошивальщик" либо даже полностью п.3