I think the current update propagation route is quite long and interdependent. I think the chain of events is: main sets the timer for navigator. navigator requests a state from statemanager, then statemanager updates the speed setpoint of the stokers, which finally triggers the motor speed/power to be updated.. So none of the libraries know their own update rate, only main? And they all have the same update rate. The stoker PID in branch stoker_pid has a hard-coded UPDATE_RATE parameter (chosen to match everything else), which is used as a scalign factor in the PDI calcualtion, rather than an actual update rate. This parameter needs to be settable on initialisation to consistently match the actual update rate. Idealy in a way that allows its update rate to be decoupled from everything else.
Related to enabling the above: The stokers' update() method will probably need to trigger a motor power recalculation, rather than the set_speed() method.
I think the current update propagation route is quite long and interdependent. I think the chain of events is:
mainsets the timer fornavigator.navigatorrequests a state fromstatemanager, thenstatemanagerupdates the speed setpoint of thestokers, which finally triggers the motor speed/power to be updated.. So none of the libraries know their own update rate, only main? And they all have the same update rate. The stoker PID in branchstoker_pidhas a hard-codedUPDATE_RATEparameter (chosen to match everything else), which is used as a scalign factor in the PDI calcualtion, rather than an actual update rate. This parameter needs to be settable on initialisation to consistently match the actual update rate. Idealy in a way that allows its update rate to be decoupled from everything else.Related to enabling the above: The stokers'
update()method will probably need to trigger a motor power recalculation, rather than theset_speed()method.