Group weekly reports
Ilir Bylykbashi
Summary:
This week I have focused on trying to create an environment in which I can try to write code and pass it on to Microbit:V2 for testing. After trying different programs, I decided to use Platform IO with Arduino as it seems like the only thing that is working for the moment, which John and I both tested. We then tried to get this to work with the breadboard and the physical device.
In this week we have spent a lot of time to find out how we can divide the responsibilities between us software engineers but have found this rather difficult to do so we have mostly worked together on writing the codes and trying to assemble the small pieces of equipment that we have. We have now focused on trying to do the small things first, namely getting the motors to work and check what the result is when connecting it and after flashing the device with a new code.
The most difficult part this week has been trying to get out of the Unity project for simulating a robot going through the maze and trying to assemble the physical device with our software. Even when following countless instructions online, we still have difficulties when using Platform IO on Visual Studio Code. We will still try to use the framework intended for our Microbit:V2, but using the Arduino framework will suffice for now.
This is one of the many tests that we ran to try out the equipment.
John Frederick Lærum
Summary:
This week I’ve put the simulation i was working with in Unity on hold for a bit. I’ve been testing the motor driver board currently using PlatformIO with arduino as framework as i’ve not yet found a way to include any of the microbit libraries on platformIO. Created a motor driver class to control the two motors outputs at the driver board. Before testing with a motor connected I used leds to simulate signals and measured the outputs.
I then tested the motor with the class and i’ve had some success with this, but with the arduino framework and how the code currently is designed with writing pins analog or digital i don’t get the expected behavior. If I simply write the two pins of motor 1 to opposite digital logic values I get expected behavior. So currently i have some issues tied to whenever we introduce analog signals to control speed, because digitalwrite does not seem to “reset” it the way i would like.
This is the current motor driver class i’ve been working with just to get started and some initial testing.
This is just one of the configurations i did for testing. I also did iterations where i called upon motorDriver1.forward(255) etc, to test different values. to see how it responds. I also referred to the datasheet for the Kitronik 5698 compact motor driver board for microbit, while working on this.
Just a simple photo of how i connected the leds to display the output at the motor pins, i also made sure to measure while i did this to confirm i got expected values.
Sigurd Sætherø Spangelo
Summary:
This week, I connected the circuit for distance measurement with multiplexing, written an Arduino program in C++ to test the system, and verified that the circuit functions as intended.
Here is what the sensor array looks like in LTSpice, with four sensors:
I am using the binary decoder 74HC138 to select the sensor with a 3-bit binary number. This chip can operate at 3V and has active-low output signals, making it suitable for this circuit. The input stages for the current switches are adjusted to ensure that the current draw from the decoder chip outputs falls within the limits specified in the chip’s datasheet (by changing the emitter resistor to 390 ohms). Otherwise, the design remains unchanged from last week’s prototype.
Initially, the circuit was connected with red LEDs as loads instead of a common load with a transient filter, as shown in the circuit diagram. This was done to visually troubleshoot the sensors, as shown in the image below:
Then, a simple test code was set up to create a class called MISOSensorArray (MISO stands for multiple-in-single-out), which can be used for any similar multiplexed, multiple-in-single-out sensor array.
I envision that motor speed/position sensors could also be implemented using a similar concept, thus utilizing the same class.
The class is generic, where the generic constants are the number of sensors and the number of bits used to represent the sensor indices.
Currently, only the regular Arduino library is used to interact with the micro:bit’s GPIO pins, using digitalWrite and analogRead. All hardware interaction is handled by three methods in this class, and the rest of the methods are built upon these three. If the code were later to be changed to use a dedicated micro:bit hardware library, only these three methods would need modification.
The code was primarily written to test the sensor circuit but should serve as a useful starting point for further system development. The code is published on GitHub in the following repository: https://github.com/Joffeey/MicroMind_Autonomous. All “public” methods in the class are documented with “docstrings” that briefly explain what the methods do and provide explanations for arguments and return values where needed.
During testing, the circuit worked, as demonstrated in the video below:
The test showed that the signal measured by the microcontroller ranged from approximately 0.1 to 0.25 (where “high” corresponds to 1.0 and “low” to 0.0), meaning that the output voltage of the sensors can be increased further to better utilize the measurement range.
Otherwise, everything worked as expected. It should also be possible to reduce the measurement time by using a sharper/higher-order transient filter on the output.
I also suspect that the supply voltage is lower and may have higher impedance than expected, causing the output voltage from the sensors to be lower than previously measured. This deserves further measurements and testing but is good enough for the first iteration, I would argue.
Thomas Frimann
Summary:
This week, work has been done on 3D modeling of the front wheel construction, the belts, and a method for mounting the belts.
Simple calculations have been started for the mold form for the outer layer of the belts, and calculations have been made for other options if casting is not feasible. (It has not yet been clarified what materials and equipment are available; a request will be sent next week to determine what we have on hand).
There is also a preliminary idea about track/maze construction and how it should be designed and created (upon the request of Richard and Steven: there is a requirement list/email that I will familiarize myself with this weekend).
Challenges this week have included uncertainty about what is available and what production methods we can use. It has also been challenging when it comes to the actual sizes of parts that were initially desired to be used, leading to some redesign and new calculations.
Daniels Blomnieks
Summary:
This week I have been working on 3d modeling rear driving wheels.
Me and Thomas were discussing the type of track design we want to make, and how easy it would be to make a mold for it, if it’s possible.
we were informed that we are the ones who are gonna make the final maze. It is somewhat difficult to work with smart systems, since I need to allocate most of my time to take the retake exam that is in one week away.
Also me and Thomas had your extreme task from 20.09 kl12:00 to 22.09 kl12:00