-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MotorEncoder #10
Comments
The code that controls this is in d_pwm: https://github.com/ev3rt-git/ev3rt-hrp2/blob/master/target/ev3_gcc/drivers/motor/d_pwm/Linuxmod_AM1808/d_pwm.c (the 2 ms period is here) I don't think there is any hardware limit apart from the CPU processing power & the optical resolution of the encoder. It seems that the people behind EV3.14 have done optimizations on the tacho tracking algorithm though.
Yes, this irritates me as well; however this is likely inherited from the LEGO-provided drivers. AFAIK LEGO did not do speed calculation in degrees per second, rather they used some percent speed units (calculation here).
This is strange - power is explicitly checked to be in the specified bounds (here). The syslog call might be slow, but that sounds strange to me.
The authors have provided the source code (GPL FTW), so the changes could be ported to EV3RT. |
In my experiments with a large Motor I found some interesting things:
Example: I drive a Motor for 500 MotorDegree with a constant Power. It takes 0,552998s.
So it is 500 Degree/ 0,552998s=904 Degree/s --> get_Power has to provide a value of 90 but it shows 78-79 at every time!
The text was updated successfully, but these errors were encountered: