I've written the following code to obtain the direction and distance to a destination from my present location. the results are outputted on a pan/tilt system.. the code compiles and uploads, and in the serial monitor i get the right calculations. However, the servo pans to the right degree, but shakes back and forth every few milliseconds. i would like the servo to go the the degree and stay there for a few secons (perhaps delay the cycle every 5 seconds).. Any help troubleshooting this would be appreciated.

// For one second we parse GPS data and report some key values for (unsigned long start = millis(); millis() - start < 1000;) { while (ss.available()) { char c = ss.read(); // Serial.write(c); // uncomment this line if you want to see the GPS data flowing if (gps.encode(c)) // Did a new valid sentence come in? newData = true; } }

Do you really mean every few milliseconds? I can't imagine how you'd be able to tell that.

Since you only update the GPS position fix and recalculate the bearing once per second, and taking at face value your description that the jitter occurs very frequently, I suppose this must be jitter and backlash from the servo itself. In that case perhaps you need to replace your servo with one that is more accurate. Digital servos are designed to avoid that sort of problem.

I only provide help via the forum - please do not contact me for private consultancy.

sorry..yes the servo only jitters every few seconds. This is the pan/tilt kit I am using (the servos came with it): <http://www.robotshop.com/ca/productinfo.aspx?pc=RB-Dag-29&lang=en-US>i can't find the spec sheet for my servo... but this one is very similar: <http://www.jetfoamy.com/index.php?route=product/product&product_id=80>

The servo doesn't really jitter... it just does not hold its position. In other words, it rotates about 10 degrees away from the calculated value, and then swings back to the calculated value. This cycle repeats every few seconds.

The servo doesn't really jitter... it just does not hold its position. In other words, it rotates about 10 degrees away from the calculated value, and then swings back to the calculated value. This cycle repeats every few seconds.

Thanks

rdeans

You've got debug code in there showing the servo commands - does the output correspond to the movement you're seeing?

Do the GPS position fixes alter when the jitter occurs? If so, is the servo jitter being correctly calculated from the GPS jitter?

I only provide help via the forum - please do not contact me for private consultancy.

for (unsigned long start = millis(); millis() - start < 1000;) { while (ss.available()) { char c = ss.read(); // Serial.write(c); // uncomment this line if you want to see the GPS data flowing if (gps.encode(c)) // Did a new valid sentence come in? newData = true; } }Using a while loop where appropriate, instead of twisting a for loop out of shape, would be a good idea.

float distanceangle; if (distance <= 100){ distanceangle =int(-0.6*distance + 120);Declare a variable of type float. Compute a float value. Cast it to an int and store in the float. I wonder why more people don't do that.

The indenting of your code makes it really hard tofollow. Use the Tools + Auto Format menu item to do something about it.

Simplifying your output would be useful. Print millis(), distanceangle, and courseangle only. If you are not changing the value written to the servo on any given pass through loop, but the servo still moves, it is underpowered or undersized.

Looks to me as if the GPS input is being received on average twice a second, there was only one error, the GPS position was consistent throughout and the commanded servo angle was 39 degrees throughout.

If the servo moved during that time then either there's a problem with the servo itself (or wiring/power supply etc), or memory corruption causing the servo's internal state to be corrupted, or a timing issue preventing the Servo class from outputting the PWM pulses accurately. It seems unlikely that a timing issue would occur consistently so the third option seems unlikely. I suggest you check the free memory immediately before doing the gps.encode and see whether you're anywhere near running out. I haven't looked at the gps implementation but presumably it's got a buffer big enough to hold at least a complete sentence, so it'll be a bit of a memory hog. It's also possible that gps.encode itself uses significant stack or heap space , so unless your freeMemory check shows you have hundreds of bytes to spare I would suggest you also look under the covers of the GPS library and see whether the memory consumption is likely to be static, or changing significantly over time. (If it's changing, then your free memory checks won't tell you what the peak consumption is unless you put them INSIDE the library.)

I only provide help via the forum - please do not contact me for private consultancy.

/* This sample code demonstrates the normal use of a TinyGPS object. It requires the use of SoftwareSerial, and assumes that you have a 4800-baud serial GPS device hooked up on pins 3(rx) and 4(tx). */

// For one second we parse GPS data and report some key values for (unsigned long start = millis(); millis() - start < 1000;) { while (ss.available()) { char c = ss.read(); // Serial.write(c); // uncomment this line if you want to see the GPS data flowing if (gps.encode(c)) // Did a new valid sentence come in? newData = true; Serial.print("Millis() is "); Serial.print(millis()); }

That's a little hard to believe. That means that you are getting, parsing and using a complete sentence from the GPS approximately every 8 milliseconds, at 9600 baud, or 125 per sentences per second. I don't believe that that is the case.

The Serial.print() statements are inside the if(gps.decode(c)) block, which, according to the comment, returns true only when the end of sentence marker arrives. So, that looks to me like they should happen only when the $ at the end of the NMEA sentence arrives.

Never mind. I went back and looked at the code. I assumed some curly braces that were not really there.

OP: I wanted you to print the time only when you got a complete sentence, so we could see how long that was taking.

It's a good idea to always use curly braces, so that you can add code to a block (or not), and it is clear that the code is (or is not) part of a block.