Actually, I’m using a DC power supply rated to output 4.5v and .4a, but actually outputs 6.36v and about 1.15a. That is connected to the VL connector (center) and all three jumpers between the three power connectors are installed (the VS1-VS2 and VS-VL jumpers).
All my tests have been done with only a single servo attached to the SSC-32.
After typing all this, I just went and checked the manual again, and realized that I did in fact misread one of the jumper settings. The VS-Vl, I thought was VL-VS (which is why I hooked the power up to VL). I just tried again, with the power conncted to VS1, and all the same problems are still occuring.
Thanks,
Mike
Edit: Powering the VL off a 9v battery has solved the servo holding problem. I think it also fixed the strange characters problem.
The pulse direction is still backwards from what the manual says, however. Also, I just noticed that if I command the servo to center (1500) and then force it out of that, it will return to 1500 EXCEPT when I force it past ~60degrees clockwise. Then, it thinks that that position (about 60 degrees clockwise from center) is center, and tries to stay there. I have to force it back past the actual center for it to continue to hold the center position again.
Any idea why this is requiring two power sources? My robot will have two power sources, but they will be 7.2v and 12v, with the 7.2 being stepped down to 6v and powering the servos. If the VS and VL can’t be run together, I may have a problem.
An unregulated power supplys(most wallwarts) will show an unloaded output much higher(I’ve see 12v supplies sho 18v) than they will actually provide when connected up to a circuit(loaded). If a power supply is rated at 4.5v then expect it’s loaded voltage will be 4.5 or a little LESS.
I thought of that, and checked the voltage at the terminal while the SSC was powered, and was receiving ~5.3v. Plenty to run the servos, but I guess not enough to run the electronics, and certainly not both. I’ll see if I can find a higher powered power supply tonight, and see if that fixes the problem of needing multiple power sources.
The problem of the servo only moving in one direction with command line still exists (and when it reaches max travel, it locks there and will not respond to any commands, and must be reset), as does the pulse and direction being reversed (which isn’t really a big deal, as long as they all do that). Also, the problem of the servo holding at ~60 degrees clockwise of center when it is forced there (from center) is still present, and very odd.
Hrmm…
Well, that’s half the battle…
As for the other half…
I’m not sure what’s up.
Perhaps it’s something to do with the servos that you’re using.
I believe that you mentioned that you’re using analogs before…
I’ve heard some horror stories in the past about less expensive servos.
What kind were you testing it with?
Yes, it is analog. The servo I am using right now is from a company called Blue Bird. I’ll check around and see if I can find someone with an RC plane or something to test it with. Unfortunately, this is the only servo I have at the moment, so I can’t test the SSC-32 with another servo to further pinpoint the problem.
Any other ideas for troubleshooting?
Thanks,
Mike
Edit: The servo model number is BMS-620 (high torque). I could post a link to the supplier I purchased it from, but being that it was not LM, I think that might not be such a good idea. I don’t know how they feel about posting links to other vendor’s sites. The reason I went with this servo and not one from LM is because it was the highest torque and fastest speed combination I could find anywhere, and was quite reasonably priced.
this is interesting because my second biped was built entirely out of some blue bird servos. the only problem i ever encountered was that if you sent the servo too high or low a value, it would permanantly ruin that servo. of course i was not using it on the ssc-32 but i was using an old (the original) ssc-12 from LM. how far past standard values did you go, also i can assure you that manually forcing servos into odd points can cause issue as well.
I don’t believe I sent it anything higher than 2250 (slider) or lower than 750 (again, with the slider). Because of the clockwise rotation, it MAY have thought it was moving to 3000 or more.
The only reason I forced it that far away from the position it was holding at is because that seemed the be the point where things would go bad when sending it text commands. Something about that position is wrong, but I am not sure what.
When you say that commanding it to an out of range value would permanently ruin it, what exactly gets ruined? Is it just the electronics? The motor still seems to be functioning just fine, and the electronics are only having a few issues. At any rate, I will be pulling the stock electronics out at some point and converting them to digital (to be run via the I2C bus). If it turns out that I cooked this thing somehow (or that they simply are inadequate for my needs as they are), I’ll just do that conversion to begin with.
I managed to find a friend who knows somebody with RC equipment, so I am going to try to arrange to meet with him and test this servo on equipment we KNOW works. I don’t think the SSC-32 is the problem, but without either another servo or another controller, I can’t think of any way to track down the source of these problems.
After some further experimenting, I THINK I may have tracked down the problem. It seems that if I move slowly, the servo is capapble of a full 180 degree range of motion. This works whether I slowly move the slider or whether I use text commands with small increments. I have not tested the speed or time commands, however.
If I center the servo to start and then jump to something near the edge of the servo’s range of movement (say more than 500 off of center), it tends to either lock up or only rotate clockwise from that point onward.
While trying to research this servo, I found a spec sheet that included the following information:
Dead Bend Width: 8usec
Direction: Re-clock wise/pulse travelling 1200 to 1600 usec
I’m not quite sure what this means, as I don’t know a whole lot about servos. My GUESS is that the servo may have been designed for retractable landing gear, and as such has a software limit of 1200-1600 usec, and only wants to travel in a clockwise direction. Even if this is the case, it does not explain why the pulses send the servo in the wrong direction (it CAN move counter clockwise), nor does it explain why the servo is capapble of a full 180 degree movement, as long as the slider or position commands are done slowly.
I’m not sure how the back end of the SSC-32 terminal works, but the slider MAY just increment the position the servo is at, rather than sending it an actual position command. This may be why the servo tends to react better when using the slider instead of text commands, but that is just a guess.
Any ideas or comments are welcome. I’m new to this, and can certainly use the help.
the whole wrong direction thing is not really an issue as i have encountered that many times with different off brand servos (not an issue in RC because almost every radio has a reverse switch).
i just pulled out some older blue bird servos and hooked them to the ssc-32, i found it did hunt a little at the extremes of motion but i could send it from one side to the other (~160-170 degrees) with out any trouble. it is very possible you recieved a bum servo, it happen to me once. if you ordered from balsapr.com they might take it back (they did several years back but it helps when you ordered 20 some odd servos from them) of course you do have to pay shipping
I was able to test the servo in a friend’s RC car today, and confirmed that it is the servo itself that is causing the problems, as it does all the same things when hooked into the RC system (which we know works, and tested with other servos).
Unfortunately, I was not able to test the SSC-32 with any other servos, but I’m pretty sure that it is functioning fine.
I don’t think I will bother with trying to get a replacement for this one, as I plan to upgrade all my servos to Guru’s digital servos as soon as possible (not sure when that will be). In the mean time, it functions well enough that I can test what I need to.
Well, I just started testing my full batch of new servos, and every one I have tested so far is doing the exact same thing as the original servo did. I could fairly easily believe that I received a single faulty servo, but I have already tested nearly a dozen, each with identical results. At this point, I am beginning to wonder if there may be something wrong with the SSC-32 itself.
Does anyone have ANY ideas on what I can do to fix or alleviate this problem?
Confusion… The post before this you determined “it is the servo itself that is causing the problems”, then the next post is the opposite. Can you please repeate the description of the problem so I can try and help. The thread is getting long and there was other power problems in the beginning. Do you have a real servo? Hitec, Futaba, JR or anything that you can put on the SSC-32?
In the original post, I only had a single servo. I purchassed one initially so that I could test the code I had written to interface with the servo controller.
The most recent set of posts is after acquiring 18 brand new servos, of two different model types. These servos are having the same problems that the original servo had. These problems were/are: moving in the wrong direction, and locking up in the clockwise direction when given a fast or long move command.
Initially, I was powering both the servos and the logic off a single 6v PSU. Powering the logic off a 9v battery solved the logic reset problem I sometimes had, but the other problems have persisted.
When you say “real” servo, what exactly do you mean? I have a total of 19 “real” servos, but they are not manufactured by any of the companies you list. While they are physically real, they may not be real by your standards (in terms of quality?). All my servos are manufactured by Blue Bird (which I went with because of higher power, but probably would not have, if they are indeed the problem child here).
I have tested about a dozen different servos at this point, of two different models, and they are all doing the exact same thing. I am going to try to find a better PSU tomorrow and see if that affects the behavior at all.
Could you post the code you are using so we can take a peek at it? When you say the servo is moving in the wrong direction I wounder what would happen if you instruct it to move the other way. What happens?
When you move a servo one direction, you must instruct it to move to center or to a new location or it will stay in the last position.
Forgive me if I am asking questions that you are already aware of.
I am using the LynxTerm program. I also have tested it with my own code, but the results are the same. Every result I have posted so far has happened with the LynxTerm program. It isn’t a serial communication issue.
Are you sure you removed the VS=VL jumper? This is required to completely separate the two supplies.
Sorry, sorry, sorry… I just mean we need to test your controller with a name brand servo, that’s all. However I do know the Bluebird servos will hold a position, so it’s got to be power supply related.
PSU = power supply unit? The power supply has to be a regulated DC unit. Some unregulated wall packs have way too much AC riding on the DC to be of any use. And if the supply is not powerful enough it can cause the servo to act eratic even with good pulses coming in. Even analog devices have voltage and current requirements in order to function. If you could throw a volt meter on the bus and watch it while the servos are trying to move that could speak volumes.
Yes, the VL=VS1 jumper is off the board. The other two jumpers (VS1=VS2) are installed.
Not sure if the BB count as name brand. The more I work with the them, the less I like them. I should have just ordered from you. Live and learn, I guess.
And yes, PSU is a wall power supply. I think I stole it from an old CD player, but I can’t be sure on that. I had it laying around gathering dust, and so have been using that. I think this is where the problem lies. Andy also holds this opinion. While measuring the voltage at the VS1 terminal, it stayed in the high 5v to low 6v range while idle, and dropped to the mid to high 4v range while moving slowly. When issuing a fast/long move command, it abruptly dropped to the low 2v range (roughly 2.25v) and remained there while the servo was frozen. I tested this several times, with roughly the same results. The voltages were slightly different, but that is to be expected.
So, it looks like the problem lies with the power supply. I’ll definitely be getting a replacement tomorrow, and will post again with results.
A HUGE thanks go to Andy, who helped me to build a voltage regulator circuit. Using this, I was able to solve the servo locking up issue. Now my only issue is the direction issue.
I’ve been doing some research on these servos, and it appears that they should be rotating clockwise with longer pulses, the same way that Hitecs do. That is not the case here, and I have not yet heard from the supplier I purchased them from as to whether this is normal. All 19 of my servos do this, however, so I am assuming it is, and may just be a documentation error. Either way, I can easily account for this reversal in software.
Thanks to everyone for helping me troubleshoot these issues. I am now one step closer to finishing construction on the robot.
Nuff messin round, now on to the fun!