... | ... | @@ -107,7 +107,7 @@ The robot was still moving very slowly, so we changed the motor powers in the tu |
|
|
|
|
|
#### Experimenting with faster initial ramp climb
|
|
|
|
|
|
We wanted to find a faster method for climbing the first ramp than using the old LineFollower program. As described, we initially disabled line following and instead used the program **_FullDownie.java_**[5] which simply makes the robot drive forward with full speed. We did this to see if, by positioning it correctly, we could get the robot to go straight up and not drive off the ramp.
|
|
|
We wanted to find a faster method for climbing the first ramp than using the old LineFollower program. As described, we initially disabled line following and instead used the program **_FullDownie.java_** [5] which simply makes the robot drive forward with full speed. We did this to see if, by positioning it correctly, we could get the robot to go straight up and not drive off the ramp.
|
|
|
|
|
|
The robot performed very poorly, often making a sudden turn off the track. After taking a closer look, we ended up replacing the left motor, a LEGO-stick-thing, and the support wheel. This seemed to improve the robot’s driving slightly, but did not fix the issues with seemingly random turns completely. We gave up on trying to get the robot to go straight without sensor input and went on to experimenting with the gyro sensor.
|
|
|
|
... | ... | @@ -117,7 +117,7 @@ The next experiment was whether or not equipping the robot with a gyro sensor wo |
|
|
|
|
|
As in the other experiments we started out by rebuilding the robot - this time using the gyro sensor. Initially we intended to place the sensor at the center of the robot (directly above the wheels). We however realized that there would be less motion on the center axis than on either front or back of the robot, resulting in more steady readings of the gyro, which in our case, where we want to detect small changes, is an unwanted property. Therefore we decided to mount the gyro in front of the robot.
|
|
|
|
|
|
To test whether the gyro sensor can be used to detect when the robot reaches a platform, we wrote a small program **GyroTest.java **[6], that records and displays the minimum - and maximum seen values so far while the robot drives forward at a steady paste (both motors run with a power of 80). We intended to log the gyro readings throughout each test, but had some errors that we couldn’t find an immediate solution for. Instead we moved on without logs and used the displayed minimum - and maximum values instead.
|
|
|
To test whether the gyro sensor can be used to detect when the robot reaches a platform, we wrote a small program **GyroTest.java ** [6], that records and displays the minimum - and maximum seen values so far while the robot drives forward at a steady paste (both motors run with a power of 80). We intended to log the gyro readings throughout each test, but had some errors that we couldn’t find an immediate solution for. Instead we moved on without logs and used the displayed minimum - and maximum values instead.
|
|
|
|
|
|
Running the GyroTest.java program was done in two tries. First we started the program on the ramp just before the platform, letting the robot drive onto the platform and reading the maximal and minimal seen gyro values. Secondly we decided to let the robot gain some momentum before driving onto the platform, and therefore started it at the bottom of the ramp and let it drive all the way up onto the platform. Neither of these runs gave a noticeable result that we felt we could rely on, when attempting to detect that the robot reached a platform and therefore should start behaving differently. This might have been a result of us driving with a fairly slow speed initially, where a faster robot would have had an easier time triggering significant gyro sensor readings. From our experiences in previous lessons, we did not feel like running the risk of spending several hours on attempting an approach that did not seem to promise a useful result. Therefore, we ended up discarding the idea of using a gyro sensor as a way of detecting the platform and moved on to build a robot that with no concern of time-consumption climbed the ramp and returned to the floor.
|
|
|
|
... | ... | @@ -131,7 +131,7 @@ We started out by rebuilding the robot such that it now had two light sensors in |
|
|
|
|
|
*Figure 2: The robot rebuilt to use two light sensor for following a line on the ground.*
|
|
|
|
|
|
After rebuilding the robot, we began implementing the **_InitialClimber.java_** [7] program. The program started out as a copy of **_LineFollower.java_**[4], and the idea was to use one of the two sensors to follow the line on the ramp, and the other to detect and initiate a turn at the big black line at the end of the platforms. The general idea can be seen in Figure 3.
|
|
|
After rebuilding the robot, we began implementing the **_InitialClimber.java_** [7] program. The program started out as a copy of **_LineFollower.java_** [4], and the idea was to use one of the two sensors to follow the line on the ramp, and the other to detect and initiate a turn at the big black line at the end of the platforms. The general idea can be seen in Figure 3.
|
|
|
|
|
|
![180 degree turn](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week1011/img/InitClimber-idea.png)
|
|
|
|
... | ... | @@ -278,7 +278,7 @@ We constructed an architecture with a class, **_Switcher.java_** [19] with a fie |
|
|
|
|
|
##### Using a bumper
|
|
|
|
|
|
An implementation similar to **_SimplePilot.java_** [16], that used a touch sensor to detect when the robot hit the wall by the track *and then* making the second 90 degree turn, was also made (**_PilotWithBumper.java_**[23]), but was never tested. To test it, we would have to refit the robot with a touch sensor, preferably with a bumper to ensure that collision with the wall would be detected no matter the angle of the robot. Since the difference to using SimplePilot seemed minor and we figured that this version would take longer to complete the track due to having to wait until hitting the wall and then backing up, we decided to postpone refitting with a touch sensor until we might see an actual gain in using one. We never got to this point. A benefit we might have seen would be the possibility of letting the robot use the bumper to align with the wall, by waiting a little before stopping upon impact, thus enabling it to enter the next ramp perpendicularly after making the 90 degree turn following collision.
|
|
|
An implementation similar to **_SimplePilot.java_** [16], that used a touch sensor to detect when the robot hit the wall by the track *and then* making the second 90 degree turn, was also made (**_PilotWithBumper.java_** [23]), but was never tested. To test it, we would have to refit the robot with a touch sensor, preferably with a bumper to ensure that collision with the wall would be detected no matter the angle of the robot. Since the difference to using SimplePilot seemed minor and we figured that this version would take longer to complete the track due to having to wait until hitting the wall and then backing up, we decided to postpone refitting with a touch sensor until we might see an actual gain in using one. We never got to this point. A benefit we might have seen would be the possibility of letting the robot use the bumper to align with the wall, by waiting a little before stopping upon impact, thus enabling it to enter the next ramp perpendicularly after making the 90 degree turn following collision.
|
|
|
|
|
|
### Discussion of alternative approaches
|
|
|
|
... | ... | |