Driving Straight

On Wednesday, we continued to work with and inexplicably break the RDS Cricket cars. Our first task was to make a wheel return to its original position after being turned, which we had accomplished on Friday. From here, we needed to have one wheel follow the motions of the other. For this task, we wrote this program:

"followwh": By setting the error as the difference between wheel positions, Wheel A will move to match the position of Wheel B. This is a later screenshot of the program; with our first car the motor was attached to port C and will be referred to as Wheel C.  

But, we found that no matter where we turned Wheel C, Wheel A would move forward. We decided to do some tests by printing counta. Counta behaved like we would expect, with the number increasing after forward spinning and decreasing after backwards spinning. However, countc increased with both forward and backward motion. This is why Wheel A kept going forward. Robbie told us that it was an error with the car itself, and that we should just switch to Port B. However, our first car, Belle, had an existing issue with Port B. 

Hence our first car switch of the day! We got another car, named Jasmine, and we were very excited to have a nicely working car. Now, the program worked to make one wheel follow the other, so we moved to trying to get the car to drive straight. Our first idea was to use our wheel-following program, with the adjustment of setting Motor C to be on. However, we soon found that we should take away the stopping and backwards-moving parts of that program, since they would never be necessary and could be counterproductive. On Robbie's suggestion, we changed to a model of telling the car to turn either left or right, depending on whether the car was pulling to the left or to the right. 

The first program for driving straight. 

The program works by telling Wheel B to spin at a constant power, and Wheel A will speed up or slow down depending on whether the car needs to move to the left or to the right. 

Jasmine, without any modification, will turn to the left quite sharply. Running this program, it only bears slightly to the left. We couldn't see a reason within our program that would cause it to favor the left, and we even wrote a version that switched Wheel A and Wheel B, and the result was the same. To see if our program was working at least, we borrowed another car, Cinderella, which drove very nicely straight while running the program. 

At this point, Amy suggested that we try yet another car, Aurora, since Jasmine was still pulling to the left. Now, we started coming up with programs that would stop the car at the top or bottom of the ramp. First, we implemented a light sensor stop, which worked well on the way up, but the car moves so quickly going down the ramp that it passes right over the tape without registering a difference in the light sensor. We found the "stop stack" command very useful to make the car implement a final stop and stop checking or trying to move. (this program, and the ultrasonic sensor version, are included in the last picture in this post). 

Going down the ramp, but missing the tape:

To help the car stop at the bottom, we wrote the below program to use the ultrasonic, rather than the light, sensor to stop the car. 

Going up the ramp, stopping with ultrasound:

At first, it seemed to be going well, but we noticed that Aurora went really fast all the time. After noticing no change even when we changed our base speed to 20, we started testing again. After running this simple program:

Wheel B was still spinning full speed while Wheel A was stopped (as it should be). To get around this bizarre problem, we connected the motor to Port C instead. But suddenly, instead of driving straight, the car started spinning! We tested again by printing the counts and individually turning the wheels, and found that counta increased going forward and decreased backward, but countc decreased going forward and increased going backward. We changed our error expression from counta-countc to counta+countc to compensate from this. 

We also noticed, with Juliette's help, that our methods for turning right and left were identical, because the sign of the error changes depending on whether we want to turn left or right. We were able to remove the conditional and simplify the program: 

Our final collection of methods: "turn" which increases or decreases the power to Wheel A depending on whether the error is positive or negative, "drivestra" which starts the car out to drive forward and then calls another method to keep it going straight, "three" which simply keeps the car driving straight, "sonicrun" which goes straight until it is 15 units from an object, and "taperun" which goes until it passes over something dark. 

In the end, the car can go up the ramp and stop, but still goes much to fast down the ramp. Going down, it tries to compensate, but the wheel can never have more than 100 percent power and therefore cannot compensate powerfully enough at that speed.