| ... | ... | @@ -16,60 +16,117 @@ The goal for the day is to make a Lego car follow the Alishan track using a gyro |
|
|
|
|
|
|
|
The plan for the day is to build upon previous results [1]. It seemed plausible to use a gyroscope to detect when a plateau is reached however additional sensory needs to be implemented in order for the car to follow the straight inclined paths. The idea is to exploit the black line on these paths and use a light sensor to make the car follow these lines. Behavioral control will be necessary in this setup due to the car having multiple behaviors. It is estimated that hard coding is the optimal solution for the turns do the course of the black line.
|
|
|
|
|
|
|
|
|
|
|
|
## Implementing a light sensor
|
|
|
|
|
|
|
|
### Setup
|
|
|
|
|
|
|
|
In a previous exercise we used a single light sensor to make the car able to follow the edge of a black line. This is the starting point for this task. The light sensor is mounted in front of the car pointing downwards. The flood light is turned on according to results from a previous exercise [2]. A test program is made where the steering is controlled by a PID regulator. This program is based on experience gained from exercise 4 [3]. The set point was defined as the middle value between the light sensor reading of white and black respectively. In addition to this we implemented a direct PC connection in order to tune the parameters of the PID regulator.
|
|
|
|
In a previous lesson we used a single light sensor to make the car able to follow the edge of a black line. This is the starting point for this task. The light sensor is mounted in front of the car pointing downwards as seen in the following image.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The flood light is turned on according to results from a previous lesson [2]. A test program is made where the steering is controlled by a PID regulator. This program is based on experience gained from exercise 4 [3]. The set point was defined as the middle value between the light sensor reading of white and black respectively. In addition to this we implemented a direct PC connection in order to tune the parameters of the PID regulator.
|
|
|
|
|
|
|
|
### Results
|
|
|
|
|
|
|
|
By inspecting the LEGO cars line following behavior we quickly realized that one light sensor is insufficient. The Lego car is only able to follow one edge of the black line. Any deviations from this and the car will perform a 180 degree turn due to the PID implementation. The structure of the track combined with driving up and down requires the LEGO car to be able to approach the black line from both the left and the right side. The solution for this is to implement yet another light sensor.
|
|
|
|
|
|
|
|
|
|
|
|
## Implementing two light sensors
|
|
|
|
|
|
|
|
### Setup
|
|
|
|
|
|
|
|
Two light sensors are placed in the front of the LEGO car point downwards. Again the flood light is turned on in both sensors. The setup is shown in the following figure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Results
|
|
|
|
|
|
|
|
The line following capabilities is somewhat improved by adding an extra sensor. The LEGO car now follows the center of the black line instead of an edge. However, the PID regulation is slow. When the LEGO car approaches the black line from an angle the PID regulation is not able to correct for this angle and steer the LEGO car onto the black line. In this case the LEGO car just crosses the line. By inspection the cause of this problem is narrowed down to the motor control which seems relatively slow thereby affecting the PID regulation.
|
|
|
|
|
|
|
|
In the beginning of the exercise it was estimated that the LeJOS differential pilot would be the optimal solution for motor control due to its use of the tachometer. Since the turning methods of this class takes a value in degrees and a radius as input it seemed as the obvious choice in order to simply the programming of the turns. When using this class, a speed and an acceleration is defined and in order to steer the `steer()` method is called. This method takes an input from -200 to 200 as input and steers the LEGO car accordingly. The problem is that even at an extreme turn rate (200 or -200) the one motor only slows down and never turns in the opposite direction. Therefore sharp turns are excluded when using the differential pilot.
|
|
|
|
|
|
|
|
The conclusion is to change from the differential pilot to direct motor control using the leJOS MotorPort class.
|
|
|
|
|
|
|
|
|
|
|
|
## Converting to direct motor control
|
|
|
|
|
|
|
|
### Setup
|
|
|
|
|
|
|
|
### Results
|
|
|
|
|
|
|
|
In the beginning of the lesson it was estimated that the LeJOS differential pilot would be the optimal solution for motor control due to its use of the tachometer. Since the turning methods of this class takes a value in degrees and a radius as input it seemed as the obvious choice in order to simply the programming of the turns. When using this class, a speed and an acceleration is defined and in order to steer the `steer()` method is called. This method takes an input from -200 to 200 as input and steers the LEGO car accordingly. The problem is that even at an extreme turn rate (200 or -200) the one motor only slows down and never turns in the opposite direction. Therefore sharp turns are excluded when using the differential pilot.
|
|
|
|
|
|
|
|
The solution is to change from the differential pilot to direct motor control using the leJOS MotorPort class. This greatly improves the PID regulation of the LEGO car.
|
|
|
|
|
|
|
|
|
|
|
|
## Adding behavioral control
|
|
|
|
|
|
|
|
### Setup
|
|
|
|
|
|
|
|
With the plateau detection and line following behavior in place it is time combine these elements into a single program. For this we will use the behavior control paradigm from lesson 7 [4].
|
|
|
|
The two behaviors are implemented as shown in the following diagram.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Arbiter contains a list of the behaviors and constantly check, in a prioritized manor, if the behavior has available commands. This will ensure that the behavior with the highest priority will control the LEGO car, if it has any commands for it.
|
|
|
|
The PlateauPilot has the highest priority and is implemented as a Finite State Machine (FSM) which is shown in the following diagram.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The implementation of this is shown in the following code snippet.
|
|
|
|
|
|
|
|
```java
|
|
|
|
switch (nextAction) {
|
|
|
|
case pass: //starting at the bottom.
|
|
|
|
nextAction = ActionType.rightTurn;
|
|
|
|
...
|
|
|
|
break;
|
|
|
|
case rightTurn:
|
|
|
|
car.TurnRight();
|
|
|
|
nextAction = ActionType.leftTurn; //every right turn is preceded by a left turn
|
|
|
|
break;
|
|
|
|
case leftTurn:
|
|
|
|
car.TurnLeft();
|
|
|
|
nextAction = isAscending ? ActionType.rotate180 : ActionType.stop;
|
|
|
|
break;
|
|
|
|
case rotate180:
|
|
|
|
car.Stop();
|
|
|
|
car.Rotate180();
|
|
|
|
car.Stop();
|
|
|
|
isAscending = false;
|
|
|
|
nextAction = ActionType.rightTurn;
|
|
|
|
break;
|
|
|
|
case stop:
|
|
|
|
car.Stop();
|
|
|
|
isFinished = true;
|
|
|
|
long endTime = System.currentTimeMillis();
|
|
|
|
long durationms = endTime - startTime;
|
|
|
|
String winnerTime = formatTime(durationms);
|
|
|
|
LCD.drawString(winnerTime, 0, 0);
|
|
|
|
LCD.clear(2);
|
|
|
|
LCD.drawString("Next: WIN!", 0, 2);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
```
|
|
|
|
The FSM is responsible for performing all turns on the track. By letting the FSM control the stopping mechanism we avoid having a third behavior that uses the light sensor or an additional color sensor to detect when the LEGO car is in the green end zone.
|
|
|
|
|
|
|
|
Each turn is hard coded by imposing a certain power to each motor in a fixed amount of time. The amount of power and the time interval is then adjust according to manual inspection.
|
|
|
|
The hardware setup is identical to previously.
|
|
|
|
|
|
|
|
### Results
|
|
|
|
|
|
|
|
With the current setup the car is able to follow the first line on the first inclined path. However problem arise when in the plateau detection which is illustrated in the following figure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sometimes the plateau is detected to late (Problem 1) and the LEGO car continues out of the track. At other times the plateau is detected to early and the LEGO car makes a right turn too soon (Problem 2).
|
|
|
|
The behavioral control indicates that the problem is related to the gyroscope which might not receive enough impact of the incline change when mounted close to the LEGO car. A solution to this is place the gyroscope higher.
|
|
|
|
|
|
|
|
## Raising the gyroscope
|
|
|
|
|
|
|
|
### Setup
|
|
|
|
|
|
|
|
|
|
|
|
The gyroscope is raised by placing it on a long brick as shown in the following image.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Results
|
|
|
|
|
|
|
|
By raising the gyroscope and manually tuning the PID parameters and turns the LEGO car is able to drive all the way to the top of the Alishan track. On the top plateau the LEGO car performs a 180 degree turn and initiates its way back. Here a new problem arises. Whenever the LEGO car gets off the top plateau it almost immediately makes a left turn as illustrated in the following figure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Switching between PID parameters
|
| ... | ... | @@ -93,6 +150,8 @@ The conclusion is to change from the differential pilot to direct motor control |
|
|
|
|
|
|
|
[3] https://gitlab.au.dk/rene2014/lego/wikis/Lesson-4
|
|
|
|
|
|
|
|
[4] https://gitlab.au.dk/rene2014/lego/wikis/Lesson-7
|
|
|
|
|
|
|
|
|
|
|
|
### Video
|
|
|
|
|
| ... | ... | |
