This week we have concentrated on the group. With that we have divided roles, found a group name, and started mocking up the design of the car.

Group roles:

• Sondre: Group leader and car movement
  • In charge of the movement of the car
• Theo: Software design for sensors
• Matias: Sensor & Control Lead:
  • Detection and distinction between walls and objects and color recognition for the boxes.
• Anette: Documentation manager and to be determined
• Robin: Hardware Lead
  • In charge of designing the pcb for the robot, and wiring

Robin

This week, my time was dedicated to creating a library for the electrical CAD software and developing the first version of the robot’s electrical schematic.

Library Creation for the “Micro:bit Driver Expansion Board (V2.0)”

To integrate the motor control board into our design, a complete component library was created. This work was based on the official technical documentation from the manufacturer, DFRobot, including resources like their motor driver and micro:bit wikis.

https://wiki.dfrobot.com/micro_bit_driver_expansion_board_sku_dfr0548

The library I created includes:

• The Footprint: Defines the physical dimensions and the positioning of the board’s connectors on the printed circuit board.

.

• The Schematic Symbol: Represents the board and its logical connections in the schematic editor.

• The 3D Model: For integration and visualization in the final mechanical assembly.

Initial Electrical Schematic

Following an analysis of the provided robot chassis, the first version of the electrical schematic was completed. This schematic forms the foundation of the robot’s electronic architecture.

This document is a working baseline that will be expanded and improved as the project progresses, particularly with the addition of sensors  and other features.

Sondre:

This week I’ve been experimenting with shifting the robot from MicroPython to C++ using Visual Studio Code with PlatformIO. Until now, most of my coding has been done in MicroPython because it’s easy to get started with on the BBC micro:bit v2. However, after talking to Steven I have tried to shift to VS code. This was his recommendation, since Micropython has some shortcomings. 

PlatformIO in VS Code feels like a big step forward. It offers far more functionality than the MicroPython environment. Things like better debugging tools, more  libraries, and a more professional layout. That’s why I’ve decided to make the switch, even though it comes with a steeper learning curve. 

At the moment, I’m still figuring out the correct C++ code to make the wheels behave the way I want. The challenge has been translating the logic I already know from MicroPython into proper C++ functions that run smoothly on the micro:bit. It’s taking some time, but I can already see the potential benefits once I get the hang of it. 

I’ve also been testing with the L298N motor driver connected to the micro:bit. One of my goals is to use encoders to get more precise control over the motors. For now, I’m only able to use a standard external encoder, since I don’t yet have access to a DC motor with a built-in encoder. Still, it’s been a useful way to learn how encoder feedback can be integrated into my robot control system. 

Overall, this week has been a mix of progress and frustration, but I feel like I’m on the right path. Even though the transition from MicroPython to C++ isn’t simple, I believe the added functionality in VS Code and PlatformIO will give me much more control over my robot in the long run. 

Anette:

Pickup system:

This week I have mostly been looking into concepts for the pickup system. The main issue is we don’t have any machine students on our team, so I have to come up with something simple that can be done without too many variables. Another issue is where to place the system due to the car lacking free space, and the system can’t be in the way of the preexisting sensors. Therefore the goal is to find a solution that doesn’t utilize too many components, and preferably only needs one motor. This is both to minimise complexity and space. From these requirements I came up with a few different concepts:

• Forklift/shovel:
  • This is my main idea. Because we don’t have a lot of space at the bottom we can place a motor at the top and have a forklift like structure that scoops up the box and places it securely above the sensors when moving the car. The main issue here is to make it strong enough to carry the box and we need to either modify the box or place it on something in order to pick it up.
  • 
• Hook:
  • Modify the box to have some kind of handle so we can use a simple arm with a hook to pick up the box. In order to make this work we need a lot of accuracy.
• Gripping mechanism:
  • The idea was to have two arms that pinch the box and then lift it in order to carry it from a to b. Alternatively we wanted to add a compartment where the boxes could be stored in order to pick up multiple in one setting. The main issue here is this system needs two motors and a lot of space we don’t have.
• Robot arm:
  • This is a fun solution, but it’s most likely too complex for our system.
• Magnet Crane:
  • If we added a magnet to the box we could use an electromagnet with a set height to pick up the box. The problem is this will use a lot of power, especially because this needs to be on when driving back to the delivery point as well.

I’m going to present the ideas to the group on Monday so they can have a say and see if they have any comments. Then I’ll present a main and alternative idea to Richard after the meeting to get a final solution and discuss how to proceed.

Detection system:

Since this is closely related to the pickup system I have also been looking into ways and challenges that might appear when detecting the box. The area we are going to operate in is the arena we can custom build in “the cave”. This consists of some kind of floor panels with a set size and walls with a set height. We are going to look into this on Monday. These are the ideas i have been looking into:

• Distinguishing between the wall and the box by measuring the width.
  • We can do this by using the HC-SR04 sensors that are already attached to the car to measure the width of an obstacle (to differentiate between the wall and the box). This can be used to locate the box so we can proceed to the pickup process.
  • A challenge here might be if a box is located in a corner or in the blindspot of the sensors. Also we need to find a way to make sure the car is oriented the right way compared to the box in order to pick it up.
• Other methods:
  • Move the sensor in the back to the front and either point it downwards to detect differences in the terrain, or if the box is taller than the wall we can measure the height. The issue here might be how to attach the second sensor and how to make sure the pickup system is not in the way of the sensor.
  • RGB sensor in order to detect a coloured box.
  • Camera and coloured patch/dot on the box.
  • Qr code.
  • Add a small led to the box and use a photodiode on the car to detect direction.

Other:

Furthermore I have also been looking into systems from last year. This is mostly to remind myself of the processes we used, and because the other members have not had systems before. The main issue we need to proceed with before we keep working is defining our variables that we haven’t finalized yet. This includes:

• Where exactly the robot will operate
• How it will behave in the set space
• Where is the delivery point
• Order of operations
• Divide into subsystems to delegate objectives
• Finalise the design of each subsystem

I additionally made a basic group contract with Sondre that we will present on monday so people can add or remove anything if they would like.

I also talked to Steven on monday and asked about the motors and the batteries we are going to use. The motors are going to need 2 pins each, so we were advised to either use two microbits and split up the tasks, or switch to an arduino mega. If we use two boards we can split them between motion, detection, measuring and the pickup process according to how this is most logistical.

Matias:

This week I focused on exploring options for the detection system. I have been reviewing different color sensors and evaluating how viable they could be for our case. Although no final decision has been made yet, this step is important because the accuracy of recognition will depend on it later on.

In addition, I have been thinking about possible strategies to classify between the object and the wall. The goal is to find a clear way to distinguish them that is both robust and simple to implement. For now, these are just initial ideas, but I believe they will lay the foundation for the practical work in the upcoming weeks.

In summary, it was not a week of big visible results, but rather of analysis and preparation, which I consider necessary to move forward effectively.

Théo :

This week, I continued to get more familiar with the micro:bit and with C/C++. I also attempted to figure out how to interact with the sensors, although with limited success