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.
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.
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.
- 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.
Ingen kommentarer:
Send en kommentar