ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Comepetion run by Sellafield: Standardised robotic control architecture for Sellafield

“Sellafield are seeking to move towards a robot control system that can provide a modularised ‘plug-and play’ hardware reconfiguration solution”

After reading the challenge statement it sounds like ROS2 overcomes all of these challenges.

What are your thoughts on Sellafield pursuing a new framework instead of using ROS2, which seems to meet their requirements?

Could ROS Industrial enter this competition?


Unfortunately, this opportunity is now closed. But I do believe ROS 2 is the correct technology for their technology.

they gave an online presentation a few weeks ago in which they stated quite literally that for this one they wouldn’t consider any ros-based solution. I think they were trying to find out what else is on the market.


There is a more complete video presentation of what Sellafield is looking for. The video (( starting at 19:06 where their software engineer lays out “doesn’t ROS solve all of this?” gets into some of the critiques we have heard from end-users that really just want something easier to use from non-CS folks. I believe there is a pathway to get to this vision, and you will note in the presentation, and I grabbed the screenshot that shows this, they will consider ROS-based solutions if you can address some of the reconfigurability/sustainability questions they raise.

Pretty interesting and never bad to see what else is out there. I think this puts out a good use case for ROS-I/ROS2 demonstration systems to highlight this type of functionality with low-tech-skill staff.

Matt R.
ROS-I Americas program manager


@mrobinson, i think you are dead right. Demonstration system are a requirement. Coming from a Nuclear robotics background they want something with the functionality of ROS-2 with an operator focussed user-interface.
They also dont want or need complexity in that UI, mostly they want relaible looking (windows 95 era looking) button based UI that can make the robots respond in an expected fashion.
They would also feel very comforted from a very clear concise node diagram showing live node state.

However, i don’t think their analysis of ROS is entirely fair in this, but it is a presentation issue.

1 Like

Man, I despise this line of thinking in industry, “ROS doesn’t have my particular feature set RIGHT NOW so we need a wholly different solution.” There is also the classic, “ROS is hard for us to use, so we’ll just roll our own so we can create our own custom UI tools.” The “versioned software is bad” part is particularly scary; essentially what they are saying is they don’t patch software at a nuclear power plant. Similarly, they have issues with strong typing which is usually a mechanism to improve reliability. This might a good use case for the QAWG to discuss.


Just out of curiosity, are there any great UI tools available for ROS?

I’ve been told that ignition rviz is great and everyone should be contributing to fleshing it out

1 Like

While I don’t like it either, over the years I’ve come to understand this: consider having a need (whether your own or a client’s) and analysing potential technology to cover that requirement/fill the need.

If you’re looking to acquire technology or base your product on something for the long term, a traditional matrix based evaluation approach typically doesn’t have a column for “could be used if we spend 6 months developing base feature X”, nor a column for “might get this depending on community contributions and/or time in the schedule of the maintainer/developer”.

With quite a few alternative (competing?) technology stacks on the commercial/closed source side (perhaps not for this particular set of requirements, or with a hefty price-tag), and a bunch of other non-functional-requirements (such as the ones mentioned by @mrobinson (ie: licensing, maintenance, operator UX, deployment, integration with existing infrastructure/technology)), is it so strange for companies to make the choice to not use ROS?

IMO, the main difference between commercial software and open-source software in this sort of context:

  • in OSS, a missing feature presents an opportunity to contribute
  • in any other case, a missing feature is reason for dismissal/looking for alternatives

If, as a company, I’m not looking to contribute or become part of an OSS community, why would I consider missing features a feature?

1 Like

I can tell you that no nuclear power plant would pass modern regulatory certification without a policy on software version management. Alas, most nuclear power plants are certified under ancient regimes.

It is not quite that, it is that they want to control version release cycle, not realising that open source can allow that, and can allow them to patch out or remove any functionality they find problematic.

I also fear there is a risk it is a classic “it is easier to write than read” problem.