ev3dev-lang-python: Motor speed_sp problem
- ev3dev version: 4.4.19-15-ev3dev-ev3
Almost all of the many problems I was having have evaporated over the last few days but I still have a couple of problems with motors:
- Speed_sp has units of tacho counts per second which is equivalent to degrees per second for the EV3 motors. This seems to work well for higher values of speed_sp (900, for example) but seems to be extremely inaccurate for me for low values of speed_sp such as 100. If I run a large motor at speed_sp = 900 for 10 seconds I get 25 rotations, as I should (9000/360=25). If I run a large motor at speed_sp=100 for 36 seconds I should get 3600 degrees or 10 rotations but in fact I get 12.25 rots which is a ‘huge’ 22.5% error. What’s going on? I’ve tried this with two different large motors and a medium motor and get the same result every time. Here is my script:
#!/usr/bin/env python3
from ev3dev.ev3 import *
from time import sleep
m = LargeMotor('outB')
m.run_timed(time_sp=36000, speed_sp=100) # should turn 3600 degrees or 10 ROTS
# but turns 12.25 ROTS 12.25/10= 1.225 so 22.5% error!
sleep(40)
- The documentation does not indicate what is the usable range of values for speed_sp, even though this information is more or less essential and cannot be obtained using max_speed because the theoretical maximum speed is in fact unobtainable. I assume the speed_sp range is not given because it varies from one type of motor to another, but you could at least give it for the EV3 motors. My trial and error experiments suggest that the maximum usable value for speed_sp for the large motor is about 950. Can you confirm this? (Max_speed returns 1050.) Values of 1000 used more than once consecutively can ‘disable’ the motor until a much lower value (such as 900, but not 950) is used again, according to my experiments. For example, if I run the following script with a large motor the speed_sp=900 runs fine but only the first speed_sp=1000 run works – the second attempt fails and the motor does nothing. UPDATE: As indicated in a later message, this appears to be a problem when stop_action is ‘coast’ or ‘brake’ but not when it is ‘hold’.
#!/usr/bin/env python3
from ev3dev.ev3 import *
from time import sleep
m = LargeMotor('outB')
m.run_timed(time_sp=5000, speed_sp=**900**)
sleep(7)
m.run_timed(time_sp=5000, speed_sp=**900**)
sleep(7)
m.run_timed(time_sp=5000, speed_sp=**1000**)
sleep(7)
m.run_timed(time_sp=5000, speed_sp=**1000**)
sleep(7)
For the medium motor the maximum usable speed_sp is about 1450. Can you confirm this? It is NOT ok to use a value of 1500 according to my tests. Max_speed returns 1560.
- I’m interested in helping beginners move from EV3-G to EV3 Python so I’d like to help them understand the relationship between EV3-G’s power setting (-100 to +100) and EV3 Python’s speed_sp and duty_cycle_sp values. When I tell EV3-G to rotate the large motor 100 rotations at 100% power it takes 38 seconds which gives 100/38= 2.6 rot/s or 158 rot/min or 950 deg/s. This matches nicely with my observation that the maximum usable value of speed_sp is about 950 and that using a value of 1000 or more is certain to cause problems.
When I tell EV3-G to rotate the medium motor 100 rotations at 100% power it takes 24 seconds which gives 100/24= 4.17 rot/s or 250 rot/min or 1500 deg/s. This matches quite well my observation that the maximum usable value of speed_sp is about 1450, but I believe that a value of speed_sp = 1500 is not reliable in ev3 Python even though the corresponding speed is attainable in EV3-G.
Perhaps I will also carry out some tests to see the correspondence between duty_cycle_sp and speed_sp.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 27 (16 by maintainers)
I have already said what I think at https://github.com/rhempel/ev3dev-lang-python/issues/220#issuecomment-249761040. The max speeds are already set to the empirically determined speed with no load at 9V. After quite a bit of discussion several years ago, this is what @rhempel and I settled on because it really is the maximum speed possible and is an easily measurable benchmark for future motors.
If you want to translate speed to % of max speed obtainable under some other conditions, I would suggest making a function that scales 100% to
max_speed * 0.7
or something like that rather than changing the drivers.There is no harm really. But since it is physically impossible to go faster, there is no harm in constraining either.