Skip to content
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

Open
peehrlich2 opened this issue Jan 18, 2020 · 1 comment
Open

MotorEncoder #10

peehrlich2 opened this issue Jan 18, 2020 · 1 comment

Comments

@peehrlich2
Copy link

In my experiments with a large Motor I found some interesting things:

  1. You can receive an update from the Motorencoders every 2 ms. Unfortunately I can´t found a specification, were I can see the official upate-rate of the Encoders. Perhaps it is possible to increase it?
  2. When you use get_Power, the calculated values are not correct.
    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!
  3. If you do a set_Power with a value more then 100 you get some strange effects: Than the Robot had delays up to 60 ms between the cycles.
  4. In https://avr.icube.unistra.fr/en/index.php/EV3.14 I found a discription, how to double the EncoderResolution from 1 degree to 0.5 degree. This would be also a cool feature in EV3RT.
@JakubVanek
Copy link
Contributor

JakubVanek commented Feb 15, 2020

  1. You can receive an update from the Motorencoders every 2 ms. Unfortunately I can´t found a specification, were I can see the official upate-rate of the Encoders. Perhaps it is possible to increase it?

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.

  1. When you use get_Power, the calculated values are not correct.
    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!

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).

  1. If you do a set_Power with a value more then 100 you get some strange effects: Than the Robot had delays up to 60 ms between the cycles.

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.

  1. In https://avr.icube.unistra.fr/en/index.php/EV3.14 I found a discription, how to double the EncoderResolution from 1 degree to 0.5 degree. This would be also a cool feature in EV3RT.

The authors have provided the source code (GPL FTW), so the changes could be ported to EV3RT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants