inconsistent declare/undeclare parameter behaviour
@fujitatomoya ci sta già lavorando.
Dal 20/2/2025.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
current behaviour
A ROS node can:
- explicitly declare a parameter via
declare_parameterand explicitly undeclare it viaundeclare_parameter - implicitly declare a parameter by setting the option
allow_undeclared_parameters(true)and then just setting the parameter viaset_parameterand implicitly undeclare a dynamic parameter by changing its type toPARAMETER_NOT_SET
It is also possible to mix these modes and implicitly undeclare an explicitly declared parameter by not allowing undeclared parameters, using dynamic parameter types and then setting its type to PARAMETER_NOT_SET. In such a situation, it will not be possible to "reactivate" the parameter again, without the node explicitly declaring the parameter again.
This mix of explicit creating and implicit deletion of parameters is inconsistent.
expected behaviour
If an explicitly declared dynamic parameters type is changed to PARAMETER_NOT_SET, it should result into the same behaviour as declaring the parameter with PARAMETER_NOT_SET in the first place. That means, after changing the type to PARAMETER_NOT_SET, has_parameter must return true and ros2 param get should return Parameter not set. and ros2 param dump should show the value as null.
Additionally, it would be useful if this would still work with static types, such that a parameter has a static type and its value is either be set or unset (null), comparable to a NULL pointer in C.
The current implicitly undeclare behaviour should only apply when allow_undeclared_parameters is true and parameters are declared implicitly via set_parameter.
- Lingua principale
- C++
- Stelle
- 805
- Fork
- 564
- Merge medio
- 1g 22h
- PR unite (30g)
- 21
Guida per i contributori
Apri 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 ros2/rclcpp
-
good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
Issue simili
-
[CI] Nightly Clang build broken: structured binding captured in a lambda in FileDataSource.cpp Apertabug build
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 91/100
facebookincubator/velox#19194 ·
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW Apertafuzz
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
ClickHouse/ClickHouse#122114 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
module/agent platform/macos type/bug/regression
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
enhancement PyCDE
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100