Closed iandareid closed 4 months ago
The parameter system is ported to the new param manager class (to make it more readable and easier to add / edit parameters).
Double check that all hard-coded values are switched to parameters, if possible
We also need to comb through ROSflight to implement the same changes.
@iandareid
I will need help on the estimator file if you have time tomorrow. I don't know what to call a lot of the hard-coded values.
@iandareid
I am working on making the timers run on parameters... How fast should path_follower
publish data? It is currently set to 10Hz, which is surprising to me since path_manager
publishes the current path at 100Hz and the estimation loops close at 100Hz as well.
Well path manager doesn't need to be 100 Hz that's for certain. It could easily be half of that.
The path follower could likely by turned up, I would be interested to see what changes that would make to performance. I will look into it to see if there is any reason it couldn't match the controller's 100 hz.
There is a chance that having them match could create instability, if they oscillate around one another. But we should definitely try at least 50 Hz.
The parameter system currently has default parameters set in several different places in each node. We need to standardize where default values are defined. The parameter system also uses a struct to pass parameters to different parts of the system. This means that to add new parameters for a new implementation of any part of ROSplane it requires and update to the "base" class that interfaces with ROS. This is not desirable and complicates integration. We should replace this with a map that can dynamically take new parameters, and allow for a user implementing a new module to add new parameters without having to track down 3 or 4 things to do so.