Fluctuation level of reported velocity

[pleaback]

I have adapted the velocity motion control example for a CubeMars GL30 and have been monitoring the reported velocity using the built in AS5048A. After tuning the PIC values as advised, the average reported velocity of the unloaded motor matches the target well. However, the reported velocity does seem quite noisy, but I have no experience of what precision to expect.

With motor.LPF_velocity.Tf set to 0.01, a target of 6 radians/second has reported “noise” of ±3 radians/sec.
12 radians/sec ±3
24 radians/sec ±1.5
48 radians/sec ±0.5
My working assumption of the reduced noise with increased rotation rate is that the momentum of the rotor is causing smoothing.

I tried setting a motor.motion_downsample, thinking a larger time gap between position samples would increase the accuracy of the speed calculation, but it had no visible effect.

I doubt the sensor is this noisy. It has a factory installed magnet and the AS5048A has orders of magnitude higher accuracy than the noise I am seeing.

The motor cogging is going to show up as velocity noise. Am I just observing the cogging? This gimbal motor is advertised as “low cogging” and has a favourable 12N14P configuration, but there is no advertised quantification of the cogging.

What level of velocity “noise” are other people getting ?

Pete.

[runger]

Hi Pete,

I think this is a very common observation, and generally also my experience. It’s more with some motors and less with others.

@pleaback

My working assumption of the reduced noise with increased rotation rate is that the momentum of the rotor is causing smoothing.

Not knowing more about your setup I would agree that this is a good explanation. You could further test it if you add some weight (well centred) to the motor.

@pleaback

The motor cogging is going to show up as velocity noise. Am I just observing the cogging? This gimbal motor is advertised as “low cogging” and has a favourable 12N14P configuration, but there is no advertised quantification of the cogging.

I think cogging is a good candidate. Other candidates include:

• off centre mounting of either the sensor or the magnet
• mechanical inaccuracies of the motor, e.g. in the bearing
• sampling issues
• sensor noise (which we agree should be less than the error you’re observing)
• PID tuning issue

Playing with the PID and LPF can make quite a difference. In an project I’m working on that is aiming for smooth, constant speed rotation tuning the PID and LPF reduced the velocity errors from about 5% to 0.5%.
But of course raising the filter too much makes the system less responsive to changes, so it depends on your needs and application.

Cogging should show up as a regular pattern in the velocity, that repeats in the same way for each rotation. If it is cogging it should also mean that the speed measured at lower bandwidth (e.g. below the time needed for one rotation) should be more stable, while the speed within one rotation is “wobbly”…

Sampling issues (from my point of view) are caused by things like the lag you have over SPI, and the fact that we’re not running in exactly constant time-steps. Of course we account for the time in the algorithms, but doing so requires using the MCU’s clocks to measure time, which aren’t 100% accurate and are themselves subject to sampling effects.
So in sum you have inaccuracies in the measurements (due to lag, sensor error, etc) and inaccuracies in the timestamps, both of which are fairly small quantities (since we have high loop frequencies), and which are differentiated to obtain delta-Timestamps and delta-Angles. IMHO this situation can easily lead to cases where errors in velocity get amplified, and small amounts of position-jitter lead to large errors in the velocity signal.
I’ve been thinking for a while about ways to mitigate this, if indeed this is the problem people are having.

Unfortunately the AS5048A only has SPI output, so you will need a second sensor if you want to measure the velocity independently of the SimpleFOC code… with some other sensors you can use their other outputs “in parallel” to measure the velocity from another MCU/computer. Or you can use SimpleFOC monitoring to get a picture of what’s going on, but this is not ideal because the monitoring output affects the system’s performance, and also the output can only sample the signal at a much lower rate due to Serial speed limits.

Please let me know any results you find, or if you have any further questions

[pleaback]

Hi Rickard,

Thank you for your detailed and useful reply.

IMHO this situation can easily lead to cases where errors in velocity get amplified, and small amounts of position-jitter lead to large errors in the velocity signal.

I see. I imagine hardware implemented FOC benefits greatly (in terms of simplification) from regular time intervals.

Unfortunately the AS5048A only has SPI output,

There is the PWM output, but reading through this forum, the resulting precision of the PWM is problematic. I might have a go at attaching another AS5048A to the shaft and reading it with a second Arduino.

I am curious about the LPF. Applying a low pass filter to the velocity is a sensible tactic, but set too high, has the risk of filtering out real fluctuation in movement and introduces delay in the control loop. Two questions:-

1. Is there a risk of noise being introduced into the velocity calculation by the detla T being very small ? Ie a very fast control loop
2. Does the stability of the FOC control loop benefit from the LPF removing the real cogging velocity fluctuations ?

Please let me know any results you find, or if you have any further questions

Will do.

Pete.

[runger]

Hey,

@pleaback

Is there a risk of noise being introduced into the velocity calculation by the detla T being very small ? Ie a very fast control loop

From my point of view, the smaller the delta-T, the higher the error will be proportionally because we can assume the clock/clock sampling errors to be more or less constant, and not depending on the sample interval.
So from my point of view yes. For this reason we also have a min_elapsed_time setting in the sensor, which you can set to prevent causing errors by oversampling the velocity. The effect is that you will receive the same velocity as for the last call to getVelocity(). So this effectively sets a maximal sample rate for the sensor.

@pleaback

Does the stability of the FOC control loop benefit from the LPF removing the real cogging velocity fluctuations ?

I would say yes. But the effect on the control is exactly as you say - setting high LPF values smooths the velocity but makes the system unresponsive to real changes. The phase margin is then too high, and the system is quite unstable until it manages to settle. Depending on the setup it might shake itself apart before that happens .
So fixing cogging the face of a requirement for responsive control definately requires a different approach than the LPF. If the control doesn’t need to be responsive (such as for a record player maybe, which is supposed to just rotate at a set speed) the LPF can be a good solution, and you can perhaps mitigate the control problems by only changing the set-point gradually.

And I’ll also make the remark that possibly a mechanical solution (e.g. the belt and weight of the turntable in the record player example) may be easier than spending days optimising the control.