I’m working on a motorised aircraft throttle quadrant and I’m using an iFlight GM6208 gimbal motor with an AS5048A magnetic encoder and SimpleFOC. I’m currently using the SimpleFOC Mini v1.0 driver.
The GM6208 is a relatively high-resistance gimbal motor (around 32 Ω phase resistance), and I’m trying to get very smooth, slow movement in closed-loop position control while the motor tracks the physical throttle lever position.
At normal/faster movement the motor behaves reasonably well, but as the commanded movement becomes very slow, I get increasingly noticeable stop/start or “cogging/stiction”-like behaviour. This is particularly noticeable when trying to make the throttle follow small, smooth changes.
I’m currently using voltage-based control, without inline phase current sensing.
I’m curious if anyone here has experience using high-resistance gimbal motors for this kind of very slow, smooth closed-loop motion, and whether there are particular SimpleFOC settings or control approaches that work well.
I’m also considering adding inline current sensing (INA240 + shunt) and would be interested to know whether people think proper current/torque control is likely to make a significant difference with a motor like this, or whether I should instead be looking at a different motor/driver combination.
The goal isn’t high speed or high torque — it’s really smooth, controllable, low-speed movement with a good “throttle lever” feel.
Any experience or suggestions would be very welcome!
Edit: I also came across an older velocity_ultra_slow control mode in the SimpleFOC v1.0 documentation. It was specifically designed for very low speeds (<0.1 rad/s) and works by integrating the desired velocity into an angle target and then using a high-gain angle controller, rather than relying on the normal velocity calculation. This seems quite relevant to what I’m trying to achieve, but I don’t see this controller in the current SimpleFOC 2.x version I’m using (askuric/Simple FOC@^2.4.0). Is there a recommended equivalent approach in the current version?
That mode was equivalent to using angle mode and incrementing the target the way velocity_openloop does it. So you can still do the same thing manually, but in your case it doesn’t sound like you need the incrementing behavior. Just set target angle directly.
You could try angle_nocascade. I use it on my CNC machine in voltage control mode for fastest possible response, since the maximum speed is not high enough to need current control. Your high resistance motor is probably the same way. It needs much higher PID gains than regular angle mode. I use P_angle.P=75, I=10000, D=0
An experimental feature you could try is deadtime compensation. It improves linearity of response at low voltage, and greatly smooths out open loop motion, which is normally sort of steppy. It’s not perfect though, and usually results in a sort of “tick” at each zero crossing in open loop which you can feel if holding the motor in your hand or hear if it’s sitting on cardboard or something that can amplify it.
I have recently been FOCing around with a 10R gimbal motor with a similar aim to you; smooth low speed motion. I too do not have useful current sensors (the SimpleFOC shield I have uses very noisy Hall current sensors alas).
At low speed theory suggests back EMF will be tiny so voltage control for the inner torque loop should be fine.
I would have a look at this example because although it lacks smoothing/low pass filtering, it allows very accurate angle control: Custom control | Arduino-FOC
Like the comment above, I have my motor affixed to cardboard and you can hear the noise from the normal angle control mode. With angle_nocascade, I found it easier to get rid of the noise. It doesn’t make sense to have a velocity control loop getting in the way unless you actually need to limit velocity.
Side note: I have never understood why you would need accurate velocity control of a motor - the much more common scenario is surely angular control?
Velocity control is used for things like wheeled vehicles, drone propellers, machine tool spindles, where the total amount of movement is not critical (sometimes spindle movement is critical, like doing coordinated motion for threading, and then angle mode is used).
The regular angle mode with cascaded velocity works better with inertial loads than angle_nocascade. The angle PID outputs a target velocity proportional to the distance from the target, so velocity decreases as you approach.
Nocascade outputs a target torque proportional to distance from target, so it will continue accelerating until it goes past, and overshoot. Theoretically the D parameter can counteract that, but I’ve never been able to get any good out of it. Even very small values like 0.1 compared to I=10000 cause weird noises and instability.
But if you’re streaming target positions and expecting it to follow closely, the overshoot is always very small so the faster response can give better overall results.