Group weekly reports
Ilir Bylykbashi
Summary:
This week, we had a presentation on Monday that took several hours. Due to the presentation, I didn’t have the opportunity to work further on the project that day.
Throughout the week, my focus has been on establishing radio communication between two micro:bit units. Currently, we have two micro:bits, and we want to utilize both of them. I’ve been working on creating code that can transfer real-time information from one micro:bit to another, allowing us to receive sensor or motor data. This required making modifications to the main code, setting up loops, and configuring values to ensure smooth operation.
We successfully achieved our objective, creating a system that operated as if we had a single micro:bit connected at all times, with the transmitted information remaining consistent. To achieve this, we introduced the following code:
#include <Arduino.h>
#include <NRF52_Radio_library.h>
We’ve included a screenshot of the receiver’s code in this report, but please note that the main micro:bit’s code is considerably more extensive and intricately integrated into the project, making it impractical to include it here.
Challenges:
Our progress was not without its challenges. One significant challenge was managing the power consumption during radio transmission. Initially, we set the transmit power to its default value, which was 4. This decision resulted in inconsistent sensor readings. While various factors could have contributed to this issue, reducing the power settings proved to be a practical solution. This adjustment resolved the issue with receiving unstable sensor readings.
Moreover, we recognized that higher transmission power could lead to signal interference within our micro:bit setup, prompting us to opt for a lower power setting as the most suitable solution for the time being.
In conclusion, this week marked significant progress in our project as we achieved seamless radio communication between micro:bit units. Despite initial challenges related to power consumption and signal interference, we have successfully laid the foundation for more advanced functionalities.
John Frederick Lærum
Summary:
This week I have been updating some of the existing code in our project. While going over our code I found a simple, but “stupid” fault in our StateMachine.cpp where after doing NumberOfReadings and storing the average in the result variable we did actually take a new single reading to determine which state to transition to. Updated it to instead be based on the result variable that we generate.
Also added mostly for testing now turn left, right and around functions that we will be needing during traversal and speedrunning in the maze. A challenge tied to the turning is to make sure we implement it in a way that we are confident the mouse will stop at the correct orientation more or less at least.
As I had the two micro:bits I tested the implementation Ilir did in our project and joined working with the implementation.
Video of output:
https://www.youtube.com/watch?v=8qQu5YN8I4o
Ahead now I will turn my focus to implementing mapping. Storing cell values with different conditions/values to represent walls in cells which we will be using to map the maze. I imagine we will do a step-by-step solution to implementing the algorithm to solve the maze, implementing a mapping system for the cells is perhaps a good point to start.
Thomas Frimann
Summary:
Modelled two versions of the labyrinth, one 18×18 and one 36×36. For walls, Daniels’ posts are intended to be slightly modified for use in this model I have designed.
further modified and prepared the platform for the mouse and some covers for 3D printing for next week. Also started making a part to adjust motor placement/tightening against the drive wheel.
Daniels Blomnieks
Summary:
Modeled 18X18 maze
Sigurd Sætherø Spangelo
Summary:
(awaiting submission)