DD-Wheel with Hoverboard Motor

Is there a specific relationship between the motor and the encoder that needs to be aligned?

Hope to see your connection combination, i hope g try

Here you can probably see. I’ll have to double check so this is the working combination though

Thank you!
I have tested this combination.
Today, I tested various combinations of uvw again and it was useless.

Just rotation direction.
By swapping either encoder AB wires or two motor wires this can be reversed.
The index pulse is not used and should not be connected to the ESC.

At ESC startup the firmware aligns the encoder (small wheel move you notice).

Understand, thank you very much!
I now use only the AB phase of the encoder.

I did an experiment, will it help to confirm the fault?
Connect the USB and turn on the power. Rotate the steering wheel to the angle limit area (mmos output pwm), then disconnect the usb connection, rotate the steering wheel to any angle, you will feel the gear torque. Connect usb again, the steering wheel loses gear torque (mmos initialization sets the current steering wheel position to the midpoint, no output pwm). Disconnect the USB connection again, rotate the steering wheel to any angle, you will feel smooth

This seems to behave as expected.

The ESC was disconnected from its PWM input at medium to high torque level.
I see three issues here.
1. If you disconnect the MMOS board from the USB port, it will lose its power supply and will not generate any PWM signal to the ESC. If there is no PWM signal, the last read value is active until PWM input resumes or some random signal received by radio interference changes it.
2. If the encoder was powered by the MMOS board the ESC looses the encoder input.
3. Or the MMOS board induces interference into the encoder wires. This will trip the ESC firmware's motor positioning loop and probably be noticeable while under heavy torque.

PWM input is restored and the ESC can resume normal operation.

The ESC was disconnected from its PWM input at low or zero torque level.
All three issues from above apply too. Last PWM input was low or zero and the wheel turns smoothly because the last torque level was low or zero.

Could it be, that the MMOS board stops PWM output if you go beyond the angle limit?

Do you still have the opto-isolation in place for the PWM wires?

Do you have any issues using the wheel if you do not hit the angle limits?

1: If the angle limit is exceeded, the MMOS board will not stop the PWM output. The wheels turn into gears.

2: I now keep optocoupler isolation (without optocoupler isolation, there will be noise. Or connect the GND of mmos and GND of ESC to eliminate noise.)

3: If the angle limit is not reached (mmos without pwm output), the steering wheel remains smooth. Once mmos has pwm output, the wheels become gears. The same goes into the game.

The encoder power supply is connected to ESC. I have not tried the encoder power supply connected to mmos.

The new video can better explain the problem

I was able to reproduce the exact same behaviour you show in the video - under the following condition. If "firmware encoder ppr" does not match "effective encoder ppr", I get the same results as you do.
I used a firmware that uses 8192 ppr instead of the correct 16383 ppr but I suspect that it would also happen if the encoder randomly loses steps.

The firmwares I sent you expects an effective encoder ppr of 2000.
Could you please double check, that this is your effective encoder ppr. Please take into account the gear ratio you might have in your setup.
Could you also please double check the MMOS encoder cpr setting. MMOS wants to know cpr which is 4 times the effective ppr value.

If you find that all values are correct, your encoder may be broken. Maybe try a different encoder or use an arduino sketch to verify that the encoder is working correctly.

Could you tell us what brand and model encoder you use?

Maybe the same problem I have with one of the encoder inputs of the ESC (A). Measure the voltage of the A and B encoder inputs of the ESC and notice if one of them have an lower High level. I solve the problem by adding a extra pull-up resistor. (10k)

I found this code and made the connection
In the first step, I mark 0 on the steering wheel and align the serial monitor number 0. In the second step, the steering wheel is turned a few times and then reversed a few times, and it is found that the number 0 of the serial monitor cannot be completely aligned with the 0 point I marked.
Judging from this, the encoder may be damaged, or it may be that the encoder and the steering wheel cannot rotate 1 to 1.

The encoder seems to be a cloned version

Code:

volatile long temp, counter = 0; //This variable will increase or decrease depending on the rotation of encoder
   
void setup() {
  Serial.begin (115200);
  pinMode(2, INPUT_PULLUP); // internal pullup input pin 2
 
  pinMode(3, INPUT_PULLUP); // internalเป็น pullup input pin 3
   //Setting up interrupt
  //A rising pulse from encodenren activated ai0(). AttachInterrupt 0 is DigitalPin nr 2 on moust Arduino.
  attachInterrupt(0, ai0, RISING);
 
  //B rising pulse from encodenren activated ai1(). AttachInterrupt 1 is DigitalPin nr 3 on moust Arduino.
  attachInterrupt(1, ai1, RISING);
  }
 
  void loop() {
  // Send the value of counter
  if( counter != temp ){
  Serial.println (counter);
  temp = counter;
  }
  }
 
  void ai0() {
  // ai0 is activated if DigitalPin nr 2 is going from LOW to HIGH
  // Check pin 3 to determine the direction
  if(digitalRead(3)==LOW) {
  counter++;
  }else{
  counter--;
  }
  }
 
  void ai1() {
  // ai0 is activated if DigitalPin nr 3 is going from LOW to HIGH
  // Check with pin 2 to determine the direction
  if(digitalRead(2)==LOW) {
  counter--;
  }else{
  counter++;
  }
  }

I will test further

That sketch might give you a little trouble since digitalRead isn't super fast. It could indicate missed steps even if MMOS could be counting them.
Maybe this can work (it uses bitRead instead):

Code:

//#include <PinChangeInterrupt.h>

const byte encoderPinA = 0;//outputA digital pin2
const byte encoderPinB = 1;//outoutB digital pin3
volatile int count = 0;
int protectedCount = 0;
int previousCount = 0;

#define readA bitRead(PIND,2)//faster than digitalRead()
#define readB bitRead(PIND,3)//faster than digitalRead()

void setup() {
  Serial.begin (57600);

  pinMode(encoderPinA, INPUT_PULLUP);
  pinMode(encoderPinB, INPUT_PULLUP);

  attachInterrupt(digitalPinToInterrupt(encoderPinA), isrA, CHANGE);
  attachInterrupt(digitalPinToInterrupt(encoderPinB), isrB, CHANGE);
  //attachPCINT(digitalPinToPCINT(encoderPinA), isrA, CHANGE);
  //attachPCINT(digitalPinToPCINT(encoderPinB), isrB, CHANGE);
}

void loop() {
  noInterrupts();
  protectedCount = count;
 
 interrupts();

  if(protectedCount != previousCount) {
    Serial.print("prtcnt:");
    Serial.println(protectedCount);

  }
  previousCount = protectedCount;
}

void isrA() {
  if(readB != readA) {
    count ++;
  } else {
    count --;
  }
}
void isrB() {
  if (readA == readB) {
    count ++;
  } else {
    count --;
  }
}

Also, when troubleshooting my encoders in the past I have used an Arduino as a simple oscilloscope. It visualizes the signals coming in in a very good way. Do you have the possibility to do this? It should work on pretty much any arduino with analog inputs I guess.

[edit] This is what I used:

Remember to have the motor output activated when you do the measuring.

Hello your code cannot work.
I use ArduinoPrintADC.ino can work, but only A0 can work. I separately test the AB phase of the encoder, which can output a square wave.
I use Arduino Nano.

I don’t understand what doesn’t work. Why only A0?

Only the A0 pin of the Arduino board can work (check the waveform).
When connecting A1-A7, the waveform cannot be read.
-------------------------------------------------

The code for this link works very well. I slowly rotate the encoder while observing that the AB phase waveform is normal.
I judge the encoder is normal.

Code address

1: Now use the encoder, parameter 2000ppr NPN voltage output. Motor and encoder rotation 1:1. mmos is set to 8000cpr.
2: Testing the encoder through the Arduino board seems to work normally.
3: After reconnecting the motor and the encoder with the timing belt, there is no error between the rotating motor and the encoder. After testing the wrong FFB problem is still the same.
3: I also bought a new encoder, parameter 1024ppr NPN voltage output.

I still suspect you have the same problem as I have with my ESC boards. Check the signals to the ESC with the motor activated. You might have a lower pullup-voltage on one of the inputs (Think it was A), and then you need to mount a extra pullup resistor.

I used pull-up resistors, and independent and combined tests of A and B did not solve the problem. (Remove the optocoupler isolation test) I have no multimeter to measure.
I estimate that there is no voltage problem with the encoder. Each optocoupler isolation module has a led. The led indicates signal input. When there is signal input, the LED brightness is normal.