Motor Speed Ceiling

Thanks! This is actually for a part of the next iteration of that project :grinning: …just gotta get it to go fast first :stuck_out_tongue:

They are mind blowing. I know it’s not a 1:1 comparison but they’re faster than my first home computer!

I gave it a shot, but no change in behavior :confused: …for sure worth a shot!

Almost certainly something silly which will be obvious in hindsight. I’m sure I overlooked something that should be obvious.

That is a great suggestion, let me give that a go!

It doesn’t look like the voltage is being limited.
If you are sure the sensor works and is correctly aligned, you could try lag compensation.

What motor is this? Do you know the specs?

1 Like

We do have specs for the motor, but they aren’t 100% complete. I could probably find out any missing information.

Here’s what we know:

image

image

I’m pretty sure that the sensors work because I can see the signal on the scope, but I can’t speak to how well aligned they are. Is there a way for me to test that?

If it’s running smoothly and you are getting same speed in both directions, it should be OK.

1 Like

I haven’t noticed a difference in speed between the two directions, but I can check more closely :grinning:

Does anyone have any ideas

I gave this a shot and it gets up to a very consistent 130 rad/sec when free running, but I can’t seem to get it to go faster by tuning parameters.

This would be the same as above, right? Just passing the motor constructor the poles, resistance, kv, and inductance?

Any ideas on why it might stall as the voltage goes up instead of going faster? I’m seeing the same thing in current control mode where if I set the target current too high the motor stops rotating entirely

Have you finetuned motor.zero_electric_angle? The auto calibration doesn’t work very well for hall sensors. It’s accurate enough for trapezoid mode, but not sine/SVPWM. I use torque or velocity mode and command the motor to spin faster than it’s able, and adjust the zero angle until top speed is the same in both directions.

Hall sensors change once every 60 electrical degrees (pi/3 radians), so pi/6 is half of a hall state change interval. Because smoothing works by extrapolating, the average angle ends up being pi/6 ahead of where it would be without smoothing, and needs to be offset backward.

Phase correction also has the convenient side effect that you can adjust it on the fly to do field weakening, which I don’t think we have an easy way of doing otherwise. You could try it (probably values between -pi/6 and 0) and see if you can reach higher speed that way. If everything is working properly, the higher speed comes at the cost of higher current consumption (some of the stator field is used to cancel out the rotor field and reduce BEMF). But if top speed remains the same, then there must be something other than voltage that’s limiting it. Loop rate is usually the prime suspect, but that’s been ruled out already.

1 Like

Yes. This will increase the speed for sure.
But there might be another additional issue.

1 Like

If you don’t mind sharing, which ESP32 board is it, and which motor?

If it’s not too expensive I’ll order such a motor and see what’s going on. It’s really mysterious!

I hadn’t messed with it, but I thought that was an excellent suggestion so I gave it a go, unfortunately it seems like the automatic calibration did a pretty good job and I wasn’t able to get much improvement (maybe 1-2 rad/sec).

The bad news is that its a custom board I threw together using DRV8316 drivers and an ESP32-S3 and it’s also a pretty obscure motor (I got it directly from the factory as a sample). The good news is that I extras of both the controller board and the motors sitting here that I can send you for free if you DM me an address :smiley: …I would really appreciate any feedback. I still feel like this is something silly that I’m doing which might be obvious to someone else.

Well I figured it out :smiley: :slightly_frowning_face:

It’s a hardware issue with my driver board.

I got my hands on a SimpleFOCshield 2.0.4 and thanks to everything that I’ve learned here (Thank You!) I was able to get the motor up and running with that shield pretty much immediately.

I still need to build a working shield that can drive two motors, but I’m sure the issue is something hardware related.

It’s weird that it kinda works but not fully. I can’t think what would cause the board to be speed limited like that other than PWM signals degrading, but they all looked good on the scope.

Do any obvious design mistakes jump out to anyone?

2 Likes

Since now you have two boards, one working, another not, you can run a very detailed differential analysis on the entire chain of signals and eventually the problem will pop out.

Cheers,
Valentine

2 Likes

Oh man - I’m glad you found it, but on the other hand hardware issues aren’t nice to find.

Looking at your schematic, it seems to me you’re using some not recommended pins:
45, 46 - not recommended for use - and does your module have Octal PSRAM?
The ESP32 pins are always very confusing to me - did you check that all the pins are really useable on your module, and their various pull-up/pull-downs aren’t causing problems?

Other than this I can’t see any obvious problems, I haven’t had time to reference the schematic back to the Datasheets…

2 Likes

It’s an ESP32-S3 module which is quite a bit more forgiving with which pins can be used for which functions than the S2 was. I’ll take a look at those on the scope to make sure they aren’t doing anything funky, but I think they should be safe to use here