[strands_movebase] Investigate if controller_frequency should be lower
Opened this issue · 10 comments
At AAF, we discovered that the controller_frequency parameter (https://github.com/strands-project/strands_movebase/blob/indigo-devel/strands_movebase/strands_movebase_params/move_base_params.yaml#L3) being set to 10 hz caused quite a bit of overshooting. Changing it to 5 hz fixed the issues that we were having. We should investigate if this leads to an improvement on other systems as well.
It should also be noted that 20 hz caused massive overshooting and other problems (we observed 4m overshoot in once instance). So there is a clear problem with higher frequencies.
i also noticed the overshooting a couple of days ago when preparing the nav tests. It wasn't happening very often before (after some fix we did for the previous case of overshooting, which I don't remember what it was). I wonder what changed for it to reappear...
Could it have to do with overall load? What if we set the frequency higher than the computer can actually deliver? Would things queue up then? That's my best guess so far.
As I mentioned in the previous comment, 20 hz caused the system to go completely haywire. We still need to investigate if these overshoot issues are Werner specific though. At AAF, it was overshooting every time it had to turn before reaching its final position.
Yes, I suspect it's the discrepancy between desired rate and achievable rate. 20Hz is not achievable I assume and hence it fails...
I'm having this with Bob all the time, I reduced the frequency to 5Hz but he still overshoots all the time... @nilsbore any suggestion?
@bfalacerda Sorry, this fixed it for us at least. What version of the MIRA firmware do you have installed? The new version?
@creuther updated our robots with the new firmware, MCU 1.8.14, and overshooting seems to be gone, even with the 10Hz controller frequency.
DWA prints warnings when the controller loop tales longer than the frequency parameter, and I didn't see that happening when the robots were overshooting, so I'm doubtful that that was the culprit in Werner also. Anyway, I think atm it'd be a good policy to update the firmware for non-Werner robots, since it has some important fixes to odometry reporting.
So, @Jailander @gestom first adopting this for Linda and then decide if to update Werner?
maybe after we are done with the charging tests?