Forgive me if I’m late on the game on this. But were there discussions in the past about how to proceed with Rviz in ROS2? I tried Googling around to see if there were past discussions about breaking from Ogre in an Rviz rewrite but I haven’t found anything. Any insight or pointers would be welcome.
I’m mostly curious as to why it seems that rviz is being rewritten again using Ogre (at least it appears) and QT, rather than let’s say Unreal, which is largely OS independent and already supports QT/OGRE combined functionality in a supported framework. But unreal also supports AR and VR tools along with many other widgets and plugins. I realize Unreal has a custom license based on a royalty for commercial applications (they assume games), but they will customize that individually, and might provide a ROS community license if it’s in their interest to move into a new domain?
I’m not trying to stir up trouble, I’m just curious, as my company desperately needs a fully functional Rviz replacement to move our commercial manipulation stack to ROS2 (which would hopefully then be released publicly as a ROS2 alternative to MoveIt!). As of now, I either need to wait on Rviz development for ROS2 to get to the ROS1 level of functionality (waiting is not really an option for my customers) or write something myself. In thinking about forking/writing Rviz functionality myself , it seemed odd that the new Rviz would not have had some documented discussions on whether to use a newer framework other than Ogre that facilitated faster development and easier cross platform deployment.
That issue needs to be updated (it’s on my todo list), but since we were not planning on a “from scratch” rewrite of rviz, I decided to stick with Ogre, since none of the other options gave us much immediate benefit (from my perspective) and I estimated that it was a lot of work to replace Ogre.
What we did do during the port of rviz for ROS 2 (here: https://github.com/ros2/rviz) is we tried to abstract all calls to Ogre behind one rviz API or another, so that in the future we could hopefully replace Ogre with a newer version of Ogre or some other toolkit.
I say “tried” because there were some quite deep integrations with Ogre, especially in the selection tools and interactive markers, and also many of the third-party displays also use Ogre directly. So some things have been abstracted, but others were deemed too complicated to do for now. So if we wanted to remove Ogre, then we’d have to first finish those abstractions or rewrite the non-abstracted code in the new system.
Sure I understand the desire to not want to rewrite from scratch. Let me state the other side as I see it. If you were to redo Rviz using three.js or Babylon.js, then you eliminate any need for third party apps as a browser becomes your 3D rendering environment. Of course adding plugins and other Qt-style
Menus means people have to write Web apps, but In some sense that’s easier for certain individuals. Also, the open source communities behind these webgl platforms is large so perhaps it might spur more outside (of OSRF) development from people that are intimidated by Rviz.
I realize that I have changed from the original Unreal/Unity approach I mentioned at the start of this thread to a webgl approach, but this is in response to any licensing issues with Unity or Unreal (though for free/open source, I don’t see any real challenges with Unreal or Unity either).
I realize that bringing these issues up now (rather than a year ago) might not be helpful, but we are trying to plan how to make th Ros2 jump in the near future without the Interactive Markers and other Rviz tools that our navigation and manipulation frameworks are built on top of. We need to replace those with something.
A complete rewrite is rarely a good idea. If you want a web-based RViz then just write a new one, no need to throw away everything that has been developed in the last 10 years.
I also don’t think that web apps are the solution for everything. From my personal experience, I can say they are a lot harder to develop for non-web-developers than Qt/C++ or Qt/Python applications. As ROS is used quite a lot in academics and starting to get used in the industry, where Qt is the dominating GUI framework, I would not like the decision to move to the web.
However, I agree that Ogre is not perfect. three.js, for example, could also be used in combination with Qt. Did you know that the Qt guys are already working on several methods to support web browsers? If that is what you are looking for google Qt WebGL rendering and Qt WebAssembly.
Well, we can have a quite deep discussion about the reasons for using Qt compared to web applications here, but I don’t think they would lead to something. My personal preference is Qt because I work on industrial HMIs, if you work on something more consumer-focused then probably web apps would be your choice, long-term support and consistency are key in industrial environments.
Unity or Unreal are probably not a good fit for an open source software project altogether. But I may be wrong here.
Actually both Unreal and Unity would be unsuitable for rviz in my opinion (and unnecessarily sophisticated). Unity is not open source, and a that’s deal breaker for us, since we want a fully open source stack for our user space software. And Unreal because even though it claims open source, they have restrictions on distribution of source and binaries (no matching OSI license for that), as well as commercial use and would potentially prevent someone from producing a product with rviz embedded without needing to pay royalties or something. And that’s a feature of the BSD license we’ve chosen and want to preserve.
I did consider VTK and Qt3D, however. I think both are in the right range of compromise: open source, easier to use than plain OpenGL, not a full blown game engine (we don’t need to simulate water or physics in rviz, perhaps Gazebo but not rviz).
Any ways we’ve had that discussion on the rviz issue. Ogre is still ok for now (I’m not sure what limitations it has that rviz needs to overcome), my biggest concern for Ogre 1.x is support lifetime since the main Ogre team has moved on to Vulcan/Metal based Ogre 2.x. But that’s why I started abstracting in the ROS 2 work.
If you want a web based solution, there can be both, and there is. You could consider porting robot web tools (http://robotwebtools.org/tools.html), which had a rviz clone called visualization_rwt I think. OSRF doesn’t have to initiate every project that’s possible . I think a web based solution will not replace the desktop application written in C++ (for now) since performance is a key feature of rviz (not saying 3d is slow in the browser, but pub/sub, serialization, and transforms have been issues for rwt in the past due to JS being slow). Maybe with enhancements to the WebAssembly sandbox it might be possible at some point to replace the desktop app. But that’s too risky to try instead of porting the existing rviz right now. If we had more resources I’d definitely love to try.
Your absolute quickest and least effort option for that is to contribute to the rviz2 port. It has everything ported except some of the displays, and the effort of porting most displays is relatively low. Interactive markers might be a more considerable amount of work, but there’s no other option that would be less work in my opinion.
I guess it depends on your use case, but I don’t have any issues with Qt productivity wise, and it seems like a good option (not sure what your particular issues with it are). It also just got an ISO 26262 option for those industrial users who need that sort of thing and are willing to pay for it:
. I think a web based solution will not replace the desktop application written in C++ (for now) since performance is a key feature of rviz (not saying 3d is slow in the browser, but pub/sub, serialization, and transforms have been issues for rwt in the past due to JS being slow). Maybe with enhancements to the WebAssembly sandbox it might be possible at some point to replace the desktop app. But that’s too risky to try instead of porting the existing rviz right now. If we had more resources I’d definitely love to try.