Booted up old as5040 in ab mode…flawless and silent…same bluepoll same pins same code except encoder count.
https://streamable.com/rf1h88
@Adam_Donovan:
I can’t play the videos of the flaw but I had an error similar to the description.
When using AS5048 over SPI I had a random switch of direction and a rough running.
The error is not in the sensor or its communication but it is in SimpleFOC library 1.6.0.
When checking the angle position with no movement I see a constant angle reading in 1.5.0
Looks like this:
in 1.6.0 it is like this:
Angle reading is bouncing back and forth by 2PI randomly in high frequency. I’m sure it is not randomly, but I was not able to find the reason.
So going back to 1.5.0 eliminates the problem.
Probably it helps.
@Juxo thank you going to give it a try
Going back to 1.5 doesn’t seem to solve it for me. I am still running in ab mode so unless something had been dodgy in that I would also not have been able to run the as5040 nice.
We are going to dig deeper in the reg setting of the ma730 and see if that can give us any clues.
BTW I think those videos are outdating because its a free account…
A possible explanation… (just a hunch) is that you are not sampling the sensor fast enough. Lets say you are going medium speed and get the following readings (in degrees).
20 70 120 170 220 270 320 10 60 .... (inc 50 deg per reading)
The logic is fine with this because it spots the jump from 320 to 10.
But if we speed this up 4x we get
20 220 80 280 120 230 .... (inc 200 deg per reading).
This is going to seriously mess up the algorithm it won’t know which direction it’s going.
Mathematically
electrical_rpm = rpm_shaft * pole_pairs;
if (sensor_samples_per_minute / electrical_rpm < 10) then bad_things_could_happen()!
I made that 10 up but it likely to be between 3 and 10
If you were sampling at 100hz that would be 6000 samples a minute. I’m guessing the algorithm would break down for a 7 pp motor at at maybe 85 to 250 rpm. My maths probably needs checking
Hunch #1 (above) can be fixed by calling motor.move(x) more often. Not sure if you are familiar with nyquist theorem/undersampling but that is what I’m describing.
I have anothe similar hunch. Hunch #2 is to call motor.loopFOC() more often. I’m thinking the latter is more likely to cause change in direction. loopFoC is trying to keep magnetic field 90degrees ahead and at higher speeds this is harder to do.
Obviously calling move and loopfoc more often is typically not possible without changing mcu or code optimization.
What speed is your mcu? What is the tim period that your main loop() takes? What is the erpm where things go bad.
Wrt v1.5 and 1.6 can you measure loop time for each. Perhaps 1.5 is a little faster.
Hey Owen thanks for thinking about it:). I think probably it was hysteresis. Seeing as the ma730 doesn’t actually allow you to change those values I will consider it not suitable for the moment. I did however now test the as5047u with our setup and it’s fine…does the job. Weather or not it’s quieter that the i2c sensor I’ll keep testing but so far it is not getting any errors at least. Made a quick video of it working
https://streamable.com/og9wgz
1 Like
Id like to have another go at trying to use this sensor as the small package size is very nice. I had problems with the development board that shipped with MPS and was wondering if any of you have success and are using them still? At higher RPM especially
I did re test the MA730 again yesterday in the hopes of some miracle cure but alas it’s still doing its random thing.
Hi Adam,
I’m Ted Smith, the US technical lead for MPS Sensors. For some reason, I’m unable to view your videos above. I’d like to understand what is happening with the MA730 in your application, though. Could you repost your video showing the error you’re getting?
Ted
1 Like
Hey @Ted_Smith it’s really great that you’ve offered to help @Adam_Donovan.
I’ve used ma730 at slow speeds with no problems. Can you explain what the 23hz bandwidth of ma730 means compared to ma702 (490hz) for higher speed foc velocity control?
@Owen_Williams - Basically, if you were to drive a motor “back-and-forth” with a sine wave (basically vibrating the motor), the bandwidth / cutoff frequency is where you will start to see a rolloff of the response. This is due to the backend filter. It is an IIR sliding-window type filter with position and velocity state variables. Essentially, the MA702 and MA730 are the same except that the MA730 has a much larger (16 x)* filter window, so velocity changes take longer to show through. The immediate effect of this is that during an acceleration, there is a lag depending on the rate of acceleration. At constant velocity, the lag is constant - it’s just the propagation delay which is about 8 us. To determine the lag at a given acceleration, you can just take a*Tau^2 where a is acceleration in deg/sec^2 and Tau is the time constant listed on the datasheet (proportional to the window size / bandwidth i.e. MA702 Tau is 16x smaller than MA730).
We also have the MA732 which has a configurable filter window, so you can tradeoff bandwidth vs. resolution via SPI programming. Basically, you can configure it to behave exactly like the MA702 or the MA730 or something in between.
I will say that I’ve not had much success running FOC in commercial applications with MA730; I usually sacrifice the 2 bits and use the MA702 (or the MA732) as the low bandwidth of MA730 can cause issues especially if there’s large accelerations.
I know that’s a lot of info to cram into one post, so feel free to ask any questions…
- To gain a half bit of resolution, we need to double the filter window size, so MA730 - 14 bit is 2^4 larger window than MA702 - 12 bit.
2 Likes
Hi @Ted_Smith, apologies for the slow reply. I will re upload the videos and and try and explain the problem again. Great to have someone from MPS on the forum.
I am using FOC with MA730 and high accelerations.
@Geronimo - What is your max acceleration (in deg / s^2 or rad / s^2)? We can calculate your maximum angle lag from that. I’m curious how much a typical FOC controller can handle…
Ted
Yes you are right there is a problem with accelerating with this encoder. How much acceleration did you manage to get?