Sciborg, Day 4

Sciborg, Day 4

After our conga line challenge, we aimed to use feedback and control to guide our sciborg along a white line using a LEGO NXT light sensor.

Leading up to our final program, we first had to understand how the light sensor functioned.

In the program “Light Sensor Test,” we connected the light sensor up to the Arduino board and printed the value the light sensor read when pointing at different colors in the serial print monitor.

We noted the difference between the white tape (~480) and the brown board around it (~580).

We used this information to program our “Light Sensor Follow” codes.

LIGHT SENSOR FOLLOW

We began by designating a value that determined the motor outputs. We chose 550 to be the boundary. When the recorded value was less than 550, the sciborg continued on a “straight” path (where both motors’ outputs were intended to create an equal distance covered in the same amount of time). When it was greater than 550, then the sciborg would move motor 1 in reverse at 100 power and move motor 2 forward at 108.5 power. This created slight adjustments to the right. We chose a delay of 50ms before running the loop again. This program worked really well – up until the left turn in the white line. When the readings went beyond 550, then we had the sciborg adjust it’s trajectory to the right until the readings fell into the right range again. This only worked because the course has mostly right turns.

As the sciborg wasn’t programmed to make adjustments to the left, we now knew what to address next. This was a good stepping stone to thinking about other approaches. When the sciborg reached the left turn, it rotated right until it traveled back upon the path on which it came.

LIGHT SENSOR FOLLOW CODE2

We then created a code that would always turn right when the sensor reading rose above the tolerated range of accepted readings, and would turn left if the sensor reading was in a higher range of values.

Using our measured readings from the light sensor, we decided to tolerate readings within the range of x < 570. When readings fell into this range, the sciborg continued to move straight.

When the value fell in the range of 570 < x < 620, the sciborg would make a correction to the right until the value fell into the “straight” path category.

When the value was greater than 620, the sciborg was told to make a correction to the left.

We delayed this loop for 50ms.

The trouble we found with this code was that the sciborg quickly reached a point where it was oscillating back and forth from being reading in one range and then another. The small delay did not allow the sciborg to gain sufficient distance to move away from this problematic zone. For example, the sciborg would read a value in between 570 and 620, and move to the right. The next reading would have the value greater than 620, prompting the sciborg to move to the left. By the time of the next reading 50ms later, the reading would be between 570 and 620 again and the sciborg would move to the right once more. Therefore, we saw a quick, jerking motion alternating between the left and right directions repeated continuously.

After both of these programs, we now began to address the left turn issue and the possibility of creating a sweeping sensor motion that determines the need to turn left or right.

LIGHT SENSOR FOLLOW 3

An important note to this part is that we relocated the light sensor to the previously “rear direction” of the sciborg. Forward motion is now positive.

The purpose of this code was to set up a time interval to implement a sweeping motion. The sweeping motion was intended to help the sciborg determine the direction in which it would correct its trajectory.

We set up a time interval of 2 seconds. We set the time to start when the loop started.

We used ranges for the readings in conjunction with the time intervals, beginning with the “straight path” part of the loop. It stated that while the value <= 585 the sciborg would go straight.

When millis – startMillis was less than or equal to 2 seconds (interval1), the sciborg made a right turn (m2 speed < m1 speed).

When millis – startMillis was greater than 2 seconds, then the sciborg would adjust to the left (m2 < m1). This step also reset the current time value to zero, the start time value.

This was intended to have the sciborg (if not continuing on a straight path, i.e. the value > 585) sweep to the right to search for the white line. If it was not found in 2 seconds, the sciborg would then sweep to the left looking for it for 2 seconds.

The sciborg eventually ended up traveling in ellipses in either the left or right directions looking for the path.

LIGHT SENSOR FOLLOW4

We then looked back on our 3 programs. We decided to pursue a new code that resembled the second program the most.

Here, we designated a boundary value which determined the direction in which the sciborg adjusted its path. As we had measured the sensor readings for all white, ½ on white, ¼ on white/all on brown, we found the respective readings. The all brown/ 1/4 white reading was ~595. We played around with the boundary value (further details below).

We told the sciborg to adjust to the right when value < 590. Our speeds show great power of the left wheel and minimal power, reversed direction of the right.

When the value exceeded 590, we told the sciborg to adjust to the left. We put a great amount of power in the right wheel and much less in reverse to the left.

We delayed 5ms before reevaluating the sensor readings.

Many of these values were determined through trial and error. Once we had the baseline program (with arbitrary numbers) that successfully maneuvered through the straight parts of the course as well as the shallow turns, we adjusted the numbers to accommodate the sharp turn halfway through the course.

Before our corrections, we noticed that the sciborg would overshoot the hard turn and then travel in a counterclockwise circle searching for the line. Our first correction was to minimize the delay. We believed that if the delay was smaller, the sciborg would not overrun the curve and thereby get “lost.” By reevaluating faster, the sciborg would cling to the curve better.

The next constant we adjusted was the sensor range. Before a 590 value, we had previously used a 600 value. This enabled the sciborg to follow alongside the curve, but not on it directly. We then lowered this value so that the sciborg would follow the white line itself. This also helped tighten the turns and distance away from the tape.

Our other corrections were to adjust the speeds. Depending on the direction of the turn, each motor (spinning in a different direction) would rotate at a relatively greater/slower rate to create the turn. We chose the outside wheel on the turn to be at almost maximum power. The inner wheel traveled backward at a slow rate. (Although the numbers were arbitrarily chosen, they were designed to have a great difference with the resulting effect being the main focus). We created these extremely large differences because we wanted the sciborg to have better ability with tight turns. This great disparity came as a trade off with precision with the shallower turns, but we found a balance that functioned well with both.

With all these numerical changes, our sciborg was able to make the hard right turn and easily navigate the shallower twists toward the end.

It may look like it’s having a fit, but hey, it works!