Notifications
Clear all
2021-01-15 9:51 pm
why not just reverse the polarity on one of them
I certainly hope you don't mean reverse positive and negative in them, that would likely kill the servo controller embedded in the motor!
Your code sounds like it is doing exactly what you asked it to do, as you use two for-loops. It has to run through the first one before it can run through the second one. So the servos move independently.
What you need to do is realize the relationship between the two servos. When servo1 is at 180 degrees, servo2 needs to be at 0 degrees. When servo1 is at 179 degrees then servo2 needs to be at 1 degree. And so on and so on.
The relationship, mathematically, seems to be servo2 = (servo1 - 180) * -1, which does give a "negative zero" at one extreme but otherwise seems valid.
Add another variable in the for-loop that is the result of that calculation. Then drive the second servo using that variable in the same for-loop, you only would need one. The "negative zero" condition could be fixed with an if statement to detect it and produce a zero.
And, of course, you would only need one for-loop.
Hope that makes some sense!
😎
Bill
"Never trust a computer you can’t throw out a window." — Steve Wozniak
Topic starter
2021-01-15 11:14 pm
I certainly hope you don't mean reverse positive and negative in them, that would likely kill the servo controller embedded in the motor!
Thanks Bill,
Yea, that was gonna be what I would have done, had things worked better
I understand the intent behind your math, but I was only using the sweep script as a test, see, I don't really want them to sweep in the way the script is written, I want them to sorta "snap" from one almost full position (which I will have to determine after I mount them) to the opposite almost full position. My estimate is that they'll probably sweep about 140, maybe from 20 to 160 (and reverse) or thereabouts, probably less actually
It's for this thing
I won't know until I get them mounted exactly how much they need to swing, and I don't want them going slow, more like a snapish kind of action, and I'll need to mount the servos before I even figure out how long to make the arms, and, of course, where to mount them so the faceplate clears and exactly how much they need to swing
Like most of my other projects, I'm designing it as I go with a clear starting point and ending point, with the middle being kinda vague
2021-01-17 12:03 am
Do the servos have their own power supply?
I don't think you would need to keep attaching the servo to a pin in the main loop?
With a button remember in a loop it will keep reading it until you release it.
Is the button HIGH or LOW when pressed?
You can use Serial.print() to debug code.
Topic starter
2021-01-17 12:49 am
Do the servos have their own power supply?
Yes. I've got 2 servos so I needed external power. I wanted to make sure they had enough to lift the mask. Besides, running servos off the same power as the nano didn't seem a great idea
I don't think you would need to keep attaching the servo to a pin in the main loop?
I didn't need that line til I started trying to detatch them after they move, but detatching didn't work the way I expected
With a button remember in a loop it will keep reading it until you release it.
Yea, odd thing about that. I press the button, they swing, I release the button, they stutter, then I press the button again, and they swing the other way like I wanted them to, but they stutter again when I release it, so pressing the button does swap positions, but it stutters when I let go. Seems like I'm almost there
Is the button HIGH or LOW when pressed?
High when pressed, low when released... Or not now that I think about it. The button goes to ground, not to positive. Suddenly I'm not so sure
You can use Serial.print() to debug code.
Would there be anything to print with no errors ?
2021-01-17 1:02 am
What happens if you change,
if ( newButtonState == HIGH )
to
if ( newButtonState == LOW )
Topic starter
2021-01-17 9:47 am
Almost the same results with the stuttering, with the exception that the button has far less effectiveness
Holding it down does nothing, and momentary press only changes the position about 10% of the time
I also changed
toboolean oldButtonState = HIGH;
boolean newButtonState = HIGH;
Which seemed logical in accordance with your proposed edit, due to leaving it in the original configuration had very close to 0% effect
The only time in the original configuration that the button had effect was when the stutter brought the horns to a stop at one end of the swing or the other, which didn't happen often, then it just went back to stuttering. Holding it down did nothing
I suppose that would have more effect if I tied the button (D2) back to positive, but I'm not sure of the consequences of introducing power directly back into D2
2021-01-17 11:14 am
Tomorrow I will wire up a couple of servo motors and a button and see if I can figure it out unless of course you or someone else beats me to it 🙂
2021-01-17 12:25 pm
2021-01-17 12:28 pm
Tomorrow I will wire up a couple of servo motors and a button and see if I can figure it out unless of course you or someone else beats me to it 🙂
Sorry, I already had an example, just needed to tweak it 😉
Topic starter
2021-01-17 5:15 pm
Okay, this one isn't causing any stuttering, or moving, but, the serial does show it switching from "open" to "closed" on button press, or, more accurately, when I release the button, the actual press did nothing. Also, one of the LEDs on the nano briefly flashes on release as well, an indicator I suppose
I originally tried it the way you wrote it, but the button is on D2 not D8, which I expected not to work, but I tried it anyway just in case arduino has pin naming schemes anything like the pi, but it seems that 8 means 8 and 2 means 2
Then I considered how "HIGH" was written in the code, and figured, if I burn out the nano, I've got a few left and tied the button to positive instead of negative, which did nothing. This must be why the serial only prints on release of the button, pressing makes LOW, and it goes HIGH on release, so HIGH must be the normal state
This must be very close tho, cuz it's doing enough to know open and closed are related to the button. I'm trying to add a serial print to the if/then to see if it's getting that far, but it doesn't like my formatting
I'm keeping a couple of the previous sketches open along with this one, because it seems like somewhere between them should be the answer. One makes them (sorta) move with the button, one prints correctly, and one swings perfectly
2021-01-18 3:51 am
Okay, this one isn't causing any stuttering, or moving, but, the serial does show it switching from "open" to "closed" on button press, or, more accurately, when I release the button, the actual press did nothing. Also, one of the LEDs on the nano briefly flashes on release as well, an indicator I suppose
I originally tried it the way you wrote it, but the button is on D2 not D8, which I expected not to work, but I tried it anyway just in case arduino has pin naming schemes anything like the pi, but it seems that 8 means 8 and 2 means 2
Then I considered how "HIGH" was written in the code, and figured, if I burn out the nano, I've got a few left and tied the button to positive instead of negative, which did nothing. This must be why the serial only prints on release of the button, pressing makes LOW, and it goes HIGH on release, so HIGH must be the normal state
Ok, it sounds like you have a floating pin. Even though I used INPUT_PULLUP in pin mode, I also incorporated a 10k PULL_DOWN resistor on my tactile button.
This must be very close tho, cuz it's doing enough to know open and closed are related to the button. I'm trying to add a serial print to the if/then to see if it's getting that far, but it doesn't like my formatting
Yes, I think it must be the PULL_DOWN resistor, because I get no jitter at all, and works perfectly every time.
Try my full code again with the PULL_DOWN resistor in place, but first comment out the servo write statements in the functions, so just the print statements are working, so you can fine tune the debounce value first.
Cheers.
Page 1 / 2
Next