Emir and Jakob started testing if they could get multiple BT connections to communicate.
We constructed four simulations:
Warehouse input
Delivery car 1
Delivery car 2
Delivery car 3
We would simulate the cars driving to the warehouse input and delivering one ball each.
We designed our simulation as follows:
We start up by connecting the warehouse to all three cars.
To simulate that the car is in right position to deliver, we press the Enter button.
The car send a message to the warehouse that it can start knocking off its cargo.
The warehouse receives the message from the car. The warehouse knocks off the cargo and sends a message back, that the car can drive away (this is shown by making a wheel turn).
Emir and Jakob would test how the two different designs compared to each other.
After testing, they would decide which design they would choose.
Result
Emir and Jakob decided to use the old PD3CD3 , due to better read signal.
Journal
Proof of glitches
When a car is approaching the gate, there is a success rate of 80% that the gate opens at the right distance. In the other 20% the gate opens earlier. We constructed a test to proof the glitches occurred when approaching the gate.
Here we have a test result from the gate sensor when a car is approaching it
The gray area is the appearance of two glitches. The red line indicates the value to make the gate open.
Both the glitches would have made the gate open at a wrong distance.
Sonic tests
Test the PD4CD4 if there will be a higher success rate of the gate opening at the right distance.
Test of the new sonic sensor on PD4CD4. In this setup there is only one sensor active. Notice that the sensor on the gate has been removed (it is marked with a red circle). Here is a picture of the setup, and data from 40 seconds.
Test of the new sonic sensor on PD4CD4. In this setup, there are two sensors active. Notice that the sonic sensor has been placed back on the gate (it is marked with a red circle). Here is the picture of a setup, and data from 40 seconds.
Test of three sonic sensors active at the same time. A car is standing close, to simulate a car approaching. Here is a picture of the setup, and data from 40 seconds.
The results show that the more sonic sensors which are active, the worse the readings are. The sonic sensors will interfere too much with each other. We have decided to use the old PD3CD3, and accept that in some cases, the car will open earlier than expected.
We made a new state for making the opening and closing of the gate more stabile.
Here is a state diagram of the new code design:
Added to the old design:
Implemented traffic light in the code and physical design
Longer gate in the physical design
Added fixings to the pavement, due to the new forces of the new gate design
Picture of the GateSytem PD3KD3:
Testing GateSystem
We constructed a new part to the track so the car would be able to go around in circles.
We tested the new gate by making the car drive constantly around the track. We observed that the sonic sensor on the front of the car had some interference with the sonic sensor on the gate.
We constructed two tests.
A test where the sonic sensor on the car is turned on
A test where the sonic sensor on the car is turned off
The gate is supposed to open when the car is in a distance of 10 cm. A failed test is defined by the gate opening when the car is more than 30 cm from it.
Test 1
We made 40 tests with a success rate of 20%. The new code design had the advantage to cope with the problem of the gate opening earlier.
Video of a failed test:
Test 2
We made 30 tests with a success rate of 100%. We made the conclusion that the sonic sensor on the gate interfered with the sonic sensor on the car.
Video of a successful test:
We wanted to test the color sensor, and added the color makings on the circular track. We made the car say the names of the color whenever it passed the color. We tested green, blue, red, yellow and white.
Picture of the color track:
To our surprise the color green was triggered by the black tape, which made the green marking impossible to rely on.
The white tape was more stable than we had hoped, and can be used on the final track. All the other colors worked without any problems.
The code design of the GateSystem also support mutable cars in convoys .
Video of a successful convoy:
The traffic light worked without any problems.
Next step:
Implementing the new physical design with one more sonic sensor
Implementing the new sensor in the new code design
Emir and Jakob have come up with some solutions to the bad test result from previous tests.
The gate they have made requires some practical design of the front of the car. It will have to be flat to give a good sonic response. If the other groups make an alternative front, the gate will not function optimal.
As we see it, there is either the solution that we design a front to all the different cars, or we make an alternative gate design which seeks to support as many car designs as possible.
We will have to come up with another way to detect the incoming cars.
Gate design
The previous design is a backup which we know works with a flat front. In case we run out of time, we will add a flat front to all car designs.
We have set up two new scenarios:
GateSystem PD3CD3
We will use the same design as previous version, but add some small changes to the physical design and code design.
GateSystem PD4CD4
To support as many car designs as possible we will place another sonic sensor at the side of the track.When this sensor sees the car the gate will open. The sensor on the gate will only detect the car when the car is exiting the gate.
After finishing the physical design and the program design we constructed a test of concept. We made 10 tests with a success rate of 40%. Here is a video of a successful test:
In order to improve the test environment, we constructed a test track of the T-cross. Here is the track:
And here we have the test setup:
We had a program from previous work with line following, and made a car with a program to follow the line. We started the program at the gate and then started the program on the car. We made 50 tests with a success rate of 15%. Here is a video of a successful test:
We thought of what the problem could be. When we took raw data from the sonic sensor it gave unstable signals from the front of the car. We tried to isolate the sonic sensor. We constructed a test with a flat surface acting as a car. We made 15 tests with a success rate of 100%. We are sure that the lack of good sonic response from the front of the car is coursing the bad test results with the car. Here is a video of a successful test with a flat surface:
Next steps:
Try testing with different designs of cars and programs.
Try to make an alternative way to detect the car coming from the factory
Emir and Jakob tried to make a new design of the Gate. Both gate- and software wise.
After considering how to make the design better, we tried to cut off some weight. We added a red light so it would glow red when the gate was opened. We came up with this design:
Jakob have some experience with “State machines” and “thread programming”. Therefore we decided to make the gate control in one thread and sensor input in another tread.
The sensor input will be a “command thread”, and the other will be a “Gate control thread”.
The sensor can man make two commands:
The gate should be open
The gate should be close
We made the gate a “State machine”. The two states are:
Gate is closed
Gate is open
The program overview looks like this:
The idea of the design is:
“The gate is normally closed and the light is off. When a car (from the factory) comes in the distance of 10 cm the gate will open, and the light will turn on. When the car is more than 20 cm away from the gate, the gate will close.”
Our gate was too heavy that’s why we change it totally with cardboard box. We also put a wheel on the bottom of the gate so it can easier open the gate. We tested and it works much better now.
