Inacccuracy in Speed measurement
w4ff3l opened this issue · 8 comments
Speed measurements are jumping around alot. More particulary with increasing PWM. Is this only for me or does someone else have such measurements? At about 800 PWM i get a difference of about 3.
Yes, I have encountered this issue. This is extremely visible when trying to use multiple wheels on the same system. Each wheel tries to compensate each other and it becomes a shaky mess :D .
That sucks.. Makes the PID unusable for me :(
Well you could try implementing more precise speed measuring using hall or/and BackEMF. Or just use external encoders.
@w4ff3l you could try looking at VESC https://github.com/vedderb/bldc . Maybe they have done something better.
the speed measurements should be measured from the hall sensors. The hall sensors provide ~6mm precision, and the time measurement is from a hardware counter. So inaccuracy in measurement could only come from a delay in servicing the hall interrupt? May be worth looking at the calculations, working out the frequency of the counter, and calculating how much the counter would increase per hall change at the speeds you are talking about - 800 PWM is almost max power - can't say I ever run that high. Maybe the counter resolution is insufficient? Maybe we ARE skipping hall changes (there should be a variable which is incremented if this is the case...).
But also, you would not expect driving by PWM to produce a constant speed?
And yes @AntumArk - asking two wheels on the same side to achieve the same speed using PID control would be a challenge! I'm guessing that a 'reasonable' approach would be to use PID control on ONE pair of wheels, and PWM on the other, with some form of link from the PWM of the PID controlled pair to the PWM of the PWM driven pair, reducing the PWM slightly - i.e. only use feedback from one pair....? - thinking about it, this would indicate that for a four wheel system, a board per SIDE may be more appropriate than a board for front and a board for back - which would then mean you would add some additional modes in the firmware for this specific circumstance :). May be interesting if one board lost power or control failed though!!!!
For the measurement the Wheels were not on the ground. Is it not right to expect the same speed measurement for the same PWM if there is no tractive force working on the wheels? Edit: Or say a concstant tractive force.
no :).
everything from bearing wobble to power fluctuations ....
@w4ff3l, @btsimonh I encountered this issue during my developments on FOC branch (just freshly released). The way I solved it is as follows:
- if a counter is running between 2 Hall changes, indeed at high PWM (800), the motor speed will be around (400-500 rpm). This will results in only aprox 10 counts between 2 Hall changes. This is too low to get a proper speed resolution for feedback control.
- so, what I did is: I detect if I am in transient condition (counter is changing quickly). If it is not in transient, I sum the counts between 4 Hall changes, and use the total sum. So, now I will have 40 counts instead of 10 and this will give better speed resolution.
- If I am in transients, then I use counter between 2 hall changes, to detect fast speed changes (see implementation below)
My new FOC branch provides 3 operating modes:
- VOLTAGE
- SPEED
- TORQUE
For your application you have 4 wheels (if I understood correctly ):
-> If it is a kart you sit on, I would go for TORQUE mode for all wheels. This mode will make sure that the wheels are not "fighting" each other, causing wear and inefficiency.
-> If it is a robot remotely controlled, I would go for SPEED mode on all wheels to make sure the robot is not getting out of control. You could also go for TORQUE mode, but you will need to be more agile on the sticks :) It will be like with quad-copters: the difference between Stabilization mode, and Acro 3D mode.