Feature/mw/fields2cover2

[aosmw]

Update Fields2Cover to v2 api.

Uses Fields2Cover/ortools_vendor#2 and Fields2Cover/Fields2Cover#126

This builds on behavior tree update PR 43 by @tonynajar.

[SteveMacenski]

Generally looks good to me, but you have some linting issues that CI is unhappy about that we need resolved and the build doesn't turn over :(

I have no meaningful comments on your port to v2's API - that all looks great.

[aosmw]

Either the lines are too long for uncrustify or have wrong style for the cpplint.

Error: /__w/opennav_coverage/opennav_coverage/opennav_coverage/include/opennav_coverage/utils.hpp:160:  If an else has a brace on one side, it should have it on both  [readability/braces] [5]
Error: /__w/opennav_coverage/opennav_coverage/opennav_coverage/include/opennav_coverage/utils.hpp:166:  If an else has a brace on one side, it should have it on both  [readability/braces] [5]
Error: /__w/opennav_coverage/opennav_coverage/opennav_coverage/include/opennav_coverage/utils.hpp:180:  If an else has a brace on one side, it should have it on both  [readability/braces] [5]

[SteveMacenski]

Either the lines are too long for uncrustify or have wrong style for the cpplint.

These are lines that this PR touches, please heed the formatting requirements :-)

[SteveMacenski]

What worries me is compatibility with 22.04 and with Humble.

There is a separate humble branch - so that all should be more or less fine!

are still using ROS1, so making use of a whole ROS project becomes gradually more complex or even impossible.

There is no intention for support for ROS 1. Frankly I haven't really thought about ROS 1 in years. If someone wanted to port this all to ROS 1 and have a ROS 1 branch, I wouldn't block it, but I wouldn't implement it

By any chance will this v2 API update be compatible with Humble or should I start preparing for a big upgrade?

For maintenance reasons, the humble branch will stay on V1 since that was what it was released under and v2 has breaking changes. With that said, I'd be happy to have a humble-v2 branch that folks on Humble can use with v2 if someone opens a PR once this is all wrapped up. I just don't want to push API breaking changes to everyone except those that want that in exchange for the breakage.

This PR and work on Fields2Cover packaging is my attempt at giving back.

And I genuinely thank you for this @aosmw! I spend alot of my time fighting the good fight working on things like this, so the help is really, truly appreciated!

This is fixed in BehaviorTree/BehaviorTree.CPP@97c3f6a

Ugh. Build from source until that is released too.... I guess...

Needs something like this ros-navigation/navigation2#4267

Precisely!

I think we're on the home stretch here, update the action to 24.04 which should fix rosdep & that should be the last of the large problems

[SteveMacenski]

Any word?

[aosmw]

I was going to wake this up again now that ros-navigation/navigation2#4298 has landed.
Most of what is needed is just stripping out the workarounds in .github

I was also going to look into how to point the github build at the ghcr.io/ros-navigation/navigation2:main docker image.

[aosmw]

The build against the source of fields2cover works, ie using the .github/deps.repos mechanism.
The build against the packaged version of fields2cover for rolling on 24.04 currently does not.

HOWEVER,
There remains a package conflict to negotiate for nav2_constrained_smoother and nav2_smac_planner that is not resolved by rosdep. libceres-dev wants libgoogle-glog-dev that wants libunwind-dev but the docker image has libunwind7-dev.

ALSO,
The packaged install location of the fields2cover dependent libraries is pretty ugly and fails to find its libabsl libraries properly. Looking for them in /opt/ros/lib/lib rather than in /opt/ros/lib/x86_64-linux-gnu where they currently reside.

IOW,
The current install of ros-rolling-fields2cover 2.0.0-13noble.20240514.144256 put the ortools/absl/protobuf/fields2cover libraries in /opt/rolling/lib/x86_64-linux-gnu rather than a more conventional/contained ros location. They should be properly vendored into /opt/ros/rolling/opt/ortools

FYI,
I now have a way to poke around in the github action build by running it using https://github.com/nektos/act. It requires that the image being used has nodejs installed. Once it is running I find its container name using docker ps, and then get a bash shell inside it using docker exec -it $(docker ps --latest --quiet) bash

CONCLUSION,
Close but still so far.

[SteveMacenski]

The build against the packaged version of fields2cover for rolling on 24.04 currently does not.

Great... I thought we'd mentioned that to fix it, but I suppose still no dice.

There remains a package conflict to negotiate for nav2_constrained_smoother and nav2_smac_planner that is not resolved by rosdep. libceres-dev wants libgoogle-glog-dev that wants libunwind-dev but the docker image has libunwind7-dev.

I'm a little confused by that considering this builds fine in Nav2's CI and for me locally with a 24.04 docker image

[SteveMacenski]

Perhaps it would be easier to manually setup the build like here rather than using the ROS tooling wrappers?

[aosmw]

The image used in the github workflow is currently rostooling/setup-ros-docker:ubuntu-noble-ros-rolling-ros-base-latest
That is the likely cause of the libceres-dev, libgoogle-glog-dev, libunwind-dev, libunwind7-dev dance at the moment.

The main problem of using the Fields2Cover package, (2.0.0-13noble.20240514.144256) right now is the command line flags that the ros buildfarm uses and what they do to the locations of where things get installed prior to creating the debian package.

Fields2Cover does not use ament_cmake and I when I started trying to help, I tried to workaround what was there. I introduced the use of cmake include(GNUInstallDirs) and used the variable CMAKE_INSTALL_LIBDIR which is overriden by the ros packaging command in a way that is not playing nicely.

Digging down into it the command that is getting run by the ros build farm to create the package - https://build.ros2.org/job/Rbin_uN64__fields2cover__ubuntu_noble_amd64__binary/77/console and wrapping it in a script to reproduce locally

#!/bin/bash

mkdir -p build
cd build
DEB_PYTHON_INSTALL_LAYOUT=deb cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DBUILD_TESTING:BOOL=OFF -DCMAKE_INSTALL_PREFIX=/optmw/ros/rolling -DCMAKE_PREFIX_PATH=/optmw/ros/rolling -DBUILD_TESTING=OFF -DFETCHCONTENT_FULLY_DISCONNECTED=OFF ..

make -j8
sudo make install

Notice the -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu
Notice that i tweak the install prefix to /optmw isolate it on my local dev system.

I have some ideas to get it to play nicely (in a ros package install) that I am playing around with.

My aim is to find a way to get the ortools sfuff installed in /opt/ros/rolling/opt/f2c_ortools while still working for a non-ros/non-ament build.

THIS Fields2Cover/Fields2Cover#146 (remove libabsl-dev from Fields2Cover/package.xml) might be a simple fix for now but the way the Fields2Cover package is dumping ortools artifacts into /opt/ros/rolling should really be improved so I will keep plugging away at it.

[SteveMacenski]

I have some ideas to get it to play nicely (in a ros package install) that I am playing around with.

Great!! For the meantime though would it be useful to just build F2C in CI here from a deps.repos file that we use tagged at a version we support for a given distribution?

But fixing F2C to have the binaries work well is useful. If we're having issues here, I presume anyone else trying to use the binaries would also have a similar issue.

[Marc-Morcos]

Sorry to bother but, from reading the history, this works on older versions of ROS and you are currently just fighting the autotester?

[aosmw]

@MarcM0 This PR targets rolling, which was in a fair bit of flux when I was last touching this. Its settled now so worth a revisit. I won't be looking at it for a while though. Next steps would be to update it to the latest rolling and check the state of the fields2cover packages.

[mikolodz]

@MarcM0 This PR targets rolling, which was in a fair bit of flux when I was last touching this. Its settled now so worth a revisit. I won't be looking at it for a while though. Next steps would be to update it to the latest rolling and check the state of the fields2cover packages.

Hello @aosmw, how are you doing? Do you think you will be able to give it a try in the near future?

[lianzhijun17]

@SteveMacenski @tonynajjar @aosmw @mikolodz
Hello,
Thank you very much for your time and assistance!
I am currently using the Humble branch. When I use the F2C v1.2.1 API, the simulation runs perfectly in Gazebo. However, when I switch to the F2C v2.0.0 API, I encounter an issue during the simulation. Although I can see the coverage path and the robot moves to the start point, it stops there and does not proceed further until the progress checker times out. The /cmd_vel topic shows a very low speed of 0.0005, which seems to be the root of the problem.
I am unsure how to resolve this issue and would greatly appreciate any guidance or suggestions you might have.
Thank you again for your help!

[u33549]

Offering support for Fields2Cover v2 API Integration / Reviving PR #53

Hello @SteveMacenski, @aosmw, and team,
I have been reviewing this PR and the history of migrating opennav_coverage to the Fields2Cover v2 API. I see that due to packaging bottlenecks and binary/dependency conflicts on Noble/Rolling at the time, the project recently merged support for F2C v1.2.1 on Jazzy/Rolling via #82.

I am very interested in contributing to this repository and helping revive the transition to F2C v2.0.0+.

Before diving into the code, I would like to ask:

Is there an ongoing active branch or a new roadmap for the v2 migration, or should we start fresh from the current main branch state?

Has the F2C Debian packaging issue (the libabsl / GNUInstallDirs path mismatch on the ROS buildfarm) been resolved upstream in Fields2Cover, or do we still need to vendor it via deps.repos for CI?

Regarding the runtime issue mentioned by @lianzhijun17 (where the robot stalls at the start point with near-zero /cmd_vel), has anyone pinpointed whether this is a local Nav2 controller configuration issue or an architectural change in how F2C v2 returns path coordinates?

I have a local setup with Ubuntu 22.04/24.04 and ROS 2, and I'd be glad to take over the heavy lifting, fix the linting/braces issues, and debug the simulation tracking. Looking forward to your guidance!

[SteveMacenski]

Is there an ongoing active branch or a new roadmap for the v2 migration, or should we start fresh from the current main branch state?

There is not current active branch, so if you wanted to start clean or start with something related to this, either is OK by me! I think its up to you and what you think is best / most efficient :-)

Has the F2C Debian packaging issue (the libabsl / GNUInstallDirs path mismatch on the ROS buildfarm) been resolved upstream in Fields2Cover, or do we still need to vendor it via deps.repos for CI?

I think we should plan to build from source to pin to a release version, but you can/should test.

Happy to have the help!

[u33549]

Thanks for the quick and encouraging response, @SteveMacenski! 🙏

Since there's no active branch and it's open to whatever is most efficient, here's how I plan to approach it:
Starting point: humble / Ubuntu 22.04. I'm most comfortable in that environment and prefer working on 22.04, so I'd like to land the v2 migration there first, and only look at Jazzy/Rolling after that.
I've audited the entire F2C surface in the repo (only opennav_coverage and opennav_row_coverage actually touch F2C — 9 production sources/headers + 10 test files), and I've split the work into two clearly separated tracks:

1. UPDATE — mandatory v2 API migration (no behavior change, just compile + run on v2)
   These are the existing modules re-wired to the v2 API:

types.hpp — clean up the duplicate LineString typedef; re-validate all F2C* aliases against v2 headers.
robot_params.hpp (+ the two dynamic-param callbacks in coverage_server.cpp and row_coverage_server.cpp) — public fields → setters: robot_width/op_width/linear_curv_change → setWidth()/setCovWidth()/setMaxDiffCurv(), setMinRadius() → setMinTurningRadius(), and handle the parameterized Robot constructor.
swath_generator.cpp — step_angle public field → setStepAngle().
path_generator.cpp — searchBestPath() → planPath(); turn_point_dist → TurningBase::setDiscretization().
headland_generator.cpp — verify generateHeadlands / ConstHL signatures.
route_generator.cpp — verify genSortedSwaths / setSpiralSize / setCustomOrder.
coverage_server.cpp — F2CField public fields → getters (.coord_sys → getCRS(), .field → getField()); verify Parser::importFieldGml / Transform::transformToUTM.
utils.hpp — path.states → getStates(); re-validate PathState/PathSectionType, F2CField/F2CCell constructors, Transform::transformToPrevCRS, moveTo.
visualizer.cpp — verify geometry primitives (getGeometry, Point + Point, startPoint/endPoint).
opennav_row_coverage/utils.hpp — the F2C↔GDAL/OGR bridge + CRS handling (most fragile integration point).
row_swath_generator.cpp — StartPoint()/EndPoint() → camelCase startPoint()/endPoint(); verify Swath(LineString, width, id) ctor and reversePoints().
Build — find_package(Fields2Cover 2.0 REQUIRED), Fields2Cover::Fields2Cover link target, package.xml rosdep key.
Tests — update the 10 affected test files to the new API.

2. UPGRADE — new v2 capabilities to add after the migration lands
   These are genuinely new features F2C v2 unlocks that the current code doesn't use yet (ordered low → high effort):

NSwathModified objective — fast swath-count objective, speeds up the brute-force angle sweep.
Velocity profile + driving direction — expose PathState::velocity and dir (FORWARD/BACKWARD) to the ROS output.
Path post-processing — discretize/populate/reduce, plus getTaskTime() for an ETA in the action feedback/result.
HL_SWATH type + headland swaths — treat headland rings as drivable swaths.
F2CRoute + inter-swath connections — real transition paths between swaths via planPath(robot, route, curve).
Facade (planCovPath / Options) — an optional "single-call" simple-mode pipeline alongside the granular one.
Decomposition (TrapezoidalDecomp / BoustrophedonDecomp) — split non-convex (L/U-shaped) fields into convex sub-cells, drastically reducing swath count.
Multi-cell TSP routing (RoutePlannerBase) + start/end point pinning (setStartAndEndPoint) — OR-Tools-based routing through headlands across multiple cells, starting from the robot's current pose. This is the biggest architectural win.

My plan is to get Track 1 (Update) fully compiling, tested, and validated against the demo package first, then layer Track 2 (Upgrade) features incrementally so each can be reviewed on its own.
I'll start a clean branch off main/humble and open a draft PR early so you can track progress. Looking forward to it!

[SteveMacenski]

#105 (review) to supersede