Reference frame of the controller

Dear all,

I noticed that the controller sometimes does not properly track the base trajectory. This might be due to the fact that the control is not computed in /map frame but rather in the /origin or /odom frame. If this is the case, this is generally wrong because the transformation between /map and /origin (or /odom) are not constant (that's what the localizer is computing) and therefore the controller is affected by the errors/drifts in the odometry (which is not negligible).

Best

[NadiaHG]

I think this is exactly the same issue that we already had last year that was solved reseating the odometry 😔 , I also think that a planner for a base should use the map frame, but then will be needed some localization software and we will mix manipulation and navigation functions, I think that the manipulation and navigation team should decide how to process together @mzillich what do you think?

And pleaseeeeeeeeee in case we need to use map I recommend a separation of low level drivers of the arm (only move and get joint states of the arm) and the controllers for the 8dof, start a map server just to move one joint of the arm is really undesirable.

I think that controlling the base without using the localization will never work because the feedback provided by the encoders will accumulates error on time. The point is that so far the base controller was implemented in squirrel_navigation and was independent of drivers and so on... in my opinion this low level controller is like move_base without the planning suite (but extra controller for the arm), therefore we can maybe treat it like move_base, that is, using parameters (i.e. a parameter that specifies the world frame) and spawning the controller separately from the other hardware.

I also think that resetting the odometry before every navigation task cannot be a solution because this will screw up the localization since the incremental odometry will be totally off when the reset is performed... furthermore, this would solve the problem only if the path is very short, the drift will accumulate anyway.

[mzillich]

I agree with @federico-b. This should be in map frame. If we want to run the arm controller stand-along, then we just have to add a static transform map-odom, right?

Adding a static transform /map -> /odom when no localizer is running is also a solution. What are we currently doing on our robot, we also publish a static zero transform /odom -> /origin to connect the all transformation tree.

Again, what's the issue now? The controller computes nothing - it just sends the values to the motor or the base. In any case, I guess it's the planner's job to plan in the proper frame.
Commet from Simon Haller : agreeing with federico-b adding a static transfrom could be a easy solution

Hi,
so I might have misunderstood the role of the whole thing. But it seemed to me that the new controller was able to command the base to follow some waypoints... so there must be a trajectory controller for the base too... is that ros_control_controller_manager? Cause I guess that package is designed to control the arms of the PR2 (cause move_base controls the base), so it might be that it is designed assuming precise encoders (such as the one for the arms) and not for encoders with big noise, like odometry... but I might be wrong here, don't know much about ros_control. Anyway, if we use this controller only for few centimeters, I guess it should work anyway.

[mzillich]

Yes, that's the plan to stay on the safe side: only use the 8DOF controller for short base movements. Long ones use the normal navigation services.

That depends on how many controllers you implement - one controller only works for a specific setup. So if needed, for sure, one can provide a ros_controller just for the base. The question is just how much sense this makes. I think we need to clarify all those things in our weekly hangout on Wednesday as there are apparently still some open issues on misunderstandings regarding needed and currently implemented functionality. Talk to you then. And good luck with the arm. If plugging in and out does not help, kick it fiercely ;)