Using ArmFeedforward for adjustable hood

Hello, I was wondering if the wpilib ArmFeedforward class works for adjustable hoods too. I feel like it would because it would be accounting for gravity the same as it would for an arm (based on the current angle it is at).

Also I was wondering about the kG term you pass into the ArmFeedforward constructor. What is it? The volts needed to keep the arm/hood horizontal?

1 Like

Yup, we used ArmFeedforward and a motion profiled PD controller on a hood with much success!

kG is the voltage needed to overcome gravity at horizontal. In the ArmFeedforward class it’s multiplied by the cosine of the current position in radians to get the voltage needed to oppose gravity at the current position. You can use sysid or recalc to find it (along with kV, kA, and kS (sysid only)).

1 Like

Ok nice. Did you find the need to correct for the drivetrain acceleration in the hood voltage? I feel like the hood would be thrown back when you accelerate, like you would be when riding in an accelerating car.

Also, I’ve used sysid successfully before, but how exactly does using it work with the hood? Can you only raise the hood? Our hood ranges from about 20-70 degrees, and I feel like if I tried to do the backwards sysid test it would just slam into the bottom because it would working with gravity too.

And where on the dashboard does it give you the kG value? I’m not seeing it

We haven’t tested it while driving yet, but that would be an application where the encoder value would change and thus your control system would drive it to its actual setpoint. Our hood is geared way down so it’s probably not going to be that big of a concern because of inertia, but I’m not sure what your mechanism looks like.

In sysID, you can just start the hood wherever. Because of the gearing our hood doesn’t backdrive with gravity, but if this is a concern you can just use recalc (or hold it and run for a bit of time): ReCalc.

kG will show up when you upload data from an arm test (the theoretical mode, which I think you’re referring to, only has kV and kA because those are what you need to calculate optimal feedback gains).

1 Like

Ok, say I start the hood at the bottom and use the sysid forward test to raise it. Wouldn’t sysid just incorrectly assume the voltage needed to overcome gravity was a part of the static friction and give me a really high kS?

Depends on the range of motion of your mechanism, the mass, the power of the motor, and how clean the signal is.

If there’s not enough data to jointly determine kG and kS, that probably means one of the two can be safely ignored (it’s small enough to be negligible).

1 Like

Ok that makes sense. So if I have enough gearing on my hood so that it stays up on its own, should I even be using ArmFeedforward or should I just use SimpleFeedforward?

I feel like even if I have enough gearing, it’s still going to need less voltage to go down because gravity is helping it out. So should I give it some kG that greater than zero but less than kS in that case? If you slowly ramp up the voltage, the static friction would change from stopping it from going down to stopping it from going up. So I think I would want to find that sweet spot in between. How would I determine the value experimentally? Or am I just overthinking it and none of it will actually effect much?

It’ll all shake itself out in the test routine. ReCalc can give decent estimates, as well.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.