I’m running a simple velocity motion control example with the following settings:
- Arduino Uno
- SimpleFOCshield v2
- Actuator 1 pole pair
- 500 CPR / Quadrature off
- Supply 12V
- Limit 10V
If I give it a high target velocity of ~120 rad/s it will directly start clipping between the upper and lower limit (12V to 0V). However, if I incrementally move towards that target velocity e.g. in steps of 5 rad/s, it will work OK.
It seems to work better if I do not print the phase voltage, I am able to achieve up to 150-160 rad/s.
I’m a bit lost where to look for the issue:
Am I at the limit of the arduino?
If I don’t want to use quadrature, do I have to disable the interrupts for channel B of the encoder, they seem to be redundant? If I do this I get a PP check fail, however I seem to achieve slightly higher velocity before the clipping.
I did lower the output_ramp for the velocity PID, that seem to help a bit for the large target steps.
Regardless of the steps i’ve done, I always run into this clipping at a given velocity. I’m mostly interested to understand what causes this, so I’m better aware of the limits.
Hi @marethyu ,
I would assume you’re getting there… 160rad/s is pretty good for an Uno I would say!
I would assume you can control this by setting the output_ramp low enough.
What is the speed limit on your encoder? There will be a limit there imposed either by the encoder, or the Uno (which has to complete one interrupt before the next one happens).
I’m really not 100% sure from your description, but it does sound like you might be hitting an encoder speed limit - the Uno has to process all the encoder pulses, so if you have very fast acceleration for longer periods of time you might be hitting that limit. I guess we’d have to so some maths to figure out if it is the case or not. In this case absolute sensors can be better since they don’t depend on counting impulses. On the other hand, if the encoder itself can handle it, a faster MCU, especially one that has hardware support for encoders (like STM32) would definitely be able to handle it even if the Uno can’t.
That’s expected, using the Serial port uses quite a few MCU cycles which can otherwise go to running the motor.
Thanks again for your answer. I’ve indeed tested with lowering the output_ramp and that seems to avoid this issue at lower velocities, however, it will still occur at some point.
I’ve also looked a bit further into the timings and I found this:
Velocity Motion Control Example:
- Loop time without move–> 1.3 ms
- Quad off / 100 rad/s / interrupt A&B → loop 2.7 ms
- Quad off / 100 rad/s / only interrupt A → loop 2.1 ms
- Quad on / 100 rad/s → loop up to 7.6 ms → a lot of variation + noise
The encoder that I’m using allows for 1256 rad/s, see datasheet attached:
Unfortunately, I think this is then just the limit of the loop time. I still have to look if the biggest delay comes from FOC or motion control action.
Still waiting for my STM32 board, long delivery times unfortunately.
Hope it comes soon!
With an STM32 board, you could try the hardware-based encoder driver from here. This would handle the encoder impulses with no load at all on the MCU. And the STM32 will execute the loopFOC() much faster anyway.
So I hope things should improve a lot with the new MCU setup when it arrives.