Start up prob, too fast

I have an old Lynx arm (about 6 years old, yellow) with the SSC-32 with V1 firmware.

Couple Qs, whats the current draw? I’m using a 1 amp 6VDC switching wallwart to power it all, and get the going limp randomly when moving an axis.

And on first movement/start up (or after a go limp) moving any axis runs full speed no matter what the speed is set to. After that it runs correctly.

Others can answer questions about power draw better than I can, but I like to use a 2amp version of wall wart…

Yes, the first move will always go at an uncontrolled speed as the SSC-32 has no clue where it was before than. What I like to try to do, is to leave the robot or arm at some known initial park position, that is near if not at the place where gravity will have left it. Then when you start up, you tell it to go to your initial position. As it should not be far from where it is, you don’t see that initial jerk.

Kurt

That’s BAD, VERY BAD. I’ve been a service engineer for CNC lasers (and associated automation) for 13+ years, and on boot up/referencing, it always goes at a diminished speed, because it doesn’t know where its at.

I find this working (the SSC-32) to be unacceptable.

Please note: this is not an issue of the SSC-32. It is an issue with most hobby level servos, such as Hitec/Futaba/… Analog and most digital servos. That is they provide no way to query their current positions. The only thing that an SSC-32 does here is to generate your specified pulse every 20ms. It is the servo that then jumps to that location.

After the SSC-32 generates your first set of pulses, it has an idea where the servos should be (again it has no feedback of this from the actual servos), and when you ask for move to happen over a set amount of time, it does the calculations to change the pulse widths over that time period to get you there in a smooth fashion…

A 1 AMP power source is NOT going to be enough to run an arm - any arm. Get this Regulated Wall Pack - 6.0vdc 3.0amp and you should have the power you need. It sounds like your SSC-32 is resetting due to not enough power from the wall wart.

8-Dale

Your issue is probably due to the fact that for 13+ years you have been working with equipment using stepper motors and now you are dealing with servos. If you want to work with servo based equipment, then you will need to get up to speed on servos and how they work.

Nope. Not a stepper in the machines. All Servos. Some with DC servos others with AC servos.

Then if you are going to use “hobby” servos, then you need to get up to speed on “hobby” servos and how they work. You may also need to read up on the capabilitys of the ssc-32. Some people make the mistake of thinking a $500 hobby/educational robotic arm has the same capabilitys as a $500k industrial robotic arm. The common arm position solution is to park the arm in a resting position when shutdown, then start the arm at the same position before making any moves from the rest position. You might try the ssc-32 servo “speed” function to see if it does not require a known previous position. You can always look for solutions in the software that is controlling the ssc-32, or possibly read the voltage from the servo pot wiper to determine the approximate current position of the arm.

Yup. The ‘servo’ in hobby servo is a misnomer. It has no feedback, so its not a servo by definition. Its open loop just like a stepper. (without a tacho, encoder, resolver)

wow! :wink:

Nope!

The typical R/C servo has an integral pot for position feedback.

Alan KM6VV

Well the truth is a hobby servo does indeed have feedback, or it wouldn’t be very useful. We call it local feedback, meaning the servo has feedback so it can move to a commanded position, but the device telling it where to go does not have any feedback. You can call it unacceptable, but we do have a lot of fun making cool robot arms and legs using them.

i say… dont let the limitations stop you. :wink:

Just cross-posted over to the BM forum.

Older post, but I think I may have a solution to the fast-startup problem for R/C servos. (Isn’t there a current thread on this, I couldn’t find it).

I’ve mentioned and I’m sure others know about running servos from a desk power supply at lower voltage for initial tests in order to “weaken” or slow down servos so they don’t destroy themselves.

In talking with a UK robotics friend, he says he varies the frame or refresh rate of his servos in order to control the stiffness of the “electronic spring” effect of R/C servos. 20 mS is normal frame time, if the frame time is lengthened to 25 mS, there is a noticeable “softening” of the servo. Up to 100 mS is often useful. He varies all of his servos times, not fixed by interrupt code in the uP.

My question,
Can we add variable frame time to the SSC-32 (or BB-II for that matter) to allow a choice of frame time? That shouldn’t be too hard, assuming adequate memory time, and perhaps a handle for the parameter. Ideally it would modify groups of servos, on the fly, at a minimum even just an initial, one-time setting of the frame time would be useful.

Actually, the benefits go further then just start-up. Making a servo “softer” makes for much more complaint walking, moving arms, etc. as well.

Alan KM6VV

You may want to look into the ssc-32 servo speed function. The timed servo function requires a known previous position, but the speed function should not. My ssc-32 is not available for testing.

I knew about that, it helps. This would would actually make the servo “soft”.

Alan KM6VV

Um, what? :open_mouth:

No it’s still required to know where the servo is before either speed or timed moves can be achieved.

I am highly suspicious of the frame rate and power supply solutions. Sounds like smoke and mirrors to me. All I ever experienced when slowing the frame rate was ugly…

That is a bummer for a speed function. Current position should not be a requirement. Maybe something to modify if the firmware is ever updated.

Hi Zoomkat,

I personally don’t think there is much the servo controller can do, as it has no feedback from the servo to say where it is. All it can do is send the servo a the initial pulse of some specific width and the servo will jump to that location as fast as the servo wants to. What the Speed or Time functions do, is knowing where the servo is and where it wants to be, it can choose how much of a delta in pulse width to send to the servo for each servo pulse cycle.

That is why for example with my Rover with Arm, I would try to have the arm go back to some known rest location before it is turned off and the first command to the Arm is to move to that rest location… That way hopefully the servos don’t move very far.

Kurt