Group-22: Lab Notebook 8 - Robot Race

Date: 05/05/2015

Group members participating:

• Christian Bonde Andersen
• Nikolaj Cilleborg Haulrik
• Rasmus Meldgaard Petersen
• Jesper Kurtzmann Svith

Activity duration: (6+7+7+4)*4 = 96 hours

Overall goal

In this lab session the overall goal is to build and program an autonomous LEGO robot [http://en.wikipedia.org/wiki/Autonomous_robot] that can complete a course (fig ??) as fast as possible. The robot starts in the green zone at the bottom. Then it goes up the ramp and turns at the top before it goes back down the ramp and finishes in the green zone.

Fig. 1: The course of this weeks lab session, “The Alishan train track”.

Our approach to this lab session is to try different approaches and methods to complete the course instead of just making one robot and optimizing it the best way possible. To do this we make four different experiments:

• The first experiment is to construct a high speed robot using a gearing system that can quickly accelerate the robot up the ramp.
• The second experiment is to use a light sensor and a PID controller to drive the robot along a black line.
• The third experiment uses a behavior pattern to prioritise different behaviors to be executed by the robot on different parts of the course.
• The fourth experiment will use a simple robot which has been hardcoded to drive and turn according to the course dimensions.

At the end of this report we will sum up and compare the advantages and shortcomings of the four experiments in order to determine which approach is more feasible.

Experiment 1: Fast robot with high gearing

Task

For the first experiment our main focus is speed. This is relevant as the robot will compete on the racetrack. To obtain higher speed we implement a gearing mechanism on both motors and test it on a straight track.

Plan

The goal for this experiment is to learn about the cars behavior when using gears on the motors. For this experiment we use a basic car setup (see fig.1) with the opportunity to mount other sensors as well.

Fig. 2: Robot with high gearing from the electrical motors to the wheels.

To test the robot we use a straight track and a basic program which powers the motors equally all the time in order to drive forward:

     while (! Button.ESCAPE.isDown())
     {
    
	     car.forward(power, power);
	      
	 	     	     
	     Thread.sleep(60);

     }

Fig. 3: Showing the code used to drive the high-speed robot forward. The power is distributed equally to the wheels as we are only concerned about a straight motion.

Results

Through this experiment we learned that gearing the motors causes significant problems to the robots path. The robot has no problems accelerating to it’s maximum speed, however if the robot experiences disturbances on it’s path i.e a small bump, the robot will go into a spin. What happens is that the high speed combined with low friction causes one of the wheels to slide (with the same speed) while the other wheel tries to catch up to the other. This behavior can all be seen in the video:

Fig. 4: Video showing the robot go into an uncontrollable spin after a small push. First to the right, then to the left.

We can conclude that gaining momentum is not necessarily an advantage for the robot as it comes with a cost of increased vulnerability to its driving behavior. If we were to maintain control of the robot, it would require a significant amount of code to prevent the robot of going into a spin. This could be done using a PID controller to perform frequent corrections to the power distributed to the wheels.

Though a PID controller could improve the robot’s stability, we must consider that part of the robot’s behavior is caused by frictional problems. This means that though a PID controller may control the power, the wheels will still rotate at at very high rate and thus making the robot slide. This problem may be solved using wheels with a larger radius, or by implementing an acceleration behavior to the robot.

Experiment 2: The Race car with one light sensor.

Task

For the second experiment we want to obtain a more controlled robot. To do this we abandon the idea of gearing the wheels and stick to a more traditional build with the motors powering the wheels directly. Additionally we implement a PID controller in order to follow a black line precisely.

Plan

To build a race car robot with wheels mounted directly to the motors and a light sensor to be used for the PID controller.

Results

We built the robot as seen in fig 3 with the light sensor mounted in the front. This makes it easy for the robot to follow the car. When the wheels are directly mounted to the motor the build can be made pretty simple. Though in our case the design evolved into a dragster looking race car.

Fig. 5: The Racecar robot with swingarm with one light sensor mounted on it.

Flexible front mount

As an addition to the sensors mounted in the front of the car, we decided to make the whole front of the car flexible (see Fig. 6) We knew from lab lesson 1 that the light sensor reading vary according to the distance from the sensor to the surface. By doing this we made sure that the sensors mounted to the front would always keep the same distance to the surface which can be a challenge when the robot drives over the plateaus (see fig. 6).

Fig 6: Indicates a robot approaching the hill on the racetrack. It shows why the flexible front mount is preferred to a static mount as it makes sure that the distance to the ground is the same regardless of the angle.

Fig. 7: Shows the flexible front mount on the robot. By implementing this feature we made sure that the sensor keeps the same distance to the ground throughout the course.

Driving using light sensor and PID control

The attached light sensor was used to follow the black line along the racetrack. We used the sensor readings to implement a PID-controller in order to follow the line smoothly. In lab lesson 4 we created a PID-controller for a line follower robot using J. Sluka [2] which we decided to reuse in this case (code snipped fig. 7).

while (! Button.ESCAPE.isDown())
     {
    	 
	     LCD.refresh();

	     LightValue = sensor.light();
	     float error = LightValue - OFFSET; 
	     
	     LCD.drawString("Light Val: ", 0, 2);
        	     LCD.drawInt(getLightVal(),0,9,3);
         	     LCD.refresh();
	     
	     integral = integral + error;
	     
	     derivative = error - lastError;
	     
	     float Turn = KP*error + KI*integral + KD*derivative;
	     
	     float powerLeft = 0;
	     float powerRight = 0;
	     
	     powerLeft = TP + Turn;
	     powerRight = TP - Turn; 
	     	     
	     // Only drive if power is positive
	     if (powerLeft > 0 && powerRight > 0){
	    	 
	    	 car.forward((int)powerLeft, (int)powerRight);
	     }
	     
	     if((lastError >= 0 && error <= 0) || (lastError <= 0 && error >= 0)){
	    	 integral = 0;
	     }

	     lastError = error;       
	     
	     Thread.sleep(60);

     }

Fig. 7: inner loop of the line follower PID-control class.

One main problem we encountered when first implementing the PID-controller was that the power to the motors could turn negative and cause the motor to drive backwards. To overcome this issue we made a simple if statement that only allowed a call to the drive function if the power values are positive. The next step was to tweak the PID values to follow the line precisely.

Tweaking values using a GUI

As the sensors on the robot require a lot of tweaking, we implemented a GUI to transfer values to the robot on the fly (see fig. 8). This was particularly helpful when tuning the PID controller values, as we did not have to hardcode the values directly to the nxt program. Additionally we implemented an ‘offset’ (O) and ‘target-power’ (TP) value transfer. The offset indicated the desired light-level to oscillate between, and the target power was used to increase the robot’s base speed. A video of the robot using the PID-controller to follow the black line can be seen in fig. 9.

Fig. 8: Showing the GUI used to tweak the PID controller, the ‘offset’ and the ‘target-power’ on the fly.

Fig. 9: A video showing the robot following a black line using the PID-controller.

Getting around the bends

To get the race car around the bends, we decided to hardcode a turn which would be triggered if the light sensor read a series of white readings. This caused some issues as the robot guided by the PID controller would reach the bend at different positions and thus the hardcoded turn would not always line up correctly and reach the next part of the ramp at the right angle. If the robot turned too little, it would simply miss the black line and drive of the side of the ramp.

This finding has lead us to the conclusion that we need to add another sensor. We think that a gyro sensor could better detect the change in the angle of the slope on the ramp so the next experiment is going to incorporate this.

Experiment 3: The Race Car with gyro, color sensor and light sensor

Goal

To use a behavior pattern to make the robot drive the course. Implement the color- and the gyro sensor in the car build.

Plan

We first made a gyro test setup on a separate LEGO NXT to approximate the change in angle and see if the setup worked (see fig. 10). We hoped to use a gyro for detecting the change in angle of the slope and using it to determine when a turn was coming up. We wanted to use the knowledge gained from our last lab report, so we want to implement three different behaviors as concurrent threads. One behavior for each sensor that should be prioritized in order to control the robot during straight passages, turns and one for stopping in the end zone.

Fig. 10: NXT gyro test setup.

On the track, the robot has to act according to colors, corners and the black line. To do this we implemented a ‘behavior pattern’ [1] with different prioritised behaviors. The color sensor has the highest priority and indicates when the robot reaches the goal zone marked by green color. The gyro sensor has second priority and is used to sense when the robot has reached a turn. The last prioritised behavior is the light sensor which is used for the PID controller and tells the robot to follow the black line along the racetrack. The behavior diagram and the code used for implementation is shown below (see fig. 11):

Fig. 11: Diagram showing the prioritised behaviors implemented in the robot.

public class RaceCarMain {
	
	public static void main (String[] args) throws Exception {
		
		SharedCar [] car = { new SharedCar(), new SharedCar(), 
                			 new SharedCar()};
		
		CarDriver cd = new CarDriver();
		
		Goal goal = new Goal(car[0]);
		Bump bump = new Bump(car[1]);
		LineFollowerPID follow = new LineFollowerPID(car[2]);
		
		// Room for more behaviors
				
		Arbiter arbiter = new Arbiter(car, cd);
		Button.waitForAnyPress();
		
		arbiter.setDaemon(true);	    
           arbiter.start();
       
           follow.setDaemon(true);
           follow.start();
        
           goal.setDaemon(true);
           goal.start();
                
           Delay.msDelay(2000);
        
           bump.setDaemon(true);
           bump.start();
	}
}

Fig 12: Code snippet from RaceCarMain.java showing the hierarchical behavior implementation. The robot prioritises in the following order ‘Goal’, ‘Bump’ and ‘PID’.

Results

Results from the gyro test gave us a value to trigger the behavior. When the robot is stable the gyro measures a raw value of roughly 600. When the robot drives over a bump at the plateau the value dips to around 500. When testing the behavior on the ramp, we found that a value of 560 would trigger the turn, while still not registering any small bumps made by the robot itself.

After testing we mounted the extra sensors to our pivot mounting rig as seen in fig 13.

Fig. 13: Showing our robot for this experiment. A light sensor, a color sensor and a gyroscope is mounted in the front and the wheels are mounted directly to the motors.

Gyroscope

The racetrack is equipped with three flat plateaus separated by three steep paths. One of the track’s challenges is to detect when the robot is on a plateau. Multiple approaches can be used to overcome this challenge. In order to detect the three plateaus on the racetrack, we use a gyroscope. The idea is that angular changes to the robot’s path can be detected by the gyroscope (see Fig. 14) and thus indicate that it is time to turn.

Fig. 14: Shows the robot on the racetrack. The gyroscope’s job is to detect when there is a downwards angular change and a plateau has been reached.

Troubleshooting During testing we encountered a strange glitch in the code where the robot would ignore the given PID values and input from the gyro, despite the gyro having the highest priority. We still do not know why this happened. In the end we made the gyro having the 2nd priority, after the color sensor.

The way we programmed the PID controller, the robot is only able to work its way from right to left when looking for a black line to follow. This meant that the robot should always be started to the right of the black line when beginning the program.
Finding: Target power (TP) in the PID controller heavily affects how well the robot is able to locate the black line it is supposed to follow. We then encountered a more serious problem. The robot would pass over the black line and not correct itself enough to actually follow the direction of the line. We tried to implement a behaviour where the robot would stop after turning a corner and slowly adjust to find the black line again. (see fig 15).

Fig. 15: Illustration of the soft turn needed for the robot to slowly find the black line again.

We had issue with the gyro being triggered when starting the robot, because of the movement of the operator. This resulted in the robot thinking it was at the first corner, and would therefore turn right, after getting out of the green start zone. To solve this issue we used a time measurement to register when the program was started and only start the inner loop of the gyro sensor class when 1.5 seconds had passed. This ensured the robot would be on the slope of the ramp before measuring for bumps in the plateau.

After solving the issues we encountered we managed to complete first half of the run (see fig. 16). To finish the entire race course we had to fine tune the hardcoded turns for the remaining plateaus.

Fig. 16: This video shows the race car robot doing the first half of the race course. It manages to turn in the first corner, but gets stuck in the next corner due to a missing hardcoded turn.

Experiment 4: Hard coded car with no sensors

Goal

Our goal with our last experiment, was to see if we within reasonable time could make a robot follow the track, without using sensors whatsoever. To do this we wanted to implement the NXTRegulatedMotor, so we could give specific commands to the two electrical motors, instead of just a power level and duration.

Plan

We intended to accomplish this by measuring the length of the track that the robot had to drive. We then measured the diameter of the wheels and calculated the circumference. We could then use the length of the track and circumference of the wheel to calculate how many rotations that the wheels would have to turn in order to cover the desired distance. We then calculated the number of rotations in degrees, since this is the required input for the NXTRegulatedMotor.

In order to turn the facing of the robot 90 degrees, we would turn one wheel 180 (in reality 190 degrees) in one direction and the other wheel 180 (again 190 degrees, due to the motors) degrees in the opposite direction. To turn the facing of the robot 180 degrees, we would turn each wheel 360 degrees in opposite directions.

Diameter * Pi = circumference

81.6mm * Pi = ~ 256mm

Distance to cover: distance / circumference = number of rotations

Distance of turns: 380mm / 256mm = 1.48 ~1.5 rotations

Distance of the long side of the track: 1850mm / 256mm = 7.22 ~ 7.2 rotations

We also did two small experiments to make sure that the mathematical theory was correct, as there is always the chance of the electrical motors being inaccurate because of wear and tear. The first experiment was to see if the distance covered was the same as the circumference of the wheel:

Fig 17: The test setup for measuring the distances covered by one rotation of the motor. The arrow indicates where the robot started and the line at the wheel is where it ended after one rotation.

We learned that the robot only covered a distance of 24,7 cm, and not 25,6 cm as it should have. Here we also noticed that the robot was slightly at an angle comparing to where it started.

We then conducted a small experiment to see if this was the same case when turning, and we found that is was, but it was inconsistent how much the electrical motors would turn, resulting in a slight variation in angle on every turn.

We came up with the following route that the robot would have to drive to make it up the track and all the way down again. We hoped that there would be enough room on the track to have enough space for the robot to make small mistakes.

Pseudo code: 7.2 rotations forward, 90 degrees right, 1,5 rotations forward, 90 degrees right, 7.2 rotations forward, 90 degrees left, 1.5 rotations forward, 90 degrees left, 7.2 rotations forward, 180 degrees, 7.2 rotations forward, 90 degrees right, 1.5 rotations forward, 90 degrees right, 7.2 rotations forward, 90 degrees left, 1.5 rotations forward, 90 degrees left, 7.2 forward, (Stop)

Fig. 18 - Distance that the robot is supposed to drive.

Results

We managed to finish the track with a hardcoded robot in 57 seconds. When running this way, the robot is far from reliable, since the smallest error in the deployment of the robot can result in a failed run. Likewise, any changes in the environment (track) will almost certainly result in a failed run. We encountered dust and dirt at some point on the track, which made one of the wheels spin out. This made the robot drive off at a slight angle, something that made it drive off the track on the way down again. Theoretically the fastest possible run for this rigid type of hard coded approach would be 27 seconds, but the robot itself is not able to accelerate accurately at that speed (x3), as one wheel often spins out. This is because of lack of grip of the cheap rubber tyres and the robot trying to accelerate instantly to the required speed.

Fig. 19 - video showing the “proper” run (featuring Rasmus as assistance)

Fig. 20: Pros and cons of hard coding a robot for racing

During this last experiment, we learned that there are many shortcomings of hardcoding a robot to drive a specific track. Even though the perfect way through a track is known, there will always be uncertainties and small differences in the beginning of the run can cause big trouble in the end.

Conclusion

Through the four experiments we explored different approaches and methods of obtaining an efficient robot for the Alishan train track. Our findings showed:

• Though speed is an essential component when competing on the Alishan race track, we conclude that gearing the motors is not ideal. Our experiment revealed frictional problems with the wheels lacking the ability to find grip at its maximum speed. To overcome this issue an acceleration method in the program may be feasible. Additionally the robot was very prone to crashing and going into a spin at high speed.

• Using a PID controller makes the robot follow the black line precisely along the track.

• Hardcoding the Alishan track corners into the robot’s program was not 100% accurate, as it was difficult to find the black line after a completed turn. For this we tried to methods: One where the robot reacted once several white readings had been conducted by the light sensor and one where the turn behavior was triggered by changes measured by the gyroscope. For further experiments other solutions may be preferable.

• As the track features flat plateaus and steep paths, the light sensor will become inaccurate as the distance to the ground varies. To overcome this problem a flexible front mount proved to be efficient in keeping the readings consistent.

• A GUI for the PID control is essential in order to spare the struggle of hard coding values into the program.

• A behavior pattern is very efficient to manage and prioritise different behaviors.

• Hard coding everything is a fast approach to complete the track. However this approach reveals some significant shortcomings. Hard coding makes the robot prone to the slightest affections, and once the robot goes out of its path, there is no way it will complete.

• A mix of hard coded corners and a PID controller to stay on track may be the more preferable way to an efficient robot on the Alishan track.

References

[1] Behavior pattrn: Jones, Flynn, and Seiger, "Mobile Robots, Inspiration to Implementation", Second Edition, 1999, http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/11128_Mobile_Robots_Inspiration_to_Implementation-Flynn_and_Jones.pdf

[2] PID controller: J. Sluka, http://www.inpharmix.com/jps/PID_Controller_For_Lego_Mindstorms_Robots.html

[3] Autonomus robots: http://en.wikipedia.org/wiki/Autonomous_robot

[4] All code: https://drive.google.com/open?id=0B7MCCWb4fFztfkQ4aVZFaF9tUnljYm43YzJlM0xNQ2ZSNHVCbGFMRllTWGlNWVgtLTJSSFU&authuser=0