I am working on a robotic equatorial telescope mount.
I have some Maxon EC-max motors on hand for this. The datasheet for this motor can be found here: http://www.servovision.com/Motor1/E/177.pdf
The motors I have are a custom part based on the 48V version in this datasheet
The terminal resistance is around 4.6 ohm (gives a phase resistance of around 2.3) and a terminal inductance of 0.573mH (phase inductance of 0.286mH).
I have adjusted the resistance measurement code so that it can measure resistance in this range (increased the measurement voltage limit and set the current limit to be less than the max current that will flow through the motor).
The ODrive measured phase resistance and inductance values are:
1.567 Ohm
0.217mH
The encoder calibration works and the controller attempts to start position control but returns with ERROR_FOC_TIMING.
I have had the ODrive running this motor before I adjusted the resistance measurement as the measurement would just return 1/10 ohm. In this configuration I cant turn the current limit down to a suitable limit for this motor and it runs extremely hot.
Any ideas as to where to start looking to get this motor working?
1 Like
This motor is quite high resistance, and the currents used are very small (1’s of A). This means that you may run into resolution/noise issues on the current sensing. So you may get some benefit from increasing the current sense resolution (you don’t need 75A measurement range).
Have a look here. You can set it to DRV8301_ShuntAmpGain_80VpV to get twice the resolution.
That will help in general, but is unrelated to the ERROR_FOC_TIMING problem.
The timing problem seems to be that when switching from calibration routine to run mode, it starts at a random phase in the PWM sequence, so it may run out of CPU time in the first cycle. There are various ways to make this more robust, but the quickest fix is to try to disable the USB interface, to disable any interrupts from there (just for testing).
Try commenting out this line.
Another thing you can try is to permute this delay a little to see if that randomly makes it sync up.
If your problem persists, let’s make an issue in github about this, and either I or someone in the community (our you 
) will fix it.
Thanks for the suggestions, I will look into this over the weekend.
1 Like
I managed to get it running, mostly.
I reduced the delay you referred to from 10 to 8. With USB still running and all worked fine.
I also had to reduce the current PI controller bandwidth down significantly. I also need to make some changes to the PLL bandwidth as the velocity estimate seems to break down at low speed.
1 Like
Awesome!
What is your encoder resolution?
200 slots per rotation, so 800 pulses after decode. The low speed encoder calibration appears to work better than when I set a low speed in velocity control mode. I need to tune the position and velocity gains better too.
Ah okay, yeah that is quite coarse. I would suggest lowering the encoder PLL bandwidth, exactly like you did.
You may also wish to lower the vel_gain, especially if you are running the motor without a load: It has a very high torque constant especially with respect to it’s rotor inertia.
During tuning you can set the pos_gain very low, and/or only run in velocity control mode until everything is running smoothly.
1 Like