Skip the alignment of the position sensor

hardware support
1

Hello
I am using a motor with an encoder and I would like to be able to skip position sensor alignment.
I think I understand that with the encoder alone I will not be able to skip the alignment of the position sensor.
The motor also has hall sensors. I can equip both for that purpose.

Thank you so much.

2

What type of encoder? If it is the type A-B (quadrature) then it is not possible to skip homing.
If absolute (such as magnetic encoder) then it is possible, you need to just record the electric zero angle and provide this during motor.initFOC.

It is not possible to skip alignment with hall sensors either.

3

is the type A-B (quadrature)

4

SimpleFOC needs to know the absolute position of the sensor (well, the electrical angle within the rotor’s rotation, but it works out to the same thing).

So the calibration on startup is required for encoders (AB type) or HallSensors or any other encoder which is not “absolute” - e.g. gives an absolute angle right after starting up.
Encoders with an Index pin can be made absolute by searching for the Index, but this also requires moving the motor. Encoders with no Index pin or Hall Sensors require the calibration to run on startup.

5

At the end of the calibration process. The motor makes a sharp turn to get into position. Is there a way to do that in a smoother way? It can be this parameter: motor.velocity_index_search = 3;

Thank you.

6

Is this in position mode?

If so, I think the motor is moving to the current target position after starting the main loop. So maybe the solution is to do this at the end of the setup:

motor.target = motor.shaft_angle;

1 Like
7

So just to confirm: I have an ABZ incremental encoder with an index signal. Because the index signal only fires when the encoder reaches the home position, the motor has to be turned during startup to find the home position before the position can be considered “absolute”. So it’s not possible to skip startup calibration with this setup even though the encoder is technically “absolute”?

1 Like
8

Yep, you’re gonna have to do the index search at the start. No other real way around it. (That I know of at least. :slight_smile: )

1 Like
9

If you use a non-backdriveable gearbox and relatively low pole count motor (i.e. not a stepper), you could probably get away with saving the position before shutting down and assuming it hasn’t moved when starting back up. Might be a few ticks off, but good enough to run until you encounter the index so you can correct it on the fly.

Hall sensors are absolute within one electrical rotation, so as long as the shaft hasn’t turned more than half an electrical revolution forward or backward while turned off, you can recover the position at startup. An absolute magnetic encoder on the shaft is no better unless the motor is mechanically limited to less than one full revolution. Otherwise the full rotations counter has the same uncertainty to it after powering off/on.

1 Like
10

Can we start in open loop for a couple seconds, read the electrical positions, then switch to closed loop?

That would create a smooth start.

I need this for my application as well (belt-driven turntable).

11

Usually it’s the other way around :slight_smile: People wanting to use closed loop to get moving and then switch to open loop for perfectly constant speed running. So far nobody has succeeded in getting that to work well.

If it’s able to start in open loop, and energy efficiency isn’t a concern, then you can just continue in open loop.

12

I do run open loop right now, and it is pretty good. Speed stability is ± 0.1%.

But I want to try closed loop to compare.

Also, I experience some speed drift as the motor warms up, which is not ideal. Over the course of 2 hrs, the speed could increase by about 0.5%

If I stay in open loop, I plan to use the hall sensors to montior speed and adjust the velocity parameter down to compensate.

13

Open loop speed is generated from the CPU clock, so it’s as precise as you can get. Does your CPU have an external crystal? The internal oscillator can vary with temperature. Most likely the measured speed from the sensor will be subject to the same drift, since it’s being measured relative to the CPU clock.

14

Yes. Specifically use the NUCLEO-G474RE because it has an external crystal.