Ensuring Consistent State Space Type in CForestStateSpaceWrapper
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 55/100
Direzione di ricerca
Cerca il costruttore di CForestStateSpaceWrapper e verifica come viene inizializzato il suo type_. Leggi la logica referenziata in PathLengthDirectInfSampler.cpp, in particolare le righe 96–117, e verifica che il wrapper riporti il tipo del StateSpace sottostante e mantenga il suo nome in modo coerente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I noticed a potential issue with CForestStateSpaceWrapper. This class inherits from StateSpace but does not explicitly assign an initial value to type_, leaving it as the default value STATE_SPACE_UNKNOWN.
A possible error I discovered is in PathLengthDirectInfSampler.cpp (lines 96–117), where values are set based on different state space types:
if (!InformedSampler::space_->isCompound())
{
if (InformedSampler::space_->getType() == STATE_SPACE_REAL_VECTOR)
{
// R^n, this is easy
informedIdx_ = 0u;
uninformedIdx_ = 0u;
}
else if (InformedSampler::space_->getType() == STATE_SPACE_UNKNOWN)
{
// Unknown, this is annoying. I hope the user knows what they're doing
OMPL_WARN("PathLengthDirectInfSampler: Treating the StateSpace of type \"STATE_SPACE_UNKNOWN\" as "
"type \"STATE_SPACE_REAL_VECTOR\".");
informedIdx_ = 0u;
uninformedIdx_ = 0u;
}
else
{
throw Exception("PathLengthDirectInfSampler only supports Unknown, RealVector, SE2, and SE3 "
"StateSpaces.");
}
}
To address this, I believe the state space type of CForestStateSpaceWrapper should be consistent with the type of the StateSpace provided during its construction. For example:
CForestStateSpaceWrapper(geometric::CForest *cforest, base::StateSpace *space)
: cforest_(cforest), space_(space), planner_(nullptr)
{
this->type_ = space->getType();
setName(space->getName() + "CForestWrapper");
}
This approach seems more reasonable and ensures consistency between the wrapper and the underlying StateSpace.
- 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
-
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 182 giorni fa. Aperta
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
eclipse-score/lifecycle#929 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
colbymchenry/codegraph#3223 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
firefox-devtools/profiler#6436 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno