I accidentally my servos. :(

I’m just starting out, and I have three 85BB’s.
Everything was working well, but… I started messing around with different rates of servo positioning, and tooled all three of my servos on one test run with no load. I assume the servos just tried to go over their limits and thats what caused the stripping, but I don’t see how my code could have caused that:

ENABLEHSERVO2
Main  
Hservo [P0\-4000\100,P1\-4000\100,P2\-4000\100]
pause 600
goto First
End

First
Hservo [P0\4000]
pause 300
goto Second
End

Second
Hservo [P1\4000]
pause 300
goto Third
End

Third
Hservo [P2\4000]
pause 300
goto Main
End

The only possibility I can think of is that maybe by changing the rate(seen in the Main block) it backgrounded that process and continued, so things got out of alignment, and it got outside of the (4000,-4000) boundary…
Any insight? I’m using the ARC-32 btw.
Theres probably something supremely retarded that I’m missing…

Anyways, I can just replace the gears, correct? Nothing else is damaged I believe. Is it worth replacing the gears with metal sets?

You can replace the gears vs. buying all new servos but I would want to make sure you figure out what’s causing the overshoot before investing in metal gears. I’m not familiar with the ARC-32 board yet, so I don’t want to provide any guesses as to what might be the problem.

I don’t understand why you have all those goto statements. You could remove all but the last goto statement that says “goto Main” and it would do the same thing.

I agree with Mike that the code could be simpler by removing the goto and end statements in the middle.

However I don’t see anything obvious in the code. Did you actually see it overshoot? I did not do a full calculation of your end points in degrees, but I think the ±4000 hservo units translates into a pulse range of 1300-1700us which is again probably something like ±15 to 20 degrees.

My guess is simply your servos did not like being jerked from one point to another. That is you are asking it to move something like 40 degrees in .1 second and then try to jerk them back 40 degrees in one servo period (.02) seconds. My quick look at the specs they can move 60 degrees in .14 seconds. So again it is just a guess, but I am thinking they did not like those quick actions and quit.

Kurt

Okay, I just replaced the gears on one of the stripped servos, I’m 95% positive I put them on correctly. But the first test code I ran:

ENABLEHSERVO2
Pause 5000
Hservo [P0\200\400]
Pause 30000

It stripped again…
I was under the impression that the third number in the Hservo command sets the number of steps to get to the position. This means the higher that number is, the slower it will go. So, I thought this was a safe bit of starting code…

Also, I noticed, every time I start up the Arc32, it moves a tiny bit, what is the point of this?

Also, I’ve been testing this gutted servo without the gears in. I’m running that same code. It starts turning at the right time, and it keeps going and it slows down as I turn the pot towards the \200\ position. Once its there, it stops, and I turn of the arc32. When I turn it on again, It does the random check turn thing, then stops. Because there are no gears, the pot is still at \200\ from the previous test. **However, after the pause it begins to spin at full-speed, as if it were very far away from the 200 position. Only by moving the pot off to the side about 20-30 degrees does it begin to slow down, so I can move it to 200 to satisfy it… Should that be expected?

edit: after a bit more testing, the action marked by ** up there, does not occur when I don’t include the third number, ie, when the code looks like this:

ENABLEHSERVO2 Pause 5000 Hservo [P0\0] Pause 30000

As the first time I stripped all of my servos was when I included that third number, and it seems to be acting strangely when I do have it now, am I completely misunderstanding that number or what…

edit2: YAY, the only gear that stripped this time was a gear that didn’t strip the first time, so I still have a complete set. :smiley:

But I still need to know whats going on…

edit3: is petroleum jelly okay for greasing replacement gears?

edit4: Got a question, I was looking back at the arc32 manual, and it says that Hservo is a background command. What happens if you run 2 contradicting Hservo commands at the same time?

Hservo [P0\-1000]
Hservo [P0\1000]

Would it just cancel the first one?

you probably need to use something like lynxterm to carefully test your servos after reassembly. If the output gear with the travel stop is not replaced properly, then the servo may hit the travelstop and strip a gear. Use lynxterm to carefully check the servo travel limits so you don’t exceed them.

I’m not sure if there is something like that for the ARC-32, but I still can’t get the speed setting to work… I replaced the gears on all of my 85BB’s, and now whenever I don’t set the speed, it works fine, but when I say something like [P0\1000\10] It should never move fast at all, correct? Instead, When I run it, It quickly moves to one side, then inches its way back slowly. There was no load. Unless I’m mistaken, a command like that should make it move once, slowly, in a single direction. Instead, it moved quickly, at varying speeds, in multiple directions…

Here is the code I ran:

ENABLEHSERVO2
Main
Pause 10000
Hservo [P0\1000\10]
Hservo [P1\0]
Hservo [P2\0]
goto Main

I took a video of this code stripping the P0 servo… I’ll upload it in a bit.

I don’t know anything about the ARC-32, but with the ssc-32, certain commands won’t work as expected until the servo has been put in an initial position. The chip has to know this position for the chip to be able to make timed moves and such to a new position.

Yep, I believe the Arc32 and most other processors will do the first move in more or less zero time. So it is always best that if you know the rest position for the servos to first tell them to go there…

Kurt

Sorry, I was gone for the weekend, and still haven’t uploaded the video, but I’m pretty sure what’s happening isn’t what you described. When I upload the video, you can see the servo acts really strangely and irrational(according to me…). Does the port of the phoenix V2.0 to BM IDE, use the speed setting that has been causing my problems? I plan to use it… but I need to know if this is an actual problem first…

edit: mk you should be able to watch the clip youtube.com/watch?v=gxkDcxOTcQE <-there, after its finished processing in and 30 mins or so

There’s not a lot of ARC-32 problem / cause data yet, but it sounds like it could be hardware associated with low power. Are you by chance trying to power everything from a single supply? It could be that the supply can’t deliver the needed current. When servos are instructed to move they draw more current. If the supply can’t deliver this amount the result is the voltage lowers. If it lowers too much the microcontroller resets. You can imagine how much weirdness can happen if the microcontroller is continuously resetting… :wink:

Well, its a 6v 2A power supply I got from you guys, and I’ve been able to run the regular Hservo command without speed adjustment on all three servos simultaneously with no problems. Its only when I mess with the speed that it acts weirdly…
Heres the video. I run the same program twice, the first time it acts strangely, the second time it strips the servo.

I started off by saying it might be power related. It might not be power related. I only had a few words to go by. :wink: The wall pack we sell is a good one. And I agree it should power your project as described. I do not know what regulator is on the ARC-32. I would expect it to have a low dropout regulator, but don’t know. They have a way to power the servos separately on it right? This could be a good troubleshooting step. Servos draw more or less current depending on the amount of work they are doing. That and the erratic comment is why I started the power supply conversation.

Just looked at the video. It’s not power related.

So any ideas on how I can fix this? I’m probably going to be running the Phoenix code, which appears to rely exclusively on the speed variable. Is it possible my board is just defective? Its hard to imagine that I’d still be able to run servos without speed settings perfectly, and change LED outputs and everything. Perhaps is a compiler issue? I can try running it from another computer with XP… I don’t want to burn through more gears though. :neutral_face:

For testing you might want to get a pair of diodes like below and put them in series in the power to the servo. This should drop the voltage low enough to prevent gear stripping until you resolve the problem. Mal formed pulses sent to the servo can cause it to rotate until it hits the shaft hard stop and possibly damages it self.

radioshack.com/product/index … Id=2036269

The first HSERVO command should set all the initial positions of the servos. Do NOT use a speed argument with this first HSERVO command. If you do the hservo command will think the servo is currently at 0(which is all the way to one side and then some) and will move back to your specified position at the specified speed. This is what caused your described problem above.

The onboard regulator of the ARC-32 is a low drop regulator. Also the onboard electronics will run as low as 3v so even if the input battery goes lower than the regulator requires you will still be able to run for quite some time.

You can have seperate batteries on the ARC-32 for logic and each Servo rail as well.

But based on the servo the problem is your are trying to use a speed argument on the first set position.

:blush: I should have known that! :blush: Sorry…

Excellent! Work perfectly (again). :smiley:

Nothing to be sorry about. It’s brand new stuff so there is a learning curve. Even for old hats like you. :slight_smile:

Anothering thing about the voltage and the onboard regulator. I’ve already experimented with supplying Vdd directly with as low as 2.9v, bypassing the regulator(you don’t need to do anything other than put the power straight into a Vdd pin). the ARC32 seems to work fine all the way down to around 2.95 volts. I was doing this experiment because I needed to test a 3.3v GPS module. The BasicAtomPro modules should also work down to around the same voltage without trouble.

Jim isn’t that old, or is he? :wink:

That sounds great, meaning that the board could be supplied with only one single LiPo cell :smiley: