Actually, right now I am just using the SSC-32 terminal program off the LM website. I have not even started writed any code to control my servos (yet).
The manual seems to state that the servo should hold position once it is given a command via the terminal program (as though the SSC will automatically update the pulse). Perhaps I misread that.
Thanks,
Mike
I’m not sure about your case Mike. I have not used the SSC-32 yet. As far as running servos from a microcontroller, the code example I gave should move a servo to 12 'o clock and then hold that posistion forever.
Well, even if the SSC-32 does not automatically hold a position, I’m not sure what is causing the servo to not respond correctly, or for the pulse direction to be flipped now (when I am almost positive it was the other way around earlier). The locking up issue is also pretty strange.
The strange characters displayed in the terminal window are also a bit odd, although probably not a bad thing.
Mike
Any servo position command (i.e. #0 P1500 ) will hold that servo at that position.
First, check to be sure that everything is wired in the correct direction.
Two of your problems – servos won’t hold, and the weird characters – seem to be battery related.
What type of batteries are you using?
Are you powering the logic off of VS1?
If you are, try powering the logic off of a 9V battery.
That should fix the odd characters that you’re getting (odd characters tend to appear when the terminal program has lost contact with the SSC-32’s logic chip, and you send a demand to it without it having a way to contact the SSC-32).
To fix the holding problem, first recharge your battery.
Then try to power only one servo.
If it works well after that, your problem was a lack of amperage in your batteries.
(I use BAT-08, which are 6V 1600mAh, and I get 30-60 minutes on a full charge powering 12 servos.)
I don’t know what’s causing the odd directional movements, but, hopefully, they are just another symptom of bad batteries.
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.
Nathan
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.
Thanks,
Mike
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.
nick
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.
Thanks,
Mike
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.
Thanks,
Mike
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
nick
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.
Thanks,
Mike
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?
Thanks,
Mike
I’d say, send it to Jim, and have him take a look at it.
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.
Mike
Mike,
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.
Mike
