Consistent Distance Overshoot?

3 replies [Last post]
WintryExplorer
Title: NooBot
Joined: 02/16/2011
Posts:
BotPoints: 3
User offline. Last seen 11 years 31 weeks ago.

I am working on a set of exercises and solution examples for Botball and have run into an odd issue that keeps popping up in my programs.

Whenever I attempt to return to the robot's initial position, it overshoots it by a few inches. This has occurred in the follow two simple programs I've written:

[program 1]
//drive forward in a straight line for 10s, then stop, and drive in reverse to the initial position
#include

int main()
{
create_connect();

create_drive_straight(100);
sleep(10);
create_stop();

sleep(0.5);

create_drive_straight(-100);
sleep(10);
create_stop();

create_disconnect();
}

[program 2]

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

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;

gc_distance = 0; //initialize the
create_sensor_update(); //Create's distance tracking

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

//sensor loop
while(gc_distance < total_distance)
{
//update the distance tracking every 0.1 seconds
sleep(0.1);
create_sensor_update();
}

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

create_disconnect();
}

Program 2 is adapted from the 'drive in exactly one circle' exercise (Activity 16a) of the Instructor Workshop, so I'm at a loss as to why this keeps happening. I imagine the loss of accuracy in the robot's movement this issue represents would be detrimental for students preparing for the competition. Has anyone else encountered this problem? What am I doing wrong?

KIPR Matthew
KIPR Matthew's picture
Title: KIPR Staff
Joined: 06/04/2009
Posts:
BotPoints: 154
User offline. Last seen 5 years 3 weeks ago.

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();
}

Join the Botball folding at home team!
http://folding.stanford.edu/
Team 87314 "Botball"
Stats: http://folding.extremeoverclocking.com/team_summary.php?s=&t=87314

PiPeep
PiPeep's picture
Title: RocketBot
Joined: 07/19/2009
Posts:
BotPoints: 170
User offline. Last seen 8 years 28 weeks ago.

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.

Jeremy Rand
Jeremy Rand's picture
Title: Botball Youth Advisory Council
Joined: 04/03/2009
Posts:
BotPoints: 1168
User offline. Last seen 7 years 18 weeks ago.

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.

-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS