Griffin did a nice job of explaining ideas with gravity control issues. You know something about your system, and thus you don’t have to wait for feedback to start your control effort. You might have a model of your system and use that model to drive outputs before the desired position term in your PID would move it otherwise. This model could be math, or it could be taken from data.
Think about testing your arm in a number of positions, making a table of angle versus hold force, and then putting that force in as a “hold drive” outside of the PID control path. This prevents the PID system from having to wait for an error before reacting. It also means you don’t have an integrator that is already wound up when you want to start your next move.
In real world systems you might see acceleration or deceleration feed forward working with a PID, where your math model predicts how your robot would move. It might drive a “no slip” acceleration profile to drive the motors. The programmed acceleration knows the desired position at each time interval. This is fed as desired position to the PID. The PID then helps correct for errors when the predicted motion doesn’t match measured motion. In this sort of system, any work done by the PID is actually bad – your model didn’t match behavior. If you were perfect, the PID output would be zero all the time.
For your robot, this means your model doesn’t have to be perfect. A rough approximation of hold current by position will help the PID, and if you’re a bit wrong, you still have that loop to help you maintain desired position.