search

strands-project / strands_movebase

A repository for all the STRANDS-augmented movebase, including 3D obstacle avoidance, etc.
MIT License
10 stars 20 forks source link

[strands_movebase] Investigate if controller_frequency should be lower #71

Open nilsbore opened 8 years ago

nilsbore commented 8 years ago

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.

nilsbore commented 8 years ago

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.

bfalacerda commented 8 years ago

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...

marc-hanheide commented 8 years ago

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.

nilsbore commented 8 years ago

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.

marc-hanheide commented 8 years ago

Yes, I suspect it's the discrepancy between desired rate and achievable rate. 20Hz is not achievable I assume and hence it fails...

bfalacerda commented 8 years ago

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?

nilsbore commented 8 years ago

@bfalacerda Sorry, this fixed it for us at least. What version of the MIRA firmware do you have installed? The new version?

bfalacerda commented 8 years ago

@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.

marc-hanheide commented 8 years ago

So, @Jailander @gestom first adopting this for Linda and then decide if to update Werner?

gestom commented 8 years ago

maybe after we are done with the charging tests?