LAB.10 - Bump car

Date: 18/11-2010
Group members participating: Brian, Michael
_____________________________________________
Schedule for the day
- Getting the sample bumpercar to work on the NXT

Problems and progress (notes):

1. Press the touch sensor and keep it pressed. What happends ? Explain.
2. Both DriveForward and DetectWall have a method takeControl that are called in the Arbitrator. Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of DetectWall is true.
3. Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed. Exit should be the highest priority behavior. Try to press ESCAPE both when DriveForward is active and when DetectWall is active. Is the Exit behavior activated immediately ? What if the parameter to Sound.pause(20) is changed to 2000 ? Explain.
4. To avoid the pause in the takeControl method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor every 20 msec and stores the result in a variable distance accessible to takeControl. Try that. For some behaviors the triggering condition depends on sensors sampled with a constant sample interval. E.g. a behavior that remembers sensor readings e.g. to sum a running average. Therefore, it might be a good idea to have a local thread to do the continous sampling.
5. Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.
6. Try to implement the behavior DetectWall so it can be interrupted and started again e.g. if the touch sensor is pressed again while turning.

Detailed description of solution

Finale Status:
- We downloaded the example code from the Behavior programming, and at first we got some problems that it seamed not to go into the driveforward, but we found the problem to be that one of the motors in driveforward was set wrong.

1. When the touch sensor is pressed, it will execute the HitWall behavior, and in the event that it the touch sensor keep pressed, it will execute the HitWall behavior again and again until the touch sensor is released.
2. From the source code, we can't see that DriveForward class is being called when DetectWall is called, because DetectWall take direct control over the motors.
3. The way we implemented it, was to make an class that extende the ButtonListener, and made it active when ESCAPE was pressed. It works when it is avoiding an wall and when driving forward. When the ESCAPE button is pressed the program exits right away or as fast so we can't detect the differents.
4. Done.
5. Done, by using thread.sleep
6. Without any change in the core behavior in DetectWall, we just added printout to the screen, we could see that the TakeControl is called about 7 times, every time the button is pressed. Further more we experienced that the we could interrupt the HitWall progress, by pressing the button while. This made it start over again.

LAB.9 - Bump car

Date: 10/11-2010
Duration of activity: 10:15 - 13:00
Group members participating: Kaalund, Brian
-Continued-
Date: 11/11-2010
Duration of activity: 11:15 - 13:30
Group members participating: Kaalund, Brian
_____________________________________________
Goal:
- Measure the presicion over 20 inches track
- Make precise turns with tacho counter the goal is 90 degrees
- Make a track and se how well the car navigates
- explain how a avoid and return to coarse could be implemented
Problems and Solutions (notes):
- Because it is an Amarican libary they do not use the metric system so there is some calculation errors
- the precise wheel with and axel length is modified until the precise distance and angle rotation is achieved, even though we have measured it.



-
Detailed description of Tests and solutions
- The test track to evaluate our own system and the koordinate drive from lejos

- Solution to avoid objects and return to track (not implemented). The idea is that when the Lego car detects an object it will back up and turn 90 degrees. Drive forward and make an parallel path for a certain distance and then return to path.

Measurement
Calibration of turning and distance.
- 20 inches test showed it moved 19,48 inches

- Making 90 degree turn

          1: 5.8268 inch = 115 degree

          2: 4.409 inch = 94 degree

          3: 3.543 inch = 75 degree

          4: (mean value of (2) and (3)) = 3.976 inch = 85 degree

          5: 4.1 inch = 88 degree

          6: 4.19 inch = 91 degree

          The first (1) of the measurment turning 90 degrees, was the outer diameter of the wheel base.

Finale Status:

- Our own implemented koordinate system shoved a better result than the delivered from leJos, but it was not perfect as shown in video. and also not bug free.
To get it to work perfectly we had to measure the wheels precise and then add or subtract until it worked perfectly. Because there is an issue with precision.

LAB.8 - Behavior AI

Date: 04/11-2010
Duration of activity: 09:15 - 14:00
Group members participating: All
_____________________________________________
Schedule for the day
- Try the specified car class with sonic sensor.
- Behavior as concurrent threads.(disable the threads and watch them in action seperatly and in pairs)
- Describe
- Add ligth sensing behavior like car 2a and 2b from LAB.7

Problems and progress (notes):
- The car class behaves like one of the bugs from lab 7. when a object is detecded in front the NXT backs up and turn a few degrees and drives forward again. after some time is generates a sound every 10 secounds.
- The display shows the distance measurement and what state the code is in. Indicating if it is in the drive, avoid or sound state.
- only rd: The NXT drives randomly according to the codeformula "50+50*Math.random" on both wheels. It does not interact with the inverement.
- only rd,af: it drives randomly until an obsticle is detected, then it will backup and turn with a speciffic direction and then returning to random drive.

- measured ligth sensor values. Non in front about 36, and nearly in front 26. under table 26
- increased priority for the light thread so it is just beneath distance sensor, but it stil seams like it does not react on the light inverement. By diasbling all but the ligth thread is showed that the ligth values did not give enogth difference in motor power when reacting on ligth.
- [rd] enabled [af] disabled: showed that thread sleep for light sensor needs to be increased to give time for [rd] because only stop for this function was enabled. start delay for light set at 1000 old value was 100.
- [af] enabled: change to priority needed because drive light took all the time [af] can overwrite light and light can overwrite [rd]
- [ps] enabled so it can overwrite [rd]:

note: rd = random drive, af = distance sensor avoid, ps = play sound

Detailed description of solution
- After some of the problems with, the lightdrive overwriting, actual all others behavioral functions. This was a problem, as we wanted the randomdrive and the avoid obstical also to work. So that we get the same behavior out of it as before, just with an new behavior in it, go to the light.

We found that the solution was, to change which behaviors can suppress which.

Finale Status:
- The system worked and we saw the behavior of a bug afraid of ligth an avoiding things in front
- The big issue in the system is the thread individual priority and delay times. extensive testing was needed to get the bug to focus on both ligth/dark attraction and obstacles before it behaved as they had same

LAB.7 - Make a bug

Date: 28/10-2010
Duration of activity: 11:15 - :
Group members participating: Kaalund, Brian
_____________________________________________
Goal:
- Implement the 3robot types describet in the paper
- change robot 2b with 4 sensors with negative connections
- make a robot that combines the 2a and 2b solution called vehicle 3.
- implement threads to control the different systems
- implement averating over the ligth sensor values max and min

Problems and progress (notes):
- Forgot the key, Brian had to go home and get it, so the testing were delayed 30 minutes

- First succesful test, vehicle 1, shoved a fault in the threshold values for the RCX ligth sensor.
The problem made the robot seem aggressive and taunting, so a calibration solution were tested, and it made some of the problems go away but not all of them. We can't seem to figure out why.
- vehicle 2a implemented and worked unless both sensors sav black/white, kaalund forgot that sequence.
- vehicle 2a worked as it should after implementing the required state.
- vehicle 2b implemented by changing the ports as shown in the above picture. Then it showed it is attracted to ligth as long as the sensor values were different. The 2 states defining what to do when both sensors show the same have to be modified. And that works.
- Vehicle 3 constructed by letting the 2 ekstra sensors point up. The reason for that is because we cannot see the difference in value between green and read
- Vehicle 4 is vehicle 2b, just with the motors in is own thread, so there an minimum of two threads ( main and motors ). This was implemented by using the Car class, that was provided in an previous lecture. We also was thinking about making, the reading of the sensors in an class for it self, so it could be in its own thread, and making the sensor updating the high and low values. and returning it to an thread safe value class. This will making the main program an lot smaller. But the problem with this method, is that we will not be able to control when the sensor data is transfered to the motor thread. This is the main reason we did not do it this way, but just implemented quick solution, in an light sensor class.

Detailed description of solution
- The first couple of the robots was, programed in one function, namely the main function. Where there was made an calibrate function for the light sensor (We used the RCX light sensors). First after the robot where we was going to use threads, we implemented an light sensor class to do the calibrating and determine where there is something in front of the light sensor or not. By using an function to determine if there is something in front of the light sensor, is the readability of the code. This class has to be initialized for each light sensor, where as the car class, does not need to be initialized for each motors, because the motors are "hard" coded in to the function.

picture shows the setup vehicle 3

Finale Status:
- We finished building all the robots and they all worked, not all of them worked like we wanted to, but then again they worked in the parameters detailed in the assignment.

LAB.6 - Racing competition part 2

Date: 07/10-2010
Duration of activity: 09:15 - 16:00
Group members participating: All, but Amos went home at 13:00
_____________________________________________
Schedule for the day (the game plan):
- Amos's PID is implemented
- The cases tested last week for knowing the corners is optimized
- Find a solution for the top platform
- Find a solution for detecting the green platform

Problems and progress:
- Trying to structure the regulator into a class to improve stateupdate with sensors, works perfect

- First attempt for the cornering failed, it seems when it loses the black line in the corner it overshoot and cannot get the direction rigth.
- An idea is to disable the PID regulator when in the corner and lett at speciffic cornering program for the track take over, the idea works but need some fine tuning.
-
- start sequence implemented that makes the car run forward for at short time making sure its off the green.
- attempted to implemet a top detection but it seem that the 3'rd sensor that will give 3 black is ignored and therefore never aborts linefollower. The turning gives problems beacuse just before getting 3 black the devices turn a little, that turning radius i partly unknown. The unknown turning have been removed with some pause funktion for the line follower so theres no updating of power.
- test has shown that the 3 sensors needs to be calibrated individualy, if calibrated at the same time something goes wrong.
- sound implemented for debugging
- implemented some dataloggning for debugging
- problems on slopes with sunligth, migth be solved with threshold fixes

Measurements
-

Detailed description of solution
- The device use 3 RCX ligth sensors. The wheels are low profile racing wheels for the best traction

- The system runs frow certain states
Start sequence ->
Line follower - > Corner detection - > Turn Rigth ->
Line follower -> Corner detection -> Turn Left ->
Line follower ->
Top detection -> Run straigth and Turn 180 ->
Line follower -> Corner detection -> Turn Rigth ->
Line follower -> Corner detection -> Turn Left ->
Line follower -> Bottom detection -> Run straigth -> STOP

-
Finale Status:
-

We could'nt get it to complete the course, the problem seamst to be after the turning.

When the PID regulator is reengaged, it seamst that the problem is that the regulator, make some kind of fault. To fully understand we'll need some kind of way to debug while we are runding the robot. Perhabs with an debugning channel over the bluetooth.

So in the end our time is : hav'nt completed the course yet.

LAB.5 - Racing competition part 1

Date: 30/9-2010
Duration of activity: 11:15 - 17:00:
Group members participating: All
_____________________________________________
Schedule for the day:
- Get the existing line follower to work
- measure value from the NXT sensor
- implement the old sensor system
- measure values from the old sensor
- run line follower with old sensor
- improve sweep mode (lost black and it spins around, not a good solution)
- build soulution that takes care off all the issues

Problems and progress:
- NXT sensor green and black values in same region
- Smal bugs corrected with old sensors
- First linefollower showed loss of black line and not enough power to wheel wen driving in cirkels
- Smarter turning system failed first test, there might be problems with a motor.

- cant sample fast enough, removed screen output, but it didnt work.
- decided to move forward with a new sweep method
- implementet a 2 and then 3 sensor setup, attempted to improve line following but stil lagging

Measurements
The values are from the blackwhitesensor.java
- NXT sensor green 32-34
- Old sensor
white 32-35
green 22-24
black 18-21
- Old sensor raised 1cm
green 27
black 23
- Motor +70+ and -70
for 100 ms 9 grader
for 150 ms 2*9
for 550 ms 90 grader
that means the turn function is turn(degrees){ sleep(degrees/9*50ms + 50ms}
there is some mismatch when returning and overall but that is because of overshooting and motor not delivering the same power
- No traction uphil, experimentation with different wheels, and more speed
- we are using 3 sensors to determine the borders and and will try to optimize speed by using the total width of the sensor hookup

Detailed description of solution
- The new sweep method.
As shown on the picture the system is intended to turn lets say 10 degres left and then 20 degress to the rigth to compensate for the degrees rigth. this setup increses ontil the devise has turned 180 or has hit a black or green spot.

- 2 sensor solution: pseudo code (LS = left sensor, RS = Right sensor, W = white, B = black)
if LS and RS == B
then forward
else if LS == B and RS == W
then turn left
else if RS == B and LS == W
turn right
else
sweep mode

- 3rd sensor system improves the system by letting the car drive as long as the middle is black or one of the other sensors,exception if all are black, then there is a stopline.
example the car drives so the middle turns white but left is stil black

Final Status:
- all states of state machine that manage sensors not implemented
- no solution to detecting and turning in the corners
- no solution to stopping and turning in top-platform

LAB.4 - Balancing robot 1

Date: 23/9-2010
Duration of activity: 11:15 - 14:
Group members participating: All
_____________________________________________
Schedule for the day:
- Make the diode sensor balancing robot
- get the code to work
- make improvements
- Test difference BC/AC motor output
- follow up on last weeks sound sensor, klapping

Problems and progress:
- Testet with BC motor driving. saw some problems with balancing and then it at random times just drives and lose balance
- Tested with AC connection and it couldn't balance probably because wrong error value or motor not giving the same output power.
- trying so solve some of the issues by moving the sensor up on the robot. That Didn't work, it did how ever made it worse.
- making a robot with sensor in front and in back so it can try to even out the difference.

- Because of there is't one more of the NXC lightsensor, we had to make try to make an,

RCX Lightsensor work on the NXT and in lejOS.

The first attemts to make an test program to get some data values from the lightsensor, did not work, because of use of the wrong library.

After a little driving into the lejOS api, made it clear that the library we wanted to use, was not the right one.

The right one is to import lejos.nxt.addon.*, then the lightsensor object will then be RCXLightSensor.

There is some changes one of them is to use setFloodlight instated of using activate.
- old sensor available and resulted in wrong data, we might need older sensor library

Detailed description of 2 sensor balancing
By implementing 2 ligth sensors the plan is to minimize the error betwen the to sensors.
The goal is have the same distance in front and in back.
The problem with the design is difference in the ligth sensors and therefore there should be at calibrating sekvens

The final design have not been tested because of problems with getting the old ligth sensors to work.
They now work but the system need a specieal designet regulator algorithm for balancing.
Final Status:
- There balancing robot work for at wery short time, improvement failed.
- Our own solution were not deploid
- Motor output saw some difference and showed the lockup failiure