-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix : Log discrepancy when setting MPPI parameters dynamically #4707
Conversation
@PlatHum can you rebase on or pull in |
Signed-off-by: Francisco Gonçalves <[email protected]>
Signed-off-by: Francisco Gonçalves <[email protected]>
I think this reveals a previously unkown/uncaught error with dynamic parameter setting, perhaps? Or at least a problem with the tests performed. Previously, setting parameters always returned success even if the parameter was not set successfully or not found, which made it seem that all was fine. From the logs of one of the tests as an example:
For this one in particular, it seems like |
Please look into this - this is causing not only the individual unit tests to fail, but also the full system tests that use MPPI, so this PR would not allow MPPI to work. Have you tested MPPI after making these changes? Its worth checking where this is being triggered, it may well be valid sometime in setup / configuration - considering we see error logs around lifecycle transition failures. I believe when nodes are declared, they are set, and thus the callback could be triggered. |
I can close - but we appreciate your proactivity and help! I hope to merge another one of your PRs soon 😄 |
Basic Info
Description of contribution in a few bullet points
ParametersHandler::dynamicParamsCallback
cannot find the dynamically set parameter name in its parameters list, set theParametersResult
output message'ssuccessful
field tofalse
instead of alwaystrue
.Future work that may be required in bullet points
rcl_interfaces/msg/SetParametersResult
message returned also has areason
field that could be populated with the reason for failure. This could be the name of the parameter not found or the full already printed warning.For Maintainers: