Using motor ticks w/o 'mav' or 'mrp' functions

Could you do some tests to see if this would be true? I'd be interested in seeing 2 or 3 robots tested with a variety of movement controls to see which were most accurate(and at different speeds to see if that effects it). I could probably write some test code to run if you could run it on robots and measure distance traveled that could be some valuable information for the community.

EDIT: Here are the most obvious movement algorithms I could think of. Would be interesting to see how consistent they are and which ones have obvious biases(the clamp may cause some problems)

#include<stdio.h>
 
//! relative speed the robot should move at as percent of max(functions will auto-scale). Needs to be more than MINSPEED
#define SPEED 50
//! minimum speed to prevent some problems from low power. Also in percent
#define MINSPEED 10
//! distance the robot should travel during the test in ticks
#define FINALDIST 2000
//! Define algorithm it should use(pick from the enum below)
#define ALGORITHM ALG_MRP
//! The steps for acceleration in the ALG_MRPA algortithm
#define STEPS 25
//! port the left motor is plugged into
#define LMOTOR 0
//! port the right motor is plugged into
#define RMOTOR 3
//! Simple utility function
#define CLAMPVEL(x) ((x) < MINSPEED ? MINSPEED : (x))
 
enum{
	ALG_MRPD,
	ALG_MRPA,
	ALG_MAVD,
	ALG_MAVL,
	ALG_MAVQ,
	ALG_MOTD,
	ALG_MOTL,
	ALG_MOTQ
} algorithms;
 
int main(int argc, char* argv[]){
	int curdis=0, curvel=0;
	switch(ALGORITHM){
	case ALG_MRPD:
		mrp(LMOTOR, SPEED*11, FINALDIST);
		mrp(RMOTOR, SPEED*11, FINALDIST);
		bmd(LMOTOR);
		break;
	}
	case ALG_MRPA:
		for(int i=1; i <= STEPS; i++)){
			mrp(LMOTOR, 11*CLAMPVEL(SPEED*i/STEPS), FINALDIST/STEPS/2);
			mrp(RMOTOR, 11*CLAMPVEL(SPEED*i/STEPS), FINALDIST/STEPS/2);
			bmd(LMOTOR);
		}
		for(int i=STEPS; i > 0; i--)){
			mrp(LMOTOR, 11*CLAMPVEL(SPEED*i/STEPS), FINALDIST/STEPS/2);
			mrp(RMOTOR, 11*CLAMPVEL(SPEED*i/STEPS), FINALDIST/STEPS/2);
			bmd(LMOTOR);
		}
		break;
	case ALG_MAVD:
		mav(LMOTOR, SPEED*11);
		mav(RMOTOR, SPEED*11);
		msleep(1000*FINALDIST/(SPEED*11));
		break;
	case ALG_MAVL:
		while(curdis < FINALDIST){
			curdis = get_motor_position_counter(LMOTOR);
			mav(LMOTOR, 11*CLAMPVEL((FINALDIST-curdis)*SPEED/FINALDIST));
			mav(RMOTOR, 11*CLAMPVEL((FINALDIST-curdis)*SPEED/FINALDIST));
			msleep(5);
		}
		break;
	case ALG_MAVQ:
		while(curdis < FINALDIST){
			curdis = get_motor_position_counter(LMOTOR);
			mav(LMOTOR, 11*CLAMPVEL((FINALDIST-curdis)*(FINALDIST-curdis)*SPEED/FINALDIST/FINALDIST));
			mav(RMOTOR, 11*CLAMPVEL((FINALDIST-curdis)*(FINALDIST-curdis)*SPEED/FINALDIST/FINALDIST));
			msleep(5);
		}
		break;
	case ALG_MOTD:
		motor(LMOTOR, SPEED);
		motor(RMOTOR, SPEED);
		while(get_motor_position_counter(LMOTOR) < FINALDIST) msleep(5);
		break;
	case ALG_MOTL:
		while(curdis < FINALDIST){
			curdis = get_motor_position_counter(LMOTOR);
			mav(LMOTOR, CLAMPVEL((FINALDIST-curdis)*SPEED/FINALDIST));
			mav(RMOTOR, CLAMPVEL((FINALDIST-curdis)*SPEED/FINALDIST));
			msleep(5);
		}
		break;
	case ALG_MOTQ:
		while(curdis < FINALDIST){
			curdis = get_motor_position_counter(LMOTOR);
			motor(LMOTOR, CLAMPVEL((FINALDIST-curdis)*(FINALDIST-curdis)*SPEED/FINALDIST/FINALDIST));
			motor(RMOTOR, CLAMPVEL((FINALDIST-curdis)*(FINALDIST-curdis)*SPEED/FINALDIST/FINALDIST));
			msleep(5);
		}
		break;
	case default:
		printf("A command is messed up somewhere\n");
	}
	off(LMOTOR);
	off(RMOTOR);
	return 0;
}

The scope of what you are suggesting is beyond my available time or interest. I assume the code above is meant as an outline of a test plan. From my experiments with a couple Links, the mrp and mav tests with speeds less than 50% [500 >SPEED>10] will cause much randomness in both the forward distance and the final attitude of the bot. Even for higher speeds, 5 to 10 runs would be required to get a sense of the error distribution [a lot of manual measurement]
- I found the ALG_MAVD method to be unreliable as well.
- I'm not familiar with your notation for CLAMPVEL(), is that in C++? please explain.
-The ALG_MOTD method requires testing with a range of battery charges to bound the error [quite time consuming]
-I might experiment with a variation on the ramp-up, ramp-down method and report back.

Please let me know if I misinterpreted your request.

I would expect from those to have ALG_MAVD to be least precise it is basically the same as mrp with less accuracy
CLAMPVEL is just a preprocessor define function using the ternary operator. It could also be written as

int CLAMPVEL(int x){
	if(x < MINSPEED) return MINSPEED;
	else return x;
}

I didn't neccesarily mean for just you to test them but rather anyone who has access to try it out with various settings(preferably with repitition on each setting to check for consistency).
I think the *Q ones will probably be the most accurate(A quadratic ramp down from fastest speed to slowest). The might be improved with a smoother increase in speed so it isn't jerky though. It also might be useful to take into account the minimum speed so the curve is smoother.
And as I've said the MAVD will probably be least accurate with the MRPA being right after it(I think all the separate commands will cause some problems, but that might be able to be compensated for).
Also just as a note with mrp and mav the maximum velocity is usually closer to 1100 and depends on the robot and charge. I assumed 1100 in my code(so the conversion from percent is just multiply by 11)

Hi Terry,

Have you played around with the PID gains? My guess is that poor accuracy at low velocities would be caused by overcorrection/oscillation, which would be improved by fiddling with the PID gains. I'm also going to conjecture that KIPR didn't do much tuning of the PID gains... a few hours of experimenting with the Ziegler-Nichols method might yield good improvements.

I would be surprised if motor() yields better results than a properly tuned PID controller, because motor() will possibly make different wheels move at different speeds in a way that is dependent on battery level.

It's more than low accuracy though. I noticed that the wheels wouldn't even turn if the power was too low(somewhere around 100ticks/second)

@ruler501 Wheels not turning at low speeds sounds like a PID gain issue as well.

I should probably learn more about PID gains I guess

Jeremy,
I haven't experimented with the PID gains, but from my experience the motors act like the lag in the control loop is too great and varies from one sample to the next (if so, PID gain will not fix it). The two drive motors seem to take turns moving forward. [setting the PID gain is not easy, even under ideal timing, its largely trial and error]
Also, on startup one or the other of the motors sometimes jitters, leading to an attitude angle error. For speeds over ~600 the speed smooths out, but sometimes one motor stops before the other even though the stop is initiated by one.
I was surprised to find that, on the Link, the EMF integral, or sum, which is the 'count', is available with just power to the motors; this isn't true in the simulation.
Perhaps the OS in the Link has two free-running samplers of each motor port EMF when the mav function is active and they are not synchronized.