StateSpace::validSegmentCount for infinite state spaces
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
Direzione di ricerca
Inizia in StateSpace::setup() e segui come maxExtent_, longestValidSegment_ e longestValidSegmentFraction_ influenzano DiscreteMotionValidator per uno spazio degli stati infinito. Riproduci il caso di floating joint descritto tramite MoveIt ompl_interface, quindi determina e documenta il comportamento previsto; il lavoro è completato quando il comportamento per estensioni infinite è esplicito e validato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hello,
in StateSpace::setup(), we get that longestValidSegment_ = maxExtent_ * longestValidSegmentFraction_, with no way to directly set this longest valid segment from user code.
For infinite spaces (as appears to be the case for floating joints in the ompl_interface in MoveIt), such as a robot moving freely through space without restrictions, maxExtent_ would be infinite, and therefore longestValidSegment_ would be too. A DiscreteMotionValidator would therefore also not check any intermediate states.
Perhaps we could issue a warning or an error when this is infinite? Or is there perhaps a cleaner way to handle this case?
A more subjective bit:
In my opinion, perhaps, computing a fraction of bounds that a user would probably would just set as a rough upper bound for their workspace (which would then increase if they extended the workspace, possibly leading the planner to suddenly tunnel through obstacles it correctly avoided before without a clear cause) is not really what some users would expect. Would a constant distance not be more appropriate here? Or just not providing a default at all and issuing a warning, since use cases are so variable?
- Lingua principale
- C++
- Stelle
- 2.2k
- Fork
- 718
- Merge medio
- 16h 12m
- PR unite (30g)
- 1
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
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 ompl/ompl
-
Constructor is missing in py-binding/control/planners/sstForse già presa @srivarshni7 l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
-
Possible [optimization] Does EITstar::isValidAtResolution re-calculate the same path excessively?Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
-
AORRTC always returns zero-length path on RealVectorStateSpace (OMPL 2.0.0 Python bindings)Forse già presa @zkingston l’ha presa 183 giorni fa. Aperta
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
Issue simili
-
Code: Performance
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
CrimsonCrossBunker/Cataclysm-Cleanwater-Bomb#1167 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
meshcore-dev/MeshCore#3760 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
deepseek-ai/DeepGEMM-Ascend#29 ·
I maintainer di solito rispondono entro 1 giorno
-
area:lattice bug
Difficoltà 1/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 3 giorni