Thanks Erdin. I tried it and you are right. I've never seen that happen before. I will research it and try to try to see why it happened.

This is a routine to read a current sensor (Sparkfun BOB-08882) I am averaging ten successive reading in order to smooth the results. The ten individual readings look OK  but look at the average! I understand that the analog pins share a single ADC, and that there are timing issues when several analog pins are being read, but in this case no other analog pins are being used. To my simple mind this defies digital logic; ten digital values are added, then the sum is divided by 10,  but the result is not the average.???

Code:

int ReadCurrent()
{
  int adc;
  int sum;
  int curr;
  for(int i=0; i<10; i++){
    adc = analogRead(currentPin);
    delay(2); //wait for it
    Serial1.print("adc = ");
    Serial1.println(adc);
    sum += adc;
    delay(2);
  }
  adc = sum/10;
  Serial1.print("average adc = ");
  Serial1.println(adc);
  curr = (adc - 511) * 70;
  return curr;
}

This is a typical printout:
adc = 520
adc = 520
adc = 506
adc = 509
adc = 503
adc = 521
adc = 522
adc = 518
adc = 510
adc = 507
average adc = 663

The Arduino board is a Mega(ATmega1280)

Hi Paul,
        I should have defined my terms;  As I understand it a vector has a direction and a magnitude, in this case it would be a heading and a distance.  A 2D waypoint would be a pair of coordinates representing a point on some grid or other, in my case a Cartesion grid with the positive x-axis lying along the magnetic North, and the origin (0,0) located at the robot's Home position.(recharging station).
As it moved away from its home position it could record its movements as a series of vectors
e.g   82(cm), @45(deg)
        34,        134
        150,        89   
or it could record the turning points
e.g.      0,0
           33,33
          187,63
The components of the vectors would be gotten from a magnetic compass and wheel encoder
The waypoints would be calculated from the vectors.
As I write this I have a stronger and stronger feeling that the two methods would be equally error prone since one can be derived from the other, but I also know that "feeling" that you are right is no proof that you are.

Hi,
      Has anyone made an analysis of, or acquired experience in the following  ...which is more error-prone, as a way of recording the path of a robot, a list of vectors or a list of waypoints? More specifically, If my autonomous robot  moved from A  to B along an arbitrary jig-zag path, by odometry only, recording its path as it goes, and then attempted to return to A using the data recorded on the way out, would the error in reaching A likely be less if the path was recorded as a series of vectors which could be reversed to return, or a set of waypoints recorded at each change of course?

Hello Cyberteque,
           My encoders are actually simple ones (not quadrature) and I am using them for two purpoes; to measure the distance travelled, and to make the robot travel in a straight line by synchronizing the drive servos.  Since I presented the problem here I have found two physical causes for my problems and have corrected them.: (1)  I sometimes powered the robot by USB alone and the voltage sagged to 3.7v. Now I make sure that the batteries are plugged in at all times. (2) One of the pull-up resistors was making intermittent connection in the breadboard. This allowed the encoders signal to float rather than going high. I repaired the circuit. Now all is going swimmingly until the next inexplicable hardware problem arises. : )   I am finding robot programming much more challenging than the usual programming in which you are dealing with well-behaved abstractions . Thank you for your input.

I disconnected the Boe Bot from USB and put it on battery power (5 AA cells regulated to 5V)
I connected the voltmeter to the encoder signal line and ground and turned the wheel manually, slowly.
The voltage alternated between 0.00V and 4.88V as it should.
I connected the voltmeter to the servo supply line and ground.   4.87V

I then connected the Boe Bot to USB and disconnected the batteries, and measured the voltages
The encoder signal line was 4.86V and the servo  supply line was 4.86V

I then opened the serial monitor ran the script in order to get output you asked for.
To my great surpise the output was normal! 
I repeated this a half dozen times without anything abnormal showing up.

That is good news and bad news.
Good in the sense that it is working.
Bad in the sense that I didn't learn why it didn't work initially.

My only guess is that there was a poor connection on the breadboard, where the pull-up resistors are, and that it was accidentally corrected when I was manipulating the wires while measuring the voltages. (The voltage on the encoder signal lines may have been bobbling up and down, creating multiple interrupts)

Lesson learned:  If the software does not work, do not become too focused on the details of the software, the problem may be in the hardware.

Thank you, Rob, for staying with me and pushing me toward the solution.

The values of Rindex and Lindex don't get higher than about 25 in any of my trials, but I'll change to unsigned long anyway because in practice I'll need them.

The  signal line is pulled low by the encoder when it gets a reflection and allowed to float otherwise so I have put 10K pull-up resistors on the signal lines as per the manufacturers instructions.

I don't have a logic probe but I am going to turn one of the wheels over slowly by hand while monitoring the signal line with a voltmeter. That's my next activity. I'll report back.

This is the encoder data sheet
http://www.parallax.com/Portals/0/Downloads/docs/prod/robo/DigitalEncoderDoc.pdf
     

Thanks Rob,
     Both good suggestions, but alas, they made no improvement.  My ISRs are as brief as I can make them ( Rindex++ ).  I have tried eliminating the Serial.prints altogether and just observed the rotation of the Boe Bot wheels and they rotated randomly 1/4 to 1/2 revolution, sometimes running on indefinitely until I pulled the power.
Glen

Hi,
       I am starting to put together my first robot (Boe Bot from Parallax) My microcontroller board is an Arduino Mega(ATmega1280)
I am having problems with the wheel encoders (Boe Bot digital encoder kit from Parallax). The encoder signal lines are connected to Arduino pins 2 & 3.
My problem is that I get interrupts much faster than the slots of the wheels pass the encoders. Also interrupts often continue to come in after the wheels have stopped.Here is my code:

Code:

#include <Servo.h>
Servo servoRight;
Servo servoLeft;
volatile int Rindex = 0;
volatile int Lindex = 0;

void setup()                                 
{
  attachInterrupt(0,rtEncoderInterrupt,RISING);
  attachInterrupt(1,ltEncoderInterrupt,RISING);
  Serial.begin(9600);
  servoRight.attach(12);
  servoLeft.attach(11);
  servoRight.writeMicroseconds(1700);
  servoLeft.writeMicroseconds(1300);
}
void loop()
{   
  // stop the servos after 16 interrupts from either  encoder
  if((Rindex == 16) || (Lindex == 16))
  {
    servoRight.writeMicroseconds(1500);
    servoLeft.writeMicroseconds(1500);
  }
  // hold execution here
   while((Rindex >= 16)||(Lindex >= 16)){}   
}

void rtEncoderInterrupt()
{
  Serial.println(Rindex);
  Rindex++;
}
void ltEncoderInterrupt()
{
  Serial.print("          ");
  Serial.println(Lindex);
  Lindex++;
}

From this code I expected  to see the Boe Bot wheels turn two reolutions (there are 8 slots in each wheel), and to see the following on the serial monitor:
1
       1
2
        2
3
etc.

Instead I saw the wheels turn 1/4 to 1/2 revolution at constant speed and this on the monitor:
1
2
3
       1
4
        2
        3
5
        6
etc.
 the pattern being random. After one of the columns reached 16 ,and the motors were stopped, interrupts continued to occor sporadically.
I have been working at this little sketch for two days and I am at my wits end. Can anyone make a suggestion?

I want to report that the problem is solved.  Don's comments about "timing" and "libraries" steered me in the right direction. It seems that the two libraries I was using both use interrupts and that a conflict existed. Since I already had shifted from Uno to Mega1280 I dispensed with NewSoftSerial and used one of the hardware serial ports available on the Mega instead.  Everything works as it should now, but I can't go back to the Uno as I had hoped to do.

You are likely correct, Don, but the timing problem is in the "behind the scenes"  code of the various libraries involved.  I have actually removed the (cursorHome) command because the cursor was ending up in the 0,0 position anyway at the end of the previous print operation. I'm still working at it. I have sprinkled "Serial.print(millis())"  throughout the code and have noticed that the action "goes away" somewhere for up to 500ms. before coming back with an incorrect keyboard code. (??)

I have a problem that I can't solve. I have worked for days at it and have unsuccessfully searched the internet for anything related.  This is the offending code:

Code:

void display_text()
{   
  lcdSerial.print(clearScreen);
  delay(10);
  if(textSize < 5) {           //one 80-char string
    // display it
    for(int i=0; i<20*textSize; i++)
    {
      lcdSerial.print(text[i]);
    }
  }
  else if(textSize > 4) //  greater than  80-char
  {   
    topLeft = 0;
    topLeftMax = 20*(textSize-4);           // 3rd line from the bottom
    // display the first 80 characters
    for(int i=0; i<80; i++){
      lcdSerial.print(text[i]);
    }
    // use upArrow and downArrow to scroll through the text
    do
    {       
      while(keyboard.available() == false) {
      }
      inByte = keyboard.read();
      Serial.println(inByte,DEC);  // for debugging
      if(inByte == upArrow && topLeft > 0){
        topLeft-=20;
      }       
      else if(inByte == downArrow && topLeft < topLeftMax){
        topLeft +=20;
      }       
      lcdSerial.print(cursorHome);
      for(int i=topLeft; i<topLeft+80; i++){
        lcdSerial.print(text[i]);
      }
    }
    while(inByte != PgDn); // to go for a response 
  }   
}

text[] is a string of 320 characters to be displayed, with scrolling, on a 4 X 20 LCD. The first 80 characters are first placed on the LCD and then the upArrow and downArrow keys are supposed to allow scrolling through the text.
The problem is that the inByte read from the keyboard gives the correct code only about once every three keystrokes. On the other keystrokes it gives sometimes one, sometimes two incorrect codes with no pattern that I can perceive. The keyboard works correctly when I test it in another simple sketch.  Strangely (to me) the keyboard will work correctly in this routine if I comment out the second last and third last lines of code.  I am using a Arduino Uno and thinking that I was running out of SRAM I switched to an ATMega1280 but the problem persists. The keyboard is handled by PS2Keyboard.h and the LCD by NewSoftSerial.h. 
What is going on here????
("textSize" in the above code is the number of preformatted 20-character lines of text.)

[That seems unlikely.  /quote]
Unlikely, but true. There were eight pairs of keys with the same codes, and there were other inexplicable oddities.

It's not like a PS2 keyboard is rocket science

True, but it is muddled science. The assignment of the key codes in the original PS/2  keyboards must have made sense on some level (perhaps on a physical level of the pcb) but they bear no relationship to each other or to the ASCII codes which they have to be translated into.
And to further confuse the issue the work of detecting, debouncing, buffering and interpreting keypresses was divided between a "keyboard encoder" in the keyboard and a " "keyboard controller" in the host computer, the two being in two-way communication. So when we try to interface an Arduino board with a PS/2 keyboard we are working with half a system. And even worse, the Parallax PS/2 keyboard, as it turns out, is PS/2 in name only. It does have PS/2 style connector.
However, I have it sorted out now, or at least to the extent that the keyboard will serve my purposes.  I contacted Parallax support staff and they sent me a list of the key code assignments in their keyboard. They have assigned the codes rationally, i.e. like the ASCII codes, and have kept the printing and non-printing codes in separate groups.
   The authors of the PS2Keboard.h and .cpp files did some reassigning of codes in an attempt to make the PS/2 mish-mash more reasonable.  So, the selective reassignment of codes in PS2Keyboards.pss  and the total reassignment of codes in the Parallax keboard gave me a system in which several keys were assigned the same code (this happened eight times), some keys had no code, and some printable keys were given control functions and vice versa.   As a kludge I went into the PS2Keyboard library files on my PC and re-reassigned some key codes to resolve most of the conflicts and I now have a working keyboard that talks to my Arduino Uno.
      The Parallax Mini keyboard is a nice little 88-key keyboard, with full-size keys Only the numeric kepad keys have been omitted.  Check it out at
http://tinyurl.com/62h7y7q
Now if someone would write a library for it the world would be a better place 

Thanks Kari for that.   I used that library (PS2Keyboard.h  and .cpp) to handle the interface to the keyboard and it worked just fine. I had no trouble receiving the key codes, but if several keys share some of the codes, then the keyboard is unusable, unless there is some work-around that I can't imagine. 
Glen

Yes, here's the link...........

http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/Keyboard/List/0/SortField/4/ProductID/338/Default.aspx

This keyboard is not in their print catalog, only on their web store.

Glen