{rolling} WIP: Enable ROS Visualization tools

[robwoolley]

This fixes longstanding issues preventing Gazebo/Ignition and RViz2 from building with meta-ros.

This includes work to resolve Ogre-Next, PyQt5, and SIP.

This is a work-in-progress and is not yet completed. It is being shared for feedback and for others that wish to help contribute to fixing bugs or doing testing.

[graceagrace]

Is this currently building/working? I see you have a separate PR open for ROS2 Humble + kirkstone support. How does this one differ? Can this be built against scarthgap?

[robwoolley]

Is this currently building/working? I see you have a separate PR open for ROS2 Humble + kirkstone support. How does this one differ? Can this be built against scarthgap?

Hi @graceagrace, they are both works-in-progress (WIP). I was sharing them with others in the hopes to get some help finishing it off. All the recipes were building, but some projects have optional dependencies that aren't satisfied yet. Notably, things like the ogre 3d engine which have support for different image libraries and plugins. I also didn't get to doing rigorous run-time testing however I did hear that some others were successful in running the GUIs.

The main difference between the two is that the older Yocto release uses sip v4 to generate the Qt Python bindings whereas the newer release uses sip v6 (see https://layers.openembedded.org/layerindex/recipe/332209/ ). This essentially doubled the effort. The newer Yocto release also uses gcc13 so at the time I was having to fix a lot of new C++ warnings in the compiler that hadn't been completely addressed yet by the upstream projects.

[graceagrace]

@robwoolley, thanks very much for the detailed reply. I am working on an image for developers that requires RVIZ and some Gazebo plugins. I plan to do a fair bit of runtime testing, so I'll certainly report back with any findings/additional patches required.

Is there a certain state you'd like to get this to before you would feel comfortable merging? Is it taking care of the optional deps, or something else?

[robwoolley]

Is there a certain state you'd like to get this to before you would feel comfortable merging? Is it taking care of the optional deps, or something else?

I would be happy with confirmation that someone built it and ran it. I think it is more important to get it in to avoid bit rot and allow others to pitch in to fix it. It should only be built by request so it shouldn't block anyone else.

You probably need this fix in order for it to work: robwoolley/meta-openembedded@3c4c1e8

I will try to find some time to push that to meta-openembedded soon.

[graceagrace]

Hi @robwoolley,

Some good news - I got all packages building and got RVIZ running with the scarthgap + humble combination. I made my own fork of meta-ros here, with branch feature/enable-viz-tools-humble-scarthgap - I essentially merged your branch into scarthgap and tested builds from there. I believe most of our content is the same - it's hard to do a real diff since it's been some time since your branch had scarthgap merged in. I for sure had to make an additional patch to rviz-rendering to resolve a runtime error with the OGRE RenderSystem_GL plugin.

I also made a fork to meta-qt5 here, with branch feature/enable-viz-tools-humble-scarthgap. I split the python3-pyqt5 target and native recipes, similar to what you did on the kirkstone branch of meta-qt5.

I'm very excited to see this working, though! My target setup is essentially qemux86_64 - I built an OCI image with ros-core and rviz2 and ran it using Podman. Have not tested on an ARM machine, yet, because I don't typically use viz tools on deployment targets.

All this to say - I think your PR is good to merge. I need to clean up my commit history quite a bit, as I had some false starts and went down a few debugging rabbit holes for that OGRE runtime issue, but I'd be happy to put in a PR with my humble-specific changes afterwards. Looking forward to hearing your thoughts.

EDIT: Also worth noting are my local.conf settings:
DISTRO_FEATURES:append = " x11 opengl vulkan polkit"
PACKAGECONFIG:append:pn-clang = " libomp"
PACKAGECONFIG:append:pn-python3 = " tk"
PACKAGECONFIG:append:pn-qtbase = " fontconfig"
PACKAGECONFIG:append:pn-qtbase-native = " openssl gui"

[robwoolley]

@graceagrace This is fantastic! Thank you so much for confirming that this works and sharing the screenshot. I included it as part of the working group minutes in today's meeting: https://docs.google.com/document/d/1LqUjcu6vdlqVJO62SreCyjzddNDZhfO2n-7qYghY_cQ/edit?tab=t.0

FYI, I submitted the python split changes to meta-qt5 last week. I am hoping they get merged in soon: meta-qt5/meta-qt5#588

I'll try to find some time to revise my earlier patches and add your fixes to the series. I look forward to adding your patches as I got exhausted from trying to track down all the missing dependencies myself.

[graceagrace]

@robwoolley, sounds great! I'd be happy to know any feedback/suggested changes to my patches. In particular, my patch to rviz-rendering is a bit heavy-handed, I think (replacing a hard-coded path with another hard-coded path), but it's a consequence of RVIZ vendoring OGRE instead of using the system installation.

Glad to hear you submitted the appropriate changes to meta-qt5 - thanks for doing that. And thanks for your continued support of the community!

[robwoolley]

Merged into master. Here are the steps to build successfully:

# Follow the instructions on using kas in the build branch
kas shell meta-ros/kas/oeros-master-rolling-raspberrypi5.yml:meta-ros/kas/visualization.yml

cd ../layers/meta-ros
git checkout master-next
cd ../meta-qt5

# Cherry pick my PRs on GitHub: https://github.com/meta-qt5/meta-qt5/pulls

cd $BUILDDIR
bitbake --continue desktop-full 

All the variants should now work: ros-core, ros-base, perception, simulation, desktop, and desktop-full

Each builds on the previous variant with desktop-full as the superset of them all