Use `mpGetFBPulsePosEx` instead of `mpGetFBPulsePos`

[ted-miller]

mpGetFBPulsePos returns raw feedback position of the encoders. This can be different than logical position of the joint. This is due to things such as cross-axis couplings or gravity-compensation.

We already implement compensation for the cross-axis thing. And I'm told that gravity-compensation is a very specialized feature that's only available on one or two arms.

Now I'm hearing that there is a new feature on the next-gen controller that could also be affected by this.

The simple fix is to use mpGetFBPulsePosEx, which should apply any required corrections to the output.

[gavanderhoorn]

So would that allow us to remove the code we currently have for things like that cross-axis coupling you link to?

Is there also an mpGetServoSpeedEx(..)?

[ted-miller]

So would that allow us to remove the code we currently have for things like that cross-axis coupling you link to?

Yes, we could remove that chunk of code.

Is there also an mpGetServoSpeedEx(..)?

Not that I'm aware of.

---

I'm seeing some contradictory information on mpGetFBPulsePosEx regarding the absolute accuracy feature of the next-gen controller. I don't yet have the ability to test myself.

One report:

It looks that the axes correction is applied just after calling mpGetFBPulsePos(), but if other correcting features are enabled, the differences will be appered. For example, gravitiy compensation (this is for special customer) or absolute accuracy (this is only YNX1000 currently). I suggest to use mpGetFBPulsePosEx() instead of mpGetFBPulsePos(), [..]

Another:

(apologies for the screenshot)

[gavanderhoorn]

Hm. So in any case this reads as-if we'd have to introduce another batch of controller-specific #ifdefs. Correct?

[ted-miller]

Yeah, sounds that way