TMS320F28069: InstaSpin Motion position control delay/overshoot

You might refer to lab13b and lab13c, use a higher control bandwidth and increase the PWM frequency at the same time. It's better to use ST-Curve for such motion control, and you should consider the time delay to get the position command from the communication.

Hi Roman,

Based on your description, I assume you can run the motor smoothly with local AS5048A feedback and starting to experience oscillation and overshoot when switching to IMU feedback.

If that is the case, one thing you may want to take into consideration is the latency in the feedback path, especially the position signal from IMU. Can you please confirm the delay from a move to TMS320F28069M getting the signal in ISR (IMU update, position calculation, controller processing, sending through CAN...)? Also, can you also confirm the update rate of the position information?

Here are two aspects that may affect your performance:

1. With a bigger latency than local feedback, you will have to reduce the control bandwidth of your position loop. The more you can minimize this latency, the better performance you will be able to experience. (if you could, please share the latency, update rate, and controller parameters with us)
2. The inertial identification is supposed to run with load connected, please make sure this is what you are practicing.

Thanks.
Han

Hi Han.

I will describe everything that comes to mind here. If additional info is necessary please let me know.

1. Motor ID procedure (Lab2b). We tried many different combinations of parameters and always get similar results here with and without a load. Please see the video of the procedure: 

2. Inertia ID (Lab12a). Also tried many different combinations. We get similar results every time we run it. Here is the video: 

3. Move (Lab13B). It works really well. The system very precisely executes all movements. The video: 

4. Position control with IMU (modified Lab13a). We mount the IMU to the camera. IMU sends feedback via CANBUS (1Mbps) to the ESC. The system oscillates and whatever we try, nothing changes this behavior. When I started this tread, we were mounting the IMU to the frame, not to the camera. We were getting delay, as you can see from the video, posted in first message. Now we are mounting the IMU to the camera, as other gimbal manufacturers do. We tried many different combinations of settings, lower-higher position frequencies and a bunch of other things. Watch the video: 

We measured the delay of the IMU feedback. We moved the motor via Lab13b and logged both motor encoder and IMU together. The delay is around 15ms. The IMU position feedback is 100Hz. 

Here is the user config file:
4667.user_j1.h

If I missed anything, please let me know.

Thank you,
Roman

Hi Roman,

Hope you get some update on the problem. Based on our experience, with the latency on your position feedback chain, lowering the bandwidth will help stabilizing the loop or reduce the oscillation. With higher bandwidth, the same amount of time delay will translate to higher phase lag, which will affect phase margin more. If you cannot effectively reduce the delay, lowering the bandwidth will be something you will have to consider. One thing you could consider as well is to increase the INERTIA estimation result in the setting (by 2-10 times), which will normally allow you to have higher bandwidth and better performance. Thanks.

Han