We have an arm using MotionMagicTorqueFOC and I just want to confirm what reference point should be provided. We expect it to be -1 to 1 where 0 is the position forward horizontal. Is this accurate?
We are seeing weird motion and when the motion is complete the mechanism isn’t being held at position even with some P. Is that expected?
Do you have a feedforward?
MotionMagicTorqueFOC doesn’t have a feedforward. It has a kA, kV, kS, and a kG. We have all of these values set. We got these values from SysID (with some messing around since there wasn’t a lot of data). Overall the motion is actually quite good 90% of the time. But 10% of the time it just doesn’t work right and it doesn’t really hold position.
public static final Slot0Configs pivotGains = new Slot0Configs() {{
GravityType = GravityTypeValue.Arm_Cosine;
kS = 1.6221;
kG = 2.3923;
kV = 1.6429;
kA = 2.7332;
kP = 69.657;
kI = 0;
kD = 26.77;
}};
These are all feedforward terms, except for kG which is a feedback term in the CTRE implementation.
Can you share a pic of your SysId analyzer with the data loaded?
We figured out the problem. There was a mechanical problem with the driving gears where they were not always engaged. Problem solved 
How? Isn’t the whole calculation just cos(setpoint) * kG?
Kg just counteracts gravity. That calc should just keep the mechanism stationary.
I know, but then why is it feedback? I accidentally referred to kG as only the one for arm.
For elevator type feedback it should be setpoint * kG, which still isn’t feedback.
The CTRE implementation uses the measured angle instead of the setpoint.
Are you sure these values are for TorqueCurrentFOC mode? Kv should be nearly zero in that case.
I see
Kinda weird though
Not really weird at all. It trades a bit of stability at steady-state for substantially better performance if you drift far from the setpoint.
Arm angle is a natural place to do a feedback linearization. It changes slowly and the signal is not very noisy.
But then it creates some kind of way where if you drift a bit you’ll keep drifting since everytime you slightly change your angle that’s the new “setpoint”. So it’ll create drift over time if your values aren’t perfect
it will cause stable oscillation, not drift. This oscillation is typically small and damped out by feedback.
So since it’s that small it is negligible for the added performance?
They were the result of using SysId with Torque as voltage. I agree that some of thes should be 0 but ot is what it provided and it actually functions. It just isnt as accurate as we want. When we tried to maually tune it we had all sorts of problems.
SysId doesnt really work well with arms that mobe fast and dont move far. We had to do multiple tests to get data that would result in valid kv, ks, etc.
If you have suggestions on how to run tests that would work better that would be great!
Now that the mechanical issue is resolved we are trying to redo SysId and it is really tough. I think the problem is that it is including more data that we want into the test.
I think the data at the beginning of the graph should be excluded, but I don’t know how or if it is supposed to even be there.
Looks like you might be encountering this:
I don’t think the fix has hit a release yet, unfortunately, so you either have to copy the code into your own repository or else roll the dice until the test works (I recommend the former).
In any case, it looks like your signal is extremely noisy. I’d look into that.
That does sound like the problem we are having.
Do you have any suggested resources on the data being noisy? We are currently using the ctre SignalLogger and we have increased the data to 250 hrtz. This was based on examples from ctre.
I’m unsure - this is more noise than I’ve seen in data from CTRE devices so far this year. What encoder are you using?
