rust_gpiozero icon indicating copy to clipboard operation
rust_gpiozero copied to clipboard

Servo set max pulse width math is incorrect

Open johnn01 opened this issue 4 years ago • 7 comments

    /// Set the servo's maximum pulse width
    pub fn set_max_pulse_width(&mut self, value: u64) {
        if value >= self.frame_width {

The default frame_width is set to 20, while the default max_pulse_width is 2000. However, my servo goes to 2100. I'm unable to change this because as seen above, 2100 >= 20.

To work around this, I have to set frame_width to something greater than 2100, increase max_pulse_width to 2100, and then decrease frame_width back to 20.

johnn01 avatar May 25 '20 22:05 johnn01

I will have to look into this. Thanks

rahul-thakoor avatar Jun 17 '20 05:06 rahul-thakoor

Hi there, just took a look at this and made a PR. @rahul-thakoor

Cheers!

i-jey avatar Jul 17 '20 04:07 i-jey

The particular issue mentioned originally has to do with the way we compare frame width (milliseconds) to max and min pulse width (microseconds). Working on a PR to fix it.

after-ephemera avatar Jul 27 '20 01:07 after-ephemera

hey @azjkjensen

so we should keep

                    min_pulse_width: 1000,
                    max_pulse_width: 2000,

? ie #14 shouldn't be merged but #18 merged instead?

rahul-thakoor avatar Jul 27 '20 06:07 rahul-thakoor

After some more investigation, actually neither. If we go the #14 route and use ms, the struct fields for max_pulse_width, min_pulse_width, and frame_width should all be changed to float types. These values for some servos (such as https://servodatabase.com/servo/towerpro/sg90) require more granularity.

Alternatively, we can use microseconds for these fields instead, diverging from the Python library but potentially remaining more performant and Rust-friendly. Defaulting these values to microseconds would allow us to continue to use unsigned types, avoiding floating-point arithmetic for each operation.

after-ephemera avatar Jul 29 '20 16:07 after-ephemera

hey, @AldaronLau any thoughts on this?

rahul-thakoor avatar Aug 02 '20 13:08 rahul-thakoor

@rahul-thakoor @azjkjensen How about instead of deciding between floating-point milliseconds and integer microseconds, we use the Duration type from the standard library? It seems like the perfect fit for this situation (it also avoids floating point, and in my opinion is the more Rust-friendly to do things - and not too divergent from the Python library).

AldaronLau avatar Aug 02 '20 18:08 AldaronLau