Stepper motor speed problems - Balancing robot

Hardware support
#1

Hey, I’m pretty new to simpleFOC but I’m trying to use it to build a balancing robot!

My setup is as follows:
Nema17 Stepper motors
AS5048a encoders via SPI
L289N Drivers
ESP32 (Using newest version of library so not the pwm issue from previous)

https://www.youtube.com/watch?v=b9eZFD8hCGE

I’ve managed to get the robot balancing with closed loop velocity control (See video). But I’m having issues when I try and move the robot or introduce disturbances as the motors seem to be quickly hitting a velocity limit at around 10 rad/s and promptly falling over.

The weird problem I’m having is that when I’m testing velocities, I seem to be able to go faster in one direction (like 20 rad/s). I’m powering the motors with a 4S Lipo and I’ve got the voltage limit set to 12V, in one direction for some reason it is ramping up to that 12V much quicker.
Has anyone else had any weird issues with stepper motors like this? Let me know if there’s any more info that might help, thanks!

1 Like
#2

@Neil_Harrison welcome!

This may be an indication that the motor and sensor are not perfectly aligned.

The initFOC function does it’s best job at working out where sensor/motor zero_electric_offset and direction but if you have low sensor resolution or high pole count (like with a stepper) it might be out.

It is possible to skip calibration and pass your own values into the function. If you print out motor.zero_electric_offset and sensor.natural_direction after calibration, you can use these as a starting point and adjust offset by ±0.05 increments until forward/reverse speeds are more even.

#3

That is awesome, this has been one of the things I wanted to try also, well done! :smiley:

I would suggest you the same thing as Owen suggested. Go to the examples and find the zero offset and the direction for both motors.
Once when you have it try to tune the zero_electrical_offset so that in the voltage mode your motor spins equally as fast in both directions. (You can maybe redo the example in utils few times examples/utils to get a good value.)

The other thing that you might try is to downasmple the motor.move() function. To leave more time to the motor to do actual foc algorithm. You should be able to balance your robot with sample times around 10ms. So that would probably mean you would have 10+ loopFOC() calls per one move() call. Which will get you better alignment of phase currents and higher achievable velocity.

#4

Thank you both! I was starting to suspect that, I’d been getting varying values for the zero offset in the calibration so I’d averaged a few of them and put that in the init function. Do you guys know how precisely the sensor has to be 2mm away from the magnet? I think I might redesign the encoder mount as I’m starting to lose trust in my current one.

I tried downsampling the move function and the motors are able to go a bit faster but they start making a lot of noise at higher speeds, that might be down to the PID tuning I guess though.

Another odd thing that might be playing a part, with the L289N driver, when the battery is not plugged in, the motors can still rotate at a low speed. Should this be able to happen? When I measure the voltage at the +12V pin of the driver when it’s only powered on the 5V pin it reads 5V too, have I messed up something in the wiring or is this normal behavior?

#5

What you can try is increasing the voltage that is used for sensor alignement: motor.voltage_sensor_align that should give the motor a bit more force when aligning to push the stator exactly where it’s supposed to go. :slight_smile:

You can try to see what is the difference in achievable velocity in between voltage and velocity mode. Maybe it would make sense to close the loop through voltage instead velocity. And that way you could even remove the move function completely.

What is your loop sample time?
Does it go under 1ms?

#6

Ah that might help, the motors don’t move very much during calibration. I’ve found the motors don’t really start up until 2/3V so this is making low speeds in voltage control difficult, hence using velocity control for balancing. I’ll try re-align the sensor and get back to you.

The loop time is usually below 1ms but does spike to nearly 2ms every so often, I’ve tried fixing this to 2ms but that didn’t seem to help too much.

#7

The L289N is quite a simple driver, and the boards are usually inexpensive and don’t implement any protections. So yes, this is expected behaviour, the 5V is back-powering the 12V rail.

And it can be a problem, depending on your setup: the motors are trying to turn from the 5V supply, and if you’re powering the whole thing via the USB port of your laptop while programming the MCU, you run the risk of drawing too much current and damaging the USB hardware.

IMHO using a powered USB-Hub between your computer and the MCU is a good idea. And one of those USB-protector plugs that displays the voltage and current drawn can’t hurt either. Mine beeps at me when the USB gets back-powered or power falls out of spec.

1 Like