Week 3 Summary

In week 3, we are all starting to finalise our parts of the project.

Here is Abdul Wahab's summary for week 3:

In the third week and after conducting a research in how to get more accurate responses from the Arduino code, the most accurate function to use is the if + else if statement and combine this function with the Boolean logic OR & AND statements. The final code was more accurate and it can to certain degree know which level that have been passed by knowing the mathematically measured values and compare it with the values that have been measure in the analog input. Moreover, in order to get more accurate feedback from the Arduino code, the code should have a range of values that was calculated by getting the error from these and were implemented in the code. 

Adam completed all 3 Levels for the game code, heres his summary:

Level 3 consists of a RC circuit, and involves finding the resistance of the resistor that will result in the capacitor being charged to a certain voltage in a specific amount of time. This is the hardest level of the 3, and will require the student to use the natural log, which they may not have been taught in GCSE's. In regards to organising the game code. Erik told me about a method used in Visual Studio. It involves having a C++ file for all the function defintions, a header file for all the function declarations, and a final C++ file for the main body, which will be calling functions from the functions.cpp file. The header file is included in fuinctions.cpp and main.cpp so they can be used together. With visual studio, these files are all stored inside one "project". Heres a photo of the layout:


Erik's week 3 progress:

The code no longer hangs when trying to connect to a device that is not an Arduino. Initially I attempted to run the checks on a new thread, however. The solution I have used to solve the issue involves editing the source code of the library I am using to add a line that throws a runtime error if the connected device is incompatible, which will progress to the next port when caught.




Comments

Post a Comment

Popular posts from this blog

Week 4 summary

In week 4, we were mainly making small changes to our code for the bench inspection. Heres Erik's summary for week 4 During testing the communication after connecting the computer and Arduino, I discovered that at seemingly random points the Arduino would be reset and the rest of the program break as a result. I believe the cause of this issue is that the destructors for the ‘SerialPort’ objects are called once functions end. This issue could not be fixed in time for bench inspection, so instead of having the game code and arduino code interface with each other, they will both run independantly and the user will use the arduino to read the voltage and confirm its correct, then use the game code to input the resistance value and move onto the next level. Adams progress for week 4: After the change in functionality because of the communication code not working, we decided to have th game code and arduino code run independantly. I had to modify the game code to prompt the user...
Read more