Shop OBEX P1 Docs P2 Docs Learn Events
Servo chatter — Parallax Forums

Servo chatter

jshrews23jshrews23 Posts: 8
edited 2006-03-08 13:10 in Robotics
I have been using the Boe-Bot for a few months now and am struggling with a random problem.· I have checked the Forum and can't find anything that specifically·addresses servo chattering.

I have 4 servos in their appropriate places of pins 12-15.· The most that runs at one time is two (the wheels).· When I run the smaller programs everything runs smoothly.· In a larger program (55% of EEProm memory), it will randomly skip certain areas in the program.· I think the reason is due to the servo chatter.· Every now and then the servo will 'studder' and then go off and do some other function.

I have 20ms pauses for all servo movements.· Is there an overload possibility of servos? I don't think the servos are bad because they will work with smaller programs.· The bigger program has worked before, but not on a consistent basis. Thats the key, it is not being consistent, even the errors are random. Any ideas?

Comments

  • PARPAR Posts: 285
    edited 2006-03-06 23:52
    Maybe your BS2 is resetting due to low battery voltages caused perhaps by the use of the servos and/or other drains. You state that only two servos run simultaneously; is that by design, or is that the problem (i.e., only two will actually actuate at once and more will not)? Are there any other components which "turn on" at the same time the two servos are running? Or, are the servos binding (straining) on something? Tried fresh batteries? "...go off and do some other function"? Are you saying that the Boe-Bot doesn't "start over" (reset) but rather begins to do some other programmed function (at random)?

    PAR
  • jshrews23jshrews23 Posts: 8
    edited 2006-03-07 00:07
    Batteries could be an issue, but doubtful, replaced them just awhile ago...but I will check.

    Two servos run simultaneously by design (to keep from bugs or chattering, etc.) Other componenents do not turn on while servos are running.·
    Some components I have:·2 pushbuttons (goes low when pushed),·3 line follower sensors, 4 servos

    The first signs of servo problems, yes the servos were binding or straining on something (claw design). The problem was fixed and even now without the claw servo attached, it can manfunction.· How would/could that affect the wheels if only the wheels are told to move and not the claw?

    I cannot say exactly for sure right now whether the robot actually resets or not, that is·probably the correct·assumption.· I will test for that.· Basically that is the idea, it is either reseting or randomly going to another program function.

    Thank you for your posting...I actually have hope that there could be a remedy!
    ·
  • PARPAR Posts: 285
    edited 2006-03-07 00:32
    jshrews23 said...
    ...
    Two servos run simultaneously by design (to keep from bugs or chattering, etc.)...


    ....· How would/could that affect the wheels if only the wheels are told to move and not the claw?
    So, if "by design to keep from chattering", are you saying that by design (only two wheeled servos) you do not have the problem (and only when you program all four servos to operate that you see the problem)?

    Perhaps your program logic is not what you think it is, and that the program is actually attempting to start up 3 or 4 servos?

    Post your code; maybe someone will see a different source for the problem.

    PAR
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-03-07 00:49
    jshrews -

    Place the following at the very beginning of your program:
    DEBUG "Starting"

    If you see "Starting" appear more than once during any iteration of the prgram, a RESET IS occurring.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • jshrews23jshrews23 Posts: 8
    edited 2006-03-07 00:51
    Excellent idea.

    Attached is my code.· Hopefully it is clearly documented as to what may be happening.· Obviously because there is not a visual of the robot, it may be hard to see what the statements are doing.· However, the main case here is that there is chatter with the servos.· Suggestions of problem have been:
    ·· - too many servos
    ·· - low batteries
    ·· - bad servos
    ·· - not long enough pauses for servos
    ·· - possibility of bad programming, variables getting mixed up in registers or memory

    Please let me know what you think.
  • jshrews23jshrews23 Posts: 8
    edited 2006-03-07 01:10
    Thank you Bruce and Par for your input! The program is indeed resetting! It doesn't reset at the same time or place, but it does reset.
    Now that this problem is defined, how do I keep it from reseting??
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2006-03-07 01:12
    jshrews23,

    I have experienced what you describe only when running servo's over a long distance.

    refer to this thread...
    http://forums.parallax.com/showthread.php?p=549166

    ...and look at the schematic to the servo's.
    http://forums.parallax.com/attachment.php?attachmentid=38778

    The 4.7K resistors on the servo inputs, and a 1000uF cap across the servo supply
    greatly improved the chatter that I experienced.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.

    Post Edited (Beau Schwabe (Parallax)) : 3/7/2006 1:47:54 AM GMT
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-03-07 01:43
    jshrews -

    Before I answer your question, are you using pin port 16 for anything? If not, forget that I asked.

    You can approach this from a couple of different ways, but they really boil down to the same thing. What you REALLY want to know is what was the program doing JUST BEFORE the RESET occurred. Since we can't really know that with absolute certainty, what we do is one of the following:

    Method 1:

    Place numerous DEBUG statement at the primary points of the program. Then when you see "Starting" you go back to the last thing displayed as an indicator as to approximately where you were in your program, just before the RESET occurred.

    Method 2:

    If you have the spare variable space (rare, but it does happen) you can maintain a small trace log. On a piece of paper, assign each statement label a number, starting with 1 and ascending as far as you need to go. As you logically enter each statement label in your program (ex. "Refresh_Servos") you stuff the assigned number for that just prior statement label into the next available element in an array, then shift all the entries up one notch (losing the oldest one), and then proceed on. As you get to significant portions of the program, you dump the trace log and clear it, and then continue on. Then, when "Starting" is displayed, you look back at the last trace log that was dumped, for an indication as to where you were by number. This method can be real helpful if you feel an unexpected path is being taken through your program logic.

    Any of these debugging methods, when used with conditional compilation directives, can be turned ON or OFF at will, which makes it real nice, and also helps to keep the program up to speed, as much as possible.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • neotericneoteric Posts: 144
    edited 2006-03-07 14:19
    If your board is indeed resetting at different places, it is a "brownout situation."· If you have a wallwart, plug it into it.· You will see that the servos cant pull the stamp low enough to reset it.

    I had the same problem.· 5 servos on a 9 volt battery.· I finally broke down and got the servo controller from Parallax, which controls 16 servos with a seperate power source than the stamp.· Worked great.

    A tiny bit of servo use can drain a 9V battery pretty quickly, in my experience.
  • jshrews23jshrews23 Posts: 8
    edited 2006-03-08 01:03
    The new batteries worked great and yes the batteries die quickly.

    I have done some research on the servo controller board.· After what I have seen, I can not tell how much control I have over the servos.· I want to make an autonomous robot and control the servos different ways at different times.· Do I have control with my basic stamp over these servos on the servo control board?

    In other words, I don't want the servos running all the time. I want to be able to tell the servos to go faster or slower and different directions depending on the situation...all without a computer hooked up to it.· Can I do this with the servo control board?
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-03-08 08:14
    jshrews -

    When you say "all without a computer hooked up to it" do you mean "all without a PC hooked up to it", or "all without a PBASIC Stamp hooked up to it"?

    You speak of "the servo controller board" and I presume you're speaking of the Parallax Servo Controller (PSC) board below. Other servo controllers may behave differently than what it stated below.

    Some entity (PC, Stamp or otherwise) must "drive" the PSC with the appropriate commands, as it has no autonomous or "playback mode" of its own. A PBASIC Stamp is quite capable of providing these commands when correctly programmed by the user, with the appropriate PSC commands.

    I hope that answers your question, as it's just a bit unclear.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • jshrews23jshrews23 Posts: 8
    edited 2006-03-08 13:10
    My apologies! Yes I meant to do all this without a PC hooked up to the robot.·

    Yes I want the stamp to control the servos.· Is it all the same commands?

    How does the powering work? ·People have said it helps as far as not draining all the voltage, but if there is a bunch of servos all on the same board, will it not still drain the voltage?
Sign In or Register to comment.