Create Auto Programming

Hi, welcome to the Botball Community!

I'm unfamiliar with this particular project, but I've done similar things (and I know other people who have). Based on my experience, I'm skeptical of the accuracy and usefulness of this project for a few reasons. Most importantly, wheel slippage will affect the distance traveled, and wheel slippage is very different when pushing a robot manually compared to the robot driving itself. The Create's sensors also introduce an issue, because the Create's wheel sensors are unidirectional -- they can't tell if the wheel is moving forward or backward. So if you make the robot drive backward, or even make it turn so that one wheel moves backward, this project will likely get it wrong. As an aside, based on the code snippets presented in the video, the programmer doesn't appear to be at all familiar with C (e.g. he uses "!= 0" in if statements), which makes me wonder how many bugs are probably present in the code.

In short, this kind of code is a cool idea (I implemented it on the XBC, so I see why people would like to code it), but in practice it's probably not a great solution.

Now, what is a good idea? The dead-reckoning method I recommend is:

1. Figure out (roughly) how many motor ticks exist per millimeter on the particular robot you're working on. For the Create, this is close to 1.0. Call this R.
2. Figure out how far you want the robot to travel in millimeters. Call this X.
3. Write code telling the robot to travel X*R ticks. (For the Create, this would be X mm.) Run it.
4. Measure with a meter stick or tape measure how far the robot actually traveled. Call this Y0.
5. Multiply the distance in the program by X/Y0. Run it again.
6. Measure the distance again. Call this Y1.
7. Multiply the distance in the program by X/Y1.
8. Repeat steps 6-7 until the robot is sufficiently accurate. This will usually take less than 5 iterations.

Hope this helps.

I have 2 questions:
1. How exactly would I do step one?
2. On step 4, you say measure how far the robot actually traveled. Would it be more accurate to measure from the back or the front? Would it matter?

Thanks for the reply.

There are various ways to do step 1. For the Create, 1 is a good estimate because that's what the Create documentation says. For a robot driven by CBC motors, you could do one of two things: (1) you could measure the circumference of the wheel in millimeters and multiply by 1100 (this works because 1100 motor ticks is approximately 1 revolution, i.e. the robot will travel the circumference of its wheel; or (2) you could push the robot a certain distance and check how many ticks the motor moved (the Sensors screen on the CBC interface will show you this), then divide the ticks by the millimeters traveled.

Note that once you successfully follow the instructions for one movement, the result is a much more accurate input for step 1. E.g. if you eventually figure out that you need to move A ticks for a distance of B millimeters, you can use A/B as your input for step 1 in the future.

Measuring how far the robot traveled can be done from any reference point, as long as it's consistent. I like to lightly mark the old position on the game board with a pencil before I have the robot move, and then I mark it again after it moves; then I can measure the distance between the two pencil marks. Just make sure you're using the exact same part of the robot each time and you should be fine.

Good luck! Feel free to post if you have any other questions.

Thanks for answering my questions so quickly, it's hard only having 3 beginning programmers in a group.

This isn't related to movement, but one of our 4 servo's wires used for a claw have malfunctioned. You have to bend it a certain way so that it works properly, but I find it inconsistent. I switched that servo to a motor since that is the only thing we can use. I was wondering if you could write a pseudocode to emulate it acting as a replacement servo. It is a 2 pronged claw, similar to a pincer. The right side is stationary, and the left side is the one that clamps it together. I would post pictures on here, but I can't seem to find a way to do it.

If you want to use your motor as a servo, you probably want the mtp function.

mtp(0, 500, 900); will move motor 0 to position 900 at speed 500. Motors have the advantage over servos that you can directly control the speed and read the position, but the disadvantage is that motors will eventually drift over time.

If you want to wait for the motor to finish moving to the requested position, the bmd function will do that. So:

mtp(0, 500, 900);
bmd(0);

is equivalent in usage (though the numbers will be different) to:

set_servo_position(0, 900);

If I recall correctly, the servo positions range from 0 to 2047 (with the range being about 180 degrees), while the motors can turn continuously with 1100 ticks being about 1 revolution.

As an aside, if your servo wire is broken, it may be covered under KIPR's warranty. Try calling or e-mailing the KIPR office and see if they'll send you a new servo. Even if it's not covered by the warranty, they can sell you one (the servos are something like $15 each, I think... so not a huge deal).