Support ROS 2 Jazzy / Ubuntu 24.04

[sea-bass]

This PR switches to use ROS (not OSRF) Docker images and also adds Jazzy support now that it's out.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
__init__.py	0	0	100%
core
__init__.py	9	0	100%
dynamics.py	43	0	100%
gazebo.py	136	8	94%	55, 124, 230, 244–248
hallway.py	73	10	86%	59, 61, 63, 96, 158, 196–199, 205
locations.py	126	21	83%	53, 55, 69, 84–85, 87, 98–99, 101–102, 119, 177, 192, 217, 227, 273, 284–285, 287–288, 312
objects.py	69	4	94%	78, 106, 137, 197
robot.py	214	58	72%	140–141, 203, 216, 263, 277–278, 282, 286, 292–293, 295–296, 313–314, 342, 344–345, 366–367, 370–373, 376–378, 403, 407–409, 411, 413–416, 429–431, 435, 437–439, 441, 444–445, 448, 470–471, 479, 484–489, 492, 505
room.py	48	1	97%	113
world.py	571	138	75%	146–147, 183–184, 188, 241–242, 244–245, 273–274, 325, 339–340, 342–343, 372–376, 378–380, 382–383, 386, 390–394, 397–399, 402–409, 440, 476–477, 480, 496, 526–527, 538, 541, 563–567, 569–571, 574–575, 578–581, 583, 586, 588–590, 592–594, 596, 615, 625–629, 664–665, 668–671, 688–689, 695–696, 698–699, 701, 703–704, 706, 708–709, 719–720, 723, 725, 739, 741, 748, 795, 826–827, 846–847, 851–852, 887–888, 890, 907–908, 927–931, 943–946, 958–961, 986–987, 989, 1033–1034, 1166–1167
yaml_utils.py	106	11	89%	64, 68, 152–154, 158–159, 182–183, 207–208
gui
__init__.py	2	0	100%
main.py	152	29	80%	22, 24–26, 28, 49, 178–181, 188–191, 193, 196–202, 206–208, 212–213, 219, 230
world_canvas.py	226	52	76%	34–36, 110, 112, 114, 177, 181, 232–237, 243–244, 246–248, 253–254, 257, 260–262, 265, 270–271, 273, 300, 322–327, 330, 333–334, 349–351, 354, 371, 400, 418–419, 421–422, 464, 480, 487
manipulation
__init__.py	1	0	100%
grasping.py	236	61	74%	102, 110–112, 114–122, 124, 132, 462, 464–466, 470–472, 566–568, 571–575, 583, 586–588, 593–594, 600–604, 607–614, 617–619, 628, 630, 632–638
navigation
__init__.py	3	0	100%
a_star.py	78	10	87%	67–72, 74–76, 165
execution.py	34	4	88%	46–47, 49–50
occupancy_grid.py	139	14	89%	44–47, 49–53, 56, 192, 226, 234, 238
path_planner.py	26	6	76%	33, 36, 38, 42, 85, 90
planner_base.py	59	17	71%	29–35, 51, 57–59, 140–145
prm.py	72	56	22%	40–44, 46, 50–51, 54, 57–64, 66–67, 76–79, 85, 101–102, 104–109, 111–112, 115–118, 121–126, 135, 144, 154, 156, 158–159, 161, 174–178
rrt.py	172	7	95%	228, 353–354, 360–361, 363, 392
world_graph.py	70	3	95%	118, 121, 145
planning
__init__.py	0	0	100%
actions.py	66	43	34%	59–60, 62, 66–75, 77–80, 82–86, 88–91, 93–97, 99–100, 102–104, 150–151, 154–158
planning/pddlstream
__init__.py	7	1	85%	13
default_mappings.py	9	0	100%
planner.py	40	8	80%	119–126
primitives.py	57	2	96%	68, 208
utils.py	85	3	96%	66, 99–100
utils
__init__.py	0	0	100%
general.py	33	4	87%	23, 45, 51–52
knowledge.py	139	16	88%	90–91, 100, 135–138, 145, 149–150, 163, 178, 182, 224, 240, 295
motion.py	60	6	90%	56, 67–71
polygon.py	111	0	100%
pose.py	89	3	96%	79, 211, 227
search_graph.py	93	3	96%	240–242
trajectory.py	65	0	100%
TOTAL	3519	599	82%

Tests	Skipped	Failures	Errors	Time
168	0 💤	0 ❌	0 🔥	3m 36s ⏱️

[eholum]

Might need a bit more time to diagnose wtf is going on here, I partially blame my arm64 processor but no idea if that's the case.

So asking my dumb question for clarification while I do that...

[eholum]

I'm learning a lot about venvs from you! In this case I might need a little more information - since it feels very "un-docker-y" to use a venv (I don't know if that's true). Would it be preferable to add a test target after installing baseline dependencies in the pyrobosim image? Is there some specific advantage to a venv?

[eholum]

There are some weird issues that I run into building the base image... definitely unrelated here but man pip is messing me up.

8.903 Collecting PyQt5 (from pyrobosim==1.2.0)
8.931   Downloading PyQt5-5.15.10.tar.gz (3.2 MB)
11.68      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2/3.2 MB 1.2 MB/s eta 0:00:00
11.95   Installing build dependencies: started
17.11   Installing build dependencies: finished with status 'done'
17.11   Getting requirements to build wheel: started
17.18   Getting requirements to build wheel: finished with status 'done'
17.18   Preparing metadata (pyproject.toml): started
17.26   Preparing metadata (pyproject.toml): finished with status 'error'
17.26   error: subprocess-exited-with-error
17.26   
17.26   × Preparing metadata (pyproject.toml) did not run successfully.
17.26   │ exit code: 1
17.26   ╰─> [23 lines of output]
17.26       pyproject.toml: line 7: using '[tool.sip.metadata]' to specify the project metadata is deprecated and will be removed in SIP v7.0.0, use '[project]' instead

[sea-bass]

So in Ubuntu >= 23.04 (introduced in Python 3.11) you get an error by default if you directly try pip install packages into system Python (apt installs are fine).

The 2 ways to get around that are:

1. Make a virtual environment
2. Add the --break-system-packages arg (which does not exist as an option in older versions)

Neither of them is ideal, but the first one can be made to work in both older and newer versions... at some cost as you can see here.

The 2nd option can be implemented with some logic that checks the Python and/or Ubuntu version and adds the argument only for newer versions. This would prevent the need for a venv in the Dockerfile AND let us actually run colcon test. So maybe this is preferable even if ugly?

[sea-bass]

As for your error, I wonder if the version of PyQt5 released for your architecture is wonky. See if you can install a different version than whatever is pinned, or maybe pin it to an older version if not set in the requirements?

[sea-bass]

Actually, I found a much better solution!

ENV PIP_BREAK_SYSTEM_PACKAGES=1

[sea-bass]

pyproject.toml: line 7: using '[tool.sip.metadata]' to specify the project metadata is deprecated and will be removed in SIP v7.0.0, use '[project]' instead

This one seems like a known issue... sigh
altendky/pyqt-tools#120

I guess if you put the image to something that uses Python 3.10 or earlier, you'll be at least able to work for now?

[eholum]

I guess this is now moot because of your migration off PyQt5... but for the build issues I ran into I just needed to apt-get install -y qtbase5-dev prior to installing the Python package. I guess you need to have the build tools installed and for some reason in my docker build they just weren't... Also needing to somehow auto accept the GPL license terms.

Either way if you merge the migration all those issues go away and I can have that hour of my life back.