Open tpatten opened 6 years ago
Hi,
good question. For the controller, we used the base controller as written by @Senka2112 and that has worked for at least two years now. The ros_controller cannot be the issue as it just sends down the values to the base_controller. But for sure, that one probably is not that accurate and completely relies on odom. So if this has a huge drift...
Best,
Philipp
Any idea what we could do in base_controller to compensate for the drift? I was just going through the code and it is not obvious how to get around the problem. Since it relies on the tf, we would have to exit the control loop and readjust within the map frame to get the compensated goal in odom. This means the controller needs to be called multiple times.
Oh boy, that sounds like sth really dirty. I have to take a closer look at the odom stuff first. But if this drifts, I guess this is the issue. The base controller tries to move to the commanded position by relying on that information. Just for clarification - this happens on the non-carpet floor (remember, back @UIBK at some point we had the issue that the carpet yielded a drifting robot...).
Currently we have a small issue with the 8dof planner generating long trajectories, but it has also exposed a problem with the controller. The base has a really large error. The arm joints look good, just the base is way off (the example in the first image is a very extreme case but nonetheless you can see how bad it is - blue is desired pose, white is actual pose). Is the controller properly tuned? Or is this a ros control issue? Or is it due to the odom drift during the execution of the trajectory? I suspect it could be last because after we generate a new plan to the same location and send the goal, the robot is much closer to the desired location (see second image).