-
Notifications
You must be signed in to change notification settings - Fork 113
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
[RSDK-2226] audit GPIO servo code #2283
Conversation
…ith silhouette consistency
// before going high afterwards. Let's stay low for at least minUs microseconds, and make sure | ||
// the frequency is slow enough that we can do this. | ||
if maxFrequency := 1e6 / (minUs + maxUs); frequency > maxFrequency { | ||
logger.Warnf("servo frequency (%f.1) is above maximum (%f.1), setting to max instead", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool :) does the calculated frequency gets floored in this case? also why do minUs+maxUs if at most we should turn on the PWM for maxUs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I set the GPIO pin to high (duty cycle is 100%), it cuts power to the motor entirely. I infer that the servo needs some amount of time with the PWM signal low, so it can be confident it knows how long it was high. What's the minimum time it can be low? I dunno; probably the same as the minimum it can be high, so the period should be at least minUs+maxUs. but I just made all that up, because I don't actually know how servos work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The amount of time the signal needs to spend low is the "dead band width," and the motors I've seen so far have it in the 1-10 microsecond range. My defaulting to 500 microseconds is super overkill. I'll change this to go faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make sense i'll defer to you to select the best value but would suggest 100us to be on the safe side :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100 seems exceptionally slow, but I bumped it up to 50. You're right that 10 was probably too fast for a global maximum.
LGTM with a couple of comments, would be great to make sure the PCA board works. About the behavior does the driver find a resolution for the Orin board? if so what does it looks like? Since the search function assume hardware PWM i want to make sure the it doesn't have a weird behavior there. |
dc9bdc6
to
0a48adb
Compare
It outputs the right signal, according to the oscilloscope. but I haven't gotten the motors to move, which makes me suspect that either it's doing it at the wrong voltage, or the wrong amperage. Both of those feel outside the scope of software: I could figure out how to hook up an external power supply to the PCA board, or something else like that, but I don't see how it could possibly affect this PR.
The Orin sets the resolution to 65535, both for hardware PWM and software PWM. Software PWM makes the motor wiggle around a whole lot, even at 50 Hz, because it's still total garbage. Hardware PWM works great.
Yes, the tests on both the pi and the orin were done through app.viam.com. |
|
Important changes: - If the frequency is not specified in the config, we've always used the current frequency of the pin. However, if the pin's frequency is currently 0, we now default to a sane value (300 Hz) instead! - If the frequency is so fast that we cannot move all the way to the max position (because it would require holding the signal high for longer than the period of the PWM), lower the frequency so that we could spend the maximum time high and the minimum time low. Unimportant changes: - Don't capitalize the S in microseconds - Rename `min` and `max` to `minDeg` and `maxDeg`, to contrast with `minUs` and `maxUs` - Add more comments! - Comments: sentences start with capital letters and end with periods. PWM is capitalized. Tried with 2 different servo motors (a TowerPro SG-5010 and a Bilda 2000-0025-0503) at my desk. They both work fine when plugged into a Jetson Orin AGX, and also both work fine when plugged into a raspberry pi. I tried plugging them into a PCA9685, but suspect I need to give it an extra power source to drive the motors: I could see the PWM signal change on the oscilloscope, but couldn't get either motor to move.
Except for a few commits that added and removed debugging info along with other changes, my hope is that each commit is self-contained and this should be easy to review commit-by-commit if it's confusing all at once.
Important changes:
Unimportant changes:
min
andmax
tominDeg
andmaxDeg
, to contrast withminUs
andmaxUs
Tried with 2 different servo motors (a TowerPro SG-5010 and a Bilda 2000-0025-0503) at my desk. They both work fine when plugged into a Jetson Orin AGX, and also both work fine when plugged into a raspberry pi. I tried plugging them into a PCA9685, but suspect I need to give it an extra power source to drive the motors: I could see the PWM signal change on the oscilloscope, but couldn't get either motor to move.