Let's Make Robots!

Object tracking servo jitters... in only one direction?

I've come across a problem during the fine-tuning of my object tracker. When the "neck" servo is steadily decending positions (turning to the left) the movement is smooth, even with decrements > 1. It acts completely different when turning right. There is a distict pause between each SERVOPOS and I noticed it takes longer to process a debug cycle as well. The head shakes, rattles and rolls, the values used to adjust turning speed based on object distance are insufficient, and it just looks terrible. Like I made me a reject robot piece from a Herbie Hancock video.

Things I've done:

  • replaced the servo
  • swapped servo pins
  • checked voltages (servos on their own L7806, rest on 7805)
  • did all sorts of changes to the code to try and eliminate the hiccup
  • ran it at 8MHz
  • stared at debug endlessly

None of it changed the results. I should note that if I plug in a very simple min-position-to-max-position-sweeping program the jitter seems to go away. Maybe something in my code makes it slow? I've tried to make each direction routine exactly the same, process wise. I don't know, I've been staring at it too long. Any input would be epic.

20X2_eyes_debug_v3.3.bas2.74 KB
20X2_neck_and_eye_test.bas928 bytes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

It is probably the ping. Ping and servo gives always servo jitter if the pulse is send to the ping. Switch off the servo (set the servo pin low), before the ping pulse is send out, then use the servo command. In your case it is possible because no force acting on your servo, so the servo will not move if you set the servo pin low.

I had also some success replacing the servo cable by a three-wire shielded cable.

I have the two sensors set up in a daisy chain that constantly loops after you send a startup pulse. After the chain starts you can access the sensor values through the analog pin or measure the next pulsewidth reading (what I do). Good thinking though.

Run a little program on the sensors to determine how long they take to reset, or change readings, in milliseconds.  Then add that time + 50% as a delay just before you take your readings on the sensors.  Make sure your servo is not moving while you're doing the reading or you'll get bad data.

Remember your robot will cycle through this so quickly we will not notice the pause it takes to do the reading.

I think an average servo would take about 4 or 5 milliseconds to move 1 degree of movement (i.e. 90 to 91) keep that in mind when you're trying to take readings only when there is no movement.

The ultrasonic readings are ok, it's the servo that's gone wacky. I tried that thinking there was a timer conflict but the symptom remained.

I accidentally did a gravity test with my setup last night. Essentially everything broke or bent. Paper clips and hot glue have their pros and cons. I'll have to rebuild it before anymore testing can be done. I'll probably just assemble the final unit for use on the bot since it seems to have passed its proof of concept phase. That being said, it might take awhile to finish.

A side effect is I'll have it apart and I'll be able to tap into the analog output of the sensors. Again, I'm going with the idea of there being a possible timer conflict with the pulsewidth measuring I'm doing and the processor's servo timing. The analog output is just an ADC reading, boom, distance.

I haven't ruled out your solution though, Markus. When I dropped my setup I'd just finished installing a totally different (cheap-o 9g) servo from a completely different batch and it was even worse. Constant twitching with no response to servo pulse signal. After replying to your comment moments ago, I think the ping signal could have been the culprit, as you described.

Regardless, there will be some downtime before I report back. Thanks for the input guys, you've given me things to work on.

Perhaps the jitter isn't in the hardware, but in the software?  Post it, let some fresh eyes give it a go..  It's helped me..

I put my code in attachments as opposed to pasting the whole thing in the post. I try to keep the scrolling to a minimum if I can help it; my personal style. Both mentioned programs should be listed just below the embedded vid (if you can't see it you just need to log in).

I agree with Lasrin that this looks to me like a software problem.

You already experimented with pauses in your code and i think that is the way to go. If your main loop is to short, you keep firing pulses at the servo with changing lengths. Keep in mind that the servo expects short pauses between the pulses.

First try a simple program that just turns the servo back and forth and see if you can get it to turn smoothly. Put pause commands with different lengths in the loop and see if it makes a difference.

After that, add the code that reads the sonar sensor to see if it makes a difference. Perhaps the pulse-in is messing with the servo timing.

I used to love watching that video on MTV in the 80's, back when MTV played videos.   thanks for digging that up, it was fun to see again.

regarding your problem....I think your suffering from "designers dilema", where only the designer really see's the problem.   ya, I see what your talking about, barely.   I;ve seen the issue in my projects also and never could figure it out.   I agree with Gareth, thats just how servo's are.  the gears just dont work the same way in both directions.

I say dont worry about it, move on with your project.   if thats the worst of your problems, your in great shape!   I love the eye movement, however a simpler approach would be to point the eyes slightly outward from each other and which ever reads a closer object, turn that way until both eyes read the same distance.  move the head only, not the eyes.  however it is cool to see them move.

are those orange medicine bottles?