Closed kaichie closed 7 months ago
I think also this comment wasn't documented:
Perhaps this is just a documentation item that users should set specific over general polygons in the list since the first that applies is used (so backups at the end)
Missing docs that the first polygon, if many cover a range, is used first. That should be addressed in the tutorial, configuration guide, and readme
@kaichie look at the rendering: there's something wrong with the fformatting or your new section https://output.circle-artifacts.com/output/job/2288c871-ef24-4297-8327-cddd9214fe45/artifacts/0/html/configuration/packages/collision_monitor/configuring-collision-monitor-node.html
@kaichie look at the rendering: there's something wrong with the fformatting or your new section https://output.circle-artifacts.com/output/job/2288c871-ef24-4297-8327-cddd9214fe45/artifacts/0/html/configuration/packages/collision_monitor/configuring-collision-monitor-node.html
I could not see anything obvious that is wrong with the table formatting. Looks like it is affected by the length of the parameter name on the left. Not familiar with this but will continue looking later, appreciate any tips here.
I have no particular suggestion. given that this is already a problem, I don't expect you to fix it (though that would be ideal), I would however expect you to make it less bad. It seems like reducing the <velocity_polygon_name>.<sub_polygon_name>
length would do alot of good. Perhaps <vel_poly>.<subpoly>
If that's not quite enough, seeing what formatting is not properly IDing these tables max width
Attempted to fix it in this commit, looks okay on the collision monitor page, but causes the table on other pages to look a bit funny, for example, here. Reverted and updated the parameter length to <vel_poly>.<subpoly>
.
OK, works for me for now
For https://github.com/ros-planning/navigation2/pull/3708