Can I reuse the hall sensors in a brushless motor as an encoder?

Question

I have upgraded the motors in my robotic arm to sensored, brushless RC car motors. The hope was to reuse the Hall sensors to double as a rotary encoder, by tapping 2 Hall sensors and treating the 2 bits as a quadrature signal (a crude quadrature since 2 of the 4 states will be longer than the other 2).

This works when none of the motor phases are powered and I just rotate the motor manually. But once the stator coils are energized, the encoder no longer counts correctly: When running at low power, the counting is correct, but when running under high power, the count is monotonic (only increases or decreases) no matter if I run in reverse or forward.

I'm almost certain this is because of the stator coils overpowering the permanent magnets on the rotors. So is there still a way to use the Hall sensors as an encoder?

Sorry if this is an obvious question. I'd love to research this problem more if I had more time.

Update: I've measured the wave forms with my DSO quad and see the expected 120 degree separated signals (the measurement for phase C gets more inaccurate over time because I only had 2 probes, so I measured phases A & B first, then A & C, and then merged them.

When ESC speed is 0.1:

When ESC speed is 0.3:

Previously, I was using a hardware quadrature counter (EQEP module on a BeagleBone). At speed=0.3, this was counting backwards no matter if I do forward or reverse!

I then implemented quadrature counting on an LPC1114FN28 uController. The result was still bad at high speeds (count didn't change at all). The logic was:

void HandleGPIOInterrupt()
{
  const uint8_t allowableTransitions[4][2] = {1, 2, 3, 0, 0, 3, 2, 1};
  static int prevState = -1;
  int state = phaseA | (phaseB * 2)
  if (prevState != -1)
  {
    if (allowableTransitions[prevState][0] == state)
    {
       ++rotations;
    }
    else if (allowableTransitions[prevState][1] == state)
    {
      --rotations;
    }
  }
  prevState = state;
}    

Then I got the idea to change the code to not update prevState until an expected state happens (to deal with glitches):

  int state = phaseA | (phaseB * 2)
  if (prevState != -1)
  {
    if (allowableTransitions[prevState][0] == state)
    {
       ++rotations;
       prevState = state;
    }
    else if (allowableTransitions[prevState][1] == state)
    {
      --rotations;
      prevState = state;
    }
    else
    {
        // assume transition was a glitch
    }
  }
  else
    prevState = state;

Now the counting finally is correct in both directions, even at speeds higher than 0.3! But are there really glitches causing this? I don't see any in the waveforms?

Answer 1

I would think you should be able to. I've used magnets and reed switches in a similar application for a speed sensor which uses the turns to calculate speed much like an encoder and it worked perfectly. The hall sensor should behave in a similar way.

Answer 2

I've figured out the problem a while ago. It turns out to be a power supply problem. I'm using a computer power supply (Antec HCG 850M) with the under voltage & over current protections removed, so it doesn't trip.

There was also another huge problem I didn't mention. The motor was randomly stopping and starting several times a second.

Then I saw that the electronic speed controller I'm using only had a 330uF filter capacitor. It was also was very hot to touch, despite being a low resistance, electrolytic polymer capacitor. After replacing it with a similar 1000uF capacitor, the problems are gone.

Answer 3

Yes, I am a technician who works on stabilized camera gimbals for drones and we use hall effect sensors as encoders on our camera gimbals. You must mount the hall effect sensor IC facing toward the motor pole in the rear side of the motor as close as possible without touching. This will detect the magnetic flux as the motor shaft rotates. This works very well for DC brushless motors, I cannot guarantee that it will work as well for any other type of motor.