Consistent Distance Overshoot?

That accuracy sounds correct for those Create functions. The first one is an accuracy of 5% and the second of 4%. The first one is based solely on time, so I would expect it to be less accurate.

It looks like you are looking at the 2010 workshop materials.

My suggestion is that you make sure you are using KISS-C 2.3.2 or newer and that your CBC has a firmware of UH 216 or newer (you can check that from the about screen from the main CBC menu).

Once you have those versions, I would suggest that you use the new create functions:
set_create_distance();
get_create_distance(0.1);

These should be more accurate and more stable. Since your program 1 was based on time it remains the same. Modifying your program 2 it would become:

//Have the robot drive in a circle of a given radius, returning to where it started.

int main()
{
int radius = 200;

create_connect();

//the distance traveled is equal to the circumference of the circle, 2*PI*r
float total_distance = 2 * 3.14159265 * radius;

//reset create distance counter
set_create_distance(0);

//start driving in a circle
create_drive(75, radius);

//sensor loop
while(get_create_distance(0.1)<=total_distance)
{
//do nothing until desired distance is reached
}

//once we've reached this point, the create has returned to its inital position
create_stop();

create_disconnect();
}

Sorry for bumping such an old thread, but this may prove useful to someone, if not to the original poster.

I've always used "efficiency" coefficients as multipliers or divisors for wait times and/or speed. This works on both the create and on standard motors. The idea is that you make the motors move as accurately as you can, and then you introduce these "fudge"-factors.

CBCJVM's movement package even lets you define these "efficiency" values per-motor and as a function of speed, although that may prove to be over-kill for some people.

Agreed, fudge factors are very useful for imperfect systems such as robots. To elaborate, let's say you tell your robot to drive 100mm, and it ends up going 110mm. The fudge factor by which you want to multiply all of your move distances is 100/110.

This assumes that your robot is consistently overshooting/undershooting by the same fraction. If your robot is not doing so, chances are that something else is wrong, e.g. incorrect setup, mechanical issues, low battery, or programming bugs, and you shouldn't attempt to use a fudge factor to correct such issues.

Also remember that odometry is inherently inaccurate, which is why mission-critical systems e.g. the autonomous cars from the DARPA Grand Challenge don't use odometry except in combination with sensor systems that don't drift. An odometrically navigated robot may be able to make a few straight/turn maneuvers without much drift, but trying to make your entire program rely exclusively on such navigation is unlikely to work, particularly with the cheap equipment used in Botball.