Servo twitch or hiccup problem

I hope this is the best forum to post this into, as it involves a servo twitch problem which some of you may have run into with robotics.

I am doing a project which involves a very sensitive wind direction sensor, which is used to command a servo for a homemade chart recorder. It uses a slotted disc, with two optical sensors, one 90 degrees out of phase, as a quadrature encoder.

I have it working just like I want it…. as far as the sensor goes. The sensor creates a wind direction number from 5 to 360 in 5 degree increments, and that number is used for controlling a servo. The servo is used for moving a pen arm, so the pen produces a Chart Recorder plot of the wind direction (As well as a plot of temperature rising or falling and wind increasing or getting calmer. The recorder is for helping to detect thermals, rising air, for flying models. It is not for a weather station so calibration does not matter, only the relative changes over a small range).

Anyway, it is working great, except…. the servo twitches every 11 seconds. I have tried to track down a cause for it, and cannot.

Now originally, for development, I had a lot of serial print info so I could see what it was doing. That caused some issues. So I got rid of all except the wind direction serial print. The servo was twitching, about once per second.

I copied the code then stripped out all the code that I knew probably was not the cause, and indeed the problem remains.

I got rid of the calculations that are used to control the servo. It is fixed with a value of 1500 microseconds. So, it ought to just sit there, never moving. But still lit twitches.

I got rid of the serial print for wind direction, leaving no serial print commands, and the twitching occurred less often., but it is still there, every 11 seconds. I got rid of “serial.begin”, so there is no serial enabled at all, no difference.

There is a delay of 20 milliseconds for the loop (plus the time for the servo pulse and rest of the code to run). So if it takes say 22 milliseconds per loop, then it is running about 500 cycles before that one twitch.

I changed the delay from 20 to 50 milliseconds. It twitches at about 27-28 seconds, right in proportion to the increased delay. But the twitch is totally different, rather than one big jump to the same direction each time, it twitches a very small amount back and forth very quickly about 10 times.

I changed the time delay to 100 ms, and the twitching does not occur. But the wind direciton sensor needs a faster cycle than that or can miss a few pulses from the optical sensors. And I know the common delay used for servos is 20 ms (OK, technically the loop runs longer than that due to the time of the delay plus servo pulse plus the rest).

I tried a time delay of 75 ms, and the twitching occurred at about 26 seconds, a few twitches that happen more slowly than with the day of 50 ms.

A bit of an update. With the delay set back to 20 ms, the twitch is every 17 seconds rather than every 11. I had deleted a bit more code, but still this ought not to be happening.

I will mention that the servo is using its own 5V power, and works fine with demo servo sketches. So, the servo itself is fine and the breadboard and wiring set-up is fine. It’s this code that is acting screwy.

I am using a Uno, which has worked fine for everything else I’ve done so far.

Here is a link to a youtube video where the direction sensor and servo are working fine… except for that twitch every 11 seconds:

Included below is the cut-down code.

Does anyone have any ideas what the cause may be?

I have to fix this twitch, the whole thing is useless if it twitches like that as the chart plot would be a mess.

  • George Gassaway

#include <Servo.h>

Servo myservo; // create servo object to control a servo

int pos = 0; // variable to store the servo position

// constants won’t change. They’re used here to
// set pin numbers:
const int SensorA = 7; // the number of the pushbutton pin
const int LedA = 12; // the number of the LED pin

const int SensorB = 8; // the number of the pushbutton pin
const int LedB = 13; // the number of the LED pin

int SSA = 0; //optical sensor A
int SSB = 0; // optical Sensor B
int SSold = 1; // Sensor State old (Previous value for Sensor State
int SScurrent = 1; // Current value for Sensor State, comapres with SSold

int SenStateA = 0; // variable for reading the Sensor State A
int SenStateB = 0; // variable for reading the Sensor State B

void setup() {

myservo.attach(12); // attaches the servo on pin 12 to the servo object

// initialize the LED pin as an output:
pinMode(LedA, OUTPUT);
// initialize the pushbutton pin as an input:
pinMode(SensorA, INPUT);

// initialize the LED pin as an output:
pinMode(LedB, OUTPUT);
// initialize the pushbutton pin as an input:
pinMode(SensorB, INPUT);

Serial.begin(9600);

}

void loop(){

delay (20);

// read the state of the Sensors:
SenStateA = digitalRead(SensorA);
SenStateB = digitalRead(SensorB);

// write servo value in microseconds. For this test, it is a fixed value to
// prove the hiccup is not related to any random values being thrown into the calculation
myservo.writeMicroseconds(1500);

// check if Sensor A is HIGH:
if (SensorA == HIGH) {
// turn LED on:
digitalWrite(LedA, HIGH);
}
else {
// turn LED off:
digitalWrite(LedA, LOW);

}
// check if Sensor B is HIGH:
if (SensorB == HIGH) {
// turn LED on:
digitalWrite(LedB, HIGH);
}
else {
// turn LED off:
digitalWrite(LedB, LOW);
}

}

//////////

You are using pin 12 for the servo and LedA.

wildbill,

Thanks very much!

Indeed that was the cause. Ironically I never used those LED's, as once I got to the breadboard stage I found that the optical sensor outputs could directly make the LED's turn on or off.

Of course if I had actually tried to connect an LED to pin 12, I would have found pin 12 being used for the servo signal, and realized the problem..

So, rather than reassign the pin number, I got rid of all the LED related code, and it's working perfectly now.

Video here of it working properly, with a bit of focus on some other aspects:

http://youtu.be/5L--We85XV0

  • George Gassaway