Powered Up motors: L vs. XL

[gyenesvi]

14 minutes ago, FoxOne said:

As for power, I'm not sure. At a glance, seems like a simple term to grasp for users, but need to understand the underlying method.

I am using it as a term to simplify / abstract away the underlying details (as I am not familiar with the correct physical terms), and also because the LWP3.0 protocol uses that term. For me it is sufficient in order to understand the core concept of speed regulation and the ability to move slowly with high torque.

[FoxOne]

1 minute ago, gyenesvi said:

I am using it as a term to simplify / abstract away the underlying details (as I am not familiar with the correct physical terms), and also because the LWP3.0 protocol uses that term. For me it is sufficient in order to understand the core concept of speed regulation and the ability to move slowly with high torque.

I see, and it's completely reasonable.

But let me elaborate on what bugs me --

1) DC motor physics is well known, and we can make certain predictions, e.g. about max power / torque vs. RPM and etc.

2) Control methods are known, too -- PWM, feedback and so on.

3) Now the interesting part -- we mix it together and something magic happens. Like we can independently set RPM and torque (well, kinda), and all other amazing things

I believe I miss something.

My point is -- can't see [yet] how sophisticated feedback and control could *increase* torque available at low speeds. Given that for DC motor stall torque is the max available torque, already.


 

[vascolp]

Nice discussion around here guys, I have learned a quite few things.

7 hours ago, FoxOne said:

IMy point is -- can't see [yet] how sophisticated feedback and control could *increase* torque available at low speeds. Given that for DC motor stall torque is the max available torque, already.

@FoxOne you are right, feedback does not magically improves torque just like that. What you have to compare is trying to control a motor speed by hand vs controlling it electronically. With electronically controled motors your efficiency improves a lot. Like for instance, trying to keep a constant speed in your car with or without Cruise control. Cruise control does a better job because it has much better sensors than you the driver, where you only have the speedmeter to watch, windows and maybe your speed sensation. Now consider a LEGO train or a LEGO crawler where your only input is what you see and compare it to what electronics can measure and how fast they can react.

In that sense, an electronically controlled motor has much more torque... being used efficiently! 

 

I also have a question: some of you might know I did this Remote Bla Bla thing, a general purpose program to control a technic hub with Lego Remote without the need for mobile. On it, I deliberately did not included a mode using the speed controls available in Pybricks because I wasn't fully aware of them. But now I want to include a mode for it! That should be something like dividing the speed of the motor in say 7 steps and having the ability to increment speed in steps by using the remote. The question is: what speed should I consider for the maximum speed of the motor? Should I use for instance RPM speed presented by philo for each type of motor? Will this work? Would I get something similar to @Toastie trains?!?!  Or are those speeds too much because those are off load speeds?

[Toastie]

11 hours ago, FoxOne said:

how sophisticated feedback and control could *increase* torque available at low speeds

OK, I am a chemist, so others surely(!) know much better, I am just telling, what I have learned - or at least believe to have learned - over the past decades - I am old

Now, the LEGO approach to control the (average) power delivered to any of their motors (for a long time already I believe, for sure with RCX, NXT, EV3, RC train, PF, PUp) is pulse width modulation, pwm, of their outputs. Yes I know, we all know that. In any case: "0% power" = 0% on-time (= 0% duty cycle) of the full DC voltage available = off; 100% power = 100% on-time = full DC voltage available at the output. [Note: The latter is not always entirely true, as my oscilloscope told me; there may be a remaining >very short< off-time barely noticeable - not important]. The term "power" is of course wrong, as the power depends on the current drawn by a device connected to the output. In an ideal, non-inductive world, that current is limited by the internal resistance of the device.

Let us assume that the current drawn at any "% power setting" is >not< limited by the electronics nor the battery feeding the electronics (again, in the ideal world ...). In this case, 50% power = 50% average on-time at the output; power is then average on-time x (max.) current flowing. The modulation frequency is well in the audible range - see Philos pages and elsewhere. The voltage supplied to the output is pulses of full DC voltage available.

The scale of 0% to 100% duty cycle is different for different devices: for RCX and others: 0 = 0% and 7 = 100% duty cycle. For PUp 0 = 0% and 100 = 100% duty cycle. But that is easily taken care of using a scaling factor for more versatile calculations (as I cannot calculate in the octal system ).

Next thing I believe to have noticed: The PUp tacho motors are operated by the hub in a way that when you set "power" = duty cycle to let's say 50%, a certain no-load (i.e. the motor is driving its axle without anything attached to it) rotation speed results (rounds per minute, rpm). This rotation speed appears to be the reference for the "speed" setting in the PUp hubs: When you set "speed" (not power) to 50%, the freely running motor seems to having the same rpm as when you set 50% power. Upon increasing the load at the axle, rpm go down, the controlling device realizes that (feedback) and increases the pwm duty cycle to let's say 60% (= higher average power) to maintain the 50% speed you wanted. And so on. You can tell the PUp hubs the max. duty cycle they are allowed to supply - I always use 100%. Long trains require quite some torque when they are starting to move (smoothly of course, i.e. no "overshooting").

And all that is of course heavily depending on the motor design. Highly down-geared motors, as the PUp L/XL motors need much less power control (as they can produce - at constant voltage or better: duty cycle (!) - quite some torque without any intervention at different loads). However, almost ungeared small DC motors, as e.g. the train motors (PUp, PF/9V) are a nightmare for constant speed train operation: On the 0-7 duty cycle scale (0 = off, 7 = 100%) at level 2 they barely produce any torque, at 3 they awake, at 4 the train jumps forward and then moves with semi "constant" speed and at 5 it derails easily . Well, I guess this is the fun part, but not for me ... Solution 1: Add more train motors. Solution 2: Use one or more L/XL motors. Solution 3: Add PID speed control, when you can reliably read in the rpm on any axle; either with a rotation sensor (RCX) or internal tacho in PUp L/XL motors. OK, I believe setting "speed" in PUp hubs invokes some kind of PI/PID control.

On my RCX powered trains, I can monitor the %duty cycle setting on the output, when the PID algorithm tries to keep the train moving at constant speed: It goes all over the place from almost 100% when climbing up, to 10% when going down and then wildly up/down when negotiating curves/switch points, as the load caused by wildly changing friction forces goes also wildly up and down.

 

3 hours ago, vascolp said:

what speed should I consider for the maximum speed of the motor

Well, as said above, either use the rpm of a freely running tacho motor at a given %duty cycle (= "power") setting on the 0-100% scale as reference. You simply read-out the tacho values at 0, 50 and 100% power and then shoot a function through the three (or more of course) calibration points - or use Philo's data. In any case you need the actual tacho values for the control algorithm. I do not know whether the tacho value is the same as rpm.

Or you create your own speed scale, provided you want to program your own algorithm or want to use one of the many available out there. I did the latter for my RCX trains, as they don't have tacho motors, but only train motors, and I am calculating the speed using rotation sensor data. The sensor sits on one of the train axles (somewhere, does not matter where when using the same wheel size on the entire train. 1 rpm = 16 ticks on that sensor and the latter is what the RCX gets as input data. This is rather coarse - and no way as good as the tacho readings on the PUp motors, but it works, when you adjust the PID parameters carefully. 

Hope that helps - but maybe not at all.

All the best,
Thorsten

Edited December 31, 2021 by Toastie

[gyenesvi]

10 hours ago, FoxOne said:

My point is -- can't see [yet] how sophisticated feedback and control could *increase* torque available at low speeds. Given that for DC motor stall torque is the max available torque, already.

I guess my initial understanding and wording was vague, but it's getting clearer. So I don't propose that it would magically increase torque above the available maximum, but only increase it momentarily on demand within that available maximum to achieve the desired speed. I imagine it works the following way. Suppose the motor has a max RPM (depending on the load), achieved when you give it max power (at max voltage or however that is achieved physically, it's not relevant). Suppose that you want to go with 50% of that RPM. Instead of simply giving it 50% power, what the controller does is that it gives it increasing amount of power, util the desired speed is reached, and keeps regulating the power (in a very fast loop) by monitoring the speed utilizing the position sensor data (this is the PID controller part). The point is that even when moving at low speed, the motor is going to move with *high enough* torque to achieve that speed (within the max torque budget).

It's true that theoretically you could do the same with a PF motor by hand, but in practise, you can't be precise enough regulating the power. For example with a heavier off-road model climbing through an obstacle, it could easily happen that you either give it too little power and your model won't move, or you suddenly give it too much power and it will move too fast, so you end up with kind of a binary control, even though the actual motor power can be regulated continuously. So in this sense, it can be hard to move it slowly when higher torque is required to achieve that. When there is little load (for example a light model on a flat surface), then it is fairly easy to do it by hand as well.

What I don't understand in this process is how the speed itself is defined. In the PU protocol it is measured as a percentage, but what does 100% mean? It's probably not the unloaded RPM, since that does not mean too much in practise, as usually the motor has varying amount of load. Maybe the motor can measure the load itself (by observing the instantaneous current?) and scale the max RPM accordingly.

[Toastie]

16 minutes ago, gyenesvi said:

What I don't understand in this process is how the speed itself is defined. In the PU protocol it is measured as a percentage, but what does 100% mean? It's probably not the unloaded RPM, since that does not mean too much in practise, as usually the motor has varying amount of load. Maybe the motor can measure the load itself (by observing the instantaneous current?) and scale the max RPM accordingly.

As said a minute ago - sorry for cross posting - this is a) up-to you or b) in the PUp case they seem to having 1:1 scaled the %speed with the %power rpm, using an internal calibration factor for tacho to rpm conversion.

Well, it does make sense to define the speed scale in that manner: It is in many cases no big difference, when you are setting 50% speed or 50% power on a geared motor, as all the PUp tacho motors are. The 100% speed setting simply means no speed control, as that corresponds already to full DC voltage at the output (so I believe). However, everywhere in between and most efficiently when you still have power reserves available. I would build my model (regardless of what type) in a way that is runs at ("your desired") full speed at PUp (or any other PID algorithm) motor speed settings of 70 ... (max.) 80% using appropriate gearing. This way you still have some reserve to control the speed at "your full speed".

Does that make sense?

Best
Thorsten

Edited December 31, 2021 by Toastie

[vascolp]

Probably on advantage of using pybricks is that Motors with sensors already have a way to set the speed of the motor (specified in deg/s) and already have PID controller implemented (check this page for instance and serch the run() method and below the control.pid()). I never tried this myself, but after this discussion I curious about it!

[FoxOne]

9 hours ago, vascolp said:

In that sense, an electronically controlled motor has much more torque... being used efficiently! 

That's what I was looking for, thanks!

@Toastie

Thanks for a thorough clarification! One additional note on a case "it holds still.. and suddenly it moves at full speed".

As I understand, this might be attributed to the fact that static friction is greater than rolling resistance. First,, motor needs to overcome static friction, so we crank up a voltage, then suddenly there's not much resistance at all with the start of a movement.

6 hours ago, Toastie said:

OK, I am a chemist

Explains your gravitation towards field testing )) I was trained as a mathematician, hence my urge to discover a proper functional dependency )).

@gyenesvi

Point taken, thanks -- granted, it's easier to control a vehicle with support of control system.

Edited December 31, 2021 by FoxOne

[Toastie]

18 hours ago, FoxOne said:

As I understand, this might be attributed to the fact that static friction is greater than rolling resistance.

Absolutely. This is the major issue with long and heavy trains - and when wanting to run such a train at low speed while negotiating curves and switch points. They get easily "stuck" due to significantly increased friction as compared to running on straights - and you need to overcome the static friction again and again. This was the main reason for me to program that PID algorithm into the RCX. Back in those days there were no tacho-, PF-L/XL motrors or anything close to that. And I wanted my trains to move slowly - it makes them look even more powerful.

Best
Thorsten