After the publication of the first open call and at our brokerage days, we received a set of questions that seem to be of general relevance. Please find a selection of the most common and their respective answer answer below.
If you have a question that is not yet adressed, please address it to the open call ticketing system via opencalls@robmosys.eu.
What is RobMoSys about?
- The vision of RobMoSys is to create better models, as the basis for better tools and better software, which then allow to build better robotic systems.
- Please see the video “RobMoSys explained: What is the aim of RobMoSys?” for a quick introduction to the core idea of RobMoSys. We use the PC domain as an analogy to describe what we aim for in RobMoSys and how we achieve it.
- See the primary user-stories and the technical user-stories for a user-perspective on the aims of RobMoSys.
- Under approach, the methodology RobMoSys is explained in more details. We finally also recommend reading the publicly available excerpt of the RobMoSys Grant Agreement.
Which types of activities qualify for financial support?
To achieve the RobMoSys goal, types of activities that qualify for financial support are following:
- Development of RobMoSys-conformant industrial case studies based on existing assets.
- Software developments under the form of models, tools, components and patterns in one or more of the technical topics (for more details see Annex 2 of the Guide for Applicants). The current RobMoSys tools baseline is available here.
- Contribution to RobMoSys community building.
The RobMoSys technical user-stories provide a variety of possible topics that RobMoSys encourages to consider.
Can you summarize in a few sentences what the focus of Open Call 2 is?
- Open Call 2 focuses on the link between component level and system level.
- We want to introduce engineering principles for putting together and configuring components to complex systems. We want to get quick answers to what-if questions without building all the different versions and trying them out. We want to understand the outcome of different combinations in order to decide for the one best fitting our needs. When we then decide for one version and build it, we expect to get exactly what we predicted.
- We want to illustrate the advantages of the RobMoSys approach in very concrete examples for which the pilots provide a baseline.
What is the differentiation between first and second open call?
Within the platform concept, the First Open call focuses on composable software development (models, tools and meta-models) while the Second Open Call focuses on system-level through application pilots using the RobMoSys ecosystem.
More in detail, the First Open Call will focus on basic components, that is functional building blocks for motion, perception, real-world software stacks, navigation and manipulation. By the end of this first open call, it is expected that the community will already be able to benefit from industry-grade modelling tools supporting the creation of robotic applications that can be built by composing high quality composable models and associated software functions in the domains of motion, perception, navigation and manipulation.
The Second Open Call of RobMoSys focuses on the following aspects:
- Industry-Driven Ecosystem. RobMoSys defines a model-based ecosystem of assets and services to help the robotics industry to improve their software/system engineering practices. We look for proposals joining us in our effort to create this ecosystem and to demonstrate with real industrial cases your own success story.
- Towards a Strong RobMoSys Community. We call for expert groups willing to be coached by members of the RobMoSys core consortium, in order to implement the RobMoSys concepts. Successful applicants must be ready to advance the RobMoSys way of thinking, and to go for real world examples in line with the RobMoSys industrial pilots (developed by the RobMoSys core consortium).
What will happen with the results of the first call?
Feedback from projects and teams will be constantly gathered to improve specifications and will be reported back to the Tier-1 Experts Group. This procedure will ensure flexibility and continuous interaction to maximize the quality and the impact of Open Call results. The results also will feed into the technical specifications for the second open call.
What artifacts do you expect as outcomes of the project? Models, meta-models, descriptions, tools…?
The outcome ideally should be a combination of models, meta-models, description and tools.
Their step change will be demonstrated by pilot applications which will be built using the above outcomes.
What will the role of open call applicants be with respect to the RobMoSys goals?
The members of the core consortium are responsible for kick-starting all specifications of meta-models with concrete contents, motivations and documentation. They will develop and publish a “living on-line document” at the RobMoSys Wiki describing the methodology and the models; this document also offers a discussion infrastructure for the community. Similarly, the core consortium is in charge of the development of prototypical proof-of concept (PoC) software libraries and tooling.
The open call applicants are expected to contribute to, to extend, to improve and to use the models and tooling, to maximise the influx of knowledge and brains.
Their role is to identify the best tools already available, to adjust them, to validate the results in the best application areas and to establish benchmarks. They shall also assist in providing the access to integrated sets of common tool chains and real-world test installations to support the development of complex robotics systems.
What is an ITP?
An ITP, a so-called Integrated Technical Project, is a sub-project within the scope of the RobMoSys Integration Action, selected and contracted under an open-call in Instruments #1 and #2.
What is a RobMoSys ITP compared to a ROSIN ITP?
ROSIN (ROS-Industrial quality-assured robot software components) aims at enhancing the quality of ROS-Industrial, both the framework and its content, via continuous integration and code-testing in order to push robotics by broad availability of high-quality software.
RobMoSys (Composable Models and Software for Robotics) focuses on a model-driven and composition-oriented approach to system integration to establish a European robotics software ecosystem.
ROSIN aims to enhance the quality of existing software through software quality assurance, while RobMoSys addresses better quality of robotics software right from the beginning via providing adequate structures as a fundament that improve the quality and composability of building blocks.
How do I apply?
On https://robmosys.eu/open-call-2/, you find all necessary documents, like call text, guide for applicants, guide for evaluators and proposal templates, as well as the link to the proposal submission platform for the ongoing Open Call 2.
How is your tentative schedule for the open Call? When will we find out whether our proposal is accepted?
The first round of the Open Call 2 schedule will be the following:
- Opening 1st February 2019 – Closing 30th April 2019 (5 pm Brussels time).
- Evaluation & Physical panel meeting between May and July 2019.
- Results & Information to applicants in July / August 2019.
- Contract negotiation and signature in August 2019.
- Start of projects September 2019.
The (possible) second round of the Open Call 2 schedule will be the following:
- Opening 1st August 2019 – Closing 31st October 2019 (5 pm Brussels time).
- Evaluation & Physical panel meeting between November 2019 and January 2020.
- Results & Information to applicants in January / February 2020.
- Contract negotiation and signature in February 2020.
- Start of projects March 2020.
Note that second round may NOT be lunched due to high quality of proposals in the first round.
Second round does NOT concern Instrument #2.
What are the criteria for selection of proposals?
Proposal evaluation criteria for each Instrument are described in section 3 of the Guide for Evaluators.
Who will evaluate the proposals?
- In the Instruments #1 and #2 each proposal will be evaluated by at least two acknowledged evaluators with different expertise, for example in the technology field or in application area(s). External experts (independent of the RobMoSys consortium and of any proposer) as well as internal experts from the core consortium will be involved in the evaluation process.
- In the Instrument #3 proposals will be reviewed by RobMoSys core consortium.
More details on the evaluation process are described in section 2 of the Guide for Evaluators.
Is there any pre-proposal check?
As a special service to potential applicants, pre-proposals can be submitted via the RobMoSys Open Call Platform during the first eight weeks after publication of the call (so until March 31, 2019). A member of the staff of the RobMoSys Project will respond to applicants within a reasonable period (if longer than five business days, the applicants will be informed).
The response will be limited to clarifying whether the proposal fits into the scope of the call.
Please note that it is not mandatory to submit one and it has no influence on the evaluation of the full proposal. Pre-proposal should be based on the Proposal Template but Excellence and Impact sections are obligatory.
Which information do I have to submit for the pre-proposal check?
Pre-proposal should be based on the Proposal Template, but only Excellence and Impact sections are mandatory.
When is the deadline for the pre-proposal check?
Deadline for pre-proposal submission is March 31st, 2019, 17:00 Brussels time.
How are the contractual arrangements foreseen?
There will be a direct contract between CEA as coordinator of RobMoSys and the selected third party. A template funding agreement for all Instruments is provided below:
Please note that the rights and obligations contained in this Funding Agreement derived from the RobMoSys Grant Agreement and Consortium Agreement and consequently are not negotiable. Only content in Annex 1 content is negotiable.
How will the contract look like?
A template funding agreement for all Instruments is provided below:
Please note that the rights and obligations contained in this Funding Agreement derived from the RobMoSys Grant Agreement and Consortium Agreement and consequently are not negotiable. Only content in Annex 1 content is negotiable.
How is our Intellectual Property Rights protected?
Full open source contributions are preferred but not mandatory. However, we expect at least the models and their transformations to proprietary tools to be under an open source license that enables composability similar to proven platform projects like Eclipse.
The Intellectual Property Rights policy is part of the funding agreement between CEA and the third party. Please refer to paragraph 5 of the document below:
How much maximum funding can I apply for?
- In Instrument #1 the funding is limited to 60,000€ per proposal in total.
- In Instrument #2 the funding is limited to 300,000€ per proposal in total.
- In Instrument #3 the funding is limited to 20,000€ per proposal in total.
There are no restrictions regarding the number of proposals in which an entity can participate. Please note that the funding for the beneficiary (as defined by the EC) will not exceed 250,000€ (even if a party participates in more than one project; for both calls in total). Restriction of shifts between partners in an project concerning this matter will be part of the contract.
Do we need to apply for maximum funding in each Instrument?
The maximum indicated budgets are strict constraints.
They are high enough to give flexibility to also go for bigger efforts. However, you are not at all obliged to come up with a proposal just close to that maximum budget. There is no reason against going for a smaller activity.
Your proposal needs to fit to the instrument / topic and it needs to be convincing in terms of value for money. It can make perfect sense to go for less but be very focused! Better do a smaller thing excellent than doing nothing well of something too broad.
Will there be overheads?
- In the Instruments #1 and #2 indirect costs are eligible. You can add 25% of overheads to your direct costs. Please note that equipment costs are not eligible, all the necessary equipment (robotic platforms, etc.) are made available by third-parties themselves. The electronic tool in the open call submission platform will help you to properly calculate your budget.
- In the Instrument #3 only the direct cost are funded (no indirect costs).
Will we receive pre-payments?
- In the Instruments #1, #2 and #3 third parties can receive pre-financing of up to 40%.
How is the payment schedule? How are payment triggered?
Third-party beneficiaries will receive their payments according to the following schedule:
- One pre-financing payment of 40% of the funding, within 30 days from the entry into force of the ITP agreement;
- Instrument #2 receives an interim payment of 40% of the funding, within 60 days from receiving an ITP progress report,
- Final balancing payment of all the funding, not exceeding the initial budget, within 60 days from receiving the final ITP report.
How to track whether deliverables are fulfilling required qualities?
We are working with a traffic light system on the monitoring platform to visualize whether you are on track or further improvements are deemed necessary. This usually should be done within 2 weeks after submission of a deliverable / milestone.
How will the Key Performance Indicators be defined, after which the quality of results is rated?
- In the Instruments #1 and #2 the ITP proposals suggest a limited but sharp set of individual KPIs, these KPIs will be fine-tuned during the preparation of the contract.
- There are no KPIs required in the Instrument #3.
How long will payments take?
Payment process might take up to four weeks.
Funding constraints between the two calls: Is 250k€ the maximum by partner for the 2 calls?
Yes, the funding constraint of € 250.000 per entity (PIC) is valid for the sum of the two calls. So if you plan to have a follow-up proposal in the second call, you should not use your full budget already in the first call.
The entity is identified by the PIC, thus the funding constraint of € 250.000 for large institutions, like e.g. Fraunhofer, is summed up for all sub-entities (institutes).
Where (in which section) of the proposal template should one include the financial details (e.g. person months / costs, travel costs, overall planned budget...)?
For the proposal, a budget calculation form is included in the open call platform. Please enter your figures there. Once you select an institution, the budget section is available to fill. And there is a budget subsection per institution added.
In Instrument #2 it is important that you select if your institution is for profit (70%) or non-for-profit (100%).
After submission, you will receive by email an excel sheet with the proposed budget (for your own records). There is no need to include the budget information in the proposal template.
For the pre-proposal, it is not necessary to include the budget.
Do we really need to form a consortium or tandem?
- In the Instrument #1 the single entities (1 partner + subcontractor(s) when reasonable) are expected.
- In the Instrument #2 RobMoSys is looking for experiments which will be realized in a joint effort by preferably at least two partners offering complementary, multi-disciplinary competences that go beyond the mainstream robotics community; for example, robotics experts teaming up with software engineering people, or tool builders, or experts from automotive, aerospace, embedded, cyber physical systems. If your organisation is large enough to cover this mix of competences internally, this is sufficient.
- In the Instrument #3 the entities employing experts with a background which is relevant for the project are welcome.
Who to tandem with?
The Instrument #2 of the Second Call welcomes consortia offering complementary, multi-disciplinary competences that go beyond the mainstream robotics community; for example, robotics experts teaming up with software engineering people, or tool builders, or experts from automotive, aerospace, embedded cyber physical systems.
RobMoSys is offering another Information Day on April 12, 2019 to find an appropriate partner for your idea. Moreover, we also offer an online tool for finding tandem partners on our website (please note that you need to register yourself in order to access full information on the profiles).
Can I team up with a partner of the RobMoSys core consortium?
No, this is not possible. Consortium partners cannot be beneficiaries of third party funding. But there will have a set of Inter-project meetings to have a proper exchange between the ITPs and the core team.
Do we need to find a partner from a different country, or is it possible to go with a purely national consortium?
There is no criterion to form multi-national consortia. In the framework of RobMoSys ITPs, you can opt for mono-national consortia without reducing your chances to get selected.
Could I also team up with an institution outside Europe?
Horizon 2020 is open to the world, and this is also valid for the RobMoSys Open Call. Partners from outside Europe can fully contribute to and benefit from Europe’s research and innovation capacity, but will need to cover their participation costs in RobMoSys with their own funds.
I am working for the same university as one of the consortium partners, but in another department. Can I apply for an ITP?
No, this would result in a situation with conflict of interest for reasons involving economic interest, political or national affinity, family or emotional ties or any other shared interest. Therefore, those beneficiaries cannot apply.
Other entities who have some link (loose or not) to core consortium partners can apply. We will make sure that the evaluation process is completely independent and none of the above situations with conflict of interest will occur.
Do you require industry to be represented in the team?
- The Instrument #1 is designed for SMEs and small teams in large industrial companies.
- In the Instrument #2 the industry representation in your team is highly welcome, however it is no prerequisite for a successful proposal. Evaluation is based on whether all required competences are represented in the team. Moreover, it is important to demonstrate usability in real-world scenarios and the industry-grade quality of their realisation.
Do we need to bring an end-user in the consortium?
No, there is no requirement to have an end-user in the consortium and having and end-user in your consortium does not automatically increase the chances that your proposal is accepted. What is most relevant is that you have all relevant competences represented in your team.
Do the projects need to be real life examples?
- In the Instrument #1 the funded ITPs must develop RobMoSys-conformant pilots (industrial case studies) based on existing assets (software and tools from the RobMoSys ecosystem), or provide software components conformant to the RobMoSys pilots.
- In the Instrument #2 we are looking for profound developments on the RobMoSys baseline (models, tools, components, patterns). Therefore, real life examples are not mandatory, but they can be of relevance for the Impact evaluation criterion.
Can you narrow the scope a bit, in order to increase the impact in “wow” application?
We prefer projects that illustrate their contribution in the domain of robot-centric motion, navigation and manipulation.
Do you consider autonomous driving as part of robotics?
It is part of the robotics domain, but RobMoSys is not focusing on autonomous driving as application domain. Of course, all platform-level aspects are, such as the motion stack and information and software architectures.
Nevertheless, outcomes of RobMoSys are expected to be of high relevance for autonomous driving as well as we consider input from the automotive domain being of high relevance for robotics. The contributions need to make a difference in robotics in general and should not be specialized to autonomous driving.
For a space robotics scenario: Is it relevant considering that building blocks could be reused in civilian applications?
We see no difference in the “platform” between application of it in space contexts or other contexts. Adequateness in any means with respect to civilian applications is thus relevant (solutions for space robotics applications are typically not affordable for civilian applications).
RobMoSys does not address [please enter your subject here], but this is absolutely required to reach what RobMoSys is aiming for!
If you think something is missing, this is your reason and driver to get involved! Please note that half of the project budget is dedicated to third party projects. The development of the RobMoSys ecosystem is clearly a community effort. We are looking forward to your proposal responding to that need addressed.
Do you expect a huge oversubscription? Do I increase my chances by submitting several proposals with different scopes?
We strongly advise you to focus on the quality of a single proposal rather than to submit a series of proposals with different scopes. Please keep in mind that your maximum funding is fixed over all submissions. In case more than one of your proposals were to be selected, you would have to withdraw from your other partners.
Can you make your pilots accessible?
Yes, the pilots can be provided to project contributors to support designing, developing, testing, benchmarking and demonstrating their contribution.
For more details please see the available pilot skeletons.
Moreover, we are able to offer the services and equipment of the Robotics Innovation Facilities (RIF Paris-Saclay, CEA) and Centres of Competence (CoC in Munich, TUM) to stimulate the developments coordinated by the project.
What pilots do you foresee? Can we know more about the pilots?
Pilots span different domains and different kind of applications (and hence requirements), centred around the core applications of “navigation” and “(mobile) manipulation”. We as core consortium provides a set of concrete Pilot applications to kick-start implementations. Find out more about these pilots at www.robmosys.eu/pilots and in the technical wiki at http://robmosys.eu/wiki/pilots:start.
Can I trust that RobMoSys delivers the structures, tools and components I need?
RobMoSys is a joint effort with close involvement of the robotics community to ensure delivery of adequate structures and supporting tools. The RobMoSys core consortium therefore needs your input and contributions! RobMoSys needs the support of the robotics community to identify and realize the necessary structures to enable composition in a robotics ecosystem. We have funding to do so in Open Calls.
Delivering components that can be composed to systems is not the main aim of RobMoSys. The aim of RobMoSys is to provide structures and tools such that these components can be supplied and composed in an ecosystem.
Check our basic commercial User stories , the technical user stories in our wiki as well as Composition in an Ecosystem.
The core concepts are already now usable. A tooling baseline also is already provided.
Please also refer to the technical FAQ for an answer to the question “When will RobMoSys be ready to use?“
What happens if information in the wiki is changed over the runtime of my project?
During the project runtime, snapshots of the wiki are taken to freeze it. The snapshots provide a stable reference to use in project proposals. The contractual agreement will be based on these snapshots.
Nevertheless, we of course encourage you to trace the updates in the live Wiki for selected pages of your interest (an updated changelog helps you easily finding new contents).
Can I rely on agreements during the contract negotiation phase, or will you change tooling etc. during my project runtime?
The contractual agreement will be based on static wiki snapshots that you can rely on. If tooling is adapted during the runtime of your project, you are free to adapt to it, but you are not obliged to do so.
Are the inter-project meetings open to outsiders? Can I participate at those meetings even if my proposal does not get accepted?
We are currently investigation the options to combine the Inter ITP workshops with a Summer School (or Spring School) and to thus make them also accessible to interested “outsiders” that want to follow and contribute to the RobMoSys approach without being “officially” involved.
We will also continue to organize open workshops (e.g. at ERF) and presentations (e.g.at automatica and international conferences).
The RobMoSys website and newsletters will keep you posted.
I have a question that is not answered in your FAQs. What can I do?
Please send your question to opencalls@robmosys.eu. We are obliged to handle all questions related to the open calls through our ticketing system in order to comply with the obligations from the European Commission for a closed loop. We will make sure that your request is addressed to the appropriate person and answered in a reasonable time frame.
Will you publish all questions from the open call platform in the FAQ?
More general questions that could be of overall interest will be published in the FAQ section. If you have more in-depth technical or scientific questions that might even be related to a concrete project idea, we will keep it confidential, of course.
Can you summarize in a few sentences what the focus of Open Call 2 is?
- Open Call 2 focuses on the link between component level and system level.
- We want to introduce engineering principles for putting together and configuring components to complex systems. We want to get quick answers to what-if questions without building all the different versions and trying them out. We want to understand the outcome of different combinations in order to decide for the one best fitting our needs. When we then decide for one version and build it, we expect to get exactly what we predicted.
- We want to illustrate the advantages of the RobMoSys approach in very concrete examples for which the pilots provide a baseline.
Do you have examples of what kind of system level challenges you mean?
- There are the still-up-to-date technical user stories
- We also have examples in our slides, for example:
Info and Brokerage Day Munich, 13.02.2019
“Achievements_Munich Infoday 2019” / slide 5 - The topics in Instrument #2 (see Annex 2 to Guide for Applicants) reflect these system level challenges
We want to observe and collect system level properties and make them accessible. Why are you not that enthusiastic about that? It is at the system level?
Building an economically feasible robot application requires to fulfill its requirements by a proper selection, combination and finally configuration of existing building blocks. We thus are in need to make sure that properties are explicated, that we trade off them and that we finally make sure that these properties end up in the system. So it is much about putting the wanted properties into place in the system. Just observing, collecting, monitoring is not enough as putting the properties into place by the system builder is a requirement.
What do you mean by linking different levels? You stress very often that just remaining within one level is not sufficient?
You always need to show how you concretely link to the lower level. Just stating that you abstract from the lower level, then do something on that abstracted level and then forget about how you bring that back to the lower level is not sufficient. For example, you can easily reason at an abstract level about whether the resource reservations are free of conflict, but we want to see that the result ends up in a proper configuration of the concrete components.
Is symbolic planning, artificial intelligence, learning in the scope of Open Call 2?
- It is not in the scope of Open Call 2 when their use does not come with a clear benefit for system level engineering or when they do not come with a clear benefit for systems at run-time. For example, just linking symbolic planning to robot skills is not enough as there are already examples for interfacing and linking symbolic planners with the task sequencing layer. Indeed, it would make a difference when you could deal better with resource share reservations and resource consistencies. However, this then is not only about symbolic planning, but a lot more about the link between the lower levels (skills, configurations, sequencing layer), the world models, the self-model etc.
- Think very concretely of supporting the system builder in doing his / her complex job and how you can assist the system builder by reducing his / her cognitive load via tool support. A very concrete example is the management of dependency graphs via constraints and the proper tracing of their fulfillment etc. See the topics in Instrument #2 (see Annex 2 to the Guide for Applicants) and check whether and where using so-called AI methods might help.
We have a tool and want to align that to the RobMoSys structures. Where does this fit into Open Call 2?
- Of course, we welcome all kinds of tools to become conformant to RobMoSys. A broad variety of tools being conformant to RobMoSys and populating the ecosystem is highly welcome and needed.
- Nevertheless, just advancing a particular tool to become RobMoSys conformant is not enough in Instrument #2 as we are seeking for added value with respect to system level composition. You also need to carefully consider what is already covered and where are white spots.
- We consider Instrument #3 the best one for such a kind of activity as instrument 3 brings together different communities and you can serve as an ambassador. It can also fit into Instrument #1 depending on the scope of demonstrations.
Eclipse is part of your project and you promote the format of an Eclipse project as a means to publish RobMoSys outcomes. What does that mean?
- Stay tuned, more to come soon!
- Basically, the RobMoSys consortium is working on a sustainability roadmap for the RobMoSys body-of-knowledge. We are in the duty to ensure that the body-of-knowledge represented within the RobMoSys community keeps maintained, advanced, moderated, freely accessible beyond the runtime of the RobMoSys funding period.
- This is independent from the different tools that support the RobMoSys approach. For a software tool using Eclipse it might make perfect sense to become hosted as an Eclipse project. That tool then needs to express its coverage of RobMoSys structures and the conformity level of these coverages but remains independent. It will be linked from RobMoSys to become visible as part of the RobMoSys ecosystem.
Does everything need to be Open Source?
- No, not at all! It is not a problem at all to build proprietary components which conform to the RobMoSys ecosystem. For example, you can do that by using the Open Source SmartMDSD toolchain with its plug-ins which supports you in achieving conformance to RobMoSys. You can also use the Papyrus toolchain with its plug-ins to support you in achieving RobMoSys conformance.
- The RobMoSys consortium ensures that the structures shaping the RobMoSys ecosystem are open and freely accessible as this is necessary to be able to become part of that ecosystem. We also try to ensure that tooling like SmartMDSD is always mature enough and freely available “as is” to ensure access to the RobMoSys ecosystem. This is not in conflict with hopefully upcoming commercial tools which conform to RobMoSys and which then might provide help desks etc.
How do the different tools fit together?
- There will always be different tools supporting different aspects of the full RobMoSys ecosystem and not just one single tool covering everything. Thus, it is important that every tool expresses its coverage of RobMoSys structures and the conformity level of these coverages. RobMoSys already now comprises different tools with different coverage, with tools even coming already from ITPs. For example, the RobMoSys concept of a digital datasheet ensures the handover between different tools at dedicated stages in the engineering process and between dedicated roles involved in the overall lifecycle of a robotics system.
- We do not aim for such tooling interoperability that you can switch to another RobMoSys conformant tool at any time you want to. Instead, with a RobMoSys conformant tool, you take the artefacts from the ecosystem, do your role specific work and put back the resulting artefacts to the ecosystem. These can then be used by other RobMoSys conformant tools.
I want to illustrate my contributions via ROS
- RobMoSys does not just aim for modeling but foremost for achieving composition. Thus, the semantics of the RobMoSys structures play a major role. We want you to connect to the RobMoSys structures and their semantics. Of course, this includes using the available RobMoSys conformant software baseline. We do not want you to go for a shortcut to a particular software implementation circumventing the RobMoSys structures and implementations without a need. So we strongly encourage you to use the RobMoSys software component model with its managed tasks, services, configurations, parameterizations etc.
- We aim for laying the foundations for proper engineering principles for complex software systems for robotics which are aligned with the needs of business ecosystems, foremost separation of roles. For this, we identify and explicate most advanced structures as enablers for this step change. We make those available via a model-driven approach and consistently usable via model-driven tooling which, of course, comes with concrete software code bases including middlewares etc.
- Do not be afraid of starting from scratch and losing your background when you do not code or model directly against ROS. With RobMoSys tooling, you work with software components at a level where you code them agnostic to the underlying software stacks and RobMoSys provides a mature ready-to-use baseline to start with. RobMoSys assists you by coaching, by tutorials and by workshops. Just talk to the ITPs of the first open call when you want to learn about coaching.
- We aim for introducing the advanced RobMoSys structures into the continuous and ongoing effort of the ROS 2 community. For this, we are seeking for an explicit link between RobMoSys and ROS 2, see topic 1 of instrument 2 (see Annex 2 to the Guide for Applicants) and its detailed description. Exactly for the reasons which initiated the advancement from ROS 1 to ROS 2, it makes no sense at all to map the advanced RobMoSys architectural patterns onto ROS 1. However, we offer a mixed port component which allows you to still use your legacy and link it to a RobMoSys based system. See also the requirements in Instrument #1 to come up with at least two RobMoSys components.
- See the following web page for details
– pilots,
– tutorial.
Do you have an adoption / migration path?
- Yes, please see Annex 1 to the Guide for Applicants.
- You can already now link your ROS 1 system to RobMoSys via the RobMoSys mixed port component. By this, you can already now use the advanced RobMoSys structures with their benefits without redoing everything. See for this the hints on the mixed port component, the baseline of the pilots etc.
- The same holds true for YARP systems. You can already now link these as well with the RobMoSys world.
- The mixed port component is also a central concept used in the SeRoNet project which conforms to RobMoSys. SeRoNet focuses on OPC UA and on linking different worlds via mixed port components, including ROS.
Why do you not just model ROS 1 and provide model-driven tooling for it?
Because just modeling ROS 1 concepts does not introduce the composition structures which enable the system level benefits envisioned by RobMoSys. The reasons for not going directly to ROS 1 are exactly the same as is the motivation for going from ROS 1 towards ROS 2. Nevertheless, the mixed port component allows mutual access between ROS 1 and RobMoSys systems without causing interference between their configurations, their resources, their coordination etc.
There are activities of doing that in a RobMoSys conformant way funded by ROSIN project (ROS-mdd), see also the SeRoNet project.
Why do you not just model ROS 2 and provide model-driven tooling for it?
ROS 2 provides much better opportunities to take up the RobMoSys structures with their benefits when going its next rounds. However, RobMoSys still is on advanced and consistent concepts that can be mapped onto many different implementations. See topic 1 in Instrument #2 in Annex 2 to the Guide for Applicants for this.
Do I need to write all the device drivers from scratch again when I use RobMoSys?
- No, via the mixed port component, you can easily reuse a lot of drivers from others. Furthermore, many drivers are already available.
- For the future, we envision that device drivers are not an issue anymore with the introduction of OPC UA. See link below:
– Composing a System with OPC UA Mixed-Port Components,
– Accessing an OPC UA Device.
Does wrapping “MoveIt” into a RobMoSys set of components fit into Open Call 2?
- Yes, of course! We want to get most out of existing robotics software / libraries. For this, they need to be provided / accessible via RobMoSys software components. This then allows to take advantage from RobMoSys system level composition etc.
- Depending on the level of take-up of RobMoSys structures, either Instrument #1 (just linking via the mixed port component, wrapping by a RobMoSys component) or Instrument #2 (splitting up into RobMoSys components with RobMoSys conformant services, aligning robot model representations to RobMoSys, etc.) is the right one. Even Instrument #3 can fit for a core developer of MoveIt.
I want to link OPC UA and ROS via RobMoSys. How to do that?
- Please carefully check the detailed description of topic 6 in Instrument #2 (see Annex 2 to the Guide for Applicants).
- Please also carefully check what is already available on OPC UA in our wiki (section OPC UA, Mixed Port, SeRoNet).
I have a particular device (mobile platform, manipulator, etc.) and want to make it accessible via the RobMoSys world. Which instrument do you foresee for this?
- Have a careful look at Instrument #1 but be careful. It is not enough to just provide a device driver component to have your platform also available in the ecosystem of RobMoSys. You need to go for a system level example using the RobMoSys components and the RobMoSys composition to come up with a full system where we can illustrate the benefits of the RobMoSys approach. Otherwise, it would just remain at a “me too” level.
- You can also have a careful look at Instrument #3. This is of interest when you link by your platform the RobMoSys world with a completely different world and then serve by your expertise, by your setting etc. for a mutual exchange, cross-links and benefits.
There are more frequently asked questions related to technical aspects, like the following
- When will RobMoSys be ready to use?
- Does providing a model for my building block mean that I have to expose all my IP in that model?
- The RobMoSys structures seem to be complex. What’s in for me as a user?
- Where can I find the RobMoSys metamodel?
- What is a component in RobMoSys?
- What is the difference between composition and integration?
- I am a system integrator; where to start?
- I am a technology provider; where to start?
- I am a tooling provider; where to start?
- I am new to MDSE, DSLs, and modeling. Where can I read about it?
- Can I use RobMoSys with <insert robotics framework here>?
- ROS is in very widespread use; why does RobMoSys not build upon ROS?
You can find more questions and the related answers in our wiki at http://robmosys.eu/wiki/faq.
Please subscribe to our newsletter to get information on important updates.