Hall sensor timing issue

I updated my library to 2.0 and equipped a motor with Hall sensors and an AS5048a to evaluate the Hall implementation.
Good news: works from scratch without any problems. It’s more efficient at higher speed.
Bad news: timing seems to be suspect.

I measured a up-ramp (target vs. real speed). To prevent errors of _micros, millis and so on I used Timer2 of my Nucleo 411re.

As you can see in the table below there is a significant deviation between target and speed in hall senor mode. To be sure not to run in a precision problem I also enlarged the measurement time to more then 10 seconds with exactly the same result.

image

It seems to be the same issue that occurs in the magnetic sensor implementation I mentioned in Velocity measurement problem, magnetic sensor

Hope that helps to identify the problem

I think the previous issue was a problem with openloop velocity mode. I take it you are testing closed loop now. Are you using a Tachometer to measure real speed?

One difference between hall and magnetic is that hall needs to know the correct pole pair count to work out velocity. i.e. the wrong PP can throw out the value.

The velocity calcs for hall is pretty simple.
velocity = (_2PI / cpr) / (pulse_diff / 1000000.0

breaking this down a bit

  1. _2PI/cpr is the angle of 1 hall transition in radians. So for a 7pp motor, cpr = 7pp x 6 transitions = 42. and _2PI/cpr = 0.15 radians per transition.
  2. (pulse_diff/1000000) is the time in seconds between last 2 pulses.

This velocity discrepancy is probably either due to wrong cpr (you provided the wrong PP) or some inaccuracy in how that pulse_diff is calculated.

When I was faced with the problem the first time I also used the velocity_closedloop mode as now.
The error disappeared with version 1.6, I guess.
Also the PP issue is not an option because I used the same program for both runs. First I commented-out the magnetic senor lines and afterwards the Hall lines. In both cases I used the motor object
BLDCMotor motor = BLDCMotor(12);

So it is proven that I had always the same amount of PP provided to the motor-class.

As @Antun_Skuric sayed in September it’s not the PP. What has been the problem in V1.5? I don’t know. The only difference is that the deviation isn’t that precise but it behaves pretty similar.

Hey guys,
Yes @Juxo you’re right.
We had had a problem of measuring time in between function calls in Magnetic sensor implementation. And that was the reason of relatively constant velocity error.

I’ll look into this and let you know. This seems to be the same type of issue!

@Juxo - I’ve done a quick test asking for 6.283 rad/s and counted 121 revolutions in 120 seconds. So your 10% errors aren’t always present in all systems.

I did briefly see something similar to what you were seeing but I’m finding it hard to repeat. My suspicion is that it happens more when the integral term is ‘too strong’ - it’s like its stubbornly adds voltage when its not required.

I don’t fully understand that I term. For instance if I start with I=10 in code is then changed to I=0 (using motor.command()) I’d expect integral term to fade away but it remains active (yeh the integral adds sum of errors but it should be multipled by kI somehow IMHO)

Can you try reducing I to a low value e.g. I=1 and maybe increasing P a little. Also the halls are quite lumpy/noisy so a Tf of 0.1 or even 0.2 if you are mostly at constant speed might help.

@Owen_Williams, unfortunately I burned my last driver board last week. Currently I haven’t any possibility to test SimpleFOC issues. When I’m equipped again I will go deeper into that issue. Meanwhile I trust in you :slight_smile: