[thatprogrammer]

Originally Posted by NotInControl

1. Uses Motion profiles so it can control the acceleration, jerk, and velocity of each joint through out the motion
2. Calculates the inverse dynamics (Toque required per time considering the dynamics of the motion)
3. Does not need to account for induced dynamics due to a moving base



Now your gravity compensated control loop, will act to counteract those forces, and if tuned well enough, , with enough finite control, it will be able to regain its position, once those forces stop acting on the manipulator, or become constant. However the point I am trying to make is to understand the limitations of the approach to know when it will work, when it may not, and to have more educated conversations based on the requirements of your strategy.

*Also, you also want to be mindful of the current draw required to hold position, and the length of time you need to do so. This requires attention to gearbox design to ensure that the efficiency of the gearbox is as high as possible in the operating window where the load is being held. While you are holding position, you will be using power, and if you require to hold that position for long durations of time, or have an inefficient gearbox a power assessment would need to be done to ensure you are not depleting your battery unnecessarily. Obviously, adding another mechanical break adds complexity to the system, and that is why control development is a marriage between mechanical, electrical, and software. Each discipline needs to be involved, and understand the limitations and compromises so the end system can behave as expected.

** Many times in control development the final system doesn't behave as expected because there were forces acting on the actual system not understood or captured in the development model, and then the system needs to be redesigned, or modified live on the hardware in the presents of the unmodeled dynamics.

This post raises some interesting points on controlling robots under
game conditions rather. I had a few questions based on your points.
1. Is there an advantage to using a motion profile with a constantly changing set-point? Obviously, the advantage of a motion profile is that you can travel over a pre-calculated path in a fairly efficient manner. How does this translate if you are dynamically adjusting your set point, resulting in the roboRIO being required to generate a new set point dynamically?

2. Points 2 and 3 (assuming you DID need to calculate induced dynamics)

2. Calculates the inverse dynamics (Toque required per time considering the dynamics of the motion)
3. Does not need to account for induced dynamics due to a moving base

Require model based controls, do they not?

Thanks for all the help in this thread! It's been really fascinating to get an understanding of how a PIDF loop can be used to linearize the PID portion of a controls loop.