Hello! I’m wondering if anybody can qualitatively describe the level of smoothness we should see out of our shoulder joint when using wpilib control loops. We had slop In motion magic just due to multiple gear ratios and chain tension and all of that fun mechanical stuff and though our arm works right now with a trapezoidal motion profile and a semi-decent tuned feedforward, it still seems relatively jolty when accelerating and decelerating, this doesn’t seem to be mechanical related, so I’m wondering if this is normal or if we should retune our feedforward or profiled pid controller.
1 Like
Have you decreased your motion magic acceleration constant?
we omitted motion magic and instead are using a trapezoidal motion profile and our goal is to pin the crap out of the acceleration just for speeds sake, if we were to decrease it my guess is it would be smoother, but I’m wondering if there is a way to make it smoother while still having high acceleration, and if so what is the maximum acceleration you should be at.
Why would motion magic perform worse than a WPILib trapezoidal motion profile?
How much backlash is in your system? Large accelerations do not play well with backlash.
In response to what you are saying, you can have a higher acceleration constant and then tune the D term to act as a harder brake. Also, you should apply a feedforward to your motion magic loop to account for gravity affecting your arm. An arbitrary feed forward would work best with motion magic
MotionMagic is a trapezoidal motion profile.
MotionMagic with a an Arbitrary Feedforward calculation should work just fine if you can make WPILib’s work. The motion magic API even provides you S-Curve smoothing that should be able to shake out your shakiness with your initial acceleration and deceleration.
With regard to what the maximum acceleration should be, I would say that it should be whatever value gives you smooth motion through the action you’re trying to take.
Hi, I’m on the same team as Henry. The problem we ran into with motion magic was that we had our motors & cancoder chained to our arm, and when moving it manually, the cancoder fluctuated about 5 degrees due to chain slop. As a fix, we mounted a Pigeon on our arm and use that as our measuring device instead of the Cancoder. Thus to use the pigeon we switched to a wpi trapezoidal.
1 Like
In doing this, we are wondering on the implementation of going back to motion magic, would we zero the motors off of the pigeon every control loop? We have reduced the slack since we made this fix so the backlash is significantly less than it was before and we could potentially make the switch back after our first competition. I also re-tuned it this morning and got it significantly smoother, turns out it was due to command loop overruns which were rampant in our code due to lots of smart dashboard puts that have since been mostly fixed.
1 Like
I guess I was under the understanding that the d coefficient doesn’t play well with the trapezoidal motion profile, but I could be wrong.
1 Like
very, minimal when the arm is on the side of gravity(ie. forward), but there is a huge jolt from -90 to -91 because of the tension in the change switching from one side to the other. It’s a lot better than when we originally switched to a wpilib control loop.
1 Like
I’m also wondering if there is a rule of thumb for the actual maximum acceleration of an frc motor, ie, if our max velocity is 106 revolutions per second, can our acceleration be double that, ie, 106 revs/ second in 1/2 second, or more than that? Is there some rule of thumb for that?
1 Like