Botting the way - 3Pi Intro (2)

Hey there!

Here's the followup to the 3pi blog.

Now, this assumes some familiarity with the development kit for 3pi.

Now, our 5 light sensors' values can be read (Using Arduino's C++ development kit) with the following function:

  unsigned int sensor_values[5];
  read_line_sensors(sensor_values,IR_EMITTERS_ON);

meaning sensor_values[0] holds the leftmost sensor's value. This is displayed as a number between -2000 (maximum reflection, or "all white") and 2000 (no reflection, or "all black"). With this, a super simple way of guiding our bot on the track is to place it anwhere on the track, and simply find out where it should turn. If it's a closed track and the line is not overly thick, what we do (in pseudocode) is:

position=0; //centered
for i in sensor_values
  position+=sensor_values[i];

What are we saying here? We're basically looking for position to be a rough reflection of wheter we are to the left (negative values) or to the right (positive values). In this supersimple version, we will just assume there are no conflicts (which there certainly WILL be!) on the track, and sensors provide fairilly accurate information. The idea now is simple (pseudocode):

if position < 0
 robot turns right
else if position = 0
 robot moves forward
else if position > 0
 robot turns left

How's this done on our little 3pi friend? It's simple. All we can set is the motor's speed. We have 2 motors: left and right. The robot doesn't know what "forward" means, but that's easy - both motors set to the same speed mean the robot moves forward*Or do they?!. Turn left simply means we set the RIGHT motor speed to something faster than the left's, and vice-versa.

To set so, the code is as follows (C++):

  int velocity_left=0;
  int velocity_right=30;
  OrangutanMotors::setSpeeds(velocity_left,velocity_right);

In this example we make our robot circle around itself with the left motor as the center.

Note that a 3pi's speed is expressed in a number between -255 and 255. Any higher/lower and they are set as if 255/-255 was given as input. This is not meters per second or any international system measure unit, so we can't correspond it to meters or inches. More on this later on.

* Nothing in real experiments is as sweet as it sounds during our planning, is it? Robots are physically more complex than we're assuming here for a variety of reasons. The basic one is that no two objects can be absolutelly equal in a real environment. Sure, we set both motor's speed to 20 in our code, but what if one of them has suffered harsher degradation for some reason? 20 on both speeds will NOT in fact make our bot go forwards, but form a weird angle. Fortunatelly, we can correct this through a method called callibration. This will be explained later on.