abdrive360 - fix lost encoder increment on right wheel

[AndyLindsay]

The right wheel seems to lose an encoder tick on its first forward maneuver. It probably has to do with starting at the edge of an an increment. The left wheel goes forward and traverses an entire 64th of a revolution before encoder ticks increase to 1. Meanwhile, the right wheel crosses from 0 to -1 immediately. This may need to be corrected in servo360 instead.

[AndyLindsay]

Since the native resolution is 4096ths of a turn, this is probably not something where the 0 to -1 transition is closer than the 0 to +1 transition. Well, it might be 1/4096 closer, but that's not going to look like an entire 1/64th abdrive encoder increment.

With #define console active, I can see that the target positions go to +/- 64 in response to drive_goto(1, 1) and back to 0, 0 in response to drive_goto(-1, -1).

For example, in this entry csop has transition from 2 (position control) to 3 (goto control), and aT (angle target) is 64 for the left servo, and -64 for the right.

ms: 20 id: 0, csop: 3, ms: 20 spR: 0, spT: 0, spM: 0, csop: 3, aT: 64, a: 23, tG: 198, tD: 36, af: 0 id: 1, csop: 3, ms: 20 spR: -4096, spT: -256, spM: 0, csop: 3, aT: -64, a: 38, tG: 0, tD: -102, af: 0

To repeat this test, servo360 needs to be recompiled with #define console un-commented in servo360.h. After that, libservo360.side has to be recompiled.

#define _console_

#include "simpletools.h"
#include "abdrive360.h"

int main()                    
{

  //
  #ifdef _console_
    drive_speed(0, 0);
    console_start();
    suppressFbDisplay = 0;
  #endif 
  //

  //drive_goto(0, 0);
  pause(500);

  drive_goto(1, 1);
  pause(1500);

  drive_goto(-1, -1);
  pause(1500);

  drive_goto(-1, -1);
  pause(1500);

  drive_goto(1, 1);
  pause(1500);

  drive_goto(1, 1);
  pause(1500);

  drive_goto(-1, -1);
  pause(1500);

  #ifdef _console_
  suppressFbDisplay = 1;
  #endif
  while(1);
}

[AndyLindsay]

This might just go away with control system tuning, so it should be revisited after issue 95.

[AndyLindsay]

9/18 This is not an accounting error. It might disappear with control system tuning. 9/21 Bug found and corrected in speed PID that favored counterclockwise error correction, which was probably also a contributor.

Reopen during control system tuning if needed.