Issues w/ 4EncoderMotor

cristian.spiescu

Hello,

I am struggling to get the 4EncodorMotor running. I'm working w/ UiFlow2. I'm pasting screenshots + Python snippets below:

1/ In normal mode, the motor speed is low fluctuates a lot. It accelerates. Then decelerates. Then decelerates more, etc. The pattern seems random to me.

encoder4_motor_0 = Encoder4MotorModule(address=0x24)
encoder4_motor_0.set_all_motors_mode(0x00)
encoder4_motor_0.set_motor_pwm_dutycycle(0x01, 50)

2/ For speed mode. For a value of 50, the motor turns smooth. If I increase it, nothing happens. If I decrease it, it does the pattern: stopped; then shock/move a bit; then stop again; then shock again; etc.

  i = 50
  encoder4_motor_0 = Encoder4MotorModule(address=0x24)
  encoder4_motor_0.set_all_motors_mode(0x02)
  encoder4_motor_0.set_speed_point_value(0x01, i)

Initially I connected only the motor pins; I thought that maybe it (either the firmware or the lib) has a "adjust after feedback" algorithm. And because the lack of the feedback => malfunction. Actually seeing that the "speed" and "position" mode have functions to control PID - in these cases feedback is mandatory.
But then I connected the encoder, and I see the same behavior. The encoder works correctly; tested with:

print(encoder4_motor_0.get_motor_encoder_value(0x01))

It updates correctly both when I turn by hand, and when the motor turns (badly, cf. above).

I mention that I have a worm gear motor like this:

I tested it w/ the lab PSU, suplying variable voltage. It runs smooth. So I exclude a malfunction of the motor.

Any hints?

Thanks!

cristian.spiescu

I bought another similar board; thinking that maybe the first one is broken. But it behaves the same way.

Playing w/ the various params, I started to observe a bit of response at my commands. For the moment it's still erratic. I observe some persistence of the board. I.e. if I run the program twice, the second time it keeps the params of the first run. I'm under the impression that a reset of the main board, doesn't reset the 4EncoderMotor board.

The joy of an IoT project is now transformed in an ugly and frustrating process of guesswork and reverse engineer of the API. ☹️ A while ago, I thought I saw people from M5stack on the forum, providing help here and there. Either I was wrong, or it's not the case any more.

felmue

Hello @cristian-spiescu

I am sorry to hear about your troubles. The forum in mainly users helping other users. That said, there a a few M5Stack people in here as well from time to time. (BTW I am not one of them.)

Unfortunately I do not have the necessary hardware to try and help you out. Sorry.

May I suggest you try sending an email to M5Stack support - I cannot guarantee any better outcome but I think it probably doesn't hurt to try.

Thanks
Felix

cristian.spiescu

Thanks for the tips @felmue 🙂.

I think I found a working recipe. My conclusions would be the following:

1/ For my motor, I am using P, I, D = 1, 0, 0. I think an even lower P coef would have worked, but the API doesn't accept it.
2/ W/ this values, I reach the maximum speed w/ speed =~30. Then if I decrease the wanted speed, the actual speed decreases as well. When I arrive at -14, the actual spin is 0. Decreasing more will make the motor turn the opposite direction.
3/ I find this negative value odd. I don't understand why it's offseted from 0.
4/ If I go the opposite direction, i.e. -50 and increase, the stop point is not -14 any more. It's about -3. So there is some kind of hysteresis effect.
5/ I'd say that the reduction of my gearbox (1:50) corroborated w/ the resolution of the encoder, pushes the PID params to the low limit.
6/ The position mode works similar to the position. However, when arriving at the set point, the motor oscillates (a lot if high speed; a bit, if low speed). So for me is no go to use this, although my use case does involve stopping at position. I'll use the speed + control it via the program; i.e. decrease it when approaching the target.
7/ I don't understand why the PWM mode oscillates. In my opinion it's a bug. I don't think the PWM mode should have used the feedback of the encoder.

So all in all, I'll be able to continue my project now. 🙂