Shop OBEX P1 Docs P2 Docs Learn Events
Servo Arm Controls — Parallax Forums

Servo Arm Controls

Justin RatliffJustin Ratliff Posts: 14
edited 2008-04-19 07:26 in Robotics
Here's a tough problem I can't get around.· My program below runs my servo motors through a demo routine of movement.· It works, but only as long as the debug statement is in the code and as long as I leave the debug window oen.· If I remove the debug statement the servos twitch, then do nothing.· If I close the debug window after it opens the program stops and the servos go dead (the arms drop).

I'd like it to run in a loop with out the debug statement effecting the program one way or another.· Any suggestions on how to do that?

Thanks for reading.· jumpin.gif -Justin·· Weyoun7@aol.com
Here is my code:

'Generic values
i· VAR· Byte····· 'loop counter, whatever

'These are for the servo routines
LEFT_HAND··· CON·· 3····· 'left wheel port
LEFT_ELBOW·· CON·· 1····· 'right wheel port
NECK········ CON·· 10····· 'neck servo
RIGHT_HAND·· CON·· 4
RIGHT_ELBOW· CON·· 7

'troubleshooting routines
DEBUG "Yul Demo is Online!",CR

Main:
FOR i = 1 TO 100
·· PULSOUT LEFT_ELBOW,879
·· PULSOUT LEFT_HAND,769
·· PULSOUT RIGHT_ELBOW,769
·· PULSOUT RIGHT_HAND,769
·· PULSOUT NECK, 765
·· PAUSE 20
·· NEXT
GOTO RArm

RArm:
FOR i = 1 TO 100
···· PULSOUT RIGHT_ELBOW, 769
···· PULSOUT RIGHT_HAND, 969
···· PULSOUT NECK, 665
···· PAUSE 20
···· NEXT
···· GOTO RArm2

RArm2:
FOR i = 1 TO 100
···· PULSOUT RIGHT_ELBOW, 569
···· PULSOUT RIGHT_HAND, 769
···· PAUSE 20
···· NEXT
···· GOTO RArm3

RArm3:
FOR i = 1 TO 100
···· PULSOUT RIGHT_ELBOW, 769
···· PULSOUT RIGHT_HAND, 969
···· PAUSE 20
···· NEXT
···· GOTO RArm4

RArm4:
FOR i = 1 TO 100
···· PULSOUT RIGHT_ELBOW, 769
···· PULSOUT RIGHT_HAND, 469
···· PULSOUT NECK, 965
···· PAUSE 20
···· NEXT
···· GOTO LArm

LArm:
FOR i = 1 TO 100
···· PULSOUT LEFT_ELBOW, 769
···· PULSOUT LEFT_HAND, 900
···· PULSOUT NECK, 765
···· PAUSE 20
···· NEXT
···· GOTO LArm2

LArm2
FOR i = 1 TO 100
···· PULSOUT LEFT_ELBOW, 769
···· PULSOUT LEFT_HAND, 469
···· PULSOUT NECK, 565
···· PAUSE 20
···· NEXT
···· GOTO Main

END

Comments

  • UghaUgha Posts: 543
    edited 2008-04-17 11:46
    Have you tried replacing the debug statement with a pause? Maybe its a timing issue (although it doesn't look like it to me, you
    can always give it a try).

    Try various ranges of 20 to 500 for the pause.

    Also, good programming style is to use PIN instead of CON when defining names for pins.


    Disclaimer: I'm a newbie, take my advice at your own risk.
  • Justin RatliffJustin Ratliff Posts: 14
    edited 2008-04-18 01:55
    I tried a pause statement instead of debug and that made no change. I tried changing the pause rate, that did not make any change.

    This is plain a Basic Stamp II, I have not used PIN before like that, but I gave it shot, a run time error "Expected ':' or end-of-line" popped up when I replaced CON with PIN.

    It's weird, because when a dugbug statement is ran and as long as the debug window is open, the servos move and stay in their correct position until the code directs them to move again.

    If the debug statement is removed or the debug window is closed, the first servo will move to it's position and then instantly disengage and the robot goes limps and stops moving. But put the debug statement in and leave the debug window open and bingo-bango everything works right. Except I want to work without a debug window. =)
  • Mike GreenMike Green Posts: 23,101
    edited 2008-04-18 02:06
    What kind of power source do you have? What's its current capacity?
    Are the servos powered from the same source as the Stamp?
  • Justin RatliffJustin Ratliff Posts: 14
    edited 2008-04-18 02:13
    My power source is a 13V 1.8 amp DC power supply. The power supply does feed both the Basic Stamp and servos, but each has a regulator. I've tried differnet and seperate power sources and the results are the same. I also just now tried a different Basic Stamp II and a Basic Stamp2e rev.D and the resoluts are the same.

    I've also tried different servos and I get the same results.
  • Mike GreenMike Green Posts: 23,101
    edited 2008-04-18 02:31
    You have 5 servos that all start moving at the same time. Depending on the mechanical load, the servos could draw as much as 1A each for a total peak current of 5A. You didn't say what voltage the regulators produce or what type of regulators they are. Most TO220 regulators limit their output at 1A and also shut down when they begin to overheat. If they don't have heatsinks, the one feeding the servos could easily overheat with a 1A drain and 13V input producing (13V - 5V) * 1A = 8 Watts. I don't know what difference the DEBUG statement makes, but this behavior sure sounds like a power supply problem.
  • Justin RatliffJustin Ratliff Posts: 14
    edited 2008-04-18 11:23
    The Basic Stamp II is powered via a 1amp LDO 5volt regulator, the servos with a 9V 1amp reguator.

    To test the idea of it being power I removed all the pulsout line except for the NECK and to that port I connected a single servo with nothing connected to it (no load). I ran the program with the debug line and it work. I removed the debug line and I got the same resoults as before, the servo moves to it's first position then it stops moving.

    I thought it was a power issue at first also, but from those resoluts do you think it may still be a power issue?

    Thank you guys for your help and suggestions!
    -Justin R.
  • allanlane5allanlane5 Posts: 3,815
    edited 2008-04-18 13:05
    Yes. When Mike says "the servo's will pull 5 amps", that means a 9volt 1 amp regulator will overheat and shut down until it cools -- thus, no more servo motion.

    By the way, Servo's are designed for 5 volt to 6 volt to MAYBE 7.5 volt use. Any voltage above that will reduce servo life. If you care about that.

    The solution is to get a 6 volt 5 amp power supply and try that.

    This could ALSO be a "grounding" problem.· The BS2 supply ground wire and the 9-volt supply ground wire ARE tied together, right?· It's possible the PC cable is providing a "common ground" for both, when this is removed the the servo's don't properly recieve the BS2 signal.
  • Justin RatliffJustin Ratliff Posts: 14
    edited 2008-04-19 03:46
    Intersting idea about the grounding problem thank you for the suggestions. I've seen a lot of grounding problems, but this is not one of them. There are proper interconnects for grounding.

    I don't want to argue about the voltage requirements, but I do not believe my standard servos need 5 amps when the BoeBot and Toddler run regularly off of AA battery packs and from any specs I have seen on a AA battery they typically can't sustain even 1amp.

    My regulators are not overheating. I used the above code with all servo lines removed except for the neck servo and ran it under no load and powered it via 4 AA's at 6 volts and 6 AA's at 9 volts, any power combination I try I get the same results.

    You are right, 9 volts is above the specs for most servos. I like to run my servos closer to 9 volts, I have not killed a servo yet from that.

    The key problem for me with this code and Basic Stamp is when a Debug statement is in the code and the Debug window is left open the servos move as they should. Remove the Debug line or close the debug window and it's like the code jumps to the end statement. It's really weird to see. This should be a simple function.
  • Justin RatliffJustin Ratliff Posts: 14
    edited 2008-04-19 07:18
    A new discovery:

    Here is my new test program for the neck servo:

    i VAR Byte 'loop counter, whatever
    NECK CON 10 'neck servo
    console CON 16 'Serial I/O to PC
    cmdchar VAR Byte 'Charactor from command stream
    cmdbaud CON 3313 '300 baud

    Main:
    SERIN console, cmbaud, [noparse][[/noparse]cmdchar] 'Get the command key
    IF cmdchar = "x" THEN Serv1
    IF cmdchar = "u" THEN Serv2
    GOTO Main:

    Serv1:
    FOR i = 1 TO 100
    PULSOUT NECK, 765
    PAUSE 20
    NEXT
    GOTO Main

    Serv2:
    Pulsout NECK, 1265
    pause 100
    GOTO Main


    Ok, no debug line in this at all. But, this program lets you use a debug window or other serial terminal link to send keyboard X and U commands to the Basic Stamp to control a servo. From the windows stamp editor you can click on RUN, select DEBUG, NEW then select your COM port and set the Baud to 300. From there you can enter in an X from the keyboard and as long as the Debug window or some other terminal window is open and keeps an open connection the servo will stay at position 765 for a count of 100 even under load or if you try to manually move the servo horn it will push back and keep position 765. After it completes it's 100 count the servo goes limp and can be freely moved.

    What I now think the problem is with a debug window the Stamp is forced to enforce the position of that servo for the 100 count so it forces the PULSOUT to keep the servo at position 765 until it reached 100 in the FOR NEXT loop.

    Where as if a terminal link was not made with the Basic Stamp then in the very same FOR NEXT loop it'll move the servo to position 765 and then it think it's job is done does not follow through with the PULSOUT command for the count of 100 in the FOR NEXT loop.

    What else is interesting is if were to run the same FOR NEXT loop with a servo modified for continuous rotation, it happens to run at whatever number I give it for the duration of the FOR NEXT loop weather a debug window is open or not because a modified servo does not have the internal position feedback.

    So, what I would need is a way to program the Stamp to enforce the PULSOUT for the duration of the FOR NEXT loop on it's own without a debug window. Perhaps this why most robot arms projects use an external servo control board?

    Post Edited (Justin Ratliff) : 4/19/2008 7:23:31 AM GMT
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2008-04-19 07:26
    Justin -

    Just as an aside, you may like to know about another command to read data into a program. Take a look at the PBASIC Reference Manual, or the Editor Help File, and look at the DEBUGIN command.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Involvement and committment can be best understood by looking at a plate of ham and eggs. The chicken was involved, but the pig was committed. ANON
Sign In or Register to comment.