@@ -63,11 +63,11 @@ Which simply stops the motors and exits the system if the ESCAPE button is press
In detect wall we have added a proper suppression so that the escape behavior can take precedence.
##### Observation of the behavior
When we push the button when the robot is driving forward, it stops immediately. However if it is pressed when it just started avoiding an obstacle, we saw a weird behavior, where the robot reached a state where it the current action for avoiding is allowed to follow through, but the it did not stop the program afterwards, but detect wall was suppressed, so if it was near an obstacle, it was simply standing still. If we pushed the button later in the avoidance period it finished up and exited as we expected.
When we push the button, when the robot is driving forward, it stops immediately. However if it is pressed when it just started avoiding an obstacle, we saw a weird behavior, where the robot reached a state where it the current action for avoiding is allowed to follow through, but the it did not stop the program afterwards, but detect wall was suppressed, so if it was near an obstacle, it was simply standing still. If we pushed the button later in the avoidance period it finished up and exited as we expected.
#### Taking control
The arbitrator have a monitor that looks at all entries in the list of behaviors and sees if the behavior wants to get control. This is done by running through the list from high priority to low priority and returns the entry with highest priority which want control. The method breaks out of the loop as soon as it finds a behavior that wants to take control, so a high priority behavior will shadow for a lower priority behavior.
The arbitrator has a monitor that looks at all entries in the list of behaviors and sees if the behavior wants to get control. This is done by running through the list from high priority to low priority and returns the entry with highest priority which want control. The method breaks out of the loop as soon as it finds a behavior that wants to take control, so a high priority behavior will shadow for a lower priority behavior.
#### Separating taking control and distance measurements
...
...
@@ -154,11 +154,11 @@ Because we do not need dynamic behavior, we have chosen to do our implementation
### Initial construction of the robot
The main purpose of the robot should be not to lose. To achieve this we got the following general idea for building our robot which was to have as many useful and different sensors as possible. This should reduce the chance that our opponent could trick our robot into doing something unintended to a minimum. One of the first things we realized was that we could have multiple touch sensors connected to the same port, using cables for RCX sensors, which fit our idea nicely.
The main purpose of the robot should be not to lose. To achieve this we got the following general idea for building our robot, which was to have as many useful and different sensors as possible. This should reduce the chance that our opponent could trick our robot into doing something unintended to a minimum. One of the first things we realized was that we could have multiple touch sensors connected to the same port, using cables for RCX sensors, which fit our idea nicely.
The original building plan for the robot was to build a big wall around the robot to protect against whatever unpredictable thing our opponent would do. Among these we wanted to prevent another robot to drive something below our robot and lift it from the floor.
Behind each wall we wanted 2 touch sensors one in each end for a total of 8. The idea here was that we could use the ultrasonic sensor to detect the direction of an opponent, and use the touch sensor to detect when the robot was right next to our robot. By having touch sensor all the way around our robot and only try to push the opponent’s robot when they are pressed, we should be able to avoid the case where the opponent's robot drops something and our robot using the ultrasonic sensor interprets the dropped item as the opponent's robots, since that item probably won’t be heavy enough to push in the touch sensors.
Behind each wall we wanted 2 touch sensors one in each end for a total of 8. The idea here was that we could use the ultrasonic sensor to detect the direction of an opponent, and use the touch sensor to detect when the robot was right next to our robot. By having touch sensors all the way around our robot and only try to push the opponent’s robot when they are pressed, we should be able to avoid the case where the opponent's robot drops something and our robot using the ultrasonic sensor interprets the dropped item as the opponent's robots, since that item probably won’t be heavy enough to push in the touch sensors.
To detect the white edge of the arena plate, we wanted 2 light sensors in front connected to one port and 2 light sensor in the back to another port.
...
...
@@ -168,7 +168,7 @@ We wanted to use the ultrasonic sensor to find our opponent without having turn
Image 2: Image of partial build original idea
We started building our robot, but we didn’t get that far before we checked the weight and discovered it was way too heavy and so we had to cut down on a lot of things.
We started building our robot, but we didn’t get far before we checked the weight and discovered it was way too heavy and so we had to cut down on a lot of things.
After cutting down we had only small walls and no walls behind the robot, we also cut the light sensor behind the robot plus some other small optimizations and we managed to get below 1 kg.
...
...
@@ -179,11 +179,11 @@ Image 3: Image of ultrasonic version of the robot.
### Programming the robot
#### Line detection
The first behavior we implemented was detecting the line, and turning away from it. The detection is done by looking at the median of the black and white values, if the measured value is lower we see black if higher we see white. Then we turn on the spot in a direction dependent on which sensor has been activated, if both the robot drives a little backwards.
The first behavior we implemented was detecting the line, and turning away from it. The detection is done by looking at the median of the black and white values, if the measured value is lower we see black if higher we see white. Then we turn on the spot in a direction dependent on which sensor has been activated, if both the robot drives a little backwards before turning.
#### Ultrasonic Behavior
As distance readings, from the ultrasonic sensor, blocks the thread, we implemented this behavior in a separate thread. The *Behavior* class could then request the latest reading. Using the *NXTRegulatedMotor* class, we pointed the ultrasonic sensor forward, then 45 degrees to the right and finally 45 degrees to the left. Using distance values, from the three angles, we estimated turned the robot in the direction with the shortest distance.
We however found that the motormounted ultrasonic sensor was simply too slow. It took about one second to do the entire reading of forward and 45 degrees left and right. Meaning that the guess of the position of the other robot always will be way too outdated, so we could not use the guess for anything constructive. One second is a lot of time in a lego sumo match.
As distance readings, from the ultrasonic sensor, blocks the thread, we implemented this behavior in a separate thread. The *Behavior* class could then request the latest reading. Using the *NXTRegulatedMotor* class, we pointed the ultrasonic sensor forward, then 45 degrees to the left and finally 45 degrees to the right. Using distance values, from the three angles, we turned the robot in the direction with the shortest distance.
We however found that the motor-mounted ultrasonic sensor was simply too slow. It took about one second to do the entire reading of forward and 45 degrees left and right. Meaning that the guess of the position of the other robot always will be way too outdated, so we could not use the guess for anything constructive. One second is a lot of time in a lego sumo match.
Because of the disappointing results, we chose not to use the ultrasonic sensor.
...
...
@@ -196,9 +196,9 @@ By discarding the motor and the ultrasonic sensor, we suddenly had a bit more we
Image 4: The robot after removing the ultrasonic sensor and adding touch sensors in the back.
With this design we however have another problem. We only know if have something in front of us, which is what we want, or if we have been touched on one of the three sides we do not want. Then we got the idea that we might be able to distinguish the walls from each other by small differences in the raw value from the touch sensors. This will be possible if the sensors are inaccurate i.e. the sensors do not all produce the same value, but precise i.e. the sensors keeps reproducing the same value. If they did, we could make an analog to digital converter [11] on our NXT, thus freeing up ports while we get all the information we wanted.
With this design we however have another problem. We only know if have something in front of us, which is what we want, or if we have been touched on one of the three sides we do not want. Then we got the idea that we might be able to distinguish the walls from each other by small differences in the raw value from the touch sensors. This will be possible if the sensors are inaccurate i.e. the sensors do not all produce the same value, but precise i.e. the sensors keeps reproducing the same value.
Every bumper is mounted on two touch sensors. We tested all the unused touch sensors in LegoLab, and found the the raw value returned by SensorPort.readRawValue() ranged in 181-185 with readings from the individual sensor being fairly consistent. We were able to pair touch sensors to get raw values of 98, 99 and 100. It was possible to get readings of +/- 3, but most readings of the paired sensors were the same. Because the individual sensors are paired with another sensor with similar raw value, we are also able to detect which bumper is pressed, even when only one sensor is pressed. Although detecting which bumper is pressed using the raw values, may sometimes be imprecise, it is still better than random guessing.
We tested all the unused touch sensors in LegoLab, and found the the raw value returned by SensorPort.readRawValue() ranged in 181-185 with readings from the individual sensor being fairly consistent. We were able to pair touch sensors to get raw values of 98, 99 and 100. It was possible to get readings of +/- 3, but most readings of the paired sensors were the same. Because the individual sensors are paired with another sensor with similar raw value, we are also able to detect which bumper is pressed, even when only one sensor is pressed. Although detecting which bumper is pressed using the raw values, may sometimes be imprecise, it is still better than random guessing.
```java
intvalue=SensorPort.S1.readRawValue();
...
...
@@ -245,12 +245,12 @@ Our final implementation can be found on GitLab[8].
Image 6: The test robot
We created another robot as seen in the image above. The original purpose of the robot was to test the ultrasonic sensor, since it was difficult to do this without having an opponent to detect. We also had a lot of use out of it to help us think of ideas and in general test our robot without help from other groups.
We created another robot as seen above in image 6. The original purpose of the robot was to test the ultrasonic sensor, since it was difficult to do this without having an opponent to detect. We also had a lot of use out of it to help us think of ideas and in general test our robot without help from other groups.
It was not possible to test the robot against an opponent, after completion. We did test the robot against different opponents during development. Video [10] shows a battle during the final stage of development.
# Conclusion
We have been very limited by the weight limitation, because of our vast amounts of sensors and especially the rcx cables. We have found that a motor mounted ultrasonic sensor is simply too slow to use in a sumo fight, a solution could have been to use two ultrasonic sensors, but we did not have weight or sensor ports to spare. Most interestingly is our experience with using multiple touch sensors connected to the same port through rcx cables. It was surprising how well we could distinguish the sensors solely because of small differences in the measured raw value.
We have been very limited by the weight limitation, because of our vast amounts of sensors and especially the RCX cables. We have found that a motor mounted ultrasonic sensor is simply too slow to use in a sumo fight, a solution could have been to use two ultrasonic sensors, but we did not have weight or sensor ports to spare. Most interestingly is our experience with using multiple touch sensors connected to the same port through RCX cables. It was surprising how well we could distinguish the sensors solely because of small differences in the measured raw value.
