Hi , I’d like to ask a general question about servos and which type I could use for a simple toy robot project, totally new to this and this is my first dive into any kind of electronics.
I’ll have 3 servos controlling some simple arm movements and body twist. During some experiments with some 9g servos I noticed that if power was cut during the animation, it all went out of whack after power restore.
A button press starts the animation.
What can be done for it to recover it’s position after a power interrupt ?
Would an analogue servo help me out in any way ?
I’d like to return to the start position if possible, I don’t really know what’s possible here, trying to not buy things I won’t need.
When the attach() function is called a servo will normally move to its default angle, which is 90 degrees. However, if you write() an angle to a servo before the attach() then it will move to that angle
When power is restored, everything is zero or undetermined. Your code must first define everything and then configure everything to your desired setting (input, output, high, low, attach, angle).
I believe you want to restore the configuration at the time of lost power. You will never know when that will occur. You can only know that it had occurred. It might be possible for you to have a battery backup activated in time for a function to store all your desired settings in EEPROM. That changes your simple arm movement to a complex, interrupt driven, time critical, toy arm movement.
You might accept the power loss, and the restart of the program puts the arm in a defined, configured position.
I’d like the arms to be down , so just off zero a little , the maximum would be straight out as if you held your arm out straight, so around 90 ?
I haven’t properly coded anything yet , I just need advice on the operation of servos to make sure I can achieve what I want and don’t buy things I won’t need.
The final goal is independent arm movement from around “0” (arms at side) to straight out “90” , a third servo in the bottom of the body will just twist side to side , just slight movement, hopefully I can get it all smooth and slowish. I’ll also have some LEDS in the head , I’ve bought some 603’s , they are tiny , about 1mm , probably be about 5 of them. Also , the hands of the robot will rotate, I’ll be using some small geared DC motors , like N20’s. Finally … I’ll be adding some sound via an mp3 module, and some other lighting to the diorama type backdrop. So far I’ve concentrated on 3D printing all the bits I need , I didn’t think I should do anything else until I know for sure I can fit everything in. But I have been shopping and bought a few bits including a PCA9685 and a LDN something, I’ve read that I could use that for the servos , and maybe the LEDs as well ?
As I said , totally new to electronics so it should be fun and interesting
Without knowing where it is at power on, this is not possible, because to move at a lower speed, one must send intermediate positions, not just a single position. If the last known position was stored in EEPROM, you can use the method just suggested, starting from that position and moving to the desired at-rest position. But it's still vulnerable to whatever happened when the system was powered off. If, with no power, the servos move, there is no feedback to tell you where you're starting from at power on.
Yes, and he/she could have probably dealt with that by moving the servos to a known position at startup. Not having seen the sketch I can't tell and we don't really know what the requirement is, do we ?
It seems reasonable to set the servos to a known start position but, of course, if the robot is required to carry on from where it got to before the power was interrupted then a different solution is required. I would suggest that using EEPROM in that solution is not a good idea due to the number of times that it would need to be written to
As for
If you have tried write()ing to the servo before attach()ing it then you will know that it does not have to start at 90 degrees
As you said earlier, we don’t have much info from the OP. Code would be good. So I used 90 as it’s the default.
But the fact remains that regardless of what angle you use in setup, that won’t reliably stop unpredictable positioning after a power cut.
However, my main point was the one boldened. The consequences of that unwanted initial fast movement can range from trivial to annoying. My Teabag Dunker provides evidence of the latter.
But there is no need for an initial twitch, if you store position before power off, do not allow physical disruption of the servo while power is off, and start from there by writing the value to the servo BEFORE doing the attach. As was pointed out, EEPROM is not practical if you're storing EVERY position change, but most situations will analyse out to one, two, or maybe three positions that are 'resting' positions, and should be saved, while in the unfortunate case that the power goes out while moving, there is an initial twitch to whatever position was saved last.
NEEDS analysis will clarify your 'teabag dunker' situation.
I use this technique for model railroad servos controlling semaphores(3-position) and turnouts (2 position). We save only endpoints, and midpoint in the case of the semaphore. There are no, zero, cases on my layout where I could ever conceivably exceed the EEPROM write cycle limitations, as none of the devices would change more than a few tens of times per session.
About the only thing that I might envisage doing that might actually do so would be a wig-wag signal, or a sawmill cutting lumber, where hundreds of endpoints might be reached in an evening. If I ever run across such a situation, I'd probably make the animation contingent on a PIR input telling me there's a person in the area of the scene.
If you write() to the servo before attach()ing it then you can reliably position the servos after a power cut. The positioning will be predictable. What may be a problem is the speed that the servo moves at when moving to the commanded position. This could perhaps be ameliorated by defaulting the servo to a known safe position then moving it slowly to its start position
If only we knew what @atc0829 really wants to do ...
Indeed. May turn out to be yet another thread that fades out due to no feedback from the OP.
To close off our side discussion: you are right about the predictability of the start up position. I was preoccupied with the speed issue due to my very recent Teabag Dunker experience.