You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
question:
what are the benefits of splitting the dynamic reconfigurable parameters into 3 servers? The drawback I found is that we cannot treat MPC as any other local planner when changing generic parameters as the goal tolerances.
proposal:
replicate TEB architecture with a single server but multiple tabs, so parameters are neatly distributed on RQT reconfigure but still accessible under a predictably named server (we will PR the change if deemed opportune).
The text was updated successfully, but these errors were encountered:
I see the problem; but seems to me that PR #24 is adapting to the parameters namespace structure created with this example configuration
I think it would had been simpler to rewrite the configuration file declaring all MPC parameters in its own file and all the other parameters in a separated testing configuration. The 3 reconfigure servers looks rather overkilling to me
Hi, this issue is both a question and a proposal.
question:
what are the benefits of splitting the dynamic reconfigurable parameters into 3 servers? The drawback I found is that we cannot treat MPC as any other local planner when changing generic parameters as the goal tolerances.
proposal:
replicate TEB architecture with a single server but multiple tabs, so parameters are neatly distributed on RQT reconfigure but still accessible under a predictably named server (we will PR the change if deemed opportune).
The text was updated successfully, but these errors were encountered: