roboforum.ru

Привет.

Во всех примерах ROS используется

подразумевая под этим кодом создание и инциализацию директории рабочего пространства (workspace) с именем catkin_ws (http://wiki.ros.org/catkin/workspaces#Catkin_Workspaces)

Вопрос: В чем "глубинный" смысл понятия рабочего пространства в понимании ROS.

Например, проводя аналогии:
Visual Studio - оперирует терминами "solution" и "project"
Eclipse использует "workspace" и "project"
Idea-based IDE (от JetBrains) используют пакеты, модули, библиотеки.

А в ROS получается workspace и сразу packages. А где понятие "project"? Например, я разрабатывают 2 разных проекта: "robot1" и "robot2". Верно ли, что в таком случае в ROS я должен организовать такую структуру файлов

Это не совсем так. Действительно, в документации на wikiROS написано не совсем понятно, в следствии чего складывается впечатление, что рабочее пространство и каталоги вашего проекта расположены в одном месте, непосредственно в папке /catkin_ws/src. Вы конечно можете разместить каталоги вашего проекта по этому пути, но, как вы верно заметили, сразу возникает вопрос - а если будет два и более проекта?
Вам необходимо создавать папки ваших проектов в этом каталоге, в вашем случае это будет выглядеть так: /catkin_ws/src/robot1 и /catkin_ws/src/robot2. То есть путь /catkin_ws/src/ и является стандартным для создания каталогов содержащих ваши проекты, здесь вы сможете создать любое количество папок и поместить туда свои проекты.
В вашем случае каталоги будут выглядеть так:

На самом деле не важно как вы назовете каталог своего рабочего пространства. Он создается один раз и в нем вы сохраняете свои проекты. Подойдут и те пути что указали вы. Но как всегда, рекомендуется использовать стандартный путь для сохранения совместимости между версиями ROS.

Благодарю. То, что нужно!

Из нашей практики. Рекомендую в папке catkin_ws/src хранить не конечные пакеты, а ссылки на них (soft link). А сами папки с проектами могут валяться где угодно ещё.

Обоснование:
В какой-то момент в основном воркспейсе у вас будет лежать куча проектов, ваших и не очень. Каждое изменение в любом из CMakeLists.txt (поменяли флаги, с Debug на Release, или просто чего добавили) будет приводить к долгой пересборке всего воркспейса (как минимум регенерация кеша cmake). Потому мы периодически создаём мелкие воркспейсы под один два проекта, кладём в another_ws/src ссылки (ln -s) на эти проекты, дабы не копировать лишний раз папки с исходниками, работаем-отлаживаем-правим, и по завершению проверяем собираемость в общем воркспейсе. При том физически исходники каждого проекта лежат ровно в одном экземпляре.

Итого никакой упячки "где последняя версия", и разумное время сборки.