mobile: the occupancy grid should draw the planner background, and planners should agree on units
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 30/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- python
- Ambito
- data-visualization, robotics
Direzione di ricerca
Start with PlannerBase.plot_bg and BaseOccupancyGrid.plot(), then compare how DistanceTransformPlanner.plan(goal), PRMPlanner and validate_endpoint interpret the goal coordinates. The unit convention is not yet decided, so agree it with the maintainer first and record it in the mobile section of desiderata.md. Done means the planners share one convention, unit-cell output is unchanged, and new tests cover a 0.5 cell size and a non-zero origin.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Drawing a planner's background (the occupancy grid, the distance field, the colorbar, the cell labels) is done by PlannerBase.plot_bg, in cell numbers. The occupancy grid object, which knows its own workspace, cellsize and origin, only draws the obstacles. The two should be one thing: the map draws itself, and a planner hands it an optional overlay.
Why
- The planners disagree about units.
plot_bgdraws in cell numbers (axes labelled "x (cells)") andDistanceTransformPlanner.plan(goal)uses the goal as a row/column index, whilePRMPlannertakes world coordinates. For a grid with one cell = 1 unit starting at 0, which is everything in the book, they are the same. For a grid with 0.5-unit cells, or one that starts at (10, 20), a goal in world units givesIndexErrorfor the distance transform and a misplaced picture. validate_endpointtests a point against the grid in world coordinates, then the planner uses the same number as a cell index.- Every planner repeats the background logic through the base class, and
RRTPlannerdraws aPolygonMapby another route.
Proposal
BaseOccupancyGrid.plot()takes an optional overlay field and its options (field,colorbar,colorbar_style,labels,label_style,cmap,inflated), and draws in world coordinates using its own geometry.PlannerBase.plot_bgshrinks to "supply the distance field and the inflated image" and calls the map.- Decide whether every planner takes world coordinates and converts to cells itself (my suggestion), and document it in a mobile section of
desiderata.md(the design principles file at the repo root). - Keep the output identical for unit cells, since all the book examples use them; add tests for a 0.5 cell size and a non-zero origin.
Not in scope
- The
blockargument convention (tracked separately). - Animation arguments.
Related
plot(labels=True),colorbar_styleand friends are now arguments ofplot()(the PR that addslabels), which this builds on.
- Lingua principale
- C++
- Stelle
- 3.5k
- Fork
- 639
- Merge medio
- 1g 13h
- PR unite (30g)
- 98
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di petercorke/robotics-toolbox-python
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
petercorke/robotics-toolbox-python#709 ·
I maintainer di solito rispondono entro 1 giorno
-
help wanted
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
petercorke/robotics-toolbox-python#839 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement help wanted
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
petercorke/robotics-toolbox-python#825 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
feat(ets): numerical inverse kinematics for planar ETS2Forse già presa @qwist1233-cpu l’ha presa 2 giorni fa. Apertaenhancement help wanted
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
petercorke/robotics-toolbox-python#824 ·
I maintainer di solito rispondono entro 1 giorno
-
Rigorous testing of operational-space methodsForse già presa @kVinsom l’ha presa 1 giorno fa. Apertatech-debt Tests needed
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
petercorke/robotics-toolbox-python#804 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di petercorke/robotics-toolbox-python
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
ROCm/rocm-systems#13754 · 2 commenti ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
raspberrypi/libpisp#80 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
nanoporetech/pod5-file-format#198 ·
-
Upstream changes to reviewAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
rhalbersma/xstd-ints#341 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
secondlife/lsl-definitions#222 ·
I maintainer di solito rispondono entro 9 giorni